qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platfor


From: Bin Meng
Subject: Re: [PATCH v4 4/7] hw/riscv: Use pre-built bios image of generic platform for virt & sifive_u
Date: Wed, 29 Jul 2020 13:10:00 +0800

Hi Alistair,

On Wed, Jul 29, 2020 at 1:05 PM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Tue, Jul 28, 2020 at 9:51 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Alistair,
> >
> > On Wed, Jul 29, 2020 at 2:26 AM Alistair Francis <alistair23@gmail.com> 
> > wrote:
> > >
> > > On Tue, Jul 28, 2020 at 8:46 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Alistair,
> > > >
> > > > On Tue, Jul 28, 2020 at 11:39 PM Alistair Francis 
> > > > <alistair23@gmail.com> wrote:
> > > > >
> > > > > On Wed, Jul 15, 2020 at 9:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > Hi Alistair,
> > > > > >
> > > > > > On Mon, Jul 13, 2020 at 9:53 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > On Sun, Jul 12, 2020 at 1:34 AM Alistair Francis 
> > > > > > > <alistair23@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Jul 9, 2020 at 10:07 PM Bin Meng <bmeng.cn@gmail.com> 
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > From: Bin Meng <bin.meng@windriver.com>
> > > > > > > > >
> > > > > > > > > Update virt and sifive_u machines to use the opensbi 
> > > > > > > > > fw_dynamic bios
> > > > > > > > > image built for the generic FDT platform.
> > > > > > > > >
> > > > > > > > > Remove the out-of-date no longer used bios images.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > > > > > > > > Reviewed-by: Anup Patel <anup@brainfault.org>
> > > > > > > > > Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
> > > > > > > >
> > > > > > > > This patch seems to break 32-bit Linux boots on the sifive_u 
> > > > > > > > and virt machines.
> > > > > > > >
> > > > > > >
> > > > > > > It looks only Linux boot on sifive_u is broken. On our side, we 
> > > > > > > have
> > > > > > > been using VxWorks to test 32-bit OpenSBI on sifive_u so this 
> > > > > > > issue
> > > > > > > gets unnoticed. I will take a look.
> > > > > >
> > > > > > I've figured out the issue of 32-bit Linux booting failure on
> > > > > > sifive_u. A patch has been sent to Linux upstream:
> > > > > > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> > > > >
> > > > > Thanks for that. What change in QEMU causes this failure though?
> > > > >
> > > >
> > > > There is nothing wrong in QEMU.
> > >
> > > There is. This patch causes a regression for 32-bit Linux boot on the
> > > sifive_u. Your v5 has not addressed this.
> >
> > The 32-bit Linux boot failure was fixed by:
> > http://lists.infradead.org/pipermail/linux-riscv/2020-July/001213.html
> >
> > What additional issue did you see?
> >
> > >
> > > With this patch, the Linux boot stops here:
> > >
> > > OpenSBI v0.8
> > >    ____                    _____ ____ _____
> > >   / __ \                  / ____|  _ \_   _|
> > >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> > >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > >  | |__| | |_) |  __/ | | |____) | |_) || |_
> > >   \____/| .__/ \___|_| |_|_____/|____/_____|
> > >         | |
> > >         |_|
> > >
> > > Platform Name       : SiFive HiFive Unleashed A00
> > > Platform Features   : timer,mfdeleg
> > > Platform HART Count : 4
> > > Boot HART ID        : 3
> > > Boot HART ISA       : rv64imafdcsu
> >
> > This is a 64-bit hardware.
>
> You are right. It's not 32-bit, that was my mistake. I'm used to my
> first test being 32-bit, but in this case it's not.
>
> It looks like this commit instead breaks the sifive_u for 64-bit with
> the 5.3 kernel.
>
> >
> > > BOOT HART Features  : pmp,scounteren,mcounteren
> > > BOOT HART PMP Count : 16
> > > Firmware Base       : 0x80000000
> > > Firmware Size       : 116 KB
> > > Runtime SBI Version : 0.2
> > >
> > > MIDELEG : 0x0000000000000222
> > > MEDELEG : 0x000000000000b109
> > > PMP0    : 0x0000000080000000-0x000000008001ffff (A)
> > > PMP1    : 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
> > > [    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> > > [    0.000000] Linux version 5.3.0 (oe-user@oe-host) (gcc version
> >
> > It seems that you are using quite an old kernel. Can you please try
> > the latest version?
>
> It is an old kernel, but old kernels should still keep working (or we
> should at least know why they don't)
>
> >
> > > 9.2.0 (GCC)) #1 SMP Thu Sep 19 18:34:52 UTC 2019
> > > [    0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
> > > [    0.000000] printk: bootconsole [sbi0] enabled
> > > [    0.000000] initrd not found or empty - disabling initrd
> > > [    0.000000] Zone ranges:
> > > [    0.000000]   DMA32    [mem 0x0000000080200000-0x00000000bfffffff]
> > > [    0.000000]   Normal   empty
> > > [    0.000000] Movable zone start for each node
> > > [    0.000000] Early memory node ranges
> > > [    0.000000]   node   0: [mem 0x0000000080200000-0x00000000bfffffff]
> > > [    0.000000] Initmem setup node 0 [mem 
> > > 0x0000000080200000-0x00000000bfffffff]
> > > [    0.000000] OF: fdt: Invalid device tree blob header
> > > [    0.000000] software IO TLB: mapped [mem 0xbb1fe000-0xbf1fe000] (64MB)
> > >
> > > Without this patch I can boot all the way to looking for a rootFS.
> > >
> > > Please don't send new versions of patches without addresses regressions.
> >
> > The patches were sent after addressing all regressions you reported
> > (well the 32-bit Linux booting issue is actually not a QEMU
> > regression, but one that exists in the Linux kernel side for a long
> > time).
>
> Yep, that is my mistake. Sorry about the confusion.
>
> >
> > I just tested 64-bit Linux boot on both virt and sifive_u, and they
> > both can boot all the way to looking for a root fs.
>
> Can you test with older kernels?
>

OK I will investigate.

> If we can't support older kernels with the default bios option we at
> least need to know why and list that in the release notes.
>

Regards,
Bin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]