Raspberry Pi4 bootloader beta update and new stable release stream

[22/7]

I've had network boot on my pi4 working flawlessly now for some months. I got it to work by using the then "beta" firmware.

How should I go about setting it to "stable" without affecting my working netboot?

Thanks.

TTT. My question got buried amid alot of off topic chatter.

Thank you.

[timg236]

I've had network boot on my pi4 working flawlessly now for some months. I got it to work by using the then "beta" firmware.

How should I go about setting it to "stable" without affecting my working netboot?

Thanks.

TTT. My question got buried amid alot of off topic chatter.

Thank you.

If you edit /etc/default/rpi-eeprom-update and change FIRMWARE_RELEASE_STATUS you can set it to 'stable' instead of 'beta'
https://www.raspberrypi.org/documentati ... teeprom.md

The rpi-eeprom-update shell-script literally appended to /lib/firmware/raspberrypi/bootloader in order to switch the current firmware directory.

So you can actually call this whatever you like, create your own directories with saved EEPROMs containing customized configurations.
e.g. I have a dev or test directories where I can easily stash test configurations.

[BeauSlim]

Yet another thing to add to the list for companies during COVID 19: Remind everyone to take their work chair home. No joke.

The naming scheme makes perfect sense to me, and it is similar to many other projects.

[alsala]

My two cents with a thought, yet just another personal opinion.

Hi there, while I am a forum newbie , I've been in the IT industry for looong time and, in my opinion, an easy way to understand the naming would be to consider the 'Critical' as for 'Mission Critical Devices' so, basically, those where you don't want to mess around with new features because you want things to stay exactly as they are unless some good (critical) reason to upgrade.

Peace! and thanks to the engineers for they support and patience and to the users for pushing things to make products always a little better.

[22/7]

@timg236

All good and thank you. Updated bootloader with stable and netboot is still working. I used the use_flashrom feature due to netboot and no issues so far.

[kpf]

I too have a pair of 4Bs running network boot (for months) happily so thank you for all of the work you put into this, everyone!

I'd like to try the new SELF_UPDATE mode, so that I don't need to have SD cards in my Pis, but I can't quite figure out how to tell rpi-eeprom-update to do the right thing. As I understand it, it will have to notice that there is a newer bootloader version, merge the existing configuration values into a copy of the new version, and then drop it into /boot as pieeprom.upd. I've read through the entire script a few times and I can only see two modes: the flashrom mode where the update is applied immediately, and the recovery mode where recovery.bin is used to apply the update.

What's the proper incantation for rpi-eeprom-update to place the files into /boot so that SELF_UPDATE can use them?

[Rukbat]

Why do people think that telling us to hurry up and do something will actually make things happen faster?

After 46 years of being told to develop software faster, James, I gave up trying trying to figure out why people think that and started wondering if some people think at all.

