Status - Running TI SDK-Built C66 DSP Example EXE on BB-X15 - Beagleboard Debian

GoogleGroups
1

Today, it looks like I’m able to load the example C66 DSP executable built under the TI SDK RTOS folder ipc_3_50_04_08/examples/DRA7XX_linux_elf/ex02_messageq and successfully run it. The other day I was getting remoteproc errors (-2) and a message indicating that the resource table was not found. I’m not sure what was going on, except the status of DSP1 was showing up as Offline instead of Running. I followed the instructions to transition DSP1 to the Running state, but it remained Offline.

Today, when I tried that same step, it transitioned from Suspended to Running.

Following are the steps I took to get the Linux app, built under the latest TI SDK Linux folder, exchanging messages with DSP1 (also built under the latest TI SDK).

root@beaglebone:/home/debian/ipc-starter/debug# cat /sys/kernel/debug/remoteproc/remoteproc*/name
4b234000.pru
4b238000.pru
4b2b4000.pru
4b2b8000.pru
58820000.ipu
55020000.ipu
40800000.dsp
41000000.dsp
root@beaglebone:/home/debian/ipc-starter/debug# cat /sys/class/remoteproc/remoteproc*/state
offline
offline
offline
offline
suspended
suspended
suspended
suspended
root@beaglebone:/home/debian/ipc-starter/debug# echo on > /sys/bus/platform/devices/40800000.dsp/power/control
root@beaglebone:/home/debian/ipc-starter/debug# cat /sys/class/remoteproc/remoteproc*/state
offline
offline
offline
offline
suspended
suspended
running
suspended
root@beaglebone:/home/debian/ipc-starter/debug#

root@beaglebone:/lib/firmware# mv dra7-dsp1-fw.xe66 dra7-dsp1-fw.xe66.stock_image

root@beaglebone:/lib/firmware# ln -s /home/debian/ipc-starter/debug/server_dsp1.xe66 dra7-dsp1-fw.xe66

cd /sys/bus/platform/drivers/omap-rproc/

root@beaglebone:/sys/bus/platform/drivers/omap-rproc# echo 40800000.dsp > unbind

[ 1952.619664] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[ 1952.619707] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[ 1952.621403] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[ 2449.430488] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[ 2449.430933] remoteproc remoteproc6: stopped remote processor 40800000.dsp
[ 2449.431164] remoteproc remoteproc6: releasing 40800000.dsp

root@beaglebone:/sys/bus/platform/drivers/omap-rproc# echo 40800000.dsp > bind

[ 1952.619664] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[ 1952.619707] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[ 1952.621403] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[ 2449.430488] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[ 2449.430933] remoteproc remoteproc6: stopped remote processor 40800000.dsp
[ 2449.431164] remoteproc remoteproc6: releasing 40800000.dsp
[ 2594.517030] omap-rproc 40800000.dsp: assigned reserved memory node dsp1-memory@99000000
[ 2594.517162] remoteproc remoteproc6: 40800000.dsp is available
[ 2594.532869] remoteproc remoteproc6: powering up 40800000.dsp
[ 2594.532890] remoteproc remoteproc6: Booting fw image dra7-dsp1-fw.xe66, size 4407080
[ 2594.539898] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[ 2594.539936] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[ 2594.540034] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[ 2594.545910] alloc_contig_range: [99000, 99003) PFNs busy
[ 2594.546343] alloc_contig_range: [99004, 99007) PFNs busy
[ 2594.546807] alloc_contig_range: [99000, 99003) PFNs busy
[ 2594.547230] alloc_contig_range: [99004, 99007) PFNs busy
[ 2594.556580] alloc_contig_range: [99600, 99700) PFNs busy
[ 2594.564388] virtio_rpmsg_bus virtio2: rpmsg host is online
[ 2594.564464] remoteproc remoteproc6: registered virtio2 (type 7)
[ 2594.564474] remoteproc remoteproc6: remote processor 40800000.dsp is now up
[ 2594.565391] virtio_rpmsg_bus virtio2: creating channel rpmsg-proto addr 0x3d

