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

[Alexander Graf]

On 10.05.2011, at 06:58, Rob Landley wrote:

> On 05/09/2011 09:11 AM, Alexander Graf wrote:
>>> C) requires more research, because I have to make sure the entry point
>>> is either doing the 16->32 (or 64) bit startup dance or that it's being
>>> launched in the right mode (which the bios isn't doing), but vmlinux
>>> doesn't need to be decompressed and copied so it's just making sure
>>> we're expecting the right layer of stuff.  Which means reading through
>>> arch/x86/boot to see what the vmlinux->bzImage packaging is adding, I
>>> suppose.
>> 
>> The issue is that this is not how it works on real hardware.
> 
> Real hardware doesn't have the -kernel option.  On x86 that option is
> currently patching the rdev area after loading the blob into DRAM.
> 
>> Grub won't just load a vmlinux file and boot it.
> 
> The -kernel option doesn't load grub, it loads a _kernel_.  -kernel is a
> linux-specific bootloader.  It doesn't chainload other bootloaders.

My point is that -kernel is on the same level as grub. It's a bootloader - just 
(mostly) implemented in host mode, not guest mode. I'm not objecting to your 
idea. Just saying that what you're doing isn't streamlined in Linux atm, so you 
might hit barriers that people didn't expect :).


> 
>> I'm not even sure how much exactly
>> the early entry code handles in Linux before it jumps to the ELF entry
>> point.
>> 
>> Either way, if you get something rolling that also ensures that it fails
>> when it's an ELF file that's not Linux, I'd be very open to it :).
> 
> If it's an ELF file that's not Linux, I can ensure the result won't boot
> Linux.  It's guaranteed to fail without me doing anything.
> 
> I don't understand your objection.  (The option is called -kernel.  It
> does what it says on the tin.  If you feed it something that isn't a
> kernel, which you can do now, this is pilot error.)
> 
> By the way, I just did "qemu -kernel qemu-img" an the emulated vga
> screen was very colorful.  Feeding it qemu-io gave a different pattern
> of vga text mode garbage.  It's happily loading an elf file _now_, and
> spinning its little CPU on the resulting garbage...

IIRC -kernel loads ELF images as raw blobs atm. Just try to implement it and 
you'll see what I mean, seriously :).

Basically, -kernel with an OpenBSD ELF kernel would be different. You somehow 
need to be able to find out the boot protocol. Either it's defined by 
architecture or by random OS conventions. If you can somehow make sure that a 
kernel really is Linux and nothing else, speaking some random Linux boot 
protocol with it is just fine!

> 
>>> But "-kernel vmlinux" is not currently at the top of my todo list, lemme
>>> finish studying the v9fs code first...
>>> 
>>>> Point being, the handling of -bios is board-specific (not even
>>>> architecture-specific) and thus inconsistent.
>>> So, currently, is -kernel.  Having it accept vmlinux on more platforms
>>> would make it more consistent.  (Having -bios accept that too sounds
>>> great, but is orthogonal to what I'm trying to do.)
>>> 
>>>> Your points above - page
>>>> tables, TLB entries etc. - only apply to -kernel but not to -bios, that
>>>> should give us a bare-metal machine.
>>> In 16 bit mode.
>> 
>> Depends on the machine. On PPC e500 for example, even with -bios we have
>> to set up TLB entries, but those are at least defined by the spec :).
> 
> Yes, -kernel has to do setup work before starting the kernel.  This is
> true now, it remains true if the kernel is in a different file format.
> -kernel is a linux bootloader, which is not the same thing as the -bios
> option.

I disagree. -kernel is a _kernel_ bootloader. There's more out there than just 
Linux :).


Alex




> 
> Rob