[U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long
Tom Rini
trini at ti.com
Sat Oct 19 20:25:51 CEST 2013
On Sat, Oct 19, 2013 at 11:07:54AM +0200, Oliver Schinagl wrote:
[snip]
> What my patch fixes is, that u-boot passes ram parameters (ramsize)
> via the global data -> ramsize. Ramsize is a phys_size_t which is
> defined as unsigned long (yay for typedef :p). Nearly all platforms
> pass the memory size to the linux kernel as gd->ramsize =
> get_ram_size();
>
> And here is the bug, (unsigned long)ramsize = (signed long)get_ram_size();
Well, here's where we have a few related problems. We need to:
a) Know how much memory U-Boot has available to it, to work with (for
relocation, image loading, etc, etc)
b) Tell an OS how much memory exists via ATAGs or Device Tree.
(b) is what gets complicated because the rule of thumb U-Boot has had
forever is to update the device tree to have "correct" memory
information. A number of PowerPC boards have dtb files with 0x0 for
size, for auto-detect in U-Boot. A number of ARM boards just have
128MiB size and then work well in Linux as we fixup that incorrect
amount to the larger real value.
We need a way to add in support for case (c) of "Device Tree has correct
memory information, DO NOT TOUCH". This has been talked about before
but what I said in (b) complicates things. We may way to see if for
example the DT indicates a size beyond what we can determine and if so,
just go with it (and perhaps a debug() print about not touching).
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131019/857b70b5/attachment.pgp>
More information about the U-Boot
mailing list