Sticky: USB-MSD boot EEPROM third update - 2020-06-12

[RonR]

This works for me. I did have issues as described above but I don't believe it's the process which is flawed -

Code: Select all

wget https://github.com/raspberrypi/rpi-eeprom/raw/master/firmware/beta/pieeprom-2020-06-12.bin
rpi-eeprom-config pieeprom-2020-06-12.bin > cfg.txt
nano cfg.txt
rpi-eeprom-config --out new.bin --config cfg.txt pieeprom-2020-06-12.bin
sudo rpi-eeprom-update -d -f ./new.bin
sudo reboot

You can use 'vcgencmd bootloader_config > cfg.txt' to get your current settings as 'cfg.txt'.

You don't need to do all that unless you're changing your bootloader configuration.

All you need to do is run:

Code: Select all

sudo rpi-eeprom-update -f pieeprom-2020-06-12.bin

Your bootloader configuration will remain unchanged if you don't use the -d option.

[thatchunkylad198966]

This works for me. I did have issues as described above but I don't believe it's the process which is flawed -

Code: Select all

wget https://github.com/raspberrypi/rpi-eeprom/raw/master/firmware/beta/pieeprom-2020-06-12.bin
rpi-eeprom-config pieeprom-2020-06-12.bin > cfg.txt
nano cfg.txt
rpi-eeprom-config --out new.bin --config cfg.txt pieeprom-2020-06-12.bin
sudo rpi-eeprom-update -d -f ./new.bin
sudo reboot

You can use 'vcgencmd bootloader_config > cfg.txt' to get your current settings as 'cfg.txt'.

You don't need to do all that unless you're changing your bootloader configuration.

All you need to do is run:

Code: Select all

sudo rpi-eeprom-update -f pieeprom-2020-06-12.bin

Your bootloader configuration will remain unchanged if you don't use the -d option.

Worked first try!
Cheers dude.

EDIT: this has been ran on a 120GB SSD I got for £6 from a local carboot, performing well.



/boot and / is on the SSD. can't complain.

[pqa]

After booting from USB (M.2 SATA SSD), the green ACT LED is permanently lit, and every 10 seconds the following is logged:

[ 255.851826] mmc0: Timeout waiting for hardware cmd interrupt.
[ 255.851836] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 255.851847] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
[ 255.851857] mmc0: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
[ 255.851866] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[ 255.851876] mmc0: sdhci: Present: 0x1fff0001 | Host ctl: 0x00000001
[ 255.851885] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080
[ 255.851893] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
[ 255.851902] mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
[ 255.851911] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003
[ 255.851920] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[ 255.851929] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525
[ 255.851938] mmc0: sdhci: Cmd: 0x0000371a | Max curr: 0x00080008
[ 255.851946] mmc0: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000
[ 255.851955] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
[ 255.851962] mmc0: sdhci: Host ctl2: 0x00000000
[ 255.851971] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
[ 255.851979] mmc0: sdhci: ============================================

After inserting an SD card, the green LED goes out, the following is logged, and the above timeout messages stop:

[ 256.101110] mmc0: new ultra high speed DDR50 SDHC card at address aaaa
[ 256.102344] mmcblk0: mmc0:aaaa SC32G 29.7 GiB
[ 256.104877] mmcblk0: p1 p2

This is a Raspberry Pi model 4b v1.1 with 4Gb memory. The kernel is:
Linux aaron 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux

The problem occurs with both the 2020-06-03 and 2020-06-12 bootloader.

If I remove
enable_uart=1
from /boot/config.txt

then I get the following message, but only once (i.e. not repeated every
10 seconds), and the green LED now flickers approx once per second. Inserting
an SD card stops the once per second flickering.

[ 26.088338] mmc0: Timeout waiting for hardware cmd interrupt.
[ 26.088350] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 26.088363] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
[ 26.088374] mmc0: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
[ 26.088384] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[ 26.088393] mmc0: sdhci: Present: 0x1fff0001 | Host ctl: 0x00000001
[ 26.088403] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080
[ 26.088412] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
[ 26.088422] mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
[ 26.088431] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003
[ 26.088440] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[ 26.088449] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525
[ 26.088458] mmc0: sdhci: Cmd: 0x0000371a | Max curr: 0x00080008
[ 26.088468] mmc0: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000
[ 26.088477] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
[ 26.088485] mmc0: sdhci: Host ctl2: 0x00000000
[ 26.088494] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
[ 26.088501] mmc0: sdhci: ============================================
[ 31.207544] vcc-sd: disabling

Other than the above, I have not observed any other issues.

I am using:
UGREEN M.2 SATA SSD Enclosure USB C to M2 Caddy NGFF Gen2 Adapter
(lsusb shows 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)
Western Digital WDS250G2B0B WD Blue 3D NAND Internal SSD M.2 SATA, 250 GB

[agzorig]

Success!
My Pi 4B 4GB now boots from a 2.5" 120GB SSD via a USB 3.0 - SATA Adapter.

Thanks!

[thatchunkylad198966]

Success!
My Pi 4B 4GB now boots from a 2.5" 120GB SSD via a USB 3.0 - SATA Adapter.

Thanks!

Welcome to the club!

[cormack]

I've been banging away at my system all weekend, and couldn't be happier with where things are. Everything has been working fine on my Pi 4B 2GB v1.1 board, with SupTronics X820 V3.0 SATA III board and Samsung 860 QVO 1TB SSD. I believe I'm as up to date on everything as can be, if I've been following these threads correctly. Even the latest rpi-update seems to be working... my "tvservice -m" command is again returning all the modes supported by my HDMI dummy plugs (this system runs headless, but I use dummy plugs to give the HDMI subsystem something to see.)

Code: Select all

===============================================================================
 MODEL AND FIRMWARE VERSION
===============================================================================

Raspberry Pi 4 Model B Rev 1.1

Jun 10 2020 17:48:30 
Copyright (c) 2012 Broadcom
version e46bba1638cca2708b31b9daf4636770ef981735 (clean) (release) (start_x)

===============================================================================
 OPERATING SYSTEM
===============================================================================

Raspbian GNU/Linux 10 (buster)
Linux pi-dev 5.4.45-v8+ #1321 SMP PREEMPT Wed Jun 10 17:46:14 BST 2020 aarch64 GNU/Linux

===============================================================================
 PI MODEL 4B EEPROM VERSION
===============================================================================

Jun 12 2020 11:55:44
version ef583b735977179d4b27711af03419559f982a5e (release)
timestamp 1591959344

===============================================================================
 PI MODEL 4B EEPROM UPDATE STATUS
===============================================================================

BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Fri 12 Jun 2020 10:55:44 AM UTC (1591959344)
 LATEST: Fri 12 Jun 2020 10:55:44 AM UTC (1591959344)
 FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000138a1
 LATEST: 000138a1

===============================================================================
 PI MODEL 4B EEPROM CONFIG
===============================================================================

