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

[Oliver Schinagl <oliver+list@schinagl.nl>]

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.

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).

Thank you for any input regarding that issue.

Oliver