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

[thatchunkylad198966]

I give up.

[W. H. Heydt]

Just a small detail but using the EEPROM image from 15/05/20 I initially couldn't get USB booting to work, because the boot order was 0xF21 instead of 0xF41 as described on the bootload configuration page. However, dumping the config to a text file, the boot order was listed as 0xF41. Rewriting the config to the EEPROM also seemed not to behave as expected - rewriting the config with boot order of 0xF41 didn't work at first - I had to change it to something different first, then back to 0xF41 before it worked.

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

Code: Select all

sudo apt update && sudo apt upgrade
cd /lib/firmware/raspberrypi/bootloader/beta
md5sum pieeprom-2020-05-15.bin
# 7e6c31d3c1af0787a567229ba2e444b9
rpi-eeprom-config pieeprom-2020-05-15.bin 

Code: Select all

[all]
BOOT_UART=0
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

I'm seeing the same behavior that Marko reported. md5sum matches what you posted. A dump down to bootconf.txt shows BOOT_ORDER=0xf41. However, during the boot process, it shows 0xf21. I will try Marco's workaround....

Edit to add: Used Marco's method. First changed to 0x124. That booted to SSD. The set it to 0x41 and it still boots.

Code: Select all

pi@ddc4test:~/pieeprom $ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 111.8G  0 disk
├─sda1   8:1    0   512M  0 part /boot
└─sda2   8:2    0 111.3G  0 part /

Code: Select all

pi@ddc4test:~/pieeprom $ blkid
/dev/sda1: LABEL_FATBOOT="SSD_BOOT" LABEL="SSD_BOOT" UUID="E923-8E0A" TYPE="vfat" PARTUUID="5a76e188-01"
/dev/sda2: LABEL="ssd_root" UUID="c0929a72-23fc-4ca5-8a16-919718dcbd8c" TYPE="ext4" PARTUUID="5a76e188-02"

Code: Select all

pi@ddc4test:~/pieeprom $ lsusb
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
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

Note...The Pi is connected via a USB 2 port to a KVM switch that has an internal hub. The SSD is connected through an Eluteng SATA adapter to a USB 3 port.

[HawaiianPi]

Yay, it works!

Haven't read through this thread yet, but I converted my /boot on uSD card + / on USB-SSD 4B2 to cardless USB boot, and it seems to be working fine so far (cold boot and reboot).

Configuration

• Raspberry Pi 4B 2GB (rev. 1.1)
• Raspbian Buster with desktop (SSH, VNC server and serial console output enabled)
• Official RPF USB-C power supply
• SP 256GB SATA-III SSD
• Eluteng USB 3.0 to SATA-III adapter cable (blue version, default firmware)
• CP2102 USB-TTL (3V3) UART (used as serial console cable)
• Logitech Unifying dongle (K400r keyboard with touchpad)
• 2 layer acrylic case with 40x10mm Noctua Fan (cheap case with expensive fan)

System was originally configured by cloning a Raspbian SD card to the SSD and copying the files from /boot to another FAT32 formatted card (with a few tweaks here and there, the main one being editing /etc/fstab to mount the SD card as /boot). I continued with /boot on the SD card while updating firmware and configuring the boot-loader, and when it all seemed to be ready, I deleted the contents of the SSD "boot" partition and copied the SD card contents there. A final edit of /ect/fstab to mount the SSD "boot" partition as /boot and I was ready to go cardless.

Tried a few cold boots and reboots and it worked as expected (booted right up from USB with no card in system).

Now that I have a working configuration I can try cloning it to other USB mass storage devices to test them (cloning to a Samsung BAR Plus 64GB USB 3.1 flash drive as I type this).

Thank you to everyone who contributed. You rock!


EDIT1
Using Raspbian's SD Card Copier utility to clone my SSD to the Samsung USB flash drive worked. Will test others as time allows.

EDIT2: ran some quick tests on other ASMedia based adapters I have (cold boot and reboot).
Older Eluteng USB 3.0 to SATA-III adapter cable with black SATA connector and default firmware (no TRIM) works!
Older Eluteng USB 3.0 to SATA-III adapter cable with black SATA connector and firmware updated to fix TRIM works!
TNP* USB 3.0 to SATA-III adapter cable with firmware updated to fix TRIM works! *Generic version of Eluteng black.

I believe above are all ASM1153E chips, but you can never be too sure with ASMedia (same device ID on multiple chips).

EDIT3
Found an ASMedia based adapter for mSATA SSD (I seem to recall this one needed a firmware update to fix TRIM).
Cloned the SP 256GB SSD to a MyDigitalSSD SuperBoot2 128GB mSATA SSD and gave it a try. It worked!

