]A patch that gets rid of the unexpected variable MTRR range while ]still using the carve out method of making UMA DRAM UC is easy enough ](see below). ] ]What are the chances that this patch fixes the AMD family 10h systems ]but breaks others? Is there someone here with a non-AMD UMA system?
OK, so in theory there might be a non-AMD UMA project that doesn't suffer from this incorrect variable MTRR range problem. But no one has a non-AMD UMA system that can be used to confirm this. The danger is that fixing the AMD problem the easy way (below) will eventually be found to break one or more non-AMD systems. Does anyone have a suggested solution? All I can think of is to make a private AMD copy of the variable MTRR code, just like we have with the fixed MTRR code. While sharing code between AMD and non-AMD projects seems efficient on the surface, lack of non-AMD systems for testing makes it impractical in some cases.
Thanks, Scott
]If so, it would be useful if you could load it with _less_ than 4GB ]of memory and then dump the variable MTRRs. If it also has the ]unexpected MTRR range, then patching mtrr.c is probably the right ]thing to do. ] ]Thanks, ]Scott ] ]Signed-off-by: Scott Duplichan scott@notabs.org ] ]Index: src/cpu/x86/mtrr/mtrr.c ]=================================================================== ]--- src/cpu/x86/mtrr/mtrr.c (revision 5978) ]+++ src/cpu/x86/mtrr/mtrr.c (working copy) ]@@ -423,9 +423,7 @@ ] if (var_state.hole_startk || var_state.hole_sizek) { ] printk(BIOS_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); ]- ]+ // Set up UMA as an UC hole ] var_state.hole_startk = (uma_memory_base >> 10); ] var_state.hole_sizek = (uma_memory_size >> 10); ] } ]