|
From: <ebi...@ln...> - 2001-01-09 03:05:07
|
Ken Yap <ke...@nl...> writes: > |What do you need a section header for? Sections aren't really applicable > |to programs, just relocatable content. > |You should only need to care about Program Headers. > > 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. > |> + Added code to support non-MULTIBOOT ELF when IMAGE_ELF is selected but > |> IMAGE_MULTIBOOT is not. Booting from images created by mkelf-linux > |> now works! > | > |I definentily need to review this and get a little discussion going. > |I have patches for linux to add a syscall to boot ELF images, > |on both x86 & alpha. > | > |It would be nice if etherboot had a compatible format. I intend to > |start writing just what beyond the elf format will be needed to be > |compatible. > > I'm just using ELF format as a container. You can continue to use > IMAGE_MULTIBOOT. My changes affect only what happens when > IMAGE_MULTIBOOT is not selected, which was undefined prior to my > changes. Seeing as the Linux kernel image file is actually a 3 section > image, and the sections are not the traditional code, data, bss at all; > the addresses in the image are tied to real physical addresses (no > relocation data) and real devices, what can your Linux patch sensibily > do when given an Etherboot ELF image? I need to read the code, to see what you have. But it should be able to boot an Etherboot ELF image just as etherboot does. Currently I have small linux program (I'll put it up for down load this week) that can do dhcp & tftp and the start the downloaded kernel, on top of a linux kernel. Currently I can create images that will booth with either etherboot or my program&kernel put on a linux floppy. This handles nicely the cards that linux supports that etherboot doesn't yet support. Or architectures (alpha) that etherboot doesn't support yet. The environment my kernel patch exports: images tied to real physical addresses. (You can have a virtual != physical address but the virtual is ignored). The processor comes up in native mode (32 bit protected mode on x86), with essentially virutal addressing disabled. (On some architectures you can't disable the mmu and have to create a page table to simulate this). A register is loaded with a pointer to a data block with information that you can't find out by probing the hardware, but you need. Like how much memory is in the system. BIOS tables in a know range of physical are considered probable. This that require BIOS calls are not considered probable. Not needing to do BIOS calls is important for me because I'm doing this as part of the work to get linuxBIOS going&useful. linuxBIOS being just a big enough stub to boot a kernel on a machine with none of the traditional legacy BIOS calls. Does this clarify where I'm coming from? Eric |
