Re: [PATCH v4 0/2] ARM: dts: aspeed: Add ASRock Rack B650D4U BMC

[Prasanth]

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