| Message ID | 20240926-th1520-dwmac-v2-3-f34f28ad1dc9@tenstorrent.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add the dwmac driver support for T-HEAD TH1520 SoC | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/vmtest-fixes-PR | fail | merge-conflict |
> +&mdio0 { > + phy0: ethernet-phy@1 { > + reg = <1>; > + }; > + > + phy1: ethernet-phy@2 { > + reg = <2>; > + }; > +}; Two PHYs on one bus... > + gmac1: ethernet@ffe7060000 { > + compatible = "thead,th1520-gmac", "snps,dwmac-3.70a"; > + reg = <0xff 0xe7060000 0x0 0x2000>, <0xff 0xec004000 0x0 0x1000>; > + reg-names = "dwmac", "apb"; > + interrupts = <67 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "macirq"; > + clocks = <&clk CLK_GMAC_AXI>, <&clk CLK_GMAC_AXI>; > + clock-names = "stmmaceth", "pclk"; > + snps,pbl = <32>; > + snps,fixed-burst; > + snps,multicast-filter-bins = <64>; > + snps,perfect-filter-entries = <32>; > + snps,axi-config = <&stmmac_axi_config>; > + status = "disabled"; > + > + mdio1: mdio { > + compatible = "snps,dwmac-mdio"; > + #address-cells = <1>; > + #size-cells = <0>; > + }; > + }; > + > + gmac0: ethernet@ffe7070000 { > + compatible = "thead,th1520-gmac", "snps,dwmac-3.70a"; > + reg = <0xff 0xe7070000 0x0 0x2000>, <0xff 0xec003000 0x0 0x1000>; > + reg-names = "dwmac", "apb"; > + interrupts = <66 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "macirq"; > + clocks = <&clk CLK_GMAC_AXI>, <&clk CLK_GMAC_AXI>; And the MACs are listed in opposite order. Does gmac1 probe first, find the PHY does not exist, and return -EPROBE_DEFER. Then gmac0 probes successfully, and then sometime later gmac1 then reprobes? I know it is normal to list nodes in address order, but you might be able to avoid the EPROBE_DEFER if you reverse the order. Andrew
On Thu, Sep 26, 2024 at 08:39:29PM +0200, Andrew Lunn wrote: > > +&mdio0 { > > + phy0: ethernet-phy@1 { > > + reg = <1>; > > + }; > > + > > + phy1: ethernet-phy@2 { > > + reg = <2>; > > + }; > > +}; > > Two PHYs on one bus... Thanks for pointing this out. I will move phy1 to mdio1. > > > + gmac1: ethernet@ffe7060000 { > > + compatible = "thead,th1520-gmac", "snps,dwmac-3.70a"; > > + reg = <0xff 0xe7060000 0x0 0x2000>, <0xff 0xec004000 0x0 0x1000>; > > + reg-names = "dwmac", "apb"; > > + interrupts = <67 IRQ_TYPE_LEVEL_HIGH>; > > + interrupt-names = "macirq"; > > + clocks = <&clk CLK_GMAC_AXI>, <&clk CLK_GMAC_AXI>; > > + clock-names = "stmmaceth", "pclk"; > > + snps,pbl = <32>; > > + snps,fixed-burst; > > + snps,multicast-filter-bins = <64>; > > + snps,perfect-filter-entries = <32>; > > + snps,axi-config = <&stmmac_axi_config>; > > + status = "disabled"; > > + > > + mdio1: mdio { > > + compatible = "snps,dwmac-mdio"; > > + #address-cells = <1>; > > + #size-cells = <0>; > > + }; > > + }; > > + > > + gmac0: ethernet@ffe7070000 { > > + compatible = "thead,th1520-gmac", "snps,dwmac-3.70a"; > > + reg = <0xff 0xe7070000 0x0 0x2000>, <0xff 0xec003000 0x0 0x1000>; > > + reg-names = "dwmac", "apb"; > > + interrupts = <66 IRQ_TYPE_LEVEL_HIGH>; > > + interrupt-names = "macirq"; > > + clocks = <&clk CLK_GMAC_AXI>, <&clk CLK_GMAC_AXI>; > > And the MACs are listed in opposite order. Does gmac1 probe first, > find the PHY does not exist, and return -EPROBE_DEFER. Then gmac0 > probes successfully, and then sometime later gmac1 then reprobes? > > I know it is normal to list nodes in address order, but you might be > able to avoid the EPROBE_DEFER if you reverse the order. The probe order seems to always be the ethernet@ffe7060000 (gmac1) first and then ethernet@ffe7070000 (gmac0). I do not see any probe deferral in the boot log [1]. Thanks, Drew [1] https://gist.github.com/pdp7/02a44b024bdb6be5fe61ac21303ab29a
On Thu, Sep 26, 2024 at 12:13:06PM -0700, Drew Fustini wrote: > On Thu, Sep 26, 2024 at 08:39:29PM +0200, Andrew Lunn wrote: > > > +&mdio0 { > > > + phy0: ethernet-phy@1 { > > > + reg = <1>; > > > + }; > > > + > > > + phy1: ethernet-phy@2 { > > > + reg = <2>; > > > + }; > > > +}; > > > > Two PHYs on one bus... > > Thanks for pointing this out. I will move phy1 to mdio1. ??? Are you saying the two PHYs are not on the same bus? > > > + gmac1: ethernet@ffe7060000 { > > > + compatible = "thead,th1520-gmac", "snps,dwmac-3.70a"; > > > + reg = <0xff 0xe7060000 0x0 0x2000>, <0xff 0xec004000 0x0 0x1000>; > > > + reg-names = "dwmac", "apb"; > > > + interrupts = <67 IRQ_TYPE_LEVEL_HIGH>; > > > + interrupt-names = "macirq"; > > > + clocks = <&clk CLK_GMAC_AXI>, <&clk CLK_GMAC_AXI>; > > > + clock-names = "stmmaceth", "pclk"; > > > + snps,pbl = <32>; > > > + snps,fixed-burst; > > > + snps,multicast-filter-bins = <64>; > > > + snps,perfect-filter-entries = <32>; > > > + snps,axi-config = <&stmmac_axi_config>; > > > + status = "disabled"; > > > + > > > + mdio1: mdio { > > > + compatible = "snps,dwmac-mdio"; > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + }; > > > + }; > > > + > > > + gmac0: ethernet@ffe7070000 { > > > + compatible = "thead,th1520-gmac", "snps,dwmac-3.70a"; > > > + reg = <0xff 0xe7070000 0x0 0x2000>, <0xff 0xec003000 0x0 0x1000>; > > > + reg-names = "dwmac", "apb"; > > > + interrupts = <66 IRQ_TYPE_LEVEL_HIGH>; > > > + interrupt-names = "macirq"; > > > + clocks = <&clk CLK_GMAC_AXI>, <&clk CLK_GMAC_AXI>; > > > > And the MACs are listed in opposite order. Does gmac1 probe first, > > find the PHY does not exist, and return -EPROBE_DEFER. Then gmac0 > > probes successfully, and then sometime later gmac1 then reprobes? > > > > I know it is normal to list nodes in address order, but you might be > > able to avoid the EPROBE_DEFER if you reverse the order. > > The probe order seems to always be the ethernet@ffe7060000 (gmac1) first > and then ethernet@ffe7070000 (gmac0). I do not see any probe deferral > in the boot log [1]. > [1] https://gist.github.com/pdp7/02a44b024bdb6be5fe61ac21303ab29a So two PHYs are found, so they must be on the same bus. It could well be that this MAC driver does not connect to the PHY until the interface is opened. That is a good 30 seconds after the driver probes in this log message. So there has been plenty of time for the PHYs to be found. What would be interesting is if you used NFS root. Then the interface would be opened much faster, and you might see an EPROBE_DEFER. But i'm just speculating. If it works for you, there is no need to do more. Andrew
On Thu, Sep 26, 2024 at 09:30:32PM +0200, Andrew Lunn wrote: > On Thu, Sep 26, 2024 at 12:13:06PM -0700, Drew Fustini wrote: > > On Thu, Sep 26, 2024 at 08:39:29PM +0200, Andrew Lunn wrote: > > > > +&mdio0 { > > > > + phy0: ethernet-phy@1 { > > > > + reg = <1>; > > > > + }; > > > > + > > > > + phy1: ethernet-phy@2 { > > > > + reg = <2>; > > > > + }; > > > > +}; > > > > > > Two PHYs on one bus... > > > > Thanks for pointing this out. I will move phy1 to mdio1. > > ??? > > Are you saying the two PHYs are not on the same bus? Sorry, this is my first time working on an Ethernet driver and I misunderstood. Sipeed only shares the schematic of the baseboard for the LPi4a [1]. There are pages for GMAC Ethernet0 and GMAC Ethernet1. Each shows 4 MDIO differential pairs going into a SG4301G transformer. I believe that RTL8211F-CG phy chips are on the LM4A SoM board which contains the TH1520 SoC. Unfortunately, Sipeed does not provide a schematic of the SoM so its hard for me to inspect how the phy chips are wired up. Vendor kernel [2] that Sipeed uses has: mdio0 { #address-cells = <1>; #size-cells = <0>; compatible = "snps,dwmac-mdio"; phy_88E1111_0: ethernet-phy@0 { reg = <0x1>; }; phy_88E1111_1: ethernet-phy@1 { reg = <0x2>; }; }; so I think that does mean they are on the same MDIO bus. > > > > > + gmac1: ethernet@ffe7060000 { > > > > + compatible = "thead,th1520-gmac", "snps,dwmac-3.70a"; > > > > + reg = <0xff 0xe7060000 0x0 0x2000>, <0xff 0xec004000 0x0 0x1000>; > > > > + reg-names = "dwmac", "apb"; > > > > + interrupts = <67 IRQ_TYPE_LEVEL_HIGH>; > > > > + interrupt-names = "macirq"; > > > > + clocks = <&clk CLK_GMAC_AXI>, <&clk CLK_GMAC_AXI>; > > > > + clock-names = "stmmaceth", "pclk"; > > > > + snps,pbl = <32>; > > > > + snps,fixed-burst; > > > > + snps,multicast-filter-bins = <64>; > > > > + snps,perfect-filter-entries = <32>; > > > > + snps,axi-config = <&stmmac_axi_config>; > > > > + status = "disabled"; > > > > + > > > > + mdio1: mdio { > > > > + compatible = "snps,dwmac-mdio"; > > > > + #address-cells = <1>; > > > > + #size-cells = <0>; > > > > + }; > > > > + }; > > > > + > > > > + gmac0: ethernet@ffe7070000 { > > > > + compatible = "thead,th1520-gmac", "snps,dwmac-3.70a"; > > > > + reg = <0xff 0xe7070000 0x0 0x2000>, <0xff 0xec003000 0x0 0x1000>; > > > > + reg-names = "dwmac", "apb"; > > > > + interrupts = <66 IRQ_TYPE_LEVEL_HIGH>; > > > > + interrupt-names = "macirq"; > > > > + clocks = <&clk CLK_GMAC_AXI>, <&clk CLK_GMAC_AXI>; > > > > > > And the MACs are listed in opposite order. Does gmac1 probe first, > > > find the PHY does not exist, and return -EPROBE_DEFER. Then gmac0 > > > probes successfully, and then sometime later gmac1 then reprobes? > > > > > > I know it is normal to list nodes in address order, but you might be > > > able to avoid the EPROBE_DEFER if you reverse the order. > > > > The probe order seems to always be the ethernet@ffe7060000 (gmac1) first > > and then ethernet@ffe7070000 (gmac0). I do not see any probe deferral > > in the boot log [1]. > > > [1] https://gist.github.com/pdp7/02a44b024bdb6be5fe61ac21303ab29a > > So two PHYs are found, so they must be on the same bus. > > It could well be that this MAC driver does not connect to the PHY > until the interface is opened. That is a good 30 seconds after the > driver probes in this log message. So there has been plenty of time > for the PHYs to be found. > > What would be interesting is if you used NFS root. Then the interface > would be opened much faster, and you might see an EPROBE_DEFER. But > i'm just speculating. If it works for you, there is no need to do > more. > > Andrew I tried to setup an nfs server with a rootfs on my local network. I can mount it okay from my laptop so I think it is working okay. However, it does not seem to work on the lpi4a [3]. It appears the rgmii-id validation fails and the dwmac driver can not open the phy: thead-dwmac ffe7060000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 thead-dwmac ffe7060000.ethernet eth0: validation of rgmii-id with support \ 00,00000000,00000000,00006280 and advertisementa \ 00,00000000,00000000,00006280 failed: -EINVAL thead-dwmac ffe7060000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -22) I suppose that this is what you were talking about that NFS will cause the interface to be opened much faster. Thanks, Drew [1] https://dl.sipeed.com/shareURL/LICHEE/licheepi4a/02_Schematic [2] https://github.com/revyos/thead-kernel/blob/lpi4a/arch/riscv/boot/dts/thead/th1520-b-product.dts#L758 [3] https://gist.github.com/pdp7/458eb93509548383beabeb21c8ffc43a
Drew Fustini wrote: > On Thu, Sep 26, 2024 at 09:30:32PM +0200, Andrew Lunn wrote: > > On Thu, Sep 26, 2024 at 12:13:06PM -0700, Drew Fustini wrote: > > > On Thu, Sep 26, 2024 at 08:39:29PM +0200, Andrew Lunn wrote: > > > > > +&mdio0 { > > > > > + phy0: ethernet-phy@1 { > > > > > + reg = <1>; > > > > > + }; > > > > > + > > > > > + phy1: ethernet-phy@2 { > > > > > + reg = <2>; > > > > > + }; > > > > > +}; > > > > > > > > Two PHYs on one bus... > > > > > > Thanks for pointing this out. I will move phy1 to mdio1. > > > > ??? > > > > Are you saying the two PHYs are not on the same bus? > > Sorry, this is my first time working on an Ethernet driver and I > misunderstood. > > Sipeed only shares the schematic of the baseboard for the LPi4a [1]. > There are pages for GMAC Ethernet0 and GMAC Ethernet1. Each shows 4 MDIO > differential pairs going into a SG4301G transformer. > > I believe that RTL8211F-CG phy chips are on the LM4A SoM board which > contains the TH1520 SoC. Unfortunately, Sipeed does not provide a > schematic of the SoM so its hard for me to inspect how the phy chips are > wired up. > > Vendor kernel [2] that Sipeed uses has: > > mdio0 { > #address-cells = <1>; > #size-cells = <0>; > compatible = "snps,dwmac-mdio"; > > phy_88E1111_0: ethernet-phy@0 { > reg = <0x1>; > }; > > phy_88E1111_1: ethernet-phy@1 { > reg = <0x2>; > }; > }; > > so I think that does mean they are on the same MDIO bus. It depends how you look at it. The SoC has two MACs and they can both control their own MDIO bus. However MDIO of both MACs are pinmux'ed to the same pins on the SoC. So the solution above just mux the pins to GMAC0 and let that control both PHYs. Alternatively I guess one could let each GMAC control their own phy on their own MDIO bus and then switch pinmux settings everytime you need to need to talk to one or the other. /Emil
> > Vendor kernel [2] that Sipeed uses has: > > > > mdio0 { > > #address-cells = <1>; > > #size-cells = <0>; > > compatible = "snps,dwmac-mdio"; > > > > phy_88E1111_0: ethernet-phy@0 { > > reg = <0x1>; > > }; > > > > phy_88E1111_1: ethernet-phy@1 { > > reg = <0x2>; > > }; > > }; > > > > so I think that does mean they are on the same MDIO bus. > > It depends how you look at it. The SoC has two MACs and they can both > control their own MDIO bus. However MDIO of both MACs are pinmux'ed to > the same pins on the SoC. Ah. That is unusual. > So the solution above just mux the pins to GMAC0 and let that > control both PHYs. That makes sense. Using both MDIO bus controllers and playing with the pinmux on each transaction would be a lot more complex. Andrew
> I tried to setup an nfs server with a rootfs on my local network. I can > mount it okay from my laptop so I think it is working okay. However, it > does not seem to work on the lpi4a [3]. It appears the rgmii-id > validation fails and the dwmac driver can not open the phy: > > thead-dwmac ffe7060000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 > thead-dwmac ffe7060000.ethernet eth0: validation of rgmii-id with support \ > 00,00000000,00000000,00006280 and advertisementa \ > 00,00000000,00000000,00006280 failed: -EINVAL > thead-dwmac ffe7060000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -22) Given what Emil said, i would suggest flipping the MDIO busses around. Put the PHYs on gmac1's MDIO bus, and set the pinmux so that its MDIO bus controller is connected to the outside world. Then, when gmac1 probes first, its MDIO bus will be probed at the same time, and its PHY found. Andrew
Drew Fustini wrote: > From: Emil Renner Berthing <emil.renner.berthing@canonical.com> > > Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> > [drew: change apb registers from syscon to second reg of gmac node] > [drew: add phy reset delay properties for beaglev ahead] > Signed-off-by: Drew Fustini <dfustini@tenstorrent.com> > --- > arch/riscv/boot/dts/thead/th1520-beaglev-ahead.dts | 91 ++++++++++++++ > .../boot/dts/thead/th1520-lichee-module-4a.dtsi | 135 +++++++++++++++++++++ > arch/riscv/boot/dts/thead/th1520.dtsi | 50 ++++++++ > 3 files changed, 276 insertions(+) ... > diff --git a/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi b/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi > index ca84bc2039ef..d9d2e1f4dc68 100644 > --- a/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi > +++ b/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi > @@ -11,6 +11,11 @@ / { > model = "Sipeed Lichee Module 4A"; > compatible = "sipeed,lichee-module-4a", "thead,th1520"; > > + aliases { > + ethernet0 = &gmac0; > + ethernet1 = &gmac1; > + }; > + > memory@0 { > device_type = "memory"; > reg = <0x0 0x00000000 0x2 0x00000000>; > @@ -25,6 +30,16 @@ &osc_32k { > clock-frequency = <32768>; > }; > > +&dmac0 { > + status = "okay"; > +}; > + > +&aogpio { > + gpio-line-names = "", "", "", > + "GPIO00", > + "GPIO04"; > +}; > + These GPIO line names does not belong in this patch. They should already be included in your other patchset adding the names for the other lines. /Emil
On Fri, Sep 27, 2024 at 05:55:04AM -0700, Emil Renner Berthing wrote: > Drew Fustini wrote: > > From: Emil Renner Berthing <emil.renner.berthing@canonical.com> > > > > Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> > > [drew: change apb registers from syscon to second reg of gmac node] > > [drew: add phy reset delay properties for beaglev ahead] > > Signed-off-by: Drew Fustini <dfustini@tenstorrent.com> > > --- > > arch/riscv/boot/dts/thead/th1520-beaglev-ahead.dts | 91 ++++++++++++++ > > .../boot/dts/thead/th1520-lichee-module-4a.dtsi | 135 +++++++++++++++++++++ > > arch/riscv/boot/dts/thead/th1520.dtsi | 50 ++++++++ > > 3 files changed, 276 insertions(+) > > ... > > > diff --git a/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi b/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi > > index ca84bc2039ef..d9d2e1f4dc68 100644 > > --- a/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi > > +++ b/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi > > @@ -11,6 +11,11 @@ / { > > model = "Sipeed Lichee Module 4A"; > > compatible = "sipeed,lichee-module-4a", "thead,th1520"; > > > > + aliases { > > + ethernet0 = &gmac0; > > + ethernet1 = &gmac1; > > + }; > > + > > memory@0 { > > device_type = "memory"; > > reg = <0x0 0x00000000 0x2 0x00000000>; > > @@ -25,6 +30,16 @@ &osc_32k { > > clock-frequency = <32768>; > > }; > > > > +&dmac0 { > > + status = "okay"; > > +}; > > + > > +&aogpio { > > + gpio-line-names = "", "", "", > > + "GPIO00", > > + "GPIO04"; > > +}; > > + > > These GPIO line names does not belong in this patch. They should > already be included in your other patchset adding the names for the > other lines. > > /Emil Thanks, yeah, those sneaked in here. Drew
On Fri, Sep 27, 2024 at 01:58:40PM +0200, Andrew Lunn wrote: > > I tried to setup an nfs server with a rootfs on my local network. I can > > mount it okay from my laptop so I think it is working okay. However, it > > does not seem to work on the lpi4a [3]. It appears the rgmii-id > > validation fails and the dwmac driver can not open the phy: > > > > thead-dwmac ffe7060000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 > > thead-dwmac ffe7060000.ethernet eth0: validation of rgmii-id with support \ > > 00,00000000,00000000,00006280 and advertisementa \ > > 00,00000000,00000000,00006280 failed: -EINVAL > > thead-dwmac ffe7060000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -22) > > Given what Emil said, i would suggest flipping the MDIO busses > around. Put the PHYs on gmac1's MDIO bus, and set the pinmux so that > its MDIO bus controller is connected to the outside world. Then, when > gmac1 probes first, its MDIO bus will be probed at the same time, and > its PHY found. > > Andrew I'm trying to configure the pinmux to have gmac1 control the mdio bus but it seems I've not done so correctly. I changed pins "GMAC0_MDC" and "GMAC0_MDIO" to function "gmac1" (see the patch below). I don't see any errors about the dwmac or phy in the boot log [1] but ultimately there is no carrier detected and the ethernet interface does not come up. Section "3.3.4.103 G3_MUXCFG_007" in the TH1520 System User Manual shows that bits [19:16] control GMAC0_MDIO_MUX_CFG where value of 2 selects GMAC1_MDIO. Similarly, bits [15:12] control GMAC0_MDC_MUX_CFG where a value of 2 also selects GMAC1_MDC. Emil - do you have any suggestion as to what I might be doing wrong with the pinmux? Thanks, Drew [1] https://gist.github.com/pdp7/1f9fcd76f26acd5715398d54f65a2e27 diff --git a/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi b/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi index ca84bc2039ef..f2f6c9d9b590 100644 --- a/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi +++ b/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi @@ -11,6 +11,11 @@ / { model = "Sipeed Lichee Module 4A"; compatible = "sipeed,lichee-module-4a", "thead,th1520"; + aliases { + ethernet0 = &gmac0; + ethernet1 = &gmac1; + }; + memory@0 { device_type = "memory"; reg = <0x0 0x00000000 0x2 0x00000000>; @@ -55,6 +60,22 @@ &sdio0 { status = "okay"; }; +&gmac0 { + pinctrl-names = "default"; + pinctrl-0 = <&gmac0_pins>; + phy-handle = <&phy0>; + phy-mode = "rgmii-id"; + status = "okay"; +}; + +&gmac1 { + pinctrl-names = "default"; + pinctrl-0 = <&gmac1_pins>, <&mdio1_pins>; + phy-handle = <&phy1>; + phy-mode = "rgmii-id"; + status = "okay"; +}; + &gpio0 { gpio-line-names = "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", @@ -87,3 +108,101 @@ &gpio3 { "GPIO09", "GPIO10"; }; + +&mdio1 { + phy0: ethernet-phy@1 { + reg = <1>; + }; + + phy1: ethernet-phy@2 { + reg = <2>; + }; +}; + +&padctrl0_apsys { + gmac0_pins: gmac0-0 { + tx-pins { + pins = "GMAC0_TX_CLK", + "GMAC0_TXEN", + "GMAC0_TXD0", + "GMAC0_TXD1", + "GMAC0_TXD2", + "GMAC0_TXD3"; + function = "gmac0"; + bias-disable; + drive-strength = <25>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + + rx-pins { + pins = "GMAC0_RX_CLK", + "GMAC0_RXDV", + "GMAC0_RXD0", + "GMAC0_RXD1", + "GMAC0_RXD2", + "GMAC0_RXD3"; + function = "gmac0"; + bias-disable; + drive-strength = <1>; + input-enable; + input-schmitt-disable; + slew-rate = <0>; + }; + }; + + gmac1_pins: gmac1-0 { + tx-pins { + pins = "GPIO2_18", /* GMAC1_TX_CLK */ + "GPIO2_20", /* GMAC1_TXEN */ + "GPIO2_21", /* GMAC1_TXD0 */ + "GPIO2_22", /* GMAC1_TXD1 */ + "GPIO2_23", /* GMAC1_TXD2 */ + "GPIO2_24"; /* GMAC1_TXD3 */ + function = "gmac1"; + bias-disable; + drive-strength = <25>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + + rx-pins { + pins = "GPIO2_19", /* GMAC1_RX_CLK */ + "GPIO2_25", /* GMAC1_RXDV */ + "GPIO2_30", /* GMAC1_RXD0 */ + "GPIO2_31", /* GMAC1_RXD1 */ + "GPIO3_0", /* GMAC1_RXD2 */ + "GPIO3_1"; /* GMAC1_RXD3 */ + function = "gmac1"; + bias-disable; + drive-strength = <1>; + input-enable; + input-schmitt-disable; + slew-rate = <0>; + }; + }; + + mdio1_pins: mdio1-0 { + mdc-pins { + pins = "GMAC0_MDC"; + function = "gmac1"; + bias-disable; + drive-strength = <13>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + + mdio-pins { + pins = "GMAC0_MDIO"; + function = "gmac1"; + bias-disable; + drive-strength = <13>; + input-enable; + input-schmitt-enable; + slew-rate = <0>; + }; + }; +};
On Sat, Sep 28, 2024 at 02:05:13PM -0700, Drew Fustini wrote: > On Fri, Sep 27, 2024 at 01:58:40PM +0200, Andrew Lunn wrote: > > > I tried to setup an nfs server with a rootfs on my local network. I can > > > mount it okay from my laptop so I think it is working okay. However, it > > > does not seem to work on the lpi4a [3]. It appears the rgmii-id > > > validation fails and the dwmac driver can not open the phy: > > > > > > thead-dwmac ffe7060000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 > > > thead-dwmac ffe7060000.ethernet eth0: validation of rgmii-id with support \ > > > 00,00000000,00000000,00006280 and advertisementa \ > > > 00,00000000,00000000,00006280 failed: -EINVAL > > > thead-dwmac ffe7060000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -22) > > > > Given what Emil said, i would suggest flipping the MDIO busses > > around. Put the PHYs on gmac1's MDIO bus, and set the pinmux so that > > its MDIO bus controller is connected to the outside world. Then, when > > gmac1 probes first, its MDIO bus will be probed at the same time, and > > its PHY found. > > > > Andrew > > I'm trying to configure the pinmux to have gmac1 control the mdio bus > but it seems I've not done so correctly. I changed pins "GMAC0_MDC" and > "GMAC0_MDIO" to function "gmac1" (see the patch below). > > I don't see any errors about the dwmac or phy in the boot log [1] but > ultimately there is no carrier detected and the ethernet interface does > not come up. > > Section "3.3.4.103 G3_MUXCFG_007" in the TH1520 System User Manual shows > that bits [19:16] control GMAC0_MDIO_MUX_CFG where value of 2 selects > GMAC1_MDIO. Similarly, bits [15:12] control GMAC0_MDC_MUX_CFG where a > value of 2 also selects GMAC1_MDC. > > Emil - do you have any suggestion as to what I might be doing wrong with > the pinmux? I've been thinking about this and I don't think there is any problem on the LPi4a. Both Ethernet jacks work when I have the mdio bus muxed for gmac0 to control it. It seems to control both phy's okay. Earlier, I tried to setup nfs root but it didn't work. I believe this is just due to my ignorance of how to configure it correctly. I've instead switched to just adding 'ip=dhcp' to the kernel command. This causes stmmac_open() to happen shortly after the thead-dwmac is probed for both gmac0 and gmac1. The phy is found for both and there are no errors. Without 'ip=dhcp', stmmac_open() is not called until around 40 seconds into boot when NetworkManager tries to open it. Everything works correctly but the delay of over 30 seconds from thead-dwmac probe to interface up looks odd in the logs, but I am pretty sure this is just due the point in time at which NetworkManager decides to bring up the network interfaces. Booting with gmac0 connected to Ethernet cable: https://gist.github.com/pdp7/e1a8e7666706c7d3c99b6b7a3b43f070 Booting with gmac1 connected to Ethernet cable: https://gist.github.com/pdp7/8a9c2066a2c20377ec3b479213b9be4c thead-dwmac probe for gmac happens around 6 seconds. stmmac_open() occurs shortly after that. The interface is up by around 10 seconds into boot. DHCP request works okay and the interface is up and working once the shell is ready. In short, I believe the dts configuration in patch 3/3 of this series works okay for both Ethernet ports on the LPi4a. Thanks, Drew
diff --git a/arch/riscv/boot/dts/thead/th1520-beaglev-ahead.dts b/arch/riscv/boot/dts/thead/th1520-beaglev-ahead.dts index 5a5888f4eda6..ddcee6298939 100644 --- a/arch/riscv/boot/dts/thead/th1520-beaglev-ahead.dts +++ b/arch/riscv/boot/dts/thead/th1520-beaglev-ahead.dts @@ -15,6 +15,7 @@ / { compatible = "beagle,beaglev-ahead", "thead,th1520"; aliases { + ethernet0 = &gmac0; gpio0 = &gpio0; gpio1 = &gpio1; gpio2 = &gpio2; @@ -108,6 +109,25 @@ &sdio0 { status = "okay"; }; +&gmac0 { + pinctrl-names = "default"; + pinctrl-0 = <&gmac0_pins>; + phy-handle = <&phy0>; + phy-mode = "rgmii-id"; + status = "okay"; +}; + +&mdio0 { + phy0: ethernet-phy@1 { + reg = <1>; + interrupt-parent = <&gpio3>; + interrupts = <22 IRQ_TYPE_LEVEL_LOW>; + reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>; + reset-delay-us = <10000>; + reset-post-delay-us = <50000>; + }; +}; + &padctrl_aosys { led_pins: led-0 { led-pins { @@ -127,6 +147,77 @@ led-pins { }; &padctrl0_apsys { + gmac0_pins: gmac0-0 { + tx-pins { + pins = "GMAC0_TX_CLK", + "GMAC0_TXEN", + "GMAC0_TXD0", + "GMAC0_TXD1", + "GMAC0_TXD2", + "GMAC0_TXD3"; + function = "gmac0"; + bias-disable; + drive-strength = <25>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + + rx-pins { + pins = "GMAC0_RX_CLK", + "GMAC0_RXDV", + "GMAC0_RXD0", + "GMAC0_RXD1", + "GMAC0_RXD2", + "GMAC0_RXD3"; + function = "gmac0"; + bias-disable; + drive-strength = <1>; + input-enable; + input-schmitt-disable; + slew-rate = <0>; + }; + + mdc-pins { + pins = "GMAC0_MDC"; + function = "gmac0"; + bias-disable; + drive-strength = <13>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + + mdio-pins { + pins = "GMAC0_MDIO"; + function = "gmac0"; + bias-disable; + drive-strength = <13>; + input-enable; + input-schmitt-enable; + slew-rate = <0>; + }; + + phy-reset-pins { + pins = "GMAC0_COL"; /* GPIO3_21 */ + bias-disable; + drive-strength = <3>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + + phy-interrupt-pins { + pins = "GMAC0_CRS"; /* GPIO3_22 */ + function = "gpio"; + bias-pull-up; + drive-strength = <1>; + input-enable; + input-schmitt-enable; + slew-rate = <0>; + }; + }; + uart0_pins: uart0-0 { tx-pins { pins = "UART0_TXD"; diff --git a/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi b/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi index ca84bc2039ef..d9d2e1f4dc68 100644 --- a/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi +++ b/arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi @@ -11,6 +11,11 @@ / { model = "Sipeed Lichee Module 4A"; compatible = "sipeed,lichee-module-4a", "thead,th1520"; + aliases { + ethernet0 = &gmac0; + ethernet1 = &gmac1; + }; + memory@0 { device_type = "memory"; reg = <0x0 0x00000000 0x2 0x00000000>; @@ -25,6 +30,16 @@ &osc_32k { clock-frequency = <32768>; }; +&dmac0 { + status = "okay"; +}; + +&aogpio { + gpio-line-names = "", "", "", + "GPIO00", + "GPIO04"; +}; + &aonsys_clk { clock-frequency = <73728000>; }; @@ -55,6 +70,22 @@ &sdio0 { status = "okay"; }; +&gmac0 { + pinctrl-names = "default"; + pinctrl-0 = <&gmac0_pins>, <&mdio0_pins>; + phy-handle = <&phy0>; + phy-mode = "rgmii-id"; + status = "okay"; +}; + +&gmac1 { + pinctrl-names = "default"; + pinctrl-0 = <&gmac1_pins>; + phy-handle = <&phy1>; + phy-mode = "rgmii-id"; + status = "okay"; +}; + &gpio0 { gpio-line-names = "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", @@ -87,3 +118,107 @@ &gpio3 { "GPIO09", "GPIO10"; }; + +&mdio0 { + phy0: ethernet-phy@1 { + reg = <1>; + }; + + phy1: ethernet-phy@2 { + reg = <2>; + }; +}; + +&padctrl0_apsys { + gmac0_pins: gmac0-0 { + tx-pins { + pins = "GMAC0_TX_CLK", + "GMAC0_TXEN", + "GMAC0_TXD0", + "GMAC0_TXD1", + "GMAC0_TXD2", + "GMAC0_TXD3"; + function = "gmac0"; + bias-disable; + drive-strength = <25>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + + rx-pins { + pins = "GMAC0_RX_CLK", + "GMAC0_RXDV", + "GMAC0_RXD0", + "GMAC0_RXD1", + "GMAC0_RXD2", + "GMAC0_RXD3"; + function = "gmac0"; + bias-disable; + drive-strength = <1>; + input-enable; + input-schmitt-disable; + slew-rate = <0>; + }; + }; + + gmac1_pins: gmac1-0 { + tx-pins { + pins = "GPIO2_18", /* GMAC1_TX_CLK */ + "GPIO2_20", /* GMAC1_TXEN */ + "GPIO2_21", /* GMAC1_TXD0 */ + "GPIO2_22", /* GMAC1_TXD1 */ + "GPIO2_23", /* GMAC1_TXD2 */ + "GPIO2_24"; /* GMAC1_TXD3 */ + function = "gmac1"; + bias-disable; + drive-strength = <25>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + + rx-pins { + pins = "GPIO2_19", /* GMAC1_RX_CLK */ + "GPIO2_25", /* GMAC1_RXDV */ + "GPIO2_30", /* GMAC1_RXD0 */ + "GPIO2_31", /* GMAC1_RXD1 */ + "GPIO3_0", /* GMAC1_RXD2 */ + "GPIO3_1"; /* GMAC1_RXD3 */ + function = "gmac1"; + bias-disable; + drive-strength = <1>; + input-enable; + input-schmitt-disable; + slew-rate = <0>; + }; + }; + + mdio0_pins: mdio0-0 { + mdc-pins { + pins = "GMAC0_MDC"; + function = "gmac0"; + bias-disable; + drive-strength = <13>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + + mdio-pins { + pins = "GMAC0_MDIO"; + function = "gmac0"; + bias-disable; + drive-strength = <13>; + input-enable; + input-schmitt-enable; + slew-rate = <0>; + }; + }; +}; + +&sdio0 { + bus-width = <4>; + max-frequency = <198000000>; + status = "okay"; +}; diff --git a/arch/riscv/boot/dts/thead/th1520.dtsi b/arch/riscv/boot/dts/thead/th1520.dtsi index 517a9e2e93a3..f51cc0c465ee 100644 --- a/arch/riscv/boot/dts/thead/th1520.dtsi +++ b/arch/riscv/boot/dts/thead/th1520.dtsi @@ -222,6 +222,12 @@ aonsys_clk: aonsys-clk { #clock-cells = <0>; }; + stmmac_axi_config: stmmac-axi-config { + snps,wr_osr_lmt = <15>; + snps,rd_osr_lmt = <15>; + snps,blen = <0 0 64 32 0 0 0>; + }; + soc { compatible = "simple-bus"; interrupt-parent = <&plic>; @@ -273,6 +279,50 @@ uart0: serial@ffe7014000 { status = "disabled"; }; + gmac1: ethernet@ffe7060000 { + compatible = "thead,th1520-gmac", "snps,dwmac-3.70a"; + reg = <0xff 0xe7060000 0x0 0x2000>, <0xff 0xec004000 0x0 0x1000>; + reg-names = "dwmac", "apb"; + interrupts = <67 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq"; + clocks = <&clk CLK_GMAC_AXI>, <&clk CLK_GMAC_AXI>; + clock-names = "stmmaceth", "pclk"; + snps,pbl = <32>; + snps,fixed-burst; + snps,multicast-filter-bins = <64>; + snps,perfect-filter-entries = <32>; + snps,axi-config = <&stmmac_axi_config>; + status = "disabled"; + + mdio1: mdio { + compatible = "snps,dwmac-mdio"; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + gmac0: ethernet@ffe7070000 { + compatible = "thead,th1520-gmac", "snps,dwmac-3.70a"; + reg = <0xff 0xe7070000 0x0 0x2000>, <0xff 0xec003000 0x0 0x1000>; + reg-names = "dwmac", "apb"; + interrupts = <66 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq"; + clocks = <&clk CLK_GMAC_AXI>, <&clk CLK_GMAC_AXI>; + clock-names = "stmmaceth", "pclk"; + snps,pbl = <32>; + snps,fixed-burst; + snps,multicast-filter-bins = <64>; + snps,perfect-filter-entries = <32>; + snps,axi-config = <&stmmac_axi_config>; + status = "disabled"; + + mdio0: mdio { + compatible = "snps,dwmac-mdio"; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + emmc: mmc@ffe7080000 { compatible = "thead,th1520-dwcmshc"; reg = <0xff 0xe7080000 0x0 0x10000>;