[参考译文] TDA4VL-Q1：在定制 TDA4VL 电路板上运行 Edge AI SDK 时没有显示输出

您好、James：

您能否共享电路板的器件树 DTS 文件？

对于上下文：

如果显示流水线完全正常运行、则会出现 Tidss；但如果流水线中的某个组件出现问题、则不会出现 Tidss。 我想看看显示流水线是如何相互连接的。 例如、对于 AM68 SK 电路板、我们连接 DSS->DSI->sn65dsi86->panel-edp： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am68-sk-base-board.dts?h=ti-linux-6.6.y#n734 

此致、

Takuma

尊敬的 Takuma：

我是 Damon。 James 帮助我发布问题、我会跟大家一起跟进、以便进一步讨论。

1、硬件/软件兼容性问题
我们的电路板硬件基于修改后的 J721S2XSOMXEVM 设计、而初始边缘 AI SDK 软件似乎是为 SK-AM68 EVM 配置的。 这是否意味着我们需要对器件树配置进行相应调整以确保适当的兼容性？

2.设备树验证
我目前不确定电路板是否正在运行“k3-am68-sk-base-board.dts"或“或“k3-j721s2-common-proc-board.dts"配置“配置。 为了进行澄清、我已经在电路板上执行了以下命令、并且我共享输出“TDA4VL_CURRENTs.dts"以“以供您查看：

dtc -I fs -O dts -o TDA4VL_current.dts /proc/device-tree/

e2e.ti.com/.../2235.DTS_5F00_files.zip

注意：我对 Rule.make 的修改如下：

### PLATFORM CONFIG ###
#platform
PLATFORM=am68-sk
SOC=j721s2
#SOC_TYPE?=hs-fs
SOC_TYPE?=gp

ARCH=aarch64
ARMV8=a72

#u-boot machine
#UBOOT_MACHINE=am68_sk_a72_defconfig
UBOOT_MACHINE=j721s2_evm_a72_defconfig

# UBOOT_MACHINE for the R5
#UBOOT_MACHINE_R5=am68_sk_r5_defconfig
UBOOT_MACHINE_R5=j721s2_evm_r5_config

尊敬的 Damon：

