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.

[参考译文] AM2431:支持以太网主引导和备份引导

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1423298/am2431-support-of-ethernet-primary-boot-backup-boot

器件型号:AM2431
主题中讨论的其他器件: SysConfigDP83869、LP-AM243UNIFLASH

工具与软件:

尊敬的 TI 专家:

我们正在离线讨论以太网主引导和备用引导的支持。 按照您的建议、我还在此处创建了 E2E 主题来邀请客户参与、以便我们可以保持浏览同一页面。

在最后一个电子邮件主题中、客户按照以下步骤查看以太网备份引导在其电路板上是否正常工作。

  1. 给电路板断电
  2. 将引导模式切换到 UART 主模式和以太网备用模式。
  3. 将一条以太网线缆从电路板的以太网端口连接至一个 PC 端口。
  4. 开始使用 Wireshark 监控连接到电路板的 PC 端口。
  5. 为电路板供电。

客户得到了  下面的 Wireshark 屏幕截图。

客户 非常确定  其电路板上的 MAC 地址88:0C:E0:67:D6:18用于 AM2431、因为电路板的以太网端口通过电缆直接连接到计算机的以太网端口、而计算机 MAC 完全不同。

顺便说一下、客户注意到、对于备用引导、 AM2431上电后仅发送约117秒的 BOOTP 请求。 时间有点太长了。   

如果以太网引导程序/工具准备就绪、客户将 在下一个电路板版本中将以太网更改为主引导(使用模式更改开关)。  

因此、请确保 我们正在 使用的以太网引导工具既可以用于主引导、也可以用于备份引导。

谢谢!

