qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 6/6] [S390] Add firmware code


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH 6/6] [S390] Add firmware code
Date: Sat, 10 Apr 2010 17:03:03 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Sat, Apr 10, 2010 at 11:22:37AM +0200, Alexander Graf wrote:
> 
> On 10.04.2010, at 02:00, Aurelien Jarno wrote:
> 
> > On Sat, Apr 10, 2010 at 01:29:55AM +0200, Alexander Graf wrote:
> >> 
> >> On 09.04.2010, at 22:17, Aurelien Jarno wrote:
> >> 
> >>> On Thu, Apr 01, 2010 at 06:42:41PM +0200, Alexander Graf wrote:
> >>>> This patch adds a firmware blob to the S390 target. The blob is a simple
> >>>> implementation of a virtio client that tries to read the second stage
> >>>> bootloader from sectors described as of offset 0x20 in the MBR.
> >>>> 
> >>>> In combination with an updated zipl this allows for booting from virtio
> >>>> block devices. This firmware is built from the same sources as the second
> >>>> stage bootloader. You can find the zipl patch to build both here:
> >>>> 
> >>>> http://alex.csgraf.de/qemu/0001-Zipl-VirtIO-bootloader-code.patch
> >>> 
> >>> I am not fully comfortable introducing a binary firmware based on a
> >>> patch posted on a website. I see two options:
> >>> - Get your patch merged into ZIPL, so that we can build the firmware
> >>> directly from the ZIPL sources
> >> 
> >> IBM wants to keep the copyright on the zipl sources, so this one's out.
> > 
> > You can't transfer the copyright, as it is done for example for GNU
> > projects?
> 
> I don't think so. Apart from it being illegal in Germany (you can't transfer 
> full copyrights) I'm not sure that'd really help.
> 
> Another idea:
> 
> How about I set up a git tree on repo.or.cz and put it there? That git tree 
> would contain all my changes, be a single public source and I'd try to pull 
> all 'upstream' changes back in?

Also looks a good idea.

> >>> 
> >>> Also do you really want to make the firmware mandatory? What about a
> >>> warning and falling back to the direct kernel boot instead (if provided), 
> >>> as it is already now. Some other machines are doing that.
> >> 
> >> Yes, I do. It doesn't hurt to have it loaded and on -kernel we can just 
> >> set the PSW differently, thus making the guest jump directly into the 
> >> kernel. So the firmware is loaded and completely ignored. That's btw what 
> >> happens with this patch already. -kernel overrides the firmware.
> >> 
> > 
> > That means people needs to have the firmware installed even if they
> > don't need it.
> 
> I don't see a problem there. It's less than 4k. Plus it's mandatory for x86 
> and ppc too, so why make it different?
> 

It's mandatory for x86 and ppc as the bootloader is actually doing the
jump to the kernel (for ppc it even provide some services to the kernel).

The main problem I see is for distributions that want to rebuild the
firmwares from sources. Also making it optional is just a few lines
more.

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




reply via email to

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