What Is Model-Based Design? A Practical Introduction for Modern Embedded Systems   Table of Contents Why embedded development needs a better workflow What Model-Based Design is A simple mental model: from idea to executable model to hardware Why engineers use it: the core advantages Verification along the way: MIL, SIL, PIL, HIL How NXP enables this with Model-Based Design Toolbox (MBDT) What comes next in this article series 1 Why embedded development needs a better workflow Modern embedded systems are no longer isolated functions running on a single controller. In today's vehicles and intelligent machines, applications span sensing, communication, control, safety logic, diagnostics, and multiple processing nodes that must work together as one system. As this complexity grows, traditional workflows based mainly on handwritten code and late-stage hardware testing become difficult to scale, hard to validate early in the development cycle, and slow to iterate. Issues are often discovered late, when integration becomes more costly and harder to manage. Model-Based Design offers an alternative approach designed to address these challenges. It enables earlier validation and a more structured development flow, where verification is not an afterthought, but part of every stage of development. 2 What Model-Based Design is   Model-Based Design is a visual way of programming, where you build your functionality by drawing an engineering diagram, and that diagram can be executed—either as a simulation on your computer or as code running on real hardware. In this approach, models become the central engineering artifact used to design, simulate, verify, and deploy embedded systems. Instead of starting from low-level implementation details, engineers create an executable model of the application behavior, simulate, verify, refine it, and then generate code for the target system. This model-centric workflow makes designs easier to understand, easier to reuse, and less prone to errors. It also enables model-based testing, where test cases can be derived directly from system models and used to verify behavior early in development. 3 A simple mental model: from idea to executable model to hardware A simple way to think about Model-Based Design is this: you describe what the system should do in an executable model, validate that behavior in simulation, and then carry the same design through to the final implementation. In this approach, the model is not just documentation—it becomes an active engineering asset used for design, simulation, verification, and code generation. This creates a direct path from idea to application, where requirements, design, prototyping, testing, and deployment are connected in one continuous workflow. 4 Why engineers use it: the core advantages One of the biggest advantages of Model-Based Design is that it changes where engineering effort is spent. Instead of focusing primarily on how to implement functionality at a low level, engineers can focus on what the system should do—its behavior, control strategy, and response to real-world scenarios. This approach also enables early validation. System behavior can be simulated on a PC before the final hardware is available, allowing issues to be detected earlier and reducing costly rework late in the development cycle. In addition, Model-Based Design enables hardware-independent simulation, where algorithms can be developed and validated before being tied to a specific target platform. This allows teams to explore designs faster and reuse validated functionality across different hardware solutions. As a result, teams benefit from: faster iteration during development improved traceability between design and implementation reduced integration risk more consistent validation across development stages Ultimately, this contributes directly to faster time-to-market, as development cycles are shortened and fewer late-stage issues need to be addressed. Some concrete examples can be found in the following articles: From Virtual Vehicle to All-Electric Off-Road UTV in Less Than a Year Dyson Accelerates New Product Development with System-Level Simulation 5 Verification along the way: MIL, SIL, PIL, HIL A key strength of Model-Based Design is that validation happens continuously throughout development. This is typically organized into several stages: Model-in-the-Loop (MIL): the model is tested against a simulated environment Software-in-the-Loop (SIL): generated code is executed on the host PC and compared to model behavior Processor-in-the-Loop (PIL): code runs on the target MCU to verify functional correctness and performance Hardware-in-the-Loop (HIL): the controller is tested against a real-time or emulated system before final deployment These stages provide a structured validation path, ensuring that issues are detected early and confidence is built progressively before running on final hardware. Model-Based Design also supports reuse and scalability. A validated model can be adapted, parameterized, or reused across multiple systems, reducing development effort and improving consistency. 6 How NXP enables this with Model-Based Design Toolbox (MBDT) To make this workflow practical on real embedded hardware, NXP provides the Model-Based Design Toolbox (or MBDT). This acts as a bridge between the MathWorks' and NXP's software ecosystems, and allows the entire workflow to be done from one environment, as depicted in the diagram above. Concretely, this allows engineers to use MATLAB and Simulink to design, simulate, verify, and automatically generate code that can run directly on NXP microcontrollers and processors. MBDT provides: block libraries for hardware access integration with configuration tools for pins, clocks, and peripherals support for PIL workflows code generation and deployment capabilities profiling and runtime monitoring through tools like FreeMASTER This creates a complete end-to-end flow—from model to validated application running on target hardware. Engineers can explore functionality at a high level, validate behavior through simulation, and deploy with confidence onto real systems. 7 What comes next in this article series In the articles that follow, we will move from this general introduction to concrete, real application examples. We will show how Model-Based Design and NXP tools can be applied across a modern system architecture, covering applications such as battery management, motor control, radar, steering, lighting, and parking sensors. Each example will illustrate how functions can be designed, validated in simulation, and deployed onto the appropriate hardware nodes. The key idea is simple: Model-Based Design helps engineers focus on system behavior while reducing the gap between concept, implementation, and validation. With NXP's Model-Based Design Toolbox, this approach can be carried from the modeling environment all the way to a running application on hardware. MBDT  https://www.nxp.com/mbdt https://mathworks.com/nxp 

