USB-MSD boot EEPROM first update - 2020-05-28

[timg236]

The APT firmware which was updated for the Chromium video crash also pulls in USB MSD support so rpi-update isn't required now. Although the more people testing 5.4 Kernel the better because hopefully, that will become the default before too long

[RonR]

@timg236,

I'm using the latest bootloader and vl805:

BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Thu 28 May 07:22:33 UTC 2020 (1590650553)
LATEST: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000137ad

and the latest RaspOS (Lite) (4.19.118) + usb-msd-boot-firmware.

With an empty /boot/config.txt, the green activity LED flashes at one second intervals polling an empty SD card slot as expected.

With only 'enable_uart=1' in /boot/config.txt, the green activity LED is solid on 99.9% of the time with an empty SD card slot.

Is this expected behavior?

What's the bootloader configuration?

Code: Select all

[all]
BOOT_UART=1
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
SD_BOOT_MAX_RETRIES=1
USB_MSD_BOOT_MAX_RETRIES=1
BOOT_ORDER=0xf41

Do you see anything on the HDMI display when it's in this state?

This is the latest RaspiOS Lite (both 4.19.118 and 5.4.44) using SSH (no HDMI display in use).

It might be worth trying the 2020-06-03 release

I updated to the 2020-06-03 release the moment it came out, but no change.

[timg236]

@timg236,

I'm using the latest bootloader and vl805:

BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Thu 28 May 07:22:33 UTC 2020 (1590650553)
LATEST: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000137ad

and the latest RaspOS (Lite) (4.19.118) + usb-msd-boot-firmware.

With an empty /boot/config.txt, the green activity LED flashes at one second intervals polling an empty SD card slot as expected.

With only 'enable_uart=1' in /boot/config.txt, the green activity LED is solid on 99.9% of the time with an empty SD card slot.

Is this expected behavior?

What's the bootloader configuration?

Code: Select all

[all]
BOOT_UART=1
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
SD_BOOT_MAX_RETRIES=1
USB_MSD_BOOT_MAX_RETRIES=1
BOOT_ORDER=0xf41

Do you see anything on the HDMI display when it's in this state?

This is the latest RaspiOS Lite (both 4.19.118 and 5.4.44) using SSH (no HDMI display in use).

It might be worth trying the 2020-06-03 release

I updated to the 2020-06-03 release the moment it came out, but no change.

Thanks, does it boot once the SD card is inserted? If I understand this correctly rootfs is on USB and bootfs is on SD card which isn't present at boot.
I'll try to reproduce that but it would be useful to know whether it's bypassing the error pattern or if it gets stuck in USB boot mode. The state transitions through config.txt to supper things like the boot partition directive for NOOBS is annoyingly complex once you through in retries, alternate partitions, NOOBS boot_partition and restarts but I can't see an obvious path for that issue.

[RonR]

Thanks, does it boot once the SD card is inserted? If I understand this correctly rootfs is on USB and bootfs is on SD card which isn't present at boot.
I'll try to reproduce that but it would be useful to know whether it's bypassing the error pattern or if it gets stuck in USB boot mode. The state transitions through config.txt to supper things like the boot partition directive for NOOBS is annoyingly complex once you through in retries, alternate partitions, NOOBS boot_partition and restarts but I can't see an obvious path for that issue.

This issue has nothing to do with booting. A USB device is booted properly using USB-MSD boot with no SD card present. The issue is ACT LED behavior following the USB-MSD boot EEPROM update.

If /boot/config.txt contains NO enable_uart=1 and NO dtparam=sd_poll_once, the ACT LED flashes at 1 second intervals as expected. If an SD card is inserted, the SD card is recognized and ACT LED activity is as expected.

If /boot/config.txt contains enable_uart=1 but NO dtparam=sd_poll_once, the ACT LED is on solid 99.9% of the time. If an SD card is inserted, the ACT LED goes off, but only after a considerable amount of time has passed, and the SD card is ultimately recognized.

