I have used a makefile to build my code and I have produced an ELF file.
To make it understandable for my attiny85, I usually use avr-objcopy -O ihex -R .eeprom -R .fuse main.elf main_all.hex. I get a hex file containing fuse settings. I flash the hex file with avrdude -p t85 -c avrispmkII -P usb -U flash:w:main_all.hex.
I am using an avrispmkII connected via a working and tested SPI.
This time I got an error.
ERROR: address 0x820003 out of range
I guess because I've played in the code with fuses that this is the problem. According to Contiki compile error, " ERROR: address 0x820003 out of range at line 1740 of...",
I've noticed that you can make avrdude create a hex without fuses.
avr-objcopy -O ihex -R .eeprom -R. Fuse main.elf main_ohne.hex
This has also worked and now lets the attiny85 flash completely normally.
Now the real question.
How do I still get the fuses on the attiny85?
Is there any way to see which fuse I am setting how, before I set the fuses? I ask explicitly before, because I have no experience in flashing with 12V (HV) and this arvmkII synonymous not true (Yes, I should look in the data sheet whether he can).
My main concern is to get the fuses on the attiny. I am a graduate electrical engineer who is programming in the spare time. So I'm fine with overprivileged links and the magic command.
(Rough translation from the German original)
You can set the fuse bytes on the command-line of avrdude. example
There are only 3 fuse bytes on the attiny: low, high, and extended. They can be found on p. 148 of the datasheet.
Just compute the fuse setting as a hex number and include -U switches like
-U efuse:w:0xff:m -U hfuse:w:0x89:m -U lfuse:w:0x2e:m
for the extended, high, and low fuses.
Related
I have 3 MB of SPI flash on my board and I am able to pack the bzImage, busybox initrd and coreboot ROM into this SPI flash. I am also able to boot to the shell , all using the ROM kernel-as-bootloader.
I have bigger kernel on the USB device. I am also able to detect the USB and mount it. But the problem is busybox does not seem to have kexec utility. I cannot use any other initrd package because my cpio (uncompressed) size should not go beyond 1.4 MB due to memory constraints. U-root has kexec support but the minimal image size easily reaches 3MB or at least, I couldn't find a way to built it lesser than that size.
Hence, is there a way to add kexec support to busybox (compile static binary and copy to initrd? ) or any other initrd package that can suffice the need within 1.4MB size?
EDIT
This post suggests that there may be kexec support available in busybox, but I couldn't find any trace of it. In fact the request to add kexec-tools to busybox was done over a decade ago. But when I did grep in the busybox, I saw no traces of it.
The kexec binary from kexec-tools takes about 300KB (x86_64 with -Os). Even if it would be added to busybox, it wouldn't get much smaller than that because it does need to do fairly complicated things that are not done anywhere else in busybox.
If you don't have even 300KB left, then you should probably remove configuration options from busybox itself to save space. With uClibc, you can also remove some options you don't need, like wchar and threading. Make sure you use static linking, it saves a little bit of space.
The following Buildroot defconfig generates an initramfs of exactly 1.4MB.
BR2_x86_64=y
BR2_x86_corei7=y
BR2_STATIC_LIBS=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="https://toolchains.bootlin.com/downloads/releases/toolchains/x86-64-core-i7/tarballs/x86-64-core-i7--uclibc--stable-2018.11-1.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_7=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_1=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
BR2_PACKAGE_KEXEC=y
BR2_PACKAGE_KEXEC_ZLIB=y
BR2_TARGET_ROOTFS_CPIO=y
# BR2_TARGET_ROOTFS_TAR is not set
We could build a version of kexec for busybox which results in a 220K static linked binary like so:
Use musl
Strip the binary with strip (Maybe it could reduce the size even more?)
Disable unused features via ./configure --without-<FEATURE>
KEXEC_VERSION=2.0.24
KEXEC=kexec-tools-$KEXEC_VERSION
curl -LO https://mirrors.edge.kernel.org/pub/linux/utils/kernel/kexec/$KEXEC.tar.xz
tar xf $KEXEC.tar.xz
cd $KEXEC
CC=musl-gcc LDFLAGS=-static ./configure \
--without-lzma \
--without-xen \
--sbindir=/bin
make
strip build/sbin/kexec
file buils/sbin/kexec # -> [...] statically linked, stripped
du -h build/sbin/kexec # -> 220K [...]
Still not great, but yeah.. Let us know if you could shrink it even more :-)
I'm attempting profile an Android NDK 14b clang based application with Google's simpleperf sampling profiler. The recorded callstack samples aren't actually unwound -- just the top frame of the callstack seems to be recorded, so the profiling reports aren't very useful. I've specified -fno-omit-frame-pointer in most of the code, but this seems to make no difference.
What am I missing? Is there a more current profiler for Android NDK projects I should be using?
If you are doing frame pointer based unwinding (using --call-graph fp option), please use aarch64 architecture, because arm has combined arm/thumb code, and can't unwind well even if you use -fno-omit-frame-pointer everywhere.
If you are doing dwarf based unwinding (using -g or --call-graph dwarf option), -fno-omit-frame-pointer doesn't work, and you'd better use shared libraries containing debug info in the apk.
It is also possible that the unwinding stops at java code. To unwind java code, you need to fully compiled it into native code and use dwarf based unwinding.
After all, you can use app_profiler.py contained in the ndk r14b. It tries to handle details for you, fully compiling the java code, and downloading libraries with debug info to device. It is also easy to check and change if it doesn't work well in your environment.
There are some simpleperf options I've found I need to specify (or not specify) which seem to make it more likely that I get the expected call-graph.
If I specify '-a --cpu 1' for instance, then the binary I'm profiling won't even appear in the call graph.
For instance if I do (where perf_text.x mostly spins for 1 second on cpu 1):
simpleperf record -g -a -e cpu-cycles --cpu 1 ./perf_test.x -C 1 -w bw -t 1
simpleperf report -g caller
then perf_test.x won't appear at all (for me) in the output.
So drop the --cpu x option if you are using it.
Also, high sampling rate increases the overhead. Below runs with the (current) default sampling rate of 4000 sample/sec.
simpleperf record -g -a -e cpu-cycles -F 4000 ./perf_test.x -C 1 -w bw -t 1
simpleperf report -g caller
Above shows simpleperf as the top process using 40-70% of the samples.
Reducing the sampling rate:
simpleperf record -g -a -e cpu-cycles -F 1000 ./perf_test.x -C 1 -w bw -t 1
simpleperf report -g caller
brought perf_test.x up to the top % of total samples and the 1st simpleperf entry comes in at 24% of total samples.
Hope this is helpful.
I am compiling a very basic "hello world" program with gcc, with this command line:
gcc -m32 prog_cible.c -o prog_cible
I am very surprised of the entry point address:
readelf -h prog_cible
...
Entry point: 0x420
I have tunrned off alsr with this command:
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
I think this cannot be the real entry point.
I suppose a base address is added to 0x420 ?
In the past, 10 years ago, readelf gave me the good entry point. What has changed since ?
Thanks
I think this cannot be the real entry point.
You are correct. Your gcc is likely configured to build PIE binaries by default. PIE binary is really a special form of a shared library.
If you look at the type of the binary (which readelf -h also printed), you'll see that it's a DYN, not EXEC.
You can disable PIE with gcc -m32 -no-pie ..., and then your entry point will look something like 0x8048420.
Is there a tool gcc or binutils that can show me the big consumers of .bss? I have tried to sum up sizes from objdump -t bin-file | grep bss but it does not add up to the same as when I do size bin-file.
I am trying to find out where the ram is going in an embedded project that is using some external libraries.
[EDIT]
It turned out to be the heap section defined in the link script that ate the "extra" bss that I did not see.
Print BSS consumption of every object file:
size --common -t *.o
In my build chain, I need to do this:
objcopy -I binary -O $BFDNAME -B $BFDARCH <this> <that>
in order to get a binary file into library form. Because I want other people to be able to use this, I need to know how to get $BFDNAME and $BFDARCH from their toolchain when they run the build. I can get the values locally by running objdump -f against a file I've already built, but is there a better way which won't leave me compiling throw-away files just to get configuration values?
Thank you for pointing this out, regularfry! Your answer helped me to find another solution which works without specifying the architecture at all:
ld -r -b binary -o data.o data.txt
On my system (Ubuntu Linux, binutils 2.22) both objcopy and ld approaches produce identical object files.
All credit goes to:
http://stupefydeveloper.blogspot.de/2008/08/cc-embed-binary-data-into-elf.html
For future reference, the answer seems to be this: the first entry in the output of objdump -i is the default, native format of the system.