RPI CM5 has 130s delay on boot

RPI CM5 has 130s delay on boot

[andrew]

Hello all,

 

I'm feeling a bit out my depth and hoping someone can help me. We've been
using uboot on the RPI CM4 with great success, it's been perfect.

 

We are migrating some projects to the RPI CM5 but have hit a roadblock. The
boot process regularly (but not always) gets stuck for exactly 130s, as
shown here:

 

[ 3.403341] Waiting for root device /dev/mmcblk0p2...
[ 3.403453] usb 1-1.7: Product: WS170120
[ 3.403454] usb 1-1.7: Manufacturer: WaveShare
[ 3.403455] usb 1-1.7: SerialNumber: 220211
[ 3.429612] input: WaveShare WS170120 Touchscreen as
/devices/platform/axi/1000480000.usb/usb1/1-1/1-1.7/1-1.7:1.0/0003:0EEF:0005
.0001/input/input0
[ 3.443253] hid-generic 0003:0EEF:0005.0001: input,hiddev96,hidraw0: USB HID
v1.11 Device [WaveShare WS170120] on usb-1000480000.usb-1.7/input0
[ 134.202779] mmc0: Command Queue Engine enabled, 16 tags
[ 134.208450] mmc0: new HS400 Enhanced strobe MMC card at address 0001
[ 134.215432] mmcblk0: mmc0:0001 BJTD4R 29.1 GiB
[ 134.221178] mmcblk0: p1 p2 p3 p4 < p5 p6 >
[ 134.226023] mmcblk0: mmc0:0001 BJTD4R 29.1 GiB
[ 134.230952] mmcblk0boot0: mmc0:0001 BJTD4R 4.00 MiB

 

After searching, this appears to be the same issue as reported here:

 

https://lore.kernel.org/u-boot/421019670.5226453.1745000686387@mail.yahoo.co
m/

 

but I cannot see any solution. Can anyone assist please?

 

KR, Andrew

 

 

Re: RPI CM5 has 130s delay on boot

[Peter Robinson]

Hi Andrew,

Sorry for the delayed reply.

> I'm feeling a bit out my depth and hoping someone can help me. We've been
> using uboot on the RPI CM4 with great success, it's been perfect.
>
> We are migrating some projects to the RPI CM5 but have hit a roadblock. The
> boot process regularly (but not always) gets stuck for exactly 130s, as
> shown here:

So I don't have a CM5, only a couple of RPi5s, the early and later
revs, for U-Boot testing/development.



> [ 3.403341] Waiting for root device /dev/mmcblk0p2...
> [ 3.403453] usb 1-1.7: Product: WS170120
> [ 3.403454] usb 1-1.7: Manufacturer: WaveShare
> [ 3.403455] usb 1-1.7: SerialNumber: 220211
> [ 3.429612] input: WaveShare WS170120 Touchscreen as
> /devices/platform/axi/1000480000.usb/usb1/1-1/1-1.7/1-1.7:1.0/0003:0EEF:0005
> .0001/input/input0
> [ 3.443253] hid-generic 0003:0EEF:0005.0001: input,hiddev96,hidraw0: USB HID
> v1.11 Device [WaveShare WS170120] on usb-1000480000.usb-1.7/input0
> [ 134.202779] mmc0: Command Queue Engine enabled, 16 tags
> [ 134.208450] mmc0: new HS400 Enhanced strobe MMC card at address 0001
> [ 134.215432] mmcblk0: mmc0:0001 BJTD4R 29.1 GiB
> [ 134.221178] mmcblk0: p1 p2 p3 p4 < p5 p6 >
> [ 134.226023] mmcblk0: mmc0:0001 BJTD4R 29.1 GiB
> [ 134.230952] mmcblk0boot0: mmc0:0001 BJTD4R 4.00 MiB
>
>
>
> After searching, this appears to be the same issue as reported here:
>
>
>
> https://lore.kernel.org/u-boot/421019670.5226453.1745000686387@mail.yahoo.co
> m/
>
>
>
> but I cannot see any solution. Can anyone assist please?

