On Tue, Oct 21, 2008 at 09:10:03PM +0200, Wolfgang Denk wrote:
I should have mentioned that we have DEBUG enabled and we've also run the RAM test that is included in u-boot. The ram test does pass.
Please see the FAQ, entry # 1. Passing the RAM test does not mean anything when it comes to accessing the RAM in burst mode.
Ok, makes sense I understand that the ram test is not sufficient to fully exercise the bus. In particular, it appears that it does not have lots of entropy, so shorted address/data may not be detected and the timing tolerance is much wider than would be found in normal operating conditions.
I am not familiar with those, I thought that once the SDRAM is operating you cannot alter those calibration and timing/delay registers. Is this calibration something that is enabled in u-boot or just via the register accesses to the memory controller?
How about reading the code?
(Looking at canyonlands.h)
Ok, I took a look at this and the autocalibration is not obvious. It looks like there is a currently a hardcoded RQDC value of 80000038. If this is undefined then the code will go into the autocalibration mode. So I've undefined it and sure enough it goes into autocalibration. The part that is odd is that the autocal does not work on the Canyonlands board. If it is enabled, then the Canyonlands fails in the same way as our hardware. I.e. right at the time of relocation, it just hangs. When set back to the hardcoded value, the canyonlands works fine.
Perusing the code, the only sort of exception that I noticed was one for the Katmai. During operation I don't see the code fail to find the window, so it appears that it finds a suitable value. When examined with the abatron it looks like a value is set into the mfio_rqdc register.
So I am somewhat puzzled. It is not obvious to me why the autocal is failing to work on the canyonlands.
On another project we found that the window constrained slightly when operating in burst mode (via DMA) vs regular ram line reads/writes. I don't know if that could be the same issue where since the failure is just at the time the burst mode is enabled.
Thanks, Ayman