On Thursday, May 20, 2010 03:32:36 pm you wrote: > > Ugh. > > I can think of two things that might be useful. > > 1) Add a print statement into mkelfImage that prints the value of > kernel_alignment Most of the fields are already printed so this > just requires tweaking linux-i386/convert_params.c > > Where you still have a reboot in the kexec case I am a little curious > if everything applied ok.
I'm more curious, myself, at what happened in the past couple of hours to the hard drive... I've literally done __NOTHING__ to the binary generated, and nothing to the script I used (the script removes the old .ebi, uses mkelfImage to generate a new one, then kexecs it). Three hours ago, it behaved exactly as I said. I moved on to an entirely different task, and decided to revisit it after your reply. Now it is working, and its behavior is consistent between kexec and etherboot. I'm a bit WTF'd out about that... but I'll take the victory where I can get it. That being said, the program that calls mkelfImage (which you knew as cwx), runs the following command: mkelfImage --command-line="some stuff here" --kernel=kernelBinary --ramdisk- base=20971520 --ramdisk=ramDiskPath --output=file The .ebi files generated are the ones that are returning: Loading x-slam://10.0.10.1:10006/239.192.0.131:10006 .....(ELF)... done Firmware type: LinuxBIOS (and then does nothing) And that appears to be due to the --ramdisk-base= argument. Simply increasing the size allows the kernel to start - but then fails as it can't load the ramdisk. I'm a bit unclear on what --ramdisk-base actually does; so I'm willing to venture that it may be the source of our problem. I'll see what else I can figure out tomorrow. If you can enlighten me for the purpose of ramdisk-base, I'd appreciate it. (What an initrd load address is/means isn't something I know offhand). I'm going to look that up as well, but for now, I have to call it a night. -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
