[U-Boot] FSL DDR @ 83xx

[U-Boot] FSL DDR @ 83xx

[Andre Schwarz]

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

[U-Boot] FSL DDR @ 83xx

[Jon Loeliger]

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

[U-Boot] FSL DDR @ 83xx

[Kim Phillips]

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

[U-Boot] FSL DDR @ 83xx

[Andre Schwarz]

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

[U-Boot] FSL DDR @ 83xx

[Andre Schwarz]

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

[U-Boot] FSL DDR @ 83xx

[Kumar Gala]

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

[U-Boot] FSL DDR @ 83xx

[Andre Schwarz]

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

[U-Boot] FSL DDR @ 83xx

[Andre Schwarz]

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

[U-Boot] FSL DDR @ 83xx

[Jon Loeliger]

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

[U-Boot] FSL DDR @ 83xx

[Jon Loeliger]

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

[U-Boot] FSL DDR @ 83xx

[Jon Loeliger]

Andre Schwarz wrote:

> 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 ?

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

[U-Boot] FSL DDR @ 83xx

[Jerry Van Baren]

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

[U-Boot] FSL DDR @ 83xx

[Andre Schwarz]

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