If /boot/config.txt contains enable_uart=1 but AND dtparam=sd_poll_once, the ACT LED is off 100% of the time. If an SD card is inserted, it is not recognized and ACT LED remains off.

[timg236]

Thanks, does it boot once the SD card is inserted? If I understand this correctly rootfs is on USB and bootfs is on SD card which isn't present at boot.
I'll try to reproduce that but it would be useful to know whether it's bypassing the error pattern or if it gets stuck in USB boot mode. The state transitions through config.txt to supper things like the boot partition directive for NOOBS is annoyingly complex once you through in retries, alternate partitions, NOOBS boot_partition and restarts but I can't see an obvious path for that issue.

This issue has nothing to do with booting. A USB device is booted properly using USB-MSD boot with no SD card present. The issue is ACT LED behavior following the USB-MSD boot EEPROM update.

If /boot/config.txt contains NO enable_uart=1 and NO dtparam=sd_poll_once, the ACT LED flashes at 1 second intervals as expected. If an SD card is inserted, the SD card is recognized and ACT LED activity is as expected.

If /boot/config.txt contains enable_uart=1 but NO dtparam=sd_poll_once, the ACT LED is on solid 99.9% of the time. If an SD card is inserted, the ACT LED goes off, but only after a considerable amount of time has passed, and the SD card is ultimately recognized.

If /boot/config.txt contains enable_uart=1 but AND dtparam=sd_poll_once, the ACT LED is off 100% of the time. If an SD card is inserted, it is not recognized and ACT LED remains off.

There’s some a couple of issues in the Linux repo about this. AIUI the SDHCI driver polls rather than using card detect because card detect can be unreliable and is possibly muxed with something else. This means that without an SD card the driver keeps polling looking for an SD card and then reports the errors in the kernel log which becomes worse if you have enable uart. Personally I’m happy to change the verbosity of the errors but if someone who knows the driver has a better PR that would be welcome. It won’t fix the activity LED but it might be possible to bodge it to not update the LED unless the card is initialised

[andrum99]

Thanks, does it boot once the SD card is inserted? If I understand this correctly rootfs is on USB and bootfs is on SD card which isn't present at boot.
I'll try to reproduce that but it would be useful to know whether it's bypassing the error pattern or if it gets stuck in USB boot mode. The state transitions through config.txt to supper things like the boot partition directive for NOOBS is annoyingly complex once you through in retries, alternate partitions, NOOBS boot_partition and restarts but I can't see an obvious path for that issue.

This issue has nothing to do with booting. A USB device is booted properly using USB-MSD boot with no SD card present. The issue is ACT LED behavior following the USB-MSD boot EEPROM update.

If /boot/config.txt contains NO enable_uart=1 and NO dtparam=sd_poll_once, the ACT LED flashes at 1 second intervals as expected. If an SD card is inserted, the SD card is recognized and ACT LED activity is as expected.

If /boot/config.txt contains enable_uart=1 but NO dtparam=sd_poll_once, the ACT LED is on solid 99.9% of the time. If an SD card is inserted, the ACT LED goes off, but only after a considerable amount of time has passed, and the SD card is ultimately recognized.

If /boot/config.txt contains enable_uart=1 but AND dtparam=sd_poll_once, the ACT LED is off 100% of the time. If an SD card is inserted, it is not recognized and ACT LED remains off.

There’s some a couple of issues in the Linux repo about this. AIUI the SDHCI driver polls rather than using card detect because card detect can be unreliable and is possibly muxed with something else. This means that without an SD card the driver keeps polling looking for an SD card and then reports the errors in the kernel log which becomes worse if you have enable uart. Personally I’m happy to change the verbosity of the errors but if someone who knows the driver has a better PR that would be welcome. It won’t fix the activity LED but it might be possible to bodge it to not update the LED unless the card is initialised

