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

[Araforn]

However what Im seeing as strange is that the Kingston M.2 and adaptor only boots when connected to the usb 2.0 ports!.

Of course this negates the benefit of USB booting entirely. Can anyone help me with this or perhaps indicate why it would boot only on USB2.0?.

What does lsusb return with that enclosure connected?

That enclosure uses a JMicron USB-SATA bridge chip, and those are somewhat notorious for not properly supporting UAS in Linux. Assuming the output of lsusb indicates a vendor ID of 152d and device ID of 0578, then adding usb-storage.quirks=152d:0578:u to the beginning of the line in /boot/cmdline.txt (with a single space delimiter) should get you up and running from USB 3.0.

In theory, UAS can deliver up to 20% faster performance over USB 3.0, but in real life practical use it's probably less, and might not even be noticeable. However, disabling UAS will also disable TRIM, and that will definitely affect performance with time and use.

I would normally suggest the Eluteng adapter cable, but since you are using an M.2 drive that won't help you. Look for another enclosure with an ASMedia ASM1153E controller, and hope that it doesn't need a firmware update (some do, while others work out of the box, which is preferable, since firmware updates can be hard to find).

It's too bad you didn't get the 2.5" version of that SSD (less expensive, and you could use the Eluteng adapter cable).

Thanks a lot for your reply.

Heres what lsusb reports.

Bus 002 Device 002: ID ab12:34cd
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 045e:075d Microsoft Corp. LifeCam Cinema
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The product ID is ab12 and vendor ID is 34cd.

Alas the quirks does not work on this adaptor so i cant use this with USB3.0 booting.

A warning for others.

Thanks again.

[lohriialo]

I've updated to the latest firmware but usb boot not working

Board: rpi4 4GB
OS: Raspberry Pi OS

Code: Select all

sudo apt update
sudo apt full-upgrade

Code: Select all

vcgencmd bootloader_version

Jun 15 2020 14:36:19
Version c302d.........d781 (release)

Code: Select all

vcgencmd bootloader_config

BOOT_ORDER=0xf41

Scenario :
sdcard boot just fine
usb boot not working (took out the sdcard, inserted into a USB micro sd card reader, tried too boot from both USB 2.0 and 3.0 port)

Result : https://www.dropbox.com/s/xcsm2klq9knmv ... 1.jpg?dl=0

Any pointers is appreciated!

[hippy]

Result : https://www.dropbox.com/s/xcsm2klq9knmv ... 1.jpg?dl=0

Looks to me like the Boot Eeprom has done its job, found the SD Card in the USB reader, has tried to boot from it and then it fails. No idea why. Doing the same works for me.

[dickon]

That sort of thing is usually because it can't mount / for whatever reason. What's the contents of /boot/cmdline.txt ?

[itsmedoofer]

Hi,

Hi,

I have a ELUTENG clear USB caddy, ID 2537:1068, no issues with booting from it with any of the beta firmware released so far, it works fine and it is stable. However be aware that it appears to be blacklisted by default and may not be suitable for SSD usage due to the lack of TRIM...

That being said I have been using it since the launch of the Pi4 without issue, is TRIM such a big deal ?

I've just ordered the ELUTENG cable recommended previously so will give that a go, however a caddy solution would be much preferable...

That uses the Norelsys 1068X chip, and yes, they are UAS blacklisted in Linux by default.

TRIM is a big deal with SDD (not needed for HDD). Without periodic trimming the SSD will get slower over time with continued use. TRIM also reduces write amplification, which can affect the lifespan of the SSD.

You should be able to find an enclosure (caddy) with an ASMedia controller, but advertised specifications don't always include that information (and it still might need a firmware update).

2.5 inch SSD models are already in a caddy of sorts, since they are really just little circuit boards inside of a 2.5 inch drive compatible case, so adding yet another case outside of that is not really needed.

Well the much fabled ELUTENG cable came this morning, all up and running with TRIM now, as the Pi is static on the desk I don't think I'm going to miss a caddy, I've stuck some rubber feet on the bottom of the HDD and it's as just as good really ! Thanks for the recommend !

Some bench marking with gnome-disks confirmed your comments on speed, post trim the average speeds a little better, but significantly more consistent, if I can work out how to do it I will share my graphs later.

I also took a punt on one of these https://www.amazon.co.uk/Inateck-Drive- ... ing&sr=8-4. It has the same chipset as the ELUTENG cable and you can enable trim. HOWEVER is has a "Green Feature" you have to turn it on before it can be read, a physical press of a button, it will also power down after 30 mins and require another physical press of a button to wake it up, making all but useless for our application here...

[lohriialo]

