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.

AM572X DSP Custom Board Definition

Other Parts Discussed in Thread: AM5728

This question is an evolution of a previous question I posted here:  https://e2e.ti.com/support/embedded/tirtos/f/355/t/492719

We are designing a custom board based on the EVM AM5728 GP.  We will have Linux on the ARMs and TI-RTOS on the DSP Cores. 

The plan is to have the ARM control as much of the hardware as possible, but the DSP does need to access some of the interfaces. The DSP will need to access UART, SPI, GPIO, PCIE.  DSP will be using memory mapped from the ARM via the MMU.  It is anticipated that he ARM will handle all PINMUX config and setup clocks.

In looking at the board files for the evmAM572x for the C66, it seems like I can delete almost everything under the assumptions above. 

Currently on the EVM AM5728 GP, I have been able to do testing with the following board init:

Board_initCfg boardCfg;

boardCfg = BOARD_INIT_UNLOCK_MMR

| BOARD_INIT_UART_STDIO

| BOARD_INIT_MODULE_CLOCK

| BOARD_INIT_PINMUX_CONFIG // The PINMUX config causes an 18 second delay in completing the Board_init() function. ;

Board_init(boardCfg);

Just short of starting with the evmAM572x board file and slowly stripping everything out one piece at a time until something breaks,
I was wondering if someone could comment on the idea that I might not need a board init at all. For example, the UART Init is
actually calling UART_stdioInit(BOARD_UART_INSTANCE); which I could call directly instead of calling Board_init().

Comments/Questions/Ideas?

  • I will ask the RTOS team to look at this.
  • Yes,  I think that you can call directly only functions that you need.

    But you will have to do some reverse engineering in order to do it,  (and you want to)

    So try it,  and tell us your observations.

    Ran

  • Chris,

    Here are my 2 cents on this system integration.

    From your description it sounds like ARM would be the system master in your system while DSP will only be used to control a few peripherals.  If the A15 controls the DSP then I would recommend  using U-Boot  to initialize PLL, PSC, pinmux, DDR, UART etc. Another board init call from the DSP or M4 to configure these parameters would cause conflict with what U-Boot has already setup, also might have a negative effect on Linux running on the ARM.

    Note: there could be some exception to this rule like in case of UART. You can`t use the same UART port for DSP logs as the one used by ARM Linux as this can potentially cause a conflict when both ARM and DSP are trying to access it unless you put some safety mechanism in place.

    In addition to this, you will also need to resolve Memory conflicts while running application on the DSP. Currently Linux assumes all the memory is allocated to the ARM and the TI RTOS for AM57xx defines the memory map as defined in the platform definition 

    Also, if you use timers on the DSP side make sure that you are using the following timer as this is what has been aligned on the RTOS side and the Linux side in the SDK.

    •   A15                      (GPTimer 2 & 10)     
    •   DSP                     (GPTimer 5 & 6)      
    •  IPU(Dual-M4)       (GPTimer 3,4,9 & 11) 

    Regards,

    Rahul

  • Thanks Rahul, good info.

    Follow up question. Can you point me to where the memory map you show above is defined? That seems to me like maybe the Linux memory map for one of the examples?

    What I had found and thought to be the memory map for TI-RTOS for the evmAM5728 was located here:

    C:\ti\bios_6_45_00_19\packages\ti\platforms\evmAM572X\Platform.xdc

    In our case we intend for both DSP's to have a common memory map and then the ARM will map each DSP into physical memory using the MMU's, like this:

    DSP 1                                                     Physical
    0x80000000 – 0x8FFFFFFF             0xE0000000 – 0xEFFFFFFF             EMIF DDR
     0x90000000 – 0x90FFFFFF             0x00000000 – 0x00FFFFFF          GPMC FPGA 1

    DSP 2                                                     Physical
    0x80000000 – 0x8FFFFFFF             0xF0000000 – 0xFFFFFFFF             EMIF DDR
    0x90000000 – 0x90FFFFFF             0x01000000 – 0x01FFFFFF           GPMC FPGA 2
  • Chris,

    Yes, the platform definition in Platfom.xdc file found under bios_6_45_00_19\packages\ti\platforms\evmAM572X\Platform.xdc is where the memory map is defined. The overall system memory map has been provided in the comment prior to line 104 in that file.The subsequent lines are used to associate the memory regions and map it to individual cores.

    Regards,
    Rahul