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

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

[Richard Purdie]

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.

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.

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.

I think I'm concluding that:

* ARCH from the environment no longer changes u-boot and the comment is wrong
* OE shouldn't/doesn't need to set ARCH
* 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.

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?

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?

Thanks!

Richard

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

[Tom Rini]

[-- 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 --]

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

[Richard Purdie]

On Fri, 2026-07-31 at 09:30 -0600, Tom Rini wrote:
> 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".

Ok, I did think that might be the case.

> > 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.

That is not my experience. With both MACHINE=fvp-base with meta-arm:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/4127

and MACHINE=armuarm64 with oe-core:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/4493

it breaks if I put ARCH in EXTRA_OEMAKE (where ARCH is coming in as
arm64).

> > 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.

Ok, good. That is an easy patch then! :)

> > * 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.

Ok, I can perhaps document that mapping and point at the definitive
list of which values it should return, thanks.

> > 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/

So UBOOT_ARCH_DIR is a smaller subset of UBOOT_ARCH and is the list in
"ls arch". I can document that too I guess which should help the next
person trying to figure this out.

> > 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).

If someone wants to use llvm these days, changing TOOLCHAIN to clang
for u-boot would swap all the CC/LD options behind the scenes. I don't
think u-boot needs to know/care about the KERNEL_CC_* variables and
friends, as far as I can tell it doesn't currently use them either...

Cheers,

Richard