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

[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.

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)

What's this then? (In case screenshot doesn't show click here https://drive.google.com/file/d/11vTNxj ... sp=sharing)




*** Edit***
It worked yet again. I captured that scrot while reinstalling just to be sure I wasn't wrong.
I'm going to make a video because it's neither false nor misleading. It just works.

[timg236]

The latest firmware is in APT so installing Raspberry Pi OS to an SD card, apt update, apt full-upgrade does work. Clearly you have to update the bootloader as well which is already covered in the instructions.

Usual beta disclaimer, if you aren't already familiar with the updating the bootloader EEPROM or firmware then wait until USB MSD boot is available in the OS image. When that happens the documentation will a simple two-step process with the Raspberry Pi Imager to update the EEPROM and flash an image to USB MSD.

No doubt some SATA adapters / drivers won't be supported in that release but there's no sense in blocking what currently works until every interop issue is solved. It already seems to support everything Pi3 did and a reasonable variety of USB 3 devices.

[JumpmasterRT]

The latest firmware is in APT so installing Raspberry Pi OS to an SD card, apt update, apt full-upgrade does work. Clearly you have to update the bootloader as well which is already covered in the instructions.

That's just it. I didn't update the bootloader manually.

The ONLY thing I've done, twice now, is:
Fresh install (5/27 release)
Update/full-upgrade
Reboot
Copy to SSD
Remove SD
Reboot from SSD
Wait 30 damn minutes for it to boot (it does get faster each time though)
Write this post.


I did NOT update the bootloader on EITHER of these.

[timg236]

The latest firmware is in APT so installing Raspberry Pi OS to an SD card, apt update, apt full-upgrade does work. Clearly you have to update the bootloader as well which is already covered in the instructions.

That's just it. I didn't update the bootloader manually.

The ONLY thing I've done, twice now, is:
Fresh install (5/27 release)
Update/full-upgrade
Reboot
Copy to SSD
Remove SD
Reboot from SSD
Wait 30 damn minutes for it to boot (it does get faster each time though)
Write this post.


I did NOT update the bootloader on EITHER of these.

Raspbian does not automatically select the beta bootloader, if you have edited /etc/default/rpi-eeprom-update and selected beta that would work.

You can test this by reverting the bootloader and repeating the steps above.

[JumpmasterRT]

Raspbian does not automatically select the beta bootloader, if you have edited /etc/default/rpi-eeprom-update and selected beta that would work.

You can test this by reverting the bootloader and repeating the steps above.

Mine says critical, not beta. still boots (slow as molasses in January but it does boot)

[HawaiianPi]

I did NOT update the bootloader on EITHER of these.

What you are claiming is impossible. You are either mistaken about your Pi4 not being updated, or you've left out some important detail (like the extra step that updated your bootloader), or you're just trolling.


Raspberry Pi 4B 4GB with non-beta firmware

First boot, Raspberry Pi OS (32-bit) before OS updates (have not completed startup script).

Code: Select all

$ sudo rpi-eeprom-update && vcgencmd bootloader_version
BCM2711 detected
BOOTLOADER: up-to-date
CURRENT: Thu 16 Apr 2020 05:11:26 PM UTC (1587057086)
 LATEST: Thu 16 Apr 2020 05:11:26 PM UTC (1587057086)
 FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad
Apr 16 2020 18:11:26
version a5e1b95f320810c69441557c5f5f0a7f2460dfb8 (release)
timestamp 1587057086

After update/full-upgrade/reboot.

Code: Select all

$ sudo rpi-eeprom-update && vcgencmd bootloader_version
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Thu 16 Apr 2020 05:11:26 PM UTC (1587057086)
 LATEST: Thu 16 Apr 2020 05:11:26 PM UTC (1587057086)
 FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad
Apr 16 2020 18:11:26
version a5e1b95f320810c69441557c5f5f0a7f2460dfb8 (release)
timestamp 1587057086

Exactly the same, and it will not boot from USB!

So what does the command sudo rpi-eeprom-update or vcgencmd bootloader_version return on your Pi4 system(s)?

(slow as molasses in January but it does boot)

What does lsusb return when your SSD is connected?

[LTolledo]

FYI this is the current status of my secondary desktop (where I tried the "experiment")

Code: Select all

pi@RPi4B-4G:~ $ sudo rpi-eeprom-update && vcgencmd bootloader_version
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Thu 16 Apr 2020 05:11:26 PM UTC (1587057086)
 LATEST: Thu 16 Apr 2020 05:11:26 PM UTC (1587057086)
 FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad
Apr 16 2020 18:11:26
version a5e1b95f320810c69441557c5f5f0a7f2460dfb8 (release)
timestamp 1587057086

it matches the one posted by HawaiianPi

and from where I based my conclusion of false and misleading

to remove the doubt that the info above is "doctored" maybe an image will be better convincing

RPi4B-4G EEPROM status.jpg (55.42 KiB) Viewed 2067 times

[tofflock]

What's this then? (In case screenshot doesn't show click here https://drive.google.com/file/d/11vTNxj ... sp=sharing)

The top line of this screen image shows

BOOT_ORDER=0xf41

It would be good to know what preceded this as this BOOT_ORDER configuration is that from a modified boot eeprom. New Pi4s are not shipped with a boot eeprom which contains this configuration AFAIUI.

PeterF

[JumpmasterRT]

What you are claiming is impossible. You are either mistaken about your Pi4 not being updated, or you've left out some important detail (like the extra step that updated your bootloader), or you're just trolling.

Does any of this persist from one installation to another? Meaning, if I followed the bootloader update instructions a week ago, would they still be on the Pi or would that have reverted back with every new OS installation afterward? Unless that's possible, I'm not mistaken, not left anything out and I'm not trolling. That's why I said I was going to make a video so I could show exactly what I did.

New Pi4s are not shipped with a boot eeprom which contains this configuration AFAIUI.
PeterF

Same question to you sir. If I had messed with all of this a week ago, would those changes still persist with each subsequent OS installation?


Actually, here's another thing.
Yesterday when I saw the replies that this was impossible, I went back to do it again so I could see if I had made a mistake. I took a second to see if I could just flash the SSD with the 5/27 release, plug it in and work. It did not and I got the boot loop error like others have. Then, after ONLY doing the apt update, apt full-upgrade did it work. I didn't mess with the eeprom nor the bootloader on this series of installs.

[JumpmasterRT]

What does lsusb return when your SSD is connected?

The SSD is connected via a powered USB 3 drive dock.

Code: Select all

pi@raspberrypi:~ $ lsusb
Bus 002 Device 003: ID 0578:0578 Intrinsix Corp. 
Bus 002 Device 002: ID 2109:0817 VIA Labs, Inc. 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 003: ID 2109:2817 VIA Labs, Inc. 
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[Herbaldew]

Does any of this persist from one installation to another? Meaning, if I followed the bootloader update instructions a week ago, would they still be on the Pi or would that have reverted back with every new OS installation afterward?

Yes it does. I started to ask if you knew this yesterday morning.

The bootloader is on the pi hardware not on the SD card or USB drive. So once you have changed the bootloader it stays that way unless you manually revert or a newer boot loader comes along. What you see on your screenshot being downloaded is the 2020-04-16 version - it is just making sure yours is at least that new.

Run

Code: Select all

vcgencmd bootloader_version

to see what is currently on your pi.

As far as taking 30 minutes to boot, no clue there - mine boot in ~30 seconds.

[HawaiianPi]

The SSD is connected via a powered USB 3 drive dock.

Code: Select all

pi@raspberrypi:~ $ lsusb
Bus 002 Device 003: ID 0578:0578 Intrinsix Corp. 
Bus 002 Device 002: ID 2109:0817 VIA Labs, Inc. 
Bus 001 Device 003: ID 2109:2817 VIA Labs, Inc.

I see a JMicron controller (0578:0578), and an additional VIA USB 2.0 hub (2109:2817).

Some JMicron controllers are known to be troublesome and require disabling UAS to operate at high speed. Try adding usb-storage.quirks=0578:0578:u to the beginning of the line in /boot/cmdline.txt (usb-storage.quirks=0578:0578:u console=tty1...)

Not sure about that second VIA device (2109:0817). Is that another hub?

Does any of this persist from one installation to another?

Unlike previous models, the Pi4 has on-board EEPROM storage for upgradeable firmware. So yes, it does persist. Once upgraded it will remain until replaced by something newer, or reset by using an EEPROM recovery SD card. I missed "BOOT_ORDER=0xf41" at the top of your picture, and that is definitely from an upgraded bootloader.

My upgraded system that does boot from USB shows this.

Code: Select all

$ sudo rpi-eeprom-update && vcgencmd bootloader_version && vcgencmd bootloader_config
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/critical
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
BOOT_ORDER=0xf41

