Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

[W. H. Heydt]

don't work for me.
have fresh buster on both of sd and ssd, followed all steps from https://www.raspberrypi.org/documentati ... _config.md, unmasked eeprom, then updated it:

Code: Select all

   cp  /lib/firmware/raspberrypi/bootloader/beta/pieeprom-2020-05-15.bin pieeprom.bin
   rpi-eeprom-config pieeprom.bin > bootconf.txt
   rpi-eeprom-config --out pieeprom-new.bin --config bootconf.txt pieeprom.bin
   sudo rpi-eeprom-update -d -f ./pieeprom-new.bin
   reboot

but after reboot seems that version of eeprom still old.

Code: Select all

vcgencmd bootloader_version
Apr 16 2020 18:11:26
version a5e1b95f320810c69441557c5f5f0a7f2460dfb8 (release)
timestamp 1587057086

would someone be so kind to help me?

Did you change the value in /etc/default/rpi-eeprom-update from "critical" to "beta"? Followed by a reboot and then the other steps.

[W. H. Heydt]

Use the following in /boot/config.txt:

Code: Select all

dtparam=sd_poll_once

That works. The dtoverlay version still works on my Pi3B+ even under the current production Buster, though.

[RonR]

Use the following in /boot/config.txt:

Code: Select all

dtparam=sd_poll_once

That works. The dtoverlay version still works on my Pi3B+ even under the current production Buster, though.

Neither sdtweak nor sdio overlays work on the Raspberry Pi 4. I don't know if that's intentional or a bug.

dtparam=sd_poll_once also works on the Raspberry Pi 3.

[HawaiianPi]

That works. The dtoverlay version still works on my Pi3B+ even under the current production Buster, though.

Neither sdtweak nor sdio overlays work on the Raspberry Pi 4. I don't know if that's intentional or a bug.

dtparam=sd_poll_once also works on the Raspberry Pi 3.

Don't know if "intentional" is the correct term, but sdtweak,poll_once was for the bcm2835-sdhost used in most older Pi models.

https://github.com/raspberrypi/linux/issues/3286

So it's not really intentional or a bug. Perhaps outdated is a better term, since it still works on older models, but something new was needed for the Pi4.

[busywait]

I use a ASMedia USB3 to SATA adapter:
ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

I have the same controller, startech branded no luck for my SSD

I get the same IDs if I run lsusb. One of my cables is StarTech, the other is ELUTENG. Both from Amazon, the ELUTENG was half the price.

There is a firmware update for that cable on the StarTech website. It's to enable the TRIM command I think, but maybe it will help here? The updater ran cleanly enough on my Windows machine, but not clear if it actually did anything. I've not tried boot from USB yet (and, I only tried the updater on the StartTech cable).

[W. H. Heydt]

This is a report of the first phase of a two phase update. This part is--essentially--a regression test.

Current system: Pi3B+ booting from a WD 314GB PiDrive HDD. System boots just fine after running rpi-update.

The next phase will be to prepare a Pi4B2 to replace the Pi3B+ and swapping that to the PiDrive.

[hippy]

Pi 4B 1GB, with Raspbian Buster plus desktop, just idling, my green activity LED is hyper active when booted and running from my SD Card in an SD Card reader. The LED flickers but is mostly on, sometimes 'half brightness', on and off too rapid to discern I guess, and sometimes 'stuck on' for a second or two.

Use the following in /boot/config.txt:

Code: Select all

dtparam=sd_poll_once

Thanks. That stopped the flickering and staying on. Unfortunately entirely, so it seemed after an admittedly brief test, so there's no indication of disk access activity at all. Would be nice to have something which restores 'boot from SD socket' behaviour.

[RonR]

Use the following in /boot/config.txt:

Code: Select all

dtparam=sd_poll_once

Thanks. That stopped the flickering and staying on. Unfortunately entirely, so it seemed after an admittedly brief test, so there's no indication of disk access activity at all. Would be nice to have something which restores 'boot from SD socket' behaviour.

