• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1192 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.

XAUI Linux driver bringup

Revenant
Prodigy 80 points
Other Parts Discussed in Thread: TCI6638K2K

Hello TI,

We are bringing up the XAUI driver on the TCI6638K2K EVM board. I am using the kernel from this link - https://git.ti.com/keystone-linux/linux

Additionally i have followed the steps to enable 10GE driver functionality from the MCSDK UG steps given here:

http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#10Gig_Ethernet_Driver

I connected the RTM BOC EVM to the XAUI interface on the K2K EVM and obtained the following logs from the kernel

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.61 (user@user-ubuntu) (gcc version 4.7.3 20130226 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.03-20130313
- Linaro GCC 2013.03) ) #1 Mon Jun 13 11:08:34 IST 2016

....

[    1.870000] libphy: GPIO Bitbanged MDIO: probed
[    1.880000] mdio_bus gpio-ffffffed: cannot get PHY at address 0
[    1.890000] mdio_bus gpio-ffffffed: cannot get PHY at address 1

[    1.890000] tun: Universal TUN/TAP device driver, 1.6
[    1.900000] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    1.900000] keystone-netcp 2090000.netcp: missing num_serdes parameter
[    1.910000] keystone-netcp 2090000.netcp: missing serdes_lanes parameter
[    1.920000] keystone-netcp 2090000.netcp: missing serdes_ref_clk parameter
[    1.920000] keystone-netcp 2090000.netcp: missing serdes_baud_rate parameter
[    1.930000] keystone-netcp 2090000.netcp: missing serdes_rate_mode parameter
[    1.940000] keystone-netcp 2090000.netcp: missing serdes_phy_intf parameter
[    1.950000] keystone-netcp 2090000.netcp: missing serdes_loopback parameter
[    1.950000] keystone-netcp 2090000.netcp: Missing cpts_clock_mult property in the DT.
[    1.960000] keystone-netcp 2090000.netcp: Missing cpts_clock_shift property in the DT.
[    1.970000] keystone-netcp 2090000.netcp: Missing cpts_clock_div property in the DT.
[    1.980000] keystone-netcp 2090000.netcp: Created interface "eth0"
[    1.980000] keystone-netcp 2090000.netcp: dma_chan_name nettx0
[    1.990000] keystone-netcp 2090000.netcp: Created interface "eth1"
[    1.990000] keystone-netcp 2090000.netcp: dma_chan_name nettx1
[    2.000000] keystone-netcp 2090000.netcp: Created interface "eth2"
[    2.010000] keystone-netcp 2090000.netcp: dma_chan_name nettx2
[    2.010000] keystone-netcp 2090000.netcp: Created interface "eth3"
[    2.020000] keystone-netcp 2090000.netcp: dma_chan_name nettx3
[    2.030000] XGE serdes config:
[    2.030000]   ref_clk=156.25MHz, link_rate=10.3125G, lanes=2
[    2.030000]   c1=2, c2=0, cm=2, tx_att=12, tx_vreg=4
[    2.040000]   eq flags: vreg=1, cdfe=1, offset=1
[    2.040000] XGE: serdes reset
[    3.270000] XGE: timeout waiting for serdes link up
[    3.280000] keystone-netcp 2f00000.netcp: Created interface "eth4"
[    3.280000] keystone-netcp 2f00000.netcp: dma_chan_name xgetx0
[    3.290000] XGE: serdes reset
[    4.520000] XGE: timeout waiting for serdes link up
[    4.520000] keystone-netcp 2f00000.netcp: Created interface "eth5"
[    4.530000] keystone-netcp 2f00000.netcp: dma_chan_name xgetx1
[    4.530000] XGE: serdes reset
[    5.760000] XGE: timeout waiting for serdes link up

I would like to know the reason for the timeout and whether the initialization is complete or pending.

I am using the MCSDK LINUX 3_01_04_07

ROOTFS Image - arago-console-image-k2hk-evm.cpio.gz

I am loading all the images directly in memory through CCS via the on-board debugger. The kernel is started using the bootm command

after all the images are loaded to memory - bootm 0x88000000 - 0x87000000

Could you please let us know the reason for this behavior. Are there any additional  .config / DTS file settings or dependencies on the ROOTFS ?

Could the SerDES reset be influenced by the debugger leading to unexpected behavior ?

Regards

- Rishi

  • 0
    TI__Guru** 116100 points
    Dear Rishi,

    Able to up the 10G ethernet port ?

    ifconfig eth4 up
    ifconfig eth5 up

    Can you please try the latest processor SDK package for K2H/K2K board ?
    www.ti.com/.../processor_sw.page

    Also please refer to the following e2e discussion.
    e2e.ti.com/.../1875094
  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 80 points

    Hi Titus,

    Yes, i was able to bring it up...

    Regardless of the timeout message i executed the ifconfig eth4/5 up commands and the commands were successful.

    However, i have disabled SMP and running Linux on only ARM Core 0. So, now i am getting this - hwqueue.12: Failed to set IRQ affinity

    message. I am guessing that the hwqueue IRQ is hard-coded to be routed to a core other than 0 ? Or is it safe to ignore. I have yet to check

    ping function on this port by interfacing it to external XAUI equipment. Will update on this thread if that succeeds...

    root@k2hk-evm:~# ifconfig eth4 up
    [  498.790000] keystone-hwqueue hwqueue.12: Failed to set IRQ affinity
    [  498.790000] keystone-netcp 2f00000.netcp: initialize cpsw version 1.1 (0) CPSW identification value 0x4ee3
    [  498.800000] keystone-netcp 2f00000.netcp: Created a cpsw ale engine
    [  498.810000] net eth4: netcp device eth4 opened
    [  498.820000] IPv6: ADDRCONF(NETDEV_UP): eth4: link is not ready
    [  498.820000] 8021q: adding VLAN 0 to HW filter on device eth4
    root@k2hk-evm:~# [  498.910000] IPv6: ADDRCONF(NETDEV_CHANGE): eth4: link becomes ready

    Regards

    - Rishi

  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 80 points

    Hi Titus,

    As i mentioned earlier we are able to bring up both the Eth4 and Eth5 interfaces. The IRQ affinity message can be ignored.

    However i am unable to ping over the 10 GBEthernet port to our test equipment.

    We are suspecting it is an issue with the RTM-BoC.

    Additionally at this link -

    there are two configurations of the BoC mentioned -  Rev A RTM-BOC with 10Gig PHY and Rev. B/C RTM-BOC with Dual Retimer

    We have Rev B/C. Therefore do i have to make the changes mentioned for Rev A as well in the DTS ?