Notice how the "CURRENT" version is newer than the "LATEST" version. That's what happens when you have a new OS install on an already upgraded system, because /etc/default/rpi-eeprom-update is set to FIRMWARE_RELEASE_STATUS="critical" normally, which means it will only be upgraded if a critical bug or security issue needs to be fixed. If you change that to "beta" you will get the latest beta bootloader, otherwise it will not be replaced until something newer is deemed critical (stable is another option).

So if you either changed that to beta, or used a beta recovery SD card to upgrade your bootloader, that new bootloader is installed in your Pi4's EEPROM, and it will not be replaced by a new OS install, unless something newer becomes a critical update. And since it seems you have the beta bootloader, the rest of what you said is true (sudo apt update && sudo apt full-upgrade -y will get you the required *.dat and *.elf files to USB boot, with the beta bootloader).

Mystery solved.

[PeterO]

I still can't get my head round this process, so although I've got PIOS64 on a bootable HDD I won't be doing anything more with it until the process comes out of beta and there is no manual messing about with bootloader versions needed and I'm sure it is being automatically updated.

I followed the instructions you gave the other day but I have no idea what that has actually put in the eeprom.

PeterO

[JumpmasterRT]

Does any of this persist from one installation to another? Meaning, if I followed the bootloader update instructions a week ago, would they still be on the Pi or would that have reverted back with every new OS installation afterward?

Yes it does. I started to ask if you knew this yesterday morning.

I did not. This all makes MUCH more sense now.

Run vcgencmd bootloader_version to see what is currently on your pi.

Code: Select all

pi@raspberrypi:~ $ sudo rpi-eeprom-update
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/critical
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad

That's where I kept getting confused. Running vcgencmd bootloader_version doesn't give you as much info as rpi-eeprom-update so I wasn't seeing the difference between current and latest. I had changed the path back to critical (shown) when it booted so slow and I kind of gave up until I saw this thread. That is why I thought it was downloading the 6/3/20 version at update/upgrade. Then this morning when people were showing their before and after updates and HawaiianPi asked me to run sudo rpi-eeprom-update OR vcgencmd bootloader_version, I ran BOTH and noticed the output difference. I went to the critical folder to take a screenshot to show everyone that the 6/3 version was indeed there. Obviously it was not and that didn't make sense since the path was correct. This caused me to go back over my notes and I saw that I had done this:

Code: Select all

sudo rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/beta/pieeprom-2020-06-03.bin

So even though I had changed rpi-eeprom-update from beta back to critical I hadn't actually reverted it... once I did, it wouldn't boot. (That raises another question, why is it that the FW DIR can say one thing but the actual file can be somewhere else?)

As far as taking 30 minutes to boot, no clue there - mine boot in ~30 seconds.

It does get faster each boot but that first one is a good 5 min. However, since I have been doing this all wrong, maybe it WILL work better once I do it correctly.


Interesting side note that I didn't pick up on until after reverting back to 4/16/20 is that you don't get the first boot setup popup in beta. I thought that was weird but chocked it up to the fact that I was working with RasPiOS and not Raspbian. Once I reverted and installed, the first boot setup popped up.

[JumpmasterRT]

I see a JMicron controller (0578:0578), and an additional VIA USB 2.0 hub (2109:2817).

Some JMicron controllers are known to be troublesome and require disabling UAS to operate at high speed. Try adding usb-storage.quirks=0578:0578:u to the beginning of the line in /boot/cmdline.txt (usb-storage.quirks=0578:0578:u console=tty1...)

Not sure about that second VIA device (2109:0817). Is that another hub?

No. I only have the Logitech dongle and the dock plugged in. Here's the output difference with the dock removed.

Code: Select all

pi@raspberrypi:~ $ lsusb
Bus 002 Device 003: ID 0578:0578 Intrinsix Corp. 
Bus 002 Device 002: ID 2109:0817 VIA Labs, Inc. 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 003: ID 2109:2817 VIA Labs, Inc. 
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Unlike previous models, the Pi4 has on-board EEPROM storage for upgradeable firmware.

That also explains so much. I didn't know that had changed.

Mystery solved.

