Still trying to get a stable 2.6.20.4 running on 8349ITX eval board

Still trying to get a stable 2.6.20.4 running on 8349ITX eval board

[Bruce_Leonard]

Hi,

Posted a cry for help a few days ago on this issue ;)> .  Got a couple of 
answers that didn't get me any farther so I'm on another fishing 
expedition.  Basic set up is as follows; MPC8349ITX eval board; 2.6.20.4 
kernel; a ubuntu/dapper FS via NFS.  The problem seems to be a random 
lock-up in either a DSI exception (0x300), a program exception (0x700) or 
a DTLB miss on store exception (0x1200).  I'm sure it's not truly random 
(I'm sure there's probably only a single underlying problem), but it's 
random in how it manifests.  When trying to mount the root FS via NFS, it 
always successfully reaches the point where it runs "/sbin/init" in 
main.c, but which script it fails in varies and it never gets to a login.

I've tried passing "init=/bin/sh" on the command line and I can reach a sh 
prompt, but it doesn't take long before it locks up.  I can do a "find . 
-name '*gcc*'" about four times before it stops.  I have a BDI2K hooked up 
so I know where it's stopping (most commonly in the DTLB miss mentioned 
above), but backtrace from GDB gets me nothing, and SRR0 and SRR1 don't 
contain any useful information (frequently they're both zero).  I expect 
it may be an interaction with the BDI, tho I'm not sure.

I've also tried a couple of other file systems (one right off the CD that 
ships with the eval board and the latest from ELDK) as well as pulling 
Kumar's powerpc kernel tree.  All possible combinations of these kernels 
and file systems fail to run for any period of time.

Long winded way to get around to my questions (sorry :(  ):
1) Can any one point me to good references in using the BDI2K to find my 
way back from exceptions?
2) I assume someone (Kumar?) has gotten some combination of kernel/FS to 
boot and run on this box.  What combination is that?

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.

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

RE: Still trying to get a stable 2.6.20.4 running on 8349ITX eval board

[Benedict, Michael]

>I've tried passing "init=3D/bin/sh" on the command line and I=20
>can reach a sh=20
>prompt, but it doesn't take long before it locks up.  I can do=20
>a "find .=20
>-name '*gcc*'" about four times before it stops.=20

I, too, am still experiencing this issue.   If it helps debugging, it is
only VFS accesses that seem to be locked.  I was able to run a
network-based IO app fine for almost a day (I rebooted the machine
then), even though the root filesystem "stops".

>2) I assume someone (Kumar?) has gotten some combination of=20
>kernel/FS to=20
>boot and run on this box.  What combination is that?

I am thinking that these issues are closely coupled to root NFS.  I know
this isn't good news, but I think the combo is running the root
filesystem on the hard drive or ramdisk.
	Good luck,
		Michael

RE: Still trying to get a stable 2.6.20.4 running on 8349ITX eval board

[Bruce_Leonard]

Michael,

linuxppc-embedded-bounces+brucle=selinc.com@ozlabs.org wrote on 04/11/2007 
01:59:11 PM:

> 
> >2) I assume someone (Kumar?) has gotten some combination of 
> >kernel/FS to 
> >boot and run on this box.  What combination is that?
> 
> I am thinking that these issues are closely coupled to root NFS.  I know
> this isn't good news, but I think the combo is running the root
> filesystem on the hard drive or ramdisk.
>    Good luck,
>       Michael
> 
For the heck of it, we tried formatting the hard drive, put ubuntu/dapper 
on a ext3 partition, and used that as the root FS.  Same results.  We 
booted with init=/bin/sh but when we run debootstrap --second-stage it got 
just a few seconds into it and locked up in a program exception.

Thanks for the input though.  I'll keep poking and let you know what I 
figure out.  I keep hoping some guru out there will go "ahhhh......" 
'cause I ain't no guru!  :)

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.

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

Re: Still trying to get a stable 2.6.20.4 running on 8349ITX eval board

[Ed Swierk]

