[U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long

[Scott Wood <scottwood@freescale.com>]

On Thu, 2013-10-03 at 23:15 +0200, Oliver Schinagl wrote:
> Hey all,
> 
> I just yesterday received my CubieTruck (cubieboard3) with 2 GiB of Ram 
> and added support for it to the sunxi-u-boot branch. While I know this 
> isn't merged into the main u-boot tree (yet), I ran into the following 
> problem.
> 
> At the end of the dram init code, it is customary to call get_ram_size() 
> and return its value. This is then used to print the DRAM size and also 
> is passed to the Linux kernel.
> 
> However the return size of get_ram_size() is a long. While I don't 
> understand why not unsigned long or even u64 was chosen, this causes 
> get_dram_size to overflow when having a ramsize of 2 GiB. While only 
> printing of the value isn't hugely important, this does indicate u-boot 
> seems to be somewhat artificially limited to 2 GiB of Ram? This only 
> seems to affect the SPL as, if I understood correctly, there it stores 
> the ram_size into the gd struct which I think is unsigned long.
> 
> I've started working on a patch to convert common/memsize.c's 
> get_ram_size(), to be completely unsigned long, however there seems to 
> be quite a lot of code that calls this. So my question is now before 
> going over all drivers and change that and submit a big patch-set, did I 
> overlook anything and are my conclusions correct, get_ram_size should 
> return unsigned long.

get_ram_size() is inherently incapable of dealing with memory that is
too large to be mapped all at once.  It also would have a hard time with
2GiB RAM, because it sizes by powers of two, so the next address to be
checked would be at 4GiB which cannot be mapped on 32-bit (plus, at such
large RAM sizes you run a significant risk of a false positive by
hitting I/O).

Can't you get the RAM size from the memory controller config instead?

> Finally, a long is 32 bits on x86 and armv7, but how will that relate to 
> 64bits armv8? As I understood, Windows treats long's as 4 bytes no 
> matter if it's 32 bit or 64 bit. Linux is better and a long is 4 bytes 
> on 32 bits, and 8 bytes on 64 bits versions. So how will u-boot work on 
> armv8? Will the long datatype work well, or should I consider changing 
> things more future proof? (u32 and u64 come to mind).

U-Boot on armv8 follows an LP64 model just like Linux.

-Scott