[参考译文] [TDA4 J721E SDK7.2] SOC 引导阶段在 R 内核固件加载和运行期间卡住。

您好、Li、

只要我们确保在 mcu3_1之前首先加载 mxu3_0、我就不认为加载有任何问题。 此外、在加载固件时大小不应更合适。  

您能否提供有关悬挂位置的更多信息？ 您能否使用 CCS 连接到挂起内核并查看其卡在何处？

此致、

Brijesh

如果引导过程挂起、mcu3-0在没有 CCS 信息的情况下无法正常运行、只能捕获一些 Linux 固件上载 dmesg 日志。

何利、您好！

您能否共享 mcu3_0和 mcu3_1固件的大小信息？ 我想在视觉应用中、我们为每个 mcu3_0/mcu3_1预留了大约15MB 的空间。  您的固件大小是否超过15MB？  

此外、您在 dmesg 中使用了哪些错误？ 请您分享这些信息吗？  

此致、

Brijesh

您好，专家：

下面是开始错误日志：

我们可以看到启动过程在该位置被阻止。

您好！

我真的怀疑启动与固件的大小有关。 您是否意味着、如果 mcu3_0和 mcu3_1固件的大小不同、则您看不到此问题？  

您能否使用 rproc 命令从 uboot 提示符加载这些固件、并查看它们是否正确加载？

此致、

Brijesh

你(们)好。

我的意思是 mcu3-0的大小大于 mcu3-1固件、引导过程将会卡住。此外、如果我们 在 uboot.prompt 中加载这些固件、这将很好。

尊敬的 Brijesh 和 He：

   我想我们有一个名称为 MCU3_0和 MCU3_1的加载序列、允许先加载3_0。 但是、如果3_0的大小远远大于3_1、那么完成3_0的整个过程将需要更多的时间、而不是3_1。  

  因此、我们建议使用 信标或类似的机制来提供帮助。

  请帮助评论这家 Brijesh、谢谢。

BR

Sikai

您好！

是的、mcu3_0固件 需要先加载、因此如果您可以通过某种方式保护加载该固件、那就好了。  

此致、

Brijesh

我们如何保护加载此固件？ 内核中的加载过程 是并行的。

您好、

您 要加载的 mcu3_0固件的大小是多少？ 您还确切地看到了错误吗？  

如果 uboot 能够正确加载映像、那么您在 Linux 内核引导时是否遇到问题？  

此致、

Brijesh

你(们)好。  

mcu3_0的大小几乎为4Mib.

2.当 Linux 内核引导时，我们看不到内核中任何明显的错误日志，R 内核中可能有错误(在 mcu3-0引导期间)

您好、

但是 、如何知道 mcu3_0加载/引导失败？ 您是否使用 CCS 连接到 mcu3_0并检查内核的状态？ 或者 IPC 在 mcu3_0上不工作？

此致、

Brijesh

您好！

  上周，我们试图重现此问题，但没有成功。我们将尝试 复制此问题，如果您有任何其他信息，请注意我们。

您好，如果有关于此问题的任何更新、请告知我们。 非常感谢。

或者给我们提供解决方案： 如何 在 Linux 内核中实现 R core 固件的串行加载？

您好，

如果有任何与此问题相关的更新、请告知我们。 非常感谢。

或者给我们一个提到的解决方案： 如何 在 Linux 内核中实现 R 内核固件的串行加载？

是，这仍然是一个紧急问题。 我们使用 CCS 连接到 mcu3-0并检查内核的状态。

我们有一个可以复制的固件版本，复制的概率为20%、但内核日志级别为0、没有更多信息。 稍后、我们将日志级别更改为7、但无法再在同一环境中复制它...

当可以复制时、mcu3_ 0和 mcu3_ 1。 它无法正常工作、无法连接 CCS。

