[LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based)
Corey Osgood
corey.osgood at gmail.com
Sat Sep 1 05:55:48 CEST 2007
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 <davej at redhat.com>.
>
> 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
More information about the coreboot
mailing list