Ticket Name: Linux/TDA2EVM5777: JTAG debugging and Linux running?

Query Text:
Part Number: TDA2EVM5777 Other Parts Discussed in Thread: TDA2 Tool/software: Linux Hello! My name is Marco and I'm trying to develop a TDA2 based project in the following constellation: My development platform is the XC5777X CPU Board with TDA2. I'm using latest visual SDK, latest CCS and a XDS200 debugger (Firmware upgrade done). On both A15 linux is running, the other cores have to be programmed bare metal and, of course, have to be debugged over JTAG. So my first question: If I have Linux running, how can I connect the other cores over JTAG chain? I can not start any GEL-Script, or other CCS-Stuff on the "Linuxed" CPU, but I can connect it. I have to release the cores (M4 and C66x) and make them able to be connected using CCS with the XDS200 debugger... and don't know how to do this. Maybe anybody can help me? Second question: I've downloaded the "visual SDK" and was a little bit suprised: Everything works fine, until you are in the use case of pre-developed TI-Stuff. But we have to use the last bit of performance out of M4 and DSP, so this one have to be coded bare metal. There's not really a way shown, how to use a gnu-compiler and build a startupcode for each internal CPU from scratch. The only way shown is using TI-BIOS, RTOS and the buildsystem based on "use cases", "algorithm"... which do not fit our requirements. Are there any other SDK or examples available, which shows a point of start for bare metal programming the TDA2+? (M4, DSP, PRUs, etc... bare metal, Linux almost works great on A15.) TNX - Marco.

Responses:
Hi Marco, Which version of VisionSDK you have? Regards, Yordan

I have vision SDK on BIOS 2.12.02....

Hi Marco, for your second question you can check if Starterware works for you. It is a software development package that provides no-OS platform support for ARM and DSP processors. It is located in "...\VisionSDK_2_12\ti_components\drivers\starterware_01_07_01_20\" directory and has comprehensive docs and examples. For the JTAG question I will ping an expert to comment. Regards, Yordan

Thank you very much: I will take a look and give it a try. Marco

Marco Reppenhagen Marco Reppenhagen said: If I have Linux running, how can I connect the other cores over JTAG chain? You will need to install the TDA2x device support(located in the auto dev package) on your CCS. See here Then you will need to target connect to A15. When connected successfully you will have to run TDA2xx_MULTICORE_EnableAllCores() gel from the gel menu. If gel is executed successfully, you will now be able to target connect to M4 and DSP. Thanks, Alex

Alex Bashkov : Of course I have installed the TDA2x support. I'm also able to connect A15 with CCS over XDS200 and I can run M4 code and DSP code after calling the GEL script. That is not what I'm looking for, because if Linux runs on the A15 cores, I'm not able to run any gel script on it... So my question is, how can I connect the cores over JTAG when Linux uses both A15 cores? I have to debug my code in the running system, this will be linux on the main cores and bare metal code on the subcores. I can not "connect" the cores in CCS JTAG chain, even though they are almost running (firmware successfully loaded via remoteproc in Linux). I can not run any gel script, after linux have been bootet on A15 cores. I have sadly no idea how to fix this...

Marco Reppenhagen, Why are you not able to run any gel script on AM15 cores? Do you receive an error if you try to run the DSP enable gel or you just don't want to disturb Linux? Basically as far as I know, for a standalone DSP app you will need to use ARM-based CCS GEL scripts to take the DSP out of reset, and to do this you need to connect to the ARM, but if you don't want to disturb Linux then you will need to disable the ARM-based GEL scripts from performing "on target connect" functionality. Basically, you don't want the ARM running any GEL scripts *except* the one to take the DSP out of reset. Once the DSP is out of reset, you can connect to the DSP and load/run/debug your app. Thanks, Alex

Thank you: I will try to disable "on target connect" functionality and be back for a report, tomorrow.

