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

[Oliver Schinagl]

Hey all,

Having not received any feed back at all, I went ahead and did the 
changes anyway. Everything seems to run and work fine for sunxi and 
prints proper sizes.

For the other boards, I tried to run a MAKEALL but there where so many 
random other warnings I can't say for 100% certainty there where no 
mistakes that crept in. Boards where strange size conversion where done 
or it was assumed that the return value of get_ram_size() was long are 
typecast to have the same (erroneous) behavior. Boards that had simple 
fixes where fixed.

Ideally, every maintainer should check if their board requires deeper 
review and fixing due to this change.

Oliver

On 03-10-13 23:15, 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.
>
> 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
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot