linux/poky.git/meta/recipes-bsp/u-boot/u-boot.inc, branch yocto-5.0.9

u-boot.inc: Refactor do_* steps into functions that can be overridden

2024-08-19T13:09:14+00:00

The looping logic for handling (and not handling) UBOOT_CONFIG has led to the various do_* functions to be large and unwieldy. In order to modify one of the functional blocks inside of a loop (or in the else condition) means you either have to replace the function entirely, or append the function and undo something it did and then do what you need for your change. This refactor breaks out all of the inner loops and else clauses into new functions that themselves can be overridden without needing to worry about the bulk of the looping logic. It should not break any existing recipes doing prepends, appends, or overrides. None of the functional blocks were changed, just refactored out into new functions. Backport from master: https://git.openembedded.org/openembedded-core/commit/?id=937bcc229502fcc154cc676b4fcc93c561873def (From OE-Core rev: bbb8db8fec7fbee56fcdbc665a758b911d73a767) Signed-off-by: Ryan Eatmon Signed-off-by: Steve Sakoman

u-boot: Move UBOOT_INITIAL_ENV back to u-boot.inc

2024-03-03T16:25:20+00:00

Commit cc6c3e31526d ("u-boot: Move definitions to common locations") moved UBOOT_INITIAL_ENV to uboot-config.bbclass, but it should be kept at u-boot.inc because it encodes ${PN} in it, which should be set by the U-Boot recipe. Currently, whatever inherits uboot-config bbclass will fill-in its own PN, which would change the content of UBOOT_INITIAL_ENV per-package. Cc: Klaus Heinrich Kiwi Cc: Marek Vasut Fixes: cc6c3e31526d ("u-boot: Move definitions to common locations") (From OE-Core rev: 0b0c4b37d318b86f100512476ffd861e0ce1f47e) Signed-off-by: Fabio Estevam Signed-off-by: Richard Purdie

u-boot: Pass in prefix mapping variables to the compiler

2024-02-17T18:19:19+00:00

Avoid: u-boot-1_2024.01-r0 do_package_qa: QA Issue: File /boot/u-boot-qemuriscv64-2024.01-r0.elf in package u-boot contains reference to TMPDIR [buildpaths] by ensuring the compiler has the prefix mapping options passed in to it to correctly remap the source paths and avoid the warning. (From OE-Core rev: 85c6b06da641fdaf09f2cfe7066e0cf1185c7969) Signed-off-by: Richard Purdie

u-boot: Map arm64 into map for u-boot dts installation

2023-02-24T13:31:45+00:00

While arm64 is a valid UBOOT_ARCH (according to mkimage -A) u-boot keeps arm64 specific dts under 'arch/arm' directory. As the result the recipe tries to install arch/arm64 (if UBOOT_DTB was specified) and fails with [1]. Remapping "arm64" to "arm" to fix this issue. [1] | install: cannot stat '.../u-boot/1_2023.01-r0/build/arch/arm64/dts/u-boot.dtb': No such file or directory (From OE-Core rev: 3ca99403d5f320c6d7ae59b107f3b3bf183b4089) Signed-off-by: Pavel Zhukov Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

u-boot: Add /boot in SYSROOT_DIRS

2022-11-29T10:29:58+00:00

To be able to use /boot files, like UBOOT_ENV_BINARY, in other recipes, like kernel-fitimage.bbclass. (From OE-Core rev: 5ed129c4e793c76e2ce9c762cc67c4c2232df447) Signed-off-by: Fabre Sébastien Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

u-boot: Rework signing to remove interdependencies

2022-10-26T11:28:40+00:00

