rpi-eeprom beta package - VL805 updates

[trejan]

Is there a way of knowing if the VLI update has been applied?

You need the vl805 utility from the rpi-eeprom package. There were standalone versions you could download for firmware testing but the utility was updated to fix some bugs so you should get the latest from rpi-eeprom.

Code: Select all

$ sudo vl805
VL805 FW version: 000137ab

This is undocumented but the vl805 utility is just reading from PCI config space for the firmware version. You can look at it directly by installing pciutils and running "sudo lspci -d 1106:3483 -xxx | grep 50:". The first 4 octets are the version number of the VL805 firmware in little endian format i.e. reversed.

Code: Select all

$ sudo lspci -d 1106:3483 -xxx | grep 50:
50: ab 37 01 00 00 00 00 00 00 00 00 00 06 11 83 34

If you want it nicely formatted then do

Code: Select all

$ sudo lspci -d 1106:3483 -xxx | awk ' { if ($1 == "50:") { print "VL805 FW version: " $5 $4 $3 $2 } } '
VL805 FW version: 000137ab

It is probably best to use the vl805 utility though as that is the documented way of getting the firmware version.

[Diablo2_Fan]

I usually use a different OS on my RPi4.

When I use a second SD card with Raspbian Buster and perform all updates. Does this update the eeprom across operating systems?

So if I then insert my other SD card again with e.g. gentoo, are the changes from "000137ab" also present?

[Kendek]

When I use a second SD card with Raspbian Buster and perform all updates. Does this update the eeprom across operating systems?

Yes, but you can also do a manually EEPROM/VLI update with this method. If the recovery.bin and image files are on the boot FAT32 partition, the upgrade will be performed in the next boot phase.

[andrum99]

I usually use a different OS on my RPi4.

When I use a second SD card with Raspbian Buster and perform all updates. Does this update the eeprom across operating systems?

So if I then insert my other SD card again with e.g. gentoo, are the changes from "000137ab" also present?

The Raspberry Pi 4B has two EEPROM chips on the board - one stores the bootloader, one stores the firmware for the VL805 USB controller chip. These are actual physical chips, so however you update them they will keep those contents.

None of the other models of Raspberry Pi have EEPROM chips. Hope that clarifies things.

[goodburner]

I would like to report that my raspberry pi 4B that I got a few days after release has been performing extremely well, and I decided to overclock it to 1925/600 @ +4, also downloaded the eeprom package here and it has become quite the little powerhouse. The performance appears smoother and faster than at launch. This is exactly what I'd want all companies to do. I guess devs abandoning their products appears to happen more often with software than hardware, however your continuous updates and fixes have shown me that you are extremely committed to your product.

I hated all the USB-C "issues" that were purported by the media as click bait, I don't know if that affected your sales? I hope it did not.
Would you mind sharing how "well" 4B has been performing, compared to the previous ones? Just curious to look at the number.

Thank you for everything!

PS: I maybe a bit drunk but whatever I say still holds lol

[bensimmo]

I would like to report that my raspberry pi 4B that I got a few days after release has been performing extremely well, and I decided to overclock it to 1925/600 @ +4, also downloaded the eeprom package here and it has become quite the little powerhouse. The performance appears smoother and faster than at launch. This is exactly what I'd want all companies to do. I guess devs abandoning their products appears to happen more often with software than hardware, however your continuous updates and fixes have shown me that you are extremely committed to your product.

I hated all the USB-C "issues" that were purported by the media as click bait, I don't know if that affected your sales? I hope it did not.
Would you mind sharing how "well" 4B has been performing, compared to the previous ones? Just curious to look at the number.

Thank you for everything!

PS: I maybe a bit drunk but whatever I say still holds lol

The USB-C click bait 'problem for a few' people probably helped sales, that was good cheap mass advertising everywhere.
It got the name and the fact there was a new Pi about.
It did however keep the media away from touching on the heating and near instant throttling issues at the start and nothing much of the official case makes it useless.