Initial testing with JMicron chip based adapters is not going well (still working in it)...
Quick test was a fail on a VIA based adapter as well.

[timg236]

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.

Are the characters appearing on the HDMI display or are you using a serial console? There's nothing before Linux which will accept keyboard input. Try removing "quiet" and "splash" from cmdline.txt and make sure that you are using PARTUUID to specify the rootfs

[timg236]

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

Boot using an SD card and make sure that you have applied to the EEPROM update correctly. You MUST use "rpi-eeprom-update -d -f" and verify BOOT_ORDER=0xf41 (or at least has 4 for MSD boot somewhere)

N.B. Vague "it didn't work" posts will be ignored. It's not worth playing 20 questions each time

[timg236]

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?

It might work if the boot file-system is in small partition at the start of the disk. Start.elf and the bootloader assume 512 byte blocks and LBAs are 32-bit, there's a lot of old code so 2TB is completely untested.

[RonR]

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

mbr2gpt should allow you to use drives over 2TB.

GPT is working here with the new bootloader and firmware.

[Kendek]

GPT is working here with the new bootloader and firmware.

GPT or GPT with hybrid MBR? Because I use the latter, but if it's not necessary...

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

Boot using an SD card and make sure that you have applied to the EEPROM update correctly. You MUST use "rpi-eeprom-update -d -f" and verify BOOT_ORDER=0xf41 (or at least has 4 for MSD boot somewhere)

N.B. Vague "it didn't work" posts will be ignored. It's not worth playing 20 questions each time

When I run this:

rpi-eeprom-update -d -f

It just tells me about other commands I should run. I still can't get it to work. I tried flashing Raspbian to the SSD, tried updating the eeprom from within the SDCARD. it doesn't boot. I get four blinking lights and an always on power light. it's a no go.

[timg236]

GPT is working here with the new bootloader and firmware.

GPT or GPT with hybrid MBR? Because I use the latter, but if it's not necessary...

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

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

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

Are the characters appearing on the HDMI display or are you using a serial console? There's nothing before Linux which will accept keyboard input. Try removing "quiet" and "splash" from cmdline.txt and make sure that you are using PARTUUID to specify the rootfs

They're on screen. Removing quiet and splash reveals init_resize.sh segfaults all over place, some errors about illegal instructions. It's a freshly etched default raspbian image aside from downloading the .dat and .elf files from git repo, have now also put it on the microSD and it boots. I probably am hosing something in this but can't seem to figure out what.

[timg236]

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.

Are the characters appearing on the HDMI display or are you using a serial console? There's nothing before Linux which will accept keyboard input. Try removing "quiet" and "splash" from cmdline.txt and make sure that you are using PARTUUID to specify the rootfs

They're on screen. Removing quiet and splash reveals init_resize.sh segfaults all over place, some errors about illegal instructions. It's a freshly etched default raspbian image aside from downloading the .dat and .elf files from git repo, have now also put it on the microSD and it boots. I probably am hosing something in this but can't seem to figure out what.

init_resize.sh will sometimes cause a crash on exit but I think it's more visible with MSD boot. It's interesting that it gets through the bootloader + start.elf loading but fails in a completely different and more reliable Linux stack. I suspect there is something unsafe in init_resize.

Are you able to repeat the process but do the first boot from the on-board SD card so that init_resize.sh runs as normal then see if it will boot via MSD afterwards ?

[RuggedPineapple]

Are the characters appearing on the HDMI display or are you using a serial console? There's nothing before Linux which will accept keyboard input. Try removing "quiet" and "splash" from cmdline.txt and make sure that you are using PARTUUID to specify the rootfs

They're on screen. Removing quiet and splash reveals init_resize.sh segfaults all over place, some errors about illegal instructions. It's a freshly etched default raspbian image aside from downloading the .dat and .elf files from git repo, have now also put it on the microSD and it boots. I probably am hosing something in this but can't seem to figure out what.

init_resize.sh will sometimes cause a crash on exit but I think it's more visible with MSD boot. It's interesting that it gets through the bootloader + start.elf loading but fails in a completely different and more reliable Linux stack. I suspect there is something unsafe in init_resize.

Are you able to repeat the process but do the first boot from the on-board SD card so that init_resize.sh runs as normal then see if it will boot via MSD afterwards ?

Yep, that does it. Put the same image on the microSD and let it do it's thing. Used Raspbian's built in SD copier utility to clone it over to the flash drive, shut down, pulled the SD card out and started it up. Boot right to the desktop.

[RuggedPineapple]

