AM5728: DSP Remoteproc issue

Hello Geek13,

Yes, you should be able to run applications on all cores.

1) I want to make sure I understand your setup. Is this correct?:
Application1 on DSP1 does mailbox communication with Linux ARM.
Application1 works as expected.
Application2 on DSP2 does mailbox communication with PRU core.
Application2 works are expected.
RemoteProc is used to load all slave cores.
You are having issues when you try to port Application1 to DSP2. Your processor hangs when you try to start DSP2.

2) Are you able to successfully run Application1 on DSP1 at the same time as running Application2 on DSP2?

3) Do you get different behavior if you load DSP1 and DSP2 using the bind/unbind method? In the Linux IPC Documentation, search for "To reload DSP1 with this new executable, we perform the following steps".

Regards,

Nick

Hi Nick, 

Yeah any of the application work fine with DSP1 core but not with DSP2, loaded from Linux core using Remoteproc.

Am using 

For DSP1

echo 'stop' > /sys/class/remoteproc/remoteproc2/state

echo 'start' > /sys/class/remoteproc/remoteproc2/state

For DSP2

echo 'stop' > /sys/class/remoteproc/remoteproc3/state

echo 'start' > /sys/class/remoteproc/remoteproc3/state

But unable to run application on DSP2..

Another query Nick, How to check DSP processing speed without RTOS. Because am running my DSP core at 600MHz that I already confirm by pulling that clock on provided ClkOut pin. But still am not seen good performance of DSP.

Is there any benchmark technique by which I can seen real processing on DSP core without RTOS.

Regards,

Geek13

Hi Nick, 

  On DSP2, also not able to run server_dsp2.xe66 example of IPC. While able to access server_dsp1.xe66.

   Here I used prebuild binaries provided in SDK.

   Both binaries are linked to their respective cores.

  Regards,

   Geek13

Hello Geek13,

Could you elaborate a bit more on your question "How to check DSP processing speed without RTOS"? e.g., are you asking if we have any benchmarks for DSPs running bare metal code instead of running RTOS?

Could you please post the terminal output for the server_dsp2.xe66 example? Are you looking at ex02_messageq?

Regards,

Nick

Hi Nick,

 As per my previous query, am able to do remoteproc on DSP1 & DSP2 core.

 44000000.ocp:L3 Custom Error: MASTER DSP2_DMA TARGET L4_PER3_P3 (Read): Data Access in User mode during Functional access on  DSP2 core error gone after initialize timer for DSP2 in cfg file

But not able to resolve similar error as mention below on DSP1:

44000000.ocp:L3 Custom Error: MASTER DSP1_MDMA TARGET L4_PER2_P3 (Read): Data Access in User mode during Functional access

Although am able to run my application on both core simultaneously but with below exception on DSP1:

