[U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD

[Stephen Warren]

On 11/10/2011 10:47 AM, Marek Vasut wrote:
>> On 11/10/2011 10:01 AM, Marek Vasut wrote:
>>>> On 11/10/2011 02:58 AM, Marek Vasut wrote:
>>>>>> [Description of IH_TYPE_KERNEL_ANYLOAD]
>>>>>
>>>>> just a silly question, but didn't we agree on cmd_bootz? Or is this
>>>>> unrelated ?
>>>>
>>>> bootz did seem to be agreed upon initially, but Wolfgang's most recent
>>>> response suggested that a new IH_TYPE would be acceptable, and it's a
>>>> lot less code to implement. At a later point, bootz could still be
>>>> implemented if desired.
>>>
>>> Well DAMN. I think I'll probably implement bootz, because it seems
>>> superior solution which I DID NEED for one of my devices for a while now
>>> (if noone is working on it already). I can't say what ETA will be on
>>> that, maybe next week, maybe two weeks.
>>
>> Out of curiosity, why doesn't this bootm feature work for you?
>> Admittedly you still need to wrap the zImage inside a uImage, but I
>> don't think that's insurmountable? Aside from that, doesn't it work
>> exactly like a bootz command would?
> 
> Do you still have those +12bytes (sizeof(uImage header)) offset there?
> I don't like it.

The uImage file itself certainly includes the uImage header.

The code in my latest patches should be pointing images.os.load right at
the image start itself (i.e. pointing past the header), so I don't think
there's any incorrect offset within the code. This was really just a bug
in the "-1 load address" patches I posted anyway.

> Also, I think using zImage might be plain easier.

Well, admittedly it's slightly simpler not to wrap zImage in uImage,
since there's no need to run mkimage. However, with this new IH_TYPE,
all the mkimage parameters can be hard-coded (there's no need to specify
any real value for the addresses; just use 0), so the command-line is
pretty simple. Besides, I imagine the kernel uImage target can be
updated (or a new one added) to continue to do this for you.

I did consider that not running mkimage at all would be simpler, but
there are other places mkimage would still be needed anyway:

a) Any initrd would still need to be wrapped in a uImage for bootm to
recognize it. If you wrote a bootz to accept a raw unwrapped initrd, I
imagine that same raw initrd recognition code could just as easily be
applied to bootm.

b) The distro will most likely want to specify either the entire Linux
command-line, or at least something to append to it. I imagine this will
work by the distro creating a uImage-wrapped U-Boot script e.g.
/boot/script.uimg. Creating that script would require mkimage too.
Perhaps again U-Boot could be modified to support loading scripts from
disk and executing them without requiring a uImage header though.

So, I don't think eliminating mkimage entirely is all that likely. And
as such, using mkimage for the kernel itself doesn't seem like a big deal.

Still, I'm not a distro vendor, so I don't know what their feelings are
on this topic.

-- 
nvpublic