It's the same as the Raspberry Pi 3. The green LED must be hard-wired to something related to the SD card and not programmable.

[W. H. Heydt]

Phase two is done. With a little of the usual persuasion, the Pi4B2 has an updated bootloader with the correct boot sequence and it now boots properly from the WD PiDrive with SD card.

Code: Select all

pi@pidrive:~ $ lsusb
Bus 002 Device 002: ID 1058:07ba Western Digital Technologies, Inc. PiDrive (WDLB)
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0557:2213 ATEN International Co., Ltd CS682 2-Port USB 2.     0 DVI KVM Switch
Bus 001 Device 003: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Code: Select all

pi@pidrive:~ $ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 292.5G  0 disk
├─sda1   8:1    0   255M  0 part /boot
└─sda2   8:2    0 292.2G  0 part /

[ehem]

GPT is supported for USB mass storage boot only. SD card GPT will come later because that's different legacy file system code to untangle in start.elf (future rpi-update).

No official support for hybrid MBR but you might get away with it so long as the VC boot partition is always first plausible EFI / FAT candidate

Did I just read that a rather critical portion of USB booting for the Raspberry PI 4 is undocumented? Yes, this is really rather important.

What order does this alpha bootloader try the schemes in? (GPT then MBR, MBR then GPT)

How does it find the boot filesystem in a GPT? An EFI BIOS will look for boot parameters in an entry with a particular type-UUID. I'm pretty sure the Raspberry PI 4 should be looking for an entry with a different type-UUID. Does the Raspberry PI 4 instead simply try to read the first GPT entry as a vfat filesystem?

I can see many corner cases where Hybrid MBR could fail in the ROM upwards ... see this article for some others

https://www.rodsbooks.com/gdisk/hybrid.html

The main one is whether a given OS tries the GPT first versus the MBR first. Most with proper GPT support will honor the GPT over the MBR since it is much harder to accidentally produce a valid GPT than it is to accidentally produce a valid MBR.

For the Raspberry PI 4, the above is a major concern. Knowing previous limitations of the Raspberry PI bootloader code I setup a SSD with a hybrid MBR where the first entry is where the Raspberry PI should look for boot information. With no expectation of the Raspberry PI 4 bootloader to supporting GPT and it being handier for the OS, it is not the first GPT entry. Looking for a specific type-UUID would be my expectation.


If one wants to share the area with the Tianocore EFI project, you could have two GPT entries covering the same area of the storage medium (while the type-UUIDs differ, the start and end values match, hence they find the same data).

[sirvapesalot]

Not sure what I did, but would appreciate help . It now boots to the SSD through USB 3.0 port, but not fully I get the following message:

Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

This is through a new ssd with retropie on it.

[HawaiianPi]

I use a ASMedia USB3 to SATA adapter:
ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

I have the same controller, startech branded no luck for my SSD

I get the same IDs if I run lsusb. One of my cables is StarTech, the other is ELUTENG. Both from Amazon, the ELUTENG was half the price.

There is a firmware update for that cable on the StarTech website. It's to enable the TRIM command I think, but maybe it will help here? The updater ran cleanly enough on my Windows machine, but not clear if it actually did anything. I've not tried boot from USB yet (and, I only tried the updater on the StartTech cable).

All of my ASMedia based adapters with that ID have worked for me. However, ASMedia is notorious for using the same ID on multiple chipsets, so it may matter which specific chip your adapter is running. I believe mine are all the ASM1153E chip, but I can't be 100% sure on some of them (molded plugs that I couldn't take apart to look). All the ASMedia based adapters worked fine for USB booting with the Pi4 beta firmware, but some did require a firmware update to support TRIM.

I've had failed boots on JMicron and VIA based adapters, but my JMicron JMS561U based Sabrent cable at least would mount a drive on an already booted system (the JMS567 adapter cable would not even do that on the USB 3.0 ports).

