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.

TDA4VM: C7x RemoteProc Trace Buffer empty in Linux, but valid in U-Boot (Processor SDK 11.01)

Part Number: TDA4VM

I am experiencing an issue where the C7x_1 trace buffer is empty when viewed from Linux via /sys/kernel/debug/remoteproc/remoteproc2/trace0, even though the remote processor is reported as "up."

I have verified that the firmware is executing and writing to the trace buffer by loading it manually in U-Boot. In U-Boot, I can see the expected log messages in memory, but in Linux, the trace remains blank.

1. Verification in U-Boot (Works)

When loading the firmware via U-Boot prompt:

load mmc 1:1 0x90000000 ipc_echo_test_freertos_c7x_1_release.xe71
rproc init
rproc load 8 0x90000000 ${filesize}
rproc start 8
md.b 0xa86a0000 0x100


output:
=> md.b 0xa86a0000 0x500
a86a0000: 53 63 69 63 6c 69 65 6e 74 5f 69 6e 69 74 20 46    Sciclient_init F
a86a0010: 61 69 6c 65 64 0a 49 50 43 5f 65 63 68 6f 5f 74    ailed.IPC_echo_t
a86a0020: 65 73 74 20 28 63 6f 72 65 20 3a 20 43 37 58 5f    est (core : C7X_
a86a0030: 31 29 20 2e 2e 2e 2e 2e 0d 0a 00 00 00 00 00 00    1) .............
a86a0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

 Issue in Linux (Blank Trace)
In Linux, the device boots, but the trace is empty:

debian@BeagleBone:~$ echo start | sudo tee /sys/class/remoteproc/remoteproc2/state [ 115.701747] remoteproc remoteproc2: remote processor 64800000.dsp is now up debian@BeagleBone:~$ sudo cat /sys/kernel/debug/remoteproc/remoteproc2/trace0 (No output) 

Resource Table: Linux reports the trace buffer at 0xa86a0000 with length 0x80000. This matches the address I checked in U-Boot. DTS Reserved Memory:


debian@BeagleBone:~$ sudo cat /sys/kernel/debug/remoteproc/remoteproc2/resource_table                                                                 
[sudo] password for debian: 
Entry 0 is of type vdev
  ID 7
  Notify ID 0
  Device features 0x1
  Guest features 0x1
  Config length 0x0
  Status 0x7
  Number of vrings 2
  Reserved (should be zero) [0][0]

  Vring 0
    Device Address 0xa8000000
    Alignment 4096
    Number of buffers 256
    Notify ID 0
    Physical Address 0x0

  Vring 1
    Device Address 0xa8004000
    Alignment 4096
    Number of buffers 256
    Notify ID 1
    Physical Address 0x0

Entry 1 is of type trace
  Device Address 0xa86a0000
  Length 0x80000 Bytes
  Reserved (should be zero) [0]
  Name trace:c71



IN DT The c71 re reserved for memroy:
[    0.000000] OF: reserved mem: initialized node c71-dma-memory@a8000000, compatible id shared-dma-pool
[    0.000000] OF: reserved mem: 0x00000000a8000000..0x00000000a80fffff (1024 KiB) nomap non-reusable c71-dma-memory@a8000000
[    0.000000] OF: reserved mem: initialized node c71-memory@a8100000, compatible id shared-dma-pool
[    0.000000] OF: reserved mem: 0x00000000a8100000..0x00000000a8ffffff (15360 KiB) nomap non-reusable c71-memory@a8100000

Questions:

  1. Trace Blank in Linux: Since the memory address 0xa86a0000 contains data in U-Boot, why would the Linux RemoteProc trace debugfs entry return nothing? Is there a specific cache coherency or nomap attribute requirement in the DTS for the trace buffer to be visible to Linux?

  2. Sciclient_init Failure: My logs show Sciclient_init Failed. Why would Sciclient fail to initialize on C7x when loaded via U-Boot or RemoteProc? Are there specific board configurations or TISCI permissions required for C7x to communicate with the DM (Device Manager) on MCU1_0 in this SDK version?




  • Hello.

    Trace Blank in Linux: Since the memory address 0xa86a0000 contains data in U-Boot, why would the Linux RemoteProc trace debugfs entry return nothing? Is there a specific cache coherency or nomap attribute requirement in the DTS for the trace buffer to be visible to Linux?

     TDA4VH-Q1: Trace buffer not working in C7x 

    Sciclient_init Failure: My logs show Sciclient_init Failed. Why would Sciclient fail to initialize on C7x when loaded via U-Boot or RemoteProc? Are there specific board configurations or TISCI permissions required for C7x to communicate with the DM (Device Manager) on MCU1_0 in this SDK version?

    Is sciserver running on MCU1_0 ? Can you please check it once ?

    Regards

    Tarun Mukesh