root@beaglebone:/home/debian/ipc-starter/debug# ./app_host -l
→ main:
Processor List
procId=0, procName=HOST
procId=1, procName=IPU2
procId=2, procName=IPU1
procId=3, procName=DSP2
procId=4, procName=DSP1
root@beaglebone:/home/debian/ipc-starter/debug# ./app_host DSP1
→ main:
→ Main_main:
→ App_create:
App_create: Host is ready
← App_create:
→ App_exec:
App_exec: sending message 1
App_exec: sending message 2
App_exec: sending message 3
App_exec: message received, sending message 4
App_exec: message received, sending message 5
App_exec: message received, sending message 6
App_exec: message received, sending message 7
App_exec: message received, sending message 8
App_exec: message received, sending message 9
App_exec: message received, sending message 10
App_exec: message received, sending message 11
App_exec: message received, sending message 12
App_exec: message received, sending message 13
App_exec: message received, sending message 14
App_exec: message received, sending message 15
App_exec: message received
App_exec: message received
App_exec: message received
← App_exec: 0
→ App_delete:
← App_delete:
← Main_main:
← main:

root@beaglebone:/home/debian/ipc-starter/debug# uname -a
Linux beaglebone 4.14.108-ti-r131 #1buster SMP PREEMPT Tue Mar 24 19:18:36 UTC 2020 armv7l GNU/Linux

root@beaglebone:/home/debian/ipc-starter/debug# cat /etc/dogtag
BeagleBoard.org Debian Buster IoT TIDL Image 2020-04-06

Also, I tried this same example on the latest SDK image built from the pre-built binaries:

← main:
root@am57xx-evm:~/ipc-starter# ./app_host -l
→ main:
Processor List
[ 1623.665988] omap-iommu 58882000.mmu: 58882000.mmu: version 2.1
[ 1623.703839] omap-iommu 41501000.mmu: 41501000.mmu: version 3.0
[ 1623.710423] omap-iommu 41502000.mmu: 41502000.mmu: version 3.0
[ 1623.717147] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[ 1623.724224] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
procId=0, procName=HOST
procId=1, procName=IPU2
procId=2, procName=IPU1
procId=3, procName=DSP2
procId=4, procName=DSP1
root@am57xx-evm:~/ipc-starter# ./app_host DSP1
→ main:
[ 1636.665992] omap-iommu 58882000.mmu: 58882000.mmu: version 2.1
[ 1636.703878] omap-iommu 41501000.mmu: 41501000.mmu: version 3.0
[ 1636.710490] omap-iommu 41502000.mmu: 41502000.mmu: version 3.0
[ 1636.717216] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[ 1636.724309] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
→ Main_main:
→ App_create:
App_create: Host is ready
← App_create:
→ App_exec:
App_exec: sending message 1
App_exec: sending message 2
App_exec: sending message 3
App_exec: message received, sending message 4
App_exec: message received, sending message 5
App_exec: message received, sending message 6
App_exec: message received, sending message 7
App_exec: message received, sending message 8
App_exec: message received, sending message 9
App_exec: message received, sending message 10
App_exec: message received, sending message 11
App_exec: message received, sending message 12
App_exec: message received, sending message 13
App_exec: message received, sending message 14
App_exec: message received, sending message 15

App_exec: message received
App_exec: message received
App_exec: message received
← App_exec: 0
→ App_delete:
← App_delete:
← Main_main:
← main:

For building the TI SDK RTOS examples (IMU, DSP, host), and for instructions on how to get the Linux host to load and run the exe’s, I followed this:http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_IPC.html#ipc-for-am57xx

As I get additional results worth posting, I’ll do so. I THINK my next-steps are to learn how to build SDK RTOS DSP images with the resource table, and then load and debug via CCS.

2

Great news. It might be helpful to share this in a new post in bone group I put up too much negative stuff in our thread.

That way when they ask every two weeks we can refer to your new post.

I still stand by my comments about the users being too needy.

But sharing is right thing to do

Congratulations

3

Hey Mark,

This IS that separate forum thread for C66<->Beaglebone, BB-X15 Dev…

Let me know if it needs a clearer, more compact title.

Once I get to implementing DSP/SDR algorithms on the C66, I’m going to assume that the community here doesn’t want to see those examples, just those that are related to interfacing DSP to Linux, debugging the DSP, enabling peripherals on the DSP, etc…

Maybe a reasonable next-step would be repeating this example, but loading the DSP example program using CCS/JTAG, running, and then seeing if the app can still pingpoing messages with it (as shown above).

4

Jeff

