• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 936 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Syslink notify example does not work

Lajos Rancz
Expert 1065 points


Hi all,

I've built the syslink's notify example and there is a little problem. Tthe fw upload takes place regularly, the A8 can communicate with the DSP and the VideoM3 but cannot with the VPSS M3. The VPSS M3 core does not get any nofity (the task is running, but the callback function is not called). Logs:

Attached to slave procId 0.
Loading procId 0.
Loaded file notify_ti81xx_dsp.xe674 on slave procId 0.
Started slave procId 0.
Attached to slave procId 1.
Loading procId 1.
Loaded file notify_ti81xx_videom3.xem3 on slave procId 1.
Started slave procId 1.
Attached to slave procId 2.
Loading procId 2.
Loaded file notify_ti81xx_vpssm3.xem3 on slave procId 2.
Started slave procId 2.
NotifyApp sample application
Run for all supported proc IDs
Entered NotifyApp_startup. Number of processors: 4
After Ipc_loadcallback:
status [0x0]
After Ipc_startcallback:
status [0x97d2000]
After Ipc_loadcallback:
status [0x0]
After Ipc_startcallback:
status [0x0]
After Ipc_loadcallback:
status [0x0]
After Ipc_startcallback:
status [0x0]
Registered event number 10 with Notify module for processor 0
Registered event number 11 with Notify module for processor 0
Registered event number 10 with Notify module for processor 1
Registered event number 11 with Notify module for processor 1
Registered event number 10 with Notify module for processor 2
Registered event number 11 with Notify module for processor 2
Registered event number 10 with Notify module for processor 3
Registered event number 11 with Notify module for processor 3
Leaving NotifyApp_startup() (0x0)
Entered NotifyApp_execute()

Sending events to procId 0
Sent 5000 events to event ID 10 to processor 0
Sent 5000 events to event ID 11 to processor 0
Received 5000 events for event ID 10 from processor 0
Received 5000 events for event ID 11 from processor 0
Sent 10000 events to event ID 10 to processor 0
Sent 10000 events to event ID 11 to processor 0

Sending events to procId 1
Received 10000 events for event ID 10 from processor 0
Received 10000 events for event ID 11 from processor 0
Number of RTOS-side received/sent events:
procId: [0]
Number of events: [20000]
Sent 5000 events to event ID 10 to processor 1
Sent 5000 events to event ID 11 to processor 1
Sent 10000 events to event ID 10 to processor 1
Sent 10000 events to event ID 11 to processor 1

Sending events to procId 2
Received 5000 events for event ID 10 from processor 1
Received 5000 events for event ID 11 from processor 1
Received 10000 events for event ID 10 from processor 1
Received 10000 events for event ID 11 from processor 1
Number of RTOS-side received/sent events:
procId: [1]
Number of events: [20000]

Followings in dmesg until killing the application:

notify_shm_drv_sendevent failed! status = 0xfffffff0
notify_send_event failed! status = 0xfffffff0

What's wrong?

