Allow UBOOT without UART on pi 5 - #1623
Faalangst26 wants to merge 3 commits into
Conversation
| KERNEL_BOOTCMD ?= "booti" | ||
|
|
||
| UBOOT_MACHINE = "rpi_arm64_config" | ||
| UBOOT_MACHINE = "rpi_5_arm64_config" |
There was a problem hiding this comment.
UBOOT_MACHINE is used to specify configuration of U-Boot. rpi_arm64_config is the same as rpi_arm64_defconfig and is a valid configuration for U-Boot.
rpi_5_arm64_config doesn't exist. So this change breaks u-boot build.
There was a problem hiding this comment.
Shoot! Must've been my build cache, because it works on my end.
Would it be an idea to add an extra variable like
'U_BOOT_REQUIRES_UART'
And check on that? That'd avoid influencing other processes.
I'd be happy to update the PR.
There was a problem hiding this comment.
Sounds good. TBH checking UBOOT_MACHINE in rpi-config looks weird. So something like this would be better (sorry if indentation is broken, typing from the phone):
if [ $RPI_USE_U_BOOT = 1 ] && [ $UBOOT_REQUIRES_UART = 1 ] && [ $ENABLE_UART != 1 ]; then
bbfatal "..."
fi
But maybe maintainers have a better idea.
…t combo. - Don't abuse the UBOOT_MACHINE variable as it gets used by the UBOOT build process. - Add the U_BOOT_REQUIRES_UART to all machine confs, setting in to "1" on all except for the Pi 5, maybe other types also don't require it?
|
Changed the U_BOOT_MACHINE config back to the existing |
|
@Faalangst26 could you please update your commits according to the contribution guides in the repo? (Messages, signed-off-by etc) I see it as 2 commits:
The first commit can be dropped. |
Fixes #1582
Like @tjallingt, I noticed that disabling UART when using UBOOT causes the build to fail when building for the pi 5. This whilst on pi 5 it is explicitly supported to do so according to the docs:
https://meta-raspberrypi.readthedocs.io/en/latest/extra-build-config.html#boot-to-u-boot
In my own testing, I found that the pi 5 actually refuses to boot on kernel 6.18 when UART and UBOOT are both enabled in combination with the RAUC layer. Disabling the UART fixes this.
- What I did
Changed the machine config for pi 5 to use an unique UBOOT_MACHINE target, instead of sharing it with pi 1, 2 and 3.
- How I did it
Updated the value in conf/machine/raspberrypi5.conf, this causes the case in the URAT check in the rpi_config_git.bb to fall through, and continue to build, without altering other variables.
I did a global search in the project for other places UBOOT_MACHINE is used, and found no other references, so I believe it is safe to update it here.