Kevin

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

    您好、建宇、

    我已重建 SDK、现在该 PHY 可以正确绑定到83826。

    这样很好、您可以在释放模式下构建该示例并重新进行测试。

    请确保您已按照指南中的说明在 PC 中添加了静态 ARP 条目。

    此外、您应该通过 Wireshark 监视端口并查看是否从电路板接收了任何数据包。 这将有助于以针脚指出到底不起作用的部分。

    此致、

    Nitika

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

    嗨、Nitika、

    如果内置在版本中、日志会有所不同、

    DMSC 固件版本10.0.8--v10.00.08 (Fiery Fox)
    DMSC 固件版本0xA
    DMSC ABI 修订版4.0


    [ ENETSBL ]开始以太网传输...
    启用时钟!
    EnetAppUtils_reduceCoreMacAllocation:将 CoreID:1的 MAC 地址分配从4减少到2
    打开 MAC 端口2
    EnetPhy_bindDriver:1873
    PHY 7处于活动状态
    EnetMod_ioctl:1608
    Cpsw_registerIoctlHandler:1844
    EnetPer_ioctl:1394
    Enet_ioctl:1057
    无法为端口1 --1设置 DSCP 优先级映射
    [ ENETSBL ] initQs() txFreePktInfoQ 用8个 pkts 初始化
    [ ENETSBL ] EVM MAC 地址:88:0c:e0:67:d6:2d

    [ ENETSBL ] PHY 7处于活动状态
    [ ENETSBL ]请等待 LinkUp ...

    [ 2024年12月12日02:01:34.926]
    Rx:Cpsw_handleLinkUp:1450

    [ 2024年12月12日02:01:36.927]
    RX:[ ENETSBL ]链路已完成!

    [ 2024年12月12日02:01:52.995]
    Rx:[ ENETSBL ]状态:0
    [ ENETSBL 错误] Uniflash 超时错误。
    Cpsw_handleLinkDown:1476
    禁用 ENET 的时钟:5、INSTS:0!
    闪烁失败!!
    已跳过启动!

    封装如下:

    e2e.ti.com/.../CD3E_5F00_sbl_5F00_package.zip

    请注意、 "Uniflash 超时错误。   无论是否执行 uniflash.py、都会触发"。 网络软件包是我执行 py 文件的软件包。

    建宇

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

    您好、建宇、

    如果内置在发行版中、则日志不同

    这是预期行为、在发布模式下会对 ENET 日志进行优化、这就是为什么您会看到数字来代替调试模式下出现的实际消息。

    未接收到应用映像时会出现"Uniflash timeout error"。

    SBL 按预期工作、您能告诉我您设置了什么 IP 地址吗? 以便我能够更好地理解 Wireshark 日志。

    此致、

    Nitika

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

    嗨、Nitika、

    感谢您的答复。

    客户根据您的示例设置 IP。

    本地 IP 为 192.168.0.136、MAC 00-1b-21-8a-20-11

    分配给电路板的 DHCP IP 为 192.168.0.137

    运行 SBL 之前的 MAC 地址是 88-0c-e0-67-d6-08

    运行 SBL 后的 MAC 地址是 88-0c-e0-67-d6-2d

    谢谢!

    Kevin

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

    您好!

    是否已修改系统集成设置? 我希望 EVM Mac 地址为以下2个中的任何一个:



    从 Wireshark 日志中、电路板会将链路完整数据包发送到 PC (SBL 运行后的电路板 IP 地址为192.168.0.195)、但未到达电路板。

    需要验证的事项如下:

    1.    sbl_enet.h 文件中的宏 ENET_HOST_PC_MAC_ADDRESS 应该具有主机 PC 以太网接口的 MAC 地址。

    2.在主机 PC 的以太网接口上、网关设置为192.168.0.195。

    3.添加静态 ARP 条目的 new-Netstibor 命令应包含 EVM 的 MAC 地址(SBL 运行后在 UART 终端中打印的地址)。


    您是否可以尝试运行 python 脚本一旦在终端上看到"[ ENETSBL ] Please Wait for LinkUp ..."消息、您就会看到"Received"消息。 链路数据包从电路板发出以来一直显示错误消息。

    此致、

    Nitika

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

    嗨、Nitika、

    我更新了该变量。

    1.    sbl_enet.h 文件中的宏 ENET_HOST_PC_MAC_ADDRESS 应具有主机 PC 以太网接口的 MAC 地址。[/QUOT]

    我似乎能够连接到 SBL 程序。 不过等待链路后的时间窗口有点太小了。

    [ ENETSBL ] PHY 7处于活动状态
    [ ENETSBL ]请等待 LinkUp ...

    [ 2024年12月12日02:01:34.926]
    Rx:Cpsw_handleLinkUp:1450

    [ 2024年12月12日02:01:36.927]
    Rx:[ ENETSBL ]链路已完成!

    因此、我一看到 LinkUp 就成功运行了一次脚本。 控制台将返回以下命令、

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    D:\CD3E-AP\Ethernet\Ethernet_boot>python enet_uniflash.py --cfg=default_sbl_enet_app.cfg
    [LOG] Parsing config file ...
    [LOG] Ensure that sbl_qspi_enet has already been sent over before running this script.
    [LOG] Found 1 command(s) !!!
    [LOG] Creating socket
    Starting Linkup ...
    Received.
    ('192.168.0.195', 5001)
    [LINKUP] (SUCCESS) EVM Linked up. Starting transfer ...
    Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 15%|▏| 8872/61139 [00:00<00:00, 593566.Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 17%|▏| 10344/61139 [00:00<00:00, 431962Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 19%|▏| 11816/61139 [00:00<00:00, 455279Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 22%|▏| 13288/61139 [00:00<00:00, 492875Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 24%|▏| 14760/61139 [00:00<00:00, 527486Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 27%|▎| 16232/61139 [00:00<00:00, 560188Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 29%|▎| 17704/61139 [00:00<00:00, 590607Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 31%|▎| 19176/61139 [00:00<00:00, 618939Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 34%|▎| 20648/61139 [00:00<00:00, 645489Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 36%|▎| 22120/61139 [00:00<00:00, 670540Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 39%|▍| 23592/61139 [00:00<00:00, 694098Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 41%|▍| 25064/61139 [00:00<00:00, 696664Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 43%|▍| 26536/61139 [00:00<00:00, 718222Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 46%|▍| 28008/61139 [00:00<00:00, 738073Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 48%|▍| 29480/61139 [00:00<00:00, 756183Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 51%|▌| 30952/61139 [00:00<00:00, 774234Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 53%|▌| 32424/61139 [00:00<00:00, 791964Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 55%|▌| 33896/61139 [00:00<00:00, 827918Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 58%|▌| 35368/61139 [00:00<00:00, 842869Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 60%|▌| 36840/61139 [00:00<00:00, 857809Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 63%|▋| 38312/61139 [00:00<00:00, 799125Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 65%|▋| 39784/61139 [00:00<00:00, 812463Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 67%|▋| 41256/61139 [00:00<00:00, 842524Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 70%|▋| 42728/61139 [00:00<00:00, 855152Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 72%|▋| 44200/61139 [00:00<00:00, 867317Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 75%|▋| 45672/61139 [00:00<00:00, 879100Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 77%|▊| 47144/61139 [00:00<00:00, 890419Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 80%|▊| 48616/61139 [00:00<00:00, 918221Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 82%|▊| 50088/61139 [00:00<00:00, 928094Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 84%|▊| 51560/61139 [00:00<00:00, 938051Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 87%|▊| 53032/61139 [00:00<00:00, 947904Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 89%|▉| 54504/61139 [00:00<00:00, 974214Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 92%|▉| 55976/61139 [00:00<00:00, 965991Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 94%|▉| 57448/61139 [00:00<00:00, 974080Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 96%|▉| 58920/61139 [00:00<00:00, 951137Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 99%|▉| 60392/61139 [00:00<00:00, 959119Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 61146packets [00:00, 971093.84packets/s]Traceback (most recent call last):
    File "D:\CD3E-AP\Ethernet\Ethernet_boot\enet_uniflash.py", line 461, in <module>
    status, part_time = transceive(sock, partial_file, len(partial_file), args.boardIP, args.boardPort,filecfg.cfgs[index].filename, total_size)
    File "D:\CD3E-AP\Ethernet\Ethernet_boot\enet_uniflash.py", line 410, in transceive
    data, addr = sock.recvfrom(8)
    socket.timeout: timed out
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    UART 仍然返回  

    [报价 userid="622144" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1423298/am2431-support-of-ethernet-primary-boot-backup-boot/5563514 #5563514"] 2024年12月12日02:01:52.995]
    Rx:[ ENETSBL ]状态:0
    [ ENETSBL 错误] Uniflash 超时错误。
    Cpsw_handleLinkDown:1476
    禁用 ENET 的时钟:5、INSTS:0!
    闪烁失败!!
    已跳过启动![/quote]

    我认为 PC 在板超时后仍在传输数据。

    e2e.ti.com/.../CD3E_5F00_sbl_5F00_package2.zip

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

    您好、建宇、

    但是、等待链接后的时间窗口有点太小了。

    只要在电路板链接发生前不超时、您也可以先启动 python 脚本。 我们可以通过将 python 脚本下行中的值从5增加来增加超时:  

            如果 LINK_UP_TIMEOUT_COUNT == 5

    hello_world 具有一个相对较小的 appImage、我不希望该超时。 仍然可以通过增加套接字超时来重试。

    您是否可以在 enet_uniflash.py 文件-     sock.settimeout(5的此行中将值从5增加到10?)

    此致、

    Nitika

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

    嗨、Nitika、

    这次我是在 SBL 启动之前启动脚本的。 输出相同。 我使用的固件为 Hello_world 演示、大小为60KB。

    我很确定电路板在转移完成之前会打印出超时的内容。

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

    您好、建宇、

    如果在处理闪存命令时出现错误、也会显示 Uniflash 超时打印、特别是从 Bootloader_uniflashProcessFlashCommands ()函数返回错误、指示这可能是闪存问题。

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    /* Process the flash commands and return a response */
    status = Bootloader_uniflashProcessFlashCommands(&uniflashConfig, &respHeader);
    /* Exit if error or timeout; Send response to host */
    if (status != SystemP_SUCCESS)
    {
    DebugP_log("[ ENETSBL ERROR ] Uniflash timeout error.\r\n");
    done = 1U;
    status = SystemP_FAILURE;
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    您能否确认您已根据板载闪存器件的要求修改了示例。

    此致、

    Nitika

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

    嗨、Nitika、

    我已在 Bootloader_uniflashProcessFlashCommands 之后添加 STATUS = SystemP_SUCCESS、结果返回 SUCCESS。

    下周我会对 flash 问题有所了解。

    谢谢!

    建宇

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

    您好、建宇、

    感谢您提供的信息、如果您以后需要任何帮助、请告诉我。

    此致、

    Nitika

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

    您好、建宇、

    此处是否有任何有关进度的更新?

    此致、

    Nitika

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

    嗨、Nitika、

    很抱歉、本周我被分配了另一个任务。 也许我们可以关闭该主题、并在出现新问题时添加另一个主题。

    谢谢!

    建宇

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

    嗨、Nitika、

    当前的情况是、如果客户如上所述添加"STATUS = SYSTEMP_SUCCESS"、则以太网引导成功。 但是、它们仍然没有解决闪存问题。

    客户上周还尝试了另一位工程师来解决闪存问题、但未成功。

    我刚才与客户讨论了要完全结束这个主题、他们本周仍将关注这个 Flash 问题。

    当前、此闪存问题的故障日志如下所示。

    我想知道您有一些建议供客户进行调试吗?

    谢谢!

    Kevin  

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

    尊敬的 Kevin:  

    在"STATUS = SYSTEMP_SUCCESS"的情况下、以太网引导 SBL 完成后会发生变化。 您能否让客户切换到 OSPI 引导模式并检查 Hello world 应用程序是否运行?

    我不希望它能够运行、因为 uniflash 问题可能会导致 appImage 未正确刷写、但我仍然想检查一下。

    我还会邀请 Flash 专家、提供任何调试建议。

    此致、

    Nitika  

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

    尊敬的 Kevin:

    另一个问题是、客户在哪个电路板上测试此示例(AM243x-LP)或他们的定制电路板?

    此致、

    Nitika

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

    嗨、Nitika、

    感谢您的帮助。

    客户在其定制电路板上测试示例。

    稍后将更新运行"Hello World"应用的结果。

    谢谢!

    Kevin

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

    嗨、Nitika、

    客户只需仔细检查一下、在使用 "STATUS = SYSTEMP_SUCCESS" 来避免闪存问题后、结果实际上并不成功、但在下面的最后一个日志中仍会显示问题。

    在深入了解详细信息后、我们发现此故障来自以下代码行、状态为-1。

    Status = Bootloader_parseMultiCoreAppImage (bootHandle、&bootImageInfo);

    您是否认为此问题也是由于闪存实际未成功导致的?

    谢谢!

    Kevin

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

    尊敬的 Kevin:

    深入了解详细信息后、我们发现此故障来自以下代码行、状态为-1。

    Status = Bootloader_parseMultiCoreAppImage (bootHandle、&bootImageInfo);[/QUOT]

    这与我之前的怀疑相符-  Bootloader_uniflashProcessFlashCommands 函数甚至在刷写完成之前也可能失败、这就是为什么未找到适当的完整性的 appImage 以及示例失败的原因。

    接下来、我们可以  通过以下步骤检查 Bootloader_uniflashProcessFlashCommands 函数的确切位置:

    1.有一个  loop_forever () 在 main.c 文件中定义的函数。 在 main.c 中的以下行之前添加对该函数的调用:

            /*处理闪存命令并返回响应*/
            Status = Bootloader_uniflashProcessFlashCommands (&uniflashConfig、&respHeader);
    2. Re 编译并像以前一样运行以太网引导示例、执行将卡在 loop_forever 函数内。
    3. 为您的电路板启动目标配置、并将目标连接到 R5F0_0 (SBL 仅在 R50_0内核上运行)。
    4.前往 Run > Load > Load Symbols 并加载 sble_ospi_enet.release.out 初始文本文件。
    5.程序计数器位于  loop_forever ()  位置。 现在、修改变量的值  开关环路  通过调试器设为0 (进入 View > Variables 并手动将 loop 设为0)。
    6.现在,像往常一样解析文件,找到 Bootloader_uniflashProcessFlashCommands 中的 状态值是否为非零。


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

    尊敬的 Kevin:

    我正在通过该线程进行读取、我可以在某个时间提供我的输入。

    此致、

    Vaibhav

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

    尊敬的 Kevin:

    我们可以从这一点开始进行调试: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1423298/am2431-support-of-ethernet-primary-boot-backup-boot/5581232#5581232

    除了这一点,你能告诉我以下几点:

    1. QSPI 闪存器件的名称。
    2. 它以哪种模式运行? 例如:4S-4D-4D
    3. 请从应用程序 SysConfig 分享 OSPI 选项卡的屏幕截图。

    此致、

    Vaibhav

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

    尊敬的 Vaibhav:

    使用的闪存是什么  GD25Q64ESIG  1S-1S-4S 模式下。

    我发现  certLen = Bootloader_getX509CertLen (x509Header)= 0、这会导致函数出现故障状态 Bootloader_parseMultiCoreAppImage (bootHandle、BootImageInfo) ;深入探究后、我发现  x509_cert_ptr 的值 为0x1F、而不是0x30、这样可得出 certLen  = 0:

    以下是来自 SysConfig 的配置:

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

    尊敬的 Nitika 和 Vaibhav:

    我们似乎可以通过找出  x509_cert_ptr 返回值0x1F 而不是0x30来缩小这一问题的范围。

    您能帮我们建议一些线索吗?

    谢谢!

    Kevin

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [报价 userid="546457" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1423298/am2431-support-of-ethernet-primary-boot-backup-boot/5583741 #5583741"]x509_cert_ptr 返回值0x1F 而不是0x30。

    首先、我们需要查看正在闪烁的 appimage 是否正确、然后验证是否正确。

    所以、典型的 HS FS appimage 将是这样的:  

    因此、我们需要首先从存储器浏览器确认映像是否以如下方式启动:0x30 0x82、依此类推。

    您能这样做并告诉我吗?

    此致、

    Vaibhav

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

    尊敬的 Vaibhav:

    我在存储器浏览器中检查了以下3个位置、都显示0:

    0x60000000、0x60080000、0x60088000

    谢谢!

    Ellen

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

    尊敬的 Vaibhav:

    感谢您的答复。

    由于这些值均为0、这是否意味着 appimage 闪存不正确?

    谢谢!

    Kevin

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [报价 userid="481704" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1423298/am2431-support-of-ethernet-primary-boot-backup-boot/5584689 #5584689"]0x60000000、0x60080000、0x60088000[/QUOT]

    您已查看其中三个位置。

    您能否检查您的 hello world appimage 在何处闪存?

    这应该是您最终的已知偏移?

    如果这是你检查过的上述三个中的一个、并且你看到全部为0、那么有两种可能:

    1. DAC 未启用、因此您无法看到闪存内容。
    2. DAC 启用、并且 appimage 未刷写到闪存器件上。

    为了缩小此问题的范围、在查看存储器浏览器之前、您是否可以通过以下方式启用 DAC?

    您可以通过调用以下命令来执行此操作:

    int32_t OSPI_enableDacMode (OSPI_Handle handle)
    在读取 Memory Browser 并检查内容后、您可以继续禁用 DAC 模式、如下所示:
    int32_t OSPI_disableDacMode (OSPI_Handle handle)
    期待您的答复。
    此致、
    Vaibhav
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Vaivhav、

    感谢您的答复。

    这是 UART 打印的信息、偏移为0x80000、hello word appimage 应在0x60080000处刷新:

    另请注意、该函数返回-1:  

        Status = Bootloader_uniflashProcessFlashCommands (&uniflashConfig、&respHeader);

    我尝试在存储器浏览器之前启用 DAC、得到的结果是:

     

    数据似乎与 hello word appimage 不匹配。

    您的、

    Ellen

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

    您好、Ellen、

    是的、您在 DAC 启用后看到的 hello world appimage 不正确。

    为了确保通过以太网接收到的 appImage 正确无误、您是否能够在共享内存浏览器值  0x70090000 保护。

    如果这与 hello world appImage 匹配、则表示接收到的 appImage 正确并且闪烁是问题。

    此致、

    Nitika

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

    嗨、Nitika、

    这是来自0x70090000的数据、该数据是否正确?

    您的、

    Ellen

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

    您好、Ellen、

    appImage 的 MSRAM 值看起来是正确的。 因此、通过以太网接收的数据不是问题。

    您能否分享闪存的.json 文件和示例的 example.syscfg 文件、以了解在原始示例之上所有已修改的内容?

    此致、

    Nitika

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

    JSON 文件

    e2e.ti.com/.../gd25q64.json.txt

    SysConfig

    e2e.ti.com/.../6622.example.syscfg.txt

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

    嗨、Nitika、

    请查找上面由建宇上传的.json 文件和 example.syscfg。

    我还在  上面附加了 SysConfig 中的闪存配置的屏幕截图(请参阅我在2024年 DEC 25上的回复)。

    非常感谢您的帮助:)

    您的、

    Ellen

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

    您好、Ellen、

    感谢您的答复。

    我还在  上文附加了 SysConfig 中闪存配置的屏幕截图

    我已经看到这一点、但其他类似 OSPI 配置和其他闪存配置(详细配置不可见)、因此请求了 example.syscfg 文件。

    请允许我在某个时候浏览随附的文件、并执行后续步骤。

    此致、

    Vaibhav

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

    您好、Ellen、

    我已经检查了闪存器件的数据表、其中提到对于8的虚拟周期配置、时钟频率不应超过133 MHz / 120 MHz。

    此处虚拟时钟读数为8、因此应更改频率、在您的示例中、在 SysConfig 的 OSPI 部分中、频率设置为200 MHz。

    打开 OSPI 部分后、时钟频率应设置为133 MHz = 133333333、时钟分频器:4、禁用 DMA、禁用 PHY 模式。

    如果您可以看到进行上述更改后启用 DAC 模式后正确刷写了 hello world、请告知我们。

    注意:

    如果没有、那么我们可以通过将运行模式切换到1S-1S-1S、然后检查 hello world 是否正确刷写来进行健全性检查。

    此致、

    Vaibhav

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

    尊敬的 Vaibhav:

    感谢您的详细建议、下面是我的结果:

    时钟分频器:4、禁用 DMA、禁用 PHY、模式:1S-1S-4S、时钟133MHz / 120MHz:

    时钟分频器:4、禁用 DMA、禁用 PHY、模式:1S-1S-1S、时钟133MHz / 120MHz:

    0x70090000位置处的数据在以下情况下都保持一致:

    您能帮忙检查数据吗?

    非常感谢!

    您的、

    Ellen

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

    您好、Ellen、

    感谢您的答复。

    1S-1S-1S

    切换此操作模式时、是否也确保更改了 SysConfig 闪存其他设置? 或者、您只是从1S-1S-4S (早期的)中选择下拉列表1S-1S-1S?

    我要介绍的其他设置如下:

     

    仅供参考、1s-1s-4s 时看到的闪存值不正确、1s-1s-1s 时的值(hello world 似乎根本没有刷写、我们需要确认引导加载程序映像)。 您能不能检查引导加载程序映像的十六进制转储、并在1-1s-1s 模式下将其与0x60000000进行比较。

    期待您的答复。

    此致、

    Vaibhav

1 2