[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[llandre]

I have a question about SDRAM detection code (cpu/ppc4xx/sdram.c).
I tested it with the following configurations:
Configuration #1: 32 MB (2 chips), SDRAM clk = 133 MHz
Configuration #2: 32 MB (2 chips), SDRAM clk = 111 MHz
and everything worked fine.

Then I tried the following:
Configuration #3: 64 MB (2 chips), SDRAM clk = 111 MHz
and the SDRAM does not work. U-Boot executes fine until it jumps to SDRAM
after relocation.
In this case, two chips K4S561632E-TI75 have been used.
In my understanding the default value (0x07f00000) for the RTR register
is wrong because these chips have a 64 ms/8k cycle refresh.
Thus this register should be 0x03780000. I tried to change it
but SDRAM did not work anyway. I suspect it is necessary to fix
the TR register too or that the value for RTR is wrong.
Any suggestions/remarks?



TIA and best regards,

llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2 at dave-tech.it

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[Roger Larsson]

On Thursday 25 November 2004 19.42, llandre wrote:
> I have a question about SDRAM detection code (cpu/ppc4xx/sdram.c).
> I tested it with the following configurations:
> Configuration #1: 32 MB (2 chips), SDRAM clk = 133 MHz
> Configuration #2: 32 MB (2 chips), SDRAM clk = 111 MHz
> and everything worked fine.
>
> Then I tried the following:
> Configuration #3: 64 MB (2 chips), SDRAM clk = 111 MHz
> and the SDRAM does not work. U-Boot executes fine until it jumps to SDRAM
> after relocation.
> In this case, two chips K4S561632E-TI75 have been used.
> In my understanding the default value (0x07f00000) for the RTR register
> is wrong because these chips have a 64 ms/8k cycle refresh.
> Thus this register should be 0x03780000. I tried to change it
> but SDRAM did not work anyway. I suspect it is necessary to fix
> the TR register too or that the value for RTR is wrong.
> Any suggestions/remarks?

We are using the automatic SDRAM settings code
(cpu/ppc4xx/sdp_sdram.c, unsure about exact name sdp_...
Anyway I think you can use it for necessary calculations)

Have you configuread all four banks?

/RogerL

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[Wolfgang Denk]

In message <200411260033.34493.roger.larsson@norran.net> you wrote:
>
> We are using the automatic SDRAM settings code
> (cpu/ppc4xx/sdp_sdram.c, unsure about exact name sdp_...

SPD - serial presence detect.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is only one way to console a widow.  But remember the risk.
                                                   -- Robert Heinlein

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[llandre]

At 00.33 26/11/2004, Roger Larsson wrote:
>On Thursday 25 November 2004 19.42, llandre wrote:
> > I have a question about SDRAM detection code (cpu/ppc4xx/sdram.c).
> > I tested it with the following configurations:
> > Configuration #1: 32 MB (2 chips), SDRAM clk = 133 MHz
> > Configuration #2: 32 MB (2 chips), SDRAM clk = 111 MHz
> > and everything worked fine.
> >
> > Then I tried the following:
> > Configuration #3: 64 MB (2 chips), SDRAM clk = 111 MHz
> > and the SDRAM does not work. U-Boot executes fine until it jumps to SDRAM
> > after relocation.
> > In this case, two chips K4S561632E-TI75 have been used.
> > In my understanding the default value (0x07f00000) for the RTR register
> > is wrong because these chips have a 64 ms/8k cycle refresh.
> > Thus this register should be 0x03780000. I tried to change it
> > but SDRAM did not work anyway. I suspect it is necessary to fix
> > the TR register too or that the value for RTR is wrong.
> > Any suggestions/remarks?
>
>We are using the automatic SDRAM settings code
>(cpu/ppc4xx/sdp_sdram.c, unsure about exact name sdp_...
>Anyway I think you can use it for necessary calculations)
>
>Have you configuread all four banks?

The processor (405EP) has just two banks. We use only the first one.

As you suggested I had a look at spd_sdram.c.
In my understanding the settings used for RTR register
in sdram.c are not correct.
For SDRAM frequency = 133 MHz, this register is set as follows:
rtr = 0x07f00000;
Thus
0x07f0 * 1/133MHz = 2032 * 1/133MHz = 15.24 us
this refresh is ok for 32 MB configuration (2 chips, 16 MB each).

For the 64 MB configuration (2 chips, 32 MB each) I think that
this register should be set as follows:
64 ms / 8192 = 7.8 us
7.8 us * 133 MHz = 1040 = 0x410 => rtr = 0x04100000;
Do you agree?


llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2 at dave-tech.it

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[Andrew E. Mileski]

llandre wrote:
> 
> As you suggested I had a look at spd_sdram.c.

I've spent a lot of time in this file from the 1.0.2 codebase.  I've
re-written the 44X code in this file to increase the detection ability,
and fixed some obvious errors and typos too.

Example from 1.1.1 (off the top of my head): line 1077

The code seems to have come from IBM originally, but hasn't kept in sync
with it.  The IBM code has some of the same errors and typos.  Both have
detection code that is _very_ limited.  They only check for what the IBM
manual describes as recommended settings for TR1.  I've found these are
rarely adequate.

I'm not 100% confident in my code yet, but I'd highly recommend looking
at TR1 if you are having problems.

--
Andrew E. Mileski

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[Wolfgang Denk]

Dear Andrew,

in message <41A90923.4080509@isoar.ca> you wrote:
> 
> Example from 1.1.1 (off the top of my head): line 1077

Such a statement is absolutely useless. If you are referring to  some
code,  please provide the name of the file, version / timestamp and a
snippet of the relevant code.

A plain line number is just bogus.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The more we disagree, the more chance there is that at least  one  of
us is right.

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[Andrew E. Mileski]

Wolfgang Denk wrote:
> Dear Andrew,
> 
> in message <41A90923.4080509@isoar.ca> you wrote:
> 
>>Example from 1.1.1 (off the top of my head): line 1077
> 
> Such a statement is absolutely useless. If you are referring to  some
> code,  please provide the name of the file, version / timestamp and a
> snippet of the relevant code.
> 
> A plain line number is just bogus.

Wolfgang, you can trust that when I'm prepared to submit a patch for
changes, all the pertinent information will be provided for those not
expected to be currently looking at the file.  I merely mentioned it
to illustrate that there is questionable code in the file.  It was
not my intention to submit a patch request at this time, as I stated.
I apologize for leading you and list readers to believe otherwise.

However for your reference, line 1077 from the tarball
   ftp://ftp.denx.de/pub/u-boot/u-boot-1.1.1.tar.bz2
in the  file cpu/ppc4xx/spd_sdram.c is dated Dec 9 2003.  There is no
file version number that I can locate.  The line reads:
   case 0x011:
which should be
   case 0x01:
Nobody has noticed, since this condition is not commonly encountered.
I only noticed it when looking at the source.  It sort of stands out.

Those that would like to see my current patch for this file can contact
me directly off-list.  As I stated, it's not yet ready for official
distribution, and it is 1.0.2 based.  It is also fairly large for a
posting to the list.

-- 
Andrew E. Mileski

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[Wolfgang Denk]

In message <41AA5143.1010703@isoar.ca> you wrote:
> > 
> > A plain line number is just bogus.
> 
> Wolfgang, you can trust that when I'm prepared to submit a patch for
> changes, all the pertinent information will be provided for those not
> expected to be currently looking at the file.  I merely mentioned it
> to illustrate that there is questionable code in the file.  It was

Even then: a plain line number is totally useless...

> file version number that I can locate.  The line reads:
>    case 0x011:

... as is a single source line whithout a few lines of context.

Please try to be a bit more helpful and post information  others  can
use, or don't post any such stuff at all.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Men of peace usually are [brave].
	-- Spock, "The Savage Curtain", stardate 5906.5

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[Andrew E. Mileski]

Wolfgang Denk wrote:
> 
> ... as is a single source line whithout a few lines of context.
> 
> Please try to be a bit more helpful and post information  others  can
> use, or don't post any such stuff at all.

I didn't realize going to a specific line number, or searching on a
unique phrase would be such a problem.

Attached please find a patch for this line.  It is against the file
cpu/ppc4xx/spd_sdram.c dated Dec 9 2003 in the tarball
   ftp://ftp.denx.de/pub/u-boot/u-boot-1.1.1.tar.bz2
There are only 6 lines of context.  I can provide more on request if
it will help, or provide a patch in a different format.

Is this now enough to illustrate the point I was making to "llandre"?

Thank you for your patience.

-- 
Andrew E. Mileski

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: typo-1.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20041128/79941727/attachment.txt 

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[Stefan Roese]

Hi Llandre,

Sorry if I jump into this thread this late!

> I have a question about SDRAM detection code (cpu/ppc4xx/sdram.c).
> I tested it with the following configurations:
> Configuration #1: 32 MB (2 chips), SDRAM clk = 133 MHz
> Configuration #2: 32 MB (2 chips), SDRAM clk = 111 MHz
> and everything worked fine.
> 
> Then I tried the following:
> Configuration #3: 64 MB (2 chips), SDRAM clk = 111 MHz
> and the SDRAM does not work. U-Boot executes fine until it 
> jumps to SDRAM
> after relocation.
> In this case, two chips K4S561632E-TI75 have been used.
> In my understanding the default value (0x07f00000) for the 
> RTR register
> is wrong because these chips have a 64 ms/8k cycle refresh.
> Thus this register should be 0x03780000. I tried to change it
> but SDRAM did not work anyway. I suspect it is necessary to fix
> the TR register too or that the value for RTR is wrong.
> Any suggestions/remarks?

Yes, you are right: There seems to be a problem with the refresh counter
intialization in the sdram.c code (I am not referencing the spd_sdram.c
code here!). But I am not sure that this explains why U-Boot is not
running on your board with the 256mbit chips. We are running this code
on our board with all kind of sdram's (64mbit, 128mbit, 256mbit and even
512mbit) without any known problems. The 256mbit chips we use right now
are the Micron MT48LC16M16A2-7E.

But again there seems to be a problem which needs to be fixed. I can put
this on my list or you could send a patch! ;-)

