AM335x ICE board Linux support

AM335x ICE board Linux support

[Roger Quadros]

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


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x ICE board Linux support

[Roger Quadros]

+Rob

On 25/04/16 14:59, Roger Quadros wrote:
> 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

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
> 
> [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
> 
> 

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x ICE board Linux support

[Tony Lindgren]

* Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160426 01:42]:
> On 25/04/16 14:59, Roger Quadros wrote:
> > 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.

Ideally this would be runtime detected..

> > 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.

> > 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

> > [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
> > 
> > [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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x ICE board Linux support

[Roger Quadros]

Hi Tony,

On 26/04/16 18:10, Tony Lindgren wrote:
> * Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160426 01:42]:
>> On 25/04/16 14:59, Roger Quadros wrote:
>>> 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.
> 
> Ideally this would be runtime detected..
> 
>>> 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.
> 
>>> 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.

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?

cheers,
-roger

> 
> Regards,
> 
> Tony
> 
>>> [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
>>>
>>> [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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x ICE board Linux support

[Tony Lindgren]

* Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160429 03:10]:
> On 26/04/16 18:10, Tony Lindgren wrote:
> > 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.

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

> 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?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x ICE board Linux support

[Roger Quadros]

On 29/04/16 18:31, Tony Lindgren wrote:
> * Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160429 03:10]:
>> On 26/04/16 18:10, Tony Lindgren wrote:
>>> 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.
> 
> 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.

> 
>> 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.

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

> 
> 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.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM335x ICE board Linux support

[Tony Lindgren]

* Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160502 01:25]:
> On 29/04/16 18:31, Tony Lindgren wrote:
> > * Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160429 03:10]:
> >> On 26/04/16 18:10, Tony Lindgren wrote:
> >>> 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.
> > 
> > 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.

OK

> >> 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.
> 
> Probably I'm looking at the wrong place but in am353x-bone-common.dtsi
> I only see "default" and "sleep" pins.
> 
> > 
> > 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.

OK I guess up to you to figure out what makes most sense here.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html