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/PROCESSOR-SDK-AM437X: Removing Ethernet interface from device tree

Part Number: PROCESSOR-SDK-AM437X
Other Parts Discussed in Thread: AM4378

Tool/software: Linux

I'm designing a board with the AM4378. We started designing based on the AM437x Starterkit and are currently using Linux SDK 4.3.0.5 with a build of the core image. I can't seem to find a working procedure to remove the ethernet connection on 'eth0' (RGMII1) and just use 'eth1' (RGMII2). I followed the steps from the post: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/391961  which made the linux image only see one ethernet connection (eth0) but both ports on the starterkit remained active. Only 'eth0' showed up when I ran ifconfig, but 'eth0' was assigned an IP address regardless of the port I plugged the cable into. For our application we have to use some of the pins associated with RGMII1 for eMMC on MMC1 since that is the only bootable pinout for MMC1 so I have to be able to dissociate those pins from RGMII1.

The section of the devicetree that appears to be relevant is: (starterkit settings)

&mac {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_sleep>;
dual_emac = <2>;
status = "okay";
};

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
status = "okay";
};

&cpsw_emac0 {
phy_id = <&davinci_mdio>, <4>;
phy-mode = "rgmii";
dual_emac_res_vlan = <1>;
};

&cpsw_emac1 {
phy_id = <&davinci_mdio>, <5>;
phy-mode = "rgmii";
dual_emac_res_vlan = <2>;
};

The settings I tried following the recommendations in the previously linked post resulted in this section in the file am437x-sk-evm.dts:

&mac {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_sleep>;
status = "okay";
};

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
status = "okay";
};

&cpsw_emac0 {
phy_id = <&davinci_mdio>, <4>;
phy-mode = "rgmii";
};

&cpsw_emac1 {
phy_id = <&davinci_mdio>, <5>;
phy-mode = "rgmii";
};

I've also tried reversing the pin order in the cpsw section of the pinmux

What I want, but what I'm clearly not coding correctly is something like:

&mac {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_sleep>;
status = "okay";
};

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
status = "okay";
};

&cpsw_emac0 {
phy_id = <&davinci_mdio>, <5>;
phy-mode = "rgmii";
}

  • Hi,
    Your last DTS snippet is looking close to me. Please take a look at this link here that I think describes what you are trying to do which is making the second cpsw interface the primary port.

    processors.wiki.ti.com/.../Linux_Core_CPSW_User's_Guide

    You will need the active slave definition described in the link above added to your mac node definition. This tells the cpsw driver that the second port is the primary port.

    active_slave = <1>;

    Regards,
    Schuyler
  • Ok, this had the same effect as the procedure in the link I posted in the original question. Both RJ45s were associated with 'eth0'. I'm surprised by this because the port I was trying to disable still worked even after I forced the IO pins to be configured as gpio inputs. 

    However, once this update was implemented I also commented out the '&cpsw_emac0' definition and the interface began behaving as desired. I guess this worked because the mdio bus didn't know the address for the phy that manages 'eth0' on the starter kit. I have tested this state by plugging in an ethernet cable into each RJ45. In the phy I want to work it behaved normally and in the phy I want to be disabled the processor is unaware that the cable is plugged in. 

    I assume that this is a safe configuration since I was able to remap the IO pins from rgmii1 as a 'hardware_pins' object and they seem to be accessible as gpios in some test code.