The updates are all good, the Pi4 has a lot of headroom from the default settings with just a bit of airflow. A whole new cooling solution avenue is keeping the resellers happy.

Now both these updates are performed automatically Excellent (assuming you are not an original Buster user) and don't follow how to get it.

[timg236]

Now both these updates are performed automatically Excellent (assuming you are not an original Buster user) and don't follow how to get it.

The rpi-eeprom package will be added as a dependency in the near future so the update process will just be

Code: Select all

sudo apt update
sudo apt upgrade
sudo reboot

N.B. A second reboot might be required if you have never updated the VC firmware because the rpi-eeprom-update uses the new 'vcgencmd bootloader_config' functionality to migrate bootloader settings. This is also required to check whether someone has set FREEZE_VERSION=1 to request that automatic EEPROM updates should be skipped.

[jamesh]

I would like to report that my raspberry pi 4B that I got a few days after release has been performing extremely well, and I decided to overclock it to 1925/600 @ +4, also downloaded the eeprom package here and it has become quite the little powerhouse. The performance appears smoother and faster than at launch. This is exactly what I'd want all companies to do. I guess devs abandoning their products appears to happen more often with software than hardware, however your continuous updates and fixes have shown me that you are extremely committed to your product.

I hated all the USB-C "issues" that were purported by the media as click bait, I don't know if that affected your sales? I hope it did not.
Would you mind sharing how "well" 4B has been performing, compared to the previous ones? Just curious to look at the number.

Thank you for everything!

PS: I maybe a bit drunk but whatever I say still holds lol

Sales unaffected as we are still slightly behind on the demand/supply curve although its almost sorted. We have made over 1M Pi4's so far! The 4GB has been a really good seller!

We do spend a lot of time and money ensuring things get better over time, and backward compatibility is very important so we retain it as much as we can. This means fixes for recent products are usually fixes for old product as well!

[dividuum]

Hey. I toyed around with the boot upgrade mechanism and have a few questions:

• If I have two FAT32 partitions (/dev/mmcblk0p1 / /dev/mmcblk0p2 in Linux notation), it seems that the built-in boot rom also detects the recovery.bin file on the second partition. At least once I place it there, the normal Pi OS in the first partition doesn't start for me. Is that correct? If so, does it search all FAT32 partitions?
• If that's the case, it also seems that the recovery.bin -> recovery.001 mechanism doesn't work in that case. The filename is unchanged and the system is stuck trying to update.
• Partially related: I tried to implement the upgrade mechanism using the LINUX_REBOOT_CMD_RESTART2 reboot mechanism. The idea is: Place recovery.bin, pieeprom.upd and accompanying files on a secondary partition, reboot the Pi into that partition. My ideal outcome would then be: The Pi starts recovery.bin from the secondary partition, applies the update, renamed recovery.bin to recovery.001 (thanks to the .upd extension on pieeprom.udp) and then reboots. The big advantage (at least as far as I see it) is that the normal boot partition is completely untouched and even if the upgrade somehow fails to remove the recovery.bin file, a normal power cycle would restart from the untouched first partition again. I guess due to the behaviour listed first, the boot loader would still find a recovery.bin file in the second partition and the complete idea won't work.
• Is the configuration file format for the eeprom the same as used in the config.txt? IIRC there is a [all] and [none] section. Are comments using # supported?

[timg236]

Hey. I toyed around with the boot upgrade mechanism and have a few questions:

