secure-boot-recovery5: Update docs to improve developer experience

[jack-obrien]

Hi there,

Recently I tried setting up secure boot on a pi5 and I had a lot of trouble wading through the docs and testing it.

In particular there was some confusion about the possibility to test booting from a signed pieeprom.bin EEPROM bootloader image without burning the OTP bits in the BCM2712. Seems other devs have had this issue, I found this forum post helpful at the time: https://forums.raspberrypi.com/viewtopic.php?t=370062

Most of this stuff should be pretty uncontroversial, just adding clarification about how the tools in this folder work.

However I would appreciate some feedback on the 2nd commit "secure-boot-recovery5: Document that BCM2172 needs burnt OTP to boot signed pieeprom.bin". The two LED blinks seems like an undocumented feature of the Pi 5. Just want to confirm my understanding is correct about the BCM2712 currently not booting a signed EEPROM image without first burning the public key into OTP.

[timg236]

I think this first paragraph is only true on a BCM2712 C1, unfortuantely BCM2712 D0 (CM5, Pi500 and newer Pi5) cannot do the flash code from the bootrom.

[timg236]

Looks good apart from the minor detail about different bootrom behaviour.

[jack-obrien]

Thanks for the feedback! Happy to update that commit about the bootrom behaviour.

Do you know if the BCM2712 D0 bootrom still needs burnt OTP to boot a signed EEPROM image?

I can check this myself soon if needed, I have a couple CM5s to play with.

[timg236]

Thanks for the feedback! Happy to update that commit about the bootrom behaviour.

Do you know if the BCM2712 D0 bootrom still needs burnt OTP to boot a signed EEPROM image?

I can check this myself soon if needed, I have a couple CM5s to play with.

Thanks for this. The BCM2712 C1 and D0 bootroms have the same OTP code signing requirements. Unfortunately, the D0 bootrom can't flash the activity LED due to fallout from the GPIO re-assignment between C1 and D0 which was in turn caused by removing the unused (by RPi) parts of the silicon.
So D0 will just fail to get based the bootrom USB descriptor. The Raspberry Pi secure-boot provisioner tracks the status of provisioned devices in an SQLlite database to try to make this more obvious because we can't just ask the device!