RK3576 适配联芸MAE0621A-Q3C 千兆以太网PHY-CSDN博客

RK给的公版原理图上1000M PHY是RTL8211F，作为一匹细心的牛马，我先把MAE0621A-Q3C的所有pin脚都拉出来和RTL8211F比对了一遍，结果完全一致，几个IO口的内部上下拉及功能定义都是一样的。这就意味着在同一硬件环境下，MAE0621A-Q3C和8211F上电配置是一致的，无需做调整。

电源部分

接着再看电源部分，RK原理图上PHY vddl 电压采用DCDC输出，搭配有电感电容，这部分和MAE0621A-Q3C给的原理图也是一致，可以直接使用。

和FAE确认，如果项目上原来使用的是RTL8211FD这类LDO输出vddl的PHY，就需修改外围增加电感电容，或者直接使用外部供电1.1v，MAE0621A-Q3C也是适用的。总结如下：

时钟部分

在PHY的时钟电路这块，RK原理图上给出了无源晶体提供和MAC提供25M时钟两种方案。

查阅MAE0621A-Q3C的datasheet和参考设计也是完全兼容的。需要注意的是，时钟源需要3.3v的电压域，这在RK3576上选择合适的VCCIO就好。

贴片试用

前面硬件检查过后，就八九不离十，基本判断为可以直接贴片测试了。

板子上电后，因为没有合入MAE0621A-Q3C的驱动，从dmesg打印看，识别为Generic PHY。

插上网线和PC对接，可以直接1G linkup，拔掉网线 down，看起来一切正常啊。

然后到网络节点下，访问phy的寄存器。目前PHY是挂在stmmac-0这条bus下的，可以用
cat phy_registers 读取当前page下的0~31号寄存器

echo <reg> <value> > phy_registers 可以对某个寄存器赋值。参照datesheet来尝试对PHY做个复位动作，看来也完全符合预期。

在PC上用dhcpsrv起了DHCP自动分配，RK3576也顺利拿到了IP，ping也没问题。这让我出乎意料，这几乎直接可以用了！

驱动合入

咱还是按要求合入驱动包，官方给的驱动版本是v1.8.1.2，包含了maxio.c和patch.diff两个文件。maxio.c 是驱动的主程序，看内容主要是做了寄存器的优化配置，patch文件记录了其他修改项。

以linux 6.1为例，按照常规步骤：

1. 拷贝 maxio.c 到目录 linux-6.1/drivers/net/phy/

2. 编辑linux-6.1/drivers/net/phy/Makefile, 增加：

obj-$(CONFIG_MAXIO_PHY) += maxio.o

3. 编辑linux-6.1/drivers/net/phy/Kconfig, 增加：
config MAXIO_PHY
    tristate "MAXIO PHYs"
    help
      Supports the Maxio MAExxxx PHY.

4. 编辑kernel/arch/arm64/configs/xxx_defconfig , 增加：

CONFIG_MAXIO_PHY=y

其他修改

patch文件中记录了对 /drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 文件的一处修改：

@@ -3232,6 +3236,20 @@ int stmmac_resume(struct device *dev)
    priv->cur_tx = 0;
    stmmac_clear_descriptors(priv);
+   if (ndev->phydev->drv->config_init) {
+       if (ndev->phydev->phy_id == MAXIO_PHY_MAE0621A_Q2C_ID || ndev->phydev->phy_id == MAXIO_PHY_MAE0621A_Q3C_ID) {
+           ndev->phydev->drv->config_init(ndev->phydev);
+       }
+   }
    stmmac_hw_setup(ndev, false);
    stmmac_set_rx_mode(ndev);

咨询了FAE，这里是因为RK所采用的stmmac需要在初始化的时候灌入RX CLK，否则会报"DMA engine initialization failed"，此处的操作就是把PHY先初始化起来提供RX CLK。如果是全志系列的sunxi mac，就不需要合入此修改了。

以上完成后，就可以编译kernel，直接烧录了！

功能验证

烧录完再次上电后，查看日志，已经可以识别为MAE0621A_Q3C了，并且正确加载了v1.8.1.2版本的驱动。

获取IP，Ping，网口开关，10M/100M/1000M协商，这些动作都没有问题，表现与8211F无异。

流量测试

RK RGMII Delayline

RGMII Delayline 是RK自动计算RGMII delay的工具，其基本原理是设置PHY的RGMII loopback，然后从MAC发包，环回收包后检查是否有错包和丢包。在此过程中，遍历MAC的txdly和rxdly设定，从所有结果中选取最优值。此工具可以保证用户网络达到最佳流量。

目前在RK3576的默认设备树中，RGMII模式设置为RGMII-ID，这意味着RX方向的延时由PHY来保证，MAC不做调整，TX方向则可以做调整。从节点读上来的设定也可以看到，TX当前设定为0x20，RX不做设定。

咱就在这个RK3576+MAE0621A-Q3C的环境上来跑一下自动计算工具，看看效果怎么样。可是不出意外的话意外发生了，奈何我怎么跑都无法得到合适的txdly值，但实际网络通信又没有问题。拿贴有RTL8211F的板子来跑，也是一样的结果。

继续找FAE咨询，虽然不是联芸PHY的问题，但FAE小哥还是很负责地做了一番研究，还联系了RK的支持。最后给出的方案是测试时需要将RK3576的内存在uboot下临时修改为2GB，方法如下：

--- a/arch/arm/mach-rockchip/param.c
+++ b/arch/arm/mach-rockchip/param.c
@@ -287,10 +287,12 @@ struct memblock *param_parse_ddr_mem(int *out_count)
            return 0;
        }
+       count = 1;
        for (i = 0, n = 0; i < count; i++, n++) {
            base = t->u.ddr_mem.bank[i];
            size = t->u.ddr_mem.bank[i + count];
+           size = SZ_2GB;
            /* 0~4GB */
            if (base < SZ_4GB) {
                mem[n].base = base;

修改后终于可以计算得到合适的txdly值，从输出的结果来看，打O的都是不丢包的txdly，范围很宽，0x1b是取了中间值，这样可以给不同的板卡留足裕量。