I am trying to build an image on a new Raspberry Pi 5 Model B Rev 1.1. But after using mender-convert and flashing the image on the SD card, the RPi is stuck on the U-Boot logo
The same image works with both Raspberry Pi 5 Model B Rev 1.0 and Raspberry Pi 4
Thanks for the comment! I had to look up, but the overlays/bcm2712d0.dtbo is present.
While debugging the above, I removed the following in config.txt:
[all]
kernel=kernel8.img
Or modified it to:
[all]
kernel=kernel_2712.img
On the flashed SD card. In either case, it uses kernel_2712.img to boot, and I am no longer getting stuck on the U-Boot logo.
However, now I am facing another issue where the ${mender_kernel_root} in cmdline.txt isn’t being resolved. Here is my cmdline.txt:
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount... Begin: Resizing root filesystem...\n\nDepending on storage size and speed, this may take a while.... lsblk: ${mender_kernel_root}: not a block device
done.
Begin: Will now check root file system... fsck from util-linux 2.38.1
Checking all file systems.
done.
3.302873] ${mender_kernel_root}: Can't lookup blockdev
mount: mounting ${mender kernel_root} on /root failed: No such file or directory
Failed to mount ${mender_kernel_root} as root file system.
Modifying to root=/dev/mmcblk0p2 in cmdline.txt works, but this will break the rootfs updates. Any help or suggestions on how to fix this? Thanks!
I suspected that this was happening since overriding the RASPBERRYPI_KERNEL_IMAGE to kernel_2712.img was also causing the RPI to get stuck at the U-Boot logo. When the RPI gets stuck at the U-Boot logo, I am unable to see any logs on the serial console.
I ran into the same issue when I tried to convert an image for the RevPi 5.
The only way I have found so far to get around it is to disable UART by changing enable_uart=1 to 0 in the config.txt on the firmware partition. I read somewhere that UBOOT gets stuck if anything is transmitting via UART during boot, which some of the Kunbus devices seem to do.
Unfortunately, that approach seems to break a lot of functionality (including login…). Hope you’ll have more luck than I did
I’m trying to determine if it’s possible to use the same image for both the RPi 4 and RPi 5. I also want to know what could break if the UART is disabled, and if there are any permanent solutions.
I ran into that problem yesterday, while getting my cm5
up and running.
The problem was in the boot.scr, which loads the bootargs from the cmdline.txt, before executing mender_setup and then never writes them back …
so still ${mender_kernel_root} is used instead of the interpolated version.
the fix is to write a new boot.cmd and make an boot.scr from it.
here’s mine, if you wanna give it a try …
content of boot.cmd:
fdt addr ${fdt_addr}
fdt move ${fdt_addr} ${fdt_addr_r}
fdt get value bootargs /chosen bootargs
run mender_setup
setenv bootargs “${bootargs}”
mmc dev ${mender_uboot_dev}
mw.w ${kernel_addr_r} 0x8b1f
if load ${mender_uboot_root} ${ramdisk_addr_r} /boot/vmlinuz; then
if cmp.w ${kernel_addr_r} ${ramdisk_addr_r} 1; then
echo “Decompressing kernel…”
unzip ${ramdisk_addr_r} ${kernel_addr_r}
else
echo “Copying kernel…”
cp.b ${ramdisk_addr_r} ${kernel_addr_r} ${filesize}
fi
if load ${mender_uboot_root} ${ramdisk_addr_r} /boot/initrd.img; then
setenv ramdisk_param “${ramdisk_addr_r}:${filesize}”
else
setenv ramdisk_param “-”
fi
booti ${kernel_addr_r} ${ramdisk_param} ${fdt_addr_r}
fi
run mender_try_to_recover
and that’s how to make a boot.scr from it, which needs to get placed next to the u-boot.bin (boot partition)
mkimage -A arm64 -T script -C none -n “Boot script” -d boot.cmd boot.scr
