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.

[参考译文] AM6546:PRU-ICSSG EMAC MAC 地址重新配置

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1183996/am6546-pru-icssg-emac-mac-address-re-configuration

器件型号:AM6546

您好!

我正在为运行 EMAC 固件的 AM654x SR2.0 PRU-ICSSG 使用以太网设备驱动程序。  需要能够在运行时( 在接口启动后)更改与设备关联的单播 MAC 地址。

对于较旧版本的 EMAC 固件(例如02.02.08.02)、这是可能的;该接口将继续正常运行、并将接收定向到其"新"单播 MAC 地址的帧。

在 EMAC 固件(02.02.09.07)的当前版本中、此版本不再正常工作;在 MII_G_RT MAC0/1寄存器中设置新的 MAC 地址并过滤 DA0/1寄存器后、该接口不再接收定向到其单播地址的以太网帧。  我可以看到 MII_G_RT 接收计数器明显递增、其中包括单播帧、但 PRU/UDMA 不会向驱动器发送单播帧。

据我所见、我们的驱动程序中的代码与 Linux 驱动程序中的代码一致。  但是、Linux 驱动程序似乎不支持"动态" MAC 地址重新配置-除非我缺少某些内容。

您是否 会解释在操作过程中成功更改单播 MAC 地址所需的确切步骤序列、即不停止并重新启动 PRU 上运行的 EMAC 固件。

谢谢、

Ian

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

    您好 Ian、

    根据您的描述、似乎您已经开发了定制的 EMAC 驱动程序。 是这样吗? 您是否尝试执行通用以太网以外的操作? 我们是否应该了解有关您的软件的任何其他信息?

    我正在向 Linux 开发人员检查我们的 Linux 驱动程序是否支持即时 MAC 地址重新配置。

    此致、

    Nick

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

    您好、Nick、

    此 驱动程序专为商业实时操作系统编写、旨在支持通用以太网。  对于以太网驱动程序、我们不会尝试执行任何我认为异常的操作。

    谢谢、

    Ian

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

    您好 Ian、

    我还没有听说过 Linux 开发人员。

    您是否了解过 AM64x MCU+ SDK 中的 AM64x ENET-LLD 驱动程序? AM65x 和 AM64x 中的 PRU_ICSSG 非常相似、因此它们实际上使用相同的 Linux 驱动程序和 PRU 固件。 这意味着 AM64x 驱动程序也是一个很好的模板、供您查看。

    看起来 MCU+ SDK 中的 FreeRTOS 驱动程序允许使用  enetAppUtils_allocmac()设置 MAC,如下所述: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_04_00_17/exports/docs/api_guide_am64x/enet_integration_guide_top.html

    此致、

    Nick

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

    您好、Nick、

    感谢您的回复。  我将介绍您提到的 AM64x 驱动程序。

    由于此操作适用于早期的 EMAC 固件、而现在不适用于当前的 EMAC 固件、我想知道当 MAC 地址更改时是否需要通知固件。  我看到最近发布的固件的 git 提交注释提到 IET 的变化(散布式快速流量?) MAC 验证、这表明固件可能必须对为接口配置的 MAC 地址有一定的了解。  您能否调查在02.08.02和02.09.07版本之间对 EMAC 固件进行了哪些 MAC 地址更改、并解释这对主机驱动程序有何影响?

    Ian

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

    Nick、

    另一个可能相关的观察结果是:如果我停止并重新启动 PRU EMAC 固件(02.09.07)、该接口将不再接收任何入站帧、无论是多播还是单播。  此序列与 PRU EMAC 固件02.08.02相同-重新启动固件后、接口接收帧。

    我们也需要解决这个问题。  请告诉我、与早期固件相比、当前 EMAC 固件是否具有与关断和重新启动相关的不同要求。  例如、这可能包括 ICSSG 存储器初始化或 ICSSG 硬件中的其他状态信息。

    谢谢、

    Ian

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

    您好 Ian、

    设定支持期望

    我们正在达到我在论坛上所能支持的范围。 我可以回答有关 TI 软件的特性支持和功能的问题、但我不能支持定制软件的开发。 因此、我将以合理的方式提供帮助、但我没有资源帮助您完全逆向工程我们的软件、以便您编写自己的软件。

    在 Linux 中更改 MAC 地址

    从 Linux 方面来说、PRU 以太网驱动程序支持在 Linux 运行时更改 MAC 地址。 但是、我们似乎不支持在 PRU 固件运行时更改 MAC 地址。 PRU 暂停、MAC 地址更改、然后重新启动 PRU。

    设置新 MAC 地址的 Linux 软件最近没有改变、因此我希望无论使用哪个版本的 PRU EMAC 固件、该过程都能正常工作。

    STEPS
    
    ip link set dev <Device> down
    ip link set dev <Device> address <New mac address>
    ip link set dev <Device> up 
    
    EXAMPLE
    
    root@am65xx-evm:/opt/ltp# ip link set dev eth6 down
    [87121.060623] icssg-prueth icssg2-eth eth6: Link is Down
    [87121.068784] remoteproc remoteproc18: stopped remote processor b20c000.txpru
    [87121.075840] remoteproc remoteproc17: stopped remote processor b206000.rtu
    [87121.082653] remoteproc remoteproc16: stopped remote processor b238000.pru
    [87121.091983] net eth6: stopped
    root@am65xx-evm:/opt/ltp# ip link set dev eth6 down address 80:e3:75:88:e4:fa
    root@am65xx-evm:/opt/ltp# ip link set dev eth6 up  
    [87138.753790] remoteproc remoteproc16: powering up b238000.pru
    [87138.759771] remoteproc remoteproc16: Booting fw image ti-pruss/am65x-sr2-pru1-prueth-fw.elf, size 37540
    [87138.769266] remoteproc remoteproc16: unsupported resource 5
    [87138.774915] remoteproc remoteproc16: remote processor b238000.pru is now up
    [87138.781929] remoteproc remoteproc17: powering up b206000.rtu
    [87138.787799] remoteproc remoteproc17: Booting fw image ti-pruss/am65x-sr2-rtu1-prueth-fw.elf, size 30088
    [87138.797240] remoteproc remoteproc17: remote processor b206000.rtu is now up
    [87138.804245] remoteproc remoteproc18: powering up b20c000.txpru
    [87138.810259] remoteproc remoteproc18: Booting fw image ti-pruss/am65x-sr2-txpru1-prueth-fw.elf, size 35264
    [87138.819889] remoteproc remoteproc18: remote processor b20c000.txpru is now up
    [87138.828806] net eth6: started
    root@am65xx-evm:/opt/ltp# [87141.899318] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready
    [87141.905679] icssg-prueth icssg2-eth eth6: Link is Up - 1Gbps/Full - flow control off
    ifconfig eth6
    eth6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
            inet 172.24.145.218  netmask 255.255.254.0  broadcast 172.24.145.255
            inet6 fe80::82e3:75ff:fe88:e4fa  prefixlen 64  scopeid 0x20<link>
            ether 80:e3:75:88:e4:fa  txqueuelen 1000  (Ethernet)
            RX packets 1142506  bytes 138293256 (131.8 MiB)
            RX errors 0  dropped 252038  overruns 0  frame 0
            TX packets 8713  bytes 1052821 (1.0 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    

    打开和关闭 PRU 以太网  

    至少在 Linux 驱动程序方面、我们已经进行了大量更改、甚至从 SDK 8.2更改为 SDK 8.5 (请记住、AM64x 和 AM65x PRU 以太网共享相同的驱动程序和固件、因此最近的 AM64x Linux SDK 8.5更新也适用于 AM65x)。 其中一些更改会影响驱动程序中的设置和拆卸功能。 例如 https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/log/drivers/net/ethernet/ti/icssg_prueth.c?h=ti-linux-5.10.y

    如果最新固件使用基于旧版 Linux 驱动程序的软件运行、我不确定最新固件的行为是什么。

    此致、

    Nick

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

    Nick、

    感谢您的消息和其他信息。

    感谢您不能就如何为您直接支持的操作系统开发驱动程序向我们提供建议。

    但是、正如我确信您所理解的那样、在编写器件驱动程序时、一个先决条件是驱动程序必须与之配合使用的硬件和软件接口的足够技术定义。  从我的角度来看、问题在于、据我所知、PRU EMAC 固件提供的接口(存储器使用、命令集等)没有公共定义。  此外、AM654x TRM 不提供有关硬件多个方面(MIIG、地址分类器等)的全面信息。  为 TI 直接支持的操作系统之外的操作系统开发驱动程序的唯一实际方法似乎是对 Linux 或 RTOS 驱动程序进行反向工程、正如您所承认的。   如果 TI 无法提供有关硬件和固件的全面文档、也无法回答有关硬件和固件的特定技术问题、并且  未准备好帮助对您的驱动器进行逆向工程、  TI 客户如何解决此类问题?  (这不是一个口头问题。)

    Ian

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

    您好 Ian、

    第一:阐明 Linux 驱动程序模板  

    如上所述、Linux 驱动程序不支持在 PRU 内核运行时更改 MAC 地址的用例。 支持的用例是关闭 PRU 内核、更改 MAC 地址、然后重新启动 PRU 内核

    第二:请求获取有关与 PRU 固件连接的更多信息

    问得好。 通常、如果客户需要开发定制固件或堆栈、我们建议客户联系关注第三方 PRU 工业通信的公司。 如果需要、我可以提供一些推荐。

    一致认为、PRU EMAC 固件的标准接口定义会有所帮助。 我将您的主题重新分配给 PRU 固件团队的一名成员、以讨论您要求更清晰地定义输入/输出/系统要求以及固件版本之间的更改的请求。

    如果他们在几个工作日内没有回复、请对该主题执行 Ping 操作。

    第三:MCU+(即 FreeRTOS)驱动程序是否有不同的 FeatureSet?  

    上面链接的文档中、我不清楚 FreeRTOS 驱动程序是否能够在 PRU 内核运行时更改 MAC 地址。 固件团队成员也应该能够就该问题发表意见。

    此致、

    Nick

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

    您好、Nick、

    首先,感谢你的支持;感谢你的建设性意见。

    我一侧的进一步实验确认两种故障模式(MAC 地址重新配置和停止/重新启动)都与 MII_G_RT 地址分类器配置相关。

    学习 Linux 驱动程序后,根本不清楚应该如何配置地址分类器。  如果您的 EMAC 固件团队同事能够澄清这一点、那将会有所帮助。  例如、考虑 icssg_prueth.c 中的以下代码序列

    static int emac_ndo_open(struct net_device *ndev)
    {
    ...

        /* set h/w MAC as user might have re-configured */
        ether_addr_copy(emac->mac_addr, ndev->dev_addr);

        icssg_class_set_mac_addr(prueth->miig_rt, slice, emac->mac_addr);
        if (!emac->is_sr1)
            icssg_ft1_set_mac_addr(prueth->miig_rt, slice, emac->mac_addr);

        icssg_class_default(prueth->miig_rt, slice, 0, emac->is_sr1);

    ...

    icssg_classifier.c 中

    static void rx_class_ft1_set_da(struct regmap *miig_rt, int slice,
    int n, const u8 *addr)
    {
        u32 offset;

        offset = FT1_N_REG(slice, n, FT1_DA0);
        regmap_write(miig_rt, offset, addr_to_da0(addr));
        offset = FT1_N_REG(slice, n, FT1_DA1);
        regmap_write(miig_rt, offset, addr_to_da1(addr));
    }

    (笑声)

    /* required for SR2 for SAV check */
    void icssg_ft1_set_mac_addr(struct regmap *miig_rt, int slice, u8 *mac_addr)
    {
        u8 mask_addr[] = { 0, 0, 0, 0, 0, 0, };

        rx_class_ft1_set_start_len(miig_rt, slice, 0, 6);
        rx_class_ft1_set_da(miig_rt, slice, 0, mac_addr);
        rx_class_ft1_set_da_mask(miig_rt, slice, 0, mask_addr);
        rx_class_ft1_cfg_set_type(miig_rt, slice, 0, FT1_CFG_TYPE_EQ);
    }

    (笑声)

    /* disable all RX traffic */
    void icssg_class_disable(struct regmap *miig_rt, int slice)
    {

    (笑声)

        /* FT1 Disabled */

        for (n = 0; n < ICSSG_NUM_FT1_SLOTS; n++) {
            u8 addr[] = { 0, 0, 0, 0, 0, 0, };

            rx_class_ft1_cfg_set_type(miig_rt, slice, n,
                                      FT1_CFG_TYPE_DISABLED);
            rx_class_ft1_set_da(miig_rt, slice, n, addr);
            rx_class_ft1_set_da_mask(miig_rt, slice, n, addr);
        }

        /* clear CFG2 */
        regmap_write(miig_rt, offs[slice].rx_class_cfg2, 0);
    }

    void icssg_class_default(struct regmap *miig_rt, int slice, bool allmulti,
    bool is_sr1)
    {
    (笑声)

    /* defaults */
    icssg_class_disable(miig_rt, slice);

    (笑声)

    }

    在此代码序列中,emac_ndo_open似乎从调用配置 icssg_ft1_set_mac_addr FT1插槽0以匹配接口的单播 MAC 地址,但随后的调用树emac_ndo_open->->icssg_class_defaulticssg_class_disable 将取消该配置并禁用 FT1插槽0。  在这种情况下、为什么 MAC 地址首先通过调用编程到 FT1插槽0icssg_ft1_set_mac_addr中?

    我介绍了该代码序列的一部分、以说明为什么将 Linux (或其他)驱动程序用作参考并不能很好地替代正确的文档、而且完全删除 FT1配置似乎使我正在使用的驱动程序按预期运行。  我想先了解一下原因、然后再简单地接受它作为"修复"。

    目前我的心理模型是 MII_G_RT 硬件负责过滤具有单播目标地址但与 MAC0和 MAC1寄存器中配置的值不匹配的入站帧(对于相关片)。  但是、固件似乎将 FT1配置用于其他目的、而我无法通过读取 Linux 驱动程序来解决这些问题、尤其是考虑到上述不一致性-可能包括源地址验证?  大致正确吗?

      清楚地说明 v02.09.07 EMAC 固件希望如何配置地址分类器、包括启动和停止固件以及发出端口泛洪命令所需的事件序列、将会非常有帮助。

    谢谢您的期待。

    Ian

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

    从今天的通话中复制问题:

    1) 1)地址分类器的工作方式
    2) 2) PRU 固件的配置方式
    3) 3)关于如何设置地址分类器的分步指南

    谢谢、

    Nick

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

    经过进一步的实验、我认为我发现并修复了这两个问题:

    1:重新配置接口 MAC 地址后无法接收单播帧

    2:停止并重新启动接口后无法接收任何帧

    (1)的根本原因似乎与 FT1配置有关。  如前所述、Linux 驱动程序似乎会对 FT1插槽0 DA0/1进行编程 、以匹配 接口的已配置单播地址、然后立即将该配置归零并禁用。  在我的案例中、只需在整个已解决问题(1)中禁用 FT1插槽0。  这似乎是   Linux 驱动程序中的缺陷、或者至少是误导性/冗余代码序列。

    (2)的根本原因似乎与地址分类器门配置有关。   在关闭期间、Linux 驱动程序调用 icssg_class_disable、其中包括以下序列:

    (笑声)

        for (n = 0; n < ICSSG_NUM_CLASSIFIERS; n++) {
    (笑声)

            /* configure gate */
            offset = RX_CLASS_GATES_N_REG(slice, n);
            regmap_read(miig_rt, offset, &data);
            /* clear class_raw so we go through filters */
            data &= ~RX_CLASS_GATES_RAW_MASK;
            /* set allow and phase mask */
            data |= RX_CLASS_GATES_ALLOW_MASK | RX_CLASS_GATES_PHASE_MASK;
            regmap_write(miig_rt, offset, data);
        }

    (笑声)

    但是,这似乎不能正确地重置分类器门。  通过实验和阅读 TRM、我认为代码应该如下所示:

    (笑声)

        for (n = 0; n < ICSSG_NUM_CLASSIFIERS; n++) {
    (笑声)

            /* configure gate */
            offset = RX_CLASS_GATES_N_REG(slice, n);
            regmap_read(miig_rt, offset, &data);
            /* set all masks */
            data |= RX_CLASS_GATES_RAW_MASK | RX_CLASS_GATES_ALLOW_MASK | RX_CLASS_GATES_PHASE_MASK;
            regmap_write(miig_rt, offset, data);
        }

    (笑声)

    启动期间、驱动程序应清除例程 icssg_class_default 中的 RX_class_gates_raW_mask 位、修改后如下:

    (笑声)

        /* Setup Classifier */
        for (n = 0; n < classifiers_in_use; n++) {
            /* match on Broadcast or MAC_PRU address */
            data = RX_CLASS_FT_BC | RX_CLASS_FT_DA_P;

            /* multicast? */
            if (allmulti)
                data |= RX_CLASS_FT_MC;

            rx_class_set_or(miig_rt, slice, n, data);

            /* set CFG1 for OR_OR_AND for classifier */
            rx_class_sel_set_type(miig_rt, slice, n,
                                  RX_CLASS_SEL_TYPE_OR_OR_AND);


            /* configure gate */
            u32 const offset = RX_CLASS_GATES_N_REG(slice, n);
            regmap_read(miig_rt, offset, &data);
            /* clear class_raw so we go through filters */
            data &= ~RX_CLASS_GATES_RAW_MASK;
            regmap_write(miig_rt, offset, data);
        }

    (笑声)

    将这些更改整合到我正在使用的驱动程序中已解决了与停止和重新启动接口相关的问题。

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

    您好 Ian、

    感谢您的回复! 我将与 Linux 开发人员分享您的观察结果、看看这些结果是否看起来也像他希望对我们的驱动程序进行的更改。

    您是否希望我们在该主题上提供任何其他反馈?

    此致、

    Nick

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

    谢谢 Nick。  从 您的 Linux 开发人员那里获得一些反馈会很有帮助、尤其是在我误解或我的更改在某种程度上是有害的情况下。  这也可以帮助将来可能阅读该主题的其他人。  之后、我认为该螺纹可以闭合。