[quote userid=“658234" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1546434/tda4vl-q1-no-display-output-when-running-edge-ai-sdk-on-custom-tda4vl-board/5950958 硬件/软件兼容性问题

通常、在进行定制电路板时需要更改 DTS 文件。 SK-AM68 和 J721S2XSOMXEVM 之间的器件树会有所不同、并且对于定制电路板也会有所不同。

[quote userid=“658234" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1546434/tda4vl-q1-no-display-output-when-running-edge-ai-sdk-on-custom-tda4vl-board/5950958 设备树验证

它看起来好像 正在使用 k3-j721s2-common-proc-board.dts。  

•  定制电路板上是否有 sn65dsi86 桥接器？
• 如果有、您能否检查原理图以查看连接了相同的 GPIO、或者与电源、时钟或使能 GPIO 是否存在任何差异？
  • 有一个 dtsi 文件可以在此处设置这些引脚： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi?h=ti-linux-6.12.y#n731

Regarsd,

Takuma

我已经重新比较了 EVM 和我们的电路板。 我们的电路板仅使用 DP0 并移除了 DP1、而 sn65dsi86 只能在 DP1 上用作 DSI0 和 DP1 之间的桥接器。 那么我们可以忽略与 DP1 相关的配置吗？

此外、我们的电路板有 SERDES0、直接连接到 DP0 连接器。 与 EVM 的区别在于：EVM 仅使用 2 个通道、而我们使用 4 个通道、我们已经按如下方式修改了引脚配置。

还需要为仅 DP0 连接修改哪些内容才能使 TI DSS 正常启动？

尊敬的 Damon：

我懂了。  如果使用直接 DP 连接、则 sn65dsi86 相关配置不应影响显示器输出。 但是、建议删除。

至于显示无法正常工作、您能否检查器件树和原理图以确保没有差异？ 以下是 TI 默认器件树和 CPB（通用处理器电路板）原理图的内容：

我看到共享日志中的 DP0-prw 的探测器函数已延迟：

[  12.707643]平台固定调节器-DP0-prw：延迟探头待定

此致、

Takuma

尊敬的 Takuma：

我只想为您补充这些硬件详细信息和差异：

-定制电路板:基于 J721S2XSOMXEVM 的修改设计。

- DP 模块的主要差异:
DP0_pwr_3V3：已删除扩展 IO、DP0_3V3_EN 现在由 McASP1_AXR1 (V27) 控制为 GPIO。
2. SERDES0 通道：未使用 SERDES0_TX0/TX1 作为 PCIe 功能、更改为使用 SERDES0_TX0/TX1/TX2/TX3 作为 DP 功能并连接到 DP 连接器。
3.断开 DP1 连接。

请告知需要修改设备树节点。 谢谢你。

此致、

Damon

尊敬的 Damon：

请将  McASP1_AXR1  引脚多路复用为 GPIO、并更改 DP0_pwr_3V3 节点中的 GPIO 属性以使用 McASP1_AXR1 引脚。

此致、

Takuma

尊敬的 Takuma：

实施建议的更改后、不再显示“dp-pwr delayed probe pending“日志。 但是、仍然没有视频输出、并且 tidss 模块无法正确安装。 我在日志中注意到串行器/解串器 wiz 错误消息、如下所示：

[    1.136706] ------------[ cut here ]------------
[    1.141432] wiz bus@100000:wiz@5060000: Unable to create SERDES platform device
[    1.148924] WARNING: CPU: 1 PID: 11 at drivers/phy/ti/phy-j721e-wiz.c:1624 wiz_probe+0xd10/0xe6c
[    1.157915] Modules linked in:
[    1.161033] CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.6.44-ti-g541c20281af7-dirty #1
[    1.169478] Hardware name: Texas Instruments J721S2 EVM (DT)
[    1.175257] Workqueue: events_unbound deferred_probe_work_func
[    1.181222] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    1.188333] pc : wiz_probe+0xd10/0xe6c
[    1.192158] lr : wiz_probe+0xd10/0xe6c
[    1.195982] sp : ffff80008163ba80
[    1.199361] x29: ffff80008163bb40 x28: ffff000b7e206098 x27: 0000000000000003
[    1.206654] x26: ffff800080cb8130 x25: 0000000000000004 x24: 0000000000000004
[    1.213946] x23: 0000000000000000 x22: ffff00082cd090c8 x21: ffff00082c1cc010
[    1.221237] x20: ffff00082cd09080 x19: 0000000000000000 x18: 0000000000000006
[    1.228529] x17: 766564206d726f66 x16: 74616c7020534544 x15: 5245532065746165
[    1.235821] x14: 7263206f7420656c x13: ffff8000812ef178 x12: 0000000000000366
[    1.243112] x11: 0000000000000122 x10: ffff800081347178 x9 : ffff8000812ef178
[    1.250404] x8 : 00000000ffffefff x7 : ffff800081347178 x6 : 80000000fffff000
[    1.257696] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[    1.264987] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00082c151c80
[    1.272279] Call trace:
[    1.274770]  wiz_probe+0xd10/0xe6c
[    1.278239]  platform_probe+0x68/0xc4
[    1.281975]  really_probe+0x148/0x2b0
[    1.285712]  __driver_probe_device+0x78/0x12c
[    1.290159]  driver_probe_device+0xd8/0x15c
[    1.294429]  __device_attach_driver+0xb8/0x134
[    1.298965]  bus_for_each_drv+0x88/0xe8
[    1.302878]  __device_attach+0xa0/0x190
[    1.306792]  device_initial_probe+0x14/0x20
[    1.311062]  bus_probe_device+0xac/0xb0
[    1.314975]  deferred_probe_work_func+0x88/0xc0
[    1.319600]  process_one_work+0x138/0x248
[    1.323697]  worker_thread+0x320/0x438
[    1.327522]  kthread+0x110/0x114
[    1.330815]  ret_from_fork+0x10/0x20
[    1.334463] ---[ end trace 0000000000000000 ]---
[    1.339305] wiz: probe of bus@100000:wiz@5060000 failed with error -12

这可能是根本原因吗？
我应该进行哪些调整来解决视频输出问题？
随附的是完整日志和当前 DTS 文件、供参考。 谢谢你。

e2e.ti.com/.../log_5F00_and_5F00_dts_5F00_0805.zip

此致、

Damon

尊敬的 Damon：

很棒的景点 是的、如果使用直接 DP 连接而非 DSI 转 eDP 桥接器、也需要串行器/解串器。

从 DTS 文件中删除 EDP_SERDES_mux 基准的状态或将其设置为 0、因为对于使用 SerDes 通道 0/1 的 4 通道模式或双通道模式、我们需要值 0：

尊敬的 Damon：

在下一步中、您是否可以尝试使用与 j784s4 的 serdes4 节点类似的内容来定义 serdes0（更改主要是代替 serdes4、 将使用 serdes0 节点名称）： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts?h=ti-linux-6.1.y#n1109

并像在同一器件树文件中一样在 mhdp 节点中使用新定义的 serdes0 链接？

此致、

Takuma

尊敬的 Damon：

U-Boot 中是否设置了任何器件树叠加？ 具体来说、uEnv.txt 文件中是否有 name_overlays 变量？

此致、

Takuma

尊敬的 Takuma：

仅   uEnv.txt 中的 k3-j721s2-edgeai-apps.dtbo name_overlays 变量。

此致、

Damon

尊敬的 Takuma：

测试表明、注释掉 pcie1_rc 节点是原因。 恢复后、系统将正常引导。

如何 serdes0 在保留 pcie1_rc 节点的同时修改 DP 以仅发挥作用？ 如果我进行以下修改、是否会 pcie1_rc 导致编译错误（例如） serdes0_pcie_link not found？

+/*&serdes0 {
        status = "okay";
        serdes0_pcie_link: phy@0 {
                reg = <0>;
@@ -564,14 +576,28 @@
                cdns,phy-type = <PHY_TYPE_PCIE>;
                resets = <&serdes_wiz0 1>;
        };
+};*/
+&serdes0 {
+       status = "okay";
+       serdes0_dp_link: phy@0 {
+               reg = <0>;
+               cdns,num-lanes = <4>;
+               #phy-cell = <0>;
+               cdns,phy-type = <PHY_TYPE_DP>;
+               cdns,max-bit-rate = <2700>;
+               resets = <&serdes_wiz0 1>, <&serdes_wiz0 2>,
+                            <&serdes_wiz0 3>, <&serdes_wiz0 4>;
+       };
 };

此致、

Damon

尊敬的 Damon：

对于 TDA4VL、无法仅针对 DP 实现串行器/解串器功能、同时还保留 PCIe。 串行器/解串器在两者之间共享、因此要拥有这两个接口、必须在两者之间拆分通道。

保留 pcie1_RC 节点是否具有 PCIe 功能？ 或者、看看该错误是否可以解决、以及您是否不需要 PCIe？

此致、

Takuma

尊敬的 Takuma：

为误解道歉。 我不需要 PCIe 功能并想将所有 4 个信道分配给 DP。

但是、我遇到的问题是：当我通过删除 PCIe 节点修改设备树时、系统无法引导。 这可能是由于我的修改中的错误。 您能指导我如何正确实施这些更改吗？ 谢谢你。

附加上下文：

我尝试了 status = "disabled"  &pcie1_rc 节点中的设置、但 TI DSS 仍然无法启动。 这表明这些功能配置可能不是根本原因。 是否有任何其他方法来诊断和解决 TI DSS 初始化故障？ 谢谢你。

尊敬的 Damon：

这可能 是 U-Boot 和 Linux 配置之间的某些不匹配导致的。  

您是尝试更新 U-Boot DTS 以匹配 Linux DTS、还是在 U-Boot DTS 中禁用与串行器/解串器和串行器/解串器相关的接口？

此致、

Takuma

尊敬的 Damon：  

您是否可以尝试如下所示的操作：

e2e.ti.com/.../0001_2D00_example_2D00_dts_2D00_for_2D00_serdes_2D00_configured_2D00_for_2D00_x4_2D00_lanes_2D00_DP.patch

作为免责声明、我无法在 TI EVM 上进行全面测试、因为硬件不会将所有串行器/解串器信号路由到 DP。 但我确实看到 TI 默认的 k3-j721s2-main.dtsi 具有一些串行器/解串器配置、因此这可能会导致一些冲突？

此致、

Takuma

尊敬的 Takuma：

 torrent_phy_dp 在提供的修补程序之后、 k3-j721s2-main.dtsi  mhdp: dp-bridge@a000000 由于未解析、在中删除会导致节点中出现编译错误 phys = <&torrent_phy_dp>。 我 phys = <&torrent_phy_dp> 直接从 mhdp: dp-bridge@a000000中删除,这允许编译通过,但系统仍然显示:
wiz: probe of bus@100000:wiz@5060000 failed with error -12 引导后。

[    1.140544] ------------[ cut here ]------------
[    1.145272] wiz bus@100000:wiz@5060000: Unable to create SERDES platform device
[    1.152766] WARNING: CPU: 0 PID: 38 at drivers/phy/ti/phy-j721e-wiz.c:1624 wiz_probe+0xd10/0xe6c
[    1.161756] Modules linked in:
[    1.164872] CPU: 0 PID: 38 Comm: kworker/u4:2 Not tainted 6.6.44-ti-g541c20281af7-dirty #1
[    1.173317] Hardware name: Texas Instruments J721S2 EVM (DT)
[    1.179095] Workqueue: events_unbound deferred_probe_work_func
[    1.185061] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    1.192173] pc : wiz_probe+0xd10/0xe6c
[    1.195998] lr : wiz_probe+0xd10/0xe6c
[    1.199822] sp : ffff800081e2ba80
[    1.203201] x29: ffff800081e2bb40 x28: ffff000b7e206598 x27: 0000000000000003
[    1.210494] x26: ffff800080cb8130 x25: 0000000000000004 x24: 0000000000000004
[    1.217786] x23: 0000000000000000 x22: ffff00082d9b48c8 x21: ffff00082cc65c10
[    1.225078] x20: ffff00082d9b4880 x19: 0000000000000000 x18: 0000000000000006
[    1.232369] x17: 766564206d726f66 x16: 74616c7020534544 x15: 5245532065746165
[    1.239661] x14: 7263206f7420656c x13: ffff8000812ef178 x12: 0000000000000366
[    1.246952] x11: 0000000000000122 x10: ffff800081347178 x9 : ffff8000812ef178
[    1.254244] x8 : 00000000ffffefff x7 : ffff800081347178 x6 : 80000000fffff000
[    1.261536] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[    1.268827] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00082c1ad580
[    1.276119] Call trace:
[    1.278610]  wiz_probe+0xd10/0xe6c
[    1.282079]  platform_probe+0x68/0xc4
[    1.285815]  really_probe+0x148/0x2b0
[    1.289551]  __driver_probe_device+0x78/0x12c
[    1.293998]  driver_probe_device+0xd8/0x15c
[    1.298268]  __device_attach_driver+0xb8/0x134
[    1.302804]  bus_for_each_drv+0x88/0xe8
[    1.306718]  __device_attach+0xa0/0x190
[    1.310632]  device_initial_probe+0x14/0x20
[    1.314901]  bus_probe_device+0xac/0xb0
[    1.318815]  deferred_probe_work_func+0x88/0xc0
[    1.323440]  process_one_work+0x138/0x248
[    1.327534]  worker_thread+0x320/0x438
[    1.331359]  kthread+0x110/0x114
[    1.334651]  ret_from_fork+0x10/0x20
[    1.338300] ---[ end trace 0000000000000000 ]---
[    1.343142] wiz: probe of bus@100000:wiz@5060000 failed with error -12

