Closed malyjak closed 1 year ago
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.
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?
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.
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.
Right. So that shows another issue. Maybe you don't set the console on tty1? I can't remember what is the default.
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.
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:
oe-init-build-env
to new build dirMACHINE ??= "raspberrypi4-64"
in local.confRPI_USE_U_BOOT = "1"
to local.confbitbake core-image-base
core-image-base-raspberrypi4-64.wic.bz2
, flashit to the SD card, and boot up the RPiDescribe 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.