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

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

[Kim Phillips]

[switching over to u-boot-users]

On Thu, 12 Apr 2007 14:58:17 -0700
Bruce_Leonard at selinc.com wrote:

> 
> about memory timing I remembered that the 8349itx u-boot port allows the 
> choice of using SPD for detecting the DDR RAM or using hard coded defaults 
> in the memory controller.  I figured what the heck, I'll give the hard 
> coded values a try even though they were probably wrong for the particular 
> part I've got installed.  And the bloody thing ran!  I had it executing a 

I just applied the last spd patch I had in my queue to the
u-boot-mpc83xx.git tree on denx.de.  Can you please pull & test?

Kim

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

[Bruce_Leonard at selinc.com]

Kim,

Kim Phillips <kim.phillips@freescale.com> wrote on 04/12/2007 04:02:51 PM:

> [switching over to u-boot-users]
> 
> I just applied the last spd patch I had in my queue to the
> u-boot-mpc83xx.git tree on denx.de.  Can you please pull & test?
> 
> Kim

I'll give it a try this evening and get back to you by tomorrow.  Is this 
a full tree that I can just clone or do I need to try and git a particular 
commit and merge it with what I've pulled from the main line at denx.de? 
Sorry if this is a basic question, but I'm a total newbie with git.

Bruce


------------------------------------------------

This e-mail may contain SEL confidential information.  The opinions
expressed are not necessarily those of SEL.  Any unauthorized disclosure,
distribution or other use is prohibited.  If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout.

Thank you.

------------------------------------------------

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

[Kim Phillips]

On Thu, 12 Apr 2007 16:16:13 -0700
Bruce_Leonard at selinc.com wrote:

> Kim,
> 
> Kim Phillips <kim.phillips@freescale.com> wrote on 04/12/2007 04:02:51 PM:
> 
> > [switching over to u-boot-users]
> > 
> > I just applied the last spd patch I had in my queue to the
> > u-boot-mpc83xx.git tree on denx.de.  Can you please pull & test?
> > 
> > Kim
> 
> I'll give it a try this evening and get back to you by tomorrow.  Is this 
> a full tree that I can just clone or do I need to try and git a particular 
> commit and merge it with what I've pulled from the main line at denx.de? 
> Sorry if this is a basic question, but I'm a total newbie with git.
> 
it's a full tree you can clone or pull into any existing u-boot git tree:

git pull git://www.denx.de/git/u-boot-mpc83xx.git

if it doesn't apply, git will give you instructions..

You can always view commitdiffs in denx.de's gitweb interface, this one is:

http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-mpc83xx.git;a=commitdiff;h=6fbf261f8df294e589cfadebebe5468e3c0f29e9

Kim

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

[Bruce_Leonard at selinc.com]

Kim Phillips <kim.phillips@freescale.com> wrote on 04/12/2007 04:02:51 PM:

> [switching over to u-boot-users]
> 
> On Thu, 12 Apr 2007 14:58:17 -0700
> Bruce_Leonard at selinc.com wrote:
> 
> > 
> > about memory timing I remembered that the 8349itx u-boot port allows 
the 
> > choice of using SPD for detecting the DDR RAM or using hard coded 
defaults 
> > in the memory controller.  I figured what the heck, I'll give the hard 

> > coded values a try even though they were probably wrong for the 
particular 
> > part I've got installed.  And the bloody thing ran!  I had it 
executing a 
> 
> I just applied the last spd patch I had in my queue to the
> u-boot-mpc83xx.git tree on denx.de.  Can you please pull & test?
> 
> Kim

Your patch didn't seem to make any difference so I'm going spend the next 
few days trying to figure out why (it may very well be that the memory 
module we have in the board isn't a correct one for SPD to work tho it's 
what shipped in the board so I would expect it to be correct).  Since I 
know very little about DDR RAM and SPD it may take me a few days to figure 
out what's going on.  On the flip side I may be a good person to figure it 
out because I'll suspect everything and take nothing at face value since I 
know nothing.  ;)

I'll keep you posted.

Bruce

------------------------------------------------

This e-mail may contain SEL confidential information.  The opinions
expressed are not necessarily those of SEL.  Any unauthorized disclosure,
distribution or other use is prohibited.  If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout.

Thank you.

------------------------------------------------

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

[Benedict, Michael]

