From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 10 Nov 2011 12:10:58 -0700 Subject: [U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD In-Reply-To: <201111101940.40863.marek.vasut@gmail.com> References: <1320860840-6347-1-git-send-email-swarren@nvidia.com> <201111101907.39470.marek.vasut@gmail.com> <4EBC1702.6090302@nvidia.com> <201111101940.40863.marek.vasut@gmail.com> Message-ID: <4EBC21C2.7080903@nvidia.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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) -- nvpublic