On 05/30/2013 01:45 PM, Cristian Măgherușan-Stanciu wrote:
Wow, I can't believe I was so close to the commit before the fork ;-D
I also think this is a good strategy, please keep us posted on any progress.
Peter and Cristi, thank a bunch for your help. Your suggestions helped me a lot in reaching the following conclusions.
I tried a couple of things, as Peter suggested. I managed to build a ROM from their tree. It didn't work since it was written for a different board. I pulled in the romstrap table from my board, and the early serial init. That also didn't work. It could be that their code reconfigures the cpu to nb bus in a way not suited for my board; I haven't dug too deeply into the issue. That configuration is best left in the romstrap.
Since the raminit code is fairly isolated, I pulled it into my branch, and spent about half a day getting it to compile. I spent a little time finding out why the meat of raminit code is not called, until I found out it was looking for a SO-DIMM. That's already a red flag.
The code from VIA has a ton of tables with delays and driving values for DRAM. The most important parameter, how much to wait before reading each set of DQ pins, is also preset. That preset is different than what I have been using. Needless to say, raminit fails. The presets are board-specific.
Other than the presets, I can't see anything fundamentally different from the raminit algorithm that's on gerrit. I don't think the effort of rebasing the VIA code is worth the benefits (not even sure there are any benefits -- the gerrit code does the same thing with 20 times less LOC). I'll have to play around with it some more, see if I can get it working.
Right now, it looks like the VIA code serves better as a HOWTO (or HOWNOTTO) guide.
Will post updates (either here or on IRC).
Alex
P.S. Limited time offer: Free tickets to join the fun for anyone with a VX900 board.
-
Alex G.