>-----Original Message-----
From: Bruce_Leonard@selinc.com [mailto:Bruce_Leonard at selinc.com] 
>
>Kim Phillips <kim.phillips@freescale.com> wrote on 04/12/2007 
>04:02:51 PM:

>> I just applied the last spd patch I had in my queue to the
>> u-boot-mpc83xx.git tree on denx.de.  Can you please pull & test?

>Your patch didn't seem to make any difference so I'm going 
>spend the next 
>few days trying to figure out why (it may very well be that the memory 
>module we have in the board isn't a correct one for SPD to 
>work tho it's 
>what shipped in the board so I would expect it to be correct).

Same thing for me, unfortunately.  I will also do my best to figure this
out.
	Thank you all!
		Michael

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

[Bruce_Leonard at selinc.com]

> 
> >Your patch didn't seem to make any difference so I'm going 
> >spend the next 
> >few days trying to figure out why (it may very well be that the memory 
> >module we have in the board isn't a correct one for SPD to 
> >work tho it's 
> >what shipped in the board so I would expect it to be correct).
> 
> Same thing for me, unfortunately.  I will also do my best to figure this
> out.
>    Thank you all!
>       Michael
> 
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().

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.

Thanks.

Bruce

------------------------------------------------

This e-mail may contain SEL confidential information.  The opinions
expressed are not necessarily those of SEL.  Any unauthorized disclosure,
distribution or other use is prohibited.  If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout.

Thank you.

------------------------------------------------

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

[Timur Tabi]

On Thu, 12 Apr 2007 14:58:17 -0700
Bruce_Leonard at selinc.com wrote:

> about memory timing I remembered that the 8349itx u-boot port allows the 
> choice of using SPD for detecting the DDR RAM or using hard coded defaults 
> in the memory controller.  I figured what the heck, I'll give the hard 
> coded values a try even though they were probably wrong for the particular 
> part I've got installed.  And the bloody thing ran!  I had it executing a 

Those numbers were obtained by running the SPD code on the MPC8349E-mITX, and seeing what 
it spit out.  Then I just plugged those numbers into the board header file, with the hopes 
that it might work for someone.  I'm glad it did!

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[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

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

[Bruce_Leonard at selinc.com]

Timur,

Timur Tabi <timur@freescale.com> wrote on 04/13/2007 10:03:29 AM:

> 
> 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.
> 
Can't seem to find and BDI config files in the BSP.  Mine is pretty basic 
and does no RAM/FLASH/or other CS configuration.  Pretty much all it does 
is hold the processor after a POR.  I'm letting u-boot handle all config 
operations.  If you think I need more than that, please feel free to send 
me your config file.

Bruce

------------------------------------------------

This e-mail may contain SEL confidential information.  The opinions
expressed are not necessarily those of SEL.  Any unauthorized disclosure,
distribution or other use is prohibited.  If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout.

Thank you.

------------------------------------------------

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

[Benedict, Michael]

Timur Tabi wrote:
> 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
> 
The key differences were:
DDR:timing_cfg_1=0x26242321
<snip>
DDR:sdram_mode=0x00000032

For the hard-coded RAM init / stable case and

DDR:timing_cfg_1=0x26232321
<snip>
DDR:sdram_mode=0x00000022

For the SPD RAM init / unstable case.  In other words, the CASLAT
control value.  In the default timing case (bus speeds are configurable
on the board) this is with a max_data_rate of 400 and ddrc_clk of 266.

Timur,
	I am slightly confused about the scenario you used to develop
the hardcoded timings.  The git tree from October 31 (when you commited
these definitions) did not even contain SDP support for DDR400 RAM
(unless I am not reading the code correctly).  Is it possible that 

I am really confused by this code.  Hopefully someone can explain all
the conditionals that are causing the caslat to be decremented based on
spd.clk_cycle*.  In my current configuration I could blame that
decrement by two on the difference.  Any help explaining this code is
greatly appreciated.
	Thank you!
		Michael

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

[Bruce_Leonard at selinc.com]

"Benedict, Michael" <MBenedict@twacs.com> wrote on 04/16/2007 02:25:14 PM:

> > 
> The key differences were:
> DDR:timing_cfg_1=0x26242321
> <snip>
> DDR:sdram_mode=0x00000032
> 
> For the hard-coded RAM init / stable case and
> 
> DDR:timing_cfg_1=0x26232321
> <snip>
> DDR:sdram_mode=0x00000022
> 

I found the same descrepency.  I'm used to SDRAM, but I'm still figuring 
out DDR SDRAM (which is just enough different to be confusing ;)  ) so I'm 
not sure what impact the differences in timing_cfg_1 have.  Working on it.

