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
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
Will post updates (either here or on IRC).
P.S. Limited time offer: Free tickets to join the fun for anyone with a