CM5, eMMC and Uboot

[JeanPhilippeLebel]

I'm porting a Yocto-based system from cm4 to cm5. I've got everything working except the uboot on the cm5.

I've updated the uboot to meta-lts-mixins (scarthgap/u-boot), uboot 2024.04.

When I boot the system, I see

RP1_UART 0000001f00030000

being printed over and over again on the debug UART

My config.txt looks like this

      [pi5]
      enable_rp1_uart=1
      pciex4_reset=0
      dtparam=uart0_console
      dtoverlay=uart0
      dtparam=uart0=on

I've read the 2024.04 uboot only supports booting from a SDCard but I was not able to confirm it.

What am I missing?

Thanks!

[tholag]

I don't know if that fixes your specific problem, but the current scarthgap release does include the later U-Boot 2024.07 in receipes-bsp/u-boot. AFAIK, those mix-ins relate to earlier releases or kirkstone.

[JeanPhilippeLebel]

Thanks @tholag for your reply.

I've updated yoky, meta-raspberrypi amd meta-openembeded to the latest scarthgap version.

Using the bitbake-layers show-recipes u-boot command, I have the following results:

with the mixin (scarthgap/u-boot)

=== Matching recipes: ===
u-boot:
  meta-lts-mixins-uboot 1:2024.04
  meta                 1:2024.01

Without

=== Matching recipes: ===
u-boot:
  meta                 1:2024.01

Scarthgap being a LTS version, I would like to stick with it.

Looking at https://layers.openembedded.org/layerindex/recipe/422268/, it seems the Slyhead version has been updated to 2024.07.

I will see if I can upgrade the u-boot to a newer version.

[JeanPhilippeLebel]

@tholag, I've tested with both u-boot 2025.01 and 2025.04 and the behavior is exactly the same.

[tholag]

I'm also struggling with the RP1-support in U-Boot, but UART is deactivated on my CM5 board with CONFIG_BOOTDELAY=-2 and it does boot from the mmc with 2024.07

(This thread is remotely related Compute Module 5 doesn't autoboot without debug UART )

[JeanPhilippeLebel]

Isn't UART (enable_uart=1) required to use the u-boot with meta-raspberrypi?

[tholag]

Yes, and/but adding CONFIG_BOOTDELAY=-2 seems to skip waiting for an actual uart console, see environment, variable "bootdelay".

I have not managed to boot a CM5 with any other value than "-2".

[bergepro]

Yes, and/but adding CONFIG_BOOTDELAY=-2 seems to skip waiting for an actual uart console, see environment, variable "bootdelay".

I have not managed to boot a CM5 with any other value than "-2".

This issue has been driving me nuts. was finally able to get uboot working with this var. Thank you.

[ghmanoj]

@tholag Thanks. I was also having issue with booting CM5. Changing the bootdelay value in u-boot fixed issue for me.

[ghmanoj]

Most of the things works for me. Only error message I am seeing in dmesg now is "failed to contact RP1 firmware" issue. I am not seeing any issue running the system though.

[JeanPhilippeLebel]

Well, you guys are lucky because no matter what, I can't get it to boot using the uboot.

I updated to the latest EEPROM just is case, no difference.

Setting CONFIG_BOOTDELAY=-2, no difference.

Can someone share they config.txt file?

Also, I use MACHINE = 'raspberrypi-armv8' to cover both the cm4 and cm5. Do you think this can be the problem?

[lonhtm]

Without CONFIG_BOOTDELAY=-2, my CM5 was stuck at the uboot logo

After setting this var, it can boot but I could not enter the uboot shell.

[danielfdickinson]

Most of the things works for me. Only error message I am seeing in dmesg now is "failed to contact RP1 firmware" issue. I am not seeing any issue running the system though.

That's a (mostly) cosmetic issue: https://github.com/raspberrypi/linux/issues/6593

[H-Grobben]

Had the same issue: when my debug UART was connected to the CM5 (directly on the debug header) I was able to boot into Linux. Without, or unpowerd debug UART board (LC231X), it did not boot into Linux. As you can't see what happens I hooked up a logic analyzer to the Tx pin of the debug header. It shows that UBoot will detect a key press if the Rx line of the debug header is low, or unconnected.

My fix: in config.txt set 'enable_uart' to 0, despite the recipe requires the uart to be enabled:

https://github.com/agherzan/meta-raspberrypi/commit/8e07f0d328d4aa573bdb1f89cff853ce12602356

So I added this to my rpi-config_%.bbappend file:

do_deploy:append() {
    sed -i 's/^\(enable_uart=1\)/#\1/' "$CONFIG"
}

RPI_EXTRA_CONFIG = "\n\
kernel=u-boot.bin\n\
\n\
enable_uart=0\n\
"

[sahib]

FWIW I have the same (or rather very similar issue: https://github.com/agherzan/meta-raspberrypi/issues/1539). Neither setting CONFIG_BOOTDELAY=-2 or enable_uart=0 seem to help. I do get some some more logs from the rpi-firmware, but none from u-boot.

What I did: Compile latest u-boot git master☨ using the vanilla rpi_arm64_defconfig. I do see the u-boot logo appearing for a brief amount of time, but no logs (neither via vidconsole, uart0 or the classic uart on GPIO14/15). The logo duration does not seem to change no matter what I set bootdelay to (probably indicating that it does fail during pretty early setup.

All in all kinda frustrating by now. Anyone has some ideas that might help me and @JeanPhilippeLebel?

☨: Using:

ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make rpi_arm64_defconfig
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make

[sahib]

Okay, funny enough I do get output on uart10 (i.e. the pins directly on the CM5) when setting this in config.txt:

[cm5]
dtoverlay=dwc2,dr_mode=host

I noticed this when comparing config.txt from an regular PiOS image. For reference, my full config.txt is:

enable_uart=0 # does not seem to be fully required, autoboot can be fixed via bootdelay=-2 as well.
uart_2ndstage=1
kernel=u-boot.bin
arm_64bit=1

[cm5]
dtoverlay=dwc2,dr_mode=host

The actual u-boot issue seems to be related to the u-boot setup script I use, but I can debug that using the logs I got now...

[JeanPhilippeLebel]

@sahib That is a great progress; any conclusion on this?

Thanks,

[sahib]

@JeanPhilippeLebel I've managed to boot it by now. Those were the major things I needed to fix:

• Use kernel 6.12.y, 6.6.y got stuck for me during PCI-e init (suspectedly due to some device tree mismatch between rpi-firmware and kernel)
• Without the dtoverlay=dwc2,dr_mode=host I had no logs from u-boot. I don't really know why that is.
• Since we were using a FIT image (with included device-tree) it needed to match all device-tree overlays sneakily applied by the rpi-firmware.
• u-boot indeed needed the bootdelay=-2 fix to disable the autoboot countdown.
• I had to use console=ttyAMA10 to output logs on the CM5's debug UART. The usualy console=serial0 did not work.

Hope that helps a bit.