[Buildroot] [PATCH v2 1/2] configs/qemu_riscv64_virt: Update to 5.1 kernel

[Buildroot] [PATCH v2 1/2] configs/qemu_riscv64_virt: Update to 5.1 kernel

[Alistair Francis]

Update the 64-bit defconfig to use the latest kernel.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
v2:
 - Keep kernel version hard coded

 configs/qemu_riscv64_virt_defconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configs/qemu_riscv64_virt_defconfig b/configs/qemu_riscv64_virt_defconfig
index 12afac44fb..c0b1a43925 100644
--- a/configs/qemu_riscv64_virt_defconfig
+++ b/configs/qemu_riscv64_virt_defconfig
@@ -10,13 +10,13 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
 # Filesystem
 BR2_TARGET_ROOTFS_EXT2=y
 
-# Linux headers same as kernel, a 4.20 series
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_20=y
+# Linux headers same as kernel, a 5.1 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_1=y
 
 # Kernel
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.20.17"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.12"
 BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
 BR2_LINUX_KERNEL_IMAGE=y
 
-- 
2.22.0

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Alistair Francis]

Update the 32-bit defconfig to use the latest kernel. This requires a
patch to revert a ABI to ensure that the glibc port continues to work.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
v2:
 - Keep kernel version hard coded
 - Remove unused config fragment

 ...ert-riscv-Use-latest-system-call-ABI.patch | 66 +++++++++++++++++++
 board/qemu/riscv32-virt/linux.config.fragment | 12 ----
 configs/qemu_riscv32_virt_defconfig           | 10 +--
 3 files changed, 71 insertions(+), 17 deletions(-)
 create mode 100644 board/qemu/riscv32-virt/0001-Revert-riscv-Use-latest-system-call-ABI.patch
 delete mode 100644 board/qemu/riscv32-virt/linux.config.fragment

diff --git a/board/qemu/riscv32-virt/0001-Revert-riscv-Use-latest-system-call-ABI.patch b/board/qemu/riscv32-virt/0001-Revert-riscv-Use-latest-system-call-ABI.patch
new file mode 100644
index 0000000000..e0dfaa1501
--- /dev/null
+++ b/board/qemu/riscv32-virt/0001-Revert-riscv-Use-latest-system-call-ABI.patch
@@ -0,0 +1,66 @@
+From 15f62343916fcb3cae82e618da28eaa82bc8c007 Mon Sep 17 00:00:00 2001
+From: Alistair Francis <alistair.francis@wdc.com>
+Date: Tue, 16 Apr 2019 09:03:41 -0700
+Subject: [PATCH] Revert "riscv: Use latest system call ABI"
+
+This reverts commit d4c08b9776b392e20efc6198ebe1bc8ec1911d9b.
+
+The latest RISC-V 32bit glibc submission doesn't work with this patch,
+so let's revert it. This revert can be reverted when the glibc
+submission is updated to work on the 5.1 kernel.
+
+Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
+---
+ arch/riscv/Kconfig                   | 1 +
+ arch/riscv/include/uapi/asm/unistd.h | 5 ++++-
+ arch/riscv/kernel/vdso/Makefile      | 2 --
+ 3 files changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
+index eb56c82d8aa1..43dd2680c696 100644
+--- a/arch/riscv/Kconfig
++++ b/arch/riscv/Kconfig
+@@ -11,6 +11,7 @@ config 32BIT
+ 
+ config RISCV
+ 	def_bool y
++	select ARCH_32BIT_OFF_T if !64BIT
+ 	# even on 32-bit, physical (and DMA) addresses are > 32-bits
+ 	select PHYS_ADDR_T_64BIT
+ 	select OF
+diff --git a/arch/riscv/include/uapi/asm/unistd.h b/arch/riscv/include/uapi/asm/unistd.h
+index 0e2eeeb1fd27..486a288b454c 100644
+--- a/arch/riscv/include/uapi/asm/unistd.h
++++ b/arch/riscv/include/uapi/asm/unistd.h
+@@ -17,8 +17,11 @@
+ 
+ #ifdef __LP64__
+ #define __ARCH_WANT_NEW_STAT
+-#define __ARCH_WANT_SET_GET_RLIMIT
+ #endif /* __LP64__ */
++#define __ARCH_WANT_SET_GET_RLIMIT
++#ifndef __LP64__
++#define __ARCH_WANT_TIME32_SYSCALLS
++#endif
+ 
+ #include <asm-generic/unistd.h>
+ 
+diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile
+index fec62b24df89..eed1c137f618 100644
+--- a/arch/riscv/kernel/vdso/Makefile
++++ b/arch/riscv/kernel/vdso/Makefile
+@@ -2,11 +2,9 @@
+ 
+ # Symbols present in the vdso
+ vdso-syms  = rt_sigreturn
+-ifdef CONFIG_64BIT
+ vdso-syms += gettimeofday
+ vdso-syms += clock_gettime
+ vdso-syms += clock_getres
+-endif
+ vdso-syms += getcpu
+ vdso-syms += flush_icache
+ 
+-- 
+2.21.0
+
diff --git a/board/qemu/riscv32-virt/linux.config.fragment b/board/qemu/riscv32-virt/linux.config.fragment
deleted file mode 100644
index bca9aa61c7..0000000000
--- a/board/qemu/riscv32-virt/linux.config.fragment
+++ /dev/null
@@ -1,12 +0,0 @@
-CONFIG_32BIT=y
-CONFIG_ARCH_RV32I=y
-# CONFIG_ARCH_RV64I is not set
-CONFIG_MAXPHYSMEM_2GB=y
-CONFIG_LBDAF=y
-# CONFIG_SCSI_NSP32 is not set
-CONFIG_GENERIC_ATOMIC64=y
-CONFIG_GENERIC_LIB_ASHLDI3=y
-CONFIG_GENERIC_LIB_ASHRDI3=y
-CONFIG_GENERIC_LIB_LSHRDI3=y
-CONFIG_GENERIC_LIB_UCMPDI2=y
-CONFIG_GENERIC_LIB_UMODDI3=y
diff --git a/configs/qemu_riscv32_virt_defconfig b/configs/qemu_riscv32_virt_defconfig
index 84f7b6ab9c..0395292cd8 100644
--- a/configs/qemu_riscv32_virt_defconfig
+++ b/configs/qemu_riscv32_virt_defconfig
@@ -10,15 +10,15 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
 # Filesystem
 BR2_TARGET_ROOTFS_EXT2=y
 