问题：

1. 是否还需要在中调整与显示相关的配置 k3-j721s2-main.dtsi？

2. 如果没有、接下来的调试步骤是什么？

谢谢你。

此致、

Damon

尊敬的 Damon：  

您是对的。 应删除 k3-j721s2-main.dtsi 中的 phys =<&torrent_phy_dp>。 实际上、现在是在板级 dts 文件而不是 dtsi 文件上完成配置。 有点奇怪的是,我的建筑不是在我的尽头出错  

您可以尝试引用下面添加的补丁吗？

e2e.ti.com/.../0001_2D00_version_2D00_3_2D00_example_2D00_dts_2D00_for_2D00_serdes_2D00_configured_2D00_for_2D00_x4_2D00_l.patch

我看到这些错误日志的唯一情况是没有像以下主题中那样启用 SerDes 器件树节点的某些组件：  TDA4VM：在 j721e 上使用 combined_appImage 在 SBL 引导流程中运行 vision_apps 

否则、您能否共享最新的完整器件树？ Diff 看起来不错、但想仔细检查器件树文件。

此致、

Takuma

尊敬的 Takuma：

我已经应用了您提供的补丁、但很遗憾、 wiz probe fail 问题仍然存在。

附件如下：

1. 完整的引导日志

   e2e.ti.com/.../TDA4VL_5F00_edgeai_5F00_log_5F00_20250814.txt

