[OE-core] [PATCH] Revert "kernel-arch.bbclass: add arm64 support to U-Boot architecture map"
Koen Kooi
koen.kooi at linaro.org
Wed Apr 22 07:48:02 UTC 2015
> Op 22 apr. 2015, om 09:18 heeft Koen Kooi <koen.kooi at linaro.org> het volgende geschreven:
>
>
>> Op 19 feb. 2015, om 04:34 heeft Nathan Rossi <nathan.rossi at xilinx.com> het volgende geschreven:
>>
>> This reverts commit 0b891265716c414ade29d587fc1a3c4ea7beadbe.
>>
>> U-Boot does support AArch64, this however was only added to newer
>> versions of U-Boot and at the time of this original commit the U-Boot in
>> OE-Core did not support the 'arm64' architecture. OE-Core now has a
>> newer version of U-Boot for the mkimage recipe and thus supports the
>> 'arm64' architecture.
>>
>> Signed-off-by: Nathan Rossi <nathan.rossi at xilinx.com>
>> ---
>> meta/classes/kernel-arch.bbclass | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
>> index bbcfa15..6a6ad91 100644
>> --- a/meta/classes/kernel-arch.bbclass
>> +++ b/meta/classes/kernel-arch.bbclass
>> @@ -40,7 +40,6 @@ def map_uboot_arch(a, d):
>>
>> if re.match('p(pc|owerpc)(|64)', a): return 'ppc'
>> elif re.match('i.86$', a): return 'x86'
>> - elif re.match('arm64$', a): return 'arm'
>> return a
>
> I just debugged a boot failure to this revert. The machine in question is using u-boot 2013.04 + vendor patches and can’t be replaced at this time. I get that OE doesn’t care about vendor trees using obsolete versions, but this case is extra annoying because a few lines later this bbclass does:
>
> export UBOOT_ARCH = "${@map_uboot_arch(d.getVar('ARCH', True), d)}"
>
> instead of:
>
> export UBOOT_ARCH ?= "${@map_uboot_arch(d.getVar('ARCH', True), d)}"
>
> So now I’m forced to overlay kernel-arch.bbclass with the revert reverted and hope I don’t get any machines with a recent u-boot. Having said all that, modern uboots should default to zImage for arm32 and Image for aarch64 and have CONFIG_SUPPORT_RAW_INITRD enabled so mkimage isn;t needed anymore.
>
> So, opinions on weakly assigning UBOOT_ARCH?
Nathan corrected my thinko:
09:25 < nrossi> just curious around the UBOOT_ARCH, does overriding it work? as in UBOOT_ARCH_<machine> = "foo"
09:26 * koen tries
09:38 < nrossi> koen: i think changing it to a ?= for the future is probably worth it. But i imagine getting that change backported would be a pain
09:40 < koen> UBOOT_ARCH_aarch64 = "arm" in local.conf also seems to work
09:41 < koen> I never realized that would take precedence over python methods
09:41 < nrossi> well its not the python method that is setting it
09:42 < koen> ah, right
09:42 < koen> it's set using a method, not by the method
So I don’t need the class overlay anymore!
More information about the Openembedded-core
mailing list