-# Linux headers same as kernel, a 4.20 series
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_20=y
+# Linux headers same as kernel, a 5.1 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_1=y
 
 # Kernel
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.20.17"
-BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
-BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/riscv32-virt/linux.config.fragment"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.12"
+BR2_LINUX_KERNEL_DEFCONFIG="rv32"
+BR2_LINUX_KERNEL_PATCH="board/qemu/riscv32-virt/0001-Revert-riscv-Use-latest-system-call-ABI.patch"
 BR2_LINUX_KERNEL_IMAGE=y
 
 # Bootloader
-- 
2.22.0

[Buildroot] [PATCH v2 1/2] configs/qemu_riscv64_virt: Update to 5.1 kernel

[Thomas Petazzoni]

On Wed, 19 Jun 2019 09:54:05 -0700
Alistair Francis <alistair.francis@wdc.com> wrote:

> Update the 64-bit defconfig to use the latest kernel.
> 
> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
> ---
> v2:
>  - Keep kernel version hard coded

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Thomas Petazzoni]

On Wed, 19 Jun 2019 09:54:06 -0700
Alistair Francis <alistair.francis@wdc.com> wrote:

>  # Kernel
>  BR2_LINUX_KERNEL=y
>  BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.20.17"
> -BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
> -BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/riscv32-virt/linux.config.fragment"
> +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.12"
> +BR2_LINUX_KERNEL_DEFCONFIG="rv32"
> +BR2_LINUX_KERNEL_PATCH="board/qemu/riscv32-virt/0001-Revert-riscv-Use-latest-system-call-ABI.patch"

We prefer using the BR2_GLOBAL_PATCH_DIR mechanism nowadays, so I've
adjusted your patch to use that and applied. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Alistair Francis]

On Thu, Jun 20, 2019 at 6:57 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> On Wed, 19 Jun 2019 09:54:06 -0700
> Alistair Francis <alistair.francis@wdc.com> wrote:
>
> >  # Kernel
> >  BR2_LINUX_KERNEL=y
> >  BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.20.17"
> > -BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
> > -BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/riscv32-virt/linux.config.fragment"
> > +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.12"
> > +BR2_LINUX_KERNEL_DEFCONFIG="rv32"
> > +BR2_LINUX_KERNEL_PATCH="board/qemu/riscv32-virt/0001-Revert-riscv-Use-latest-system-call-ABI.patch"
>
> We prefer using the BR2_GLOBAL_PATCH_DIR mechanism nowadays, so I've
> adjusted your patch to use that and applied. Thanks!

The BR2_GLOBAL_PATCH_DIR system looks really cool, I'll be sure to use
that next time. Thanks

Alistair

>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Mark Corbin]

Hello Alistair

On 20/06/2019 18:01, Alistair Francis wrote:
> On Thu, Jun 20, 2019 at 6:57 AM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>> On Wed, 19 Jun 2019 09:54:06 -0700
>> Alistair Francis <alistair.francis@wdc.com> wrote:
>>
>>>  # Kernel
>>>  BR2_LINUX_KERNEL=y
>>>  BR2_LINUX_KERNEL_CUSTOM_VERSION=y
>>> -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.20.17"
>>> -BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
>>> -BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/riscv32-virt/linux.config.fragment"
>>> +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.12"
>>> +BR2_LINUX_KERNEL_DEFCONFIG="rv32"
>>> +BR2_LINUX_KERNEL_PATCH="board/qemu/riscv32-virt/0001-Revert-riscv-Use-latest-system-call-ABI.patch"
>> We prefer using the BR2_GLOBAL_PATCH_DIR mechanism nowadays, so I've
>> adjusted your patch to use that and applied. Thanks!
> The BR2_GLOBAL_PATCH_DIR system looks really cool, I'll be sure to use
> that next time. Thanks
>
> Alistair

I can't get the updated 32-bit QEMU configuration to build - there is a
problem with glibc...

In file included from ../sysdeps/unix/sysv/linux/lowlevellock-futex.h:23:0,
???????????????? from ../sysdeps/nptl/lowlevellock.h:23,
???????????????? from ../sysdeps/nptl/libc-lockP.h:33,
???????????????? from ../sysdeps/nptl/libc-lock.h:184,
???????????????? from gconv_db.c:26:
gconv_db.c: In function '__gconv_find_transform':
../sysdeps/unix/sysv/linux/riscv/sysdep.h:120:31: error: '__NR_futex'
undeclared (first use in this function); did you mean
?'__futex'?

The updated 64-bit version works without any problems.

Is there an issue with the patch revert for glibc?

Thanks

Mark

-- 
Mark Corbin
Embecosm Ltd.
https://www.embecosm.com

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Alistair Francis]

On Thu, Jun 20, 2019 at 10:13 AM Mark Corbin <mark.corbin@embecosm.com> wrote:
>
> Hello Alistair
>
> On 20/06/2019 18:01, Alistair Francis wrote:
> > On Thu, Jun 20, 2019 at 6:57 AM Thomas Petazzoni
> > <thomas.petazzoni@bootlin.com> wrote:
> >> On Wed, 19 Jun 2019 09:54:06 -0700
> >> Alistair Francis <alistair.francis@wdc.com> wrote:
> >>
> >>>  # Kernel
> >>>  BR2_LINUX_KERNEL=y
> >>>  BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> >>> -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.20.17"
> >>> -BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
> >>> -BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/riscv32-virt/linux.config.fragment"
> >>> +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.12"
> >>> +BR2_LINUX_KERNEL_DEFCONFIG="rv32"
> >>> +BR2_LINUX_KERNEL_PATCH="board/qemu/riscv32-virt/0001-Revert-riscv-Use-latest-system-call-ABI.patch"
> >> We prefer using the BR2_GLOBAL_PATCH_DIR mechanism nowadays, so I've
> >> adjusted your patch to use that and applied. Thanks!
> > The BR2_GLOBAL_PATCH_DIR system looks really cool, I'll be sure to use
> > that next time. Thanks
> >
> > Alistair
>
> I can't get the updated 32-bit QEMU configuration to build - there is a
> problem with glibc...
>
> In file included from ../sysdeps/unix/sysv/linux/lowlevellock-futex.h:23:0,
>                  from ../sysdeps/nptl/lowlevellock.h:23,
>                  from ../sysdeps/nptl/libc-lockP.h:33,
>                  from ../sysdeps/nptl/libc-lock.h:184,
>                  from gconv_db.c:26:
> gconv_db.c: In function '__gconv_find_transform':
> ../sysdeps/unix/sysv/linux/riscv/sysdep.h:120:31: error: '__NR_futex'
> undeclared (first use in this function); did you mean
>  '__futex'?
>
> The updated 64-bit version works without any problems.

