qemu-riscv
[Top][All Lists]
Advanced

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

Re: [Qemu-riscv] [Qemu-devel] [PATCH v2 00/23] Add RISC-V TCG backend su


From: Alistair Francis
Subject: Re: [Qemu-riscv] [Qemu-devel] [PATCH v2 00/23] Add RISC-V TCG backend support
Date: Thu, 20 Dec 2018 11:04:41 -0800

On Thu, Dec 20, 2018 at 10:45 AM Palmer Dabbelt <address@hidden> wrote:
>
> On Thu, 20 Dec 2018 09:20:05 PST (-0800), address@hidden wrote:
> > On Wed, Dec 19, 2018 at 10:07 PM Richard Henderson
> > <address@hidden> wrote:
> >>
> >> On 12/19/18 11:16 AM, Alistair Francis wrote:
> >> > This patch set adds RISC-V backend support to QEMU. This is based on
> >> > Michael Clark's original work with extra work on top.
> >> >
> >> > This has been somewhat tested and can run other architecture softmmu
> >> > code. It seems that any complex OS will eventually hang, but we can
> >> > run the BIOS and OS startup code for a number of different operating
> >> > systems.
> >> >
> >> > I haven't tested linux user support at all yet. I think Michael had that
> >> > working reliably though and hopefully my changes haven't broken it.
> >> >
> >> > There are still some todos in the code (there are missing instructions
> >> > and byte swapping) but these should assert instead of generating invalid
> >> > code.
> >>
> >> Queued to tcg-next, with the extrh fix.
> >
> > Thanks Richard!
>
> Sounds good to me.  I'm still attempting to collect the RISC-V patches to get 
> a
> PR out, a few things came up but I should have time now.  This was the biggest
> patch set, so it should be a lot easier now.
>
> Thanks for picking this up!
>
> >> Some of those todos are no longer todos, since e.g. bswap is now optional.
> >> Those asserts should never fire (as a good assert should do, I suppose).
> >>
> >> The missing instructions are only for riscv32, which afaik is just now 
> >> making
> >> its way to glibc.  So a chroot complete enough to build qemu is a ways 
> >> away.
> >> I'm ok with leaving that incomplete for now.
>
> We've decided to delay the rv32i glibc port until after the next glibc 
> release,
> which is targeted for the beginning of February.  glibc should freeze at the
> end of the year, at which point we're going to do a rv32i glibc prerelease and
> try to build a proper userspace with the theory being that we'll shake out ABI
> bugs that way.

Yocto/OE has full support for building 32-bit userspaces with the
latest 32-bit glibc patchset so that is probably a good place to start
testing. It even runs QEMU!

Alistair



reply via email to

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