Avoid hang when 4GB or more DRAM is installed on AMD RS780 UMA systems.
-- When building for UMA, reduce the limit for DRAM below 4GB from E0000000 to C0000000. This is needed to accomodate the UMA frame buffer. -- Correct problem where msr C0010010 bits 21 and 22 (MtrrTom2En and Tom2ForceMemTypeWB) are not set consistently across cores. -- Enable TOM2 only if DRAM is present above 4GB. -- Use AMD Tom2ForceMemTypeWB feature to avoid the need for variable MTRR ranges above 4GB. -- Split function x86_setup_var_mtrrs into standard and AMD versions. The AMD version of the function relies on Tom2ForceMemTypeWB for making DRAM above 4GB type WB. The AMD version also incorporates a change to avoid an unexpected variable MTRR range when using UMA graphics. -- Improve white space consistency for mtrr.c by using tabs in place of spaces. Tested on kino-780am2-fam10 with 2GB and 4GB.
Signed-off-by: Scott Duplichan scott@notabs.org
Index: src/cpu/amd/mtrr/amd_mtrr.c =================================================================== --- src/cpu/amd/mtrr/amd_mtrr.c (revision 6056) +++ src/cpu/amd/mtrr/amd_mtrr.c (working copy) @@ -107,14 +107,14 @@ unsigned long address_bits; struct mem_state state; unsigned long i; - msr_t msr; + msr_t msr, sys_cfg;
/* Enable the access to AMD RdDram and WrDram extension bits */ disable_cache(); - msr = rdmsr(SYSCFG_MSR); - msr.lo |= SYSCFG_MSR_MtrrFixDramModEn; - wrmsr(SYSCFG_MSR, msr); + sys_cfg = rdmsr(SYSCFG_MSR); + sys_cfg.lo |= SYSCFG_MSR_MtrrFixDramModEn; + wrmsr(SYSCFG_MSR, sys_cfg); enable_cache();
printk(BIOS_DEBUG, "\n"); @@ -148,11 +148,18 @@ msr.lo = state.mmio_basek << 10; wrmsr(TOP_MEM, msr);
+ // assume no DRAM above 4GB + sys_cfg.lo &= ~SYSCFG_MSR_TOM2En; + sys_cfg.lo &= ~SYSCFG_MSR_TOM2WB; if(state.tomk > (4*1024*1024)) { /* Setup TOP_MEM2 */ msr.hi = state.tomk >> 22; msr.lo = state.tomk << 10; wrmsr(TOP_MEM2, msr); + // enable tom2 + sys_cfg.lo |= SYSCFG_MSR_TOM2En; + // Make DRAM above 4GB WB without using any variable MTRR ranges + sys_cfg.lo |= SYSCFG_MSR_TOM2WB; }
/* zero the IORR's before we enable to prevent @@ -167,10 +174,9 @@ * Enable the RdMem and WrMem bits in the fixed mtrrs. * Disable access to the RdMem and WrMem in the fixed mtrr. */ - msr = rdmsr(SYSCFG_MSR); - msr.lo |= SYSCFG_MSR_MtrrVarDramEn | SYSCFG_MSR_MtrrFixDramEn | SYSCFG_MSR_TOM2En; - msr.lo &= ~SYSCFG_MSR_MtrrFixDramModEn; - wrmsr(SYSCFG_MSR, msr); + sys_cfg.lo |= SYSCFG_MSR_MtrrVarDramEn | SYSCFG_MSR_MtrrFixDramEn; + sys_cfg.lo &= ~SYSCFG_MSR_MtrrFixDramModEn; + wrmsr(SYSCFG_MSR, sys_cfg);
enable_fixed_mtrr();
@@ -186,5 +192,5 @@ /* Now that I have mapped what is memory and what is not * Setup the mtrrs so we can cache the memory. */ - x86_setup_var_mtrrs(address_bits); + amd_setup_var_mtrrs(address_bits); } Index: src/cpu/x86/mtrr/mtrr.c =================================================================== --- src/cpu/x86/mtrr/mtrr.c (revision 6056) +++ src/cpu/x86/mtrr/mtrr.c (working copy) @@ -364,31 +364,30 @@
void x86_setup_fixed_mtrrs(void) { - /* Try this the simple way of incrementally adding together - * mtrrs. If this doesn't work out we can get smart again - * and clear out the mtrrs. - */ + /* Try this the simple way of incrementally adding together + * mtrrs. If this doesn't work out we can get smart again + * and clear out the mtrrs. + */
- printk(BIOS_DEBUG, "\n"); - /* Initialized the fixed_mtrrs to uncached */ - printk(BIOS_DEBUG, "Setting fixed MTRRs(%d-%d) Type: UC\n", - 0, NUM_FIXED_RANGES); - set_fixed_mtrrs(0, NUM_FIXED_RANGES, MTRR_TYPE_UNCACHEABLE); + printk(BIOS_DEBUG, "\n"); + /* Initialized the fixed_mtrrs to uncached */ + printk(BIOS_DEBUG, "Setting fixed MTRRs(%d-%d) Type: UC\n", + 0, NUM_FIXED_RANGES); + set_fixed_mtrrs(0, NUM_FIXED_RANGES, MTRR_TYPE_UNCACHEABLE);
- /* Now see which of the fixed mtrrs cover ram. - */ - search_global_resources( + /* Now see which of the fixed mtrrs cover ram. */ + search_global_resources( IORESOURCE_MEM | IORESOURCE_CACHEABLE, IORESOURCE_MEM | IORESOURCE_CACHEABLE, set_fixed_mtrr_resource, NULL); - printk(BIOS_DEBUG, "DONE fixed MTRRs\n"); + printk(BIOS_DEBUG, "DONE fixed MTRRs\n");
- /* enable fixed MTRR */ - printk(BIOS_SPEW, "call enable_fixed_mtrr()\n"); - enable_fixed_mtrr(); + /* enable fixed MTRR */ + printk(BIOS_SPEW, "call enable_fixed_mtrr()\n"); + enable_fixed_mtrr();
}
-void x86_setup_var_mtrrs(unsigned address_bits) +static void x86_setup_var_mtrrs(unsigned address_bits) /* this routine needs to know how many address bits a given processor * supports. CPUs get grumpy when you set too many bits in * their mtrr registers :( I would generically call cpuid here @@ -449,6 +448,64 @@ post_code(0x6A); }
+ +void amd_setup_var_mtrrs(unsigned address_bits) +/* this routine needs to know how many address bits a given processor + * supports. CPUs get grumpy when you set too many bits in + * their mtrr registers :( I would generically call cpuid here + * and find out how many physically supported but some cpus are + * buggy, and report more bits then they actually support. + */ +{ + /* Try this the simple way of incrementally adding together + * mtrrs. If this doesn't work out we can get smart again + * and clear out the mtrrs. + */ + struct var_mtrr_state var_state; + + /* Cache as many memory areas as possible */ + /* FIXME is there an algorithm for computing the optimal set of mtrrs? + * In some cases it is definitely possible to do better. + */ + + var_state.range_startk = 0; + var_state.range_sizek = 0; + var_state.hole_startk = 0; + var_state.hole_sizek = 0; + var_state.reg = 0; + var_state.address_bits = address_bits; + + search_global_resources( + IORESOURCE_MEM | IORESOURCE_CACHEABLE, IORESOURCE_MEM | IORESOURCE_CACHEABLE, + set_var_mtrr_resource, &var_state); + + if (var_state.range_sizek >= 0x100000000ull / 1024 && var_state.range_startk == 0) + { + // no variable MTRR range is needed for WB from 4GB-TOM2 + // because Tom2ForceMemTypeWB will be used for this purpose. + var_state.range_sizek = var_state.hole_startk; + } + +#if (CONFIG_GFXUMA == 1) /* UMA or SP. */ + // For now we assume the UMA space is at the end of memory below 4GB + // Reduce the dram wb mtrr range so that it does not cover the uma at the end + var_state.range_sizek -= (uma_memory_size >> 10); +#endif + /* Write the last range */ + var_state.reg = range_to_mtrr(var_state.reg, var_state.range_startk, + var_state.range_sizek, 0, MTRR_TYPE_WRBACK, var_state.address_bits); + printk(BIOS_DEBUG, "DONE variable MTRRs\n"); + printk(BIOS_DEBUG, "Clear out the extra MTRR's\n"); + /* Clear out the extra MTRR's */ + while(var_state.reg < MTRRS) { + set_var_mtrr(var_state.reg++, 0, 0, 0, var_state.address_bits); + } + printk(BIOS_SPEW, "call enable_var_mtrr()\n"); + enable_var_mtrr(); + printk(BIOS_SPEW, "Leave %s\n", __func__); + post_code(0x6A); +} + void x86_setup_mtrrs(unsigned address_bits) { x86_setup_fixed_mtrrs(); Index: src/include/cpu/amd/mtrr.h =================================================================== --- src/include/cpu/amd/mtrr.h (revision 6056) +++ src/include/cpu/amd/mtrr.h (working copy) @@ -8,6 +8,7 @@ #define MTRR_WRITE_MEM (1 << 3)
#define SYSCFG_MSR 0xC0010010 +#define SYSCFG_MSR_TOM2WB (1 << 22) #define SYSCFG_MSR_TOM2En (1 << 21) #define SYSCFG_MSR_MtrrVarDramEn (1 << 20) #define SYSCFG_MSR_MtrrFixDramModEn (1 << 19) Index: src/include/cpu/x86/mtrr.h =================================================================== --- src/include/cpu/x86/mtrr.h (revision 6056) +++ src/include/cpu/x86/mtrr.h (working copy) @@ -37,7 +37,7 @@ #if !defined (ASSEMBLY) && !defined(__PRE_RAM__) #include <device/device.h> void enable_fixed_mtrr(void); -void x86_setup_var_mtrrs(unsigned address_bits); +void amd_setup_var_mtrrs(unsigned address_bits); void x86_setup_mtrrs(unsigned address_bits); int x86_mtrr_check(void); void set_var_mtrr_resource(void *gp, struct device *dev, struct resource *res); Index: src/northbridge/amd/amdmct/wrappers/mcti.h =================================================================== --- src/northbridge/amd/amdmct/wrappers/mcti.h (revision 6056) +++ src/northbridge/amd/amdmct/wrappers/mcti.h (working copy) @@ -42,11 +42,12 @@ //#define SYSTEM_TYPE MOBILE #endif
-/*---------------------------------------------------------------------------- -COMMENT OUT ALL BUT 1 -----------------------------------------------------------------------------*/ +/*--------------------------------------------------------------------------*/ +#if (CONFIG_GFXUMA) +#define UMA_SUPPORT 1 /*Supported */ +#else #define UMA_SUPPORT 0 /*Not supported */ -//#define UMA_SUPPORT 1 /*Supported */ +#endif
/*---------------------------------------------------------------------------- UPDATE AS NEEDED Index: src/northbridge/amd/amdmct/wrappers/mcti_d.c =================================================================== --- src/northbridge/amd/amdmct/wrappers/mcti_d.c (revision 6056) +++ src/northbridge/amd/amdmct/wrappers/mcti_d.c (working copy) @@ -132,13 +132,17 @@ //val = 1; /* enable */ break; case NV_BottomIO: +#if (UMA_SUPPORT == 0) val = 0xE0; /* address bits [31:24] */ +#elif (UMA_SUPPORT == 1) + val = 0xC0; /* address bits [31:24] */ +#endif break; case NV_BottomUMA: #if (UMA_SUPPORT == 0) val = 0xE0; /* address bits [31:24] */ #elif (UMA_SUPPORT == 1) - val = 0xB0; /* address bits [31:24] */ + val = 0xC0; /* address bits [31:24] */ #endif break; case NV_ECC:
Am 10.11.2010 06:13, schrieb Scott Duplichan:
-- Split function x86_setup_var_mtrrs into standard and AMD versions. The AMD version of the function relies on Tom2ForceMemTypeWB for making DRAM above 4GB type WB. The AMD version also incorporates a change to avoid an unexpected variable MTRR range when using UMA graphics.
Maybe move amd_setup_var_mtrrs to src/cpu/amd/mtrr/amd_mtrr.c, too?
Patrick
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Patrick Georgi Sent: Wednesday, November 10, 2010 02:46 AM To: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] Avoid hang when 4GB or more DRAM is installed on AMD RS780 UMA systems
] Maybe move amd_setup_var_mtrrs to src/cpu/amd/mtrr/amd_mtrr.c, too?
Hello Patrick,
Moving amd_setup_var_mtrrs to amd_mtrr.c can be done. But amd_setup_var_mtrrs relies on three static functions in mtrr.c. These three functions would have to be make public: range_to_mtrr, set_var_mtrr, enable_var_mtrr. If that is OK I can give it a try.
Another possibility is to go back to the idea of one x86_setup_var_mtrrs function. A new flag could be passed to x86_setup_var_mtrrs that tells tells the function that it ius running on an AMD system.
It is a little frustrating to have to worry about the possibility of a code change breaking non-AMD UMA operation when I have no way to test it. For example, I suspect the UMA logic for > 4GB systems is not working for all systems. While I can confirm this for AMD systems, I cannot confirm it for non-AMD systems. So I assume I must use one method or another to preserve the existing logic for non-AMD use, just in case it really does work for UMA systems with more than 4GB DRAM.
Thnaks, Scott
]Patrick
Am 10.11.2010 18:43, schrieb Scott Duplichan:
Another possibility is to go back to the idea of one x86_setup_var_mtrrs function. A new flag could be passed to x86_setup_var_mtrrs that tells tells the function that it ius running on an AMD system.
In that case, you could as well keep the separate AMD function around. My main "issue" was that there's vendor specific code in a (supposedly) generic file, esp. when there's already an amd_mtrr.c file. But I guess it doesn't matter that much, and when you're using static variables of mtrr.c, then it might actually be the right place.
It is a little frustrating to have to worry about the possibility of a code change breaking non-AMD UMA operation when I have no way to test it. For example, I suspect the UMA logic for > 4GB systems is not working for all systems. While I can confirm this for AMD systems, I cannot confirm it for non-AMD systems. So I assume I must use one method or another to preserve the existing logic for non-AMD use, just in case it really does work for UMA systems with more than 4GB DRAM.
What's the highlevel algorithm there?
From what I understand, the following happens - please correct me here:
You look up the resources like the "generic" mtrr code, and then there are two differences to the generic code path: 1. (4gb-tom2 .. 4gb) is left uncached (because of Tom2ForceMemTypeWB) 2. UMA is put at (4gb-umasize .. 4gb) and left uncached
Maybe we could do that with a weak function: First, the generic code in x86_setup_var_mtrrs determines the set of memory regions, then calls a weak function (if implemented), and only then makes the call to enable_var_mtrr.
The AMD code would then provide that function and handle the special cases (eg. UMA and that TOM2 space). It wouldn't require those other functions as it's given the var_state struct to work on.
On i945, UMA is done by providing a fixed resource. I don't think any other changes were necessary (see src/northbridge/intel/i945/northbridge.c)
As for the TOM2 stuff: Do you _have_ to mark it uncached? Depending on the situation, it might be less work to just mark it WB in the MTRRs (if that provides a full power-of-two region). But that's a potential optimization to look into separately.
Patrick
]Am 10.11.2010 18:43, schrieb Scott Duplichan: ]> Another possibility is to go back to the idea of one x86_setup_var_mtrrs ]> function. A new flag could be passed to x86_setup_var_mtrrs that tells ]> tells the function that it ius running on an AMD system. ]In that case, you could as well keep the separate AMD function around. ]My main "issue" was that there's vendor specific code in a (supposedly) ]generic file, esp. when there's already an amd_mtrr.c file.
You know, it is possible there is no AMD specific code in the new function amd_setup_var_mtrrs. One change is a fix for a problem that occurs only if 4GB or more DRAM is installed. The status of the problem on non-AMD systems is not known. The other change avoids the unanswered question about whether non-AMD systems really do exclude UMA memory from the reported memory resource. But based on your i945 comment below, i945 does exclude UMA memory before DRAM is reported. Maybe I will look one more time at making the AMD code do this. My last attempt didn't work.
]But I guess it doesn't matter that much, and when you're using static ]variables of mtrr.c, then it might actually be the right place. ] ]> It is a little frustrating to have to worry about the possibility of ]> a code change breaking non-AMD UMA operation when I have no way to ]> test it. For example, I suspect the UMA logic for > 4GB systems is ]> not working for all systems. While I can confirm this for AMD systems, ]> I cannot confirm it for non-AMD systems. So I assume I must use one ]> method or another to preserve the existing logic for non-AMD use, just ]> in case it really does work for UMA systems with more than 4GB DRAM. ]What's the highlevel algorithm there? ]From what I understand, the following happens - please correct me here: ]You look up the resources like the "generic" mtrr code, and then there ]are two differences to the generic code path: ]1. (4gb-tom2 .. 4gb) is left uncached (because of Tom2ForceMemTypeWB) ]2. UMA is put at (4gb-umasize .. 4gb) and left uncached
That is about right. The code comments I added may be a little misleading. Here is what item 2 is really trying to do:
2. If there is DRAM above 4GB, then limit the WB variable MTRRs to DRAM below TOM. For UMA systems, stop at TOM-uma_memory_size.
]Maybe we could do that with a weak function: ]First, the generic code in x86_setup_var_mtrrs determines the set of ]memory regions, then calls a weak function (if implemented), and only ]then makes the call to enable_var_mtrr. ] ]The AMD code would then provide that function and handle the special ]cases (eg. UMA and that TOM2 space). It wouldn't require those other ]functions as it's given the var_state struct to work on. ] ]On i945, UMA is done by providing a fixed resource. I don't think any ]other changes were necessary (see src/northbridge/intel/i945/northbridge.c)
Maybe a similar method would be better for AMD systems. On the other hand, I believe the i945 does not support DRAM above 4GB, which would explain why it is immune to the problem of 'hang when 4GB or more DRAM is installed'. If it can be confirmed that the only coreboot projects supporting DRAM above 4GB are AMD based, then some of the testing concerns can be dropped.
]As for the TOM2 stuff: Do you _have_ to mark it uncached? Depending on ]the situation, it might be less work to just mark it WB in the MTRRs (if ]that provides a full power-of-two region). ]But that's a potential optimization to look into separately.
Not sure I understand the question exactly. RAM between 4GB and TOM2 is easy on AMD systems. Just set Tom2ForceMemTypeWB (done elsewhere) and you are done, the DRAM between 4GB and TOM2 becomes WB and memory above TOM2 continues to default to UC.
Thanks, Scott
]Patrick
] On i945, UMA is done by providing a fixed resource. I don't think any ] other changes were necessary (see src/northbridge/intel/i945/northbridge.c)
I took a look at the i945 code and found the AMD code also adds the exact same fixed resource for the UMA area. What I cannot figure out is how this can reduce the WB DRAM range so that the UMA memory ix excluded.
If I test with 2GB installed and a 256 MB frame buffer, function add_uma_resource is called with the expected arguments: Adding UMA memory area, base=70000000 size=10000000
Later, set_var_mtrr_resource is passed a range of c0000-7fffffff. The existing coreboot code assumes this range has already had the UMA part removed, and adds it back:
// Increase the base range and set up UMA as an UC hole instead var_state.range_sizek += (uma_memory_size >> 10);
What logic should deduct the reserved range from the DRAM range before this code runs?
Thanks, Scott
On 11/10/2010 06:18 PM, Scott Duplichan wrote:
] On i945, UMA is done by providing a fixed resource. I don't think any ] other changes were necessary (see src/northbridge/intel/i945/northbridge.c)
I took a look at the i945 code and found the AMD code also adds the exact same fixed resource for the UMA area. What I cannot figure out is how this can reduce the WB DRAM range so that the UMA memory ix excluded.
If I test with 2GB installed and a 256 MB frame buffer, function add_uma_resource is called with the expected arguments: Adding UMA memory area, base=70000000 size=10000000
Later, set_var_mtrr_resource is passed a range of c0000-7fffffff. The existing coreboot code assumes this range has already had the UMA part removed, and adds it back:
// Increase the base range and set up UMA as an UC hole instead var_state.range_sizek += (uma_memory_size>> 10);What logic should deduct the reserved range from the DRAM range before this code runs?
Hmm. The UMA resource should be in high memory. And code should say if UMA high memory resource is used do not allocate c0000. Interesting.....
-----Original Message----- From: Joseph Smith [mailto:joe@settoplinux.org] Sent: Wednesday, November 10, 2010 05:42 PM To: Scott Duplichan Cc: 'Patrick Georgi'; coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] Avoid hang when 4GB or more DRAM is installed on AMD RS780 UMA systems
]On 11/10/2010 06:18 PM, Scott Duplichan wrote: ]> ] On i945, UMA is done by providing a fixed resource. I don't think any ]> ] other changes were necessary (see src/northbridge/intel/i945/northbridge.c) ]> ]> I took a look at the i945 code and found the AMD code also adds the exact ]> same fixed resource for the UMA area. What I cannot figure out is how this ]> can reduce the WB DRAM range so that the UMA memory ix excluded. ]> ]> If I test with 2GB installed and a 256 MB frame buffer, function add_uma_resource ]> is called with the expected arguments: Adding UMA memory area, base=70000000 size=10000000 ]> ]> Later, set_var_mtrr_resource is passed a range of c0000-7fffffff. The existing ]> coreboot code assumes this range has already had the UMA part removed, and ]> adds it back: ]> ]> // Increase the base range and set up UMA as an UC hole instead ]> var_state.range_sizek += (uma_memory_size>> 10); ]> ]> What logic should deduct the reserved range from the DRAM range before ]> this code runs? ]> ]Hmm. The UMA resource should be in high memory. And code should say if ]UMA high memory resource is used do not allocate c0000. Interesting.....
I think I can explain this part. The message "Adding UMA memory area, base=70000000 size=10000000" refers to the physical address of the DRAM that becomes unavailable due to UMA. This DRAM is never accessed using this physical address. It is accessed through the frame buffer bar, which gets assigned an address between top of memory and 4GB, such as E8000000.
]-- ]Thanks, ]Joseph Smith ]Set-Top-Linux ]www.settoplinux.org
Scott Duplichan wrote:
set_var_mtrr_resource is passed a range of c0000-7fffffff. The existing coreboot code assumes this range has already had the UMA part removed, and adds it back:
// Increase the base range and set up UMA as an UC hole instead var_state.range_sizek += (uma_memory_size >> 10);What logic should deduct the reserved range from the DRAM range before this code runs?
Good question. Or should the above code be removed?
Why does UMA need special consideration? Is it any other reason than that it sometimes should be included in RAM size, and other times not?
Scott Duplichan wrote:
The message "Adding UMA memory area, base=70000000 size=10000000" refers to the physical address of the DRAM that becomes unavailable due to UMA. This DRAM is never accessed using this physical address. It is accessed through the frame buffer bar, which gets assigned an address between top of memory and 4GB, such as E8000000.
Ignoring the real issue for a while, isn't this really stupid? Why not let the BAR point to actual DRAM instead, and free up some IO space?
//Peter
What logic should deduct the reserved range from the DRAM range before this code runs?
] Good question. Or should the above code be removed?
Oh sorry, never mind this question. I think I found where the i945 code deducts uma size before reporting the dram:
tomk -= uma_size; http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/northbridge/inte...
I will make the AMD code work this way and re-sumbit the patch.
Thanks, Scott
On 11/10/2010 07:30 PM, Scott Duplichan wrote:
-----Original Message----- From: Joseph Smith [mailto:joe@settoplinux.org] Sent: Wednesday, November 10, 2010 05:42 PM To: Scott Duplichan Cc: 'Patrick Georgi'; coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] Avoid hang when 4GB or more DRAM is installed on AMD RS780 UMA systems
]On 11/10/2010 06:18 PM, Scott Duplichan wrote: ]> ] On i945, UMA is done by providing a fixed resource. I don't think any ]> ] other changes were necessary (see src/northbridge/intel/i945/northbridge.c) ]> ]> I took a look at the i945 code and found the AMD code also adds the exact ]> same fixed resource for the UMA area. What I cannot figure out is how this ]> can reduce the WB DRAM range so that the UMA memory ix excluded. ]> ]> If I test with 2GB installed and a 256 MB frame buffer, function add_uma_resource ]> is called with the expected arguments: Adding UMA memory area, base=70000000 size=10000000 ]> ]> Later, set_var_mtrr_resource is passed a range of c0000-7fffffff. The existing ]> coreboot code assumes this range has already had the UMA part removed, and ]> adds it back: ]> ]> // Increase the base range and set up UMA as an UC hole instead ]> var_state.range_sizek += (uma_memory_size>> 10); ]> ]> What logic should deduct the reserved range from the DRAM range before ]> this code runs? ]> ]Hmm. The UMA resource should be in high memory. And code should say if ]UMA high memory resource is used do not allocate c0000. Interesting.....
I think I can explain this part. The message "Adding UMA memory area, base=70000000 size=10000000" refers to the physical address of the DRAM that becomes unavailable due to UMA. This DRAM is never accessed using this physical address. It is accessed through the frame buffer bar, which gets assigned an address between top of memory and 4GB, such as E8000000.
Not so sure about AMD chips but I know Intel chips reserve memory just below 4Gb for vga buffer. As for resource ranges Intel chips reserve a low memory range for VESA IO registers and a high memory range for GMCH MMIO registers. Hope that helps.
Sent from my mobile phone
On 10.11.2010, at 17:36, Joseph Smith joe@settoplinux.org wrote:
Not so sure about AMD chips but I know Intel chips reserve memory just below 4Gb for vga buffer. As for resource ranges Intel chips reserve a low memory range for VESA IO registers and a high memory range for GMCH MMIO registers. Hope that helps.
Actually the intel chipsets reserve memory at the top of ram for graphics, not below 4G
On Wed, 10 Nov 2010 19:29:45 -0800, Stefan Reinauer stefan.reinauer@coresystems.de wrote:
Sent from my mobile phone
On 10.11.2010, at 17:36, Joseph Smith joe@settoplinux.org wrote:
Not so sure about AMD chips but I know Intel chips reserve memory just
below 4Gb for vga buffer. As for resource ranges Intel chips reserve a
low
memory range for VESA IO registers and a high memory range for GMCH MMIO registers. Hope that helps.
Actually the intel chipsets reserve memory at the top of ram for
graphics,
not below 4G
Ah your right, my bad. It is just below TOM. ex: [rest of memory][vga memory area][tom].
On 11/10/10, Scott Duplichan scott@notabs.org wrote:
Avoid hang when 4GB or more DRAM is installed on AMD RS780 UMA systems.
-- When building for UMA, reduce the limit for DRAM below 4GB from E0000000 to C0000000. This is needed to accomodate the UMA frame buffer. -- Correct problem where msr C0010010 bits 21 and 22 (MtrrTom2En and Tom2ForceMemTypeWB) are not set consistently across cores. -- Enable TOM2 only if DRAM is present above 4GB. -- Use AMD Tom2ForceMemTypeWB feature to avoid the need for variable MTRR ranges above 4GB. -- Split function x86_setup_var_mtrrs into standard and AMD versions. The AMD version of the function relies on Tom2ForceMemTypeWB for making DRAM above 4GB type WB. The AMD version also incorporates a change to avoid an unexpected variable MTRR range when using UMA graphics. -- Improve white space consistency for mtrr.c by using tabs in place of spaces. Tested on kino-780am2-fam10 with 2GB and 4GB.
Hi,
I'm interesting in how the RS780 UMA system hangs with more than 4GB DRAM, is it caused by the incorrect MTRR for uma memory region?
On my K8+RS780+SB710 board with UMA enabled, the system works fine with 2G DRAM, but with 4G DRAM the SATA disks cannot be detected by Linux and caused driver timeout, seems there are problems with io memory visit. Does this related with uma or MTRR? I tried your patch but seems no effect with the problem.
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Liu Tao Sent: Thursday, November 11, 2010 03:32 AM To: Scott Duplichan Cc: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] Avoid hang when 4GB or more DRAM is installed on AMD RS780 UMA systems
On 11/10/10, Scott Duplichan scott@notabs.org wrote:
Avoid hang when 4GB or more DRAM is installed on AMD RS780 UMA systems.
-- When building for UMA, reduce the limit for DRAM below 4GB from E0000000 to C0000000. This is needed to accomodate the UMA frame buffer. -- Correct problem where msr C0010010 bits 21 and 22 (MtrrTom2En and Tom2ForceMemTypeWB) are not set consistently across cores. -- Enable TOM2 only if DRAM is present above 4GB. -- Use AMD Tom2ForceMemTypeWB feature to avoid the need for variable MTRR ranges above 4GB. -- Split function x86_setup_var_mtrrs into standard and AMD versions. The AMD version of the function relies on Tom2ForceMemTypeWB for making DRAM above 4GB type WB. The AMD version also incorporates a change to avoid an unexpected variable MTRR range when using UMA graphics. -- Improve white space consistency for mtrr.c by using tabs in place of spaces. Tested on kino-780am2-fam10 with 2GB and 4GB.
Hi,
I'm interesting in how the RS780 UMA system hangs with more than 4GB DRAM, is it caused by the incorrect MTRR for uma memory region?
On my K8+RS780+SB710 board with UMA enabled, the system works fine with 2G DRAM, but with 4G DRAM the SATA disks cannot be detected by Linux and caused driver timeout, seems there are problems with io memory visit. Does this related with uma or MTRR? I tried your patch but seems no effect with the problem.
-
Joseph Smith -
Liu Tao -
Patrick Georgi -
Peter Stuge -
Scott Duplichan -
Stefan Reinauer