User avatar
JumpmasterRT
Posts: 19
Joined: Thu Dec 05, 2019 4:57 pm
Location: Georgia, United States

Re: USB-MSD boot EEPROM update - 2020-05-28

Sun Jun 07, 2020 1:32 pm

LTolledo wrote:
Sun Jun 07, 2020 4:41 am
JumpmasterRT wrote:
Sat Jun 06, 2020 10:55 pm
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)

Image


*** 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.
4gb Raspberry Pi 4 | Kernel = 4.19.93-v7l+ | Raspbian Buster with PIXEL on a 32gb SD card | Logitech Wireless M/K = MK-320

timg236
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 741
Joined: Thu Jun 21, 2018 4:30 pm

Re: USB-MSD boot EEPROM update - 2020-05-28

Sun Jun 07, 2020 2:17 pm

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.

User avatar
JumpmasterRT
Posts: 19
Joined: Thu Dec 05, 2019 4:57 pm
Location: Georgia, United States

Re: USB-MSD boot EEPROM update - 2020-05-28

Sun Jun 07, 2020 2:27 pm

timg236 wrote:
Sun Jun 07, 2020 2:17 pm
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.
4gb Raspberry Pi 4 | Kernel = 4.19.93-v7l+ | Raspbian Buster with PIXEL on a 32gb SD card | Logitech Wireless M/K = MK-320

timg236
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 741
Joined: Thu Jun 21, 2018 4:30 pm

Re: USB-MSD boot EEPROM update - 2020-05-28

Sun Jun 07, 2020 2:32 pm

JumpmasterRT wrote:
Sun Jun 07, 2020 2:27 pm
timg236 wrote:
Sun Jun 07, 2020 2:17 pm
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.

User avatar
JumpmasterRT
Posts: 19
Joined: Thu Dec 05, 2019 4:57 pm
Location: Georgia, United States

Re: USB-MSD boot EEPROM update - 2020-05-28

Sun Jun 07, 2020 2:40 pm

timg236 wrote:
Sun Jun 07, 2020 2:32 pm
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)
4gb Raspberry Pi 4 | Kernel = 4.19.93-v7l+ | Raspbian Buster with PIXEL on a 32gb SD card | Logitech Wireless M/K = MK-320

User avatar
HawaiianPi
Posts: 6126
Joined: Mon Apr 08, 2013 4:53 am
Location: Aloha, Oregon USA

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 5:31 am

JumpmasterRT wrote:
Sun Jun 07, 2020 2:27 pm
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)?

JumpmasterRT wrote:
Sun Jun 07, 2020 2:27 pm
(slow as molasses in January but it does boot)
What does lsusb return when your SSD is connected?
My mind is like a browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?

LTolledo
Posts: 4476
Joined: Sat Mar 17, 2018 7:29 am
Location: Anime Heartland

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 9:35 am

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
RPi4B-4G EEPROM status.jpg (55.42 KiB) Viewed 2067 times
"Don't come to me with 'issues' for I don't know how to deal with those
Come to me with 'problems' and I'll help you find solutions"

Some people be like:
"Help me! Am drowning! But dont you dare touch me nor come near me!"

tofflock
Posts: 14
Joined: Mon Mar 05, 2012 11:53 am

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 10:39 am

JumpmasterRT wrote:
Sun Jun 07, 2020 1:32 pm
What's this then? (In case screenshot doesn't show click here https://drive.google.com/file/d/11vTNxj ... sp=sharing)
Image
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

User avatar
JumpmasterRT
Posts: 19
Joined: Thu Dec 05, 2019 4:57 pm
Location: Georgia, United States

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 11:17 am

HawaiianPi wrote:
Mon Jun 08, 2020 5:31 am
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.
tofflock wrote:
Mon Jun 08, 2020 10:39 am
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.
4gb Raspberry Pi 4 | Kernel = 4.19.93-v7l+ | Raspbian Buster with PIXEL on a 32gb SD card | Logitech Wireless M/K = MK-320

User avatar
JumpmasterRT
Posts: 19
Joined: Thu Dec 05, 2019 4:57 pm
Location: Georgia, United States

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 12:16 pm

HawaiianPi wrote:
Mon Jun 08, 2020 5:31 am
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
4gb Raspberry Pi 4 | Kernel = 4.19.93-v7l+ | Raspbian Buster with PIXEL on a 32gb SD card | Logitech Wireless M/K = MK-320

Herbaldew
Posts: 68
Joined: Wed Feb 07, 2018 2:59 pm
Location: US Mid-Atlantic

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 1:23 pm

JumpmasterRT wrote:
Mon Jun 08, 2020 11:17 am
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.

User avatar
HawaiianPi
Posts: 6126
Joined: Mon Apr 08, 2013 4:53 am
Location: Aloha, Oregon USA

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 3:40 pm