2. 下的所有文件  dts/ti/

   e2e.ti.com/.../dts_5F00_ti.zip

3. 使用从电路板解压缩的器件树源 (DTS) 文件  dtc

   e2e.ti.com/.../dts_5F00_from_5F00_board_5F00_dtc_5F00_0814.zip
4. uEnv.txte2e.ti.com/.../7635.uEnv.txt
5. 构建信息：

   提供	ti-processor-sdk-linux-edgeai-j721s2-evm-10_01_00_04-Linux-x86-Install.bin
   Rules.make	e2e.ti.com/.../Rules_5F00_make.zip

请帮助查看这些材料并协助进行故障排除。 谢谢！

此致、

Damon

尊敬的 Damon：

感谢您提供非常详细的信息。 我想我发现了这个问题。 出于某种原因、在编译的 DTB 文件中、串行器/解串器节点似乎处于“禁用“状态。  

我看到您的 DTS 在 serdes0 中的状态为“正常“、因此我不确定为什么不覆盖它。  此外、似乎还有其他外设（如 ospi1 节点）不会覆盖状态。  

至于一些想法 、可能是构建失败、 未刷写更新的器件树、或者内核正在加载不正确的器件树。

尝试试验 DTS 中的更改是否反映在 DTC 解编译的 DTB 中。

