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

[Marek Vasut]

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

Well you're contradicting to yourself. You said using initramfs is bad because 
distros won't have easy way to change it. Now you say adding initrd to uImage 
via mkimage is good. Why the heck can't we just load zImage and initrd without 
the envelope at all, uboot can do that?

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

No, but uboot can (and often does) source a script on the same device storing 
zImage and initrd. You just adjust the script.