On 05/08/2011 09:10 AM, Andreas Färber wrote: > 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.
I actually wrote a long reply and then save-as-draft rather than sending it because it boils down to "I need to do the work myself and send you a patch". What I meant was that the build for every Linux architecture produces a vmlinux file, which it often then packs into another format but on mips and powerpc the file I feed to -kernel is the elf vmlinux file. (Doesn't even have to be stripped.) Which is nice, because when I debug stuff with the -s option I need to feed the vmlinux file to gdb, so just having to keep track of one of the suckers is incredibly convenient. Being able to build 5 architectures without having to record an arbitrary path to whatever the output file is called this time is also nice. Yes, -kernel is linux-specific: so is vmlinux. Yes -kernel does various other stuff to boot a linux kernel, but at least half of it is obsolete things for 2.2 and earlier kernels, as described in the rdev man page. (And if you want to use such ancient kernels, you can always make a boot floppy image and use rdev, just just make a disk image with a bootloader in it from one of the install cds on http://archive.download.redhat.com/pub/redhat/linux or something.) Pretty much everything the kernel needs is on the command line these days, including vga settings and the physical starting address of the initial ram disk ("ramdisk_start=", see init/do_mounts_rd.c in the kernel). On most platforms the one thing it needs is a device tree pointer (in a register) and then it finds the command line data blob through that. I have no interest in GNU/multiboot, and neither does most of the rest of the Linux community from what I've seen. The GNU/hurd is welcome to it, the FSF has nothing to do with Linux. The people porting device trees to x86 soo the mechanism will be properly universal (that went into the 2.6.39 development series, by the way) are not referencing GNU/multiboot. I want to teach -kernel to accept a vmlinux file, not introduce crazy FSF code dependencies, which don't seem to be supported on any non-x86 platform yet despite being designed with Solaris in mind, into my build. What I want to do is actually somewhat straightforward, load_elf() is already used directly on several platforms like mips_r4k.c, the hard parts of making it work on x86 are A) properly editing the kernel command line instead of trying to recreate rdev, B) figuring out where to splice the kernel command line start address into a vmlinux instead of a bzImage, and C) starting in the right mode. 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. 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. Rob