• State Resolved
  • Locked Locked
  • Replies 40 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 3167 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.

DRA718: VIsion SDK+Robust RVC abnormal program termination

Christian N
Expert 1285 points
Part Number: DRA718
Other Parts Discussed in Thread: TVP5150, SYSBIOS, DRA71

Team

We are developing our custom RVC app based on Ti provided Vision SDK 02.12.0.0+RobustRVC 4.0 sources
We have a custom 7" display and use TV5150 as video input.

We are having several abnormal program termination
 
Ocurrence 1: Calling Bsp_deviceInit(&deviceInitPrms)  
If
initPrms->isI2cInitReq = (UInt32) TRUE;
initPrms->isI2cProbingReq = etiher (FALSE or TRUE);

Abort happens calling
bsp_osal.c
ln814:
Hwi_construct(&(gBspOsalHwiObj[i].hwiStruct),
                      (Int32) intNum,
                      (Hwi_FuncPtr) fxn,
                      &hwiParams,
                      0U);

We test with initPrms->isI2cInitReq = (UInt32) FALSE; to continue with the development but the following abort happens


Ocurrence 2: Calling chains_main_robust_rvc.c->chains_main_robust_rvc.c->chains_vipSingleRvcCamCrc_Display(&gChains_usecaseCfg);

gChains_usecaseCfg values
   gChains_usecaseCfg.algProcId = SYSTEM_PROC_DSP1;
   gChains_usecaseCfg.displayType = CHAINS_DISPLAY_TYPE_LCD_7_INCH;
   gChains_usecaseCfg.captureSrc = CHAINS_CAPTURE_SRC_VIDDEC_TVP5150;

else if(captureSrc == CHAINS_CAPTURE_SRC_VIDDEC_TVP5150)
{
   pInstPrm->videoIfMode = SYSTEM_VIFM_SCH_ES;
   pInstPrm->videoIfWidth = SYSTEM_VIFW_8BIT;
   pInstPrm->bufCaptMode = SYSTEM_CAPT_BCM_FRM_DROP;
   pInstPrm->numStream = 1;

   pInprms->width = captureInWidth;
   pInprms->height  = captureInHeight/2;
   pInprms->dataFormat = SYSTEM_DF_YUV422P;
   pInprms->scanFormat = SYSTEM_SF_INTERLACED;

}

At the end of calling chains, we see that abort happens in heap memory alloc
chains_vipSingleRvcCamCrc_Display.c

/*Read by JTAG
pUcObj->CapturePrm.memAllocInfo.memSize = 2592000*/
ln387
    pUcObj->CapturePrm.memAllocInfo.memAddr =
        (UInt32)Utils_memAlloc(
                UTILS_HEAPID_DDR_CACHED_SR,
                pUcObj->CapturePrm.memAllocInfo.memSize,
                128
            );
/*Read by JTAG  size=2592000, align=512*/
    block = Memory_HeapProxy_alloc(heap ? heap : Memory_defaultHeapInstance,
                        size, align, eb);

/*Last function before aborting*/
Ptr HeapMem_alloc(HeapMem_Object *obj, SizeT reqSize,
                    SizeT reqAlign, Error_Block *eb)

Aborting function called
void abort(void)
{
    loader_exit();
    for (;;);   /* SPINS FOREVER */
}

Could you help with that?

