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/TMDSICE3359: TMDSICE3359

Part Number: TMDSICE3359
Other Parts Discussed in Thread: AM3359

Tool/software: Linux

Hardware: AM3359 Industrial Communications Engine (ICE) www.ti.com/.../tmdsice3359
Soft: SDK 05.02.00.10, Linux RT

Hi!
I have to start the ICE on PRU-hardware PRP mode (PRU-ICSS, none-software PRP).
The compiler compiles the sdk finely.

What I made:
- (with root permissions and from the bin directory of the SDK) ./create-sdcard.sh.
- run the commands:
mkdir /media/vl/rootfs/sys/class
mkdir /media/vl/rootfs/sys/class/remoteproc
mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc1
mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc2
echo 'am335x-pru0-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc1/firmware
echo 'am335x-pru1-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc2/firmware
echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc1/state
echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc2/state

The ICE start (dmesg | grep pru):
[ 13.545180] pruss 4a300000.pruss: creating PRU cores and other child platform devices
[ 13.584988] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/ocp/pruss_soc_bus@4a326004/pruss@0/mdio@32400[0]' - status (0)
[ 13.585105] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/pruss_soc_bus@4a326004/pruss@0/mdio@32400[1]'
[ 13.585115] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp/pruss_soc_bus@4a326004/pruss@0/mdio@32400[1]'
[ 13.702569] remoteproc remoteproc1: 4a334000.pru is available
[ 13.702664] pru-rproc 4a334000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
[ 13.718658] remoteproc remoteproc2: 4a338000.pru is available
[ 13.718735] pru-rproc 4a338000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully
[ 13.992666] prueth pruss_eth: pruss_fw_drop_untagged_vlan 0
[ 13.992679] prueth pruss_eth: pruss MC Mask (Port 0) ff:ff:ff:ff:ff:ff
[ 13.992687] prueth pruss_eth: pruss MC Mask (Port 1) ff:ff:ff:ff:ff:ff
[ 13.996139] prueth pruss_eth: TI PRU ethernet (type 0) driver initialized
[ 22.149922] remoteproc remoteproc2: powering up 4a338000.pru
[ 22.212831] remoteproc remoteproc2: Booting fw image ti-pruss/am335x-pru1-prueth-fw.elf, size 6696
[ 22.245129] pruss 4a300000.pruss: configured system_events[63-0] = 0x00600000.08a00000
[ 22.293317] pruss 4a300000.pruss: configured intr_channels = 0x0000032a host_intr = 0x000002aa
[ 22.327800] remoteproc remoteproc2: remote processor 4a338000.pru is now up
[ 22.445581] remoteproc remoteproc1: powering up 4a334000.pru
[ 22.473182] remoteproc remoteproc1: Booting fw image ti-pruss/am335x-pru0-prueth-fw.elf, size 6780
[ 22.514480] pruss 4a300000.pruss: configured system_events[63-0] = 0x00000600.04500000
[ 22.553091] pruss 4a300000.pruss: configured intr_channels = 0x000000d5 host_intr = 0x00000155
[ 22.599048] remoteproc remoteproc1: remote processor 4a334000.pru is now up
[ 23.450960] prueth pruss_eth eth1: Link is Up - 100Mbps/Full - flow control off
[ 23.690901] prueth pruss_eth eth0: Link is Up - 100Mbps/Full - flow control off

The ifconfig shows:
eth0 Link encap:Ethernet HWaddr 2C:6B:7D:46:58:3B
inet6 addr: fe80::2e6b:7dff:fe46:583b%775872/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:280 (280.0 B) TX bytes:8169 (7.9 KiB)

eth1 Link encap:Ethernet HWaddr 2C:6B:7D:46:58:3D
inet6 addr: fe80::2e6b:7dff:fe46:583d%775872/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9 errors:0 dropped:0 overruns:0 frame:0
TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1018 (1018.0 B) TX bytes:8967 (8.7 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1%775872/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:249 errors:0 dropped:0 overruns:0 frame:0
TX packets:249 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19120 (18.6 KiB) TX bytes:19120 (18.6 KiB)

Then, acording to the software-dl.ti.com/.../Industrial_Protocols_HSR_PRP.html :
ifconfig eth0 down
ifconfig eth1 down
ethtool -K eth0 prp-rx-offload on
ethtool -K eth1 prp-rx-offload on
ifconfig eth0 up
ifconfig eth1 up

The listing:
ifconfig eth0 down
[ 266.302779] pruss 4a300000.pruss: unconfigured system_events[63-0] = 0x00000600.04500000
[ 266.311104] pruss 4a300000.pruss: unconfigured host_intr = 0x00000155
[ 266.318478] remoteproc remoteproc1: stopped remote processor 4a334000.pru
[ 266.331405] net eth0: stopped
root@am335x-evm:~# ifconfig eth1 down
[ 266.392312] pruss 4a300000.pruss: unconfigured system_events[63-0] = 0x00600000.08a00000
[ 266.401619] pruss 4a300000.pruss: unconfigured host_intr = 0x000002aa
[ 266.408115] remoteproc remoteproc2: stopped remote processor 4a338000.pru
[ 266.422267] net eth1: stopped
root@am335x-evm:~# ethtool -K eth0 prp-rx-offload on
root@am335x-evm:~# ethtool -K eth1 prp-rx-offload on
root@am335x-evm:~# ifconfig eth0 up
[ 266.582939] iep ptp bc clkid -1
[ 266.588731] remoteproc remoteproc1: powering up 4a334000.pru
[ 266.612592] remoteproc remoteproc1: Booting fw image ti-pruss/am335x-pru0-pruprp-fw.elf, size 7500
[ 266.625768] pruss 4a300000.pruss: configured system_events[63-0] = 0x00000600.00900000
[ 266.637543] pruss 4a300000.pruss: configured intr_channels = 0x00000095 host_intr = 0x00000115
[ 266.650126] remoteproc remoteproc1: remote processor 4a334000.pru is now up
[ 266.657171] remoteproc remoteproc2: powering up 4a338000.pru
[ 266.669251] remoteproc remoteproc2: Booting fw image ti-pruss/am335x-pru1-pruprp-fw.elf, size 7224
[ 266.678447] pruss 4a300000.pruss: configured system_events[63-0] = 0x00600000.01200000
[ 266.694096] pruss 4a300000.pruss: configured intr_channels = 0x0000012a host_intr = 0x0000022a
[ 266.706685] remoteproc remoteproc2: remote processor 4a338000.pru is now up
[ 266.717970] net eth0: started
[ 266.730235] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
root@am335x-evm:~# ifconfig eth1 up
[ 266.784543] net eth1: started
[ 266.797933] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 266.807840] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
root@am335x-evm:~# [ 267.349523] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 282.660159] NOHZ: local_softirq_pending 08

Then I run the command:
ip link add name prp0 type prp slave1 eth0 slave2 eth1 supervision 45

The listing:
root@am335x-evm:~# ip link add name prp0 type prp slave1 eth0 slave2 eth1 supervision 45
[ 342.664963] device eth0 entered promiscuous mode
[ 342.699585] device eth1 entered promiscuous mode
[ 342.749558] device eth0 left promiscuous mode
[ 342.779714] device eth1 left promiscuous mode

Then the command:
ifconfig prp0 192.168.14.165 up

The bad listing:
root@am335x-evm:~# ifconfig prp0 192.168.14.165 up
[ 342.880629] prp0: No slave devices configured
[ 342.885037] prp0: port invalid when doing set_rx_mode
[ 342.918590] prp0: port invalid when doing set_rx_mode
[ 342.951273] IPv6: ADDRCONF(NETDEV_UP): prp0: link is not ready
[ 342.957263] prp0: port invalid when doing set_rx_mode
[ 342.969302] prp0: port invalid when doing set_rx_mode
[ 343.118699] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 344.640708] prueth pruss_eth eth1: Link is Up - 100Mbps/Full - flow control off
[ 344.648266] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

As you can see, the am335x-pru1-pruprp-fw.elf driver is run. But the last command, there are no critical messages.

As expected, there is no ping.
Please help.

  • VLeshka,

    I've recreated this issue and am now discussing with our development team. Please give me some time to work with them to come up with some suggestions.

    Thanks for your post.
  • VLeshka,

    Working with the development team, it seems we both missed the step of assigning a duplicate MAC address to both interfaces as required by the PRP spec. Once I changed this, I was able to ping in my set up. Can you confirm if this addresses the ping issue for you?

    Thanks.
  • RonB,
    Hi!

    After booting the ICE, I have entered the command:
    ifconfig eth1 hw ether 2C:6B:7D:46:58:3B

    then commands:
    ip link add name prp0 type prp slave1 eth0 slave2 eth1
    ip addr add 192.168.14.161/24 brd + dev prp0
    ifconfig prp0 netmask 255.255.255.0
    ip link set dev prp0 up
    ifconfig

    the result:
    root@am335x-evm:~# ifconfig
    eth0 Link encap:Ethernet HWaddr 2C:6B:7D:46:58:3B
    UP BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
    Interrupt:44

    eth1 Link encap:Ethernet HWaddr 2C:6B:7D:46:58:3B
    inet6 addr: fe80::2e6b:7dff:fe46:583b%775872/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:49 errors:0 dropped:21 overruns:0 frame:0
    TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:4054 (3.9 KiB) TX bytes:6591 (6.4 KiB)

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1%775872/128 Scope:Host
    UP LOOPBACK RUNNING MTU:65536 Metric:1
    RX packets:165 errors:0 dropped:0 overruns:0 frame:0
    TX packets:165 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:12612 (12.3 KiB) TX bytes:12612 (12.3 KiB)

    prp0 Link encap:Ethernet HWaddr 2C:6B:7D:46:58:3B
    inet addr:192.168.14.161 Bcast:192.168.14.255 Mask:255.255.255.0
    inet6 addr: fe80::2e6b:7dff:fe46:583b%775872/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1494 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:54 (54.0 B)

    Result:
    the ping from other device to ICE is fine, and prp-reserve of ethernet cable works perfectly.

    But there are no any ping from ICE to other devices.
    Why?
  • RonB,
    Is there any progress?
  • VLeshka,

    I'm sorry, I was not able to reproduce your results. For me, the ping works fine from either side.

    Here is a summary of the commands I used:

    ifconfig eth1 down
    ifconfig eth1 hw ether C4:F3:12:72:4D:EE
    ifconfig eth1 up
    ip link add name prp0 type prp slave1 eth0 slave2 eth1 supervision 45
    ifconfig prp0 192.168.3.10 up
    ifconfig
    ping 192.168.3.11
  • VLeshka,

    Have you had a chance to try this again? I just tried again and did not have any problems with ping. Thanks.
  • What hardware do you use? Describe fully, please.

  • VLeshka,

    I'm using two ICE boards connected with one cable. One is configured to use the CPSW ports and the other the PRU ports for Ethernet. When I follow the instructions in the documentation I can ping from either board to the other without issues.

    I'm using Processor SDK 5.02 right out of the box with no modifications. I didn't have to rebuild anything for this test.
  • VLeshka,

    Since I haven't heard back from you one this, I'm going to go ahead and mark this resolved. If you have further feedback, please feel free to add it or create a new post. Thanks.
  • RonB, Hi!
    What ICE boards did you use?
  • VLeshka,

    I used the same AM3359 Industrial Communications Engine (ICE) boards that your referred to in your original post. Mine are both rev 2.1 A.

    Thanks.
  • RonB,
    Hi!

    I made a second ICE for our lab - when test 2 same AM3359 Industrial Communications Engine (ICE) boards, the ping is fine.
    I not pointed out in my original post: I have use one ICE and PC, because acording to the prp-manual, the prp-device should work with none-prp devices.
    Please check this bug.

    And second question:
    when ping between 2 ICE on software PRP, the ping is 0.7-0.9 ms.
    But when ping between 2 ICE on PRU-hardware PRP mode (PRU-ICSS, none-software PRP), the ping is 1.7-1.9 ms.
    Twice as much! Why?
  • VLeshka,

    I set this up, with an ICE configured for PRP per the above discussed and documented steps and connected it to a PC through a Gigabit switch. I was able to ping from the ICE to the PC and from the PC to the ICE.

    I also noticed the extended ping delays. My understanding is that this is caused from switching from NAPI for ethernet to interrupt driven to lower packet latency. This is to trade off throughput which NAPI is better at to latency which interrupts should be better at.

    I hope this feedback is helpful to you.
  • About "PRU - PC": okay, I'll try a few computers (note that the "soft prp" works via my PC finely.).

    About ping delay: thank for answer. And question: from your answer it follows that the "soft prp" does not uses the NAPI. Is that so?

  • Let's again step by step. I do 2 sd-card for ICE (pru-prp):

    1. For mounted sd-card in /media/vl/ :
    mkdir /media/vl/rootfs/sys/class
    mkdir /media/vl/rootfs/sys/class/remoteproc
    mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc1
    mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc2
    echo 'am335x-pru0-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc1/firmware
    echo 'am335x-pru1-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc2/firmware
    echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc1/state
    echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc2/state
    sync

    2. In boot mode of linux RT:
    setenv netargs 'setenv bootargs console=${console} root=/dev/nfs nfsroot=${rootpath},${nfsopts} rw ip=dhcp ti_prueth.pruss1_ethtype=${pruss1_ethtype} ti_prueth.pruss2_ethtype=${pruss2_ethtype}'
    setenv pruss1_ethtype 2
    setenv pruss2_ethtype 2
    saveenv

    3. In linux RT (for 192.168.14.165):
    ip link add name prp0 type prp slave1 eth0 slave2 eth1 supervision 45
    ifconfig prp0 192.168.14.165 up

    As a result:
    - the ping between san and prp is allways on.
    - there is no ping between ICE debugs (pru-prp) for any time (for example, 1 hour), and then ping is on. And note: if both ICE boots synchronously, there is no "ping off" in some cases.
    Why?

  • VLeshka,

    I'm sorry, I'm not able to follow your latest post.

    VLeshka VV said:
    - the ping between san and prp is allways on.

    What is san and what is prp? Maybe a picture would help me understand what you are connecting. Are these the two ICE boards?

    VLeshka VV said:
    - there is no ping between ICE debugs (pru-prp) for any time (for example, 1 hour), and then ping is on. And note: if both ICE boots synchronously, there is no "ping off" in some cases.

    What is ICE debugs?

    What is "ping off"?

    Thank you.

  • Hi VLeshka,

    It's been a while since I've heard back from you on this. Can you provide some further feedback if this is still an important issue to you? Thank you.