[U-Boot] FSL DDR @ 83xx
Kim,
I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ?
regards, André
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ?
The new, common DDR code in use by the FSL boards does not yet cover the 83xx family, though the plan is to eventually do so.
Patches in that direction, are, naturally, welcome... :-)
jdl
Jon Loeliger schrieb:
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ?
The new, common DDR code in use by the FSL boards does not yet cover the 83xx family, though the plan is to eventually do so.
Patches in that direction, are, naturally, welcome... :-)
jdl
Is anybody working on this ? The spd_sdram code lacks support for 3 bank adress bits and various termination schemes which are essential for tiny boards with soldered memory.
Of course I could contribute for the 8343. But I don't now about the "others" (85xx/86x) in detail and don't want to scatter #ifdefs all over the code ...
regards, André
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
On Dec 9, 2008, at 12:01 PM, Andre Schwarz wrote:
Jon Loeliger schrieb:
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ?
The new, common DDR code in use by the FSL boards does not yet cover the 83xx family, though the plan is to eventually do so.
Patches in that direction, are, naturally, welcome... :-)
jdl
Is anybody working on this ? The spd_sdram code lacks support for 3 bank adress bits and various termination schemes which are essential for tiny boards with soldered memory.
Of course I could contribute for the 8343. But I don't now about the "others" (85xx/86x) in detail and don't want to scatter #ifdefs all over the code ...
regards, André
I don't believe anyone is currently working on getting the new ddr code to be used w/83xx. Feel free to submit patches that does this and we will review them as they are posted.
- k
Kumar Gala schrieb:
On Dec 9, 2008, at 12:01 PM, Andre Schwarz wrote:
Jon Loeliger schrieb:
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ?
The new, common DDR code in use by the FSL boards does not yet cover the 83xx family, though the plan is to eventually do so.
Patches in that direction, are, naturally, welcome... :-)
jdl
Is anybody working on this ? The spd_sdram code lacks support for 3 bank adress bits and various termination schemes which are essential for tiny boards with soldered memory.
Of course I could contribute for the 8343. But I don't now about the "others" (85xx/86x) in detail and don't want to scatter #ifdefs all over the code ...
regards, André
I don't believe anyone is currently working on getting the new ddr code to be used w/83xx. Feel free to submit patches that does this and we will review them as they are posted.
- k
After spending few hours it seems to work basically. This is what I've done :
- add mpc8xxx(ddr/libddr.a to top level Makefile for 83xx - created mpc83xx/ddr-gen2.c and ported to meet ddr83xx_t - created board specific ddr.c for SPD accessor and basic setup. - created board specific ddr2_spd_eeprom_t (soldered memory)
The board config got these #defines :
#define CONFIG_FSL_DDR2 #define CONFIG_DDR_SPD #define CONFIG_NUM_DDR_CONTROLLERS 1 -> this should go into mpc83xx header #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL 1
Since spd_sdram.o is always build (mpc83xx/Makefile) and the code is also activated by CONFIG_SPD_EEPROM we should find a reasonable way to switch between "old" and "new" DDR code by some kind of #define.
Is this the way to go ?
regards, André
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Andre Schwarz wrote:
I don't believe anyone is currently working on getting the new ddr code to be used w/83xx. Feel free to submit patches that does this and we will review them as they are posted.
- k
After spending few hours it seems to work basically. This is what I've done :
- add mpc8xxx(ddr/libddr.a to top level Makefile for 83xx
- created mpc83xx/ddr-gen2.c and ported to meet ddr83xx_t
- created board specific ddr.c for SPD accessor and basic setup.
- created board specific ddr2_spd_eeprom_t (soldered memory)
The board config got these #defines :
#define CONFIG_FSL_DDR2 #define CONFIG_DDR_SPD #define CONFIG_NUM_DDR_CONTROLLERS 1 -> this should go into mpc83xx header #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL 1
Since spd_sdram.o is always build (mpc83xx/Makefile) and the code is also activated by CONFIG_SPD_EEPROM we should find a reasonable way to switch between "old" and "new" DDR code by some kind of #define.
Is this the way to go ?
Yes, it is. You will also need a per-board set of functions to answer the "configuration issues" in a way similar to the rest of the 85xx and 86xx boards.
You will have to carefully juggle the presence of the "new" and "old" simultaneously (via CONFIG_FSL_DDR2, likely) until all the 83xx boards are supported under the new mechanism.
jdl
Andre Schwarz wrote:
I don't believe anyone is currently working on getting the new ddr code to be used w/83xx. Feel free to submit patches that does this and we will review them as they are posted.
- k
After spending few hours it seems to work basically. This is what I've done :
- add mpc8xxx(ddr/libddr.a to top level Makefile for 83xx
- created mpc83xx/ddr-gen2.c and ported to meet ddr83xx_t
- created board specific ddr.c for SPD accessor and basic setup.
- created board specific ddr2_spd_eeprom_t (soldered memory)
The board config got these #defines :
#define CONFIG_FSL_DDR2 #define CONFIG_DDR_SPD #define CONFIG_NUM_DDR_CONTROLLERS 1 -> this should go into mpc83xx header #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL 1
Since spd_sdram.o is always build (mpc83xx/Makefile) and the code is also activated by CONFIG_SPD_EEPROM we should find a reasonable way to switch between "old" and "new" DDR code by some kind of #define.
Is this the way to go ?
Yes, it is. You will also need a per-board set of functions to answer the "configuration issues" in a way similar to the rest of the 85xx and 86xx boards.
You will have to carefully juggle the presence of the "new" and "old" simultaneously (via CONFIG_FSL_DDR2, likely) until all the 83xx boards are supported under the new mechanism.
jdl
Andre Schwarz wrote:
Kumar Gala schrieb:
On Dec 9, 2008, at 12:01 PM, Andre Schwarz wrote:
Jon Loeliger schrieb:
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ?
The new, common DDR code in use by the FSL boards does not yet cover the 83xx family, though the plan is to eventually do so.
Patches in that direction, are, naturally, welcome... :-)
jdl
Is anybody working on this ? The spd_sdram code lacks support for 3 bank adress bits and various termination schemes which are essential for tiny boards with soldered memory.
Of course I could contribute for the 8343. But I don't now about the "others" (85xx/86x) in detail and don't want to scatter #ifdefs all over the code ...
regards, André
I don't believe anyone is currently working on getting the new ddr code to be used w/83xx. Feel free to submit patches that does this and we will review them as they are posted.
- k
After spending few hours it seems to work basically. This is what I've done :
- add mpc8xxx(ddr/libddr.a to top level Makefile for 83xx
- created mpc83xx/ddr-gen2.c and ported to meet ddr83xx_t
- created board specific ddr.c for SPD accessor and basic setup.
- created board specific ddr2_spd_eeprom_t (soldered memory)
The board config got these #defines :
#define CONFIG_FSL_DDR2 #define CONFIG_DDR_SPD #define CONFIG_NUM_DDR_CONTROLLERS 1 -> this should go into mpc83xx header #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL 1
Since spd_sdram.o is always build (mpc83xx/Makefile) and the code is also activated by CONFIG_SPD_EEPROM we should find a reasonable way to switch between "old" and "new" DDR code by some kind of #define.
Is this the way to go ?
regards, André
Hi André, others,
Has anyone made any progress on moving the mpc83xx family to the mpc8xxx/ddr unified initialization?
André, could you post what you did to the list or, if it isn't in publishable shape, email it to me so I can bash at it?
Thanks, gvb
Jerry Van Baren wrote:
Andre Schwarz wrote:
Kumar Gala schrieb:
On Dec 9, 2008, at 12:01 PM, Andre Schwarz wrote:
Jon Loeliger schrieb:
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ?
The new, common DDR code in use by the FSL boards does not yet cover the 83xx family, though the plan is to eventually do so.
Patches in that direction, are, naturally, welcome... :-)
jdl
Is anybody working on this ? The spd_sdram code lacks support for 3 bank adress bits and various termination schemes which are essential for tiny boards with soldered memory.
Of course I could contribute for the 8343. But I don't now about the "others" (85xx/86x) in detail and don't want to scatter #ifdefs all over the code ...
regards, André
I don't believe anyone is currently working on getting the new ddr code to be used w/83xx. Feel free to submit patches that does this and we will review them as they are posted.
- k
After spending few hours it seems to work basically. This is what I've done :
- add mpc8xxx(ddr/libddr.a to top level Makefile for 83xx
- created mpc83xx/ddr-gen2.c and ported to meet ddr83xx_t
- created board specific ddr.c for SPD accessor and basic setup.
- created board specific ddr2_spd_eeprom_t (soldered memory)
The board config got these #defines :
#define CONFIG_FSL_DDR2 #define CONFIG_DDR_SPD #define CONFIG_NUM_DDR_CONTROLLERS 1 -> this should go into mpc83xx header #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL 1
Since spd_sdram.o is always build (mpc83xx/Makefile) and the code is also activated by CONFIG_SPD_EEPROM we should find a reasonable way to switch between "old" and "new" DDR code by some kind of #define.
Is this the way to go ?
regards, André
Hi André, others,
Has anyone made any progress on moving the mpc83xx family to the mpc8xxx/ddr unified initialization?
André, could you post what you did to the list or, if it isn't in publishable shape, email it to me so I can bash at it?
Thanks, gvb
Jerry,
unfortunately I got interrupted, since this has not been a high priority issue to us. The usual 83xx DDR setup works quite fine.
Since I'm horribly out of sync there'll be no patch.
What I have done so far (it's not yet working) :
- added #defines to board header for DDR gen2. - created DDR-II compatible PROM table parsable by SPD code. - added board specific DDR code according to Freescale file layout. - created cpu/mpc83xx/ddr-gen2.c
All new code is plain copy/paste of existing Freescale code with minor mods.
Setting up LAW has not been done in any way.
I think the new code is pretty much straight forward and definitely worth the effort porting it to 83xx.
You'll get my stuff off-list.
regards, Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
Kumar Gala schrieb:
On Dec 9, 2008, at 12:01 PM, Andre Schwarz wrote:
Jon Loeliger schrieb:
On Mon, 2008-12-08 at 18:02 +0100, Andre Schwarz wrote:
Kim,
I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ?
The new, common DDR code in use by the FSL boards does not yet cover the 83xx family, though the plan is to eventually do so.
Patches in that direction, are, naturally, welcome... :-)
jdl
Is anybody working on this ? The spd_sdram code lacks support for 3 bank adress bits and various termination schemes which are essential for tiny boards with soldered memory.
Of course I could contribute for the 8343. But I don't now about the "others" (85xx/86x) in detail and don't want to scatter #ifdefs all over the code ...
regards, André
I don't believe anyone is currently working on getting the new ddr code to be used w/83xx. Feel free to submit patches that does this and we will review them as they are posted.
- k
mpc83xx/spd_sdram needs some fixes to work with latest chips :
1. max_data_rate seems to be mishandled. Since it's twice the physical clock we need much higher vaues for calculating optimum caslat ... or use "max_bus_clock" instead. bus_clock seems to be reasonable since the SPD timing values refer to clock and/or clock cycle time.
if (max_data_rate >= 390 && max_data_rate < 460) { /* it is DDR 400 */
This is the top-level if -> DDR-333 gives max_data_rate = 666 .... and goes into
else if (max_data_rate >= 323) { /* it is DDR 333 */
Additionally the caslat reduction code should use "<=" and ">=" for the evaluation of clk_cycle2 and clk_cycle3. Otherwise it will only work for a specific memory with SPD contents.
To make it short : DDR-II-333 will be configured with caslat = 5 @ 133MHz Controller speed -> It would work fine with caslat = 3.
2. Actually 3 bank adress bits are quite usual. This SPD values are not yet evaluated.
3. Termination schemes (150/75/50 Ohm) and driver characteristics are not handled at all. Most boards would need this or may only run stable with the most conservative timings.
Does it make sense to fix these things or is the "new" DDR code the way to go ?
regards, André
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Andre Schwarz wrote:
mpc83xx/spd_sdram needs some fixes to work with latest chips :
max_data_rate seems to be mishandled. Since it's twice the physical clock we need much higher vaues for calculating optimum caslat ... or use "max_bus_clock" instead. bus_clock seems to be reasonable since the SPD timing values refer to clock and/or clock cycle time.
if (max_data_rate >= 390 && max_data_rate < 460) { /* it is DDR 400 */
This is the top-level if -> DDR-333 gives max_data_rate = 666 .... and goes into
else if (max_data_rate >= 323) { /* it is DDR 333 */
Additionally the caslat reduction code should use "<=" and ">=" for the evaluation of clk_cycle2 and clk_cycle3. Otherwise it will only work for a specific memory with SPD contents.
To make it short : DDR-II-333 will be configured with caslat = 5 @ 133MHz Controller speed -> It would work fine with caslat = 3.
Actually 3 bank adress bits are quite usual. This SPD values are not yet evaluated.
Termination schemes (150/75/50 Ohm) and driver characteristics are not handled at all. Most boards would need this or may only run stable with the most conservative timings.
Does it make sense to fix these things or is the "new" DDR code the way to go ?
Ultimately, one way or another, at the end of the day, when all is said and done, the old way will be removed and the new way will prevail. You know.
So, yeah, all of these "per board" configurations will have to be supplied in a new file like each of the 85xx and 86xx boards have done.
HTH, jdl
On Mon, 08 Dec 2008 18:02:02 +0100 Andre Schwarz andre.schwarz@matrix-vision.de wrote:
I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ?
I haven't taken a look at the "new" common ddr code, and there are no current 83xx users that I know of, but if you're willing to port it over to 83xx, it should work better for you than the current 83xx spd code, and give us a basis to work on to move the rest of the 83xx boards over.
Kim
Kim Phillips schrieb:
On Mon, 08 Dec 2008 18:02:02 +0100 Andre Schwarz andre.schwarz@matrix-vision.de wrote:
I'd like to change my DDR setup code since it looks like my computed values are not perfectly stable on our 8343 based board.
This implies using a fake SPD and the related code to set up the controller.
Is the "new" common FSL DDR setup code (cpu/mpc8xxx/ddr/*) stable for 83xx or shall I stick to cpu/mpc83xx/spd_sdram.c for a while ?
I haven't taken a look at the "new" common ddr code, and there are no current 83xx users that I know of, but if you're willing to port it over to 83xx, it should work better for you than the current 83xx spd code, and give us a basis to work on to move the rest of the 83xx boards over.
Kim
ok - thanks. That's why I'm asking ... no 83xx yet. I'll try the default spd driver with fake EEPROM then.
regards, André
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
participants (5)
-
Andre Schwarz -
Jerry Van Baren -
Jon Loeliger -
Kim Phillips -
Kumar Gala