LAD Name Server Setup : connect failed!

Any of these help?

Chris

Chris...thanks for pointing me to that FAQ Wiki.

I have tried a couple of things, but I have some questions about how to actually check some of them.

Below, I have quoted some possible failures from that wiki page, followed by my response.

 "Failure to load the slave image. If the a slave executable fails to load, the sockets to communicate with it are not created. Make sure the slaves you need to communicate with are already loaded."

 For this I checked that following boot messages are present in dmesg.

 [   19.485591]  remoteproc0: powering up dsp1

[   19.489911]  remoteproc0: Booting fw image dra7-dsp1-fw.xe66, size 929933

Does this make sure that the slave image is loading successfully. As the slave here is DSP1?

Is there any other way to make sure that this is the case?

“Failure to provide the correct KERNEL_INSTALL_DIR when building the user-side IPC libraries. Some customers reported this error when using Linux 3.9+ kernels (where the AF_MAX value in socket.h has increased). This created a mismatch in what AF_RPMSG was set to in user libs and the kernel, and the connect call failed. The solution was to require users set KERNEL_INSTALL_DIR when building the user-space libraries so IPC can interrogate the kernel version and set AF_RPMSG appropriately.”

 I added CFLAGS="-DAF_RPMSG=41" to ipc-linux.mak file, so that it can avoid any possible AF_RPMSG mismatch.

“Failure to configure the slave image correctly. Internally, the slave-side MessageQ transport (TransportRpmsg) broadcasts its availability to the Linux host. If this broadcast doesn't occur (e.g., b/c the slave wasn't configured with TransportRpmsg), the socket connection will fail with error 22.”

 I am not sure how to check this case, as I am using dra7-dsp1-fw.xe66 from ti as mentioned in the boot messages above.

“General slave-to-host interrupt failure. Some devices (e.g. DRA7XX) have interrupt crossbars that must be configured correctly as part of system boot (e.g. uboot). If these crossbars aren't initialized correctly, the slave-side broadcast that TransportRpmsg is available won't be received, the underlying socket connection won't be available, and the first sign of failure will be LAD trying to connect to the socket.”

 This is something I still need to explore, but I would clear of the top ones before making any changes to uboot.

Thanks.

Girish Tummala said:

 "Failure to load the slave image. If the a slave executable fails to load, the sockets to communicate with it are not created. Make sure the slaves you need to communicate with are already loaded."

 For this I checked that following boot messages are present in dmesg.

 [   19.485591]  remoteproc0: powering up dsp1

[   19.489911]  remoteproc0: Booting fw image dra7-dsp1-fw.xe66, size 929933

Does this make sure that the slave image is loading successfully. As the slave here is DSP1?

Is there any other way to make sure that this is the case?

The dmesg indicates that remoteproc is properly configured in the Linux kernel to load the slave core. DSP1 in this case.

Once its loaded, if DEBUG_FS config option is enabled in your kernel, then you can cat appropriate remoteproc core for is System prints output.

% cat /debug/remoteproc/remoteproc0/trace0

Some of this info can be found: http://processors.wiki.ti.com/index.php/IPC_Install_Guide_Linux#Running_Test_Applications

Girish Tummala said:

“Failure to configure the slave image correctly. Internally, the slave-side MessageQ transport (TransportRpmsg) broadcasts its availability to the Linux host. If this broadcast doesn't occur (e.g., b/c the slave wasn't configured with TransportRpmsg), the socket connection will fail with error 22.”

 I am not sure how to check this case, as I am using dra7-dsp1-fw.xe66 from ti as mentioned in the boot messages above.

The slave application was build with a configuration file (*.cfg).  If you plan on running messageQApp, you must use the corresponding DSP binary (messageq_single.xe66). That application has been configured with TransportRpmsg.

Some of this information can also be found in the  IPC Install Guide link above.

Hi Arnie,
Thanks for pointing out that I need to use messageq_single.xe66 binary.
I see that I have messageq_single.c file in my ipc package, I am thinking I need to build it for DSP and load the binary.
Are there any documented steps of how to configure the build environment for dsp?
Do I need to use syslink or does IPC already have all the ingredients for building dsp binaries?

Also, I see a lot of documentation on configuring dsp build environment using CCS.

Do I really need CCS to build binaries for DSP? Or is just one way?

Thanks

Are you using IPC as part of a SDK for your DRA7XX device?

You don't need CCS at all to build IPC components but you do need some of the tools and componenets (Sys/BIOS, CGT, XDCTools) delivered with CCS.  If you are using an SDK for your device, you may already have these tools and components.  It would be simply configuring your IPC product.mak file and building the IPC DSP-side.

Some of this information in the IPC Install Guide: http://processors.wiki.ti.com/index.php/IPC_Install_Guide_Linux#ipc-bios.mak

In your case, you'd need to set the following VARIABLES in the products.mak to build the DSP test executable.

PLATFORM = DRA7XX

XDC_INSTALL_DIR = <Path to XDCTools>
BIOS_INSTALL_DIR = <Path the Sys/Bios component>

ti.targets.elf.C66 = <Path to Code Generation tools for C66XX DSP>

I am not building IPC as a part of sdk.

I followed the IPC install guide and tried to build ti-ipc recipe with the above VARIABLES set in products.mak.

I am building the recipes for ti-ipc_3.30.00.09 along with ti-sysbios_6.33.00.19, ti-cgt6x_7.2.12.bb and ti-xdctools_3.23.00.32

I am getting the following build error when I run "make -f ipc-bios.mak all"

I am just pasting the part where I am seeing error.

======== .interfaces [./packages/ti/sdo/ipc/family/da830/] ========