Best regards,
Stefan

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[llandre]

Hi Stefan,

>Sorry if I jump into this thread this late!

No problem

> > I have a question about SDRAM detection code (cpu/ppc4xx/sdram.c).
> > I tested it with the following configurations:
>...
>Yes, you are right: There seems to be a problem with the refresh counter
>intialization in the sdram.c code (I am not referencing the spd_sdram.c
>code here!). But I am not sure that this explains why U-Boot is not
>running on your board with the 256mbit chips. We are running this code
>on our board with all kind of sdram's (64mbit, 128mbit, 256mbit and even
>512mbit) without any known problems. The 256mbit chips we use right now
>are the Micron MT48LC16M16A2-7E.
>
>But again there seems to be a problem which needs to be fixed. I can put
>this on my list or you could send a patch! ;-)

Actually we have just found a small hardware related problem
that prevented SDRAM to work and we fixed it.
Nevertheless the counter is wrong but it seems SDRAM technology
is really reliable! If 512mbit chips work, it means that they tolerate
a refresh frequency that is 1/4 of the nominal value!!!
Unfortunatley processors are not so well behaved :-)
If I have the chance, I'll try to submit a patch.


Regards,

llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2 at dave-tech.it

[U-Boot-Users] PPC4xx: SDRAM detection (bug?)

[Wolfgang Denk]

In message <41AA5EFE.1020403@isoar.ca> you wrote:
>
> Attached please find a patch for this line.  It is against the file
> cpu/ppc4xx/spd_sdram.c dated Dec 9 2003 in the tarball
>    ftp://ftp.denx.de/pub/u-boot/u-boot-1.1.1.tar.bz2
> There are only 6 lines of context.  I can provide more on request if
> it will help, or provide a patch in a different format.

Thanks, added.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Nobody will ever need more than 640k RAM!"       -- Bill Gates, 1981
"Windows 95 needs at least 8 MB RAM."             -- Bill Gates, 1996
"Nobody will ever need Windows 95."             -- logical conclusion