[coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+ work

Eric W. Biederman ebiederm at xmission.com
Fri May 21 02:48:34 CEST 2010

Troy Telford <ttelford.groups at gmail.com> writes:

> 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:// .....(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.

ramdisk-base is just where in ram to load the ramdisk.  mkelfImage defaults
to 8M.  You are setting it to 20M.  With the change to kernels to default
them to running at 16M that only leaves 4M for the kernel which I expect is
to little.  Because mkelfImage is old and the hack is crude I don't
mkelfImage is to stupid to realize that we have a problem.


More information about the coreboot mailing list