Hello! I'm back again after I've tried many approaches, but I'm still not able to connect to M4 Subcore during Linux is running. I can not execute the GEL-Script, which will bring up the M4 cores; Following Error occoured: IPU1SSClkEnable_API() cannot be evaluated. Target failed to read 0x4AE06514 at (*((unsigned int *) ((cpu_num==1) ? (((0x4AE00000+0x6000)+0x500)+0x14) : (((0x4AE00000+0x6000)+0x700)+0x214)))&0x4) [TDA2xx_multicore_reset.gel:373] at IPUSSClkEnable(1) [TDA2xx_multicore_reset.gel:311] at IPU1SSClkEnable_API() If I bring up the M4 (IPU1@58820000) in the Linux via "remoteproc" (loading a pre-compiled xem4 as "dra7-ipu1-fw.xem4") dmesg shows me: [ 2162.133520] remoteproc0: releasing 58820000.ipu [ 2165.749631] omap-rproc 58820000.ipu: assigned reserved memory node ipu1_cma@9d000000 [ 2165.749686] remoteproc0: 58820000.ipu is available [ 2165.749694] remoteproc0: Note: remoteproc is still under development and considere. [ 2165.749702] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward comp. [ 2165.882920] remoteproc0: powering up 58820000.ipu [ 2165.882937] remoteproc0: Booting fw image dra7-ipu1-fw.xem4, size 4870616 [ 2165.883060] omap-iommu 58882000.mmu: 58882000.mmu: version 2.1 [ 2165.889434] remoteproc0: remote processor 58820000.ipu is now up [ 2165.889784] virtio_rpmsg_bus virtio0: rpmsg host is online [ 2165.890812] remoteproc0: registered virtio0 (type 7) I think, the IPU should be connectable over JTAG now... I tried IPU1/0 IPU1/1.. other m4 IPU2/0... second core: IPU2/1... with the following result: As mentioned: IPU2 (both cores) are still hold in reset. This is OK... because it have not been touched. BUT -> IPU1 (tried out both cores): This IPU1 core I've just started is not connectable in JTAG chain: "Can not access to DAP"... Why? It should be running... being out of reset, setup... a programm should run...? (I've no other processor in development, which cores can't be connected, if they have been setup successfully, and are successfully running, i can connect them over JTAG chain... there must be something missing here....) OK - I tried out to override the linux-stuff on M4 and started a new debug session on CSS. In detail I got the following error message: Error connecting to the target: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 7.0.48.0) Do you have any suggestions, how to cope with this problem? THANK YOU - Marco.

Hello again Marco Reppenhagen , Let me investigate your results thoroughly and try something out on my side. Will get back to you soon. Thanks Alex

Thank you... I stand by for any kind of suggestions :-)

As posted in another ticket: I've got another problem using "remoteproc" to use firmware in the sub-cores: The linux used in the latest (?) vision-sdk is quite old an do not support the control stuff... more precisely: It do not generate the "/sys/class/remoteproc/" directory. I installed the lates mainline kernel which generates this interface, but of course without any entry: The dra7xx dts do not deal with subcores. A15 Main CPU works fine, but I sadly do not found any support for ipu and/or dsp. My idea was to control the cores with linux and be shure they are running while I try to connect with JTAG chain as mentioned above in this thread. But this is temporary not possbile... Either I have to backport the mainline-kernel remoteproc code to the old 4.4. kernel used in SDK, or I have to implement the support of ipu and dsp into the mainline kernel. Before I try this on my own, I would like to ask you, if theres is any kernel ready to use with TDA2 subcore AND fully functional remoteproc interface available... Thank you: Marco

OK... I found a solution: patchwork.kernel.org/.../ After patching I've got what I need.

OK... Something new -> Short, FYI: I'm now able to build "something" like a firmware, which I can load into the M4 core. At this moment the startup-code is not working properly, the small programm is not running... but the Core change its state from "offline" to "running" after loading the ELF into the M4 via remoteproc... and after doing this, I'm able to connect the core over XDS200 using the CCS and a standard-ccxml Target confguration. (Later I will try to use this to "upload" some code via JTAG into the M4... (lack of time at the moment...) ) CU Marco.

Now I've got a solution. Something went wrong building the ELF... placing the IVT by the " #pragma" which I had to replace using some "__XXX__" GCC instructions. Now I am able to build Cortex M4 code using arm-linux-gnueabi-xxx toolchain in a very small build environment and loading this as a firmware up to the M4s of the TDA2... it's running fine! Thank you for your support.