• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 342 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PROCESSOR-SDK-AM57X: Starting DSP2 fails if DSP1 is not already running

John Pruitt
Prodigy 130 points
Part Number: PROCESSOR-SDK-AM57X

Target AM57x

I am having a problem running a very simple DSP program on both dsp1 and dsp2. The program being used just creates a main task, starts BIOS, andworkspace_dsp_hello.tar.gz the task prints a message and then loops forever as if it is waiting for a debugger to attach.

I am attaching the source code and objects for these two projects. I am building these programs from within Code Composer (12.4) as CCS Projects. I am using an RTOS processor sdk version 8.01.00.09. I have tried running the programs on both 4.19.94 and 5.10.168 kernels with mixed results.

The differences between the source code files are as follows:

  • The XDCtools Platform argument is slightly different:
    • The DSP1 project is using ti.platforms.evmDRA7XX:dsp1
    • The DSP2 project is using ti.platforms.evmDRA7XX:dsp2
  • main1.cfg: The procName is set to "DSP1" or "DSP2" depending on the project.
  • dsp1_rsc_table_dsp.h: The variable MEM_BASE is set to match the reserved-memory region for the appropriate DSP.
    • DSP1 gets a MEM_BASE value of 0x99000000
    • DSP2 gets a MEM_BASE value of 0x9F000000
    • These values match what is in the device tree I am using for the reserved-memory regions for dsp1 and dsp2 respectively


I build these programs using Code Composer (12.04) on a Linux VM.(Ubuntu 18.04)

  • Untar the file, should create a workspace_dsp_hello directory
  • Start Code Composer, pick the workspace_dsp_hello directory for the workspace_dsp_hello
    • File->Import...->Code Composer Studio->CCS Projects. Press Next>
    • Press the Browse... button to the right at the top line, "Select search-directory". Press the Open button in the upper right of the Select Search Directory dialog that comes up in order to select the default directory it is showing.
    • Check the checkboxes for both DSP1 and DSP2. Press Finish.
    • This should import the 2 projects and show them in the Project Explorer.
  • Build the projects. I have been using Debug versions.

Results:

4.19.94 kernel

  • Both programs can be started and the trace0 output for each is like this:

root@mitysom-am57x:~# more /sys/kernel/debug/remoteproc/remoteproc2/trace0
[ 0.000] 18 Resource entries at 0xa0000000
[ 0.000] registering rpmsg-proto:rpmsg-proto service on 61 with HOST
[ 0.000] [t=0x033e7906] xdc.runtime.Main: NameMap_sendMessage: HOST 53, port=61
[ 0.000] Waiting for debugger
root@mitysom-am57x:~# more /sys/kernel/debug/remoteproc/remoteproc3/trace0
[ 0.000] 18 Resource entries at 0xa0000000
[ 0.000] registering rpmsg-proto:rpmsg-proto service on 61 with HOST
[ 0.000] [t=0x0380d228] xdc.runtime.Main: NameMap_sendMessage: HOST 53, port=61
[ 0.000] Waiting for debugger

  • This output was after a reboot where the DSP processors were started as part of the reboot.
  • Originally, neither DSP was running and I started DSP2 first, and then DSP1.

5.10.168 kernel

  • The results were not as good here and I am not sure why.
    • When starting a DSP, a symbolic link is made from /lib/firmware/dra7-dsp1-fw.xe66 to DSP1.out and similarly for DSP2.out.
    • If neither DSP is running and I start DSP2, then it freezes the kernel. The console is unresponsive. A system reboot after a power cycle is still trying to start DSP2 and this again freezes the system.
      • After the freeze, I plug the SD card into the Linux VM and move the target of the symbolic link from DSP2.out to DSP2.out.hide. This lets the system boot again.
    • If I start DSP1, it seems to work.
      • If I then start DSP2, this seems to work. So DSP2 seems to work if DSP1 is already running.
      • If a reboot is now done with the intent to start both DSPs, things go south and the system is toast. I don't think the order of starting the DSPs is guaranteed and since the order seems to matter, it is not likely to work. I don't remember all the details but sometimes the system goes into rolling exceptions.
      • This is repaired by renaming the targets of the symbolic links as was done above.

Questions:

  • Why would trying to start DSP2 freeze the system on 5.10.168 if DSP1 is not already running?
  • Are there possibly some kernel config options that could affect starting the DSPs like this?

Thanks.

  • 0
    TI__Mastermind 31805 points

    Hello John,

    Will need some time next week to look into your query.

    From a high level this might  be an IPC version issue considering that it is working with the earlier kernel (SDK 6.3) and not the newer kernel that belongs to SDK 8.2

    -Josue

  • 0 in reply to Josue Zamitiz-Ayala
    TI__Mastermind 31805 points

    Hello John,

    Are the resource tables the same on both kernels?

    Have you double checked that there is no memory overlap on the non-working case?

    -Josue

  • 0 in reply to Josue Zamitiz-Ayala
    Prodigy 130 points

    I am building the programs once (using sdk 08) and trying to run the same executable on 2 different kernels. I know that this is suspect since programs built with sdk 08 are not guaranteed to work on the older kernel. My problem is that when built with sdk 08, the program seems to be ok on the older kernel and not the newer. This is the reverse of the expectation.

    So yes, the resource tables are the same on both kernels.

    I am pretty sure there is no memory overlap. I have had memory overlaps before and I am familiar with those failures. The overlaps often get a failure complaining about trying to use a semaphore in a non-task context. This message is not really useful but I understand now that it means the resource table is probably wrong. There is no error message here. The linux kernel just seems to freeze.

    I will try to build the programs with sdk 06 to see if it is any different.

  • 0 in reply to John Pruitt
    TI__Mastermind 31805 points

    John, 

    To answer your question, no there is no kernel configs that should affect the order of the DSPs. THe DSPs, should be capable of running independently of each other. See this thread https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1067208/am5726-regarding-initialization-of-dsp1-dsp2.

    -Josue

  • 0 in reply to Josue Zamitiz-Ayala
    Prodigy 130 points

    I think I solved the problem. I now have programs that are being built with sdk06 tools and they work on the 4.19 kernel. Similarly, with minor changes, the programs can be built with sdk08 and work on the 5.10 kernel.

    I essentially replaced my resource table and configuration (.cfg) files with samples from working TI examples. There were minor differences in the resource tables. The primary difference in the configuration files was that mine was not setting up a Clock and Timer. Once this was done, then things started working much better.

    Thanks.