|V1: The version of the bootblock goes in the first byte. |
|V1: Determines which bootblock copy is newer. |
|V1: Boot-related and miscellaneous flags. |
|V1: The number of times the tertiary bootloader has booted a sketch. |
|V1: The number of times the tertiary bootloader has burned a sketch. |
|V2: The owner of this board, displayed in B36, 0xffffffff illegal. |
|V2: The name or id of this board, displayed in B36, 0xffffffff illegal. |
|V3: The count of full uptime hours on this board, excluding any fractions lost to reboots. |
|V4: The bits determining which faces should provide/accept power at boot time. |
|V5: Which of last eight boots (LSB: most recent) involved watchdog resets. |
|V6: Optional ADC calibration data for NSEW faceVoltage, and railVoltage. |
|Reserved for future use; currently undefined; should not be read. |
|The checksum of the first 60 bytes of this block. |
The SFBBootBlock structure is more complicated than it otherwise might be, to make it possible for an older tertiary bootloader to interoperate with a newer bootblock format in a reasonably sane way. In particular, an older tertiary bootloader should be able to verify the newer format, and get at the old fields that it knows about, without messing up newer fields it doesn't understand.
In addition, we reserve room in EEPROM for two SFBBootBlock, which are written to alternately, so that dying during a bootblock write will cause rollback to the prior bootblock, rather than the complete loss of all bootblock information. The value of the writeTag field determines which copy is 'current' and which is 'backup'.
This drastically reduces the chances that the (overall, redundant) boot block will be accidentally corrupted, even if a power failure occurs during a boot block update. Typically, in such a case, all that will happen is that interrupted update will be lost, and the backup, still-uncorrupted boot block will be treated as current instead.
V4: The bits determining which faces should provide/accept power at boot time.
V3: The count of full uptime hours on this board, excluding any fractions lost to reboots.
Note that maintaining this field involves an EEPROM write once an hour. This does age the EEPROM, although with the dual bootblocks it will take over two centuries to perform a million write operations. Nonetheless, if desired for whatever reason, incrementing of the powerOnHours can be suppressed by calling
V1: The version of the bootblock goes in the first byte.
If bootblock-handling code of a given version accesses a bootblock of a newer version, that older code must look only at the fields it understands (while faithfully double-buffering the entire block, however).
On the flip side, all future versions of the bootblock code must