TDA4VM: Adding DRU channel to C7x using SYSCONFIG

Hi Arnie,

Can you also build sysfs itb file using "make sysfw-image" command and then copy sysfw.itb file from board-support/k3-image-gen-2022.01/ folder to BOOT folder in SD card?

Regards,

Brijesh

Hi Brijesh,

Unfortunately, after running the above mentioned command and copying the sysfw.itb file to the boot partition, the problem persists.

Regards

Hi Amine,

What error do you see? Is it resource allocation? Can you please share the error log? 

Regards,

Brijesh

Hi Brijesh,

For the moment the C7x does not emmit any error logs however the TIDL hangs while trying to initialise it's 12 DRU channels (we are initialising 4 DRU in our code). 

How ever when we initialise only 2 DRU channels in our code, the TIDL works just fine. This means that the DRU channels reallocation has failed.

Regards.

Hi Amine,

If there is any resource allocation failure, the C7x should print some error messages. Typically resources are allocated in the UDMA driver, even in TIDL, and when it fails, it prints error message on the UART console, assuming vision_apps_init.sh script is run. 

If you are seeing hang, it may not be due to channel allocation. Can you check when it fails/hangs? 

Regards,

Brijesh

Hi Amine,

Also can you please share the changes done in the rm-cfg.c file for the review? 

Regards,

Brijesh

Hi Brijesh,

Here are the error msgs when we try to initialse more than 16 DRU channels on the C7X (using the  vision_apps/utils/udma driver).

Attached is the rm-cfg.c in which we allocate 26 DRU channels to C7X, 1 DRU channel for C66_0 and 1 DRU channel for C66_1.

0447.rm-cfg.c

Regards

Hi Amine,

Could you please check and confirm that you have provided print function to the driver init API, like below?

udmaInitPrms.printFxn = (Udma_PrintFxn)appLogPrintf;

Because i don't see any error print from the driver. The current error print is from the utils folder.  It might be that it is able to allocate DMA channels, but failed to allocate something else, like rings..  Can you also try setting TD completion ring to null like below? 

chPrms.fqRingPrms.ringMem = ch_obj->fq_ring_mem;
chPrms.cqRingPrms.ringMem = ch_obj->cq_ring_mem;
chPrms.tdCqRingPrms.ringMem = NULL; //ch_obj->tdcq_ring_mem;
chPrms.fqRingPrms.ringMemSize = APP_UDMA_RING_MEM_SIZE;
chPrms.cqRingPrms.ringMemSize = APP_UDMA_RING_MEM_SIZE;
chPrms.tdCqRingPrms.ringMemSize = 0; //APP_UDMA_RING_MEM_SIZE;
chPrms.fqRingPrms.elemCnt = APP_UDMA_RING_ENTRIES;
chPrms.cqRingPrms.elemCnt = APP_UDMA_RING_ENTRIES;
chPrms.tdCqRingPrms.elemCnt = 0;//APP_UDMA_RING_ENTRIES;

Regards,

Brijesh

Hi Brijesh,

Yes the print function is provided to the driver as shown below. FYI: the "UDMA: Init ... !!!" msg is displayed on the C7X logs.

After changing the below line

chPrms.tdCqRingPrms.ringMem = NULL; //ch_obj->tdcq_ring_mem;
chPrms.tdCqRingPrms.ringMemSize = 0; //APP_UDMA_RING_MEM_SIZE;
chPrms.tdCqRingPrms.elemCnt = 0;//APP_UDMA_RING_ENTRIES;

The additional DRU channels initialisation seems to work, since no error messges were displayed from the utils/udma driver.

Regards.

Hi Amine,

Thanks, it seems it is running out of rings on C7x. Its ok to not use TearDown rings, as long as there is no explicit call for tear down, so above change is ok, assuming the call to disableCh API is at the very end of the program. 

Not sure currently how we can allocate more rings, i will check the team and will get back. 

Regards,

Brijesh 

Hi Brijesh,

I hope you are doing well.

Below is what we did using the SYSCONFIG tool:

• Changed the "Extended Tx channels DRU Count" nbr:
  • C66_0 = 6 -> 0
  • C66_1 = 6 -> 0
  • C7X_0 = 16 -> 28
• Changed the "Ring accelerator Free rings Count" nbr:
  • C66_0 = 38 -> 3
  • C66_1 = 12 -> 3
  • C7X_0 = 32 -> 76

Attached is the rm-cfg.c file.2350.rm-cfg.c

After compiling u-boot and updating the boot partition on the SD card, the original 16 DRU channels are working correctly.

However, with the additional channels, the initialisation is working OK but the data transfer is KO. we verified the execution flow and it turns out that the channel keeps waiting indefinitely for the <__EFR> event, with the <__EFR> register value is allways at 0.

Are there any other resource reallocation that need to be done ?

Regards.

Hi Amine,

I will request Anshu Jain to help here.

Regards,

Brijesh

Hi Amine,

Can you please check below comment and code in the ti-processor-sdk-rtos-j784s4-evm-08_06_01_03\vision_apps\platform\j784s4\rtos\c7x_1\main.c. This needs to be changed on the number of channels allocated for C7x. 

/* Important Note: The CLEC configuration in this file corresponds to the default UDMA
* partitioning of events as found in pdk/packages/ti/drv/udma/soc/j784s4/udma_rmcfg.c
* for the UDMA_RM_C7X_MSMC_DRU4. The first 20 events are configured for C7X-1, so
* enabling these CLEC events for C7X-1 here. If the default UDMA event partitioning
* is changed, this mapping of events will need a corresponding change */
static void appC7xClecInitDru(void)
{
CSL_ClecEventConfig cfgClec;
CSL_CLEC_EVTRegs *clecBaseAddr = (CSL_CLEC_EVTRegs*) CSL_COMPUTE_CLUSTER0_CLEC_REGS_BASE;

uint32_t i;
uint32_t dru_input_start = 664 + 96*C7X_CORE_ID;
uint32_t dru_input_num = 20;
/* program CLEC events from DRU used for polling by TIDL
* to map to required events in C7x
*/
for(i=dru_input_start; i<(dru_input_start+dru_input_num); i++)
{
/* Configure CLEC */
cfgClec.secureClaimEnable = FALSE;
cfgClec.evtSendEnable = TRUE;

/* cfgClec.rtMap value is different for each C7x */
cfgClec.rtMap = CSL_clecGetC7xRtmapCpuId();
cfgClec.extEvtNum = 0;
cfgClec.c7xEvtNum = (i-dru_input_start)+32;
cfgClec.acDru = 0;
CSL_clecConfigEvent(clecBaseAddr, i, &cfgClec);
}
}

Regards,

Brijesh

Hi Brijesh,

After changing the dru_input_num = 28 in the appC7xClecInitDru function, the first 27 DRU channels are working correctly (Init & Data Transfer are OK).

However the last DRU channel (the 28th) seems to have the same issue as before, meaning that the initialisation is OK but the data transfer is KO, with the channel waiting indefinitely for the <__EFR> event, with the <__EFR> register value is allways at 0.

Regards.

Hi Amine,

Not exactly sure, there might be some limitation in CLEC programming. For the time being, can you please use 27 channels, meanwhile, i will check the team why 28 channels are not working. 

Regards,

Brijesh 

Hi Amine,

In the above code, can you please check if CSL_clecConfigEvent API is returning error or success for 28th event? 

Because in this API implementation, i see below checks, where CSL_CLEC_MAX_EXT_EVT_OUT is set to 128 and CSL_CLEC_MAX_C7X_EVT_OUT is set to 64. So if any of these event number of more than this value, it can return error and then this channel will not work.. 

if((NULL == pRegs) ||
(NULL == evtCfg) ||
(evtNum >= CSL_CLEC_MAX_EVT_IN) ||
(evtCfg->extEvtNum >= CSL_CLEC_MAX_EXT_EVT_OUT) ||
(evtCfg->c7xEvtNum >= CSL_CLEC_MAX_C7X_EVT_OUT))
{
retVal = CSL_EFAIL;
}

Regards,

Brijesh

Hi Brijesh,

We verified the result of every CSL_clecConfigEvent call within the appC7xClecInitDru function and all results are equal to 0 (CSL_PASS).

Regards