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

[Stephen Warren]

On 11/10/2011 11:40 AM, Marek Vasut wrote:
>> On 11/10/2011 11:07 AM, Marek Vasut wrote:
>>> Stephen Warren wrote:
>> ...
>>
>>>> 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.
>>>
>>> Well if you want an image where you have kernel+initrd, why not use
>>> initramfs ?
>>
>> As I understand it, initramfs is embedded into the kernel image, and
>> initrd is a separate file.
>>
>> (existing desktop) distros typically want their initrd as a separate
>> file, so they can rebuild the initrd separately from the kernel image -
>> i.e. ship a binary zImage for the kernel, but build the initrd at
>> (distro or kernel update) install time based on whether the user needs
>> RAID, LVM, crypto, random driver, ... modules or not. Rebuilding a
>> separate initrd file is pretty easy. Rebuilding the initramfs already
>> embedded into the kernel zImage is probably not.
> 
> This is definitelly a good point. But then, if you can load zImage, can't you 
> load initrd with u-boot?

Well maybe. I don't exactly follow what you're saying. My main point was
the if you need/want an initrd (which I think will become more common),
you're going to have to use mkimage to get U-Boot to accept it. If
you're using mkimage on the initrd anyway, then using mkimage on the
zImage seems like basically no extra work; just one more command to run
using tools you already have. I /think/ the only advantage of a bootz
command over bootm is the ability not to run mkimage on the zImage.
Hence, there's not much advantage to a bootz command.

Still, if you don't have an initrd, I guess a bootz command would save
you the mkimage step on the zImage.

Either way, I'm not really arguing against a bootz command; just
pointing out that in many cases it doesn't buy you that much. Still, it
does in other cases.

>>>> 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.
>>>
>>> Hm, isn't FDT supposed to contain the command line now ?
>>
>> Well, I don't think FDT supoprt is far enough along for any (ARM) SoC
>> that a distro could exclusively rely on it yet. But, I may be wrong. I'm
>> also thinking only of mainline; downstream support may be far more
>> advanced in many cases.
>>
>> Either way, the physical mechanism of passing the command-line to the
>> kernel (ATAGs vs. FDT) isn't relevant to this discussion; it's just a
>> transport mechanism.
>>
>> Distros will probably still need to adjust the command-line, e.g. to add
>> "quiet splash" to it or not based on whether a recovery or regular boot
>> is required.
> 
> That's true, but you can have the generic command line in FDT and then pass 
> changed command line through u-boot environment. I don't see a reason why you'd 
> want to push it into uImage.

How can you get the cmdline modifications into U-Boot other that through
a (uImage-based) U-Boot script? I don't think a distro installer is
going to grovel in U-Boot's saved environment and modify that to its
wishes (and even if it could, it shouldn't)

-- 
nvpublic