Building AI/ML Devices at the Edge? Start with FRDM From smart sensing and anomaly detection to computer vision, voice interfaces, and even multimodal GenAI—AI/ML use cases are rapidly moving onto the device. But if you're an engineer getting started, the real questions usually are: What hardware should I use? What tools actually work for embedded AI? Do I need the cloud for everything? Let’s break it down ! Why Edge AI? Running AI directly on-device enables: Real-time decisions (low latency) Better privacy Offline operation (no cloud dependency) Optimized power consumption That’s exactly where the FRDM development platform comes in. Quick Positioning: From MCU to Edge AI Processor Category Boards AI Capability Level Typical Use Case MCU (Low Power Edge ML) FRDM-MCXA156 + ⭐ sensor AI, TinyML MCU + Neural Acceleration FRDM-MCXN947 ++ ⭐⭐ Edge AI with vision/audio, TinyML Application Processor (Entry Edge AI) FRDM-IMX93 +++ ⭐⭐⭐ HMI + AI inference High-Performance Edge AI FRDM-IMX8MPLUS ++++ ⭐⭐⭐⭐ Vision AI, Advanced HMI Next-Gen AI + Safety FRDM-IMX95 / PRO +++++ ⭐⭐⭐⭐⭐ Gen AI, Advanced Edge Computing AI/ML applications can run on general-purpose hardware, but leveraging dedicated hardware acceleration significantly improves performance, enables faster results, and reduces power consumption. Below is a reference list of FRDM development boards that support AI/ML applications, helping you choose the right platform based on your target use case   Board Positioning AI Acceleration Hardware Capabilities (AI-relevant) Best For FRDM-MCXA156 Entry-level MCU (TinyML)  No NPU (CPU-only) Sensors via Expansion headers (Arduino, MikroBUS, Pmod) Parallel display support Sensor ML Anomaly detection Basic TinyML FRDM-MCXN947 MCU with neural acceleration NPU Parallel camera interface (basic) Parallel display Audio (PDM/I2S) Voice AI  Low-res vision Object classification Anomaly Detection FRDM-IMX93 Entry Edge AI MPU NPU  MIPI CSI camera Display (MIPI DSI/LVDS) Audio + connectivity Smart HMI Light vision AI Edge gateways FRDM-IMX8MPLUS Advanced Multimedia + Edge AI platform NPU Multi-camera (MIPI CSI) High-res display (HDMI/DSI)  Audio DSP Connectivity (Wi-Fi, BLE, Ethernet) Some PCIe expansion Computer vision Object detection Industrial AI FRDM-IMX95 Next-gen AI + real-time MPU Next-gen NPU + heterogeneous compute Multi-camera pipelines Advanced HMI Industrial connectivity M.2 expansion(Up to 1 AI accelerators) Robotics Industrial AI Safety applications FRDM-IMX95-PRO Full-featured AI dev platform High-performance NPU + scalable AI (Ara240 Discrete NPU)  Multi-camera Advanced display M.2 expansion (Up to 2 AI accelerators) Advanced AI prototyping Gen AI Edge servers Edge computing  Software and tools for ML/AI applications   GoPoint GoPoint accelerates AI/ML evaluation on FRDM platforms powered by i.MX application processors by providing a ready-to-use, graphical environment with pre-integrated demos. Developers can quickly run applications such as image classification, object detection, and voice recognition directly on the hardware without complex setup. These demos are already optimized for available compute resources—including CPU, GPU, DSP, and NPU—allowing users to immediately visualize performance and understand how AI workloads map to the system. This makes GoPoint an ideal starting point for exploring edge AI capabilities and validating use cases before moving into full application development. Application Code Hub (ACH) Application Code Hub complements rapid evaluation tools by offering a centralized repository of reusable, production-oriented software examples for FRDM boards. It provides full application projects, source code, and documentation that developers can directly import into MCUXpresso IDE or VS Code. With filtering based on use case—such as vision AI, audio processing, or anomaly detection, ACH enables developers to quickly find and customize reference implementations. This helps bridge the gap between proof-of-concept and real product development, significantly reducing development time while enabling scalable AI/ML application design. eIQ Time Series Studio (TSS) eIQ Time Series Studio is purpose-built for developing AI models based on sensor and time-series data, making it highly relevant for FRDM-based edge intelligence applications. It provides a guided workflow for data collection, labeling, model training, and validation, all optimized for MCU-class devices. Developers can easily transform raw sensor data—such as vibration, motion, or environmental signals—into deployable machine learning models for use cases like predictive maintenance, anomaly detection, and condition monitoring. With built-in analytics and seamless deployment to FRDM boards, TSS simplifies the path from data to intelligent behavior on the edge. eIQ AI/ML Software Environment The eIQ software environment is the foundation that enables AI/ML development across the entire FRDM ecosystem, providing an end-to-end workflow from model creation to on-device inference. It supports importing and optimizing models from popular frameworks such as TensorFlow, PyTorch, and ONNX, and integrates tightly with MCUXpresso and Linux-based environments. eIQ includes tools for model optimization—such as quantization and pruning—as well as runtime engines designed for efficient execution on CPUs, DSPs, and NPUs. By combining these capabilities with hardware acceleration available on FRDM boards, eIQ allows developers to build, deploy, and run real-time AI applications directly on embedded devices with minimal reliance on cloud computing. FQA What is an NPU in the FRDM platform? A Neural Processing Unit (NPU) in the FRDM platform is a dedicated hardware accelerator integrated into certain microcontrollers (such as the MCX-N family) that is specifically designed to execute machine learning and neural network workloads efficiently. Unlike general-purpose CPUs, the NPU is optimized for the mathematical operations used in AI models, enabling significantly faster inference—up to tens of times higher throughput—while consuming less power. In FRDM boards, the NPU works alongside the CPU and DSP to offload complex AI computations, allowing real-time processing for applications such as image recognition, voice detection, and sensor-based anomaly detection directly on the device. Combined with NXP’s eIQ® software environment, the NPU becomes the core execution engine that transforms FRDM platforms into efficient, low-power edge AI systems capable of running intelligent applications without relying on the cloud What is a Discrete NPU? A Discrete Neural Processing Unit (DNPU) is a standalone AI accelerator designed specifically to execute machine learning and neural network workloads efficiently. Unlike integrated NPUs that are built into a processor, a DNPU exists as a separate chip or module that can be added to a system. It offloads compute-intensive AI operations, such as matrix multiplications and deep learning inference from the main CPU or GPU, delivering significantly higher performance and better energy efficiency. This makes DNPUs ideal for advanced edge AI applications like computer vision, generative AI, and real-time multimodal processing. How do I use Ara modules (DNPU) with FRDM boards? Ara modules, based on NXP’s DNPU technology, can be used with compatible FRDM boards to extend AI processing capabilities. On supported i.MX-based FRDM platforms such as FRDM-IMX95 or FRDM-IMX95-PRO—developers can connect Ara modules (e.g., Ara240) through the M.2 expansion interface. Once connected, the Ara module works alongside the main processor to offload complex AI workloads, enabling faster inference, lower latency, and improved power efficiency. Using the eIQ® AI software environment, developers can prototype and validate models on FRDM, then scale performance by enabling Ara acceleration, creating a seamless path from development to high-performance edge AI deployment. From TinyML to advanced edge AI and GenAI, discover how to build intelligent systems directly on-device with FRDM, no cloud dependency required. FRDM-IMX8 FRDM-IMX8MP FRDM-IMX9 FRDM-MCXN i.MX Application Processors MCU

Importing a Wrapped Key Blob Using PSA Crypto APIs on RW612 Introduction In a previous article, we demonstrated how to import an RFC3394-wrapped key blob into ELS by manually performing the following operations: Deriving NXP_DIE_KEK_SK using CKDF-SP800-108 Importing the wrapped blob with mcuxClEls_KeyImport_Async() Deleting the temporary KEK after import While this approach provides full visibility into the underlying ELS operations, applications using the PSA Crypto API can achieve the same result with significantly less code. This article demonstrates how to use psa_import_key() together with PSA_KEY_LOCATION_S50_RFC3394_STORAGE to import a wrapped key blob stored in OTP. The PSA Oracle driver transparently handles the secure key loading sequence, including KEK derivation, key unwrapping, ELS slot management, and cleanup. Prerequisites FRDM-RW612 Key blob wrapped using RFC3394 format using HSM_STORE_KEY Key blob programmed to OTP fuses using LoadKeyBlob command. Required Headers: #include "psa/crypto.h" #include "mcuxClPsaDriver_Oracle_Interface_key_locations.h" #include "fsl_romapi_otp.h" Step 0 – Read the Wrapped Key Blob from OTP The example reads the blob directly from OTP memory. otp_fuse_read(starting_fuse_index + i, &fuse_word); Each fuse word contains four bytes.   These words are assembled into a contiguous buffer: blob_data[i * 4 + 0] = (fuse_word >> 0) & 0xFF; blob_data[i * 4 + 1] = (fuse_word >> 8) & 0xFF; blob_data[i * 4 + 2] = (fuse_word >> 16) & 0xFF; blob_data[i * 4 + 3] = (fuse_word >> 24) & 0xFF; The resulting buffer contains the RFC3394 wrapped key. Step 1 – Configure PSA Key Attributes Before importing the blob, PSA key attributes must describe how the key should be managed. The most important configuration is the key location: psa_set_key_lifetime( &attributes, PSA_KEY_LIFETIME_FROM_PERSISTENCE_AND_LOCATION( PSA_KEY_PERSISTENCE_VOLATILE, PSA_KEY_LOCATION_S50_RFC3394_STORAGE)); The PSA_KEY_LOCATION_S50_RFC3394_STORAGE location informs the Oracle driver that: The provided data is an RFC3394-wrapped key blob. The blob requires unwrapping before use. NXP_DIE_KEK_SK must be derived automatically during key loading. In this example we used an AES 128-bit key. The key type and size must match the wrapped key: psa_set_key_type(&attributes, PSA_KEY_TYPE_AES); psa_set_key_bits(&attributes, 128); Usage permissions are then assigned: psa_set_key_usage_flags( &attributes, PSA_KEY_USAGE_ENCRYPT | PSA_KEY_USAGE_DECRYPT); Finally, specify the algorithm: psa_set_key_algorithm( &attributes, PSA_ALG_ECB_NO_PADDING); Step 2 – Import the Wrapped Blob The blob is imported using a single PSA API call: psa_import_key( &attributes, blob_data, blob_length, &key_handle); For developers familiar with the low-level ELS implementation, this single call effectively replaces: derive_nxp_die_kek_sk() import_wrapped_key_blob() delete_key_from_slot() At this point, PSA stores the wrapped blob and returns a key handle: psa_key_id_t key_handle; The returned handle is subsequently used for cryptographic operations. Next Steps At this point, the wrapped key blob has been successfully imported into the target ELS key slot, and the temporary  NXP_DIE_KEK_SK  has been removed. The imported key is now available for use by ELS-protected cryptographic operations without exposing the underlying key material to application software. The next step is to validate the imported key by performing the operation it was provisioned for.  For this example, we used AES-ECB encryption: psa_cipher_encrypt( key_handle, PSA_ALG_ECB_NO_PADDING, plaintext, sizeof(plaintext), ciphertext, sizeof(ciphertext), &ciphertext_length); Step 4 – Cleanup Once the key is no longer required, destroy it using: psa_destroy_key(key_handle); This releases the PSA key object and allows the Oracle driver to clean up any associated secure resources. Unlike the low-level ELS implementation, the application does not need to explicitly manage ELS keyslots. PSA vs Direct ELS Implementation Direct ELS API PSA Crypto API Derive KEK manually Automatic Import blob manually Automatic Manage keyslots Managed by Oracle Delete temporary KEK Automatic Greater control Simpler application code Higher implementation effort Faster integration Both approaches ultimately leverage the same secure hardware mechanisms within RW612. The PSA approach simply abstracts the underlying ELS operations behind a standardized cryptographic interface.

