|
From: <ebi...@ln...> - 2001-01-12 19:05:27
|
Ken Yap <ke...@nl...> writes: > |> 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. > > All the same, even though I specified 0 for the number of section table > entries and null for the offset, the tools went looking for a section > table. Feel free to take this up with the BFD maintainers yourself, I'm > not going to lose sleep over 32 bytes extra in the file. No I won't either but if I get the chance I'll complain to them... > |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. > > Etherboot doesn't have any 16 bit code either (except for the BIOS > calls) when it's calling the extension in protected mode. The only 16 > bit mode code is in boot.S and setup.S from the kernel. > > So it looks like you have all that you need already. Hmm. I'll have to look and see what etherboot is doing now. More feedback after I have read your code :) > > I might even change the code to detect the multiboot magic number > automatically and eliminate one more configure option. Actually that's an interesting kettle of fish. Maybe I misread the multiboot stuff but as I read it you only need the magic number for a.out executables.... Eric |
