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: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
Date: Tue, 29 Mar 2011 11:09:01 +0200

On 28.03.2011, at 21:52, Aurelien Jarno wrote:

> 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.

I really wouldn't want to see PREP getting removed, now that we have a 
maintainer for it again :). It might be a good idea to recompile the binary we 
ship from that source though?


Alex




reply via email to

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