Re: 回覆: NVL32 BMC enablement — offering help on ftgmac100 work

[Andrew Lunn <andrew@lunn.ch>]

On Wed, Apr 29, 2026 at 02:08:51AM +0000, Jacky Chou wrote:
> Hi Ender,
> 
> We stopped to submit the RGMII delay configuration in ftgmac100 driver, please
> adjust the correct RGMII delay and configure in bootloader.
> 
> Currently, we suggest the PHY side to enable TX and RX internal delay, which
> means the phy-mode is set to 'rgmii-id' to tell the PHY driver to enable both
> delay to its PHY device.

Please don't top post. It makes it harder to make the emails
understandable.

> Thanks for the update on the AST2700 ftgmac100 plans.
> 
> A bit of context from our side: we're working on the OpenBMC upstream
> effort for nvl32 (the AST2600-based msx4 platform Marc Olberding
> upstreamed in commit f28674fab34f). To get host networking working on
> our test platform we currently carry a local kernel patch in the
> OpenBMC layer that re-adds the mac0/mdio3/ethphy3 nodes, but holding
> it there long-term goes against upstream-first principles and the
> Gerrit reviewer has flagged it.
> 
> Given AST2600 ftgmac100 work is sequenced after the AST2700 series,
> do you have any suggestions on how we could resolve this using
> upstream resources — e.g. an interim path that's acceptable to the
> community while we wait for the proper driver fix? Any pointer on
> the right shape (RFC PATCH, openbmc/linux backport, something else)
> would help us a lot.

Hi Ender

The problem about getting stuff upstream is phy-mode. If you don't
have the PCB adding the delays, you need to use phy-mode='rmgii-id'.
Which is the typical design.

The root cause of the problem is actually the bootloader. It enables
the delays in the MAC. The Linux MAC driver leaves them untouched, but
it also passed the phy-mode direct to the PHY, not taking into account
that the MAC has added delays.

The quick and easy fix for getting patches merged into Mainline Linux
is to patch the bootloader. Stop it enabling delays in the MAC. You
can then use the correct phy-mode. If you go this way, place make it
clear in the commit message you have modified the bootloader.

The more complex way to solve this is to make the Linux MAC driver
look at how the bootloader has configured the delays, compare it
against phy-mode, and decide what to do. I've not thought through all
the combinations but something like:

* If the bootloader MAC configuration is not adding delays, do
  nothing. (This covers what i just suggested)

* If the bootloader MAC configuration is adding delays, and phy-mode
  == 'rmgii', turn off the delays and pass phy-mode=rgmii-id to the PHY
  (This covers any DT blobs which got passed me and merged)
  
* If the bootloader MAC configuration is adding delays, and phy-mode
  == 'rmgii-id', turn off the delays and pass phy-mode=rgmii-id to the
  PHY (This covers how it should be)

What makes it more complex is that delays are not simple on/off, but a
range of values. If the PCB is badly designed you sometimes need small
delays to compensate. So rather than having a delay of 2ns, it might
be 2.1ns. Or it might be 0.1ns. If it is 2.1ns, when you turn it off,
you need to set the MAC to actually add 0.1ns delay. And you need to
consider 0.1ns as not adding delays, and keep the 0.1ns. And if the
delay is actually 1.8ns, it gets even more interesting, because i
doubt the hardware can add a delay of -0.2ns, so you should actually
leave the MAC delay alone, and pass phy-mode = rgmii to the PHY so it
does not add delays as well.

If you decide you want to make changes to the MAC driver, do it, post
patches, and they will get reviewed. And given the number of dts files
i've stopped getting merged, it should not be hard to find others to
do testing for you, and you might end up with a crate of beer/box of
wine from other openBMC users.

     Andrew