LinuxQuestions.org - Boot Raspberry Pi 4 from USB storage device

- Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)

- - Boot Raspberry Pi 4 from USB storage device (https://www.linuxquestions.org/questions/slackware-arm-108/boot-raspberry-pi-4-from-usb-storage-device-4175682591/)

Boot Raspberry Pi 4 from USB storage device

It might be 3 weeks after the event, but I've only today found out that booting the RPi4 from a USB storage device is now very possible. This is great news for me.

The Raspberry Pi 4 eeprom needs re-programming, which is a very simple process. Just download the latest bootcode update - write the contents to a microSD card - boot the RPi4 with it - wait until the green LED flashes on/off rapidly and constantly - power off.

Raspberry Pi 4 EEPROM latest update 03 September 2020: https://github.com/raspberrypi/rpi-e...20.09.03-138a1

I've tested with a 16GB USB stick running the Slackware ARM installer and it works like a charm. Next I'll be connecting a SSD and playing around with that. I know from previous experience that compiling on a USB3 connected SSD is ~10-25% quicker than using my fastest microSD cards on the RPi4.

Me too.

I recently lost my original sdcard. I loaded a replacement, updated to the latest eeprom, and shoved the sdcard into one of those sdcard --> usb adapters. It just goes. ssds <500G are thin on the ground here, and I don't want to import if I can avoid it. England is still in the EU, and duty, and VAT are coming soon to Ireland. Just need to watch that.

I 'converted' my RPi4 a few months back with the beta.
(Detailed on here somewhere.)

I can now boot from pendrive (slowly), SSD, & best of all, HDD - so I can use my old spinners on it, & they are almost as fast as an SSD, on a USB3 connection.

It's just a shame it took them so long, (13 months plus), to give us what should have been working at time of release.

I swore that I wouldn't buy another until it booted from USB3, so now I just might get another one. ;)

Not strictly on USB boot, but I have a question somewaht related.
I have done the eeprom upgrade yesterday and went fine.

I've alse renamed the "recovery.bin" to RECOVERY.000" as suggested in several pages on the net.
After the upgrade, at boot now I have a page in huge char stating eeprom version like this one in attach
but the boot proceed and everything is fine.

Is that normal or I do need to do other stuffs ?

Pigi.

P.s. th image is not mine but mine is very similar.

Quote:

Originally Posted by Pigi_102 (Post 6169161)

Is that normal or I do need to do other stuffs ?

That's very similar to how my screen looks too. I'd say that was normal. Or at least expected.

Quote:

Originally Posted by fatmac (Post 6169107)

It's just a shame it took them so long, (13 months plus), to give us what should have been working at time of release.

I swore that I wouldn't buy another until it booted from USB3, so now I just might get another one. ;)

I've been waiting for this a long time too. It's long overdue in my opinion.

I had serious issues booting from USB3 SSD because the adapter I'm using happens to be on the naughty-list of "USB3-SATAIII adapters with known issues". That's putting it mildly...

Code:

root@torq:~# lsusb

Bus 002 Device 002: ID 2109:0711 VIA Labs, Inc. VLI Product String

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

My USB3-SATAIII adapter is the first device on the list - ID 2109:0711

Anyway, I like a challenge and after a few hours of fudging around, trial and error fashion, and much jiggery-pokery with Slackware ARM current...

Taa-dah! Working like a BOSS. Gotta love Slackware! <3 :thumbsup: :D :D :D

Here's my 'fdisk -l' output:

Code:

root@torq:~# fdisk -l

Disk /dev/sda: 447.13 GiB, 480103979008 bytes, 937703084 sectors

Disk model: high speed

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x35804286



Device    Boot  Start      End  Sectors  Size Id Type

/dev/sda1  *      2048    329727    327680  160M  b W95 FAT32

/dev/sda2        329728  2426879  2097152    1G 82 Linux swap

/dev/sda3      2426880 937703083 935276204  446G 83 Linux

Here's my 'blkid' output:

Code:

root@torq:~# blkid

/dev/sda1: SEC_TYPE="msdos" UUID="46F9-9AA7" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="35804286-01"

/dev/sda2: UUID="ecd0a6a8-601e-4734-8893-f49b84e711dd" TYPE="swap" PARTUUID="35804286-02"

/dev/sda3: UUID="3b767c37-98e2-4358-b12e-998824d5f2f2" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="35804286-03"

Here's my '/boot/cmdline.txt' file:

Code:

usb-storage.quirks=2109:0711:u dwc_otg.lpm_enable=0 console=tty1 nofont root=PARTUUID=35804286-03 rootfstype=ext4 rootwait ro

My '/etc/fstab' file:

Code:

/dev/sda2        swap            swap        defaults        0  0

UUID=3b767c37-98e2-4358-b12e-998824d5f2f2        /                ext4        defaults        1  1

UUID=46F9-9AA7  /boot            vfat        fmask=177,dmask=077 1  0

#/dev/cdrom      /mnt/cdrom      auto        noauto,owner,ro,comment=x-gvfs-show 0  0

/dev/fd0        /mnt/floppy      auto        noauto,owner    0  0

devpts          /dev/pts        devpts      gid=5,mode=620  0  0

proc            /proc            proc        defaults        0  0

tmpfs            /dev/shm        tmpfs      nosuid,nodev,noexec 0  0

If anybody reading this is having issues getting their Slackware OS to boot from USB-SSD on a RPi4 - and they're pretty sure everything is present and correct and it should be booting - investigate the USB3 adapter you're using for any known issues, and make sure your /boot partition type is set to: 0b [W95 FAT32]. It might save you a few headaches! :D :cool:

I'm curious ... haven't used an R'Pi in a long time. Do they still have to boot from a W95 Fat32 partition?

Quote:

Originally Posted by justwantin (Post 6169335)

I'm curious ... haven't used an R'Pi in a long time. Do they still have to boot from a W95 Fat32 partition?

Yes. Although it'll boot from FAT16 or exFAT type partitions as well. Or has in the past.

Booting a Raspberry Pi 4 from USB3 SSD has certainly revealed a few things. The problems I have had is with my two USB3-SATA III adapters which are not supported by Raspberry Pi 4 firmware. However, I managed to find a USB3 HDD/SSD enclosure that worked without any problems at all. So I was able to do a few test runs and compare results.

Code:

usb-storage.quirks=2109:0711:u

The above setting in the /boot/cmdline.txt file is a "stop-gap/work-around" for a USB storage device that's not 100% compatible with the RPi4. It should only be used with the knowledge that UAS (USB scuzzy) drivers will blacklist the specified device and force the use of generic usb_storage drivers instead - and the USB3 storage device then operates much slower as a consequence!

On a Raspberry Pi 4, using the latest [pre-compiled] SARPi4 build as a reference, here are my build times using different storage solutions:

• Kingston SDCA3/64GB [90R/80W] microSD card: 41 mins 37 secs

• Unbranded USB3-SATA III adapter with Kingston SSDNow V300 480GB SSD (using usb-storage.quirks): 1 hour 7 mins 12 secs

• Unbranded USB3-SATA HDD/SSD enclosure with Kingston SSDNow V300 480GB SSD (using UAS drivers): 39 mins 44 secs

The above was carried out using the same scripts with the same processes involved on the same device, only on different storage mediums. Incidentally, if I use a SD card for a /boot partition and mount / and /swap on the SSD - I can further reduce that last build time.

The lesson here for me is that 'usb-storage.quirks' should only be used when all other alternatives are unavailable. There are always other options. From investigations on Google and reading what other users have reported, the Startech USB3S2SAT3CB USB3-SATA III adapter is one of the most reliable and trouble-free. Think I'm going to save myself some angst and buy one.

Quote:

Originally Posted by Exaga (Post 6169438)

From investigations on Google and reading what other users have reported, the Startech USB3S2SAT3CB USB3-SATA III adapter is one of the most reliable and trouble-free. Think I'm going to save myself some angst and buy one.

Startech USB3S2SAT3CB USB3-SATA III adapter arrived today. I have verified that the reports on Google, about this adapter being 100% compatible with the RPi4 firmware, are telling the truth. After using it for 2-3 hours with a SSD there's been no problems at all running it with the UAS drivers. Anybody who's thinking of using a USB3 SSD to boot or as a storage device on the RPi4 should get one of these if they're buying for the first time or their existing adapter is giving them problems. :thumbsup:

Hello Exaga,
what kind of trouble did you get with the "unknown" SATA-USB3 adapter ?

I'm having issue in trying to boot from my SSD, but can't really find wht the problem is.
In my case I get the infamous "unable to mount" root at boot, but can't really find the cause.

I can't really understand what's going on, as the first part of boot works, and then it goes in kernel panic.
The exact same kernel works when booting from an usb pen.

Is there a way to log those messages from boot ?

Forget my previous message :)
I've managed to fix the "unable to mount root" problem.
It was my fault, I didn't change the "root=" option in /boot/cmdline.txt

