On Sat, 2013-10-19 at 01:07 +0200, Oliver Schinagl wrote:
On 10/18/13 18:43, Scott Wood wrote:
On Fri, 2013-10-18 at 02:04 +0200, Oliver Schinagl wrote:
So now that that's settled, anything fundamentally wrong with my patch? :)
Did you see my other mail in this thread? This patch is sort of OK for
Sorry I did and I got distracted from it.
raising the get_ram_size() limit from 1 GiB to 2 GiB (with an increased risk of false positives from I/O), but it can't go beyond that on
I'd ask 'how so' but I'm not sure I'd understand anyway ;)
Do you mean why it can't go beyond 2 GiB? The next address to probe after 0x8000_0000 would be 0x1_0000_0000 which is beyond what can be addressed in a 32-bit environment. I suppose you could return 4 GiB if 0x8000_0000 tests OK, but nothing beyond that. You'd need a larger datatype than "unsigned long" if you want to return 4 GiB, though.
And the one 64-bit environment that we're about to have in U-Boot (armv8) has discontiguous memory, which is another case where get_ram_size() won't work.
32-bit. A better approach would be to get the RAM size from the memory controller, which is what we do on many Freescale PPC boards.
Not possible for us at this moment. The memory controller is programed with hard-coded values on a per board basis. I think we could technically obtain values via/from the memory controller, but have no knowledge at this moment. Allwinner has a tool, livesuit, which is used to flash full disk images to a device. We currently guesstimate that livesuit can somehow detect the memory parameters and injects it into the stock bootloader. But we really have no clue if that really happens or how it's done. So we rely on extracting the information from a running stock android/linux and hardcode it into u-boot.
So the issue is that you don't have documentation on what the values you program into the memory controller mean? Can you extract the memory size as well from a running stock image?
BTW, shouldn't get_ram_size restore the original data in the final "return (maxsize)" case? I know, patches welcome. :-)
-Scott