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/AM3358: Beaglebone Black RGMII

Part Number: AM3358

Tool/software: Linux

LK"I

Hi,

I'm using Beaglebone black as a reference board.

on my custom board it'll be connected to a Gbit Ethernet PHY via RGMII1.

I've removed the 100Mb PHY  , and connected it to my Gbit Ethernet PHY to check.

I've changed the device tree:

am335x-bone-common.dtsi

cpsw_default: cpsw_default {
pinctrl-single,pins = <
/* Slave 1 */
0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mii1_txen.rgmii1_tctl */
0x118 (PIN_INPUT_PULLUP | MUX_MODE2) /* mii1_rxdv.rgmii1_rctl */
0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mii1_txd3.rgmii1_txd3 */
0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mii1_txd2.rgmii1_txd2 */
0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mii1_txd1.rgmii1_txd1 */
0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mii1_txd0.rgmii1_txd0 */
0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mii1_txclk.rgmii1_txclk */
0x130 (PIN_INPUT_PULLUP | MUX_MODE2) /* mii1_rxclk.rgmii1_rxclk */
0x134 (PIN_INPUT_PULLUP | MUX_MODE2) /* mii1_rxd3.rgmii1_rxd3 */
0x138 (PIN_INPUT_PULLUP | MUX_MODE2) /* mii1_rxd2.rgmii1_rxd2 */
0x13c (PIN_INPUT_PULLUP | MUX_MODE2) /* mii1_rxd1.rgmii1_rxd1 */
0x140 (PIN_INPUT_PULLUP | MUX_MODE2) /* mii1_rxd0.rgmii1_rxd0 */
>;
};
cpsw_sleep: cpsw_sleep {
pinctrl-single,pins = <
/* Slave 1 reset value */
0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
>;
};

davinci_mdio_default: davinci_mdio_default {
pinctrl-single,pins = <
/* MDIO */
AM33XX_IOPAD(0x948, PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0) /* mdio_data.mdio_data */
AM33XX_IOPAD(0x94c, PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_clk.mdio_clk */
>;
};
davinci_mdio_sleep: davinci_mdio_sleep {
pinctrl-single,pins = <
/* MDIO reset value */
AM33XX_IOPAD(0x948, PIN_INPUT_PULLDOWN | MUX_MODE7)
AM33XX_IOPAD(0x94c, PIN_INPUT_PULLDOWN | MUX_MODE7)
>;
};

&cpsw_emac0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "rgmii";
};
&mac {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_sleep>;
slaves = <1>;
status = "okay";
};
&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
status = "okay";
};

But , it doesn't seems to work, i've check the RGMII_TX_CLK coming from the Sitara, it doesn't show any clock at all.

Is there anything else i need to do in order to make the sitara start "talking" with RGMII? should i config anything else with the Kerenl configuration? or it just a matter of device tree configuration?

Harel

  • Just so I'm clear...you dead-bugged a RGMII PHY in place of the existing RMII PHY on the BB Black?

  • LK"I

     

    To be more accurate.

    I've removed the HDMI & the 100 PHY.

    and connected it with wire up to a EVB with the new PHY (actually it is Ethernet switch with build-in PHY ...)

    I can't see anything on the Sitara RGMII clock... so  I'm wondering what is wrong here...

    Harel

  • RGMII doesn't lend itself to blue-wiring of any kind as the timing on this interface is extremely tight. Also, because BBB was designed as an RMII (10/100) board, the PCB layout/timing may not be able to support RGMII (10/100/1000). 

    I'd recommend moving to the AM335x GP EVM as it has native support for RGMII.

  • LK"I

    I just want to check functionallity.

    I can reduce the clock speed to 10M

    Harel

  • Ensure that RXC is present. TXC will not be output in the absence of RXC.

  • -DK- said:
    RGMII doesn't lend itself to blue-wiring of any kind

    Actually I know of one case where someone successfully patched a gigabit phy to a BBB (for prototyping / proof of concept reasons), with a few feet of extra wire on the clock lines to provide 1-2ns delay (because of issues with internal delay). :D

    I still think pictures should have been made.

  • LK"I

    Since i'm connected to Ethernet Switch and i want to skip the MDIO ID check, i've changed the device tree to this:

    I also tried to changed the speed to 10, maybe it'll work at lower speed . (my connection to the switch is not optimized).

    &cpsw_emac0 {

    phy-mode = "rgmii";

    fixed-link {

    speed = <10>;

    full-duplex;

    };

    };

    this is what i'm geeting at linux console:

    [115630.033854] net eth0: initializing cpsw version 1.12 (0)
    [115630.039372] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
    [115630.045941] cpsw 4a100000.ethernet: ALE Table size 1024
    [115630.066481] Generic PHY fixed-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=fixed-0:00, irq=-1)
    [115630.100260] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
    [115630.106306] 8021q: adding VLAN 0 to HW filter on device eth0
    debian@arm:~$ [115631.104495] cpsw 4a100000.ethernet eth0: Link is Up - 10Mbps/Full - flow control off
    [115631.112558] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

    and ifconfig:


    eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC>  mtu 1500
            inet 169.254.235.247  netmask 255.255.0.0  broadcast 169.254.255.255
            inet6 fe80::9a5d:adff:fe7f:ca8b  prefixlen 64  scopeid 0x20<link>
            ether 98:5d:ad:7f:ca:8b  txqueuelen 1000  (Ethernet)
            RX packets 170533  bytes 15575118 (14.8 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 7924  bytes 4622096 (4.4 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 173

    although it report RX/TX packets, it doesn't detect the DHCP server.

    i also tried to staticly assign an IP, but it doesn't work.

    i'm now checking physically on the lines...  (and trying to apply the clk delay ...)

    any more ideas?

    Harel

  • The console log appears to report the interface is up, but the ifconfig command does not. Try an ifup eth0 or ifconfig eth0 up and see if this starts the dhcp process.

    Which SDK are you using?

    Also please attach a log of ethtool -S eth0, the interface is reporting lots of traffic but does not mean it is leaving the part.
  • NIC statistics:
         Good Rx Frames: 88
         Broadcast Rx Frames: 24
         Multicast Rx Frames: 64
         Pause Rx Frames: 0
         Rx CRC Errors: 0
         Rx Align/Code Errors: 0
         Oversize Rx Frames: 0
         Rx Jabbers: 0
         Undersize (Short) Rx Frames: 0
         Rx Fragments: 0
         Rx Octets: 13746
         Good Tx Frames: 0
         Broadcast Tx Frames: 0
         Multicast Tx Frames: 0
         Pause Tx Frames: 0
         Deferred Tx Frames: 0
         Collisions: 0
         Single Collision Tx Frames: 0
         Multiple Collision Tx Frames: 0
         Excessive Collisions: 0
         Late Collisions: 0
         Tx Underrun: 0
         Carrier Sense Errors: 136
         Tx Octets: 0
         Rx + Tx 64 Octet Frames: 33
         Rx + Tx 65-127 Octet Frames: 21
         Rx + Tx 128-255 Octet Frames: 0
         Rx + Tx 256-511 Octet Frames: 34
         Rx + Tx 512-1023 Octet Frames: 0
         Rx + Tx 1024-Up Octet Frames: 0
         Net Octets: 14695
         Rx Start of Frame Overruns: 0
         Rx Middle of Frame Overruns: 0
         Rx DMA Overruns: 0
         Rx DMA chan 0: head_enqueue: 1
         Rx DMA chan 0: tail_enqueue: 163
         Rx DMA chan 0: pad_enqueue: 0
         Rx DMA chan 0: misqueued: 0
         Rx DMA chan 0: desc_alloc_fail: 0
         Rx DMA chan 0: pad_alloc_fail: 0
         Rx DMA chan 0: runt_receive_buf: 0
         Rx DMA chan 0: runt_transmit_bu: 0
         Rx DMA chan 0: empty_dequeue: 0
         Rx DMA chan 0: busy_dequeue: 36
         Rx DMA chan 0: good_dequeue: 36
         Rx DMA chan 0: requeue: 0
         Rx DMA chan 0: teardown_dequeue: 0
         Tx DMA chan 0: head_enqueue: 135
         Tx DMA chan 0: tail_enqueue: 1
         Tx DMA chan 0: pad_enqueue: 0
         Tx DMA chan 0: misqueued: 1
         Tx DMA chan 0: desc_alloc_fail: 0
         Tx DMA chan 0: pad_alloc_fail: 0
         Tx DMA chan 0: runt_receive_buf: 0
         Tx DMA chan 0: runt_transmit_bu: 15
         Tx DMA chan 0: empty_dequeue: 135
         Tx DMA chan 0: busy_dequeue: 0
         Tx DMA chan 0: good_dequeue: 136
         Tx DMA chan 0: requeue: 0
         Tx DMA chan 0: teardown_dequeue: 0

    Internet Systems Consortium DHCP Client 4.3.5
    Copyright 2004-2016 Internet Systems Consortium.
    All rights reserved.
    For info, please visit www.isc.org/.../

    [ 1210.338745] net eth0: initializing cpsw version 1.12 (0)
    [ 1210.344149] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
    [ 1210.350573] cpsw 4a100000.ethernet: ALE Table size 1024
    [ 1210.362870] Generic PHY fixed-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=fixed-0:00, irq=-1)
    [ 1210.393864] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
    [ 1210.399766] 8021q: adding VLAN 0 to HW filter on device eth0
    Listening on LPF/eth0/98:5d:ad:7f:ca:8b
    Sending on   LPF/eth0/98:5d:ad:7f:ca:8b
    Sending on   Socket/fallback
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
    [ 1211.393173] cpsw 4a100000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx
    [ 1211.401228] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14

    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15