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

[jfabernathy]

My question is about what happens moving forward with the new bootloader. I have both my RPi4 4GB updated with the 2020-6-15 boot loader.

What would be the correct process to create a bootable USB storage device. My guest that it still requires some special work until the image that the Raspberry Imager creates has been update with the right files.

What I do now is create the fresh microSD with Imager and boot that first, do the full-upgrade, etc. Then at that point I can use the SD Card Copier to copier the microSD image to the USB storage device.

Is there anything else that the new USB image needs. It will boot, but is there a chance that at some point in the future doing an apt upgrade will rewrite the eeprom with an image that not boot the USB device?

In other works do I need to turn off the automatic update of the eeprom on every image I create?

[RonR]

Is there anything else that the new USB image needs. It will boot, but is there a chance that at some point in the future doing an apt upgrade will rewrite the eeprom with an image that not boot the USB device?

In other works do I need to turn off the automatic update of the eeprom on every image I create?

apt upgrade updates the rpi-eeprom-update program and the library of eeprom image files, but it doesn't do any writing of your Raspberry Pi eeprom.

You must manually initiate the actual eeprom update with one of two commands (followed by a reboot):

Automatically update to the latest version (as selected by the FIRMWARE_RELEASE_STATUS value in the /etc/default/rpi-eeprom-update file):

Code: Select all

sudo rpi-eeprom-update -a

or

Update to a specific eeprom file:

Code: Select all

sudo rpi-eeprom-update -f /pathto/eeprom-image-file-name

[HawaiianPi]

So I bought a new SanDisk 256GB Extreme PRO USB 3.1 Solid State Flash Drive - SDCZ880-256G-G46

That's a pricey flash drive! I don't know what you paid for it, but on Amazon.com and shop.westerndigital.com it's over $60. For less money one could get a Crucial MX500 250GB SSD ($49.99) and Eluteng USB 3.0 to SATA-III adapter cable ($7.99), which I know works with both UAS and TRIM, and will perform better and last longer.

Of course the SanDisk USB drive is smaller, if that's important to you.

What does the Raspberry Pi Diagnostics utility say about that SanDisk USB drive (Menu > Accessories)?

Have you created a UDEV rule and tested TRIM?

[jfabernathy]

So I bought a new SanDisk 256GB Extreme PRO USB 3.1 Solid State Flash Drive - SDCZ880-256G-G46

That's a pricey flash drive! I don't know what you paid for it, but on Amazon.com and shop.westerndigital.com it's over $60. For less money one could get a Crucial MX500 250GB SSD ($49.99) and Eluteng USB 3.0 to SATA-III adapter cable ($7.99), which I know works with both UAS and TRIM, and will perform better and last longer.

Of course the SanDisk USB drive is smaller, if that's important to you.

What does the Raspberry Pi Diagnostics utility say about that SanDisk USB drive (Menu > Accessories)?

Have you created a UDEV rule and tested TRIM?

I ran Raspberry Pi Diagnostics on the new USB flash drive and it's fast. Funny thing is none of my recommended microSD card pass the random write test.
I had a Startech usb3-SATA3 adapter with a 1TB Samsung SSD but the adapter died recently and a new Eluteng should arrive today. I'll look at your Crucial solution in the future.
Can you explain more about your UDEV rule and TRIM question? I have setup "Quirks" in the boot cmdline on real SSDs.

[HawaiianPi]

Can you explain more about your UDEV rule and TRIM question? I have setup "Quirks" in the boot cmdline on real SSDs.

Creating a UDEV rule is similar to adding quirks. You identify the controller and create a rules file in /etc/udev/rules.d
Note that adding quirks disables UAS, and that disables TRIM, so it won't work with drives that need quirks.

$ lsusb
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1153E SATA 6Gb/s bridge ...
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
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

Since my Eluteng adapters use ASMedia controller chips, we'll call our file 01-asmedia-trim.rules (name can be whatever-you-want.rules).

Code: Select all

sudo nano /etc/udev/rules.d/01-asmedia-trim.rules

ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

Insert your own device's vendor and product ID and save the file.

To see if it's working, issue a manual fstrim command for the drive's mount point. For the OS drive that would normally be

Code: Select all

sudo fstrim -v /

which should return the amount of bytes trimmed.

