On 10/19/13 01:25, Scott Wood wrote:
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
Yeah why can't it go beyond 2 GiB. It should be an unsigned long, so it should be able to go beyond 2 GiB, as you state, upto 4 GiB on a 32-bit environment.
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();
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.
As for returning exactly 4 GiB, assuming that register space is 0 bytes (impossible but lets just say for arguments sake) we now have 0x8000_0000 addresses available, so exactly 4 GiB. If for whatever reason it ends up being only 4 GiB -1 byte, I don't think anybody will care/notice (but it would have to be taken into account I suppose?
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.
So get_ram_size() needs a brother, get_discont_ram_size? :)
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?
Sort of, we bus-width, io-size and chip density, from those values we determine the chip-size/ram-size we can't exctract the actual number.
That said, io-size I think (or was it bus-width?) while programmed into the ram controller, isn't even highly important, it is expected that it is used for drive strength, 2 chips vs 4 chips, but physical examination of the tablet/board helps here.
Oliver
BTW, shouldn't get_ram_size restore the original data in the final "return (maxsize)" case? I know, patches welcome. :-)
-Scott