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