lkml.org 
[lkml]   [2017]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64}
On Mon, Jun 05, 2017 at 09:56:33PM -0700, Palmer Dabbelt wrote:
> On Mon, 29 May 2017 03:50:47 PDT (-0700), Arnd Bergmann wrote:
> > On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >> On Tue, 23 May 2017 04:30:50 PDT (-0700), Arnd Bergmann wrote:
> >>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >>>> RISC-V has both 32-bit and 64-bit base ISAs, but they are very similar.
> >>>> Like some other platforms, we'd like to share one arch directory between
> >>>> the two of them.
> >>>
> >>> I think we mainly do the others for backwards-compatibility with ancient
> >>> build scripts, and we don't need that here. Instead, you could add one more
> >>> line to the 'SUBARCH:=' statement that interprets the uname output.
> >>
> >> I don't think that does the same thing. The desired effect of this diff is:
> >>
> >> * "uname -m" when running on a RISC-V machine returns either riscv32 or
> >> riscv64, as that's what tools like autoconf expect when trying to find
> >> tuples.
> >>
> >> * I can cross compile for riscv32 and riscv64. That's currently controlled by
> >> a Kconfig setting, but ARCH=riscv32 vs ARCH=riscv64 controlls what defconfig
> >> sets.
> >>
> >> * I can natively compile for riscv32 and riscv64. That uses the same Kconfig
> >> setting, and the same ARCH=riscv32 vs ARCH=riscv64 switch for defconfig.
> >
> > Right, but my point is that a new architecture should not rely on 'ARCH='
> > to pick the defconfig, we only do that on a couple of architectures for
> > backwards compatibility with old scripts.
> >
> >> Neither of the two Kconfig issues is a big deal, but we de need "uname -m" to
> >> return "riscv64" or "riscv32" not "riscv". I think the only way to do that is
> >> to set SRCARCH, but I'd be happy to change it if there's a better way. I think
> >> if I just do this
> >>
> >> diff --git a/Makefile b/Makefile
> >> index 0606f28..4adc609 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >> @@ -232,7 +232,8 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> >> -e s/arm.*/arm/ -e s/sa110/arm/ \
> >> -e s/s390x/s390/ -e s/parisc64/parisc/ \
> >> -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> >> - -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ )
> >> + -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
> >> + -e s/riscv.*/riscv/ )
> >>
> >> # Cross compiling and selecting different set of gcc/bin-utils
> >> # ---------------------------------------------------------------------------
> >> @@ -269,14 +270,6 @@ ifeq ($(ARCH),x86_64)
> >> SRCARCH := x86
> >> endif
> >>
> >> -# Additional ARCH settings for RISC-V
> >> -ifeq ($(ARCH),riscv32)
> >> - SRCARCH := riscv
> >> -endif
> >> -ifeq ($(ARCH),riscv64)
> >> - SRCARCH := riscv
> >> -endif
> >> -
> >> # Additional ARCH settings for sparc
> >> ifeq ($(ARCH),sparc32)
> >> SRCARCH := sparc
> >>
> >> then I'll end up with "uname -m" as "riscv" -- I haven't tried it, but that's
> >> why we ended up with this diff in the first place.
> >
> > Do you mean the "uname -m" output comes from "${SRCARCH}" at
> > the time of the kernel build? That would be easy enough to change
> > by simply hardcoding it depending on CONFIG_64BIT.
>
> OK, I didn't know about COMPAT_UTS_MACHINE. That's a much better solution,
> I'll use that.

Hello Palmer,

I suppose the commit:

https://github.com/riscv/riscv-linux/commit/8c826930d2a19ecd4f1036f10a380dc4fddd0da5

aims to address this, but it appears to be incomplete. It lacks
the first fragment of the patch above, i.e. the conversion from
the "uname -m" output (i.e. "riscv{64,32}") to the canonical
arch string (i.e. "riscv"). As a result, a native build (which
normally doesn't explicitly pass ARCH=riscv to make and therefore
relies on the output of "uname -m") would fail.

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

\
 
 \ /
  Last update: 2017-06-12 00:51    [W:0.167 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site