Am 06.04.2013 um 01:00 schrieb Scott Wood <scottw...@freescale.com>:
> On 04/04/2013 06:59:24 AM, Alexander Graf wrote: >> On 04.04.2013, at 13:53, Andreas Färber wrote: >> > For PReP, Fabien has not stated what his use case actually is (in >> > particular which hardware?), so it's hard for me to comment on what the >> > hardware actually does and I thus won't accept random changes just >> > because they happen to be in Leon3 code. There's nothing conceptually >> > wrong with loading ELF code so I'm positive we will find a solution to >> > accommodate all use cases in some way. :) >> I think it makes a lot of sense to support loading -kernel as an ELF binary. >> I don't think it's a good idea to allow -kernel without any BIOS. We do that >> on the e500 machines and so far it's mostly hurt us. > > If by "mostly hurt us" you mean allowed things to work without having to do a > bunch of hacking to create a paravirt U-Boot and/or implement a bunch of > emulation that we don't really need otherwise. Also, as soon as ARM moves to uEFI, Linux won't run bare metal the way it would with formware either. We went through that argument very leghthly on x86. It used to do direct -kernel without involving firmware. Then came SMP tables that were missing, ACPI tables that were missing, etc. Suddenly your -kernel booted system couldn't do hotplug for example. It ran through different code paths, causing testability pain. What if Linux adds a callback into uboot tomorrow that it uses to do early printk? Suddenly we lack that. On ARM, look at highbank. Because we're not running we're lacking a monitor mode blob that provides sys calls for flushing caches. Thus today the highbank machine doesn't boot anymore with Linux. If we ran firmware like the real board, that would provide for the sys call. Alex
