STICKY: USB-MSD boot EEPROM fourth update - 2020-06-15

[Doug_]

this will make USB boot possible....correct?

Yes it will, and *ideally* the next step is to use the clone tool to clone your current uSD Image to a SSD, shutdown, remove the uSD and reboot from the SSD and be in business to continue as normal.

The truth is that it may not happen so smoothly as that.

Probably if you have chosen a HDD or an external SSD like a Toshiba T5 or SanDisk Extreme Portable SSD it will work and will continue operating normally with very good performance. HDD somewhat slower for obvious reasons. Trim will not work but hey these drives never intended to need trim.

If you chose a SATAIII style internal SSD and an off the shelf USB3 adapter cable - you would have probably first noticed when cloning the uSD to the drive the write speed was kinda poor. The first sign you have issues. Try booting from the fresh new SSD and deep disappointment when nothing seems to happen.

You are smart and attentive and realise there is a fix - add a bit of code to the beginning of the /boot/cmdline.txt file: ‘USB-storage.quirks=xxxx:yyyy:u ‘ where xxxx and yyyy correspond to your particular interface cable. Now you can boot at USB3.0 speeds and pretty much good to go.

You learn then about trim and UAS - the two reasons you probably chose a real SSD but didn’t know it. To get this working correctly you need the ‘good’ interface - Eluteng is the brand you need to find, Amazon seems to be the best source. (Still waiting for mine!)

Now, that green LED is constantly winking at you and the Dmesg ring buffer fills every few seconds with errors. The fix for that is a blank formatted uSD card in the PI 4’s. card slot. Easy fix provided you have a uSD card laying around.

I can’t fault the RPI effort - the nonsense seems to be with the Linux kernel.

[Kendek]

...
HDD somewhat slower for obvious reasons. Trim will not work but hey these drives never intended to need trim.
...

Newer SRM HDDs supports TRIM, which is required for optimal performance.

[paulwratt]

I have just logged an #issue with https://storage.jamesachambers.com to have interface pages added to the site, which should help isolate good and bad interfaces, but also hilite interfaces that work on some systems and not on others (different firmware), thru GitHub.

However I posted an issue 1 week ago, and 2 weeks ago on his blog site, and have not had any response, is anyone else able to contact him?

I cant get to the site any more, to verify the interface info listed on his blog site https://jamesachambers.com where he tested USB3 boot on RPi4. can anyone else get to that site? or has the db/bandwidth been exceeded (a lot of uploaded data in recent weeks, with exposure from these beta threads).

alternately, has anyone got the info from the beta threads to post a sticky for RPI4 USB3 boot interface compatablity list. it would be good to provide (possible) links for those interfaces where updated firmware is known to work, and post "quirks" fix as well (saving on reposting multiple times per thread).

Cheers

Paul
(good summary post there @Doug thanks, top of the page too)

[Bookingyo]

I finally got it running using a Kingston 120gb A400 SSD and Inateck 2.5 Hard Drive enclosure which supports UASP. My Pi 4's boot via POE from my network switch.

I hope these instructions help others.

First install Raspberry Pi OS on an SD card from Linux computer using whatever method you prefer. I use gnome-disks restore image option. I also run headless so I enabled SSH by adding a file entitled ssh under /boot.

Boot your Pi 4 with the SD card loaded in the SD card slot.

Connect to Pi via SSH. Not needed if using monitor, keyboard and mouse.

Time to update the Pi OS to its latest version.

Code: Select all

sudo apt update && sudo apt upgrade -y

Code: Select all

sudo reboot

Once the device has rebooted let's run:

Code: Select all

sudo nano /etc/default/rpi-eeprom-update

and change "critical" to "stable"

Code: Select all

sudo rpi-eeprom-update -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-06-15.bin

Code: Select all

sudo reboot

Once the device has rebooted you should get the following when you run

Code: Select all

sudo rpi-eeprom-update

BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Mon 15 Jun 13:36:19 UTC 2020 (1592228179)
LATEST: Mon 15 Jun 13:36:19 UTC 2020 (1592228179)
FW DIR: /lib/firmware/raspberrypi/bootloader/stable
VL805: up-to-date
CURRENT: 000137ad
LATEST: 000137ad

and if you run

Code: Select all

vcgencmd bootloader_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

Make sure you see this 0xf41, as this tells you your boot order, 4 = USB.

