[coreboot] [PATCH] Avoid hang when 4GB or more DRAM is installed on AMD RS780 UMA systems

[Scott Duplichan]

-----Original Message-----
From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Liu Tao
Sent: Thursday, November 11, 2010 03:32 AM
To: Scott Duplichan
Cc: coreboot at 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 at 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.

-- 
Regards,
Liu Tao

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


Hello Liu Tao,

If you can point me to your code I could try to help. I might be
able to run your code on my board.

I did not try to find the exact cause of the hang because there
were more than one incorrect setting. 

I am about to submit a new patch. This time I will test with both
family 10h and family 0Fh (K8) processors. The previous patch was
really intended for family 10h.

Thanks,
Scott