[U-Boot-Users] Still trying to get a stable 2.6.20.4 running on 8349ITX evalboard

[Timur Tabi]

Bruce_Leonard at selinc.com wrote:

> Just an update, I've had the kernel up and running a continuos "find" 
> command for the last 11 hours using the hardcoded DDR memory controller 
> values, so there's definitely something wrong with using SPD and the 
> memory that's installed on my 8349itx board.  Still working on figuring 
> out spd_sdram().

You may need to define CFG_DDR_SDRAM_CLK_CNTL.

You'll notice in spd_sdram() that not only is it really complicated, with dozens of 
if-statements, but there's quite a bit of code to handle various errata.  In other words, 
it's not surprising (well, to me, at least) that you may have encountered a hardware bug 
of some kind.  Alternatively

Fortunately, you have values that you know work.  Debugging should be easy, because all 
you need to do is figure out which value is incorrectly computed by spd_sdram() and then 
you can see how that value is calculated.  Most likely you'll see that the result of some 
SPD register is unexpected, in that it's either completely wrong or outside of a range 
that the code expects (e.g. your DDR is much faster than any other DDR that anyone's tried).

> I'll just float this out there in case anyone has a suggestion. 
> spd_sdram() runs (obviously) before the RAM is available.  So all my 
> variables are in the cache (which by the way is a really slick idea), but 
> I can seem to access those variables with the BDI or GDB.  I get a "Cannot 
> access memory at address 0xfd000ee8" message.  This message is a bit odd 
> to me since I'm "accessing" that memory location through the processor 
> itself, and I know the processor can access that memory, because it's 
> stack is also in the cache and it successfully boots therefore it can 
> access the memory.  So why can't I?  I'm sure it's some thing subtle that 
> I haven't yet learned about the 8349, but if any one could slap me up side 
> the head and point out the obvious that I'm missing I would appreciate it.

Well, this is what printfs are for.  What BDI config file are you using?  Make sure you're 
not using the one that enables RAM, because that one can't be used to debug U-Boot.

Oh wait, do you have the config file that I wrote?  I don't know if it's on the BSP.  Let 
me know if you don't have it.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale