Raspbian for Robots boot stalls at "mmc1: new high speed SDIO card at address 0001"

GoPiGo
,
1

Greetings!

I am trying to create a different kind of multi-boot environment and I am stuck.

First: I know this works because I tried it before with a different version of Raspbian, (the plain vanilla 32 and 64 bit versions of Raspbian).

Now I have extended this to contain

  • Raspbian for Robots buster
  • GoPiGo O/S 3.0
  • Full up latest version of Raspberry Pi O/S 32 bit
  • Full up latest version of Raspberry Pi O/S 64 bit.

Previously, except for some PARTUUID errors, (silly me!), everything was golden.

Today while trying to boot R4R for the first time I am getting as far as

mmc1: new high speed SDIO card at address 0001
random: crng init done

Without typing in the entire screen, the last few messages are:

mc1: queuing unknown CIS tuple 0x80 (3 bytes)
mmc0 SDHCI controller on fe340000.emmc2 [fe340000.emmc2] using ADMA
of_cfs_init
of_cfs_init: OK
Waiting for root device PARTUUID=0df6e72d-05
random: fast init done
mmc1: new high speed SDIO card at address 0001
random: crng init done

It has been sitting for about five minutes.

I don’t know if it’s still waiting for the root device or something else is the problem.

Any help would be gratefully appreciated.

Update:
It appears that the latest, as-released, version of Raspbian for Robots (2019-12-12 or thereabouts) does not have boot files compatible with booting directly to a USB device.  What puzzled me is that I’ve been booting R4R to a USB device for a while now - so why should R4R “suddenly” stop working?

I do not know this for a fact, but I strongly suspect that subsequent upgrades to the system since the original installation to its SD card updated the boot files and configuration to make it compatible.

Copying all the “fixup[xx]” and start[xxx].elf files from GoPiGo O/S’s boot partition to the boot partition of Raspbian for Robots, appears to “fix” the problem.

Note that I have not yet tried this with anything other than a Pi-4 4gb system.

1 Like
2

After some thought, I have decided that the above description requires some correction and amplification as I forgot to include parts of the issue.

First:
The original, as shipped, Raspbian for Robots will not boot at all, failing with a boot message that the start4.elf and it’s associated fixups file are “too old” and are (apparently) not compatible with a direct-to-USB boot.  (Earlier versions of Raspbian required a two-step boot process starting with a boot from SD card that then transferred control to the USB device.)

Second:
To fix this, I copied over the start[xx].elf files and the associated fixup files from the most recent version of Raspbian (32 bit) and tried to boot again.  This time it failed with the issue noted above.

Third:
I then tried by copying over an older, (but more recent), version of these files from the GoPiGo O/S 3.0.  This appears to work, but creates it’s own subtle set of issues.  Apparently what is needed is an updated set of boot files in the initial boot partition, followed by the original boot files in the target boot partition that you boot into.

More as I learn more.

1 Like
3

Hey there,

I had noticed this post when I had encountered this error on trying to USB boot the latest mainline linux kernel with Rpi OS on my Raspberry Pi 3B+. I’m not very sure about your setup (aka R4R) or if this is relevant to you but I’ll just add it here incase someone finds it helpful:

So I had tested this out a bit more at my end and had noticed the following behaviour:

  1. USB boot + 32 bit kernel does not work on any kernel version after v5.12 (Fails with the exact same behaviour you described in the original post)
  2. USB + 64 bit kernel works perfectly on all the newer version v5.13 onwards
  3. SD card + 32 bit works perfectly as well

I talked to the folks over at the kernel mailing list and it seems like this issue was caused after the following commit in the kernel:

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?id=ea718c699055c8566eb64432388a04974c43b2ea

This commit is from March 2021.

I’m not sure which kernel version you were using but maybe it has this commit and hence causing issues. They suggested to add the following line to config.txt which should help bypass the issue, till its fixed:

fw_devlink=permissive

Regards,
ojas

1 Like
4

Great find!

I’m going to have to put this into my “Book of Magic Spells” :wink: so I can find it later.

Two big, BIG thumbs up!
:+1: :+1:

1 Like
5

Thanks, glad I could help :slight_smile:

1 Like
6

Just a small edit about 64bit kernel part, I realised I was testing this a bit wrong hence this is still unconfirmed and I’m not sure if 64bit works with USB boot with newer kernels, or not. Everything else in my reply should still hold

1 Like