Thanks in advance

  • 0
    TI__Intellectual 2440 points

    Hi Christian,

    At least the first issue looks like it's an init time issue. Can I ask if these are occurring during RVC initialization? Is RVC functioning at any point?

    Secondly, I wanted to mention we have Robust RVC 5.0 now. If you're currently in initial stages of bringing up Robust RVC, is there a reason why you're using 4.0?

    Thanks,

    David

  • 0 in reply to David Huang
    Expert 1285 points

    Hi David

    We are moving foward RVC 5.0. When we start with RVC version 5.0 was not available

    Both issues happen at init time.

    Regards

  • 0 in reply to Christian N
    Expert 1285 points
    Team

    We move foward RVC 5.0.
    In RVC 4.0 we put a wait_for_debugger function at the beginning of chains_main_robust_rvc.c Void Chains_main(...) and debugger can "synchronize" code execution with it, but the same function in the same place in RVC 5.0 doesn't work
    Code runs into GateSmp_enter and doesn't reach to Chains_main -> wait_for_debugger

    Could you help with that?

    Regards
  • 0 in reply to Christian N
    TI__Intellectual 2440 points

    Hi Christian,

    You had a closer to base Robust RVC implementation working before, right? Do you know of recent changes that could be causing this? 

    Can you provide full logs for both of these crashes?

    Thanks,

    David

  • 0 in reply to David Huang
    Expert 1285 points

    Hi David

    We left RVC 4.0 and now we are working on RVC 5.0

    We didn't modify anything prior to board init functions (memory maps, chains configurations are the same as base), so chains_main_robust_rvc.c should be reached.

    We are using XDS110 as debugger, M4 FW is running at boot time (U-Boot spl) so please let us to know what kind of logs could be usefully to you, and how can we get it.

    Digging depper

    utils_remote_log_server.c -> ln526 pCoreObj->memInfo[coreID].headerTag=REMOTE_LOG_HEADER_TAG rises Hwi_excHandler

    Regards

  • 0 in reply to Christian N
    TI__Mastermind 33390 points

    Hi Christian,

    Could you instead use the enableDebug feature in vision_sdk/links_fw/src/rtos/bios_app_common/tda2ex/ipu2/src/main_common_ipu2.c to step through the code?

    Snippet from the file below

    /**
    *******************************************************************************
    *
    * \brief This function enables the IPU2 debug option
    *
    * This function enables the IPU2 debug option from main() onwards
    * - Set the volatile variable enableDebug = 1 to enable debug
    * - rebuild the code with enableDebug = 1
    * - Once enableDebug is set to 1, the control waits in this
    * function even after the free-run
    * - Can connect to core IPU2 via CCS and J-Tag to debug
    * - Once CCS is connected, reset enableDebug = 0 to come out of
    * this function and proceeds with further debug
    *
    * \return SYSTEM_LINK_STATUS_SOK
    *
    *******************************************************************************
    */

  • 0 in reply to Vishal Mahaveer
    Expert 1285 points

    Hello Vishal

    We did that earlier and found that code breaks at
    utils_remote_log_server.c -> ln526 pCoreObj->memInfo[coreID].headerTag=REMOTE_LOG_HEADER_TAG rising ti_sysbios_family_arm_m3_Hwi_excHandlerAS__I

    It happens running main_common_ipu2.c RemoteLog_init()

    Looking at pCoreObj value=0xA0200000.

    It means that it is using second  RAM bank?

    At this time this is a phy or logical address?

    In a such a case we have an open related question https://e2e.ti.com/support/arm/automotive_processors/f/1020/p/693005/2561633#2561633

  • 0 in reply to Christian N
    TI__Mastermind 33390 points

    0xA0200000 here refers to physical memory..

    In vision_sdk build output folder, there is a ".map" file generated which also contains a section about  the memory configuration table.

    vision_sdk/binaries/sample_app/*/vision_sdk_ipu2_release.xem4.map

    MEMORY CONFIGURATION
    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
      REMOTE_LOG_MEM        a0200000   00040000  000278a0  00018760  RWIX


    Corresponding memory is reserved on A15 side under rvc_pool2 node of reserved_memory
    http://git.ti.com/android-sdk/kernel-omap/blobs/6AO.1.0-rvc/arch/arm/boot/dts/dra71-evm-robust-rvc.dts#line11



  • 0 in reply to Vishal Mahaveer
    Expert 1285 points

    VISION memory map files weren't modified (remains as is from TI)

    U-Boot DRA7_RPROC_CMA_xxxx_xxxx match with apps/build/tda2ex/mem_segment_definition_linux.xs and double check it with

    git.ti.com/.../c02f6f05089dcbf7efc3c79fa26698a700e44e56

    Running U-Boot only, and stopping it at countdown, by JTAG using Memory Browser for:

    M4_IPU2_C0  we get at 0xa020 0000 (address where exception rises) Error: Target failed to read 0xA0200000

    A15_0 we can read and write 0xa020 0000

    Sure we are missing something... could you help with that

    Thanks a lot for your time

  • 0 in reply to Christian N
    TI__Mastermind 33390 points
    Can you do the following in u-boot prompt and see if it is accessible
    => md.l 0xa0200000 1
  • 0 in reply to Vishal Mahaveer
    Expert 1285 points

    Hi Vishal

    0xa0200000 is accesible

    md.l 0xa0200000 1

    a0200000: 9e8cd6cb

  • 0 in reply to Christian N
    TI__Mastermind 33390 points
    Hi Christian,

    We are trying the same procedure on our end with RVC 5.0 + DRA71 EVM, to see if we see the same behavior.

    Regards,
    Vishal
  • 0 in reply to Vishal Mahaveer
    TI__Mastermind 33390 points

    We tried the RVC5.0 on DRA71 EVM and we were able to use memory browser to look at 0xA020_0000 location.



    1) Could you guys try the prebuilt firmware that is part of the package and check the behavior.
    2) Could you guys check and share the map file on your build system (vision_sdk/binaries/sample_app/*/vision_sdk_ipu2_release.xem4.map)


  • 0 in reply to Vishal Mahaveer
    Expert 1285 points

    Hi Vishal

    1) Using RobustRVC-5.0/rvc_phase-6/emmc_files/vis3.2/dra71-ipu2-fw.xem4 we can read 0xA020_0000 location. IPU2 was flashed only and U-boot was stopped at countdown (Linux was not running)

    2)-vision_sdk/binaries/apps/tda2ex_17x17_evm_robust_rvc/vision_sdk/bin/tda2ex-evm/vision_sdk_ipu2_debug.xem4.map custom file. Let me know if you need the full file

    MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  L2_ROM                00000000   00004000  00000184  00003e7c  RWIX
  L2_RAM                20000000   00010000  00000000  00010000  RWIX
  OCMC_RAM1             40300000   00080000  00000000  00080000  RWIX
  OCMC_RAM2             40400000   00100000  00000000  00100000  RWIX
  OCMC_RAM3             40500000   00100000  00000000  00100000  RWIX
  DSP1_L2_SRAM          40800000   00048000  00000000  00048000  RWIX
  NDK_MEM               84000000   00200000  00000000  00200000  RWIX
  SR1_BUFF_ECC_ASIL_MEM 84200000   00001000  00000000  00001000  RWIX
  SR1_BUFF_ECC_QM_MEM   84201000   00001000  00000000  00001000  RWIX
  SR1_BUFF_NON_ECC_ASIL 84202000   00001000  00000000  00001000  RWIX
  SR1_FRAME_BUFFER_MEM  84203000   0fa00000  00000000  0fa00000  RWIX
  IPU2_CODE_MEM         99000000   00800000  0060e870  001f1790  RWIX
  IPU2_DATA_MEM         99800000   03c00000  02f2d174  00cd2e8c  RWIX
  IPU1_0_CODE_MEM       9e000000   00800000  00000000  00800000  RWIX
  IPU1_0_DATA_MEM       9e800000   01400000  00000000  01400000  RWIX
  SR0                   a0100000   00100000  00100000  00000000  RWIX
  REMOTE_LOG_MEM        a0200000   00040000  000278a0  00018760  RWIX
  LINK_STATS_MEM        a0240000   00080000  00024da4  0005b25c  RWIX
  SYSTEM_IPC_SHM_MEM    a02c0000   00080000  00054640  0002b9c0  RWIX
  HDVPSS_DESC_MEM       a0340000   00100000  0001b340  000e4cc0  RWIX
  TRACE_BUF             a0440000   00060000  00008000  00058000  RWIX
  EXC_DATA              a04a0000   00010000  00000000  00010000  RWIX
  PM_DATA               a04b0000   00080000  00000000  00080000  RWIX
  DSP1_CODE_MEM         a1000000   00200000  00000000  00200000  RWIX
  DSP1_DATA_MEM         a1200000   01800000  00000000  01800000  RWIX
  SR2_MEM               a9000000   04000000  00000000  04000000  RWIX


SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    00000044   00000044    r-x
  00000000    00000000    00000044   00000044    r-x .ducatiBoot
00000400    00000400    00000140   00000140    r--
  00000400    00000400    00000140   00000140    r-- .resetVecs
99000000    99000000    0000044c   0000044c    rw-
  99000000    99000000    0000044c   0000044c    rw- .resource_table
9900044c    9900044c    00000014   00000014    r-x
  9900044c    9900044c    00000004   00000004    r-- .const:ti_sysbios_hal_ammu_AMMU_numLargePages__C
  99000450    99000450    00000010   00000010    r-x .text.1
99000460    99000460    0060e414   0060e414    r-x
  99000460    99000460    00507b06   00507b06    r-- .const
  99507f68    99507f68    000be3b4   000be3b4    r-x .text.2
  995c631c    995c631c    00000004   00000004    r-- .const:ti_sysbios_hal_ammu_AMMU_numLinePages__C
  995c6320    995c6320    00000f54   00000f54    r-x .text.3
  995c7274    995c7274    00000004   00000004    r-- .const:ti_sysbios_hal_ammu_AMMU_numMediumPages__C
  995c7278    995c7278    00001614   00001614    r-x .text.4
  995c888c    995c888c    00000004   00000004    r-- .const:ti_sysbios_hal_ammu_AMMU_numSmallPages__C
  995c8890    995c8890    00045b2a   00045b2a    r-x .text.5
  9960e3bc    9960e3bc    000004b8   000004b8    r-- .const:ti_sysbios_hal_ammu_AMMU_mmuInitConfig__C
99800000    99800000    02f09c40   00000000    rw-
  99800000    99800000    02800000   00000000    rw- .systemHeap
  9c000000    9c000000    004f5c3c   00000000    rw- .bss
  9c4f5c40    9c4f5c40    00214000   00000000    rw- .bss:taskStackSection
9c709c40    9c709c40    000234d4   0001f4d4    rw-
  9c709c40    9c709c40    0001f4d4   0001f4d4    rw- .data
  9c729114    9c729114    00004000   00000000    rw- .stack
9c72d114    9c72d114    00000064   00000064    rw-
  9c72d114    9c72d114    00000064   00000064    rw- .args
a0440000    a0440000    00008000   00000000    rw-
  a0440000    a0440000    00008000   00000000    rw- .tracebuf

    ....
    .bss:extMemNonCache:remoteLogCoreShm 
    *          0    a0200000    000278a0     NOLOAD SECTION
                      a0200000    000278a0     utils_common.aem4 : utils_remote_log_server.oem4 (.bss:extMemNonCache:remoteLogCoreShm)

    .bss:extMemNonCache:linkStats 
    *          0    a0240000    00024da4     NOLOAD SECTION
                      a0240000    00024da4     utils_common.aem4 : utils_link_stats_collector.oem4 (.bss:extMemNonCache:linkStats)

    .bss:extMemNonCache:ipcShm 
    *          0    a02c0000    00054640     NOLOAD SECTION
                      a02c0000    00054640     links_common_system.aem4 : system_ipc.oem4 (.bss:extMemNonCache:ipcShm)

    .bss:extMemNonCache:vpdma 
    *          0    a0340000    0001b340     NOLOAD SECTION
           
    ...

    Regards

  • 0 in reply to Christian N
    TI__Mastermind 33390 points

    Hi Christian,

    Any chance you guys did any modification to Ammu configurations?
    vision_sdk/links_fw/src/rtos/bios_app_common/tda2ex/ipu2/Ammu2*.cfg

    I am still not sure on which cfg file is used Ammu2_bios.cfg or Ammu2_linux.cfg, most probably Ammu2_bios.cfg.
    As per the Ammu2_bios file, 0xA0200000 is logical address.

    /* map SR_0 data memory into ammu (non-cacheable) */
    var entry = AMMU.largePages[2];
    entry.pageEnabled = AMMU.Enable_YES;
    entry.translationEnabled = AMMU.Enable_YES;
    entry.logicalAddress = 0xA0000000;
    entry.translatedAddress = 0x80000000;
    entry.size = AMMU.Large_512M;
    entry.L1_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
    entry.L1_posted = AMMU.PostedPolicy_NON_POSTED;
    entry.L2_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
    entry.L2_posted = AMMU.PostedPolicy_NON_POSTED;


    Could you guys use the ROV view of CCS and check the Ammu configuration?
    Check this before you hit the crash.

    Regards,
    Vishal

  • 0 in reply to Vishal Mahaveer
    TI__Mastermind 33390 points

    Sorry for the confusion again. The Ammu2_linux.cfg is used for Robust RVC.
    We still need to check the Ammu configuration.

    Few more questions,
    1) have you made any changes to apps/configs/tda2ex_evm_robust_rvc/cfg.mk
    2) Could you share your build configuration (make -s -j showconfig)


  • 0 in reply to Vishal Mahaveer
    Expert 1285 points
    Any memory configuration file were modified.

    Sorry, but I'am unfamiliar with ROV. I launch it but I can't find where Ammu configuration could be checked.
    When I try to get Memory module, I get the following error
    Error: java.lang.Exception: Target memory read failed at address: 0x9c7290d4, length: 4 This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt.
  • 0 in reply to Christian N
    TI__Intellectual 2440 points
    Hi Christian,

    Ammu configuration file is:
    vision_sdk/links_fw/src/rtos/bios_app_common/tda2ex/ipu2/Ammu2_linux.cfg

    Would be good to know any changes made there in addition to the other two Vishal mentioned.

    Thanks,
    David
  • 0 in reply to Vishal Mahaveer
    Expert 1285 points

    1)Files changed

    /ti_components$ git status
