NVL32 BMC enablement — offering help on ftgmac100 work

NVL32 BMC enablement — offering help on ftgmac100 work

[Ender Hsieh]

Hi Jacky, hi linux-aspeed,

I'm Ender Hsieh from NVIDIA, working on enabling the NVL32 BMC
platform (AST2600, msx4 design — the one Marc Olberding added in
commit f28674fab34f) on upstream OpenBMC.

I've been tracking the ftgmac100 cleanup work going on recently
(the 2025-07 .. 2026-02 batch around DT probe, MDIO setup, match
data refactoring) — looks like solid groundwork.

Could you share a summary of where the Aspeed networking stack
work is at right now? Happy to coordinate on-list or off-list,
whichever works for you.

Thanks,
Ender Hsieh
andhsieh@nvidia.com

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

[Jacky Chou]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

Hi Ender,

Next, we are planning to submit a series of patches to add AST2700 support to the ftgmac100 driver.
At the moment, we are focusing on upstreaming the AST2700 platform. Once the platform support is in place, we will proceed with upstreaming the corresponding network driver.

Thanks,
Jacky

************* Email Confidentiality Notice ********************
免責聲明:
本信件(或其附件)可能包含機密資訊，並受法律保護。如 台端非指定之收件者，請以電子郵件通知本電子郵件之發送者, 並請立即刪除本電子郵件及其附件和銷毀所有複印件。謝謝您的合作!

DISCLAIMER:
This message (and any attachments) may contain legally privileged and/or other confidential information. If you have received it in error, please notify the sender by reply e-mail and immediately delete the e-mail and any attachments without copying or disclosing the contents. Thank you.

________________________________
寄件者: Ender Hsieh <andhsieh@nvidia.com>
寄件日期: 2026年4月28日 上午 11:30
收件者: linux-aspeed@lists.ozlabs.org <linux-aspeed@lists.ozlabs.org>
副本: Jacky Chou <jacky_chou@aspeedtech.com>; Marc Olberding <molberding@nvidia.com>; Andrew Lunn <andrew@lunn.ch>
主旨: NVL32 BMC enablement — offering help on ftgmac100 work

Hi Jacky, hi linux-aspeed,

I'm Ender Hsieh from NVIDIA, working on enabling the NVL32 BMC
platform (AST2600, msx4 design — the one Marc Olberding added in
commit f28674fab34f) on upstream OpenBMC.

I've been tracking the ftgmac100 cleanup work going on recently
(the 2025-07 .. 2026-02 batch around DT probe, MDIO setup, match
data refactoring) — looks like solid groundwork.

Could you share a summary of where the Aspeed networking stack
work is at right now? Happy to coordinate on-list or off-list,
whichever works for you.

Thanks,
Ender Hsieh
andhsieh@nvidia.com

[-- Attachment #2: Type: text/html, Size: 4550 bytes --]

Re: NVL32 BMC enablement — offering help on ftgmac100 work

[Ender Hsieh]

Hi Jacky,

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.

Thanks,
Ender

回覆: NVL32 BMC enablement ― offering help on ftgmac100 work

[Jacky Chou]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 2174 bytes --]

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.


Thanks,
Jacky

************* Email Confidentiality Notice ********************
Ãâ؟•Ã÷:
±¾Ðżþ(»òÆ丽¼þ)¿ÉÄÜ°üº¬™CÃÜÙYӍ£¬KÊÜ·¨Âɱ£×o¡£Èç ̨¶Ë·ÇÖ¸¶¨Ö®ÊÕ¼þÕߣ¬ÕˆÒÔëŠ×Óà]¼þ֪ͨ±¾ëŠ×Óà]¼þÖ®°lËÍÕß, KÕˆÁ¢¼´„h³ý±¾ëŠ×Óà]¼þ¼°Æ丽¼þºÍäNš§ËùÓÐÑ}Ó¡¼þ¡£ÖxÖxÄúµÄºÏ×÷!

DISCLAIMER:
This message (and any attachments) may contain legally privileged and/or other confidential information. If you have received it in error, please notify the sender by reply e-mail and immediately delete the e-mail and any attachments without copying or disclosing the contents. Thank you.

________________________________
¼Ä¼þÕß: Ender Hsieh <andhsieh@nvidia.com>
¼Ä¼þÈÕÆÚ: 2026Äê4ÔÂ28ÈÕ ÏÂÎç 11:14
ÊÕ¼þÕß: Jacky Chou <jacky_chou@aspeedtech.com>
¸±±¾: Andrew Lunn <andrew@lunn.ch>; linux-aspeed@lists.ozlabs.org <linux-aspeed@lists.ozlabs.org>; Marc Olberding <molberding@nvidia.com>
Ö÷Ö¼: Re: NVL32 BMC enablement ¡ª offering help on ftgmac100 work

Hi Jacky,

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.

Thanks,
Ender

[-- Attachment #2: Type: text/html, Size: 5035 bytes --]

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

[Andrew Lunn]

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

Re: NVL32 BMC enablement — offering help on ftgmac100 work

[Ender Hsieh]

> 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.

Thanks Andrew — and thanks Jacky for the earlier steer too.

We're already on this path. I have a local branch with both U-Boot and
kernel dts switched to phy-mode = "rgmii-id", and the &scu
mac0-clk-delay block removed from the U-Boot dts.

We'll validate end-to-end on hardware first, then send the patches.
I'll make sure the commit messages on both the U-Boot and kernel sides
clearly note that the bootloader has been modified to stop enabling
the MAC delays, so reviewers see the relationship between the two.

> If you decide you want to make changes to the MAC driver, do it,
> post patches, and they will get reviewed.

Appreciated — but unfortunately tight timelines on our side mean I
can't take on the smarter MAC driver work right now. I'll keep it on
my radar as a follow-up if bandwidth allows.

Thanks again,
Ender