The U-Boot signing code is a bit of a mess. The problem is that mkimage determines the public keys to embed into a device tree based on an image that it is signing. This results in all sorts of contortions: U-Boot has to be available to the kernel recipe so that it can have the correct public keys embedded. Then, the signed U-Boot has to be made available to U-Boot's do_deploy. This same dance is then repeated for SPL. To complicate matters, signing for U-Boot and U-Boot SPL is optional, so the whole process must be seamlessly integrated with a non-signed build. The complexity and interdependency of this process makes it difficult to extend. For example, it is not possible to install a signed U-Boot binary into the root filesystem. This is first because u-boot:do_install must run before linux:do_assemble_fitimage, which must run before u-boot:do_deploy. But aside from infrastructure issues, installing a signed U-Boot also can't happen, because the kernel image might have an embedded initramfs (containing the signed U-Boot). However, all of this complexity is accidental. It is not necessary to embed the public keys into U-Boot and sign the kernel in one fell swoop. Instead, we can sign the kernel, stage it, and sign the staged kernel again to embed the public keys into U-Boot [1]. This twice-signed kernel serves only to provide the correct parameters to mkimage, and does not have to be installed or deployed. By cutting the dependency of linux:do_assemble_fitimage on u-boot:do_install, we can drastically simplify the build process, making it much more extensible. The process of doing this conversion is a bit involved, since the U-Boot and Linux recipes are so intertwined at the moment. The most major change is that uboot-sign is no longer inherited by kernel-fitimage. Similarly, all U-Boot-related tasks have been removed from kernel-fitimage. We add a new step to the install task to stage the kernel in /sysroot-only. The logic to disable assemble_fitimage has been removed. We always assemble it, even if the final fitImage will use a bundled initramfs, because U-Boot will need it. On the U-Boot side, much of the churn stems from multiple config support. Previously, we took a fairly ad-hoc approach to UBOOT_CONFIG and UBOOT_MACHINE, introducing for loops wherever we needed to deal with them. However, I have chosen to use a much more structured approach. Each task which needs to use the build directory uses the following pseudocode: do_mytask() { if ${UBOOT_CONFIG}; then for config, type in zip(${UBOOT_CONFIG}, ${UBOOT_MACHINE}); do cd ${config} mytask_helper ${type} done else cd ${B} mytask_helper "" fi } By explicitly placing the work in mytask_helper, we make it easier to ensure that everything is covered, and we also allow bbappends files to more easily extend the task (as otherwise they would need to reimplement the loop themselves). [1] It doesn't particularly matter what we sign. Any FIT will do, but I chose the kernel's because we already went to the trouble of setting it up with the correct hashes and signatures. In the future, we could create a "dummy" image and sign that instead, but it would probably have to happen in the kernel recipe anyway (so we have access to the appropriate variables). (From OE-Core rev: 5e12dc911d0c541f43aa6d0c046fb87e8b7c1f7e) Signed-off-by: Sean Anderson Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

u-boot: Add savedefconfig task

2022-10-25T12:42:03+00:00

Add savedefconfig task which U-Boot supports (unfortunately not all consumers of cml1 support this). (From OE-Core rev: efc54f1f836651c8ef27a683a9e5d583c8ce87a6) Signed-off-by: Alex Kiernan Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

u-boot: Remove duplicate inherit of cml1

2022-10-25T12:42:03+00:00

Splitting u-boot-configure.inc out of the base left duplicate cml1.bbclass in the base include. Fixes: fc9a17ad386c ("u-boot: Split do_configure logic into separate file") (From OE-Core rev: 286f91f7659307bcdf0ba541b8d6b56db5604ceb) Signed-off-by: Alex Kiernan Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

u-boot: Split do_configure logic into separate file

2022-01-20T11:57:29+00:00

Some auxiliary u-boot recipes may need u-boot properly configured (including *.cfg additions via bbappends) but aren't necessarily building u-boot itself; to support such situations, here we split the u-boot do_configure() out of u-boot.inc and into its own u-boot-configure.inc. (From OE-Core rev: e55e6fb4983a41f74c0e457bf54bd8dfa5608daa) Signed-off-by: Zev Weiss Signed-off-by: Richard Purdie

u-boot: Fix syntax error in ${UBOOT_ENV}.scr compilation

2021-10-23T16:42:28+00:00

A previous commit (a3d3c2d4ac421a0dde2a20825eab4434f16b2452) introduced support for compiling a U-Boot boot script, but the logic contained a syntax error which was only visible in the build log. Fix the error by using separate []s for each expression in the if statement. (From OE-Core rev: e33994157abbea897ceaf465f9d2a99a9c8212b1) Signed-off-by: Peter Hoyes Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie