patch: grow grafix memory, and fix PLL on dbe62

[ron minnich]

This grows graphics mem to 16M per artec's recommendation.

The PLL autoconfig works now, so move to an auto value instead of
manual config.

This does not fix the problem with the memory errors. We've still got
something wrong in memory, and it is not clear what.

Signed-off-by: Ronald G. Minnich

I forgot it in the patch.

ron

[Tom Sylla]

On Wed, Jul 9, 2008 at 12:05 PM, ron minnich  wrote:
> This does not fix the problem with the memory errors. We've still got
> something wrong in memory, and it is not clear what.

Does DBE62 have an unterminated memory interface? Can you compare MSR
0x4c00000f from coreboot to a working BIOS? Unterminated platforms are
supposed to have a special value (0xF2F100FF 0x56960004) for that
register, which is in a comment in geodelx.c, but I don't see that
value in any table. (maybe I am missing it, but the special value
should be set for DB800, too)

[Carl-Daniel Hailfinger]

On 09.07.2008 18:05, ron minnich wrote:
> This grows graphics mem to 16M per artec's recommendation.
>
> The PLL autoconfig works now, so move to an auto value instead of
> manual config.
>
> This does not fix the problem with the memory errors. We've still got
> something wrong in memory, and it is not clear what.
>
> Signed-off-by: Ronald G. Minnich

Acked-by: Carl-Daniel Hailfinger

Regards,
Carl-Daniel

[Uwe Hermann]

On Wed, Jul 09, 2008 at 09:05:39AM -0700, ron minnich wrote:
> This grows graphics mem to 16M per artec's recommendation.

You mean 32MB? The comment says "Video RAM has to be in 2MB chunks", so
either 16M is wrong, or the comment is wrong (?)

The patch is fine otherwise, but I cannot test...

Uwe.

[ron minnich]

On Thu, Jul 10, 2008 at 4:32 AM, Uwe Hermann  wrote:
> On Wed, Jul 09, 2008 at 09:05:39AM -0700, ron minnich wrote:
> > This grows graphics mem to 16M per artec's recommendation.
>
> You mean 32MB? The comment says "Video RAM has to be in 2MB chunks", so
> either 16M is wrong, or the comment is wrong (?)
>
> The patch is fine otherwise, but I cannot test...

I will reword that comment. I think the meaning is lost in translation?

Video RAM has to be in mulitples of 2 MB

ron

[ron minnich]

On Wed, Jul 9, 2008 at 11:54 AM, Tom Sylla  wrote:
> On Wed, Jul 9, 2008 at 12:05 PM, ron minnich  wrote:
> > This does not fix the problem with the memory errors. We've still got
> > something wrong in memory, and it is not clear what.
>
> Does DBE62 have an unterminated memory interface? Can you compare MSR
> 0x4c00000f from coreboot to a working BIOS? Unterminated platforms are
> supposed to have a special value (0xF2F100FF 0x56960004) for that
> register, which is in a comment in geodelx.c, but I don't see that
> value in any table. (maybe I am missing it, but the special value
> should be set for DB800, too)

That's interesting! The coreboot value is  83:f1:00:aa:56:96:03:44

I'll try to boot *something* that lets me see the other bios value.

ron

[Uwe Hermann]

On Fri, Jul 11, 2008 at 08:21:58AM -0700, ron minnich wrote:
> On Thu, Jul 10, 2008 at 4:32 AM, Uwe Hermann  wrote:
> > On Wed, Jul 09, 2008 at 09:05:39AM -0700, ron minnich wrote:
> > > This grows graphics mem to 16M per artec's recommendation.
> >
> > You mean 32MB? The comment says "Video RAM has to be in 2MB chunks", so
> > either 16M is wrong, or the comment is wrong (?)
> >
> > The patch is fine otherwise, but I cannot test...
>
> I will reword that comment. I think the meaning is lost in translation?
>
> Video RAM has to be in mulitples of 2 MB

Ah, yes, makes sense then.

Acked-by: Uwe Hermann

with the updated comment.

Uwe.

LX RAM I/O delay

[Peter Stuge]

On Fri, Jul 11, 2008 at 08:33:12AM -0700, ron minnich wrote:
> > Does DBE62 have an unterminated memory interface? Can you compare
> > MSR 0x4c00000f from coreboot to a working BIOS? Unterminated
> > platforms are supposed to have a special value (0xF2F100FF
> > 0x56960004) for that register
>
> That's interesting! The coreboot value is  83:f1:00:aa:56:96:03:44

Decoded those values per page 549-550 of LX_databook.

The coreboot value means:
Half power drive of DQ DQS DQM TLA RAS CAS CKE CS WE MA and BA.
Full SDCLK setup.
DDR read latch enable position set to 1.
SDCLK disabled on SDCLK[1,3,5] outputs.
Output delay for CKE CS RAS CAS WE BA and MA set to 2.

