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

[LufyCZ]

How would I go about using USB boot on the Ubuntu Server version? I copied the updated files to the system-boot partition, but have had no luck getting the Pi to boot. The distro uses uboot, could that be a problem?

I got raspbian to work fine from an SD card in a card reader.

[timg236]

How would I go about using USB boot on the Ubuntu Server version? I copied the updated files to the system-boot partition, but have had no luck getting the Pi to boot. The distro uses uboot, could that be a problem?

I got raspbian to work fine from an SD card in a card reader.

Other distros will almost certainly need updates, you'll have to check with the maintainers of those distros

[timg236]

I've managed to find a device that breaks USB boot if it is attached. I have a pair of Startech.com 3.5" HDD enclosures (S3510BMU33), which are single drive enclosures. I have a 1TB hard disk in each which currently make up a ZFS pool that I have used successfully with Raspbian, and now Ubuntu 20.04 arm64. To test USB MSD boot, I powered down that Pi, the hub, and the enclosures, then connected the hub and the two enclosures to my 'testing' Pi 4B 4GB (same as the one that boots from other USB MSD devices). I'm seeing a consistent hang in the bootloader when it gets to the 'LUN 0' stage of examining the drive. I've tried extending the device timeout from 2000 to 7000 milliseconds, but it makes no difference. The drive spins up but the bootloader gets stuck at 'LUN 0'.

The Startech enclosure has vid:pid 174c:1053 which is a generic ASM1053 id. The bridge chip says ASM1053 on it.