Yes. Thank you for explaining it. In doing so, you actually answered a few questions in my last reply (and others that I didn't think to ask). LOL

[JumpmasterRT]

Some JMicron controllers are known to be troublesome and require disabling UAS to operate at high speed. Try adding usb-storage.quirks=0578:0578:u to the beginning of the line in /boot/cmdline.txt (usb-storage.quirks=0578:0578:u console=tty1...)

Thank you! That worked like a CHARM.

(If you could point me to a resource on how you figured that out, it would be most helpful) ("That" being how you knew what controller I had just from looking at the lsusb output)

[HawaiianPi]

Thank you! That worked like a CHARM.

(If you could point me to a resource on how you figured that out, it would be most helpful) ("That" being how you knew what controller I had just from looking at the lsusb output)

Those 2 hexadecimal numbers separated by a colon (0578:0578) are the vendor ID and product ID. The 0578 vendor ID is not common, and is probably used by Intrinsix for their branded products. The second 0578 is common to a popular family of JMicron controllers, most of which need quirks to operate in Linux.

The issue is with UAS, or USB-Attached-SCSI (sometimes called UASP with the word Protocol added to the end). In simple terms, it's a different way of accessing data from a storage device that is faster than "bulk" or USB Mass Storage Device protocol. For one reason or another, some controllers don't play well with Linux when using UAS, and that results in significantly slower performance, often resulting boot failure (at least yours was booting).

The fix is to disable UAS for the problematic controller, and that's what adding usb-storage.quirks to cmdline.txt does. Disabling UAS reduces performance slightly, but MSD is still much faster than borked UAS, especially at USB 3.0 speeds. For HDD this is fine, but for SSD you want UAS, because disabling UAS also disables TRIM, which is needed to maintain SSD performance.

Sometimes UAS/TRIM issues can be fixed with a firmware update to the USB-SATA adapter, but it looks like your dock is a combination device with a built-in (VIA) USB hub, so you'd need to check with whoever made the dock to see if they have any updates available.

The USB 3.0 to SATA-III adapter cable on my 4B2 has an ASMedia controller with UAS & TRIM support in Linux. Not all of them do, though. I have a few different enclosures and adapters with the same 174c:55aa ID, and some of them needed a firmware update to enable TRIM (but ASMedia firmware updates can be very hard to find).

[trejan]

Those 2 hexadecimal numbers separated by a colon (0578:0578) are the vendor ID and product ID. The 0578 vendor ID is not common, and is probably used by Intrinsix for their branded products. The second 0578 is common to a popular family of JMicron controllers, most of which need quirks to operate in Linux.

Nah. This isn't anything to do with Intrinsix. They're an ASIC design firm according to their website and doesn't sell anything to end users. The unusual VID:PID is down to somebody messing up or not caring at the factory making this device and entering 0578 into both fields when programming the bridge chip config EEPROM.

[HawaiianPi]

The unusual VID:PID is down to somebody messing up or not caring at the factory making this device and entering 0578 into both fields...

Yea, you're probably right. The correct VID:PID should have been 152d:0578 but someone got lazy. I have seen worse...

Some of the product names in firmware are pretty puzzling, like my multi-drive dock that's called "Go to final lap" or my USB DAC called "DigiHug" (awww, my DAC is hugging me ... WTF does that even mean?). I even had a device with "manufacture String" and "Product String" in those fields.

[mmoseeker]

A USB device is booted properly using USB-MSD boot

[retrkdr]

Re: USB-MSD boot EEPROM update - 2020-05-28
Report this postQuote
Sun Jun 07, 2020 7:17 am

The latest firmware is in APT so installing Raspberry Pi OS to an SD card, apt update, apt full-upgrade does work. Clearly you have to update the bootloader as well which is already covered in the instructions. "
Q1
Being new to this postseries, could you point me to the "instructions" for updating bootloader?
Q2
I am in the process of setting up my new RPi4B. I have an SSD on my Pi 3B+ (no micro SD card). If I did the full apt-get update and upgrade on my 3B+, could I just plug the SSD into my new Pi4B and boot from there?

[mcq]

Apologies if this is off topic. I'm running pieeprom-2020-06-03.bin on two different RPi 4s, one with 4Gig the other 8Gig. The 4Gig one is working perfectly, but the 8Gig one is showing badly corrupted video in Chromium. Can I revert to the non-beta firmware or reload whatever drives the video accelleration, or...?

Example of video...



(yes, I'm a noob and I should know better )

[W. H. Heydt]

Status update... Got new modules through rpi-update. Still losing the task bar for log in IDs other than 'pi'.

[andrum99]

Status update... Got new modules through rpi-update. Still losing the task bar for log in IDs other than 'pi'.

Still the wrong thread to be discussing this on. If you really want to get someone's attention, open a bug on https://github.com/RPi-Distro/repo, or start a new thread with an appropriate title.

[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.

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

ACT LED is still stuck on with no SD card present but enable_uart=1 present in config.txt with 5.4.45.+ latest bootloader.