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.