[LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based)

[Uwe Hermann]

Hi,

here's an initial patch for the MSI MS-6178 mainboard.

It boots up to a login prompt, but there are a number of issues
which need to be fixed before we can call this fully supported.

I'll post a list of working and non-working parts later, need to do more
tests...

One major issue is that the booting (and operation afterwards) is _really_
slow, a full boot takes more than 10 or 20 minutes!
I suspect RAM init problems or cache (L1/L2) problems, but I haven't yet
found out what's really going on.

Full boot log of LinuxBIOS + the original BIOS attached.

I guess (from looking at the boot log diffs) that this may be the reason
for the slow boot, but how do I fix it?

CPU: L1 I cache: 16K, L1 D cache: 16K
  -CPU: L2 cache: 128K

(i.e., it seems the L2 cache is never enabled when using LinuxBIOS)

Here's the SPD dump of the RAM I used (64 MB in slot 0):

00: 80 08 04 0c 09 01 40 00 01 a0 60 00 80 08 00 01
10: 8f 04 07 01 01 00 0f f0 70 00 00 1e 14 1e 32 10
20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 6a
40: 00 00 00 00 00 00 00 00 00 42 50 42 36 37 38 31
50: 41 00 00 00 00 00 00 00 00 00 00 00 00 29 62 00
60: 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff 64 04
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff fe ff ff ff ff ff ff ff ff fe ff

$ lspci -nn (from vendor BIOS)

00:00.0 Host bridge [0600]: Intel Corporation 82810 GMCH [Graphics Memory Controller Hub] [8086:7120] (rev 03)
00:01.0 VGA compatible controller [0300]: Intel Corporation 82810 CGC [Chipset Graphics Controller] [8086:7121] (rev 03)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801AB PCI Bridge [8086:2428] (rev 01)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801AB ISA Bridge (LPC) [8086:2420] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801AB IDE [8086:2421] (rev 01)
00:1f.2 USB Controller [0c03]: Intel Corporation 82801AB USB [8086:2422] (rev 01)
00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801AB AC'97 Audio [8086:2425] (rev 01)
00:1f.6 Modem [0703]: Intel Corporation 82801AB AC'97 Modem [8086:2426] (rev 01)
01:00.0 VGA compatible controller [0300]: S3 Inc. 86c325 [ViRGE] [5333:5631] (rev 06)
01:01.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8029(AS) [10ec:8029]

$ lspci -xxx

00:00.0 Host bridge: Intel Corporation 82810 GMCH [Graphics Memory Controller Hub] (rev 03)
00: 86 80 20 71 06 00 80 20 03 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 20 71
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 68 51 a0 3c 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 9a dd 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00

Uwe.

[LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based)

[Corey Osgood]

Uwe Hermann wrote:
> Hi,
>
> here's an initial patch for the MSI MS-6178 mainboard.

Looks like a good start (see comments below)

Acked-by: Corey Osgood
> It boots up to a login prompt, but there are a number of issues
> which need to be fixed before we can call this fully supported.
>
> I'll post a list of working and non-working parts later, need to do more
> tests...
>
> One major issue is that the booting (and operation afterwards) is _really_
> slow, a full boot takes more than 10 or 20 minutes!
> I suspect RAM init problems or cache (L1/L2) problems, but I haven't yet
> found out what's really going on.
>
> Full boot log of LinuxBIOS + the original BIOS attached.
>
> I guess (from looking at the boot log diffs) that this may be the reason
> for the slow boot, but how do I fix it?
>
> CPU: L1 I cache: 16K, L1 D cache: 16K
>   -CPU: L2 cache: 128K
>
> (i.e., it seems the L2 cache is never enabled when using LinuxBIOS)

