| Message ID | 20260830182036.284736-1-prasanth.padarthi10@gmail.com |
|---|---|
| Headers | show |
| Series | ARM: dts: aspeed: Add ASRock Rack B650D4U BMC | expand |
Hi Andrew, I do not currently have the PCB layout or trace-length information, so I cannot prove that the board provides the TX delay externally. What I have validated on hardware is: rgmii: fails, with RX CRC errors and no valid RX traffic rgmii-rxid: passes, 5000/5000 packets, 0% loss, no RX CRC errors rgmii-id: also passes with the same traffic test This shows that the RTL8211F RX internal delay is required, but it does not establish where the TX delay is provided. Given that I cannot provide PCB-level evidence for the TX delay, would you prefer that I use rgmii-id for the next revision? Thanks, Prasanth On Mon, 31 Aug, 2026, 1:53 am Andrew Lunn, <andrew@lunn.ch> wrote: > On Sun, Aug 30, 2026 at 11:50:34PM +0530, Prasanth Kumar Padarthi wrote: > > Add device tree support for the ASRock Rack B650D4U BMC, which is > > based on the ASPEED AST2600 SoC. > > > > The series adds the board compatible and describes the BMC memory, > > SPI NOR flash layout, UART console, and MAC0 connected to an > > RTL8211F Ethernet PHY. > > > > The MAC0 RGMII timing configuration was validated on B650D4U > > hardware. With plain "rgmii", the PHY negotiated 1000baseT/Full but > > received no valid packets and accumulated RX CRC errors. With > > "rgmii-rxid", a 5000-packet test completed with 0% packet loss and > > no RX CRC errors. "rgmii-id" was also tested successfully, but the > > additional TX delay is not required, so "rgmii-rxid" is retained. > > Please take a read of: > > > https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287 > > Does the PCB have 2ns of delay for TX, but notR RX? > > Andrew >
Hi Andrew, I do not currently have the PCB layout or RGMII trace-length information, so I cannot confirm that the PCB provides approximately 2 ns of TX delay but no RX delay. My hardware results are: rgmii negotiates 1000baseT/Full, but RX traffic fails with CRC errors. rgmii-rxid passes a 5000-packet test with no loss or RX CRC errors. rgmii-id also passes the same test. These results indicate that an RX delay is required, but they do not establish whether the TX delay is provided by the PCB, MAC, or PHY. I therefore agree that the traffic test alone is insufficient to justify rgmii-rxid. I have contacted ASRock Rack requesting confirmation of the RGMII timing and PCB trace-delay configuration. I will wait for that information before selecting the phy-mode for the next revision or making a claim about where the TX delay is implemented. Thanks, Prasanth On Mon, Aug 31, 2026 at 1:53 AM Andrew Lunn <andrew@lunn.ch> wrote: > > On Sun, Aug 30, 2026 at 11:50:34PM +0530, Prasanth Kumar Padarthi wrote: > > Add device tree support for the ASRock Rack B650D4U BMC, which is > > based on the ASPEED AST2600 SoC. > > > > The series adds the board compatible and describes the BMC memory, > > SPI NOR flash layout, UART console, and MAC0 connected to an > > RTL8211F Ethernet PHY. > > > > The MAC0 RGMII timing configuration was validated on B650D4U > > hardware. With plain "rgmii", the PHY negotiated 1000baseT/Full but > > received no valid packets and accumulated RX CRC errors. With > > "rgmii-rxid", a 5000-packet test completed with 0% packet loss and > > no RX CRC errors. "rgmii-id" was also tested successfully, but the > > additional TX delay is not required, so "rgmii-rxid" is retained. > > Please take a read of: > > https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287 > > Does the PCB have 2ns of delay for TX, but notR RX? > > Andrew
On Mon, Aug 31, 2026 at 06:43:46AM +0530, Prasanth wrote: > Hi Andrew, > > I do not currently have the PCB layout or trace-length information, so I cannot > prove that the board provides the TX delay externally. > > What I have validated on hardware is: > > rgmii: fails, with RX CRC errors and no valid RX traffic > rgmii-rxid: passes, 5000/5000 packets, 0% loss, no RX CRC errors > rgmii-id: also passes with the same traffic test > > This shows that the RTL8211F RX internal delay is required, but it does not > establish where the TX delay is provided. > > Given that I cannot provide PCB-level evidence for the TX delay, would you > prefer that I use rgmii-id for the next revision? There has been a number of threads about the Aspeed SoC. It typically has delays enabled in its MAC, by the bootloader. The Linux MAC driver does not disable this, nor does it mask the value passed to the PHY. So you see many Aspeed .dts files incorrectly using 'rgmii'. Over the last couple of years i have been pointing out this problem, but nobody has stepped up to fix the issue. Most DT developers just leave the Ethernet node out, in order to get something merged. You case is interesting, because you are not suggesting 'rgmii'. So it could be there is more going on. If you look in the email archives you should find the information about where to configure the delay in the hardware. You might want to read it out to understand how the bootloader has configured the hardware. Andrew
Hi Andrew, Thanks. As I mentioned earlier, I had already found that the AST2600 has MAC-side RGMII delay configuration. I will now check the actual delay register values on this board after U-Boot has initialized the MAC, and compare them with the corresponding U-Boot configuration. That should help determine how much of the observed behavior is coming from the MAC-side delays left configured by the bootloader. Tan Siewert has also confirmed that the RGMII traces on the B650D4U do not provide the delay, and pointed out the difference between the SoC-specific delay handling in upstream U-Boot and openbmc/u-boot. I will investigate that before preparing the next revision and will remove the RX-only delay claim from the current patch. Thanks, Prasanth On Mon, Aug 31, 2026 at 5:42 PM Andrew Lunn <andrew@lunn.ch> wrote: > > On Mon, Aug 31, 2026 at 06:43:46AM +0530, Prasanth wrote: > > Hi Andrew, > > > > I do not currently have the PCB layout or trace-length information, so I cannot > > prove that the board provides the TX delay externally. > > > > What I have validated on hardware is: > > > > rgmii: fails, with RX CRC errors and no valid RX traffic > > rgmii-rxid: passes, 5000/5000 packets, 0% loss, no RX CRC errors > > rgmii-id: also passes with the same traffic test > > > > This shows that the RTL8211F RX internal delay is required, but it does not > > establish where the TX delay is provided. > > > > Given that I cannot provide PCB-level evidence for the TX delay, would you > > prefer that I use rgmii-id for the next revision? > > There has been a number of threads about the Aspeed SoC. It typically > has delays enabled in its MAC, by the bootloader. The Linux MAC driver > does not disable this, nor does it mask the value passed to the > PHY. So you see many Aspeed .dts files incorrectly using 'rgmii'. Over > the last couple of years i have been pointing out this problem, but > nobody has stepped up to fix the issue. Most DT developers just leave > the Ethernet node out, in order to get something merged. > > You case is interesting, because you are not suggesting 'rgmii'. So it > could be there is more going on. > > If you look in the email archives you should find the information > about where to configure the delay in the hardware. You might want to > read it out to understand how the bootloader has configured the > hardware. > > Andrew