Note that any controller you have added quirks for will return an error, because disabling UAS also disables TRIM. Also, some known problematic controllers may be UAS blacklisted in Linux by default.

And finally, some controllers may need a firmware update to support trim (that's the controller's firmware, not the Pi's). For example, the older Eluteng adapter cable with a black SATA connector (newer Eluteng with blue connector works out of the box).

[jfabernathy]

I think the Startech adapter is also ASMedia. My new adapter is the same as you listed. I didn't do a lot of research when I read about the Quirks.
https://jamesachambers.com/raspberry-pi ... sh-drives/ My performance was not bad, but got better with Quirks added to cmdline.

So does putting in the UDEV rule give me the Quirk like performance without disabling TRIM?

[HawaiianPi]

So does putting in the UDEV rule give me the Quirk like performance without disabling TRIM?

No. Quirks disable UAS, which reduces performance, but drives that don't properly support UAS can be very slow in responding to commands, so they actually perform better without it (using mass storage protocol instead). However, without UAS you don't get TRIM.

So what you really want is a drive that properly supports UAS. And "drive" in this case can either mean an OEM USB drive (like your SanDisk Extreme PRO), or a USB adapter or enclosure with a SATA/NVMe/AHCI drive. One advantage of going with a SATA drive and USB adapter is that replacing or updating the adapter will often resolve problems, and is often less expensive than replacing the entire drive.

[jfabernathy]

So using your udev rules file for my Eluteng adapter. I'm getting good performance and TRIM works with my Samsung 1TB QVO SSD

Category Test Result
HDParm Disk Read 282.26 MB/s
HDParm Cached Disk Read 222.17 MB/s
DD Disk Write 193 MB/s
FIO 4k random read 22882 IOPS (91530 KB/s)
FIO 4k random write 8733 IOPS (34933 KB/s)
IOZone 4k read 29835 KB/s
IOZone 4k write 26884 KB/s
IOZone 4k random read 18115 KB/s
IOZone 4k random write 31687 KB/s

[BRX7]

I'm still getting issues with warm reboots, maybe 1 out of 4 reboots fails,
here is my bootconfig

[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
USB_MSD_PWR_OFF_TIME=0
BOOT_ORDER=0xf41


Should I tweak the PWR off time?
Im using a startech 3.1 USB TO SATA asmedia 1153

[njheb]

I have a data point for usb3/ssd interfaces. The "UGREEN USB 3.0 to 3.5-Inch SATA External Drive Enclosure" causes too much electrical interference for my wifi to associate reliably on an 8GB 4B Pi at USB3 speed. Its fine at USB2. From my notes, lsusb report details VID=174c:PID=55aa, ASM1051E/ASM1053E/ASM1153.

Boots fine with 2020-06-15 stable firmware. Trims OK with udev rule on a crucial-BX500 120GB. So workable with ethernet only. Another downside with the enclosure is that the power button is very sensitive there is no hold for n seconds for power off. I caught it by accident while trying various positions for the enclosure relative to the pi to try and over come EM interference.

Edit follows:The problem is not with the UGREEN enclosure. The Pi was housed in an Aluminium Heatsink Case. The USB3 interference interacting with the case was causing the wifi problems. So there is nothing intrinsically wrong with the pi wifi and usb3 with my set up.

I moved back to a boot and root partition on a uSD to have the ability to
power up or eject and power off the enclosure. The wifi links described as struggling below could only be associated with the enclosure powered off when the pi was mounted in the case.

A lot of permutations of adapters and a-to-b cables and usb3 top or bottom connector slots were tried before the case was finally removed.

Chan 1 and Chan 4 tested at 2.4GHz with case fitted and showed no difference.

NB I have no access to a 5Ghz link for testing.

For me boiling down the test results:
a)The wifi was jammed with the enclosure on the bottom usb3 connector and wifi struggled when on the top usb3 connector.
b)the reverse is true for an iitrust adapter it jammed wifi on the top usb3 connector and wifi would struggle when the iitrust was connected on the bottom usb3.
c)An eluteng adapter jammed wifi on both usb3 connectors.

Of the adapters I own the iitrust has a thicker cable diameter so presumably has more shielding than the eluteng.

It seems distorting the wifi field by holding a hand near the case would improve matters a little on the struggling link replicates.

