Hi Reinhard,

This e-Mail of yours did reach me directly, but did not make it to the list. Something funny going on...

That's what happened to me as well I guess.

The current SDRAM/DDRAM init in top5200.c consists of 13 assignment statements, parametrized by 8 constants from top5200.h.

Correct. That's about the minimum of stores you need to perform to initialize the SDRAM controller and the SDRAM itself.

So far I have not added any VPD reading for those, because the only TOP5200 version being built so far has exactly that kind of Micron SDRAM (64MB total).

If you add VPD (I do not know the abbreviation but I guess you mean a configuration EEPROM) you can live with the same amount of stores if you specify everything inside the VPD. So I guess we agree here.

When I look at the original source for the IceCube SDRAM init this is very hard to read and understand; not to mention that this init did not work for the TOP5200 although it is the same type of SDRAM and the same wiring. But I found out that the IceCube init produces quite different values than I come up with following the 5200 Manual and the Micron Manual. My values work on TOP5200 and incidently also on LITE5200 - in fact the TOP5200 port can be parametrized to produce code for the LITE5200 which works perfectly and was done by me as a crosscheck.

The original init code from Wolfgang did also not work on one of my engineering boards. That was the reason I submitted a fixed version. There were some sync instructions missing. Additionally the new code uses #defines to make it flexible and SDRAM type independent. I did not remove the automatic detection of SDRAM size and CS usage because I wanted the SDRAM include files to be board independent. Of course you could specify the missing parameters in the board code as well. But the code to do it automatically already existed.

How would you want to generalize?

A) a small function, containing 13 statements and having 8 parameters B) a function that tries to figure out what SDRAM/DDRAM is connected and which size it has C) a function with alot of #if's catering for the minute differences between the various boards

I would go for B with a kind of C where some parameters are passed to the initialization function. These parameters can either come from an EEPROM, #defines, calculated on the fly or whatever you can think of.

For the argument of an initial port, I prefer to use fixed values for initialization of SDRAM, values that have been tested in other environments (BDI2000, other OS) compared to automatic determined values. If the automatic determined values work, its fine, of course - but if they don't you end up researching why.

Personally I do not want to have the code calculate all the values. But detecting the usage of CS1 and the size of the SDRAM is not a bad thing in my mind. The nice thing of doing in like that would be that we could add a #define option to make it a programmers choice whether to do the detection of simply take #defines instead. I guess that would make both of us happy.

Coming back to the reason I started this discussion: Do you have an idea where to place this MGT5100 / MPC5200 generic piece of code? Where to put the SDRAM initialization values? As they are also board independent and many boards are using the same SDRAM a central place would be good, too.

Regards Mark