Yep, it's not working for me now either. I think the Linux patch is
somehow not being applied. I'll investigate.

Alistair

>
> Is there an issue with the patch revert for glibc?
>
> Thanks
>
> Mark
>
> --
> Mark Corbin
> Embecosm Ltd.
> https://www.embecosm.com

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Alistair Francis]

On Thu, Jun 20, 2019 at 10:40 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Thu, Jun 20, 2019 at 10:13 AM Mark Corbin <mark.corbin@embecosm.com> wrote:
> >
> > Hello Alistair
> >
> > On 20/06/2019 18:01, Alistair Francis wrote:
> > > On Thu, Jun 20, 2019 at 6:57 AM Thomas Petazzoni
> > > <thomas.petazzoni@bootlin.com> wrote:
> > >> On Wed, 19 Jun 2019 09:54:06 -0700
> > >> Alistair Francis <alistair.francis@wdc.com> wrote:
> > >>
> > >>>  # Kernel
> > >>>  BR2_LINUX_KERNEL=y
> > >>>  BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > >>> -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.20.17"
> > >>> -BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
> > >>> -BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/riscv32-virt/linux.config.fragment"
> > >>> +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.12"
> > >>> +BR2_LINUX_KERNEL_DEFCONFIG="rv32"
> > >>> +BR2_LINUX_KERNEL_PATCH="board/qemu/riscv32-virt/0001-Revert-riscv-Use-latest-system-call-ABI.patch"
> > >> We prefer using the BR2_GLOBAL_PATCH_DIR mechanism nowadays, so I've
> > >> adjusted your patch to use that and applied. Thanks!
> > > The BR2_GLOBAL_PATCH_DIR system looks really cool, I'll be sure to use
> > > that next time. Thanks
> > >
> > > Alistair
> >
> > I can't get the updated 32-bit QEMU configuration to build - there is a
> > problem with glibc...
> >
> > In file included from ../sysdeps/unix/sysv/linux/lowlevellock-futex.h:23:0,
> >                  from ../sysdeps/nptl/lowlevellock.h:23,
> >                  from ../sysdeps/nptl/libc-lockP.h:33,
> >                  from ../sysdeps/nptl/libc-lock.h:184,
> >                  from gconv_db.c:26:
> > gconv_db.c: In function '__gconv_find_transform':
> > ../sysdeps/unix/sysv/linux/riscv/sysdep.h:120:31: error: '__NR_futex'
> > undeclared (first use in this function); did you mean
> >  '__futex'?
> >
> > The updated 64-bit version works without any problems.
>
> Yep, it's not working for me now either. I think the Linux patch is
> somehow not being applied. I'll investigate.

The conversion to the BR2_GLOBAL_PATCH_DIR mechanism broke the build.
I'll send a patch now that fixes it.

Alistair

>
> Alistair
>
> >
> > Is there an issue with the patch revert for glibc?
> >
> > Thanks
> >
> > Mark
> >
> > --
> > Mark Corbin
> > Embecosm Ltd.
> > https://www.embecosm.com

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Alistair Francis]