此致、

Takuma

尊敬的 Takuma：

这确实很奇怪。 以前、当我修改调节器属性时、更改始终生效。

然后今天,在我使用 make linux-dtbs /单独编译和部署设备树 make linux-dtbs_install （而在我总是使用 make linux / make linux_install 进行完整编译和部署之前）之后,的状态 serdes0 终于生效。

目前、 serdes probe fail“" 日志“日志已消失。 不幸的是, modetest -M tidss 仍然没有视频输出,仍然找不到 tidss。 完整的日志和 DTS 如下：

e2e.ti.com/.../TDA4VL_5F00_edgeai_5F00_log_5F00_20250815.txt

e2e.ti.com/.../dts_5F00_from_5F00_board_5F00_dtc_5F00_0815.zip

此时是否存在任何其他可能的问题？ 我应该朝哪个方向进行故障排除？ 谢谢你。

此致、

Damon

尊敬的 Damon：

有两点：

1. 您能否将此修补程序应用到 dd.c 并从 dmesg 共享日志？ 这将使每个驱动程序的探测器功能更加详细、并且应该显示是否探测了显示流水线中的每个驱动程序。
   e2e.ti.com/.../2867.0001_2D00_Enable_2D00_debug_2D00_logs_2D00_for_2D00_device_2D00_driver_2D00_probing.patch
2. 您能否分享“zcat /proc/config.gz “的输出？  

此致、

Takuma

尊敬的 Takuma：

由于我目前正在出差,它可能需要几天额外的时间来提供 dmesg 打开调试在 dd.c. 现在、我 config.gz 先附上的内容供您参考。

e2e.ti.com/.../zcat_5F00_config_5F00_gz_5F00_20250818.txt

谢谢！

此致、

Damon

尊敬的 Damon：

我懂了。 请在方便时提供日志。  

否则、内核配置看起来很好。 看起来显示流水线中的所有驱动程序都已启用。 因此、下一步是查看是否使用之前共享的修补程序探测驱动程序。

此致、

Takuma

尊敬的 Takuma：

是否 有关于以下情况的调试指南或提示  未探测节点 ？

