On 05/21/2014 03:04 AM, James Hogan wrote:
On 20/05/14 15:47, Andreas Herrmann wrote:
From: David Daney <david.daney@xxxxxxxxxx>
These are needed to boot a generic mips64r2 kernel on OCTEONIII.
Signed-off-by: David Daney <david.daney@xxxxxxxxxx>
Signed-off-by: Andreas Herrmann <andreas.herrmann@xxxxxxxxxxxxxxxxxx>
---
arch/mips/include/asm/r4kcache.h | 2 ++
arch/mips/mm/c-r4k.c | 32 ++++++++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 1c74a6a..789ede9 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1094,6 +1110,21 @@ static void probe_pcache(void)
c->dcache.waybit = 0;
break;
+ case CPU_CAVIUM_OCTEON3:
+ /* For now lie about the number of ways. */
Is this to work around the finite length of way_string[]?
Can we fix that to be more dynamic instead? (admittedly special casing
"direct mapped" looks like a bit of a pain).
The OCTEON ICache is a weird size that is not (and I think cannot be)
represented by the CP0_Config* bits. However, it doesn't matter, as any
operation that attempts to invalidate any part of it, operates on the
entire cache, so everything works out in the end.
The DCache is fully coherent, so any invalidate/flush operations are
redundant.
So for both of these, we just need to supply values that are both
plausible, and don't result in panics and/or OOPS messages being printed.
Cheers
James
+ c->icache.linesz = 128;
+ c->icache.sets = 16;
+ c->icache.ways = 8;
+ c->icache.flags |= MIPS_CACHE_VTAG;
+ icache_size = c->icache.sets * c->icache.ways * c->icache.linesz;
+
+ c->dcache.linesz = 128;
+ c->dcache.ways = 8;
+ c->dcache.sets = 8;
+ dcache_size = c->dcache.sets * c->dcache.ways * c->dcache.linesz;
+ c->options |= MIPS_CPU_PREFETCH;
+ break;
+
