On 05/09/2011 10:50 AM, Peter Maydell wrote: > On 9 May 2011 16:11, Alexander Graf <ag...@suse.de> wrote: > [about -kernel, unless I've got confused] >> The issue is that this is not how it works on real hardware. Grub won't just >> load a vmlinux file and boot it. 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 we do that we need to document what the new way of doing "just load > and jump to the entry point of my not-a-linux-kernel ELF image" is; at > the moment for ARM that use case is supported by -kernel (the code > specifically handles ELF images as not-kernels), so changing that would > be a back-compatibility break...
Arm doesn't need nearly as much setup as x86, some boards just map flash at the physical start address with a jump straight to the kernel entry point. On arm there's no legacy start mode, meaning no 16->32 bit transfer requiring mmu initialization as part of the setup. (I believe arm starts with a 1-1 virtual/physical mapping in the absence of initialized page tables, or something like that.) The big black magic thing coreboot/bios and uboot do is DRAM refresh, which QEMU simply doesn't care about: we map dram from the host and it gets refreshed at that level. So this behavior may actually be correct for Linux in the absence of a device tree (which just means initializinng a register to point to it on ppc, dunno what ARM does). And if you feed in an "-append" option to set a kernel command line, then you know it's a linux kernel. If we explicitly ask for more setup, then you know to do more setup. (I think that bit still needs to be written, I have to go read the code...) Rob
