Arnout Vandecappelle <arn...@mind.be> writes: > On 16/05/2022 15:17, Michael Ellerman wrote: >> Arnout Vandecappelle <arn...@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 <j...@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