On 11.02.2009 18:11 Uhr, ron minnich wrote:
> I agree it's an emergency however :-)
>
> 10 minute boot times! call the hospital, the computer is sick!
>
> ron
>
I did a very similar patch two days ago. Sorry this is not against
Carl-Daniel's latest changes, but I thought I'd put it out for
discussion first.
There's one case when MTRR setup goes severely wrong, and that is all
those boards with UMA graphics onboard. That's all the 945GM boards, the
690 boards, some VIA boards, etc etc.
What the patch does is create a special case for UMA. It checks whether
there's an MTRR hole, and if there is none, it creates one for the UMA area.
With the patch applied my test board went down from 8 used MTRRs to 2
(one for RAM and one for UMA) and at the same time the complete RAM is
covered.
I remember there was a suggestion for a complete "optimal" MTRR setup
algorithm that attempts to always do the right thing with major
complexity. This patch is much simpler. It takes the most common case
and fixes it without trying to be perfect. So I think this is a good
solution for v2, and maybe someone wants to do the perfect thing for v3
at some point.
Comments? Acks?
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [email protected] • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
fix mtrr setup for UMA architectures.
Signed-off-by: Stefan Reinauer <[email protected]>
Index: src/cpu/x86/mtrr/mtrr.c
===================================================================
--- src/cpu/x86/mtrr/mtrr.c (.../branches/upstream/coreboot-v2)
+++ src/cpu/x86/mtrr/mtrr.c (.../trunk/coreboot-v2)
@@ -37,6 +37,10 @@
#include <cpu/x86/mtrr.h>
#include <cpu/x86/cache.h>
+#ifdef CONFIG_GFXUMA
+extern uint64_t uma_memory_base, uma_memory_size;
+#endif
+
static unsigned int mtrr_msr[] = {
MTRRfix64K_00000_MSR, MTRRfix16K_80000_MSR, MTRRfix16K_A0000_MSR,
MTRRfix4K_C0000_MSR, MTRRfix4K_C8000_MSR, MTRRfix4K_D0000_MSR,
MTRRfix4K_D8000_MSR,
@@ -164,7 +168,7 @@
* ramsize = 156MB == 128MB WB (at 0MB) + 32MB WB (at 128MB) + 4MB UC (at
156MB)
*/
/* 2 MTRRS are reserved for the operating system */
-#if 0
+#if 1
#define BIOS_MTRRS 6
#define OS_MTRRS 2
#else
@@ -228,9 +232,22 @@
unsigned long range_startk, unsigned long range_sizek,
unsigned long next_range_startk, unsigned char type, unsigned
address_bits)
{
- if (!range_sizek || (reg >= BIOS_MTRRS)) {
+ if (!range_sizek) {
+ /* If there's no MTRR hole, this function will bail out
+ * here when called for the hole.
+ */
+ printk_spew("Zero-sized MTRR range @%ldKB\n", range_startk);
return reg;
}
+
+ if (reg >= BIOS_MTRRS) {
+ printk_debug("Warning: Out of MTRRs for base: %4ldMB, range:
%ldMB, type %s\n",
+ range_startk >>10, range_sizek >> 10,
+ (type==MTRR_TYPE_UNCACHEABLE)?"UC":
+ ((type==MTRR_TYPE_WRBACK)?"WB":"Other") );
+ return reg;
+ }
+
while(range_sizek) {
unsigned long max_align, align;
unsigned long sizek;
@@ -368,6 +385,7 @@
enable_fixed_mtrr();
}
+
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
@@ -394,10 +412,22 @@
#endif
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);
+#ifdef CONFIG_GFXUMA
+ // For now we assume the UMA space is at the end of memory
+ if (var_state.hole_startk || var_state.hole_sizek) {
+ printk_debug("Warning: Can't set up MTRR hole for UMA due to
pre-existing MTRR hole.\n");
+ } else {
+ // Increase the base range and set up UMA as an UC hole instead
+ var_state.range_sizek += (uma_memory_size >> 10);
+ var_state.hole_startk = (uma_memory_base >> 10);
+ var_state.hole_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);
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
