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.

AM5728: using omap remoteproc to get DSP running

Part Number: AM5728

Hi we try to run code on the DSP core of the AM57x.

I can follow the example from here: 

to get it running on the IDK, but on our custem hardware I encounter the following difficulties:

After loading the DSP watchdog continuously reboots the DSP:

[ 154.129254] 000: remoteproc remoteproc2: crash detected in 40800000.dsp: type watchdog
[ 154.129289] 000: remoteproc remoteproc2: handling crash #15 in 40800000.dsp
[ 154.129297] 000: remoteproc remoteproc2: recovering 40800000.dsp
[ 154.150088] 000: omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[ 154.150122] 000: omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[ 154.150134] 000: remoteproc remoteproc2: stopped remote processor 40800000.dsp
[ 154.159137] 000: remoteproc2#vdev0buffer: assigned reserved memory node dsp1-memory@99000000
[ 154.159296] 000: remoteproc2#vdev0buffer: registered virtio0 (type 7)
[ 154.159304] 000: remoteproc remoteproc2: remote processor 40800000.dsp is now up

this sequence is printed repeatedly.

root@cpm:~# lsmod
Module Size Used by
prueth 40960 0
pru_rproc 24576 1 prueth
irq_pruss_intc 20480 1 pru_rproc
pruss 16384 2 pru_rproc,prueth
omap_remoteproc 20480 0
cmemk 45056 0

I made the following changes to the devicetree

to enable the dsps in general

&dsp1 {
	status = "okay";
};
&dsp2 {
	status = "okay";
};

To reserve memory:

	reserved-memory {
		#address-cells = <2>;
		#size-cells = <2>;
		ranges;
		ipu2_memory_region: ipu2-memory@95800000 {
			compatible = "shared-dma-pool";
			reg = <0x0 0x95800000 0x0 0x3800000>;
			reusable;
			status = "okay";
		};
		dsp1_memory_region: dsp1-memory@99000000 {
			compatible = "shared-dma-pool";
			reg = <0x0 0x99000000 0x0 0x4000000>;
			reusable;
			status = "okay";
		};
		ipu1_memory_region: ipu1-memory@9d000000 {
			compatible = "shared-dma-pool";
			reg = <0x0 0x9d000000 0x0 0x2000000>;
			reusable;
			status = "okay";
		};
		dsp2_memory_region: dsp2-memory@9f000000 {
			compatible = "shared-dma-pool";
			reg = <0x0 0x9f000000 0x0 0x800000>;
			reusable;
			status = "okay";
		};
	};
};

These parts I took over from am572x-idk-common.dtsi. Our system has 2GB of RAM, so I thought I can go with the default settings.

Is there something else I need to set or can you point me to a manual where required settings and configurations are described in on eplace?

  • Hi Thomas,

    Have you tried with the default firmware that comes along with SDK? Does that err out as well?

    Best Regards,
    Keerthy

  • Thomas,

    Please confirm if you are using the same timer that dsp is using for watchdog for some other purpose? If so could be causing a conflict.
    Watchdog timer is enabled though device tree and dsp1 uses timer10 for watchdog by default.

    Also, you can get the crash dump by running
    cat /sys/kernel/debug/remoteproc/remoteproc2/trace0_last which might give more info on the crash?

    Best regards,

    Dave

  • Yes, the same happens with the default firmware.

  • thanks I will try the crash dump. I will check again for the timers in the device tree, however this thing is convoluted and so far I did not see an obvious conflict. Is there some means to gather usable information from the running system?

  • This is the trace output:

    root@cpm:~# cat /sys/kernel/debug/remoteproc/remoteproc2/trace0_last
    [ 0.000] Watchdog enabled: TimerBase = 0x48086000 Freq = 19200000
    [ 0.000] Watchdog_restore registered as a resume callback
    [ 0.000] 17 Resource entries at 0x95000000
    [ 0.000] [t=0x000502c9] xdc.runtime.Main: --> main:

  • I cannot find any other usage of timer10, can I somehow check if the timer itself is correctly configured?

    I read also about configuration of the interrupt crossbar from u-boot, could this also influence this behavior?

  • Do you have some further advice on how to get this running.

    Some step by step on what to check or howto would be appreciated.

  • I gave it another shot: I echanged the watchdog timer definitions for dsp1 and dsp2 in the devitree, now I get the watchdog triggers in the traces for remoteproc 0 and 1. However the host application still does not run.

    I also got this from the lad logfilfe:

    [211.464714] Sending response...
    [211.464752] Retrieving command...
    [212.464974] LAD_NAMESERVER_GETUINT32: calling NameServer_getUInt32(0x35548, 'DSP1:MsgQ:01')...
    [212.465021] NameServer_getLocal: entry key: 'DSP1:MsgQ:01' not found!
    [212.465041] NameServer_getRemote: no socket connection to processor 1
    [212.465059] NameServer_getRemote: no socket connection to processor 2
    [212.465076] NameServer_getRemote: no socket connection to processor 3
    [212.465093] NameServer_getRemote: no socket connection to processor 4
    [212.465111] value = 0x80
    [212.465127] status = -5
    [212.465145] DONE
    [212.465162] Sending response...
    [212.465201] Retrieving command...
    [213.151511] LAD_MESSAGEQ_DESTROY: calling MessageQ_destroy()...
    [213.151546] MessageQ_destroy: entered, refCount=1
    [213.151564] MessageQ_delete: deleting 0x35630
    [213.151596] MessageQ_delete: returning 0
    [213.151616] MessageQ_destroy: exiting, refCount=0
    [213.151634] status = 0

    anything else I am missing or can check?

  • Hi Thomas,

    Are you still facing this issue?

    Thomas Kaufmann1 said:

    I gave it another shot: I echanged the watchdog timer definitions for dsp1 and dsp2 in the devitree, now I get the watchdog triggers in the traces for remoteproc 0 and 1. However the host application still does not run.

    Can you let me know, does that mean that after you switched the watchdog timer definitions you no longer see the watchdog expiration? Are you loading both dsp1 and dsp2, or just dsp1?

    Thanks,

    Angela

  • Yes the issue is still pending, however I did not work on this topic for some time due to lack of input.

    I think I just wanted to see in this case if the watchdog timer settings have some affect, I think they do.

    However I am not yet too far into the topic as that I can make much sense out of the eroor messages.

    Is it possible to run the DSP without watchdog, for initial testing? If yes how?

    Are there some specific instructions regarding using the DSPs? As stated before, on the IDK it works.

  • Hi Thomas,

    For disabling the watchdog, please check section "10.2.5.3.5.3. Linux and Android – Disabling Watchdog" of the following link http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#ipc-debugging-tools-and-techniques-on-am57xx

    This will cause the kernel driver to not initialize the watchdog timer for the core. Note, however, that if some other driver or app is initializing the same timer that remote core firmware is using for watchdog, then the remote core image will detect it and think that watchdog is enabled.

    If watchdog is still expiring after removing it from the DT for the node, please check that the same timer is not being used by another application in the system.

    Thanks,

    Angela