| Message ID | 20190619165406.19615-2-alistair.francis@wdc.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v2,1/2] configs/qemu_riscv64_virt: Update to 5.1 kernel | expand |
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
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
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
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
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
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
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
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
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
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
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
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
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