Re: [Qemu-devel] Allow ARMv7M to be started without a kernel

[Andreas Färber]

Am 06.05.2011 um 14:48 schrieb Alexander Graf:

> On 06.05.2011, at 01:50, Rob Landley wrote:
>
> > On 05/05/2011 06:26 PM, Alexander Graf wrote:
> > > > As an aside: I think QEMU should have an option which is "just load
> > > > a plain ELF or raw binary, with no funny Linux-kernel-specific
> > > > behaviour" rather than overloading -kernel to mean "if it's a raw
> > > > image it's Linux and if it's an ELF file it's not".
> > >
> > > Traditionally, -bios has been that one. -kernel is more of a real
> > > bootloader replacement, including all the weirdness a bootloader  
> > > does
> > > :).
> >
> > Except that neither "qemu-system-x86_64 -bios vmlinux" nor
> > qemu-system-x86_64 -kernel vmlinux" will load an ELF kernel on  
> > x86-64.
> >
> > The code to do this _exists_ within qemu, it's just not hooked up
> > consistently on all targets.  We have a universal cross-platform  
> > image
> > format, and we have support in qemu for loading that format, and for
> > some reason it's only enabled on certain targets.  I've never  
> > understood
> > why...
>
> Unfortunately, booting isn't that easy :). The kernel needs some  
> more data than just itself and an entry point to properly load. On  
> some architectures, it requires a device tree (and pointer to it in  
> a register), it might require page tables / TLB entries to be set  
> up, if you want -initrd and -append to work you also need to tell  
> the kernel where to find those.
>
> So while ELF is a nice container for binaries, there are still some  
> pieces missing to actually make it a kernel loader. But that's what  
> multiboot was invented for. I haven't seen too much effort going on  
> around multiboot on non-x86, but it basically fills exactly the gap  
> you're wondering about. It uses ELF and adds a simple boot protocol  
> for all the other fancy stuff a kernel needs.

I guess Rob meant something different: -bios does not load ELF files  
for all machines (raw neither). For example, for raw-only PReP I had  
posted a patch that enables loading ELF firmware like OpenBIOS that  
you turned down.

Point being, the handling of -bios is board-specific (not even  
architecture-specific) and thus inconsistent. Your points above - page  
tables, TLB entries etc. - only apply to -kernel but not to -bios,  
that should give us a bare-metal machine.
Unfortunately I didn't see a way to make this handling more generic  
either. Some magic defines get passed into the ELF load function, so  
the call can't be moved to generic sources, and validation and  
placement of raw firmware is architecture- and board-specific from my  
view...

Andreas