A quick google reveals the following will disable the activity LED altogether:

Code: Select all

dtparam=act_led_trigger=none
dtparam=act_led_activelow=off

It is also possible to configure the activity LED to be a heartbeat indicator, which means it will flash slowly for low system load, and fast for high system load:

Code: Select all

dtparam=act_led_trigger=heartbeat

[RonR]

A quick google reveals the following will disable the activity LED altogether:

Code: Select all

dtparam=act_led_trigger=none
dtparam=act_led_activelow=off

It is also possible to configure the activity LED to be a heartbeat indicator, which means it will flash slowly for low system load, and fast for high system load:

Code: Select all

dtparam=act_led_trigger=heartbeat

I think you missed the whole point. I'm aware of both the options above as well as others.

The issue is whether simply adding 'enable_uart=1' with no other options present should change the ACT LED from flickering (polling) at one-second intervals (the normal expected behavior) to instead be on solid 99.9% of the time.

[LTolledo]

The APT firmware which was updated for the Chromium video crash also pulls in USB MSD support so rpi-update isn't required now. Although the more people testing 5.4 Kernel the better because hopefully, that will become the default before too long

WOAH! so does this means that when I do apt update and upgrade it's available now? (if it is THANKS!)

as the RPi4B-8G arrived it has replaced the board on my primary desktop, the RPi4GB-4G now replaced the RPi3B+ on the secondary desktop.
and am itching to do SSD native boot on the secondary desktop....

yeah I was experiencing Chromium video crashes last night on this secondary desktop and forced me to do an update/upgrade .... seems stable for now... (is still monitoring the system status via ssh + htop on another unit)...

though it might be a bit off topic (or not related).... I do still experience some intermittent freezes on USB wireless keyboard and mouse on the recently updated/upgraded RPi4B-4G
am not using WiFi and Bluetooth...(both are turned off).


Many thanks!

[HawaiianPi]

The APT firmware which was updated for the Chromium video crash also pulls in USB MSD support so rpi-update isn't required now.

Interesting. Restored an SD card from a pre-beta backup, booted from that, then ran sudo apt update && sudo apt full-upgrade -y followed by a reboot. When the system was back up I cloned that card to my SSD, shutdown, pulled the card and powered it up again.

And ... it booted from USB. So it seems much simpler now. Same configuration as before, except for the kernel.

Code: Select all

~ $ uname -a && sudo rpi-eeprom-update && vcgencmd bootloader_version && vcgencmd bootloader_config

Linux RaspberryPi4B2 4.19.118-v8+ #1311 SMP PREEMPT Mon Apr 27 14:32:38 BST 2020 aarch64 GNU/Linux
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Wed 03 Jun 2020 12:53:47 PM UTC (1591188827)
 LATEST: Thu 16 Apr 2020 05:11:26 PM UTC (1587057086)
 FW DIR: /lib/firmware/raspberrypi/bootloader/stable
VL805: up-to-date
CURRENT: 000138a1
 LATEST: 000137ad
Jun  3 2020 13:53:47
version b5de8c32f4f45a12a1fdfe107254df82965f9d56 (release)
timestamp 1591188827
[all]
BOOT_UART=1
WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
SD_BOOT_MAX_RETRIES=0
USB_MSD_BOOT_MAX_RETRIES=2
BOOT_ORDER=0xf41

Although the more people testing 5.4 Kernel the better because hopefully, that will become the default before too long

Now I need to rpi-update again and see if I can re-create the hard crash I had earlier. I suppose I should do that on my other drive...

EDIT
Yup, it still crashes.

Since this seems related to the 5.4 kernel (or something else installed by rpi-update) and is not caused by the boot-loader, I'll start a thread in Troubleshooting. The gist of it is that tvservice --modes=DMT (or CEA) makes the system hard crash!

More info here: 5.4 kernel: tvservice --modes=DMT command causes hard crash

[LTolledo]

all righty....might as well give this a whirl.....