The reference value means:
Full power drive of DQ DQS DQM TLA RAS CAS CKE CS WE MA and BA.
Half SDCLK setup for control signals.
DDR read latch enable position set to 3.
All SDCLK outputs enabled.
Output delay for CKE CS RAS CAS WE BA and MA set to 3.

//Peter

LX RAM I/O delay

[ron minnich]

Thanks for the decode!

suggestion for all of us. Every time we decode this stuff, we *write a
program* -- perl, C, who cares -- that does it for us. Then, from that
point on, anyone can more easily get this info. And, coreboot will
have another cool property -- a huge suite of programs for figuring
these settings out.

Thanks!

ron

[ron minnich]

BTW, I'm out for 10 days. If anyone wants to commit these acked
patches, go for it; I can't.

I would suggest acking Marc's 5536 patch; I can test and verify later,
but it looks ok to me.

thanks

ron

msrtool

[Peter Stuge]

On Sat, Jul 12, 2008 at 09:02:36AM -0700, ron minnich wrote:
> Thanks for the decode!

Today's lesson: Don't trust my decodes right now.
> suggestion for all of us. Every time we decode this stuff, we
> *write a program* -- perl, C, who cares -- that does it for us.

Yeah. I did that. The diff output from your coreboot value vs. the
reference value is attached. As you can see I shifted some bits wrong
when doing the decode manually. I need some practice I guess.
> And, coreboot will have another cool property -- a huge suite of
> programs for figuring these settings out.

Yes, definately. I still want to fix up msrtool a little more but
will send very soon.

//Peter

msrtool

[Peter Stuge]

On Sat, Jul 12, 2008 at 09:56:43PM +0200, Peter Stuge wrote:
> --- coreboot.dec	2008-07-12 21:48:52.000000000 +0200
> +++ unterm.dec	2008-07-12 21:49:16.000000000 +0200

..
> 60 B_MA Buffer Control for MA BA drive = 0: Quarter power
> 60 B_MA Buffer Control for MA BA drive = 1: Half power

Copypaste error for this bit. 0 means Half power, 1 means Full power.

//Peter

msrtool

[Tom Sylla]

The decode might seem interesting, but this is close to veering down a 
bad path.

You do *not* want to try and futz around with any of those settings. The 
values in the table (plus the missing one for unterminated) are the only 
ones you will ever want to use. Thousands of hours of debug and 
validation time by AMD came up with those numbers. You should not have 
to "tweak" any of those settings to get something to work. There are 
comments in the coreboot source to that effect, too.

My only reason to point this out is that by decoding it, you are sort of 
implying that the fields might need to be tweaked.

Peter Stuge wrote:
> On Sat, Jul 12, 2008 at 09:02:36AM -0700, ron minnich wrote:
> > Thanks for the decode!
>
> Today's lesson: Don't trust my decodes right now.
> > suggestion for all of us. Every time we decode this stuff, we
> > *write a program* -- perl, C, who cares -- that does it for us.
>
> Yeah. I did that. The diff output from your coreboot value vs. the
> reference value is attached. As you can see I shifted some bits wrong
> when doing the decode manually. I need some practice I guess.
> > And, coreboot will have another cool property -- a huge suite of
> > programs for figuring these settings out.
>
> Yes, definately. I still want to fix up msrtool a little more but
> will send very soon.
>
> //Peter

msrtool

[ron minnich]

On Sat, Jul 12, 2008 at 3:36 PM, Tom Sylla  wrote:
> The decode might seem interesting, but this is close to veering down a
> bad path.
>
> You do *not* want to try and futz around with any of those settings. The
> values in the table (plus the missing one for unterminated) are the only
> ones you will ever want to use. Thousands of hours of debug and
> validation time by AMD came up with those numbers. You should not have
> to "tweak" any of those settings to get something to work. There are
> comments in the coreboot source to that effect, too.

believe me, I dont' want to mess with them.
> My only reason to point this out is that by decoding it, you are sort of
> implying that the fields might need to be tweaked.

no. Here's my thinking. It could decode those bits and then say,
"This is appropriate to an UNTERMINATED bus with ONE row of DIMMS and
4 devices. "
"The DRAM hardware is configured for CL 2.5'

and so on.

I.e. allow people to backtrack from the settings to the hardware and
see if things make sense. The goals is NOT to tweak the individual
bits.

thanks

ron

msrtool

[ron minnich]

