[U-Boot] [PATCH] tools: fix FIT image with ramdisk
Simon Glass
sjg at chromium.org
Sun Jul 21 01:29:19 CEST 2013
+Stephen
Hi Tom,
On Sat, Jul 20, 2013 at 4:38 PM, Tom Rini <trini at 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 at 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.
And another thing, perhaps instead of the NOLOAD image type, we should
generalise a bit and have a property in the FDT node to mean that loading
should be skipped, like 'no-load'. Then we could apply it to ramdisks and
FDT also, rather than relying on address 0 having a special meaning.
Perhaps I should have suggested this at the time.
Regards,
Simon
More information about the U-Boot
mailing list