Is your cpu id in model_6xx_init.c? I'm not seeing any attempt even at
cpu init in the LB boot log, and IIRC there should be something printed.
And if I'm reading the kernel boot log right, your model ID is 0x06a5,
which isn't currently in there and not added by your patch. I'll fire up
the mew-vm tomorrow and see if it has the same problem, the boot on that
board is slow but not that slow, I figured it was just my old 400MHz
celeron running over a serial connection.
> Here's the SPD dump of the RAM I used (64 MB in slot 0):
>
> 00: 80 08 04 0c 09 01 40 00 01 a0 60 00 80 08 00 01
> 10: 8f 04 07 01 01 00 0f f0 70 00 00 1e 14 1e 32 10
> 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 6a
> 40: 00 00 00 00 00 00 00 00 00 42 50 42 36 37 38 31
> 50: 41 00 00 00 00 00 00 00 00 00 00 00 00 29 62 00
> 60: 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff
> 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff 64 04
> 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> f0: ff ff ff ff ff fe ff ff ff ff ff ff ff ff fe ff
>
> $ lspci -nn (from vendor BIOS)
>
> 00:00.0 Host bridge [0600]: Intel Corporation 82810 GMCH [Graphics Memory Controller Hub] [8086:7120] (rev 03)
> 00:01.0 VGA compatible controller [0300]: Intel Corporation 82810 CGC [Chipset Graphics Controller] [8086:7121] (rev 03)
> 00:1e.0 PCI bridge [0604]: Intel Corporation 82801AB PCI Bridge [8086:2428] (rev 01)
> 00:1f.0 ISA bridge [0601]: Intel Corporation 82801AB ISA Bridge (LPC) [8086:2420] (rev 01)
> 00:1f.1 IDE interface [0101]: Intel Corporation 82801AB IDE [8086:2421] (rev 01)
> 00:1f.2 USB Controller [0c03]: Intel Corporation 82801AB USB [8086:2422] (rev 01)
> 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801AB AC'97 Audio [8086:2425] (rev 01)
> 00:1f.6 Modem [0703]: Intel Corporation 82801AB AC'97 Modem [8086:2426] (rev 01)
> 01:00.0 VGA compatible controller [0300]: S3 Inc. 86c325 [ViRGE] [5333:5631] (rev 06)
> 01:01.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8029(AS) [10ec:8029]
>
> $ lspci -xxx
>
> 00:00.0 Host bridge: Intel Corporation 82810 GMCH [Graphics Memory Controller Hub] (rev 03)
> 00: 86 80 20 71 06 00 80 20 03 00 00 06 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 20 71
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 68 51 a0 3c 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 9a dd 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
>
> Uwe.

Can you send lspci -xxx from linuxbios? I really can't see anything too
alarming in the boot logs, although I could be overlooking it. Can you
also try memtest86?

-Corey

[LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based)

[Uwe Hermann]

On Thu, Aug 30, 2007 at 11:43:41PM -0400, Corey Osgood wrote:
> > I guess (from looking at the boot log diffs) that this may be the reason
> > for the slow boot, but how do I fix it?
> >
> > CPU: L1 I cache: 16K, L1 D cache: 16K
> >   -CPU: L2 cache: 128K
> >
> > (i.e., it seems the L2 cache is never enabled when using LinuxBIOS)
>
> Is your cpu id in model_6xx_init.c? I'm not seeing any attempt even at
> cpu init in the LB boot log, and IIRC there should be something printed.
> And if I'm reading the kernel boot log right, your model ID is 0x06a5,
> which isn't currently in there and not added by your patch. I'll fire up
> the mew-vm tomorrow and see if it has the same problem, the boot on that
> board is slow but not that slow, I figured it was just my old 400MHz
> celeron running over a serial connection.

I checked that, but it looks correct to me. If I'm not mistaken I have
a 0x0665 (Mendocino), but maybe I got the format of those IDs wrong?

See CPU info below:

$ proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 6
model name	: Celeron (Mendocino)
stepping	: 5
cpu MHz		: 434.356
cache size	: 128 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr up
bogomips	: 869.78
clflush size	: 32

$ cpuid
 eax in    eax      ebx      ecx      edx
00000000 00000002 756e6547 6c65746e 49656e69
00000001 00000665 00000000 00000000 0183f9ff
00000002 03020101 00000000 00000000 0c040841

Vendor ID: "GenuineIntel"; CPUID level 2

Intel-specific functions:
Version 00000665:
Type 0 - Original OEM
Family 6 - Pentium Pro
Model 6 - Celeron
Stepping 5
Reserved 0

Feature flags 0183f9ff:
FPU    Floating Point Unit
VME    Virtual 8086 Mode Enhancements
DE     Debugging Extensions
PSE    Page Size Extensions
TSC    Time Stamp Counter
MSR    Model Specific Registers
PAE    Physical Address Extension
MCE    Machine Check Exception
CX8    COMPXCHG8B Instruction
SEP    Fast System Call
MTRR   Memory Type Range Registers
PGE    PTE Global Flag
MCA    Machine Check Architecture
CMOV   Conditional Move and Compare Instructions
FGPAT  Page Attribute Table
PSE-36 36-bit Page Size Extension
MMX    MMX instruction set
FXSR   Fast FP/MMX Streaming SIMD Extensions save/restore

TLB and cache info:
01: Instruction TLB: 4KB pages, 4-way set assoc, 32 entries
02: Instruction TLB: 4MB pages, 4-way set assoc, 2 entries
03: Data TLB: 4KB pages, 4-way set assoc, 64 entries
41: 2nd-level cache: 128KB, 4-way set assoc, 32 byte line size
08: 1st-level instruction cache: 16KB, 4-way set assoc, 32 byte line size
04: Data TLB: 4MB pages, 4-way set assoc, 8 entries
0c: 1st-level data cache: 16KB, 4-way set assoc, 32 byte line size

$ x86info -a
x86info v1.20.  Dave Jones 2001-2006
Feedback to .

Found 1 CPU
--------------------------------------------------------------------------
eax in: 0x00000000, eax = 00000002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69
eax in: 0x00000001, eax = 00000665 ebx = 00000000 ecx = 00000000 edx = 0183f9ff
eax in: 0x00000002, eax = 03020101 ebx = 00000000 ecx = 00000000 edx = 0c040841

Family: 6 Model: 6 Stepping: 5 Type: 0 Brand: 0
CPU Model: Celeron (Mendocino) Original OEM
Feature flags:
 fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr

Cache info
 L1 Instruction cache: 16KB, 4-way associative. 32 byte line size.
 L1 Data cache: 16KB, 4-way associative. 32 byte line size.
 L2 unified cache: 128KB, 4-way associative. 32 byte line size.
TLB info
 Instruction TLB: 4KB pages, 4-way associative, 32 entries
 Instruction TLB: 4MB pages, fully associative, 2 entries
 Data TLB: 4KB pages, 4-way associative, 64 entries
 Data TLB: 4MB pages, 4-way associative, 8 entries
 (null)
Connector type: Socket 370  (370 Pin PGA)

MTRR registers:
MTRRcap (0xfe): MTRRphysBase0 (0x200): MTRRphysMask0 (0x201): MTRRphysBase1 (0x202): MTRRphysMask1 (0x203): MTRRphysBase2 (0x204): MTRRphysMask2 (0x205): MTRRphysBase3 (0x206): MTRRphysMask3 (0x207): MTRRphysBase4 (0x208): MTRRphysMask4 (0x209): MTRRphysBase5 (0x20a): MTRRphysMask5 (0x20b): MTRRphysBase6 (0x20c): MTRRphysMask6 (0x20d): MTRRphysBase7 (0x20e): MTRRphysMask7 (0x20f): MTRRfix64K_00000 (0x250): MTRRfix16K_80000 (0x258): MTRRfix16K_A0000 (0x259): MTRRfix4K_C8000 (0x269): MTRRfix4K_D0000 0x26a: MTRRfix4K_D8000 0x26b: MTRRfix4K_E0000 0x26c: MTRRfix4K_E8000 0x26d: MTRRfix4K_F0000 0x26e: MTRRfix4K_F8000 0x26f: MTRRdefType (0x2ff):

450MHz processor (estimate).
> > $ lspci -xxx
> >
> > 00:00.0 Host bridge: Intel Corporation 82810 GMCH [Graphics Memory Controller Hub] (rev 03)
> > 00: 86 80 20 71 06 00 80 20 03 00 00 06 00 00 00 00
> > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 20 71
> > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 50: 68 51 a0 3c 00 00 00 00 00 00 00 00 00 00 00 00
> > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 70: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 80: c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 90: 00 00 9a dd 00 00 00 00 00 00 00 00 00 00 00 00
> > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
>
> Can you send lspci -xxx from linuxbios? I really can't see anything too
> alarming in the boot logs, although I could be overlooking it.

Sure.

00: 86 80 20 71 06 01 80 20 03 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 60 ff 0a 20 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 da 77 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00

I already tried playing a bit with the northbridge
registers and RAM init (GMCHCFG, DRAMT, BUFF_SC etc.)
but that doesn't seem to have much influence.
> Can you also try memtest86?

I already did, and it works, it's just very slow.

* Memtest86 with vendor BIOS:
  229 MB/s, L1: 4256 MB/s, L2: 1116 MB/s

* Memtest with LinuxBIOS:
  16 MB/s, L1: 16 MB/s, L2: off (?)

Uwe.

[LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based)

[popkonserve]

> 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
>
> 00: 86 80 20 71 06 01 80 20 03 00 00 06 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 60 ff 0a 20 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 da 77 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00

- the refresh (offset 53h) should be 15,6µs instead of 7,8µs which
should only be used for high density rams (>256MB)
- CL, SRCD and SRP (offset 53h) are unconfigured. either read them from
the spd or configure them by performing read/write tests
- the onboard vga (offset 70h) is left unconfigured and thus disabling it
- MISCC2 (offset 80h) is left unconfigured. the datasheet says for some
bits: Do NOT program to 0.

regarding the L2 cache on the cpu read the following:

page 7:
http://www.cs.inf.ethz.ch/stricker/lab/doc/intel-part4.pdf

line 473ff
http://fxr.watson.org/fxr/source/i386/i386/initcpu.c?v=RELENG4

Holger

[LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based)

[Corey Osgood]

popkonserve wrote:
> > 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
> >
> > 00: 86 80 20 71 06 01 80 20 03 00 00 06 00 00 00 00
> > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 50: 60 ff 0a 20 00 00 00 00 00 00 00 00 00 00 00 00
> > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 90: 00 00 da 77 00 00 00 00 00 00 00 00 00 00 00 00
> > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
> the refresh (offset 53h) should be 15,6µs instead of 7,8µs which
>
> should only be used for high density rams (>256MB)

No, 0x20 is correct, bit 5 is the only bit flipped.
> CL, SRCD and SRP (offset 53h) are unconfigured. either read them from
>
> the spd or configure them by performing read/write tests

No, they're configured to the slowest and safest possible timings. I
haven't gotten to optimizing it yet.
> the onboard vga (offset 70h) is left unconfigured and thus disabling it

But there are some commented lines of code to enable vga. I just never
got to messing around with it.
> MISCC2 (offset 80h) is left unconfigured. the datasheet says for some
>
> bits: Do NOT program to 0.

MISCC2 is for VGA. See above.
> regarding the L2 cache on the cpu read the following:
>
> page 7:
> http://www.cs.inf.ethz.ch/stricker/lab/doc/intel-part4.pdf
>
> line 473ff
> http://fxr.watson.org/fxr/source/i386/i386/initcpu.c?v=RELENG4
>
> Holger

I'll look into these later, but I suspect x86_enable_cache() does
something similar.

-Corey

[LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based)

[popkonserve]

> > the refresh (offset 53h) should be 15,6µs instead of 7,8µs which
> >
> > should only be used for high density rams (>256MB)
>
> No, 0x20 is correct, bit 5 is the only bit flipped.

oops, sorry, you are right...
> > CL, SRCD and SRP (offset 53h) are unconfigured. either read them from
> >
> > the spd or configure them by performing read/write tests
>
> No, they're configured to the slowest and safest possible timings. I
> haven't gotten to optimizing it yet.

yeah, that's what i thought, too. but if you're able to read the values 
from the spd it should be no problem setting them!?
> > page 7:
> > http://www.cs.inf.ethz.ch/stricker/lab/doc/intel-part4.pdf
> >
> > line 473ff
> > http://fxr.watson.org/fxr/source/i386/i386/initcpu.c?v=RELENG4
>
> I'll look into these later, but I suspect x86_enable_cache() does
> something similar.

hmm, no. actually x86_enable_cache() just emits a post code, prints some 
info and calls enable_cache() which is an inline in cache.h which just 
enables L1 cache by flipping a bit in the processor configuration 
register 0 (CR0). that's all.
it should be renamed to enable_L1_cache() to avoid confusion.
the L2 cache can not be enabled in CR0. just take a look at the code and 
you'll see.
Holger

[LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based)

[Corey Osgood]

Uwe Hermann wrote:
> On Thu, Aug 30, 2007 at 11:43:41PM -0400, Corey Osgood wrote:
> > > I guess (from looking at the boot log diffs) that this may be the reason
> > > for the slow boot, but how do I fix it?
> > >
> > > CPU: L1 I cache: 16K, L1 D cache: 16K
> > >   -CPU: L2 cache: 128K
> > >
> > > (i.e., it seems the L2 cache is never enabled when using LinuxBIOS)
> >
> > Is your cpu id in model_6xx_init.c? I'm not seeing any attempt even at
> > cpu init in the LB boot log, and IIRC there should be something printed.
> > And if I'm reading the kernel boot log right, your model ID is 0x06a5,
> > which isn't currently in there and not added by your patch. I'll fire up
> > the mew-vm tomorrow and see if it has the same problem, the boot on that
> > board is slow but not that slow, I figured it was just my old 400MHz
> > celeron running over a serial connection.
>
> I checked that, but it looks correct to me. If I'm not mistaken I have
> a 0x0665 (Mendocino), but maybe I got the format of those IDs wrong?
>
> See CPU info below:
>
> $ proc/cpuinfo
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 6
> model name	: Celeron (Mendocino)
> stepping	: 5
> cpu MHz		: 434.356
> cache size	: 128 KB
> fdiv_bug	: no
> hlt_bug		: no
> f00f_bug	: no
> coma_bug	: no
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 2
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr up
> bogomips	: 869.78
> clflush size	: 32
>
> $ cpuid
>  eax in    eax      ebx      ecx      edx
> 00000000 00000002 756e6547 6c65746e 49656e69
> 00000001 00000665 00000000 00000000 0183f9ff
> 00000002 03020101 00000000 00000000 0c040841
>
> Vendor ID: "GenuineIntel"; CPUID level 2
>
> Intel-specific functions:
> Version 00000665:
> Type 0 - Original OEM
> Family 6 - Pentium Pro
> Model 6 - Celeron
> Stepping 5
> Reserved 0
>
> Feature flags 0183f9ff:
> FPU    Floating Point Unit
> VME    Virtual 8086 Mode Enhancements
> DE     Debugging Extensions
> PSE    Page Size Extensions
> TSC    Time Stamp Counter
> MSR    Model Specific Registers
> PAE    Physical Address Extension
> MCE    Machine Check Exception
> CX8    COMPXCHG8B Instruction
> SEP    Fast System Call
> MTRR   Memory Type Range Registers
> PGE    PTE Global Flag
> MCA    Machine Check Architecture
> CMOV   Conditional Move and Compare Instructions
> FGPAT  Page Attribute Table
> PSE-36 36-bit Page Size Extension
> MMX    MMX instruction set
> FXSR   Fast FP/MMX Streaming SIMD Extensions save/restore
>
> TLB and cache info:
> 01: Instruction TLB: 4KB pages, 4-way set assoc, 32 entries
> 02: Instruction TLB: 4MB pages, 4-way set assoc, 2 entries
> 03: Data TLB: 4KB pages, 4-way set assoc, 64 entries
> 41: 2nd-level cache: 128KB, 4-way set assoc, 32 byte line size
> 08: 1st-level instruction cache: 16KB, 4-way set assoc, 32 byte line size
> 04: Data TLB: 4MB pages, 4-way set assoc, 8 entries
> 0c: 1st-level data cache: 16KB, 4-way set assoc, 32 byte line size
>
> $ x86info -a
> x86info v1.20.  Dave Jones 2001-2006
> Feedback to .
> Found 1 CPU
>
> eax in: 0x00000000, eax = 00000002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69
> eax in: 0x00000001, eax = 00000665 ebx = 00000000 ecx = 00000000 edx = 0183f9ff
> eax in: 0x00000002, eax = 03020101 ebx = 00000000 ecx = 00000000 edx = 0c040841
>
> Family: 6 Model: 6 Stepping: 5 Type: 0 Brand: 0
> CPU Model: Celeron (Mendocino) Original OEM
> Feature flags:
>  fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr
>
> Cache info
>  L1 Instruction cache: 16KB, 4-way associative. 32 byte line size.
>  L1 Data cache: 16KB, 4-way associative. 32 byte line size.
>  L2 unified cache: 128KB, 4-way associative. 32 byte line size.
> TLB info
>  Instruction TLB: 4KB pages, 4-way associative, 32 entries
>  Instruction TLB: 4MB pages, fully associative, 2 entries
>  Data TLB: 4KB pages, 4-way associative, 64 entries
>  Data TLB: 4MB pages, 4-way associative, 8 entries
>  (null)
> Connector type: Socket 370  (370 Pin PGA)
>
> MTRR registers:
> MTRRcap (0xfe): MTRRphysBase0 (0x200): MTRRphysMask0 (0x201): MTRRphysBase1 (0x202): MTRRphysMask1 (0x203): MTRRphysBase2 (0x204): MTRRphysMask2 (0x205): MTRRphysBase3 (0x206): MTRRphysMask3 (0x207): MTRRphysBase4 (0x208): MTRRphysMask4 (0x209): MTRRphysBase5 (0x20a): MTRRphysMask5 (0x20b): MTRRphysBase6 (0x20c): MTRRphysMask6 (0x20d): MTRRphysBase7 (0x20e): MTRRphysMask7 (0x20f): MTRRfix64K_00000 (0x250): MTRRfix16K_80000 (0x258): MTRRfix16K_A0000 (0x259): MTRRfix4K_C8000 (0x269): MTRRfix4K_D0000 0x26a: MTRRfix4K_D8000 0x26b: MTRRfix4K_E0000 0x26c: MTRRfix4K_E8000 0x26d: MTRRfix4K_F0000 0x26e: MTRRfix4K_F8000 0x26f: MTRRdefType (0x2ff):
>
> 450MHz processor (estimate).
> > > $ lspci -xxx
> > >
> > > 00:00.0 Host bridge: Intel Corporation 82810 GMCH [Graphics Memory Controller Hub] (rev 03)
> > > 00: 86 80 20 71 06 00 80 20 03 00 00 06 00 00 00 00
> > > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 20 71
> > > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 50: 68 51 a0 3c 00 00 00 00 00 00 00 00 00 00 00 00
> > > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 70: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 80: c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 90: 00 00 9a dd 00 00 00 00 00 00 00 00 00 00 00 00
> > > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
> >
> > Can you send lspci -xxx from linuxbios? I really can't see anything too
> > alarming in the boot logs, although I could be overlooking it.
>
> Sure.
>
> 00: 86 80 20 71 06 01 80 20 03 00 00 06 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 60 ff 0a 20 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 da 77 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
>
> I already tried playing a bit with the northbridge
> registers and RAM init (GMCHCFG, DRAMT, BUFF_SC etc.)
> but that doesn't seem to have much influence.