Your call maybe this is good enough I deleted my previous post it wasn’t intended it’s gone.

I’d start a new thread and repaste summary but you did all the work I did nothing but encourage you so share in whatever way you feel is best.

Congratulations I’m probably going to purchase an evm that supports jtag now and skip Linux on ARM I will run RTOS on both that way I have skills hiring managers need :wink::smiley::rofl::joy::grinning: like DSP and hard realtime and CCS source level debug of RTOS and bare bones using JTAG and C6xx binary support and best off documented explanations of the IPC memory layout. Dropping binaries on Linux is not a skill set I want on my resume and I expect documents. ASK is my solution

Mark

5

<<THINK my next-steps are to learn how to build SDK RTOS DSP images with the <<resource table, and then load and debug via CCS.

That’s all documented in the SDK documents including how CCS put the cores in the correct state with gel files. That’s the beauty of CCS /JTAG.

the same may need to be done using IPC in an actual Linux app I don’t know.

If I were you I would see if you can generate a simple DSP application in CCS of your own that actually works then make sure it still works having rproc load it.

I’d be Leary of modifying these canned examples or building/ modifying a new DSP program in the SDK make file. It’s possible something crucial isn’t explained.

Rapidly debugging in source level in CCS is orders of magnitude faster than all the hocus pocus your doing to get Linux to load DSP and using printf.

That arm loading part can be done only once at end when DSP application is done.

Interesting the x15 uses a beaglebone prompt in your screen captures of prompt it’s actually a Beagleboard. Minor detail. And your original thread used an EVM prompt. That may confuse some

You have a fan for board or is that just needed for the AI?

That’s nice that the bbx15 requires no mods for JTAG right? Connectors present

I guess you bought a jtag for home use? Which one?

Just anticipating questions users may ask trying to replicate the SDK DSP running on Debian and then wanting to follow in the footsteps of writing DSP apps

6

I found this in some documents I will post link to this document it covers IPC and the document Jeff referenced is part of this.

Snippet

The IOMMU is programmed by the ARM based on the associated resource table. If you’re planning any memory changes then you’ll want to make a custom resource table as described in the wiki page IPC Resource customTable.

http://software-dl.ti.com/processor-sdk-linux/esd/docs/04_03_00_05/linux/Foundational_Components.html#id127

While a good resource it’s talking about older versions of CCS I’d recommend finding the equivalent doc from the latest SDK and follow the recommended version of CCS in that documents

This document discusses Linux device driver’s in detail as well I’d guess the Debian kernel has similar read me docs but don’t know.

This doc also shows a cookbook approach with screen captures on installing tools and even using CCS to debug the Linux kernel with GAB

This is the level of detail I was used to seeing 10 year’s ago for omap4.

Unfortunately some links are broken and give messages this wiki has been taken down. That’s scary.

Updating documents of this detail has to be daunting and a huge task

Examples are covered in detail about modifying from RTOS to bare metal to Linux

I’d say there’s enough info here to fill a summer of full time experiments while most users won’t use all the details beginners should be quickly cognizant of the complexity of the AM72x

One last negative this document mentions EVM and black and white bones.

I’ve found a version of this document that was newer that said the x15 and AI was supported but judging by questions in E2E forum many have struggled that’s no fault of TI this chip is amazing and very complex.

All the cores with benchmark programs and examples are covered that’s nothing short of amazing to document yet alone support.

New Users must do their homework to succeed there no easy shortcut

7

First page here lists the boards supported by RTOS SDK

Dev guide RTOS

https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/index.html

Dev Guide Linux

https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/linux/index.html

quick start discusses jtag , CCS, bare metal and has 2 RTOS videos

3 jtag are supported make sure to research correct jtag connector is present on board you buy and works by googling

https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/index_overview.html#emulator-support

No gel file no fun make sure CCS has one for your board

The support for connecting a JTAG to the EVM to debug software is included in the CCS package. In some cases, additional modifications to configuration GEL files are provided separately. To get the latest version, perform a CCS Check for Updates.

Templates ie how to import samples into CCS

https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/index_examples_demos.html

8

Thanks for cross referencing all the docs Mark!

I’m sorry I missed this, but I stumbled upon an older GSOC project, libdsp-x15, which looks like it adds an FFT, IFFT, and biquad/sos functionality which are callable from a library added to Linux. Not sure if that’s part of OpenCL…