echo 'start' > /sys/class/remoteproc/remoteproc2/state
[  409.911073] remoteproc remoteproc2: powering up 40800000.dsp
[  409.920275] remoteproc remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 2907568
[  409.938200] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[  409.944093] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[  409.950025] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[  40/KW▒▒%▒͝}▒▒́▒▒▒ѥ▒▒▒▒▒͝▒B▒▒сJ́z▒▒▒▒▒5R▒ ▒S')▒▒▒ʂ▒jjjjjjjjjjjj▒▒сB▒ɕ▒▒jjjjjjjjjjjj▒▒[  409.965002] WARNING: CPU: 0 PID: 104 at /oe/bld/build-CORTEX_1/arago-tmp-external-linaro-toolchain/work-shared/am57xx-evm/kernel-source/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x254/0x370
[  409.965006] 44000000.ocp:L3 Custom Error: MASTER DSP1_MDMA TARGET L4_PER2_P3 (Read): Data Access in User mode during Functional access
[  409.965009] Modules linked in: sha512_generic sha512_arm sha256_generic sha1_generic sha1_arm_neon sha1_arm md5 cbc aes_arm_bs crypto_simd cryptd xfrm_user xfrm4_tunnel ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo bc_example(O) xhci_plat_hcd xhci_hcd pru_rproc pruss_intc pruss dwc3 udc_core snd_soc_simple_card snd_soc_simple_card_utils snd_soc_omap_hdmi_audio pvrsrvkm(O) ahci_platform ti_vpe libahci_platform libahci ti_sc omap_aes_driver ti_csc omap_wdt pruss_soc_bus libata omap_sham dwc3_omap ti_vpdma scsi_mod rtc_omap extcon_palmas rtc_palmas snd_soc_tlv320aic3x at24 rtc_ds1307 omap_des des_generic crypto_engine omap_crypto omap_remoteproc virtio_rpmsg_bus rpmsg_core remoteproc sch_fq_codel uio_module_drv(O) uio ftdi_sio usbserial usbcore usb_common gdbserverproxy(O) cryptodev(O) cmemk(O)
[  409.965148] CPU: 0 PID: 104 Comm: systemd-udevd Tainted: G        W  O    4.14.67-gd315a9bb00 #1
[  409.965151] Hardware name: Generic DRA74X (Flattened Device Tree)
[  409.965152] Backtrace:
[  409.965162] [<c020b5bc>] (dump_backtrace) from [<c020b8a0>] (show_stack+0x18/0x1c)
[  409.965167]  r7:00000009 r6:600f0193 r5:00000000 r4:c1053a10
[  409.965175] [<c020b888>] (show_stack) from [<c092b128>] (dump_stack+0x90/0xa4)
[  409.965185] [<c092b098>] (dump_stack) from [<c022b780>] (__warn+0xec/0x104)
[  409.965188]  r7:00000009 r6:c0bd9760 r5:00000000 r4:eddf5a88
[  409.965196] [<c022b694>] (__warn) from [<c022b7d8>] (warn_slowpath_fmt+0x40/0x48)
[  409.965200]  r9:0000001a r8:ee9ca850 r7:c0bd9ab0 r6:00000002 r5:c0bd968c r4:c0bd9730
[  409.965207] [<c022b79c>] (warn_slowpath_fmt) from [<c051ab3c>] (l3_interrupt_handler+0x254/0x370)
[  409.965209]  r3:ee9ca6c0 r2:c0bd9730
[  409.965212]  r4:80080003
[  409.965218] [<c051a8e8>] (l3_interrupt_handler) from [<c027f104>] (__handle_irq_event_percpu+0x6c/0x134)
[  409.965223]  r10:c105540d r9:ee9c8500 r8:00000017 r7:eddf5bac r6:00000000 r5:ee9c8500
[  409.965225]  r4:ee9cabc0
[  409.965230] [<c027f098>] (__handle_irq_event_percpu) from [<c027f1f0>] (handle_irq_event_percpu+0x24/0x60)
[  409.965234]  r10:200f0113 r9:eddf4000 r8:ee808000 r7:00000000 r6:c10093ac r5:ee9c8500
[  409.965237]  r4:ee9c8500
[  409.965242] [<c027f1cc>] (handle_irq_event_percpu) from [<c027f26c>] (handle_irq_event+0x40/0x64)
[  409.965244]  r5:ee9c8564 r4:ee9c8500
[  409.965251] [<c027f22c>] (handle_irq_event) from [<c0282b80>] (handle_fasteoi_irq+0xac/0x160)
[  409.965254]  r7:00000000 r6:c10093ac r5:ee9c8564 r4:ee9c8500
[  409.965260] [<c0282ad4>] (handle_fasteoi_irq) from [<c027e354>] (generic_handle_irq+0x2c/0x3c)
[  409.965263]  r7:00000000 r6:00000000 r5:00000017 r4:c0e64afc
[  409.965268] [<c027e328>] (generic_handle_irq) from [<c027e8dc>] (__handle_domain_irq+0x64/0xbc)
[  409.965273] [<c027e878>] (__handle_domain_irq) from [<c0201474>] (gic_handle_irq+0x44/0x80)
[  409.965277]  r9:eddf4000 r8:fa213000 r7:fa212000 r6:eddf5c68 r5:fa21200c r4:c1004000
[  409.965283] [<c0201430>] (gic_handle_irq) from [<c020c478>] (__irq_svc+0x58/0x8c)
[  409.965286] Exception stack(0xeddf5c68 to 0xeddf5cb0)
[  409.965290] 5c60:                   c1058378 200f0113 c0e5e248 00006f24 c0e5e248 c1003c7c
[  409.965294] 5c80: c1003da4 c1003e48 0000073a 00000000 200f0113 eddf5cc4 eddf5cc8 eddf5cb8
[  409.965297] 5ca0: c0219284 c0943da4 600f0113 ffffffff
[  409.965302]  r9:eddf4000 r8:0000073a r7:eddf5c9c r6:ffffffff r5:600f0113 r4:c0943da4
[  409.965311] [<c0943d7c>] (_raw_spin_unlock_irqrestore) from [<c0219284>] (a15_erratum_get_cpumask+0xdc/0xe8)
[  409.965317] [<c02191a8>] (a15_erratum_get_cpumask) from [<c020ef4c>] (broadcast_tlb_mm_a15_erratum+0x70/0xb8)
[  409.965322]  r10:f84fe75f r9:c02197b8 r8:edd676c0 r7:bed51000 r6:ffffe000 r5:edd676c0
[  409.965324]  r4:00000000
[  409.965330] [<c020eedc>] (broadcast_tlb_mm_a15_erratum) from [<c020f25c>] (flush_tlb_page+0x94/0xd0)
[  409.965333]  r6:04e00000 r5:edf16ea0 r4:edf16ea0
[  409.965341] [<c020f1c8>] (flush_tlb_page) from [<c0317960>] (ptep_clear_flush+0x68/0x74)
[  409.965343]  r4:f7938fdf
[  409.965349] [<c03178f8>] (ptep_clear_flush) from [<c030a470>] (wp_page_copy+0x37c/0x604)
[  409.965353]  r9:f84fe75f r8:00e00000 r7:edf16ea0 r6:efe8d3b8 r5:efe72be0 r4:eddf5e40
[  409.965357] [<c030a0f4>] (wp_page_copy) from [<c030c16c>] (do_wp_page+0xa8/0x5a0)
[  409.965362]  r10:edd676fc r9:00000055 r8:ffffe000 r7:00000000 r6:f79387df r5:edf16ea0
[  409.965364]  r4:eddf5e40
[  409.965369] [<c030c0c4>] (do_wp_page) from [<c030efb0>] (handle_mm_fault+0x774/0xc50)
[  409.965373]  r8:ffffe000 r7:00000000 r6:f79387df r5:00000040 r4:f79387df
[  409.965378] [<c030e83c>] (handle_mm_fault) from [<c0213fd0>] (do_page_fault+0x134/0x348)
[  409.965382]  r10:edd676fc r9:00000055 r8:bed51060 r7:00000a0f r6:edd676c0 r5:edf09440
[  409.965384]  r4:eddf5fb0
[  409.965388] [<c0213e9c>] (do_page_fault) from [<c020127c>] (do_DataAbort+0x38/0xb8)
[  409.965392]  r10:0048e008 r9:fffffffe r8:eddf5fb0 r7:bed51060 r6:c0213e9c r5:00000a0f
[  409.965394]  r4:c1008cbc
[  409.965398] [<c0201244>] (do_DataAbort) from [<c020c780>] (__dabt_usr+0x40/0x60)
[  409.965401] Exception stack(0xeddf5fb0 to 0xeddf5ff8)
[  409.965405] 5fa0:                                     00000001 00000020 00000021 99538500
[  409.965408] 5fc0: b6f50cf0 004e19f8 00000441 0048e008 004e19f8 fffffffe 0048e008 004e19f8
[  409.965412] 5fe0: 0048cc90 bed51080 004683b8 b6d992b0 200f0030 ffffffff
[  409.965415]  r8:30c5387d r7:30c5387d r6:ffffffff r5:200f0030 r4:b6d992b0
[  409.965418] ---[ end trace d33cf0c8865d4a21 ]---
[  410.491535] remoteproc remoteproc2: registered virtio0 (type 7)
[  410.497480] remoteproc remoteproc2: remote processor 40800000.dsp is now up
root@am57xx-evm:~#

Regards,

Geek13

Hi Nick,

 Yeah I want to check processing power of DSP core without RTOS. For that am asking above.

 Is there any way to look that.

 Regards,

Geek13

Geek13 said:

But not able to resolve similar error as mention below on DSP1:

44000000.ocp:L3 Custom Error: MASTER DSP1_MDMA TARGET L4_PER2_P3 (Read): Data Access in User mode during Functional access

 

Does that issue also occur when running on DSP2?  Does it happen repeatably, e.g. every time you run the program and always at the same spot?  Do you know what the DSP is accessing when the error occurs?  What peripherals are being touched in your DSP code?

Hi Brad,

Yeah this error is repeatedly seen on dsp1. As I mention on DSP2 this resolved by configuring timer in cfg file.

Application on both the cores DSP1 & DSP2 run successfully but with error on DSP1 I mentioned above

Regards,

Geek13

For future readers,

AM57xx ex02_messageq in Processor SDK 5.0 through Processor SDK 6.0 has a known bug for dsp2. This bug is caused by an incorrect timer configuration in the Dsp2.cfg file. The bug is fixed in Processor SDK 6.1.

Output error will look like 
"L3 Custom Error: MASTER DSP2_DMA TARGET L4_PER3_P3 (Idle): Data Access in User mode during Functional access"

Workaround: in Dsp2.cfg:

+ /* Configure BIOS clock source as GPTimer6 */
+ Clock.timerId = 5;

Timer.create(Clock.timerId, Clock.doTick, timerParams);

Regards,

 Nick

Hello Geek13,

I am going to mark the thread resolved for now. Feel free to reply if you'd like to continue the discussion here. Thanksgiving next week may slow down replies, but we will get back to you.

Regards,

Nick