ESP8266 Community Forum

- Sat Sep 06, 2014 6:30 pm #269 wi07c.rom starts with the same header as eagle.app.v6.flash.bin posted by someone on this forum, so that's it - first 256K is for user app, and that AT command interpreter is nothing but a user app (which is little suprise for those who hacked HC-04 bluetooth modules before). At 0x40000, there's indeed code, not random bytes, but code starts not from the very begining.

- Sat Sep 06, 2014 6:52 pm #270 what's in wi07c.rom maps at 0x40240000 and thus is:

Code: Select allirom0_0_seg :                       org = 0x40240000, len = 0x32000


Proof:

Browse wi07c.rom in hex editor from 0x40000 and grep for 0x24 0x40, you'll find B8 01 24 40, and indeed, at 0x401b8 offset there's clearly start a short routine. It ends with 0D F0 (ret.n), as expected, and is preceeded by some data word and ret.n of a previous routine.

- Sun Sep 07, 2014 5:23 am #291 The flash contains the compiled firmware image, starting at byte 0

The firmware image (e.g wi07c.rom) consists of several segments and is generated by genflashbinv6.exe in the SDK. I have reversed the file format and published it in my github repo.
This particular flash dump consists of 3 segments:

magic = e9, segments = 3, entrypoint=40100004
seg 0: base 40100000, 24236 bytes (.text segment, loaded to IRAM)
seg 1: base 3ffe8000, 3008 bytes (.data, loaded to DRAM)
seg 2: base 3ffe8bc0, 4816 bytes (.rodata, loaded to DRAM)

So the app, including headers, is about 32074 bytes. (Note that this header dump is coherent with the log that the ROM spews out when it boots from flash.) The rest of the flash is probably configuration and other cruft. I doubt that the data at 0x40000 is actually used, but I guess that we have to disassemble the application firmware or analyze the SPI conversation to really find out.

- Sun Sep 07, 2014 7:04 am #293

The flash contains the compiled firmware image, starting at byte 0

The firmware image wi07c.rom consists of several segments and is generated by genflashbinv6.exe in the SDK. I have reversed the file format and published it in my github repo.
The flash dump consists of 3 segments:

magic = e9, segments = 3, entrypoint=40100004
seg 0: base 40100000, 24236 bytes (.text segment, loaded to IRAM)
seg 1: base 3ffe8000, 3008 bytes (.data, loaded to DRAM)
seg 2: base 3ffe8bc0, 4816 bytes (.rodata, loaded to DRAM)

So the app, including headers, is about 32074 bytes. (Note that this header dump is coherent with the log that the ROM spews out when it boots from flash.) The rest of the flash is probably configuration and other cruft. I doubt that the data at 0x40000 is actually used, but I guess that we have to disassemble the application firmware or analyze the SPI conversation to really find out.

@Kongo: I suggest that you add your Github repo URL to your profile!

Thank you for your RE efforts, these are really helpful!

I think we are almost there, but as stated above, my guess is that what is at 0x40000 is actually used, here is why...

In order to generate a flashable firmware, you need to first run "make" as usual to generate the "eagle.app.v6.out" ELF file and the corresponding "eagle.app.v6.bin" raw binary file into the ".output\eagle\debug\image" directory.

Then, it looks like you must launch the "app\gen_misc.bat" script in order to generate the required flashable files, detailed below:

Code: Select allrm ../bin/eagle.app.v6.flash.bin
rm ../bin/eagle.app.v6.irom0text.bin
rm ../bin/eagle.app.v6.dump
rm ../bin/eagle.app.v6.S

cd .output\eagle\debug\image\

xt-objdump  -x -s eagle.app.v6.out > eagle.app.v6.dump
xcopy /y eagle.app.v6.dump ..\..\..\..\..\bin\

xt-objdump  -S eagle.app.v6.out > eagle.app.v6.S
xcopy /y eagle.app.v6.S ..\..\..\..\..\bin\

xt-objcopy -j .text eagle.app.v6.out eagle.app.v6.text.out
xt-objcopy -S -g -O binary eagle.app.v6.text.out eagle.app.v6.text.bin

xt-objcopy -j .data eagle.app.v6.out eagle.app.v6.data.out
xt-objcopy -S -g -O binary eagle.app.v6.data.out eagle.app.v6.data.bin

xt-objcopy -j .rodata eagle.app.v6.out eagle.app.v6.rodata.out
xt-objcopy -S -g -O binary eagle.app.v6.rodata.out eagle.app.v6.rodata.bin

xt-objcopy -j .irom0.text eagle.app.v6.out eagle.app.v6.irom0text.out
xt-objcopy -S -g -O binary eagle.app.v6.irom0text.out eagle.app.v6.irom0text.bin

xcopy /y eagle.app.v6.irom0text.bin ..\..\..\..\..\bin\

..\..\..\..\..\tools\gen_appbin.py eagle.app.v6.out v6

xcopy /y eagle.app.v6.flash.bin ..\..\..\..\..\bin\

cd ..\..\..\..\


This script:

• removes the old "eagle.app.v6.dump" ELF dump, "eagle.app.v6.S" disassembly file, "eagle.app.v6.flash.bin" and "eagle.app.v6.irom0text.bin" binary files from the \bin directory, if present
• creates the ELF "bin\eagle.app.v6.dump" dump file
• creates the "bin\eagle.app.v6.S" disassembly file
• creates the raw binary files corresponding to the ".text", ".data", ".rodata" and ".irom0.text" sections from the "eagle.app.v6.out" ELF file
• copies the raw binary "eagle.app.v6.irom0text.bin" to "\bin"
• launches the "tools\gen_appbin.py" script that will extract the ".text", ".data" and ".rodata" start addresses from the "eagle.app.v6.out" ELF file and pass them along with the split section files created above to the "tools\genflashbin.exe" in order to create the final "bin\eagle.app.v6.flash.bin"

Thus, besides the auxiliary dump and disassembly files, you get TWO output files: the "\bin\eagle.app.v6.flash.bin" file containing the user code and data AND the "\bin\eagle.app.v6.irom0text.bin" file containing the code from the static libraries located in "\lib". Please not that there is absolutely NO ASCII string in this file...

So, my guess is that the "\bin\eagle.app.v6.flash.bin" has to be flashed using the XTCOM_UTILITY to Flash offset 0x00000 as you found out, but also that the "\bin\eagle.app.v6.irom0text.bin" file has to be flashed using the same XTCOM_UTILITY with an 0x40000 offset too.

I don't know the reason why the static library code has to be separated from the main application code and data, but I suspect that this is related to the "cache" or "shadow" mechanism that is highly anticipated in other threads.