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

[Rob Landley]

On 05/10/2011 12:13 AM, Alexander Graf wrote:
> 
> 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 :).

Oh sure.  That's why I haven't posted the patch yet.

I read through enough to assemble a very rough todo list (call
load_elf(), figure out if the kernel can run from the read-only ROM blob
or if I need to copy it to normal DRAM like some targets do, figure out
where the structure rdev used to patch lives in the blob the ELF loaded
so we can set the right field in it to specify where the command line
lives, figure out what we need to add to said command line...)

But it's not in the top 5 of my todo list today...

>> 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 :).

Which is why -kernel needs to fix up the result (if nothing else, to
feed it a command line).

> Basically, -kernel with an OpenBSD ELF kernel would be different.

My lack of caring about OpenBSD cannot be expressed in words.  Does the
current -kernel option support OpenBSD kernels?  If so, I wouldn't be
introducing any regressions.

> You somehow need to be able to find out the boot protocol.

No, I don't.  I need to ignore OpenBSD with the force of a thousand DMV
agents on break.

"Your new thing would continue not to do something the current -kernel
option doesn't support".  Yes.  Yes it would.  I don't see how this is
considered a valid objection.

> 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!

The current -kernel option will happily load a TEXT FILE.  The result
does not boot, but it makes pretty pictures in the VGA screen.

Feeding -kernel an OpenBSD kernel is only slightly less useful than
feeding it a text file, and if you want multiboot you know where to find
it.  (There's code for that in qemu now, it's just not at all
interesting to me.)

>> 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.

A linux kernel bootloader.  It's 100% linux-specific.  Always has been.

Feel free to provide a counter-example.  Show me how to boot an OpenBSD
kernel with "qemu-system-x86_64 -kernel".

> There's more out there than just Linux :).

The current code disagrees with you.  This project's been around for a
decade and nobody's ever bothered to add BSD support to -kernel, and I
won't either.

If you'd be more comfortable if the command line option was renamed
"-linux", feel free to submit a patch, but you're currently arguing
against the existing code, not against the patch I'm writing.

Rob