On 22.10.2010, at 14:01, "Scott Duplichan" <sc...@notabs.org> wrote:
> 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?
> 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 <sc...@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);
> }
I think the problem you are seeing might be that on some chipsets the memory
resource still contains the UMA part of that memory while on others it just
contains the usable memory. That would explain why removing that particular
line from the code would solve the problem for you.
Not sure what the right solution would be but we should make sure that it's
consistent across chipsets..
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
