Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
S32K3引导加载程序和HSE - 最佳实践? 您好,NXP团队: 我们正在 S32K312 上实施一个强大的 OTA 更新架构,采用 HSE 全块 A/B 交换。 我们的目标架构是: - S32K312,2 MB PFlash 分为两个 1 MB 物理块。 - HSE AB_SWAP 通过被动块激活服务使用。 - 通过 Modbus/串口接收 OTA 数据包。 - 引导加载程序将签名映像加载到被动 PFlash 块中。 - HSE 验证被动图像/SMR。 - 引导加载程序请求 AP_SWAP。 - RESET后,新更换的银行暂时启动。 - 确认命令可使交换永久生效;否则设备将回滚。 最初我们尝试将一个全局引导加载程序放在 DFlash 中,位于两个 PFlash 存储区之外。该引导加载程序将接收 OTA,对被动 PFlash 存储进行编程,请求 HSE AP_SWAP,然后继续管理确认/回滚。 我们采用这种方法遇到了架构和运行时复杂性方面的问题: 1. HSE AB_SWAP 似乎在完整的 PFlash 块边界上进行操作,而不是在任意应用程序分区上进行操作。 2. 单个 DFlash 引导加载程序位于已交换/已验证的银行映像之外。 3. 交换后,活动的 PFlash 存储体仍然需要有效的启动/IVT/RESET 结构。 4. 当 DFlash 也参与引导加载程序运行时/记录处理时,我们遇到了执行方面的困难。 5.目前还不清楚全局 DFlash 引导加载程序是否与干净的全库 HSE AB_SWAP 生产设计兼容。 因此,我们暂时改用复制的PFlash引导加载程序模式: - 每个 1 MB PFlash 存储区包含自己的 IVT + 引导加载程序 + 应用程序。 - 引导加载程序在每个存储体的底部都有一个预留插槽。 应用程序在引导加载程序槽之后启动。 - 已签名的 OTA 镜像是一个完整的银行镜像,包含引导加载程序和应用程序。 - 在 HSE AB_SWAP 之后,新激活的银行是独立的,可以启动。 对于 HSE 全模块 A/B 更换来说,这似乎要干净得多,但我希望确认其预期/生产安全的方法。这样做并不理想,因为它在一定程度上违背了工厂引导加载程序的初衷。 问题: 1.对于 S32K312 HSE AB_SWAP,在交换后的 PFlash 存储体之外,单个全局 DFlash 驻留引导加载程序是否是一种受支持/推荐的架构? 2. 或者 HSE AB_SWAP 是否有效地要求/建议每个被交换的 PFlash 块都是可独立启动的,具有自己的 IVT/引导加载程序/RESET 路径? 3.如果可以使用 DFlash 引导加载程序,那么交换后的引导流程应该如何构建,才能仍然满足 SBAF/HSE 引导预期? 4. NXP 是否有任何参考示例展示了 DFlash 引导加载程序如何在 S32K3 上管理全块 HSE AB_SWAP? 5.对于具有回滚/确认语义的生产 OTA,重复的 PFlash 引导加载程序模型是否是更安全的预期设计? 我们已经看到,通过修改链接器脚本可以将代码和 IVT 链接到 DFlash 中(我们也尝试过),但我们的问题具体是,在使用 HSE 全块 A/B 交换和安全启动/SMR 验证时,这样做是否合适。 谢谢! Re: S32K3 bootloader and HSE - best practice ? 嗨@coratron 1.对于 S32K312 HSE AB_SWAP,在交换后的 PFlash 存储体之外,单个全局 DFlash 驻留引导加载程序是否是一种受支持/推荐的架构? 从硬件角度来看,没有任何限制。两种选择都是可行的。如果数据闪存的容量足够大,并且您不打算将其用于存储数据,则可以将引导加载程序放置在数据闪存中。如果您需要将数据闪存用于其他用途,那么在两个分区中分别保存两份引导加载程序副本是一种常见的做法。 2. 或者 HSE AB_SWAP 是否有效地要求/建议每个被交换的 PFlash 块都是可独立启动的,具有自己的 IVT/引导加载程序/RESET 路径? 不,没有这样的要求。只需在数据闪存(引导加载程序的 IVT)中具有有效的 IVT 即可。通常的做法是,RESET后总是启动引导加载程序,然后引导加载程序跳转到用户应用程序。 3. 如果可以使用 DFlash 引导加载程序,那么交换后的引导流程应该如何构建,才能仍然满足 SBAF/HSE 引导预期? SBAF 或 HSE 没有提出任何具体要求。启动引导加载程序后,它可以决定是跳转到应用程序,还是下载新应用程序,或者执行回滚等操作,然后它应该重置设备(在回滚/交换的情况下)或跳转到应用程序。 4. NXP 是否有任何参考示例展示了 DFlash 引导加载程序如何在 S32K3 上管理全块 HSE AB_SWAP? 我们没有这样的例子。 5. 对于具有回滚/确认语义的生产 OTA,复制的 PFlash 引导加载程序模型是否是更安全的预期设计? 我不认为这两种方法在安全性方面有任何绝对优势。特定架构的适用性取决于整体系统设计、网络安全要求、OTA 工作流程和回滚策略。这两个概念都可以在稳健的生产解决方案中得到实现。 问候, 卢卡斯 Re: S32K3 bootloader and HSE - best practice ? 感谢你的及时回复@lukaszadrapa 。这澄清了问题,并提供了很大的帮助——我们已经能够重新评估 DFlash 中的引导加载程序实现,并且取得了成功。 该团队已经习惯了其他供应商的文档/可访问性,发现 NXP 虽然是汽车应用领域的领导者,但与它们相比,NXP 的文档却出奇地令人困惑。 您的及时反馈弥补了这些不足,再次感谢您的帮助——非常感激。我会将您的回复标记为解决方案,并向您的团队提供以下反馈: - 如果能提供 Dflash 引导加载程序 + HSE 演示,就能节省时间(包括您的时间)。我相信这对于使用 AB_SWAP 的人来说是自然而然的设置。 - NXP 应该统一并整理文档和软件栈(长期来看) - 兼容性/版本分散,没有统一的信息来源,导致混乱。 问候
View full article
RT1064:引脚配置,用于从内部闪存启动 你好, 这可能听起来像个愚蠢/新手问题,但我无法确定必须对 BOOT_MODE1/BOOT_MODE0 和 BT_CFG[11..0] 引脚进行哪些操作才能将 RT1064 配置为从其内部闪存启动。 参考手册中的表 9.9 只列出了 3 种启动源(通过 FlexSPI 的 NOR 闪存、SD 卡和 eMMC),但没有列出内部闪存,就好像这部分内容是从 RT1060 复制粘贴过来的一样…… AN12290 提到了 FlexSPI2 内部总线到此内部闪存,但没有说明如何从上述 3 个启动源中选择它。 MIMXRT1060/1064 评估套件板硬件用户指南中的表 5 指出,只有两种启动模式可用(QSPI 或 SD 卡),并且还声称不支持 QSPI 启动(参见 2.7 段),因此 SD 卡是唯一的启动源…… 非常感谢您的帮助! i.MX RT106x Re: RT1064 : pin configuration to boot from internal flash 嗨@batmat , 如 AN12290 中所述,MIMXRT1064 只能从 FlexSPI2 启动,FlexSPI2 专用于内部 QSPI 闪存。您仍然可以通过 FlexSPI1 接口连接外部闪存,该接口可用于保存数据或其他功能,但不能用于启动。这就是为什么参考手册中的表 9.9 只列出了 3 个启动源,即通过 FlexSPI 的 NOR 闪存、SDCARD 或 eMMC;通过 FlexSPI2 的 NOR 闪存是唯一可用于启动的 FlexSPI,并且默认情况下它已经路由到板载闪存。 为了能够从内部 QSPI 闪存启动,引导设备开关 (SW7) 设置应为: SW7-1 关闭,SW7-2 关闭,SW7-3 打开,SW7-4 关闭。 BOOT_CFG1[7:4] 引脚必须设置为 0,才能选择通过 FlexSPI 的串行 或非 启动作为引导设备。同时,BOOT_CFG2[2:0]引脚也必须设置为0,以便选择内部QSPI Flash。MIMXRT1064-EVK 默认具有这些引脚设置。 BR, 埃德温。 Re: RT1064 : pin configuration to boot from internal flash 你好,埃德温, 确实有道理。我感到很困惑,因为外部闪存和内部闪存都是 QSPI 接口的,很难确定哪个是哪个。 我建议对 RT1064 的表 9.9 进行文档改进。 应该将“通过 FlexSPI 启动 NOR 闪存”改为“通过内部 FlexSPI2 启动内部 NOR 闪存”,并补充说明“RT1064 不支持通过 FlexSPI 从外部 NOR 闪存启动”。 我认为这样可以避免混淆。 再次感谢您提供的出色且及时的支持。
View full article
S32K3 bootloader and HSE - best practice ? Hi NXP team, We are implementing a robust OTA update architecture on an S32K312 using HSE full-block A/B swap. Our target architecture is: - S32K312 with 2 MB PFlash split into two 1 MB physical blocks. - HSE AB_SWAP is used via the passive-block activation service. - OTA package is received over Modbus/serial. - Bootloader stages the signed image into the passive PFlash block. - HSE verifies the passive image/SMR. - Bootloader requests AP_SWAP. - After reset, the newly swapped bank boots provisionally. - A confirm command makes the swap permanent; otherwise the device rolls back. Originally we tried to keep one global bootloader in DFlash, outside the two PFlash banks. That bootloader would receive OTA, program the passive PFlash bank, request HSE AP_SWAP, and then continue to manage confirm/rollback. We ran into architectural and runtime complexity with that approach: 1. HSE AB_SWAP appears to operate on full PFlash block boundaries, not arbitrary app partitions. 2. A single DFlash bootloader is outside the swapped/authenticated bank image. 3. The active PFlash bank still needs valid boot/IVT/reset structure after swap. 4. We had difficult execution hazards when DFlash was also involved in bootloader runtime/record handling. 5. It became unclear whether a global DFlash bootloader is compatible with a clean full-bank HSE AB_SWAP production design. We therefore moved to a duplicated PFlash bootloader mode for now: - Each 1 MB PFlash bank contains its own IVT + bootloader + application. - The bootloader has a reserved slot at the base of each bank. - The application starts after the bootloader slot. - The signed OTA image is a full bank image containing bootloader + application. - After HSE AB_SWAP, the newly active bank is self-contained and bootable. This appears much cleaner for HSE full-block A/B swap, but I would like to confirm the intended/production-safe approach. This is suboptimal as it partially defeats the purpose of a factory bootloader. Questions: 1. For S32K312 HSE AB_SWAP, is a single global DFlash-resident bootloader outside the swapped PFlash banks a supported/recommended architecture? 2. Or does HSE AB_SWAP effectively require/recommend that each swapped PFlash block be independently bootable, with its own IVT/bootloader/reset path? 3. If a DFlash bootloader is possible, how should the post-swap boot flow be structured so SBAF/HSE boot expectations are still met? 4. Are there any NXP reference examples showing a DFlash bootloader managing full-block HSE AB_SWAP on S32K3? 5. For production OTA with rollback/confirm semantics, is the duplicated PFlash bootloader model the safer intended design? We have seen that code and IVT can be linked into DFlash by modifying the linker script (and we tried that), but our question is specifically about whether that is appropriate when using HSE full-block A/B swap and secure boot/SMR verification. Thank you. Re: S32K3 bootloader and HSE - best practice ? Hi @coratron  1. For S32K312 HSE AB_SWAP, is a single global DFlash-resident bootloader outside the swapped PFlash banks a supported/recommended architecture? There are no limitations from HW point of view. Both options are possible. If the size of data flash is sufficient and you do not plan to use it for your data, the bootloader can be placed in the data flash. If you need data flash for other purposes then having two copies of the bootloader in both partitions is common practice. 2. Or does HSE AB_SWAP effectively require/recommend that each swapped PFlash block be independently bootable, with its own IVT/bootloader/reset path? No, there’s no such requirement. It is sufficient to have valid IVT only in data flash (bootloader’s IVT). Common practice is that bootloader is always started after reset and then then the bootloader jumps to user application. 3. If a DFlash bootloader is possible, how should the post-swap boot flow be structured so SBAF/HSE boot expectations are still met? There are no specific requirements coming from SBAF or HSE. Once bootloader is started, it can decide if it should jump to application or if it should download new application or if it should do rollback, etc. and then it should reset the device (in case of rollback/swap) or jump to the application. 4. Are there any NXP reference examples showing a DFlash bootloader managing full-block HSE AB_SWAP on S32K3? We don’t have such example. 5. For production OTA with rollback/confirm semantics, is the duplicated PFlash bootloader model the safer intended design? I would not classify either approach as universally safer. The suitability of a particular architecture depends on the overall system design, security requirements, OTA workflow and rollback strategy. Both concepts can be implemented in a robust production solution. Regards, Lukas Re: S32K3 bootloader and HSE - best practice ? Thanks for your prompt reply @lukaszadrapa . That clarifies and helps substantially - we have been able to re-evaluate our bootloader implementation in DFlash and were successful. The team is used to the documentation / accessibility from other vendors and finds NXP to be surprisingly confusing compared to them despite being a leader in automotive applications. Your prompt feedback makes up for these gaps, so thanks again for your help - much appreciated. I will mark your reply as the solution, with the following feedback directed at your team: - A Dflash bootloader + HSE demo would have been great to save time (yours included). I am sure this is the natural setup for people that use AB_SWAP. - NXP should unify and get the documentation and software stack organised (long term) - compatibility / versions are scattered, there is no one source of information which leads to confusion. Regards 
View full article
S32K3ブートローダーとHSE - ベストプラクティスとは? こんにちは、NXPチームの皆様、 当社は、HSEのフルブロックA/Bスワップを使用して、S32K312上で堅牢なOTAアップデートアーキテクチャを実装しています。 我々の目標とするアーキテクチャは以下のとおりです。 - S32K312は、2MBのPFlashを2つの1MBの物理ブロックに分割して搭載しています。 - HSE AB_SWAPは、パッシブブロックのアクティベーションサービスを介して使用されます。 - OTAパッケージはModbus/シリアル経由で受信されます。 - ブートローダーは署名付きイメージをパッシブPFlashブロックに段階化します。 - HSEは受動イメージ/SMRを検証します。 - ブートローダーがAP_SWAPを要求します。 リセット後、新しく交換されたバンクは暫定的に起動します。 確認コマンドを実行すると、スワップが永続的に適用されます。そうでない場合は、デバイスはロールバックされます。 当初は、2つのPFlashバンクとは別に、DFlashに1つのグローバルブートローダーを配置しようと試みました。そのブートローダーはOTAを受信し、パッシブPFlashバンクをプログラムし、HSE AP_SWAPを要求し、その後、確認/ロールバックの管理を継続します。 そのアプローチでは、アーキテクチャと実行時の複雑さという問題に直面しました。 1. HSE AB_SWAP は、任意のアプリケーション パーティションではなく、PFlash ブロックの境界全体で動作するようです。 2. 単一のDFlashブートローダーは、スワップ/認証済みバンクイメージの外にあります。 3. アクティブなPFlashバンクは、スワップ後も有効なブート/IVT/リセット構造を必要とします。 4. DFlashがブートローダーの実行時/レコード処理にも関与していた場合、実行時に重大なハザードが発生しました。 5.グローバルDFlashブートローダーがクリーンなフルバンクのHSE AB_SWAP生産設計と互換性があるかどうかは不明瞭になりました。 そのため、当面はPFlashブートローダーを複製したモードに移行しました。 - 各1MBのPFlashバンクには独自のIVT + ブートローダー+アプリケーションが含まれています。 - ブートローダーは、各バンクの底部に予約済みのスロットを持っています。 - アプリケーションはブートローダースロットの後に起動します。 - 署名付きOTAイメージは、ブートローダー+アプリケーションを含むフルバンクイメージです。 - HSE AB_SWAP実行後、新たにアクティブになったバンクは自己完結型でブート可能です。 HSEのフルブロックA/Bスワップには、この方法の方がはるかにクリーンに見えますが、意図された、かつ生産上安全な方法であることを確認したいと思います。これは、工場出荷時のブートローダーの目的を部分的に損なうため、最適とは言えません。 質問: 1.S32K312 HSE AB_SWAPの場合、スワップされたPFlashバンクの外に単一のグローバルDFlash常駐ブートローダーを配置するアーキテクチャは、サポート/推奨されていますか? 2. あるいは、HSE AB_SWAPは、交換された各PFlashブロックが、独自のIVT/ブートローダー/リセットパスを持ち、独立してブート可能であることを実質的に要求/推奨しているのでしょうか? 3.もしDFlashブートローダーが可能なら、SBAF/HSEブートの期待に応えられるように、スワップ後のブートフローはどのように構成すべきでしょうか? 4. S32K3上でDFlashブートローダーがフルブロックHSE AB_SWAPを管理することを示したNXPの参考例はありますか? 5.ロールバックや確認セマンティクスを持つ本番OTAの場合、複製されたPFlashブートローダーモデルの方が安全な設計でしょうか? コードとIVTをリンカースクリプトを改変することでDFlashにリンクできるという話は見ており(私たちも試しました)、しかし私たちの質問は、HSEのフルブロックA/Bスワップやセキュアブート/SMR検証を使う場合にそれが適切かどうかについてです。 よろしくお願いします。 Re: S32K3 bootloader and HSE - best practice ? こんにちは、 @coratron さん。 1.S32K312 HSE AB_SWAPの場合、スワップされたPFlashバンクの外に単一のグローバルDFlash常駐ブートローダーを配置するアーキテクチャは、サポート/推奨されていますか? ハードウェアの観点からは、何の制限もありません。どちらの選択肢も可能である。データフラッシュのサイズが十分で、データに使う予定がない場合は、ブートローダーをデータフラッシュに配置できます。データフラッシュを他の用途で使用する必要がある場合は、両方のパーティションにブートローダーのコピーを2つずつ用意するのが一般的な方法です。 2. あるいは、HSE AB_SWAPは、交換された各PFlashブロックが、独自のIVT/ブートローダー/リセットパスを持ち、独立してブート可能であることを実質的に要求/推奨しているのでしょうか? いいえ、そのような要件はありません。データフラッシュ(ブートローダーのIVT)に有効なIVTがあれば十分です。一般的な慣習としては、リセット後にブートローダーが起動され、その後ブートローダーがユーザーアプリケーションにジャンプします。 3. もしDFlashブートローダーが可能なら、SBAF/HSEのブート期待を満たすように、スワップ後のブートフローはどのように構成すべきか? SBAFまたはHSEからの具体的な要件はありません。ブートローダーが起動すると、アプリケーションにジャンプするか、新しいアプリケーションをダウンロードするか、ロールバックを行うかなどを判断し、その後(ロールバックやスワップの場合に)デバイスをリセットするか、アプリケーションにジャンプします。 4. S32K3上でフルブロックHSE AB_SWAPを管理するDFlashブートローダーを示すNXPのリファレンスサンプルはありますか? そのような例はありません。 5. ロールバック/確認セマンティクスを持つ本番OTAの場合、複製されたPFlashブートローダーモデルは意図された設計の方が安全なのでしょうか? どちらの方法も、普遍的に安全だと断言することはできません。特定のアーキテクチャの適性は、全体のシステム設計、セキュリティ要件、OTAワークフロー、ロールバック戦略に依存します。両概念は堅牢な本番環境で実装可能です。 よろしくお願いいたします。 ルーカス Re: S32K3 bootloader and HSE - best practice ? @lukaszadrapa さん、迅速なご返信ありがとうございます。これにより状況が明確になり、大いに役立ちました。DFlashにおけるブートローダーの実装を再評価することができ、成功しました。 チームは他のベンダーのドキュメントやアクセス性に慣れており、オートモーティブ アプリケーションのリーダーであるにもかかわらず、NXPは意外にも分かりにくいと感じています。 あなたの迅速なフィードバックがこれらの穴を補っています。改めてご助言ありがとうございます。とても感謝しています。あなたの回答を解決策としてマークし、あなたのチームに以下のフィードバックを送ります。 - DflashブートローダーとHSEのデモがあれば、(あなたの時間も含めて)時間を節約できたでしょう。これはAB_SWAPを使用する人にとって自然な設定だと確信しています。 - NXPはドキュメントやソフトウェアスタックを統合し、長期的に整理すべきです。互換性やバージョンが散在しており、情報源が一つにないため混乱が生じます。 よろしくお願いいたします
View full article
MPC5644A 核心测试 我正在尝试对 MPC5644A 芯片组进行核心测试。 我目前使用的环境是 Eclipse 和 Wind River。 我下载了制造商的库 e200Zx_ICST_RTMC_3.0.0,其中包含几个汇编源 (.s) 文件。 其中,vle 编译成功。 但是 book_e 和 spe 编译失败。 编译过程中,各种汇编指令(如 bc、bcl、bclr、xoris、bclrl 和 bcctrl)出现错误。我打开了 book_e 和 spe 汇编文件的属性,并将 -tPPCE200Z4NEG:simple 添加到 C/C++ 版本 --> 设置 --> Diab 汇编器 --> 其他 --> 其他选项和标志中,并成功完成了编译。然而,在调试过程中,我到达了 `fsl_self_test_icst.c` 中的 `Fsl_call_test_execution_icst` 之前,而这部分实际上执行的是核心测试。如果我继续进行下一步,就会陷入无限循环。 通过 Eclipse 的反汇编检查,我发现当我单步进入地址 0x51518(紧接在 `SPE_ICST_int_logical_test` 开始之后)时,它会立即跳转到 0x3f2b90(一个空白空间)。 我应该怎么办?我不知道从哪里开始。 Re: MPC5644A core test 你好, SCST 仅支持 MPC56xx 系列中的以下设备: MPC560xP MPC564xB-C 由于 MPC5644A 和 MPC564xB 共享相同的 e200z4 CPU 内核,因此 SCST 库中以 CPU 为中心的部分可以进行调整。但是,所有整合方面都必须进行审查: 异常向量地址 存储器映射 时钟初始化 外围依赖性 链接器脚本假设 实际的 CPU 测试算法应该具有很强的可移植性,因为它们针对的是相同的 e200z4 架构。 NXP 没有为旧款 MPC5644A 设备提供官方的 SCST 库。然而,由于 MPC5644A 与 MPC564xB 系列使用相同的 e200z4 内核,因此在审查特定设备的集成细节后,或许可以采用 MPC564xB 解决方案中以 CPU 为中心的自检例程。或者,可以使用 MCU 的内置功能安全机制(ECC、CRC、看门狗、MPU、异常处理)开发自定义启动诊断实现,以满足项目特定的功能安全要求。 我应该怎么办?我不知道从哪里开始。 如果代码在 0x51518 处进入 SPE_ICST_int_logical_test(),然后立即跳转到 0x3F2B90(看起来像是空内存),我首先怀疑的不是 CPU 故障,而是链接器/库集成问题。 对于 SCST 库而言,这通常意味着以下情况之一: 1. 函数指针或分支表未正确链接 2. 缺少库对象 3. 内存模型错误/虚拟环境不匹配 4. 为另一台设备构建的 SCST 库 5. MMU/TLB 翻译问题 顺祝商祺! Peter
View full article
Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. The compilation logs are attached below. Please advise on how to resolve this issue. DEBUG: Executing python function extend_recipe_sysroot NOTE: Direct dependencies are ['/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rpm/rpm_4.19.1.1.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rsync/rsync_3.2.7.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/unifdef/unifdef_2.12.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-extended/xz/xz_5.4.7.bb:do_populate_sysroot'] NOTE: Installed into sysroot: ['cmake-native', 'openssl-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'dwarfsrcfiles-native', 'elfutils-native', 'file-native', 'libedit-native', 'lua-native', 'make-native', 'perl-native', 'python3-native', 'rpm-native', 'bzip2-native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libtirpc-native', 'lzlib-native', 'zstd-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libunistring-native', 'nettle-native'] NOTE: Skipping as already exists in sysroot: ['gettext-minimal-native', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'zlib-native', 'bison-native', 'flex-native', 'gnu-config-native', 'patch-native', 'pkgconfig-native', 'pseudo-native', 'rsync-native', 'unifdef-native', 'xz-native', 'acl-native', 'attr-native', 'popt-native', 'sqlite3-native'] DEBUG: sed -e 's:^[^/]*/:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native/:g' /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/openssl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/ncurses-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/elfutils-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/lua-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/perl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/python3-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/rpm-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/curl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/gmp-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgcrypt-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgpg-error-native/fixmepath | xargs sed -i -e 's:FIXMESTAGINGDIRTARGET:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot:g; s:FIXMESTAGINGDIRHOST:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native:g' -e 's:FIXME_PSEUDO_SYSROOT:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/pseudo-native:g' -e 's:FIXME_HOSTTOOLS_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/hosttools:g' -e 's:FIXME_PKGDATA_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/pkgdata/s32g399avmcu2.1asc:g' -e 's:FIXME_PSEUDO_LOCALSTATEDIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/pseudo/:g' -e 's:FIXME_LOGFIFO:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/temp/fifo.4087696:g' DEBUG: Python function extend_recipe_sysroot finished DEBUG: Executing python function sstate_task_prefunc DEBUG: Python function sstate_task_prefunc finished DEBUG: Executing python function do_package DEBUG: Executing python function package_setup_pkgv DEBUG: Python function package_setup_pkgv finished DEBUG: Executing python function package_convert_pr_autoinc DEBUG: Python function package_convert_pr_autoinc finished DEBUG: Executing python function package_prepare_pkgdata NOTE: Installed into pkgdata-sysroot: [] DEBUG: Python function package_prepare_pkgdata finished DEBUG: Executing python function perform_packagecopy ERROR: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.10/subprocess.py', lineno: 421, function: check_output 0417: else: 0418: empty = b'' 0419: kwargs['input'] = empty 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): File: '/usr/lib/python3.10/subprocess.py', lineno: 526, function: run 0522: # We don't call process.wait() as .__exit__ does that for us. 0523: raise 0524: retcode = process.poll() 0525: if check and retcode: *** 0526: raise CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/image -p -S . | tar -xf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/ocxl.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/pvpanic.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/xilinx_sdfec.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/cxl.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/fastrpc.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/uacce: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/uacce/uacce.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Okay, thank you very much. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi, @zhijie  Thanks for your reply. I have reproduced the issue, it does not related with current BSP, but from the building system changes I am looking into it and will reply you later once any progress made? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Thanks, @zhijie  Could you also help to share the result of uname -a? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @zhijie  Thanks for your post. May I know the details of your building environment? It is the first time you built the BSP46? or previously it is correct? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi  @zhijie  I am also facing the same issue, if you ressolved it kindly let us know. ERROR: zlib-1.3.1-r0 do_package: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/smurugan8/LWT/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.12/subprocess.py', lineno: 466, function: check_output 0462: else: 0463: empty = b'' 0464: kwargs['input'] = empty 0465: *** 0466: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0467: **kwargs).stdout 0468: 0469: 0470:class CompletedProcess(object): File: '/usr/lib/python3.12/subprocess.py', lineno: 571, function: run 0567: # We don't call process.wait() as .__exit__ does that for us. 0568: raise 0569: retcode = process.poll() 0570: if check and retcode: *** 0571: raise CalledProcessError(retcode, process.args, 0572: output=stdout, stderr=stderr) 0573: return CompletedProcess(process.args, retcode, stdout, stderr) 0574: 0575: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/image -p -S . | tar -xf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address tar: ./usr/lib/libz.so.1: Cannot create symlink to ‘libz.so.1.3.1’: No such file or directory Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello chenyin:     Is there any update on this build failure issue?     Wait for good news, much appreciated. BR Zhijie Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello Chenyin     The problem is resolved, Thanks! BR Zhijie Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @zhijie  Thanks for your reply By checking the logs of the building failure, it seems related with the program changes of the building machine. Would you mind trying the following way? On your ubuntu PC, use the command "sudo apt install tar=1.34+dfsg-1build3" to make a change of tar version used, the clean the BSP and rebuild it again   BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. I was having the same issue and I've figured out the issue is with the tar version build 4 and the downgrading did resolve the error, but the actual issue is the tar and pseudo using openat2() instead of openat for the system call. The poky has already given the patch as far as I've seen, does the NXP has any update on it? I'm currently using LLDP 6.1.22 SDK on the LX2160ARDB_REV2 Board and the same error appears when i try to build rcw using bitbake.  If NXP has upated the pseudo_git.bb to use openat2() instead of openat() as per tar's latest build 4., it will be useful for us as we can update tar to the latest version. Attached the logs for your reference. The bug from yocto-project link is added here  https://bugzilla.yoctoproject.org/show_bug.cgi?id=16117 Regards, PVSN Subhash Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @pvsnsubhash  Thanks for your reply, after my workaround fix for the issue, I had also noticed the pseudo issue and then reported it to our internal team. The corresponding team would review the issue and arrange the schedule for the formal fix. Thanks again for your valuable inputs. BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @Sanjiv_Mns  Thanks for your reply. 1. OK, I understand you are currently using i.MX instead of S32G products 2. You may have a try with the following method:  "sudo apt install tar=1.34+dfsg-1build3" and then clean/rebuild with your Yocto setup 3. If still issues, I suggest waiting for the feedback from your original link, I believe my colleague would help you to solve it based on you i.MX setup BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi @chenyin_h  Have you found anything that could help resolve it? This issue is currently blocking our progress, We would really appreciate any update or guidance you can provide. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. The issue is because of the tar package in linux getting upgraded to build4 from build3. Downgrade the tar package using the below steps and hold the apt upgrade for that package for now and proceed with your compilation. wget http://archive.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1build3_amd64.deb sudo dpkg -i tar_1.34+dfsg-1build3_amd64.deb  sudo apt-mark hold tar After the above steps, you can proceed with your compilation and no such errors will be seen. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi @chenyin_h   I am still facing the same issue. I have already raised a query on the forum, but I haven't received any response yet.Link I am attaching the log below for your reference. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @Sanjiv_Mns  Thanks for your reply. May I know if you met the same issue? would you mind creating a new post with your details logs, we would directly support it ASAP. BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. I solved this issue in NXP iMX BSP 6.6.36-2.1.0 and 6.12.49-2.2.0 bumping the pseudo_git.bb to 1.9.5 and updating the older-glibc-symbols patch... both copied from the corresponding wrynose recipe (6.18.20-2.0.0). git diff... diff --git a/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch b/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch index c453b5f735..f42b32b8d9 100644 --- a/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch +++ b/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch @@ -28,10 +28,10 @@ diff --git a/Makefile.in b/Makefile.in @@ -120,7 +120,7 @@ $(PSEUDODB): pseudodb.o $(SHOBJS) $(DBOBJS) pseudo_ipc.o | $(BIN) libpseudo: $(LIBPSEUDO) - $(LIBPSEUDO): $(WRAPOBJS) pseudo_client.o pseudo_ipc.o $(SHOBJS) | $(LIB) + $(LIBPSEUDO): $(WRAPOBJS) pseudo_client.o pseudo_client_scanf.o pseudo_ipc.o $(SHOBJS) | $(LIB) - $(CC) $(CFLAGS) $(CFLAGS_PSEUDO) -shared -o $(LIBPSEUDO) \ + $(CC) $(CFLAGS) -Lprebuilt/$(shell uname -m)-linux/lib/ $(CFLAGS_PSEUDO) -shared -o $(LIBPSEUDO) \ - pseudo_client.o pseudo_ipc.o \ + pseudo_client.o pseudo_client_scanf.o pseudo_ipc.o \ $(WRAPOBJS) $(SHOBJS) $(LDFLAGS) $(CLIENT_LDFLAGS) diff --git a/pseudo_wrappers.c b/pseudo_wrappers.c diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb b/meta/recipes-devtools/pseudo/pseudo_git.bb index 5f32b3777a..c491f0c97f 100644 --- a/meta/recipes-devtools/pseudo/pseudo_git.bb +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb @@ -1,8 +1,6 @@ require pseudo.inc SRC_URI = "git://git.yoctoproject.org/pseudo;branch=master;protocol=https \ - file://0001-configure-Prune-PIE-flags.patch \ - file://glibc238.patch \ file://fallback-passwd \ file://fallback-group \ " @@ -14,9 +12,9 @@@ SRC_URI:append:class-nativesdk = " file://older-glibc-symbols.patch" SRC_URI[prebuilt.sha256sum] = "ed9f456856e9d86359f169f46a70ad7be4190d6040282b84c8d97b99072485aa" -SRCREV = "e11ae91da7d0711f5e33ea9dfbf1875dde3c1734" +SRCREV = "0bad85523ff71f1a84cea5fdf72e7f560c4aeed4" S = "${WORKDIR}/git" -PV = "1.9.0+git" +PV = "1.9.5+git" # largefile and 64bit time_t support adds these macros via compiler flags globally # remove them for pseudo since pseudo intercepts some of the functions which will be
View full article
使用 BSP46 和 linux-libc-headers 6.6 时会出现编译失败。 使用 BSP46 和 linux-libc-headers 6.6 时会出现编译失败。 编译日志附在下方。请告知如何解决此问题。 调试:正在执行 Python 函数 extend_recipe_sysroot 注意:直接依赖项为 ['/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/参考发行版、系统开发套件。/meta/配方-devtools/pseudo/pseudo_git.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rpm/rpm_4.19.1.1.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rsync/rsync_3.2.7.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/unifdef/unifdef_2.12.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-extended/xz/xz_5.4.7.bb:do_populate_sysroot'] 注意:已安装到系统根目录:['cmake-native', 'openssl-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'dwarfsrcfiles-native', 'elfutils-native', 'file-native', 'libedit-native', 'lua-native', 'make-native', 'perl-native', 'python3-native', 'rpm-native', 'bzip2-native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libtirpc-native', 'lzlib-native', 'zstd-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libunistring-native', 'nettle-native'] 注意:由于 sysroot 中已存在以下项,因此跳过:['gettext-minimal-native', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'zlib-native', 'bison-native', 'flex-native', 'gnu-config-native', 'patch-native', 'pkgconfig-native', 'pseudo-native', 'rsync-native', 'unifdef-native', 'xz-native', 'acl-native', 'attr-native', 'popt-native', 'sqlite3-native'] 调试:sed -e 's:^[^/]*/:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/配方-sysroot-native/:g'/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/openssl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/ncurses-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/elfutils-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/lua-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/perl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/python3-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/rpm-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/curl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/gmp-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgcrypt-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgpg-error-native/fixmepath| xargs sed -i -e 's:FIXMESTAGINGDIRTARGET:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/配方-sysroot:g;s:FIXMESTAGINGDIRHOST:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native:g'-e 's:FIXME_PSEUDO_SYSROOT:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/pseudo-native:g'-e 's:FIXME_HOSTTOOLS_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/hosttools:g'-e 's:FIXME_PKGDATA_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/pkgdata/s32g399avmcu2.1asc:g'-e 's:FIXME_PSEUDO_LOCALSTATEDIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/pseudo/:g'-e 's:FIXME_LOGFIFO:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/temp/fifo.4087696:g' 调试:Python 函数 extend_recipe_sysroot 已完成 调试:正在执行 Python 函数 sstate_task_prefunc 调试:Python 函数 sstate_task_prefunc 已完成 调试:正在执行 Python 函数 do_package 调试:正在执行 Python 函数 package_setup_pkgv 调试:Python 函数 package_setup_pkgv 已完成 调试:正在执行 Python 函数 package_convert_pr_autoinc 调试:Python 函数 package_convert_pr_autoinc 已完成 调试:正在执行 Python 函数 package_prepare_pkgdata 注意:已安装到 pkgdata-sysroot:[] 调试:Python 函数 package_prepare_pkgdata 已完成 调试:正在执行 Python 函数 perform_packagecopy 错误:执行 Python 函数时出错,exec_func_python() 自动生成: 导致此异常/失败的 Python 调用堆栈跟踪如下: 文件:'exec_func_python() autogenerated',行号:2,函数: 0001: *** 0002:perform_代码包,软件包copy(d) 0003: 文件:'/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/参考发行版、系统开发套件。/meta/classes-global/代码包,软件包.bbclass',行号:363,函数:perform_代码包,软件包copy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_代码包,软件包copy[cleandirs] = "${PKGD} " 0362:perform_代码包,软件包copy[dirs] = "${PKGD} " *** 0363: 0364:python populate_代码包,软件包s() { 0365: oe.代码包,软件包.populate_代码包,软件包s(d) 0366:} 0367:populate_packages[dirs] = " ${D} " 文件:'/usr/lib/python3.10/subprocess.py'行号:421,函数:check_output 0417:否则: 0418:空 = b'' 0419: kwargs['input'] = 空 0420: *** 0421: 返回 run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): 文件:'/usr/lib/python3.10/subprocess.py'lineno: 526, function: run 0522: # 我们不调用 process.wait()作为。 __exit__它能帮我们做到这一点。 0523:提高 0524: retcode = process.poll() 0525:如果检查并返回代码: *** 0526: 引发 CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: 返回 CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: 异常:subprocess.CalledProcessError:命令“tar --exclude=./sysroot-only”-cf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/image-p -S 。| tar -xf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/package'返回非零退出状态 2。 子进程输出: 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 tar:./usr/include:无法创建目录:地址错误 获取到未知目录的 *at() 系统调用,文件描述符为 4 fd 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 tar:./usr/include:无法创建目录:地址错误 tar:./usr/include/misc:无法创建目录:没有该文件或目录 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用,文件描述符为 4 fd 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 tar:./usr/include:无法创建目录:地址错误 tar:./usr/include/misc/ocxl.h:无法打开:没有该文件或目录 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用,文件描述符为 4 fd 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 tar:./usr/include:无法创建目录:地址错误 tar:./usr/include/misc/pvpanic.h:无法打开:没有该文件或目录 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 tar:./usr/include:无法创建目录:地址错误 tar:./usr/include/misc/xilinx_sdfec.h:无法打开:没有该文件或目录 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 tar:./usr/include:无法创建目录:地址错误 tar:./usr/include/misc/cxl.h:无法打开:没有该文件或目录 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 tar:./usr/include:无法创建目录:地址错误 tar:./usr/include/misc/fastrpc.h:无法打开:没有该文件或目录 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 tar:./usr/include:无法创建目录:地址错误 tar:./usr/include/misc/uacce:无法创建目录:没有该文件或目录 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 tar:./usr/include:无法创建目录:地址错误 tar:./usr/include/misc/uacce/uacce.h:无法打开:没有该文件或目录 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径包含 无法为“include”分配绝对路径。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 好的,非常感谢。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 嗨, @zhijie 感谢您的回复。 我已经重现了这个问题,它与当前的 BSP 无关,而是由构建系统变更引起的。 我正在调查此事,一旦有任何进展,我会稍后回复您。 BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 谢谢, @zhijie 您能否也帮忙分享一下 uname -a 的运行结果? BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好, @zhijie 感谢你的帖子。 请问您的建筑环境有哪些具体情况? 这是你第一次组装BSP46吗?还是之前组装过? BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 嗨@zhijie 我也遇到了同样的问题,如果您解决了,请与我们联系。 错误:zlib-1.3.1-r0do_package:执行 Python 函数时出错,exec_func_python() 自动生成: 导致此异常/失败的 Python 调用堆栈跟踪如下: 文件:'exec_func_python() autogenerated',行号:2,函数: 0001: *** 0002:perform_packagecopy(d) 0003: 文件:'/home/smurugan8/LWT/sources/poky/meta/classes-global/package.bbclass',行号:363,函数:perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD} " 0362:perform_packagecopy[dirs] = "${PKGD} " *** 0363: 0364:python populate_packages() { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = " ${D} " 文件:'/usr/lib/python3.12/subprocess.py'行号:466,函数:check_output 0462:否则: 0463:空 = b'' 0464: kwargs['input'] = 空 0465: *** 0466: 返回 run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0467: **kwargs).stdout 0468: 0469: 0470:class CompletedProcess(object): 文件:'/usr/lib/python3.12/subprocess.py'行号:571,功能:运行 0567: # 我们不调用 process.wait()作为。 __exit__它能帮我们做到这一点。 0568:提高 0569: retcode = process.poll() 0570:如果检查并返回代码: *** 0571: 引发 CalledProcessError(retcode, process.args, 0572: output=stdout, stderr=stderr) 0573: 返回 CompletedProcess(process.args, retcode, stdout, stderr) 0574: 0575: 异常:subprocess.CalledProcessError:命令“tar --exclude=./sysroot-only”-cf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/image-p -S 。| tar -xf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/package'返回非零退出状态 2。 子进程输出: 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径库 无法为“lib”分配绝对路径。 tar:./usr/lib:无法创建目录:地址错误 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径库 无法为“lib”分配绝对路径。 获取到未知目录的 *at() 系统调用,文件描述符为 4 文件描述符 4 的未知基本路径,路径库 无法为“lib”分配绝对路径。 tar:./usr/lib:无法创建目录:地址错误 tar:./usr/lib/libz.so.1:无法创建指向“libz.so.1.3.1”的符号链接:没有这样的文件或目录 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好,陈音: 关于版本失败的问题,有什么最新进展吗? 请耐心等待好消息,非常感谢。 BR 志杰 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好, @zhijie 谢谢你的回复 通过查看建筑物故障日志,似乎与建筑物机器的程序更改有关。 您能否尝试一下以下方法?在你的 Ubuntu 电脑上,使用命令“sudo apt install tar=1.34+dfsg-1build3 ”来更改使用的 tar 版本,然后清理 电路板支持包。 并重新构建它。   BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好,陈音 问题已解决,谢谢! BR 志杰 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 我也遇到了同样的问题,我发现问题出在 tar 版本 build 4 上,降级确实解决了错误,但真正的问题是 tar 和 pseudo 使用了 openat2() 而不是 openat 来进行系统调用。 据我所见,poky 已经发布了补丁,NXP 方面有什么更新吗? 我目前使用的是 LLDP 6.1.22 版本。我在 LX2160ARDB_REV2 板上使用 SDK,尝试使用 bitbake 构建 rcw 时出现同样的错误。 如果 NXP 已将 pseudo_git.bb 更新为使用 openat2() 而不是 openat()(如 tar 最新构建 4 中所述),这将对我们很有用,因为我们可以将 tar 更新到最新版本。 附件包含日志文件,供您参考。 yocto-project 链接中的错误已添加到此处 https://bugzilla.yoctoproject.org/show_bug.cgi?id=16117 此致, PVSN Subhash Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好, @pvsnsubhash 感谢您的回复。在我找到解决办法后,我也注意到了这个伪问题,并已将其报告给了我们的内部团队。 相关团队将审查该问题,并安排正式修复的时间。 再次感谢您提供的宝贵意见。 BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好, @Sanjiv_Mns 感谢您的回复。 1. 好的,我了解到您目前使用的是 i.MX 而不是 S32G 产品。 2. 您可以尝试以下方法: "sudo apt install tar=1.34+dfsg-1build3"然后使用您的 Yocto 设置进行清理/重建 3. 如果问题仍然存在,我建议您等待原链接的反馈,我相信我的同事会根据您的 i.MX 设置帮助您解决问题。 BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 问题在于 Linux 中的 tar 软件包从 build3 升级到了 build4。按照以下步骤降级 tar 软件包,暂时不要对该软件包执行 apt upgrade 命令,然后继续进行编译。 wget http://archive.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1build3_amd64.deb sudo dpkg -i tar_1.34+dfsg-1build3_amd64.deb sudo apt-mark hold tar 完成以上步骤后,您可以继续进行编译,不会再出现此类错误。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 嗨@chenyin_h 你找到什么可能有助于解决这个问题的方法了吗? 这个问题目前阻碍了我们的进展,非常感谢您能提供任何最新信息或指导。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好, @Sanjiv_Mns 感谢您的回复。 请问您是否遇到过同样的问题?请您创建一个新帖子,附上您的详细日志,我们将尽快直接提供支持。 BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 嗨@chenyin_h 我仍然面临同样的问题。我已经在论坛上发帖询问了,但还没有收到任何回复。链接 附件中包含以下日志,供您参考。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 我在 NXP iMX BSP 6.6.36-2.1.0 中解决了这个问题。6.12.49-2.2.0 将 pseudo_git.bb 升级到 1.9.5 并更新 old-glibc-symbols 补丁……两者都是从相应的 wrynose 配方 (6.18.20-2.0.0) 复制而来。 git diff... diff --git a/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch b/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch 索引 c453b5f735..f42b32b8d9 100644 --- a/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch +++ b/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch @@ -28,10 +28,10 @@ diff --git a/Makefile.in b/Makefile.in @@ -120,7 +120,7 @@ $(PSEUDODB): pseudodb.o$(SHOBJS) $(DBOBJS) pseudo_ipc.o| $(BIN) libpseudo: $(LIBPSEUDO) - $(LIBPSEUDO): $(WRAPOBJS) pseudo_client.opseudo_ipc.o$(SHOBJS) | $(LIB) + $(LIBPSEUDO): $(WRAPOBJS) pseudo_client.o伪客户端扫描.o 伪IPC.o$(SHOBJS) | $(LIB) - $(CC) $(CFLAGS) $(CFLAGS_PSEUDO) -shared -o $(LIBPSEUDO) \ + $(CC) $(CFLAGS) -Lprebuilt/$(shell uname -m)-linux/lib/ $(CFLAGS_PSEUDO) -shared -o $(LIBPSEUDO) \ - pseudo_client.o pseudo_ipc.o\ + pseudo_client.o伪客户端扫描.o 伪IPC.o\ $(WRAPOBJS) $(SHOBJS) $(LDFLAGS) $(CLIENT_LDFLAGS) diff --git a/pseudo_wrappers.cb/pseudo_wrappers.c diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb b/meta/recipes-devtools/pseudo/pseudo_git.bb 索引 5f32b3777a..c491f0c97f 100644 --- a/meta/recipes-devtools/pseudo/pseudo_git.bb +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb @@ -1,8 +1,6 @@ 需要 pseudo.inc SRC_URI = "git://git.yoctoproject.org/pseudo;branch=master;protocol=https"\ - file://0001-configure-Prune-PIE-flags.patch \ - file://glibc238.patch \ file://fallback-passwd \ file://fallback-group \ “ @@ -14,9 +12,9 @@@ SRC_URI:append:class-nativesdk = " file://older-glibc-symbols.patch” SRC_URI[prebuilt.sha256sum]=“ed9f456856e9d86359f169f46a70ad7be4190d6040282b84c8d97b99072485aa” -SRCREV =“e11ae91da7d0711f5e33ea9dfbf1875dde3c1734” +SRCREV = "0bad85523ff71f1a84cea5fdf72e7f560c4aeed4" S = " ${WORKDIR} /git" -PV = "1.9.0+git" +PV = "1.9.5+git" # 大文件和 64 位 time_t 支持通过编译器标志全局添加这些宏 # 移除它们,因为伪函数会拦截一些函数,这些函数将会被拦截。
View full article
BSP46とlinux-libc-headers 6.6の組み合わせでコンパイル失敗が発生します。 BSP46とlinux-libc-headers 6.6の組み合わせでコンパイル失敗が発生します。 コンパイルログを以下に添付します。この問題を解決する方法についてご教示ください。 DEBUG:python関数の実行extend_recipe_sysroot 注意:直接依存関係は ['/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot'、 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rpm/rpm_4.19.1.1.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rsync/rsync_3.2.7.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/unifdef/unifdef_2.12.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-extended/xz/xz_5.4.7.bb:do_populate_sysroot'] 注意:sysrootにインストールした際: ['cmake-native', 'openssl-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'dwarfsrcfiles-native', 'elfutils-native', 'file-native', 'libedit-native', 'lua-native', 'make-native', 'perl-native', 'python3-native', 'rpm-native', 'bzip2-native', 'libarchive-native', 'libbnsl2-native', 'libtirpc-native', 'lzlib-native', 'zstd-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libunistring-native', 'nettle-native'] 注意:sysrootで既に存在しているようにスキップしています: ['gettext-minimal-native', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'zlib-native', 'bison-native', 'flex-native', 'gnu-config-native', 'patch-native', 'pkgconfig-native', 'pseudo-native', 'rsync-native', 'unifdef-native', 'xz-native', 'acl-native', 'attr-native', 'popt-native', 'sqlite3-native'] DEBUG: sed -e 's:^[^/]*/:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native/:g'/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/openssl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/ncurses-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/elfutils-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/lua-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/perl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/python3-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/rpm-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/curl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/gmp-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgcrypt-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgpg-error-native/fixmepath|XARGS sed -i -e 's:FIXMESTAGINGDIRTARGET:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot:g;s:FIXMESTAGINGDIRHOST:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native:g'-E 's:FIXME_PSEUDO_SYSROOT:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/pseudo-native:g'-E 's:FIXME_HOSTTOOLS_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/hosttools:g'-E 's:FIXME_PKGDATA_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/pkgdata/s32g399avmcu2.1asc:g'-E 's:FIXME_PSEUDO_LOCALSTATEDIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/pseudo/:g'-E 's:FIXME_LOGFIFO:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/temp/fifo.4087696:g' デバッグ: Python 関数 extend_recipe_sysroot が完了しました デバッグ: Python関数sstate_task_prefuncを実行中 デバッグ: Python関数sstate_task_prefuncが終了しました デバッグ: Python関数 do_package を実行中 デバッグ: Python関数 package_setup_pkgv を実行中 デバッグ: Python関数 package_setup_pkgv が完了しました デバッグ: Python 関数 package_convert_pr_autoinc を実行中 デバッグ: Python 関数 package_convert_pr_autoinc が完了しました デバッグ: Python関数 package_prepare_pkgdata を実行中 注: pkgdata-sysroot にインストールされました: [] デバッグ: Python関数 package_prepare_pkgdata が完了しました デバッグ: Python関数 perform_packagecopy を実行中 エラー: exec_func_python() で Python 関数を実行中にエラーが発生しました (自動生成)。 この例外/失敗を引き起こしたPython呼び出しのスタックトレースは以下の通りです: ファイル: 'exec_func_python() autogenerated', lineno: 2, function: 0001: 0002:perform_packagecopy(d) 0003: ファイル: '/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[指揮] = "${PKGD}" *** 0363: 0364:Python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = " ${D} " ファイル: '/usr/lib/python3.10/subprocess.py'、行番号: 421、関数: check_output 0417: それ以外の場合: 0418: 空 = b'' 0419: kwargs['input'] = 空 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): ファイル: '/usr/lib/python3.10/subprocess.py'、行番号: 526、関数: 実行 0522: # process.wait() は呼び出しませんとして。 __exit__それは私たちのためにやってくれる。 0523: 上げる 0524: retcode = process.poll() 0525: チェックして戻りコードを取得する場合: *** 0526: raise CalledProcessError(retcode, process.args, 0527: 出力=標準出力、標準エラー=標準エラー) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: 例外: subprocess.CalledProcessError: コマンド 'tar --exclude=./sysroot-only'-cf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/image-p -S 。|tar -xf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/package'ゼロ以外の終了ステータス2を返しました。 サブプロセスの出力: 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス TAR: ./USR/Include/MISC:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/ocxl.h: 開けられない:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/pvpanic.h: 開けません:そのようなファイルやディレクトリはありません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/xilinx_sdfec.h: 開けません:そのようなファイルやディレクトリはありません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/cxl.h: 開けません:そのようなファイルやディレクトリはありません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/fastrpc.h: 開けられない:そのようなファイルやディレクトリはありません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス TAR: ./USR/include/misc/uacce:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/uacce/uacce.h: 開けられない:そのようなファイルやディレクトリは存在しない 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. はい、どうもありがとうございました。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @zhijie ご返信ありがとうございます。 問題を再現しましたが、現在のBSPとは関係なく、ビルディングシステムの変更によるものです 現在調査中です。進展があり次第、後ほどご連絡いたします。 BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. ありがとう、 @zhijie uname -aの結果も教えていただけますか? BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @zhijie 投稿ありがとうございます。 ビルディングの環境について詳しく教えていただけますか? BSP46を組み立てるのは今回が初めてですか?それとも以前にも組み立てたことがありますか? BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは@zhijie 私も同じ問題に直面しています。もし解決できた方がいらっしゃいましたら、ぜひ教えてください。 エラー: zlib-1.3.1-r0do_package: exec_func_python() で Python 関数を実行中にエラーが発生しました (自動生成) この例外/失敗を引き起こしたPython呼び出しのスタックトレースは以下の通りです: ファイル: 'exec_func_python() autogenerated', lineno: 2, function: 0001: 0002:perform_packagecopy(d) 0003: ファイル: '/home/smurugan8/LWT/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[パッケージ] = "${PKGD}" *** 0363: 0364:Python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = " ${D} " ファイル: '/usr/lib/python3.12/subprocess.py'、行番号: 466、関数: check_output 0462: それ以外の場合: 0463: 空 = b'' 0464: kwargs['input'] = 空 0465: *** 0466: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0467: **kwargs).stdout 0468: 0469: 0470:class CompletedProcess(object): ファイル: '/usr/lib/python3.12/subprocess.py'、行番号: 571、関数: run 0567: # process.wait() は呼び出しませんとして。 __exit__それは私たちのためにやってくれる。 0568: 上げる 0569: retcode = process.poll() 0570: チェックして戻りコードを取得する場合: *** 0571: raise CalledProcessError(retcode, process.args, 0572: 出力=標準出力、標準エラー=標準エラー) 0573: return CompletedProcess(process.args, retcode, stdout, stderr) 0574: 0575: 例外: subprocess.CalledProcessError: コマンド 'tar --exclude=./sysroot-only'-cf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/image-p -S 。|tar -xf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/package'ゼロ以外の終了ステータス2を返しました。 サブプロセスの出力: 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パス lib 'lib' の絶対パスを割り当てられませんでした。 tar: ./usr/lib:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 tar: ./usr/lib:Cannot mkdir: 悪いアドレス tar: ./usr/lib/libz.so.1:'libz.so.1.3.1'へのシンムリンクを作成できません:そのようなファイル、又はディレクトリはありません Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、陳音 問題は解決しました。ありがとうございました! BR 志傑 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、chenyinさん: このビルド失敗問題について、何か進展はありますか? 良い知らせをお待ちしています。大変ありがたいです。 BR 志傑 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @zhijie ご返信ありがとうございます ビルディングの故障ログを確認すると、建築機械のプログラム変更に関連しているようです。 以下の方法を試していただけますか?Ubuntu PCで、コマンド「sudo apt install tar=1.34+dfsg-1build3 」を使用して使用するtarのバージョンを変更し、BSPをクリーンアップして再度再構築してください。   BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 私も同じ問題に直面していましたが、問題はtarのバージョンビルド4にあることが分かり、ダウングレードすることでエラーは解決しました。しかし、実際の問題はtarとpseudoがシステムコールにopenatではなくopenat2()を使用していることです。 私が知る限り、Pokyは既にパッチをリリースしているようですが、NXPは何かアップデート情報を持っていますか? 現在、LLDP 6.1.22を使用しています。LX2160ARDB_REV2ボード上でSDKを起動しても、bitbakeでRCWを構築しようとすると同じエラーが出ます。 もしNXPがtarの最新ビルド4のようにopenat()ではなくopenat2()を使ったpseudo_git.bbを更新していれば、tarを最新バージョンにアップデートできるので便利になるでしょう。 参考までにログファイルを添付しました。 yocto-projectのバグはここに追加されています https://bugzilla.yoctoproject.org/show_bug.cgi?id=16117 よろしくお願いいたします。 PVSN スバシュ Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @pvsnsubhash ご返信ありがとうございます。問題の回避策を講じた後、私も同様の疑似問題に気づき、社内チームに報告しました。 担当チームが問題を検討し、正式な修正のためのスケジュールを調整します。 貴重なご意見をありがとうございました。 BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは@chenyin_h 私は依然として同じ問題に直面しています。フォーラムに既に質問を投稿しましたが、まだ返信がありません。リンク 参考までに、ログファイルを以下に添付いたします。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @Sanjiv_Mns ご返信ありがとうございます。 あなたも同じ問題に遭遇しましたか?詳細記録を載せた新しい投稿を作成してもよろしいでしょうか?できるだけ早く直接サポートします。 BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは@chenyin_h 解決に役立つ何か見つけましたか? この問題が現在進行を妨げています。何か進捗やアドバイスをいただけると本当にありがたいです。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @Sanjiv_Mns ご返信ありがとうございます。 1. わかりました。現在S32G製品ではなく i.MX を使っていると理解しています 2. 以下の方法で試してみることもできます: "sudo apt install tar=1.34+dfsg-1build3"そしてYoctoのセットアップでクリーン・再構築 3. それでも問題が解決しない場合は、元のリンクからのフィードバックをお待ちください。私の同僚があなたのi.MXの設定に基づいて解決のお手伝いをしてくれると思います。 BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 問題は、Linuxのtarパッケージがbuild3からbuild4にアップグレードされたことです。以下の手順でtarパッケージをダウングレードし、そのパッケージのアップグレードを一旦保留してコンパイレーションを進めてください。 wget http://archive.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1build3_amd64.deb sudo dpkg -i tar_1.34+dfsg-1build3_amd64.deb sudo apt-mark hold tar 上記の手順を踏み終えた後、コンパイルを進めば、そのようなエラーは一切見られません。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. この問題はNXP iMX BSP 6.6.36-2.1.0で解決しました。また、6.12.49-2.2.0 では pseudo_git.bb を 1.9.5 に上げ、older-glibc-symbols パッチを更新しています。これらはどちらも対応する wrynose レシピ (6.18.20-2.0.0) からコピーされたものです。 git diff... diff --git a/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch b/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch インデックス c453b5f735..f42b32b8d9 100644 --- a/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch +++ b/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch @@ -28,10 +28,10 @@ diff --git a/Makefile.in b/Makefile.in @@ -120,7 +120,7 @@ $(PSEUDODB): pseudodb.o$(SHOBJS) $(DBOBJS) pseudo_ipc.o| $(BIN) libpseudo: $(LIBPSEUDO) - $(LIBPSEUDO): $(WRAPOBJS) pseudo_client.opseudo_ipc.o$(SHOBJS) | $(LIB) + $(LIBPSEUDO): $(WRAPOBJS) pseudo_client.opseudo_client_scanf.o pseudo_ipc.o$(ショーブス) |$(リブ) - $(CC) $(CFLAGS) $(CFLAGS_PSEUDO) -共有 -o $(LIBPSEUDO) \ + $(CC) $(CFLAGS) -Lprebuilt/$(shell uname -m)-linux/lib/ $(CFLAGS_PSEUDO) -shared -o $(LIBPSEUDO) \ - pseudo_client.o pseudo_ipc.o\ + pseudo_client.opseudo_client_scanf.o pseudo_ipc.o\ $(WRAPOBJS) $(SHOBJS) $(LDFLAGS) $(CLIENT_LDFLAGS) diff --git a/pseudo_wrappers.cb/pseudo_wrappers.c diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb b/meta/recipes-devtools/pseudo/pseudo_git.bb インデックス 5f32b3777a..c491f0c97f 100644 --- a/meta/recipes-devtools/pseudo/pseudo_git.bb +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb @@ -1,8 +1,6 @@ 擬似ファイルが必要です。 SRC_URI = "git://git.yoctoproject.org/pseudo;branch=master;protocol=https\ - file://0001-configure-Prune-PIE-flags.patch \ - file://glibc238.patch \ file://fallback-passwd \ file://fallback-group \ " @@ -14,9 +12,9 @@@ SRC_URI:append:class-nativesdk = " file://older-glibc-symbols.patch」 SRC_URI[prebuilt.sha256sum]= "ed9f456856e9d86359f169f46a70ad7be4190d6040282b84c8d97b99072485aa" -SRCREV = "e11ae91da7d0711f5e33ea9dfbf1875dde3c1734" +SRCREV = "0bad85523ff71f1a84cea5fdf72e7f560c4aeed4" S = " ${WORKDIR} /git" -PV = "1.9.0+git" +PV = "1.9.5+git" #largefileおよび64bit time_tサポートは、これらのマクロをコンパイラフラグを通じてグローバルに追加します # 擬似関数は一部の関数を遮蔽するため、擬似は
View full article
MC34GD3000 gate drive output voltage level when VPWR is 24 V Hello NXP Community, I am planning to use the MC34GD3000 to drive a 24 V, 26 W motor. In many reference circuits and examples, the VPWR supply of the MC34GD3000 appears to be connected to the same supply voltage as the motor supply. In my application, the motor supply voltage will be 24 V, so VPWR of the MC34GD3000 will also be 24 V. I would like to clarify the gate drive output voltage level of the MC34GD3000. In the datasheet absolute maximum ratings table, I found values such as: - PX_HS_G to PX_HS_S: 3.0 V to 16.5 V - PX_LS_G to PX_LS_S: 3.0 V to 16.5 V - PX_BOOT to PX_HS_S: 3.0 V to 16.5 V My question is: When VPWR is 24 V, what is the actual PWM gate drive output voltage level of the MC34GD3000? Does the gate drive output become 24 V because VPWR is 24 V, or is the gate drive output limited to approximately 16.5 V maximum with respect to each MOSFET source node? For example, for the low-side MOSFET, should I understand that PX_LS_G to PX_LS_S is driven up to around 15 V, not 24 V? And for the high-side MOSFET, should I understand that PX_HS_G is driven above the phase node, but the gate-to-source voltage PX_HS_G to PX_HS_S is still limited to around 15 V? I would appreciate your confirmation. Thank you. BLDC Driver Re: MC34GD3000 gate drive output voltage level when VPWR is 24 V Hello, Yes, your understanding is correct. Even when VPWR is connected to a 24 V motor supply, the MC34GD3000 does not drive the MOSFET gates to 24 V with respect to their source terminals. The device generates an internal gate-drive supply (VLS), which is regulated to approximately 15 V. ErikaC_1-1783696364130.png ErikaC_0-1783696304074.png Therefore: For the low-side MOSFET, PX_LS_G is driven to approximately 15 V above PX_LS_S. For the high-side MOSFET, PX_HS_G is driven above the phase node through the bootstrap circuit, but the gate-to-source voltage PX_HS_G − PX_HS_S remains approximately 15 V. ErikaC_2-1783696431300.png The limits shown in the datasheet (PX_HS_G to PX_HS_S and PX_LS_G to PX_LS_S) represent the effective gate-to-source drive voltage and indicate that the gate drive is not equal to the 24 V VPWR supply. Hope this helps!
View full article
MPC5744P IVOR1 マシンチェックハンドラがRTOS、ベアメタルSで訂正不能なFLASH ECCエラーでヒットしない こんにちは、SDK 2.1の FLASH_ECC_Error_Injection_MPC5744P デモプロジェクトを使ってFLASH ECCの故障処理をテストしています。 ベアメタルSDKの例では、Generate_noncorrectable_FLASH_ECC_errorを呼び出した後、コアは正しく故障を捕捉し、期待通りMachine_check_handler(IVOR1ハンドラー)に入ります。 RTOS ベースのプロジェクトに同一の ECC インジェクション ロジックを移植した後、マシン チェック例外は発生せず、コードは Machine_check_handler にジャンプしません。 私は既に以下の移植および設定手順を完了しました。 起動時の.sファイルにIVOR1_Handlerを完全に移植して定義しました。アセンブリファイル(ベアメタルデモと互換性あり)。 FCCUアラーム割り込みの設定は完全に実装されていますが、訂正不可能なFLASH ECCエラーを注入してもFCCUアラーム割り込みは発生しません。 この問題を解決するために、3つの重要な質問があります。 FLASHの訂正不能なECCエラーに対してマシンチェックハンドラ(IVOR1)へのアクセスを可能にするために、必須となるハードウェア/レジスタ構成は何ですか? RTOS上でECC障害注入とマシンチェック例外処理を実行する際に、特別な考慮事項や制約はありますか? この欠損マシンチェック例外の根本原因を特定するためのステップバイステップのデバッグやトラブルシューティングのワークフローを提供できますか? Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet 挙げられている例は知りませんが、おそらく私がGHSコンパイラを使用して作成したアプリケーションノートの移植版だと思います。 https://www.nxp.com/docs/en/application-note/AN13179.pdf https://www.nxp.com/docs/en/application-note-software/AN13179SW.zip RTOSが動作に影響を与える場合、RTOSがMSRレジスタに対してどのような処理を行っているかを調査する必要がある。第5章に注意してください。 また、ECCの処理方法については、セクション8を参照してください。 Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet こんにちは、 テスト中に以下のことが分かりました。 私のプロジェクトでは、-O1最適化レベルでコンパイル中にIVOR1_Vectorハンドラーをトリガーできません。-O0 オプションでは例外処理は正常に機能します。 しかし、参照デモプロジェクトは、同じ最適化設定を使用して-O1オプションで正しく動作します。 根本原因を特定するための提案をいただけるとありがたいです。
View full article
s32k144 - Device is secured Hi Team, I am working with the S32K114 (AN12323) project. Initially, I flashed the Gateway project with CSEC disabled, and the programming was successful. After that, I attempted to flash the CAN example application, but I encountered the following error: "Device is secure, erase to unsecure." To resolve the issue, I also tried using the "Emergency Kinetis Device Recovery" option, but it did not work. Could you please suggest how to recover the device or remove the secure state so that I can flash the CAN example? Re: s32k144 - Device is secured Hi @Senlent , In which scenarios would the reset signal period be approximately 118 µs, and what factors could cause it to increase to around 475 µs in my case?     Thnaks. Re: s32k144 - Device is secured Hi@Pranathi06 If the reset signal period is not ~118µs, but greater than 200µs, such as 500µs or even longer, the MCU will not be able to be decrypted and recovered via the SWD/JTAG debug interface using the mass erase command. Re: s32k144 - Device is secured Hi @Senlent  I measured the RESET_b pin waveform using an oscilloscope. The RESET_b signal is continuously toggling. Pulse repetition appears to be roughly 400–500 µs (cursor shows Δt ≈ 475 µs). Peak level is around 5 V, which suggests you may be probing an external reset circuit rather than directly measuring a 3.3 V MCU pin, or there is a pull-up to 5 V on RESET. The reset activity is continuous and regular.   Thanks         Re: s32k144 - Device is secured Hi@Pranathi06 The "S32K144_FOTA_GATEWAY" command doesn't involve any CSEc or flash security related operations, so I'm unsure what you've done to the MCU. You could measure the waveform of the RESET pin and tell me its reset cycle. The reset cycle can be used to determine if the chip can recover to normal operation. Re: s32k144 - Device is secured Hi @Senlent , Yes, successfully flashed "S32K144_FOTA_Gateway", when I tried to flash Can_example project that time "Device is secured" after that I cannot be able to flash any software. Thanks Re: s32k144 - Device is secured Hi@Pranathi06 Is your problem occurring when downloading the "S32K144_FOTA_Gateway" program, or have you already successfully flashed "S32K144_FOTA_Gateway"? Re: s32k144 - Device is secured Hi @Senlent      I flashed AN5401_S32K144_CSEc_Resetting_Flash_to_Factory_State to erase the keys. After that, I flashed only the GATEWAY_PROJECT; I did not flash the Memory_Partition project. Thanks.   Re: s32k144 - Device is secured Hi@Pranathi06 "Before flashing my GATEWAY_PROJECT, I have flashed "Resetting flash to state" I don't understand your meaning. The AN12323SW doesn't have a "Resetting flash to state" program. From what you're saying, you've modified "S32K144_FOTA_Gateway"? You just need to check if your program has enabled the CSEc module and assigned a key, and whether you've considered restoring the CSEc module to its factory state within the application. If not, then this situation is unrecoverable. Re: s32k144 - Device is secured Hi @Senlent  I didn't flash Memory_partition project.  Before flashing my GATEWAY_PROJECT, I have flashed "Resetting flash to state"  Is there any solution for recover? Thanks. Re: s32k144 - Device is secured Hi@Pranathi06 This issue is unrelated to whether "CSEC" is enabled in "S32K144_FOTA_Gateway" because when testing AN12323SW, your first step should be to download and run "S32K144_Memory_Partition" to perform partitioning, which already enables CSEC by default and assigns a key. Senlent_0-1783587478752.png AN12130: Senlent_1-1783587519720.png This is why the MCU is locked; since the solution doesn't provide a reset CSEC operation, it cannot be recovered. Next time, remember to modify "S32K144_Memory_Partition" to partition only, without enabling CSEC or the key. Re: s32k144 - Device is secured Hi@Pranathi06 This is based on experience, and your situation is quite similar: the CSEc hardware encryption module was enabled, preventing mass erase of the CSEc encryption key, which caused the problem. Although the chip has deadlocked, and the MCU can no longer download programs or debug, as long as the chip's power supply is normal, you can still use a J-LINK debugger to connect to the CoreSight DAP debug access interface of the S32K1xx series MCU ARM Cortex M4F/M0+ via the SWD/JTAG debug interface to read the MDM-AP status register. Therefore, you can determine the root cause of the chip deadlock based on the read MDM-AP status register value. If you need me to help you pinpoint the cause of the deadlock, you can try using J-LINK to read the MDM-AP status register.
View full article
RDDRONE-BMS772 Development Board Accessories RDDRONE-BMS772开发板配件 I want to purchase the RDDRONE-BMS772 development board for battery-related experiments. I need to measure and record the voltage, current, and temperature data of the experimental battery. Besides the accessories included with the development board on the official website, what other accessories do I need to purchase, such as the battery itself and a compatible battery charger? In other words, I need to conduct battery experiments and measure and record the battery's voltage, current, and temperature data. In addition to the accessories included in the development board packaging, what other related accessories do I need for this experiment? Could you please provide a detailed list of accessories, preferably including the compatible models of these accessories? I need to purchase them all at once for the experiments. Thank you very much. 我现在想要购买RDDRONE-BMS772这个型号的开发板进行电池的相关实验需要测量记录实验电池的电压、电流和温度数据,现在除了官网上开发板包含的配件之外,我还需要购买哪些配件,比如电池、和电池匹配的电池充电器这些其他需要的相关配件;就是说我现在需要进行电池实验,需要测量记录电池的电压、电流和温度数据,在这个实验的基础上,除了开发板包装里的配件之外我还需要哪些相关的其他配件,你能不能帮我列个详细的配件清单,最好能把适配开发板的这些配件型号也帮我列一下,我需要一次性购买来进行实验,万分感谢。 Re: RDDRONE-BMS772 Development Board Accessories RDDRONE-BMS772开发板配件 Dear Fan007, for battery state estimation research, the RDDRONE-BMS772 requires a real 3S to 6S Li-ion battery pack with a balance connector and a matching charger. The documentation does not specify a particular battery or charger model. You just need to make sure that the parameters are within specified limits.  JozefKozon_1-1783586246113.png JozefKozon_2-1783586292642.png For firmware development and debugging, an external debugger is recommended, such as: SEGGER J-Link Mini PEMicro Universal Multilink Other compatible JTAG debuggers The board provides JTAG (J2) and DCD-LZ (J19) debug interfaces. There is no direct USB programming/debugging from a PC, so an external debugger is necessary.   Minimum recommended setup: RDDRONE-BMS772 board 3S Li-ion battery pack with balance connector Compatible 3S charger J-Link or PEMicro debugger Windows PC with S32 Design Studio This setup allows measurement of cell voltages, pack voltage, current (coulomb counting), temperature, and cell balancing, making it suitable for SOC/SOH algorithm development.   With Best Regards, Jozef Re: RDDRONE-BMS772 Development Board Accessories RDDRONE-BMS772开发板配件 I apologize, you didn't understand me. My current research is about battery state estimation, which requires measuring the voltage, current, and temperature data of a real battery. Therefore, I don't need a battery simulator; I need a real battery. So, I need a battery compatible with my development board and a specific model of the corresponding battery charger. Also, are the PEMicro adapter and SEGGER J-Link Mini debugger mentioned in the link necessary hardware for debugging or programming algorithms on the development board? Can't the development board be directly connected to a computer for debugging and programming? Are these adapters and debuggers available on the market? Furthermore, besides the hardware you mentioned, are there any other necessary hardware components for the development board? Please answer these questions in detail. Thank you very much. 抱歉,你没理解我的意思,我目前的研究是关于电池状态估计的,需要测量真实电池的电压电流和温度数据,所以我不需要电池模拟器,我需要的是真实的电池,所以我需要适配开发板的电池和对应电池充电器的具体型号;并且那个链接里提到的PEMicro适配器以及SEGGER J-Link Mini调试器是开发板调试或者烧录算法必须的硬件吗?开发板不能直接连接到电脑上进行调试和烧录程序吗?这些适配器和调试器在市面上可以买到吗?还有,开发板除了你提到的这几个硬件之外还有别的必须硬件吗?请您详细解答一下这些疑问,万分感谢。 Re: RDDRONE-BMS772 Development Board Accessories RDDRONE-BMS772开发板配件 I apologize, you didn't understand me. My current research is about battery state estimation, which requires measuring the voltage, current, and temperature data of a real battery. Therefore, I don't need a battery simulator; I need a real battery. So, I need a battery compatible with my development board and a specific model of the corresponding battery charger. Also, are the PEMicro adapter and SEGGER J-Link Mini debugger mentioned in the link necessary hardware for debugging or programming the development board? Can't the development board be directly connected to a computer for debugging and programming? Are these adapters and debuggers available on the market? Furthermore, besides the hardware you mentioned, are there any other necessary hardware components for the development board? Please answer these questions in detail. Thank you very much. 抱歉,你没理解我的意思,我目前的研究是关于电池状态估计的,需要测量真实电池的电压电流和温度数据,所以我不需要电池模拟器,我需要的是真实的电池,所以我需要适配开发板的电池和对应电池充电器的具体型号;并且那个链接里提到的PEMicro适配器以及SEGGER J-Link Mini调试器是开发板调试或者烧录算法必须的硬件吗?开发板不能直接连接到电脑上进行调试和烧录程序吗?这些适配器和调试器在市面上可以买到吗?还有,开发板除了你提到的这几个硬件之外还有别的必须硬件吗?请您详细解答一下这些疑问,万分感谢。 Re: RDDRONE-BMS772 Development Board Accessories RDDRONE-BMS772开发板配件 Dear Fan007,  for the additional HW needed with the RDDRONE-BMS772 please refer to this link.  JozefKozon_0-1783575667159.png For the battery pack, we can offer you a BATT-6EMULATOR and BATT-14EXTENDER. The battery emulator can be used instead of the battery pack, but because there are different connectors, the battery extender should be in between.  With Best Regards, Jozef
View full article
Fee's first read program crashed I'm using the FEE function of an S32K311 microcontroller to store data. FEE tests for erasing and writing work fine, but on the first read attempt, without any data written, it fails to load and crashes. Similar to the C40, the first read returns 0xFF, which I can use to identify the first read/write operation and fill in the default value. Is there a way to make the first FEE return a value like 0xFF instead of crashing? I'm using RTD 4.0.0. Re: Fee首次读取程序跑飞 Hi@ LJH1 The first time you call Fee_Read(), you don’t have to write to it first. However, if the block has never been written to, the read job is likely to return MEMIF_BLOCK_INVALID or MEMIF_BLOCK_INCONSISTENT. The application layer should be able to treat it as “uninitialized” and then write the default value. Do not rely on reading valid data directly on the first read; the correct approach is to check the job result after reading, and initialize default values and write them when invalid/inconsistent data is encountered. Senlent_0-1783662229362.png
View full article
在 i.MX8M Plus 和 TIM-VX/VSINPU 上,GC7000UL 通用计算推理路径似乎仅支持 NPU。 板/电路板支持包。: i.MX8M Plus,aarch64 Galcore 版本 6.4.11.p2.745085 ONNX 运行时,带有 VSINPUExecutionProvider(静态链接到 libtim-vx.so) Vivante OpenCL ICD 已存在且功能正常(Vivante.icd → libVivanteOpenCL.so) 目标: 专门在 GC7000UL 3D GPU 核心上运行 ResNet50 推理基准测试(MLPerf loadgen 测试框架),以便与已收集的现有 NPU(VIP8000Nano)和 CPU 基准测试结果进行比较。 已确认有效的功能: 通过 Vivante OpenCL ICD 使用 clGetPlatformIDs/clGetDeviceIDs 可以清晰地枚举同一平台下的两个独立设备: 设备 0:GC7000UL.6204.0000 设备 1:VIP8000Nano-S+I.8002.0000 两者都报告 CL_DEVICE_TYPE_ACCELERATOR,没有错误,通过链接到 libOpenCL.so → libGAL.so 的最小 C 测试程序确认。 是什么阻碍了通过 ORT 进行 GPU 调度: ort.get_available_providers() 仅返回 ['VSINPUExecutionProvider', 'CPUExecutionProvider'] — 没有基于 OpenCL 的 EP。 VSINPUExecutionProvider 静态链接到 libtim-vx.so(OVXLIB/vsi_nn_* API)。libtim-vx.so 和 libGAL.so 的符号/字符串转储显示没有 DEVICE_INDEX/DEVICE_ID 风格的环境变量或配置表面——只有行为切换(VIV_VX_ENABLE_SHADER、VSI_NN_ENABLE_* 等)。 libGAL.so 确实在原始 HAL 层导出了 gcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndex,但是从 OVXLIB/TIM-VX 到该调用没有明显的管道,这表明 VSINPU 使用的图形编译器可能被硬编码为仅针对 NPU 核心,而不管设备索引如何。 具体问题: 此电路板支持包 (galcore 6.4.11.p2) 上的 TIM-VX / OVXLIB 是否支持将图编译并分发到 GC7000UL 作为通用计算目标?或者,此版本中的图编译器是否设计为仅限 NPU?我如何验证是否可以以这种方式运行它? 如果 TIM-VX 上游支持 GPU 目标图编译,但 NXP 提供的版本中未启用,是否有构建标志/SDK 元器件可以启用它? 如果无法通过 TIM-VX/ORT 获得支持,NXP 是否有推荐的方法可以直接在 GC7000UL 上运行通用推理(例如通过 OpenCL/OpenVX 层,因为该部分协议栈已被确认功能正常),或者是否有示例应用程序、SDK 组件或参考实现可供我们参考? 我目前是一名学生,正在尝试进行这项实现,并在 GPU 上运行 ORT,请问是否有任何方法或途径可以使用 GPU 进行推理? 非常感谢 IMX8MPLUS #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 嗨@WaleedO , 感谢您联系恩智浦技术支持。 要在 GPU 上运行推理,您应该使用 GPU 委托,它允许由 GPU 加速支持的操作,而不是完全在 CPU 上运行。 我建议您查看我们的机器学习用户指南,以便更好地了解可用的执行后端、委托配置、支持的框架和示例应用程序。该指南还包含逐步示例,可以帮助您验证 GPU 委托是否已正确加载以及您的模型是否按预期执行。 如果在安装或执行过程中遇到任何问题,请分享您的模型、BSP 版本以及您正在使用的命令,我将很乐意为您提供进一步的帮助。 此致, 亚历杭德罗·加西亚 Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 你好@Chavira 很高兴见到你。 查阅文档后发现,GPU 委托和 OpenCL 路径是在 i.MX 95/952 GPU(Arm Mali G310)中使用。我目前正在研究IMX8MPLUS。IMX8M Plus 的架构如下:VX 代理 ==> TIM-VX ==> GPU/NPU(统一驱动程序) ==> I.MX 8 系列 NPU 和 GPU(GC7000、GC7000L、GC7000UL)。根据文件记载。 目前我正在使用 ONNX 和 ORT。当我运行该程序时,它默认在 NPU 上运行。是否有办法使用 OpenCL 在IMX8MPLUS GPU 上工作?或者是否有任何手动覆盖或我可以实现的技术,以便我可以手动将编译目标设置为 NPU 或/和 GPU? 非常感谢您的回复。 亲切的问候, IMX8MPLUS #TIM-VX #VX-delegate
View full article
s32k144 - デバイスは保護されています チームの皆さん、こんにちは。 私はS32K114(AN12323)プロジェクトに取り組んでいます。最初は、 CSECを無効にした状態でGatewayプロジェクトをフラッシュしたところ、プログラミングは成功しました。 その後、 CANの例アプリケーションをフラッシュしようとしましたが、以下のエラーに遭遇しました: 「デバイスは安全です。データを消去して安全性を解除してください。」 問題を解決するために 「緊急Kinetisデバイス回復」 オプションも試しましたが、効果がありませんでした。 CANの例をフラッシュするために、デバイスの復元方法やセキュア状態を解除する方法を教えていただけますか? Re: s32k144 - Device is secured こんにちは、 @Senlent さん。 どのようなシナリオでリセット信号周期が約118μsになるのか、また私の場合、どのような要因で約475μsまで増加するのでしょうか?     ありがとうございます。 Re: s32k144 - Device is secured こんにちは、@ Pranathi06 リセット信号周期が約118µsではなく、200µsより長く、例えば500µsまたはそれ以上の場合、 MCUはSWD/JTAGデバッグインターフェースのマスイレーズコマンドによる復号・復号はできません。 Re: s32k144 - Device is secured こんにちは、 @Senlentさん 私はオシロスコープを使ってRESET_bピンの波形を測定しました。 RESET_b信号は連続的にトグルしています。 パルスの繰り返し周期はおよそ400~500µsのようです(カーソルはΔt ≈ 475µsを示しています)。 ピークレベルは約 5Vで、3.3V MCUピンを直接測定するのではなく外部リセット回路を探っている可能性や、RESET時に5Vへのプルアップがある可能性を示唆しています。 リセット活動は継続的かつ定期的に行われる。   よろしくお願いします。         Re: s32k144 - Device is secured こんにちは、@Pranathi06 「S32K144_FOTA_GATEWAY」コマンドはCSEcやフラッシュのセキュリティ操作を含んでいないので、あなたがMCUに何をしたのかはわかりません。 リセットピンの波形を測定してリセットサイクルを教えてもらえます。 リセットサイクルはチップが正常動作に復旧できるかどうかを判断するために使えます。 Re: s32k144 - Device is secured こんにちは、 @Senlent さん。 はい、「S32K144_FOTA_Gateway」は正常にフラッシュしましたが、その時にプロジェクトをフラッシュしようとしたとき、「デバイスは保護済み」Can_example、その後はどのソフトウェアもフラッシュできなくなりました。 よろしくお願いします。 Re: s32k144 - Device is secured こんにちは、@ Pranathi06 問題は「S32K144_FOTA_Gateway」プログラムのダウンロード中に発生していますか、それとも既に「S32K144_FOTA_Gateway」の書き込みに成功していますか? Re: s32k144 - Device is secured こんにちは、 @Senlentさん     キーを消去するために、AN5401_S32K144_CSEc_Resetting_Flash_to_Factory_State をフラッシュしました。その後、GATEWAY_PROJECTのみをフラッシュし、Memory_Partitionプロジェクトはフラッシュしませんでした。 ありがとうございます。   Re: s32k144 - Device is secured こんにちは、@ Pranathi06 「GATEWAY_PROJECTをフラッシュする前に、「フラッシュを状態にリセット」をフラッシュしました」 あなたの言っている意味が分かりません。 AN12323SWには「フラッシュを状態にリセットする」プログラムがありません。 あなたの話からすると、「S32K144_FOTA_Gateway」を変更したということですか? プログラムがCSEcモジュールを有効にしてキーを割り当てているか、そしてアプリケーション内でCSEcモジュールを工場出荷時の状態に戻すことを検討しているかを確認する必要があります。 そうでなければ、この状況は回復不可能となる。 Re: s32k144 - Device is secured こんにちは、 @Senlentさん Memory_partitionプロジェクトをフラッシュしませんでした。 GATEWAY_PROJECTをフラッシュする前に、「フラッシュを状態にリセット」をフラッシュしました。 復旧するための解決策はありますか? ありがとうございます。 Re: s32k144 - Device is secured こんにちは、@ Pranathi06 この問題は、「S32K144_FOTA_Gateway」で「CSEC」が有効になっているかどうかとは関係ありません。AN12323SWをテストする場合、最初のステップとして「S32K144_Memory_Partition」をダウンロードして実行し、パーティショニングを実行する必要があります。このツールはデフォルトでCSECを有効にし、キーを割り当てます。 Senlent_0-1783587478752.png AN12130: Senlent_1-1783587519720.png これがMCUがロックされている理由です。 解はリセットCSEC操作を提供しないため、復元できません。 次回は、「S32K144_Memory_Partition」をパーティション分割のみに変更し、CSECやキーを有効にしないようにしてください。 Re: s32k144 - Device is secured こんにちは、@ Pranathi06 これは経験に基づいたもので、あなたの状況も非常によく似ています。CSEcハードウェア暗号化モジュールが有効になっていたため、CSEc暗号化キーの一括消去が妨げられ、それが問題の原因となったのです。 チップはデッドロックされており、MCUはプログラムのダウンロードやデバッグができなくなりますが、チップの電源が正常であれば、J-LINKデバッガを使ってS32K1xxシリーズMCU ARM Cortex M4F/M0+のCoreSight DAPデバッグアクセスインターフェースに接続し、SWD/JTAGデバッグインターフェースを介してMDM-APステータスレジスタを読み取ることができます。 したがって、MDM-APの状態レジスタの読み取り値に基づいてチップデッドロックの根本原因を特定できます。 もしデッドロックの原因を特定する手助けが必要なら、 J-LINK を使って MDM-APステータスレジスタを読み取ってみるといいですよ。
View full article
MC34GD3000 VPWRが24 Vの場合のゲートドライブ出力電圧レベル こんにちは、NXPコミュニティの皆さん、 このMC34GD3000を使って24V、26Wのモーターを駆動する予定です。 多くの参考回路や例では、MC34GD3000のVPWR電源はモーター電源と同じ電源電圧に接続されているように見えます。私の用途では、モーターの電源電圧は24Vなので、MC34GD3000のVPWRも24Vになります。 MC34GD3000のゲート駆動出力電圧レベルについて確認させてください。 データシートの絶対最大定格表には、次のような値が記載されていました。 - PX_HS_G~PX_HS_S:3.0V~16.5V - PX_LS_G~PX_LS_S:3.0V~16.5V - PX_BOOTからPX_HS_Sまで:3.0V~16.5V 私の質問は次のとおりです。 VPWRが24Vの場合、MC34GD3000の実際のPWMゲートドライブ出力電圧レベルはどのくらいですか? VPWRが24Vであるためゲートドライブ出力は24Vになるのでしょうか、それとも各MOSFETソースノードに対してゲートドライブ出力は最大約16.5Vに制限されるのでしょうか? 例えば、ローサイドMOSFETの場合、PX_LS_GからPX_LS_Sへの駆動は24Vではなく約15Vまで駆動されるということを理解しておくべきでしょうか? ハイサイドMOSFETについては、PX_HS_Gは位相ノードより上に駆動されるものの、ゲート・ソース間電圧PX_HS_GからPX_HS_Sまでは依然として約15Vに制限される、と理解してよろしいでしょうか? ご確認いただければ幸いです。 よろしくお願いします。 BLDCドライバー Re: MC34GD3000 gate drive output voltage level when VPWR is 24 V こんにちは、 はい、あなたの理解は正しいです。VPWRが24Vモーター電源に接続されていても、MC34GD3000はMOSFETゲートをソース端子に対して24Vに駆動しません。このデバイスは、約15Vに安定化された内部ゲート駆動電源(VLS)を生成します。 ErikaC_1-1783696364130.png ErikaC_0-1783696304074.png そのため、 ローサイドMOSFETの場合、PX_LS_GはPX_LS_Sより約15V高い電圧で駆動されます。 ハイサイドMOSFETでは、PX_HS_Gは位相ノードの上をブートストラップ回路を通じて駆動されますが、ゲート対ソース電圧PX_HS_G−PX_HS_Sは約15Vのままです。 ErikaC_2-1783696431300.png データシートに示されている制限(PX_HS_GからPX_HS_S、PX_LS_GからPX_LS_S)は、実効的なゲート対ソースドライブ電圧を表し、ゲートドライブが24V VPWR電源と等しくないことを示しています。 お役に立てば幸いです!
View full article
Imx6ull KSZ8041NLイーサネットの問題 こんにちは 、 私たちの潜在的なプロジェクトの一つにデュアルイーサネットを利用するために、Imx6ullプロセッサを搭載した2つのイーサネット物理線を接続しました。 一方のPHYはKSZ8081、もう一方のPHYはKSZ8041です。以下は当社のDTS構成です。 &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; ステータス = "正常"; }; &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; phy-mode = "rmii"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; ステータス = "正常"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0: イーサネット-phy@1 { reg = <1>; micrel、LEDモード = <1>; クロック = <&CLKS IMX6UL_CLK_ENET_REF>; クロックネーム = 「rmii-ref」; }; ETHphy1: イーサネットphy@3 { reg = <3>; micrel、LEDモード = <1>; クロック = <&clks IMX6UL_CLK_ENET2_REF>; クロックネーム = 「rmii-ref」; }; }; }; pinctrl_enet1: enet1grp { fsl、pins = < MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 >; }; pinctrl_enet2: enet2grp { fsl、pins = < MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0 MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0 MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0 MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031 >; }; イーサネットの物理はカーネルログで検出され、イーサネットケーブルを接続するとリンクも検出されています。 しかしIPはKSZ8081物理に接続されているイーサネットに届き、IPはKSZ8084NLに接続されているイーサネットに割り当てられていません。 そして、イーサネットKSZ8041NL eth0でrxエラーが観察されます。以下のログは以下の通りです: root@sls-IMX6ull14X14evk:~# ifconfig eth0 リンク encap:イーサネット HWaddr BA:9C:69:1F:76:3A UP放送マルチキャスト MTU:1500 メトリック:1 RXパケット:0 エラー:1065 ドロップ:0 オーバーラン:0 フレーム:1065 送信パケット数:65 エラー数:0 ドロップ:0 オーバーラン数:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:12024(11.7 KiB) eth1 リンク encap:イーサネット HWaddr 42:19:11:7F:5E:89 inet addr:10.20.0.184放送日時: 10.20.1.255マスク:255.255.254.0 inet6 アドレス: fe80::8248:9837:9647:2a00/64 スコープ:リンク UP ブロードキャスト実行中 マルチキャスト MTU:1500 メトリック:1 受信パケット数:18 エラー数:0 ドロップ数:0 オーバーラン数:0 フレーム数:0 送信パケット数:23 エラー数:0 ドロップ数:0 オーバーラン数:0 キャリア数:0 衝突回数:0 txqueuelen:1000 RX バイト:2494 (2.4 KiB) TX バイト:3162 (3.0 KiB) lo Link encap:ローカルループバック インターネットアドレス: 127.0.0.1マスク:255.0.0.0 inet6 アドレス: ::1/128 スコープ:ホスト UPループバック実行中 MTU:65536 メトリック:1 受信パケット数:17 エラー数:0 ドロップ数:0 オーバーラン数:0 フレーム数:0 送信パケット数:17 エラー数:0 ドロップ数:0 オーバーラン数:0 キャリア数:0 衝突回数:0 txqueuelen:1000 RX バイト:2011 (1.9 KiB) TX バイト:2011 (1.9 KiB)   root@sls-IMX6ull14x14EVK:~# ethtool eth0 eth0の設定: 対応ポート:[TP MII ] 対応リンクモード:10baseT/Half、10baseT/Full。 100ベースT/ハーフ 100ベースT/フル サポートされる一時停止フレーム使用:対称 自動交渉を支持:はい 対応FECモード:報告されていません 広告リンクモード:10baseT/ハーフ 10baseT/フル 100ベースT/ハーフ 100ベースT/フル 広告される一時停止フレームの使用:対称 広告された自動交渉:はい 広告されたFECモード:報告されていません リンクパートナーが宣伝しているリンクモード:10baseT/Half、10baseT/Fullです 100ベースT/ハーフ 100ベースT/フル リンクパートナーが一時停止を提示したフレーム使用:いいえ リンクパートナーが自動交渉を宣伝していました:はい リンクパートナーがFECモードを広告している:報告されていません 速度:100Mb/s デュプレックス:フル 自動交渉:オン 移植版:ツイステッドペア ファイアド:3 トランシーバ:外部 MDI-X:不明 ウェイクオン支援:g ウェイクオン:d リンク検出:はい   また、50MHzのクロックも確認しましたが、これは適切に生成され、PHY KSZ8041NLにも入力されています。 要するに、1本のイーサネットは正常に動作していますが、2本目のイーサネットは正常に動作KSZ8081 KSZ8041NL。 解決策をご提案ください。参考までに、両方のイーサネット物理ハードウェアのスクリーンショットも添付しています。 image (1).png image (2).jpg i.MX6 全て i.MX6UL Re: Imx6ull KSZ8041NL ethernet issue NXPチームの皆様、こんにちは。 問い合わせ内容について、何か最新情報があれば教えていただけますか? Re: Imx6ull KSZ8041NL ethernet issue こんにちは、NXPサポートチームの皆さん、 私たちはすでに、私たちが直面しているイーサネットの問題について詳細を共有しています。 ですので、あなたの側で確認して、何か解決があれば教えていただけますか? 必要であれば、お電話にて貴社チームと問題について話し合うことも可能です。 貴社チームからの良いフィードバックをお待ちしております。 よろしくお願いいたします。 リテシュ・プラジャパティ Re: Imx6ull KSZ8041NL ethernet issue こんにちは@HarshilSoni434 @ritesh_prajapat お元気でお過ごしのことと思います。 KSZ8041の回路図のストラップオプションを見てみましょう。 Manuel_Salas_0-1785172670273.png 分離モード:プルアップ(デフォルト)=有効 プルダウン= 無効にする PHYは、RMIIデータピン(RXD0、RXD1、CRS/DV、RX_ER、TXD0、TXD1、TX_EN)をMACから切り離します。 MDIO/MDCは完全に機能しており、PHYも検出され、リンクパルスも生成されています。おそらくこれが、PHYが検出され、リンクがアップ状態に見える理由でしょう。 ISOLATEピンのR37をプルアップ抵抗 (~4.7kΩからGND)に変更してみてもらえますか? 次に確認すべき点はリセットピンです。リセットが正しくアサルされているか確認していただけますか? そして、reset_n信号が以下の接続点に合っているかを確認してください: phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; 次に、CONFIG[2:0] RMII のストラップが物理的に正しく接続されていることを確認してください。 また、KSZ8041の回路図の信号マッピング表には、次の情報が記載されています。 Manuel_Salas_1-1785173206995.png ネット名が入れ替わっているように見えます(MDCはenet_mdioとラベル付けされ、その逆も同様です)。 よろしくお願いいたします。 サラス。 Re: Imx6ull KSZ8041NL ethernet issue @Manuel_Salasさん、ご提案いただきありがとうございます。 お客様からいただいたご提案事項はすべて確認し、結果は大体本日中にご報告いたします。 よろしくお願いいたします。 リテシュ・プラジャパティ Re: Imx6ull KSZ8041NL ethernet issue こんにちは@Manuel_Salas ご返信ありがとうございます。 ご提案通り、プルダウン抵抗の変更を行い、イーサネットの通信も確認しましたが、残念ながら挙動は同じです。 IPネゴシエーション中にRXエラーが発生しています。 また、以下の点についても確認いたしました。 - リセットピンは、imx6ullのピン接続に基づいて適切です。リセットラインに手動でパルスを印加したところ、PHY(KSZ8041NL)はリセットされましたが、動作は同じでした。 - MDIOとMDCのピンの入れ替わりは回路図上の問題であり、実際のハードウェアでは接続は正しく行われています。 つまり、変更後も動作は同じで、両方のPhyは検出されますが、IPはKSZ8081と共に出ていて、KSZ8041NLでは検出されません。以下は更新されたログです: root@sls-IMX6ull14x14evk:~# DMESG |グレップFEC [ 2.124528] FEC 20B4000.イーサネット eth0: 登録済みPHCデバイス0 [ 2.207221 FEC 2188000.イーサネット eth1: 登録済みPHCデバイス1 [ 72.966866] fec 20b4000.イーサネット eth0: リンクは稼働中 - 100Mbps/フル - フロー制御はオフ root@sls-IMX6ull14x14evk:~# DMESG |グレップ eth0 [ 2.124528] FEC 20B4000.イーサネット eth0: 登録済みPHCデバイス0 [ 72.966866] fec 20b4000.イーサネット eth0: リンクは稼働中 - 100Mbps/フル - フロー制御はオフ root@sls-IMX6ull14X14evk:~# ifconfig eth0 リンク encap:イーサネット HWaddr 26:F5:A6:8C:73:42 inet6 addr: FE80::F2af:2D7A:228C:2038/64 Scope:Link UP放送 マルチキャスト実行 MTU:1500 メトリック:1 RXパケット:0 エラー:63 ドロップ:0 オーバーラン:0 フレーム:63 送信パケット:12 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:2093(2.0 KiB) eth1 リンク encap:イーサネット HWaddr 22:81:A6:66:8C:3A UP放送マルチキャスト MTU:1500 メトリック:1 RXパケット:0 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 TXパケット:0 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:0(0.0 B) lo Link encap:ローカルループバック inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host ループバックを走らせる MTU:65536 メトリクス:1 RXパケット:91 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 送信パケット数:91 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 collisions:0 txqueuelen:1000 RXバイト:7797(7.6 KiB) TX バイト:7797(7.6 KiB) root@sls-IMX6ull14x14EVK:~# ethtool eth0 eth0の設定: 対応ポート:[TP MII ] 対応リンクモード:10baseT/Half、10baseT/Full。 100ベースT/ハーフ 100ベースT/フル サポートされる一時停止フレーム使用:対称 車載交渉を支持:はい 対応FECモード:報告されていません 広告リンクモード:10baseT/ハーフ 10baseT/フル 100ベースT/ハーフ 100ベースT/フル 広告される一時停止フレームの使用:対称 広告された車載交渉:はい 広告されたFECモード:報告されていません リンクパートナーが宣伝しているリンクモード:10baseT/Half、10baseT/Fullです 100ベースT/ハーフ 100ベースT/フル リンクパートナーが一時停止を提示したフレーム使用:いいえ リンクパートナーが車載交渉を宣伝していました:はい リンクパートナーがFECモードを広告している:報告されていません 速度:100Mb/s デュプレックス:フル 車載交渉:オン 移植版:ツイステッドペア ファイアド:0 トランシーバ:外部 MDI-X:不明 ウェイクオン支援:g ウェイクオン:d リンク検出:はい ぜひご提案をお願いします。 Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん さらにイーサネットFECドライバ fec_main.Cへのデバッグも行いましたRXエラーの根CASEを特定するために。 その結果、ドライバがCRCの不一致エラー BD_ENET_RX_CRのためにすべてのrxパケットを無視していることがわかりました。 SO これを踏まえて、問題解決のためのご提案をお願いします。 Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん、 前回の観察結果に基づくと、何か最新情報はありますか? CRCエラーのため、すべての受信パケットが無視されることを改めてお知らせします。SO、何がその原因になり得るCANでしょうか? Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん、 おはよう、 すでに共有された問題に関する直近のアップデート@HarshilSoni434確認する機会はありましたか?CRCミスマッチの受信パケットの正確な問題を絞り込むために、何か手がかりや追加の発見があれば教えていただけませんか? 弊社側で何か情報が必要な場合はお知らせください。 よろしくお願いいたします。 リテシュ・プラジャパティ
View full article
Feeの最初の読み取りプログラムがクラッシュしました S32K311マイクロコントローラのFEE機能を使用してデータを保存しています。消去と書き込みのFEEテストは正常に動作しますが、データが書き込まれていない状態での最初の読み出し試行で、ロードに失敗してクラッシュします。C40と同様に、最初の読み出しでは0xFFが返されるため、これを使用して最初の読み書き操作を識別し、デフォルト値を設定できます。最初のFEEでクラッシュする代わりに0xFFのような値を返すようにする方法はありますか?RTD 4.0.0を使用しています。 Re: Fee首次读取程序跑飞 こんにちは@ LJH1 Fee_Read() を初めて呼び出す場合、事前に書き込みを行う必要はありません。ただし、ブロックに一度も書き込みが行われていない場合、読み取り処理は MEMIF_BLOCK_INVALID または MEMIF_BLOCK_INCONSISTENT を返す可能性があります。アプリケーション層は、これを「未初期化」として扱い、デフォルト値を書き込む必要があります。 最初の読み取りで有効なデータを直接読み取ろうとしないでください。正しい方法は、読み取り後にジョブの結果を確認し、無効なデータや矛盾したデータが見つかった場合はデフォルト値を初期化して書き込むことです。 Senlent_0-1783662229362.png
View full article
i.MX8M PlusおよびTIM-VX/VSINPU上のGC7000UL汎用演算推論パスはNPU専用であるように見える 理事会/BSP: i.MX8M Plus、aarch64 Galcore バージョン 6.4.11.p2.745085 VSINPUExecutionProviderを用いたONNXランタイム(libtim-vx.so に対して静的リンク) Vivante OpenCL ICDの存在と機能(Vivante.icd → libVivanteOpenCL.so) 目標: GC7000UL 3D GPUコア上でResNet50推論ベンチマーク(MLPerfロードゲンハーネス)を実行し、既存のNPU(VIP8000Nano)やCPUベンチマークの結果と比較します。 動作確認済みの項目: Vivante OpenCL ICDを経由したclGetPlatformIDs/clGetDeviceIDsは、1つのプラットフォーム上で2つの独立したデバイスをきれいに列挙します。 デバイス0:GC7000UL.6204.0000 デバイス1:VIP8000Nano-S+I.8002.0000 両者とも、CL_DEVICE_TYPE_ACCELERATORを報告し、エラーはなく、libOpenCL.so → libGAL.so と連携した最小限のCテストプログラムで確認されました。 ORT経由でGPUディスパッチを妨げている原因: ort.get_available_providers()は['VSINPUExecutionProvider', 'CPUExecutionProvider']のみを返します — OpenCLベースのEPはありません。 VSINPUExecutionProviderは静的にリンク libtim-vx.so(OVXLIB/vsi_nn_* API)です。libtim-vx.so と libGAL.so の両方のシンボル/文字列ダンプでは、DEVICE_INDEX/DEVICE_IDスタイルのenv varやconfig surfaceは表示されず、動作の切り替え(VIV_VX_ENABLE_SHADER、VSI_NN_ENABLE_*など)のみが表示されます。 libGAL.so 生のHALレイヤーでgcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndexをエクスポートしますが、OVXLIB/TIM-VXからその呼び出しまでの配管は見当たりません。これは、VSINPUが使うグラフコンパイラがデバイスインデックスに関係なくNPUコアのみをターゲットにしている可能性を示唆しています。 具体的な質問: このBSP(galcore 6.4.11.p2)上のTIM-VX / OVXLIBは、グラフをコンパイルして一般的な計算対象としてGC7000ULにディスパッチするのをサポートしているのでしょうか?それともこのビルドではグラフコンパイラは設計上NPUのみ対応されているのでしょうか?また、その方法で実行可能かどうかはどうやって確認すればよいのでしょうか? もしTIM-VXの上流でGPUターゲットグラフコンパイルがサポートされているのに、このNXP搭載ビルドでは有効になっていない場合、それを公開するビルドフラグやSDKコンポーネントはありますか? TIM-VX/ORTを通るサポート済みの経路がない場合、NXPが推奨する汎用推論をGC7000UL上で直接実行する方法(例えばOpenCL/OpenVXレイヤー経由、その部分は機能が確認されているため)やサンプルアプリ、SDKコンポーネント、または参照実装などを基準に構築する方法はありますか? 現在学生で、この実装に取り組みながらGPUの上にORTを動かそうとしているのですが、GPUを使って推論できる方法、あるいは他に何か方法はありますか? どうもありがとうございます。 IMX8MPLUS #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 @WaleedO さん。 NXPサポートまでご連絡いただきありがとうございます。 GPU上で推論を実行するにはGPUデリゲートを使うべきで、これを使うとサポートされた操作をCPUだけで動作するのではなくGPUで加速できます。 利用可能な実行バックエンド、設定の委任、サポートフレームワーク、例のアプリケーションをよりよく理解するために、 Machine Learning ユーザーガイド の確認をお勧めします。ガイドには、GPUデリゲートが正しく読み込まれているか、モデルが期待通りに動作しているかを確認するためのステップバイステップの例も含まれています。 セットアップや実行中に問題が発生した場合は、モデル、BSPバージョン、使用しているコマンドを共有していただければ、喜んでサポートいたします。 よろしくお願いします、 アレハンドロ・ガルシア Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 @Chavira はじめまして。 ドキュメントを確認すると、GPUデリゲートとOpenCLパスは95/952 GPU(Arm Mali G310)内で i.MX 使われています。現在、『The IMX8MPLUS』に取り組んでいます。 IMX8M Plusは以下のスタックを持っています:VX delegate ==> TIM-VX ==> GPU/NPU(統一ドライバー)==> I.MX 8シリーズNPU、 GPU(GC7000,GC7000L、GC7000UL)。ドキュメントによると。 現在、私はONNXとORTを扱っています。実行時には、デフォルトでNPU上で実行されます。OpenCLを使って IMX8MPLUS GPUで作業する方法はありますか?あるいは、コンパイルをNPUかGPUに手動で設定できる手動オーバーライドや技術があれば教えてください。 ご返信いただき、誠にありがとうございます。 敬具、 IMX8MPLUS #TIM-VX #VX-delegate
View full article
关于在多个 AB_SWAP 位置使用 IVT 的说明 (S32K328) 您好,NXP团队: 我正在使用 AB_SWAP 和 HSE_B 进行 S32K328 内存布局,我需要澄清 IVT 位置应该如何处理。 摘自S32K3xx参考手册: IVT 是定义在闪存中固定位置的主要启动入口结构。 IVT 包含指向应用程序映像、启动配置和可选身份验证数据的指针。 在 AB_SWAP 配置中,根据设备和设置的不同,有多个与启动和映像选择相关的已定义闪存区域/地址。 在 S32K328 的内存映射表中,我看到: IVT 位于0x0040_0000 (活动银行) 0x0060_0000 (在同一存储区)处还有另一个对齐区域,这似乎与某些布局中的启动/优先级处理或保留空间有关。 问题: 静脉输液 IVT 是否预期仅存在于每个银行的主要位置(例如,0x0040_0000) ? 或者,是否存在任何要求(或支持的情况),要求在另一个地址(例如0x0060_0000 )也必须存在 IVT(或类似 IVT 的结构)? AB_SWAP 中的多个 IVT 地址 当 RM 显示多个与 IVT 相关的地址(例如,0x0040_0000、0x0050_0000、0x0060_0000 等)时,这些地址分别代表什么? 单独的 IVT 实例,或 同一 IVT 概念下是否使用了备用启动插槽/优先级位置? 使用辅助/备用区域 如果像 0x0060_0000 这样的区域没有明确记录为包含 IVT: 应该保留吗? 它可以安全地用于应用程序数据/元数据吗? 最佳实践 对于 AB_SWAP + HSE 安全启动系统,关于 IVT,这些附加对齐地址的建议解释是什么? 语境: 设备:S32K328 启动模式:AB_SWAP 网络安全:HSE_B,已启用安全启动 目标:正确的启动行为和安全的内存分配 S32K3 #s32k328 Re: Clarification on IVT usage at multiple AB_SWAP locations (S32K328) 嗨@venkatesh-kv 1.在任何可用的已定义地址处,一个 IVT 就足够了。它不一定要是像 0x40_0000 这样的主要位置。SBAF 负责按给定顺序搜索有效的 IVT。 如果在 IVT 更新期间出现问题,可以选择使用第二个 IVT 作为备份。这通常是在 IVT 的启动配置字中的 BOOT_SEQ 位启用安全启动时发生的。 2. S32K328 在 AB_SWAP 模式下有三个可能的 IVT 位置:0x40_0000、0x60_0000、0x1000_0000。SBAF 按此顺序搜索有效的 IVT。地址越靠下,优先级越高。例如,如果 0x40_0000 处存在有效的 IVT,SBAF 将使用此 IVT,而不会检查其他位置。 3. 不必保留该区域,您可以将其用于您的代码或数据。 4. 对于此用例,如前所述,其他 IVT 位置可用作备份。安全启动应用笔记的“6.2 更新 IVT”部分也对此进行了讨论。 可从以下网址下载: https://www.nxp.com/products/S32K3 应用笔记请点击此处查看: 文档 -> 安全文件 -> 安全启动应用笔记 v0.1.1.0(AN744511) 相关演示项目可在此处下载: 设计资源 -> 软件 -> 安全文件 -> SecureBootAppNoteDemo (SW745310) 问候, 卢卡斯
View full article