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

[JackD12001]

Booting great

None of the other USB devices are getting the way.

Now, what to do with that Micro SD

[jr3us]

Timg and hardware experts:

I have created an sd card that I successfully used to convert the RPi4 to use the new USB boot capability.

Can I use this same card to convert my other RPi4s without modifying the card again by using the commands needed after booting from the SD card?

When the conversion occurred for the RPi3's , I was able to do similar to turn on USB boot for them.


Thanks in advance for the information!

[neilshep50]

All works first time for me

Raspberry Pine ( MagPi issue 91, page 28 )
Using a Sandisk Z400s 256GB SSD in a USB3/SATA adapter case. lsusb output below:

Code: Select all

pi@raspberrypi:~ $ 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 04f2:b091 Chicony Electronics Co., Ltd Webcam
Bus 001 Device 003: ID 046d:c52b 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
pi@raspberrypi:~ $ 

Next job: Try it with my Toshiba 128GB mSATA SSD in an ASM1153E USB3 bridge. This previously required the usb-quirks fix to make it work on the USB3.0 ports. EDIT Works just fine on the USB 3.0 port. This Adapter/SSD combination requires to be attached to a USB2.0 port to flash succesfully with Balena Etcher or Raspberry Pi Imager on a Windows 10 machine.

[Man in a van]

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

try replacing

start4.elf
fixup4.dat

worked for me

ronnie