How to install .MLTBX 1 Table of Contents • Overview • Executive Summary - What is .MLTBX • Context - Where to obtain the .mltbx file • Method 1 - Manual Installation (.mltbx) • Method 2 - Install via NXP Support Package • Method 3 - Automotive Software Package Manager • Conclusion 2 Overview NXP provides a range of MATLAB ® Toolboxes distributed as .mltbx packages to support modeling, simulation, configuration, and code generation for NXP microcontrollers and processors. These toolboxes integrate directly with the MathWorks environment and enable faster development workflows by extending MATLAB/Simulink with NXP-specific blocks, drivers, and examples. The scope of this article is to guide users through the process of installing an NXP .mltbx toolbox obtained from the official NXP website. It explains the prerequisites, where to download the toolbox, and how to install and verify it within MATLAB. The instructions are intended for engineers and developers who have basic familiarity with MATLAB but may be new to installing third-party toolboxes distributed outside of MathWorks Add-Ons. By following this guide, readers will be able to correctly install the NXP toolbox, ensure it is recognized by MATLAB, and prepare their environment for subsequent development and evaluation tasks. 3 Executive Summary - What is .MLTBX An .mltbx file is a MATLAB Toolbox package used to distribute and install MATLAB or Simulink extensions. It is a self-contained archive created by MathWorks that can include functions, Simulink blocks, documentation, examples, and setup scripts. When opened in MATLAB, an .mltbx file is installed using the Add-On Manager, which automatically places the toolbox in the default add-ons folder, and registers the toolbox within the environment. This format allows third-party vendors - such as NXP - to safely deliver toolboxes outside of the MathWorks Add-On Explorer while preserving a standard installation experience. In short, a .mltbx file is the official and recommended way to package, install, update, and uninstall MATLAB toolboxes. 4 Context - Where to obtain the .mltbx file There are multiple ways to get the .mltbx file, as shown below: Manual download and install - from NXP site (.mltbx file) Installation via MATLAB - Add-Ons / toolbox flow (NXP Support Package) Installation via Automotive Software Package Manager - bundle installer All methods are valid and can be used depending on your setup and preferences. The Automotive Software Package Manager approach installs bundles and generates an installer that walks through the steps automatically. Prerequisites Before installing the toolbox, ensure the following: MATLAB is installed on your machine You have access to the toolbox download source Note: The .mltbx file cannot be used without MATLAB. The toolbox is only available for Windows and may require additional prerequisites such as: Embedded Coder MATLAB Coder Simulink Coder 5 Method 1 - Manual Installation (.mltbx) The manual installation flow is simple, once prerequisites are met. Manually download the .mltbx file from the NXP site and install it. Typical install behavior: Open MATLAB → run or double-click the .mltbx file → install → toolbox is added automatically. Installed toolboxes are placed under MATLAB Add-Ons directories and appear in the Add-On Explorer. Step 1 - Select the toolbox family As a first step, on the NXP site, select "Automotive SW - Model-Based Design Toolbox". Step 2 - Select the target software In our example, we are selecting "Automotive SW - S32K3 Software". Step 3 - Select the S32K3 Model-Based Design Toolbox Select "Automotive SW - S32K3 - Model-Based Design Toolbox". Step 4 - Choose Product Information Select the Product Information: "Model-Based Design Toolbox S32K3 1.8.0". Step 5 - Accept Software Terms and Conditions The Software Terms and Conditions will appear - select "I Agree". Step 6 - Download the .mltbx file After the terms and conditions agreement, you can download the .mltbx file. When downloading, save the file under the .zip extension, as shown below. Step 7 - Reveal file extensions in Windows To see and change the file extension, follow the next steps: Press the three dots visible below: Select "Options". Deselect "Hide extensions for known file types". Press Apply and OK. After this update, the file will be visible with its extension. Step 8 - Change the file extension to .mltbx Change the file extension from .zip to .mltbx : A pop-up will appear - press "Yes": View after changing the file from .zip to .mltbx: Step 9 - Install the toolbox in MATLAB Double-click the .mltbx file and accept the License Agreement. The installation process will start and it will take a few moments to be finalized.  Installation Finalized   Toolbox registered in MATLAB Add-On Manager  6 Method 2 - Install via NXP Support Package The NXP Support Package add-on is a guided installer that: Checks and validates all installation prerequisites Directs users to the page where the required .mltbx package can be downloaded Allows users to select the .mltbx package to install Provides the option to open relevant documentation resources Step 1 - Open MATLAB Launch MATLAB. Step 2 - Navigate to Add-Ons Go to: Add-Ons → Get Add-Ons. Step 3 - Install the toolbox Load the toolbox file or follow your internal download process. Note: Direct download via Add-On Explorer may not always be available, depending on licensing and setup. 7 Method 3 - Automotive Software Package Manager This method uses the Automotive Software Package Manager, which installs bundles and generates an installer that walks through the steps automatically. Step 1 - Access Package Manager Use the Automotive Software Package Manager. Step 2 - Select required components Choose: Target platform - e.g. S32K3 Required tools - e.g. FreeMASTER, Model-Based Design Toolbox Step 3 - Generate installer The tool generates a bundle installer. Step 4 - Run installer Run the generated installer. Follow the step-by-step instructions. 8 Conclusion Installing an NXP .mltbx toolbox is straightforward once the MATLAB prerequisites are in place. Depending on your workflow, you can choose the manual .mltbx installation, the guided NXP Support Package, or the Automotive Software Package Manager bundle installer - all three methods produce a properly registered toolbox inside MATLAB. With the toolbox installed and verified, your environment is ready to start developing, simulating, and generating code for NXP microcontrollers and processors. Stay tuned for the next article, where we will dive into using the newly installed toolbox to build your first Model-Based Design project.

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 アセンブリファイルのプロパティを開き、C/C++ ビルド --> 設定 --> Diab アセンブラ --> その他 --> その他のオプションとフラグに -tPPCE200Z4NEG:simple を追加したところ、コンパイルが正常に完了しました。しかし、デバッグ中に、実際にコアテストを実行する`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. メモリモデルの誤り/VLEの不一致 4. 別のデバイス用に構築されたSCSTライブラリ 5. MMU/TLB変換の問題 よろしくお願いいたします。 ピーター

複数の*IPアドレスを1つのイーサネットインターフェースにマッピングする(LWIP) こんにちは、 複数のIPアドレスを1つのイーサネットポートに異なるstruct netif論理インターフェースでバインドしようとしています。現在の実装では、動作させるために1つのインターフェースを無効にしています。 適切なアプローチに関するガイダンスや情報源を求めている。どんなご意見でも歓迎いたします。 ありがとうございます int main ( void ) { struct netif netif1 , netif2 ; 整数ret ; ip4_addr_t netif1_ipaddr 、 netif1_netmask 、 netif1_gw ; ip4_addr_t netif2_ipaddr 、 netif2_netmask 、 netif2_gw ; ethernetif_config_t enet_config = { . phyHandle = & phyHandle , . phyAddr = EXAMPLE_PHY_ADDRESS 、 . phyOps = EXAMPLE_PHY_OPS 、 . phyResource = EXAMPLE_PHY_RESOURCE 、 } ; BOARD_ConfigMPU () ; BOARD_InitPins () ; BOARD_BootClockRUN () ; BOARD_InitDebugConsole () ; BOARD_InitModuleClock () ; SCB_DisableDCache () ; IOMUXC_SelectENETClock () ; BOARD_InitBothEnetPins_test () ; BOARD_ENET_PHY1_RESET ; EnableIRQ ( ENET_1G_MAC0_Tx_Rx_1_IRQn ) ; EnableIRQ ( ENET_1G_MAC0_Tx_Rx_2_IRQn ) ; MDIO_Init () ; g_phy_resource.read = MDIO_Read ;​​ g_phy_resource.write = MDIO_Write ;​​ time_init () ; CRYPTO_InitHardware () ; lwip_init () ; 最初の論理インターフェースとそのIP構成を追加する IP4_ADDR ( & netif1_ipaddr , 192 , 168 , 0 , 102 ) ; IP4_ADDR ( & netif1_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR ( & netif1_gw , 192 , 168 , 0 , 100 ) ; netif_add ( & netif1 , & netif1_ipaddr , & netif1_netmask , & netif1_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_default ( & netif1 ) ; netif_set_up ( & netif1 ) ; 2つ目の論理インターフェースとそのIP構成を追加する IP4_ADDR ( & netif2_ipaddr , 192 , 168 , 0 , 111 ) ; IP4_ADDR ( & netif2_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR ( & netif2_gw , 192 , 168 , 0 , 100 ) ; netif_add ( & netif2 , & netif2_ipaddr , & netif2_netmask , & netif2_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_up ( & netif2 ) ; while ( 1 ) { // 両方のnetifから受信フレームをポーリングする ethernetif_input ( & netif1 ) ; ethernetif_input ( & netif2 ) ; sys_check_timeouts () ; // すべてのコアプロトコルのすべてのシステムタイムアウトを処理します } -1を返す; } Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) LWIPで複数のIPアドレスを単一のイーサネットインターフェースにマッピングすることは、異なるネットワーク識別子やサービスを1つの物理接続で扱う必要があるシステムで有用です。重要なのは、IP設定、ルーティング、ARP処理が適切に管理され、各アドレスが競合なく正しく応答することです。組み込みネットワークソリューションを設計する際には、利用可能なハードウェアオプションや、柔軟なネットワーク構成と信頼性の高い通信をサポートする Explore Networking Products を理解することも役立ちます。異なるネットワークシナリオでの適切なテストは、パケット処理やインターフェース設定に関連する問題を特定するのに役立ちます。 Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) こんにちは。問題を投稿されてからかなり時間が経ちましたが、何か解決策は見つかりましたか？ 現在、TI TMS570LC43 LaunchPadとlwIP 1.4.1バージョンを使用して同じことを試しています。

Gui_Guider在生成C code时会出现卡死的情况 在导入字体文件后生成C代码会出现一直生成的情况，我将页面缩减成一个，去除图标生成一个简单的界面也会一直卡在Generating C code的情况。 Re: Gui_Guider在生成C code时会出现卡死的情况 我发现原因就是我直接在Gui_Guider里导入一个新的字体然后Generating C code就会出现卡死，我如何解决这个问题？

将多个 IP 地址映射到一个以太网接口（LWIP） 你好， 我正在尝试使用不同的 struct netif 逻辑接口将多个 IP 地址绑定到单个以太网端口。我目前的实现方法是禁用其中一个接口才能使其正常工作。 寻求有关正确方法的指导或资源。任何见解都非常感谢。 谢谢！ int main ( void ) { struct netif netif1 , netif2 ; int ret ； ip4_addr_t netif1_ipaddr 、 netif1_netmask 、 netif1_gw ； ip4_addr_t netif2_ipaddr 、 netif2_netmask 、 netif2_gw ； ethernetif_config_t enet_config = { . phyHandle = & phyHandle , .phyAddr = EXAMPLE_PHY_ADDRESS ，​ .phyOps = EXAMPLE_PHY_OPS ，​ .phyResource = EXAMPLE_PHY_RESOURCE ，​ } ； BOARD_ConfigMPU () ; BOARD_InitPins () ; BOARD_BootClockRUN () ; BOARD_InitDebugConsole () ; BOARD_InitModuleClock () ; SCB_DisableDCache () ; IOMUXC_SelectENETClock () ; BOARD_InitBothEnetPins_test () ; BOARD_ENET_PHY1_RESET ； 启用IRQ （ ENET_1G_MAC0_Tx_Rx_1_IRQn ） ； 启用IRQ （ ENET_1G_MAC0_Tx_Rx_2_IRQn ） ； MDIO_Init () ; g_phy_resource.read = MDIO_Read ;​​ g_phy_resource.write = MDIO_Write ;​​ time_init () ; CRYPTO_InitHardware () ; lwip_init () ; // 添加第一个逻辑接口及其 IP 配置 IP4_ADDR （ & netif1_ipaddr ， 192，168，0，102 ） ；​​​​​​ IP4_ADDR ( & netif1_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR （ & netif1_gw ， 192，168，0，100 ） ；​​​​​​ netif_add ( & netif1 , & netif1_ipaddr , & netif1_netmask , & netif1_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_default ( & netif1 ) ; netif_set_up ( & netif1 ) ; // 添加第二个逻辑接口及其 IP 配置 IP4_ADDR （ & netif2_ipaddr ， 192，168，0，111 ） ；​​​​​​ IP4_ADDR ( & netif2_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR （ & netif2_gw ， 192，168，0，100 ） ；​​​​​​ netif_add ( & netif2 , & netif2_ipaddr , & netif2_netmask , & netif2_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_up ( & netif2 ) ; while ( 1 ) { // 轮询两个网络接口以获取传入帧 ethernetif_input （ & netif1 ） ； ethernetif_input （ & netif2 ） ； sys_check_timeouts () ; // 处理所有核心协议的系统超时 } 返回-1 ； } Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) 在 LWIP 中，将多个 IP 地址映射到单个以太网接口，对于需要通过一个物理连接处理不同网络身份或服务的系统来说非常有用。关键在于确保 IP 配置、路由和 ARP 处理得到正确管理，以便每个地址都能正确响应而不会发生冲突。在设计嵌入式网络解决方案时，了解可用的硬件选项并探索支持灵活网络设置和可靠通信的网络产品也很有帮助。使用不同的网络场景进行适当的测试有助于发现与数据包处理和接口配置相关的问题。 Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) 您好，您发布这个问题已经有一段时间了，请问您找到解决方法了吗？ 我目前正在使用TI TMS570LC43 Launchpad和lwIP 1.4.1版本尝试同样的操作。

RT1064 : pin configuration to boot from internal flash Hello, This may sound as a dumb/noob question but I can't determine precisely what must be done on the BOOT_MODE1/BOOT_MODE0 and BT_CFG[11..0] pins to configure the RT1064 to boot from its internal flash memory. Table 9.9 from the reference manual lists only 3 boot sources (NOR flash via FlexSPI, SDCARD and eMMC) but the internal flash is not listed, as if this section has been copied/pasted from RT1060... AN12290 mentions a FlexSPI2 internal bus to this internal flash but does not indicate how to select it over the 3 above-mentionned boot sources. Table 5 from the MIMXRT1060/1064 Evaluation Kit Board Hardware User's Guide indicates that 2 boot modes only are availble (QSPI or SDCARD) and also claims that QSPI boot is not available (note from 2.7 paragraph), leaving SDCARD as the sole boot source... Any help greatly appreciated i.MXRT 106x

mapping multiple * IP addresses to one Ethernet interface (LWIP) Hello, I'm attempting to bind multiple IP addresses to a single Ethernet port using different struct netif logical interfaces. My current implementation involves disabling one interface for it to work. Seeking guidance or resources on the correct approach. Any insights appreciated. Thanks, int main(void) { struct netif netif1, netif2; int ret; ip4_addr_t netif1_ipaddr, netif1_netmask, netif1_gw; ip4_addr_t netif2_ipaddr, netif2_netmask, netif2_gw; ethernetif_config_t enet_config = {.phyHandle = &phyHandle, .phyAddr = EXAMPLE_PHY_ADDRESS, .phyOps = EXAMPLE_PHY_OPS, .phyResource = EXAMPLE_PHY_RESOURCE, }; BOARD_ConfigMPU(); BOARD_InitPins(); BOARD_BootClockRUN(); BOARD_InitDebugConsole(); BOARD_InitModuleClock(); SCB_DisableDCache(); IOMUXC_SelectENETClock(); BOARD_InitBothEnetPins_test(); BOARD_ENET_PHY1_RESET; EnableIRQ(ENET_1G_MAC0_Tx_Rx_1_IRQn); EnableIRQ(ENET_1G_MAC0_Tx_Rx_2_IRQn); MDIO_Init(); g_phy_resource.read = MDIO_Read; g_phy_resource.write = MDIO_Write; time_init(); CRYPTO_InitHardware(); lwip_init(); // Add the first logical interface with its IP configuration IP4_ADDR(&netif1_ipaddr, 192, 168, 0, 102); IP4_ADDR(&netif1_netmask, 255, 255, 255, 0); IP4_ADDR(&netif1_gw, 192, 168, 0, 100); netif_add(&netif1, &netif1_ipaddr, &netif1_netmask, &netif1_gw, &enet_config, EXAMPLE_NETIF_INIT_FN, ethernet_input); netif_set_default(&netif1); netif_set_up(&netif1); // Add the second logical interface with its IP configuration IP4_ADDR(&netif2_ipaddr, 192, 168, 0, 111); IP4_ADDR(&netif2_netmask, 255, 255, 255, 0); IP4_ADDR(&netif2_gw, 192, 168, 0, 100); netif_add(&netif2, &netif2_ipaddr, &netif2_netmask, &netif2_gw, &enet_config, EXAMPLE_NETIF_INIT_FN, ethernet_input); netif_set_up(&netif2); while (1) { // Poll both netifs for incoming frames ethernetif_input(&netif1); ethernetif_input(&netif2); sys_check_timeouts(); // Handle all system timeouts for all core protocols } return -1; } Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) Mapping multiple IP addresses to a single Ethernet interface in LWIP can be useful in systems that need to handle different network identities or services through one physical connection. The key is ensuring the IP configuration, routing, and ARP handling are properly managed so each address responds correctly without conflicts. When designing embedded networking solutions, it also helps to understand the available hardware options and Explore Networking Products that support flexible network setups and reliable communication. Proper testing with different network scenarios can help identify issues related to packet handling and interface configuration. Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) Hello, It's been quite some time since you posted the issue but did had any luck figuring this out?  I am currently trying the same thing with a TI TMS570LC43 launchpad and lwIP 1.4.1 version

RT1064:内部フラッシュから起動するためのピン構成 こんにちは、 これは初心者や初心者の質問に聞こえるかもしれませんが、RT1064を内蔵フラッシュメモリから起動させるためにBOOT_MODE1/BOOT_MODE0とBT_CFG[11..0]ピンで何をすべきか正確にはわかりません。 参考マニュアルの表9.9には、3つのブートソース(FlexSPI経由のNORフラッシュ、SDCARD、eMMC)のみが記載されていますが、内部フラッシュは記載されていません。まるでこのセクションがRT1060からコピー&ペーストされたかのようです... AN12290はこの内部フラッシュへのFlexSPI2内部バスについて言及していますが、上記の3つの起動ソースで選択する方法は示していません。 MIMXRT1060/1064 Evaluation Kit Board Hardware ユーザーガイドの表5では、起動モードはQSPIかSDCARDの2種類のみが利用可能であり、QSPIブートは利用できないと主張しています(2.7段落からの注釈)、SDカードのみが唯一の起動源となっています... どんなご支援でも大変ありがたく思います。 i.MXRT 106x

MPC5644A core test I am attempting to perform a core test on the MPC5644A chipset. My current environment is Eclipse and Wind River. I downloaded the manufacturer's library, e200Zx_ICST_RTMC_3.0.0, which contains several assembly source (.s) files. Of these, vle compiles successfully. However, book_e and spe fail to compile. During compilation, errors occurred in various assembly instructions such as bc, bcl, bclr, xoris, bclrl, and bcctrl. I opened the properties of the book_e and spe assembly files and added -tPPCE200Z4NEG:simple to C/C++ Build --> Settings --> Diab Assembler --> Other --> Other options and flags, and successfully completed the compilation. However, during the debugging process, I reach just before `Fsl_call_test_execution_icst` in `fsl_self_test_icst.c`, which actually executes the core test. If I proceed to the next step, I fall into an infinite loop. Checking with Eclipse's disassembly, I found that when I step into address 0x51518 (immediately after the start of `SPE_ICST_int_logical_test`), it jumps immediately to 0x3f2b90 (an empty space). What should I do? I don't know where to start. Re: MPC5644A core test Hello, SCST supports only following devices from MPC56xx family: MPC560xP MPC564xB-C Since MPC5644A and MPC564xB share the same e200z4 CPU core, the CPU-focused portions of an SCST library may be adaptable. However, all integration aspects must be reviewed: Exception vector addresses Memory maps Clock initialization Peripheral dependencies Linker script assumptions The actual CPU test algorithms should be largely portable because they target the same e200z4 architecture. NXP does not provide an official SCST library for the legacy MPC5644A device. However, since MPC5644A uses the same e200z4 core as the MPC564xB family, it may be possible to adapt CPU-focused self-test routines from MPC564xB solutions after reviewing device-specific integration details. Alternatively, a custom startup diagnostic implementation can be developed using the MCU's built-in safety mechanisms (ECC, CRC, watchdog, MPU, exception handling) to satisfy project-specific functional safety requirements. What should I do? I don't know where to start. If the code enters SPE_ICST_int_logical_test() at 0x51518 and then immediately branches to 0x3F2B90, which appears to be empty memory, my first suspicion would not be a CPU failure but rather a linker / library integration issue. For an SCST library, this usually means one of the following: 1. Function pointer or branch table not linked correctly 2. Missing library object 3. Wrong memory model / VLE mismatch 4. SCST library built for another device 5. MMU/TLB translation issue best regards, Peter

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 验证时，这样做是否合适。 谢谢！

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

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.

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検証を使う場合にそれが適切かどうかについてです。 よろしくお願いします。

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

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

使用 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”的符号链接：没有这样的文件或目录

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'へのシンムリンクを作成できません:そのようなファイル、又はディレクトリはありません

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

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を参照してください。