• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 2629 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.

RTOS/AM5728: Peripheral registers access from IPU

Scott Jackson7
Intellectual 430 points
Part Number: AM5728


Tool/software: TI-RTOS

I'm running Linux on the Cortex A15 cores of my AM5728 and want to run SYS/BIOS on IPU1. My IPU1 application needs access to a UART. I've been trying to use the TI-RTOS UART drivers to do this but cannot get them to function properly. I've already disabled the appropriate UART in the Linux device tree file so I assume that the Linux side shouldn't be trying to take control of it. My application crashes every time it goes to configure the UART however.

After doing some digging, it looks like my IPU cannot access any peripheral registers; attempting to do so leads to a hard fault exception. I can't even access the local UNICACHE or MMU registers; CCS reports "Error: unable to read" whenever I try to access them through the Registers view. Attempting to access location 0x5508 0000 (the IPU1_UNICACHE_CFG register as shown in table 7-10 of the TRM) in the CCS Memory Browswer shows only question marks. 

I'm guessing that an MMU somewhere (either on Linux or Cortex M4/IPU side) is being configured to prevent access to these registers, but I have no idea where to look. My SYS/BIOS application is set up to have the AMMU configuration built in, but I can't confirm its being set correctly because I can't read back the appropriate registers.

Can anyone provide any assistance?

  • 0 in reply to Brad Griffis
    Intellectual 430 points
    Brad,

    I tried using the memory browser in CCS to manually translate and view addresses following the table on the link you gave me but to no avail. For example, the IPU1_MMU register is at address 0x5508 0800 according to Table 7-10 in the TRM. The wiki page states that address 0x5400 0000 is translated to the 0x7400 0000 range, but only up to 16MB, meaning it stops at 0x7500 0000, putting the IPU1_MMU address out of the translated range. I tried to browse it through IPU1 with my debugger and CCS but nothing is shown.

    Similarly, I tried to access UART5 (base address 0x4806 6000 according to table 24-182). The wiki page you referenced indicates that this should be translated to the 0x6800 0000 range for 2MB, meaning that 0x6806 6000 should be within the translated range. Again, CCS refuses to access memory from that location. Indeed if I try to perform an access through code to a location in that range (e.g., to read a UART register) my program crashes. This is true even if I use the TI-RTOS UART driver to try and configure the UART; I can step through the driver code until it tries to access a UART register at which point a hard fault exception is thrown.

    For reference, I am using the IpuAmmu.cfg file to set up my AMMU in my IPU application:
    C:\ti\ipc_3_46_00_02\examples\DRA7XX_linux_elf\ex02_messageq\ipu1\IpuAmmu.cfg

    Could it be that this is the "wrong" configuration to be using for the IPU? I suspect that this may be at least part of the problem because the addresses it specifies its translating don't match up with what the wiki page shows.
  • 0 in reply to Scott Jackson7
    TI__Guru*** 125430 points

    Scott Jackson7 said:
    Similarly, I tried to access UART5 (base address 0x4806 6000 according to table 24-182). The wiki page you referenced indicates that this should be translated to the 0x6800 0000 range for 2MB, meaning that 0x6806 6000 should be within the translated range. Again, CCS refuses to access memory from that location. Indeed if I try to perform an access through code to a location in that range (e.g., to read a UART register) my program crashes. This is true even if I use the TI-RTOS UART driver to try and configure the UART; I can step through the driver code until it tries to access a UART register at which point a hard fault exception is thrown.

    Before you can access this range you need to first enable the UART5 clock through the PRCM.  I added some more detail on the wiki page:

    http://processors.wiki.ti.com/index.php/Linux_IPC_on_AM57xx#Cortex_M4_IPU_Access_to_Peripherals

    (Please refresh the page if you still have it open from last time!)

  • 0 in reply to Brad Griffis
    Intellectual 430 points
    Brad,

    Thanks! I found the updated instructions on the page that mention enabling the UART5 clock. Enabling the clock appears to resolve the issue where the IPU won't read the UART registers (and also prevents the rproc driver on the linux side from complaining when I try to view the register contents).

    The IPU1 local registers for things like MMU and UNICACHE seem to still be unreadable however.

    So I now have two follow up questions:

    1) Where and how are these address translations set? Looking through the wiki and the IPC Resource custom table page, it looks like it's in a header buried somewhere in the RTOS SDK. What isn't clear to me yet, however, is where these values are used to set up the memory map internal to the processor. I had thought it was all done through the AMMU, but that appears to not be the case.

    2) How do I tell the TI RTOS UART driver where it should be looking for the UART registers? While it looks like the resource table mapping gets set up as part of the whole xdctools mess, the UART driver (which xdctools also manages) is still looking at the untranslated physical address, which I verified using the debugger in CCS. This access ends up causing a hardware crash, presumably because the UART driver is trying to look in the wrong place.


    Scott
  • 0 in reply to Scott Jackson7
    TI__Guru*** 125430 points

    Scott Jackson7 said:
    1) Where and how are these address translations set? Looking through the wiki and the IPC Resource custom table page, it looks like it's in a header buried somewhere in the RTOS SDK. What isn't clear to me yet, however, is where these values are used to set up the memory map internal to the processor. I had thought it was all done through the AMMU, but that appears to not be the case.

    The AMMU translation is handled by IpuAmmu.cfg as discussed in the wiki page.  That one is just doing a straight-through mapping.  The one that's changing things for you is the IOMMU.  That mapping is defined as part of the resource table.  Making any changes to that table should be handled through a "custom resource table" which is discussed in a separate page:

    http://processors.wiki.ti.com/index.php/IPC_Resource_customTable

    Scott Jackson7 said:
    2) How do I tell the TI RTOS UART driver where it should be looking for the UART registers? While it looks like the resource table mapping gets set up as part of the whole xdctools mess, the UART driver (which xdctools also manages) is still looking at the untranslated physical address, which I verified using the debugger in CCS. This access ends up causing a hardware crash, presumably because the UART driver is trying to look in the wrong place.

    I've asked for some feedback from the RTOS team on this question.  Let's see what they suggest.

  • 0 in reply to Brad Griffis
    Intellectual 430 points

    Brad,


    Thanks for the reply! After reading your response and digging through the TRM a little more, I think I understand much better now. To summarize, it looks like there are effectively two levels of translation:

    1) The UNICACHE MMU (or IOMMU)

    2) The AMMU

    Both of these together determine the virtual addressing used by the IPU core though, as you pointed out, it's effectively all done by the IOMMU in this case because the AMMU doesn't do any translation on those addresses. This does a lot to help me understand what's going on behind the scenes so I appreciate your feedback.