[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

[Fredmoy]

This works for me. I did have issues as described above but I don't believe it's the process which is flawed -

Code: Select all

wget https://github.com/raspberrypi/rpi-eeprom/raw/master/firmware/beta/pieeprom-2020-06-12.bin
rpi-eeprom-config pieeprom-2020-06-12.bin > cfg.txt
nano cfg.txt
rpi-eeprom-config --out new.bin --config cfg.txt pieeprom-2020-06-12.bin
sudo rpi-eeprom-update -d -f ./new.bin
sudo reboot

You can use 'vcgencmd bootloader_config > cfg.txt' to get your current settings as 'cfg.txt'.

You don't need to do all that unless you're changing your bootloader configuration.

All you need to do is run:

Code: Select all

sudo rpi-eeprom-update -f pieeprom-2020-06-12.bin

Your bootloader configuration will remain unchanged if you don't use the -d option.

Worked first try!
Cheers dude.

EDIT: this has been ran on a 120GB SSD I got for £6 from a local carboot, performing well.



/boot and / is on the SSD. can't complain.

Hi which Benchmar software did you use ?

[Kendek]

...
Hi which Benchmar software did you use ?

This is the GNOME Disks.

[thatchunkylad198966]

@Fredmoy - "Gnome disks"

[neilshep50]

Hi which Benchmar software did you use ?

sudo apt install gnome-disk-utility

disks then appears in "accesories"

[thatchunkylad198966]

Hi which Benchmar software did you use ?

sudo apt install gnome-disk-utility

disks then appears in "accesories"

Or: "sudo apt install --no-install-recommends gnome-disk-utility"

[Fredmoy]

Hi which Benchmar software did you use ?

sudo apt install gnome-disk-utility

disks then appears in "accesories"

Or: "sudo apt install --no-install-recommends gnome-disk-utility"

Thank you i have similar results, 377 Mo/s, mSATA 128GO with USB3 adapter, just acces time is 16ms

[timg236]

With just the SD Card inserted, usual Boot Screen and booting, works fine, just as it did when I left it yesterday ...

Code: Select all

pi@Pi4B:~ $ uname -a
Linux Pi4B 5.4.45-v7l+ #1321 SMP Wed Jun 10 17:39:20 BST 2020 armv7l GNU/Linux

Code: Select all

pi@Pi4B:~ $ sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Fri 12 Jun 10:55:44 UTC 2020 (1591959344)
 LATEST: Wed  3 Jun 12:53:47 UTC 2020 (1591188827)
 FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad

So that's "perfect" as far as I can see, 2020-06-12 in place. Onwards and upwards.

Powered down, removed the SD Card and inserted the 'was bootable' USB device. Powered-up ...

Red and green LED on permanently, no HDMI. "Nada"; a typical 'green light of death' situation.

Powered down, inserted SD Card, left the USB device connected, powered-up ...

As expected, HDMI comes on, Boot Screen appears, goes by too fast to read what's happening, boots from SD Card, green LED flashing on accesses, everything works as expected. Desktop appears, USB device mounted, looks as expected.

But darn it, back to 2020-04-16 Boot Eeprom image installed ...

Code: Select all

pi@Pi4B:~ $ uname -a
Linux Pi4B 5.4.45-v7l+ #1321 SMP Wed Jun 10 17:39:20 BST 2020 armv7l GNU/Linux

Code: Select all

pi@Pi4B:~ $ sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
*** UPDATE REQUIRED ***
BOOTLOADER: update required
CURRENT: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
 LATEST: Wed  3 Jun 12:53:47 UTC 2020 (1591188827)
 FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad

I updated the Boot Eeprom to 2020-06-12. Re-booted with SD Card inserted, USB device removed, and that worked as expected. Still at 2020-06-12 Boot Eeprom. So okay again. A couple of further reboots without USB device connected and it stays the same.

Connect the non-bootable USB device and reboot. SD Boots and we are again reverted back to 2020-04-16.

So just plugging the USB device in and rebooting is reverting the Boot Eeprom.

Which led me to; 'recovery.bin', 'pieeprom.upd' and 'pieeprom.sig' being present on both SD Card /boot and USB device /boot.

Delete all those and reboot and they are gone on USB but reappear on SD. Presumably because what's installed is earlier than what release it's tracking.

Update once again to 2020-06-12. Reboot and, Tada!, USB booted. With USB removed booting from SD card works. With only USB that also works. Without either it falls back to network booting.

So I guess the issue is that Boot Eeprom updates happen before the boot media is determined so it can update from USB before booting SD and update from SD before booting from USB. And then one ends up in a circle of hell when what's updated doesn't match what's just booted.

I guess that if everything matches on everything one is booting, everything is set exactly the same, then everything is fine but when it isn't, that's when things break.

I must admit that I haven't figured out head from tail in the complexity which is Boot Eeprom auto-updating with FREEZE_VERSION, ENABLE_SELF_UPDATE, bootloader_update, 'apt full-upgrade', and the systemd update service. I guess I need to study the documentation. I'd stuck to defaults in the hope of avoiding things going wrong. I didn't think there was any possibility of an auto-downgrade but that seems to be what does happen in some circumstances.

I can't help but think it's far more complicated than it needs to be and I'm not going to be the only one who gets themselves into a complete mess.

Can't we just have it that 'apt full-upgrade' does it all, tells the user to reboot when they need to - or leave them to figure it out for themselves as for other cases, and let them hold back the rpi-eeprom package if they don't want to auto-update ?

APT update already does this and once USB MSD is released the default self-update behaviours means that it will continue working. The vast majority of users don't need to run rpi-eeprom-update because Raspberry Pi OS does it for them. This never downgrades the bootloader (but recovery.bin will because it's just an image flashing tool).

There's no need to customize FREEZE_VERSION, ENABLE_SELF_UPDATE or in fact most of the EEPROM settings and when USB MSD is released people won't have to do it then either. That sort of thing is only really for industrial customers who want to control update behaviour directly.

There will always be churn in beta releases and there were large warnings in all the release posts indicating that people might get into a pickle for exactly these sorts of reasons.

N.B. There's a nice change in raspi-config (pending in Github) which adds a simple menu to choose between network/sd boot and usb/sd which for most people is the only real reason to tweak the bootloader config.

[thatchunkylad198966]

N.B. There's a nice change in raspi-config (pending in Github) which adds a simple menu to choose between network/sd boot and usb/sd which for most people is the only real reason to tweak the bootloader config.

How long before that's released?

[hippy]

There will always be churn in beta releases and there were large warnings in all the release posts indicating that people might get into a pickle for exactly these sorts of reasons.

Absolutely, and revealing the potential pickles, the why and how to resolve them, is a part of that. Other than this mess I got myself into it's all gone well, and it's back on track again.

[timg236]

N.B. There's a nice change in raspi-config (pending in Github) which adds a simple menu to choose between network/sd boot and usb/sd which for most people is the only real reason to tweak the bootloader config.

How long before that's released?

