ESP8266 Community Forum

- 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.

- Sun Sep 07, 2014 9:28 am #297 thank you.

now the IoT demo runs on the module without errors.

- Sun Sep 07, 2014 10:30 am #299

thank you.

now the IoT demo runs on the module without errors.

Yeah, great

And I still haven't receive mine yet...

Now, we need to get rid of the original SDK and replace it with a FOSS toolchain:

• working GNU toolchain (some Xtensa support person seems to be helping us on that)
• convert the "gen_misc.bat" DOS script into Bash or Python: should be easy
• replace the "genflashbin.exe" tool by a portable tool: almost done using Kongo's parsebin.py
• replace the "XTCOM_UTILITY" by a free (and more convenient) download tool: done using Kongo's esptool
• replace the static libraries in lib by open-source equivalent: BIG task, unless some of them are based on FOSS already, but can use objdup disassembly if required
• RE and document the existing functions in ROM: BIG task too!
• find out if there is a way to change the ROM contents: if yes, do it!

EDIT: however, for the last point, I fear that it is OTP and cannot be changed further. Not a big problem though, but could be nice to get rid of the Flash chip and have a small app running within the SoC itself

- Sun Sep 07, 2014 3:16 pm #327

thank you.

now the IoT demo runs on the module without errors.

Wow, great! Did you do anything special to make it work?

In other news, the ROM dump I made (esp8266.bin, md5 55eb884ecb257da22d9992a802134ff7) is actually corrupt, due to a protocol bug in esptool, which I have since fixed. I am very sorry for having wasted everybody's time. I just got a little bit excited and wanted to share the stuff

The new dump (http://df.lth.se/~kongo/esp8266.bin/iram0.bin, 7b52074c61442ee4c45f59d026313fa3), should hopefully be correct.
I have made an symbol-annotated disassembly for reference (http://df.lth.se/~kongo/esp8266.bin/iram0.txt), and it looks much more sane.

I'm planning to clean up esptool, probably integrating the image creation stuff, or perhaps make it read ELF and split it up automagically. Any and all feedback is welcome.