Hi Wolfgang,
On Tue, Feb 7, 2012 at 9:27 AM, Wolfgang Denk wd@denx.de wrote:
Dear Albert ARIBAUD,
In message 4F304463.1050901@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