Now shutdown your Pi, remove the SD card and put it in an SD card reader on your Linux computer. Plug in your external SSD drive into your computer as well. Pull up a terminal and run:

Code: Select all

lsblk

make note of your SD card /dev/### and your SSD/dev/###. Mine looked like this SD card = dev/sdi and SSD = /dev/sdj. I can usually tell by the size of the disks.

We are going to make an exact copy of your SD card onto your SSD by using the following command. Make sure your names are correct. You do not want to overwrite another hard drive and lose your data.

Code: Select all

sudo dd if=/dev/sdi of=/dev/sdj status=progress

Depending on how large the SD card is it may take some time (took about 30 minutes). Let it do its thing and once your back at the terminal prompt it's time to extend the ext4 partition using gparted. If your SD card and SSD drive are the same size then this step is not necessary.

Let's run:

sudo gparted

and select your SSD by using the drop down filter in the top right. You should now see a boot partition (fat32) and a rootfs partition (ext4). Select the rootfs partition (ext4) and right-click, choose Resize/Move and adjust your settings until all the space has been added to your rootfs (ext4) partition. Make sure to hit Apply All Operations and it should resize your disk.

Now all you need to do is plug in the USB SSD into one of the blue USB ports and boot up your Pi.

I still need to figure out TRIM support.

[davefi]

Just to follow up, swapped the reflashed cable onto the Pi 4 today and ran fstrim a couple of times, all looks good now!

Code: Select all

$ sudo fstrim -v /
/: 217 GiB (232999329792 bytes) trimmed

sudo fstrim -v /
/: 0 B (0 bytes) trimmed

[kazin08]

Hi to all!

i been using USB boot with my old HHD WD 500GB with an JMICRON adapter and work very well. I'm using ubuntu 20.04 and i can boot directly form USB but the problem is when i reboot the pi go off but it never boot again. This happen with booting from SD and switch to USB/HDD, but with this i can reboot at least one time, if i reboot 2 times it wont boot.
As far i know i can hear the HDD power OFF and power ON when the pi boots (when i can reboot one time) but then, after the second reboot the HDD never turn OFF and then the pi don't find it. I dont know if this issue is from the firmware or the USB adapter.

Also i notice something strange. When i boot directly form USB the command neofetch givme this version of kernel:
Kernel: 5.4.0-1012-raspi

And when i boot from SD and switch to USB i get this:
Kernel: 5.4.0-1008-raspi

this is becouse the *.elf and *.dat files?

Regards

[paulwratt]

@kazin, there is a note in the OP (Opening Post = 1st post in thread), which may be relevant to your issues:

- increase the default power off delay to 500ms following more interop testing.
- Make the USB port power off time configurable via the USB_MSD_PWR_OFF_TIME config. The range may be set between 250 and 1000ms. Zero means no port power off.

also double check your firmware, especially after boot failure. There are some reports of firmware being modified (due to missing config setting).

if firmware is AOK, and USB_MSD_PWR_OFF_TIME does not change your issue, then it is more likely to be Linux Kernel issue, not bootloader firmware

Hope that helps

Cheers

Paul

[thatchunkylad198966]

I asked on IRC, I'm asking here. someone else must be getting it?!

has anyone else noticed when booting from an SSD with the pi4 "stable" USB-BOOTLOADER, your "system" load is always high?
It's really annoying me.
I can idle at 0.00 when an SDCARD is being used. when the USB-BOOT is enabled, I'm getting well over 0.50 system load. why? -.-

EDIT: thought it could've been the SSD, bought a brand new 120GB from Amazon UK and it's the same. I also ordered a new USB3 to SATA too.
What's going wrong?

EDIT2: after a Google search, I found a thread saying to add this:

dtoverlay=sdtweak,poll_once

It's made no difference, though. :/ -.-

[RonR]

dtoverlay=sdtweak,poll_once

It's made no difference, though. :/ -.-

That only works on a Raspberry Pi 3. For the Raspberry Pi 4:

Code: Select all

dtparam=sd_poll_once

This will disable the ability to insert an SD card after the system has booted, however.

[thatchunkylad198966]

dtoverlay=sdtweak,poll_once

It's made no difference, though. :/ -.-

That only works on a Raspberry Pi 3. For the Raspberry Pi 4:

Code: Select all

dtparam=sd_poll_once

This will disable the ability to insert an SD card after the system has booted, however.

