Boot ROM Loader

Resolved

When the Boot ROM loader loads an eboot.bin with multiple segments, the segment(s) preceding the last segment need to be align filled to 16 bytes. Otherwise, a message similar to ho 0 tail 12 room 4 will appear in the boot messages.

This can be done through the eboot.ld file. Add something like:

  .text : ALIGN(4)
  {
 ...
    . = ALIGN (16); /* Ensure 16-byte alignment to keep Boot ROM loader happy with multi-segment eboot */
  } >iram1_0_seg :iram1_0_phdr

That said, while this will get rid of messages like ho 0 tail 12 room 4 in the boot message log. It is not clear to me, that it is an issue that needs to be fixed. I cannot find any details on that log message. And, I have found boot message logs posted where it occurs and the boot is considered a success.

Ignore the rest of this

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. Note, the eboot.elf checked-in to master does not need my elf2bin.py changes. Only if I rebuild it, do I need mine.

 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.