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

[Alexander Graf]

On 20.12.2010, at 23:24, Andreas Färber wrote:

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

if that works, yes. If instead loading netbsd or haiku is easier, go for those. 
Anything that actually runs is good :).

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

And I very much appreciate that! In fact, I think we're thinking along the same 
line here. The only difference is that I'd like to see a full patch set in 2 
weeks from now that makes prep do something useful, while you wouldn't mind 
getting those 2 early patches in upstream right now.

Either way, you have my full support on this. If you want to stop working on 
prep after those patches, let's merge them in now - it's an improvement either 
way. If instead you're keen on improving it, let's let them mature for a while 
while you continue to work on them. I'm sure you'll spot even more stuff and 
maybe even find out that you need to go a completely different route in the end 
:).

Whatever happens, I'm very happy to see you work on this!


Alex