> 
> I am really confused by this code.  Hopefully someone can explain all
> the conditionals that are causing the caslat to be decremented based on
> 

I'm right there with you, but I'm going through the code line by line 
trying to figure out what it's doing.  Then I'm going to post about a 
thousand (well maybe only a few) specific questions.  Hopefully the 
answers to those will help clear up both or our confusions.  I'm seeing 
some really tricky stuff in here, but I'm not sure but what that tricky 
stuff is what's causing our problems.  Update again tomorrow.

Bruce


------------------------------------------------

This e-mail may contain SEL confidential information.  The opinions
expressed are not necessarily those of SEL.  Any unauthorized disclosure,
distribution or other use is prohibited.  If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout.

Thank you.

------------------------------------------------

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

[Bruce_Leonard at selinc.com]

Timur Tabi <timur@freescale.com> wrote on 04/13/2007 10:03:29 AM:

> 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.
> 
Well, I finally zeroed in on the problem and it is indeed the DDR SDRAM 
Clock Control register as Timur suggested nearly a week ago, I just didn't 
understand at the time what he was saying.  Evidently the msb of this 
register needs to be set for DDR memory to work correctly on the 834x. 
However, I have three (and only three :)  ) questions:

1) Since it clearly needs to be set so that DDR memory will work (and I 
can see in a few other config files where CFG_DDR_SDRAM_CLK_CNTL gets that 
high bit set), why does the MPC8349ITX config file NOT set it and how has 
it worked for so many people for so long?  I find it difficult to believe 
that I'm the first person to stumble over this.  Or am I the only person 
who has tried to use the SPD code on this board?
2) My major concern is this: that high bit is un-documented, it's shown as 
reserverd in all the documentation I can find for the 834x.  How was I (or 
anyone for that matter) supposed to know about that bit?
3) What exactly is the purpose of "providing a source-synchronous option"? 
 That collection of words doesn't mean anything to me.

Thanks to all that helped point me in the right direction on this one.  I 
could have spent many weeks digging into/blaming the kernel before I ever 
thought of RAM problems.

Bruce


------------------------------------------------

This e-mail may contain SEL confidential information.  The opinions
expressed are not necessarily those of SEL.  Any unauthorized disclosure,
distribution or other use is prohibited.  If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout.

Thank you.

------------------------------------------------

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

[Benedict, Michael]

Bruce_Leonard at selinc.com wrote:
> 1) Since it clearly needs to be set so that DDR memory will
> work (and I
> can see in a few other config files where
> CFG_DDR_SDRAM_CLK_CNTL gets that
> high bit set), why does the MPC8349ITX config file NOT set it
> and how has
> it worked for so many people for so long?  I find it
> difficult to believe
> that I'm the first person to stumble over this.  Or am I the
> only person
> who has tried to use the SPD code on this board?

Actually, the clock control used to be set to this value, until commit
f6eda7f80ccc13d658020268c507d7173cf2e8aa in October last year.  The
Freescale-release BSP also has sdram_clk_cntl set to this value. I am
curious if the change was intended to accommodate another platform or if
there is something more going on here.
	Cheers,
		Michael

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

[Bruce_Leonard at selinc.com]

"Benedict, Michael" <MBenedict@twacs.com> wrote on 04/20/2007 11:13:21 AM:

> 
> Actually, the clock control used to be set to this value, until commit
> f6eda7f80ccc13d658020268c507d7173cf2e8aa in October last year.  The
> Freescale-release BSP also has sdram_clk_cntl set to this value. I am
> curious if the change was intended to accommodate another platform or if
> there is something more going on here.
>    Cheers,
>       Michael
> 

Okay Micheal,

How the #$^@&#$%&@^$ did you figure out which commit changed things?  I 
don't even know how to find that commit so I can see what changed!  The 
way I see the issue being 'fixed' is to have the following in 
.../include/configs/MPC8349ITX.h:

