VIA C7 on BCom Winnet P680 - L1/L2 cache very slow

[Corey Osgood]

I'm working on fixing up the BCom WinNet P680 port, which is a Via C7 CPU
and CN700/VT8237R chipset. I've got it running enough to boot a Memtest86
payload, but it's very slow. The L1 and L2 cache are reported as running at
11-12MB/s by Memtest, which is much slower then they're reported as running
in the stock BIOS. This makes any further testing impractical, as it takes
ages load a kernel+initrd. Any suggestions on how to fix this, or where to
look?

Thanks,
Corey

[Corey Osgood]

After sending the last message, I've done a little more debugging and
dumped cr0, and also checked the C7 FCR, everything indicates the cache is
properly enabled and not in NoWriteThrough mode, although I have very
little C7 specific information and none of it relating to cache.

So, I'm now looking elsewhere, and at the moment I'm looking at MTRRs. All
the fixed MTRRs, under coreboot, are 0'd out, and variable are all type 6
(WB?), as can be seen in the attached boot log. Here's the way the stock
BIOS sets them up:

# IA32_MTRR_FIX64K_00000 0x00000250 = 0x0606060606060606
# IA32_MTRR_FIX16K_80000 0x00000258 = 0x0606060606060606
# IA32_MTRR_FIX16K_A0000 0x00000259 = 0x0000000000000000
# IA32_MTRR_FIX4K_C0000 0x00000268 = 0x0505050505050505
# IA32_MTRR_FIX4K_C8000 0x00000269 = 0x0000000505050505
# IA32_MTRR_FIX4K_D0000 0x0000026a = 0x0000000000000000
# IA32_MTRR_FIX4K_D8000 0x0000026b = 0x0000000000000000
# IA32_MTRR_FIX4K_E0000 0x0000026c = 0x0000000000000000
# IA32_MTRR_FIX4K_E8000 0x0000026d = 0x0000000000000000
# IA32_MTRR_FIX4K_F0000 0x0000026e = 0x0404040404040404
# IA32_MTRR_FIX4K_F8000 0x0000026f = 0x0404040404040400
***@khan:~/coreboot/util/msrtool# cat
/proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1:
write-back
reg01: base=0x03e000000 ( 992MB), size= 32MB, count=1:
uncachable
reg02: base=0x0f8000000 ( 3968MB), size= 32MB, count=2:
write-combining
reg03: base=0x03df00000 ( 991MB), size= 1MB, count=1:
uncachable
reg04: base=0x0f4000000 ( 3904MB), size= 32MB, count=1: write-combining

I'm frankly not sure if I'm on the right track or not, I've done some work
porting chipsets but very little with the CPU itself. Any help would be
greatly appreciated, I was hoping this project was "just" writing IRQ and
ACPI tables.

Thanks,
Corey

Post by Corey Osgood
I'm working on fixing up the BCom WinNet P680 port, which is a Via C7 CPU
and CN700/VT8237R chipset. I've got it running enough to boot a Memtest86
payload, but it's very slow. The L1 and L2 cache are reported as running at
11-12MB/s by Memtest, which is much slower then they're reported as running
in the stock BIOS. This makes any further testing impractical, as it takes
ages load a kernel+initrd. Any suggestions on how to fix this, or where to
look?
Thanks,
Corey

[Aaron Durbin]

After sending the last message, I've done a little more debugging and dumped
cr0, and also checked the C7 FCR, everything indicates the cache is properly
enabled and not in NoWriteThrough mode, although I have very little C7
specific information and none of it relating to cache.
So, I'm now looking elsewhere, and at the moment I'm looking at MTRRs. All
the fixed MTRRs, under coreboot, are 0'd out, and variable are all type 6
(WB?), as can be seen in the attached boot log. Here's the way the stock

MTRR: Physical address space:
0x0000000000000000 - 0x0000000004000000 size 0x04000000 type 0
0x0000000004000000 - 0x000000003e000000 size 0x3a000000 type 6
0x000000003e000000 - 0x00000000fff80000 size 0xc1f80000 type 0
0x00000000fff80000 - 0x0000000100000000 size 0x00080000 type 5

0->64MiB is uncacheable
64MiB->992MiB is cacheable
992MiB-> -512KiB is uncacheable
-512KiB->4GiB is write-protect

The fixed MTRRs cover the first 1MiB so it's not surprising those are
zero'd out. The only odd thing I see in the variable MTRRs is the ROM
not being marked as WP, but I suspect that is from CONFIG_CACHE_ROM
not being enabled.

Looking through your resources I don't see anything that covers memory
during read resources (flags field):
#define IORESOURCE_MEM 0x00000200
#define IORESOURCE_CACHEABLE 0x00004000

Any flags with the bits 0x4200 should be cacheable memory.

DOMAIN: 0000 resource base c0000 size 3df40000 align 0 gran 0 limit 0
flags e0004200 index b

The above shows up ding assign resources. The MTRR code has a 64MiB
min alignment which makes me think that is where the 64MiB->992MiB
comes from.

I would do two things:

1. Add all ram resources during the read_resources() step. That way
the IO hole can be properly picked.
2. Ensure all the memory you know exist are added to the resource
list, including 0 -> 64MiB.

Hope that helps.

-Aaron

[Corey Osgood]

Thanks, I'll give it a shot!

Thanks,
Corey