AM335x ICE board Linux support

Hi,

We are working on getting Linux on AM335X Industrial Communication Engine board (ICE) [1].

This board has 2 Ethernet ports and each of them can be used either in RMII mode connected to the CPSW Ethernet MAC *or* in MII mode connected to the PRU Ethernet MAC.

The decision about the Ethernet port's mode is made by the user by setting a jumper near the Ethernet port before power up. This is a boot time configurable setting and doesn't need to change at runtime.

So 4 configurations are possible:

    ETH0	ETH1
    ----	----
    RMII	RMII
    RMII	MII
    MII		RMII	(probably redundant and not needed)
    MII		MII

Based on the port configuration, software (u-boot or Linux) needs to set the right pinmux, set a GPIOs (that controls external Mux), configure an external clock generator and enable the right device driver for the respective Ethernet port.

Clock generator needs to be configured because different clock rates are required for RMII vs MII mode.

Now question is how all this can be done on u-boot + Linux?

I already have a working solution where I create different DT blobs for the 3 configurations and have u-boot detect the mode and load the correct DT blob and also configure the clock.

You can see how the kernel patches look like here [2]

Is this approach acceptable? If not is there any better way to do this? Thanks.

cheers,
-roger

[1] AM3359 ICE board
http://www.ti.com/tool/tmdsice3359
http://processors.wiki.ti.com/index.php/AM335x_Industrial_Communication_Engine_%28ICE%29_EVM_HW_User_Guide

[2] Device tree patches
https://github.com/rogerq/linux/commit/9a9cf6a15f779fddf91dba2370627aabf19aeff5
https://github.com/rogerq/linux/commit/c87e8fa5b14f156a91883fd506e9dd8f7ccf95cf
https://github.com/rogerq/linux/commit/d9cdd25e8c3878292d7f4180af8d3ac42b9645c4

Quoted 17 lines · Roger Quadros

We are working on getting Linux on AM335X Industrial Communication Engine board (ICE) [1].

This board has 2 Ethernet ports and each of them can be used either in RMII mode connected to the CPSW Ethernet MAC *or* in MII mode connected to the PRU Ethernet MAC.

The decision about the Ethernet port's mode is made by the user by setting a jumper near the Ethernet port before power up. This is a boot time configurable setting and doesn't need to change at runtime.

So 4 configurations are possible:

    ETH0	ETH1
    ----	----
    RMII	RMII
    RMII	MII
    MII		RMII	(probably redundant and not needed)
    MII		MII

Quoted 3 lines

Based on the port configuration, software (u-boot or Linux) needs to set the right pinmux, set a GPIOs (that controls external Mux), configure an external clock generator and enable the right device driver for the respective Ethernet port.

Quoted 7 lines

Clock generator needs to be configured because different clock rates are required for RMII vs MII mode.

Now question is how all this can be done on u-boot + Linux?

I already have a working solution where I create different DT blobs for the 3 configurations and have u-boot detect the mode and load the correct DT blob and also configure the clock.

Quoted 3 lines

You can see how the kernel patches look like here [2]

Is this approach acceptable? If not is there any better way to do this? Thanks.

Quoted 3 lines

[1] AM3359 ICE board
http://www.ti.com/tool/tmdsice3359
http://processors.wiki.ti.com/index.php/AM335x_Industrial_Communication_Engine_%28ICE%29_EVM_HW_User_Guide

There are 2 ICE board version. v1 and v2. The above wiki link is wrong. We are dealing with the v2 board below
http://processors.wiki.ti.com/index.php/AM335x_Industrial_Communication_Engine_EVM_Rev2_1_HW_User_Guide

Quoted 5 lines

[2] Device tree patches
https://github.com/rogerq/linux/commit/9a9cf6a15f779fddf91dba2370627aabf19aeff5
https://github.com/rogerq/linux/commit/c87e8fa5b14f156a91883fd506e9dd8f7ccf95cf
https://github.com/rogerq/linux/commit/d9cdd25e8c3878292d7f4180af8d3ac42b9645c4

Quoted 18 lines · Roger Quadros

Quoted 17 lines · Roger Quadros

We are working on getting Linux on AM335X Industrial Communication Engine board (ICE) [1].

This board has 2 Ethernet ports and each of them can be used either in RMII mode connected to the CPSW Ethernet MAC *or* in MII mode connected to the PRU Ethernet MAC.

The decision about the Ethernet port's mode is made by the user by setting a jumper near the Ethernet port before power up. This is a boot time configurable setting and doesn't need to change at runtime.

So 4 configurations are possible:

    ETH0	ETH1
    ----	----
    RMII	RMII
    RMII	MII
    MII		RMII	(probably redundant and not needed)
    MII		MII

Quoted 3 lines

Quoted 3 lines