And when I said it segfaulted all over the place, I'm not exaggerating. I counted 12 segfault messages, 7 illegal instruction messages and 4 bad exec format. It REALLY didn't like something.

[Janson Hong]

Hi - I have one of these

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

After update to the new firmware this no longer works. The display is blank. Output via HDMI is ok. I have reinstalled the drivers etc but to no avail

JH

[timg236]

Hi - I have one of these

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

After update to the new firmware this no longer works. The display is blank. Output via HDMI is ok. I have reinstalled the drivers etc but to no avail

JH

Please post any issues not directly related to USB mass storage boot in a different thread for create firmware/linux bug reports. This sounds like a display issue with either latest firmware or Linux and be sure to post full details of the before/after software version.

[dom]

Please post any issues not directly related to USB mass storage boot in a different thread for create firmware/linux bug reports. This sounds like a display issue with either latest firmware or Linux and be sure to post full details of the before/after software version.

@Janson Hong here is probably best place to report issues with 5.4 kernel.

[stefanu]

cp /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-01-17.bin pieeprom.bin on the https://www.raspberrypi.org/documentati ... _config.md ?

[luftbaum]

I am using a 128GB USB 3.0 SSD.

For me it is working fine through USB 2.0 ports. But when I am plugging it into one of the USB 3.0 Ports, booting takes about 30 minutes and the system is stuttering and halting/freezing a lot (from ranges between thirty seconds to multiple minutes), basically unusable.

If I can assist with any information in that matter, please ask freely!

[jamesh]

cp /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-01-17.bin pieeprom.bin on the https://www.raspberrypi.org/documentati ... _config.md ?

You are going to have to be a bit more detailed in your report.

[hippy]

cp /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-01-17.bin pieeprom.bin on the https://www.raspberrypi.org/documentati ... _config.md ?

You are going to have to be a bit more detailed in your report.

I would guess they are intending to say the official documentation is not correct; the file which the configuration info is extracted from no longer exists after the latest updates, cannot therefore be copied as documented.

[timg236]

cp /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-01-17.bin pieeprom.bin on the https://www.raspberrypi.org/documentati ... _config.md ?

You are going to have to be a bit more detailed in your report.

I would guess they are intending to say the official documentation is not correct; the file which the configuration info is extracted from no longer exists after the latest updates, cannot therefore be copied as documented.

I've pushed a PR to the docs. If you have a comment on the docs or think that have an improvement suggestion then just do it as a Github PR. It's much more likely that someone will notice.

[HawaiianPi]

cp /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-01-17.bin pieeprom.bin on the https://www.raspberrypi.org/documentati ... _config.md ?

You need the beta firmware (bootloader), which is dated 2020-05-15.

Code: Select all

cp /lib/firmware/raspberrypi/bootloader/beta/pieeprom-2020-05-15.bin pieeprom.bin

[timg236]

I am using a 128GB USB 3.0 SSD.

For me it is working fine through USB 2.0 ports. But when I am plugging it into one of the USB 3.0 Ports, booting takes about 30 minutes and the system is stuttering and halting/freezing a lot (from ranges between thirty seconds to multiple minutes), basically unusable.

If I can assist with any information in that matter, please ask freely!

The best starting point is to boot from an SD-card then mount the drive under Linux and make sure that's happy copying big files etc. After that, we would probably need UART or Netconsole traces.

A detailed report on Github with 'lsusb -vvv' sometimes is enough.

N.B. The Linux xHC stack USB is completely standard and PCIe is reset before Linux is started. Oce the 4 raspberries are visible it's a Linux issue (Github Linux) before that bootloader UART or netconsole traces are normally needed for non-obvious bugs. If there's a general class of problematic devices we sometimes order them in.

[timg236]

I'm seeing the same behavior that Marko reported. md5sum matches what you posted. A dump down to bootconf.txt shows BOOT_ORDER=0xf41. However, during the boot process, it shows 0xf21. I will try Marco's workaround....

There's a bug in the current release where if BOOT_ORDER is zero or null it will be set to 0xf21 instead of 0xf41
(from when I was regression testing network boot!)

I suspect that's probably the issue
https://github.com/raspberrypi/rpi-eeprom/issues/129

I can't completely rule out a parsing issue which could cause BOOT_ORDER to be ignored but I tried your example at it worked for me. If you have a pieeprom.bin which contains 0xf41 which you can flash with recovery.bin (EEPROM rescue approach) which you could attached the issue above that would help rule the issue in/out.

In the small fix for issue-129 I'm also going to include the hash of the boot.conf on the diagnostics screen. There's not enough screen space to dump the full file but at least with the hash it's possible to check if the configuration file matches.