That sort of thing is usually because it can't mount / for whatever reason. What's the contents of /boot/cmdline.txt ?

This is what I have in my cmdline.txt

dwc_otg.fiq_fix_enable=1 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait ro rootflags=noload panic=10 quiet loglevel=1

console=serial0,115200 console=tty1 root=PARTUUID=335c5a55-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

[dickon]

Code: Select all

root=/dev/mmcblk0p2

Well, then.

[lohriialo]

Code: Select all

root=/dev/mmcblk0p2

Well, then.

Sorry for the confusion, cmdline.txt i posted earlier was from a different sdcard I have another OS on.

This is what I have in my cmdline.txt with an sdcard that won't boot via a USB sdcard reader

console=serial0,115200 console=tty1 root=PARTUUID=335c5a55-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

[dickon]

OK. So you now need to capture the console output, ideally via the serial port. If you can't do that, remove 'quiet', and add 'nosmp' (to reduce the clutter of a backtrace per core) and try again.

[lohriialo]

OK. So you now need to capture the console output, ideally via the serial port. If you can't do that, remove 'quiet', and add 'nosmp' (to reduce the clutter of a backtrace per core) and try again.

Here's the new log
https://www.dropbox.com/s/ipx984us2l9te ... 1.jpg?dl=0

[dickon]

Unusual. You'll need to see why init is dying; have a look for a logfile somewhere.

[lohriialo]

Unusual. You'll need to see why init is dying; have a look for a logfile somewhere.

Ya not sure what's going on...

USB card reader is absolutely fine, I can plug it into a Mac/Linux and it reads just fine, in fact that's how I flash pi OS onto it. As soon as I take the sdcard out and place it in the sdcard slot of the Pi, it boots right up

I'll have to do some more digging... thanks for your help

[davefi]

Hi all, so I believe I have done everything correctly as I am booting my Pi4 8GB from my SSD without any SD card installed. My adaptor cable is an Inatek, and lsusb reports it to be:

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

I have added the udev rule to enable trim:

Code: Select all

# ASMedia ASM1153E controller (Eluteng adapters)
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

After a reboot, if I run the fstrim command, I get the following error:

Code: Select all

sudo fstrim -v /
fstrim: /: FITRIM ioctl failed: Remote I/O error

I'm all quite new to this, so unsure if I have made a mistake somewhere, or if the adaptor(?) does not support trim. Happy to review/share any logs if anyone can share any pointers as to what to check for? e.g. is there a way to confirm the udev rules were applied correctly?

Adaptor: https://www.amazon.co.uk/gp/product/B01ESQZG6Y/
SSD: https://www.amazon.co.uk/gp/product/B07G3KRZBX/

[PiUser10]

Did you put the file containing this line in /etc/udev/rules.d/ and does the filename end with .rules ?
I found out the hard way that if I did not name the udev file with .rules on the end it did not work.
My file is called 01-unmap.rules

[davefi]

Yep, all present and correct as far as I can tell:

Code: Select all

$ ls /etc/udev/rules.d
total 16
4 drwxr-xr-x 2 root root 4096 Jul  2 14:35 ./
4 drwxr-xr-x 4 root root 4096 May 27 08:09 ../
4 -rw-r--r-- 1 root root  178 Jul  2 14:35 01-unmap-trim.rules
4 -rw-r--r-- 1 root root 1367 May 14 06:13 99-com.rules

[Kendek]

Yep, all present and correct as far as I can tell:

Then the ASM chip or its current firmware is not UNMAP compatible.

[HawaiianPi]

I'm all quite new to this, so unsure if I have made a mistake somewhere, or if the adaptor(?) does not support trim

I have several ASMedia based adapters, and some of them required firmware updates. Unfortunately those can be hard to locate.

The current model Eluteng adapter cable (blue SATA connector) that has been recommended numerous times on this forum works out of the box with UAS and TRIM. The old model (black SATA connector) required a firmware update, and so did a couple of others I own. I could not find anything about firmware updates on ASMedia's site, and writing to the company got no reply.

The first place to check would be with the maker of your USB adapter (Inateck). Otherwise you'll have to locate compatible firmware.

I found firmware on Plugable Technologies site. They make many USB products, some of which using ASMedia bridge chips. The firmware was Plugable branded, so I needed edit the configuration file to correct that, but other than that it was pretty simple. I used the ASM1153E firmware, but I can't guarantee that will work for your adapter, because ASMedia uses the same VID:PID for several different bridge chips.

Note that flashing non-approved firmware will definitely void any warranty your Inateck adapter has, and if the firmware isn't compatible, it could "brick" the device. So do this at your own risk. I successfully flashed three of the four older adapters I had, and that got TRIM working for me (the 4th adapter is on a system with a hard drive, so I didn't bother flashing it).

