Here are the results of some tests I ran
on my mpc860t (XPC860TZP50B5 / 3J21M).
I use mpc8bug on a FADS board to load motorola's
'init860.S' example. The example was slightly
modified to include (1-4 use differend EAs, of
course).
1) a 1:1 TLB to DRAM, R/W access (already present
in the vanilla code)
2) a TLB to map DRAM r/w, caching inhibited
3) a TLB to map DRAM r/o (behavior is the same
if for a 'real RO' mapping and for a RW
mapping with the 'CHANGE' bit cleared).
4) a TLB to map DRAM r/w but with the VALID
bit clear.
5) a 'main' routine which executes the
instructions under test through one
of the aforementioned TLB mappings.
Here's what I found (I generally load bogus
values into MD_EPN/DAR prior to executing any
of the cache instructions under test)
A) All of dcbf, dcbi, dcbst, dcbz (dcbt and dcbtst
should not and do not) raise a TLBMiss exception
with MD_EPN set correctly but failing to set DAR
(i.e. DAR is left unmodified) when trying to
access an address not in any of the TLBs.
B) All of dcbf, dcbi, dcbst, dcbz raise a TLBError
exception when accessing mapping 4) [as they should].
Unlike regular loads/stores (non-cache instructions),
DAR is NOT SET, however (i.e. left unmodified).
MD_EPN is set to 0x00000000 which does NOT point to
the faulting EA.
C) dcbi and dcbz behave like B) when accessing
through 3) [RO mapping]. Note that dcbf and
dcbst are treated like 'loads' and hence do
not raise a TLBError due to protection violation
(in accordance with the docs).
D) dcbz through a cache inhibited mapping (2)) does
not generate an alignment exception but
transparently clears the memory (either is allowed
according to the PPC specs).
Note: dcbt/dcbtst were included in all of the
tests but they never raise an exception which is
the correct behavior.
CONCLUSION:
- the only correct workaround for TLBError
is the one I suggested earlier: TLBError
handler has to inspect the faulting opcode
and fixup DAR and MD_EPN based on the GPR
values if the faulting instruction is any
of dcbf, dcbi, dcbst or dcbz.
Performance of this solution could be
improved (eliminate opcode-check in the
vast majority of the cases) by storing
a 'tag' value in DAR.
- the aforementioned workaround also could handle
TLBMiss - although performance is more of an issue
there.
Alternatives are
a) Jocke's workaround: copy MD_EPN -> DAR
(disadvantage: DAR truncated to page
boundary).
b) like a) but do this only if the faulting
instruction is any dcbxx (disadvantage:
performance loss).
c) merge significant bits of MD_EPN into
DAR. Thus, only cache instructions suffer
from an incorrect page offset in DAR.
At the same time, it's cheap.
Based on the analysis, I'd suggest to implement
the 'fixup' workaround for TLBError and alternative
c) for TLBMiss
-- Till
PS. due to unclear re-distribution terms of init860.S,
I refrain from appending it to this message. Send me
email for details about the test software.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
