[U-Boot] Hangs at relocation on 460EX Target

[Ayman M. El-Khashab]

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