Boot ROM Loader

Confused again

While the Boot ROM loader will handle multiple segments, I don't see an issue, that warrants doing the extra steps for checksum as I described below. Not sure what's different. Could the difference be that they moved the CRC and CRC length out of eboot? I am too tired I'll leave this for now.

What I am seeing today. The before and after look like this:

Without my fix:

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3460, room 16 
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4 
tail 4
chksum 0xc9
csum 0xc9
v00042dc0
~ld

Perhaps I thought the first cksum should have always been 0, based on the working boot text I found on the Internet.

With my fix:

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3472, room 16 
tail 0
chksum 0x00
load 0x3fff20b8, len 40, room 8 
tail 0
chksum 0x05
csum 0x05
v00042dc0
~ld

And yet my custom branch gets this:

Addendum: And, master as well if I rebuild eboot.elf. Also, the extra mystery text ho 0 tail 12 room 4 goes away if I use my improved(?) elf2bin.py. I didn't make note of the original cryptic failure message that caused me to make my changes to elf2bin.py. I suppose it could have been ho 0 tail 12 room 4.

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3548, room 16 
tail 12
chksum 0x77
ho 0 tail 12 room 4
load 0x3fff20cc, len 21, room 12 
tail 9
chksum 0x61
csum 0x61
v00042f30
~ld

Boot ROM Loader - Using Multiple segments

While ESP8266 Application Note - Firmware Download Protocol and esptool WiKi - Firmware Image Format, provides some information on bootloader headers.

found some more interesting bits Serial-Protocol

The details for checksumming multiple segments it is incomplete. I could not find any detailed documentation on what the Boot ROM Bootloader expects. So I resorted to the empirical method. This is based on that. Maybe this is common knowledge, I just could not find it.

1. The Boot ROM loader expects a checksum at the end of the 16-byte alignment that immediately following the last segment's payload.
2. When there are multiple segments each segment has a CS. While it is documented that the first checksum calculation is started with 0xEF, it is not documented that for each additional segment and CS it is calculated starting with zero.
3. Except for the last segment, each segment payload length is modified to include the 16-byte alignment with CS at the end. This allows the loader to, add segment length to the beginning of the payload, to find the next segment header.
4. Because of the size increase to include CS, adjacent segments can overlap. This makes the ordering of those segments in the .bin more critical. When the 1st of an adjacent segment is loaded, the padding and checksum are also loaded. Then the adjacent segment begins by overwriting the padding, etc. If they are reversed, some of the previous segment would be overwritten by padding and CS of the 2nd.

As an experiment using these adjustments and updates to elf2bin.py, I was able to add a strings segment to reboot.