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

[Kendek]

I find some dated information about changing the default boot device, but not sure if its appropriate for 6-15-2020.

What I want to do is try USB3 boot first then try SD if USB fails.

https://www.raspberrypi.org/documentati ... _config.md

BOOT_ORDER section

[davidcoton]

I have updated to the 6-15-2020 bootloader that was in the Stable directory and have my RPI4 4GB booting from USB3.

It has a console message that says it failed to find the SD card and after a few seconds resets and boots from USB3 directly.

I find some dated information about changing the default boot device, but not sure if its appropriate for 6-15-2020.

What I want to do is try USB3 boot first then try SD if USB fails.

To avoid confusion, note that the version date should be given as 2020-06-15. This avoids regional differences in the presentation of dates.

[jfabernathy]

I find some dated information about changing the default boot device, but not sure if its appropriate for 2020-6-15.

What I want to do is try USB3 boot first then try SD if USB fails.

https://www.raspberrypi.org/documentati ... _config.md

BOOT_ORDER section

Thanks for the link to the instructions. I first tried changing the boot order to 0xf14 and it still waited 5 secs or so before booting. I don't understand what the console text was telling me so I took a photo while it waited the 5 seconds. BTW, there was only a USB3 flash card installed.

f14-boot-order.jpg (99.48 KiB) Viewed 3432 times

So I tried changing it to 0x14 and that didn't boot. It finally stopped at a point of asking me to insert a SDcard. screenshot below

14-boot-order.jpg (109.47 KiB) Viewed 3432 times

[thatchunkylad198966]

Has this happened now?:

I've promoted this to stable in the Github repository, an APT update will follow shortly.

The "APT" bit?

[fruitoftheloom]

Has this happened now?:

I've promoted this to stable in the Github repository, an APT update will follow shortly.

The "APT" bit?

Undertake the usual update / full-upgrade / reboot dance:

https://www.raspberrypi.org/documentati ... pdating.md

[HawaiianPi]

Thanks for the link to the instructions. I first tried changing the boot order to 0xf14 and it still waited 5 secs or so before booting. I don't understand what the console text was telling me so I took a photo while it waited the 5 seconds. BTW, there was only a USB3 flash card installed.

I just tried 0xf14 and I'm not seeing what you experienced.

When I either cold boot or reboot I get a brief black screen, then the "Rainbow Square" GPU test pattern, then it boots. I don't see the bootloader debug screen most of the time. If I reboot many times I may occasionally see a quick flash of the debug screen, but it's gone before I can read it (and certainly not on-screen long enough to take a picture). Again, that's with 0xf14 (didn't try 0x14).

I'm booting from a SATA-III SSD with a USB 3.0 adapter cable. Tried it with and without an SD card in the system.

Boot order is correct, because even with a bootable SD card in the system, it still boots from USB.

What does the command, vcgencmd bootloader_config return?

[mindpivot]

I've been following the boot from USB threads for a few weeks now as I wait for all the parts for my first ever Pi project to show up. I'm starting with a fresh Raspberry Pi 4B 8GB, USB 3 to NVMe adapter - Realtek RTL9210 chipset, NVMe disk, SD Card.

I apologize if this is a daft question but at this point with all new parts what is the process for enabling USB boot? Is installing any beta firmware necessary? Boot or otherwise?

I saw that I maybe want to add an EEPROM flag to prevent the USB from powering down but is everything else enabled as just part of a standard full update?

At this point there is so much information from the past few weeks I'm uncertain what steps are still required to get everything working.

Thanks!

[jfabernathy]

Thanks for the link to the instructions. I first tried changing the boot order to 0xf14 and it still waited 5 secs or so before booting. I don't understand what the console text was telling me so I took a photo while it waited the 5 seconds. BTW, there was only a USB3 flash card installed.

I just tried 0xf14 and I'm not seeing what you experienced.

When I either cold boot or reboot I get a brief black screen, then the "Rainbow Square" GPU test pattern, then it boots. I don't see the bootloader debug screen most of the time. If I reboot many times I may occasionally see a quick flash of the debug screen, but it's gone before I can read it (and certainly not on-screen long enough to take a picture). Again, that's with 0xf14 (didn't try 0x14).