我认为硬件应该正常工作、因为 在 RTOS SDK 下运行时、视觉应用可以正常输出视频。 但是、我现在需要在相同的硬件上运行 Edge AI SDK。

在硬件正常工作且设备树配置正确的情况下、至少应输入探测功能。 如果甚至没有触发探头功能、我们应该在哪个方向继续进行故障排除？ 请提供相关指导。

谢谢你。

此致、

Damon

尊敬的 Damon：

不探测的节点最常见的问题是：

1. 器件树问题。 即 status=“disabled"，“，更新、更新了错误的器件树文件、缺少节点、导致构建错误的格式错误等
2.  刷写问题。 可能是刷写了错误的文件、将文件刷写到错误位置、刷写时出现权限问题等
3. 问题。 内核版本、内核模块和/或器件树之间不匹配、内核配置错误等

到目前为止、我看到的一切看起来都是正确的、整个主题中提出的建议是检查以上 3 分。 但是、正如您发现在运行时禁用串行器/解串器节点时一样、  仅仅查看共享文件似乎就找不到一些问题。  

我最奇怪的是、必须在 k3-j721s2-main.dtsi 文件中将 serdes0 节点设置为 status=“oke"。“。 因此、我建议研究 k3-j721s2-common-proc-board.dts 文件中定义为何不起作用（即，上述 3 点的第 1 点）。  

此致、

Takuma

尊敬的 Damon：

很好的发现！ 这些发现将解释我们观察到的异常情况。 我想我们之前已经检查过 DTS、但可能解析了错误的文件 并 在 TDA4VL_CURRENT_DTS 中查看。

我同意你的怀疑。 DSS 将取决于 MHDP 是否正常、而 MHDP 依赖于串行器/解串器 PHY。 因此、DSS 重试并打印出“延迟探头挂起“是因为相关性未初始化。

至于 SERDES 未初始化的原因、看起来没有探测到 serdes0 和 SERDES_wiz0 节点。

此致、

Takuma

尊敬的 Damon：

您能否共享最新的  k3-am68-sk-base-board.dts？  

我认为、之前我们检查了 k3-j721s2-common-proc-board.dts、并在此电路板 DTS 文件中更改了串行器/解串器和 MHDP。 我怀疑 k3-am68-sk-base-board.dts 可能没有进行同样的更改。  

对于 serdes0 和 SERDES_wiz0、不进行探测。

我只能推测昨天的构建环境或软件更新过程存在问题。

我同意你的评论。 我的评论与 8 月 25 日相同。 即：

到目前为止、我看到的所有内容看起来都是正确的、并且在整个主题中提出的建议是检查以上 3 点。 但是、正如您发现在运行时禁用串行器/解串器节点时一样、  仅仅查看共享文件似乎就找不到一些问题。  [/报价]

实际上、观察到的运行时行为与 DTS 内容不匹配。

此致、

Takuma

尊敬的 Takuma：

k3-am68-sk-base-board.dts 正在熔断：

e2e.ti.com/.../k3_2D00_am68_2D00_sk_2D00_base_2D00_board.zip

我没有对的内容进行任何修改 k3-am68-sk-base-board.dts,而且, k3-am68-sk-base-board.dtb 编译后没有生成任何文件。 我可以询问此文件是否也会产生影响吗？

谢谢。

此致、

Damon

尊敬的 Damon：

我读过以前的评论是错误的。 我以为你发现  k3-am68-sk-base-board.dts 是用 dts 文件代替普通的 proc 板 dts。 而是通过 edgeai dts 叠加层导致问题。

最新日志似乎 绑定了 DP0-connector。 现在问题出在 mhdp 上、奇怪的是找不到所配置的 PHY。

作为实验、您是否可以尝试 将 k3-j721s2-common-proc-board.dts 中 serdes0 下定义的串行器/解串器链路定义移至 k3-j721s2-main.dtsi？

此致、

Takuma

尊敬的 Damon：

确实是个好消息！

有点奇怪、为什么 serdes0 DP 链接需要写入 dtsi 文件内的初始 serdes0 节点。 dtso 或 dts 中的定义应具有相同的最终结果、因为它们会覆盖 dtsi。  

在任何情况下、我们是否可以顺利结束这一主题？

此致、

Takuma