尊敬的 Keermy：

   在与客户交谈后、此处提供了此案例的一些详细信息：

   1. 当 MCU3_0映像大于 MCU3_1 (MCU3_0几乎是 MCU3_1的两倍)时、很容易重现"MCU 挂起"错误。 他们没有在 MCU1或 MCU2上尝试此操作、而是在 MCU3中尝试此操作。(版本1)

   然后 、他们尝试手动放大 MCU3_1的大小(添加图形)、直到现在、它才能够重现此情况。 (版本2)

   3. 为了重现此情况并找出根本原因，他们删除了模式。 但是、自从版本1以来、已经很长时间了、他们向 MCU3添加了更多应用。 现在一个是3.9MB、另一个是4.4MB。 在这种情况下，他们已经测试了1个月，没有进行复制。 (版本3)

   随着 应用的增加、MCU3_0的大小不断增加。 当大小达到阈值时、错误会重现。

   5. 要定位错误，客户应提高日志级别。 一种奇怪的现象是，当日志级别为0时，它将重现错误，而当它们将日志级别调整为7时，它将不会重现错误。

   因此、我们需要检查以下几点：

   1.您是如何添加图案的？

   2.阈值是多少？

   3.您如何更改日志级别？

   4.当错误重现时，我们是否有任何日志？ CCS 的情况如何？ 如前所述、此时您可以连接 MCU1、MCU2如何？

   5.客户将共享其 MCU3_0和 MCU3_1的二进制文件，不确定它是否可以在 EVM 板上工作。

   6.我认为此错误可能是由资源冲突引起的。 由于 MCU3_0和 MCU3_1几乎是并行加载的、如果 MCU3_0远高于 MCU3_1、则 MCU3_0将在 MCU3_1之后完全加载。 我不确定这是否会导致一些错误。

   Tian、如果我错过任何内容、请在此处添加。

BR

Sikai

您好、Sikai、

是否对标准发布的固件内存映射进行了任何修改？ 如果是、他们是否相应地修改了 Linux DTS 文件和 MPU 设置？  

此外、您能否帮助我们了解他们如何更新内存映射？ 他们是否使用 python 工具来更新存储器映射？  

我们有这样的 mcu3_0和 mcu3_1固件在 SDK 上运行正常。 那么、想知道他们的代码有什么变化吗？ 另外、更改存储器映射的原因是什么？ 我们为每个 内核分配了大约15MB 的代码/数据、该存储器是否足够？  

此外、视觉应用初始化脚本中的任何日志或 CCS 与这些内核的连接中的错误、以查看内核的卡滞位置？  

他们是否已尝试从 uboot 提示符手动加载固件并确认其工作正常？ 如果没有、我们可以尝试逐个加载固件并查看其是否正常工作吗？

此致、

Brijesh  

尊敬的 Brijesh：

  那么、您已经尝试加载 MCU3_0和 MCU3_1、它运行正常(MCU3_0大于 MCU3_1)？  将与客户核实他们在 MCU3上所做的工作。 由于它们的动态项目要求、仍然在 MCU3上添加新的应用、因此需要不时修改存储器映射。 与客户交谈后、这不应由内存不足引起。 当错误发生时、MCU3的总图像尺寸仍小于15MB。

  对于 CCS、客户告诉我、当错误发生时、CCS 无法连接。 对于 VISION_APPS 日志、他们需要将近一周的时间才能打开日志。

BR

SIKai

您好、Sikai、

在 PSDKRA 中、我们没有在 mcu3_0/1内核上运行任何内容、因此它们几乎具有相同的大小。 我们没有一个比另一个大的试验箱。  

完全正确。 由于其图像大小仍小于15MB、因此不需要更改任何存储器映射。 它仍应适合 发布的 SDK 中提供的默认存储器映射。  

如果您无法连接 mcu3_0/1、是否能够连接任何其他 R5F？ 能否检查 A72运行是否正常？  

他们可能应该在开始时连接 mcu3_0/1、并查看何时崩溃、CCS 控制台有任何日志。  

此致、

Brijesh

尊敬的 Brijesh，

当 MCU3_1和 MCU3_0异常加载时、A72也无法正常运行。 我们认为 Remoteproc 加载固件异常。当错误再次发生时、我们将提供来自视觉应用程序和固件存储器映射的日志、以找到问题。

此致、

夏天