[U-Boot-Users] PPC4xx: SDRAM detection (bug?)
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@dave-tech.it
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
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
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@dave-tech.it
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
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
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.
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
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.
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
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
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@dave-tech.it
participants (5)
-
Andrew E. Mileski -
llandre -
Roger Larsson -
Stefan Roese -
Wolfgang Denk