libbfd/binutils target for ESP firmware upgrade images
Posted: Sat Nov 15, 2014 5:10 pmHi,
this is for anyone interested in using objcopy instead of esptool, and to be able to use objdump to show disassembly from firmware images more easily. I've implemented a libbfd target called espimage. See https://github.com/tommie/binutils-gdb/tree/xtensa, a fork of binutils 2.24 with crosstool-NG patches (upstream and jcmvbkbc's). There are probably bugs in there, it's my first libbfd target module and a Saturday hack.
E.g. show all headers:
Create an upgrade image from an ELF executable:
It doesn't output the sections in the same order as genflashbinv6, but rather by load address (as produced by the linker). I would guess it doesn't matter, but haven't tried an image yet. The trivial test of doing a copy from espimage to espimage shows no diffs:
Since the app firmware is split into two normally, I'm afraid letting the linker output firmware images directly is a no-no.
this is for anyone interested in using objcopy instead of esptool, and to be able to use objdump to show disassembly from firmware images more easily. I've implemented a libbfd target called espimage. See https://github.com/tommie/binutils-gdb/tree/xtensa, a fork of binutils 2.24 with crosstool-NG patches (upstream and jcmvbkbc's). There are probably bugs in there, it's my first libbfd target module and a Saturday hack.
E.g. show all headers:
Code: Select all
$ objdump -b espimage -x eagle.app.v6.flash.bin
eagle.app.v6.flash.bin: file format espimage
eagle.app.v6.flash.bin
architecture: xtensa, flags 0x00000000:
start address 0x40100004
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00005e44 40100000 00000010 00000010 2**0
CONTENTS, ALLOC, LOAD, ROM
1 .data 00000dbc 3ffe8000 00005e5c 00005e5c 2**0
CONTENTS, ALLOC, LOAD, ROM
2 .data3 000018ac 3ffe8dc0 00006c20 00006c20 2**0
CONTENTS, ALLOC, LOAD, ROM
SYMBOL TABLE:
no symbols
Create an upgrade image from an ELF executable:
Code: Select all
$ objcopy -j .text -j .data -j .rodata -O espimage eagle.app.v6.out eagle.app.v6.flash.bin
It doesn't output the sections in the same order as genflashbinv6, but rather by load address (as produced by the linker). I would guess it doesn't matter, but haven't tried an image yet. The trivial test of doing a copy from espimage to espimage shows no diffs:
Code: Select all
$ objcopy -F espimage eagle.app.v6.flash.bin test.bin
$ cmp eagle.app.v6.flash.bin test.bin
Since the app firmware is split into two normally, I'm afraid letting the linker output firmware images directly is a no-no.