From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 15 Oct 2013 13:01:58 -0500 Subject: [U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long In-Reply-To: <524DDE54.7090709@schinagl.nl> References: <524DDE54.7090709@schinagl.nl> Message-ID: <1381860118.7979.700.camel@snotra.buserror.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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