[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSe

From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
Date: Mon, 28 Mar 2011 20:24:51 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Mar 28, 2011 at 01:02:45PM -0500, Anthony Liguori wrote:
> On 03/28/2011 12:42 PM, Blue Swirl wrote:
> >On Mon, Mar 28, 2011 at 4:16 PM, Anthony Liguori<address@hidden>  wrote:
> >>On 03/28/2011 04:03 AM, Alexander Graf wrote:
> >>>>Um, ok.  Do I need to do anything about this?
> >>>I'm also not sure this is too important.
> >>It's GPL compliance so yes, it's very important.
> >>
> >>>  Most of our firmware blobs come from svn repos which can't be submoduled.
> >>The only firmware blob we're not currently including as a git submodule is
> >>OpenBIOS.
> >No, there's also OpenHack'Ware (ppc_rom.bin) and s390-zipl.rom.
> Alex, what's the source of zipl?
> >>  I believe the main reason is that different boards use different
> >>commits so a single submodule is a bit challenge.  We probably ought to
> >>figure something out here though for the next release.
> >>
> >>Can anyone comment a bit more about OpenBIOS?
> >>
> >>BTW, OpenBIOS is already actively mirrored on git.qemu.org so all that's
> >>needed is a patch that does a git submodule add with the appropriate commit.
> >That would be an improvement. Though building various OpenBIOS images
> >depends on appropriate cross compilers. The situation is actually same
> >as with SeaBIOS.
> Can you do a git submodule add then?
> >>>  And as long as we don't have a consistent policy about it, we can just as
> >>>well stick with the README file.
> >>We do have a consistent policy :-)  We're just not enforcing it as tightly
> >>as we should.
> >>
> >>Any binary we ship in the release tgz's should also have corresponding
> >>source in a submodule.
> >What about OpenHack'Ware (and PReP machine), should it be deleted?
> Yes.  I don't think the source for that is available, correct?  I
> don't think we have any other choice.

Debian still holds a copy of the code. People have worked recently to
restore prep support that has been broken by various patches, it would
be a pitty to remove it without before asking them.

Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net

reply via email to

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