Hi,

On Sat, Jul 13, 2013 at 8:55 PM, Tom Rini <tr...@ti.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/13/2013 10:26 PM, Stephen Warren wrote:
> > On 07/13/2013 05:21 AM, Wolfgang Denk wrote:
> >> Dear Tom Rini,
> >>
> >> In message <20130712212416.GV13531@bill-the-cat> you wrote:
> >>>
> >>> A FIT image with a ramdisk that sets the entry or load points
> >>> to 0x0 must be treated as meaning "leave in place" and NOT
> >>> "relocate to 0x0".
> >>
> >> Why is this the case?  0x0 could be a valid address on some
> >> systems. If we need a special address that "cannot exist", we
> >> should rather use the last address in the addressable range (i.
> >> e. (void *)(~0)).
>

I'm not entirely sure what is happening with ramdisk loading. Prior to the
bootm factor it seemed to me that a ramdisk had to have a load address. It
was carefully extracted from the FIT node and then ignored. So my code
for FIT_LOAD_REQUIRED should in fact have done the same! I somehow assumed
that the address would be used. Was there ever any code in U-Boot which
actually loads the ramdisk to an address (other than boot_ramdisk_high()
which doesn't actually use the FIT node load address? If so I can't find it.


> >
> > For the kernel, we created a special image type for "no
> > relocation"; IH_TYPE_KERNEL_NOLOAD. Is an equivalent needed to the
> > initrd?
>
> 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.

But it does have one advantage - there is no need to specify a load address
in the kernel FIT node. It would be great if there were an environment
variable which specifies the kernel load address when none is given by the
FIT (I don't mean loadaddr which is used as the address of the FIT). Then
we could leave out the load address from the FIT node and boards could do
the right thing. Bonus points if the address could be an offset from the
start of DRAM, since then many platforms could probably have the same value.

Thoughts?

Regards,
Simon

<http://lists.denx.de/mailman/listinfo/u-boot>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to