For some reason the bootloader is hanging when it tries to talk to this drive. I can boot from another hard disk (in the working 2.5" enclosure), but if the non-working 3.5" enclosure is connected at boot time, the bootloader always hangs. I have tried the enclosure connected to a USB 2 hub and USB 3 hub that will do USB MSD boot OK with a different drive and enclosure (2.5" Hitachi hard disk, enclosure bridge 174c:1153 which is an ASM1153E).

Screenshot with both problematic drive enclosures, and working 2.5" enclosure attached, all via hub: https://drive.google.com/file/d/1qvkYpd ... sp=sharing

Screenshot with just one problematic enclosure attached via hub: https://drive.google.com/file/d/1_lGwHV ... sp=sharing

I have jumper cables on order to hook up to another machine so I can get debug out of the serial port (I seem to have lost the ones I used back back in the day with my Pi 1s). I will look at setting up network debug output as well.

Not sure that it's actually hanging, it will probably give up on USB boot and try SD in about 20 seconds time. Most likely TEST_UNIT_READY is not responding. so that it can't progress any further.
Probably best to raise a GitHub issue with a dump of the logs containing at least the descriptors, msd, msd_verbose xhci log levels.

[thatchunkylad198966]

Sorry if this has been asked... do we need usb-storage quirks?

[jdb]

Sorry if this has been asked... do we need usb-storage quirks?

No. The bootloader uses mass-storage as the boot protocol and is completely unrelated to Linux's choice of access interface.

[geev03]

The beta firmware and bootloader for USB mass storage boot on Pi 4 are now available.

Other than a large picture of a Raspberry which is nice, that tells us absolutely nothing about your USB hardware, the bootloader version, what steps you took or in what way it di not work

That picture, I think, has all the required details showing that all the updates were carried out. I am now booting from USB.
Looks like the previous failure was few missing details (got from elsewhere) as shown below:

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

[DIE_KUH]

First I tried:

Code: Select all

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

This leads to a boot order of 0xf21, so when it fails to detect an SD card, it tries to network boot. No mass storage boot.

This, however, works:

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

Now the boot order is 0xf41 and it boots without SD card from my SSD.

I'm confused. How is this any different? It's just extracting the config and adding the exact same config to the eeprom file again.

[Marko73]

It sounds like you may have gotten the EEPROM image via a different route. Different distro?

Nope, I'm running raspbian, and I followed the instructions on the bootloader page to switch to the beta branch and update from there. As I said, the dumped config stated a boot priority of 0xF41 but this wasn't reflected on the bootloader status messages when I started the Pi. The displayed bootloader date was correct though.

It's working now anyway

[timg236]

It sounds like you may have gotten the EEPROM image via a different route. Different distro?

Nope, I'm running raspbian, and I followed the instructions on the bootloader page to switch to the beta branch and update from there. As I said, the dumped config stated a boot priority of 0xF41 but this wasn't reflected on the bootloader status messages when I started the Pi. The displayed bootloader date was correct though.

It's working now anyway

If you can reproduce it let us know with the hashes / binaries of the pieeprom.bin and pieeprom.upd. recovery.bin does a blind sector by sector write so there's nothing VideoCore side which will change your configuration.

[timg236]

It sounds like you may have gotten the EEPROM image via a different route. Different distro?

Nope, I'm running raspbian, and I followed the instructions on the bootloader page to switch to the beta branch and update from there. As I said, the dumped config stated a boot priority of 0xF41 but this wasn't reflected on the bootloader status messages when I started the Pi. The displayed bootloader date was correct though.

It's working now anyway

If you can reproduce it let us know with the hashes / binaries of the pieeprom.bin and pieeprom.upd. recovery.bin does a blind sector by sector write so there's nothing VideoCore side which will change your configuration. If BOOT_ORDER was missing then that could happen.

[thatchunkylad198966]

Sorry if this has been asked... do we need usb-storage quirks?

No. The bootloader uses mass-storage as the boot protocol and is completely unrelated to Linux's choice of access interface.

Thanks. also; can we use drives that are over 2TB?

[Herbaldew]

Any guesses what I have done wrong?

Went through the process 3 times all with same results. Once I remove the SD card and boot, I no longer have wifi and my mouse quits working.

On the bright side, I was expecting this to be much slower than hybrid SD/USB booting (My Pi 3b rebooted in 30 seconds hybrid/around 60 seconds pure USB) - Wow! Now booting hybrid around 30 seconds pure USB around 20 seconds Good job!

Edit: For clarification, the 30 second boot was timed until wifi connected - once I figured out my problem and got wifi/kb working, it was actually 30 seconds as well not the 20 seconds I mentioned above. Not complaining, still much better than twice as long like my Pi 3b was I didn't figure out how to remove the SD from the boot order, so possible some boot time to be saved there.

[DirkS]

Working without problems using cheap SSD on USB3 controller

Code: Select all

Bus 002 Device 002: 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

https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1
https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1

[timg236]

Any guesses what I have done wrong?

Went through the process 3 times all with same results. Once I remove the SD card and boot, I no longer have wifi and my mouse quits working.

On the bright side, I was expecting this to be much slower than hybrid SD/USB booting (My Pi 3b rebooted in 30 seconds hybrid/around 60 seconds pure USB) - Wow! Now booting hybrid around 30 seconds pure USB around 20 seconds Good job!

Glad it's booting. It might be worth trying a powered USB hub.

The PCI controller is reset before starting Linux which also asserts the chip reset on the VLI so I can't immediately see how state can be propagated to the host OS, although maybe the devices are now seeing a different sequence of USB resets.

[thatchunkylad198966]

Ugh, how do I select the beta bootloader?

[DIE_KUH]

Ugh, how do I select the beta bootloader?

https://www.raspberrypi.org/documentati ... teeprom.md

Changing the firmware release

You can change which release stream is to be used during an update by editing the /etc/default/rpi-eeprom-update file and changing the FIRMWARE_RELEASE_STATUS entry to the appropriate stream.

[jr3us]

Ugh, how do I select the beta bootloader?

When you edit rpi-eeprom-update, change the word critical to beta.

[thatchunkylad198966]

Done but I have a red/orange always on light when trying to boot?

[Herbaldew]

Any guesses what I have done wrong?

Went through the process 3 times all with same results. Once I remove the SD card and boot, I no longer have wifi and my mouse quits working.

On the bright side, I was expecting this to be much slower than hybrid SD/USB booting (My Pi 3b rebooted in 30 seconds hybrid/around 60 seconds pure USB) - Wow! Now booting hybrid around 30 seconds pure USB around 20 seconds Good job!

Glad it's booting. It might be worth trying a powered USB hub.

The PCI controller is reset before starting Linux which also asserts the chip reset on the VLI so I can't immediately see how state can be propagated to the host OS, although maybe the devices are now seeing a different sequence of USB resets.

I setup the SD card and then cloned it to my SSD and all is good. I was trying to copy just the /boot folder onto both a fresh image and a backed up image on my SSD and got the problems I posted.

Thanks

[thatchunkylad198966]

Done but I have a red/orange always on light when trying to boot?

I'm trying to boot from a USB3 to SATA sabrent lead. it's not booting. I've tried formatting it and flashing the eeprom whilst booted from the SD and nope. what am I doing wrong?

[thatchunkylad198966]

Also tried flashing the SSD with Raspbian and still nope. am I missing something?

[andrum99]

I've managed to find a device that breaks USB boot if it is attached. ...

For some reason the bootloader is hanging when it tries to talk to this drive.
...

Not sure that it's actually hanging, it will probably give up on USB boot and try SD in about 20 seconds time. Most likely TEST_UNIT_READY is not responding. so that it can't progress any further.
Probably best to raise a GitHub issue with a dump of the logs containing at least the descriptors, msd, msd_verbose xhci log levels.

It has actually hung - it took me a lot longer than 20 seconds to get a photo of the screen, then go back and see that it was still at exactly the same point. I will raise a github issue once I've got debug logging up and running.

[thatchunkylad198966]

Done this;

Create a bootable USB drive
Use the Raspberry Pi Imager to flash Raspbian to a USB mass storage device. Other distros have not been tested and may require updates (e.g. u-boot). One reason for having a public beta is to help get USB MSD boot support into other distros.
Download the updated firmware files *.elf *.dat from the master branch of the Raspberry Pi Firmware Github repo.
Alternatively use sudo rpi-update to update the firmware on a Raspbian SD card install and copy the files from there.
Copy these updates to the boot partition on the USB device. From now on sudo rpi-update can be used from within Raspbian on the USB boot device.
A Linux kernel update is not required. Raspbian has been tested using the 4.19 and 5.4 (32 and 64 bit) kernel.

Still won't boot....

[satadru]

So my setup is probably an outlier... but I've been able to boot this morning's firmware & kernel (both 5.4.40-v8+ & 5.4.42-v8+ ) via tftp.

However, I've only been successful at booting this morning's 5.4.40-v8+ kernel via USB mass storage. (Even there, booting success is stochastic.)

Booting 5.4.42-v8+ via USB mas storage consistently gives me USB errors, usually ending in thus after USB devices are enumerated:

Code: Select all

vcc-sd: disabling

(Occasionally I get a message like this afterward:

Code: Select all

random: crng init done

(I think initramfs never gets loaded in these instances)

This has also been happening sporadically with recent firmware and sdcard boot.) Older firmware never caused an issue.

My system other than the kernel is ubuntu focal arm64, with a zfs rootfs.

I've updated my usb firmware as well, and there's been no change there.

Running a Sabrent USB-NVME enclosure as the primary USB device, with a hub hanging off of it I have disabled intentionally with USB_MSD_EXCLUDE_VID_PID

This is my boot conf:

Code: Select all

[all]
BOOT_UART=0
WAKE_ON_GPIO=1
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=1
USB_MSD_BOOT_MAX_RETRIES=5
BOOT_ORDER=0xf124
USB_MSD_EXCLUDE_VID_PID=05e30612
USB_MSD_DISCOVER_TIMEOUT=20000
USB_MSD_LUN_TIMEOUT=4000

This is my lsusb -tv output:

Code: Select all

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
        ID 05e3:0612 Genesys Logic, Inc. Hub
        |__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
            ID 1058:25fb Western Digital Technologies, Inc. 
        |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
            ID 1058:25fb Western Digital Technologies, Inc. 
        |__ Port 3: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
            ID 1058:25fb Western Digital Technologies, Inc. 
        |__ Port 4: Dev 7, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
            ID 1058:25fb Western Digital Technologies, Inc. 
    |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
        ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. 
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        ID 2109:3431 VIA Labs, Inc. Hub
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            ID 05e3:0610 Genesys Logic, Inc. 4-port hub

More debug info: https://paste.ubuntu.com/p/4VB4XtgB5b/

I also get a lot of "xhc-cmd err: 4 type 11" errors at the bootloader screen until the kernel is found.

[RuggedPineapple]

Booting fails on a Samsung Fit Plus 128 from what I can tell, might be screwing it up. The bootloader appears to see it ( https://imgur.com/a/zTiLHcH screen grab from the boot sequence, board says it's too large to attach) but will just hang forever on a black screen that allows me to input text but isn't a command prompt.