======== .interfaces [./packages/ti/sdo/ipc/family/dm6446/] ========
======== .interfaces [./packages/ti/sdo/ipc/family/f2837x/] ========
======== .interfaces [./packages/ti/sdo/ipc/family/f28m35x/] ========
======== .interfaces [./packages/ti/sdo/ipc/family/omap3530/] ========
======== .interfaces [./packages/ti/sdo/ipc/family/omap4430/] ========
======== .interfaces [./packages/ti/sdo/ipc/family/tci663x/] ========
======== .interfaces [./packages/ti/sdo/ipc/family/tda3xx/] ========
======== .interfaces [./packages/ti/sdo/ipc/family/ti81xx/] ========
======== .interfaces [./packages/ti/sdo/ipc/family/vayu/] ========
======== .interfaces [./packages/ti/sdo/ipc/gates/] ========
======== .interfaces [./packages/ti/sdo/ipc/heaps/] ========
======== .interfaces [./packages/ti/sdo/ipc/interfaces/] ========
======== .interfaces [./packages/ti/sdo/ipc/notifyDrivers/] ========
======== .interfaces [./packages/ti/sdo/ipc/nsremote/] ========
======== .interfaces [./packages/ti/sdo/ipc/transports/] ========
======== .interfaces [./packages/ti/sdo/utils/] ========
======== .interfaces [./packages/ti/srvmgr/] ========
======== .interfaces [./packages/ti/srvmgr/omaprpc/] ========
======== .interfaces [./packages/ti/srvmgr/omx/] ========
======== .interfaces [./packages/ti/trace/] ========
generating interfaces for package ti.trace (because package/package.xdc.inc is older than package.xdc) ...
translating SysMin
"ti/trace/SysMin.xdc", line 156: can't resolve name (CString)
error: compilation of package.xdc failed: parser failed
gmake[1]: *** [package/package.xdc.inc] Error 1
gmake: *** [packages/ti/trace/,.interfaces] Error 2
make: *** [all] Error 2

Am I still missing something here?

I am trying to update to ti-sysbios 6.40.01.15 to try and see if that fixes the error.
I updated the bitbake file with proper md5 and sha256. However, I am getting an error about License file not being found.

Where should I point "LIC_FILES_CHKSUM" for proper license info for ti-sysbios 6.40.01.15?

There is a recipe for ti-ipc_3.30.00.09 in meta-ti/recipe-ti repo.
I did not find any updated recipes for ti-xdctools 3.30.01.25 and ti-sysbios 6.40.01.15 in the repo.
So I copied the old recipe file and updated the PV in the recipe file to whatever latest version I am using now, for ti-xdctools, ti-cgt6x and ti-sysbios.
I do not have any issues with building ti-xdctools and ti-cgt6x.
But with ti-sysbios, it looks like there is some error while unpacking the fetched bin file and this is causing my build to fail.

This is what I am seeing in unpack log file for ti-sysbios:

DEBUG: Executing python function do_unpack
DEBUG: Executing python function base_do_unpack
NOTE: Unpacking /home/xxxxx/xxxxxx/downloads/bios_setuplinux_6_40_01_15.bin to /home/xxxxxx/xxxxx/build/yocto/tmp/work/cortexa15t2hf-vfp-neon-poky-linux-gnueabi/ti-sysbios/6_40_01_15-r0/
DEBUG: Python function base_do_unpack finished
DEBUG: Executing python function ti_bin_do_unpack

Error: There has been an error.
Invalid value "console" for --mode. Allowed values are: gtk xwindow text
unattended
Use --help to get a list of valid options
DEBUG: Python function ti_bin_do_unpack finished
DEBUG: Python function do_unpack finished

Any idea what is going on with the unpacking function?
I am suspecting the recipe file.
Are there any modifications that are to be done to the recipe file to unpack ti-sysbios_6_40_01_15?

Girish Tummala said:

This is what I am seeing in unpack log file for ti-sysbios:

DEBUG: Executing python function do_unpack
DEBUG: Executing python function base_do_unpack
NOTE: Unpacking /home/xxxxx/xxxxxx/downloads/bios_setuplinux_6_40_01_15.bin to /home/xxxxxx/xxxxx/build/yocto/tmp/work/cortexa15t2hf-vfp-neon-poky-linux-gnueabi/ti-sysbios/6_40_01_15-r0/
DEBUG: Python function base_do_unpack finished
DEBUG: Executing python function ti_bin_do_unpack

Error: There has been an error.
Invalid value "console" for --mode. Allowed values are: gtk xwindow text
unattended
Use --help to get a list of valid options
DEBUG: Python function ti_bin_do_unpack finished
DEBUG: Python function do_unpack finished

Any idea what is going on with the unpacking function?

Sounds like your recipe is invoking the installer with option "--mode console".  You need to change it to "--mode text" (or perhaps "--mode unattended" if that doesn't work).

Girish Tummala said:

I have a related question regarding how TI submits patches to meta-ti/recipes-ti.
If there is change submitted upgrading ti-ipc to a newer version, do I need to expect similar changes being submitted to other modules which are dependent on ti-ipc?

Like in this case, I see a change which updated ti-ipc to 3.30.00.09 and the release notes for this version mentions that this needs ti-xdctools 3.30.01.25 and ti-sysbios 6.40.01.15. But I do not see any update to those modules.

I think you've made a wrong turn somewhere.  The GLSDK has a script called "download_component_sources.sh" which downloads the following (among others):

• ipc_3_30_03_14
• bios_6_41_01_36
• xdctools_3_30_05_60

That shell scripts downloads and installs all of these compoentns inside the "component-sources" directory within the GLSDK.  You are not supposed to be using Yocto to do all this, which is why none of the versions are correct.