So far the only non-ASMedia adapter that worked for me had a Norelsys 1068X chip, and it was an Orico enclosure purchased from Amazon.

Output of lsusb -vvvs in text files.

lsusb.zip

(5 KiB) Downloaded 15 times

EDIT
Just dug another JMicron adapter out of the junk box, and it also failed to boot or even mount a drive on USB 3.0.
It also had an 0x0578 ID but lsusb said it was both a JMS 567 and 579 in different places.

lsusb_JMicron_567or579.zip

(1.31 KiB) Downloaded 18 times

[BRX7]

I guess the power output of the Usb3 ports in bootloader is too low to allow some adaptors /drives to run.

[HawaiianPi]

I guess the power output of the Usb3 ports in bootloader is too low to allow some adaptors /drives to run.

Doubt it's a power issue, at least with the Pi4's USB 3.0 port, because I used the same SSDs for the tests. Its possible the adapters themselves have thin wires and don't transfer enough power, but that's doubtful as well because they all work on my Win10 laptop. ¯\_(ツ)_/¯

Oh, and the Sabrent adapter cable that doesn't boot on the Pi4 does boot on a Pi3. So do some of the JMicron adapters. I imagine some might work on USB 2.0 on the Pi4, but I didn't test that because I didn't see the point (who would want to use an SSD on USB 2.0 with a Pi4).

I know the JMicron based adapters were already known to be problematic on the Pi4. They need quirks, so I'll have to give that a try when I get the time. And yes, I know that quirks don't affect the low level boot stage because that's USB Mass Storage, but once the Linux kernel gets control it does matter (the reason some work on USB 2.0 and not 3.0 is likely because of UASP).


