Loop/wait - Waiting for BCM2835/6/7/2711... hangs/loops - no error messages/diagnostics.

[Johnnie390]

Hello all,

the above is happening on a CM4 Lite, 8GB using a SYNOLOGY SNV3400-400G NVM SSD.
The above NVME SSD has been used in othe Pi instances, ergo it is functional.
Some details -
CM4
Hardware : BCM2835
Revision : d03140
Serial : 1000000084d13d6a
Model : Raspberry Pi Compute Module 4 Rev 1.0

root@raspberrypi:/Transit/rpi-usbboot-master# uname -a
Linux raspberrypi 5.10.39-v8+ #1421 SMP PREEMPT Tue May 25 11:04:26 BST 2021 aarch64 GNU/Linux

root@raspberrypi:/Transit/rpi-usbboot-master# vcgencmd bootloader_version
Apr 29 2021 17:11:25
version c2f8c388c4ee37ad709ace403467d163e8dd91ce (release)
timestamp 1619712685
update-time 1622810466
capabilities 0x0000001f

In the usbboot directory, when I issue "./rpiboot -d nvme" I receive the error mentioned in the title line.
I have issued the rpiboot commad with the -v switch, alas nothing.
As a result of the above issues, I cannot boot the CM4 with the NVME SSD.

Any pointers/thoughts most welcome. Any further information you need, please let me know.

Regards,

Ry

[Johnnie390]

Update: If I run ./rpiboot boot command with verbosity turned on ie. ./rpiboot -vv -d nvme, the process seems to run into a tight loop -
.
.
.
Found device 2 idVendor=0x04b3 idProduct=0x310b
Bus: 1, Device: 3 Path: 1-1.4
Found device 3 idVendor=0x03f0 idProduct=0x0024
Bus: 1, Device: 4 Path: 1-1.3
Found device 4 idVendor=0x0781 idProduct=0x5583
Bus: 1, Device: 5 Path: 1-1.2
Found device 5 idVendor=0x0424 idProduct=0x2514
Bus: 1, Device: 2 Path: 1-1
Found device 6 idVendor=0x1d6b idProduct=0x0002
Bus: 1, Device: 1 Path: 1
Found device 1 idVendor=0x1d6b idProduct=0x0003
Bus: 2, Device: 1 Path: 2
Found device 2 idVendor=0x04b3 idProduct=0x310b
Bus: 1, Device: 3 Path: 1-1.4
Found device 3 idVendor=0x03f0 idProduct=0x0024
Bus: 1, Device: 4 Path: 1-1.3
Found device 4 idVendor=0x0781 idProduct=0x5583
Bus: 1, Device: 5 Path: 1-1.2
Found device 5 idVendor=0x0424 idProduct=0x2514
Bus: 1, Device: 2 Path: 1-1
Found device 6 idVendor=0x1d6b idProduct=0x0002
Bus: 1, Device: 1 Path: 1
Found device 1 idVendor=0x1d6b idProduct=0x0003
Bus: 2, Device: 1 Path: 2
Found device 2 idVendor=0x04b3 idProduct=0x310b
Bus: 1, Device: 3 Path: 1-1.4
Found device 3 idVendor=0x03f0 idProduct=0x0024
Bus: 1, Device: 4 Path: 1-1.3
Found device 4 idVendor=0x0781 idProduct=0x5583
Bus: 1, Device: 5 Path: 1-1.2
Found device 5 idVendor=0x0424 idProduct=0x2514
Bus: 1, Device: 2 Path: 1-1
Found device 6 idVendor=0x1d6b idProduct=0x0002
Bus: 1, Device: 1 Path: 1
^C
.
.

[philippebourcier]