On Wednesday 11 April 2007 13:47:55 Bruce_Leonard@selinc.com wrote:
> Posted a cry for help a few days ago on this issue ;)> .  Got a couple of
> answers that didn't get me any farther so I'm on another fishing
> expedition.  Basic set up is as follows; MPC8349ITX eval board; 2.6.20.4
> kernel; a ubuntu/dapper FS via NFS.  The problem seems to be a random
> lock-up in either a DSI exception (0x300), a program exception (0x700) or
> a DTLB miss on store exception (0x1200).  I'm sure it's not truly random
> (I'm sure there's probably only a single underlying problem), but it's
> random in how it manifests.  When trying to mount the root FS via NFS, it
> always successfully reaches the point where it runs "/sbin/init" in
> main.c, but which script it fails in varies and it never gets to a login.

I spent about 8 hours yesterday tracking down a problem on a similar board 
(Embedded Planet 8343M) booting Fedora 6 via NFS. Linux was getting a bit 
farther along than it is for you--I got a shell and could run python--but the 
CPU kept locking up somewhere near 0x600 or 0x1200, without a peep from the 
kernel. It usually occurred after a lot of memory allocation activity, so I 
tried tracing the out-of-memory code in the kernel, but then found I could 
reproduce the problem with the mtest command in U-Boot.

The problem turned out to be an incorrect DDR SDRAM configuration setting in 
U-Boot for my board (which has no SPD EEPROM, so it's U-Boot's job to 
configure the memory controller). I was using CSCONFIG_ROW_BIT_12 rather than 
CSCONFIG_ROW_BIT_13 in CFG_DDR_CONFIG, which apparently affected the way the 
CPU accesses and refreshes the DRAM. I was pretty shocked that Linux was able 
to boot at all with a configuration bug like this.

Anyway, it might be worth double-checking the DDR SDRAM code in U-Boot to make 
sure it's doing the right thing for the parts on your board.

--Ed

Re: Still trying to get a stable 2.6.20.4 running on 8349ITX eval board

[Vitaly Bordug]

On Wed, 11 Apr 2007 13:47:55 -0700
Bruce_Leonard@selinc.com wrote:

> Hi,
> 
> Posted a cry for help a few days ago on this issue ;)> .  Got a couple of 
> answers that didn't get me any farther so I'm on another fishing 
> expedition.  Basic set up is as follows; MPC8349ITX eval board; 2.6.20.4 
> kernel; a ubuntu/dapper FS via NFS.  The problem seems to be a random 
> lock-up in either a DSI exception (0x300), a program exception (0x700) or 
> a DTLB miss on store exception (0x1200).  I'm sure it's not truly random 
> (I'm sure there's probably only a single underlying problem), but it's 
> random in how it manifests.  When trying to mount the root FS via NFS, it 
> always successfully reaches the point where it runs "/sbin/init" in 
> main.c, but which script it fails in varies and it never gets to a login.
> 
> I've tried passing "init=/bin/sh" on the command line and I can reach a sh 
> prompt, but it doesn't take long before it locks up.  I can do a "find . 
> -name '*gcc*'" about four times before it stops.  I have a BDI2K hooked up 
> so I know where it's stopping (most commonly in the DTLB miss mentioned 
> above), but backtrace from GDB gets me nothing, and SRR0 and SRR1 don't 
> contain any useful information (frequently they're both zero).  I expect 
> it may be an interaction with the BDI, tho I'm not sure.
> 
> I've also tried a couple of other file systems (one right off the CD that 
> ships with the eval board and the latest from ELDK) as well as pulling 
> Kumar's powerpc kernel tree.  All possible combinations of these kernels 
> and file systems fail to run for any period of time.
> 
> Long winded way to get around to my questions (sorry :(  ):
> 1) Can any one point me to good references in using the BDI2K to find my 
> way back from exceptions?
> 2) I assume someone (Kumar?) has gotten some combination of kernel/FS to 
> boot and run on this box.  What combination is that?
> 
> 

It worked for me with both MontaVista and ELDK rfs for 6xx.

Your problem looks very much like odd DDR or memctl misconfiguration early in u-boot.
Please try upgrading your firmware with the latest u-boot from git tree at denx.de. Kernel from Paul Mackerras (powerpc.git) is also a good thing to give a try.

