• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 101 subscribers
  • Views 3483 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: IEC 61850 certification with DP83822HF

henry kim
Intellectual 590 points
Part Number: AM5728
Other Parts Discussed in Thread: DP83822HF,

Tool/software: Linux

Hi,

 

There is no event of link drop while using DP83822HF in FX mode.

So my customer modify driver code to forcibly read phy status.

Above issue is shared on below e2e.

(https://e2e.ti.com/support/embedded/linux/f/354/t/616469 )

But the forcible reading leads a problem of IEC 61850 certification due to a slow-conversion of network redundancy while ethernet bonding.

So please let me know there is any optimized krnel driver only for DP83822HF or other solutions.

SDK version : ti-processor-sdk-linux-rt-am57xx-evm-03.01.00.06

  • 0
    TI__Guru**** 393215 points
    The software team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 30050 points

    Dear,

    I found there is no issue without FX mode in their Ethernet bonding test and they think it is enough to fast to compliance IEC61850.

    But, this FX mode should be used as it is standard protocol for optical communication in Korea.

    Please check this and how DP83822HF with FX mode can be used for IEC61850 certification.

    Thanks and Best Regards,

    SI.

  • 0 in reply to Sung-IL
    TI__Mastermind 39210 points
    Hi,

    At the moment I cannot comment on the DP838822HF driver, this is not supported by our team.

    However after looking at the referenced e2e post I see a change was made to a higher level phy.c driver and not in the supporting PHY driver.

    I apologize for asking but could you please attach the boot up log for your board and describe which ethernet interfaces the board is using and the PHYs that are attached? Assuming the board is AM57x based which version of the TI SDK are you using? What changes have been made to the kernel?

    Do you have a AM57x based TI EVM?

    Regards,
    Schuyler
  • 0 in reply to Schuyler Patton
    TI__Mastermind 30050 points

    Hi Schuyler,

    please check attached boot up log in below.

    AM5728_BootLog.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    U-Boot 2016.05-svn1 (Sep 11 2017 - 10:19:32 +0900)
    CPU : DRA752-GP ES2.0
    Model: TI AM5728 IDK
    Board: AM572x IDK REV <NULL>
    DRAM: 2 GiB
    MMC: no pinctrl for sdr104
    no pinctrl for ddr50
    no pinctrl for sdr50
    no pinctrl for sdr25
    no pinctrl for sdr12
    OMAP SD/MMC: 0, OMAP SD/MMC: 1
    ** Unable to use mmc 1:1 for loading the env **
    Using default environment
    I2C chip 50: requested alen 2 does not match chip offset_len 1
    SCSI: SATA link 0 timeout.
    AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
    flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
    scanning bus for devices...
    Found 0 device(s).
    Net:
    Warning: ethernet@48484000 using MAC address from ROM
    eth0: ethernet@48484000
    Hit any key to stop autoboot: 0
    MMC: no card present
    MMC: no card present
    MMC: no card present
    MMC: no card present
    switch to partitions #0, OK
    mmc1(part 0) is current device
    SD/MMC found on device 1
    SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000
    device 0 offset 0x1c0000, size 0x400000
    SF: 4194304 bytes @ 0x1c0000 Read: OK
    device 0 offset 0x180000, size 0x40000
    SF: 262144 bytes @ 0x180000 Read: OK
    Kernel image @ 0x82000000 [ 0x000000 - 0x3724b0 ]
    ## Flattened Device Tree blob at 88000000
    Booting using the fdt blob at 0x88000000
    Loading Device Tree to 8ffe5000, end 8ffffe28 ... OK
    Starting kernel ...
    Booting Linux on physical CPU 0x0
    Initializing cgroup subsys cpuset
    Initializing cgroup subsys cpu
    Initializing cgroup subsys cpuacct
    Linux version 4.4.19-rt25-gf572d285f0 (root@johnkim-VirtualBox) (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #17 SMP PREEMPT RT Thu Sep 14 09:16:43 KST 2017
    CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d
    CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
    Machine model: TI AM5728 IDK
    Reserved memory: created CMA memory pool at 0x0000000095800000, size 32 MiB
    Reserved memory: initialized node ipu1_cma@95800000, compatible id shared-dma-pool
    Reserved memory: created CMA memory pool at 0x0000000097800000, size 32 MiB
    Reserved memory: initialized node ipu2_cma@97800000, compatible id shared-dma-pool
    Reserved memory: created CMA memory pool at 0x0000000099800000, size 32 MiB
    Reserved memory: initialized node dsp1_cma@99800000, compatible id shared-dma-pool
    Reserved memory: created CMA memory pool at 0x000000009b800000, size 32 MiB
    Reserved memory: initialized node dsp2_cma@9b800000, compatible id shared-dma-pool
    cma: Reserved 24 MiB at 0x00000000fe400000
    Forcing write-allocate cache policy for SMP
    Memory policy: Data cache writealloc
    OMAP4: Map 0x00000000ffd00000 to fe600000 for dram barrier
    DRA752 ES2.0
    PERCPU: Embedded 11 pages/cpu @eed33000 s15168 r8192 d21696 u45056
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Their Ethernet interfaces are as below.

    eth0 device: KSZ9031 Chip / Full Duplex / MII / TX Mode
    eth2 device: DP83822HF / Full Duplex / MII / FX Mode / Phy Addr: 0
    eth3 device: DP83822HF / Full Duplex / MII / FX Mode / Phy Addr: 1

    And, they have not made any change to the linux kernel, and they changed only phy.c file.

    As you see in referenced e2e post, they removed 'interrupt' and used 'polling' to read Ethernet link status because they found interrupt was not generated to read link status in FX mode.

    Their PSDK version and development environments are

    Host PC OS: Ubuntu 16.04 linux 64bit

    AM5728 SDK: u-boot-2016.05 / linux-rt-4.4.19

    AM5728 SDK Ver: ti-processor-sdk-linux-rt-am57xx-evm-03.01.00.06

    IPC: ipc_3_43_02_04

    XDC: xdctools_3_32_00_06_core

    Please let me know if you need more information.

    Thanks and Best Regards,

    SI.

  • 0 in reply to Sung-IL
    TI__Mastermind 39210 points
    Hi SI,

    Thanks for the console data and kernel info. After looking at the post again I have a couple of questions.

    First what mode of Ethernet bonding is being used? There are 6 modes if I remember correctly and the fail over can be instantaneous. Can the customer please share how they are setting up the bonding between ports 2 and 3?

    The code change the customer performed is to the higher level PHY driver and will affect all the Ethernet PHYs in the system, is the PHY on eth0 performing correctly?

    Can the customer please attach the portion of the schematic regarding the PHYs and also please attach the DTS for the board?

    Regards,
    Schuyler
  • 0 in reply to Schuyler Patton
    TI__Mastermind 30050 points

    Hi Schuyler,

    There is no issue in Eth0, and it is working well.

    Ethernet Bonding is set-up as below.

    ifconfig eth2 down;
    ifconfig eth3 down;
    echo 1 > /sys/class/net/bond0/bonding/mode;
    echo 100 > /sys/class/net/bond0/bonding/miimon;
    ifconfig bond0 192.168.0.100 netmask 255.255.255.0 up;
    echo +eth2 > /sys/class/net/bond0/bonding/slaves;
    echo +eth3 > /sys/class/net/bond0/bonding/slaves;

    Their dts file is same as AM5728 IDK's and the phy portion is as below.

    They can not share full dts file due to security issue in their company. sorry for this.

    phy_dts.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    -------------------am572x-idk.dts-----------------------
    aliases {
    ethernet2 = &pruss2_emac0;
    ethernet3 = &pruss2_emac1;
    };
    ��..
    ��...
    &pruss2_mdio {
    pinctrl-names = "default";
    pinctrl-0 = <&pru2_pins_default>;
    reset-gpios = <&gpio5 8 GPIO_ACTIVE_LOW>,
    <&gpio5 9 GPIO_ACTIVE_LOW>;
    reset-delay-us = <2>; /* PHY datasheet states 1uS min */
    };
    --------------------------------------------------------------
    --------------am57xx-idk-common.dtsi------------------
    /* Dual-MAC Ethernet application node on PRU-ICSS2 */
    pruss2_eth {
    compatible = "ti,am57-prueth";
    pruss = <&pruss2>;
    sram = <&ocmcram1>;
    interrupt-parent = <&pruss2_intc>;
    pruss2_emac0: ethernet-mii0 {
    phy-handle = <&pruss2_eth0_phy>;
    phy-mode = "mii";
    interrupts = <20>, <22>;
    interrupt-names = "rx", "tx";
    /* Filled in by bootloader */
    local-mac-address = [00 00 00 00 00 00];
    };
    pruss2_emac1: ethernet-mii1 {
    phy-handle = <&pruss2_eth1_phy>;
    phy-mode = "mii";
    interrupts = <21>, <23>;
    interrupt-names = "rx", "tx";
    /* Filled in by bootloader */
    local-mac-address = [00 00 00 00 00 00];
    };
    };
    ��..
    ��..
    &pruss2 {
    status = "okay";
    pru2_0: pru0@4b2b4000 {
    interrupt-parent = <&pruss2_intc>;
    interrupts = <16>, <17>;
    interrupt-names = "vring", "kick";
    status = "okay";
    };
    pru2_1: pru1@4b2b8000 {
    interrupt-parent = <&pruss2_intc>;
    interrupts = <18>, <19>;
    interrupt-names = "vring", "kick";
    status = "okay";
    };
    };
    &pruss2_mdio {
    status = "okay";
    pruss2_eth0_phy: ethernet-phy@0 {
    reg = <0>;
    interrupt-parent = <&gpio3>;
    interrupts = <30 IRQ_TYPE_EDGE_FALLING>;
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Their schematic is as below.

    Thanks and Best Regards,

    SI.

  • 0 in reply to Sung-IL
    TI__Mastermind 39210 points
    Hi SI,
    The mdio polling may not happen fast enough for the 100mS polling based on the miimon variable being passed. What is the fail over timing required? Have they considered using bonding mode 3 which sends data on both interfaces simultaneously? The downside of mode 3 is double the data bandwidth but if a short time is required for link fail over this might be a solution.

    How is the customer measuring the timing of the fail over with mode 1?

    Regards,
    Schuyler
  • 0 in reply to Schuyler Patton
    TI__Mastermind 30050 points
    Hi Schuyler,

    They need to get all 'Goose Data' within 1ms delay.
    And, also they can not use bonding mode 3 because bonding mode 3 transfers though all Ethernet Inferface. They should use only 1 Mac and 1 address bonding with redundant network.


    Thanks and Best Regards,
    SI.
  • 0 in reply to Sung-IL
    TI__Mastermind 39210 points
    Hi SI,

    Could the customer please provide the method they are using to measure the link fail over for mode 1?

    I want to make sure I understand the customer requirement for this application. Bonding combines two ports into 1 MAC address, the bond interface inherits the MAC of the first port added. In this example bond0 is a single interface. Mode 3 would transfer simultaneously the same redundant data through both (eth2 & eth3) interfaces that are bonded together as 1 MAC and IP address in this example. Could the customer please explain their concern with the redundant data being on the bonded interfaces?

    Mode 3 would provide the best redundancy as the question of link fail time over would not matter as the data transmitted is redundant.

    When performing the link failure over testing before making the change to phy.c was a link failure correctly reported?

    What is the topology of the customer network? Has the customer considered using a HSR/PRP type topology and protocol? This protocol was developed spefically for IEC 61850 if I am not mistaken. This protocol is similar to bonding mode 3.

    Best Regards,
    Schuyler
  • 0 in reply to Schuyler Patton
    TI__Mastermind 30050 points
    Hi Schuyler,

    This issue was resolved, and they found there was no delay issue with Bonding mode 3.
    They misunderstood about Bonding mode 3, and now decided to use Bonding mode 3 thanks to your help.

    They are using commercial IEC61850 certification test tool to test Ethernet bonding.
    Thanks again for your support and guidance.


    Thanks and Best Regards,
    SI.