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@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
