Hi,

On 22.10.2010 03:34, Scott Duplichan wrote:
> I find an unexpected MTRR setup for my RS780/SB700 UMA board. With
> a single 1GB DIMM and 256MB UMA size, the variable MTRRs look like this:
>
> -----coreboot+seabios-----
> default memory type: UC
> variable range 0: 000000000-03FFFFFFF WB
> variable range 1: 040000000-04FFFFFFF WB
> variable range 2: 030000000-03FFFFFFF UC
> variable range 3: disabled
> variable range 4: disabled
> variable range 5: disabled
> variable range 6: disabled
> variable range 7: disabled
>
> Variable range 1 is unexpected. It creates a window of WB-IO, which is
> highly unusual. 
>   

AFAIK if two ranges overlap and one of the ranges is UC, the overlapping
region will be UC. At least that's what the specs say.


> -----Production BIOS (AMI):-----
> default memory type: UC
> variable range 0: 000000000-01FFFFFFF WB
> variable range 1: 020000000-02FFFFFFF WB
> variable range 2: disabled
> variable range 3: disabled
> variable range 4: disabled
> variable range 5: disabled
> variable range 6: disabled
> variable range 7: disabled
>
> The above is how uma is normally handled. Build up WB ranges until
> the needed size is reached.
>   

For 1 GB RAM and 256 MB UMA, you have to mark 768 MB as WB. That's OK
either way (adding up WB ranges or using a UC range to carve a hole).

However, once you have 2 GB RAM and 64 MB UMA, you can do it with two
ranges:
00000000-7FFFFFFF WB
7C000000-7FFFFFFF UC
or with five ranges:
00000000-3FFFFFFF WB
40000000-5FFFFFFF WB
60000000-6FFFFFFF WB
70000000-77FFFFFF WB
78000000-7BFFFFFF WB

In the past we had to deal with range exhaustion, and that's the reason
why we carve a hole for UMA. It gets especially funny if you have more
than 4 GB RAM because then you want a hole for PCI devices below 4 GB
and you need additional ranges above 4 GB.

If switching the MTRR allocation is strictly needed for Windows (and
there is no way to avoid it), thats pretty much the only reason we
should go away from carving holes with UC.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Reply via email to