Hello,
First of all, I'd like to know if mkelfimage is still needed when using CBFS and LAB payloads, and what would be its purpose once the kernel can already be compiled as an ELF vmlinux binary with initramfs included, using for example buildroot and the kernel buildsystem's features.
Does it have anything to do with the multiboot specification, or why does coreboot need the ELF to be modified using the mkelfImage tool?
Thanks, Cristi
Cristi Magherusan wrote:
if mkelfimage is still needed
I don't know.
ELF vmlinux binary with initramfs
Yes, it's a good idea. Please try it and report if it works. Also see http://www.coreboot.org/Initramfs
Does it have anything to do with the multiboot specification,
No, multiboot is a separate topic.
or why does coreboot need the ELF to be modified using the mkelfImage tool?
I am not sure that it does need that. Did you try using the plain vmlinux?
Can you compare the vmlinux entry point with the entrypoint of an mkelfImaged ELF image?
//Peter
On Sun, 2009-08-09 at 22:33 +0200, Peter Stuge wrote:
Cristi Magherusan wrote:
if mkelfimage is still needed
I don't know.
ELF vmlinux binary with initramfs
Yes, it's a good idea. Please try it and report if it works. Also see http://www.coreboot.org/Initramfs
I have a similar image generated using buildroot(for the userland/initramfs), and the kernel's initramfs option that allows it to use a designated directory.
It seems to fail with both approaches when using CBFS (qemu with LAB kernel). With mkelfimage qemu crashes, while without it freezes while trying to load the kernel. The same kernel boots in qemu when compiled as bzImage, and the userspace is loaded fine.
Does it have anything to do with the multiboot specification,
No, multiboot is a separate topic.
or why does coreboot need the ELF to be modified using the mkelfImage tool?
I am not sure that it does need that. Did you try using the plain vmlinux?
Yes, still fails.
Can you compare the vmlinux entry point with the entrypoint of an mkelfImaged ELF image?
It differs, I suppose mkelfimage adds its own binary glue that will run before calling the real kernel image. Here's the "readelf -h" output for both(first is with mkelfImage).
File: ./buildroot-payload.elf ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x10000 Start of program headers: 52 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 5 Size of section headers: 0 (bytes) Number of section headers: 0 Section header string table index: 0
File: ./vmlinux ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x100000 Start of program headers: 52 (bytes into file) Start of section headers: 4995368 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 3 Size of section headers: 40 (bytes) Number of section headers: 30 Section header string table index: 29
I'll try to make the kernel entry point the same as mkelfimage, but I doubt it will work. Any other ideas?
If anyone decides to give it a try, the kernel images are available here: http://panzer.utcluj.ro/~alien/coreboot/elfs.tar.bz2
Thanks, Cristi
You should not need mkelfimage, and have not needed it for a long time.
I'll take a look at those images.
ron
Well, I think I see your problem. Check this out:
ENTRY(startup_32) /* test KEEP_SEGMENTS flag to see if the bootloader is asking us to not reload segments */ testb $(1<<6), BP_loadflags(%esi) jnz 2f
/* * Set segments to known values. */ lgdt pa(boot_gdt_descr) movl $(__BOOT_DS),%eax movl %eax,%ds movl %eax,%es movl %eax,%fs movl %eax,%gs 2:
So things have changed a bit since the last time I did this type of thing.
It's expecting esi to point somewhere sensible (is it?) and it's expecting that somewhere to have resonable boot flags.
Now IIRC this kernel loads fine with Filo. Probably time to look and make sure you are doing what FILO does.
ron
On Sun, 2009-08-09 at 15:01 -0700, ron minnich wrote:
You should not need mkelfimage, and have not needed it for a long time.
I'll take a look at those images.
ron
Hello,
I just noticed something interesting... The ROM with CBFS with vmlinux included (without using mkelfImage) seems to boot, or at least gets loaded by cbfs.
After the VGA BIOS runs, the emulator shows up some kernel messages that appear when hardware discovery is performed (printed over of those of the VGA BIOS) but then it seems to hang, and the CPU is at 100% like in an infinite loop which looks much like a kernel panic.
It seems there's smoething wrong in my kernel config, I'll check it again..
Cristi
On Tue, Aug 11, 2009 at 2:25 AM, Cristi MagherusanCristi.Magherusan@net.utcluj.ro wrote:
I just noticed something interesting... The ROM with CBFS with vmlinux included (without using mkelfImage) seems to boot, or at least gets loaded by cbfs.
we really need to try this on simnow. Try reconfiguring your kernel again and see what goes on. Also, are you trying the experiment of loading the kernel with gpxe/filo/whatever to see if it boots?
ron
-
Cristi Magherusan -
Peter Stuge -
ron minnich