qemu-devel
[Top][All Lists]
Advanced

[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 21:52:32 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Mar 28, 2011 at 01:50:40PM -0500, Anthony Liguori wrote:
> On 03/28/2011 01:24 PM, Aurelien Jarno wrote:
> >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.
> 
> I had thought that the actual binary was from Jocelyn and contains
> patches that noone else has.  In fact, the last commit is:
> 
> commit 55aa45ddde3283cdd781326d001f7456bf02f684
> Author: j_mayer <address@hidden>
> Date:   Mon Oct 1 06:44:33 2007 +0000
> 
>     Quickly hack PowerPC BIOS able to boot on CDROM again.
> 
> >  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.
> 
> I'd be very happy to just submodule whatever sources Debian is using.
> 

I am not sure that it corresponds to the latest code, so it might have
some issues, but at least it is something that is usable. The code is a
vailable from:

http://ftp.debian.org/debian/pool/main/o/openhackware/

Note that the .diff.gz contains a few patches needed to fix build
issues.

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



reply via email to

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