Update:
Crash and burn.......error booting from SSD...

reverting to microSD boot....
oh well.... the waiting continues.....

wait.... do I need to manually invoke update of the EEPROM or was it done automatically at update/upgrade?

[HiassofT]

I was quite positively surprised that the RPi4 booted fine from a micro SD card in my Transcend USB3 and my Hama branded USB2.0 multi-cardreaders.

I didn't have much luck with these on PCs/laptops, probably because the PC BIOS USB boot implementations didn't cope well with multi-LUN devices and the SD card with boot data being on LUN 1 instead of 0.

Transcend USB3 multi card reader:

Code: Select all

ID 8564:4000 Transcend Information, Inc. RDF8

Hama branded USB2 multi card reader

Code: Select all

ID 1307:0330 Transcend Information, Inc. 63-in-1 Multi-Card Reader/Writer

Well done, big thumbs up!

so long,

Hias

[HawaiianPi]

wait.... do I need to manually invoke update of the EEPROM or was it done automatically at update/upgrade?

You must first update the boot-loader, then boot an SD card with Raspbian Buster or Raspberry Pi OS and do the sudo apt update && sudo apt full-upgrade -y then reboot and clone that to a USB drive. After that you should be able to shutdown, pull the card and boot from USB.

Get the June 3rd beta boot-loader from: github.com/raspberrypi/rpi-eeprom/releases/tag/v2020.06.03-137ad

[LTolledo]

wait.... do I need to manually invoke update of the EEPROM or was it done automatically at update/upgrade?

You must first update the boot-loader, then boot an SD card with Raspbian Buster or Raspberry Pi OS and do the sudo apt update && sudo apt full-upgrade -y then reboot and clone that to a USB drive. After that you should be able to shutdown, pull the card and boot from USB.

Get the June 3rd beta boot-loader from: github.com/raspberrypi/rpi-eeprom/releases/tag/v2020.06.03-137ad

thanks for the tip...

as its still in "3rd beta" I guess its still not ready for "prime-time".....
I'll try it again when its already done automatically at update/upgrade, or unless there is a final official manual procedure leading to "prime-time integration"....

[coltrane]

After having trouble cloning my SD card into the USB hard drive, I decided for a fresh OS install in the external drive with success.

This is my setup now:
Seagate Momentus Thin 2.5'' 500Gb HDD assisted by a
Nedis Sata III/USB 3.1 HDD enclosure (with a JMicron Corp. JMS567 6Gb/s controler, tho the disk is only 3 Gb/s)
(4B+ 4Gb no overclock)

Boot time on USB: 31 seconds
Boot time with Kingston 128Gb select canvas plus sdxc: 46 seconds
I only did it out of curiosity before I buy an SSD external, but turns out I gained some boot time, even with a 6 year old HDD...

[Desnee]

Any ETA for the official stable release of USB-boot firmware for Raspberry Pi 4 B?

Are we talking about this summer? This year? Next year?

[JumpmasterRT]

I see some others have had my same experience...

Fresh RasPiOS (5/27) install to SD. Update/upgrade. Copy to SSD. Remove SD. Boot. Make this post.

That's all I did.

[Gavinmc42]

Fresh RasPiOS (5/27) install to SD. Update/upgrade. Copy to SSD. Remove SD. Boot. Make this post.

Yep, similar to what I did.
Obviously it is working as I typing this on it now.

Still got some OpenGL graphics No big deal problems in Warzone2100, which is fine on Gentoo64.
Probably Mesa3D related?
No big deal and not related to EEPROM.

[HawaiianPi]

I see some others have had my same experience...

Fresh RasPiOS (5/27) install to SD. Update/upgrade. Copy to SSD. Remove SD. Boot. Make this post.

That's all I did.

That couldn't have been all you did, because the boot-loader needs to be updated, and that's not done through apt (yet).

[coltrane]

I see some others have had my same experience...