Same issue here...
...
openat(AT_FDCWD, "/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = 3
...
[pid 824] openat(AT_FDCWD, "/sys/bus/usb/devices/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = 7
[pid 824] fstat64(7, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 824] getdents64(7, /* 6 entries */, 32768) = 160
...
[pid 824] openat(AT_FDCWD, "/sys/bus/usb/devices/1-1/descriptors", O_RDONLY|O_CLOEXEC) = 6
[pid 824] read(6, "\22\1\0\2\t\0\1@@\32\1\1\21\1\0\1\0\1\t\2\31\0\1\1\0\3402\t\4\0\0\1\t\0\0\0\7\5\201\3\1\0\f", 1024)
= 43
[pid 824] close(6) = 0
[pid 824] pipe2([6, 7], O_CLOEXEC) = 0
[pid 824] fcntl64(7, F_GETFL) = 0x1 (flags O_WRONLY)
[pid 824] fcntl64(7, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
[pid 824] write(7, "\1", 1) = 1
[pid 824] timerfd_create(CLOCK_MONOTONIC, TFD_CLOEXEC|TFD_NONBLOCK) = 8
[pid 824] write(1, "Waiting for BCM2835/6/7/2711...", 31Waiting for BCM2835/6/7/2711...) = 31
[pid 824] write(1, "\n", 1
) = 1
[pid 824] recvmsg(3, {msg_namelen=128}, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 824] nanosleep({tv_sec=0, tv_nsec=200000}, NULL) = 0
[pid 824] nanosleep({tv_sec=0, tv_nsec=500000}, NULL) = 0
[pid 824] recvmsg(3, {msg_namelen=128}, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 824] nanosleep({tv_sec=0, tv_nsec=200000}, NULL) = 0
[pid 824] nanosleep({tv_sec=0, tv_nsec=500000}, NULL) = 0
...

It's not a NVMe issue as I also tested on a board without NVMe installed.

The common point between the 2 boards, however is the lack of USB3 ports (on the PCIe bus) as they have been replaced with a NVMe slot.

And btw, I have nothing connected to the USB bus :

lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

[philippebourcier]

I achieved to solve the issue by :

1. Install rpiboot on Windows
2. copy the nvme dir from Linux to Windows
3. run rpiboot -d nvme on Windows

root@DietPiCM4:~# mount -l | grep nvme | cut -f-5 -d" "
/dev/nvme0n1p2 on / type ext4
/dev/nvme0n1p1 on /boot type vfat

So this issue is a Linux-only issue... 🤷‍♂️

[jcorbin]

Same problem when running on a 2GB cm4 lite on a tofu board

./rpiboot -vv -d nvme | head -n40
Boot directory 'nvme'
Loading: nvme/bootcode4.bin
Waiting for BCM2835/6/7/2711...
Found device 1 idVendor=0x3297 idProduct=0x1969
Bus: 1, Device: 5 Path: 1-1.4.4
Found device 2 idVendor=0x047d idProduct=0x8018
Bus: 1, Device: 4 Path: 1-1.4.1
Found device 3 idVendor=0x2109 idProduct=0x2815
Bus: 1, Device: 3 Path: 1-1.4
Found device 4 idVendor=0x0424 idProduct=0x2514
Bus: 1, Device: 2 Path: 1-1
Found device 5 idVendor=0x1d6b idProduct=0x0002
Bus: 1, Device: 1 Path: 1
Found device 1 idVendor=0x3297 idProduct=0x1969
Bus: 1, Device: 5 Path: 1-1.4.4
Found device 2 idVendor=0x047d idProduct=0x8018
Bus: 1, Device: 4 Path: 1-1.4.1
Found device 3 idVendor=0x2109 idProduct=0x2815
Bus: 1, Device: 3 Path: 1-1.4
Found device 4 idVendor=0x0424 idProduct=0x2514
Bus: 1, Device: 2 Path: 1-1
Found device 5 idVendor=0x1d6b idProduct=0x0002
Bus: 1, Device: 1 Path: 1
Found device 1 idVendor=0x3297 idProduct=0x1969
Bus: 1, Device: 5 Path: 1-1.4.4
Found device 2 idVendor=0x047d idProduct=0x8018
Bus: 1, Device: 4 Path: 1-1.4.1
Found device 3 idVendor=0x2109 idProduct=0x2815
Bus: 1, Device: 3 Path: 1-1.4
Found device 4 idVendor=0x0424 idProduct=0x2514
Bus: 1, Device: 2 Path: 1-1
Found device 5 idVendor=0x1d6b idProduct=0x0002
Bus: 1, Device: 1 Path: 1
Found device 1 idVendor=0x3297 idProduct=0x1969
Bus: 1, Device: 5 Path: 1-1.4.4
Found device 2 idVendor=0x047d idProduct=0x8018
Bus: 1, Device: 4 Path: 1-1.4.1
Found device 3 idVendor=0x2109 idProduct=0x2815
Bus: 1, Device: 3 Path: 1-1.4
Found device 4 idVendor=0x0424 idProduct=0x2514

[pelwell]

@Johnnie390 and @jcorbin, where are you running rpiboot? From your descriptions it sounds like you are trying to run it on the CM4. but that's not how it works. In order to update the EEPROM on a CM4 it is necessary to boot the CM4 over USB from a host Pi, PC or Mac - the nvme directory contains the version of the EEPROM image that supports NVME booting.

Looking at the NVME boot documentation I think it assumes that the reader knows what usbboot/rpiboot is in general. I suggest you read the EMMC Flashing guide for the necessary background information.

[Johnnie390]

Hello all,

I am running a CM4 Lite (No eMMC). Is is still necessary to jump throught hoops (i.e. run usbboot from another physical machine) to tweak the EEPROM on a CM4 Lite????

[timg236]

usbboot from a Raspberry Pi 4B is used to program CM4s during manufacturing so it works pretty well. Suggest checking the USB cable and avoid using a HUB

[Johnnie390]

I am (or trying to) run a CM4 Lite !!! No eMMC.

[timg236]

It's exactly the same so long as you have the SD card present.

N.B. There's no support for exporting NVMe drives via USB-MSD - the start.elf (in MSD folder) doesn't know about NVMe drives.

[Johnnie390]

Just over two weeks ago, I was able to change the EEPROM on a CM4 Lite from 29.04.2021 (NVME boot not supported) to 19.05.2021 (NVME boot supported) using this command - rpi-eeprom-update -d -f pieeprom-2021-05-19.bin i.e. no usb cables/usbboot etc. all done on the CM4 (Lite).
In the meantime, I am back on EEPROM level 29.04.2021 (my fault - updates..).
I would like to repeat the process using rpi-eeprom-update procedure but the EEPROM version will stubbornly not change despite messages indicating update success etc.
"root@raspberrypi:/Transit# rpi-eeprom-update -d -f pieeprom-2021-05-19.bin
*** INSTALLING pieeprom-2021-05-19.bin ***

CURRENT: Thu 29 Apr 16:11:25 UTC 2021 (1619712685)
UPDATE: Wed 19 May 15:51:54 UTC 2021 (1621439514)
BOOTFS: /boot

EEPROM updates pending. Please reboot to apply the update.
To cancel a pending update run "sudo rpi-eeprom-update -r"."

Most annoying AND confusing.

[lurch]

I would like to repeat the process using rpi-eeprom-update procedure but the EEPROM version will stubbornly not change despite messages indicating update success etc.

I don't have a CM4 myself, but from what I understand rpi-eeprom-update should warn you that it won't work on a CM4? See https://github.com/raspberrypi/rpi-eeprom/blob/master/rpi-eeprom-update#L495 for more info.

[jcorbin]

@Johnnie390 and @jcorbin, where are you running rpiboot? From your descriptions it sounds like you are trying to run it on the CM4. but that's not how it works. In order to update the EEPROM on a CM4 it is necessary to boot the CM4 over USB from a host Pi, PC or Mac - the nvme directory contains the version of the EEPROM image that supports NVME booting.

Looking at the NVME boot documentation I think it assumes that the reader knows what usbboot/rpiboot is in general. I suggest you read the EMMC Flashing guide for the necessary background information.

Yup, that was my misunderstanding, since my first rodeo with anything raspberry pi at all: trying to get a cm4 on a tofu board with an m.2 nvme working... so I hadn't yet metabolized all of the miles of documentation enough to realize that this tool only runs from a host computer while running the cm4 (for lack of a better term) in slave mode.

I'm not sure if there's a better way to have to tool detect "hey, um friend, it looks like you're running this on the cm4, not against the cm4 from another machine"... maybe at least after say N fails or T time of waiting...

[lurch]

I'm not sure if there's a better way to have to tool detect "hey, um friend, it looks like you're running this on the cm4, not against the cm4 from another machine"

But you might be running rpiboot on one CM4, and using that to update the EEPROM on other CM4s? 🤷

[jcorbin]

I'm not sure if there's a better way to have to tool detect "hey, um friend, it looks like you're running this on the cm4, not against the cm4 from another machine"

But you might be running rpiboot on one CM4, and using that to update the EEPROM on other CM4s? 🤷

Yeah, maybe just a notice in the readme then? I'm not sure I would've realized to read the "Flashing the Compute Module eMMC" wiki until told to do so, since I've got a lite cm4 with no emmc, and thought I was here to "Flash the EEPROM" ;-)