JumpmasterRT wrote:
Mon Jun 08, 2020 12:16 pm
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?

JumpmasterRT wrote:
Mon Jun 08, 2020 11:17 am
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.
My mind is like a browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?

User avatar
PeterO
Posts: 6046
Joined: Sun Jul 22, 2012 4:14 pm

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 3:47 pm

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
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
JumpmasterRT
Posts: 19
Joined: Thu Dec 05, 2019 4:57 pm
Location: Georgia, United States

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 4:11 pm

Herbaldew wrote:
Mon Jun 08, 2020 1:23 pm
JumpmasterRT wrote:
Mon Jun 08, 2020 11:17 am
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.
Herbaldew wrote:
Mon Jun 08, 2020 1:23 pm
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?)

Herbaldew wrote:
Mon Jun 08, 2020 1:23 pm
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.
4gb Raspberry Pi 4 | Kernel = 4.19.93-v7l+ | Raspbian Buster with PIXEL on a 32gb SD card | Logitech Wireless M/K = MK-320

User avatar
JumpmasterRT
Posts: 19
Joined: Thu Dec 05, 2019 4:57 pm
Location: Georgia, United States

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 4:26 pm

HawaiianPi wrote:
Mon Jun 08, 2020 3:40 pm
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
HawaiianPi wrote:
Mon Jun 08, 2020 3:40 pm
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.
HawaiianPi wrote:
Mon Jun 08, 2020 3:40 pm
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
4gb Raspberry Pi 4 | Kernel = 4.19.93-v7l+ | Raspbian Buster with PIXEL on a 32gb SD card | Logitech Wireless M/K = MK-320

User avatar
JumpmasterRT
Posts: 19
Joined: Thu Dec 05, 2019 4:57 pm
Location: Georgia, United States

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 5:45 pm

HawaiianPi wrote:
Mon Jun 08, 2020 3:40 pm
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. :D

(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)
4gb Raspberry Pi 4 | Kernel = 4.19.93-v7l+ | Raspbian Buster with PIXEL on a 32gb SD card | Logitech Wireless M/K = MK-320

User avatar
HawaiianPi
Posts: 6126
Joined: Mon Apr 08, 2013 4:53 am
Location: Aloha, Oregon USA

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 10:20 pm

JumpmasterRT wrote:
Mon Jun 08, 2020 5:45 pm
Thank you! That worked like a CHARM. :D

(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).
My mind is like a browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?

trejan
Posts: 3062
Joined: Tue Jul 02, 2019 2:28 pm

Re: USB-MSD boot EEPROM update - 2020-05-28

Mon Jun 08, 2020 10:44 pm

HawaiianPi wrote:
Mon Jun 08, 2020 10:20 pm
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.

User avatar
HawaiianPi
Posts: 6126
Joined: Mon Apr 08, 2013 4:53 am
Location: Aloha, Oregon USA

Re: USB-MSD boot EEPROM update - 2020-05-28

Tue Jun 09, 2020 1:59 am

trejan wrote:
Mon Jun 08, 2020 10:44 pm
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.

:roll:
My mind is like a browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?

mmoseeker
Posts: 9
Joined: Mon Jun 08, 2020 9:27 am

Re: USB-MSD boot EEPROM update - 2020-05-28

Tue Jun 09, 2020 5:13 am

A USB device is booted properly using USB-MSD boot

retrkdr
Posts: 11
Joined: Sun Dec 10, 2017 10:04 pm

Re: USB-MSD boot EEPROM update - 2020-05-28

Tue Jun 09, 2020 8:25 pm

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
Posts: 4
Joined: Wed Jun 10, 2020 4:11 pm

Re: USB-MSD boot EEPROM update - 2020-05-28

Wed Jun 10, 2020 4:41 pm

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

Image

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

W. H. Heydt
Posts: 13959
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: USB-MSD boot EEPROM update - 2020-05-28

Wed Jun 10, 2020 9:01 pm

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

andrum99
Posts: 1357
Joined: Fri Jul 20, 2012 2:41 pm

Re: USB-MSD boot EEPROM update - 2020-05-28

Wed Jun 10, 2020 9:52 pm

W. H. Heydt wrote:
Wed Jun 10, 2020 9:01 pm
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
Posts: 1894
Joined: Tue Apr 12, 2016 10:29 pm
Location: US

Re: USB-MSD boot EEPROM update - 2020-05-28

Wed Jun 10, 2020 10:20 pm

timg236 wrote:
Fri Jun 05, 2020 7:49 pm
RonR wrote:
Fri Jun 05, 2020 7:16 pm
timg236 wrote:
Fri Jun 05, 2020 6:40 pm
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.

Return to “General discussion”