On Mar 29, 2010, at 6:07 PM, Timur Tabi wrote:
On Mon, Mar 29, 2010 at 5:09 PM, Becky Bruce <beckyb@kernel.crashing.org
wrote:
<snip>
I think you need to adjust how much usable ram u-boot thinks it has if you can't map it all.
I tried that. The problem is that U-Boot uses this number to tell Linux how much DDR there is. The code doesn't really support U-Boot and Linux seeing different amounts of DDR.
If you have one BAT, and you have an amount of memory that is ! a power of 2, then you're going to leave a chunk unmapped, which can cause problems later.
AFAIK, we always have only one BAT for DDR. I wasn't planning on expanding the scope of this patch to add support for multiple BATs.
I'm not suggesting that - you really can't use multiple BATs as there are only 8 of them and they're a hot resource.
I don't know how to handle !2^X sizes of DDR.
You can't map !2^x sizes of DDR with one BAT, so in this case you're always going to end up with a mapping that's smaller than the actual size of DDR, which is a *new* scenario for 86xx. IIRC, before, we always set the BAT up for 2G, so we either 1) had *less* RAM than we had BAT mappings for or 2) pretended that we had 2G of memory and ignored the rest. Have you looked at 83xx or 85xx to see if they do anything interesting here? It's possible this problem has just been ignored other places, and we haven't had an issue yet. It should't be too complicated to get get_effective_memsize to report something reasonable.
+#define KB_TO_BATU(x) ((((x)/128) - 1) * 4) /* Convert KBs to BATU value */
It seems somewhat arbitrary that you decided to use take KB here as an arg when the BATU_SIZE macro returns bytes. I'd prefer to see symmetry here.
I used KB to keep the sizes of numbers small. The smallest value is 128KB, so it's not *that* arbitrary.
The other stuff used bytes. It's confusing. Just use bytes.....
-B