Pi 4 EEPROMs, recovery SDs and .sig files

Following on from a discussion in the WiFi in 5.30 thread about out-of-date EEPROM code, I am trying to construct an amendment to the Raspberry Pi Firmware wiki page to show how to update the Pi 4 EEPROM.

Exactly how new does the EEPROM need to be? At present, Raspberry Pi Imager will only deliver the January 2023 EEPROM code, which is the last-but-one “default” release (there is a later “default” release, but Raspberry Pi Ltd have not yet packaged it into a bootable SD image). Do we actually need the latest (i.e. April 2024) “default” EEPROM release? And if so, how would we install it without resorting to Raspberry Pi OS?

The GitHub repository contains some of the items necessary to create a recovery SD, but is missing the .sig files that recovery.bin uses to check bona fides of the individual code images. Is there an easy way of generating the hashes that these .sig files need to have?

Do we actually need the latest (i.e. April 2024) “default” EEPROM release?

I don’t think so.

On the Pi CM4 we do need start4.elf and fixup4.dat after 29-Feb-2024 so that eMMc and SD card are correctly discriminated. Recent firmware builds (2024-05-03 and 2024-05-24) have a bug in start.elf/start4.elf – the “framebuffer_swap=0” line in config.txt operates in reverse. This is corrected in recent versions of RISC OS 5.31.

bug in start.elf/start4.elf

Isn’t that by design?

you are quite right. I should have said a ‘feature’.

Revised wiki page with EEPROM update instructions now uploaded.

I still haven’t found out how to generate the .sig files, so I’m hoping that the “Raspberry Pi Imager” approach will install a sufficiently-recent EEPROM image.

The sig file is just a sha256sum of pieeprom.upd. There’s a sha256sum command in coreutils available via PackMan. Can be extracted from the zip file.

The sig file is just a sha256sum of pieeprom.upd.

Yes I’ve got that working, thanks. 8GB Pi 4B successfully re-flashed with April 2024 EEPROM.

Revised wiki page with EEPROM update instructions now uploaded.

Should the procedure for a Compute Module 4 also feature? They have EEPROM just like the Pi 4B and 400.

One detail missing from the instructions is why an EEPROM change might be needed. The text just says ‘you may need to update the boot EEPROM’ without explaining further – I’ve never felt the need to change the EEPROM. Are you saying some combinations of start4.elf and EEPROM are incompatible?

Should the procedure for a Compute Module 4 also feature? They have EEPROM just like the Pi 4B and 400.

I omitted the CM4 because I had a look at the Raspberry Pi page on upgrading the CM4 EEPROM and the process looked rather daunting. I readily accept that the CM4 would need to be added at some point.

One detail missing from the instructions is why an EEPROM change might be needed. The text just says ‘you may need to update the boot EEPROM’ without explaining further

I was prompted to update the wiki page by chatter in this forum thread which unfortunately didn’t go into specifics.

However, on a more general note, it seems reasonable to suppose that recent start4.elf releases may expect the EEPROM to be at least vaguely up-to-date (in much the same way that using a too-old bootcode.bin alongside a newer start.elf could potentially lead to problems). For example, there may be Pi 4B devices out there with 2019 EEPROM images still installed: while Raspberry Pi Ltd may be checking new start4.elf releases with some older EEPROM images, I suspect they aren’t going back that far.

I omitted the CM4 because I had a look at the Raspberry Pi page on upgrading the CM4 EEPROM and the process looked rather daunting.

It does look daunting on paper but updating thy EEPROM uses the same hardware setup as was used to flash the eMMC and may therefore familiar to the user. I would think is perfectly satisfactory to use a similar form of words as used for the RPi4/400 case and simply link to the Raspberry Pi notes.

At this point it became apparent that the github notes previously referred to have missing links, including the flashing the eMMC link.

These links seem better Compute Module EEPROM bootloader and Flash an image to a Compute Module

What all that looks like here is that an RPi5 hosts the software required to programme the CM4’s eMMC or EEPROM. The USB C on the CM4’s carrier board is connected to a USB A on the RPi5, which by a bit of good fortune is also sufficient to power the CM4. The CM4 is switched into ‘BOOT’ mode and if the EEPROM is to be programmed then its write protect must be disabled, which is a link on this carrier, and re-enabled afterwards. Different IO boards may have different arrangements and different jargon.

Changing the EEPROM version may not be a real requirement but changing the boot order can be.

HTH.

This works right out of the box with RISC OS, yes?