Is this the eMMC that's built into the SoM or is it external on a
carrier board? Can you provide more details.

On the RPi5 the uSD slot is using the SoC built in controller, I
presume that's the case on the CM5 or whatever you're using as the RP1
needs to be bought up first. We don't currently support the RP1 in
U-Boot so I'm not sure that's coming into play, I suspect purely the
SDHCI controllers.

Unfortunately the details of most of the broadcom chips are closed and
even the RPi U-Boot maintainers don't have access to those so we might
be at a bit of a loss ATM.

RE: RPI CM5 has 130s delay on boot

[andrew]

Hi Peter,

Thanks for talking the time to reply.

The boot delay went away after changing the kernel command line console setting. Previously it was on ttyAMA0, setting it to serial0 (ttyAMA10?) which is the debug uart.

I'm not clear on why - but I was happy it resolved and we can continue!

Kind regards, Andy

-----Original Message-----
From: Peter Robinson <pbrobinson@gmail.com>
Sent: 28 August 2025 10:17
To: andrew@race-technology.com
Cc: u-boot@lists.denx.de
Subject: Re: RPI CM5 has 130s delay on boot

Hi Andrew,

Sorry for the delayed reply.

> I'm feeling a bit out my depth and hoping someone can help me. We've 
> been using uboot on the RPI CM4 with great success, it's been perfect.
>
> We are migrating some projects to the RPI CM5 but have hit a 
> roadblock. The boot process regularly (but not always) gets stuck for 
> exactly 130s, as shown here:

So I don't have a CM5, only a couple of RPi5s, the early and later revs, for U-Boot testing/development.



> [ 3.403341] Waiting for root device /dev/mmcblk0p2...
> [ 3.403453] usb 1-1.7: Product: WS170120 [ 3.403454] usb 1-1.7: 
> Manufacturer: WaveShare [ 3.403455] usb 1-1.7: SerialNumber: 220211 [ 
> 3.429612] input: WaveShare WS170120 Touchscreen as 
> /devices/platform/axi/1000480000.usb/usb1/1-1/1-1.7/1-1.7:1.0/0003:0EE
> F:0005
> .0001/input/input0
> [ 3.443253] hid-generic 0003:0EEF:0005.0001: input,hiddev96,hidraw0: 
> USB HID
> v1.11 Device [WaveShare WS170120] on usb-1000480000.usb-1.7/input0 [ 
> 134.202779] mmc0: Command Queue Engine enabled, 16 tags [ 134.208450]
> mmc0: new HS400 Enhanced strobe MMC card at address 0001 [ 134.215432]
> mmcblk0: mmc0:0001 BJTD4R 29.1 GiB [ 134.221178] mmcblk0: p1 p2 p3 p4 
> < p5 p6 > [ 134.226023] mmcblk0: mmc0:0001 BJTD4R 29.1 GiB [ 
> 134.230952] mmcblk0boot0: mmc0:0001 BJTD4R 4.00 MiB
>
>
>
> After searching, this appears to be the same issue as reported here:
>
>
>
> https://lore.kernel.org/u-boot/421019670.5226453.1745000686387@mail.ya
> hoo.co
> m/
>
>
>
> but I cannot see any solution. Can anyone assist please?

Is this the eMMC that's built into the SoM or is it external on a carrier board? Can you provide more details.

On the RPi5 the uSD slot is using the SoC built in controller, I presume that's the case on the CM5 or whatever you're using as the RP1 needs to be bought up first. We don't currently support the RP1 in U-Boot so I'm not sure that's coming into play, I suspect purely the SDHCI controllers.

Unfortunately the details of most of the broadcom chips are closed and even the RPi U-Boot maintainers don't have access to those so we might be at a bit of a loss ATM.