LX2162A USXGMII 链路始终无法建立连接。 大家好， 我有一个由Solidrun公司生产的LX2162A系统模块。我目前使用的是Clearfog开发套件，但很快会换成定制的载体。 Solidrun 提供基本的 RCW/DCP/DPL，我已经验证了其功能。就我而言，dpmac3 的 DPC 适用于 SFP 笼，我可以通过 SFP DAC 电缆和各种 SFP 模块获得 XFI 连接。 RCW“rcw_2000_650_2900_3_11_0_auto”设置为SerDes1=3，SerDes2=11，我使用的是QorIQ内核（lf-6.6.52-2.2.0）和mc-utils（10.39.0），但两者都应用了一些Solidrun补丁。Uboot和其他一些东西也被打上了补丁。所有补丁均来自此处： https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 我有一套 MaxLinear GPY245-EKV-1（和 -2）开发套件，需要通过 DAC 电缆使用 USXGMII 将 phy 连接到设备。这似乎很正常。最终，这款物理芯片将被集成到 SerDes2=7 的第 6 道和第 7 道中，但我必须使用 Clearfog 上的 SFP 插槽进行测试。 Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP 我只是想配置 dpmac3 通过 DPC 使用这个 USXGMII 链路： mac@3 {
link_type = "MAC_LINK_TYPE_PHY";
enet_if = "USXGMII";
}; （我也尝试过 MAC_LINK_TYPE_BACKPLANE） 已通过“restool dpmac info dpmac.3”确认显示“DPMAC 以太网接口：DPMAC_ETH_IF_USXGMII”。 在Linux系统中，我添加了MaxLinear驱动程序并修复了一些问题： gpy_update_interface() 修复（LKML，Daniel Golle）。这导致 USXGMII 接口返回 -EINVAL，使 phy_state_machine 崩溃。 已修复 pcs-lynx.c 中的 lynx_pcs_config_usxgmii() 函数。同时通过 mdiobus_c45_modify() 写入 MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART)，因为该函数只写入了 MII_ADVERTISE，而从未在复制器块本身上启用 AN。这一问题与本论坛上的另一篇帖子（“LS1028A 10g-qxgmii phy 启动”）相吻合，该帖子也发现了相同的症状（MMD31.0/复制器）。控制寄存器卡在 0)，手动设置第 12 位后，AN 开始工作。 这是 DPMAC3 Linux 设备树条目： &dpmac3 {
managed = "in-band-status";
phy-mode = "usxgmii";
phy-handle = <&gpy245_p0>;
phys = <&serdes_1 7>;
status = "okay";
}; 其中 `gpy245_0` 是 MDIO 节点。MDIO 到物理层的流量正常。 我在 lynx_pcs 驱动程序中添加了一个打印输出，用于显示读取结果： mdio_bus 0x0000000008c0f000:00: USXGMII:
wrote ADV=0xd601 BMCR=0x1a00
readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 问题： 鉴于对该 PCS 实例上的 MDIO_MMD_VEND2 寄存器的写入似乎不会持久，在 LX2162A 系列 SoC 上的 USXGMII 接受配置之前，是否需要已知的额外步骤（SerDes/PCS 块使能、协议特定的初始化或类似步骤）？协议 3 是否已针对 dpmac3 上的 USXGMII 进行了全面验证，还是主要针对 XFI 进行设计/测试？ 其他问题： 也许我不了解 GPY245 和 USXGMII。我看到有些人称之为 QXGMII，但我不知道 LX2162A 是否能够实现这个功能。 或许我需要联系 Solidrun，但他们所有的补丁似乎都没有限制 LX2162A 的功能。 谢谢！ Re: LX2162A USXGMII link never completes LX2162A 端的文档显示，它支持您所使用的路径上的 USXGMII ，但您所描述的症状看起来不像缺少 Linux pcs-lynx 写入，而更像是所选的 PCS 实例实际上仍未处于 USXGMII 应用程序模式，或者 MC 固件正在对错误的 10G PCS 选择器进行编程。
对于SerDes1 协议 3 ，LX2162A 参考手册将所有四个 SerDes1 通道列为 USXGMII / XFI，其中第一个通道为 USXGMII / XFI.3，这对应于您在 Clearfog SFP 路径上测试的 DPMAC3 用例。对于您未来的自定义载波目标， SerDes2 协议 7还将通道 6 和通道 7 记录为 USXGMII / XFI.13 和 USXGMII / XFI.14。
需要注意的是，USXGMII / XFI 条目不会自动显示为“USXGMII”。参考手册指出，在同一通道上，USXGMII 和 XFI 之间的默认值为 XFI。模式是通过协议配置寄存器 C (PCCC)选择，其 SXGMII*_XFI 位选择 0b = USXGMII 和 1b = XFI/SFI。因此，我首先要检查的不是 Linux BMCR 写入本身，而是DPMAC3 的特定 SXGMII 实例在 MC/DPC 初始化后是否清除了其 PCCC XFI 选择位。
MC 固件中出现此类故障并非 Linux PCS 驱动程序中的故障，此前也有过先例：一个 LX2162A 工单显示，MC 在 USXGMII 配置的 PCCC 中清除了错误的 10G 接口选择器，而 MC 固件工程版本 10.35.101 解决了该问题。另一张工单指出，MC 设置由 MC 固件完成，NXP 以二进制形式提供 MC。由于您使用的是 MC 10.39.0，因此您应该已经过了那个特定的旧修复程序，但您看到的故障模式仍然与“MC 没有将预期的 PCS 置于 USXGMII 模式”或“正在处理错误的 PCS 实例”一致。
接下来我会这样做：
在 Linux 进行任何更改之前，请阅读 PCCC。 在 RCW + MC + DPL/DPC 加载之后，但在 Linux PCS 驱动程序运行之前，读取 PCCC 并确认相关的 SXGMII*_XFI 位为 0。适用于 DPMAC3 / USXGMII/XFI.3预计会是第一个 SXGMII 选择器，而不是 MAC13/14 选择器。如果该位保持为 1，则该通道仍然是 XFI/SFI，并且您的 VEND2/USXGMII PCS 写入不会应用于活动的 USXGMII PCS 路径。
检查 MDIO 访问是否连接到预期的 PCS 管理端口。 SXGMII 协议控制寄存器有一个 MDEV_PORT 字段，用于匹配 MDIO 访问。手册中指出，软件在更改该字段后必须至少等待 3 个平台时钟周期，然后才能对 SGMII/PCS 目标进行 MDIO 访问。如果 MDIO 地址解码错误，写入操作可能会“无法持久”，因为您正在读取不同的或重置/默认的 PCS 窗口。
确认 USXGMII AN 寄存器只有在模式选择正确后才有意义。 USXGMII PCS CONTROL 寄存器的第 12 位具有 AUTO_NEGOTIATION_ENABLE，而 DEV_ABILITY / PARTNER_ABILITY 是 RW 寄存器。DEV_ABILITY 下供应商任意速度字段必须非零，因为零会导致自动协商失败。但如果 PCCC 仍然选择 XFI，那么这些 BMCR/能力写入并不是真正的根本问题。
除非 GPY245 板文档明确说明，否则不要将 QXGMII 视为单独的必需外部协议。 LX2162A 文档确实包含 QXGMII 协议变流器寄存器，包括 RESET/掉电控制位，例如 PD_QXGM 和 RST_QXGM。NXP 社区关于 LS1028A 的资料也提到了 10G_QXGMII Lynx SerDes 驱动程序路径。但是您选择的已记录的 LX2162A DPMAC 接口仍然是 USXGMII / XFI，NXP 文档单独指出 LX2160 类设备支持 USXGMII，“SXGMII”不是同一回事。换句话说：“QXGMII”在驱动程序/社区讨论中的引用可能描述的是内部转换器/驱动程序命名路径，不一定与您配置的USXGMII模式不同的MAC到PHY协议。
对于本次 Clearfog SFP 测试，请保持 DPC 简单。 MAC_LINK_TYPE_PHY with enet_if = "USXGMII" 是 MDIO 上管理外部 PHY 的更自然模型。除非您有意使用背板/KR 风格的流程，否则我不认为 MAC_LINK_TYPE_BACKPLANE 可以修复面向 PHY 的 USXGMII 设置。
我不会得出协议 3“主要仅限 XFI”的结论。参考手册将协议 3 记录为 DPMAC3 的 SerDes1 通道的 USXGMII / XFI。我无法从检索到的材料中证实的是，有单独的验证声明称“协议 3 + DPMAC3 + USXGMII 已通过 GPY245 验证”。更有力、有证据支持的说法是：硬件模式存在，默认为 XFI，除非 PCCC 选择 USXGMII，并且已知 MC 固件有先例对错误的 10G PCS 选择器进行编程。
针对您具体的回读：
写入 ADV=0xd601 BMCR=0x1a00
回读 ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000
如果 PCS 实例未完全启用/选择用于 USXGMII，或者 MDIO 管理窗口未指向预期的 PCS 实例，则这正是我所期望的结果。在添加更多 Linux 端写入之前，我会先验证 PCCC 和 MC 日志。
LX2162A 协议 3 已记录在案，适用于 DPMAC3 上的 USXGMII / XFI，但 USXGMII 依赖于 MC/PCCC 选择 USXGMII PCS；如果 VEND2/BMCR 写入没有持久性，首先要证明 DPMAC3 的正确 PCCC 位已清除，并且 MDIO 正在寻址正确的 SXGMII PCS 实例。 Re: LX2162A USXGMII link never completes @yipingwang非常感谢您的详细解答！ 你说的都很有道理，我已经开始更多地了解这个平台了。我已经开始使用 AN13329.pdf 中的建议。部分地址和功能似乎无法正常工作（可能是版本不匹配），但至少我可以获取如下所示的 MC 日志： => md 0x8340020 10
08340020: e0000006 00000021 00060000 00000000 ....!...........
08340030: 00000000 00000000 00000000 00000000 ................
08340040: 00000000 00000000 00000000 00000000 ................
08340050: 00000000 00000000 00000000 00000000 ................
=> md 0x21e1000000
21e1000000: 4d430100 00000000 01400000 00300000
[email protected].
21e1000010: 00000073 00000000 00000000 00000000 s...............
21e1000020: 00000000 00000000 00000000 00000000 ................
21e1000030: 00000000 00000000 00000000 00000000 ................
=> md 0x21e1400000 50
21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U
21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed
21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data
21e1400030: 6c697720 6562206c 69727020 6465746e will be printed
21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn
21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait
21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events .
21e1400070: 000a2e2e 00000000 00000000 00000000 ................
21e1400080: 00000000 00000000 00000000 00000000 ................
21e1400090: 00000000 00000000 00000000 00000000 ................
21e14000a0: 00000000 00000000 00000000 00000000 ................
21e14000b0: 00000000 00000000 00000000 00000000 ................
21e14000c0: 00000000 00000000 00000000 00000000 ................
21e14000d0: 00000000 00000000 00000000 00000000 ................
21e14000e0: 00000000 00000000 00000000 00000000 ................
21e14000f0: 00000000 00000000 00000000 00000000 ................
21e1400100: 00000000 00000000 00000000 00000000 ................
21e1400110: 00000000 00000000 00000000 00000000 ................
21e1400120: 00000000 00000000 00000000 00000000 ................
21e1400130: 00000000 00000000 00000000 00000000 ................ 我尝试通过 uboot 来操作 PCCC。以下是相关内容： crc32+ MC firmware version 10.39.0
fsl-mc: Booting Management Complex ... SUCCESS
fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1)
Autoboot in 3 seconds
=> mmc read 0x80d00000 0x6800 0x800
=> fsl_mc apply dpl 0x80d00000
fsl-mc: Deploying data path layout ... SUCCESS
=> md.l 0x1ea10b0 1
01ea10b0: 88889991 .... 我真心希望 0x1ea10b0 是正确的地址。根据 LX2162ARM.pdf 文件，那*可能*是正确的地址，解码后显示： A (lane 0) bit 31 1 = XFI/SFI
B (lane 1) bit 27 1 = XFI/SFI
C (lane 2) bit 23 1 = XFI/SFI
D (lane 3) bit 19 1 = XFI/SFI 是否应该观察正确的寄存器地址（PCCC）？我还能提供其他信息吗？ 谢谢！ Re: LX2162A USXGMII link never completes
是的。为了 SerDes1 ， 0x1ea10b0 是正确的地址 PCCC ：
LX2162A CCSR 地图列表 SerDes 1 在 0x1EA_0000–0x1EA_FFFF 。
SerDes 内存映射列表 协议配置寄存器 C / PCCC 偏移量 0x10B0 。
所以： 0x1EA0000+0x10B0=0x1EA10B0 0 x 1 E A 0000 + 0 x 10 B 0 = 0 x 1 E A 10 B 0
所以你的 U-Boot 读取到：
复制
=> md.l 0x1ea10b0 1
01ea10b0: 88889991
正在观察预期情况 SerDes1 PCCC 登记。
需要特别注意的是命名：我不会将这些领域描述为物理领域。 SerDes 通道 A/B/C/D 适用于您当前的配置。在 LX2162A SerDes1 协议表中，协议 3 地图 物理车道 H / 车道 0 到 USXGMII / XFI.3 然后，从 G 车道/1 车道到 .4 ，F车道/2车道至 .5 以及 E 车道/3 号车道 .6 。PCCC 字段名称，例如 SXGMIIA_XFI ， SXGMIIB_XFI 等是 PCS/协议控制字段，其命名约定不一定与物理通道字母相同。
您的价值 0x88889991 高位进位解码如下：
复制
PCCC = 0x88889991
位 31:28 = 0x8 -> SXGMIIA_XFI = 1，CFG = 000
位 27:24 = 0x8 -> SXGMIIB_XFI = 1，CFG = 000
位 23:20 = 0x8 -> SXGMIIC_XFI = 1，CFG = 000
位 19:16 = 0x8 -> SXGMIID_XFI = 1，CFG = 000
位 15:12 = 0x9 -> SXGMIIE_XFI = 1，CFG = 001
位 11:8 = 0x9 -> SXGMIIF_XFI = 1，CFG = 001
关键在于 _XFI 少量。RM定义 0 作为 USXGMII 模式 和 1 作为 XFI/SFI 模式 这些领域 。因此，您读到的值强烈表明，相关的 USXFI/SXGMII PCS 实例仍然被选中。 XFI/SFI 不是 USXGMII。
这与您的症状相符：Linux/restool 可能会报告 DPMAC_ETH_IF_USXGMII 但如果PCCC仍然拥有相关 _XFI 选择位 1 底层 SerDes/PCS 选择仍然有效地处于 XFI/SFI 模式。RM 还明确指出，要启用 10G-SXGMII，软件必须进行设置 PCCC[SGMIIa_XFI] = 0 。
你的MC日志提取看起来也正常。AN13329 指示阅读 MCFBAL/MCFBAH 0x8340020 构建 MC 固件基础，然后转储偏移量的日志缓冲区结构。 0x01000000 该结构体包含魔数、日志缓冲区偏移量和日志缓冲区长度 。你的 0x21e1000000 转储文件显示了预期结果 0x4d430100 魔法和指向日志偏移量的指针 0x01400000 这与你之后的转储文件相符。 0x21e1400000 。
接下来我要拍摄的内容：
每个阶段的PCCC快照
复制
md.l 0x1ea10b0 1
捕捉它：
immediately after RESET / before MC 启动 if possible,
MC启动后，
DPC/DPL申请后，
Linux启动后，
在 DPMAC 探测/配置之后。
相邻协议配置寄存器
复制
md.l 0x1ea10a0 1 # PCC8
md.l 0x1ea10a4 1 # PCC9
md.l 0x1ea10b0 1 # PCCC
PCC8/PCC9 包含其他 SGMII 配置字段，而 PCCC 是 SXGMII/XFI 选择器寄存器。 。
确认尝试强制使用 USXGMII 时，哪个 PCCC 字段发生了变化。 如果可以安全地在 U-Boot 中进行实验，请尝试清除候选路径。 _XFI 截取一段并立即读出来。例如，如果 dpmac3 对应于第一个 SXGMII/USXFI 控制字段，则清除第 31 位将作为实验性检查：
复制
mw.l 0x1ea10b0 0x08889991 1
md.l 0x1ea10b0 1
如果它立即读取为 0x88889991 那么，要么写入操作被阻止/覆盖，要么该字段在当前阻塞状态下不可写。如果这种情况一直持续到 MC 或 Linux 运行，那么 MC/Linux 很可能正在恢复 XFI/SFI 模式。
完整的RCW SerDes解码 你已经拥有 SerDes1=3, SerDes2=11 这与 dpmac3 通道可用相符 USXGMII / XFI.3 在 SerDes1 协议 3 下 。不过，升级问题时，仍需提供完整的 RCW 字符串和原始 RCW 转储，因为 MC 固件通常会根据完整的协议集进行调整。
MC固件+DPC/DPL制品 因为你的MC是 10.39.0 ， 包括：
MC固件版本
DPC源，
DPL来源，
精确的 dpmac@3 堵塞，
restool dpmac info dpmac.3 ，
每一步之后的PCCC值。
我目前对您数据的解读： 是的， 0x1ea10b0 是正确的 SerDes1 PCCC 地址，并且 0x88889991 看起来相关的 PCS 选择器仍然处于 XFI/SFI 模式。 这与 XFI 通过 SFP 插槽工作，而 USXGMII 不接受/保留预期的 PCS 配置的情况一致。