• If I have two FAT32 partitions (/dev/mmcblk0p1 / /dev/mmcblk0p2 in Linux notation), it seems that the built-in boot rom also detects the recovery.bin file on the second partition. At least once I place it there, the normal Pi OS in the first partition doesn't start for me. Is that correct? If so, does it search all FAT32 partitions?
• If that's the case, it also seems that the recovery.bin -> recovery.001 mechanism doesn't work in that case. The filename is unchanged and the system is stuck trying to update.
• Partially related: I tried to implement the upgrade mechanism using the LINUX_REBOOT_CMD_RESTART2 reboot mechanism. The idea is: Place recovery.bin, pieeprom.upd and accompanying files on a secondary partition, reboot the Pi into that partition. My ideal outcome would then be: The Pi starts recovery.bin from the secondary partition, applies the update, renamed recovery.bin to recovery.001 (thanks to the .upd extension on pieeprom.udp) and then reboots. The big advantage (at least as far as I see it) is that the normal boot partition is completely untouched and even if the upgrade somehow fails to remove the recovery.bin file, a normal power cycle would restart from the untouched first partition again. I guess due to the behaviour listed first, the boot loader would still find a recovery.bin file in the second partition and the complete idea won't work.
• Is the configuration file format for the eeprom the same as used in the config.txt? IIRC there is a [all] and [none] section. Are comments using # supported?

The ROM scans through all FAT partitions until recovery.bin is found before trying the EEPROM. It does not look at the PM_RSTS register so there's no way to skip ignore a recovery.bin

The current recovery.bin does not scan through all the partitions so the files need to be on the first FAT partition. The recovery.bin is an evolution of the rescue image was was very minimal, I think walking the partition table could be supported but USB boot is top priority right now. If I get chance I'll put an updated recovery.bin in the "beta" folder to try.

The boot config file is the same as config.txt except there's no support for EDID filters or the include statement. The size is limited to about 2K. Comments with # are supported.

The [none] section could be used as an alternative to "Customer OTP settings" since there's no chance of conflicting with bootloader config keys.
https://www.raspberrypi.org/documentati ... ndustrial/

[dividuum]

The ROM scans through all FAT partitions until recovery.bin is found before trying the EEPROM. It does not look at the PM_RSTS register so there's no way to skip ignore a recovery.bin

Ok. Thanks for confirming.

The current recovery.bin does not scan through all the partitions so the files need to be on the first FAT partition. The recovery.bin is an evolution of the rescue image was was very minimal, I think walking the partition table could be supported but USB boot is top priority right now. If I get chance I'll put an updated recovery.bin in the "beta" folder to try.

That would be nice, but no hurry.

The boot config file is the same as config.txt except there's no support for EDID filters or the include statement. The size is limited to about 2K. Comments with # are supported.

The [none] section could be used as an alternative to "Customer OTP settings" since there's no chance of conflicting with bootloader config keys.
https://www.raspberrypi.org/documentati ... ndustrial/

I'm aware of the customer OTP feature and am using that already. The boot config file sounds like a great replacement if you don't need immutability. Thanks for your quick response!

[paul433]

I use a custom OS, so I have to adapt the rpi-eeprom package for my OS. I had the bootloader update working, but now and trying to do the vl805 update as well.

When I run sudo ./rpi-eeprom-update -a, it tells me that my bootloader is already on the latest version, but the vl805 needed updated.

On my boot partition, there is a recovery.bin, vl805.bin and vl805.sig. When I reboot, the system sits in a boot loop, when I pull the power, and look at the SD card, the 3 files are still there, untouched. I removed them, and the system booted fine, but the vl805 was not updated.

So this time I re-ran sudo ./rpi-eeprom-update -a, it copied the same files over, however I grabbed the recovery.bin from the beta folder. This time , the system rebooted, and everything worked fine. What is the difference in the recovery.bin files?

[mattmiller]

Is this still beta?

if so - fine

but if not - I'm thinking maybe a blog article about it would be a good idea as installling it has turned my Pi4 from a small room heater into something I'd be quite happy to let my kids go near now

[Paul Webster]

I did an apt-get update and upgrade on a clean RPi4 and rebooted a couple of times ... and did not receive the firmware update ... so looks like it is not pushed out for the general public yet.

[22/7]

Using the instructions here I have my pi4 successfully netbooting without an sdcard.

Setting it up like the pi2 bootcode.bin method and the pi4 files are on my omv nas.

All files and directories have the permissions set correctly.