Based on the port configuration, software (u-boot or Linux) needs to set the right pinmux, set a GPIOs (that controls external Mux), configure an external clock generator and enable the right device driver for the respective Ethernet port.

Ideally this would be runtime detected..

Quoted 7 lines

Quoted 7 lines

Clock generator needs to be configured because different clock rates are required for RMII vs MII mode.

Now question is how all this can be done on u-boot + Linux?

I already have a working solution where I create different DT blobs for the 3 configurations and have u-boot detect the mode and load the correct DT blob and also configure the clock.

If u-boot can detect the mode, can kernel also detect the mode?

You can have multiple named pinctrl states no problem that you could select from based on the detection. Not sure if that solves all the configuration issues though.

Quoted 3 lines

Quoted 3 lines

You can see how the kernel patches look like here [2]

Is this approach acceptable? If not is there any better way to do this? Thanks.

I guess for now if no runtime detection is possible in the kernel.

Regards,

Tony

Quoted 12 lines

Quoted 3 lines

[1] AM3359 ICE board
http://www.ti.com/tool/tmdsice3359
http://processors.wiki.ti.com/index.php/AM335x_Industrial_Communication_Engine_%28ICE%29_EVM_HW_User_Guide

There are 2 ICE board version. v1 and v2. The above wiki link is wrong. We are dealing with the v2 board below
http://processors.wiki.ti.com/index.php/AM335x_Industrial_Communication_Engine_EVM_Rev2_1_HW_User_Guide

Quoted 5 lines

[2] Device tree patches
https://github.com/rogerq/linux/commit/9a9cf6a15f779fddf91dba2370627aabf19aeff5
https://github.com/rogerq/linux/commit/c87e8fa5b14f156a91883fd506e9dd8f7ccf95cf
https://github.com/rogerq/linux/commit/d9cdd25e8c3878292d7f4180af8d3ac42b9645c4

Quoted 1 line · Tony Lindgren

I guess for now if no runtime detection is possible in the kernel.

There are 2 ways to detect them mode
1) Enabe GPIO rising edge detect interrupt and reset the Ethernet PHY
2) read a PHY register over MDIO bus

I'm not very sure where this can be done in the kernel.

Even if there is some place to do the detection, how do we go about reconfiguring the device tree?

Quoted 3 lines · Roger Quadros

Quoted 1 line · Tony Lindgren

I guess for now if no runtime detection is possible in the kernel.

Quoted 5 lines

There are 2 ways to detect them mode
1) Enabe GPIO rising edge detect interrupt and reset the Ethernet PHY
2) read a PHY register over MDIO bus

I'm not very sure where this can be done in the kernel.

We already have some PHY detection over MDIO detection in place, so that's probably the most generic solution.

Quoted 3 lines

Even if there is some place to do the detection, how do we go about reconfiguring the device tree?

You may not need to, you can have several named pin states:

pinctrl-names = "default", "phy-foo", "phy-bar";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_phy_foo>;
pinctrl-2 = <&cpsw_phy_bar>;
...

Then have the common pins in cpsw_default, and manually enable the other pinctrl groups based on the detection. We already have that going on in am335x-bone-common.dtsi with the &mac entry for cpsw.

But maybe you have other detection issues too beyond setting the pins?

Quoted 10 lines · Tony Lindgren

Quoted 8 lines · Roger Quadros

Quoted 1 line · Tony Lindgren

I guess for now if no runtime detection is possible in the kernel.

There are 2 ways to detect them mode
1) Enabe GPIO rising edge detect interrupt and reset the Ethernet PHY
2) read a PHY register over MDIO bus

I'm not very sure where this can be done in the kernel.

Quoted 2 lines

We already have some PHY detection over MDIO detection in place, so that's probably the most generic solution.

Sorry, I didn't get you.
Based on the PHY node we need to switch the MAC driver. i.e. either CPSW or PRUeth.
The PHY driver remains the same in both modes.

Quoted 11 lines

Quoted 2 lines

Even if there is some place to do the detection, how do we go about reconfiguring the device tree?

You may not need to, you can have several named pin states:

pinctrl-names = "default", "phy-foo", "phy-bar";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_phy_foo>;
pinctrl-2 = <&cpsw_phy_bar>;
...

Quoted 4 lines

Then have the common pins in cpsw_default, and manually enable the other pinctrl groups based on the detection. We already have that going on in am335x-bone-common.dtsi with the &mac entry for cpsw.

Probably I'm looking at the wrong place but in am353x-bone-common.dtsi I only see "default" and "sleep" pins.

Quoted 3 lines

But maybe you have other detection issues too beyond setting the pins?

It is not only about the pinmux but using an entirely different MAC driver. So we need to enable/disable different MAC drivers.

It gets even trickier if one port is assigned to one MAC driver and the other one to another MAC driver. The pinmux now has to be port specific and the cpsw driver has to be updated to support port specific pinmux. As of now it handles only one pinmux group for both its ports.