Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Andreas Färber]

Am 20.12.2010 um 13:30 schrieb Alexander Graf:

> On 20.12.2010, at 13:19, François Revol wrote:
>
> > > > > So we certainly do need some open source firmware solution for  
> > > > > prep to at least have Linux running. For other guests, I don't  
> > > > > see a reason why users shouldn't try to fetch a real firmware  
> > > > > blob separately :).
> > > >
> > > > We're not shipping any firmware for ppcemb either, so that  
> > > > argument seems moot. OpenBIOS, SeaBIOS and ZIPL are the only ones  
> > > > currently. Feel free to supply additional blobs for U-Boot etc.
> > >
> > > IIUC you don't need u-boot for the embedded targets. You just pass  
> > > in a kernel and the rest is magic.
> >
> > This holds only for Linux which imposes its own startup API to  
> > bootloaders and go with kernel drivers directly.
> >
> > Other OS like Haiku use a 2nd stage bootloader which assumes a  
> > working callable BIOS (OF on ppc), and getting it to run on U-Boot  
> > is already tricky on its own.
>
> That was my point :). I'm not aware of us supporting firmware on  
> ppcemb, so it's capable of running an OS all by itself already.

No, you rather mean: It's capable of running The OS so you don't care  
about proper firmware there.
By the same argument we could just load a Linux kernel directly on  
PReP and be good with it. Any pointers appreciated.

> > > > Recent vanilla Linux kernels wouldn't run on PReP. So what Linux  
> > > > do you want to run using open source firmware?
> > > > I certainly do not intend to write firmware for the upcoming 40p  
> > > > machine. If Linux runs on real 40p hardware then it should run  
> > > > with real firmware under emulation, too. QEMU is an emulation  
> > > > project, not a Linux testing framework.
> > >
> > > I completely agree. Linux is usually easy because it's fully open  
> > > source and supports a lot of targets. If you feel like running  
> > > NetBSD or Haiku instead, feel free to do so.
> >
> > Thanks for thinking about Haiku ;)
> >
> > Btw there are other existing targets, like AROS, MorphOS, or  
> > AmigaOS which uses a modified U-Boot with a 'boota' command that  
> > passes their 2nd stage Parthenope bootloader a list of BIOS-like  
> > callbacks into U-Boot, cf. :
> > http://www.acube-systems.biz/index.php?page=hardware&pid=2
> > http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz
> >
> > Though they probably won't run on PReP, and PReP support in Haiku  
> > might come only for the sake of supporting the BeBox, which had its  
> > own dumb firmware (MAME seems to have some emulation support for  
> > BeBox).
> >
> > OTOH, I've been thinking about adding a Sam440 target, but it'd  
> > still require the custom U-Boot to start AmigaOS for example.
>
> I'd call U-Boot the firmware that we can ship with Qemu then because  
> it's open source :). I'm not advocate for openBIOS. If it works,  
> great. If something else works better, let's take that.
>
> The only thing I really want to see is a target that does something  
> useful. That's it :). A target that loads proprietary firmware  
> halfway through is not valuable to users IMHO. A target that loads  
> proprietary firmware and boots an OS is valuable. A target that  
> doesn't need firmware and loads an OS is valuable. Maybe a target  
> that doesn't boot an OS quite yet, but loads open source firmware  
> pretty well is valuable too.

Then we agree, a target that doesn't load any firmware or kernel is  
not really valuable.

If you look around then you'll find all kinds of starved QEMU  
branches, e.g., alpha es40, avr32 and z80. They're collecting virtual  
dust while QEMU grows things like qdev. That's why I'm trying to fix  
(note: fix) things in upstream, not create another fork to bitrot.

Andreas