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

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Thu Jun 18, 2020 3:20 pm

jfabernathy wrote:
Thu Jun 18, 2020 2:35 pm
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

User avatar
davidcoton
Posts: 5840
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK
Contact: Website

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Thu Jun 18, 2020 4:55 pm

jfabernathy wrote:
Thu Jun 18, 2020 2:35 pm
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.
Location: 345th cell on the right of the 210th row of L2 cache

jfabernathy
Posts: 129
Joined: Thu Oct 11, 2018 10:52 am
Location: Central North Carolina

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Thu Jun 18, 2020 6:23 pm

Kendek wrote:
Thu Jun 18, 2020 3:20 pm
jfabernathy wrote:
Thu Jun 18, 2020 2:35 pm
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
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
14-boot-order.jpg (109.47 KiB) Viewed 3432 times

thatchunkylad198966
Posts: 450
Joined: Thu Jul 04, 2019 10:21 am
Location: UK, Birmingham

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Thu Jun 18, 2020 8:05 pm

Has this happened now?:
I've promoted this to stable in the Github repository, an APT update will follow shortly.
The "APT" bit?

fruitoftheloom
Posts: 25699
Joined: Tue Mar 25, 2014 12:40 pm
Location: Delightful Dorset

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Thu Jun 18, 2020 8:30 pm

thatchunkylad198966 wrote:
Thu Jun 18, 2020 8:05 pm
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
The information is out there....you just have to let it in.

My other Linux machines are a ChromeBox & Intel CoreDuo Desktop

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

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 12:52 am

jfabernathy wrote:
Thu Jun 18, 2020 6:23 pm
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?
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?

mindpivot
Posts: 1
Joined: Fri Jun 19, 2020 12:42 am
Contact: Twitter

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 12:59 am

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
Posts: 129
Joined: Thu Oct 11, 2018 10:52 am
Location: Central North Carolina

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 1:30 am

HawaiianPi wrote:
Fri Jun 19, 2020 12:52 am
jfabernathy wrote:
Thu Jun 18, 2020 6:23 pm
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
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
console log.jpg (129.24 KiB) Viewed 3229 times

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

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 3:37 am

jfabernathy wrote:
Fri Jun 19, 2020 1:30 am
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.
jfabernathy wrote:
Fri Jun 19, 2020 1:30 am
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?
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?

jfabernathy
Posts: 129
Joined: Thu Oct 11, 2018 10:52 am
Location: Central North Carolina

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 10:19 am

HawaiianPi wrote:
Fri Jun 19, 2020 3:37 am

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.

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

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 11:23 am

jfabernathy wrote:
Fri Jun 19, 2020 10:19 am
... 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.
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?

jfabernathy
Posts: 129
Joined: Thu Oct 11, 2018 10:52 am
Location: Central North Carolina

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 11:51 am

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.

User avatar
paulwratt
Posts: 104
Joined: Fri Jun 12, 2015 12:15 am

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 11:58 am

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
Posts: 129
Joined: Thu Oct 11, 2018 10:52 am
Location: Central North Carolina

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 2:29 pm

jfabernathy wrote:
Fri Jun 19, 2020 11:51 am
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
Posts: 9156
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 6:28 pm

jfabernathy wrote:
Fri Jun 19, 2020 1:30 am
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
Posts: 57
Joined: Tue Mar 04, 2014 1:53 am
Location: Vermont, USA

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 6:34 pm

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
Posts: 129
Joined: Thu Oct 11, 2018 10:52 am
Location: Central North Carolina

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 7:16 pm

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

User avatar
paulwratt
Posts: 104
Joined: Fri Jun 12, 2015 12:15 am

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 7:18 pm

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
Posts: 129
Joined: Thu Oct 11, 2018 10:52 am
Location: Central North Carolina

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 8:01 pm

paulwratt wrote:
Fri Jun 19, 2020 7:18 pm
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
Posts: 129
Joined: Thu Oct 11, 2018 10:52 am
Location: Central North Carolina

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Fri Jun 19, 2020 8:19 pm

jfabernathy wrote:
Fri Jun 19, 2020 8:01 pm
paulwratt wrote:
Fri Jun 19, 2020 7:18 pm
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
Posts: 57
Joined: Tue Mar 04, 2014 1:53 am
Location: Vermont, USA

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Sat Jun 20, 2020 5:31 am

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
Posts: 45
Joined: Fri Jun 19, 2020 8:07 am

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Sat Jun 20, 2020 12:54 pm

hdtodd wrote:
Sat Jun 20, 2020 5:31 am
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
Posts: 129
Joined: Thu Oct 11, 2018 10:52 am
Location: Central North Carolina

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Sat Jun 20, 2020 1:31 pm

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
Posts: 45
Joined: Fri Jun 19, 2020 8:07 am

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Sat Jun 20, 2020 1:49 pm

How to set boot order?

jfabernathy
Posts: 129
Joined: Thu Oct 11, 2018 10:52 am
Location: Central North Carolina

Re: STICKY: USB-MSD boot EEPROM third update - 2020-06-15

Sat Jun 20, 2020 4:45 pm

jfabernathy wrote:
Fri Jun 19, 2020 11:51 am
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.

Return to “General discussion”