RW610 / RW612 Knowledge Hub The RW61x series is a highly integrated, low-power tri-radio wireless MCU with an integrated MCU and Wi-Fi® 6 + Bluetooth® Low Energy (LE) 5.4 / 802.15.4 radios designed for a broad array of applications, including connected smart home devices, enterprise and industrial automation, smart accessories and smart energy. The RW61x series MCU subsystem includes a 260 MHz Arm® Cortex®-M33 core with Trustzone™-M, 1.2 MB on-chip SRAM and a high-bandwidth Quad SPI interface with an on-the-fly decryption engine for securely accessing off-chip XIP flash. The RW61x series includes a full-featured 1x1 dual-band (2.4 GHz/5 GHz) 20 MHz Wi-Fi 6 (802.11ax) subsystem bringing higher throughput, better network efficiency, lower latency and improved range over previous generation Wi-Fi standards. The Bluetooth LE radio supports 2 Mbit/s high-speed data rate, long range and extended advertising.  The on-chip 802.15.4 radio can support the latest Thread mesh networking protocol. In addition, the RW612 can support Matter over Wi-Fi or Matter over Thread offering a common, interoperable application layer across ecosystems and products. NXP RW61x Block DiagramNXP RW61x Block Diagram Documents RW610 Datasheet: RW610 Datasheet RW612 Datasheet: RW612 Datasheet RW61x User Manual: UM11865: RW61x User Manual RW61x Register Manual: RM00278: RX16x Registers   Certifications FRDM-RW612 Radio Equipment Directive Declaration of Conformity  User Guide Getting Started with FRDM-RW612 Quick Start Guide - FRDM-RW612 UG10185: RW612 Matter-Zigbee Bridge User Guide UG10178: Matter Demo Using NXP Chip Tool App for FRDM-RW612 and FRDM-MCXW71  UG10612: NXP Wi-Fi and Bluetooth Feature Debug for FRDM-RW612 UG10182: NXP 802.15.4 Demo Applications for FRDM-RW612 UG10160: Getting Started with Wireless on FRDM-RW612 Board Running RTOS  UG10171: NXP Wi-Fi and Bluetooth Demo Applications for FRDM-RW61X   RW61x Modules Azurewave: RW612 - AW-CU570 is a highly integrated, low-power tri-radio Wireless RW612 MCU with an integrated MCU and Wi-Fi 6 + Bluetooth Low Energy (LE) 5.2 / 802.15.4 radios designed for a broad array of applications. RW610 - AW-CU598 is a highly integrated, low-power tri-radio Wireless RW610 MCU with an integrated MCU and Wi-Fi 6 + Bluetooth Low Energy (LE) 5.3 radios designed for a broad array of applications U-blox: RW612 - IRIS-W10 Series are small, stand-alone, dual-band Wi-Fi and Bluetooth Low Energy wireless microcontroller unit (MCU) modules. The modules are ideal for users looking to add advanced wireless connectivity to their end products. RW610 - IRIS-W16 Series are small, stand-alone, dual-band Wi-Fi and Bluetooth Low Energy wireless modules, with everything needed for integration into end-products. The modules are ideal for users looking to add advanced wireless connectivity to their end products.  Murata: RW612 - LBES0ZZ2FR-580 Murata’s Type 2FR is a small and very high-performance module based on NXP RW612 combo chipset, supporting IEEE 802.11a/b/g/n/ac/ax + Bluetooth LE 5.4 / IEEE 802.15.4. RW610 - LBES0ZZ2FP-580 Type 2FR/2FP is a family of small and highly integrated multi-radio modules with built-in high-performance MCU with advanced security features for connected smart devices in smart homes, enterprise and industrial automation, smart accessories, and smart energy. It supports the latest Matter smart home connectivity protocol. California Eastern Laboratories (CEL): RW612 - CMP4612 is a fully integrated Dual-Band, Tri-mode (Wi-Fi 6, BT5.4, 802.15.4) radio, that includes a host MCU, Flash, RAM, peripherals, and numerous interfaces (SDIO, UART, USB, Ethernet. SPI, I2C) to support both HOSTLESS (RTOS) and HOSTED (NCP mode) architectures. CEL's solution includes either an on-board antenna or connector.   Evaluation boards  FRDM-RW612 FRDM-RW612 is a compact and scalable development board for rapid prototyping of the RW61x series of Wi-Fi 6 + Bluetooth Low Energy + 802.15.4 tri-radio wireless MCUs. It offers easy access to the MCU’s I/O's and peripherals, integrated open-standard serial interfaces, external flash memory and on-board MCU-Link debugger. FRDM-RW612 Getting Started Getting Started with FRDM-RW612 FRDM-RW612 User Manual: UM12160: FRDM-RW612 Board User Manual Current Measurement configuration: Remove the 0-ohms resistor R103 Solder a couple of pins in JP5. When trying to measure the RW61x current consumption, connect your current meter using the pins in JP5. When using the FRDM board in normal operation, connect a jumper to the pins in JP5.   u-blox   USB-IRIS-W1 The USB-IRIS-W1 development platform is built on the dual-band Wi-Fi 6 and Bluetooth LE module IRIS-W1, based on the NXP RW610/612 chip. The board is designed with a USB interface to simplify evaluation and prototyping directly from a PC. In addition to the IRIS-W1 module with integrated antenna, it also integrates four buttons, an RGB LED, and a USB/UART converter, to further support an easy evaluation. u-blox   EVK-IRIS-W1 The EVK-IRIS-W1 evaluation kit provides stand-alone use of the IRIS-W1 module series featuring the NXP RW610/612 chipset. Azurewave    AW-CU570-EVB Evaluation board for AW-CU570 module includes wireless MCU with Integrated Tri-radio Wi-Fi 6 + Bluetooth Low Energy 5.3 /802.15.4. Murata   2FR EVK Evaluation kit for Murata Type 2FR module (Murata part number LBES0ZZ2FR) includes 3 radios: Wi-Fi, BLE and 802.15.4. It is based on NXP’s RW612 chip. California Eastern Laboratories (CEL) CMP4612-2-EVB The CMP4612 Evaluation Board (CMP4612-2-EVB), based on the NXP RW612 chipset, features dual-band Wi-Fi 6, BLE 5.4 and 802.15.4 radios. The CMP4612 Evaluation Board includes an onboard Ethernet port and PHY hardware as well as an Arduino header, MCULink SWD, and USB ports. This board is designed to facilitate a seamless and efficient evaluation process for customers wanting a certified module for their end product.   Application Notes RM00287: Wi-Fi Driver API for SDK 2.16.100     The radio driver source code provides APIs to send and receive packets over the radio interfaces by communicating with the firmware images. This manual provides the reference documentation for the Wi-Fi driver and Wi-Fi Connection Manager.  UM12133: NXP NCP Application Guide for RW612 with MCU Host - User manual     This user manual describes: • The NXP NCP application for RW612 with MCU host platform i.MX RT1060 as example. • The hardware connections for one of the four supported interfaces to enable NCP mode on the NXP RW612 BGA V4 board (UART, USB, SDIO, or SPI). • The method to build and run the NCP applications on both the NCP host (i.MX RT1060) and the NCP device (RW612). The applications apply to Wi-Fi, Bluetooth Low Energy and OpenThread (OT)    UM12095:  NXP NCP Application Guide for RW612 with MPU Host - User manual      This user manual describes: • The NXP NCP application for RW612 with MPU host platform i.MX 8M Mini as example. • The hardware connections for one of the four supported interfaces to enable NCP mode on the NXP RW612 BGA V4 board (UART, USB, SDIO, or SPI). • The method to build and run the NCP applications on both the NCP host (i.MX 8M Mini) and the NCP device (RW612). The applications apply to Wi-Fi, Bluetooth Low Energy and OpenThread (OT).  AN14439: Migration Guide from FRDM-RW612 Board to Third-Party Module board This Application note provides an overview of what it means to migrate the application to a different board with different flash and pSRAM AN14111: Target Wake Time (TWT) on RW16x This application note describes the target wake time feature and provides examples for RW61X AN13006: Compliance and Certification Considerations This application note provides guidance and tips on how to test products on NXP Wi-Fi devices for regulatory compliance. AN13049: Wi-Fi/Bluetooth/802.15.4 M.2 Key E Pinout Definition This Application note defines M.2 usage for both NXP Wi-Fi/Bluetooth and Tri-Radio M.2 module design AN14489 – Wi-Fi Firmware Automatic Recovery on RW61x Describes Wi-Fi automatic recovery feature as well as how to enable and verify it on RW61x SDK. AN14464 - Low Power Checklist RW61x Family This document provides an overview on how to use the low power consumption features of the RW61x. AN14476 - NXP Dual PAN Feature and Performance Results This document provides a comprehensive exploration of the Dual Personal Area Network (Dual-PAN) feature on NXP Wireless Connectivity products implementing IEEE 802.15.4 low-rate wireless protocol area network standard. Security: AN14544 – EdgeLock 2GO Services for MPU and MCU This application note introduces various methods that the EdgeLock 2GO service can be used with MCU and MPU devices and the features available for each method. AN13813 – Secure Boot on RW61x Describes how to generate and run the secure boot (signed image) on RW61x. AN13814 – Debug Authentication on RW61x Describes the steps for debug authentication using the secure provisioning SDK tool. Import Wrapped Blob using ELS Cryptolib - Uses ELS Cryptolib to import a blob from OTP that was wrapped using HSM_STORE_KEY trust provisioning command.  Import Wrapped Blob using PSA APIs - Uses PSA API to import a blob from OTP that was wrapped using HSM_STORE_KEY trust provisioning command. Community Support If you have questions regarding RW61x series, please leave your comments in our Wireless MCU Community! here    Training FRDM-RW612 Training Wi-Fi 6 Tri-Radio in a secure i.MX RT MCU RW61x Series Training - NXP Community   Equipment Wireless Equipment: This article provides the links to the wireless equipment to help you accelerate your project development Development Tools  SDK builder The MCUXpresso SDK brings open-source drivers, middleware, and reference example application to speed your software development. NXP MCUXpresso MCUXpresso IDE offers advanced editing, compiling and debugging features with the addition of MCU-Specific debugging and supports connections with all general-purpose Arm Cortex-M.  VSCode MCUXpresso for Visual Studio Code (VS Code) provides an optimized embedded developer experience for code editing and development. Zephyr RTOS  The Zephyr OS is based on a small-footprint kernel designed for use on resource-constrained and embedded systems: from simple embedded environmental sensors and LED wearables to sophisticated embedded controllers, smart watches, and IoT wireless applications. NXP Application Code Hub Application Code Hub (ACH) repository enables engineers to easily find microcontroller software examples, code snippets, application software packs and demos developed by our in-house experts. This space provides a quick, easy and consistent way to find microcontroller applications. NXP SPSDK Is a unified, reliable, and easy to use Python SDK library working across the NXP MCU portfolio providing a strong foundation from quick customer prototyping up to production deployment. NXP SEC Tool The MCUXpresso Secure Provisioning Tool us a GUI-based application provided to simplify generation and provisioning of bootable executables on NCP MCU devices. NXP OTAP Tool Is an application that helps the user to perform an over the air firmware update of an NXP development board. SDK Examples for Wireless MCUs The wireless examples feature many common connectivity configurations.   Useful Links Bluetooth Interested in Bluetooth technology? Bluetooth® Low Energy Primer – Essential reading for understanding BLE fundamentals. Bluetooth® Specifications – Full list of standards, protocols, and technical documents. Bluetooth Feature Overview Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview   FRDM-Training Hands-On Training Product: WiFi RW6XX Protocol: 802.15.4 Protocol: BLE -> connectivity Protocol: Bluetooth Protocol: Matter Protocol: Thread Protocol: Wi-Fi Protocol: Zigbee

