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

Aneesh V aneesh at ti.com
Tue Feb 7 08:19:10 CET 2012


On Tuesday 07 February 2012 04:11 AM, Graeme Russ wrote:
> 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)

I agree. Even on some platforms that are not fully static (such as having
variants with different memory sizes) the minimum available memory is
more than enough to allocate big enough partitions for each need at
U-Boot level. And my guess (or rather speculation) is that platforms
that do not have any real dynamic needs are in the majority. I sincerely 
believe that platforms should be allowed to enable/disable
relocation based on their needs.

br,
Aneesh


More information about the U-Boot mailing list