...

	modified:   drivers/pdk_01_08_01_06/packages/ti/drv/vps/include/devices/bsp_device.h
	modified:   drivers/pdk_01_08_01_06/packages/ti/drv/vps/src/boards/makefile
	modified:   drivers/pdk_01_08_01_06/packages/ti/drv/vps/src/boards/src/bsp_board.c
	modified:   drivers/pdk_01_08_01_06/packages/ti/drv/vps/src/boards/src/bsp_boardPriv.h
	modified:   drivers/pdk_01_08_01_06/packages/ti/drv/vps/src/devices/makefile
	modified:   drivers/pdk_01_08_01_06/packages/ti/drv/vps/src/devices/src/bsp_device.c


/vision_sdk/build$ git status
...

	modified:   ../apps/src/common/main_app/tda2ex/ipu2/src/main_ipu2.c
	modified:   ../apps/src/include/chains_common.h
	modified:   ../apps/src/include/chains_common_sensor.h
	modified:   ../apps/src/rtos/common/chains_main_robust_rvc.c
	modified:   ../apps/src/rtos/usecasescd /common/chains_common.c
	modified:   ../apps/src/rtos/usecases/common/chains_common_vision.c
	modified:   ../apps/src/rtos/video_sensor/include/video_decdr.h
	modified:   ../apps/src/rtos/video_sensor/include/video_sensor.h
	modified:   ../apps/src/rtos/video_sensor/src/tvp5158/video_decdr.c
	modified:   ../apps/src/rtos/video_sensor/src/vid_sensor.c
	modified:   Rules.make (MAKECONFIG?=tda2ex_17x17_evm_robust_rvc <-this one only)
	modified:   ../links_fw/src/rtos/links_ipu/vip_capture/captureLink_displaywb_drv.c

    2)make -s -j showconfig

    #