Regards,
Lajos 

  • 0
    TI__Mastermind 22760 points

    Lajos,

    Are you using the EZSDK?  If so, which version.  Also, if you have the EZSDK and you want to run SysLink samples, you must unload the firmware.  Here are instructions from the EZSDK User's Guide for unloading the firmware:

    Note! The syslink samples use a different memory map from the default EZSDK installation. In order to run
    syslink examples, you must boot with a different memory for linux. When booting, ensure that the linux
    bootargs is changed from the default values to MEM=169M


    Note! The syslink samples cannot be run out with graphics or firmware loaded. Please execute the following
    steps to teardown the graphics plane and ensure that no firmware is running.


    target # /etc/init.d/pvr-init stop
    target # /etc/init.d/matrix-gui-e stop
    target # /etc/init.d/load-hd-firmware.sh stop


    Now the system is ready to run all syslink samples.


    target # modprobe syslink
    target # cd /usr/share/ti/syslink-examples/TI814X
    Execute the following script to run the example application
    target # ./runsamples_debug.sh

    Best regards,

        Janet

  • 0 in reply to janet
    Expert 1065 points

    Janet,

    We are using the syslink_2_10_06_28 (from IPNC RDK). We have unloaded the firmware of course (even the starting shell script is commented out). Logs:

    root@dm814x-evm:~# ps
    PID USER VSZ STAT COMMAND
    1 root 1708 S init [5]
    2 root 0 SW [kthreadd]
    3 root 0 SW [ksoftirqd/0]
    4 root 0 SW [kworker/0:0]
    5 root 0 SW [kworker/u:0]
    6 root 0 SW< [khelper]
    7 root 0 SW [irq/72-serial i]
    8 root 0 SW [irq/73-serial i]
    9 root 0 SW [irq/74-serial i]
    10 root 0 SW [irq/44-serial i]
    11 root 0 SW [irq/45-serial i]
    12 root 0 SW [irq/46-serial i]
    13 root 0 SW< [mboxd]
    14 root 0 SW [sync_supers]
    15 root 0 SW [bdi-default]
    16 root 0 SW< [kblockd]
    17 root 0 SW< [omap2_mcspi]
    18 root 0 SW [kseriod]
    19 root 0 SW< [kmmcd]
    20 root 0 SW< [rpciod]
    21 root 0 SW [kswapd0]
    22 root 0 SW [kworker/0:1]
    23 root 0 SW< [aio]
    24 root 0 SW< [nfsiod]
    25 root 0 SW< [crypto]
    32 root 0 SW [mtdblock0]
    33 root 0 SW [mtdblock1]
    34 root 0 SW [mtdblock2]
    35 root 0 SW [mtdblock3]
    36 root 0 SW [mtdblock4]
    37 root 0 SW [mtdblock5]
    38 root 0 SW [mtdblock6]
    39 root 0 SW [kworker/u:1]
    75 root 1956 S < /sbin/udevd -d
    929 root 0 SW [flush-mtd-unmap]
    930 root 0 SWN [jffs2_gcd_mtd4]
    1025 root 3204 S inetd
    1043 root 0 SWN [jffs2_gcd_mtd5]
    1046 root 0 SWN [jffs2_gcd_mtd6]
    1058 messageb 3324 S /usr/bin/dbus-daemon --system
    1063 root 2936 S /usr/sbin/telnetd
    1070 root 3000 S /sbin/syslogd -n -C64 -m 20
    1072 root 2936 S /sbin/klogd -n
    1077 root 2516 S login -- root
    1079 root 3128 S -sh
    1081 root 2248 S dropbear -i -s -b /etc/dropbear/motd
    1082 root 3128 S -sh
    1089 root 3128 R ps
    [09:47:50] Kauth Krisztian: root@dm814x-evm:~# lsmod
    Module Size Used by
    root@dm814x-evm:~#
    linux mem=80M@0x80000000
    notifyk.vpss 0xBFD00000
    cmem start 85000000
    cmem end 89000000
    setenv bootargs 'console=ttyO0,115200n8 noinitrd mem=80M@0x80000000 vram=4M notifyk.vpssm3_sva=0xBFD00000 root=/dev/mtdblock4 rw rootfstype=jffs2 ip=10.10.10.150 eth=$(ethaddr) cmemk.phys_start=0x85000000 cmemk.phys_end=0x89000000 cmemk.allowOverlap=1 earlyprintk';

    So, what's the next step?

  • 0 in reply to Lajos Rancz
    Expert 1065 points

    I've removed the notifyk.vpssm3_sva boot parameter and it's working :) So what's this?

  • 0 in reply to Lajos Rancz
    TI__Mastermind 22760 points

    Lajos,

    What's probably happening is the following:

    notifyk.vpssm3_sva is the slave (VPSS-M3 in this case) viirtual base address of the shared memory that will be used for notification between the ARM and the slave.  If you set this to a non-zero value in your bootargs, when the notify driver is loaded, it will call notify_attach() using this address.  Then, when you load the vpssm3 with the SysLink example, SysLink() will internally allocate a chunk of shared memory for notify (which will be different than the one you specified in the bootargs), and pass this notify_attach().  This second call to notify_attach() will probably fail or have no effect because the reference count is greater than 0.  So there will be a mismatch between the Arm and the slave's notification memory regions.

    If you do not set the notifyk.vpssm3_sva in the bootargs, notify_attach() is not called when the notify driver is loaded.  Then when you load the vpssm3 with your SysLink example, the SysLink call to notify_attach() succeeds because it has not yet been called.  Then Arm and slave agree on the address in shared memory for notification, so the example works.

    Best regards,

        Janet