https://github.com/henrix/libdsp-x15

9

I do have a question. Which version of CCS are you planning on using?

Looks Great as you know I have no hardware I easily followed your initial post found the source code and traced what you were doing its all documented in the link you provided ie the IPC DSP doc

your example runs from DDR using CCS and JTAG at least on the EVM and as binaries the way you did it but with no HW I cant replicate CCS success or your approach until Im confident Im buying a board that works out of box with CCS/JTAG EVM is cost prohibitive for probally everyone that asked about using DSP

Im very confident it works on the EVM the BBAI is another story its not covered in the CCS example you ran just EVM the difference will be gel files and xml files needed by CCS

adding a few more docs

I think the biggest hurdle users face is the JTAG doesnt work without mods on the BBAI hopefully that gets fixed ASAP

A few more important docs

2.1.3 OpenMP Model OpenMP is an Application Programming Interface (API) for developing multi-threaded applications in C/C++ or Fortran for shared-memory parallel (SMP) architectures.

https://www.ti.com/lit/pdf/sprab27

https://www.ti.com/lit/pdf/sprui04

4.4.1. IPC User’s Guide

4.1. TI-RTOS Kernel — Processor SDK RTOS Documentation

[

4.1. TI-RTOS Kernel — Processor SDK RTOS Documentation

](https://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_Foundational_Components.html#ti-rtos-kernel)

ESSENTIAL HOWTO FOR Building LINUX SDK on Linux Host and using CCS in linux

6. How to Guides — Processor SDK Linux Documentation

[

6. How to Guides — Processor SDK Linux Documentation

](https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_02_00_81/linux/How_to_Guides.html)

Thanks for cross referencing all the docs Mark!

I’m sorry I missed this, but I stumbled upon an older GSOC project, libdsp-x15, which looks like it adds an FFT, IFFT, and biquad/sos functionality which are callable from a library added to Linux. Not sure if that’s part of OpenCL…

https://github.com/henrix/libdsp-x15

10

Mark,

When I downloaded TI Linux SDK and TI RTOS SDK, I downloaded CCS from the same listing of products from TI for 57xx.

I ended up downloading CCS, 9.3.

I’d love to get an AI and am waiting for updates on the JTAG fix as well…

Once they implement the JTAG fix, wonder how distributors will handle that if they still are stocking the older version prior to the fix??

11

Hello Jeff

Summary of Mark and Jeff Research

This thread has validated DSP on am5728 x 15 platforms on everything but CCS which hasnt has been tested by us yet. Either board works to learn DSP.But EVM has support in E2E its their product they have to support it

Beagleboard X15 DSP support IS this thread :wink: this is our humble attempt to help the community.

Until we know more we want readers to understand the following.

#########START of AM57x DSP summary

For DSP you need an EVM or x15 Beagle board as of right now. Readers can attempt to replicate our findings on BBAI but note jtag needs mods and we didn’t test it.

CCS/JTAG is optional but strongly suggested by myself.

You need both SDKs at least right now(to build DSP example code and ARM IPC code.) Documents need to be read in proper order then questions will be supported

You Jeff validated Debian on ARM using 2 programs that did ARM to DSP IPC supplied by SDK on Beagle board x15 hardware

M4 IPC is documented in SDK as well it provides examples for EVM on SDK linux

PRU IPC is documented in SDK same as above

We dont see no reason why either m4 or IPU examples in sdk won’t work on Debian x15.

The SDK has detailed information to help new users and examples so it highly recommended but user can decide which Linux to run on ARM.

Bone AI is untested and JTAG needs mod. It says SDK supports BBAI but CCS JTAG isn’t discussed in detailed example code

########END DSP AM57x Summary

Important please confirm your Beagle Board X15 version you used.???
We will support and guarantee DSP works time willing answe question as long as users read docs and this summary is my stance.

We want user’s to have confidence if they buy an x15 or EVM they will have a positive experience and be running DSP code quickly

Feel free to add anything I’d prefer we keep the thread simple right? Your a positive fellow but maybe a disclaimer about x15 GPIO breakout should be mention or paste link to your current discussion I saw today as a reply

TO use some famous words from a seasoned support person

If new users can’t follow this thread
" I’m not sure I know how to support them​:rofl::smiley::joy:"

In all seriousness everything is right here in this thread and the links .
I forsee people asking as they always do the same questions without searching the forum for this thread title or rwzdung zero they should get referred here.

Neither of has time to create a nice orderly step by step wiki the documents tell the story.

I believe a good engineer learns by researching not demanding what is next step please.

I see our goal is to help engineer’s think out of box and get marketable skill and have fun doing it.

We have no control over what gets fixed but we can help engineer’s buying a platform know exactly what works for DSP and M4.

It ain’t really pretty but it’s better than nothing and seeing the same questions repeated bi weekly is ridiculous.

I better shut up before I cloud the summary and people miss it hidden in here.
Or we can refine it at end of thread in a final post.

Mark

12

Update for TI Soc using the DSP core
The .TI DSP’s are optomized for Signal Processing very good skillset for industry used in military and medical and avionics

The Omap L138 is another option to the Beagle X15
I tested the TEXAS INSTRUMENTS OMAP-L138/C6748 LCDK-PCB-004 DSP+ARM Development

yesterday I successfully loaded a DSP image using CCS/JTAG
While an older platform its fully supported for JTAG and CCS THIS IS VERY IMPORTANT!!!
It is supported in the SDK RTOS and is a great way to Focus on using TI DSP a very popular DSP in industry
I saw Digikey had ads not sure about stock and I saw a used one on ebay about $100

TEXAS INSTRUMENTS OMAP-L138/C6748 LCDK-PCB-004 DSP+ARM Development | eBay

[

## TEXAS INSTRUMENTS OMAP-L138/C6748 LCDK-PCB-004 DSP+ARM Development | eBay

Find many great new & used options and get the best deals for TEXAS INSTRUMENTS OMAP-L138/C6748 LCDK-PCB-004 DSP…

](https://www.ebay.com/itm/254819786425)

TMDSLCDK138 Development kit | TI.com

[

TMDSLCDK138 Development kit | TI.com

View the TI TMDSLCDK138 Development kit description, features, development resources and supporting documentatio…

](https://www.ti.com/tool/TMDSLCDK138)

.

13

To Debug and Test a DSP app on OMAP L138 dev kit using CCS and Jtag I used the following guide.

Only one DSP core so its much easier to get up and running I used below

10.3.12. OMAP-L137/C6747 EVM Hardware Setup Guide

10.1. Target — Processor SDK RTOS Documentation

[

10.1. Target — Processor SDK RTOS Documentation

](https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/index_how_to_guides.html#omap-l137-c6747-evm-hardware-setup-guide)

.

14

My last contribution hopefully I dont want to confuse people but I think this is important

No matter which SOC you pick the TI DSP has access to on chip peripherals

Perhaps you been using a PRU UART,SPI,I2C

The good news is the DSP core can use and access these peripherals as well. Its a much faster processor and while optimized for signal processing many companies use TI DSP like a normal microprocessor using home brew OS, bare metal or TI RTOS.

Perhaps you never used a TI DSP like this or have only used Linux device drivers or PRU based peripherals

You need to refer to your SOC block diagram to validate this BUT …

M3 and CC6C or cc74 depending on the SOC all have access to the SOC peripherals

DSP cores are good for audio and video codecs so maybe you need to process Audio or video and get it off chip or maybe into the SOC

As part of your learning to use the DSP maybe you want a UART for debig or SPI or I2C you need drivers

The drivers are stashed in the Processor Dev Kit (PDK) heres an example and I will post an example directory for L138 SDK below

I’d strongly suggest trying this on a single core DSP Soc as the conflict in muxing pins occurs from the host so things will get try quick on a complicated SOC BUT Not so if you have a JTAG you can remove the host sd card and connect to the DSP and work on a UART example

Here a DSP RTOS I2c example

6.1. CSL — Processor SDK RTOS Documentation

[

6.1. CSL — Processor SDK RTOS Documentation

](http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_device_drv.html#building-i2c-examples)

here are the drivers provided in source code as starting points this for the L138 the AM

C:\ti\pdk_omapl138_1_0_11\packages\ti\drv

AND The x15

C:\ti\pdk_am57xx_1_0_17\packages\ti\drv

So Jeff and I have given a a huge amount of choices we expect it will take time to digest this all we hope this was helpful

Good Luck read the docs and have fun playing on your board

Mark

.