I think it's BUFF_SC, can you use the factory value for this? It's 0x92
btw, so you don't have to look it up. I used a single sided 128mb stick
to get that value, and then tested it with about 5 other similar sticks,
only 1 passed ram_check but hung while copying LB.

And just realized something else, directly related to the email I just
sent for Joe. Please change the MRS value from 0x1d0 to 0xad0. Heh, that
could seriously bork things up, my bad.
> > Can you also try memtest86?
>
> I already did, and it works, it's just very slow.
>
> Memtest86 with vendor BIOS:
> 229 MB/s, L1: 4256 MB/s, L2: 1116 MB/s
>
> Memtest with LinuxBIOS:
> 16 MB/s, L1: 16 MB/s, L2: off (?)

Eww, you weren't kidding. Hopefully the above will take care of the mem
issue, not sure about the L2 cache still. Can you put a printk into
model_6xx_init so you can see if it's actually running or not? I'll fire
up the mem-vm tomorrow, I've got a new bios savior to try on it anyways.

-Corey

[LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based)

[Uwe Hermann]

On Thu, Aug 30, 2007 at 11:43:41PM -0400, Corey Osgood wrote:
> > here's an initial patch for the MSI MS-6178 mainboard.
>
> Looks like a good start (see comments below)
>
> Acked-by: Corey Osgood

Thanks, committed for now in r2771, but it'll need some fixes; will send
extra patches for that.

Uwe.