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.

IPC_start NameServer_attach errors

Other Parts Discussed in Thread: AM5728

Background/SW Versions:

Processor: TI AM5728

Platform: TI AM572x EVM

Processor SDK: ti-processor-sdk-linux-am57xx-evm-02.00.02.11

Linux Kernel: Using the 4.1.18 kernel included with the Processor SDK above

IPC: Using pre-built IPC binaries (both libraries and LAD) from the Processor SDK above

Related Thread: https://e2e.ti.com/support/embedded/linux/f/354/t/350493

Problem:

I'm in the process of trying to get ARM-DSP MessageQ communication working. Similar to the thread referenced above, doing a simple IPC_start() leads to some issues as observed from the LAD log file. In my case, I apparently get passed the NameServer_setup processing but run into the same "Address family not supported by protocol" errors later, during NameServer_attach. 

Unlike the thread above, I didn't build IPC - I'm using the provided binaries from the Processor SDK. I did rebuild the kernel but only with minor tweaks to the configuration provided for the AM572x EVM. So, I would assume that everything is matched up (IPC/Linux Kernel-wise) as desired.

Please see the LAD log output below; any ideas?

[723.089789] Retrieving command...
[723.090073]
LAD_CONNECT:
[723.090113] client FIFO name = /tmp/LAD/1125
[723.090136] client PID = 1125
[723.090158] assigned client handle = 0
[723.090207] FIFO /tmp/LAD/1125 created
[723.090318] FIFO /tmp/LAD/1125 opened for writing
[723.090372] sent response
[723.090396] DONE
[723.090417] Retrieving command...
[723.090515] Sending response...
[723.090547] Retrieving command...
[723.090609] LAD_MULTIPROC_GETCONFIG: calling MultiProc_getConfig()...
[723.090636] MultiProc_getConfig() - 5 procs
[723.090658] # processors in cluster: 5
[723.090678] cluster baseId: 0
[723.090699] ProcId 0 - "HOST"
[723.090720] ProcId 1 - "IPU2"
[723.090740] ProcId 2 - "IPU1"
[723.090761] ProcId 3 - "DSP2"
[723.090780] ProcId 4 - "DSP1"
[723.090801] status = 0
[723.090821] DONE
[723.090840] Sending response...
[723.090866] Retrieving command...
[723.090959] LAD_NAMESERVER_SETUP: calling NameServer_setup()...
[723.090987] NameServer_setup: entered, refCount=0
[723.091021] NameServer_setup: creating listener thread
[723.091107] NameServer_setup: exiting, refCount=1
[723.091148] status = 0
[723.091177] DONE
[723.091204] Sending response...
[723.091124] listener_cb: Entered Listener thread.
[723.091288] NameServer: waiting for unblockFd: 2, and socks: maxfd: 2
[723.091237] Retrieving command...
[723.091366] LAD_MESSAGEQ_GETCONFIG: calling MessageQ_getConfig()...
[723.091390] status = 0
[723.091412] DONE
[723.091432] Sending response...
[723.091459] Retrieving command...
[723.091533] LAD_MESSAGEQ_SETUP: calling MessageQ_setup()...
[723.091593] MessageQ_setup: entered, refCount=0
[723.091615] NameServer_create(): 'MessageQ'
[723.091640] MessageQ_setup: exiting, refCount=1
[723.091660] status = 0
[723.091679] DONE
[723.091696] Sending response...
[723.091719] Retrieving command...
[723.091950] NameServer_attach: --> procId=1, refCount=0
[723.107794] NameServer_attach: socket failed: 97, Address family not supported by protocol
[723.107853] NameServer_attach: <-- refCount=0, status=-1
[723.107874] Sending response...
[723.107909] Retrieving command...
[723.108004] NameServer_attach: --> procId=2, refCount=0
[723.123463] NameServer_attach: socket failed: 97, Address family not supported by protocol
[723.123509] NameServer_attach: <-- refCount=0, status=-1
[723.123530] Sending response...
[723.123563] Retrieving command...
[723.123684] NameServer_attach: --> procId=3, refCount=0
[723.139161] NameServer_attach: socket failed: 97, Address family not supported by protocol
[723.139203] NameServer_attach: <-- refCount=0, status=-1
[723.139223] Sending response...
[723.139256] Retrieving command...
[723.139375] NameServer_attach: --> procId=4, refCount=0
[723.154745] NameServer_attach: socket failed: 97, Address family not supported by protocol
[723.154787] NameServer_attach: <-- refCount=0, status=-1
[723.154807] Sending response...
[723.154839] Retrieving command...
[723.154961] LAD_GATEMP_ISSETUP: calling GateMP_isSetup()...
[723.154987] status = 0
[723.155006] DONE
[723.155023] Sending response...
[723.155053] Retrieving command...
[724.155468] LAD_MESSAGEQ_DESTROY: calling MessageQ_destroy()...
[724.155516] MessageQ_destroy: entered, refCount=1
[724.155540] MessageQ_destroy: exiting, refCount=0
[724.155559] status = 0
[724.155577] DONE
[724.155594] Sending response...
[724.155625] Retrieving command...
[724.155761] LAD_NAMESERVER_DESTROY: calling NameServer_destroy()...
[724.155788] NameServer_destroy: entered, refCount=1
[724.155807] NameServer_destroy: shutdown listener...
[724.155836] NameServer_destroy: joining listener thread...
[724.155871] NameServer: back from select()
[724.155898] NameServer: listener thread, event: SHUTDOWN
[724.155987] NameServer_destroy: exiting, refCount=0
[724.156011] status = 0
[724.156030] DONE
[724.156048] Sending response...
[724.156077] Retrieving command...
[724.156205]
LAD_DISCONNECT: [724.156229]
client handle = 0[724.156259]
closing FIFO /tmp/LAD/1125 (filePtr=0x2f2e8)
[724.156307] done, unlinking /tmp/LAD/1125
[724.156358] DONE
[724.156378] Retrieving command...
[724.159042] EOF detected on FIFO, closing FIFO: /tmp/LAD/LADCMDS
[724.159109]
opening FIFO: /tmp/LAD/LADCMDS

  • Further information:

    To debug the problem I built IPC instead of using the pre-built binaries that come with the Processor SDK. I explicitly set AF_RPMSG to the appropriate 41 value and confirmed LAD was utilizing it for the socket call. No change in behavior; I still get the 'address family not supported' error.

  • Hi, Gerard,

    I am not able to reproduce your error, but noticed that your lad logs are a bit different from mine. Do you get the NameServer setup and created when the kernel first boots up? It doesn't show up in your lad logs and I am not sure if you just cut and pasted after those logs, or simply it does not exist. You mentioned that you modified Kernel. Can you run the MessageQApp example using the binary in the Proc SDK 2.0.2 release?

    Rex

  • I figured out the problem - the rpmsg_proto module was not loaded. As a result, the kernel had no registered handler for the AF_RPMSG family.

    Thanks for the input.