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)