RW610 / RW612 ナレッジハブ RW61xシリーズは、MCUとWi-Fi ® 6 + Bluetooth ® Low Energy (LE) 5.4 / 802.15.4無線を内蔵した高集積、低消費電力のトライラジオ・ワイヤレスMCUで、コネクテッド・スマートホーム・デバイス、エンタープライズおよび産業オートメーション、スマート・アクセサリ、スマート・エネルギーなどの幅広いアプリケーションに対応しています。 RW61xシリーズMCUサブシステムには、260MHz Arm ®  Cortex ® -M33コア（TrustZone ™ -M搭載）、1.2MBのオンチップSRAM、およびオフチップXIPフラッシュへの安全なアクセスを可能にするオンザフライ復号化エンジンを搭載した高帯域幅クアッドSPIインターフェースを備えています。 RW61xシリーズには、フル機能の1x1デュアルバンド（2.4GHz/5GHz）20MHz Wi-Fi 6（802.11ax）サブシステムを搭載しており、前世代のWi-Fi標準を上回る高スループット、優れたネットワーク効率、低レイテンシ、広い通信範囲を実現します。Bluetooth LE無線機能によって、2Mbit/sの高速データ・レート、長距離通信、拡張アドバタイズをサポートします。オンチップの802.15.4無線は、最新のThreadメッシュ・ネットワーキング・プロトコルをサポートできます。さらに、RW612はMatter over Wi-FiまたはMatter over Threadをサポートでき、エコシステムや製品の違いを超えた共通の相互運用可能なアプリケーション・レイヤを提供します。 NXP RW61x Block DiagramNXP RW61xブロック図 書類 RW610 Datasheet: RW610 Datasheet RW612 Datasheet: RW612 Datasheet RW61xユーザーマニュアル：UM11865：RW61xユーザーマニュアル RW61xレジスタマニュアル：RM00278：RX16xレジスタ   RW61xモジュール AzureWave： RW612 - AW-CU570は、高集積、低消費電力のトライラジオ・ワイヤレスRW612 MCUで、MCUとWi-Fi 6 + Bluetooth Low Energy (LE) 5.2 / 802.15.4無線を内蔵し、幅広いアプリケーションに対応するように設計されています。 RW610 - AW-CU598 は、MCUとWi-Fi 6 + Bluetooth Low Energy (LE) 5.3無線を統合した高集積、低消費電力のトリプル無線RW610 MCUで、多様なアプリケーション向けに設計されています。 U-blox: RW612 - IRIS-W10シリーズは、小型でスタンドアロンのデュアルバンドWi-FiおよびBluetooth Low Energyワイヤレス・マイクロコントローラ・ユニット（MCU）モジュールです。これらのモジュールは、最終製品に高度なワイヤレス接続機能を追加したいユーザーに最適です。 RW610 - IRIS-W16シリーズは、小型で独立したデュアルバンドWi-FiおよびBluetooth Low Energy無線モジュールで、最終製品への組み込みに必要なすべてを備えています。これらのモジュールは、最終製品に高度な無線接続を追加したいユーザーに最適です。 Murata: RW612 - LBES0ZZ2FR-580 村田製作所のType 2FRは、NXP RW612コンボ・チップセットを基にした小型で非常に高性能なモジュールです。IEEE 802.11a/b/g/n/ac/ax + Bluetooth LE 5.4 / IEEE 802.15.4をサポートしています。 RW610 - LBES0ZZ2FP-580 Type 2FR/2FPは、スマートホーム、エンタープライズおよび産業オートメーション、スマート・アクセサリー、スマート・エネルギー向けの接続型スマート・デバイス向けに設計された、小型で高度に統合されたマルチ無線モジュール・ファミリーです。高性能MCUを内蔵し、高度なセキュリティ機能を備えています。最新のMatterスマートホーム接続プロトコルに対応しています。 California Eastern Laboratories (CEL)： RW612 - CMP4612は、デュアルバンド、トライモード（Wi-Fi 6、BT5.4、802.15.4）に対応した完全統合型無線モジュールで、ホストMCU、フラッシュ、RAM、周辺機器、および多数のインターフェース（SDIO、UART、USB、Ethernet、SPI、I2C）を備えています。ホストレス（RTOS）とホスト（NCPモード）の両方のアーキテクチャをサポートします。CELのソリューションには、オンボードのアンテナまたはコネクタが含まれています。 評価ボード  FRDM-RW612 FRDM-RW612は、Wi-Fi 6 + Bluetooth Low Energy + 802.15.4に対応するトライラジオ・ワイヤレスMCUであるRW61xシリーズのラピッド・プロトタイピングを目的とした、小型で拡張性に優れた開発ボードです。 このMCUのI/Oおよびペリフェラルに容易にアクセスできるほか、オープン・スタンダードの統合シリアル・インターフェース、外部フラッシュ・メモリ、オンボードMCU-Linkデバッガを備えています。 FRDM-RW612入門：FRDM-RW612入門ガイド FRDM-RW612ユーザー・マニュアル：UM12160: FRDM-RW612ボード・ユーザー・マニュアル FRDM-RW612クイック・スタート・ガイド：FRDM-RW612クイック・スタート・ガイド 電流測定構成： 0オームの抵抗器R103を取り外します。 JP5に2本のピンをはんだ付けします。 RW61xの消費電流を測定する場合は、JP5のピンを使用して電流メーターを接続します。FRDMボードを通常の操作で使用する場合は、ジャンパーをJP5のピンに接続します。 u-blox   USB-IRIS-W1 USB-IRIS-W1 開発プラットフォームは、NXP RW610/612 チップを基にしたデュアルバンド Wi-Fi 6 および Bluetooth LE モジュール IRIS-W1 上に構築されています。 このボードはUSBインターフェースを備えており、PCから直接評価やプロトタイピングを簡単に行うことができます。アンテナを内蔵したIRIS-W1モジュールに加え、4つのボタン、RGB LED、USB/UARTコンバータも統合されており、評価がさらに容易になります。 u-blox   EVK-IRIS-W1 EVK-IRIS-W1評価キットは、NXP RW610/612チップセットを搭載したIRIS-W1モジュール・シリーズを単独で使用することを可能にします。 Azurewave AW-CU570-EVB AW-CU570モジュールの評価ボードには、統合型トライラジオWi-Fi 6 + Bluetooth Low Energy 5.3 / 802.15.4を搭載したワイヤレスMCUが含まれています。 Murata   2FR EVK Murata Type 2FRモジュール（Murata部品番号：LBES0ZZ2FR）の評価キットには、Wi-Fi、BLE、および802.15.4の3つの無線が含まれています。NXPのRW612チップをベースにしています。 カリフォルニア・イースタン・ラボラトリーズ（CEL）CMP4612-2-EVB NXP RW612 チップセットを基にした CMP4612 評価ボード（CMP4612-2-EVB）は、デュアルバンド Wi-Fi 6、BLE 5.4、および 802.15.4 ラジオを備えています。CMP4612 評価ボードには、オンボードのイーサネットポートとPHYハードウェア、Arduinoヘッダー、MCULink SWD、USBポートが含まれています。このボードは、最終製品の認定モジュールを希望するお客様に対して、シームレスで効率的な評価プロセスを提供するために設計されています。 アプリケーション・ノート RM00287：SDK 2.16.100用Wi-FiドライバーAPI   この無線ドライバのソースコードは、ファームウェアイメージと通信することにより、無線インターフェイスを介してパケットを送受信するためのAPIを提供します。このマニュアルには、Wi-FiドライバーとWi-Fi接続マネージャーのリファレンス・ドキュメントが記載されています。 UM12133：NXP NCPアプリケーション・ガイド for RW612 with MCUホスト - ユーザー・マニュアル       このユーザーマニュアルでは、以下の内容について説明しています。 • NXP NCPアプリケーション for RW612 with MCUホスト・プラットフォーム i.MX RT1060を例として説明しています。 • NXP RW612 BGA V4ボードでNCPモードを有効にするための、サポートされている4つのインターフェース（UART、USB、SDIO、またはSPI）のうち1つのハードウェア接続。 • NCPホスト（i.MX RT1060）およびNCPデバイス（RW612）の両方でNCPアプリケーションをビルドして実行する方法。 アプリケーションは、Wi-Fi、Bluetooth Low Energy、OpenThread（OT）に適用されます。 UM12095：NXP NCPアプリケーション・ガイド（RW612用MPUホスト） - ユーザー・マニュアル このユーザーマニュアルでは次のことを説明しています。 • MPUホスト・プラットフォームi.MX 8M Miniを例にしたRW612用NXP NCPアプリケーション。 • NXP RW612 BGA V4ボードでNCPモードを有効にするための、サポートされている4つのインターフェース（UART、USB、SDIO、またはSPI）のうち1つのハードウェア接続。 • NCPホスト（i.MX 8M Mini）とNCPデバイス（RW612）の両方でNCPアプリケーションをビルドして実行する方法。アプリケーションはWi-Fi、Bluetooth Low Energy、OpenThread（OT）に適用されます。 AN14439：FRDM-RW612ボードからサードパーティ製モジュール・ボードへの移行ガイド このアプリケーション/ノートは、異なるフラッシュとpSRAMを持つ別のボードへのアプリケーション移行の概要を提供します。 AN14111：RW16xのターゲットウェイクタイム（TWT） このアプリケーション・ノートでは、ターゲット・ウェイク・タイム機能について説明し、RW61Xの例を示します。 AN13006：準拠および認証に関する考慮事項 このアプリケーション・ノートでは、NXPのWi-Fiデバイスで製品の規制準拠をテストする方法に関するガイダンスとヒントを提供します。 AN13049：Wi-Fi/Bluetooth/802.15.4 M.2キー Eピン配置定義 このアプリケーション・ノートは、NXPのWi-Fi/BluetoothおよびTri-Radio M.2モジュール設計におけるM.2の使用法を定義しています。 AN14489：RW61xにおけるWi-Fiファームウェアの自動回復 Wi-Fiの自動回復機能およびRW61x SDKでの有効化と確認方法について説明します。 セキュリティ: AN14544：MPUおよびMCU向けEdgeLock 2GOサービス このアプリケーション・ノートでは、MCUおよびMPUデバイスでEdgeLock 2GOサービスを使用するためのさまざまな方法と、各方法で利用可能な機能を紹介します。 AN13813：RW61xにおけるセキュアなブート RW61xにおけるセキュアなブート（署名済みイメージ）を生成して実行する方法について説明します。 AN13814：RW61xでのデバッグ認証 セキュア・プロビジョニングSDKツールを使用してデバッグ認証を行う手順について説明します。 コミュニティ・サポート RW61xシリーズに関するご質問は、こちらからワイヤレスMCUコミュニティにご意見をお寄せください。   トレーニング FRDM-RW612 セキュアな i.MX RT MCU での Wi-Fi 6 トライラジオのトレーニング RW61xシリーズトレーニング - NXPコミュニティ 機器 無線機器： 本記事では、プロジェクト開発を加速するために役立つ無線機器へのリンクを提供します。 開発ツール SDKビルダー MCUXpresso SDKは、オープンソースのドライバ、ミドルウェア、リファレンス例のアプリケーションを提供し、ソフトウェア開発を加速します。 NXP MCUXpresso MCUXpresso IDEは、高度な編集、コンパイル、デバッグ機能を提供し、MCU固有のデバッグを追加し、すべての汎用Arm Cortex-Mとの接続をサポートします。 VSCode MCUXpresso for Visual Studio Code（VS Code）は、コードの編集と開発向けに最適化された組込み開発者エクスペリエンスを提供します。 Zephyr RTOS  Zephyr OSは、リソース制約のある組み込みシステム向けに設計された小型カーネルを基盤としています。シンプルな組み込み環境センサーやLEDウェアラブルから、高度な組み込みコントローラー、スマートウォッチ、IoTワイヤレス・アプリケーションまで、幅広い用途に対応しています。 NXPアプリケーション・コード・ハブ アプリケーション・コード・ハブ（ACH）リポジトリにより、エンジニアは社内の専門家によって開発されたマイクロコントローラ・ソフトウェアの例、コード・スニペット、アプリケーション・ソフトウェア・パック、デモを簡単に見つけることができます。このスペースは、マイクロコントローラ・アプリケーションを迅速かつ簡単、そして一貫して見つけるための方法を提供します。 NXP SPSDKは、NXP MCUポートフォリオ全体で動作する信頼性が高くて使いやすいPython SDK統合ライブラリです。お客様の迅速なプロトタイピングから生産の展開までをサポートする強力な基盤を提供します。 NXP SECツール MCUXpressoセキュア・プロビジョニング・ツールは、NCP MCUデバイスでブート可能な実行ファイルを簡単に生成およびプロビジョニングできる、GUIベースのアプリケーションです。 NXP OTAP Toolは、ユーザーがNXP開発ボードの無線ファームウェア・アップデートを実行するのに役立つアプリケーションです。 ワイヤレスMCUのSDK例 ワイヤレスの例には、多くの一般的な接続構成が含まれています。 便利なリンク Bluetooth仕様 Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview Bluetooth_5.2_機能_概要 Bluetooth_5.3_機能_概要 Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview   FRDMトレーニング ハンズオン・トレーニング 製品: WiFi RW6XX プロトコル：802.15.4 プロトコル：BLE→コネクティビティ プロトコル：Bluetooth プロトコル：Matter プロトコル：Thread プロトコル：Wi-Fi プロトコル：Zigbee

