DMA: Error flagging in case of DMA write access to IOMM kicker register

Hello Oliver,

  The way an illegal access for DMA or DMM is handled is the same as an illegal address . Please see the reply on the below post.

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/345670.aspx

Hi Charles.

If I understand you correctly it means that in case the DMA tries to write to the IOMM register KICK_REG0 (address 0xFFFFEA38) a DMA imprecise write error should be generated. And cause of this error generation the bit 13 in the ESM register ESMSR1 (i.e. ESMSR1.13) should be set to 1.

I've given it a try now: I've configured DMA channel 5 to write to IOMM register KICK_REG0 (address 0xFFFFEA38). BUT when I trigger DMA channel 5 I can NOT observe that bit ESMSR1.13 will be set to 1.

Notes:
  * Note 1: I've tried it with DMA interrupts enabled and disabled, i.e.:
      - GCHIENAS.5 = 1
      - GCHIENAS.5 = 0
      No difference in the observation.
  * Note 2: When I change my code that the DMA channel should write to the unimplemented address 0x08040020 (instead of to the IOMM register KICK_REG0), then I can observe that bit ESMSR1.13 will be set to 1.

So the questions are now:
* Question 4: Why is the bit ESMSR1.13 not set in case the DMA tries to write to IOMM register KICK_REG0 (address 0xFFFFEA38)?
* Question 5: If bit ESMSR1.13 will not be set: Through which bit field will be indicated that the IOMM Master ID check identified a NOT allowed access by the DMA bus master? I.e. how is the error flagging mechanism working?

Regards
Oliver.

Hi Oliver,

  I tried to use DMA to write to the IOMM Kick register and I do see that the ESM flag is NOT set. I will need to investigate a bit more. However, you can try to use DMA to write to the PMM module. PMM module is also protected using masterID in which only CPU can write to it. I was able to see the ESM GP1.13 get set when DMA writes to the PMM register at 0xFFFF0000. Please give a try and let me know your result. The point I want to make is that an illegal access or an illegal address initiated by the DMA will only set the flag in the ESM and not the BERFLAG inside the DMA module. As far as why an illegal access to the IOMM is not setting the ESM flag, I tend to think at the moment it is an isolated incident that I will further investigate.

Hi Charles.

Several points:
  * Item A: As requested by you in your last posting, I've tried to trigger a DMA write access to PMM register at 0xFFFF0000. And I observe the same behaviour as you: ESM GP1.13 will be set to 1, and the corresponding bit in DMA register BERFLAG will not be set.

  * Item B: I have also tried out other operations regarding DMA and IOMM:
    - Item B.1: I do a DMA write access to IOMM register KICK_REG0 (at address 0xFFFFEA38h) with the value 0x83e70b13 (This is the value to enable the write access to the IOMM registers. See also spnu499b.pdf, page 230). I observe no error response. Then I do a DMA write access to IOMM register KICK_REG1 (at address 0xFFFFEA3Ch) with the value 0x95a4f1e0. Again I observe no error response.
    - Item B.2: After item B.1 was done, the following is done:
        * I do a DMA write access to IOMM registers ERR_ENABLE_REG/ERR_ENABLE_CLR_REG (at address 0xFFFFEAE8h/0xFFFFEAECh). I observe that the values of these registers change!
        * I do a CPU write access to the same IOMM registers. I also observe that the values of these registers change!
        So this means that the Write Access to the IOMM Registers can be ENabled by DMA write accesses!
    - Item B.3: After item B.1 was done (i.e. the IOMM register write access was enabled), the following is done: I do a DMA write access to IOMM register PINMMR0 (at address 0xFFFFEB10). I observe an ESM group 1, channel 37 error, i.e. bit ESMSR4.5 will be set to 1. This is the "IOMM - Mux configuration error". Additionally I observe the following values:
        * For register IOMM ERR_RAW_STATUS_REG = 1. So this means that a Protection Error was identified.
        * For register FAULT_ADDRESS_REG = 0x00000110. Sounds reasonable.
        * For register FAULT_STATUS_REG = 0x00030082. Sounds also reasonable.
    - Item B.4: I perform the same steps as in item B.3 described, with the only difference that item B.1 is not performed (i.e. the IOMM register write access is disabled). The observation result is the same as for item B.3.

  * Item C: Since I have stated several questions above, I just want to summarise which questions are already answered:
    @ question 1: Answered.
    @ question 2: Answered.
    @ question 3: Not answered. But since this question is the same as question 5, it is no longer relevant.
    @ question 4: Not answered.
    @ question 5: Not answered.

  * Item D: New questions:
    Question 6: Why is it possible to enable the Write Access to the IOMM Registers by usage of the DMA (i.e. see item B.1 above)? This question is IMHO for 2 reasons interesting:
            - Reason 1: In spnu499b.pdf, page 230, chapter "4.4.2 Master ID Check", is stated that only the CPU bus master can write access the IOMM registers. So this statement is contradicting to my under item B.1 observed behaviour.
             - Reason 2: Cause of the following two statements:
                    * Statement 1: In spnu499b.pdf, page 231 - 239, chapter "4.5 IOMM Registers", is stated for all write-able bit fields, that they are only write-able in privileged mode.
                    * Statement 2: And in spnu499b.pdf, page 534, chapter "16.2 Module Operation" is stated
                          "... All DMA memory and register accesses are performed in user mode. If the DMA writes to registers which are only accessible in privileged mode, the write will not be performed. ..."
                    So these two statements are contradicting!

    Question 7: Why is it possible to change the IOMM configuration by usage of the DMA (i.e. see item B.2 above)? This question is IMHO for the same 2 reasons interesting which are stated under question 6.

    Question 8: In case it will be tried to change the "Pin Multiplexing Control Registers" (i.e. registers PINMMRnn which are located at addresses 0xFFFFEB10h - 0xFFFFEB88h) by use of the DMA, an error will be generated (i.e. see items B.3 and B.4 above). BUT why will the ESM "IOMM - Mux configuration error" (i.e. ESM group 1, channel 37 error) be generated? IMHO this observation is contradicting to the statement
            "... Writes by other bus masters will generate a bus error response to the corresponding bus master ..."
        in spnu499b.pdf, page 230, chapter "4.4.2 Master ID Check". From this statement (and also cause of the above posting "Posted by Charles Tsai on Jun 03 2014 11:10 AM") I would expect an ESM "DMA - imprecise write error" (i.e. ESM group 1, channel 13 error).

