Reprovisioning PiCM5 in secure boot

[osbagain]

Hi,

I've successfully* provisioned a Pi CM5 using Secure Boot.

Setup:

• Target device: Pi CM5 with eMMC, 32GB, 8GB.
• Target OS: Bookworm (for application compatibility reasons). I've used pi-gen to generate an image.
• Host device: Pi 5, running Trixie.
• A 15cm USB-A <--> USB-C cable
• A Waveshare IO board**.
• External USB-A integrated keyboard and trackpad connected to the Host pi and monitor via micro HDMI.

Initial provisioning flow was:

1. Jumper cable on BOOT
2. Check the rpi-provisioner-ui service is up and running - normally looking at the devices/detail tab.
3. Create the signing keys and set the options in the UI > Save options
4. Get logs and devices/detail UI page up on screen
5. Remove USB keyboard
6. Plug in USB-C into CM board
7. Press and hold pwr button on CM board
8. Plug in USB-A into provisioning Pi, then release
9. Move away, sit on hands, avoid all temptation, watch only.
10. Keyboard/trackpad back in - review results, then boot the pi on a LAN. Win.Side question: In a deviation from the docs, I didn't seem to need to unplug and replug to initiate a second stage. Is this expected?

Re-provisioning

I would now like to test the re-provisioning process so that I can always return the CM5 to a known state (secure boot, custom pi-gen-created image).

Naked: I've tested a re-provisioning flow using a naked-provisioned CM5 and that worked well and is repeatable. I've outlined it below in case it's useful to others or worthy of adding to the docs (I couldn't find an equivalent).

SB: I've tried just plugging the CM5 back in, but in the provisioner UI Services tab I get:

rpi-sb-bootstrap@dev-bus-usb-XXX-XXX              failed                  failed

And the logs for that line say:

Failed to claim interface
Loading /srv/rpi-sb-provisioner/rpi-sb-bootstrap.Yzx/secure-bootloader//bootcode5.bin
Sending bootcode.bin
Failed control transfer (-7, 24)
Failed to write correct length, returned -7

This doesn't brick the device - I can still connect it up to a LAN and it works fine.

I think I'm missing some fundamental part of what a re-provisioning step should look like. Should I be changing the options or preparing the device differently?

Of interest:

1. The -7 code. I also have 2 other CM5's that report this -7, 24 code which I've bricked in the process of learning. It would be great to bring those back from the dead if that's possible.

2. Official IO board vs Waveshare. I tried using official Pi IO board and while it was successful during the initial provisioning of my early now-bricked devices, I ran into problems and so threw hardware at the problem - suspecting it was something to do with power available from the Host/provisioning Pi over USB-A. The waveshare has PoE capability OOB, so I thought I could power the board using that while using USB-C for flashing.

3. Resetting process for naked provisioned CM5

• Host: sudo systemctl stop rpi-provisioner-ui
• Host: Using the github cloned and built usbboot repo, run: ./rpiboot -v
• Host: minimise any other power draw - remove Eth, remove keyboard/trackpad
• Connect: hold pwr button + connect USB-A to USB-C
• Host: Connect PoE Ethernet cable to Pi CM5 carrier board (the Waveshare). I haven't proven that this is strictly necessary, but it's certainly not breaking anything so I'm sticking with it for now.
• Host: sudo dd if=/dev/zero of=/dev/sda bs=4M status=progress to wipe CM5 (appearing as an externally mounted USB device to the host)
• Host: Wipe / reset eeprom:

cd usbboot/recovery5
./update-pieeprom.sh # generates a .img and .sig from the latest firmware (if I understand correctly) 
cd ..
./rpiboot -d recovery5

[timg236]

Running "./update-pieeprom.sh" without specifying the private key will created an unsigned image and will fail to boot.

You'd need something like ./update-pieeprom.sh -fr "${KEY_FILE}" (where KEY_FILE is the private key matching the code signing public key hash stored in OTP) to create a signed image but I think you should be able to do this within the normal sb-provisioner UI.

[tdewey-rpi]

Hi,

I've successfully* provisioned a Pi CM5 using Secure Boot.