On Thu, Jun 20, 2019 at 11:26 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Thu, 20 Jun 2019 10:54:27 -0700
> Alistair Francis <alistair23@gmail.com> wrote:
>
> > > Yep, it's not working for me now either. I think the Linux patch is
> > > somehow not being applied. I'll investigate.
> >
> > The conversion to the BR2_GLOBAL_PATCH_DIR mechanism broke the build.
> > I'll send a patch now that fixes it.
>
> Argh, sorry about that :-/
>
> However, if the patch is needed to be able to build the toolchain, then
> there is a larger problem: it shouldn't be just this defconfig that has
> the patch.
>
> In fact, now that I think of it, I remember doing a rebuild of
> toolchains recently, and riscv32 was indeed failing with:
>
> In file included from ../sysdeps/unix/sysv/linux/lowlevellock-futex.h:23:0,
>                  from ../sysdeps/nptl/lowlevellock.h:23,
>                  from ../sysdeps/nptl/libc-lockP.h:33,
>                  from ../sysdeps/nptl/libc-lock.h:184,
>                  from gconv_db.c:26:
> gconv_db.c: In function '__gconv_find_transform':
> ../sysdeps/unix/sysv/linux/riscv/sysdep.h:120:31: error: '__NR_futex' undeclared (first use in this function); did you mean '__futex'?
>  #define SYS_ify(syscall_name) __NR_##syscall_name
>                                ^
> ../sysdeps/unix/sysv/linux/riscv/sysdep.h:232:38: note: in definition of macro 'internal_syscall4'
>   register long int __a7 asm ("a7") = number;   \
>                                       ^~~~~~
> ../sysdeps/unix/sysv/linux/riscv/sysdep.h:151:24: note: in expansion of macro 'SYS_ify'
>   internal_syscall##nr (SYS_ify (name), err, args)
>                         ^~~~~~~
>
> And this should be fixed somehow.

Yep, the problem is that the glibc port isn't upstream so it isn't
stable. The kernel has progressed ahead of the latest glibc upstrem
submission (what we are using in buildroot). To fix this we are
reverting the patch from the kernel. Hopefully in the future we can
update glibc and then remove the patch.

Alistair

>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Thomas Petazzoni]

Hello,

On Thu, 20 Jun 2019 10:54:27 -0700
Alistair Francis <alistair23@gmail.com> wrote:

> > Yep, it's not working for me now either. I think the Linux patch is
> > somehow not being applied. I'll investigate.  
> 
> The conversion to the BR2_GLOBAL_PATCH_DIR mechanism broke the build.
> I'll send a patch now that fixes it.

Argh, sorry about that :-/

However, if the patch is needed to be able to build the toolchain, then
there is a larger problem: it shouldn't be just this defconfig that has
the patch.

In fact, now that I think of it, I remember doing a rebuild of
toolchains recently, and riscv32 was indeed failing with:

In file included from ../sysdeps/unix/sysv/linux/lowlevellock-futex.h:23:0,
                 from ../sysdeps/nptl/lowlevellock.h:23,
                 from ../sysdeps/nptl/libc-lockP.h:33,
                 from ../sysdeps/nptl/libc-lock.h:184,
                 from gconv_db.c:26:
gconv_db.c: In function '__gconv_find_transform':
../sysdeps/unix/sysv/linux/riscv/sysdep.h:120:31: error: '__NR_futex' undeclared (first use in this function); did you mean '__futex'?
 #define SYS_ify(syscall_name) __NR_##syscall_name
                               ^
../sysdeps/unix/sysv/linux/riscv/sysdep.h:232:38: note: in definition of macro 'internal_syscall4'
  register long int __a7 asm ("a7") = number;   \
                                      ^~~~~~
../sysdeps/unix/sysv/linux/riscv/sysdep.h:151:24: note: in expansion of macro 'SYS_ify'
  internal_syscall##nr (SYS_ify (name), err, args)
                        ^~~~~~~

And this should be fixed somehow.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Thomas Petazzoni]

On Thu, 20 Jun 2019 11:26:06 -0700
Alistair Francis <alistair23@gmail.com> wrote:

> Yep, the problem is that the glibc port isn't upstream so it isn't
> stable. The kernel has progressed ahead of the latest glibc upstrem
> submission (what we are using in buildroot). To fix this we are
> reverting the patch from the kernel. Hopefully in the future we can
> update glibc and then remove the patch.

For riscv32 we are *not* using upstream glibc:

else ifeq ($(BR2_RISCV_32),y)
GLIBC_VERSION = 06983fe52cfe8e4779035c27e8cc5d2caab31531
GLIBC_SITE = $(call github,riscv,riscv-glibc,$(GLIBC_VERSION))

so if this glibc fork has been updated to cope with the recent kernel
change, I think we should update glibc instead of reverting the patch
from the kernel.

This would also address my comment that building a riscv32
configuration doesn't work out of the box. Of course, we would have to
disallow selecting kernel headers < 5.1 on riscv32, but that's
perfectly possible.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Alistair Francis]

