This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] DRA829V:在 u-boot 中启用 cpsw0主域以太网交换机

Guru**** 2551110 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1266033/dra829v-enable-cpsw0-main-domain-ethernet-switch-in-u-boot

器件型号:DRA829V
主题中讨论的其他器件:DRA829

您好、专家!

我们的定制电路板在 MCU 域上没有以太网端口、因此我们无法
使用 k3-j721e-mcu-wake.dtsi 中定义的 mcu_cpsw。

我已经尝试从 k3-j721e-evm-gesi-exp-board.dtbo 添加 cpsw0信息、但 u-boot 提示:

Failed to probe am65_cpsw_nuss driver
Net: No ethernet found.

此外、我没有 MDIO:

=> mdio list
No MDIO bus found

我所做的:

1.将完整的  cpsw0Ethernet@c000000 块从 linux-ti-staging 添加到 u-boot-ti-staging 中。

2.向我的 u-boot DTS 中添加了 k3-j721e-evm-gesi-exp-board.dtbo cpsw0相关信息。

3.删除了对 mcu_cpsw 的所有引用

感谢任何帮助。

/波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    是,不正确。 我将100Mbit PHY 误认为是 RMII。 它们也是 RGMII。

    如果是这种情况、请将器件树节点更新到以下位置:

    &main_cpsw0_port1 {
        status = "okay";
        phy-handle = <&main_cpsw0_phy5>;
        phy-mode = "rgmii-rxid";
        mac-address = [00 00 00 00 00 00];
        phys = <&main_phy_gmii_sel 1>;
    };
    
    &main_cpsw0_port3 {
        status = "okay";
        phy-handle = <&main_cpsw0_phy0>;
        phy-mode = "rgmii-rxid";
        mac-address = [00 00 00 00 00 00];
        phys = <&main_phy_gmii_sel 3>;
    };
    
    &main_cpsw0_port4 {
        status = "okay";
        phy-handle = <&main_cpsw0_phy4>;
        phy-mode = "rgmii-rxid";
        mac-address = [00 00 00 00 00 00];
        phys = <&main_phy_gmii_sel 4>;
    };

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    是的、在与硬件部门确认后、我已经完成了该操作。

    但它不会改变非功能行为。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    它没有改变非功能行为,但。

    您能否确认所有3个 PHY 是否相同? 如果是、您能否确认接口不起作用的2个 PHY 的 Strap 配置设置是否与与对应于哪个 ETH0的 PHY 的 Strap 配置设置相同?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    否、它们是不相同的。 根据 MDIO 列表输出、您可以看到我们使用了一个 DP83867和两个 DP83822:

    => mdio list
    ethernet@c000000port@1:
    0 - TI DP83867 <--> ethernet@c000000port@3
    4 - TI DP83822 <--> ethernet@c000000port@4
    5 - TI DP83822 <--> ethernet@c000000port@1

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    DP83822 PHY 的自举设置是否足以使其在 RGMII 模式下运行?
    另外、考虑到链路状态位为0、表示未检测到链路、
    PHY 配置可能存在其他问题。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    DP83822 PHY 的自举设置是否能使其在 RGMII 模式下运行?
    另外、考虑到链路状态位为0、表示未检测到链路、
    PHY 配置可能存在其他问题。

    我将与我的同事再次核实这一点。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我将与我的同事再次核对此内容。

    原理图确认它们是在 RGMII 模式下捆绑的。

    此外、当我检查寄存器0x17时、位9被置位、表示 RGMII 模式:

    => mii read 4 0x17
    0241
    => mii read 5 0x17
    0241

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    原理图确认它们是以 RGMII 模式捆绑的。

    是否知道链路状态位为什么保持为0?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    是否知道链接状态位为什么保持为0?

    不、这是未知的。 你有什么想法吗?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    您能向您的硬件团队核实一下吗?
    如果 PHY 未通过链路伙伴广播功能、或 PHY 与链路伙伴之间也没有连接、则可能会发生这种情况。

    此致、
    苏德黑尔

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    请建议还需检查哪些内容才能使这两个 DP83822 PHY 上的链路和传输正常工作。 我已经和硬件团队讨论过、他们没有任何线索。

    出现了另一个问题。 在 tftp 传输期间,工作端口将出现大量超时。 因为 DFU 非常慢、所以我们确实需要 tftp 运行。 我们不能等待90分钟下载 rootfs。

    在 BeagleBone-ai64上测试1MB 文件:

    => tftpboot megfile.bin
    am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2
    link up on port 1, speed 1000, full duplex
    Using ethernet@46000000port@1 device
    TFTP from server 192.168.0.1; our IP address is 192.168.0.10
    Filename 'megfile.bin'.
    Load address: 0x82000000
    Loading: ################################################## 1 MiB
    14.1 MiB/s
    done
    Bytes transferred = 1048576 (100000 hex)

    在定制电路板上测试该文件:

    => tftpboot megfile.bin
    am65_cpsw_nuss_port ethernet@c000000port@3: K3 CPSW: rflow_id_base: 16
    link up on port 3, speed 1000, full duplex
    Using ethernet@c000000port@3 device
    TFTP from server 192.168.0.1; our IP address is 192.168.0.11
    Filename 'megfile.bin'.
    Load address: 0x82000000
    Loading: T T T ##T T T #T T ####T #T ##
    Retry count exceeded; starting again

    你有什么建议可能导致这种情况? 也许是 DMA 或 IRQ 设置?

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    在 tftp 传输期间,工作端口将出现大量超时。

    您的意思是说它可以正常工作、但有时会在日志中共享时失败? 或者您是说它永远不会起作用吗?

    接口是否直接连接到 TFTP 服务器,或是否有网络交换机?
    如果有网络交换机,除了主板和 TFTP 服务器外,网络交换机是否连接了其它端口?
    能否检查一下即使 TFTP 服务器直接连接到板上,是否出现了此问题?

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我所说的"工作端口"是指实际上具有链路连接和 CAN ping 的千兆位端口。

    当使用一个1M 字节的文件时、它有时会设法使其通过、有时会因为10次超时而停止、如上所述。

    我正在隔离网络上进行测试。 没有其他设备。 如上所述、BeagleBone U-boot TFTP 运行完美无瑕、我可以在大约15秒内传输一个240MB 的文件。

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    在 TFTP 超时后、您能否共享以下寄存器的值?
    以下寄存器用于正在使用的 CPSW MAC 端口3。
    0x0C03A610 (CPSW_STAT_RXCRCERRORS)
    0x0C03A614  (CPSW_STAT_RXCODEERRORS)
    0x0C03A618  (CPSW_STAT_RXOVERSIZEDFRAMES)
    0x0C03A628  (CPSW_STAT_ALE_DROP)
    0x0C03A628 (CPSW_STAT_ALE_OVERRLOG_DROP)

    此外、您是否可以使用 tcpdump、Wireshark 或任何其他数据包捕获工具来确定:
    1. TFTP 服务器是否已收到板发送的数据包
    2. TFTP 服务器是否已将回复发送给板

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    新的一周! 确实希望能尽快解决以太网问题。 我们需要它在项目中提交。

    上述寄存器都显示为零、因此我猜即使传输有几次超时也没有错误:

    => tftpboot megfile.bin
    am65_cpsw_nuss_port ethernet@c000000port@3: K3 CPSW: rflow_id_base: 16
    link up on port 3, speed 1000, full duplex
    Using ethernet@c000000port@3 device
    TFTP from server 192.168.0.1; our IP address is 192.168.0.10
    Filename 'megfile.bin'.
    Load address: 0x82000000
    Loading: ##T #############T ########T ######T ######T ###T #T #T ####T #####T # 1 MiB
    19.5 KiB/s
    done
    Bytes transferred = 1048576 (100000 hex)
    =>
    => md 0x0C03A610 1
    0c03a610: 00000000 ....
    => md 0x0C03A614 1
    0c03a614: 00000000 ....
    => md 0x0C03A618 1
    0c03a618: 00000000 ....
    => md 0x0C03A628 1
    0c03a628: 00000000 ....
    => md 0x0C03A628 1
    0c03a628: 00000000 ....

    我将设置 Wireshark、以便能够回答您的部分问题。

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    这是 Wireshark 捕获的信息、显示超时:

    您会看到该块#540没有直接确认。 它实际上是重新排序的、并且
    另外3秒后确认。

    这现在是 Windows 11计算机上的 TFTP 服务器。 该行为与
    Ubuntu 上的 TFTP 服务器。

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    TFTP 服务器和板似乎位于不同的子网中,因此我假设它们之间有一个网络交换机。
     除了与 TFTP 服务器设备对应的端口和
    会怎么样?

    此外、正如您在注释中指出的那样、似乎确认并没有从板发送到 TFTP
    超时期间为服务器。  您是否可以按板上的"Ctrl+C"来中断 TFTP 过程、即您注意到 TFTP
    超时问题、然后检查寄存器的值:
    0x0C03A634 (CPSW_STAT_TXGOODFRAMES)
    来查看 电路板上的 TX 数据包数量是否与预期的 TFTP 数据包数量相匹配、
    数据包是由电路板发送的?

    要确定确认数据包是否未由电路板发送、还是被网络交换机丢弃、
    上述过程是必要的。 或者、如果您能够引导至 Linux 并在 Linux 上使用同一界面、请尝试 TFTP
    相同的接口运行 TI Edge AI。 如果在 Linux 中仍然可以看到超时、则在此处进行调试会更容易。 另一方面、如果问题
    在 Linux 中不可见、这表明在 U-Boot 阶段存在一些问题。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我发布了以下内容:

    => md 0x0C03A634 1
    0c03a634: 00000c79 y...
    => tftpboot megfile.bin
    am65_cpsw_nuss_port ethernet@c000000port@3: K3 CPSW: rflow_id_base: 16
    link up on port 3, speed 1000, full duplex
    Using ethernet@c000000port@3 device
    TFTP from server 10.142.1.111; our IP address is 10.142.3.9
    Filename 'megfile.bin'.
    Load address: 0x82000000
    Loading: ################
    Abort
    => md 0x0C03A634 1
    0c03a634: 00000d6d m...

    正常传输的数据包数量已从0x0c79增加到0x0d6d -> 244个数据包。 Wireshark 显示已接收到242个 TFTP 数据包、包括初始传输请求:

    247 6.516604 10.142.3.9 10.142.1.111 TFTP 93 Read Request, File: megfile.bin, Transfer type: octet, timeout=5, tsize=0, blksize=1468
    250 6.520067 10.142.3.9 10.142.1.111 TFTP 60 Acknowledgement, Block: 0
    252 6.520533 10.142.3.9 10.142.1.111 TFTP 60 Acknowledgement, Block: 1
    254 6.520981 10.142.3.9 10.142.1.111 TFTP 60 Acknowledgement, Block: 2
    256 6.521210 10.142.3.9 10.142.1.111 TFTP 60 Acknowledgement, Block: 3

    ...

    730 6.586755 10.142.3.9 10.142.1.111 TFTP 60 Acknowledgement, Block: 237
    732 6.587003 10.142.3.9 10.142.1.111 TFTP 60 Acknowledgement, Block: 238
    734 6.587266 10.142.3.9 10.142.1.111 TFTP 60 Acknowledgement, Block: 239
    736 6.587539 10.142.3.9 10.142.1.111 TFTP 60 Acknowledgement, Block: 240

    这是它超时的地方。 似乎又从 SoC 发送了两个数据包,但它们从未到达 TFTP 服务器。 另一项测试表明相同、始终存在2个数据包缺失。

    在 Linux 中,我根本看不到任何 TFTP 流量,甚至 ping 也似乎不起作用:

    root@asp3:/# tftp -g -r megfile.bin 10.142.1.111
    tftp: timeout
    root@asp3:/# ^C
    root@asp3:/# ping 10.142.1.111
    PING 10.142.1.111 (10.142.1.111) 56(84) bytes of data.
    64 bytes from 10.142.1.111: icmp_seq=1 ttl=128 time=1.71 ms
    64 bytes from 10.142.1.111: icmp_seq=3 ttl=128 time=2.35 ms
    64 bytes from 10.142.1.111: icmp_seq=5 ttl=128 time=1.23 ms
    64 bytes from 10.142.1.111: icmp_seq=6 ttl=128 time=1.32 ms
    64 bytes from 10.142.1.111: icmp_seq=7 ttl=128 time=2.16 ms
    64 bytes from 10.142.1.111: icmp_seq=8 ttl=128 time=2.35 ms
    64 bytes from 10.142.1.111: icmp_seq=9 ttl=128 time=2.37 ms
    64 bytes from 10.142.1.111: icmp_seq=10 ttl=128 time=2.33 ms
    64 bytes from 10.142.1.111: icmp_seq=11 ttl=128 time=2.24 ms
    ^C
    --- 10.142.1.111 ping statistics ---
    11 packets transmitted, 9 received, 18.1818% packet loss, time 10042ms
    rtt min/avg/max/mdev = 1.231/2.005/2.370/0.436 ms

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    我想可能是导致数据包丢失问题的两个原因(并非详尽列表):
    1.网络交换机正在断开连接
    2.硬件有问题

    如果可以获得网络交换机的统计信息、这将有助于确定
    确切的数据包丢弃点。 如果可以将板直接连接到另一个
    请执行此操作并检查是否仍在观察到丢包。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    这是通过 PC 和电路板之间的电缆连接的:

    => tftpboot megfile.bin
    am65_cpsw_nuss_port ethernet@c000000port@3: K3 CPSW: rflow_id_base: 16
    link up on port 3, speed 1000, full duplex
    Using ethernet@c000000port@3 device
    TFTP from server 192.168.0.1; our IP address is 192.168.0.10
    Filename 'megfile.bin'.
    Load address: 0x82000000
    Loading: ############T ##T ####T #################################T ###T ###########
    ###########T ################T #T T ###T ############################
    Retry count exceeded; starting again

    同样的事情、但10次超时、因此传输中止了。 我确实认为这与以太网端口的设置方式有关。 也许是 DMA 或 IRQ? 在 u-boot 中的 BeagleBone 和 TI EVM 上、tftp 可以完美运行。 这与 MCU 域上的以太网端口是不可避免的。 在这两个之间切换从来都不是一个问题,转移一个241MB 的文件需要大约15秒。

    我认为我们需要深入了解 DTS 和驱动器。

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    您能否确认并分享以下方面的详细信息?
    1.预期的 PHY 模式尤其是"RgmII-rxid"、而不是"RgmII"或其另一种变体。
    2. DP83867 PHY 是否针对特定的运行模式进行了捆绑? 如果是、您能否与我们分享
    通过读取相应的寄存器在 PHY 中配置的 TX 和 RX 延迟的详细信息?
    3.数据表中指定的地址为0x32的 PHY 寄存器8.6.32 RGMII 控制寄存器(RGMIICTL)的值为:
    https://www.ti.com/lit/ds/symlink/dp83867cr.pdf#page=90
    4.具有地址0x6f 的 PHY 寄存器8.6.38搭接配置状态寄存器2 (STRAP_STS2)的值。
    5.地址为0x86的 PHY 寄存器8.6.44 RGMII 延迟控制寄存器(RGMIIDCTL)的值。
    6.地址为0x135的 PHY 寄存器8.6.53接收状态寄存器(RXFSTS)的值。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Siddhart:

    是的、选择了模式 RgmII-rxid、并且在 phy 中设置内部 Rx 延迟。

    &main_cpsw0_port3 {
    status = "okay";
    phy-handle = <&main_cpsw0_phy0>;
    phy-mode = "rgmii-rxid";
    mac-address = [00 00 00 00 00 00];
    phys = <&main_phy_gmii_sel 3>;
    };

    main_cpsw0_phy0: ethernet-phy@0 {
    reg = <0>;
    ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
    ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
    ti,min-output-impedance;
    };

    寄存器0x32:

    => mii write 0 d 1f
    => mii write 0 e 32
    => mii write 0 d 401f
    => mii read 0 e
    00D1

    寄存器0x6F:

    => mii write 0 d 1f
    => mii write 0 e 6f
    => mii write 0 d 401f
    => mii read 0 e
    0100

    寄存器0x86:

    => mii write 0 d 1f
    => mii write 0 e 86
    => mii write 0 d 401f
    => mii read 0 e
    0007

    寄存器0x135:

    => mii write 0 d 1f
    => mii write 0 e 135
    => mii write 0 d 401f
    => mii read 0 e
    0000

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    寄存器0x6f 的值为0x0100、表示位4:6的值对应于:
    Strap 配置_RGMII_CLK_SKUK_TX 为0。
    根据"表8-7. RGZ RGMII 发送时钟偏差详细信息"、如果位4:6全为0、则它指示
    RGMII TX 时钟延迟设置为2.0ns。
    同样、寄存器的位0:2为0、对应于以下值:
    Strap 配置_RGMII_CLK_SKUK_RX
    按"表8-8"列出。 RGZ RGMII 接收时钟偏差详细信息"表示 RGMII RX 时钟偏差设置为2.0ns。

    也许 PHY 的自举设置应该是固定的、以便与 RGMII-RXID 模式匹配。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    我想你在做点什么! 我将寄存器0x32更改为0xd3 (Rx 和 TX 上的时钟延迟)并获得了明显更好的行为。 1Mbyte 文件的一次传输没有超时、以24.4Mbyte/s 的速度执行。

    然后、我将寄存器0x86设置为0x77 (TX 和 Rx 上延迟2ns)、并且 tftp 通信完全失败。

    然后、我尝试将寄存器0x6f 设置为0x0140 (2ns Rx 偏斜、0ns TX 偏斜)、但该设置不会影响。 是否需要在硬件中捆绑它?

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    寄存器0x6F 反映了自举配置的状态、这就是写入它不起作用的原因。
    正如您所提到的、PHY 需要捆绑在硬件中。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    我已要求硬件团队更改束带。

    令人奇怪的是、BeagleBone Strap 配置为 TX:[000](2ns 偏差):

    但 GESI 扩展板的数据表显示 TX:0ns、RX:2ns:

    由于所连接的不同域(MCU、Main)、是否存在不同的偏斜?

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    不应因域而存在差异。 此外、我建议保持自举配置与
    然后配置 GESI 扩展板、因为该扩展板与您所需的配置相匹配。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    修改,但没有明显的影响。 仍超时。

    寄存器0x6F 现在读取为0x0140。

    但是、将0xd3写入寄存器0x32 会 获得与上述相同的改进。 可以进一步调整吗? 我们的设置包含一个主板和一个 CPU 板、通过板对板连接器互连、因此存在硬件差异。 但是、GESI 板在通往 CPU SOM 的路上有两个板对板连接器、因此我怀疑此处的原因是什么。

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    将0xd3写入0x32在您的设置中有效的原因是
    使用的模式不是"RgmII-rxid"、而是 RgmII-id"、其中 PHY
    TX 和 RX 延迟、具体方法是
    0xD1到0xd3 (位1被置位、表示 RGMII 发送
    时钟相对于发送数据进行偏移)。

    RgmII-rxid:PHY 增加 RX 延迟、MAC 不应增加 RX 延迟。
    RGMII-id:PHY 同时增加了 RX 延迟和 TX 延迟、MAC 不应添加任何延迟。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    是的、我知道这相当于 DTS 中设置 MODE="RGMII-id"。 问题是、它为什么会产生影响。

    当 MODE ="RGMII-id"且寄存器0x86设置为0x27 (0.75ns TX 延迟和2ns Rx 延迟)时、似乎我最终拥有稳定的通信。 我需要进一步调查这是否是有效的选项。

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    更新:在启用硬件模块后、我得出结论:在 DTS 中设置以下内容适用于 DP83867:

    &main_cpsw0_port3 {
        status = "okay";
        phy-handle = <&main_cpsw0_phy0>;
        phy-mode = "rgmii-id";
        mac-address = [00 00 00 00 00 00];
        phys = <&main_phy_gmii_sel 3>;
    };

    &main_cpsw0_mdio {
        status = "okay";
        reset-gpios = <&main_gpio0 8 GPIO_ACTIVE_LOW
            &main_gpio0 9 GPIO_ACTIVE_LOW
            &main_gpio0 10 GPIO_ACTIVE_LOW>;
        reset-delay-us = <20>;

        main_cpsw0_phy0: ethernet-phy@0 {
            reg = <0>;
            ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>;
            ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>;
            ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
            ti,min-output-impedance;
        };
    感谢您的帮助!

    我非常想继续对 DP83822-PHY 进行故障排除。 我们可以这么做吗?

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我真的想继续对 DP83822-phys 进行故障排除。 我们可以这样做吗?

    当然可以。 您能否通过 LAN 电缆为任一 DP83822 PHY 共享以下寄存器的值?
    数据表链接:
    www.ti.com/.../dp83822i.pdf
    0x0010 PHY 状态寄存器(PHYSTS)
    0x0011 PHY 专用控制寄存器(PHYSCR)  
    3. 0x0014错误载波检测计数器寄存器
    4. 0x0015接收错误计数寄存器(RECR)
    5. 0x0017 RMII 和状态寄存器(RCSR)
    6. 0x0019 PHY 控制寄存器(PHYCR)

    尝试通过 DP83822 PHY 对应的接口对 PC 执行 ping 操作后、请分享上述寄存器的值。
    已知 ping 会失败、但在 ping 失败后检查寄存器会有所帮助。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    似乎在某处存在着一个重大问题。 一旦我尝试执行 ping 操作、以下 MII 或 MDIO 读取操作会因硬复位而失败。

    Hit any key to stop autoboot: 0
    => mii read 4 0
    3100
    => ping 10.142.0.139
    k3-navss-ringacc ringacc@3c000000: Ring Accelerator probed rings:1024, gp-rings[440,150] sci-dev-id:211
    k3-navss-ringacc ringacc@3c000000: dma-ring-reset-quirk: disabled
    am65_cpsw_nuss_port ethernet@c000000port@3: K3 CPSW: rflow_id_base: 16
    ethernet@c000000port@3 Waiting for PHY auto negotiation to complete......... TIMEOUT !
    am65_cpsw_nuss_port ethernet@c000000port@3: phy_startup failed
    am65_cpsw_nuss_port ethernet@c000000port@3: am65_cpsw_start end error
    am65_cpsw_nuss_port ethernet@c000000port@4: K3 CPSW: rflow_id_base: 16
    ethernet@c000000port@4 Waiting for PHY auto negotiation to complete......... TIMEOUT !
    am65_cpsw_nuss_port ethernet@c000000port@4: phy_startup failed
    am65_cpsw_nuss_port ethernet@c000000port@4: am65_cpsw_start end error
    am65_cpsw_nuss_port ethernet@c000000port@1: K3 CPSW: rflow_id_base: 16
    ethernet@c000000port@1 Waiting for PHY auto negotiation to complete......... TIMEOUT !
    am65_cpsw_nuss_port ethernet@c000000port@1: phy_startup failed
    am65_cpsw_nuss_port ethernet@c000000port@1: am65_cpsw_start end error
    ping failed; host 10.142.0.139 is not alive
    => mii read 4 0x0010
    "Error" handler, esr 0xbf000000
    elr: 0000000080863310 lr : 00000000808286a4 (reloc)
    elr: 00000000fff31310 lr : 00000000ffef66a4
    x0 : 0000000000000000 x1 : 0000000000000004
    x2 : 00000000ffffffff x3 : 0000000000000010
    x4 : 00000000fff312e8 x5 : 00000000fdf05240
    x6 : 00000000fff9ccfd x7 : 00000000fdf05210
    x8 : 0000000000000000 x9 : 0000000000000008
    x10: 0000000000000010 x11: 0000000000000004
    x12: 0000000000000000 x13: 0000000000000200
    x14: 00000000fde923b0 x15: 0000000000000000
    x16: 00000000ffee72c0 x17: 0000000000000000
    x18: 00000000fdeaddb0 x19: 00000000fde92116
    x20: 0000000000000004 x21: 0000000000000010
    x22: 0000000000000004 x23: 0000000000000010
    x24: 0000000000000004 x25: 00000000fffa5442
    x26: 00000000fffa5429 x27: 00000000fffe2000
    x28: 0000000000000010 x29: 00000000fde92010

    Code: 2a0303ea 910003fd f94000e0 b9400400 (d5033fbf)
    Resetting CPU ...

    resetting ...

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    如果是这种情况、您能否在不执行 ping 的情况下共享同一组寄存器的值?

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    当然、

    以下是 PHY 4的寄存器值:

    => mii read 4 0x10
    1002
    => mii read 4 0x11
    0108
    => mii read 4 0x14
    0000
    => mii read 4 0x15
    0000
    => mii read 4 0x17
    0241
    => mii read 4 0x19
    0004

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    寄存器0x10中的位12被置位、表示检测到反极性。
    在寄存器0x11中、位12和13为0、表示 PHY 的正常工作模式。
    寄存器0x17中的位11和12为0、表示启用 RGMII TX 时钟移位、而禁用 RGMII RX 时钟移位。 此外、位9被置位表示 RGMII 模式被启用。

    物理连接是100Base-FX 还是100Base-TX?
    根据连接类型、反向极性可能会导致问题。

    此外、在新启动时、您是否能够将0x001E 电缆诊断控制寄存器(CDCR)的位15设置为
    并在设置第1位后报告同一寄存器的值、这表示诊断测试已完成?

    您也可以尝试设置0x0019 PHY 控制寄存器(PHYCR)的位15和14、然后查看它是否有帮助。
    对于位15、您可能必须相应地修改自举。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    连接为100Base-TX。

    电缆测试返回失败:

    => mii read 4 0x1e
    0102
    => mii write 4 0x1e 0x8102
    => mii read 4 0x1e
    0103

    设置寄存器0x19的第15和14位:

    => mii read 4 0x19
    0004
    => mii write 4 0x19 0xc003
    => mii read 4 0x19
    C004

    仍然没有链路。

    更新:当另一条电缆连接到另一个交换机时、电缆测试成功:

    => mii write 4 0x1e 0x8000
    => mii read 4 0x1e
    0102

    寄存器:

    => mii read 4 0x10
    0002
    => mii read 4 0x11
    0108
    => mii read 4 0x14
    0000
    => mii read 4 0x15
    0000
    => mii read 4 0x17
    0241
    => mii read 4 0x19
    8004

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    对于电缆测试成功的新电缆、寄存器0x10中的位12为0 =检测到正确的极性。
    由于极性已固定、电缆测试似乎成功。 您是否使用新电缆测试了对 PC 的 Ping 操作?
    请在连接新电缆的情况下测试 ping 您的 PC 而不修改任何寄存器。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    是的、我尝试了 Ping 操作、但仍然失败。 这是预期行为、因为我没有链路符号、无论是在 LED 上还是在寄存器中:

    => mii dump 4 1
    1. (7849) -- PHY status register --
    (8000:0000) 1.15 = 0 100BASE-T4 able
    (4000:4000) 1.14 = 1 100BASE-X full duplex able
    (2000:2000) 1.13 = 1 100BASE-X half duplex able
    (1000:1000) 1.12 = 1 10 Mbps full duplex able
    (0800:0800) 1.11 = 1 10 Mbps half duplex able
    (0400:0000) 1.10 = 0 100BASE-T2 full duplex able
    (0200:0000) 1. 9 = 0 100BASE-T2 half duplex able
    (0100:0000) 1. 8 = 0 extended status
    (0080:0000) 1. 7 = 0 (reserved)
    (0040:0040) 1. 6 = 1 MF preamble suppression
    (0020:0000) 1. 5 = 0 A/N complete
    (0010:0000) 1. 4 = 0 remote fault
    (0008:0008) 1. 3 = 1 A/N able
    (0004:0000) 1. 2 = 0 link status
    (0002:0000) 1. 1 = 0 jabber detect
    (0001:0001) 1. 0 = 1 extended capabilities


    => setenv ipaddr 192.168.0.10; setenv netmask 255.255.255.0; setenv serverip 192.168.0.1; setenv gatewayip 192.168.0.1
    => ping 192.168.0.1
    k3-navss-ringacc ringacc@3c000000: Ring Accelerator probed rings:1024, gp-rings[440,150] sci-dev-id:211
    k3-navss-ringacc ringacc@3c000000: dma-ring-reset-quirk: disabled
    am65_cpsw_nuss_port ethernet@c000000port@3: K3 CPSW: rflow_id_base: 16
    ethernet@c000000port@3 Waiting for PHY auto negotiation to complete......... TIMEOUT !
    am65_cpsw_nuss_port ethernet@c000000port@3: phy_startup failed
    am65_cpsw_nuss_port ethernet@c000000port@3: am65_cpsw_start end error
    am65_cpsw_nuss_port ethernet@c000000port@4: K3 CPSW: rflow_id_base: 16
    ethernet@c000000port@4 Waiting for PHY auto negotiation to complete......... TIMEOUT !
    am65_cpsw_nuss_port ethernet@c000000port@4: phy_startup failed
    am65_cpsw_nuss_port ethernet@c000000port@4: am65_cpsw_start end error
    am65_cpsw_nuss_port ethernet@c000000port@1: K3 CPSW: rflow_id_base: 16
    ethernet@c000000port@1 Waiting for PHY auto negotiation to complete......... TIMEOUT !
    am65_cpsw_nuss_port ethernet@c000000port@1: phy_startup failed
    am65_cpsw_nuss_port ethernet@c000000port@1: am65_cpsw_start end error
    ping failed; host 192.168.0.1 is not alive

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    您是否可以尝试设置0x001F PHY 复位控制寄存器(PHYRCR)的第15位
    并检查是否设置了链路状态位且检测到链路?

    此外、您能否分享为每个表选择的准确自举配置的详细信息:
    表8-10. 4级搭接引脚
    表8-11. 运行模式
    表8-13. MAC 接口配置
    数据表第49页提供了上述表格:
    https://www.ti.com/lit/ds/symlink/dp83822i.pdf#page=49

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    这些都是关键:

    COL:模式1
    RX_D0:模式1
    RX_D1:模式4
    RX_D2:模式1
    RX_D3:模式1
    LED_0:模式4
    LED_1:模式1
    CRS:模式2
    RX_ER:模式2
    RX_DV:模式1

    因此、FX_EN=0、AN_EN=1、AN_1=1、AN_0=1

    从这些信息中、我认为我们要广播 10BASE-Te、半双工/全双工和100BASE-TX、半双工/全双工。

    并且 RGMII_EN=1、RMII_EN=0、XI_50=0

    这意味着 MAC 接口配置= RGMII、25MHz 参考时钟(是的、我们有25MHz 晶体)。

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

    感谢您的评分 您能否确认自举电阻和电压比是否遵循中的建议:
    表8-8. 建议4级搭接电阻比
    表8-9. 4级设置电压比

    未检测到链路很奇怪、这可能与自举配置最终处于不一致状态有关。
    如果可能、请测量电路板上的自举引脚以确保电压指示正确的状态(0 / 1)。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    电阻值对应于数据表中的值。

    如何测量这些值? 测量三角波? 这些电压是否仅短暂有效?

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Bo,

     测量 RH 和 RL 组合生成的电压就足够了、
    确保这些值处于中所述的每个模式的指定范围内
    表8-9. 4级设置电压比、位于数据表中。

    编辑 :为了说明,对于所选的 VDDIO ,请确保电压生成的电压
    分压器电路处于表中指定的 Vmin 和 Vmax 范围内。

    此致、
    Siddharth。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    我尝试测量这些、但它们都为0V! 我需要从硬件团队获得一些帮助。

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Siddhart,

    更多信息:

    当我将端口强制设置为10 MB 时、我得到链路 LED 指示灯上显示活动状态、并且寄存器0x0001中的链路状态= 1。

    我们可以看到主板(使用 PHY)和 CPU 板(使用 SoC)的不同组合之间有很多随机性。

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    您是否可以读取/转储以下 RGMII 状态寄存器。
    RGMII1_STATUS_REG (0x0C000030h)
    RGMII3_STATUS_REG (0x0C000038h)
    RGMII4_STATUS_REG (0x0C00003Ch)

    此外、在器件上运行的 ENET_CTRL 寄存器  
    ENET1_CTRL (00104044h)
    ENET3_CTRL (0010404Ch)
    ENET4_CTRL (00104050h)

    您能否确认、晶振是否连接到 PHY XI 且 XO 是否为25MHz?
    此外、转储 PHY 基本寄存器 BMCR、BMSR、ANAR、ANLPAR、ANER 和 和控制寄存器。

    此致、
    苏德黑尔

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    更新了。

    我在使用我们的 Yocto 构建系统时犯了一个巨大的错误。 当我为 u-boot 运行构建时、tiboot3.bin 和 sysfw.itb 文件不会更新。 我的重建命令如下所示(asp3是我们的机器类型):

    $MACHINE=asp3 bitbake 虚拟/引导加载程序

    要获取 tiboot3.bin 和 sysfw.it的最新版本、您需要运行:

    $MACHINE=asp3-k3r5 bitbake 虚拟/引导加载程序

    并将其组装到最终部署文件夹中:

    $ machine=asp3位烘烤核心映像-最小

    现在我在所有三个端口上都有正常工作的链路和自动协商功能、但无法对100Mbit 端口执行 ping 和 tftp 操作。

    DTS 现在看起来是这样的。 我不确定如何配置 DP83822:s。

    &main_cpsw0 {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&main_cpsw0_mdio_pins_default>,
                <&rgmii3_pins_default>,
                <&rgmii4_pins_default>,
                <&rgmii1_pins_default>;
    };

    &main_cpsw0_port3 {
        status = "okay";
        phy-handle = <&main_cpsw0_phy0>;
        phy-mode = "rgmii-id";
        mac-address = [00 00 00 00 00 00];
        phys = <&main_phy_gmii_sel 3>;
    };

    &main_cpsw0_port4 {
        status = "okay";
        phy-handle = <&main_cpsw0_phy4>;
        phy-mode = "rgmii-id";
        mac-address = [00 00 00 00 00 00];
        phys = <&main_phy_gmii_sel 4>;
    };

    &main_cpsw0_port1 {
        status = "okay";
        phy-handle = <&main_cpsw0_phy5>;
        phy-mode = "rgmii-id";
        mac-address = [00 00 00 00 00 00];
        phys = <&main_phy_gmii_sel 1>;
    };

    &main_cpsw0_mdio {
        status = "okay";
        reset-gpios = <&main_gpio0 8 GPIO_ACTIVE_LOW
            &main_gpio0 9 GPIO_ACTIVE_LOW
            &main_gpio0 10 GPIO_ACTIVE_LOW>;
        reset-delay-us = <20>;

        main_cpsw0_phy0: ethernet-phy@0 {
            reg = <0>;
            ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>;
            ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>;
            ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
            ti,min-output-impedance;
        };

        main_cpsw0_phy4: ethernet-phy@4 {
            reg = <4>;
            compatible = "ti,dp83822", "ethernet-phy-ieee802.3-c22";
            rx-internal-delay-ps = <3500>;
            tx-internal-delay-ps = <3500>;
        };

        main_cpsw0_phy5: ethernet-phy@5 {
            reg = <5>;
            compatible = "ti,dp83822", "ethernet-phy-ieee802.3-c22";
            rx-internal-delay-ps = <3500>;
            tx-internal-delay-ps = <3500>;
        };
    };
    此致、
    /波
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Sudheer,

    为了回答您的一些问题、您需要以下 SoC 寄存器:

    => md 0x0C000030 1
    0c000030: 00000003 ....
    => md 0x0C000038 1
    0c000038: 00000003 ....
    => md 0x0C00003c 1
    0c00003c: 00000003 ....
    => md 0x00104044 1
    00104044: 00000012 ....
    => md 0x0010404c 1
    0010404c: 00000012 ....
    => md 0x00104050 1
    00104050: 00000012 ....

    "不报告全双工"难道不是有点奇怪吗?

    是的、我们在所有三个 PHY 上都使用了25MHz 晶体。

    此致、

    /波

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    一些更多信息。

    对于 PHY@4 (DP83822之一):

    寄存器0x467为0xC14F
    寄存器0x468为0x0000

    我想这意味着:

    RX_D1 -模式4
    RX_D0 -模式1
    COL -模式1
    RX_ER -模式2
    CRS -模式2
    RX_DV -模式1
    LED_0 -模式4
    RX_D2 -模式1
    RX_D3 -模式1

    这反过来意味着:

    FX_EN = 0
    PHY_AD0 = 0
    AN_1 = 1
    PHY_AD1 = 0
    EEE_EN = 0
    PHY_AD2 = 1
    FLD_EN = 0
    PHY_AD3 = 0
    AN_EN = 1
    PHY_AD4 = 0
    AN_0 = 1
    LED_SPEED = 1
    LED_CFG = 0
    RGMII_EN = 1
    AMDIX_EN = 0
    XI_50 = 0
    RMII_EN = 0

    每一条带似乎都是他们想要的。 链路建立/断开仍不稳定、且从未观察到流量。

    此致、

    /波