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.