I'm booting from a SATA-III SSD with a USB 3.0 adapter cable. Tried it with and without an SD card in the system.

Boot order is correct, because even with a bootable SD card in the system, it still boots from USB.

What does the command, vcgencmd bootloader_config return?

I'm booting from a Sandisk USB3 Flash drive 256MB. Tomorrow I'll try a SSD SATA with an adapter.

After power on I see this screen for 5 or more seconds.

during 5 second wait.jpg (100.26 KiB) Viewed 3229 times

Then the screen goes blank and I get the Rainbow screen then a quick boot.

in response to your questions:

console log.jpg (129.24 KiB) Viewed 3229 times

[HawaiianPi]

I'm booting from a Sandisk USB3 Flash drive 256MB. Tomorrow I'm try a SSD SATA with an adapter.

I doubt that matters, but I have a backup on a Samsung flash drive, so I'll give it a try.

Booting from a Samsung BAR Plus 64GB USB 3.1 flash drive didn't make a difference. I did see the brief flash of the debug screen a little more often, but otherwise it was the same.

in response to your questions:
console log.jpg

The only significant difference I see is that I have the USB port power cycle disabled with, USB_MSD_PWR_OFF_TIME=0

I also tried restoring the default bootloader configuration, and that made the debug screen pause for the default 500ms USB power cycle, but 0.5 seconds is nowhere near the 5 seconds you are seeing.

What OS are you running, and what else do you have connected to your system?

[jfabernathy]

What OS are you running, and what else do you have connected to your system?

The process I did to create the boot image was to use RaspberryPi imager and flash the latest Raspberry PI OS 32bit, to a Samsung microSD.
I then booted that with only a wireless HTPC keyboard/trackball combo. I updated to the latest fixes and then upgraded the eeprom.
At that point I inserted the USB Flash and used the SD Card Copy app in Accessories to copy the SD card to my Sandisk 256GB USB3 flash drive.

Only thing slightly weird I do is I have a HDMI to DVI adapter so I can use an older monitor with DVI only and I have an AV receiver connected via 3.5mm audio to RCA plug cable. So I have the /boot/config.txt setting to force 3.5mm audio instead of HDMI A/V.

[HawaiianPi]

... used the SD Card Copy app in Accessories to copy the SD card to my Sandisk 256GB USB3 flash drive.

That sounds fine. Only other thing I can think of for your 5 second delay is that SanDisk flash drive is taking longer to start up than my devices, but that's just a guess (because I've run out of ideas).

FYI:
When using the SD Card Copier, I always enable the New Partition UUIDs option, to avoid having multiple devices with the same PARTUUID.

[jfabernathy]

So I've identified the cause of the long wait before booting my USB3 Flash drive.The offending drive is a:
SanDisk 256GB Ultra Fit USB 3.1 Flash Drive - SDCZ430-256G-G46

I tried the same procedure with a SanDisk Ultra Fit 16GB USB 3.0 Flash Drive SDCZ43-016G-G46 and it worked just fine with not much delay at all. Too fast to take a photo.

So the bootloader sees something with the SDCZ430 drive that is causing it to delay before booting. But the SDCZ43 drive doesn't trigger the same issue.

[paulwratt]

you could try a speed test on the SanDisk 256GB Ultra Fit USB 3.1 once youi have booted from it, it might tell you something (or not)

(it might have one of those chipsets that cause issues)

[jfabernathy]

So I've identified the cause of the long wait before booting my USB3 Flash drive.The offending drive is a:
SanDisk 256GB Ultra Fit USB 3.1 Flash Drive - SDCZ430-256G-G46

I tried the same procedure with a SanDisk Ultra Fit 16GB USB 3.0 Flash Drive SDCZ43-016G-G46 and it worked just fine with not much delay at all. Too fast to take a photo.

