I am working on a device built around a raspberry pi CM3+ module
after migrating our yocto project from dunfell to kirkstone it is impossible to use u-boot and get a starting device. I have no output on my terminal, and the device is not reachable from outside (which it normally is)
The mender tag we use in the project before migration is dunfell-v2022.04
The required syntax changes for kirkstone have been applied, and the image i am building builds with no errors.
The local.conf used for the image is not changed regarding the mender parts (except for the increased boot partition)
there are no changes to any of the recipes used, and the board starts if I do not issue RPI_USE_U_BOOT = “1” in the local.conf file, and after building change the file cmdline.txt to use /dev/mmcblk0p2 instead of ${mender_kernel_root}.
the change in cmdline.txt I made because the dmesg came up with:
waiting for root device ${mender_kernel_root} where I think ${mender_kernel_root} should have been replaced with the partition that mender indicates as active.
I read the mender kirkstone release notes but could not find any quirks there that indicate u-boot may cause troubles on kirkstone in our project.
I am kind of lost here, so any advice pointing me in the right direction is welcome.
Am I missing some mender variables maybe?
If more information is required regarding the configuration please ask.
in the local conf I already have the line:
INHERIT:append = " image-buildinfo mender-full rpi-update-firmware"
and I also tried a build without this script. With the same result.
I suspect it is more the incompatibility issue of mender client (v3.3.0) with kirkstone that plays it’s fiddle.
(I read about that in Mender-client fails to build on kirkstone for qemux86-64)
I don’t get build errors however.
I will look into the patch mentioned in that thread tomorrow, to see if it makes a difference.
Building and deploying a bare yocto-built image without mender brings the same results. so I guess it’s a u-boot problem rather than a mender problem.
A core-image-base with RPI_USE_U_BOOT = “1” set, renders a not booting device, without it, it boots…
@oleorhagen , I don’t know yet. at the moment I am not working on the issue.
When the issue is resolved I will post here as soon as I am working on this again.
Hi, i know this is an old topic but since we struggle with the same problem, i will share our solution with you.
We figured out that we had to add the CONFIG_OF_BOARD=y parameter to the u-boot/config/rpi_3_32b_defconfig file.
You can do this simply with Yoctos patch functionality.