[malchore]

I've updated to the latest firmware but usb boot not working

Board: rpi4 4GB
OS: Raspberry Pi OS

Code: Select all

sudo apt update
sudo apt full-upgrade

Code: Select all

vcgencmd bootloader_version

Jun 15 2020 14:36:19
Version c302d.........d781 (release)

Code: Select all

vcgencmd bootloader_config

BOOT_ORDER=0xf41

Scenario :
sdcard boot just fine
usb boot not working (took out the sdcard, inserted into a USB micro sd card reader, tried too boot from both USB 2.0 and 3.0 port)

Result : https://www.dropbox.com/s/xcsm2klq9knmv ... 1.jpg?dl=0

Any pointers is appreciated!

I had the exact same issue with my RPi4 4GB. I flashed the eeprom using the JUN-15-2020 stable version. My SD card worked just fine for booting, but my USB Flash drive would not boot. I flashed it using the Pi imager tool on the pi itself. I downloaded the Windows version of the Pi Imager tool and flashed the 32-bit OS and that too did not boot.

What DID work was flashing the 64-bit Raspberry OS to my flash drive. Weird. I want to use the 64-bit version anyways, but I have absolutely no idea why only the 64-bit OS works for USB MSD booting the OS and not 32-bit.

For fun and giggles I took my SD card and edited the cmdline.txt file on /boot. I pointed the root= line to my USB flash device (which for me is /dev/sda2.) I put the SD card back into my RPi. The bootloader_config shows BOOT_ORDER has the SD Card device as the first to boot, which it did.

This eventually lead to kernel panic errors and didn't work. Heh. I guess 32-bit bootloader can't bootstrap the 64-bit OS. Anyways - the only solution for me was to flash my USB thumb drive with the Raspberry PI OS 64-bit.

[davefi]

Thanks all, I'll see if I can find any firmware and contact Inatek. Unfortunately these are the only adaptors I have found that fit my WB 6x6 enclosures (I use loads of them).

[davefi]

Looks like I may have fixed the issue. Found a firmware and gave it a try and running trimcheck on Windows reports it looks like it is working:

Code: Select all

TRIM check v0.7 - Written by Vladimir Panteleev
https://github.com/CyberShadow/trimcheck

Loading continuation data from E:\trimcheck-cont.json...
  Drive path   :  \\.\E:
  Offset       :  60956672
  Random data  :  04 27 EA 33 3C 27 59 1F A7 0B 18 65 7C 9F 53 A4...

Reading raw volume data...
  Opening \\.\E:...
  Seeking to position 60956672...
  Reading 16384 bytes...
  First 16 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...
Data is empty (filled with 0x00 bytes).

CONCLUSION: TRIM appears to be WORKING!

I will try on the RP4 tomorrow. Thanks for the pointers & feedback @Kendek, @HawaiianPi & @PiUser10!

[LTolledo]

though still in 4th beta.....is there an updated official step-by-step procedure available somewhere?
please assume no prior EEPROM update was ever done.....

[HawaiianPi]

I had the exact same issue with my RPi4 4GB. I flashed the eeprom using the JUN-15-2020 stable version. My SD card worked just fine for booting, but my USB Flash drive would not boot. I flashed it using the Pi imager tool on the pi itself. I downloaded the Windows version of the Pi Imager tool and flashed the 32-bit OS and that too did not boot.

That's because the 32-bit image was created before USB boot was available for the Pi4, so it needs to be updated with sudo apt update && sudo apt full-upgrade -y, which is simplest to do from an SD card, which you can then clone to your USB drive and it should boot (assuming you have already correctly upgraded the bootloader).

What DID work was flashing the 64-bit Raspberry OS to my flash drive. Weird. I want to use the 64-bit version anyways, but I have absolutely no idea why only the 64-bit OS works for USB MSD booting the OS and not 32-bit.

Not so weird. The 64-bit OS is in beta, which means it's more current than the 32-bit image from May.

[RonR]

though still in 4th beta.....is there an updated official step-by-step procedure available somewhere?
please assume no prior EEPROM update was ever done.....

Not offical, but very simple...

Code: Select all

sudo apt update
sudo apt full-upgrade
sudo rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-06-15.bin
sudo reboot

After the reboot, rpi-eeprom-update should report:

BOOTLOADER: up-to-date
CURRENT: Mon 15 Jun 13:36:19 UTC 2020 (1592228179)

[LTolledo]

thank RonR!

this will make USB boot possible....correct?
will try it today.....

[RonR]

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

Yes.

You will need an updated RaspiOS. You may find this helpful: rpi-update-device