All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Stanley <joel@jms.id.au>
To: Arnout Vandecappelle <arnout@mind.be>
Cc: Michael Ellerman <mpe@ellerman.id.au>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH] linux: Fix powerpc64le defconfig selection
Date: Tue, 17 May 2022 06:13:39 +0000	[thread overview]
Message-ID: <CACPK8Xem3ZS_fQdtcyO-wjeX43j+gW3bj0xmtxU4S5WVbtzXLw@mail.gmail.com> (raw)
In-Reply-To: <a18d0411-9134-2ee7-62d0-4ba6a1780846@mind.be>

On Fri, 13 May 2022 at 21:52, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> 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@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

Yes, mpe and I discussed this. x86 does a similar thing:

ifeq ($(ARCH),x86)
  ifeq ($(shell uname -m),x86_64)
        KBUILD_DEFCONFIG := x86_64_defconfig
  else
        KBUILD_DEFCONFIG := i386_defconfig
  endif
else
        KBUILD_DEFCONFIG := $(ARCH)_defconfig
endif

If you were building on an eg. Arm or PowerPC host with ARCH=x86, you
would get unexpected results.

>
>   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...

I noticed that. It is similarly broken if you expected a kernel that
worked on armv5.

Should we disable BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG for
platforms that don't have a single defconfig?

The other option I considered was removing ARCH_DEFAULT_CONFIG and
providing a default for platforms where we could suggest one. It would
look something like this:

--- a/linux/Config.in
+++ b/linux/Config.in
@@ -176,10 +176,15 @@ endchoice
 config BR2_LINUX_KERNEL_DEFCONFIG
        string "Defconfig name"
        depends on BR2_LINUX_KERNEL_USE_DEFCONFIG
+       default "ppc64le_defconfig" if BR2_powerpc_powerpc64le
+       default "ppc64_defconfig" if BR2_powerpc_powerpc64
+       default "ppc_defconfig" if BR2_powerpc_powerpc
+       default "mutli_v5_defconfig" if BR2_ARM_CPU_ARMV5
+       default "mutli_v7_defconfig" if BR2_ARM_CPU_ARMV7A
+       default "defconfig"
        help
-         Name of the kernel defconfig file to use, without the
-         trailing _defconfig.  The defconfig is located in
-         arch/<arch>/configs in the kernel tree.
+         Name of the kernel defconfig file to use. The defconfig is located in
+         arch/<arch>/configs in the kernel tree

It would need to change the option to include the _defconfig (in order
to support plain old "defconfig"), or we could add some logic in the
.mk to add _defconfig only if the name is not "defconfig".
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  parent reply	other threads:[~2022-05-17  6:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10  2:20 [Buildroot] [PATCH] linux: Fix powerpc64le defconfig selection Joel Stanley
2022-05-13 21:52 ` Arnout Vandecappelle
2022-05-16 13:17   ` Michael Ellerman
2022-05-18 12:03     ` Arnd Bergmann
2022-05-18 17:23     ` Arnout Vandecappelle
2022-05-18 17:23       ` Arnout Vandecappelle
2022-05-26  6:57       ` Michael Ellerman
2022-05-17  6:13   ` Joel Stanley [this message]
2022-05-18 17:32     ` Arnout Vandecappelle
2022-05-28 19:25 ` Peter Korsgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACPK8Xem3ZS_fQdtcyO-wjeX43j+gW3bj0xmtxU4S5WVbtzXLw@mail.gmail.com \
    --to=joel@jms.id.au \
    --cc=arnout@mind.be \
    --cc=buildroot@buildroot.org \
    --cc=mpe@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.