So the bootloader sees something with the SDCZ430 drive that is causing it to delay before booting. But the SDCZ43 drive doesn't trigger the same issue.

Not sure what information would help solve this for the 236GB device. Below is some info I have collected.

Also I tested a SATAIII SSD with USB to SATA adapter and it also worked. Only the USB drive installed and it booted immediately with 0xf41 default boot order.

Data for the 256 USB3 flash drive

Code: Select all

pi@raspberrypi:~ $ sudo hdparm -t /dev/sda1

/dev/sda1:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 Timing buffered disk reads: 256 MB in  2.17 seconds = 118.05 MB/sec

pi@raspberrypi:~ $ lsusb
Bus 002 Device 002: ID 0781:5583 SanDisk Corp. Ultra Fit
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 099a:7202 Zippy Technology Corp.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@raspberrypi:~ $ 
pi@raspberrypi:~ $ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 3: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 3: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

Data for the 16GB USB3 flash drive

Code: Select all

pi@raspberrypi:~ $ sudo hdparm -t /dev/sda1

/dev/sda1:
SG_IO: bad/missing sense data, sb[]:  f0 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 Timing buffered disk reads: 256 MB in  2.06 seconds = 124.56 MB/sec
pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        14G  2.9G   11G  22% /
devtmpfs        1.8G     0  1.8G   0% /dev
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           2.0G  8.6M  1.9G   1% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/sda1       253M   52M  202M  21% /boot
tmpfs           391M     0  391M   0% /run/user/1000
pi@raspberrypi:~ $ lsusb
Bus 002 Device 002: ID 0781:5583 SanDisk Corp. Ultra Fit
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 099a:7202 Zippy Technology Corp.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@raspberrypi:~ $ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 3: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 3: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

[hippy]

After power on I see this screen for 5 or more seconds ...

I see similar, but two "HUB" messages when I enable USB booting but have nothing connected to USB, a 5 second or so delay after that.

I am guessing that, since you have only one "HUB" shown, it has found something on USB and is trying to work with that, but then failing.

No idea why it's failing or if that's any help.

[hdtodd]

Two data points re USB-MSD boot EEPROM firmware, both positive.

First, a thanks to those who implemented this ... and those who tested to debug it. Both my Pi-4's are in production (not critical, but not sacrificeable) so I waited 'til "stable" before trying.

Both systems I've installed on are RPI-4, 4GB, running 4.19.118-v8+ #1311 SMP PREEMPT Mon Apr 27 14:32:38 BST 2020 aarch64 GNU/Linux, up to date.

Both were updated manually per instructions in this discussion and on bootloader configuration page; set to update to "stable" configuration:

Code: Select all

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

First is a 4TB WD easystore drive, hybrid partitioning, USB3 interface:

Code: Select all

# hdparm -I /dev/sda1

/dev/sda1:

ATA device, with non-removable media
	Model Number:       WDC WD40NMZW-11GX6S1                    
	Serial Number:      WD-WX21DB757U23
	Firmware Revision:  01.01A01
	Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0

and

Code: Select all

# lsusb
Bus 002 Device 002: ID 1058:25fa Western Digital Technologies, Inc. 
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

and

Code: Select all

# rpi-eeprom-config /lib/firmware/raspberrypi/bootloader/stable/new.bin
[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=0xf14

Boots and runs just fine. A little slow on booting; some error message in the initial phase I haven't caught yet, and then significant delay (10-15 sec). Once in operation, the green light flashes indicating that it's checking for a µSD being inserted into the slot; I'll kill that with the config.txt line before rebooting; that might minimize delay (and eliminate the annoying green LED flash).

dmesg shows most of the boot to be normal, but a total of 6 reports of the following:

[ 482.284443] mmc0: Timeout waiting for hardware cmd interrupt.
[ 482.284456] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 482.284469] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
[ 482.284478] mmc0: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
[ 482.284485] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[ 482.284492] mmc0: sdhci: Present: 0x1fff0001 | Host ctl: 0x00000001
[ 482.284499] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080
[ 482.284507] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
[ 482.284515] mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
[ 482.284522] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003
[ 482.284529] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[ 482.284536] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525
[ 482.284544] mmc0: sdhci: Cmd: 0x00000502 | Max curr: 0x00080008
[ 482.284550] mmc0: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000
[ 482.284557] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
[ 482.284563] mmc0: sdhci: Host ctl2: 0x00000000
[ 482.284572] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
[ 482.284577] mmc0: sdhci: ============================================