RW610 / RW612 知识中心 RW61x 系列是一款高度集成的低功耗三射频无线 MCU，集成了 MCU 以及 Wi-Fi ® 6 + Bluetooth ® 低功耗 (LE) 5.4 / 802.15.4 射频，适用于广泛的应用场景，包括联网智能家居设备、企业和工业自动化、智能配件以及智能能源领域。 RW61x 系列 MCU 子系统包含一个 260 MHz 的 Arm ® Cortex ® -M33 内核（带 Trustzone ™ -M）、1.2 MB 片上 SRAM，以及一个高带宽 Quad SPI 接口（配备实时解密引擎，用于安全访问片外 XIP 闪存）。 RW61x 系列配备全功能的 1x1 双频段（2.4 GHz/5 GHz）20 MHz Wi-Fi 6（802.11ax）子系统，与前一代 Wi-Fi 标准相比，能提供更高的吞吐量、更好的网络效率、更低的延迟和更远的覆盖范围。蓝牙 LE 射频支持 2 Mbit/s 高速数据传输率、远距离传输和扩展广播功能。片上 802.15.4 射频可支持最新的 Thread mesh 网络协议。此外，RW612 还支持 Wi-Fi 上的 Matter 协议或 Thread 上的 Matter 协议，能在不同生态系统和产品间提供通用、可互操作的应用层。 NXP RW61x Block DiagramNXP RW61x 框图 文件 RW610 Datasheet: RW610 Datasheet RW612 Datasheet: RW612 Datasheet RW61x 用户手册：UM11865：RW61x 用户手册 RW61x 寄存器手册：RM00278：RX16x 寄存器   RW61x 模块 Azurewave： RW612 - AW-CU570：一款高度集成的低功耗三射频无线 RW612 MCU，集成了 MCU 以及 Wi-Fi 6 + 蓝牙低功耗 (LE) 5.2 / 802.15.4 射频，适用于广泛的应用场景。 RW610 - AW-CU598：一款高度集成的低功耗三射频无线 RW610 MCU，集成了 MCU 以及 Wi-Fi 6 + 蓝牙低功耗 (LE) 5.3 射频，适用于广泛的应用场景。 U-blox: RW612 - IRIS-W10 系列：小型独立式双频段 Wi-Fi 和蓝牙低功耗无线微控制器单元 (MCU) 模块。这些模块非常适合希望在其终端产品中添加高级无线连接功能的用户。 RW610 - IRIS-W16 系列：小型独立式双频段 Wi-Fi 和蓝牙低功耗无线模块，包含集成到终端产品所需的所有组件。这些模块非常适合希望在其终端产品中添加高级无线连接功能的用户。 Murata: RW612 - LBES0ZZ2FR-580：Murata 的 Type 2FR 是基于 NXP RW612 组合芯片组的小型且高性能模块，支持 IEEE 802.11a/b/g/n/ac/ax + 蓝牙 LE 5.4 / IEEE 802.15.4。 RW610 - LBES0ZZ2FP-580：Type 2FR/2FP 是一系列小型且高度集成的多射频模块，内置高性能 MCU（带高级安全功能），适用于智能家居、企业和工业自动化、智能配件及智能能源领域的联网智能设备。它支持最新的 Matter 智能家居连接协议。 California Eastern Laboratories (CEL)： RW612 - CMP4612：一款全集成双频段、三模式（Wi-Fi 6、BT5.4、802.15.4）射频，包含主机 MCU、闪存、RAM、外设和众多接口（SDIO、UART、USB、以太网、SPI、I2C），支持无主机（RTOS）和有主机（NCP 模式）架构。CEL 的解决方案包含板载天线或连接器。 评估板  FRDM-RW612 FRDM-RW612 是一款紧凑且可扩展的开发板，用于 RW61x 系列 Wi-Fi 6 + 蓝牙低功耗 + 802.15.4 三射频无线 MCU 的快速原型开发。 它提供了便捷的 MCU I/O 和外设访问方式、集成的开放标准串行接口、外部闪存和板载 MCU-Link 调试器。 RDM-RW612 入门指南：FRDM-RW612 入门 FRDM-RW612 用户手册：UM12160：FRDM-RW612 板用户手册 FRDM-RW612 快速入门指南：FRDM-RW612 快速入门指南 电流测量配置： 移除0欧姆电阻R103 在JP5上焊接几个引脚。 若要测量 RW61x 的电流消耗，使用 JP5 上的引脚连接电流计。正常操作 FRDM 板时，用跳线连接 JP5 上的引脚。 u-blox   USB-IRIS-W1 USB-IRIS-W1 开发平台基于双频段 Wi-Fi 6 和蓝牙 LE 模块 IRIS-W1（基于 NXP RW610/612 芯片）构建。 开发板设计有 USB 接口，方便直接通过 PC 进行评估和原型开发。除了带集成天线的 IRIS-W1 模块外，它还集成了四个按钮、一个 RGB LED 和一个 USB/UART 转换器，进一步为便捷评估提供支持。 u-blox   EVK-IRIS-W1 EVK-IRIS-W1 评估套件提供 IRIS-W1 模块系列的独立使用，采用 NXP RW610/612 芯片组。 Azurewave    AW-CU570-EVB AW-CU570 模块的评估板包含集成三射频（Wi-Fi 6 + 蓝牙低功耗 5.3 / 802.15.4）的无线 MCU。 Murata   2FR EVK Murata Type 2FR 模块（Murata 部件号 LBES0ZZ2FR）的评估套件包含三种射频：Wi-Fi、BLE 和 802.15.4。它基于 NXP 的 RW612 芯片。 California Eastern Laboratories (CEL) CMP4612-2-EVB CMP4612 评估板 (CMP4612-2-EVB) 基于NXP RW612 芯片组，具有双频段 Wi-Fi 6、BLE 5.4 和 802.15.4 射频。该评估板包含板载以太网端口和 PHY 硬件，以及 Arduino 接口、MCULink SWD 和 USB 端口。对于希望为其终端产品使用经过认证的模块的客户，该开发板能促进无缝高效的评估过程。 应用笔记 RM00287：SDK 2.16.100 的 Wi-Fi 驱动 API：射频驱动源代码提供了通过与固件镜像通信在射频接口上发送和接收数据包的 API。本手册提供了 Wi-Fi 驱动和 Wi-Fi 连接管理器的参考文档。 UM12133：带 MCU 主机的 RW612 的 NXP NCP 应用指南 - 用户手册：本用户手册介绍： • 以 i.MX RT1060 为 MCU 主机平台的 RW612 的 NXP NCP 应用。 • 在 NXP RW612 BGA V4 板上启用 NCP 模式的四种支持 接口（UART、USB、SDIO 或 SPI）之一的硬件连接。 • 在 NCP 主机 (i.MX RT1060) 和 NCP 设备 (RW612) 上构建和运行 NCP 应用的方法。 这些应用适用于 Wi-Fi、蓝牙低功耗和 OpenThread (OT)。 UM12095：带 MPU 主机的 RW612 的 NXP NCP 应用指南 - 用户手册：本用户手册介绍： • 以 i.MX 8M Mini 为 MPU 主机平台的 RW612 的 NXP NCP 应用。 • 在 NXP RW612 BGA V4 板上启用 NCP 模式的四种支持 接口（UART、USB、SDIO 或 SPI）之一的硬件连接。 • 在 NCP 主机 (i.MX 8M Mini) 和 NCP 设备 (RW612) 上构建和运行 NCP 应用的方法。 这些应用适用于 Wi-Fi、蓝牙低功耗和 OpenThread (OT)。 AN14439：从 FRDM-RW612 板迁移到第三方模块板的指南：本应用笔记概述了将应用迁移到具有不同闪存和 pSRAM 的不同板子的相关内容。 AN14111：RW16x 上的目标唤醒时间 (TWT)：本应用笔记介绍了目标唤醒时间功能，并提供了 RW61X 的相关示例。 AN13006：合规性和认证注意事项：本应用笔记提供了关于如何在 NXP Wi-Fi 设备上测试产品以确保符合法规的指导和提示。 AN13049：Wi-Fi / 蓝牙 / 802.15.4 M.2 Key E 引脚定义：本应用笔记定义了 M.2 在 NXP Wi-Fi / 蓝牙和三射频 M.2 模块设计中的使用方式。 AN14489 – RW61x 上的 Wi-Fi 固件自动恢复：介绍了 Wi-Fi 自动恢复功能，以及如何在 RW61x SDK 中启用和验证该功能。 安全性： AN14544 – 用于 MPU 和 MCU 的 EdgeLock 2GO 服务：本应用笔记介绍了 EdgeLock 2GO 服务可用于 MCU 和 MPU 设备的各种方法，以及每种方法可用的功能。 AN13813 – RW61x 上的安全启动：介绍了如何在 RW61x 上生成和运行安全启动（签名镜像）。 AN13814 – RW61x 上的调试认证：介绍了使用安全配置 SDK 工具进行调试认证的步骤。 技术论坛支持 如果你对 RW61x 系列有任何疑问，请在我们的无线 MCU 社区中留下你的评论！此处   培训 FRDM-RW612 培训：安全 i.MX RT MCU 中的 Wi-Fi 6 三射频 RW61x 系列培训 - NXP 社区 设备 无线设备：本文提供了无线设备的链接，以帮助你加快项目开发。 开发工具 SDK 构建器：MCUXpresso SDK 提供开源驱动程序、中间件和参考示例应用，以加快你的软件开发。 NXP MCUXpresso：MCUXpresso IDE 提供高级编辑、编译和调试功能，外加 MCU 特定调试功能，并支持与所有通用 Arm Cortex-M 的连接。 VSCode MCUXpresso：适用于 Visual Studio Code (VS Code) 的 MCUXpresso 为代码编辑和开发提供优化的嵌入式开发体验。 Zephyr RTOS：Zephyr 操作系统基于小尺寸内核设计，适用于资源受限的嵌入式系统：从简单的嵌入式环境传感器和 LED 可穿戴设备，到复杂的嵌入式控制器、智能手表和物联网无线应用。 NXP Application Code Hub：应用代码中心 (ACH) 存储库使工程师能够轻松找到由我们内部专家开发的微控制器软件示例、代码片段、应用软件包和演示。该平台提供了一种快速、简便且一致的方式来查找微控制器应用。 NXP SPSDK：一个统一、可靠且易于使用的 Python SDK 库，适用于整个 NXP MCU 产品组合，为从快速客户原型设计到生产部署提供坚实基础。 NXP SEC Tool：MCUXpresso 安全配置工具是一个基于 GUI 的应用程序，旨在简化 NCP MCU 设备上可引导可执行文件的生成和配置。 NXP OTAP Tool：一款帮助用户对 NXP 开发板执行空中固件更新的应用程序。 用于无线 MCU 的 SDK 示例：无线示例包含许多常见的连接配置。 有用链接 蓝牙规范 蓝牙 5.0 功能概述 蓝牙 5.1 功能概述 蓝牙 5.2 功能概述 Bluetooth_5.3_功能概述 Bluetooth_5.4_功能概述 Bluetooth_6_Feature_Overview   FRDM 培训 动手实践培训 产品：WiFi RW6XX 协议：802.15.4 协议：BLE -> 连接性 协议：蓝牙 协议：Matter 协议：Thread 协议：Wi-Fi 协议：Zigbee