Regards
Oliver.

Hello Oliver,

  My answers are inline.

   @ question 1: Answered.
    @ question 2: Answered.
    @ question 3: Not answered. But since this question is the same as question 5, it is no longer relevant.
    @ question 4: Not answered.

CT>> Yes, I do see that the ESM flag is not set when DMA writes to the kick registers. We are trying to confirm if this is actually a hardware issue. Depending on further analysis we may update the TRM to clarify how it works or update the errata.

    @ question 5: Not answered.

CT>> As explained for Q4, we are trying to confirm in design simulation if this is actually a hardware issue and will update either the TRM or the errata accordingly.

  * Item D: New questions:
    Question 6: Why is it possible to enable the Write Access to the IOMM Registers by usage of the DMA (i.e. see item B.1 above)? This question is IMHO for 2 reasons interesting:
            - Reason 1: In spnu499b.pdf, page 230, chapter "4.4.2 Master ID Check", is stated that only the CPU bus master can write access the IOMM registers. So this statement is contradicting to my under item B.1 observed behaviour.

CT>> I was able to confirm that DMA can indeed write to the kick registers and allowing another write to the interrupt enable register. This is not an expected behavior. We will try to understand in simulation and update TRM or errata.

             - Reason 2: Cause of the following two statements:
                    * Statement 1: In spnu499b.pdf, page 231 - 239, chapter "4.5 IOMM Registers", is stated for all write-able bit fields, that they are only write-able in privileged mode.
                    * Statement 2: And in spnu499b.pdf, page 534, chapter "16.2 Module Operation" is stated
                          "... All DMA memory and register accesses are performed in user mode. If the DMA writes to registers which are only accessible in privileged mode, the write will not be performed. ..."
                    So these two statements are contradicting!

CT>> As explained, this is not an expected behavior but however, I can reproduce the same observation you see. The DMA should be either blocked by the privilege access or by the master ID check but it is not happening.

    Question 7: Why is it possible to change the IOMM configuration by usage of the DMA (i.e. see item B.2 above)? This question is IMHO for the same 2 reasons interesting which are stated under question 6.

CT>> See above answers..

    Question 8: In case it will be tried to change the "Pin Multiplexing Control Registers" (i.e. registers PINMMRnn which are located at addresses 0xFFFFEB10h - 0xFFFFEB88h) by use of the DMA, an error will be generated (i.e. see items B.3 and B.4 above). BUT why will the ESM "IOMM - Mux configuration error" (i.e. ESM group 1, channel 37 error) be generated? IMHO this observation is contradicting to the statement
            "... Writes by other bus masters will generate a bus error response to the corresponding bus master ..."
        in spnu499b.pdf, page 230, chapter "4.4.2 Master ID Check". From this statement (and also cause of the above posting "Posted by Charles Tsai on Jun 03 2014 11:10 AM") I would expect an ESM "DMA - imprecise write error" (i.e. ESM group 1, channel 13 error).

CT>> Yes, I also see the same that only writing to the PINMMRx are generating errors to the ESM GP1.37 channel. The error status shows it is a user write error. Again, it will take sometime to understand if all the questions you raised is an issue with the hardware or lack of proper feature description.

Hi Charles.

Any news regarding my questions?

Regards

Oliver.

Hi Oliver,

  Sorry for the delay. We have verfified in design that the Kick registers are not protected by user/privilege mode. I have filed a TRM documentation update for this since the register description says these are R/WP. This is the reason that the DMA is able to write to these two registers to unlock. As far as the masterID checking is concerned, it is still under investigation by our design team. Looks like it is not working according to how it is described in the TRM. Once we understand the root cause clearly we will take the appropriate action.

 The PINMMRx registers are protected by privilege mode.

  If I get confirmation from our design team in the next two days on the masterID I will update you. I will be out of office next week and will have one of our colleagues to inform you in the forum if new update is available.

Hi Charles.

Any news regarding the masterID checking?

Regards

Oliver.

Hi Oliver,

  Sorry for the late reply. I just got back from vacation today.  The masterID is not an implemented feature for the IOMM but was mistakenly mentioned in the TRM. We will update the TRM accordingly. Only the PINMMRx registers are protected by privilege mode access. DMA accessing the PINMMRx registers will result in error going to ESM GP1.37. The Kick registers are not protected by privilege access. The TRM will be updated as well.