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
