qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] allwinner-a10: add config script support


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] allwinner-a10: add config script support
Date: Fri, 27 Dec 2013 00:38:28 +0000

On 27 December 2013 00:21, Li Guang <address@hidden> wrote:
> Peter Maydell wrote:
>> On 26 December 2013 19:40, Hans de Goede<address@hidden>  wrote:
>>> I'm one of the linux-sunxi developers, the only reason we've
>>> this fex file abomination, is because we've inherited it
>>> from the android-allwinner sources.

>> Thanks for the clarification; I suspected that might be the case.

>>> Currently most of the linux-sunxi developers are no longer
>>> focusing on the 3.4 android/allwinner derived sources we
>>> maintain. They are currently in a "good enough for everyday
>>> use" state.
>>>
>>> So now most of us are focusing on getting *proper* sunxi
>>> SoC support upstream. This is using device-tree. Currently
>>> we've working timers, interrupt-controller, uarts, mmc,
>>> sata, nic (both 100mbit and Gbit variants), ehci controller
>>> and builtin rtc support with upstream kernels. Which I
>>> believe likely covers everything the qemu emulation offers
>>> atm. For those interested, see:
>>> https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel
>>>
>>> And the mailinglist reports about progress in that branch.
>>>
>>>  From the linux-sunxi pov fex files are a legacy thing which
>>> will go away in the future.
>>>
>>
>> Given that, my preference would be to not support fex
>> file loading in QEMU.

> that means we don't care legacy script which already be used
> in most of cases?

If you care about the legacy case I think it would be nicer
to support it the same way the hardware does: implement
the flash or ROM which on the real hardware has the boot
loader in it and then just have a mode where we run the
guest firmware and boot the kernel off SD card or similar.

I don't think we should be adding hacks which neither
(a) are part of implementing emulation of the hardware
nor (b) are needed to boot upstream kernels.

thanks
-- PMM



reply via email to

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