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

[Marek Vasut]

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

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

Exactly, so the command line has nothing to do with uImage.

So basically, in the end, we need to 1) load zImage, 2) load initrd and 3) 
adjust command line. 1) and 2) can be done via standard commands, 3) via some 
script.

M