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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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