Importing a Wrapped Key Blob into ELS Using NXP_DIE_KEK_SK on RW612 Introduction When provisioning secrets into an RW612 device, one common requirement is to securely load cryptographic keys without ever exposing the plaintext key material to application software. The EdgeLock Secure Subsystem (ELS) provides a secure mechanism for accomplishing this by allowing a wrapped key blob to be imported directly into an ELS key slot. The wrapping key is derived from device-unique root material inside the secure enclave. This article demonstrates how to: Derive the die-specific NXP_DIE_KEK_SK Import and unwrap the blob using ELS Store the resulting key in an ELS keyslot Remove temporary key material after provisioning The imported key never exists in plaintext in application memory, significantly reducing the attack surface compared to software-based key management. Understanding the Key Hierarchy Before looking at the implementation, it is useful to understand the different keys involved. NXP_DIE_MK_SK(NXP_DIE_INT_MK_SK) This is the 256-bit die master key derived from UDF and PUF using the KEYPROV operation. Characteristics: Die unique Not exportable Used as a root-of-trust Occupies key slot 0 on RW612 The key is loaded via dedicated secret key bus from PUF into ELS and XOR with a UDF derived key using KEYPROV, where it is used as a main key for further derivation of all remaining keys used by ROM. Applications never directly access the key material. NXP_DIE_KEK_SK This 256-bit key is derived from the master key using CKDF. It used for the wrapping of RFC3394 blobs stored in the OTP fuse region. Purpose: Acts as a Key Encryption Key (KEK) Used only for wrapping or unwrapping other keys Can be generated dynamically when needed In this example the KEK is stored temporarily in key slot 5. Imported Key The final key imported from the wrapped blob depends on how the blob was originally generated using the HSM provisioning flow (for example, via HSM_STORE_KEY and later loaded with loadkeyblob ). The imported key may represent a customer-defined security asset such as: Customer master key ( CUST_CKDFK_FLAG ) HKDF master key ( CUST_HKDFK_FLAG ) HMAC key ( CUST_HMACK_FLAG ) CMAC key ( CUST_CMACK_FLAG ) AES key ( CUST_AESK_FLAG ) Key unwrap-only key ( CUST_KUOK_FLAG ) Regardless of the key type, the import process remains the same. The key material is never exposed to application software during this process. Once imported, the key can be used directly by ELS for the cryptographic operations associated with its intended purpose, while remaining protected within the secure subsystem. Prerequisites FRDM-RW612 Key blob wrapped using RFC3394 format using HSM_STORE_KEY Key blob programmed to OTP fuses using LoadKeyBlob command. Required Headers: #include "mcux_els.h" #include "mcuxClEls.h" #include "mcux_pkc.h" #include "fsl_romapi_otp.h" Step 1 – Derive NXP_DIE_KEK_SK The wrapped blob is protected using a Key Encryption Key (KEK). On RW612, the KEK can be derived from the device master key ( NXP_DIE_MK_SK ) using the official recipe constants. The derivation operation uses  masterKeyIdx = 0;  which corresponds to NXP_DIE_MK_SK  and produces a new key in the target slot. Example: static const uint8_t derivation_data[12] = { 0x94, 0xbe, 0x03, 0xac, 0x8b, 0x59, 0x32, 0x45, 0x11, 0x7f, 0xf8, 0x3f }; mcuxClEls_Ckdf_Sp800108_Async( masterKeyIdx, target_slot, targetKeyProperties, derivation_data);   Wait for completion: mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR);   Verify that the derived key slot becomes active before proceeding. Step 2 – Retrieve the Wrapped Blob The example reads the blob directly from OTP memory. otp_fuse_read(starting_fuse_index + i, &fuse_word); Each fuse word contains four bytes.   These words are assembled into a contiguous buffer: blob_data[i * 4 + 0] = (fuse_word >> 0) & 0xFF; blob_data[i * 4 + 1] = (fuse_word >> 8) & 0xFF; blob_data[i * 4 + 2] = (fuse_word >> 16) & 0xFF; blob_data[i * 4 + 3] = (fuse_word >> 24) & 0xFF; The resulting buffer contains the RFC3394 wrapped key. Step 3 – Import and Unwrap the Blob Once the KEK exists and the blob has been retrieved, the import operation can begin. Configure ELS for RFC3394 import: mcuxClEls_KeyImportOption_t options; options.word.value = 0; options.bits.kfmt = MCUXCLELS_KEYIMPORT_KFMT_RFC3394; Perform the import: mcuxClEls_KeyImport_Async( options, blob_data, blob_length, kek_slot, target_slot); Parameters: Parameter Purpose blob_data Wrapped key blob blob_length Blob size kek_slot Slot containing NXP_DIE_KEK_SK target_slot Destination keyslot Wait for completion: mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR); If successful, ELS unwraps the blob internally and places the resulting key into the destination key slot. No plaintext key material is exposed to software. Step 4 – Clean Up Temporary KEK After the blob has been imported, delete the temporary KEK: mcuxClEls_KeyDelete_Async(kek_slot); mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR); This leaves only the imported key resident inside ELS. Next Steps At this point, the wrapped key blob has been successfully imported into the target ELS key slot, and the temporary NXP_DIE_KEK_SK has been removed. The imported key is now available for use by ELS-protected cryptographic operations without exposing the underlying key material to application software. The next step is to validate the imported key by performing the operation it was provisioned for. Depending on the key type, this may include: AES encryption or decryption operations HMAC generation or verification CMAC generation or verification HKDF-based key derivation Importing or unwrapping additional key material Secure firmware or data encryption workflows A successful cryptographic operation confirms that: The blob was read correctly from storage. The NXP_DIE_KEK_SK derivation completed successfully. The RFC3394 unwrap operation succeeded. The key was installed into the intended ELS keyslot with the expected properties. For production deployments, this import mechanism provides a secure method for provisioning customer keys generated with the HSM tooling while ensuring that plaintext key material never leaves the ELS security boundary.

LS1028A IEEE1588 Phyタイムスタンプによるサポート こんにちは、IEEE1588 LS1028Aのサポートについて質問があります。利用可能な資料をざっと見てみましたが、質問の答えが見つかりませんでした。具体的には、FelixのスイッチドライバーかMACドライバー(どちらかは不明)が、タイムタンピングがMACレイヤーではなくEthernet Phyで行われるIEEE1588をサポートしていますか?理論的には、Phyタイムスタンプを使用すると、ラインに近いので、より高い精度が得られるはずなので、疑問に思っています。少なくとも理論上は。このSoCではどのように動作するのですか？ Re: LS1028A IEEE1588 support with Phy timestamping こんにちは、 いいえ — LS1028Aでは、IEEE 1588/PTPのタイムスタンプは、SoCの内部イーサネットハードウェア(ENETC MACまたはFelix switch MAC/PTPブロック)によって行われると記録されており、外部イーサネットPHYによって行われていません。IEEE 1588タイムスタンプは、外部のPHYベースのパケットタイムスタンプではなく、ENETC/Felix MAC側のPTPハードウェアと個別のPHCブロックによって内部的に処理されます。 よろしくお願いします。

FS26 Amux 传感问题 我尝试在将BAT 感知电压连接到AMUX 引脚后测量该引脚上的电压。我已经验证了所有相关的寄存器值， FS_STATES寄存器报告设备处于正常模式。然而，AMUX 引脚持续输出 0 V，我的 12 位 ADC 读数始终为 0。我的代码以S32K3xx 参考示例之一为基础（已附上），但 AMUX 测量功能并未按预期工作。请查一下。 Re: FS26 Amux sensing issue 您好， 感谢您分享代码和详细信息。请您核对以下内容： - 写入后读取 M_AMUX_CTRL 寄存器，并确认 AMUX_EN = 1 且 AMUX[4:0] = 0x16（已选择 BATSENSE）。 - 请同时确认 SPI 响应指示 M_AVAL = 1，这意味着主状态机处于正常模式。 - 硬件方面，请确认 BATSENSE 引脚是否有预期的电压，以及 AMUX 引脚是否正确连接到 ADC 输入。   BRs，托马斯 Re: FS26 Amux sensing issue M_AMUX_CTRL 寄存器配置为 M_AMUX_EN | M_AMUX_BATSENSE | M_AMUX_DIV_0，并通过回读验证为 0x56。这证实了模拟多路复用器处于活动状态，并正确地路由了 12V 电池感应输入。   但是，SPI 设备状态 (u8DeviceStatus) 读取结果为 0xCA。由于最高有效位已设置（sbc_fs26_RxFrameType.u8DeviceStatus & 0x80 == 1），因此全局故障保护故障处于活动状态。此外，FS_STATES 寄存器返回 11，证明设备卡在 INIT_FS（初始化故障保护）状态。 Re: FS26 Amux sensing issue 你好， 您的回读结果确认 AMUX 配置正确，但设备卡在 INIT_FS 中。 为解决此问题，请按照AN13850 （需要签署保密协议的安全文件）第 6.1 节和第 6.2 节中描述的初始化和监视程序序列进行操作： 上电或 RESET 后，按照 6.1 节所述配置所有必需的 FS_I_xxx 和 FS_I_NOT_xxx 寄存器。 在 256 毫秒的 INIT_FS 窗口内执行一次良好的看门狗刷新，以结束初始化阶段。 一旦功能安全输出解除，设备将进入正常模式，AMUX 测量功能将按预期运行。 BRs，托马斯

Linuxカーネル6.1.85用のIW416 Wi-Fi/BTドライバーのソースコードおよびビルドガイドの要請 こんにちは、NXPコミュニティの皆さん、 現在、 NXP IW416(8997ベース) Wi-Fi/BluetoothモジュールをカスタムSBCに統合する作業を進めています。私のシステムは Linuxカーネル6.1.85を搭載したYoctoベースのディストリビューションを使っています。 Wi-FiとBluetoothのドライバーを独立したカーネルモジュールとして構築したいのですが、正しくて最も安定したソースを使っているか確認したいです。 以下の点について教えていただけませんか? ドライバーソースコード: カーネル6.1.85では、どのリポジトリとブランチ(またはコミット)を使うべきでしょうか? 組み立て手順: これらのドライバーや必要なファームウェアを正しく構築・統合する方法についての公式ドキュメントやアプリケーションノート、ガイドはありますか? 何かご助言や適切な情報源を教えていただければ大変ありがたいです。 お手数ですが、よろしくお願いいたします。   Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 私の環境設定は以下のとおりです。 $ ls -al /lib/firmware/nxp/ drwxr-xr-x 2 root root 4096 2月 28 02:44 ./ drwxr-xr-x 3 root root 4096 2月 28 2024 ../ -rw-r--r-- 1 root root 415996 2月 28 2024 sdioiw416_wlan_v0.bin -rw-r--r-- 1 root root 570976 2月 28 2024 sdiouartiw416_combo_v0.bin -rw-r--r-- 1 root root 154920 2月 28 2024 uartiw416_bt_v0.bin -rw-r--r-- 1 root root 58 2月 28 02:28 wifi_mod_para.conf   $ cat /lib/firmware/nxp/wifi_mod_para.conf fw_name= "nxp/sdiouartiw416_combo_v0.bin" cal_data_cfg=なし   $ lsmod モジュールサイズ使用 モアル 745472 0 mlan 585728 1 moal   DMESGログの関連部分は提供できます。どのキーワードやパーツにgrepをすべきか教えてもらえますか?また、正常に動作した場合の期待される結果／出力についても知りたいです。   よろしくお願いします。 +起動時には、以下のようにMLANドライバからのログがあります。 [ 1.312336] wlan: MWLANドライバの読み込み中 [ 1.316381] wlan: バスドライバへの登録... [ 1.321331] wlan: バスドライバへの登録完了 [ 1.326355] wlan: ドライバのロードが正常に完了   Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 こんにちは、 @sunam ファームウェアは /lib/firmware/nxp/ に配置する必要があります。 Wi-FiとBluetoothのコンボファームウェアを使用している場合は、以下のように設定してください。 root@imx8mnevk: /lib/firmware/nxp # ls -l sduartiw416_combo.bin -rw-r--r-- 1 root root 406996 2011年4月5日sduartiw416_combo.bin 入力した後は、/lib/firmware/nxp/wifi_mod_para.confのWi-Fiドライバーの読み込みパラメータを再度確認し、ファームウェア名が一致しているか再度確認してください。 それでも起動しない場合は、デバイスの起動時に取得したdmesgログを提供してください。 よろしくお願いいたします。 Christine。 Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 こんにちは、 私は現在、IW416チップを使用しています。6.1.55-2.2.2ブランチを使ってドライバを無事に構築でき、ドライバが正しく生成されていることも確認しました。 しかし、どうやら動作していないようで、最新のファームウェアがインストールされていないことが原因ではないかと疑っています。ファームウェアファイルをどのディレクトリに入れるべきか教えていただけますか? よろしくお願いします。 Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 こんにちは、 @sunam 1. ご使用のチップセットがIW416か88W8997のどちらであるかを再度ご確認ください。これらは異なるチップセットです。 IW416の場合、 最新のファームウェアをダウンロードするには： imx-firmware/FwImage_IW416_SD (lf-6.18.20_2.0.0) · nxp-imx/imx-firmware · GitHub 最新のドライバーをダウンロードするには: GitHub - nxp-imx/mwifiex at lf-6.18.20_2.0.0 · GitHub また、ドライバーのソースコードはLinuxカーネルバージョン 2.6.32から6.19.0まで運行しているホストとも互換性があるので、あなたのL6.1.85には問題ありません。 2. ビルド手順: これらのドライバや必要なファームウェアを正しく構築・統合する方法についての公式ドキュメント、アプリケーションノート、ガイドはありますか? ==> 参照先: NXP Wi-Fiドライバーのダウンロードと構築方法 また、以下のドキュメントもあなたにとって役立つと思います。 Linux OSを実行する8M Quad EVK上でNXPベースのワイヤレスモジュール i.MX 始める 他に何かご心配な点がございましたら、お知らせください。 もし違うなら、私の回答を解決策としてマークして、閉じるのを手伝ってください。 当社の製品使用中に問題が発生した場合は、新たなCASEの作成を歓迎します。 よろしくお願いいたします。 Christine。 Re: Request for IW416 Wi-Fi/BT driver source code and build guide for Linux Kernel 6.1.85 こんにちは、 @sunam 通常は以下のようなdmesgログが出力されるはずです。 ========= root@imx8mnevk:~# dmesg |グレップ・ウラン [ 5.127546] wlan: MWLANドライバーの読み込み [ 5.141006] WLAN: バス運転手への登録... [ 5.213728] wlan: TX SGモードを有効にする [ 5.217262] WLAN: mpa_tx.BUF_Size=65280 [ 5.221136] wlan: RX SG モードを有効にする [ 5.224679] wlan: mpa_rx.buf_size=65280 [ 6.505940] wlan: RX SG モードを有効にする [ 6.585864] wlan: version = SD8987----16.92.21.p155.1-MM6X16540.p33-GPL-(FP92)//これは、当社の88W8987の例です。 [ 6.624373] wlan: バス運転手への登録完了 [ 6.637582] wlan: ドライバのロードが正常に完了 ======== wifi_mod_para.confを以下のように変更できます: ====== SDIW416 = { fw_name=nxp/sdiouartiw416_combo_v0.bin cal_data_cfg=なし cfg80211_wext=0xf max_sta_bss=1 drv_mode=7 } ======= それでも解決しない場合は、デバイスの起動時に取得したdmesgログをすべて提供してください。 DMESGログは添付ファイルとしてアップロードできます。 よろしくお願いいたします。 Christine。

