[U-Boot] [PATCH] tools: fix FIT image with ramdisk

[Tom Rini <trini@ti.com>]

On Sat, Jul 20, 2013 at 07:36:12PM -0400, Tom Rini wrote:
> On Sat, Jul 20, 2013 at 05:29:19PM -0600, Simon Glass wrote:
> > +Stephen
> > 
> > Hi Tom,
> > 
> > On Sat, Jul 20, 2013 at 4:38 PM, Tom Rini <trini@ti.com> wrote:
> > 
> > > On Sat, Jul 20, 2013 at 04:06:27PM -0600, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Sat, Jul 13, 2013 at 8:55 PM, Tom Rini <trini@ti.com> wrote:
> > > [snip]
> > > > > No, because what we have today is insufficient for the kernel, you
> > > > > still have to specify the load/entry point, in FIT at least, even on
> > > > > NOLOAD.  I'd have sworn at least, I couldn't find a way to get around
> > > > > this problem before...
> > > > >
> > > >
> > > > NOLOAD does work provided that the kernel in the FIT is a zImage.
> > > > Personally I think that is an odd thing to do, since U-Boot is perfectly
> > > > capable of decompressing a kernel, and the decompression shim requires
> > > ugly
> > > > hacks for caches and low-level serial access.
> > >
> > > I haven't seen a .its with a NOLOAD kernel that doesn't specify a
> > > load/entry property for it.  If you've got one, and it works on a
> > > Beaglebone (which doesn't have DDR starting at 0x0 ...), I'd love to see
> > > the .its :)
> > >
> > 
> > We use one with load/exec addresses of 0 (on a platform with no RAM there).
> > With NOLOAD the address seems to be ignored anyway.
> 
> OK, I shall play around again now that I've got a I swear working
> FIT image.

Following up to myself, yes, a load/exec address of 0 (which I found to
be counter-intuitave) means that kernel and ramdisk are both used
in-place and not relocated.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130813/e194ea57/attachment.pgp>