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

[Alistair Francis]

On Mon, 2019-07-01 at 19:01 +0100, Peter Maydell wrote:
> On Mon, 1 Jul 2019 at 18:50, Alistair Francis <
> address@hidden> wrote:
> > On Mon, 2019-07-01 at 17:54 +0100, Peter Maydell wrote:
> > > On Thu, 27 Jun 2019 at 16:24, 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>
> > > > ---
> > > >  .gitmodules                                  |   3 ++
> > > >  Makefile                                     |   5 +-
> > > >  pc-bios/opensbi-riscv32-virt-fw_jump.bin     | Bin 0 -> 28848
> > > > bytes
> > > >  pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin | Bin 0 -> 28904
> > > > bytes
> > > >  pc-bios/opensbi-riscv64-virt-fw_jump.bin     | Bin 0 -> 28904
> > > > bytes
> > > >  roms/Makefile                                |  48
> > > > ++++++++++++++-
> > > > ----
> > > >  roms/opensbi                                 |   1 +
> > > >  7 files changed, 44 insertions(+), 13 deletions(-)
> > > >  create mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
> > > >  create mode 100644 pc-bios/opensbi-riscv64-sifive_u-
> > > > fw_jump.bin
> > > >  create mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin
> > > >  create mode 160000 roms/opensbi
> > > > 
> > > > diff --git a/.gitmodules b/.gitmodules
> > > > index 2857eec76377..7a10e72e09cd 100644
> > > > --- a/.gitmodules
> > > > +++ b/.gitmodules
> > > > @@ -55,3 +55,6 @@
> > > >  [submodule "slirp"]
> > > >         path = slirp
> > > >         url = https://git.qemu.org/git/libslirp.git
> > > > +[submodule "roms/opensbi"]
> > > > +       path = roms/opensbi
> > > > +       url = https://github.com/riscv/opensbi.git
> > > 
> > > It would be nice to state the license for new blobs we're
> > > adding to the source tree... In particular, I find the
> > > readme at https://github.com/riscv/opensbi a bit confusing
> > > because it says it's 2-BSD but also that some parts are Apache-
> > > 2.0;
> > > the latter is *not* GPL-2.0 compatible. That makes it not
> > > completely
> > > obvious to me that we can ship this with QEMU.
> > 
> > Ah, I didn't realise there is Apache-2.0 code in there.
> > 
> > In this case all of the code we are using (we aren't using the
> > Kendryte
> > code with QEMU) is BSD-2-Clause. Even then though does it matter if
> > it
> > is GPL compatible? This isn't being linked with QEMU it is just
> > being
> > included with QEMU.
> 
> Yeah, if we're not building the apache-2.0 parts then I think
> we're OK, and as you say there's the question of whether QEMU's
> GPL affects what we ship as mere bios blobs to run as guest
> code anyway. But it's sufficiently not a "really obviously ok"
> that I'd like a second opinion; cc'd some people who might have
> second opinions.
> 
> > I can add details of the license in the source tree, where should
> > it be
> > added?
> 
> I was thinking in the commit message. We also seem to
> have human-readable information in pc-bios/README for
> the various blobs, which seems to be a good place for a brief
> one-para summary of what OpenSBI is, a URL for its upstream,
> and a brief note of the license.

Ok, I'll add that.

> 
> > > Also, new git modules in .gitmodules should be qemu.org
> > > URLs, not random external ones. (ie, we should set up
> > > mirroring of any new external repo we start shipping
> > > code and binaries for). We can set this up and fix up the
> > > gitmodules file after the fact, but the ideal is to do
> > > it in advance rather than afterwards.
> > 
> > Ok, who can setup a git mirror for the QEMU repo?
> 
> That would be Jeff or Stefan (cc'd).
> 
> > PS: It seems like there are still some issues with this patch so
> > maybe
> > it's worth dropping this patch from the PR so that we can get
> > everything else merged.
> 
> Yeah, that would be my suggestion.

Can you do that when you merge it or does Palmer have to send the PR
again?

Alistair

> 
> thanks
> -- PMM