|> At least one is needed otherwise objdump complains. And reading the spec
|> carefully you will see that the 0th entry is needed, it's a NULL entry.
|
|Hmm. I'll look but a section table should be unnecessary.
|I haven't tried striping it out though.
Mm, believe me. I ran gdb on objdump to find out what was going on.
Fortunately I resisted the temptation to call the objdump authors idiots
until I had double checked the spec.
|But it should be able to boot an Etherboot ELF image just as
|etherboot does.
Here's what a tagged Etherboot image contains, also an ELF Etherboot
image:
1. Small stub program (first32.c)
2. Kernel parameters
3. Kernel boot sector (boot.S)
4. Kernel setup sector (setup.S)
5. Kernel
6. Ramdisk (optional)
The stub program is there to handle append tag 129 to the parameters,
handle kernel parameters of the special form xxx=rom, vga=xxx, and move
the ramdisk to the top of memory. The stub program is passed 3
parameters, a pointer to a structure describing Etherboot, a pointer to
the header structure (tagged or ELF) so that the stub can find the
segments, and a pointer to the bootp record so that it can extract
necessary information out of that.
It then goes into real mode and calls the setup sector. The boot sector
is there because the setup code references bits of it. Eventually
protected mode is entered and the kernel is called.
From what you describe it sounds like you are processing the Linux
kernel in different way to generate an ELF image, perhaps even throwing
out everything except the kernel segment? If that is so, how do you
handle kernel parameters and ramdisks?
Nonetheless, your ELF image should load fine with or without
IMAGE_MULTIBOOT, as I said, it's just a container. The only difficulty
might be with obtaining the BIOS information. I would argue that
Etherboot should not do this but a stub should, just like above. Perhaps
you already have a stub segment to do this?
What does your image look like?
|