# Build Config is [ tda2ex_17x17_evm_robust_rvc ]
# Build Config file is @ /home/user/repos/famp/vision_03_02_00_00/vision_sdk/configs/tda2ex_17x17_evm_robust_rvc/cfg.mk
# Build Config .h file is @ /home/user/repos/famp/vision_03_02_00_00/vision_sdk/links_fw/include/config/apps/tda2ex_17x17_evm_robust_rvc/system_cfg.h
# Build CPUs is @ ipu2 dsp1
#
# CPUs included in application,
# PROC_IPU1_0_INCLUDE=no
# PROC_IPU1_1_INCLUDE=no
# PROC_IPU2_INCLUDE=yes
# PROC_DSP1_INCLUDE=yes
# PROC_DSP2_INCLUDE=no
# PROC_EVE1_INCLUDE=no
# PROC_EVE2_INCLUDE=no
# PROC_EVE3_INCLUDE=no
# PROC_EVE4_INCLUDE=no
# PROC_A15_0_INCLUDE=no
#
# Platform config,
# VSDK_BOARD_TYPE=TDA2EX_EVM [options: TDA2XX_EVM TDA2EX_EVM TDA3XX_EVM TDA3XX_RVP]
# PLATFORM=tda2ex-evm
# DUAL_A15_SMP_BIOS=no
# DDR_MEM=DDR_MEM_1024M [options: DDR_MEM_128M DDR_MEM_512M DDR_MEM_1024M]
# NDK_PROC_TO_USE=none [options: a15_0 ipu1_0 ipu1_1 ipu2 none]
# NSP_TFDTP_INCLUDE=no [options: yes no]
# TDA2EX_ETHSRV_BOARD=no [options: yes no]
# FATFS_PROC_TO_USE=none [options: ipu1_0 none]
# RADAR_BOARD=none [options: TDA3XX_AR12_ALPS TDA3XX_AR12_VIB_DAB_BOOSTER TDA3XX_RADAR_RVP none]
#
# Build config,
# BUILD_OS=Linux [options: Windows_NT Linux]
# BUILD_DEPENDENCY_ALWAYS=no
# BUILD_ALGORITHMS=no
# BUILD_INFOADAS=no
# PROFILE=release [options: debug release]
# KW_BUILD=no
# CPLUSPLUS_BUILD=no
# IPU_PRIMARY_CORE=ipu2 [options: ipu1_0 ipu2]
# IPU_SECONDARY_CORE=ipu1_0 [options: ipu1_0 ipu2]
# A15_TARGET_OS=Linux [options: Bios Linux Qnx]
# BSP_STW_PACKAGE_SELECT=all [options: all vps-iss-dss-only vps-vip-vpe]
#
# Safety Module config,
# RTI_INCLUDE=no
# ECC_FFI_INCLUDE=no
# DCC_ESM_INCLUDE=no
#
# Video Module config,
# IVAHD_INCLUDE=no
# VPE_INCLUDE=yes
# CAL_INCLUDE=no
# ISS_INCLUDE=no
# ISS_ENABLE_DEBUG_TAPS=no
# WDR_LDC_INCLUDE=no
# DSS_INCLUDE=yes
#
# Open Compute config,
# OPENCL_INCLUDE=no
# TARGET_ROOTDIR=/home/user/repos/famp/vision_03_02_00_00/vision_sdk/../ti_components/os_tools/linux/targetfs
# ENABLE_OPENCV=no
# ENABLE_OPENCV_TESTS=no
# OPENVX_INCLUDE=no
#
# Log config,
# ENABLE_UART_LOG=no
# ENABLE_NETWORK_LOG=no
# ENABLE_CCS_LOG=yes
# CIO_REDIRECT=no
#
# IPC config,
# WORKQ_INCLUDE=no
# IPC_LIB_INCLUDE=no
#
# Surround View config,
# SRV_FAST_BOOT_INCLUDE=no
#
# Other Module config,
# AVB_INCLUDE=no
# DCAN_INCLUDE=no
# RADAR_INCLUDE=no
# CPU_IDLE_ENABLED=yes
# FAST_BOOT_INCLUDE=no
# DATA_VIS_INCLUDE=no
# HS_DEVICE=no
# ULTRASONIC_INCLUDE=no
#
# Linux config,
# DEFAULT_UBOOT_CONFIG=dra7xx_evm_vision_config
# DEFAULT_KERNEL_CONFIG=omap2plus_defconfig
# DEFAULT_DTB=dra7-evm-infoadas.dtb
# CMEM_INCLUDE=no
# IPUMM_INCLUDE=yes
# IPU1_EVELOADER_INCLUDE=no
# ROBUST_RVC_INCLUDE=yes
# BUILD_ADAM_CAR=no
#
# Alg plugins included in build,
# ALG_swcrc ALG_rvcDiags
#
# Use-cases included in build,
# UC_vip_single_rvc_cam_view_crc
#
#
# CPUs that are NOT required but included in config [ tda2ex_17x17_evm_robust_rvc ],
#
#
# CPUs that are required but not included in config [ tda2ex_17x17_evm_robust_rvc ],
#
#
# Edit /home/user/repos/famp/vision_03_02_00_00/vision_sdk/build/configs/tda2ex_17x17_evm_robust_rvc/cfg.mk to include or exclude CPUs in an application
#

    3)/vision_sdk/links_fw/src/rtos/bios_app_common/tda2ex/ipu2/Ammu2_linux.cfg

        /* map SR_0 data memory into ammu (non-cacheable) */
        var entry = AMMU.largePages[2];
        entry.pageEnabled = AMMU.Enable_YES;
        entry.translationEnabled = AMMU.Enable_YES;
        entry.logicalAddress = 0xA0000000; /* Identity is ok, isn't?*/
        entry.translatedAddress = 0xA0000000;
        entry.size = AMMU.Large_512M;
        entry.L1_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
        entry.L1_posted = AMMU.PostedPolicy_NON_POSTED;
        entry.L2_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
        entry.L2_posted = AMMU.PostedPolicy_NON_POSTED;

  • 0 in reply to Christian N
    TI__Mastermind 33390 points

    Hi Christian,

    We suspect the issue you are facing is because of 1GB board.
    Could you try below change in u-boot and test?

    diff --git a/board/ti/dra7xx/lateattach.c b/board/ti/dra7xx/lateattach.c
    index 71c9d92..c6cbdb0 100644
    --- a/board/ti/dra7xx/lateattach.c
    +++ b/board/ti/dra7xx/lateattach.c
    @@ -12,6 +12,9 @@
    *
    * SPDX-License-Identifier: GPL-2.0+
    */
    +#undef DEBUG
    +#define DEBUG
    +
    #include <common.h>
    #include <asm/bitops.h>
    #include <asm/io.h>
    @@ -166,16 +169,6 @@

    #define VAYU_ES10_CHIPSETID 0x5436

    -#define DRA7_PGTBL_BASE_IPU1 0xbfc00000
    -#define DRA7_PGTBL_BASE_IPU2 0xbfc08000
    -#define DRA7_PGTBL_BASE_DSP1 0xbfc10000
    -#define DRA7_PGTBL_BASE_DSP2 0xbfc18000
    -
    -#define DRA7_PGTBL_BASE_IPU1 0xbfc00000
    -#define DRA7_PGTBL_BASE_IPU2 0xbfc08000
    -#define DRA7_PGTBL_BASE_DSP1 0xbfc10000
    -#define DRA7_PGTBL_BASE_DSP2 0xbfc18000
    -
    /*
    * The page table (32 KB) is placed at the end of the CMA reserved area.
    * It's possible that this location is needed by the firmware (in which
    @@ -193,6 +186,16 @@
    #define PAGE_TABLE_SIZE_L2_TOTAL (MAX_NUM_L2_PAGE_TABLES*PAGE_TABLE_SIZE_L2)
    #define PAGE_TABLE_SIZE (PAGE_TABLE_SIZE_L1+(PAGE_TABLE_SIZE_L2_TOTAL))

    +
    +#define DRA7_PGTBL_BASE_IPU1 (DRA7_RPROC_CMA_BASE_IPU1 \
    + + DRA7_RPROC_CMA_SIZE_IPU1 - PAGE_TABLE_SIZE) /* 0x9eff8000 */
    +#define DRA7_PGTBL_BASE_IPU2 (DRA7_RPROC_CMA_BASE_IPU2 \
    + + DRA7_RPROC_CMA_SIZE_IPU2 - PAGE_TABLE_SIZE) /* 0x98ff8000 */
    +#define DRA7_PGTBL_BASE_DSP1 (DRA7_RPROC_CMA_BASE_DSP1 \
    + + DRA7_RPROC_CMA_SIZE_DSP1 - PAGE_TABLE_SIZE) /* 0x9cff8000 */
    +#define DRA7_PGTBL_BASE_DSP2 (DRA7_RPROC_CMA_BASE_DSP2 \
    + + DRA7_RPROC_CMA_SIZE_DSP2 - PAGE_TABLE_SIZE) /* 0x9fff8000 */
    +
    #define PAGE_SHIFT 12
    #define PAGE_SIZE (1 << PAGE_SHIFT)

    @@ -1335,7 +1338,8 @@ u32 spl_boot_core(u32 core_id)
    if (cfg->config_mmu && cfg->has_rsc_table)
    cfg->config_mmu(core_id, cfg);

    - debug("Configured the IOMMU\n");
    + debug("IPU2=0x%x, IPU1=0x%x, DSP2=0x%x, DSP1=0x%x\n",
    + DRA7_PGTBL_BASE_IPU2, DRA7_PGTBL_BASE_IPU1, DRA7_PGTBL_BASE_DSP2, DRA7_PGTBL_BASE_DSP1);
    /* Load the remote core.
    *
    * Fill the page table of the first(possibly only) IOMMU during ELF


    If these changes work at u-boot, corresponding changes would be needed in Kernel also.

    Regards,
    Vishal

  • 0 in reply to Vishal Mahaveer
    Expert 1285 points
    Hi Vishal

    1)PATCH works!.
    1.a)Could you provide any details about it? Perhaps it would be usefully to us if new issues arise
    1.b)Should have processor paging tables in his own address space only?
    1.c)Should be the address in comments the right ones? It doesn't match with defines (IPU2 example ox99000000 + 0x05000000 - 0x4400). It is for double checking only.

    2)Original post issue (ocurrence 1) is there. We migrate to RVC5.0 to bring to tip implementation, but it doesn't solve the issue.
    Hwi_smp.c line 147 - 149

    Regards
  • 0 in reply to Christian N
    TI__Mastermind 33390 points

    Hi Christian,

    The comments in the change shared could be based on old RVC code base (based on a different vision_sdk)

    I am guessing this change is needed because the default region used for pagetable is at the border of 1GB address space (0xbfc00000, 0xbfc08000, 0xbfc10000, 0xbfc18000). Will update you with more details on the change.

    Note that Linux Kernel also has carveout for pagetable in lateattach dts, which would need updates accordingly and the remotecore CMA region also should be updated accordingly.


    Regards,
    Vishal

  • 0 in reply to Vishal Mahaveer
    TI__Intellectual 2440 points
    Hi Christian,

    Can you provide more details on the issue in Occurrence 1? You said you were able to workaround it by setting initPrms->isI2cInitReq = (UInt32) FALSE, so is the failure caused by an i2c conflict or other issue?

    Thanks,
    David
  • 0 in reply to David Huang
    Expert 1285 points
    Hi David

    Issue is related to I2C.
    We are calling Bsp_deviceInit -> Bsp_deviceI2CInit ->...->bsp_deviceI2c.c GIO_contruct with params
    &gBspDevObj.i2cGioStruct[i2cInstId=0]=address(0x9c4f0844 ) no init (all zero)
    i2cDevName =i2c1
    GIO_INPUT
    &ioParams = OS related params, not I2C related, I thought
    &eb = OS related params, not I2C related, I though
    At the end of calling chains Hwi_smp.c line 147 - 149 raise error

    Regards
  • 0 in reply to Christian N
    TI__Intellectual 2440 points

    Hi Christian,

    What error specifically? Just double checking we're looking at the same thing, I see:

    /* check vector table entry for already in use vector */

    if (*((UInt32 *)Hwi_module->vectorTableBase + intNum) !=

    (UInt32)Hwi_nullIsrFunc) {

    Error_raise(eb, Hwi_E_alreadyDefined, intNum, 0);

    return (1);

    }

    Thanks,

    David

  • 0 in reply to David Huang
    Expert 1285 points
    Hi David

    Run into Error_raise(eb, Hwi_E_alreadyDefined, intNum, 0);

    Looking at if (*((UInt32 *)Hwi_module->vectorTableBase + intNum) != (UInt32)Hwi_nullIsrFunc) disassembly at the end instruction
    cmp r1,r2
    I see a label named __stacl at R2=0x9c729114, it is strange at least for me that this location is initialized to 0xBEBEBEBE 0xBEBEBEBE .... from 0x9c729114 to 0x9c72cd58.

    Sorry for provide this kind of information, but really I don't know how this framework's function is intended for

    Regards
  • 0 in reply to Christian N
    TI__Mastermind 33390 points

    Hi Christian,

    There could be a i2c conflict between bootloader and vision_sdk. We cannot have multiple cores using peripherals at the same time. In this case between M4 and A15. Which i2c are you planning to use for vision_sdk (configuring camera, display, etc..) 

    Check vision_sdk/build/rtos/makerules/rules_m4.mk for I2C we disable by default for our boards.

    ifeq ($(ROBUST_RVC_INCLUDE),yes)
    CFLAGS_INTERNAL += -DBSP_DISABLE_I2C2 -DBSP_DISABLE_I2C5
    else
    CFLAGS_INTERNAL += -DBSP_DISABLE_I2C0 -DBSP_DISABLE_I2C2 -DBSP_DISABLE_I2C5
    endif

    The usage of these I2C flags are used in ti_components/drivers/pdk_01_08_01_06/packages/ti/drv/vps/src/boards/src/bsp_boardTda2ex.c


    Regards,
    Vishal

  • 0 in reply to Vishal Mahaveer
    Expert 1285 points

    Hi Vishal

    We are using i2c2_sdx/hdmi1_ddc_scx pin for TVP5150, as far we know i2c2 pin is I2C1 in makefiles. So our I2C2 pin (BSP_DISABLE_I2C1) is enable.
    We have already remove it from U-Boot

    RVC could works without fw on IPU1? I would like to remove all unnecesary cores for testing purposes


    Regards

  • 0 in reply to Christian N
    TI__Mastermind 33390 points
    Yes, there is no dependency on IPU1, TI RVC release is based on IPU2 and DSP1.
  • 0 in reply to Vishal Mahaveer
    Expert 1285 points
    For testing pruposes we remove flash IPU2 DSP1 MLO & UBOOT only.
    We set initPrms->isI2cInitReq = (UInt32) FALSE; to avoid Original post OCURRENCE-1.

    In this scenario program halt at chains_vipSingleRvcCamCrc_Display_Create. Digging deeper we found that the following functions are called

    chains_vipSingleRvcCamCrc_Display_Create
    +-System_linlCreate(...);
    ...
    +-System_linkControl_local()
    ...
    +-Utils_mxSendMsg()
    +-Utils_queGet(..., BSP_OSAL_WAIT_FOREVER)

    App waits for a message, but nothing is comming and it hangs

    1-It is waiting an ack message from DSP1?
    2-What this Q is intended for?

    Regards
  • 0 in reply to Christian N
    TI__Mastermind 33390 points

    Did you mean, you flashed only IPU2, DSP1, and bootloaders?
    It could be that it is waiting for DSP1.

    Could you look at the trace buffer of DSP1 and IPU2 to see what's going on.

    To get the memory dump of the trace buffer using CCS follow the steps below
    - On CCS, go to Tools --> Save Memory
       - Save File: the output file location. eg. C:\*\Desktop\0xA0440000.txt
       - File type: TI Raw Data
    - Hit Next
    - Use Start Address: 0xA0440000 for IPU2 and 0xA020A0A0 for DSP1
    - Length: Specify the number of memory words to read: 8000
    - Type-size: 32 bits
    - Hit Finish.


    If the address mentioned above for IPU2 and DSP1 (0xA0440000, 0xA020A0A0) doesn't show the trace. use the method below to figure out the correct address for tracebuffer.

    - Connect CCS to DSP1 or IPU2 core.
    - Put a break point on function "RemoteLog_serverPutString" in vision_sdk\src\utils_common\src\utils_remote_log_server.c or -vision_sdk\links_fw\src\rtos\utils_common\src\utils_remote_log_server.c
    - Look at the address for pDst to get the Memory address for the remote core.
    - Put a SW/HW break point after "pDst = &pCoreObj->serverLogBuf[pIdxInfo->startIdx];" to figure out pDst value

  • 0 in reply to Christian N
    TI__Guru 50045 points
    Hi Christian,

    chains_vipSingleRvcCamCrc_Display_Create() will call the create function of each link used in the RVC use case in sequence.
    It will wait for the link create function to return status via message. If the link create function hangs for some reason, it will get stuck.

    Going back to the abort from occurrence #1, could you check if your M4 build has "VPS_TI_RTOS_I2C" macro defined or not?

    Regards,
    Stanley
  • 0 in reply to Stanley Liu
    Expert 1285 points

    Hi Team

    Ocurrence 1:

    /ti_components/drivers/pdk_01_08_01_06/packages/ti/drv/vps/vps_components.mk

    ln1106 VPS_USE_TI_RTOS_I2C := yes

    ...

    ln1110 VPSDRV_CFLAGS += -DVPS_TI_RTOS_I2C

    Is it enough, or do we have to define it elsewhere?

    Ocurrence 2:

    We are getting the following assert

    SYSTEM: WARNING Memory address out of bounds (0x843ff000, 518400) Memory region is [0x84203000, 2592000]

    ipu2_debug map report

    SR1_FRAME_BUFFER_MEM 84203000 0fa00000 00000000 0fa00000 RWIX

    Where 2592000 come from? NDK_MEM_SIZE?

    Regards

  • 0 in reply to Christian N
    TI__Intellectual 2440 points

    Hi Christian,

    On Occurrence 1, this is in a conditional block:

    ifeq ($(SOC),$(filter $(SOC), am572x am571x dra75x dra78x))

    And ${SOC} is defined in ti_components/drivers/pdk_01_08_01_06/packages/ti/build/makerules/platform.mk based on $(BOARD). According to ti_components/drivers/pdk_01_08_01_06/packages/ti/build/readme.txt you would define $(BOARD) in the Rules.make in this directory for build, though it doesn't specify why.

    Since your build is based on tda2ex or dra71x, it shouldn't be defining "VPS_TI_RTOS_I2C" from that conditional block. The concern is that if this is defined somewhere, we need isI2cInitReq=FALSE else it hits abort() in Bsp_deviceI2cInit().

    On Occurrence 2, I'm only finding that number in vision_sdk/binaries/apps/tda2ex_17x17_evm_robust_rvc/obj/app_libs/tda2ex-evm/ipu2/release/chains_vipSingleRvcCamCrc_Display.sem4.

    Thanks,

    David

  • 0 in reply to David Huang
    Expert 1285 points

    Hi David

    Ocurrence 1:

    Did you mean that we don't need "VPS_TI_RTOS_I2C"?

    We took SDK + RVC for tda2ex_17x17_evm_robust_rvc as base. I review understand that mk's and builds system file were not modified.

    We understand that tda2ex_17x17_evm_robust_rvc is using I2C, isn't it?

    Regards

  • 0 in reply to Christian N
    TI__Mastermind 33390 points

    Hi Christian,

    Yes, this flag should not be set if isI2cInitReq=TRUE.

    The board file for tda2ex does not have definitions for I2C1. Could you adding it? Since you are using I2C1.
    ti_components/drivers/pdk_01_08_01_06/packages/ti/drv/vps/src/boards/src/bsp_boardTda2ex.c


    Regards,
    Vishal

  • 0 in reply to Vishal Mahaveer
    TI__Mastermind 33390 points

    On the I2C related crash, the IPU crash was pointing to
    E_alreadyDefined: Hwi already defined: intr# 0

    We found that for tda2ex the I2C2 interrupt number is defined as 0  and caused the crash
    File: pdk_01_08_01_06/packages/ti/csl/soc/tda2ex/cslr_soc_defines.h
    #define CSL_INTC_EVENTID_I2CINT2        (0U)

    Changing the interrupt number to 42, similar to tda2xx/cslr_soc_defines resovles the crash relaed to I2C

  • 0 in reply to Vishal Mahaveer
    Expert 1285 points

    Hi Vishal

    It works. I2C is not causing assertion.

    To keep it clear.

    • GPIO pin muxing should be done in U-Boot muxdata.h?
    • I2C PRCM configuration should be done in SPL?
    • GPIO direction/mode should be done in VISION SDK (bsp_boardxxx.c) ?
    • U-Boot dts pin muxing is not being used by SPL?
    • U-Boot dts pin setting, like the following node, is not being used by SPL?
       my_node {
      compatible = "gpio-leds";
      pinctrl-names = "default";
      pinctrl-0 = <&pinctrl_mypin_ctrl>;

      my_subnode {
         label = "my_label";
         gpios = <&gpio4 29 GPIO_ACTIVE_LOW>;
         default-state = "on";
      };
    • U-Boot dts pin muxing is not being used by U-Boot?
    • U-Boot dts pin setting, like the above, is being used by U-Boot?
    • If any pin is used by U-Boot (A15) it shouldn't be used by RVC (IPU2), so it should be removed from dts?

    Questions are for double checking? (We have done a lot of changes for test purposes, and we have to clear  unnecessary code)

    Regards

  • 0 in reply to Christian N
    TI__Mastermind 33390 points

    • GPIO pin muxing should be done in U-Boot muxdata.h?   --> All pinmuxing should be done in muxdata.h, this is used by SPL and the configurations stay for u-boot and kernel. Only exception for doing pinmux in Kernel is MMC.
    • I2C PRCM configuration should be done in SPL?              --> Yes
    • GPIO direction/mode should be done in VISION SDK (bsp_boardxxx.c) ?   --> Can be done either in bootloader or VISION_SDK
    • U-Boot dts pin muxing is not being used by SPL?      --> Muxdata.h comes in to picture in SPL, the pin mux configurations stay there on wards (u-boot. kernel). On TI dra7*.dts, only MMC has pinctrl in u-boot dts and this comes in to picture for both SPL and u-boot.

    • U-Boot dts pin setting, like the following node, is not being used by SPL?     -->  u-boot dts pinctrl settings are used by poth SPL and u-boot. In TI dts only MMC has pinctrl in u-boot dts, I don't see any other usage of pinctrl in TI dra7*.dts. 

    • U-Boot dts pin muxing is not being used by U-Boot?     --> same answer as above
    • U-Boot dts pin setting, like the above, is being used by U-Boot?          --> same answer as above
    • If any pin is used by U-Boot (A15) it shouldn't be used by RVC (IPU2), so it should be removed from dts?   --> Didn't understand this question. Recommendation is to do all pinmuxing in SPL (muxdata.h) weather it's used by A15 or IPU.



  • 0 in reply to Vishal Mahaveer
    TI__Mastermind 33390 points

    Correction to above post.
    SPL does not use the u-boot dts (CONFIG_SPL_DM is disabled)