#define CFG_DDR_SDRAM_CLK_CNTL (DDR_SDRAM_CLK_CNTL_SS_EN | 
DDR_SDRAM_CLK_CNTL_ADJUST_05)

At least that's what I did to fix it and i just lifted that from Timur's 
hardcoded SDRAM init routine in .../board/mpc8349itx/mpc8349itx.c.  By 
doing the above in the config file you cause spd_sdram() to load 
CFG_DDR_SDRAM_CLK_CNTL into the clock control register and everything 
works fine.  But I can't find that the above has ever been done in the 
config file.  It certainly wasn't in (what appears to me anyway but I 
don't know how to drive git so I may be mistaken) the original posting of 
the config file.  And I don't think it's been in any version since.  So I 
don't think using spd_sdram() to set up the DDR controller on the 8349itx 
board has ever worked.

To follow up on the purpose of the register, it provides a way to adjust 
your DDR clock (CLK not CLK\) relative to when the DDR command/address is 
issued (see Freescale's app note AN2583).  Has something to do with the 
way the DDR controller's clock is locked or not locked with DLL.  I don't 
really follow it all yet, but it's one more way to adjust signals so that 
everything lines up correctly for setup and hold times.  However, for our 
purposes of getting this board to work using spd_sdram(), you do need to 
setup the clock control reg with the values noted above, provided you are 
using a Kingston KVR400X64C3A/256 DDR memory module like I am.  I don't 
gaurentee that the adjust value will be correct for any other part.

Hope this helps someone other than just me, given how long this thread has 
been going on.  :)

Bruce

------------------------------------------------

This e-mail may contain SEL confidential information.  The opinions
expressed are not necessarily those of SEL.  Any unauthorized disclosure,
distribution or other use is prohibited.  If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout.

Thank you.

------------------------------------------------

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

[Benedict, Michael]

Bruce_Leonard at selinc.com wrote:
> "Benedict, Michael" <MBenedict@twacs.com> wrote on 04/20/2007
>> Actually, the clock control used to be set to this value,
>
>  But I can't find that the above has ever been done in the
> config file.  It certainly wasn't in (what appears to me anyway but I
> don't know how to drive git so I may be mistaken) the original posting
of
> the config file.  And I don't think it's been in any version
> since.  So I don't think using spd_sdram() to set up the DDR
controller on
> the 8349itx board has ever worked.

Sorry, I should have been more explicit.  The change I am talking about
was hard-coded in spd_sdram.c.  You are correct in that it was never in
the config file before.  Git-blame head and the
f6eda7f80ccc13d658020268c507d7173cf2e8aa commit for spd_sdram.c should
get us on the same page.

Cheers,
	Michael

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

[Jon Loeliger]

On Fri, 2007-04-20 at 14:50, Bruce_Leonard at selinc.com wrote:

> 
> How the #$^@&#$%&@^$ did you figure out which commit changed things?  I 
> don't even know how to find that commit so I can see what changed!  The 
> way I see the issue being 'fixed' is to have the following in 
> .../include/configs/MPC8349ITX.h:

Ooo!  Tool hostility!  

Deep breath.  *sigh*  There...

OK.  Commands like these may be your friends here:

    % git log -- path/to/file.c
    % git log -p

If you have the SHA-1 or name of a commit, use:

    % git show f6eda7
or
    % git show master~4

HTH,
jdl

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

[Bruce_Leonard at selinc.com]

Jon Loeliger <jdl@freescale.com> wrote on 04/20/2007 01:00:36 PM:

> On Fri, 2007-04-20 at 14:50, Bruce_Leonard at selinc.com wrote:
> 
> > 
> > How the #$^@&#$%&@^$ did you figure out which commit changed things? I 

> > don't even know how to find that commit so I can see what changed! The 

> > way I see the issue being 'fixed' is to have the following in 
> > .../include/configs/MPC8349ITX.h:
> 
> Ooo!  Tool hostility! 
> 
My apologies to the list.  It wasn't meant to be hostile, it was meant to 
be an indication of frustration.  Too many new tools and too much 
information in too short a period for me to easily digest!  I'm starting 
to blow out circuits.  Thanks for the info on git Jon.

Bruce

------------------------------------------------

This e-mail may contain SEL confidential information.  The opinions
expressed are not necessarily those of SEL.  Any unauthorized disclosure,
distribution or other use is prohibited.  If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout.

Thank you.

------------------------------------------------