Setup:

• Target device: Pi CM5 with eMMC, 32GB, 8GB.
• Target OS: Bookworm (for application compatibility reasons). I've used pi-gen to generate an image.
• Host device: Pi 5, running Trixie.
• A 15cm USB-A <--> USB-C cable
• A Waveshare IO board**.
• External USB-A integrated keyboard and trackpad connected to the Host pi and monitor via micro HDMI.

Have you considered using Raspberry Pi Connect to drive the server? Keeps your power budget for your target devices.

Side question: In a deviation from the docs, I didn't seem to need to unplug and replug to initiate a second stage. Is this expected?_

Yes - on most modern devices, the transition from bootstrap to provisioner is automatic.

Re-provisioning

I would now like to test the re-provisioning process so that I can always return the CM5 to a known state (secure boot, custom pi-gen-created image).

• If you want to completely re-provision the device with the same key:

---

sudo touch /etc/rpi-sb-provisioner/special-reprovision-device/

Replace <serial> with your device serial number.

In 2.3.0, I'm adding a WebUI change that will simplify this.

Of interest:

1. The -7 code. I also have 2 other CM5's that report this -7, 24 code which I've bricked in the process of learning. It would be great to bring those back from the dead if that's possible.

It's effectively impossible to brick a device without doing something seriously wrong - try reprovisioning with the flag I mentioned above

3. Official IO board vs Waveshare. I tried using official Pi IO board and while it was successful during the initial provisioning of my early now-bricked devices, I ran into problems and so threw hardware at the problem - suspecting it was something to do with power available from the Host/provisioning Pi over USB-A. The waveshare has PoE capability OOB, so I thought I could power the board using that while using USB-C for flashing.

Depending on your set-up, we do recommend using a powered USB hub between your server and your DUTs for this reason. I'm not confident that 3P hardware will result in fewer problems, but I can't claim to have tested the board you mention.

[osbagain]

Thanks very much for the support. Exciting that it might be as easy as touching a new file.

In my throwing of more hardware at the problem, I also dug out a powered USB hub. I'll give that a go. I hadn't thought about rpi connect and haven't played with it before, but it sounds like a good idea.

I'll also try the special-reprovision-device on the probably-not-bricked devices and report back. It's good to know that's the expected process for re-provisioning and that it's straightforward. To confirm, is it:

1. sudo systemctl stop rpi-provisioner-ui
2. Then sudo touch /etc/rpi-sb-provisioner/special-reprovision-device/<serial>
3. sudo systemctl start rpi-provisioner-ui
4. Then go through the pwr button + cable connecting dance

Or will it pick up the touched file without a service change?

[tdewey-rpi]

Thanks very much for the support. Exciting that it might be as easy as touching a new file.

In my throwing of more hardware at the problem, I also dug out a powered USB hub. I'll give that a go. I hadn't thought about rpi connect and haven't played with it before, but it sounds like a good idea.

I'll also try the special-reprovision-device on the probably-not-bricked devices and report back. It's good to know that's the expected process for re-provisioning and that it's straightforward. To confirm, is it:

1. sudo systemctl stop rpi-provisioner-ui
2. Then sudo touch /etc/rpi-sb-provisioner/special-reprovision-device/<serial>
3. sudo systemctl start rpi-provisioner-ui
4. Then go through the pwr button + cable connecting dance

Or will it pick up the touched file without a service change?

No service reload required - it'll be picked up when you re-connect the device. Note the flag is sticky.

[osbagain]

Thanks for your help @tdewey-rpi

I tried the touch /etc/rpi-sb-provisioner/special-reprovision-device/<serial> against my 2 'bricked' devices, but I still ended up with the -7, 24 error. If you'd be willing to take a look, I'd be happy to share the log files via DM. It would be great to unbrick them. I tried using a powered USB hub as part of this testing too.

Out of interest, is there a single log file that retains all the logs that are shown in the services tab of the UI? Figured it might be easier to read and share on the cmd line.

I will also try the special-reprovision-device on a successfully provisioned SB+FDE device to test out that factory reset flow.