[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220523230039.GA238308@roeck-us.net>
Date: Mon, 23 May 2022 16:00:39 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Heiko Stübner <heiko@...ech.de>
Cc: Guo Ren <guoren@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Christoph Hellwig <hch@....de>,
linux-arch <linux-arch@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
linux-csky@...r.kernel.org,
linux-s390 <linux-s390@...r.kernel.org>,
sparclinux <sparclinux@...r.kernel.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
Parisc List <linux-parisc@...r.kernel.org>,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
the arch/x86 maintainers <x86@...nel.org>,
Guo Ren <guoren@...ux.alibaba.com>
Subject: Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal
support
On Tue, May 24, 2022 at 12:40:06AM +0200, Heiko Stübner wrote:
> Hi Guenter,
>
> Am Montag, 23. Mai 2022, 18:18:47 CEST schrieb Guenter Roeck:
> > On 5/23/22 08:18, Guo Ren wrote:
> > > I tested Palmer's branch, it's okay:
> > > 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a
> > > bogus mmu-type on a no MMU kernel
> > >
> > > I also tested linux-next, it's okay:
> > >
> > > rv64_rootfs:
> > > # uname -a
> > > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT
> > > 2022 riscv64 GNU/Linux
> > > #
> >
> > That is is ok with one setup doesn't mean it is ok with
> > all setups. It is not ok with my root file system (from
> > https://github.com/groeck/linux-build-test/tree/master/rootfs/riscv64),
> > with qemu v6.2.
>
> That is very true that it shouldn't fail on any existing (qemu-)platform,
> but as I remember also testing Guo's series on both riscv32 and riscv64
> qemu platforms in the past, I guess it would be really helpful to get more
> information about the failing platform you're experiencing so that we can
> find the source of the issue.
>
> As it looks like you both tested the same kernel source, I guess the only
> differences could be in the qemu-version, kernel config and rootfs.
> Is your rootfs something you can share or that can be rebuilt easily?
>
I provided a link to my root file system above. The link points to two
root file systems, for initrd (cpio archive) and for ext2.
I also mentioned above that I used qemu v6.2. And below I said
> My root file system uses musl.
I attached the buildroot configuration below. The buildroot version,
if I remember correctly, was 2021.02.
Kernel configuration is basically defconfig. However, I do see one
detail that is possibly special in my configuration.
# The latest kernel assumes SBI version 0.3, but that doesn't match qemu
# at least up to version 6.2 and results in hangup/crashes during reboot
# with sifive_u emulations.
enable_config "${defconfig}" CONFIG_RISCV_SBI_V01
Hope that helps,
Guenter
---
BR2_riscv=y
BR2_TOOLCHAIN_BUILDROOT_MUSL=y
BR2_KERNEL_HEADERS_4_19=y
BR2_BINUTILS_VERSION_2_32_X=y
BR2_TARGET_RUN_TESTSCRIPT=y
BR2_SHUTDOWN_COMMAND_POWEROFF=y
BR2_SYSTEM_DHCP="eth0"
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
BR2_PACKAGE_STRACE=y
BR2_PACKAGE_I2C_TOOLS=y
BR2_PACKAGE_PCIUTILS=y
BR2_PACKAGE_DTC=y
BR2_PACKAGE_DTC_PROGRAMS=y
BR2_PACKAGE_IPROUTE2=y
BR2_TARGET_ROOTFS_BTRFS=y
BR2_TARGET_ROOTFS_CPIO=y
BR2_TARGET_ROOTFS_CPIO_GZIP=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_SIZE="16M"
BR2_TARGET_ROOTFS_EXT2_GZIP=y
BR2_TARGET_ROOTFS_ISO_GZIP=y
BR2_TARGET_ROOTFS_SQUASHFS=y
# BR2_TARGET_ROOTFS_TAR is not set
Powered by blists - more mailing lists