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 rminnich@gmail.com
I forgot it in the patch.
ron
On Wed, Jul 9, 2008 at 12:05 PM, ron minnich rminnich@gmail.com 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)
On Wed, Jul 9, 2008 at 11:54 AM, Tom Sylla tsylla@gmail.com wrote:
On Wed, Jul 9, 2008 at 12:05 PM, ron minnich rminnich@gmail.com 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
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
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
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
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
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
On Sat, Jul 12, 2008 at 3:36 PM, Tom Sylla tsylla@gmail.com 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
On Sat, Jul 12, 2008 at 9:05 PM, ron minnich rminnich@gmail.com wrote:
On Sat, Jul 12, 2008 at 3:36 PM, Tom Sylla tsylla@gmail.com 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
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
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.
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 rminnich@gmail.com
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Regards, Carl-Daniel
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.
On Thu, Jul 10, 2008 at 4:32 AM, Uwe Hermann uwe@hermann-uwe.de 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
On Fri, Jul 11, 2008 at 08:21:58AM -0700, ron minnich wrote:
On Thu, Jul 10, 2008 at 4:32 AM, Uwe Hermann uwe@hermann-uwe.de 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 uwe@hermann-uwe.de
with the updated comment.
Uwe.
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
Ü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 uwe@hermann-uwe.de 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 uwe@hermann-uwe.de
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
mart, did you try memtest on the dbe61?
thanks
ron
Ü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
how to fix grafix in linux
-
Alejandro Ruiz -
Carl-Daniel Hailfinger -
Mart Raudsepp -
Peter Stuge -
ron minnich -
Tom Sylla -
Uwe Hermann