public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Timur Tabi <timur@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Still trying to get a stable 2.6.20.4 running on	8349ITX evalboard
Date: Fri, 13 Apr 2007 12:03:29 -0500	[thread overview]
Message-ID: <461FB7E1.9030707@freescale.com> (raw)
In-Reply-To: <OF46D87F28.4D9E2A5F-ON882572BC.0056E9AE-882572BC.0057E466@selinc.com>

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

  reply	other threads:[~2007-04-13 17:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CF7E46FCFF66AD478BB72724345289EC2795E6@twx-exch01.twacs.local>
     [not found] ` <OF2330A747.4AF0C4FD-ON882572BB.0077B95A-882572BB.0078B180@selinc.com>
2007-04-12 23:02   ` [U-Boot-Users] Still trying to get a stable 2.6.20.4 running on 8349ITX evalboard Kim Phillips
2007-04-12 23:16     ` Bruce_Leonard at selinc.com
2007-04-12 23:25       ` Kim Phillips
2007-04-13  0:49     ` Bruce_Leonard at selinc.com
2007-04-13 13:40       ` Benedict, Michael
2007-04-13 16:00         ` Bruce_Leonard at selinc.com
2007-04-13 17:03           ` Timur Tabi [this message]
2007-04-13 18:31             ` Bruce_Leonard at selinc.com
2007-04-16 21:25             ` Benedict, Michael
2007-04-17  0:10               ` Bruce_Leonard at selinc.com
2007-04-19  5:19             ` Bruce_Leonard at selinc.com
2007-04-20 18:13               ` Benedict, Michael
2007-04-20 19:50                 ` Bruce_Leonard at selinc.com
2007-04-20 19:58                   ` Benedict, Michael
2007-04-20 20:00                   ` Jon Loeliger
2007-04-20 20:18                     ` Bruce_Leonard at selinc.com
2007-04-13 16:55     ` Timur Tabi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=461FB7E1.9030707@freescale.com \
    --to=timur@freescale.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox