• State Resolved
  • Locked Locked
  • Replies 19 replies
  • Subscribers 101 subscribers
  • Views 4724 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Linux/AM5728: IPC examples issues

Dermot Murphy
Intellectual 895 points
Part Number: AM5728

Tool/software: Linux

Hi there - I'm planning on developing an application that uses the A15, M4 and DSP cores on an am5728 (BeagleBoard X15) so I thought I'd start with getting accustomed to the TI SDK IPC example applications.

I've installed the Linux and RTOS Processor SDKs on my Ubuntu 14.04 build host and built out the IPC libraries (make ti-ipc-linux and make ipc_bios) and example applications (make ipc_examples).

I copied the binaries onto my board (/home/root) and pointed the corresponding symlinks in /lib/firmware to these binaries.

For the most part, the application works.  I can trade messages between host and DSP2, IPU1 and IPU2 but the app fails to open a MessageQ to DSP1:

root@am57xx-evm:~# ./app_host DSP2
--> main:
--> Main_main:
--> App_create:
App_create: Host is ready
<-- App_create:
--> App_exec:
App_exec: sending message 1
App_exec: sending message 2
App_exec: sending message 3
App_exec: message received, sending message 4
App_exec: message received, sending message 5
App_exec: message received, sending message 6
App_exec: message received, sending message 7
App_exec: message received, sending message 8
App_exec: message received, sending message 9
App_exec: message received, sending message 10
App_exec: message received, sending message 11
App_exec: message received, sending message 12
App_exec: message received, sending message 13
App_exec: message received, sending message 14
App_exec: message received, sending message 15
App_exec: message received
App_exec: message received
App_exec: message received
<-- App_exec: 0
--> App_delete:
<-- App_delete:
<-- Main_main:
<-- main:
root@am57xx-evm:~# ./app_host DSP1
--> main:
--> Main_main:
--> App_create:
App_create: Failed opening MessageQ
<-- App_create:
<-- Main_main:
<-- main:

Whenever I run ./app_host DSP1 

I get three messages in dmesg:

[ 3196.909673] omap-rproc 40800000.dsp: failed to send mailbox message, status = -105
[ 3196.965791] omap-rproc 40800000.dsp: failed to send mailbox message, status = -105
[ 3197.024193] omap-rproc 40800000.dsp: failed to send mailbox message, status = -105

It also appears during bootup that this DSP1 core crashes three times, gets handles twice but not the third time so I'm assuming that the core has crashed which is why the message fails. 

root@am57xx-evm:~# dmesg | grep crash

[ 7.290236] remoteproc remoteproc2: crash detected in 40800000.dsp: type watchdog
[ 7.386553] remoteproc remoteproc2: handling crash #1 in 40800000.dsp
[ 7.495896] remoteproc remoteproc2: crash detected in 40800000.dsp: type watchdog
[ 7.503389] remoteproc remoteproc2: handling crash #2 in 40800000.dsp
[ 7.664527] remoteproc remoteproc2: crash detected in 40800000.dsp: type watchdog

I'm pretty new to troubleshooting the am5728 so I'd appreciate any recommendations regarding how to troubleshoot further.  For example, should I be looking for some issues during the IPC library or example build process?  Are there other DSP images I can use to test the core?

Thanks,

