summaryrefslogtreecommitdiffstats
path: root/sys/sparc64/include
diff options
context:
space:
mode:
authormarius <marius@FreeBSD.org>2010-03-17 22:45:09 +0000
committermarius <marius@FreeBSD.org>2010-03-17 22:45:09 +0000
commit0c9a31ed99969559c9216a0483e3889f0754a214 (patch)
tree51cfb44249862c0c2201547f19acd8021f64e13a /sys/sparc64/include
parent8134df93ab5aaa8c61ff3601020377e085cf167c (diff)
downloadFreeBSD-src-0c9a31ed99969559c9216a0483e3889f0754a214.zip
FreeBSD-src-0c9a31ed99969559c9216a0483e3889f0754a214.tar.gz
o Add support for UltraSparc-IV+:
- Swap the configuration of the first and second large dTLB as with US-IV+ these can only hold entries of certain page sizes each, which we happened to chose the non-working way around. - Additionally ensure that the large iTLB is set up to hold 8k pages (currently this happens to be a NOP though). - Add a workaround for US-IV+ erratum #2. - Turn off dTLB parity error reporting as otherwise we get seemingly false positives when copying in the user window by simulating a fill trap on return to usermode. Given that these parity errors can be avoided by disabling multi issue mode and the problem could be reproduced with a second machine this appears to be a silicon bug of some sort. - Add a membar #Sync also before the stores to ASI_DCACHE_TAG. While at it, turn of interrupts across the whole cheetah_cache_flush() for simplicity instead of around every flush. This should have next to no impact as for cheetah-class machines we typically only need to flush the caches a few times during boot when recovering from peeking/poking non-existent PCI devices, if at all. - Just use KERNBASE for FLUSH as we also do elsewhere as the US-IV+ documentation doesn't seem to mention that these CPUs also ignore the address like previous cheetah-class CPUs do. Again the code changing LSU_IC is executed seldom enough that the negligible optimization of using %g0 instead should have no real impact. With these changes FreeBSD runs stable on V890 equipped with US-IV+ and -j128 buildworlds in a loop for days are no problem. Unfortunately, the performance isn't were it should be as a buildworld on a 4x1.5GHz US-IV+ V890 takes nearly 3h while on a V440 with (theoretically) less powerfull 4x1.5GHz US-IIIi it takes just over 1h. It's unclear whether this is related to the supposed silicon bug mentioned above or due to another issue. The documentation (which contains a sever bug in the description of the bits added to the context registers though) at least doesn't mention any requirements for changes in the CPU handling besides those implemented and the cache as well as the TLB configurations and handling look fine. o Re-arrange cheetah_init() so it's easier to add support for SPARC64 V up to VIIIfx CPUs, which only require parts of this initialization.
Diffstat (limited to 'sys/sparc64/include')
-rw-r--r--sys/sparc64/include/dcr.h4
1 files changed, 4 insertions, 0 deletions
diff --git a/sys/sparc64/include/dcr.h b/sys/sparc64/include/dcr.h
index a885d05..b1f993a 100644
--- a/sys/sparc64/include/dcr.h
+++ b/sys/sparc64/include/dcr.h
@@ -57,6 +57,10 @@
#define DCR_BPM_BITS 2
#define DCR_BPM_MASK \
(((1UL << DCR_BPM_BITS) - 1) << DCR_BPM_SHIFT)
+#define DCR_BPM_1HIST_GSHARE (0UL << DCR_BPM_SHIFT)
+#define DCR_BPM_2HIST_GSHARE (1UL << DCR_BPM_SHIFT)
+#define DCR_BPM_PC (2UL << DCR_BPM_SHIFT)
+#define DCR_BPM_2HIST_MIXED (3UL << DCR_BPM_SHIFT)
#define DCR_JPE (1UL << 15)
#define DCR_ITPE (1UL << 16)
OpenPOWER on IntegriCloud