So it would be interesting to see how many people with a metal heatsink case have had a similar problem to mine. And how much usb3 noise it can put onto the board if that is what is going on?

My Aluminium case was a "PIMORONI Heatsink Case". YMMV

Edit 2:
Yesterday, 2020 july 06, I emailed my findings in the above edit to pimoroni. And today in a test I found that by removing the bottom heatsink layer from the equation it was possible to boot from msd on usb3 and have wifi associate. Once up the 2.4GHz link was much improved without the bottom plate in place. Also a HDD arrived in the post so I tried that out in place of the plastic cased SSD (in case it was any better shielded) and again that would not associate with wifi when booting from msd on usb3 when the pi is "sandwiched" between the Aluminium layers, but would associate when the bottom layer is removed. NB this is on an 8GB PI4, A4 paper was used for insulation when the deconstructed case layers were being tested.

Edit 3:
I got a prompt reply from pimoroni (first thing july 8th) saying that they would possibly be reviewing the case design because I was not the first to provide feedback about this issue.

[timg236]

I'm still getting issues with warm reboots, maybe 1 out of 4 reboots fails,
here is my bootconfig

[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
USB_MSD_PWR_OFF_TIME=0
BOOT_ORDER=0xf41


Should I tweak the PWR off time?
Im using a startech 3.1 USB TO SATA asmedia 1153

It might be worth removing the USB_MSD_PWR_OFF_TIME line to see if that makes any difference. Although, it's not clear from your post at which point boot fails.

[jfabernathy]

Can you explain more about your UDEV rule and TRIM question? I have setup "Quirks" in the boot cmdline on real SSDs.

Creating a UDEV rule is similar to adding quirks. You identify the controller and create a rules file in /etc/udev/rules.d
Note that adding quirks disables UAS, and that disables TRIM, so it won't work with drives that need quirks.
Since my Eluteng adapters use ASMedia controller chips, we'll call our file 01-asmedia-trim.rules (name can be whatever-you-want.rules).

Code: Select all

sudo nano /etc/udev/rules.d/01-asmedia-trim.rules

ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

To see if it's working, issue a manual fstrim command for the drive's mount point. For the OS drive that would normally be

Code: Select all

sudo fstrim -v /

which should return the amount of bytes trimmed.

I found that Raspbian and hopefully the new Raspberry OS (32bit) support TRIM via the mounting of the SSD in fstab using the "discard" option. I wonder if that works and precluded the need for manually running the fstrim command periodically?

[BRX7]

I'm still getting issues with warm reboots, maybe 1 out of 4 reboots fails,
here is my bootconfig

[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
USB_MSD_PWR_OFF_TIME=0
BOOT_ORDER=0xf41


Should I tweak the PWR off time?
Im using a startech 3.1 USB TO SATA asmedia 1153

It might be worth removing the USB_MSD_PWR_OFF_TIME line to see if that makes any difference. Although, it's not clear from your post at which point boot fails.

I was having less success without that option, sometimes it occurs after the rainbow (black scree) sometimes at the eeprom message screen. I tried with and without PINN. I am using an Integral 128GB SSD, and startech USB312SAT3CB

[cormack]

I found that Raspbian and hopefully the new Raspberry OS (32bit) support TRIM via the mounting of the SSD in fstab using the "discard" option. I wonder if that works and precluded the need for manually running the fstrim command periodically?

You can avoid putting the "discard" option in fstab, AND avoid having to periodically run fstrim by hand, by activating the fstrim.timer with systemctl...

Code: Select all

sudo systemctl enable fstrim.timer

This will schedule an automated fstrim once a week (on Sundays, if memory serves.)

[Korsair]

Just updated from 5/27 beta to 6/15 beta. System did not boot like others have reported (headerless setup) plugged in hdmi and keyboard and mouse pi booted ok, but with USB timeouts and needing multiple retries. No sdcard. The 5/28 beta seemed more stable for my setup. 6/!5 appears to need some timing adjustments.

[paulwratt]

put a blank (non-boot) sd-card in the slot, should fix boot up time

@jfabernathy some of those timings you posted are strange, but still overall much better than USB2

[timg236]

I'm still getting issues with warm reboots, maybe 1 out of 4 reboots fails,
here is my bootconfig

[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
USB_MSD_PWR_OFF_TIME=0
BOOT_ORDER=0xf41


Should I tweak the PWR off time?
Im using a startech 3.1 USB TO SATA asmedia 1153

It might be worth removing the USB_MSD_PWR_OFF_TIME line to see if that makes any difference. Although, it's not clear from your post at which point boot fails.

I was having less success without that option, sometimes it occurs after the rainbow (black scree) sometimes at the eeprom message screen. I tried with and without PINN. I am using an Integral 128GB SSD, and startech USB312SAT3CB

The power-off time should only alter whether or not the USB port detects the device as connected. It might be worth disabling UAS in Linux in-case it is failing there viewtopic.php?t=245931

[tyjtyj]

After updating the firmware, now my pi4 boot from USB SSD but i am getting this error from dmesg every 5 sec. Any idea cause this or how to fix this ?

My PI4 SSD has come from PI3B usb boot. update to the latest

[Tue Jun 23 17:46:45 2020] mmc0: Timeout waiting for hardware cmd interrupt.
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Present: 0x1fff0001 | Host ctl: 0x00000001
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Cmd: 0x0000371a | Max curr: 0x00080008
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: Host ctl2: 0x00000000
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
[Tue Jun 23 17:46:45 2020] mmc0: sdhci: ============================================

[Kendek]

The power-off time should only alter whether or not the USB port detects the device as connected. It might be worth disabling UAS in Linux in-case it is failing there viewtopic.php?t=245931

The USB312SAT3CB is ASM1351, and the USB3S2SAT3CB is ASM1153E. I have been actively using both of these cables with Pi4 for almost a year now. In my experience, UAS and UNMAP are working fine, and all reboots are successful, with and without USB_MSD_PWR_OFF_TIME=0.

[no3rpi]

Kendek from you experience what firmware do you recommend for ASM1153E with UNMAP/TRIM support:
140509_A1_82_40 or 141126_A1_EE_82 or maybe another if it is available ?
thank you

[Kendek]

Kendek from you experience what firmware recommend for ASM1153E with UNMAP/TRIM support:
140509_A1_82_40 or 141126_A1_EE_82 or maybe another if it is available ?
thank you

Both of these firmware versions are good and stable, but I'm using the first one.

[Desnee]

Kendek from you experience what firmware do you recommend for ASM1153E with UNMAP/TRIM support:
140509_A1_82_40 or 141126_A1_EE_82 or maybe another if it is available ?
thank you

So USB312SAT3CB works with RPI4B? I tried booting LibreELEC on an RPI3B+ using that adapter and it did not work.

[Kendek]

So USB312SAT3CB works with RPI4B? I tried booting LibreELEC on an RPI3B+ using that adapter and it did not work.

Yes, this is one of the most recommended adapters. But I think the ASM1153E is more popular because of its price.

[Desnee]

So USB312SAT3CB works with RPI4B? I tried booting LibreELEC on an RPI3B+ using that adapter and it did not work.

Yes, this is one of the most recommended adapters. But I think the ASM1153E is more popular because of its price.

So let me get this straight: USB312SAT3CB is compatible with RPI4B but is NOT compatible with RPI3B+?

As I said, I tried to boot LibreELEC on the RPI3B+, it did the initial resizing of a partition task when booting the first time. I got to the part where it count down from 15 and then attempted to restart. And then nothing, just an empty black screen. I could not get it to boot. Why is this?

I can use an SSD as a secondary storage drive with this adapter with the RPI3B+ and other computers but I haven't been able to boot anything with this. Now that I think about it, I tried to boot 64-bit Ubuntu on my desktop computer with it once and failed.

[Kendek]

So let me get this straight: USB312SAT3CB is compatible with RPI4B but is NOT compatible with RPI3B+?

As I said, I tried to boot LibreELEC on the RPI3B+, it did the initial resizing of a partition task when booting the first time. I got to the part where it count down from 15 and then attempted to restart. And then nothing, just an empty black screen. I could not get it to boot. Why is this?

I can use the aforementioned adapter as a storage drive medium but I haven't been able to boot anything from. Now that I think, I tried to boot Ubuntu 64-bit on my desktop computer once and it failed.

I don't have any experience with the RPI3B+, but the USB on the Pi4 is 3.0, and provided by an external chip (VIA VL805).