[U-Boot-Users] Re: Some puzzles on dram_size()

* [U-Boot-Users] Re: Some puzzles on dram_size()
@ 2004-01-06 16:28 chris at nanometrics.ca
  2004-01-06 17:27 ` Wolfgang Denk
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: chris at nanometrics.ca @ 2004-01-06 16:28 UTC (permalink / raw)
  To: u-boot

Hi Sam,

Your problem with dram_size() may be that it tests memory
beyond the maxsize given.

     for (cnt = maxsize / sizeof (long); cnt > 0; cnt >>= 1) {
          addr = base + cnt;  /* pointer arith! */

          save[i++] = *addr;
          *addr = ~cnt;
     }

If maxsize = 16M, initial cnt = 4M, so if base = 0,
the first time through the loop, addr = 16M which is
the first address outside of the memory range given
to test.

The reason it usually works is that most boards make the
AM (address mask) in the OR (option register) of the memory
controller specify more memory than they actually need.

This may be the easy way to fix it, however I would say the correct
way would be to change the lines
     for (cnt = maxsize / sizeof (long); cnt > 0; cnt >>= 1) {
     for (cnt = 1; cnt <= maxsize / sizeof (long); cnt <<= 1) {
to
     for (cnt = maxsize / sizeof (long) / 2; cnt > 0; cnt >>= 1) {
     for (cnt = 1; cnt < maxsize / sizeof (long); cnt <<= 1) {

Unfortunately it appears in many board specific versions.

While I'm@it, the entire function should be moved to a file in
the common directory and the function definition changed to
     long int dram_size (long int *base, long int maxsize)

The setting of the MxMR (memory A/B mode register) has nothing
to do with determining the DRAM size and should be done in the
calling function which is board specific.

I know, I'm free to submit a patch, but I'm a combination of
busy and lazy.

Chris

^ permalink raw reply	[flat|nested] 10+ messages in thread