[U-Boot-Users] get_ram_size() returns wrong value

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Daniel Ann wrote:
> Hiya folks,
> 
> Somehow I've missed this before, but just today noticed that u-boot is
> reporting DRAM: 64 MB (BTW, machine is running with 128MB)
> 
> So, again, I had peaked inside the u-boot, and after doing some printf
> statements, I can get it to detect 128MB but I cant seem to get to the
> root of the problem. This is orginal code with my printf.
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>     for (cnt = 1; cnt < maxsize / sizeof (long); cnt <<= 1) {
> printf("*addr(%x)\n",*(addr=base + 0x1000000));
>         addr = base + cnt;  /* pointer arith! */
>         val = *addr;
>         *addr = save[--i];
>         if (val != ~cnt) {
>             size = cnt * sizeof (long);
>             /* Restore the original data before leaving the function.
>              */
>             for (cnt <<= 1; cnt < maxsize / sizeof (long); cnt <<= 1) {
>                 addr  = base + cnt;
>                 *addr = save[--i];
>             }
>             return (size);
>         }
>     }
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> I can see what the code does. It tries to write ~cnt value (first
> backingup) then read it in to see if it had written it successfully.
> 
> But problem lies at (base + 0x1000000). If u-boot detects val != ~cnt,
> then it will finish the loop right there and return size 64MB. If it
> succeeds, returns 128MB (which is what I have).
> 
> So, natually, I wanted to see what exactly does it change it to, and
> when, hence the printf. But guess WHAT? It reads back perfectly
> correct and return 128MB.
> 
> Do you guys think its timing issue ? Having printf natually adds delay
> factor to the code. Could this be HW problem ? (I can just throw it
> back to the HW people to get it fixed if so :) )
> 
> If I get desperate, I might just leave the dummy printf or hardcode
> the size, but for now, I wouldnt mind diving at it.

Its a memory problem.  Ultimately yes, it is a timing problem.  The 
question is where...
   * Is it your SDRAM initialization?
   * Is it a hardware/layout problem?
     * Are the address line lengths close to the same length?
     * Are the data line lengths close to the same length?
     * Is it a termination resistor problem (missing/wrong value)?
   * Is it the SDRAM itself?

Note that, with your printf(), you are repeatedly reading the memory at 
your boundary case address as well as changing the timing.  You are also 
doing a side-effect assignment to "addr" which gets discarded on the 
next line.

For identifying and debugging memory problems, those are bad practices. 
  Quite often a memory failure will show up on the first read, but be 
fine after that (which is apparently what you are seeing).  By doing 
multiple reads, you are throwing away any information you would have 
otherwise gleaned from the print statement (which may not be much, but 
hey, don't throw it away, it's all you have!).

My suggestion:

     for (cnt = 1; cnt < maxsize / sizeof (long); cnt <<= 1) {
         addr = base + cnt;  /* pointer arith! */
         val = *addr;
         *addr = save[--i];
         if (val != ~cnt) {
printf("*addr %08X => %04X != %04X\n",addr,val,~cnt);
             size = cnt * sizeof (long);
             /* Restore the original data before leaving the function.
              */
             for (cnt <<= 1; cnt < maxsize / sizeof (long); cnt <<= 1) {
                 addr  = base + cnt;
                 *addr = save[--i];
             }
             return (size);
         }
     }

gvb