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

[Marek Vasut]

> On 11/10/2011 10:47 AM, Marek Vasut wrote:
> >> On 11/10/2011 10:01 AM, Marek Vasut wrote:
> >>>> On 11/10/2011 02:58 AM, Marek Vasut wrote:
> >>>>>> [Description of IH_TYPE_KERNEL_ANYLOAD]
> >>>>> 
> >>>>> just a silly question, but didn't we agree on cmd_bootz? Or is this
> >>>>> unrelated ?
> >>>> 
> >>>> bootz did seem to be agreed upon initially, but Wolfgang's most recent
> >>>> response suggested that a new IH_TYPE would be acceptable, and it's a
> >>>> lot less code to implement. At a later point, bootz could still be
> >>>> implemented if desired.
> >>> 
> >>> Well DAMN. I think I'll probably implement bootz, because it seems
> >>> superior solution which I DID NEED for one of my devices for a while
> >>> now (if noone is working on it already). I can't say what ETA will be
> >>> on that, maybe next week, maybe two weeks.
> >> 
> >> Out of curiosity, why doesn't this bootm feature work for you?
> >> Admittedly you still need to wrap the zImage inside a uImage, but I
> >> don't think that's insurmountable? Aside from that, doesn't it work
> >> exactly like a bootz command would?
> > 
> > Do you still have those +12bytes (sizeof(uImage header)) offset there?
> > I don't like it.
> 
> The uImage file itself certainly includes the uImage header.
> 
> The code in my latest patches should be pointing images.os.load right at
> the image start itself (i.e. pointing past the header), so I don't think
> there's any incorrect offset within the code. This was really just a bug
> in the "-1 load address" patches I posted anyway.
> 
> > Also, I think using zImage might be plain easier.
> 
> Well, admittedly it's slightly simpler not to wrap zImage in uImage,
> since there's no need to run mkimage. However, with this new IH_TYPE,
> all the mkimage parameters can be hard-coded (there's no need to specify
> any real value for the addresses; just use 0), so the command-line is
> pretty simple. Besides, I imagine the kernel uImage target can be
> updated (or a new one added) to continue to do this for you.
> 
> 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 ?
> 
> 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 ?
> 
> Still, I'm not a distro vendor, so I don't know what their feelings are
> on this topic.

It's good to discuss stuff actually! It only mustn't turn into flamewar ;-)

M