I think the blocker is for USB MSD to be stable so you might get a second menu option
production software / stable releases
netboot / usb boot

[thatchunkylad198966]

N.B. There's a nice change in raspi-config (pending in Github) which adds a simple menu to choose between network/sd boot and usb/sd which for most people is the only real reason to tweak the bootloader config.

How long before that's released?

I think the blocker is for USB MSD to be stable so you might get a second menu option
production software / stable releases
netboot / usb boot

Nice! Looking forward to it.

[timg236]

-- Toggle USB root hub port power for 200ms on the first USB MSD boot attempt

My 4B2 system still cold boots and reboots fine, but I'm also running the beta VL805 138a1 firmware (if that matters).

Since this seems to be problematic for others, I wonder if it could be made a bootconfig.txt option?

Yes, I've reluctantly added a new config (there are too many configs) USB_MSD_PWR_OFF_TIME which if zero disables power-off when the xHC is initialised. After some more interop tests, the default is 500 and the accepted range is between 250 and 1000.

-- Improve handling of multiple bootable USB devices
-- Update bootloader handover to support uart_2ndstage - requires a newer start.elf firmware which will be via rpi-update.

These sound interesting, could you explain those changes in more detail, please?

Previously, before the bootloader cycled through the different boot-modes it could be configured to retry a boot-mode SD/network N times before giving up. A fixed number of retries doesn't make sense with an unknown and possibly changing number of MSD devices and bootable partitions so by default the bootloader just waits for a fixed amount of time (default 20 seconds) for a usable partition to appear.

[Kendek]

I've reluctantly added a new config (there are too many configs) USB_MSD_PWR_OFF_TIME which if zero disables power-off when the xHC is initialised. After some more interop tests, the default is 500 and the accepted range is between 250 and 1000.

Thank you for that, the USB_MSD_PWR_OFF_TIME=0 works great for me.
Now with 8GB Pi4 there is only one USB power cut (which is manageable), and nada with 4GB (which is perfect).

[timg236]

I've reluctantly added a new config (there are too many configs) USB_MSD_PWR_OFF_TIME which if zero disables power-off when the xHC is initialised. After some more interop tests, the default is 500 and the accepted range is between 250 and 1000.

Thank you for that, the USB_MSD_PWR_OFF_TIME=0 works great for me.
Now with 8GB Pi4 there is only one USB power cut (which is manageable), and nada with 4GB (which is perfect).

Which power cut is that? Linux USB init?

N.B. Pi revisions < 1.3 don't have an SD PWR switch so if there is a UHS card it will have switched to 1V8 but to safely switch back to 3V3 the power must be disconnected. The only way to do that on older revisions is to reset the PMIC which also cuts USB power. The 8GB is new enough to have the power switch and on older boards USB boot means that there is no PMIC reset so long as UHS SD card is not present.

NOOBS disables UHS mode in the NOOBS menu because a PMIC reset loses the partition id. It does this by setting sdhci.debug_quirks2=4

[Kendek]

Now with 8GB Pi4 there is only one USB power cut (which is manageable), and nada with 4GB (which is perfect).

Which power cut is that? Linux USB init?

With 8GB Pi4 (1.4, empty SD card slot), after the reboot command the USB power will cut off, simultaneously with the RPi's power LED. See my video on this. However, there is no similar phenomenon with the 4GB variant.

[webdev]

Does /boot has to be FAT file system? does it has to be first partition of SSD? I place it as same partition of /, and it report "unable to read partition as fat",

[DougieLawson]

Does /boot has to be FAT file system? does it has to be first partition of SSD? I place it as same partition of /, and it report "unable to read partition as fat",

Yes & yes.

[philrandal]

The way I got that done is by doing the rpi-update on a RaspberryPiOS boot SD card, and then copying /boot/start*.elm and /boot/fixup*.dat from the RaspberryPiOS SD card and replacing with these the ones that were on the Kali boot partition.

Thanks for the tip.

Installed Raspberry Pi OS onto a WD Blue 250GB SSD (using a USB <-> SATA adapter) and copied the updated start*.elf and fixup*.dat to it, plugged it into a Pi 4 with the latest boot rom, and lo, it booted from the USB disk first time.

Fabulous!

Cheers,

Phil

[BRX7]

I'm having a nightmare with 2020-06-15, its less stable than 2020-06-12, I think 2020-06-03 was maybe a bit better.
somtimes times its stuck before the rainbow looking for recovery elf? sometimes after the rainbow.
using a integral 128gb ssd, startech usb 3.1 adaptor ,with a RPI4 8GB 1.4 OS is manjaro arm 64bit.

my boot config
[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
BOOT_ORDER=0xf41

my RPI4 4GB 1.2 is much more stable.