Also, there is Vitesse switch on this target, which should be initialized(Normally with vendor-shipped image you'll figure out how by print thirdp_init. Starting kernel without that may result in some instability too.

Hope it helps.

-- 
Sincerely, 
Vitaly

RE: Still trying to get a stable 2.6.20.4 running on 8349ITX evalboard

[Benedict, Michael]

>
>Your problem looks very much like odd DDR or memctl=20
>misconfiguration early in u-boot.
>Please try upgrading your firmware with the latest u-boot from=20
>git tree at denx.de. Kernel from Paul Mackerras (powerpc.git)=20
>is also a good thing to give a try.
>
I can verify this bug exists with the latest Denx git u-boot.  Thank
you, I will try Paul Mackerras kernel.

>Also, there is Vitesse switch on this target, which should be=20
>initialized(Normally with vendor-shipped image you'll figure=20
>out how by print thirdp_init. Starting kernel without that may=20
>result in some instability too.
>

I have to admit, this is over my head.  What do you mean by "print
thirdp_init"? =20

Thank you Vitaly!
	-Michael

Re: Still trying to get a stable 2.6.20.4 running on 8349ITX eval board

[Bruce_Leonard]

Vitaly,

Vitaly Bordug <vbordug@ru.mvista.com> wrote on 04/12/2007 08:36:58 AM:

> 
> It worked for me with both MontaVista and ELDK rfs for 6xx.
> 
> Your problem looks very much like odd DDR or memctl misconfiguration
> early in u-boot.
>

Ed made a similar observation.  I've been assuming ;) that the DDR RAM was 
configured correctly since it's been a 'supported' eval board since at 
least u-boot 1.1.6, but there may be a problem there.  At least I'm going 
to make sure that it's all okay before I continue.
 
> Also, there is Vitesse switch on this target, which should be 
> initialized(Normally with vendor-shipped image you'll figure out how
> by print thirdp_init. Starting kernel without that may result in 
> some instability too.

Thanks.  Again I was assuming all the HW was correctly configured with 
u-boot.  I'll dig into this as well.  Soon as I find anything for sure 
I'll post a follow up.

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.

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

RE: Still trying to get a stable 2.6.20.4 running on 8349ITX evalboard

[Benedict, Michael]

>Your problem looks very much like odd DDR or memctl=20
>misconfiguration early in u-boot.
>Please try upgrading your firmware with the latest u-boot from=20
>git tree at denx.de. Kernel from Paul Mackerras (powerpc.git)=20
>is also a good thing to give a try.

This is definetly something related to u-boot.  I was using a new Denx
git u-boot for flat device tree support.  If I boot a kernel with
hardcoded ethernet-phy registers on the shipping u-boot the system is
much more stable.  Now I am trying to track down the differences between
the u-boot the freescale shipped on the device verse the newest git
sources.  Hopefully some initialization is missing that will be very
obvious.
	Cheers,
		Michael

RE: Still trying to get a stable 2.6.20.4 running on 8349ITX evalboard

[Bruce_Leonard]

Hi all,

"Benedict, Michael" <MBenedict@twacs.com> wrote on 04/12/2007 12:27:35 PM:

> >Your problem looks very much like odd DDR or memctl 
> >misconfiguration early in u-boot.
> >Please try upgrading your firmware with the latest u-boot from 
> >git tree at denx.de. Kernel from Paul Mackerras (powerpc.git) 
> >is also a good thing to give a try.
> 
> This is definetly something related to u-boot.  I was using a new Denx
> git u-boot for flat device tree support.  If I boot a kernel with
> hardcoded ethernet-phy registers on the shipping u-boot the system is
> much more stable.  Now I am trying to track down the differences between
> the u-boot the freescale shipped on the device verse the newest git
> sources.  Hopefully some initialization is missing that will be very
> obvious.
>    Cheers,
>       Michael
> 

SUCCESS!!!  (Or at least a HUGE step forward.)  Once I got to thinking 
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 
forever loop for 35 minutes, which is about 34 and a half minutes longer 
than it's ever run before!

It still augured in on me, but the processor was so locked up/confused 
that I couldn't even get the BDI to reset it, I had to cycle power.  I'm 
inclined to think it was probably an ESD event, since I've got the cover 
off the box.

Thanks to everyone who offered suggestions, especially Ed and Vitaly for 
suggesting looking at the RAM.  I was in no way, shape, or form thinking 
along those lines.  Now I've got something I can actually dig on.  I'll 
post a followup here and on the u-boot mailing list if I find anything 
wrong in "public" code.

Thanks again.

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]

[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.

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

DMA Puzzle

[Charles Krinke]

My apologies for the complexity of this e-mail but DMA seems to be a
complex subject. Thanks to Ed.S a while back, I have DMA working fine
from U-Boot, but I am having a problem in Linux with the 8541 processor
using the 2.6.17.11 kernel. I need to DMA through an outbound address
translation window setup at 0x8800_0000 and the chip I am DMA'ing to is
responding to 64bit DAC (Dual Address Cycles) and its memory is setup
beginning at 0x1_0000_0000.

It seems, that the MR0/SR0 indicate the DMA has stalled and I have not
figured out why yet. Here is the progression in the DMA driver in Linux

First obtain a pointer to my RAM buffer using pci_map_single. This
returns the buffer in kernel space at 0xC768_0000 (or thereabouts) to
0x07680000 and prepare to transfer 0x10000 (64K bytes) from 0x0_c7680000
to 0x1_0000_0000.

This is the first of several printk's in the DMA driver where the POTAR2
is being used to hold the hi part of the 64bit address.

a src_low_addr:07680000 winBase:00000000 POTAR2:00100000
newLowAddr:07680000 dir:1 size:00010000  =20

Next we write all f's to SR0 to clear it and here is the next printk.

z MR0:00000000 SR0:00000000 begin

Now we write the low part of the source address to LSAR0.=20
A constant value of 0x50000 to DATR0.
The size in bytes to the BCR (Byte Count Register) is next

Then set the MR0 to 0x0f03c404 indicating a)disable bandwidth sharing,
DAHTS & SAHTS both 8 bytes, SRW set & CDSM/SWSM cleared to indicate
start the DMA by writing the destination.

Lastly, we write the destination to the DAR0 register.

At this point, the next printk has a problem. The MR0 register has its
CS bit set and the SR0 register has its CB bit set. This indicates to me
that the channel is busy, it stalled and cannot continue.

 c MR0:0F03C405 SR0:00000004 SATR:00050000 DATR:00050000 dst_low_addr:0

Just for reference, here are two final printk's with some of the other
pertinent registers.

 d POTAR2:00100000 LSAR0:07690000 DAR0:88010000 BCR:0 DGSR:00000000
 e POTEAR2:00000000 POWBAR2:00088000 POWAR 0:80044019 1:8004401A
2:8004401B

So, the question becomes, "What is going awry here and where should I be
looking in order to understand how to close the DMA loop back to
Linux?".

Charles Krinke

[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.

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

Anyone using the MPC8313E-RDB?

[David Hawkins]

Hi all,

Is anyone using the MPC8313E-RDB?

I see Freescale is having a series of PowerQUICC seminars
for $99, and you get one of the MPC8313E-RDB boards
(which according to the fact sheet goes for $299).

http://www.freescale.com/quiccseminars

I'm using the 8349E ... but I love collecting and playing
with evaluation boards ;)

Cheers
Dave

[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.

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

Re: DMA Puzzle

[Kelsey Dawes]

On Thu, Apr 12, 2007 at 04:23:00PM -0700, Charles Krinke wrote:
> My apologies for the complexity of this e-mail but DMA seems to be a
> complex subject. Thanks to Ed.S a while back, I have DMA working fine
> from U-Boot, but I am having a problem in Linux with the 8541 processor
> using the 2.6.17.11 kernel. I need to DMA through an outbound address
> translation window setup at 0x8800_0000 and the chip I am DMA'ing to is
> responding to 64bit DAC (Dual Address Cycles) and its memory is setup

<SNIP>

Hi Charles - have you checked the device errata for 8541?  I do not have the details in front of me, but do recall several items specific to DMA  signal to complete DMA transaction.  


Worth a look anyway - 

Kelsey

[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.

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