DM8148: SYSTEM: Attaching to [DSP] ... DSP not loading Problem

Are you using DVR RDK or IPNC RDK ? What does low power and full feature mode mean ? Are you clocking the cores higher ? If so the PMIC voltage should be adjusted as per the OPP(this is on EVM). Also can you connect JTAG to DSP and see its state on your board ?

Thanks a lot for the reply, Badri. 

We are using IPNC RDK, migrating from IPNC 8127.

Low power shuts the DSP down, while full feature enables it. That's the main difference I can tell. Of course, the links are also different. 

We are not clocking higher. Both M3: 400MHz, DSP: 500Mhz. I will double check the voltage though. 

I am working on the JTAG right now and will keep you updated. 

Some updates:

We did connect ccs with dm8148 thru JTAG. DSP shows running in CCS. However when JTAG works, the serial console seems freezing (arm not working?)

We manage to locate main() for DSP and runs from there. Now it looks like since ARM(host) not working, so DSP tries to attaching to HOST all the time.

C674X_0] ***** SYSTEM : Frequency <ORG> - 500000000, <NEW> - 500000000
[C674X_0]
[C674X_0] *** UTILS: CPU KHz = 500000 Khz ***
[C674X_0]
[C674X_0] 143425: SYSTEM : System Common Init in progress !!!
[C674X_0] 143426: SYSTEM: IPC init in progress !!!
[C674X_0] 143426: SYSTEM: Attaching to [HOST] ...
[C674X_0] 143466: SYSTEM: Attaching to [HOST] ...
[C674X_0] 143506: SYSTEM: Attaching to [HOST] ...

Ok this is odd.Looks like IPNC RDK has a build option for full feature vs low power mode and some define is disabling DSP IPC configuration. Did you rebuild IPNC RDK as well when you moved from low power to full feature configuration .?  Make sure you do full clean , delete ipnc_rdk/build and ipnc_rdk/lib and rebuild. I will anyhow check with the IPNC team if they have any inputs.

I really appreciate your response.

I did do a full clean build on the IPNC RDK for full feature and copy the associated uboot and uImage before compiling the application. 

Right now we speculate that DSP has a difficulty in communicating with A8 or m3. Maybe there is some ipc address mis-alignment. We checked the memory map for multiple times but couldn't locate any.  We are kinda of running out of our limited debugging options. 

Thank you so much for spreading this around. For IPC, syslink, any suggestion on debugging method? 

Can you check the value of gSystem_ipcEnableProcId on both linux side and bios side..Grep for this in rdk codebase and check if there are any defines that disable DSP procId

Both sides are the same: 

UInt32 gSystem_ipcEnableProcId[] = {
SYSTEM_PROC_HOSTA8,
#if defined(TI_8107_BUILD) || !defined(IPNC_DSP_ON)
SYSTEM_PROC_INVALID,
#else
SYSTEM_PROC_DSP,
#endif
SYSTEM_PROC_M3VIDEO,
SYSTEM_PROC_M3VPSS,
SYSTEM_PROC_MAX /* Last entry */
};

I am wondering how to trace the address or shared region for them to communicate with each, for example. videom3 to dsp.

Thank you

Pls try changing to:

UInt32 gSystem_ipcEnableProcId[] = {
SYSTEM_PROC_HOSTA8,
SYSTEM_PROC_DSP,
SYSTEM_PROC_M3VIDEO,
SYSTEM_PROC_M3VPSS,
SYSTEM_PROC_MAX /* Last entry */
};

at all places and rebuild linux and bios side.If this works then issue if with build .

 To debug the Ipc_attach you can single step on the DSP side into the Ipc_attach call.You will see the DSP repeatedly trying to read memory location to check if status is updated by remote core

Thanks Badri. That's really helpful. 

I will compile that tomorrow and keep you updated. Once I connect CCS thru JTAG, the arm side (serial window) freezes. Is that normal? When I step on the DSP, it will trying to attach host repeatedly. Though not successfully, I should be able to locate the memory. 

You are connecting to c674 core right ? ARM should not freeze on connecting to DSP. The only possibility is DSP has temporarliy acquire a MutleProcessor Gate (HwSpinlock) in which case ARM will go into a busy loop waiting for the lock to be released and this can cause ARM to become unresponsive.

You are right. Badri.

I connected DSP after connecting ARM and even loading GEL. Now I connects DSP only, while ARM is running. 

I start the DSP running in CCS. It passes the frequency setup successfully and tries to talk to HOST repeatedly:

[c6xdsp ] : SYSTEM: Attaching to [HOST] ...
[c6xdsp ] : SYSTEM: Attaching to [HOST] ...

Also, I tried to load the firmware for DSP in CCS directly by "Load program". it's goes to 33% and then report an error. 

C674X_0: GEL: File: /home/user/ipnc/Source/ipnc_rdk/ipnc_mcfw/bin/ti814x/firmware/ipnc_rdk_fw_c6xdsp.xe674: Load failed.
C674X_0: Trouble Reading Register CSR
C674X_0: Trouble Reading Memory Block at 0x8f486794 on Page 0 of Length 0x83
C674X_0: Trouble Reading Memory Block at 0x8f486794 on Page 0 of Length 0xcd

My question is, can I load firmware this way? Is .xe674 the right format? If yes, this trouble reading might indicate the problem? 

In memory map, 0x8f486794: 

8f486780 00000060 sysbios.lib : BIOS.obj (.text:ti_sysbios_hal_Hwi_checkStack:ti_sysbios_hal_Hwi_checkStack)

Thanks a lot.

You should not load the executable via CCS when running the RDK firmware loader. You can only load symbols. This is because syslink will load the program and has a state which will get corrupted if executable is loaded via CCS.ALso ensure no gel files are getting executed before/after you connect to c674 core. All configuration done by GEL file is already done by syslink.

Hello! This may be help.

DSP processor is OFF state by default. Modify U-Boot file evm.c for DSP in ON state

In U-boot file board/ti/ti8148_ipnc/evm.c

prcm_init(u32 in_addr){

....

iss_pll_config();

iva_pll_config();

dsp_pll_config();  //  File have not this line. Insert line

....

}

ipnc_ff_pll_init (int opption)

  if (option == 1){

             PLL_CLKOUT_ENABLE(DSP_PLL_BASE);          //      file have not  this line. Insertn line

             // dsp_pll_config();          // Comment this line