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
