qemu-devel
[Top][All Lists]
Advanced

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

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


From: Alexander Graf
Subject: Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
Date: Mon, 20 Dec 2010 23:39:02 +0100

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

Also on the other forks. I'm not sure what happened with the Alpha port, but 
for AVR32 and z80 I have not seen any upstream submissions since I joined qemu. 
I know that the AVR32 people were eager in learning things, but I haven't seen 
any code submitted upstream.

I don't believe this is what will happen with you. You're well aware of how 
open source works and will hopefully pester at least me - preferably others too 
- until stuff gets in :).


Alex




reply via email to

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