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.

PROCESSOR-SDK-AM335X: CPSW switch mode

Part Number: PROCESSOR-SDK-AM335X

Hi,

Iwant to know if we can configure the switch mode in the device tree, or userspace or kernel space ?

We have to disbale dual emac to configure the switch mode ?

And how we can activate the bridging mode ? 

thank you

  • By default it will be in switch mode. To enable dual emac mode you add a "dual_emac" property (no value) to the &mac node in your dts, and you can set the dual_emac_res_vlan property on &cpsw_emac0 and &cpsw_emac1 (doing so is optional, it defaults to 1 and 2 respectively). See for example this snippet from am335x-icev2.dts:

    &cpsw_emac0 {
    	phy-handle = <&ethphy0>;
    	phy-mode = "rmii";
    	dual_emac_res_vlan = <1>;
    };
    
    &cpsw_emac1 {
    	phy-handle = <&ethphy1>;
    	phy-mode = "rmii";
    	dual_emac_res_vlan = <2>;
    };
    
    &mac {
    	pinctrl-names = "default", "sleep";
    	pinctrl-0 = <&cpsw_default>;
    	pinctrl-1 = <&cpsw_sleep>;
    	status = "okay";
    	dual_emac;
    };

    If you've configured it in dual emac mode you'll see two separate ethernet interfaces in linux, which you can bridge together if you want (like any other ethernet interfaces).

  • Thank you for your answer, that helped me to resolve my issue.

  • Hello,

    I have just another question about how the both modes work.

    I guess that switch mode is supported by the ethernet controller but not by our CPU (that means this mode will be handled by Ethernet controller CPU ==> less load in our CPU).

    On the other hand the bridge to dual emca mode will be supported by our main CPU (that means that there is more load on our CPU).

    is True or False what i understand ?

  • That is correct. There's a 3-port managed switch (with VLAN support) embedded in the SoC, with the cpu plugged into port 0 while ports 1 and 2 are the two external (R)(G)MII interfaces. Once setup, packets are forwarded between ports 1 and 2 without any cpu attention.

    In "dual emac" mode, vlans are used to keep the ports 1 and 2 isolated from each other, while port 0 is a trunk port that sees both vlans, thus allowing it to treat them as separate ports. Some scheduling parameters are also changed to ensure fairness between the two ports.

    If you then use linux bridging to bridge those ports together, all traffic between ports 1 and 2 will take a fairly long route,
    (R)(G)MII ---> (p1) switch (p0) ---> (eth0) bridge (eth1) ---> (p0) switch (p2) ---> (R)(G)MII

    This will obviously increase latency, probably limit throughput, and in heavy traffic cause high cpu load. It does however allow you to use advanced linux bridging features like sophisticated L2 firewalling.

    A limitation of switch mode currently is that there doesn't seem to be a simple way to configure the second phy from linux userspace. Fortunately, manual phy configuration is rarely needed.

  • Thank you very much for this explanation, that allows me to understand more how the both modes work.

    In our system, we will need the both mode in run time. Is there a way to switch from one mode to another mode (switch mode ==> Dual emac or Dual emac ==> switch mode) without restarting our system (in run time) and without changing the device tree.

    If we have to change the device tree, is there a way to do it in run time ?

    Best regards

  • azeddine joudar1 said:

    In our system, we will need the both mode in run time. Is there a way to switch from one mode to another mode (switch mode ==> Dual emac or Dual emac ==> switch mode) without restarting our system (in run time) and without changing the device tree.

    If we have to change the device tree, is there a way to do it in run time ?

    Switching between them at runtime sounds very awkward. You'd need to unbind and rebind the driver (and hope this doesn't result in a kernel panic since platform drivers normally don't have to deal with hotplugging hence may not handle unbind gracefully). To make the driver use altered configuration when rebinding you'd need to add a module parameter that can be changed at runtime and overrides the DT configuration when the driver is probed. Alternatively you could perhaps use runtime overlays to modify the DT at runtime, but I don't recommend it. Runtime overlays are implemented in the beagleboard.org debian kernels, but never reached mainline and have always been buggy (especially removing overlays was prone to cause kernel panics), so beagleboard.org has actually deprecated them and stopped using them.

    My recommendation would be to forget about switching dual emac mode in the kernel: just use switch mode, and when necessary emulate dual emac mode by manually setting up the vlan configuration to isolate the ports and create the two vlan interfaces for them in linux (which you can then bridge together if you want to).