[PATCH] artecgroup/dbe62: Fix SPD_NUM_COLUMNS value (DIMM page size)

[Mart Raudsepp]

artecgroup/dbe62: Fix SPD_NUM_COLUMNS value (DIMM page size)

This changes SPD_NUM_COLUMNS from 0x8 back to 0xa, as it was originally when
copied over from another board, because 0x8 evaluates to 2kB, not 8kB, while 0xa
does the latter. 8kB is what the chip has and what is also set in our currently
used firmwares for DBE62.

This (combined with all the previous committed hard work from Ron before) fixes
memtest86+ freezes and hard reboots for me in quick 30 minute testing time,
while before it would freeze or reboot just into 50% of first test.

There is more to do to get the optimum RAM setup, but this should do for now -
the rest is just optimizing to quicker timings, while current ones in the fake
SPD are very conservative.

Signed-off-by: Mart Raudsepp 
---
 mainboard/artecgroup/dbe62/initram.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mainboard/artecgroup/dbe62/initram.c b/mainboard/artecgroup/dbe62/initram.c
index 97a63a5..186f278 100644
--- a/mainboard/artecgroup/dbe62/initram.c
+++ b/mainboard/artecgroup/dbe62/initram.c
@@ -65,7 +65,7 @@ static const struct spd_entry spd_table[] = {
    {SPD_tRP, 0x58},
    {SPD_PRIMARY_SDRAM_WIDTH, 8},
    {SPD_NUM_BANKS_PER_SDRAM, 0x4},
-	{SPD_NUM_COLUMNS, 0x8},
+	{SPD_NUM_COLUMNS, 0xa}, /* 8kB */
    {SPD_NUM_DIMM_BANKS, 0x1},
    {SPD_REFRESH, 0x82},
    {SPD_SDRAM_CYCLE_TIME_2ND, 0x0},

[PATCH] artecgroup/dbe62: Fix SPD_NUM_COLUMNS value (DIMM page size)

[Carl-Daniel Hailfinger]

On 12.08.2008 21:53, Mart Raudsepp wrote:
> artecgroup/dbe62: Fix SPD_NUM_COLUMNS value (DIMM page size)
>
> This changes SPD_NUM_COLUMNS from 0x8 back to 0xa, as it was originally when
> copied over from another board, because 0x8 evaluates to 2kB, not 8kB, while 0xa
> does the latter. 8kB is what the chip has and what is also set in our currently
> used firmwares for DBE62.
>
> This (combined with all the previous committed hard work from Ron before) fixes
> memtest86+ freezes and hard reboots for me in quick 30 minute testing time,
> while before it would freeze or reboot just into 50% of first test.
>
> There is more to do to get the optimum RAM setup, but this should do for now -
> the rest is just optimizing to quicker timings, while current ones in the fake
> SPD are very conservative.
>
> Signed-off-by: Mart Raudsepp

Cool!
Acked-by: Carl-Daniel Hailfinger

Regards,
Carl-Daniel

[PATCH] artecgroup/dbe62: Fix SPD_NUM_COLUMNS value (DIMM page size)

[ron minnich]

Mart, fine job! I will test here tonight.

thanks

ron

[PATCH] artecgroup/dbe62: Fix SPD_NUM_COLUMNS value (DIMM page size)

[ron minnich]

ok, bad news. With that setting, my board never gets past dram init.

If you have more than one dbe62 board working with this setting, I'm
prepared to say I've got a busted board/dram chip/whatever.

So, if you can do an svn diff, make sure this is all that's really
different, and it works on your hardware, this is

Acked-by: Ronald G. Minnich

Thanks

ron

[PATCH] artecgroup/dbe62: Fix SPD_NUM_COLUMNS value (DIMM page size)

[Mart Raudsepp]

Ühel kenal päeval, T, 2008-08-12 kell 20:02, kirjutas ron minnich:
> ok, bad news. With that setting, my board never gets past dram init.
>
> If you have more than one dbe62 board working with this setting, I'm
> prepared to say I've got a busted board/dram chip/whatever.

I chatted with Martin-Eric, and he is quite confident you have a DBE62
with 128MB of RAM, as the unit that you received was an early prototype.
Almost all other DBE62's in circulation have 256MB, including the one
I'm working on. So I bet that is the issue here.
Did we miss the difference or forget this back when we were looking for
memory chip specification docs and told what memory chip model my units
here have and you told mine?
This also means the registers I gave you were for 256MB, while running
it on a 128MB unit might have resulted in automatically different
registry settings in our firmware - you can probably get those with the
LinuxBIOS firmware you have now.

What we need for DBE61 anyway, is ability to provide multiple SPD's to
try out - because DBE61 has various memory configurations in the wild -
128MB, 256MB, etc. But for the same RAM amount it uses always the same
memory chips, so it boils down to supporting doing what we do in our
code --> Set it up with the largest size, try writing to the highest
addresses, if it succeeds continue and if it fails try the lower amount
of RAM timings, etc. In coreboot-v3 Kconfig system we can also have a
DBE61 specific setting for RAM size, defaulting to "automatic" that does
this described testing, while those who build the image themselves for a
certain unit with known RAM size can select the right one and not have
it waste a few milliseconds on trying various.

Then we can also do the same with DBE62 - with 256MB for all units, and
128MB for the very few prototype units, of which one is what you have
with 128MB  (do you?)

Regards,
Mart Raudsepp
Artec Design LLC

[PATCH] artecgroup/dbe62: Fix SPD_NUM_COLUMNS value (DIMM page size)

[Carl-Daniel Hailfinger]

On 13.08.2008 15:33, Mart Raudsepp wrote:
> Ühel kenal päeval, T, 2008-08-12 kell 20:02, kirjutas ron minnich:
> > ok, bad news. With that setting, my board never gets past dram init.
> >
> > If you have more than one dbe62 board working with this setting, I'm
> > prepared to say I've got a busted board/dram chip/whatever.
>
> I chatted with Martin-Eric, and he is quite confident you have a DBE62
> with 128MB of RAM, as the unit that you received was an early prototype.
> Almost all other DBE62's in circulation have 256MB, including the one
> I'm working on. So I bet that is the issue here.

I'll test this on my DBE62 as well. Mine is a new one AFAICS.
> What we need for DBE61 anyway, is ability to provide multiple SPD's to
> try out - because DBE61 has various memory configurations in the wild -
> 128MB, 256MB, etc. But for the same RAM amount it uses always the same
> memory chips, so it boils down to supporting doing what we do in our
> code --> Set it up with the largest size, try writing to the highest
> addresses, if it succeeds continue and if it fails try the lower amount
> of RAM timings, etc. In coreboot-v3 Kconfig system we can also have a
> DBE61 specific setting for RAM size, defaulting to "automatic" that does
> this described testing, while those who build the image themselves for a
> certain unit with known RAM size can select the right one and not have
> it waste a few milliseconds on trying various.

I have code sitting on my disk which does that. Will try to clean up and
submit.

Regards,
Carl-Daniel

[PATCH] artecgroup/dbe62: Fix SPD_NUM_COLUMNS value (DIMM page size)

[Mart Raudsepp]

Ühel kenal päeval, T, 2008-08-12 kell 20:02, kirjutas ron minnich:
> If you have more than one dbe62 board working with this setting,

I ran memtest again for 1h40min on the same board, doing a full pass and
a half, and also on another DBE62 board for 52 minutes doing one full
pass exactly.
> So, if you can do an svn diff, make sure this is all that's really
> different, and it works on your hardware, this is

That was the only difference that made it work, yes. The 1h40 and 52min
tests were made with trunk + just this change.
> Acked-by: Ronald G. Minnich

Thanks, committed as r757 together with Carl-Daniels ack.

Next I want to work a bit on clarifying some of these fake SPD things in
comments, perhaps improving some related debug printing code, and
getting the DBE61 to work that I have at home (not sure which memory
configuration it was).
I should also clean up and post to util/ my lxmemregs tool that quickly
tells me what a memory related register value actually means, by
converting a given hex of MC_CF8F_DATA or MC_CF1017_DATA to readable
text, a la

tRFC: <value>
tRC: <value>
etc

Maybe there is already a similar more generic tool for any register that
these memory registers can be added onto if necessary? I vaguely recall
something that used a special registry description file to describe
things in a generic way?

With Regards,
Mart Raudsepp
Artec Design LLC

[PATCH] artecgroup/dbe62: Fix SPD_NUM_COLUMNS value (DIMM page size)

[ron minnich]

On Wed, Aug 13, 2008 at 10:37 AM, Mart Raudsepp
 wrote:
> I should also clean up and post to util/ my lxmemregs tool that quickly
> tells me what a memory related register value actually means, by
> converting a given hex of MC_CF8F_DATA or MC_CF1017_DATA to readable
> text, a la

Please do this first, I will test on my system.

We could do some very powerful stuff on v3. For example, in initram,
we can do a find of the ethernet chip and use that info to figure out
which spd values to try. We might end up with a dbe6x directory --
same code for two different boards! now that would be very cool.

thanks

ron