[Top][All Lists]
[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