So I'm reporting that, at least for booting, the "JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge" works for usb booting.
lsusb gives:
Bus 002 Device 003: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

Not sure about performances, though.

Pigi

Quote:

Originally Posted by Pigi_102 (Post 6172169)

Hello Exaga,
what kind of trouble did you get with the "unknown" SATA-USB3 adapter ?

The unbranded USB3-SATA III adapter was mostly slow to transfer and it was even taking forever to quick-format the root partition in 'setup'. I did a test scping the boot partition files from a remote system to and from the RPi SSD and it took just over 20 minutes to transfer approx. 160MiB data. So, something very screwy indeed going on there.

Quote:

Originally Posted by Pigi_102 (Post 6172169)

Is there a way to log those messages from boot ?

I forget who gave me this idea but use your smart phone to make a video while the system is booting. Then you can review it very easily. Otherwise, connect via serial TTL and log every thing from the terminal.

Quote:

Originally Posted by Pigi_102 (Post 6172175)

I don't know if this will benefit you, but I always use persistent drive naming in the /boot/cmdline.txt and /etc/fstab. I use PART-UUID in /boot/cmdline.txt for the root partition and then UUID in /etc/fstab for the root and /boot. I plug in a load of USB sticks/storage drives/devices all the time and I need my RPi storage devices to remain the same throughout. That's my reason for doing this.

Good to know the 152d:0567 JMicron controller works OK. I'm sure there's plenty of LQ users and others on the Internet with the same adapter as yours. The Startech adapter that I bought is impressing me. It's faster than any of my SD cards or other adapters. We're not talking by great significant amounts but it shaves a few minutes off a ~45 minute compile job and that seems to be exponential thus far.

I just tried to boot from an SSD connected with JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge -- seemingly the same device that Exaga (and some others) found to work. Mine did not work (the same SSD boots ok with another bridge - thus the SSD is ok).
Eventually I found with lsusb that the device ID is different. Mine (brand new Jan. 2021) has ID 152d:0578 which does not work, but the ID 152d:0567 is reported to work.
Unfortunate!

Quote:

Originally Posted by justwantin (Post 6169335)

I'm curious ... haven't used an R'Pi in a long time. Do they still have to boot from a W95 Fat32 partition?

Like the majority of the machines on the planet, well every computer that uses efi boot for boot. The specification calls for a tiny partition at the start of the drive formatted Fat 32.