[AlejoPm03]

Fixes: #4500

To communicate with the EEPROM, we compile and install the EEPROM overlay when generating the Raspberry Pi image. I suggest that, in the future, we investigate a way to provide our custom overlays separately or add a compilation step during updates. Currently, the overlay is only installed when generating the Raspberry Pi image, so users who only update BlueOS won't get the EEPROM overlay.

The EEPROM may contain Raspberry Pi HAT ID information. Before performing a backup, we check whether a HAT ID partition exists and parse it to determine its size, ensuring that this information isn't overwritten.

The parameters partition contains a magic word and a CRC, allowing us to locate and validate it regardless of where it's stored in the EEPROM. This is useful because its offset can vary depending on the presence and size of the HAT ID information.

When a user attempts to perform a backup and we detect that the EEPROM isn't erased, we display a warning along with a hexdump. The user can then decide whether to proceed with the backup and overwrite the existing data.

eeprom.mp4

[joaoantoniocardoso]

Nice!

There is a detail I'd like to address before merging: the serialization format doesn't seem to be following the atom format, which is what HATs use. I couldn't fully get into, but we may want to reconsider how HATs are supposed to register as well, and think of the failure modes... I'm not entirely sure how catastrophic it can go if we erase something else. The last point would be whether we want to have versioning.

Useful references:

• Atom and EEPROM format: https://github.com/raspberrypi/hats/blob/master/eeprom-format.md
• Design guide (EEPROM hardware, write protect, ID pins): https://github.com/raspberrypi/hats/blob/master/designguide.md
• Device tree guide (the DT blob atom): https://github.com/raspberrypi/hats/blob/master/devicetree-guide.md
• Reference tools (eepmake, eepdump, eepflash): https://github.com/raspberrypi/hats/tree/master/eepromutils

[AlejoPm03]

Nice!

There is a detail I'd like to address before merging: the serialization format doesn't seem to be following the atom format, which is what HATs use. I couldn't fully get into, but we may want to reconsider how HATs are supposed to register as well, and think of the failure modes... I'm not entirely sure how catastrophic it can go if we erase something else. The last point would be whether we want to have versioning.

Useful references:

* Atom and EEPROM format: https://github.com/raspberrypi/hats/blob/master/eeprom-format.md

* Design guide (EEPROM hardware, write protect, ID pins): https://github.com/raspberrypi/hats/blob/master/designguide.md

* Device tree guide (the DT blob atom): https://github.com/raspberrypi/hats/blob/master/devicetree-guide.md

* Reference tools (eepmake, eepdump, eepflash): https://github.com/raspberrypi/hats/tree/master/eepromutils

Yes, I didn't serialize it as a HAT atom because, as I understand it, that format is intended for HAT identification and configuration data, so it doesn't seem appropriate for our calibration parameters.

I tried to make the implementation safe by checking whether a HAT ID partition exists in the EEPROM and parsing its header to determine its length. The write method then prevents writes to that region. Both legacy HAT and HAT+ use the same header layout, including the eeplen field that is the total partition length, so we can detect the partition's boundaries without parsing all the atoms.

If the HAT ID partition grows and overlaps our backup, the backup will be rejected because its magic word and CRC will no longer be valid.

If we want to be safer, we could always skip the first KB, so small hats stay protected without relying on the partition header being read correctly. I don't think that's necessary, though.