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: UART configuration for use by IPU1

Expert 1935 points

Part Number: AM5728
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hello,

I'd like to use UART10 with the interrupt driver sysbios drivers.

Linux takes care of the iomux and the irq crossbar config.

To make the UART10 accessible I use a custom rsc_table.h and added:

#define UART10_CFG_REGS         0x4AE00000
#define UART10_CFG_REGS_VIRT    (UART10_CFG_REGS)

and:

    {
        TYPE_DEVMEM,
        UART10_CFG_REGS_VIRT, UART10_CFG_REGS,
        SZ_1M, 0, 0, "UART10_REGS",
    },

In my Ipu1.cfg I added:

var socType           = "am572x";
var Uart              = xdc.loadPackage('ti.drv.uart');
Uart.Settings.socType = socType;

In my C file I used:

#include <ti/drv/uart/src/v1/UART_v1.h> // defines UART_HwAttrs
#include <ti/drv/uart/UART.h>
#include <ti/drv/uart/src/UART_osal.h>
#include <ti/csl/hw_types.h>
#include <ti/csl/soc.h>

    UART_HwAttrs uart_hwAttrs;
    UART_socGetInitCfg(UART_INSTANCE, &uart_hwAttrs);
    uart_hwAttrs.baseAddr = 0x6AE2B000;
    UART_socSetInitCfg(UART_INSTANCE, &uart_hwAttrs);

That seems to take care of the wrong default address offset. This approach works fine for I2C

Now I set the IRQ crossbar up to route UART10_IRQ (221) to IPU1_IRQ32 (0x4A0027F0 is 0xDD0000).

By reading the source I found HwAttrs.eventId and intNum but no documentation on those fields.

UART_open fails with:

[0][      6.650] [t=0xa213533f] ti.sysbios.family.arm.m3.Hwi: ERROR: line 1104: E_hardFault: FORCED
[0][      6.650] ti.sysbios.family.arm.m3.Hwi: line 1104: E_hardFault: FORCED
[0][      6.650] [t=0xa2160591] ti.sysbios.family.arm.m3.Hwi: ERROR: line 1216: E_usageFault: INVSTATE: Invalid EPSR and instructio
n combination

How do I tell the sysbios uart driver / interrupt handler that the UART10 IRQ will be on IPU1_IRQ32?

Best regards,

Lo2

  • The interrupt hookup default configuration for the UART driver is in the file "pdk_am57xx_1_0_9\packages\ti\drv\uart\soc\am572x\UART_soc.c".

    Since you used the following configuration
    Uart.Settings.socType = socType;

    The UART_HwAttrs uartInitCfg is used as default configuration for the interrupt. To modify this you only need to change the intNum, the same way as you changed the base address using

    UART_socGetInitCfg(UART_INSTANCE, &uart_hwAttrs);
    uart_hwAttrs.intNum = 32; // By default it is set to 24 in the UART_soc.c file
    UART_socSetInitCfg(UART_INSTANCE, &uart_hwAttrs);

    eventID only applies to DSP core as their is an eventCombiner module for the DSP core. which needs to be configured.

    Hope this helps.

    Regards,
    Rahul
  • Another side note.

    I assume that uboot is configuring the pinmux for UART10 and you have disabled the UART10 from your Linux device tree. Now since you are not using Board_init call on the IPU, you need to manually enable the UART10 module clock as described here:
    processors.wiki.ti.com/.../Linux_IPC_on_AM57xx

    Regards,
    Rahul
  • Hello Rahul,

    thanks for the fast reply.

    UART10 is disabled in the device tree:
    serial@4ae2b000 {
    compatible = "ti,dra742-uart", "ti,omap4-uart";
    reg = <0x4ae2b000 0x100>;
    interrupts = <0x0 0xdd 0x4>;
    ti,hwmods = "uart10";
    clock-frequency = <0x2dc6c00>;
    status = "disabled";
    };

    Clock, irq crossbar and pinmuxing setup is done in uboot.
    My clock for UART10 is active: Value at address 0x4AE07880 (0xb6fbd880): 0x2
    I can also access UART10 regs: Value at address 0x4AE2B000 (0xb6fa9000): 0x5B (that also works in an ipu task)

    Running the code, I get through UART_init() (no surprise as it does almost nothing)
    but UART_open() fails. There are some UART_drv_log1 messages: How do I enable them and where will they appear?
    (remark: I don't rebuild the PDK, it takes ages)
    Since I've set "uart_hwAttrs.enableInterrupt = 0;" (for testing purposes, I need interrupts later on) even UART_open should not do much.
    I can't seem to find an implementation of "extern void UARTIntDisable(uint32_t baseAddr, uint32_t intFlag);" but I assume that just sets/clears flags.

    So could I be missing something to let the IPU access the UART10 addresses?

    Why is CSL_IPU_UART10_REGS defined as 0x4ae2b000U in ti/csl/soc/am572x/src/cslr_soc_ipu_baseaddress.h?
    That address is in the bitbanding region. So a usable virtual address will be somewhere else.
    I asked in a different post if I could setup the IPU MMU to match the CSL defaults but got no answer on that.

    The entries in the custom resource table, who read/uses them and what do they control?
    Is it just to allow access to the defined memory ranges?


    Best regards,
    Lo2

  • The CSL address definitions in Processor SDK RTOS is defined for the RTOS usecase where all cores are running RTOS. In this mode, the CSL addresses are used as is. However when using remote-proc and IPC, the address translation and MMU table is controlled remoteproc driver using resource table and system MMU.

    We have tried to explain the difference in the MMU setup difference in the standalone IPU RTOS application and running this with IPC/remoteproc:
    processors.wiki.ti.com/.../Linux_IPC_on_AM57xx

    There is no good way to get away from the adding of the 0x2000_0000 offset. the LLD driver allows users to update the base address in one place using configuration in UART_soc.c but if you are using CSL directly then you need to account for this offset.

    Regards,
    Rahul
  • I didn`t understand your following comment:

    Lo2 said:
    My clock for UART10 is active: Value at address 0x4AE07880 (0xb6fbd880): 0x2
    I can also access UART10 regs: Value at address 0x4AE2B000 (0xb6fa9000): 0x5B (that also works in an ipu task)

    Shouldn`t the virtual address be 0x6AE0_7880. also, looking at the register define for CM_WKUPAON_UART10_CLKCTRL, the Enable bit is [17:16] so not  sure why you think 0x2 indicates clock is enabled.

    Before you start integrating with Remote-proc and IPC, I would recommend that you test this by loading application over emulator independent of ARM Linux.

    Regards,

    Rahul