Dermot

  • 0
    Intellectual 895 points

    Update - I've also been using the ping_rpmsg test app once I figured out what the parameters should be and all four cores respond as expected.

    root@am57xx-evm:~# ./ping_rpmsg 5 3
    Number of arguements: 3
    Connecting to address 0x33 on vprocId 3
    Our address: send_sock: socket family: 43, proc id = -1, addr = 1024
    Binding to address 0x33 on vprodId 3
    Our address: recv_sock: socket family: 43, proc id = -1, addr = 51
    Sending "Ping!" in my loop.
    0: Received msg: Pong!, from: 51
    Message time: 155 usecs
    Received a msg from address 0x33 on processor 3
    Message content: "Pong!".
    1: Received msg: Pong!, from: 51
    Message time: 146 usecs
    Received a msg from address 0x33 on processor 3
    Message content: "Pong!".
    2: Received msg: Pong!, from: 51
    Message time: 139 usecs
    Received a msg from address 0x33 on processor 3
    Message content: "Pong!".
    3: Received msg: Pong!, from: 51
    Message time: 137 usecs
    Received a msg from address 0x33 on processor 3
    Message content: "Pong!".
    4: Received msg: Pong!, from: 51
    Message time: 139 usecs
    Received a msg from address 0x33 on processor 3
    Message content: "Pong!".
    Avg time: 143 usecs over 5 iterations

  • 0 in reply to Dermot Murphy
    TI__Guru 50170 points
    Hi, Dermot,

    Glad to hear ping works for you. I tried the ex02_messageq example, but I don't see load issue. Do you still have issue with the MessageQ example to DSP1? Do both DSP1 and DSP2 have correct images in /lib/firmware? The sysfs may give you more info when DSP fails. It is in /sys/kernel/debug/remoteproc/remoteproc(x) folder.


    root@am57xx-evm:/lib/firmware# ls -l dra7-dsp*-fw.xe66
    lrwxrwxrwx 1 root root 14 Mar 7 2018 dra7-dsp1-fw.xe66 -> ex02_dsp1.xe66
    lrwxrwxrwx 1 root root 14 Mar 7 2018 dra7-dsp2-fw.xe66 -> ex02_dsp2.xe66
    root@am57xx-evm:/lib/firmware# ls -l ex02*
    -rw-r--r-- 1 root root 4663976 Mar 7 2018 ex02_dsp1.xe66
    -rw-r--r-- 1 root root 4510088 Mar 7 2018 ex02_dsp2.xe66
    root@am57xx-evm:~# uname -a
    Linux am57xx-evm 4.9.41-ge3a80a1c5c #2 SMP PREEMPT Tue Sep 26 19:14:57 EDT 2017 armv7l GNU/Linux
    root@am57xx-evm:~# ./ex02_app_host DSP2
    --> main:
    --> Main_main:
    --> App_create:
    App_create: Host is ready
    <-- App_create:
    --> App_exec:
    App_exec: sending message 1
    App_exec: sending message 2
    App_exec: sending message 3
    App_exec: message received, sending message 4
    App_exec: message received, sending message 5
    App_exec: message received, sending message 6
    App_exec: message received, sending message 7
    App_exec: message received, sending message 8
    App_exec: message received, sending message 9
    App_exec: message received, sending message 10
    App_exec: message received, sending message 11
    App_exec: message received, sending message 12
    App_exec: message received, sending message 13
    App_exec: message received, sending message 14
    App_exec: message received, sending message 15
    App_exec: message received
    App_exec: message received
    App_exec: message received
    <-- App_exec: 0
    --> App_delete:
    <-- App_delete:
    <-- Main_main:
    <-- main:
    root@am57xx-evm:~# ./ex02_app_host DSP1
    --> main:
    --> Main_main:
    --> App_create:
    App_create: Host is ready
    <-- App_create:
    --> App_exec:
    App_exec: sending message 1
    App_exec: sending message 2
    App_exec: sending message 3
    App_exec: message received, sending message 4
    App_exec: message received, sending message 5
    App_exec: message received, sending message 6
    App_exec: message received, sending message 7
    App_exec: message received, sending message 8
    App_exec: message received, sending message 9
    App_exec: message received, sending message 10
    App_exec: message received, sending message 11
    App_exec: message received, sending message 12
    App_exec: message received, sending message 13
    App_exec: message received, sending message 14
    App_exec: message received, sending message 15
    App_exec: message received
    App_exec: message received
    App_exec: message received
    <-- App_exec: 0
    --> App_delete:
    <-- App_delete:
    <-- Main_main:
    <-- main:
  • 0 in reply to Rex Chang
    Intellectual 895 points
    Thanks for the quick reply, Rex.

    The trace at /sys/kernel/debug/remoteproc/remoteproc2 starts off normal (compared with DSP2 at remoteproc3)

    [ 0.000] Watchdog enabled: TimerBase = 0x48086000 Freq = 0
    [ 0.000] 17 Resource entries at 0x95000000
    [ 0.000] [t=0x0006a60c] xdc.runtime.Main: --> main:
    [ 0.000] registering rpmsg-proto:rpmsg-proto service on 61 with HOST
    [ 0.000] [t=0x000c54c1] xdc.runtime.Main: NameMap_sendMessage: HOST 53, port=61

    But then seems to dump registers and report an exception at 0x0:
    ...
    [ 0.000] B20=0x20050000 B21=0x0
    [ 0.000] B22=0x20050000 B23=0x0
    [ 0.000] B24=0x20050000 B25=0x0
    [ 0.000] B26=0x2000010 B27=0x0
    [ 0.000] B28=0x20050000 B29=0x0
    [ 0.000] B30=0x20050000 B31=0x0
    [ 0.000] NTSR=0x0
    [ 0.000] ITSR=0x20050000
    [ 0.000] IRP=0x20050000
    [ 0.000] SSR=0x0
    [ 0.000] AMR=0x20050000
    [ 0.000] RILC=0x0
    [ 0.000] ILC=0x20050000
    [ 0.000] Exception at 0x0
    [ 0.000] EFR=0x0 NRP=0x0
    [ 0.000] Terminating execution...

    I notice that the DSP2 trace doesn't show "Watchdog enabled..." at the first line. The message in dmesg, appears to suggest that the DSP1 core crash is of type "watchdog":

    [ 7.659480] remoteproc remoteproc2: crash detected in 40800000.dsp: type watchdog

    Perhaps I need to disable the watchdog timer for DSP1?

    It'll be a while before I can try this. This kernel build error appeared out of nowhere seemingly:

    Can't locate strict.pm in @INC (you may need to install the strict module) (@INC contains: //usr/lib/perl/site_perl/5.22.1 //usr/lib/perl/vendor_perl/5.22.1 //usr/lib/perl/5.22.1 /tmp/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy/sysroots/x86_64-arago-linux/usr/lib/perl/site_perl/5.22.1/ /tmp/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy/sysroots/x86_64-arago-linux/usr/lib/perl/site_perl/5.22.1 /tmp/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy/sysroots/x86_64-arago-linux/usr/lib/perl/vendor_perl/5.22.1/ /tmp/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy/sysroots/x86_64-arago-linux/usr/lib/perl/vendor_perl/5.22.1 /tmp/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy/sysroots/x86_64-arago-linux/usr/lib/perl/5.22.1/ /tmp/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy/sysroots/x86_64-arago-linux/usr/lib/perl/5.22.1 /tmp/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy/sysroots/x86_64-arago-linux/usr/lib/perl/5.22.1 .) at ./lib/build_OID_registry line 14.
    BEGIN failed--compilation aborted at ./lib/build_OID_registry line 14.
    lib/Makefile:220: recipe for target 'lib/oid_registry_data.c' failed
    make[2]: *** [lib/oid_registry_data.c] Error 2
    make[2]: *** Waiting for unfinished jobs....

    So I need to resolve this first before troubleshooting the DSP1 core issue more. I'll report back as soon as I can build again.
  • 0 in reply to Dermot Murphy
    TI__Guru 50170 points
    Hi, Dermot,

    You shouldn't need to do anything to run the example, and the example shouldn't fail to download if you are using prebuilt images. The image for DSP1 and DSP2 were taken from the corresponding folder, not the same image but named different, correct? Watchdog just mean the dsp is not responding so watchdog was waken up.

    If you are using ProcSDK 4.1 and later, the perl in linux-devkit of these release packages are not relocatable. The workaround is
    1) not export the path of toolchain of linux-devkit in $PATH
    2) specify the path for CROSS_COMPILE in make command. Instead of "make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage", do "make ARCH=arm CROSS_COMPILE=../../linux-devkit/sysroot/x86_64-arago-linux/usr/bin/arm-linux-gnueabihf- zImage". or even the full path to arm-linux-gnueabihf-


    Rex
  • 0 in reply to Rex Chang
    Intellectual 895 points

    Thanks Rex,

    I guess it makes more sense that watchdog is reporting the crash as opposed to causing it somehow!

    I read your helpful info about perl a little too late and I had already rebuilt my build host and re-installed the SDKs. Everything is building OK again so I'll keep an eye out for the issue and apply your workaround if it does re-occur.  I'm running Processor SDK 4.2 by the way.

    This time around, I didn't rebuild the slave core images. After running setup.sh in the Linux SDK I noticed that the prebuilt images were populated in ./targetNFS/usr/bin/ipc/examples/ex02_messageq/debug so I used those images directly. I SCPed them to /home/root on the X15 and verified that the /lib/firmware links were pointing to the corresponding binaries. And I'm seeing the same issue as before...

    DSP1 core crashed on boot:
    root@am57xx-evm:~# dmesg | grep crash
    [ 8.294471] remoteproc remoteproc2: crash detected in 40800000.dsp: type watchdog
    [ 9.069575] remoteproc remoteproc2: handling crash #1 in 40800000.dsp
    [ 9.916159] remoteproc remoteproc2: crash detected in 40800000.dsp: type watchdog

    DSP2 core working OK:
    root@am57xx-evm:~# ./app_host DSP2
    --> main:
    --> Main_main:
    --> App_create:
    App_create: Host is ready
    <-- App_create:
    --> App_exec:
    App_exec: sending message 1
    App_exec: sending message 2
    App_exec: sending message 3
    ...

    These are the pre-built images that I copied from targetNFS to /home/root on the X15:
    -rw-r--r-- 1 root root 4531160 Dec 23 2017 server_dsp1.xe66
    -rw-r--r-- 1 root root 4376368 Dec 23 2017 server_dsp2.xe66
    -rw-r--r-- 1 root root 4318952 Dec 23 2017 server_ipu1.xem4
    -rw-r--r-- 1 root root 4318952 Dec 23 2017 server_ipu2.xem4

    I was originally wondering why my server_dsp1.xe66 file built out larger than the server_dsp2.xe66 file but it looks as though the pre-built ones are the same so maybe I shouldn't care about the file sizes too much.

    Any other pointers or recommendations much appreciated!
    Thanks,
    Dermot

  • 0 in reply to Dermot Murphy
    TI__Guru 50170 points

    Hi, Dermot,

    Could you try with my dsp and host images? My images are based on ProcSDK 4.1. Which release are you using?

    Rex

    ex02.zip

  • 0 in reply to Rex Chang
    Intellectual 895 points
    Sure - I'll try them now. I'm using ProcSDK 4.2. Thanks!
  • 0 in reply to Dermot Murphy
    Intellectual 895 points
    Now that's interesting - I just used your DSP1 .xe66 file and that works fine with my app_host along with my own other slave cores.

    So I wonder if there's something weird between SDK 4.1 and SDK 4.2? Maybe I'll try running with SDK 4.1 and see if I can recreate the issue. Incidentally, do you know if there's a way to load the slave cores from Linux without having to reboot? I keep thinking that a full reboot is a bit of overkill. I understand keystone-2 devices have MPM command-line utilities but I don't think I have them on my X15 rootfs.
  • 0 in reply to Dermot Murphy
    TI__Guru 50170 points
    Dermot,

    I'll try to build 4.2 next week, and see what do I get. There is bind/unbind sysfs which power cycle DSP and causes remoteproc to download DSP.

    root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc#
    root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# echo 40800000.dsp > unbind
    [28685.462672] omap_hwmod: mmu1_dsp1: _wait_target_disable failed
    [28685.475669] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
    [28685.481945] remoteproc remoteproc2: stopped remote processor 40800000.dsp
    [28685.488907] remoteproc remoteproc2: releasing 40800000.dsp
    root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# echo 40800000.dsp > bind
    [28694.889970] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@99000000
    [28694.897875] remoteproc remoteproc2: 40800000.dsp is available
    [28694.909774] remoteproc remoteproc2: powering up 40800000.dsp
    [28694.915481] remoteproc remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 4663976
    root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# [28694.931592] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
    [28694.937481] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
    [28694.943434] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
    [28694.959528] virtio_rpmsg_bus virtio1: rpmsg host is online
    [28694.965079] remoteproc remoteproc2: registered virtio1 (type 7)
    [28694.971087] remoteproc remoteproc2: remote processor 40800000.dsp is now up
    [28694.978710] virtio_rpmsg_bus virtio1: creating channel rpmsg-proto addr 0x3d
  • 0 in reply to Rex Chang
    Intellectual 895 points
    Ah cool - that's a nice way of loading the cores.

    I'm installing the 4.1 SDKs now - I'll report back here once I've done some testing.

    Appreciate your help & in the meantime, have a good weekend!
  • 0 in reply to Dermot Murphy
    TI__Guru 50170 points
    I am downloading 4.2 both Linux and RTOS SDK. I have several meeting on Monday. If I don't get chance to run it on Monday, I will definitely try within next several days, and get back to you.

    Thanks, you too.

    Rex
  • 0 in reply to Rex Chang
    Intellectual 895 points
    No hurry - I know exactly how it can be with meetings. I'll update here anyway once I'm done testing with 4.1.
  • 0 in reply to Dermot Murphy
    Intellectual 895 points
    Some good news - I installed the 4.1 SDKs and all of the pre-built slave core binaries are working OK in the MessageQ examples. So it's looking like there's a bug in the DSP1 binary in the 4.2 SDK. Will be interesting to see if you recreate that at your end.

    Thanks for your help to date, Rex.
  • 0 in reply to Dermot Murphy
    TI__Guru 50170 points
    Dermot,

    I see the same error as yours using 4.2 release. The boot logs show dsp1 crashed and that is the reason watchdog kicked in. There isn't any change in the ex02 example code from release to release. I am working internally trying to figure out why this happens. I'll post back once we understand the issue.

    [ 6.987349] remoteproc remoteproc2: remote processor 40800000.dsp is now up
    [ 6.988077] virtio_rpmsg_bus virtio1: rpmsg host is online
    [ 6.988090] remoteproc remoteproc3: registered virtio1 (type 7)
    [ 6.988094] remoteproc remoteproc3: remote processor 41000000.dsp is now up
    [ 6.988270] virtio_rpmsg_bus virtio1: creating channel rpmsg-proto addr 0x3d

    [ 6.989169] remoteproc remoteproc2: crash detected in 40800000.dsp: type watchdog
    [ 6.989187] remoteproc remoteproc2: handling crash #1 in 40800000.dsp

    [ 6.989191] remoteproc remoteproc2: recovering 40800000.dsp
    [ 7.052930] omap_hwmod: mmu1_dsp1: _wait_target_disable failed
    [ 7.059573] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
    [ 7.087764] remoteproc remoteproc2: stopped remote processor 40800000.dsp
    [ 7.094943] omap-sham 4b101000.sham: hw accel on OMAP rev 4.3
    [ 7.104170] remoteproc remoteproc2: powering up 40800000.dsp
    [ 7.114877] remoteproc remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 4389168
    [ 7.132955] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
    [ 7.138842] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
    [ 7.144787] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
    [ 7.157999] alloc_contig_range: [99600, 99700) PFNs busy
    [ 7.170879] remoteproc remoteproc2: crash detected in 40800000.dsp: type watchdog
    [ 7.183480] omap-des 480a5000.des: OMAP DES hw accel rev: 2.2
    [ 7.194432] omap-des 480a5000.des: will run requests pump with realtime priority
  • 0 in reply to Rex Chang
    Intellectual 895 points

    Hey Rex - that's good news I guess.  At least it's a proper bug as opposed to some build environment configuration issue!

    Meanwhile I'm happy working away on the 4.1 SDKs for the purposes of my project.

    I do have one last question for you regarding the workaround to the non-relocatable perl issue.  Is there any way to implement that workaround in a single location once I've removed the compiler location from $PATH?  Or will I have to track down every reference in all affected Makefiles?

    Thanks,

    Dermot

  • 0 in reply to Dermot Murphy
    TI__Guru 50170 points

    Dermot,

    You can use relative path in the make comand, such as

    "make ARCH=arm CROSS_COMPILE=../../linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm-linux-gnueabihf- zImage" and same for other targets, like distclean, menuconfig, [platform].dtb, tisdk_[platform]_defconfig, etc.

    If you downloaded linaro toolchain instead of using the toolchain in ProcSDK package, you can use the fully qualified path to the toolchain for CROSS_COMPILE. that is CROSS_COMPILE=[fully qualified path]/arm-linux-gnueabihf- 

    We found pre-built dsp1 image in the released filesystem has the same symptom. So, it is not our build issue, nor related to kernel version. We suspect it is some changes in different IPC versions. We'll keep investigating it and address it in the future release. I'd like to close this thread. If you have other questions, please submit a new one.

    Rex

  • 0 in reply to Rex Chang
    Intellectual 895 points
    Got it - thanks very much for your help!
  • 0 in reply to Rex Chang
    Intellectual 895 points
    One last, last thing - if I try to build ti-ipc-tools using either...

    make ARCH=arm CROSS_COMPILE=~/ti-processor-sdk-linux-am57xx-evm-04.01.00.06/linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm-linux-gnueabihf- ti-ipc-linux

    or

    make ARCH=arm CROSS_COMPILE=../../linux-devkit/sysroots/x86_64-arago-linux/usr/bin/arm-linux-gnueabihf- ti-ipc-linux

    ...I get this error:

    libtool: compile: arm-linux-gnueabihf-gcc "-DPACKAGE_NAME=\"TI IPC\"" -DPACKAGE_TARNAME=\"ti-ipc\" -DPACKAGE_VERSION=\"3.0.0\" "-DPACKAGE_STRING=\"TI IPC 3.0.0\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"ti-ipc\" -DVERSION=\"3.0.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -I. -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard --sysroot=/home/dmurphy/ti-processor-sdk-linux-am57xx-evm-04.01.00.06/linux-devkit/sysroots/armv7ahf-neon-linux-gnueabi -I../../../hlos_common/include -D_GNU_SOURCE -Wall -I../../../linux/include -I../../../packages -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard --sysroot=/home/dmurphy/ti-processor-sdk-linux-am57xx-evm-04.01.00.06/linux-devkit/sysroots/armv7ahf-neon-linux-gnueabi -MT LAD_client.lo -MD -MP -MF .deps/LAD_client.Tpo -c LAD_client.c -fPIC -DPIC -o .libs/LAD_client.o
    ../../../libtool: line 1111: arm-linux-gnueabihf-gcc: command not found

    I've removed the compiler path from $PATH...
    dmurphy@tibuilder:~/ti-processor-sdk-linux-am57xx-evm-04.01.00.06$ echo $PATH
    /usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

    Do you think I can resolve by further tweaking my make command? Or let me know if you'd prefer I opened a new thread for this.

    Thanks,
    Dermot
  • 0 in reply to Dermot Murphy
    TI__Guru 50170 points
    Hi, Dermot,

    It is better to have a new thread on high level build which is not related to this topic. It's also easy for us to categorize the issues. I'll take a look at it in the meantime. I have not tried to build ti-ipc-tools myself.

    For now, could you try with fully qualified path to gnueabihf- from "/" instead of "~"? You may want to try to roll back to see what it gets using cross-compiler defined in PATH.

    The last resort is to export both ARCH=arm and CROSS_COMPILE=gnueabihf- and have PATH defined. Then, just make without ARCH and CROSS_COMPILE in the command.

    Rex