qemu-riscv
[Top][All Lists]
Advanced

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

Re: [Qemu-riscv] [Qemu-devel] [PULL 33/34] roms: Add OpenSBI version 0.3


From: Alistair Francis
Subject: Re: [Qemu-riscv] [Qemu-devel] [PULL 33/34] roms: Add OpenSBI version 0.3
Date: Mon, 1 Jul 2019 09:39:07 -0700

On Mon, Jul 1, 2019 at 6:23 AM Anup Patel <address@hidden> wrote:
>
> On Mon, Jul 1, 2019 at 6:12 PM Jonathan Cameron
> <address@hidden> wrote:
> >
> > On Fri, 28 Jun 2019 09:12:45 -0700
> > Alistair Francis <address@hidden> wrote:
> >
> > > On Fri, Jun 28, 2019 at 2:47 AM Jonathan Cameron
> > > <address@hidden> wrote:
> > > >
> > > > On Thu, 27 Jun 2019 08:20:10 -0700
> > > > Palmer Dabbelt <address@hidden> wrote:
> > > >
> > > > > From: Alistair Francis <address@hidden>
> > > > >
> > > > > Add OpenSBI version 0.3 as a git submodule and as a prebult binary.
> > > > >
> > > > > Signed-off-by: Alistair Francis <address@hidden>
> > > > > Reviewed-by: Bin Meng <address@hidden>
> > > > > Tested-by: Bin Meng <address@hidden>
> > > > > Signed-off-by: Palmer Dabbelt <address@hidden>
> > > >
> > > > I sent a late bug report on this one.. Hence posting here as well
> > > > to make sure it doesn't fall through the cracks!
> > > >
> > > > Right now you can't actually build the opensbi64-virt firmware
> > > > due to cut and paste error in the Makefile.
> > >
> > > Ah, thanks for the bug report.
> > >
> > > @Palmer Dabbelt I'm just going to send you a fixup commit. Can you
> > > apply it to your tree and send a PRv2?
> > >
> > > >
> > > > As a side note, I hit this because OpenSBI 0.3 is resulting in a login
> > > > loop on a debian test image and the current upstream isn't.  I haven't
> > > > debugged yet, but someone else may hit that problem.
> > >
> > > Unfortunately OpenSBI 0.3 is a little old now, in saying that I didn't
> > > know there are bugs in it? Which kernel are you using?
> >
> > Mainline 5.2.0-rc5.
> >
> > Just in case I also checked 5.2.0-rc7
> >
> > I tried doing an odd git bisect with good and bad reversed to figure out
> > what fixed the problem, but boot wedged at "Run /sbin/init as init process."
> >
> > The wedge was bisected to:
> >
> > 4e2cd47820 ("lib: Flush everything when remote TLB flush range is too 
> > large")
> >
> > Which the patch correctly identifies as a problem introduced this kernel 
> > cycle.
> > 5.2-rc1.
> >
> > So on that basis alone I'd suggest we want to move to a more recent openSBI
> > asap, after all the 5.2 kernel will be out in a week or so.
> >
> > I'm a bit short on time (flight to catch), so haven't pushed that fix that
> > far back in the tree yet in order to figure what is causing the login loop.
> > Won't have access to relevant build machines until Wednesday.
> >
> > That patch cherry-picked on lib: Optimize TLB flush IPIs
> > seems fine, so it is before that point...
> >
> > Passing that point would require real effort though as the two patches
> > are changing the same code.
> >
> > So I had a go from the other end (0.3) to see if it was fixed quickly.
> > Ran out of time, but at
> > "firmware: Reset all registers and flush the icache" it superficially all
> > seems to be working with no TLB related hang, or login loop.
>
> We plan to release OpenSBI 0.4 in couple of days. It would be best
> to pick-up OpenSBI 0.4 FW_JUMP binaries.

Great! When the 0.4 release comes out I'll send a patch to update the
QEMU binaries and submodules. If this PR is merged before then we can
just update on top of this (as 5.1 and earlier kernels will work with
0.3) and it not it can be squashed into this PR.

Alistair

>
> Regards,
> Anup



reply via email to

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