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

[Stephen Warren]

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.

>> 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.

The idea is that the board vendor will supply the FDT image somehow,
with either a minimal Linux cmdline or perhaps even none at all. The FDT
might be stored in some non-filesystem location; perhaps embedded into
U-Boot, perhaps in SPI/NOR/NAND flash without a filesystem. As such, the
distro can't expect to be able to directly modify the FDT contents at
install time in order to set up the cmdline it wants. Even if the FDT
were stored in /boot/fdt.uimg, the distro would probably be well advised
not to manipulate it on disk, to make it easier for an end-user to
install an updated FDT with bugfixes.

Instead, U-Boot must write the cmdline into the FDT/ATAG when it boots
the kernel, and the value it writes may need to be manipulated by the
distro, I assume by the distro providing a U-Boot script to do the
manipulation.

-- 
nvpublic