|
From: <ebi...@ln...> - 2001-01-11 19:44:39
|
Ken Yap <ke...@nl...> writes: > |> 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. Well I have double checked the specs (i.e in the gabi documents), and it says that section table is optional, in several place. If you actually have a section table then yes the first entry needs to be a dummy. > |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. It's close. Once you are dumped out of the container you need to be in a well defined state. If you are going to be in 32bit mode with paging disabled the following things also should apply. 1) All of your segment registers are loaded with an unlimted segment. This means that every segment is valid to use until you reload it. And you don't need any kind of segment table. 2) You should know what kind of environment you are coming into. And some easy to find, parse, and ignore unknown parameters can be a big help. But as for changing of the config option I have no problem. > 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? Sort of. And I do agree that there is definentily some value in stubs. But I think there should be at least enough passed to the stub so that knows if there is a BIOS present for it to call down to. In the linuxBIOS case I don't have a BIOS is the normall accepted sense of the word. For things like hard coding command lines, and locations of ramdisks stubs are definentily the right solution. > > What does your image look like? What I have is: 1. convert_param.c 2. kernel 3. Ramdisk (optional) convert_param.c converts multiboot headers, and my redesigned headers, holds the hard coded kernel parmeters. I use a little perl program call mkelfImage to generate this. I don't currently have any 16 bit code, I start the linux kernel in it's 32bit entry point. Eric |