However, I found that I can't update the new bootloader (rpi-eeprom-update) when it is netbooted. It appears to succeed but on a reboot the vcgencmd bootloader_config contents are unchanged.

I had to update the eeprom while booted from sdcard. Sudo works properly when netbooted.

[trejan]

However, I found that I can't update the new bootloader (rpi-eeprom-update) when it is netbooted. It appears to succeed but on a reboot the vcgencmd bootloader_config contents are unchanged.

This is because the default mechanism is to add recovery.bin + the new firmware to /boot and use recovery.bin at next boot to do the update. This won't work if you're netbooting. You can update it directly within Linux by setting the flashrom option but read the warning.

The default update mechanism writes recovery.bin and the EEPROM update
image(s) (pieeprom.upd and vl805.bin) to the boot partition on the sd-card.
The SHA256 hash of the corresponding images are written to pieeprom.sig
and/or vl805.sig. This guards against file system corruption which could
cause the EEPROM to be flashed with an invalid image. This is is not a
security check.

At the next reboot the ROM runs recovery.bin which updates EEPROM(s).
If the update was successful recovery.bin renames itself to recovery.000
to prevent it from running a second time then resets the system.
The system should then boot normally.

If /boot does not correspond to the boot partition on the sd-card and this
is not a NOOBS system then the mount point for BOOTFS should be defined
in /etc/default/rpi-eeprom-update by defining the BOOTFS variable.

For reference, the flashrom update mechanism may be enabled by defining
USE_FLASHROM=1 in /etc/default/rpi-eeprom-update. This not recommended
because the SPI pins are muxed with audio and other device drivers may
be using SPI (e.g. HATs). This is also not safe in the event of a power
failure during the update of the EEPROM.

[22/7]

@trejan,

So, how does the bootfs variable in /etc/default/rpi-eeprom-update look ie BOOTFS=???

Would it be another line or a single concat line?

[trejan]

So, how does the bootfs variable in /etc/default/rpi-eeprom-update look ie BOOTFS=???

BOOTFS is for non-standard installs on the SD card where /boot isn't the first partition. It isn't for netboot systems.

[22/7]

Hopefully when it is stable the eeprom updates will be functional through netbooted systems.

[dickon]

It is, just use the USE_FLASHROM option. Works for me.

[EpicROM]

Hi. Wouldn't
sudo rpi-update

do the job?

Or is it still not recommended to use that old hack? [I mean... I love to do the contrary of what it's written: it doubles the fun ]

[22/7]

It is, just use the USE_FLASHROM option. Works for me.

I was thinking to use that but wanted to be sure. I just migrated my 3d print server from a pi2 to my pi4 and I wasn't sure if having my printers connected via usb would be affected or affect the pi4 since the blurb states flash rom is not recommended due to spi and other devices.

I just figured out how to get my pi4 to netboot while my 3d printers were connected via usb and powered up. I had to use a usb "splitter" that doesn't seem to power the peripherals attached to it. On first test with the printers directly connected the pi4 would not start the ethernet. After the splitter all boots well.

[dickon]

Hi. Wouldn't
sudo rpi-update

do the job?

Or is it still not recommended to use that old hack? [I mean... I love to do the contrary of what it's written: it doubles the fun ]

With the Pi 4, we now have two things that are broadly considered 'firmware': the old start*.elf, bootcode.bin, and whatnot, and a new 32kB of EEPROM, which handles most of the initial powering up sequence, and loads the rest of the firmware from whatever it's capable of (which differs by version; currently uSD card and network). rpi-update won't handle the latter: you need the rpi-eeprom-update tool to update that.

[EpicROM]

@dickon: Many thanks and... confirmed. I ran rpi-update on the RPi4B and the EEPROM (as well as the bootblock) were not affected by it

[Diablo2_Fan]

After the update, am I the only one who got problems with the wifi?

A connection to a 2.4 ghz AP is no more possible.
5 ghz connections are possible but strongly restricted.