Korsair
Posts: 4
Joined: Sun May 24, 2020 11:46 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Sun May 24, 2020 11:51 pm

Just an FYI if you see three quick flashes of the Green LED when attempting to boot on the USB device (especially if it's sd card). I first tried using a Samsung USB adapter. The card sizes were 8GB, 16GB and 64GB. They all failed the USB boot. When I switched to a Sabrent USB adapter they all booted ok. So if you do fail it could be your adapter.

hippy
Posts: 7344
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Sun May 24, 2020 11:58 pm

Mention of tvservice earlier had me try this. Not sure where the 'vchi_msg_dequeue" came from or what it means the second time and seems to persist once it's appeared. Don't know if this is of relevance to USB booting but never had it before. Booting Raspbian Lite from USB stick.

Code: Select all

pi@raspberrypi:~ $ tvservice -s
state 0x1 [TV is off]
pi@raspberrypi:~ $ tvservice -s
vchi_msg_dequeue -> -1(90)                           <==== ?
state 0x1 [TV is off]
The "TV" (HDMI0) is on; it's showing the above 8-)

User avatar
HawaiianPi
Posts: 5657
Joined: Mon Apr 08, 2013 4:53 am
Location: Aloha, Oregon USA

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 5:26 am

jpinhal wrote:
Sun May 24, 2020 10:18 pm
...after doing the firmware update and rebooting, the mouse directly connected on USB2.0 has a bit of wierd behaviour where it stops moving and then moves again.
I'm going to guess that's a wireless mouse, and it's the dongle you're connecting to USB 2.0. I'll also predict that your wireless mouse operates in the 2.4GHz frequency band. Why would I make such assumptions?

USB 3.0 is known in interfere with 2.4GHz wireless devices, and it's not a problem unique to the Pi4. It's an issue that's been know of for awhile that affected other computers, including some very expensive Macbooks. The tiny size and bare-bones nature of the Pi4 probably doesn't help.

A simple solution is to move the dongle away from the USB 3.0 device with a short extension cable (or move the USB 3.0 device away from the mouse dongle). Better shielded USB 3.0 cables might help as well (assuming interference is leaking from the cable and not the device itself).

A shielded 6 inch short USB extension cable should be enough (worked for me and my Logitech Unifying devices).
My mind is like a browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?

manderss99
Posts: 1
Joined: Tue Aug 06, 2019 3:30 am

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 6:14 am

Sorry if this already been discussed but there is lots of info here, I'm a bit confused.

I previously copied my sd card to a samsung fit usb drive and runs the root file system from usb drive and boot from the sd card.

what would be the appropriate way to upgrade to boot directly from usb so I dont need the card?

thanks

User avatar
Roken
Posts: 361
Joined: Sun Dec 31, 2017 4:35 pm
Location: UK

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 9:23 am

Wow. Finally got it working, and found a "Gotcha" that I haven't seen documented. (I can also provide the fix).

I haven't done this with a fresh install. I was already booting with /boot on the sdcard, and fsroot on the hard drive, which was working just fine. I had no desire to create a fresh install from scratch.

The HD originally had two partitions, both ext4. the first (32Gb) was fsroot, and the 2nd (was >900Gb) was data.

I'm aware that for USB boot to work the first partition must be a vfat formatted boot partition, so I used gparted to create 256M at the start, vfat, and shuffled the other two around a bit to accommodate. I copied the files (updated from github) from the sdcard to the new boot partition, and expected this to work. It doesn't!

It seems as well as expecting the first partition to be the vfat /boot partition, the eeprom also expects it to be /dev/sdX1, and for the PARTUUID to be suffixed "-1". (It may only be one of these, but I fixed up both at the same time)

Because I created the /boot partition after the others, it was /dev/sda3 and suffixed "-3".

This resulted in one telling error, being

Code: Select all

Non FAT Partition 0 sectors XXXXXXXX type 2
Taken me a week, but:

Code: Select all

sudo sfdisk -r /dev/sda
Fixed it. Now the partitions are in order, both in /dev and the UUID suffix.

Retried and, after one failure on startup (xHC-CMD Err: 6 Type 1) it retries and boots successfully. NB. This is only on cold boot. No error on reboot. Possibly slow drive startup?

Of course, I had to correct cmdline.txt and fstab to fix the new PARTUUIDs.

So anyone failing who has created the boot partition later, this may help.
Headless PI. OMG, someone cut it's head off. Oh, hang on. it didn't have one to start with.

Kendek
Posts: 218
Joined: Thu Jul 25, 2019 4:39 pm
Location: Kaposvár, Hungary

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 9:39 am

manderss99 wrote:
Mon May 25, 2020 6:14 am
Sorry if this already been discussed but there is lots of info here, I'm a bit confused.

I previously copied my sd card to a samsung fit usb drive and runs the root file system from usb drive and boot from the sd card.

what would be the appropriate way to upgrade to boot directly from usb so I dont need the card?

thanks
Do an rpi-update, flash the beta bootloader, update the FAT32 boot partition on the USB drive and corrects the /etc/fstab. After these steps, remove the microSD card and power on the RPi.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26355
Joined: Sat Jul 30, 2011 7:41 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 9:53 am

manderss99 wrote:
Mon May 25, 2020 6:14 am
Sorry if this already been discussed but there is lots of info here, I'm a bit confused.

I previously copied my sd card to a samsung fit usb drive and runs the root file system from usb drive and boot from the sd card.

what would be the appropriate way to upgrade to boot directly from usb so I dont need the card?

thanks
I would suggest that if you are having trouble following these instructions, then perhaps participating in this beta test programme might not be the best option. If it doesn;t work you might end up with something difficult to fix. Once the bugs are sorted out, then it should be a lot easier to do this.

I'll reiterate to everyone, don't participate in this programme unless you are happy to lose data, spend hours figuring stuff out, and are a bit of a Linux masochist. It might work fine, it might not. It's a beta programme, we can take no responsibility for lost data and time. The choice is yours.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26355
Joined: Sat Jul 30, 2011 7:41 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 9:56 am

cormack wrote:
Sun May 24, 2020 10:27 pm
Found something that may be related to "rpi-update" in all of this.

Where "tvservice -l" would previously show:

Code: Select all

2 attached device(s), display ID's are :
Display Number 2, type HDMI 0
Display Number 7, type HDMI 1
It now renders:

Code: Select all

[E] No multi display support in firmware!
This system, a Pi 4B (2GB), runs headless, with an HDMI Display Emulator dummy plug plugged into each HDMI port on this Pi. So it appears I've got two issues at the moment. A.) I can't boot to the X820 as explained previously, and now I've spotted B.) this glitch with tvservice.

This Pi runs the native Broadcom display driver, not the kms or fkms GL drivers.
Odd. No multi display support indicates a old firmware version. Multi display support was in there from the launch of the Pi4. Are you sure you haven't switched to KMS accidentally? (tvservice -l should still work on FKMS)
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

andrum99
Posts: 1176
Joined: Fri Jul 20, 2012 2:41 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 10:26 am

Roken wrote:
Mon May 25, 2020 9:23 am
...

I haven't done this with a fresh install. I was already booting with /boot on the sdcard, and fsroot on the hard drive, which was working just fine. I had no desire to create a fresh install from scratch.
...
The instructions say to image the USB mass storage device using a Raspbian image. If you do that, then the partition layout will be correct to begin with.

The issue you have found seems to be that, for the Pi 4 to boot from the USB mass storage device, the first partition listed in the MBR (partition 0) must be the FAT32 boot partition. That's probably not the intended behaviour - it should work whichever primary partition is the boot partition.

andrum99
Posts: 1176
Joined: Fri Jul 20, 2012 2:41 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 10:30 am

Roken wrote:
Mon May 25, 2020 9:23 am
...
Retried and, after one failure on startup (xHC-CMD Err: 6 Type 1) it retries and boots successfully. NB. This is only on cold boot. No error on reboot. Possibly slow drive startup?
...
You can adjust the time that the bootloader waits for each USB mass storage device to become ready using the USB_MSD_LUN_TIMEOUT option in the bootloader configuration. For example:

Code: Select all

USB_MSD_LUN_TIMEOUT=3000

will change the timeout from the default (2000 milliseconds = 2 seconds) to 3000 milliseconds. This is a per-device setting. There is also an overall timeout value which defaults to 10000 milliseconds (10 seconds). This is controlled using the USB_MSD_DISCOVER_TIMEOUT setting in a similar fashion.

User avatar
rpdom
Posts: 16962
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 10:38 am

jamesh wrote:
Mon May 25, 2020 9:53 am
I'll reiterate to everyone, don't participate in this programme unless you are happy to lose data, spend hours figuring stuff out, and are a bit of a Linux masochist. It might work fine, it might not. It's a beta programme, we can take no responsibility for lost data and time. The choice is yours.
Well said.

Unfortunately I can't help with this one as my only Pi 4B is in use with other stuff that I don't want to risk having problems with and current situation means I can't justify buying a second or the USB storage to go with it for testing. :(
(Linux sysadmin of 15+ years and Unix sysadmin since 1995.)
Unreadable squiggle

User avatar
Roken
Posts: 361
Joined: Sun Dec 31, 2017 4:35 pm
Location: UK

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 10:41 am

andrum99 wrote:
Mon May 25, 2020 10:26 am
The instructions say to image the USB mass storage device using a Raspbian image. If you do that, then the partition layout will be correct to begin with.
I'm aware, though as I said, the drive was already fully prepped for the previous behaviour, with nearly 650Gbs I'd have had to offload somewhere before I started, and a fully configured Raspbian installed to it, so this was NOT a viable option.
The issue you have found seems to be that, for the Pi 4 to boot from the USB mass storage device, the first partition listed in the MBR (partition 0) must be the FAT32 boot partition. That's probably not the intended behaviour - it should work whichever primary partition is the boot partition.
No, that aspect is documented. What isn't documented is the requirement for the device allocation/PARTUUID to also be correct and point to the first partition, and this is the point of my post.
You can adjust the time that the bootloader waits for each USB mass storage device to become ready using the USB_MSD_LUN_TIMEOUT option in the bootloader configuration. For example:

Code: Select all

USB_MSD_LUN_TIMEOUT=3000

will change the timeout from the default (2000 milliseconds = 2 seconds) to 3000 milliseconds. This is a per-device setting. There is also an overall timeout value which defaults to 10000 milliseconds (10 seconds). This is controlled using the USB_MSD_DISCOVER_TIMEOUT setting in a similar fashion.
Again, I'm aware, but since the PI is running 24/7, an extra couple of seconds on the rare cold boot is nothing to worry me.
Headless PI. OMG, someone cut it's head off. Oh, hang on. it didn't have one to start with.

User avatar
DougieLawson
Posts: 38758
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 10:54 am

rpdom wrote:
Mon May 25, 2020 10:38 am
jamesh wrote:
Mon May 25, 2020 9:53 am
I'll reiterate to everyone, don't participate in this programme unless you are happy to lose data, spend hours figuring stuff out, and are a bit of a Linux masochist. It might work fine, it might not. It's a beta programme, we can take no responsibility for lost data and time. The choice is yours.
Well said.

Unfortunately I can't help with this one as my only Pi 4B is in use with other stuff that I don't want to risk having problems with and current situation means I can't justify buying a second or the USB storage to go with it for testing. :(
(Linux sysadmin of 15+ years and Unix sysadmin since 1995.)
+1

I'd participate, but I still don't have the RPi4 hardware. Early beta testing is definitely not for the faint hearted, some days it's not for the grumpy old farts who've been doing this stuff for decades.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

ZeFerby
Posts: 2
Joined: Mon May 25, 2020 10:58 am

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 11:05 am

Hello forums, this is my first post, sorry for any etiquette breach...

Thank you for this feature, I have a Crucial 120GB BX500 as boot device now, working fine, both with :
  • a noname ("ULT-Best" ???) USB3/SATA adapter
  • a Sabrent Jmicron adapter and usb-storage quirks
There is one small issue I'd like to get rid of : it seems the SD card is probed and dmesg is filled with blocks like the following after a few hours/days, so is there a setting to prevent that behaviour please ?

Code: Select all

[154627.590790] mmc0: Timeout waiting for hardware cmd interrupt.
[154627.590800] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[154627.590813] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
[154627.590823] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[154627.590833] mmc0: sdhci: Argument:  0x80000c08 | Trn mode: 0x00000000
[154627.590842] mmc0: sdhci: Present:   0x1fff0001 | Host ctl: 0x00000001
[154627.590852] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000080
[154627.590861] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x0000f447
[154627.590870] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[154627.590879] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
[154627.590888] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[154627.590898] mmc0: sdhci: Caps:      0x45ee6432 | Caps_1:   0x0000a525
[154627.590908] mmc0: sdhci: Cmd:       0x0000341a | Max curr: 0x00080008
[154627.590916] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[154627.590925] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[154627.590933] mmc0: sdhci: Host ctl2: 0x00000000
[154627.590942] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
[154627.590950] mmc0: sdhci: ============================================
pi@raspi4usb:~ $ 

hippy
Posts: 7344
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 11:19 am

rpdom wrote:
Mon May 25, 2020 10:38 am
Unfortunately I can't help with this one as my only Pi 4B is in use with other stuff that I don't want to risk having problems with and current situation means I can't justify buying a second or the USB storage to go with it for testing. :(
If you have a spare SD Card and USB SD Card Reader, or a spare 4GB or greater USB Stick, you can play along without risking anything.

This beta has been the perfect excuse for me to get on-board with learning more about the Boot Eeprom, its tools, USB and even network booting. For anyone who, like me, has never done it before I would suggest progressing through SD Card Reader, USB stick, before USB HDD or SSD; learn to walk before attempting to run the marathon.

User avatar
rpdom
Posts: 16962
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 11:28 am

hippy wrote:
Mon May 25, 2020 11:19 am
rpdom wrote:
Mon May 25, 2020 10:38 am
Unfortunately I can't help with this one as my only Pi 4B is in use with other stuff that I don't want to risk having problems with and current situation means I can't justify buying a second or the USB storage to go with it for testing. :(
If you have a spare SD Card and USB SD Card Reader, or a spare 4GB or greater USB Stick, you can play along without risking anything.

This beta has been the perfect excuse for me to get on-board with learning more about the Boot Eeprom, its tools, USB and even network booting. For anyone who, like me, has never done it before I would suggest progressing through SD Card Reader, USB stick, before USB HDD or SSD; learn to walk before attempting to run the marathon.
If I had those, and my 4B4GB wasn't busy doing other things, yes I could...
Unreadable squiggle

User avatar
cormack
Posts: 44
Joined: Fri Jul 12, 2019 7:39 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 11:44 am

jamesh wrote:
Mon May 25, 2020 9:56 am
cormack wrote:
Sun May 24, 2020 10:27 pm
Found something that may be related to "rpi-update" in all of this.

Where "tvservice -l" would previously show:

Code: Select all

2 attached device(s), display ID's are :
Display Number 2, type HDMI 0
Display Number 7, type HDMI 1
It now renders:

Code: Select all

[E] No multi display support in firmware!
This system, a Pi 4B (2GB), runs headless, with an HDMI Display Emulator dummy plug plugged into each HDMI port on this Pi. So it appears I've got two issues at the moment. A.) I can't boot to the X820 as explained previously, and now I've spotted B.) this glitch with tvservice.

This Pi runs the native Broadcom display driver, not the kms or fkms GL drivers.
Odd. No multi display support indicates a old firmware version. Multi display support was in there from the launch of the Pi4. Are you sure you haven't switched to KMS accidentally? (tvservice -l should still work on FKMS)
I agree this was odd... so it made me re-examine everything I'd done, and I found the problem. STUPID USER ERROR - DOH.

Apparently, I THOUGHT that I'd rsync'd the needed files from my SD to the vfat partition on my SSD, but comparing file sizes and date/time stamps, I saw they were different. So, I re-rsync'd the files to the SSD, and presto... it now boots. Turns out, I typo'd the destination dir with my rsync, which of course meant the files needed on the vfat partition were not present on the SSD's vfat partition.

My system now boots to the X820 SSD, and the tvservice issue is resolved.

:: totally hangs head in shame - what a putz I am LOL ::

andrum99
Posts: 1176
Joined: Fri Jul 20, 2012 2:41 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 12:55 pm

ZeFerby wrote:
Mon May 25, 2020 11:05 am
Hello forums, this is my first post, sorry for any etiquette breach...

Thank you for this feature, I have a Crucial 120GB BX500 as boot device now, working fine, both with :
  • a noname ("ULT-Best" ???) USB3/SATA adapter
  • a Sabrent Jmicron adapter and usb-storage quirks
There is one small issue I'd like to get rid of : it seems the SD card is probed and dmesg is filled with blocks like the following after a few hours/days, so is there a setting to prevent that behaviour please ?

Code: Select all

[154627.590790] mmc0: Timeout waiting for hardware cmd interrupt.
[154627.590800] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[154627.590813] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
[154627.590823] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[154627.590833] mmc0: sdhci: Argument:  0x80000c08 | Trn mode: 0x00000000
[154627.590842] mmc0: sdhci: Present:   0x1fff0001 | Host ctl: 0x00000001
[154627.590852] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000080
[154627.590861] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x0000f447
[154627.590870] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[154627.590879] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
[154627.590888] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[154627.590898] mmc0: sdhci: Caps:      0x45ee6432 | Caps_1:   0x0000a525
[154627.590908] mmc0: sdhci: Cmd:       0x0000341a | Max curr: 0x00080008
[154627.590916] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[154627.590925] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[154627.590933] mmc0: sdhci: Host ctl2: 0x00000000
[154627.590942] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
[154627.590950] mmc0: sdhci: ============================================
pi@raspi4usb:~ $ 
Yes - set sd_poll_once=1 in config.txt, then reboot so that it takes effect.

Edit: No it's not - the correct incantation is actually:

Code: Select all

dtparam=sd_poll_once
Note that with this setting, Linux only checks the SD card slot once at boot to see if a card is inserted. This means that if you insert an SD card once Linux has booted, it will not be detected, and you therefore will not be able to access it. If you need that functionality, don't use sd_poll_once.

ZeFerby
Posts: 2
Joined: Mon May 25, 2020 10:58 am

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 1:42 pm

andrum99 wrote:
Mon May 25, 2020 12:55 pm
ZeFerby wrote:
Mon May 25, 2020 11:05 am
Hello forums, this is my first post, sorry for any etiquette breach...

Thank you for this feature, I have a Crucial 120GB BX500 as boot device now, working fine, both with :
  • a noname ("ULT-Best" ???) USB3/SATA adapter
  • a Sabrent Jmicron adapter and usb-storage quirks
There is one small issue I'd like to get rid of : it seems the SD card is probed and dmesg is filled with blocks like the following after a few hours/days, so is there a setting to prevent that behaviour please ?

Code: Select all

[154627.590790] mmc0: Timeout waiting for hardware cmd interrupt.
[154627.590800] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[154627.590813] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
[154627.590823] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[154627.590833] mmc0: sdhci: Argument:  0x80000c08 | Trn mode: 0x00000000
[154627.590842] mmc0: sdhci: Present:   0x1fff0001 | Host ctl: 0x00000001
[154627.590852] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000080
[154627.590861] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x0000f447
[154627.590870] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[154627.590879] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
[154627.590888] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[154627.590898] mmc0: sdhci: Caps:      0x45ee6432 | Caps_1:   0x0000a525
[154627.590908] mmc0: sdhci: Cmd:       0x0000341a | Max curr: 0x00080008
[154627.590916] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[154627.590925] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[154627.590933] mmc0: sdhci: Host ctl2: 0x00000000
[154627.590942] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
[154627.590950] mmc0: sdhci: ============================================
pi@raspi4usb:~ $ 
Yes - set sd_poll_once=1 in config.txt, then reboot so that it takes effect.

Edit: No it's not - the correct incantation is actually:

Code: Select all

dtparam=sd_poll_once
Note that with this setting, Linux only checks the SD card slot once at boot to see if a card is inserted. This means that if you insert an SD card once Linux has booted, it will not be detected, and you therefore will not be able to access it. If you need that functionality, don't use sd_poll_once.


Thank you very much @andrum99 !

It seems to be a new config.txt dtparam option available since kernel 2012-02-12 version (for anyone stumbling on this thread by accident); this worked perfectly for me !

For anyone seeking more info on that subject :
https://github.com/raspberrypi/linux/re ... 20200212-1
https://github.com/raspberrypi/linux/issues/3286

EDIT: Added reference to the usb-storage quirks thread
Pi4, P3B+, P3A+, Pi3B
SDs all over the place, plus USB/SSD and berryboot/iSCSI

kevinthefixer
Posts: 94
Joined: Sun Jun 02, 2013 10:36 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 4:59 pm

This whole shebang happened in a very timely manner for me! I'd just purchased a new Pi4 with the goal of setting up an SSD-based system when I saw this. Beta or no, I just had to do it.

A few observations:

Test-booting from the same uSD card I'd just flashed and modified, put in a card-reader in a USB port, did not work for me. I tried with 2 different card readers, both very cheap. It's my impression these have no chip? Anyway I gave up and flashed a 256GB SSD and took the firmware files from the uSD card and it worked.

At least it worked with my Alcey sata-usb3 adapter. I tried with an older Orico enclosure that I'd hoped to use in the final build, as the board inside is smaller, but no joy there.

I also seem to have a problem with lsusb; the Orico enclosure isn't shown there. Perhaps it must have an SSD in it? Or maybe I should do sudo lsusb? Anyway here is a link to the working one: https://www.amazon.com/gp/product/B01M3 ... UTF8&psc=1
I have a couple more ordered as I like to keep a couple handy. I'll post these as I get a chance to test them.

I had wondered if it would be possible to use the uSD reader on the Pi as, well, a regular card reader without tieing up a USB port; most Pi4 cases allow access to it. Answer: Yes you can, Raspian mounts a card in it as a removable drive. I haven't yet tested whether it would interfere with booting if there's a card in it at boot.

Question: as this goes stable, do I need to change the target from "beta" to "stable" or "critical" and run rpi-update again?

Thanks to all the devs, I know this was not a trivial project, I shudder to think how many people-hours are invested here.

Edit: I think I have it sorted now. I assumed that a device labelled "Via Labs" would be part of the Pi itself; not necessarily so, my Alcey adapter has a Via chipset in it (2109:0711). This is the one that worked. Amazon just came by and delivered another adapter that doesn't work for booting; so now both my non-booting adapters (both work fine as removable drives) have JMicron chips. And it seems lsusb does not report devices not in use, so there must be a drive in the adapter before it'll tell you what it is.

jpinhal
Posts: 3
Joined: Sun May 24, 2020 2:02 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 5:49 pm

HawaiianPi wrote:
Mon May 25, 2020 5:26 am
jpinhal wrote:
Sun May 24, 2020 10:18 pm
...after doing the firmware update and rebooting, the mouse directly connected on USB2.0 has a bit of wierd behaviour where it stops moving and then moves again.
I'm going to guess that's a wireless mouse, and it's the dongle you're connecting to USB 2.0. I'll also predict that your wireless mouse operates in the 2.4GHz frequency band. Why would I make such assumptions?

USB 3.0 is known in interfere with 2.4GHz wireless devices, and it's not a problem unique to the Pi4. It's an issue that's been know of for awhile that affected other computers, including some very expensive Macbooks. The tiny size and bare-bones nature of the Pi4 probably doesn't help.

A simple solution is to move the dongle away from the USB 3.0 device with a short extension cable (or move the USB 3.0 device away from the mouse dongle). Better shielded USB 3.0 cables might help as well (assuming interference is leaking from the cable and not the device itself).

A shielded 6 inch short USB extension cable should be enough (worked for me and my Logitech Unifying devices).
@HawaiianPi Thank you for this information! I tested with a corded mouse and it is working great!

RonR
Posts: 1163
Joined: Tue Apr 12, 2016 10:29 pm
Location: US

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 6:08 pm

Roken wrote:
Mon May 25, 2020 9:23 am
I haven't done this with a fresh install. I was already booting with /boot on the sdcard, and fsroot on the hard drive, which was working just fine. I had no desire to create a fresh install from scratch.

The HD originally had two partitions, both ext4. the first (32Gb) was fsroot, and the 2nd (was >900Gb) was data.

I'm aware that for USB boot to work the first partition must be a vfat formatted boot partition, so I used gparted to create 256M at the start, vfat, and shuffled the other two around a bit to accommodate. I copied the files (updated from github) from the sdcard to the new boot partition, and expected this to work. It doesn't!

It seems as well as expecting the first partition to be the vfat /boot partition, the eeprom also expects it to be /dev/sdX1, and for the PARTUUID to be suffixed "-1". (It may only be one of these, but I fixed up both at the same time)

Because I created the /boot partition after the others, it was /dev/sda3 and suffixed "-3".

This resulted in one telling error, being

Code: Select all

Non FAT Partition 0 sectors XXXXXXXX type 2
cormack wrote:
Mon May 25, 2020 11:44 am
Apparently, I THOUGHT that I'd rsync'd the needed files from my SD to the vfat partition on my SSD, but comparing file sizes and date/time stamps, I saw they were different. So, I re-rsync'd the files to the SSD, and presto... it now boots. Turns out, I typo'd the destination dir with my rsync, which of course meant the files needed on the vfat partition were not present on the SSD's vfat partition.

To help prevent making mistakes such as these, the following may be useful to others:

Migrating Hybrid SD/USB Booting to Direct USB Booting on the Raspberry Pi 4 : Made Easy

User avatar
HawaiianPi
Posts: 5657
Joined: Mon Apr 08, 2013 4:53 am
Location: Aloha, Oregon USA

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 7:47 pm

kevinthefixer wrote:
Mon May 25, 2020 4:59 pm
At least it worked with my Alcey sata-usb3 adapter. I tried with an older Orico enclosure that I'd hoped to use in the final build, as the board inside is smaller, but no joy there.

I also seem to have a problem with lsusb; the Orico enclosure isn't shown there. Perhaps it must have an SSD in it? Or maybe I should do sudo lsusb?
The Orico enclosures are odd, they only show VID:PID with no name or description. The one I have works. It has a VID:PID of 2537:1068 and uses a Norelsys 1068X controller. To get more info you could try sudo lsusb -vvvs x:x with x:x being the Bus and Device number.

kevinthefixer wrote:
Mon May 25, 2020 4:59 pm
I have a couple more ordered as I like to keep a couple handy. I'll post these as I get a chance to test them.
This is the one I have been using for awhile and it works well: Eluteng USB 3.0 to SATA-III adapter cable.

kevinthefixer wrote:
Mon May 25, 2020 4:59 pm
I had wondered if it would be possible to use the uSD reader on the Pi as, well, a regular card reader without tieing up a USB port; most Pi4 cases allow access to it. Answer: Yes you can, Raspian mounts a card in it as a removable drive.
Yes, it works, but be aware that the Pi4 will constantly poll the slot when it's empty. You can add dtparam=sd_poll_once to config.txt to stop that, but then the card will not be easily swappable.

kevinthefixer wrote:
Mon May 25, 2020 4:59 pm
I haven't yet tested whether it would interfere with booting if there's a card in it at boot.
As long as the card itself is not bootable it shouldn't be a problem (I have tested it).

kevinthefixer wrote:
Mon May 25, 2020 4:59 pm
Edit: I think I have it sorted now. I assumed that a device labelled "Via Labs" would be part of the Pi itself; not necessarily so, my Alcey adapter has a Via chipset in it (2109:0711). This is the one that worked. Amazon just came by and delivered another adapter that doesn't work for booting; so now both my non-booting adapters (both work fine as removable drives) have JMicron chips. And it seems lsusb does not report devices not in use, so there must be a drive in the adapter before it'll tell you what it is.
Interesting. I have an adapter with the same VIA chipset, and mine does not work for booting, although it does mount a drive after the system has booted.

If your JMicron based adapters have a VID:PID of 152d:0578 adding usb-storage.quirks=152d:0578:u to the beginning of /boot/cmdline.txt should get them working (it fixed a bunch of mine).
My mind is like a browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?

andrum99
Posts: 1176
Joined: Fri Jul 20, 2012 2:41 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 8:26 pm

HawaiianPi wrote:
Mon May 25, 2020 7:47 pm
kevinthefixer wrote:
Mon May 25, 2020 4:59 pm
At least it worked with my Alcey sata-usb3 adapter. I tried with an older Orico enclosure that I'd hoped to use in the final build, as the board inside is smaller, but no joy there.

I also seem to have a problem with lsusb; the Orico enclosure isn't shown there. Perhaps it must have an SSD in it? Or maybe I should do sudo lsusb?
The Orico enclosures are odd, they only show VID:PID with no name or description.
The name and description come from a file on the Pi which lists the name and description along with the vid:pid combination they apply to - the only thing USB devices use to identify themselves is the vid:pid.

User avatar
cormack
Posts: 44
Joined: Fri Jul 12, 2019 7:39 pm

Re: Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)

Mon May 25, 2020 9:29 pm

RonR wrote:
Mon May 25, 2020 6:08 pm
To help prevent making mistakes such as these, the following may be useful to others:

Migrating Hybrid SD/USB Booting to Direct USB Booting on the Raspberry Pi 4 : Made Easy
Of course, I would have been just as apt to typo any of those commands, too. ;)

Return to “General discussion”