i.MX8MP RAW 捕获最大几何尺寸 NXP社区的各位好， 我们正在尝试在 i.MX8MP 上使用特定的图像传感器。 我们正在尝试将 RAW12 捕获从 MIPI 推送到 RAM。看来唯一的方法是通过如下所述的 ISI 模块： 问题在于，关于几何限制的文档含糊不清，我们正在尝试确定 i.MX8MP 是否适合我们的应用。 图像的高度和宽度在 ISI 中使用 CHNL_IMG_CFG[WIDTH/HEIGHT] 寄存器定义。这些条目是 13 位的，理论上将我们限制在 8191 x 8191 的几何尺寸。 宽度似乎受到硬件的限制，因为行缓冲区实际上只能容纳 2K 像素，但文档概述了通过组合其他通道的行缓冲区来实现 4K 的方法。文档中没有说明是否可以达到 8191 像素的线宽寄存器限制。我们可以绕过 ISI 处理，我们的目标是直接将 RAW MIPI 捕获的数据推送到 RAM 中。 此外，与宽度限制不同，高度限制似乎并非由物理硬件引起。 是否有任何证据表明我们可以支持 CHNL_IMG_CFG[HEIGHT] 寄存器 13 位最大值所定义的 8191 行高度？ 任何支持都将不胜感激。我已阅读过其他类似帖子，例如以下这些： https://community.nxp.com/t5/i-MX-Processors/Direct-MIPI-CSI2-to-memory-access-on-i-MX8MP/mp/2158946 https://community.nxp.com/t5/i-MX-Processors/I-MX8MP-ISI-maximum-supported-width/mp/1224069 但是，目前尚未确认是否支持 8191 宽度，我想知道这方面是否有任何更新。 此外，高度限制也没有明确规定。 谢谢 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MP Maximum Geometry for RAW Capture i.MX8MP 的 ISI 驱动程序限制在 2K 分辨率，但如果使用链式缓冲区，ISI 可以支持高达 4K 的分辨率，但不支持 8191 像素宽。在 i.MX8MP 上，单个摄像头最高可支持 4K@30Hz 的分辨率。

Requesting Gerbers for AFT05MP075N Hello, I'm working on a VHF/UHF power amplifier design using the AFT05MP075N. I have the DXF reference PCB files from the AFT05MP075N product page but I will need the complete Gerber file package for the 450–520 MHz broadband reference board. I understand these were previously provided to customers upon request. I would like support in getting those files. Thank you RF

i.mx95 Android 16 ブートロゴ: uboot ロゴからカーネルロゴへのスムーズな遷移 ubootはブートロゴを表示し、カーネルに入った後もブートロゴは表示されたままになります。 現在、ubootのコードを修正すると、uboot終了時にディスプレイが閉じられず、カーネルがロードされるまでロゴが表示され続けるという問題が発生しています。 LVDSディスプレイに関する情報については、以下の処理方法があります。 PWMスクリーンバックライト制御に関する問題については、ubootでバックライト関連のピンが初期化されるようにすることで問題を解決し、カーネルの初期化中に設定を通じて、カーネルがLVDS PWMの初期化をリセットしないようにしました。 ディスプレイの電力ドメインについては、scmi_pm_domain.c を修正しました。ディスプレイの電源モジュールがリセットされないように、ドライバのソースコードに以下の情報を追加します。 + if (strcmp(scmi_pd->name, "display") == 0) { + scmi_pd->genpd.flags = GENPD_FLAG_ACTIVE_WAKEUP | GENPD_FLAG_RPM_ALWAYS_ON; + }​ 現在の問題は、 カーネル時間の3秒後、カーネルの表示モジュールが起動すると、カーネルは緑色の画面を表示し、カーネルのロゴを正常に表示できなくなります。 回复： i.mx95 android 16 boot logo: Smooth transition from uboot logo to kernel logo kernel.log： カーネルが実行されると、ubootのロゴがカーネルのロゴに切り替わり、画面が2秒間真っ暗になります。 kernel_green.log: ディスプレイの電源ドメインを維持し、リセットを避けてください。カーネルディスプレイモジュールが実行されると、緑色の画面が表示されます。 --- a/drivers/pmdomain/arm/scmi_pm_domain.c +++ b/drivers/pmdomain/arm/scmi_pm_domain.c @@ -105,6 +105,9 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev) scmi_pd->genpd.power_on = scmi_pd_power_on; scmi_pd->genpd.flags = GENPD_FLAG_ACTIVE_WAKEUP; + if (strcmp(scmi_pd->name, "display") == 0) { + scmi_pd->genpd.flags = GENPD_FLAG_ACTIVE_WAKEUP | GENPD_FLAG_RPM_ALWAYS_ON; + } if (!strcmp(scmi_pd->name, "hsio_top")) scmi_pd->genpd.flags = 0; 回复： i.mx95 android 16 boot logo: Smooth transition from uboot logo to kernel logo ディスプレイインターフェース: lvds 理論的には、カーネルのディスプレイ関連ドライバはU-Bootの状態を維持し、二次初期化を経ずに直接ディスプレイ動作モードに入るべきである。 あるいは、初期化プロセスはカーネルの動作モードに直接かつ迅速に切り替えてカーネルのロゴを表示することもできます。 カーネル内でどのように処理すればよいでしょうか？ カーネルに表示される関連設定はDRMフレームワークを通じて構成され、そのためには基盤となるハードウェアドライバをDRMフレームワークに適合させる必要がある。 Re: i.mx95 android 16 boot logo: Smooth transition from uboot logo to kernel logo こんにちは、 LVDS に適切な dts ファイルを使用していますか？Android のプリビルドイメージでテストしましたか？ Re: i.mx95 android 16 boot logo: Smooth transition from uboot logo to kernel logo LVDSに適切なdtsファイルを使用していますか？ ----> LVDS画面は既に表示済みです。 LVDSスクリーンは、U-Bootおよびカーネル実行中にロゴを表示できます。 ubootによってロゴが表示された後、システムがカーネルに切り替わり、ディスプレイモジュールデバイスが再初期化されると、ディスプレイの電源ドメインが最初にオフになり、その後オンになるため、2秒間画面が黒くなります。 画面が真っ暗になるとは思っていません。 カーネルがディスプレイモジュールを再初期化する際に、ubootの設定を継承し、カーネルロゴを直接表示した後、Androidに入り、ブートアニメーションを直接表示することを期待しています。この過程で、画面が真っ黒になるのを避けたい。 現在、ubootに修正を加え、uboot終了時にロゴ画像が閉じないようにしました。 diff --git a/arch/arm/lib/bootm.cb/arch/arm/lib/bootm.c インデックス 81e8ddae..c6f1f8e8 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -72,7 +72,7 @@ static void announce_and_cleanup(int fake) #endif #if defined(CONFIG_VIDEO_LINK) - video_link_shut_down(); + //video_link_shut_down(); #endif U-Bootとカーネルの両方でPWMバックライト制御に修正を加え、カーネルドライバがスムーズに制御を引き継げるようにしました。 ubootからカーネルへのPWMバックライトはオフにリセットされません。 さらに、カーネル内のディスプレイ電源ドメインへの継続的な電力供給を確保するために、ディスプレイ電源ドメインの変更を試みました。しかし、この変更の結果、ディスプレイが正常に表示されなくなってしまいました。カーネルのロゴを切り替えた後、画面が緑色に表示された。 この例外はどのように処理すればよいでしょうか？DPUの設定に問題があり、それが原因でディスプレイパイプ全体が誤動作しているようです。 Androidのプリビルドイメージでテストしましたか？ -->はい、LVDSの表示機能は既に正常に動作していると確信しています。 Androidのコードは変更していません Re: i.mx95 android 16 boot logo: Smooth transition from uboot logo to kernel logo GENPD_FLAG_RPM_ALWAYS_ONフラグを追加した後、DPU95はed_cont_shdld_doneで常にタイムアウトします。 その結果、DPU95に渡されるすべてのパラメータが無効になる。 DPU95の設定方法は？DPU開発に関する関連資料はありますか？ + if (strcmp(scmi_pd->name, "display") == 0) { + scmi_pd->genpd.flags = GENPD_FLAG_ACTIVE_WAKEUP | GENPD_FLAG_RPM_ALWAYS_ON; + }​ static void dpu95_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct dpu95_drm_device *dpu_drm = to_dpu95_drm_device(crtc->dev); struct dpu95_crtc *dpu_crtc = to_dpu95_crtc(crtc); struct drm_encoder *encoder = &dpu_drm->encoder[dpu_crtc->stream_id]; bool enc_is_dsi = encoder->encoder_type == DRM_MODE_ENCODER_DSI; pr_err("liucx %s:%d \n", __func__, __LINE__); if (!liucx_logo_keep) { //return; } //dpu95_crtc_disable(crtc); drm_crtc_vblank_on(crtc); enable_irq(dpu_crtc->dec_shdld_irq); enable_irq(dpu_crtc->db_shdld_irq); enable_irq(dpu_crtc->ed_cont_shdld_irq); dpu95_fg_enable_clock(dpu_crtc->fg, enc_is_dsi); dpu95_ed_pec_sync_trigger(dpu_crtc->ed_cont); dpu95_db_shdtokgen(dpu_crtc->db);//CONTROLTRIGGER SHDTOKGEN dpu95_fg_shdtokgen(dpu_crtc->fg); dpu95_fg_enable(dpu_crtc->fg); //always timeout，why？How does DPU generate this interrupt? DPU95_CRTC_WAIT_FOR_COMPLETION_TIMEOUT(ed_cont_shdld_done); DPU95_CRTC_WAIT_FOR_COMPLETION_TIMEOUT(db_shdld_done); DPU95_CRTC_WAIT_FOR_COMPLETION_TIMEOUT(dec_shdld_done); disable_irq(dpu_crtc->ed_cont_shdld_irq); disable_irq(dpu_crtc->db_shdld_irq); disable_irq(dpu_crtc->dec_shdld_irq); DPU95_CRTC_WAIT_FOR_FRAMEGEN_PRIMARY_SYNCUP(dpu_crtc->fg); /* ignore initial empty primary pixel FIFO read status, just clear it */ dpu95_fg_primary_clear_channel_status(dpu_crtc->fg); dpu95_crtc_queue_state_event(crtc);//发送一个event，用于处理vblank事件 } Re: i.mx95 android 16 boot logo: Smooth transition from uboot logo to kernel logo linuxRMを参照してください。 https://www.nxp.com/docs/en/reference-manual/RM00293.pdf また、ドライバを確認することもできます。 Linux DPU95 DRMドライバツリーは、drivers/gpu/drm/imx/dpu95/にあります。 Linux-tn-imx/ドライバ/gpu/drm/imx/dpu95 (tn-imx_6.18.2_1.0.0-stable) · TechNexion/Linux-tn-imx · GitHub dpu95-crtc.c dpu95-extdst.c dpu95-domainblend.c U-Boot imx95_dpu.c Re: i.mx95 android 16 boot logo: Smooth transition from uboot logo to kernel logo よく分かりません。 U-Boot imx95_dpu.c について言及されましたが、その機能は何ですか？そして、私は何をすればいいですか？ ファイル U-Boot imx95_dpu.c は、U-Boot 用の DPU ドライバです。 カーネルからU-BootにDPUドライバを移植すべきでしょうか？ Re: i.mx95 android 16 boot logo: Smooth transition from uboot logo to kernel logo DPU95ディスプレイコントローラーの開発マニュアルはありますか? 現状では、dpu95はubootの状態を維持する必要があります。カーネル内では、この状況においてdpu95の動作原理を参照し、レジスタを設定することでdpu95の初期化を完了させる必要がある。

