When the user runs rpi-eeprom-config to sign a bootloader image,
if the image is not the correct size, the error message returns
a tautology:
rpi-eeprom-config -c boot.conf -p /tmp/rpi-pubkey.pem \
-o pieeprom.upd /tmp/downloaded-boot.img
ERROR: /tmp/downloaded-boot.img: \
Expected size 62914560 bytes actual size 62914560 bytes
When it should be alerting the user that there are only two
valid values for a bootloader size. My MR addresses this issue
by returning the acceptable values for the bootloader size in the
image.
./rpi-eeprom-config -c boot.conf -p /tmp/rpi-pubkey.pem \
-o pieeprom.upd /tmp/downloaded-boot.img
ERROR: /tmp/downloaded-boot.img: \
Expected sizes [524288, 2097152] bytes, got actual size 62914560 bytes
Signed-off-by: Lincoln Thurlow <lincoln@isi.edu>
Improve the error handler for the case where the new EEPROM config
exceeds the amount of available free space. Display the filename,
new size and space available.
N.B The 2711/pieeprom-2025-08-13.bin restores the free space to a
little of 4KB again.
See: https://github.com/raspberrypi/rpi-eeprom/issues/732
Flashrom is the default update mechanism on Pi5 and is not
cancellable. Remove this misleading message.
rpi-eeprom-update already has a message which knows about flashrom.
20 seconds is a little too short for safety with flashrom if every
page has to be erased and re-written. Bump this to 60 seconds
which is probably too long but nothing good will come from
interrupting flashrom.
Update rpi-eeprom-config to support replacement of bootcode.bin
with a customer counter-signed version.
Add a new rpi-sign-bootcode script which enables bootcode.bin
to be counter-signed with the customer key.
N.B. Signed boot on 2712 requires newer firmware which is currently
under development and has not been released.
Allows you to add a custom ca cert to an image.
Note: This option is only relevant for newer (as yet unreleased)
bootloader images that support custom CA certs and reserve a space for
this in the flash image.
On Raspberry Pi 5 there are dedicated pins for the bootloader SPI
EEPROM. This makes it possible to do immediate updates via flashrom.
The "current" EEPROM config is the EEPROM config at boot rather
than what has just been written to the SPI flash because this is
consistent with current behaviour.
To use flashrom instead of recovery.bin for bootloader updates
set RPI_EEPROM_USE_FLASHROM=1 in /etc/defaults/rpi-eeprom-update
BCM2711
On CM4, Pi4, CM4-S, Pi400 config.txt must be modified to disable
the analog audio driver which shares the GPIO pins used by the
bootloader EEPROM.
dtparam=spi=on
dtoverlay=audremap
dtoverlay=spi-gpio40-45
BCM2711 and BCM2712 require different EEPROM firmware and
consequently the binaries have been moved to chip specific
firmware directories.
firmware-2711 / firmware-2712
Make it explicit that a modifiable file is stored withing a
single 4K sector (for erase) and that this includes the 20
byte header.
When modifying a file pad up to the next section instead of
just to an alignment size. This enables future changes to be
more flexible in terms of alignment and padding. Although,
files/sections with different padding requirements will likely
get a different magic.
The config read/update APIs have been replaced with generic
read/replace 'boot file' APIs in order to support secure-boot.
The previous secure-boot related commits broke the interactive
rpi-eeprom-config --edit/-a options.
Require python3 instead of relying on all distros including
python-is-python3 etc.
The code will still work with python2 but distros which require
python2 will need to maintain that as a downstream patch.
Display a warning if the bootloader version is downgraded. This can
happen when swapping boot-media and the bootloader configuration is
changed from an OS with an old version of the rpi-eeprom package.
Remove the duplicated "update pending" and "to cancel update" messages.
Some users might forcibly install this on a board that isn't an rpi4.
Exit early, and explain why the program can't be run.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
The previous implementation was reading the sysfs files as plain text
and encoding them as 'ascii' to remove all the trailing zeros. This is
wrong twofold. To start with, the sysfs file we're querying are binary
files[1], and we're reading it as a string. On top of that we're
benefiting that *some* python implementations of string.encode() will
deal with trailing zeros.
Fix this by marking the files as binary and decoding them as strings
before consuming them.
[1] sysfs files are generally text based, but there is also the option
to output binary data. Our configuration file does the later.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Always use the current EEPROM configuration unless there is an
update pending in which case use that to support incremental edits.
Update help and update message to indicate that
'sudo rpi-eeprom-update -r'
may be used to cancel a pending update.
Fix a few comments
Add -E to sudo in the example to preserve the environment.
Remove the redundant escaping of single quotes now that the help is
enclosed in triple quotes.
* Add -a/--apply parameter which provides a one shot image for applying
a new configuration to the latest bootloader image and installs it
via rpi-eeprom-update.
* Print the live configuration if no arguments are specified.
* Add short flags instead of requiring verbose names.
* Make the errors more human readable instead of Exceptions
The current help text for rpi-eeprom-config are unclear. This PR changes them so that the help text matches what the tool does and what each parameter specifies. The man page, automatically derived from the help text, is also fixed.
Update the rpi-eeprom-config tool to accept config files of up to
2024 byte. The config section has a 24byte header so the section is
always <= 2KiB.
This allows a reasonably large user-data section in the config file
accessible via 'vcgencmd bootloader_config' as an alternative to
customer OTP data.
N.B. The vcgencmd uses a single VCHIQ message which is limited to
4092 bytes. Setting a 2KiB limit here gives room for user-data plus
some spare space for future config expansion before an VCHIQ bulk
message or an extra EEPROM 4KiB page is required.
If the size of bootconf.txt is reduced then set the unused data
to all ones instead of leaving garbage at the end. The EEPROM
header contains the actual file but this makes it easier to
verify the image and makes overreads more obvious.