Cool.
Anyone else getting this issue?
I decided to try Sakaki's Gentoo, USING "Pinn lite" - installed to my USB SSD and it's fine.

[RonR]

It's made no difference, though. :/ -.-

That only works on a Raspberry Pi 3. For the Raspberry Pi 4:

Code: Select all

dtparam=sd_poll_once

This will disable the ability to insert an SD card after the system has booted, however.

Cool.
Anyone else getting this issue?
I decided to try Sakaki's Gentoo, USING "Pinn lite" - installed to my USB SSD and it's fine.

Yes, everyone has it. The developers are aware of it, but it's not clear whether there's any plan to fix it.

[Doug_]

From my window onto the world the Eluteng adapter cables are somewhat elusive to find. One option is eBay for about $80 aud, Amazon us has had my order for a week but has not yet shipped, also I was restricted to purchasing one only. I hope I receive the blue SCSI version so I don’t need to reflash it’s device.

On the other hand I have two JMicron SCSI / usb3 cables for which I have to disable the UASP with quirks. These seem to be a very common type and in my understanding properly support UASP under Windows and MacOSX.

Given that this is actually the Linux driver issue not supporting the scatter/gatherer UAS mode is there some way the issue could be promoted so it can be addressed? Ref:

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

[thatchunkylad198966]

That only works on a Raspberry Pi 3. For the Raspberry Pi 4:

Code: Select all

dtparam=sd_poll_once

This will disable the ability to insert an SD card after the system has booted, however.

Cool.
Anyone else getting this issue?
I decided to try Sakaki's Gentoo, USING "Pinn lite" - installed to my USB SSD and it's fine.

Yes, everyone has it. The developers are aware of it, but it's not clear whether there's any plan to fix it.

Alright, thank you.
Question; why was this moved to "stable" when the high system load is present as a bug?

[kazin08]

@kazin, there is a note in the OP (Opening Post = 1st post in thread), which may be relevant to your issues:

- increase the default power off delay to 500ms following more interop testing.
- Make the USB port power off time configurable via the USB_MSD_PWR_OFF_TIME config. The range may be set between 250 and 1000ms. Zero means no port power off.

also double check your firmware, especially after boot failure. There are some reports of firmware being modified (due to missing config setting).

if firmware is AOK, and USB_MSD_PWR_OFF_TIME does not change your issue, then it is more likely to be Linux Kernel issue, not bootloader firmware

Hope that helps

Cheers

Paul

Yes i tryied writing USB_MSD_PWR_OFF_TIME=500 but the pi never booted so i deleted and after that it boot. Can't see what logs says because i'm running headless for now. it's right to use 500 like 500ms? or i have to use another value?

EDIT:
I managed to change the value to 1000 (1seg) but doesnt work, after one reboot it never boot again.

Regards

[HawaiianPi]

Question; why was this moved to "stable" when the high system load is present as a bug?

First of all, I wouldn't call that a "high" system load.

And second, it's not a bug.

The system polls the SD card slot to see if you have inserted a card, so you can use the slot for additional storage or backups or creating recovery cards, etc. That polling uses some system resources.

If you don't want or need to use the SD card slot, you can disable the polling as already instructed.

Another option is to leave a non-bootable card in the slot. Most of my USB booted systems have a card in the slot that I use for backups.

[HawaiianPi]

Also i notice something strange. When i boot directly form USB the command neofetch givme this version of kernel:
Kernel: 5.4.0-1012-raspi

And when i boot from SD and switch to USB i get this:
Kernel: 5.4.0-1008-raspi

this is becouse the *.elf and *.dat files?

Regards

That's usually caused by not having /etc/fstab mounting options correct.

When you start to boot from an SD card and then run the root filesystem from a USB drive, you must mount the micro SD card as /boot for kernel and firmware updates to be properly applied. When booting directly from USB you don't do that (and the first partition of the USB drive is mounted as /boot by default, assuming you cloned an SD card or wrote an image to the USB drive).

If you have run updates while switching from SD+USB boot and direct USB boot your boot partitions will be out of sync (one will have more recent versions of firmware and kernel), which is something you'll need to correct. From what you have posted, it looks like your /boot SD card needs to be updated.

JMicron USB-SATA bridge chips are notorious for not properly supporting UAS in Linux. You can disable UAS with USB quirks in the /boot/cmdline.txt file, and that may improve performance.

Add the following to the beginning of the line with a single space separation.
usb-storage.quirks=152d:0578:u

