IPC_start fails with Nameserver issue

Robert,

This is turning out to be a sticky problem (I saw your post to the other thread asking William if he had found a solution).

I guess we need to dig down into the dirty details...

You say you have the kernel socket.h patch.  Would you please attach the file <linuxkernel>/include/linux/socket.h?

Also, could you attach <linuxkernel>/include/net/rpmsg.h?

Those files are for the kernel, and there needs to be a corresponding user-side definition for AF_RPMSG. The file <ipc>/linux/include/net/rpmsg.h defines AF_RPSMG as either 40 or 41, depending on the kernel version.  Do you know your kernel version?  The toplevel Makefile in your kernel source tree contains it at the top of the file, here's mine for reference:
VERSION = 3
PATCHLEVEL = 8
SUBLEVEL = 13
Sometimes it's hard to know which one is being used, so would you be able to print out AF_RPMSG from a program?:
    printf("%d\n", AF_RPMSG);

Since the ping_rpmsg application is also failing in this way, it might be a good candidate for placing the above printf("%d\n", AF_RPMSG), that way you'll know that you're printing the value from a program that is failing when trying to use it.

It's odd that NameServerApp works (when it is the first to run).  It does the exact same LAD_connect() (unless you've rebuilt it after changing it to not #define USE_NSD, out-of-the-box NameServerApp.c #defines USE_NSD which causes the LAD_connect() to be called).

I recall that Keystone has the rpmsg_proto driver code builtin to the kernel (as opposed to being a loadable module, such as with OMAP5).  Can you inspect your boot logging and check if there is some kind of failure with setting up rpmsg_proto?  The rpmsg_proto_init() function can fail with one of the following prints:
    pr_err("proto_register failed: %d\n", ret);
    pr_err("sock_register failed: %d\n", ret);
    pr_err("register_rpmsg_driver failed: %d\n", ret);

Regards,

- Rob

Hi, Robert,

I saw you were running MessageQApp. Could you try /usr/bin/MessageQBench instead for keystone-II?

Rex

Hi Rex --

I tried that as well.

I did make some progress.  I searched and found an FAQ that pointed to a mismatch between kernel versions regarding AF_RPMSG..... It turns out that there is a header file in the ipc directory that explicitly assigns the protocol number based on kernel version.   The IPC library was choosing wrong and selecting 40 rather than 41.

However, I now get the standard LAD error of 22, cannot connect.  Based on the log messages that appear on the ARM when I start the DSP applications, I am assuming that the DSP apps are configured correctly.  This behavior is the same with the default kernel supplied or my latest version. 

One more thing, there are no boot log errors with respect to rpmsg.

So, getting back to first principles, I  reinstalled the default file system.

I copied the DSP executables (I built these) to the /lib/firmware directory and started messageq_single.

I ran the /usr/bin/MessageQBench and it worked.  I took my built version of MessageQBench and it worked.  I only copied over the executable and none of the libraries.

Next, I installed the ipc stuff via make install prefix=/..,.../usr/local.  That worked.

Finally, I replaced the lad daemon (frpm /usr/local/bin to /usr/bin).  That worked.

So, I can only conclude that something when awry in my root file system. 

so, it *appears* to be working now with my updated kernel (need for RIO support).  I am currently using K2_LINUX_03.10.10_RIO_14.04

So, this is what I did at a high level

1. Build the linux kernel with the following tag:   K2_LINUX_03.10.10_RIO_14.04

2. Add the uio stuff to the device table (but I think that is not really needed) and build that.

3. Modify a file in the ipc directory (linux/include/net/rpmsg.h) to change the AF_RPMSG to 41.   There is a check that compares linux version numbers that fails which causes the protocol errors. [Note using default arm cross compiler here]

4. I used the default Linux file system from TI

5. Copy DSP executables to /lib/firmware

6. Install ARM executables to /usr/local/bin

   1. In the ipc directory, you do the following:  sudo make install prefix=/home/klink/rootfs/usr/local

   2. You will need to remove the lad_xxxx daemon from /usr/bin, and copy the one over from /usr/local/bin (and reboot)

That’s it.  I think the fundamental problem with the IPC stuff was the protocol mismatch even with using the default Linux. 

I had an additional problem that something went wrong with my rootfs (which was the TI default one).  I may do a post-partum on that later.