[Kirkstone] Raspberry Pi 4B u-boot not working

[malyjak]

Description

After adding RPI_USE_U_BOOT = "1" to local.conf the board is stuck at boot with no additional info.

Steps to reproduce the issue:

1. checkout poky, meta-openembedded, and meta-raspberrypi to Kirkstone
2. source oe-init-build-env to new build dir
3. set MACHINE ??= "raspberrypi4-64" in local.conf
4. add RPI_USE_U_BOOT = "1" to local.conf
5. bitbake core-image-base
6. decompress core-image-base-raspberrypi4-64.wic.bz2, flashit to the SD card, and boot up the RPi

Describe the results you received: Gray screen with no output

Describe the results you expected: To see some error output / generic booting process

Additional information you deem important (e.g. issue happens only occasionally): Without adding RPI_USE_U_BOOT = "1", using the default bootloader, the board boots successfully.

Additional details (revisions used, host distro, etc.): I found similar issue for but it was never properly resolved. When I checked other linked issue it was a completely different problem related to uart. This problem I'm encountering seems more like u-boot binary is completely broken, since it should at least display some error like 'wrong configuration' or 'kernel image not found' or 'device tree binary not found' - which I get if I manually cross-compile u-boot for rpi4-64 without yocto and flash it to clean boot partition with necessary config files.

[agherzan]

The u-boot support is not actively maintained anymore. We need someone to pick this up if the community is still interested in it. I personally don't use u-boot but I know that some downstream users do so I suspect that we miss fixes of some sort.

[malyjak]

I fully understand. However, since we want to use SWUpdate in our project we are strongly bounded to u-boot. After some digging I've noticed few strange things:

1) config.txt was missing some important lines so I created a custom one as:

$ cat << EOF > config.txt
enable_uart=1
arm_64bit=1
kernel=u-boot.bin
EOF

and copied it to the boot partition on SD card.

2) u-boot.bin was missing completely, so I copied it from tmp/deploy/images/raspberrypi-4-64 folder to the boot partition as well.

After these steps, everything started working properly. I was able to see u-boot log, kernel log, and was dropped directly to login prompt.

Now the question is if this is a proper solution with relation to the meta-raspberrypi layer. I tried to dig up files where u-boot.bin is handled and if I understand things right, it's being copied to kernel8.img (in case of 64bit RPi4) together with boot.scr (and initramfs if enabled). However, this kernel8.img is not specified in the config.txt, so how exactly was it intended to execute u-boot binary?

[agherzan]

This should be fixed as per https://github.com/raspberrypi/firmware/issues/1193. Maybe we have a regression in the firmware? Could you check this issue? That's my best guess now.

[malyjak]

After doing some more tests it seems that u-boot located within the kernel8.img is working and actually loads the kernel image properly. As noted in the issue you linked, these extra lines aren't necessary anymore. So I stick with the generated config.txt and there is no problem with it apparently, since the UART communication is working completely fine. And that's the weird thing. I can see all the logs and access the system when using the UART but once I switch back to the HDMI and the keyboard, I can only see the grey screen.

I tried to play more with config.txt. options for the RPi, regarding the HDMI, such as:

hdmi_safe
hdmi_force_hotplug

but without any success so far. I'm worried my knowledge will not be enough to solve this issue, since I know absolutely nothing how displays are handled in the kernel / RPi. My best guess would be this quote from Official Documentation

When using the VC4 KMS graphics driver, the complete display pipeline is managed by Linux - this includes the HDMI outputs. These settings only apply to the legacy FKMS and firmware-based graphics driver.

[agherzan]

Right. So that shows another issue. Maybe you don't set the console on tty1? I can't remember what is the default.

[wesQ3]

Hi I am also starting a project that will rely on swupdate and thus need u-boot for dual-image updates. We are using MACHINE=raspberrypi4 rather than the 64 bit version. (We selected swupdate as our updater (and thus u-boot) based on the choice of the Linux Foundation Civil Infrastructure Platform software updater)

I found when enabling RPI_USE_U_BOOT = "1", I also encountered a blank screen on boot. When enabling uart to start debugging, I found that the device will boot to my Xorg target if I also use enable_uart=1. I wasn't able to pinpoint the interaction that made this combination of config work, but I have settled on it as a workaround.