PROCESSOR-SDK-OMAPL138: Problem loading DSP firmware

Hi, Alireza,

Are you downloading the .out file which runs ok using CCS? If that is the case, the .out file can't be used as is when using remoteproc to download. Remoteproc reads the resource table for the info to download, and the resource table needs to build into the .out file. Please read the IPC User's Guide on Resource Table for more info.

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_Foundational_Components.html#resource-custom-table

Rex

Thanks Rex.

There are so much information there to digest !

So first I put some more questions.

1. Is there another way to load and start DSP rather than IPC?

2. Is it possible to add resource table in CCS project?

3 Does this mean that I can only develop my dsp firmware on linux?

Best Regards,

Alireza

Thank you very much Rex.

1. I mean easier way. Though I think is a silly question after all.

2,3. I added the rsc_table_omapl138.h to my ccs project on windows host. It is a starterware modified example project. But I get a bunch of error, if that is all I have to do!?

By the way I have mistakenly verified your answer is there a way to unmark this.

Thanks

Hi, Alireza,

It will depends on environment, Linux or RTOS, on ARM core. If Linux, download is through remoteproc which requires resource table info. If RTOS, the bootloader loads the DSP app to DSP.

I don't know how to unmark it, but as long as there is reply, it stays open, and we can continue working on this. I'll have an expert familiar with DSP programming to help.

Rex

Hi Rex,

I added resource table and build project but the same result.

Is it possible that a resource is locked by linux cause dsp boot failure?

I use edma and timer 2.

Regards

Hi, Alireza,

All resources/peripheral can only be initialized once either by Linux or DSP, but not both. Be sure timer 2 is not configured by Linux. I am not sure how edma should configure. You may want to try having Linux configures it and used by DSP. or to verify the functionality first, let the DSP configures it, not Linux, and see if DSP app can be loaded and run.

Rex

Hi Rex

I eliminated everything and my application now only include a gpio pin setup for toggling a LED in loop.

since command:

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

output is

-sh: echo: write error: Invalid argument

I become suspicious that maybe my dsp firmware is expected to accept argument!?

Several times it has been mentioned in IPC guid that it can communicate with a core running SYS/BIOS applications.

My application is not a sys/bios application and I did everything by directly writing to registers. Is that an issuse?

Regards

Hi, Alireza,

Hmm... I am able to do it. May be try with TI example?

root@omapl138-lcdk:/sys/class/remoteproc/remoteproc0# ls -l /lib/firmware
drwxr-xr-x 3 root root 4096 Jul 7 2019 ipc
lrwxrwxrwx 1 root root 54 Jul 8 2019 rproc-dsp-fw -> ipc/ti_platforms_evmOMAPL138_DSP/messageq_single.xe674

root@omapl138-lcdk:/sys/bus/platform/drivers/davinci-rproc# cd /sys/class/remoteproc/remoteproc0
root@omapl138-lcdk:/sys/class/remoteproc/remoteproc0# ls
device firmware power state subsystem uevent virtio0
root@omapl138-lcdk:/sys/class/remoteproc/remoteproc0# cat state
running
root@omapl138-lcdk:/sys/class/remoteproc/remoteproc0# echo stop > state
remoteproc remoteproc0: stopped remote processor dsp
root@omapl138-lcdk:/sys/class/remoteproc/remoteproc0# echo start > state
remoteproc remoteproc0: powering up dsp
remoteproc remoteproc0: Booting fw image rproc-dsp-fw, size 4070504
virtio_rpmsg_bus virtio0: rpmsg host is online
virtio_rpmsg_bus virtio0: creating channel rpmsg-proto addr 0x3d
alloc_contig_range: [c6440, c6441) PFNs busy
remoteproc remoteproc0: registered virtio0 (type 7)
remoteproc remoteproc0: remote processor dsp is now up
alloc_contig_range: [c6440, c6441) PFNs busy
root@omapl138-lcdk:/sys/class/remoteproc/remoteproc0#

Does "dmesg | grep -i dsp" show anything or is the DSP app actually running successfully?

Rex

Hi Rex

Yes I can run examples.

I added following line to cmd file:

    .resource_table  load > 0xc3100000, type = NOINIT

and binding report :

header-less resource table

also

root@omapl138-lcdk:/sys/bus/platform/drivers/davinci-rproc# cat /debug/remoteproc/remoteproc0/resource_table
No resource table found

Thanks.

Comparing example out file and mine, there is no resource table at address 0xC3100000 in my file.

CCS seems to ignore rsc_table_omapl138.h.

Thanks.

Hi

I successfully build my resource table but i get:

bad phdr da 0x11800000 mem 0x224f4

failed to load program segment:-22

All different errors return -22 !!!

In a thread I read that loading DSP code to IRAM/L2RAM is not supported for OMAP-L138 at the moment.

Is it true? If yes it is very disappointing. So there is no way to fully use Omapl138 dsp with linux!? though I did this years ago with syslink. At least its should have mentioned somewhere in user guide.

I should conclude that omapl138 is getting deprecated.

Regards

Hello,

The OMAP-L138 is not getting deprecated anytime soon. At TI, we know that semiconductor product longevity and supply continuity are important to you; they are important to us as well. TI’s product life cycles are typically 10 to 15 years and often extend longer, consistent with many customers’ requirements. We are committed to product longevity for our customers and have strategies and internal policies in place to uphold this commitment.

You can read more about our commitment to product longevity and continuity of supply here: http://www.ti.com/support-quality/quality-policies-procedures/product-life-cycle.html?eloquaCampaignId=1410&utm_campaign=SDI%203_general%20awareness_092719&utm_medium=corp_email&utm_source=corp_eloqua

Regarding your issue,

Loading DSP code to IRAM is not supported at the moment by remoteproc. You'll need to add a patch for this yourself as discussed in this thread: https://e2e.ti.com/support/processors/f/791/t/774854#pi320966=2

What is the reason for needing to use IRAM instead of DDR?

Loading DSP code running SYSBIOS is supported by IPC and can be easily loaded via remoteproc. IPC is tightly coupled with SYSBIOS and XDCtools so it does not support baremetal applications. Note: this is not to say it cannot be done, just that the IPC drivers/examples do not have the support for it for this device. 

Regards,
Sahin

Thank you Sahin.

The thread that you included is the same that I mentioned earlier. It does not seem to be a successful practice.

I use IRAM as valuable resource which can significantly speed up signal processing.

Basically I do not  need any feature of IPC or SYS/BIOS, I only only want it to load my firmware and run it.

Temporarily changed IRAM segment to DDR, firmware can be loaded now with no error but still not running correctly.

The only difference with the working example I found is when I run this command

cat /debug/remoteproc/remoteproc0/carveout_memories

        Name: DSP_MEM_DATA
        Virtual address: 33db07ec
        DMA address: 0xc3000000
        Device address: 0xc3100000
        Length: 0xf00000 Bytes

I don't know where this DMA address came from which is 0xC3100000 in working example.

Regards