• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 645 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM48L952: Protecting the system registers

Jarkko Silvasti
Expert 1395 points
Part Number: RM48L952


Hi,

We have a need to protect multiple locations from USR mode writing. Since MPU has only limited amount of regions (and limited 2-power configuration) and OS itself takes already quite many we would like to spare those as much as possible for application code&ram protection and use other protection mechanism if possible for "CPU registers".

I have read this thread (and some others) and TRM chapter 2.3.2.5: https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/347425/1216363

I know that I can protect PS and PCS chip selects by using registers from PCR module. This practically covers all our regular peripheral needs, since we do not need protection to EMIF & ethernet and this allows also to leave some peripherals under direct USR mode operations (just need to notice that some registers may be protected by default from usr write).

- This PCR protection triggers always data abort not just ignore the write like some other protected registers does (like DMA registers or for example SCIGCR0)?


From that other thread I understood that system registers PPCS, PPSE and PPS (from 0xFFF8 0000 to 0xFFFF FFFF) cannot be protected similarly via PCR - registers in this area by default has typically restrictions to USR mode write but not in all registers.

Question: Only option to protect that area is MPU but i takes only 1 region region since is it 0x80000 (2^19) long

Question: without MPU "by default protected registers" in this area just ignores usr mode writes, not trigger data abort (unimplemented addresses is not in scope)?

Since emif & ethernet is out of the (our) scope based on memory map everything important can be protected with 1 MPU region & PCR usage in case it is ok for application to protect whole system peripheral area?



It this a typo or real feature that other similar RTI register can be written in USR mode and other not: RTICPUC0 (TRM 13.3.7) vs RTICPUC1 (TRM 13.3.12)? Tried to test it and looks like it is protected so it is a typo? It is a bit hard/impossible to determine from documentation what is actually protected and what isn't when designing what really needs to be protected in our application - maybe it is easier to protect whole area with MPU than trying to seek if unprotected registers are "harmless" since RTICPUC0 for example is not "harmless" and would need protection in our application...

Also couldn't find anywhere is VIM RAM write priviledged only, based on TRM assuming not but cannot be sure - tried to test it and looks like that it ignores usr mode writes so it is protected? Just for curiosity, where that is said in TRM?

