[U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?

[Graeme Russ]

Hi Wolfgang,

On Tue, Feb 7, 2012 at 9:27 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Albert ARIBAUD,
>
> In message <4F304463.1050901 at aribaud.net> you wrote:
>>
>> > In my experience, the offset is consistent on a given platform so once
>> > you do the dance once to figure out where it'll be placed you can just
>> > start off debugging post-relocation.
>>
>> That's for a given platform *and* a given U-Boot build, since the U-Boot >
>
> ...and for a given set of configured options and environment settings.
>
> Change the size of the PRAM area, or change the resolution of your
> graphics controller (and thus the size of the frame buffer), or change

The graphics controller memory may not be in main memory - It could be
in the PCI address space, in which case it may not affect the relocation
address

> the size of the log buffer, or ...
>
> There is a _plenty_ of reasons why the relocation address may change,
> even for a given binary image and a given piece of hardware.

Note that x86's E820 address map tells the kernel which physical pages of
memory are reserved for system use - Paging takes care of defragmenting
the physical address space to provide the kernel and user mode code a
virtual linear address space. Technically, U-Boot does not need to be
relocated for x86 at all, even if we want to keep it in RAM - We just tell
the kernel that the physical address space that U-Boot resides in is
reserved

There are a lot of other arches besides PPC ;) And a lot of boards which
will be shipped with an extremely static configuration (lots of consumer
devices like set-top boxes etc only have one physical configuration)

As I've said before, the new INIT_CALL framework will (hopefully) provide
much better control at the board level with zero impact on the arch or
common code - not just for relocation, but for all sorts of SoC defined
functionality.

Regards,

Graeme