Re: makefile confusion about configuring u-boot in OE (ARCH and UBOOT_ARCH)

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 4543 bytes --]

On Fri, Jul 31, 2026 at 04:01:06PM +0100, Richard Purdie wrote:
> Hi,
> 
> I'm trying to clean up some class code in openembedded-core and I'm
> getting confused about what the "docs" say I should do vs. what the
> code does (vs. what OE does).
> 
> https://github.com/u-boot/u-boot/blob/main/Makefile#L381C1-L399C20
> Makefile in u-boot says:
> 
> """
> # Cross compiling and selecting different set of gcc/bin-utils
> # ---------------------------------------------------------------------------
> #
> # When performing cross compilation for other architectures ARCH shall be set
> # to the target architecture. (See arch/* for the possibilities).
> # ARCH can be set during invocation of make:
> # make ARCH=ia64
> # Another way is to have ARCH set in the environment.
> # The default ARCH is the host where make is executed.
> 
> # CROSS_COMPILE specify the prefix used for all executables used
> # during compilation. Only gcc and related bin-utils executables
> # are prefixed with $(CROSS_COMPILE).
> # CROSS_COMPILE can be set on the command line
> # make CROSS_COMPILE=ia64-linux-
> # Alternatively CROSS_COMPILE can be set in the environment.
> # Default value for CROSS_COMPILE is not to prefix executables
> # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
> ARCH		?= $(SUBARCH)
> """
> 
> so that implies that ARCH from the environment would configure u-boot.
> Fine.

But is unfortunately a relic of our "copy the kernel Kbuild files in".

> kernel-arch.bbclass in OE exports ARCH and UBOOT_ARCH.
> 
> I want to stop u-boot.inc inheriting kernel-arch since I'm not
> convinced it is entirely compatible and we need to make changes there
> which we don't want to affect u-boot.

It's not entirely compatible, true. It's largely (for values of being a
few years behind in kernel releases, but not as bad as we were at the
start of this year).

> I therefore naively changed u-boot.inc:
> 
> -EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} V=1'
> +EXTRA_OEMAKE = 'ARCH=${@oe.kernel.map_kernel_arch(d)} CROSS_COMPILE=${TARGET_PREFIX} V=1'
> 
> This proceeded to break all our u-boot recipes.

Now that's interesting. For U-Boot, "ARCH" is meaningless. Whereas in
the kernel you have to set ARCH, it's just a Kconfig question in U-Boot.
Usually it's harmless to set.

> I think I'm concluding that:
> 
> * ARCH from the environment no longer changes u-boot and the comment is wrong

The comment is wrong and I don't think it's ever really mattered, but
there's times when it's been non-harmful.

> * OE shouldn't/doesn't need to set ARCH

Correct.

> * we should just drop most of this from u-boot
> 
> That brings me to UBOOT_ARCH, which takes ARCH and does:
> 
>     if   re.match('p(pc|owerpc)(|64)', a): return 'ppc'
>     elif re.match('i.86$', a): return 'x86'
>     return a
> 
> on it. We generally use UBOOT_ARCH with mkimage, e.g. "uboot-mkimage -A
> ${UBOOT_ARCH}". We then have code which does:
> 
>     UBOOT_ARCH_DIR = "${@'arm' if d.getVar('UBOOT_ARCH').startswith('arm') else d.getVar('UBOOT_ARCH')}"
> 
> to find code u-boot which implies UBOOT_ARCH might not be right.

So, for passing the architecture value to mkimage:
https://git.u-boot-project.org/u-boot/u-boot/-/blob/main/boot/image.c?ref_type=heads#L62
is the map between strings and values. PowerPC probably still needs a
fixup if powerpc64 is something that needs to be mapped.

> Am I right in thinking the valid values for UBOOT_ARCH are "ls arch" in
> the u-boot tree? 
> If so, the arm values in that function look dubious in that arm64
> shouldn't ever be there for example?

Exactly. arm64 is a valid UBOOT_ARCH but is under arch/arm/

> I'm no u-boot expert, I do know something about the OE classes and
> build processes and this all looks a bit of a mess to me. Can anyone
> with a bit more experience tell me if I am missing something obvious
> here and if this is as much of a mess as I think it is?

It's certainly a bit muddy here at times, yes. We use Kconfig to
configure things, and we're a little behind but that language doesn't
evolve quickly either. We use the Kbuild infrastructure to build, but
we're lagging behind and don't use all the features of the kernel
either. We likely use little enough of them that it would make more
sense to just set CROSS_COMPILE as needed via EXTRA_OEMAKE (unless
someone is aiming to build with llvm instead, and so the KERNEL_CC,
KERNEL_LD, etc, options).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]