Violated access via MPU or PCR is logged a bit differently (based on TRM 2.3.2.5 description how the words are used) so targeted addresses which cause the data abort needs to be read from different register (or is this "MRC     p15, #0, r0, c6, c0, #0" same as FAULT_ADDRESS_REG? If same, how those "MRC p16 c6"-style operations are mapped to certain peripheral address space?

  • 0
    TI__Guru 59540 points

    Hello Jarkko,

    So for your primary questions,

    Jarkko Silvasti said:

    Question: Only option to protect that area is MPU but i takes only 1 region region since is it 0x80000 (2^19) long

    Question: without MPU "by default protected registers" in this area just ignores usr mode writes, not trigger data abort (unimplemented addresses is not in scope)?

    The answers are yes, and yes respectively. Many of the system module registers are privilege mode write only but to be 100% conclusive, you would need to use the MPU to protect that region of addressable memory space. And, for the second part, if a register/bit is privilege mode only, then the write is ignored and no error is generated.

    I am also unable to find in the TRM where it states that the VIM RAM is write protected so it can only be written in privilege mode. I will enter a document feedback for this issue.

  • 0 in reply to Chuck Davenport
    Expert 1395 points

    Thanks for answers. Could you also give something to these.


    1) Can you confirm that "R/W" is just a typo in RTICPUC0 (TRM 13.3.7), should be "R/WP" as in RTICPUC1 (TRM 13.3.12)?

    2) there isn't a summary of registers (specifically from 0xFFF8 0000 onwards) which would give overview of the registers for example "W" / "WP" / "R" without going to details what these registers actually contains, so only option is to manually seek every register one by one from different locations of TRM? Would rather use just WP protection than MPU but if checking "has the all critical registers for us the built-in WP protection" is as manual work as it looks to be, it will be easier to just use MPU.

    3) after re-reading multiple times the TRM text in 2.3.2.5: "CPU’s fault address register" must refer to co-processor "cp15 c6 c0" not FAULT_ADDRESS_REG-registers (FFFFEAF4h) which looks to be under IOMM but also has exactly same name "Fault Address Register" (the reason why I only find this one via 'find' in pdf) so the text "CPU's"  is the key part in the sentence --> both MPU and PCR reports the violated address to "cp15 c6 c0"?

    4) How to map co-processor stuff to the memory map of the device? Or is this debug area some kind of an exception where co-processor stuff is mirrored to memory? Has all co-processor stuff mirrored memory location at all? (originally these questions raised before I spotted that number 3 case that those most likely are not mirrors of each other, but didn't hurt to ask for future)

    - I know (this one register was given to me) that  cp14 c0 c1 == DSCR register == direct C style access *((uint32_t*)(0xFFA01000U + 0x088U)) so it is "mirrored" under "cortex-R4F Debug" module name (in data sheet) but cannot find that "DSCR" name from TRM so most likely that memory area is not belonging to TRM scope at all and is most likely documented somewhere else  (DSCR content is described in ARM documentation that's not a problem/question).

  • 0 in reply to Jarkko Silvasti
    TI__Guru 59540 points

    Hello Jarkko,

    Jarkko Silvasti said:
    1) Can you confirm that "R/W" is just a typo in RTICPUC0 (TRM 13.3.7), should be "R/WP" as in RTICPUC1 (TRM 13.3.12)?

    Yes, this is a typo. I will enter a document feedback to get this corrected in the next release.

    Jarkko Silvasti said:
    2) there isn't a summary of registers (specifically from 0xFFF8 0000 onwards) which would give overview of the registers for example "W" / "WP" / "R" without going to details what these registers actually contains, so only option is to manually seek every register one by one from different locations of TRM? Would rather use just WP protection than MPU but if checking "has the all critical registers for us the built-in WP protection" is as manual work as it looks to be, it will be easier to just use MPU.

    Unfortunately, this would be a manual process to go through and identify all registers that are R/WP vs R/W. We do not have any summary tables or information available. As you state, it may be quicker to simply protect this space with the MPU if you have regions available for it.

    Jarkko Silvasti said:
    3) after re-reading multiple times the TRM text in 2.3.2.5: "CPU’s fault address register" must refer to co-processor "cp15 c6 c0" not FAULT_ADDRESS_REG-registers (FFFFEAF4h) which looks to be under IOMM but also has exactly same name "Fault Address Register" (the reason why I only find this one via 'find' in pdf) so the text "CPU's"  is the key part in the sentence --> both MPU and PCR reports the violated address to "cp15 c6 c0"?

    Your conclusion is correct. The CPU's fault address register is in CP15 and not the FAULT_ADDRESS_REG-registers (FFFFEAF4h. Apologies for the confution on this.

    Jarkko Silvasti said:
    4) How to map co-processor stuff to the memory map of the device? Or is this debug area some kind of an exception where co-processor stuff is mirrored to memory? Has all co-processor stuff mirrored memory location at all? (originally these questions raised before I spotted that number 3 case that those most likely are not mirrors of each other, but didn't hurt to ask for future)

    The CoProcessor access uses special asm functions to access. There is no way to memory map for easy CPU access. More information in accessing and manipulating CP15 can be found in the ARM Cortex-R4F TRM on the ARM info center page.

    Jarkko Silvasti said:
    - I know (this one register was given to me) that  cp14 c0 c1 == DSCR register == direct C style access *((uint32_t*)(0xFFA01000U + 0x088U)) so it is "mirrored" under "cortex-R4F Debug" module name (in data sheet) but cannot find that "DSCR" name from TRM so most likely that memory area is not belonging to TRM scope at all and is most likely documented somewhere else  (DSCR content is described in ARM documentation that's not a problem/question).

    For ARM specific intellectual property/content, we may reference it but we leave it to the ARM collateral to provide the detail. This prevents issues with synchronization between our documents and ARM documents as well as inconsistencies in how things are described.