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.