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.

[参考译文] AM4372:UBoot 因 BOOTP 宽广播数据中止而崩溃

Guru**** 2829655 points

Other Parts Discussed in Thread: AM4372

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1625505/am4372-uboot-crash-with-bootp-broadbast-data-abort

部件号: AM4372

你好

我正在使用 AM4372 SoC 并运行 Uboot 2016.05 commit “e646599450834807fd334dd9593112e89aee11c7"。“。 选择从网络引导选项时、我收到以下数据中止错误。

但是、使用同一 Uboot 时、从 QSPI NOR 引导是正常的。 请告诉我您可能需要哪些进一步的信息来帮助调查

 

CAuthentication passed: CERT_U-BOOT
xyzModem - CRC mode, 1(SOH)/332(STX)/0(CAN) packets, 2 retries
Loaded 339864 bytes


U-Boot 2016.05-ge646599450-MS_OCS_RM_1.1.5.1

CPU  : AM437X-HS rev 2.1
Model: MS_OCS_RM_1.1.5.1
       Watchdog enabled
I2C:   ready
DRAM:  1 GiB
PMIC:  TPS65218
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
** First descriptor is NOT a primary desc on 1:1 **
** No partition table - mmc 1 **
Using default environment

Watchdog enabled. Timeout set to 59999 ms
Net:   cpsw
Booting from network ...
cpsw Waiting for PHY auto negotiation to complete.... done
link up on port 0, speed 1000, full duplex
BOOTP broadcast 1
data abort
pc : [<bff8852a>]          lr : [<bff8949d>]
reloc pc : [<8082a52a>]    lr : [<8082b49d>]
sp : bef43480  ip : ffffffff     fp : bffd66fc
r10: 00000000  r9 : bef4ded8     r8 : bffd6244
r7 : bffeee58  r6 : 0000000e     r5 : 00000000  r4 : bffd672e
r3 : 00060101  r2 : bffd6702     r1 : bffd6702  r0 : 0000000e
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32
Resetting CPU ...

resetting ...

此致、

Sumit

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

    您好 Sumit、

    数据中止

    通常指向未对齐的存储器访问。

    您能尝试添加吗  __attribute__((packed)) 中的所有网络标头结构 Include/net.h 、它已添加到较新的 u-boot 版本中。

    该问题也会在最新的 u-boot 中得到解决。 如果需要、请尝试使用。

    此致、
    Vinu

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

    谢谢 Vinu、谢谢您对该问题的快速答复。

    通常、我们没有对上游代码的 include/net.h 区域进行任何更改。 为什么未对齐的存储器访问会发挥作用?

    此外、您是否知道除了 commit “e646599450834807fd334dd9593112e89aee11c7"之外“之外、对分支“ti-u-boot-2016.05"的“的任何进一步提交是否可以解决此问题?

    此外、正如您提到的、最新的 u-boot 已解决此问题、您能告诉我哪些更改可以解决该问题吗? 我可以检查它们并得到提示。

    此致、

    Sumit

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

    您好 Sumit、

    此外、正如您提到的最新 u-boot 已解决此问题、您能否向我指出可解决此问题的更改? 我可以检查它们并进行提示。

    请访问 https://patchwork.ozlabs.org/project/uboot/patch/20170721162842.22317-1-denis.pynkin@collabora.com/

    这不是 TI 特有的问题。  

    此外、您是否知道除提交“e646599450834807fd334dd9593112e89aee11c7"之外“之外、对分支“ti-u-boot-2016.05"的“的任何进一步提交是否解决了此问题?

    不太可能、因为我甚至在 201610.

    此致、
    Vinu

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

    感谢 Vinu 指向解决问题的提交。 我们将尝试在 Uboot2016 上将其拉回并尝试。