On Sat, Jul 12, 2008 at 9:05 PM, ron minnich  wrote:
> On Sat, Jul 12, 2008 at 3:36 PM, Tom Sylla  wrote:
> > The decode might seem interesting, but this is close to veering down a
> > bad path.
> >
> > You do *not* want to try and futz around with any of those settings. The
> > values in the table (plus the missing one for unterminated) are the only
> > ones you will ever want to use. Thousands of hours of debug and
> > validation time by AMD came up with those numbers. You should not have
> > to "tweak" any of those settings to get something to work. There are
> > comments in the coreboot source to that effect, too.
>
> believe me, I dont' want to mess with them.
> > My only reason to point this out is that by decoding it, you are sort of
> > implying that the fields might need to be tweaked.
>
> no. Here's my thinking. It could decode those bits and then say,
> "This is appropriate to an UNTERMINATED bus with ONE row of DIMMS and
> 4 devices. "
> "The DRAM hardware is configured for CL 2.5'
>
> and so on.
>
> I.e. allow people to backtrack from the settings to the hardware and
> see if things make sense. The goals is NOT to tweak the individual
> bits.

in fact I'm actually working with a mobo vendor RIGHT NOW to create
this type of 'what are the settings' tool for barcelona so we can
track down a bug. Would that we had it.

Although, really, would that they had listened and done coreboot in
the first place; they're having trouble on a DRAM config problem and
lack of coreboot means it is hard to help them .

In fact, make that *2* vendors I am talking to in this situation; same
problem, different (very different) boards.

ron

msrtool

[Carl-Daniel Hailfinger]

On 13.07.2008 06:07, ron minnich wrote:
> in fact I'm actually working with a mobo vendor RIGHT NOW to create
> this type of 'what are the settings' tool for barcelona so we can
> track down a bug. Would that we had it.
>
> Although, really, would that they had listened and done coreboot in
> the first place; they're having trouble on a DRAM config problem and
> lack of coreboot means it is hard to help them .
>
> In fact, make that *2* vendors I am talking to in this situation; same
> problem, different (very different) boards.

You could make your help conditional on coreboot usage. I do believe
that you rub in the point about coreboot, though, and I'm thankful for that.

Regards,
Carl-Daniel

msrtool

[Tom Sylla]

ron minnich wrote:
> > no. Here's my thinking. It could decode those bits and then say,
> > "This is appropriate to an UNTERMINATED bus with ONE row of DIMMS and
> > 4 devices. "
> > "The DRAM hardware is configured for CL 2.5'

hrm, you don't *need* to decode bits for that. If the value is 
"0xF2F100FF 0x56960004", it is unterminated. That's it. Other values of 
that 64 bit register mean different configurations.
> in fact I'm actually working with a mobo vendor RIGHT NOW to create
> this type of 'what are the settings' tool for barcelona so we can
> track down a bug. Would that we had it.

Is it booting? AMD provides a couple of tools to to check registers 
already. One of them is more than just a parser, and actually verifies 
all the relevant settings against "what they should be". Have you tried 
those tools? We try to use those tools on any BIOS release version, and 
especially whenever something major changes, like AGESA.

[Mart Raudsepp]

Ühel kenal päeval, L, 2008-07-12 kell 13:56, kirjutas Uwe Hermann:
> On Fri, Jul 11, 2008 at 08:21:58AM -0700, ron minnich wrote:
> > On Thu, Jul 10, 2008 at 4:32 AM, Uwe Hermann  wrote:
> > > On Wed, Jul 09, 2008 at 09:05:39AM -0700, ron minnich wrote:
> > > > This grows graphics mem to 16M per artec's recommendation.
> > >
> > > You mean 32MB? The comment says "Video RAM has to be in 2MB chunks", so
> > > either 16M is wrong, or the comment is wrong (?)
> > >
> > > The patch is fine otherwise, but I cannot test...
> >
> > I will reword that comment. I think the meaning is lost in translation?
> >
> > Video RAM has to be in mulitples of 2 MB
>
> Ah, yes, makes sense then.
>
> Acked-by: Uwe Hermann
>
> with the updated comment.

What comment would you suggest? Ron never worded it out here.

But to me the existing comment is quite clear. It has to be an even
number of megabytes by my understanding- it goes by 2MB granularity, you
can assign 0, 2, 4, 6, 8, 10, 12, 14, 16 and so on megabytes for video
memory because in the registry meaning it increases in steps of 2MB,
iirc.

As I did the equivalent changes to DBE61 some months ago when I was
making it boot linux in coreboot-v3, I can commit this soon myself too
with the provided Acks.

So I suggest the following comment:

"Video RAM has to be in a 2MB granularity"

Regards,
Mart Raudsepp

[ron minnich]

mart, did you try memtest on the dbe61?

thanks

ron

[Mart Raudsepp]

Ühel kenal päeval, N, 2008-07-17 kell 06:04, kirjutas ron minnich:
> mart, did you try memtest on the dbe61?

I think it was failing, but I need to double-check on that.

I just made a bunch of hardware selection (flash instead of IDE, etc)
related changes back then per what's on the board, so that once RAM is
good, things would be peachy, similar to DBE62.

Regards,
Mart

[Alejandro Ruiz]

how to fix grafix in linux