[Buildroot] [PATCH] linux: Fix powerpc64le defconfig selection

[Michael Ellerman]

Arnout Vandecappelle <arnout at mind.be> writes:
> On 16/05/2022 15:17, Michael Ellerman wrote:
>> Arnout Vandecappelle <arnout at mind.be> writes:
>>> On 10/05/2022 04:20, Joel Stanley wrote:
>>>> The default defconfig target for the 64 bit powerpc kernel is
>>>> ppc64_defconfig, the big endian configuration.
>>>>
>>>> When building for powerpc64le users want the little endian kernel as
>>>> they can't boot LE userspace on a BE kernel.
>>>>
>>>> Fix up the defconfig used in this case. This will avoid the following
>>>> autobuilder failure:
>>>>
>>>>    VDSO32A arch/powerpc/kernel/vdso32/sigtramp.o
>>>>    cc1: error: ‘-m32’ not supported in this configuratioin
>>>>    make[4]: *** [arch/powerpc/kernel/vdso32/Makefile:49: arch/powerpc/kernel/vdso32/sigtramp.o] Error 1
>>>>
>>>>    http://autobuild.buildroot.net/results/dd76d53bab56470c0b83e296872d7bb90f9e8296/
>>>>
>>>> Note that the failure indicates the toolchain is configured to disable
>>>> the 32 bit target, causing the kernel to fail when building the 32 bit
>>>> VDSO. This is only a problem on the BE kernel as the LE kernel disables
>>>> CONFIG_COMPAT, aka 32 bit userspace support, by default.
>>>>
>>>> Signed-off-by: Joel Stanley <joel at jms.id.au>
>>>
>>>    Applied to master, thanks. However, the defconfig mechanism for *all* powerpc
>>> seems pretty broken. Here's what we have in 5.16, before that there was
>>> something similar:
>>>
>>> # If we're on a ppc/ppc64/ppc64le machine use that defconfig, otherwise just use
>>> # ppc64_defconfig because we have nothing better to go on.
>>> uname := $(shell uname -m)
>>> KBUILD_DEFCONFIG := $(if $(filter ppc%,$(uname)),$(uname),ppc64)_defconfig
>>>
>>>    So I guess we should use a specific defconfig for *all* powerpc.
>>>
>>>    The arch-default defconfig is generally not really reliable, for example for
>>> arm it always takes v7_multi, but that won't work for v7m targets...
>> 
>> There's a fundamental problem that just the "arch" is not sufficient
>> detail when you're building a kernel.
>
>   Yes, which is pretty much unavoidable.
>
>> Two CPUs that implement the same user-visible "arch" may differ enough
>> at the kernel level to require a different defconfig.
>> 
>> Having said that I think we could handle this better in the powerpc
>> kernel. Other arches allow specifying a different value for ARCH, which
>> then is fed into the defconfig.
>
>   I don't know if it's worth bothering with that. It certainly would not make 
> our life easier, because it would mean we need to set ARCH correctly. If we can 
> do that, we can just as well set the defconfig correctly.

OK.

>> That way you could at least pass ARCH=ppc/ppc64/ppc64le, and get an
>> appropriate defconfig.
>> 
>> I'll work on some kernel changes for that.
>
>   I think the most important thing is that it makes no sense to rely on uname 
> when ARCH and/or CROSS_COMPILE are set.

I'm not sure I entirely agree.

Neither ARCH or CROSS_COMPILE give us enough information to know which
defconfig to use, so we still have to guess somehow.

CROSS_COMPILE can be set even when you're building on ppc, it's the
easiest way to specfiy a different toolchain from the default.

cheers