That should handle the most common JMicron controllers, but double-check yours by comparing the output of lsusb and make sure the VID:PID match. Look for a line similar to this,

Code: Select all

Bus 00? Device 00?: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. ...

and make sure the two hex numbers after ID are the same as the quirks line I posted above.

If that doesn't help, you can try adjusting the USB_MSD_PWR_OFF_TIME= setting (default is 500ms), or set it to zero to disable it. That setting is part of the bootloader configuration, which you can see with the vcgencmd bootloader_config command. If you don't know how to update those settings, ask for additional help.

[Kendek]

From my window onto the world the Eluteng adapter cables are somewhat elusive to find...

If you can't find the Eluteng cable-style adapter, then just try to get a StarTech one instead, with ASM1153E or ASM1351 chipset. For example, I bought several from eBay.

[dickon]

Alright, thank you.
Question; why was this moved to "stable" when the high system load is present as a bug?

Because it isn't actually using any system resources. There's a kernel process stuck in 'D' state, which adds 1 to the load average, but doesn't consume any CPU time. Look at the %idle field in top.

[thatchunkylad198966]

Question; why was this moved to "stable" when the high system load is present as a bug?

First of all, I wouldn't call that a "high" system load.

And second, it's not a bug.

The system polls the SD card slot to see if you have inserted a card, so you can use the slot for additional storage or backups or creating recovery cards, etc. That polling uses some system resources.

If you don't want or need to use the SD card slot, you can disable the polling as already instructed.

Another option is to leave a non-bootable card in the slot. Most of my USB booted systems have a card in the slot that I use for backups.

[brainsys]

Another option is to leave a non-bootable card in the slot.

That's great I've at last found a use for my old ultra-slow 2GB cards!
I might need more ...

Seriously I am not sure about disabling the slot. IMHO you can never have too many booting options if the USB/connector misbehaves.

[thatchunkylad198966]

Question; why was this moved to "stable" when the high system load is present as a bug?

First of all, I wouldn't call that a "high" system load.

And second, it's not a bug.

The system polls the SD card slot to see if you have inserted a card, so you can use the slot for additional storage or backups or creating recovery cards, etc. That polling uses some system resources.

If you don't want or need to use the SD card slot, you can disable the polling as already instructed.

Another option is to leave a non-bootable card in the slot. Most of my USB booted systems have a card in the slot that I use for backups.

It's not a bug but affecting multiple users? are you high?
The whole point of using USB-BOOT is not to use an SDCARD...
The whole system felt sluggish, the mouse/keyboard was laggy but again, not a bug.

I'll stick with PINN and installing to a USB that way and /boot on the SDCARD. no problems with that.
It's setup the same way, same things installed. no high system-load and no lag. but as you said, it's not a bug..............

[dickon]

It's not a bug but affecting multiple users? are you high?

What system resources is it using?

You have a load average >0. That doesn't mean what you appear to think it means.

[thatchunkylad198966]

It's not a bug but affecting multiple users? are you high?

What system resources is it using?

You have a load average >0. That doesn't mean what you appear to think it means.

????

When using an SDCARD, I can idle at 0.00 load. when using USB-BOOT via the "stable" firmware, it's well over 1.00.........

[dickon]

It's not a bug but affecting multiple users? are you high?

What system resources is it using?

You have a load average >0. That doesn't mean what you appear to think it means.

????

When using an SDCARD, I can idle at 0.00 load. when using USB-BOOT via the "stable" firmware, it's well over 1.00.........

Yes. It is *entirely* possible to have a load average of several hundred, yet the machine be actually idling. The load average is quite probably not what you think is it. On my machines with this issue, I've noted that the load average is ~1.00 on an otherwise-idle machine, because there's a kernel thread stuck in 'D' state. 'D' is 'runnable but not running', which usually means 'blocked on IO', which adds 1 to the load average for the time it is blocked, which artificially inflates the number.

So, I ask again: what resources is it *actually* using?

I agree it's annoying, and on the 5.4.50 kernel I'm not seeing the error, but there we go.

[HawaiianPi]

The whole system felt sluggish, the mouse/keyboard was laggy but again, not a bug.

Then you have a different problem. I do not have any lag or sluggishness when the card slot is being polled.

Whatever you've got going on is something else. Probably UAS issues with the USB drive or adapter you are using, or perhaps the USB 3.0 2.4GHz interference problem (is your mouse/keyboard wireless).