[U-Boot] arch/powerpc/lib/board.c:get_effective_memsize() for 4GB+ systems

[Robert Thorhuus]

> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org] 
> Sent: den 21 september 2012 14:50
> To: Robert Thorhuus
> Cc: 'Tabi Timur-B04825'; u-boot at lists.denx.de
> Subject: Re: [U-Boot] 
> arch/powerpc/lib/board.c:get_effective_memsize() for 4GB+ systems
> 
> 
> On Sep 21, 2012, at 6:54 AM, Robert Thorhuus wrote:
> 
> >> -----Original Message-----
> >> From: Tabi Timur-B04825 [mailto:B04825 at freescale.com]
> >> Sent: den 21 september 2012 13:37
> >> To: Robert Thorhuus
> >> Cc: Kumar Gala; u-boot at lists.denx.de
> >> Subject: Re: [U-Boot]
> >> arch/powerpc/lib/board.c:get_effective_memsize() for 4GB+ systems
> >> 
> >> Robert Thorhuus wrote:
> >> 
> >>> I really see the advantage of keeping this map you have. It is of 
> >>> course more compatible with different OSEs and you do not
> >> need to do
> >>> anything special with 32/64 bit cores. But at the same time
> >> you never
> >>> take advantage of a 64 bit core with this approach.
> >> 
> >> U-Boot is a boot loader, not an operating system.  What is U-Boot 
> >> supposed to do with more than 2GB of RAM?
> >> 
> >>> How should I access my 24GB in U-Boot?
> >> 
> >> You should not!
> >> 
> >>> So really you are saying that I should have a 2GB map 
> window in my 
> >>> 32-bit address space and then move this window depending on what 
> >>> memory I want to access? A bit cumbersome I must say. But ok.
> >> 
> >> Again, you're doing the wrong thing with U-Boot.  It's a 
> boot loader. 
> >> It's supposed to find your OS, load it into memory, and 
> then boot it.
> >> 
> >>> How about the U-Boot relocation?
> >> 
> >>> As I see the code, it is not easy to decide where it should
> >> relocate.
> >>> It will be either relocated to end of RAM or if we have
> >> more than 4G
> >>> it will be at 4GB end.
> >> 
> >> It relocates to the end of RAM or the end of 2GB, 
> whichever is lower.  
> >> It ignores all memory above 2GB.
> >> 
> >>> What if you want to place U-Boot at 16MB for instance? Or 
> if you do 
> >>> not want a memory map hole at 4GB just because U-Boot
> >> doesn't handle
> >>> more than that?
> >> 
> >> Again, you're missing the point about U-boot.
> >> 
> >>> Last AND least I just want to say I'm used to creating
> >> memory maps in
> >>> bootloader which holds for the OS. It seems the time has come to 
> >>> annihilate my illusion...
> >> 
> >> Yes, please kill it with fire!
> >> 
> >> --
> >> Timur Tabi
> >> Linux kernel developer at Freescale
> >> 
> > 
> > Hello Timur!
> > 
> > You really used the machine gun there ;)
> > 
> > Ok. I'll just answer your 2GB+ usage question:
> > 
> > Testing!
> > No I will not be using much memory at all for 
> functionality. But the memory needs to be tested. What is 
> your proposal for that then? 
> > And I see U-Boot as the first software place for test and 
> debug. Maybe I want to read out RAM contents?
> 
> 
> Robert,
> 
> We have seen some cases for u-boot to access >4G of memory 
> directly.  However, the effort to get u-boot to be a 64-bit 
> clean just has never warranted the investment for the few 
> minor cases people have raised for wanting to address >4G directly.
> 
> The one case I usually hear about is DDR test.  We suggest 
> its easier to try and getting DDR testing to utilize a window 
> scheme into memory than it is for one to go make u-boot 64-bit.
> 
> :)
> 
> - k

Hello Kumar!

Ok. Since this seems to be the verified way I'll walk it.
I'll change the DDR testing to be "small" window based.

Still I wonder why the choice was made to have U-Boot relocate in high memory rather than low memory and also not making it easy to configure the relocation.

BR
Robert