EDIT
To be clear, all of these adapters started to boot (I'm using a UART to monitor), but the JMicron adapters failed to complete the boot process. I'm still testing adapters, but I'll try to capture some terminal output of boot fails later.

[BRX7]

Im using this
https://www.startech.com/HDD/Adapters/u ... n-overview
With a 128gb ssd, no quirks as it works fine. 1.1 rpi4 4gb. Tried on a 1.2 with no joy also.

[unreal4u]

Hi!

Using a UGREEN 3.0 case based on a ASM235CM chipset and happy to report that it is working fine, thank you very much for this!!

I have a question though... can I revert back the change I had to do in /etc/default/rpi-eeprom-update from beta back to critical once everything is working or do I have to maintain this until USB booting gets in critical?

Thank you!

[HawaiianPi]

Thanks. That stopped the flickering and staying on. Unfortunately entirely, so it seemed after an admittedly brief test, so there's no indication of disk access activity at all. Would be nice to have something which restores 'boot from SD socket' behaviour.

The ACT LED is for SD card activity. As far as I recall it never indicated USB activity.

It also signals the end of shutdown (even after enabling dtparam=sd_poll_once).

[ehem]

Come to think of it, another issue of USB boot behavior comes to mind: What order do USB devices get probed in?

This is an issue if I've got two USB storage capable devices plugged in. Will a dumb USB2 key with MBR and FAT-only end up taking precedence over a USB3 which has a GPT and all the data the RP4 needs to boot?

[HawaiianPi]

Will a dumb USB2 key with MBR and FAT-only end up taking precedence over a USB3 which has a GPT and all the data the RP4 needs to boot?

Depends on what's bootable.

USB devices are enumerated in the order they are seen by the OS. If both are bootable, then the one that is ready first will boot, and that may not be the same device every boot. If one is just for data storage and another is bootable, then it shouldn't be a problem (system will boot).

It *could* be a problem if the drives were not prepared properly. For example, if you have root=/dev/sda2 in /boot/cmdline.txt then you will have trouble, since there is no guarantee the same device will always be /dev/sda. For that reason you'll want to use UUID or PARTUUID, which should be unique to each drive (which is also why you should always check the New Partition UUIDs box when cloning drives with SD Card Copier).

So instead of "root=/dev/sda2" you could use "root=PARTUUID=a1b2c3de-02" with your own PARTUUID of course. Do the same with mount points in /etc/fstab (for the same reason).

In general you don't want more than one bootable device on the system when you cold boot or reboot (unless you have some kind of boot manager as well).

[ehem]

Will a dumb USB2 key with MBR and FAT-only end up taking precedence over a USB3 which has a GPT and all the data the RP4 needs to boot?

Depends on what's bootable.

USB devices are enumerated in the order they are seen by the OS. If both are bootable, then the one that is ready first will boot, and that may not be the same device every boot. If one is just for data storage and another is bootable, then it shouldn't be a problem (system will boot).

It *could* be a problem if the drives were not prepared properly. For example, if you have root=/dev/sda2 in /boot/cmdline.txt then you will have trouble, since there is no guarantee the same device will always be /dev/sda. For that reason you'll want to use UUID or PARTUUID, which should be unique to each drive (which is also why you should always check the New Partition UUIDs box when cloning drives with SD Card Copier).

No, the situation is rather worse than this. If I have two USB-storage devices plugged in, one which has all the files the Raspberry PI 4 requires and one without; which will the Raspberry PI 4 try to boot from?

Depending upon the mechanism for finding bootable media, a random USB-key could cause the RP4 bootloader to attempt to boot from it, yet the boot fail. If it fails in a halt state this could be troublesome. If the bootloader resets the Via chip, waits for 100 microseconds and then tries devices in the order the Via chip reports them in that gets one result. If the bootloader tries them in reverse order, the result is different.

This does partially end up being a question of the behavior of the Via chip. Yet there is a bigger issue of how smart is the bootloader about looking for bootable media?

[HawaiianPi]

No, the situation is rather worse than this. If I have two USB-storage devices plugged in, one which has all the files the Raspberry PI 4 requires and one without; which will the Raspberry PI 4 try to boot from?

It will boot from the drive with the bootable OS on it. Not sure why you think this is a problem (it isn't).

I almost always have more that one drive on my computers, including the USB booted Pi 4B2 I'm replying from now. The Pi won't try to boot from a drive that is not bootable (a data drive). You can have multiple drives on the system and it will find the one with bootable OS.

As I said above, it's only a problem when there is more than one boot drive attached.

EDIT: fixed a typo.

[W. H. Heydt]

Will a dumb USB2 key with MBR and FAT-only end up taking precedence over a USB3 which has a GPT and all the data the RP4 needs to boot?

Depends on what's bootable.

USB devices are enumerated in the order they are seen by the OS. If both are bootable, then the one that is ready first will boot, and that may not be the same device every boot. If one is just for data storage and another is bootable, then it shouldn't be a problem (system will boot).

It *could* be a problem if the drives were not prepared properly. For example, if you have root=/dev/sda2 in /boot/cmdline.txt then you will have trouble, since there is no guarantee the same device will always be /dev/sda. For that reason you'll want to use UUID or PARTUUID, which should be unique to each drive (which is also why you should always check the New Partition UUIDs box when cloning drives with SD Card Copier).

No, the situation is rather worse than this. If I have two USB-storage devices plugged in, one which has all the files the Raspberry PI 4 requires and one without; which will the Raspberry PI 4 try to boot from?

Depending upon the mechanism for finding bootable media, a random USB-key could cause the RP4 bootloader to attempt to boot from it, yet the boot fail. If it fails in a halt state this could be troublesome. If the bootloader resets the Via chip, waits for 100 microseconds and then tries devices in the order the Via chip reports them in that gets one result. If the bootloader tries them in reverse order, the result is different.

This does partially end up being a question of the behavior of the Via chip. Yet there is a bigger issue of how smart is the bootloader about looking for bootable media?

The boot code has to find a FAT partition that contains the file(s) it's looking for. It will keep looking until it finds one. Note that the search order among device types is (a) documented, and (b) settable. Right now there is a choice among SD card, network, and USB devices.

If you are planning to use USB booting, the simplest thing to do is make sure that you have only one bootable USB device attached when the system boots.

As for anything else you think should be documented and is...this *is* a beta test of the feature.

[RonR]

What order do USB devices get probed in?

I haven't seen any mention of a mechanism to select which device boots when multiple candidates are present. The Raspberry Pi 4 bootloader appears to be modeled after the Raspberry Pi 3 which uses a first come first served basis. For me, this isn't acceptable as I typically have several bootable devices online at same time and use a script (sdc-boot) to set cmdline.txt on the SD card to establish and change the current 'system' device. I was hoping the new Raspberry Pi 4 bootloader would have an equivalent user settable area to control which device would be booted.

Fortunately, the new bootloader doesn't preclude my continuing to use the tried and proven method I've become accustomed to. Having an SD card present simply to facilitate boot selection isn't the huge problem that some people view it as. The old methodology and the new bootloader actually coexist quite well.

[ehem]

It will boot from the drive with the bootable OS on it. Not sure why you think this is a problem (it isn't).

I almost always have more that one drive on my computers, including the USB booted Pi 4B2 I'm replying from now. The Pi won't try to boot from a drive that is not bootable (a data drive). You can have multiple drives on the system and it will find the one with bootable OS.

Give me a technical definition of bootable.

For a traditional PC BIOS the definition is simple, the last two bytes of the first sector ends are 0xAA then 0x55. This is the same for floppy disks and hard disks. Early motherboards would only boot from the first floppy or first hard disk. Post-1995 machines started adding the ability to boot from second hard disk or CD-ROM, but the original was strictly the first floppy or hard disk.

For the Raspberry PI 4, until timg236 mentioned it above I had thought the definition was the first sector was a MBR and the first entry had a type byte indicating FAT16. Yet now apparently some GPTs are valid.

Will the RP4 only boot from the very first GPT entry? Does it look at the type UUID? Does it look at the id UUID? Is the presence/absence of "start.elf" what determines whether something is bootable?
Is the presence of the file "start.elf" the key definition? If multiple things which appear valid FAT filesystems are found, does it only examine the first one?

I would like it to prefer GPTs over MBRs. Ideally I would prefer it to search all devices for GPTs and prefer: An entry whose Id UUID matches the ethernet MAC address of the Pi, then an entry whose type-UUID is one allocated for the RPF.

What I mean by Id UUID matches the ethernet MAC address is this: Try installing the "uuid-runtime" package. Now run `uuidgen -t`, given the UUID generated try `uuid -d <UUID>`. Notice that it gives you back the MAC address, if this matches the device this is a strong hint you've got the right entry (could also use 802.11 MAC, but I think ethernet MACs are preferred).

Potentially this allows you to have a USB keyfob which boots differently for several PIs. This is also a failsafe to ensure it chooses the right device to boot from.

The boot code has to find a FAT partition that contains the file(s) it's looking for. It will keep looking until it finds one. Note that the search order among device types is (a) documented, and (b) settable. Right now there is a choice among SD card, network, and USB devices.

If you are planning to use USB booting, the simplest thing to do is make sure that you have only one bootable USB device attached when the system boots.

As for anything else you think should be documented and is...this *is* a beta test of the feature.

That only allows effecting the device type to prefer, not the exact device if multiple are present. Only one bootable USB device is good, but may not be possible. If there are multiple, what are the rules for which one is preferred? USB3 ports over USB2 ports? Upper USB ports? Lower USB ports?

(guess I'm playing the role of figuring out ways I could I cause things to fail)

[W. H. Heydt]

Im using this
https://www.startech.com/HDD/Adapters/u ... n-overview
With a 128gb ssd, no quirks as it works fine. 1.1 rpi4 4gb. Tried on a 1.2 with no joy also.

Both of mine are v1.2. One is a 4GB board and the other is a 2GB board. Once initial teething problems were solved, both are working fine.