Hi Wolfgang, On Tue, Feb 7, 2012 at 9:27 AM, Wolfgang Denk <w...@denx.de> wrote: > Dear Albert ARIBAUD, > > In message <4f304463.1050...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