On Thu, Jun 20, 2019 at 12:02 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> On Thu, 20 Jun 2019 11:26:06 -0700
> Alistair Francis <alistair23@gmail.com> wrote:
>
> > Yep, the problem is that the glibc port isn't upstream so it isn't
> > stable. The kernel has progressed ahead of the latest glibc upstrem
> > submission (what we are using in buildroot). To fix this we are
> > reverting the patch from the kernel. Hopefully in the future we can
> > update glibc and then remove the patch.
>
> For riscv32 we are *not* using upstream glibc:

Yep, there is no upstream glibc.

>
> else ifeq ($(BR2_RISCV_32),y)
> GLIBC_VERSION = 06983fe52cfe8e4779035c27e8cc5d2caab31531
> GLIBC_SITE = $(call github,riscv,riscv-glibc,$(GLIBC_VERSION))
>
> so if this glibc fork has been updated to cope with the recent kernel
> change, I think we should update glibc instead of reverting the patch
> from the kernel.

It hasn't been updated, we are using the latest. This is why we need
the kernel patch.

Alistair

>
> This would also address my comment that building a riscv32
> configuration doesn't work out of the box. Of course, we would have to
> disallow selecting kernel headers < 5.1 on riscv32, but that's
> perfectly possible.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Bin Meng]

Hi,

On Fri, Jun 21, 2019 at 4:03 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Thu, Jun 20, 2019 at 12:02 PM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > On Thu, 20 Jun 2019 11:26:06 -0700
> > Alistair Francis <alistair23@gmail.com> wrote:
> >
> > > Yep, the problem is that the glibc port isn't upstream so it isn't
> > > stable. The kernel has progressed ahead of the latest glibc upstrem
> > > submission (what we are using in buildroot). To fix this we are
> > > reverting the patch from the kernel. Hopefully in the future we can
> > > update glibc and then remove the patch.
> >
> > For riscv32 we are *not* using upstream glibc:
>
> Yep, there is no upstream glibc.
>
> >
> > else ifeq ($(BR2_RISCV_32),y)
> > GLIBC_VERSION = 06983fe52cfe8e4779035c27e8cc5d2caab31531
> > GLIBC_SITE = $(call github,riscv,riscv-glibc,$(GLIBC_VERSION))
> >
> > so if this glibc fork has been updated to cope with the recent kernel
> > change, I think we should update glibc instead of reverting the patch
> > from the kernel.
>
> It hasn't been updated, we are using the latest. This is why we need
> the kernel patch.
>

The riscv32 glibc build is still failing with current buildroot master
HEAD. Is there any plan to address this?

Regards,
Bin

[Buildroot] [PATCH v2 2/2] configs/qemu_riscv32_virt: Update to 5.1 kernel

[Alistair Francis]

On Sat, Aug 17, 2019 at 9:12 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi,
>
> On Fri, Jun 21, 2019 at 4:03 AM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Thu, Jun 20, 2019 at 12:02 PM Thomas Petazzoni
> > <thomas.petazzoni@bootlin.com> wrote:
> > >
> > > On Thu, 20 Jun 2019 11:26:06 -0700
> > > Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > > Yep, the problem is that the glibc port isn't upstream so it isn't
> > > > stable. The kernel has progressed ahead of the latest glibc upstrem
> > > > submission (what we are using in buildroot). To fix this we are
> > > > reverting the patch from the kernel. Hopefully in the future we can
> > > > update glibc and then remove the patch.
> > >
> > > For riscv32 we are *not* using upstream glibc:
> >
> > Yep, there is no upstream glibc.
> >
> > >
> > > else ifeq ($(BR2_RISCV_32),y)
> > > GLIBC_VERSION = 06983fe52cfe8e4779035c27e8cc5d2caab31531
> > > GLIBC_SITE = $(call github,riscv,riscv-glibc,$(GLIBC_VERSION))
> > >
> > > so if this glibc fork has been updated to cope with the recent kernel
> > > change, I think we should update glibc instead of reverting the patch
> > > from the kernel.
> >
> > It hasn't been updated, we are using the latest. This is why we need
> > the kernel patch.
> >
>
> The riscv32 glibc build is still failing with current buildroot master
> HEAD. Is there any plan to address this?

I thought I tried this the other day and it worked.

The RV32 glibc submission is ongoing. When it's in a better state I'll
update it here.

Alistair

>
> Regards,
> Bin