• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 1707 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

[FAQ] AM62x, AM64x: Updating the Region-based Address Translation (RAT) Settings

Nick Saulnier
Guru* 87785 points
Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

R5F, PRU_ICSSG/PRU-ICSS/PRU-SS, and M4F remote cores all have region-based address translation (RAT) modules. RAT modules allow a core to translate system addresses (e.g., DDR at 0x8000_0000) to a different local address (e.g., the remote core could write to a local address of 0x90000000, and the RAT could be configured to translate that write to the system address of DDR at 0x8000_0000). M4 cores are most likely cores to need to configure the RAT. However, be aware that the R5F and PRU cores also have RAT functionality.

When would the RAT settings need to be changed? When should the RAT settings NOT be changed? How do I change the RAT settings?

.

For information on other multicore subjects, reference the FAQ Sitara multicore development and documentation.

UPDATE January 2024: The information in this FAQ is being added to the processor academy modules. This FAQ will not be maintained going forward.
Please find the latest information in the processor's academy > MCU module > Region-based Address Translation (RAT):
AM62Ax

  • +1
    TI__Guru* 87785 points

    When do the RAT settings need to be changed?

    The RAT settings in TI’s example projects can be used as a starting point.
    However, the example projects may have different address mappings than
    your use case needs.

    Address translation is needed in these usecases:

    * The core must access memory beyond a 32-bit address space (For example,
    the on-chip debug hardware configuration registers have addresses larger
    than 0xFFFF_FFFF).

    * The core must access memory regions that are not accessible from the core's
    local addresses.

    Memory regions may be inaccessible because:

    * The memory region is already defined for local resources (for example,
    M4F has local resources at addresses that are less than 0x6000_0000, and
    greater than 0xDFFF_FFFF).

    * The project has already remapped a different memory space over that
    local address (for example, if system address 0x0000_0000 is remapped
    to local address 0x8000_0000, and the core needs to access system
    address 0x8000_0000, then system address 0x8000_0000 must be remapped
    to a different local address)

    For M4F in particular on AM24x/62x/64x, check the RAT settings when the M4F
    project accesses:

    * System memory and external memory (for example, in a shared memory usecase)

    * Device configuration registers (pinmux, clocking, power, reset, etc.
    Reference TRM chapter “Device Configuration”)

    * Main domain resources

    AM64x note: M4F drivers only support using MCU domain peripherals by default. Reference the MCU+ SDK Release Notes for a list of supported peripherals.

    AM62x note: 
    M4F drivers support using MCU domain peripherals by default. Reference
    the MCU+ SDK Release Notes for a list of supported peripherals. Some
    main domain peripherals and wakeup domain peripherals can also be
    accessed by the M4F. Reference the MCU+ SDK page "Accessing main and
    wakeup domain peripherals from MCU domain"

  • 0
    TI__Guru* 87785 points

    When should a memory region NOT be remapped?

    If Linux is initializing the remote core, then any memory region where Linux
    initializes data for the remote core must NOT be remapped.

    Linux does not have visibility into a remote core's RAT settings. Thus, Linux
    cannot tell if an address in a remote core project has been remapped or not.

    For example, let's say that we want the remote core's resource table to be
    placed in DDR at 0x9CC0_0000. However, in the remote core, another memory region
    is already remapped to the local address range of 0x9000_0000-0x9FFF_FFFF. So
    in the remote core, we remap system address 0x9000_0000 to local address
    0xA000_0000. Then the remote core files will say that the resource table is at
    local address 0xACC0_0000, and the RAT will translate that to a system address
    of 0x9CC0_0000.

    In this example, Linux would read the remote core's local address information,
    and place the resource table at system address 0xACC0_0000 instead. The code
    would not work.

    What are options to get this example to work?

    1. Continue to load the remote core with Linux. However, do NOT remap the
    0x9000_0000 address space to a different local address. Instead, move the
    memory region that was getting remapped onto local address 0x9000_0000 to
    a different local address.

    2. Load the remote core with SBL instead of with Linux.

  • 0
    TI__Guru* 87785 points

    How to update the RAT Settings in the Remote Core Project

    RAT mappings for MCU+ projects are stored in the SysConfig file example.syscfg.
    example.syscfg can be edited with the SysConfig tool, or directly with a file
    editor.

    How to use RAT Translation within the linker.cmd file

    The linker.cmd file uses the CPU core virtual address.
    That means that if a memory region is translated with the RAT, and the
    memory region is referenced in the linker.cmd file, then the linker.cmd
    file should use the local RAT translated address, not the system address.

  • 0
    TI__Guru* 87785 points

    How to use RAT Translation within the Remote Core Firmware

    MCU+ functions distinguish which peripheral they are talking to by passing the
    base address of the peripheral in the function call.

    All software written with the MCU+ SDK should use AddrTranslateP_getLocalAddr
    to get the local address of the peripheral. Even if the address is not
    currently remapped, AddrTranslateP_getLocalAddr allows code to be more easily
    ported. AddrTranslateP_getLocalAddr also prevents later versions of code from
    breaking if address translation is added.

    How does AddrTranslateP_getLocalAddr generate a local view of the base
    address?

    1. Pass the ACTUAL system address to AddrTranslateP_getLocalAddr.
    AddrTranslateP_getLocalAddr checks whether the system address is in an
    address range that was remapped:

    2. If the address range is not remapped, then AddrTranslateP_getLocalAddr
    sets localAddr = systemAddr

    3. If the address is remapped, then AddrTranslateP_getLocalAddr translates
    the localAddr

    4. Every function call that interacts with that peripheral would use the
    localAddr value.