I'm champing at the bit for USB boot on a 4, but I'd rather wait for a good implementation than a fast one. The end of the year would be just fine with me. (I can still pretty much boot from the SSD, with the exception of a little bit of use of the SD, so I'm okay with the current situation.)

[timg236]

I too have a pair of 4Bs running network boot (for months) happily so thank you for all of the work you put into this, everyone!

I'd like to try the new SELF_UPDATE mode, so that I don't need to have SD cards in my Pis, but I can't quite figure out how to tell rpi-eeprom-update to do the right thing. As I understand it, it will have to notice that there is a newer bootloader version, merge the existing configuration values into a copy of the new version, and then drop it into /boot as pieeprom.upd. I've read through the entire script a few times and I can only see two modes: the flashrom mode where the update is applied immediately, and the recovery mode where recovery.bin is used to apply the update.

What's the proper incantation for rpi-eeprom-update to place the files into /boot so that SELF_UPDATE can use them?

There aren't any special incantations, rpi-eeprom-update writes the files to /boot as normal. The difference is that once you have enabled SELF_UPDATE in the bootloader a subsequent network boot will be able to update itself.

On an SD-CARD boot, this has no effect because it will still run recovery.bin because the ROM will see it. That's the desired behaviour because the recovery.bin approach is safe in the event of power failure.

[kpf]

Thanks, so I can just revert the configuration for rpi-eeprom-update to write into /boot instead of /sdboot, and enable SELF_UPDATE in the bootloader configuration.

[timg236]

Thanks, so I can just revert the configuration for rpi-eeprom-update to write into /boot instead of /sdboot, and enable SELF_UPDATE in the bootloader configuration.

You need to set bootloader_update=1 in config.txt as well, that makes it easier for this to be conditional or reverted once complete

https://www.raspberrypi.org/documentati ... _config.md

The bootloader just looks for pieeprom.upd, pieeprom.sig and vl805.bin and vl805.sig and recovery.bin is ignored and then deleted by the rpi-eeprom-update when run at startup.

IIRC rpi-eeprom-update might complain if /boot ($BOOTFS) doesn't look like a boot partition i.e. no start.elf

[dickon]

Hmm. Thought I'd try this this morning, following the instructions at https://www.raspberrypi.org/documentati ... _config.md. But I get:

Code: Select all

BCM2711 detected
*** INSTALLING ./pieeprom-new.bin  ***
Applying bootloader update ./pieeprom-new.bin
flashrom  on Linux 5.4.29-v7l+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
linux_spi_init: failed to open /dev/spidev0.0: No such file or directory
Error: Programmer initialization failed.
flashrom EEPROM update failed

and, indeed, there's no /dev/spidev0.0 around. I don't have anything SPI on any of my Pis, so this is unknown territory to me. What have I done?

Linux pi4 5.4.29-v7l+ #1304 SMP Tue Apr 7 18:38:20 BST 2020 armv7l GNU/Linux

[kpf]

Yep, it does, my Ansible script has 'touch dummy.elf' for that reason, and I've got an issue open in the GitHub repo to get that behavior changed

[timg236]

Hmm. Thought I'd try this this morning, following the instructions at https://www.raspberrypi.org/documentati ... _config.md. But I get:

Code: Select all

BCM2711 detected
*** INSTALLING ./pieeprom-new.bin  ***
Applying bootloader update ./pieeprom-new.bin
flashrom  on Linux 5.4.29-v7l+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
linux_spi_init: failed to open /dev/spidev0.0: No such file or directory
Error: Programmer initialization failed.
flashrom EEPROM update failed

and, indeed, there's no /dev/spidev0.0 around. I don't have anything SPI on any of my Pis, so this is unknown territory to me. What have I done?

Linux pi4 5.4.29-v7l+ #1304 SMP Tue Apr 7 18:38:20 BST 2020 armv7l GNU/Linux

I suspect there's an issue with the dtoverlay to enable SPI in the 5.4 kernel. I'd suggest disabling USE_FLASHROM in /etc/default/rpi-eeprom-update

[dickon]

I suspect there's an issue with the dtoverlay to enable SPI in the 5.4 kernel. I'd suggest disabling USE_FLASHROM in /etc/default/rpi-eeprom-update

That 'works', but then obviously doesn't actually flash anything... The eeprom version is older than the self-update-capable version.

[dividuum]

[...] the recovery.bin approach is safe in the event of power failure.

I've read that in the documentation (section SELF_UPDATE) already. I guess the reason is that if the EEPROM update is done by recovery.bin, one of two outcomes can happen:

• Pi finds and loads recovery.bin, which then flashes pieeprom.upd and others and finally rename itself to recovery.001 before a reboot.
• Pi finds and loads recovery.bin, flashes pieeprom.upd and is power cycled. The firmware is broken, but as the recovery.bin still exists and is loaded even before the now half-flashed code is jumped into, the process restarts hopefully succeeding in the next attempt.

Correct? If so, the reason the self update isn't safe, is that there's no emergency recovery.bin to retry a failed flash initiated by the existing running.

[timg236]

[...] the recovery.bin approach is safe in the event of power failure.

I've read that in the documentation (section SELF_UPDATE) already. I guess the reason is that if the EEPROM update is done by recovery.bin, one of two outcomes can happen:

• Pi finds and loads recovery.bin, which then flashes pieeprom.upd and others and finally rename itself to recovery.001 before a reboot.
• Pi finds and loads recovery.bin, flashes pieeprom.upd and is power cycled. The firmware is broken, but as the recovery.bin still exists and is loaded even before the now half-flashed code is jumped into, the process restarts hopefully succeeding in the next attempt.

Correct? If so, the reason the self update isn't safe, is that there's no emergency recovery.bin to retry a failed flash initiated by the existing running.

Correct. The ROM always loads recovery.bin in the SD card in preference to SPI flash so that you can always update the SPI flash. If the SPi flash is corrupted and there's no SD card then there's no fallback. The ROM doesn't support failover to alternate SPI flash images and there's not enough space in the current SPI flash for that anyway.

The recovery.bin rename only happens after the SPI and VL805 flash has been readback and validated.

SELF_UPDATE is pretty safe for end-users who have the option to use Pi Imager to fix things. It's just a warning to anyone tempted to use this for remote industrial computers

[dividuum]

Thanks timg236 for confirming and giving some extra details.

[dickon]

I suspect there's an issue with the dtoverlay to enable SPI in the 5.4 kernel.

You were right. This being a media machine (or will be, once there's 10b support) I have dtparam=audio=on in /boot/config.txt. A random dmesg at the right time showed it clashing with the SPI. Disabled it and flashrom runs.

[bls]

IMHO the names are less critical (no pun intended) than having documentation handy. May I suggest that the next Raspbian update add a few lines of comments to /etc/default/rpi-eeprom-update:

Code: Select all

# Value may be one of:
#            beta - Bleeding edge firmware
#            stable - More stable than beta, but not yet recommended for newbies
#            critical (default) - The most stable firmware, recommended for newbies
#            someothername - You can create your own firmware directory under /lib/firmware/raspberrypi/bootloader/
#                                       See https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md for details

[M1dn1ghtN1nj4]

Maybe a dumb question, but when flashing the bootloader, is it persistent? I can swap sd cards, reinstall Raspian/OctoPrint etc, and the bootloader will stay updated? Updated on an eeprom similar to a BIOS?

[dividuum]

Maybe a dumb question, but when flashing the bootloader, is it persistent? I can swap sd cards, reinstall Raspian/OctoPrint etc, and the bootloader will stay updated? Updated on an eeprom similar to a BIOS?

Exactly.

[timg236]

IMHO the names are less critical (no pun intended) than having documentation handy. May I suggest that the next Raspbian update add a few lines of comments to /etc/default/rpi-eeprom-update:

Code: Select all

# Value may be one of:
#            beta - Bleeding edge firmware
#            stable - More stable than beta, but not yet recommended for newbies
#            critical (default) - The most stable firmware, recommended for newbies
#            someothername - You can create your own firmware directory under /lib/firmware/raspberrypi/bootloader/
#                                       See https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md for details

It's already documented in the online documentation and rpi-eeprom-update -h, and man rpi-eeprom-update

More than happy for people to submit PRs (and thanks to those who already have done so!) to improve text and documentation That tends to get updated much faster than people complaining about docs on forums

[bls]

It's already documented in the online documentation and rpi-eeprom-update -h, and man rpi-eeprom-update

More than happy for people to submit PRs (and thanks to those who already have done so!) to improve text and documentation That tends to get updated much faster than people complaining about docs on forums

Fair point.

[Gavinmc42]

I'm in a bad mood. I'm at home....,

Yep we know that feeling .
I found plenty of calming youtube lockdown music channels the second day.
If you turn the volume up a little it drowns out some of the screaming from the next room.
Get ones with nice landscapes, it is like traveling the world from home.

Edit - the box the delivery person just dropped off has yoga mats etc and a lower back support band.
It seems to be helping with this cheap office chair.
The lesson learned- when in lockdown get fit first before doing renovations.

[dickon]

I can't get this working.

Code: Select all

root@pi4:~# rpi-eeprom-update -a
BCM2711 detected
*** INSTALLING EEPROM UPDATES ***
BOOTLOADER: up-to-date
CURRENT: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
 LATEST: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
 FW DIR: /lib/firmware/raspberrypi/bootloader/stable
VL805: update required
CURRENT: 000137ab
 LATEST: 000137ad
EEPROM updates pending. Please reboot to apply the update.
root@pi4:~# ls /boot/vl8*
/boot/vl805.bin  /boot/vl805.sig
root@pi4:~# vcgencmd bootloader_config | grep SELF
SELF_UPDATE=1
root@pi4:~# grep bootload /boot/config.txt
bootloader_update=1

and I don't see any requests for pieeprom.upd, pieeprom.sig, vl805.bin, or vl805.sig in either the bootserver logs or on the boot UART output (which seems to stop dead after 'Starting start4x.elf @ 0xfec00200').

Ideas?