[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

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.

I have an idea of what's going on now, but it's not quite as I described previously. It seems that every time I reflash the bootloader with new settings, it uses the values that I wrote the previous time! This makes no sense, but I can reproduce it as it happens every single time.

I've been using this sequence of commands to update the bootloader config:

Code: Select all

nano bootconf.txt
rpi-eeprom-config --out pieeprom-new.bin --config bootconf.txt pieeprom.bin
sudo rpi-eeprom-update -d -f ./pieeprom-new.bin
sudo reboot

Presently, the output of vcgencmd bootloader_config is this:

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=0xf014

This exactly matches the contents of bootconf.txt, but when booting the displayed boot order is 0xf214, which was the value that I previously set.

I don't know how to generate the hash file(s) that you asked for, and I can't find any pieeprom.upd file, but I've attached a zip of the pieeprom-new.bin file below for your perusal - EDIT: attached a zip of the original pieeprom.bin as well:

pieeprom.zip

(208.34 KiB) Downloaded 11 times

pieeprom-new.zip

(208.35 KiB) Downloaded 10 times

[timg236]

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.

I have an idea of what's going on now, but it's not quite as I described previously. It seems that every time I reflash the bootloader with new settings, it uses the values that I wrote the previous time! This makes no sense, but I can reproduce it as it happens every single time.

I've been using this sequence of commands to update the bootloader config:

Code: Select all

nano bootconf.txt
rpi-eeprom-config --out pieeprom-new.bin --config bootconf.txt pieeprom.bin
sudo rpi-eeprom-update -d -f ./pieeprom-new.bin
sudo reboot

Presently, the output of vcgencmd bootloader_config is this:

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=0xf014

This exactly matches the contents of bootconf.txt, but when booting the displayed boot order is 0xf214, which was the value that I previously set.

I don't know how to generate the hash file(s) that you asked for, and I can't find any pieeprom.upd file, but I've attached a zip of the pieeprom-new.bin file below for your perusal - EDIT: attached a zip of the original pieeprom.bin as well:pieeprom.zippieeprom-new.zip

My best guess is that the update isn't actually happening and then upon reboot the temporary update files are removed by the rpi-eeprom-update service. You could try using the Raspberry Pi Imager to create an EEPROM rescue SD card, and replacing pieeprom.bin with pieeprom.upd and the pieeprom.sig (copy these from /boot when rpi-eeprom-update -d - f is run)

The hash can be generated by "sha256sum pieeprom.bin"

Is this a clean Raspbian install or an update to an existing image? What's the partition table "sudo fdisk -l" ?

[Marko73]

My best guess is that the update isn't actually happening and then upon reboot the temporary update files are removed by the rpi-eeprom-update service.

You're quite right, I checked again and if I reboot twice after changing the settings, the new boot sequence is finally applied!

[timg236]

My best guess is that the update isn't actually happening and then upon reboot the temporary update files are removed by the rpi-eeprom-update service.

You're quite right, I checked again and if I reboot twice after changing the settings, the new boot sequence is finally applied!

Great thanks for checking that, at least it's not a parsing error in the config reader. I've just added a quick change to the bootloader to display the SHA256 hash of the config file on the HDMI screen to help verify it. Admittedly, hashes aren't that friendly to most end users but it's very easy for second-level technical support to check them against last known good etc which is why the start.elf hash is also printed.

I'll probably push release a new beta of just the bootloader early next week with a collection of minor mods rather than creating lots of churn with individual releases.

[Marko73]

Just a quick question - I have masked the rpi-eeprom-update service, so the update files aren't removed on reboot. Does this mean they're applied every single time I boot?

[timg236]

Just a quick question - I have masked the rpi-eeprom-update service, so the update files aren't removed on reboot. Does this mean they're applied every single time I boot?

If the bootloader sees a pieeprom.upd or vl805.bin file then it will read them and compare them to the current images. If there's a difference the update will be applied and a reset is triggered. Otherwise, boot continues as normal.

So, there's a small performance overhead in leaving the files there but it's not going to fry the EEPROMs

[Marko73]

Just a quick question - I have masked the rpi-eeprom-update service, so the update files aren't removed on reboot. Does this mean they're applied every single time I boot?

If the bootloader sees a pieeprom.upd or vl805.bin file then it will read them and compare them to the current images. If there's a difference the update will be applied and a reset is triggered. Otherwise, boot continues as normal.

So, there's a small performance overhead in leaving the files there but it's not going to fry the EEPROMs

That was what I was worried about. Thanks for clearing that up

[RamaSpaceShip]

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

with a WD Blue 250GB SSD

and it worked at the first try!

[pootle]

Just done this with an original pi4 and a crucial bx500 240GB SSD connected with a cheap amazon usb - sata cable.

Just a logitech K400+ wireless kbd connected

Worked perfectly.

[BRX7]

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

with a WD Blue 250GB SSD

and it worked at the first try!

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

[BRX7]

Is there a way to force reflash eeprom?
also do we need to enter anything additional to config.txt or set partiton flag to boot?

[jr3us]

Timg and hardware experts:

I have created an sd card that I successfully used to convert the RPi4 to use the new USB boot capability.

Can I use this same card to convert my other RPi4s without modifying the card again by using the commands needed after booting from the SD card?

When the conversion occurred for the RPi3's , I was able to do similar to turn on USB boot for them.

Answering my own question, I tried updating another rpi4 using the same sd card and all that needed to be done was the rpi-eprom-update command once booted to the sd card used for the first RPi4!

I have now updated 3 of my RPi4s with the new eeprom firmware!

Regards!

[RonR]

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

A hybrid MBR is only required on the BOOT partition. mbr2gpt takes care of the whole process of converting and adding it.

[RonR]

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

GPT (with hybrid MBR on the BOOT partition) has been working well with both USB mass storage devices and SD cards on all Raspberry Pi's, and appears to be working equally well with all devices using the new Raspberry Pi 4 bootloader. GPT creation is supported with usb-boot and mbr2gpt.

This is a GPT SD card booted stand-alone on a Raspberry Pi 4 with the new bootloader and 5.4.42:

Code: Select all

/dev/mmcblk0p1: SEC_TYPE="msdos" UUID="3F22-886D" TYPE="vfat" PARTUUID="7ce111ad-90e7-4925-8ec1-6f109680237d"
/dev/mmcblk0p2: UUID="9da84841-567a-41e9-9cda-cc356d96a95b" TYPE="ext4" PARTUUID="96ac6df6-886c-4653-9a78-4dca2832e385"
/dev/mmcblk0: PTUUID="3a110cf5-466c-4d26-9935-1fb999dba037" PTTYPE="gpt"

A 4TB HD drive works equally well.

[hippy]

I have identified an oddity.

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.

Booted from the exact same SD Card in the SD socket it's how I would expect; just a few flashes every now and again.

I have double-checked the behaviour multiple times and it's consistent. Not sure how I can determine why the LED is flashing. dmesg shows nothing unusual.

As expected, or not, just me ?

[jdb]

It's a consequence of having no SD card in the slot - it's being polled several times a second for a card being inserted. This causes the activity LED to light.

[rpdom]

It's a consequence of having no SD card in the slot - it's being polled several times a second for a card being inserted. This causes the activity LED to light.

Does the

Code: Select all

dtoverlay=sdtweak,poll_once

option in config.txt work the same as it does on the Pi 3 range?

[W. H. Heydt]

It's a consequence of having no SD card in the slot - it's being polled several times a second for a card being inserted. This causes the activity LED to light.

Does the

Code: Select all

dtoverlay=sdtweak,poll_once

option in config.txt work the same as it does on the Pi 3 range?

Already tried that...no it doesn't change the behavior.

[JSEsq]

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?

[RonR]

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

[noee]

I just converted over from a hybrid SD/USB boot, seems like everything is working. Here are the USB devices on my Pi4:

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
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 20b1:000a XMOS Ltd 
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 004: ID 152a:85dd Thesycon Systemsoftware & Consulting GmbH 
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Only tested 32b.

One question, I see a boot screen now that shows the "SD card missing", then a pause, then it boots to the USB. Is this boot screen and pause expected?