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 <tr...@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 <tr...@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
