|
From: Ken Y. <ke...@nl...> - 2001-01-09 03:50:49
|
|> 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? |