Fresh RasPiOS (5/27) install to SD. Update/upgrade. Copy to SSD. Remove SD. Boot. Make this post.

That's all I did.

That couldn't have been all you did, because the boot-loader needs to be updated, and that's not done through apt (yet).

I followed this tutorial
https://tynick.com/blog/05-22-2020/rasp ... -from-usb/
on the eeprom and bootloader parts, then I found out there's a newer bootloader from June 3 and I messed the part of copying the *.elf and *.dat files (copied them to /root/boot instead of /boot). I decided to do two fresh RaspiOS installs both on the SD and on the drive (the EEPROM part seemed to be solved, but I did the tutorial again on the update, upgrade and bootloader parts with the June 3 file, and this time I copied the elf dat files to the correct /boot location on the drive) and everything went well. Also I used Raspberry Pi Imager, not NOOBS.

[LTolledo]

I see some others have had my same experience...

Fresh RasPiOS (5/27) install to SD. Update/upgrade. Copy to SSD. Remove SD. Boot. Make this post.

That's all I did.

After doing this several times on RPi4B-4G, I can safely say, with great confidence and absolute certainty, that the statement above is

false and misleading.

and back HawaiianPi's statement on the matter (that its not done via apt yet)

[Kendek]

Any ETA for the official stable release of USB-boot firmware for Raspberry Pi 4 B?

Are we talking about this summer? This year? Next year?

Yeah, if you check the latest topic. The current version 2020-06-03 is a potential candidate for promotion to 'stable' and eventually 'production/critical'.

[Desnee]

Any ETA for the official stable release of USB-boot firmware for Raspberry Pi 4 B?

Are we talking about this summer? This year? Next year?

Yeah, if you check the latest topic. The current version 2020-06-03 is a potential candidate for promotion to 'stable' and eventually 'production/critical'.

Thanks. So which one of those (stable & production/critical) is the one that adds the USB-booting feature to the official downloadable Raspberry Pi OS image?

[Kendek]

... The current version 2020-06-03 is a potential candidate for promotion to 'stable' and eventually 'production/critical'.

Thanks. So which one of those (stable & production/critical) is the one that adds the USB-booting feature to the official downloadable Raspberry Pi OS image?

This is the bootloader EEPROM image, you will need to flash it before you can boot the OS from USB. I think there will be a new Raspberry Pi OS release (with compatible firmwares) when or after the USB-MSD boot becomes stable.

[Desnee]

... The current version 2020-06-03 is a potential candidate for promotion to 'stable' and eventually 'production/critical'.

Thanks. So which one of those (stable & production/critical) is the one that adds the USB-booting feature to the official downloadable Raspberry Pi OS image?

This is the bootloader EEPROM image, you will need to flash it before you can boot the OS from USB. I think there will be a new Raspberry Pi OS release (with compatible firmwares) when or after the USB-MSD boot becomes stable.

Okay so if I were to flash my RPI 4B right now with the beta firmware, install whatever OS to a USB mass storage device, boot it and start working on it, then I could expect it to work with future firmware updates as well? I want to make sure I don't have to flash my RPI again after the stable release comes out. Can I update the beta firmware to the stable firmware once the latter comes out?

[Kendek]

Okay so if I were to flash my RPI 4B right now with the beta firmware, install whatever OS to a USB mass storage device, boot it and start working on it, then I could expect it to work with future firmware updates as well? I want to make sure I don't have to flash my RPI again after the stable release comes out. Can I update the beta firmware to the stable firmware once the latter comes out?

This USB-MSD boot test requires two things; flash the beta bootloader EEPROM image (pieeprom.bin) and if necessary, update the start4*.elf and fixup4*.dat files on the FAT32 (/boot directory) partition (apt update ; apt full-upgrade). That's all, the related future updates will be compatible.
If you are unsure, just wait for the stable release. The beta test is for advanced users only, so there is no guarantee or assistance if things go wrong.