In our C6678 application (using BIOS), we will use the CorePAC XMC MPAX segment registers (SPRUGW0B Chapter 7, XMC) to divide MSMC memory into some code and read-only data blocks, etc, where read/write/execute access may be restricted.
I have written the XMC code to restrict access, and can see that a read attempt to an unreadable area returns all zeros (instead of the true memory contents), as expected.
But I’m wondering how the access exception is reported from a hardware point of view (and perhaps whether BIOS can be configured to handle this automatically).
So far, I see the following CSL functions and associated macros (from csl_xmc.h, csl_xmcAux.h, and cslr_xmc.h) could help me:
CSL_XMC_getFaultAddress()
CSL_XMC_getFaultStatus()
CSL_XMC_clearFault()
But it’s not clear what hardware exception reports the XMC protection fault. In SPRUGW0B Chapter 9 (Interrupt Controller) Table 9-2 System Event Mapping I see a list of events and their numbers. There are events listed for protection faults in L1P, L1D,, L2, and EMC but no mention of XMC DSP memory protection fault, although there is a mysterious “SYS” fault (event 119).
If I knew the event number for an XMC protection fault I could presumably register for that exception, and then call the above CSL_XMC fault functions to get the fault address and status.
Also, I wonder at what time a memory protection fault is reported if the CPU writes to cached MSMC data in L1D that is supposed to be read-only. We are using L1D and L1P purely as cache. How would the L1D controller know that the data was supposed to be read-only in MSMC? If it only finds out (much later) when the cache line is evicted, then the fault reporting would happen long after the event that caused it. Does the L1D controller have some kind of back door access to the XMC MPAX segment registers to allow prompt reporting?
Also (although this is a BIOS question not a C6678 question), I wonder if BIOS can handle all of the above for us?
Regards, Jonathan