S32G274A 实现SHA256+RSA2048算法 Hello NXP Support Team, I am currently evaluating HSE on the S32G274A platform and would appreciate some guidance regarding the recommended implementation path. Current environment: * Device: S32G274A * Core: Cortex-M7 * IDE: S32 Design Studio 3.6 * HSE package: HSE_DEMOAPP_S32G2XX_0_1_0_16 * HSE firmware: HSE_FW_S32G2XX_0_1_0_16 Current progress: * I am following AN14070 ("How to Run HSE Demo Application on Cortex-M7 Core of S32G2"). * The HSE demo project can be imported and compiled successfully. * However, when opening the IVT View, S32DS reports an exception and the IVT view cannot be created: com.nxp.swtools.ivt.views.IVTView (I can provide the complete error log if needed.) Project objective: Currently, our bootloader implements software-based secure boot: 1. Calculate SHA-256 of the application image. 2. Verify RSA-2048 signature using a public key stored in flash. 3. Boot the application only if verification succeeds. We would like to migrate this implementation to HSE-based services on Cortex-M7. Questions: 1. Is AN14070 still the recommended starting point for HSE evaluation on S32G274A with S32DS 3.6? 2. Is the IVT View mandatory for evaluating HSE services such as: * SHA-256 * AES * RSA signature verification Or is it only required for generating the blob image and installing HSE firmware? 3. Once HSE firmware is installed, is there any reference example demonstrating: * SHA-256 calculation through HSE * RSA-2048 signature verification through HSE * Public key import into HSE key catalog 4. Are there any application notes, training materials, or demo projects that demonstrate migrating a software-based secure boot implementation to HSE services on Cortex-M7? 5. For a bootloader that currently performs SHA-256 + RSA2048 verification before jumping to the application, what is the recommended migration path using HSE? Any guidance, reference projects, or recommended documentation would be greatly appreciated. Best regards, Re: S32G274A 实现SHA256+RSA2048算法 我按照步骤操作到3. The IVTView, shown in the following figure, displays the blocks DCD, HSE, Application bootloader, Boot configuration and Automatic Align that are relevant for the generation of the blob image   我的S32 Design Studio for S32 Platform 3.6.0打不开IVT VIEW 报错：Could not create the view: com.nxp.swtools.ivt.views.IVTView   java.lang.Exception at org.eclipse.ui.internal.ViewReference.createErrorPart(ViewReference.java:115) at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:101) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPart(CompatibilityPart.java:304) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:342) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:976) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:938) at org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:138) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:385) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:311) Re: S32G274A 实现SHA256+RSA2048算法 Hi，tom9 Thank you for contacting us. The AN14070 remains a valid starting point for Cortex‑M7 evaluation, but it is recommended to use it together with the HSE Demo App package and HSE FW reference documentation. You can share detail error information with me in your testing. Regarding the application of secure boot on the S32G, you can try to refer to the following content: S32G_Secure_boot chinese/english version. At present, there are no specific documents directly meet your requirements. I will at the internal channels to help you in checking. I will reply to you if I have the results. BR Joey Re: S32G274A 实现SHA256+RSA2048算法 Hi,tom9 Thank you for your reply. The issue should be related the S32DS version. Refer to the HSE_DEMOAPP_S32G2XX_0_1_0_16_ReadMe.pdf, please try to use this recommended version. BR Joey Re: S32G274A 实现SHA256+RSA2048算法 I've finished creating the blob and burned it, but I can't see any print information on the serial port, and Trace32 can't load it either. Where should I start troubleshooting? Please take a look as soon as possible. Re: S32G274A 实现SHA256+RSA2048算法 Hi, tom9 1. Based on AN14070, the blob is created and flashed. It then boots via QSPI to load the HSE firmware and start the M7_0. After QSPI boot, you can try using Trace32 to connect to the M7_0 and check the SRAM contents to see if the app has been loaded to the correct address. 2. Load the HSE demo .elf file only after the application starts normally. Then proceed to the next step in the process, moving to SRAM. BR Joey Re: S32G274A 实现SHA256+RSA2048算法 Your answers never meet my expectations. I can now print information normally, as shown below: HSE FW Version: 0.1.0_1.0.9 HSE FW Image: Pink HSE FW up and running! Status: HSE_STATUS_RNG_INIT_OK HSE_STATUS_INIT_OK HSE_STATUS_CUST_SUPER_USER The program got stuck here and couldn't proceed. After commenting out `DEBUG_LOOP(gZero);`, it was found that it was stuck in `HSE_Config();`. /* Backup primary image */ ASSERT(FLASH_OP_OK == Flash_WriteData_FromFlash(IVT.pSysImage_bck, The code `ITV.pSysImage, MAX_SYS_IMG_SIZE)` gets stuck here. Subsequent code such as `HSE_Aes_Example` also fails to execute.

S32K358 eMIOS ISR stuck at 85°C Dear NXP Support Team, we are facing an issue on S32K358 during temperature tests at around 85°C.   In our application we use 6 eMIOS channels, each one configured to generate interrupts on both PWM edges with a frequency of 200Hz.   At 85°C, the MCU sometimes gets stuck inside one eMIOS ISR. The ISR does not exit because the code checks the interrupt flag by reading the eMIOS registers, but the flag is 0 (file Emios_Mcl_Ip_Irq.c 😞   if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))    After debugging, we noticed that when the issue occurs, the variable containing the eMIOS base address is NULL (Emios_Ip_paxBase). When the application works correctly, the same pointer is valid and the eMIOS registers are read properly. It seems that, in some conditions, the reference to the eMIOS peripheral is corrupted or cleared during ISR execution.   Do you have any indication about possible known issues or root causes, such as stack overflow, memory corruption, concurrent accesses, ISR handling, or temperature-related behavior?   Best regards, Simon Re: S32K358 eMIOS ISR stuck at 85°C Hi vane, I'm currently using RTD 7.0.0 Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Which RTD version are you working with? Any additional information would be helpful. Also, in RTD versions prior to 6.0.0, there was a known issue related to the incorrect memory mapping of static variables within function scope (ARTD-159985). This issue describes a problem where the variable Emios_Ip_paxBase, defined in both Emios_Mcl_Ip.c and Emios_Mcl_Ip_Irq.c, is assigned inconsistent initialization characteristics. Further details are provided in the Software Release Notes. BR, VaneB Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Could you please provide a simple application that reproduces the observed behavior? Also, could you confirm whether you are working with a custom board or an evaluation board? Additionally, could you share how the testing is being performed to confirm that the issue occurs at 85 °C?

The S32K311 chip cannot enter the PIT interrupt Software environment: S32DS 3.6.0  RTD 6.0.0 The program did not enter an interrupt during execution, and pit_notification was not called. Software environment: S32DS 3.6.0  RTD 6.0.0 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 I added a breakpoint inside the function to test it, but the function wasn’t called. What could be the possible reasons for this? The counter is incrementing normally, and no interrupt has been triggered. Could different software versions be a factor? Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  Currently, I do not have access to an S32K311 board. However, I tested the same configuration and code on an FRDM-A-S32K312, and I was able to confirm that PitNotification is called and the counter increments as expected. Could you set a breakpoint inside the notification function to verify whether it is being called? BR, VaneB Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 When running at full speed, pit_notification is not triggered , and the PitCount value remains at 0. The register parameters when paused are shown in the figure. Could this be related to the clock configuration? The configuration is as follows: Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  I was able to test your code on my side using an S32K311EVB, and everything is working as expected. To help rule out any issues related to your custom hardware, could you please try switching the clock source to FIRC and see if there is any change in the behavior? Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  As observed in your code, the counter only increments when PitNotification is called. This indicates that the PIT interrupt is being triggered correctly. For a simpler and more visible test, you can use printf to output the counter value inside the PitNotification function. If you are able to see the printed values, this will further confirm that the interrupt is being executed as expected. For example, I implemented it as follows: Also, if you need help setting up printf, refer to the thread how to use the printf function in S32DS 3.5? Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  It seems that the problem might not be software related; it may instead be associated with your custom board. Do you have access to another board with an S32K311 device that you could use to run the same test for comparison? Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 It also fails to enter pit_notifaction when using the internal clock. Furthermore, communication interrupts and other interrupts do not function correctly. I tested the same program and configuration on an S32K312, and it ran normally. Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 There are currently no other boards equipped with the S32K311, and several of the same boards exhibit the same problem. Only the S32K312 chip runs normally with the same program and configuration. The cause of the K311 malfunction has not been found. Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  Since the code is working as expected on my side with both the FRDM-A-S32K312 and the S32K31XEVB-Q100, and also on your side using the S32K312, it seems that the issue might not be software-related. Based on the behavior you described, this could potentially be related to the hardware. However, it is difficult to determine the exact root cause without further analysis. It might be helpful to take a look at the S32K31XEVB-Q100 schematic and the Hardware Design Guidelines for S32K3xx Microcontrollers file (included in the S32K3 General Purpose Hardware Design Package) to compare your custom board against the recommended design practices. If you think the issue could be related to the MCU itself, please contact your NXP representative or the distributor from whom the parts were purchased for further assistance.

ニューヨーク州ニューヨーク市の離婚弁護士 ニューヨークの離婚弁護士は家族法を専門とし、離婚、別居、または関連問題の解決を求める方々に専門的な代理を提供します。彼らの専門分野は、離婚、別居合意、子どもの親権、面会、養育費、配偶者扶養、財産分割、婚前および婚後契約、父性紛争、既存契約の修正などです。優れた離婚弁護士は、ニューヨークの家族法の経験、優れた交渉および訴訟スキル、共感力、細部への注意力、そして地元の裁判所や手続きの知識を持っているべきです。離婚弁護士を雇うメリットとしては、権利と利益の保護、複雑な手続きにおける専門家の指導、個別の対応、有利な結果が得られる可能性の向上、ストレスや精神的負担の軽減などが挙げられます。資格のあるニューヨーク州離婚弁護士 を見つけるためのリソース:州弁護士協会、アメリカ婚姻弁護士協会、そして全米州裁判所センター。 Re: new york ny divorce lawyer 深刻な犬の攻撃は、被害者に身体的な怪我や医療費、将来への不確実性をもたらす可能性があります。テキサス州で犬に噛まれたことによる傷害賠償請求を行うことで、治療費、逸失利益、精神的苦痛、その他事故に関連する損害に対する補償を得られる可能性があります。テキサス州の経験豊富な犬咬傷弁護士は、襲撃の状況を確認し、裏付けとなる証拠を集め、被害者を法的手続きに導きます。事件が公共の場所で発生したか私有地で発生したかにかかわらず、自分の権利を理解することは、自分の利益を守るための重要な一歩です。地元の代理を求める方には、アーリントンの犬咬傷弁護士がCASEの詳細に合わせた法的支援を提供できます。テキサス州の信頼できる人身傷害弁護士は、被害者がテキサス州法に基づいて受け取る権利のある賠償金を得られるよう支援します。

i.MX RT1064 - PEmicro 连接助手错误和启动配置意外更改 您好， 我正在使用i.MX RT1064控制器，并通过 MCUXpresso IDE 中的PEmicro Multilink接口进行调试/烧录。 有时，我在尝试连接目标设备时会遇到附件中的“PEmicro 连接助手”错误。这个问题似乎是随机发生的；我还没有发现任何特定的软件活动、代码更改或硬件事件会持续触发信号它。 我观察到，当出现此错误时，控制器的启动配置似乎发生了意外变化。在这种状态下，我无法对设备进行刷机或调试。我目前唯一能恢复的方法是将启动配置恢复到其原始设置——内部闪存模式，之后刷写和调试功能就能再次正常工作了。 一些补充细节： MCU：i.MX RT1064 调试探针：PEmicro 多链路通用 Rev E IDE：MCUXpresso IDE 有人遇到过类似的问题吗？ 我希望您能就以下方面提供指导： 什么原因会导致启动配置意外更改？ 是否存在调试器或应用程序代码可能影响启动配置的已知场景。 防止这种情况发生的建议方法。 能否在不手动更改的情况下通过软件更改启动配置 我附上了错误信息的截图供您参考。 谢谢！ i.MX RT106x Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 你好， 您能帮我解答以下问题吗？ 你用的是定制主板还是EVK主板？ 您使用的是哪个版本的SDK和IDE？ 你烧断过熔丝吗？ 您提到需要将启动配置恢复到内部闪存模式——您目前使用的是哪种启动配置？ 此致， 巴勃罗

SSSCLIがSE051で標準サポートしているAESモードは何ですか? こんにちは、 現在、Plug & Trust Middlewareのssscliツールを使用してSE051の評価を行っています。 私の目標は、CBC、ECBなどのモード、理想的にはGCMやCCMのようなAEADモードを使ってAES暗号および復号化を行うことです。 ssscli の Python ソースコードを調べていたところ、以下の点に気づきました。 const.pyでは、CRYPT_ALGO辞書はAES_CTRのみを定義しています。 cli.py では、encrypt コマンドと decrypt コマンドのヘルプ テキストには --algo oaep と --algo rsaes しか記載されていません。 商用製品で使う予定なので、NXPが提供するソースコード(const.py や cli.py など)を改変するのは避けたいです。 以下の点について説明していただけますか? 標準サポート: ソースコードを改変せずに、現在のリリース(04.07.01)でSSSCLIの暗号化/復号コマンドで利用可能なAESモードは何ですか? AES_CTRに限定されるのでしょうか？ 代替アプローチ: PythonのCLIスクリプトを改変せずにCBCやGCMのような他のモードを使う必要がある場合、C-APIを使ってカスタムアプリケーションを開発するのが推奨されるのでしょうか? それとも、これらの特定のAESモードを評価するための他の既成のNXPツールやバイナリはありますか? 環境: ボード： MCIMX8M-WEVKとOM-SE051ARD SoC: i.MX 8M Linux版: 6.1.151-CIP46 Plug & Trust MW バージョン: 2001年4月7日 何かご助言いただければ大変ありがたいです。 Re: What AES modes are supported out-of-the-box by ssscli for SE051? こんにちは、 @Uc_S さん。 はい、SSSCLIによるAESのすぐに使えるサポートはAES_CTR単に限られています。Pythonコードを修正したくない場合は、MWに示されている例のようにCでカスタムアプリケーションを開発する必要があります。例えばex_sss_symmetricのデモなどです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: What AES modes are supported out-of-the-box by ssscli for SE051? 明確なご回答をありがとうございました。 よく分かります。ssscliで標準でサポートされているモードはAES_CTRのみであることを知っておくと非常に役立ちます。 ご助言をもとに、提供された例を用いて他のAESモードを実装するためのカスタムCアプリケーションの開発を検討します。

i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Hello  I am experiencing an issue when trying to use HABv4 on an i.Mx8mm processor. To be precise hab_rvt_authenticate_image hangs when being called over the "Secure Monitor Call Calling Conventions" (smccc) in U-Boot proper. It hangs when trying to authenticate my Bootscript (boot.scr). In SPL the direct call (from elevation level 3) to the ROM function works correctly.  I have blown the SRK_Hash Fuses, but the rest of the System is still in an open configuration. What is interesting is the fact, that when I take an Image built from our Github Pipeline, where a different set of keys is used, the System is able to boot, generating the expected HAB Events as the SRK Hashes obviously don't match. Comparing the working and non working boot scripts shows no difference in the IVT and CST headers.  Using csf_parse from the CST also produces the same results from both files.  I have verified the adresses and arguments passed to the authenticate function. The bootcontainer is located inside the eMMC while the Rest of the Image (Bootscript, Kernel, Rootfs) is on the sd card. Booting an unsigned image without IVT and csf header works, as it will not call the authenticate function at all. Board: Toradex Verdin imx8mm Uboot Version: 2024.07 Images were signed using CST 3.4.0 Do you have any idea as to why the authenticate call never returns when using one set of keys (the one matching to the SRK_HASHes in the fuses) while using the wrong one? Thanks a lot for your help i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Security Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc 1. Can you share your csf file, genIVT.sh file and signed bootscript? and running commands to sign bootscript? 2. Did you read SNVS status in u-boot command line? Please share log before and after authenticate signed bootscript. u-boot => md.l 0x30370000 0x40 Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Hello  Thanks for your response 1. I have put together the script parts used to sign the bootscript as an attachment. Please note that we use a custom build system that also does other stuff. This is where some of the ENV variables are coming from, which is not directly visible in the snippets. I have also attched the signed boot script (boot.scr) as well as the boot.cmd. They are in the boot.zip folder. 2. Here is the output from your command before running the auth. Unfortunately i can't get it after, because the system hangs and will eventually be reset by the watchdog. Verdin iMX8MM # md.l 0x30370000 0x40 30370000: 00000000 80002100 00000000 00000000 .....!.......... 30370010: 00000000 80009b00 00002000 00000000 ......... ...... 30370020: 00000000 00000000 00000000 00000000 ................ 30370030: 00000000 00000000 00000020 00000000 ........ ....... 30370040: 00000000 00000000 00000000 40000000 ...............@ 30370050: 00000000 00000000 00000000 00000000 ................ 30370060: 00000000 41736166 00000000 00000000 ....fasA........ 30370070: 00000000 00000000 00000000 00000000 ................ 30370080: 00000000 00000000 00000000 00000000 ................ 30370090: 00000000 00000000 00000000 00000000 ................ 303700a0: 00000000 00000000 00000000 00000000 ................ 303700b0: 00000000 00000000 00000000 00000000 ................ 303700c0: 00000000 00000000 00000000 00000000 ................ 303700d0: 00000000 00000000 00000000 00000000 ................ 303700e0: 00000000 00000000 00000000 00000000 ................ 303700f0: 00000000 00000000 00000000 00000000 ................ The file U-Boot-Output.txt contains the output of uboot. Note that I have added in some additional debug print statements. Let me know if you have any questions regarding the content of the files Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc In order to make sure JR0 work well in u-boot case, please do below tests, Test 1. Use Engine = SW' instead of 'Engine = CAAM' in all csf file, see authentication can work well? Test 2. Dump CAAM registers in u-boot command line and share us the log u-boot=> mw  0x3034002c  0x2e1 u-boot=> md 0x30900000  1024 Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Test 1: I changed the engine to SW for everything except U-Boot. For U-Boot I couldn't change it as the bootscript from meta-toradex-security used to sign the uboot failed when changing the engine Result: Same behavior as before, i.e not working Test 2: You can find the CAAM register dump in the attachments. (Read before experiencing the failure, because after the failure I can't get into the Uboot console) Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc 1. Can you sign bootscript manually by setting 'engine=SW' in csf file? Not use Yocto meta. 2. I didn't find CAAM register dump in attachment. Please upload again. Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Regarding point 1: The bootscript was not signed with the yocto meta script. Only the SPL and Uboot proper is. The bootscript was signed with the commands from build.sh in the post. Changing the engine here did not produce any different behaviour. Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Hi Can you see the file now? Filename is "CAAM_Register_dump.txt I will try signing the bootscript manually and get back to you. Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Hi We are using upstream uboot https://github.com/u-boot/u-boot/tree/v2024.07 and applying some patches. You can find the patches in the attached zip folder. We build uboot according to https://docs.u-boot.org/en/stable/board/toradex/verdin-imx8mm.html  Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Change all instances where Engine = CAAM to SW, including in build.sh where Engine = CAAM is set. Also check whether the user has written to the memory region 0x00900000 - 0x00910000, as this region is reserved for HAB.      3.  Additionally, we need the specific BSP version.      U-Boot Version: 2024.07      Do you know which BSP this corresponds to?      I couldn’t find this version on GitHub.     I’m planning to reproduce this locally,     but we need to match the versions correctly. Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Thanks for your update. 1. If 'engine=SW' has no effect, it indicates the issue is not related to CAAM JR0, seems a software problem. 2. I can't find your u-boot version in NXP u-boot branch, I want to reproduce the issue on my side, but I don't know use which u-boot. Can you try NXP u-boot branch on your board? Such as GitHub - nxp-imx/uboot-imx at lf_v2024.04 · GitHub Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Yes sorry, I didn't get to it yesterday. 1. I have changed to ENGINE=SW everyhwere. -> No effect on the issue 2. I don't see anything writing to these addresses.  Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Would you please confirm the first two questions which I asked previously? Change all instances where Engine = CAAM to SW, including in build.sh where Engine = CAAM is set. Also check whether the user has written to the memory region 0x00900000 - 0x00910000, as this region is reserved for HAB. Re: i.Mx8mm HABv4 hangs when calling hab_rvt_authenticate_image from arm_smccc_smc Hello Sorry for the late reply. I did some further testing on my side, and got the problem fixed. The problem only occured when the SRK Hash Fuses contained the matching material to the one used to sign the bootscript. A mismatch would correctly show the expected HAB Events. Since I had a build from > 1 year ago and the only plausible difference to that was the arm trusted firmware a version used, I rolled that back to v2.12 and it now works.  Thank you very much for your time.

s32r45はeMMCから起動できません 当社の基板はeMMCからの起動ができませんが、SDカードからの起動は正常に動作します。 S32FlashTool_v2.1.4を使用してシリアル経由でfsl-image-車載-s32r45evb.sdcardという名前のイメージをeMMCに書き込み、ブート選択をeMMCブートに設定した後、シリアルポート0に何も出力されません。 専門家に見てもらって、問題箇所を特定してもらいましょう。 Re: s32r45 unable to boot from eMMC こんにちは、ピーター 私が書き込んだファイルは、公式にダウンロードしたファイル fsl-image-auto-s32r45evb.sdcard です。コンソール出力は、デフォルトでシリアルポート0、ボーレート115200に設定されていますか？ よろしくお願いします Re: s32r45 unable to boot from eMMC こんにちは、 ブート構成設定「001」が「予約済み」を意味することを確認してください。ブート構成011と001を試してみました。 IVTの正しいオフセット位置がロードされました。次の画像は、eMMCから読み取られたデータを示しています。 Re: s32r45 unable to boot from eMMC こんにちは、 レーダーチームと話していたのですが、正しくする必要があります。 1. ブート設定 正しい設定001bを使用していることを確認してください。 そして、ソフトウェアは正しいオフセット位置にロードされていますか？ よろしくお願いいたします。 ピーター 回复： s32r45 unable to boot from eMMC SW32R45 Linux BSP 39.0.0 は S32R45 Linux BSP のバージョンです。 Re: s32r45 unable to boot from eMMC 新たな発見：8回の再起動試行後、BootROMはシリアルブートモードに移行する。 Re: s32r45 unable to boot from eMMC eMMC回路で4本のデータラインを使用する場合、eMMC信号線は1.8Vを採用します。 Re: s32r45 unable to boot from eMMC お使いのデバイスのeMMCバージョンは何ですか？5.0？ EMMCのブート問題が発生した場合、S32R45側のエラーログが役立つでしょう。