On 27 December 2013 00:21, Li Guang <lig.f...@cn.fujitsu.com> wrote: > Peter Maydell wrote: >> On 26 December 2013 19:40, Hans de Goede<hdego...@redhat.com> 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
