[coreboot] FW: Two test result(linux+2G-RAM>10minutes and install ubuntu8.10) of vx800 patch

JasonZhao at viatech.com.cn JasonZhao at viatech.com.cn
Thu Feb 5 04:33:02 CET 2009


My VX800 bug of "boot linux with 2G mem >10 minutes" has been proved to
be the problem of MTRR setting.  Thanks for Carldani, Rudolf and Bari.
1 The root cause is:
1) The free memory I report to coreboot through ram_resource is [0,
1983M=2G-64M(Framebuffer)-1M(TOP 1M SM Memory)].  If I report [0,
1984M=2G-64M(Framebuffer)], then all is OK.
2) The src/cpu/x86/mtrr.c setting result of [0,1983M] is: 
reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
reg04: base=0x78000000 (1920MB), size=  32MB: write-back, count=1
reg05: base=0x7a000000 (1952MB), size=  16MB: write-back, count=1
reg06: base=0x7b000000 (1968MB), size=   8MB: write-back, count=1
reg07: base=0x7b800000 (1976MB), size=   4MB: write-back, count=1
This setting make the last 3MB is uncached due to the lack of MTRR
registers. And It seems that the last 3MB is frequently used by linux
with kernel before(2.6.25.19), so the OS become slow.  However XP and
the linux with newest kernel (2.6.26.6-49.fc8) are not disturbed by the
uncache of last 3MB.

The mtrr.c setting of [0,1984M] is: 
reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
reg04: base=0x78000000 (1920MB), size=  64MB: write-back, count=1
all of memory area is cached, and all OS run at a good speed.




2 So we need improve mtrr.c to make it can treat with such
input[0,1983M].
The legacybios handle my [0,1983] like this 
 Cache [0,2048M]
 Unchace [1983M, 1984M] size=1M
 Uncache  [1984M,2048M] size =64M.
I guess the legacybios compare the number of '1' and '0' in 1983 to
decide how to use minimum number of MTRR.

Carldaniel, you said on irc that mtrr.c also have the ability like
legacybios(cache 2G,then uncache some area of 2G). But I didn't find any
logic like that in mtrr.c. 

3 And Stefan, your cx700 code will meet the same problem. Since the
cx700's northbridge.c report the memory size in the same way of
[0,xxxx-1M(TOP 1M SM Memory)].  The last 1M will also confuse the
mtrr.c.


-jasonzhao 

-----Original Message-----
From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] 
Sent: Saturday, January 24, 2009 7:53 PM
To: Jason Zhao
Cc: r.marek at assembler.cz
Subject: Re: [coreboot] Two test result(linux+2G-RAM>10minutes and
install ubuntu8.10) of vx800 patch

Hi Jason,

thanks for the dumps.

On 24.01.2009 08:08, JasonZhao at viatech.com.cn wrote:
> Carl and ruik:
> Here is some more result of acpidump, /proc/mtrr and /proc/meminfo.
> Some explanation of my memory using in coreboot:
> [topmem-64,tompmem] as framebuffer, 
> [topmem-64M-64k,topmem-64M] as coreboot-table (In
> tables.c:rom_table_start = (*mem_top) - 64*1024;).
>   

It is a bit strange that the DSDTs are identical for both memory
configurations. The following parts of the code are suspicious:
>             Method (_CRS, 0, NotSerialized)
>             {
>                 Name (BUF0, ResourceTemplate ()
>                 {
> [...]
>                     DWordMemory (ResourceProducer, PosDecode,
> MinFixed, MaxFixed, Cacheable, ReadWrite,
>                         0x00000000,         // Granularity
>                         0x80000000,         // Range Minimum
>                         0xBFFFFFFF,         // Range Maximum
>                         0x00000000,         // Translation Offset
>                         0x40000000,         // Length
>                         ,, _Y00, AddressRangeMemory, TypeStatic)
>                 })

That address range is always the same, even if you only have 512M
memory. Why? Will it cause problems if you have 3G memory?

And our MTRR setup is incomplete for the 2G case. The last 4 MB are
uncached because we run out of MTRR registers. That will cause an
extreme slowdown during boot.

I think the MTRR setup explains almost everything.

Regards,
Carl-Daniel

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





More information about the coreboot mailing list