The drive seemed to work fine (no such error messages) when I booted from the µSD and onto the /dev/sda. It doesn't seem like an ongoing issue, but something I'll want to address if I can figure out what's causing it.

The second case is an HP 120GB SSD on a JMicron USB3 SATA adapter:

Code: Select all

# hdparm -I /dev/sda1

/dev/sda1:

ATA device, with non-removable media
	Model Number:       HP SSD S700 120GB                       
	Serial Number:      HBSA18500100245     
	Firmware Revision:  R0522A1 
	Media Serial Num:   
	Media Manufacturer: 
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0

and

# lsusb
Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 1b4f:214f
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

and

# rpi-eeprom-config /lib/firmware/raspberrypi/bootloader/stable/new.bin
[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=0xf14

Boots and runs just fine, but "dmesg" presents a regular stream of these every 11 seconds:

[54674.383844] mmc0: Timeout waiting for hardware cmd interrupt.
[54674.383855] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[54674.383865] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
[54674.383872] mmc0: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
[54674.383879] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[54674.383886] mmc0: sdhci: Present: 0x1fff0001 | Host ctl: 0x00000001
[54674.383893] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080
[54674.383900] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
[54674.383907] mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
[54674.383914] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003
[54674.383921] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[54674.383927] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525
[54674.383934] mmc0: sdhci: Cmd: 0x00000502 | Max curr: 0x00080008
[54674.383941] mmc0: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000
[54674.383947] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
[54674.383953] mmc0: sdhci: Host ctl2: 0x00000000
[54674.383960] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
[54674.383965] mmc0: sdhci: ============================================

So there's clearly some issue in here that needs attention. Not debilitating, but it's a concern.

If anyone has suggestions about where to look to solve the "timeout" issue above, I'd love to hear them.

Again, thanks to those who put in the effort to get this working ... much appreciated (makes updating easy now).

David

[jfabernathy]

I also notice some errors when booting. In my case it's when I boot without a SDcard installed. My test is to copy my SDcard to a USB3 flash drive. I'm using the 16GB flash that boots as quickly as the SD card. No delay during boot. No unexpected errors when the SD card is the boot device.

However, if I remove the SD card and boot from USB Flash, it still boots in about 15 seconds but Dmesg shows some odd mcc errors related to the SD card not installed. There is a delay in the posting of the error which affects how long it takes to get to the desktop. Usually dmesg shows the last message at 15 seconds on a SD card boot, but on USB flash after 15 second messages, it takes until 24 second for the mcc errors below:

Code: Select all

[   24.167950] mmc0: Timeout waiting for hardware cmd interrupt.
[   24.167960] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[   24.167970] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
[   24.167979] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[   24.167987] mmc0: sdhci: Argument:  0x80000c08 | Trn mode: 0x00000000
[   24.167995] mmc0: sdhci: Present:   0x1fff0001 | Host ctl: 0x00000001
[   24.168003] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000080
[   24.168010] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x0000f447
[   24.168018] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[   24.168025] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
[   24.168033] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[   24.168041] mmc0: sdhci: Caps:      0x45ee6432 | Caps_1:   0x0000a525
[   24.168049] mmc0: sdhci: Cmd:       0x0000341a | Max curr: 0x00080008
[   24.168056] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[   24.168063] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[   24.168070] mmc0: sdhci: Host ctl2: 0x00000000
[   24.168077] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
[   24.168083] mmc0: sdhci: ============================================
[   30.567991] vcc-sd: disabling
pi@raspberrypi:~ $ 

Not sure this helps track down any issue or if it's as expected

[paulwratt]

based on the (now 4) previous threads, I believe this to be a kernel issue. There is a presumption that because RPi is SD-card based, ANY failure of the "mmc detect" is logged, and that compounds the problem. And because the "mmc detect" cant reliably use the "sd-card insert detect", it uses a polling system, instead of an event system, again compounding the problem.

This however, does not account for any extra delay during boot, BEFORE the kernel is loaded

[jfabernathy]

based on the (now 4) previous threads, I believe this to be a kernel issue. There is a presumption that because RPi is SD-card based, ANY failure of the "mmc detect" is logged, and that compounds the problem. And because the "mmc detect" cant reliably use the "sd-card insert detect", it uses a polling system, instead of an event system, again compounding the problem.

This however, does not account for any extra delay during boot, BEFORE the kernel is loaded

I'll try putting a blank properly formated SD card in when booting from USB and see what changes

[jfabernathy]

based on the (now 4) previous threads, I believe this to be a kernel issue. There is a presumption that because RPi is SD-card based, ANY failure of the "mmc detect" is logged, and that compounds the problem. And because the "mmc detect" cant reliably use the "sd-card insert detect", it uses a polling system, instead of an event system, again compounding the problem.

This however, does not account for any extra delay during boot, BEFORE the kernel is loaded

I'll try putting a blank properly formated SD card in when booting from USB and see what changes

I put in a freshly formated (FAT32) SD card and booted from USB flash drive. No delays or error messages. Last dmesg message was at 16 seconds and it was related to Bluetooth initialization.

[hdtodd]

I thought the µSD polling might be because I hadn't put this

dtoverlay=sdtweak,poll_once

into config.txt. So I went to add it to the config.txt on that Pi and found that it was already there.

So I'd guess that paulwratt is correct that it's a kernel issue and not an accidental omission of the poll_once directive.

Inserting a µSD and rebooting eliminated the "mmc detect" report by dmesg, and (not surprisingly) the green µSD light is no longer flashing. Not a great long-term solution but it works for now.

I have boot order set as 0xf14 so it booted from the USB drive.

But there was still a noticeable pause during boot (several seconds). I'll try to catch it with a camera while it's paused so I can see if I can find out what it's doing.

Oh, I should have said in my earlier note that I don't see low-voltage warnings for either system -- the 120GB SSD or 4TB hard drive.

[melqui]

I thought the µSD polling might be because I hadn't put this

dtoverlay=sdtweak,poll_once

into config.txt. So I went to add it to the config.txt on that Pi and found that it was already there.

So I'd guess that paulwratt is correct that it's a kernel issue and not an accidental omission of the poll_once directive.

Inserting a µSD and rebooting eliminated the "mmc detect" report by dmesg, and (not surprisingly) the green µSD light is no longer flashing. Not a great long-term solution but it works for now.

I have boot order set as 0xf14 so it booted from the USB drive.

But there was still a noticeable pause during boot (several seconds). I'll try to catch it with a camera while it's paused so I can see if I can find out what it's doing.

Oh, I should have said in my earlier note that I don't see low-voltage warnings for either system -- the 120GB SSD or 4TB hard drive.

Same issue here

[jfabernathy]

I timed the boot process having an SD Card installed but blank vs. not installed. The real boot image was on the USB Flash device.

With the blank microSD installed it took 26 seconds from power on to full desktop displayed. It flashed the bootloader screen too fast to read it., so no delays there.

Without any SD card installed it also took 26 seconds from power on to full desktop and the bootloader screen flashed too quickly to see. However, during the time the 4 raspberries are displayed there is a message immediately after that says:
mmc1: Controller never released inhibit bit(s)

This is one of the messages you see with: dmesg | grep mmc
The timeout sequence of errors repeats every few minutes.

Code: Select all

pi@raspberrypi:~ $ dmesg | grep mmc
[    0.430279] mmc-bcm2835 fe300000.mmcnr: could not get clk, deferring probe
[    0.469029] mmc-bcm2835 fe300000.mmcnr: mmc_debug:0 mmc_debug2:0
[    0.469041] mmc-bcm2835 fe300000.mmcnr: DMA channel allocated
[    0.495065] sdhci-iproc fe340000.emmc2: Linked as a consumer to regulator.3
[    0.495157] sdhci-iproc fe340000.emmc2: Linked as a consumer to regulator.4
[    0.505702] mmc1: Controller never released inhibit bit(s).
[    0.522632] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    0.524223] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    0.525830] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    0.528752] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[    0.530363] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    0.539811] mmc0: SDHCI controller on fe340000.emmc2 [fe340000.emmc2] using ADMA
[    0.593068] mmc1: new high speed SDIO card at address 0001
[   19.687863] mmc0: Timeout waiting for hardware cmd interrupt.
[   19.687874] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[   19.687887] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
[   19.687897] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[   19.687906] mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
[   19.687916] mmc0: sdhci: Present:   0x1fff0001 | Host ctl: 0x00000001
[   19.687925] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000080
[   19.687936] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x0000f447
[   19.687946] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[   19.687955] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
[   19.687965] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[   19.687974] mmc0: sdhci: Caps:      0x45ee6432 | Caps_1:   0x0000a525
[   19.687984] mmc0: sdhci: Cmd:       0x00000502 | Max curr: 0x00080008
[   19.687994] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[   19.688003] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[   19.688011] mmc0: sdhci: Host ctl2: 0x00000000
[   19.688021] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
[   19.688029] mmc0: sdhci: ============================================
[  295.534930] mmc0: Timeout waiting for hardware cmd interrupt.
[  295.534943] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[  295.534956] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
[  295.534968] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[  295.534978] mmc0: sdhci: Argument:  0x80000c08 | Trn mode: 0x00000000
[  295.534987] mmc0: sdhci: Present:   0x1fff0001 | Host ctl: 0x00000001
[  295.534997] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000080
[  295.535006] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x0000f447
[  295.535015] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[  295.535024] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
[  295.535033] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[  295.535043] mmc0: sdhci: Caps:      0x45ee6432 | Caps_1:   0x0000a525
[  295.535052] mmc0: sdhci: Cmd:       0x0000341a | Max curr: 0x00080008
[  295.535062] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[  295.535071] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[  295.535079] mmc0: sdhci: Host ctl2: 0x00000000
[  295.535088] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
[  295.535096] mmc0: sdhci: ============================================
[  397.300513] mmc0: Timeout waiting for hardware cmd interrupt.
[  397.300518] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[  397.300524] mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
[  397.300528] mmc0: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[  397.300532] mmc0: sdhci: Argument:  0x80000c08 | Trn mode: 0x00000000
[  397.300536] mmc0: sdhci: Present:   0x1fff0001 | Host ctl: 0x00000001
[  397.300540] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000080
[  397.300543] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x0000f447
[  397.300547] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[  397.300551] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
[  397.300555] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[  397.300559] mmc0: sdhci: Caps:      0x45ee6432 | Caps_1:   0x0000a525
[  397.300562] mmc0: sdhci: Cmd:       0x0000341a | Max curr: 0x00080008
[  397.300566] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[  397.300569] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[  397.300572] mmc0: sdhci: Host ctl2: 0x00000000
[  397.300576] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
[  397.300579] mmc0: sdhci: ============================================
pi@raspberrypi:~ $

[melqui]

How to set boot order?

[jfabernathy]

So I've identified the cause of the long wait before booting my USB3 Flash drive.The offending drive is a:
SanDisk 256GB Ultra Fit USB 3.1 Flash Drive - SDCZ430-256G-G46

I tried the same procedure with a SanDisk Ultra Fit 16GB USB 3.0 Flash Drive SDCZ43-016G-G46 and it worked just fine with not much delay at all. Too fast to take a photo.

So the bootloader sees something with the SDCZ430 drive that is causing it to delay before booting. But the SDCZ43 drive doesn't trigger the same issue.

So I bought a new SanDisk 256GB Extreme PRO USB 3.1 Solid State Flash Drive - SDCZ880-256G-G46 and it works as expected so the delay problem is solved for me.