Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
使用 i.MX 95 SPSDK 实现安全启动(日本博客) 介绍 本文档描述了使用 安全配置 SDK (SPSDK) 在 i.MX 95 上创建和启动签名容器镜像以进行安全启动的过程。 除了经典的 RSA 和椭圆曲线数字签名 (ECDSA) 之外,i.MX 95 还支持后量子密码 (PQC) ML-DSA 作为安全启动数字签名算法。 在这里,我们将通过一个示例来探讨如何使用混合启动来实现 ECDSA 和 PQC ML-DSA 签名认证。 安全启动过程(概念图) 创建签名图像 SRKH:超级根密钥哈希 i.MX 95 AHAB(高级高精度启动)安全启动流程 本文假设您已经为i.MX 95 构建过一次 Linux BSP。 请参考以下文章了解如何构建该项目。 构建目标必须是 i.MX 95 的机器名称,但方法类似。 【新手指南】如何构建 Yocto Linux BSP - i.MX FRDM 开发板版(日语博客) 【新手指南】如何构建 Yocto Linux BSP - i.MX 8M Plus 版 本次测试所用的环境 硬件: i.MX 95 19x19 LPDDR5 EVK开发板 软件:Linux BSP 版本 L6.18.2-1.0.0 工具:SPSDK 版本 3.9.0Linux 版本 如果您使用 eMMC/SD 启动,则可以对FRDM i.MX 95 开发板(FRDM-IMX95 / LPDDR4X 兼容)执行相同的程序。 目录 1. Linux BSP 的准备工作 2. 安装 SPSDK 3. 密钥创建 4. 准备 YAML 文件 5. 准备工作空间 6. 创建签名图像 7. 引入签名图像 8. SRKH(超级根密钥哈希)eFuse 程序 9. 将生命周期更新为 OEM 关闭。 10. 检查 ELE 事件 11. 直接对引导加载程序进行签名   eMMC/SD启动和FlexSPI NOR启动的准备步骤和命令略有不同。因此,请按照您要测试的启动设备对应的步骤进行操作。 1. Linux BSP 的准备工作 1.1 引导加载程序 FlexSPI NOR 启动 BSP 的默认引导加载程序配置为 eMMC/SD 引导。 对于 FlexSPI NOR 启动,请将以下内容添加到 / /conf/local.conf 文件中。 UBOOT_CONFIG = "fspi" eMMC/SD/FlexSPI NOR启动通用 使用启用了u-boot CONFIG_AHAB_BOOT 的引导加载程序构建。 $ cd $ source setup-environment $ bitbake u-boot-imx -c cleansstate $ bitbake u-boot-imx -c configure $ bitbake u-boot-imx -c devshell 将会打开一个单独的 shell,您可以在其中修改 u-boot 配置。 # make O=../../build/ / menuconfig 使用 O= 指定的构建目录路径应根据您的实际环境进行调整。 ../../build/ /.config然后,确认显示 CONFIG_AHAB_BOOT=y 并返回到原始 shell。 # exit 使用原始 shell 重新构建。 $ bitbake u-boot-imx -c compile -f $ bitbake imx-boot 1.2 Linux 内核和设备树 我们将直接使用用 BSP 构建的二进制文件。 构建好的二进制文件创建在 BSP 的 /tmp/deploy/images/ / 目录中。 2. 安装 SPSDK 请按照SPSDK 安装指南准备和安装 Python 虚拟环境 (venv)。 安装完成后,检查是否可以查看版本信息和帮助。 (venv) $ spsdk --version (venv) $ spsdk --help 我们还将添加 PQC 插件。 (venv) $ pip install spsdk-pqc 3. 密钥创建 我们将为 ECDSA SECP384 创建四对私钥/公钥。 (venv) $ mkdir -p keys/secp384r1 (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk0_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk1_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk2_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk3_secp384r1.pem 我们还将为 PQC ML-DSA 创建四对私钥/公钥。 (venv) $ mkdir keys/mldsa65 (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk0_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk1_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk2_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk3_mldsa65.pem 将公钥哈希(超级根密钥哈希 - SRKH)写入 i.MX 95 的内置 eFuse 后,在重建镜像时,需要使用与该公钥配对的私钥对其进行签名,因此请保存您创建的所有密钥。 我不会将我的私钥透露给任何第三方。 4. 准备 YAML 文件 在 SPSDK 中,YAML 文件指定容器头设置、私钥、公钥以及构成签名镜像的二进制文件的路径。 请同时参考本次操作验证中使用的示例 YAML 文件。 YAML 文件中的容器头部设置和键规范字段如下: 容器头部 YAML 键 内容 srk_set SRK 套装 已使用的 srk_id SRK精选 srk_revoke_mask SRK撤销面具 gdet_runtime_behavior GDET 启用 检查所有签名 请核对所有签名。 口袋 快速启动 熔丝版本 熔丝版 sw_version SW 演化 容器标头中的每个字段都在i.MX 95 参考手册的“容器标头详细信息”部分中进行了描述。 主要规格 YAML 键 内容 签名者 经典私钥 签名者#2 PQC私钥 srk_table 经典公钥表 srk_table_#2 PQC公钥表 在所有 YAML 文件中指定相同的键。 4.1 引导加载程序的 YAML 文件 创建 YAML 文件模板,并准备 spl.yaml 和 uboot.yaml。 (venv) $ nxpimage ahab get-template -f mimx9596 -o ahab_template.yaml (venv) $ cp ahab_template.yaml spl.yaml (venv) $ cp ahab_template.yaml uboot.yaml spl.yaml 指定文件,直到它们被加载到 i.MX 95 的内部 SRAM 中,并执行 DRAM 初始化训练等。 YAML 键 内容 二进制容器 ELE 启动固件(特定于掩码版本) lpddr_imem LPDDR4X 或 5 初始化固件 lpddr_imem_qb LPDDR4X 或 5 初始化固件 lpddr_dmem LPDDR4X 或 5 初始化数据 lpddr_dmem_qb LPDDR4X 或 5 初始化数据 oei_ddr OEI 系统管理器 系统管理器 spl U-boot SPL cortex_m7_app(选项) M7图像 image_path(选项) FCB 复制生成 uboot.yaml U-boot SPL 指定要加载到 DRAM 中的文件。 YAML 键 内容 脚气 ARM 可信固件 uboot U-boot T恤(可选) OP-TEE OS(选项) 4.2 移除 FCB - 仅 FlexSPI NOR 启动 用于 FlexSPI NOR 启动的 YAML 文件也指定了 FCB(FlexSPI 配置块)。因此,为 FlexSPI NOR 启动构建的标准未签名引导加载程序 (flash.bin)...接下来,我们将使用 SPSDK 命令提取 FCB。 i.MX 95 内置的 eFuse 的 FCB 位于 FlexSPI_NOR_FCB_Offset(默认值为 0x400)。从该偏移量提取 512 字节以创建 fcb.bin。 (venv) $ nxpimage utils binary-image extract -b flash.bin -a 0x400 -s 0x200 -o fcb.bin 4.3 操作系统容器的 YAML 文件 根据 YAML 文件模板准备 os_cntr.yaml 文件。 (venv) $ cp ahab_template.yaml os_cntr.yaml 在 os_cntr.yaml 中,键image_path设置要使用的 Linux 内核和设备树的路径,并设置其他必要的参数。 4.4 数字签名算法的选择 这将使用 i.MX 95 的内置 eFuse 或容器标头中的标志进行选择。 eFuse 容器头部中的标志字段 通过在容器头的标志字段中设置“位 15:检查所有签名”= 0x1,无论 eFuse 中的 ELE_BOOT_CRYPTO 设置如何,容器内的所有签名都将进行身份验证。 容器标头的 Flags 部分中的“检查所有签名”字段由 YAML 键“check_all_signature”指定。 5. 准备工作空间 在 SPSDK 中创建一个工作区,并将必要的密钥文件、YAML 文件和二进制文件放置在其中。 5.1 创建工作区 (venv) $ nxpimage bootable-image get-templates -f mimx9596 -o workspace 5.2 密钥文件 我会把生成密钥时创建的整个 `keys` 文件夹导入过来。 5.3 YAML 文件示例 用于测试的 YAML 文件附加在imx95-spsdk-yaml-examples.tar.gz中。 5.4 二进制文件 如果您想从 Yocto Linux BSP 获取二进制文件, 构成引导加载程序的二进制文件 从 $ bitbake -e imx-boot | grep ^S= 显示的路径中复制位于 iMX95/ 中的二进制文件。 Linux 内核 / /tmp/deploy/images/ /Image-- - - .bin复制此内容。 设备树 复制位于 / /tmp/deploy/images/ / 目录下的 dtb 文件,选择您想要使用的其中一个。 如果您使用示例 YAML 文件, Linux内核是一个镜像。 设备树文件为 imx95.dtb 它们将被归入这些名称之下。 5.5 eMMC/SD 启动 文件结构如下: 如果使用示例 YAML 文件,请根据 DRAM 类型将 spl.yaml 从 emmc_sd/spl-lpddr4x.yaml 或 spl-lpddr5.yaml 重命名,并将其放置在正确的位置。 在上述示例中,RevC 产品的 ELE 启动固件为 mx95b0-ahab-container.img(B0 掩码)。 5.6 FlexSPI NOR 启动 文件结构如下。此外,还需要 fcb.bin 文件。 如果您想使用示例 YAML 文件,请从 fspi_nor/ 复制 bootable_image_fspi_nor.yaml。 另外,将 spl_fspi_nor-lpddr5.yaml 重命名为 spl.yaml 并将其放置在正确的位置。 在上述示例中,RevC 产品的 ELE 启动固件为 mx95b0-ahab-container.img(B0 掩码)。 6. 创建签名图像 我们将使用 SPSDK 创建已签名的引导加载程序和已签名的操作系统容器镜像。 导航至工作区准备期间创建的目录,并开始在该目录中工作。 (venv) $ cd workspace/imx_boot_flash_all/imx95-19x19-lpddr5-evk/ 6.1 签名引导加载程序 spl.yaml 和 uboot.yaml 文件分别指定密钥文件和二进制文件,它们由 bootable_image.yaml 调用。 将创建一个已签名的引导加载程序 signed_flash.bin 和一个用于 SRKH eFuse 程序的脚本 (*.bcf)。 eMMC/SD启动 (venv) $ nxpimage -v bootable-image export --config bootable_image.yaml -o output/signed_flash.bin 将显示以下信息。 FlexSPI NOR 启动 (venv) $ nxpimage -v bootable-image export --config bootable_image_fspi_nor.yaml -o output/signed_flash.bin 将显示以下信息。 与 eMMC/SD 的一个区别是,它以“FCB”开头。 您可以执行图像验证。 // eMMC / SD ブート (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/signed_flash.bin -m serial_downloader // FlexSPI NOR ブート (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/signed_flash.bin -m flexspi_nor 6.2 已签名操作系统容器 os_cntr.yaml 的内容将用于创建已签名的操作系统容器镜像。 (venv) $ nxpimage -v ahab export -c os_cntr.yaml 将显示以下信息。 您可以执行图像验证。 (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/os_cntr_signed.bin -m serial_downloader 7. 引入签名图像 本文档解释了如何安装您创建的已签名引导加载程序和已签名操作系统容器。 7.1 签名引导加载程序 将 signed_flash.bin 写入 i.MX95 板的启动设备。 将开发板的调试端口和串口下载端口连接到您的电脑。 如果 u-boot 启动,则切换到 fastboot 模式。 u-boot=> fastboot 0 或者,您可以以串行下载模式启动系统 BOOT_MODE。 我们将使用SPSDK编写程序。 // eMMC (venv) $ nxpuuu write -b emmc -f mimx9596 output/signed_flash.bin // SD (venv) $ nxpuuu write -b sd -f mimx9596 output/signed_flash.bin // FlexSPI NOR (venv) $ nxpuuu write -b qspi -f mimx9596 output/signed_flash.bin 也可以使用标准的 uuu 或 u-boot 命令而不是 SPSDK 的 nxpuuu 命令来刷写设备。 7.2 已签名操作系统容器 将 os_cntr_signed.bin 放入已写入 BSP 映像的 eMMC 或 SD 卡的启动分区中。 u-boot 命令使 i.MX95 连接的 eMMC 或 SD 卡显示为 USB 存储设备,从而可以将其挂载到 PC 上。 串口下载端口必须连接到您的电脑。 // eMMC u-boot=> ums mmc 0 // SDカード u-boot=> ums mmc 1 将 os_cntr_signed.bin 复制到挂载到 PC 上的启动分区后,在 u-boot 中按 Ctrl-C。 或者,您可以使用另一种方法将 os_cntr_signed.bin 放入启动分区。 启动已签名的操作系统容器时,将显示以下消息: CONFIG_AHAB_BOOT 启用u-boot 后,将使用 os_cntr_signed.bin(已签名)镜像,而不是常规的 Linux 镜像(未签名)。 7.3 运行检查 在该阶段,i.MX95 的生命周期状态为 OEM Open,因此 u-boot 或 Linux 将启动,但会在ELE 事件中检测到密钥哈希验证失败。 8. SRKH(超级根密钥哈希)eFuse 程序 8.1 eFuse 写入 将公钥的哈希值写入 i.MX 95 SRKH eFuse。 一旦写入,就无法撤销。 当在写入的设备上更新已签名的引导加载程序或已签名的操作系统容器时,将使用作为写入的 SRKH 底层公钥对的私钥对其进行签名。 如果您想使用不同的密钥对,请撤销当前的 SRKH,并使用您创建的四个未使用的密钥对之一。 将 i.MX 95 板的串行下载端口连接到您的 PC,并事先确保 u-boot 设置为 fastboot 模式。 u-boot=> fastboot 0 SRKH eFuse 编程脚本 (*.bcf) 在创建签名映像期间创建。我们将使用此方法并使用 SPSDK 编写程序。 SRKH eFuse 编程脚本包含 i.MX 95 eFuse 的字索引。 // OEM_SRKH (venv) $ nxpele -f mimx9596 batch output/ahab_oem0_srk0_hash_nxpele.bcf // OEM_PQC_SRKH (venv) $ nxpele -f mimx9596 batch output/ahab_oem0_srk1_hash_nxpele.bcf 8.2 检查 eFuse 值 您可以使用 SPSDK 的 nxpele 命令指定 eFuse 的字索引并读取它以检查其值。 // OEM_SRKH[31:0] word index = 128 (venv) $ nxpele -f mimx9596 read-common-fuse -i 128 // OEM_PQC_SRKH[511:480] word index = 463 (venv) nxpele -f mimx9596 read-common-fuse -i 463 など 或者,您可以使用 U-boot 命令或系统管理器监视器命令通过读写操作访问 eFuse,而不是使用 SPSDK。 U-boot u-boot=> 熔丝读取 u-boot=> fuse prog 系统管理器 >$ fuse.H >$ fuse.w 8.3 运行检查 现阶段,i.MX 95 的生命周期状态为 OEM 开放,但由于它已编程为 SRKH,除非被篡改,否则不会检测到ELE 事件。 即使发生篡改,如果该部分不影响操作,它将启动 OEM Open,但身份验证失败将在ELE 事件中检测到。 9. 将生命周期更新为 OEM 关闭。 i.MX 95 在出厂后的生命周期为 OEM 开放式。 调试完成后,将 i.MX 95 生命周期更改为 OEM 关闭。 关闭OEM后需要注意的几点 您无法恢复到OEM Open 模式。 CONFIG_AHAB_BOOT=y 使用包含 u-boot 的引导加载程序启动时,未签名的镜像和签名无效的镜像将无法启动。 CONFIG_AHAB_BOOT=y 如果引导加载程序包含 u-boot 但未进行此设置,则可以使用未签名的 Linux 镜像启动。因此,为确保始终启动操作系统容器 os_cntr_signed.bin,请使用包含 u-boot 且设置了 CONFIG_AHAB_BOOT=y 引导加载程序。 验证功能后,未签名的 Linux 镜像和设备树将从启动分区中删除。 9.1 SPSDK 将 i.MX 95 板的串行下载端口连接到您的 PC,并事先确保 u-boot 设置为 fastboot 模式。 u-boot=> fastboot 0 使用 SPSDK 更新生命周期。 (venv) $ nxpele -f mimx9596 forward-lifecycle-update -l OEM_CLOSED Forward Lifecycle update ends successfully. (venv) $ 9.2 U-boot u-boot=> ahab_close 即使将设备标记为 OEM 关闭,使用 uuu 写入 BSP 映像(wic 文件)时,仍然需要使用签名引导加载程序。 10. 检查 ELE 事件 ELE(Edgelock Secure Enclave)是 i.MX 95 中的一个内置模块,用于在安全启动期间验证容器镜像。 您可以使用 SPSDK、U-boot 和系统管理器命令检查 ELE 状态。 10.1 SPSDK 请先将串口下载端口连接到您的电脑,并使用 U-boot 进入 fastboot 模式,然后再继续操作。 u-boot=> fastboot 0 我们将使用 SPSDK 检索 ELE 事件。 (venv) $ nxpele -f mimx9596 get-events 10.2 U-boot CONFIG_AHAB_BOOT=y 这些是可以与 U-boot 一起使用的命令。 根据设备的生命周期,还会显示它是 OEM 开放式还是 OEM 封闭式。 u-boot=> ahab_status 10.3 系统管理器 >$ ele events 10.4 显示示例 当检测到ELE事件(SRKH值不匹配)时 SPSDK U-boot(当 OEM 打开时) 系统管理器 当未检测到ELE事件时 SPSDK U-boot(OEM 闭环后) 系统管理器   11. 直接对引导加载程序进行签名 也可以使用 SPSDK 直接向现有的未签名引导加载程序二进制文件添加签名。 在这种情况下,SPSDK 会解析来自引导加载程序二进制容器的配置。 虽然不能在 YAML 文件中为每个镜像指定详细设置,但只需指定容器头设置以及私钥和公钥的路径,即可创建签名引导加载程序。 11.1 模板创建 (venv) $ nxpimage ahab get-template -f mimx9596 -o ahab_sign.yaml --sign (venv) $ cp ahab_sign.yaml sign.yaml 11.2 YAML 文件 在 sign.yaml 中指定容器头部设置以及私钥和公钥的路径。 如果您使用的是示例 YAML 文件,请复制 direct_signing/sign.yaml。 11.3 添加签名 现有的引导加载程序二进制文件 flash.bin 将被签名。 // eMMC / SD (venv) $ nxpimage ahab sign -c sign.yaml -b flash.bin -o output/flash_directsign.bin -fs output // FlexSPI NOR (venv) $ nxpimage ahab sign -c sign.yaml -b flash.bin -o output/flash_directsign.bin -fs output -m flexspi_nor output/flash_directsign.bin 和 SRKH eFuse 编程脚本 output/*.bcf这将被创建。 综上所述 本文档介绍了如何使用 SPSDK 为 i.MX 95 安全启动创建签名镜像并启动该镜像,以保护 SoC 启动镜像。本示例演示了如何使用 PQC(i.MX 95 AHAB 中新增的功能)来完成此过程。 ========================= 即使您在本文的“评论”栏留言,我们目前也无法回复。 给您带来不便,我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 (如果您已经是NXP的代理商或与其有合作关系,可以直接向负责人咨询。) 本课程提供实践学习体验,讲解如何使用 安全配置 SDK (SPSDK) 创建和启动签名容器镜像,以便在 i.MX95 上进行安全启动。 本文档提供了一个示例,说明如何在混合启动环境中同时使用椭圆曲线数字签名密码学 (ECDSA) 和后量子密码学 (PQC) ML-DSA 来实现签名认证。 (预计工作时间:半天 *假设 i.MX 95的Linux BSP 构建已经完成一次) i.MX 处理器 安全 日本博客
View full article
Secure Boot with i.MX 95 SPSDK (Japanese Blog) Introduction This document describes the procedure for creating and booting a signed container image using the Secure Provisioning SDK (SPSDK) for secure booting on i.MX 95 . In addition to classic RSA and Elliptic Curve Digital Signatures (ECDSA), i.MX 95 also supports Post -Quantum Cryptography (PQC) ML-DSA as a secure boot digital signature algorithm. Here, we will look at an example of implementing both ECDSA and PQC ML-DSA signature authentication using Hybrid Boot. Secure Boot Process (Conceptual Diagram) Creating a signed image SRKH: Super Root Key Hash i.MX 95 AHAB (Advanced High Accuracy Boot) Secure Boot Flow This article assumes that you have already built the Linux BSP for i.MX 95 once. Please refer to the following article for instructions on how to build the project. The build target needs to be the machine name of the i.MX 95, but the method is similar. [Beginner's Guide] How to Build Yocto Linux BSP - i.MX FRDM Board Edition (Japanese Blog) [Beginner's Guide] How to Build Yocto Linux BSP - i.MX 8M Plus Edition The environment used for testing this time Hardware: Development board i.MX 95 19x19 LPDDR5 EVK Software: Linux BSP version L6.18.2-1.0.0 Tools: SPSDK version 3.9.0, Linux version If you are using eMMC/SD booting, you can perform the same procedure with the FRDM i.MX 95 development board (FRDM-IMX95 / LPDDR4X compatible). table of contents 1. Preparation on Linux BSP 2. Installing SPSDK 3. Key creation 4. Preparing the YAML file 5. Preparing the workspace 6. Creating a signed image 7. Introduction of signed images 8. SRKH (Super Root Key Hash) eFuse Program 9. Update the lifecycle to OEM Closed. 10. Checking ELE Events 11. Direct signing of the bootloader   The preparation procedures and commands used for eMMC/SD booting and FlexSPI NOR booting differ slightly. Therefore, please follow the procedure appropriate for the boot device you wish to test. 1. Preparation on Linux BSP 1.1 Bootloader FlexSPI NOR boot The BSP's default boot loader is configured for eMMC/SD booting. For FlexSPI NOR booting, add the following to the / /conf/local.conf file. UBOOT_CONFIG = "fspi" eMMC / SD / FlexSPI NOR Boot Common Use the bootloader built with u-boot CONFIG_AHAB_BOOT enabled. $ cd $ source setup-environment $ bitbake u-boot-imx -c cleansstate $ bitbake u-boot-imx -c configure $ bitbake u-boot-imx -c devshell A separate shell will open, where you can modify the u-boot configuration. # make O=../../build/ / menuconfig The build directory path specified with O= should be adjusted to match your actual environment. ../../build/ /.config Then, confirm that it shows CONFIG_AHAB_BOOT=y and return to the original shell. # exit Rebuild using the original shell. $ bitbake u-boot-imx -c compile -f $ bitbake imx-boot 1.2 Linux kernel and device tree We will use the binary built with BSP as is. The built binaries are created in the BSP's /tmp/deploy/images/ / directory. 2. Installing SPSDK Follow the SPSDK Installation Guide to prepare and install a Python virtual environment (venv). After installation, check if you can view version information and help. (venv) $ spsdk --version (venv) $ spsdk --help We will also add the PQC plugin. (venv) $ pip install spsdk-pqc 3. Key creation We will create four pairs of private/public keys for ECDSA SECP384. (venv) $ mkdir -p keys/secp384r1 (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk0_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk1_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk2_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk3_secp384r1.pem We will also create four pairs of private/public keys for PQC ML-DSA. (venv) $ mkdir keys/mldsa65 (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk0_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk1_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk2_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk3_mldsa65.pem After writing the public key hash (Super Root Key Hash - SRKH) to the i.MX 95's built-in eFuse, when you rebuild the image, you need to sign it with the private key that pairs with that public key, so save all the keys you've created. I will not disclose my private key to any third party. 4. Preparing the YAML file In SPSDK, the YAML file specifies the container header settings, the private key, the public key, and the paths to the binary files that make up the signed image. Please also refer to the example YAML file used in this operational verification. The container header settings and key specification fields in the YAML file are as follows: Container header YAML key Content srk_set SRK Set used_srk_id SRK Selection srk_revoke_mask SRK Revoke Mask gdet_runtime_behavior GDET enablement check_all_signatures Check all signatures pocket Fast Boot fuse_version Fuse Version sw_version SW Evolution Each field in the container header is described in the "Container header details" section of the i.MX 95 Reference Manual . Key specification YAML key Content signer Classic private key signer_#2 PQC private key srk_table Classic public key table srk_table_#2 PQC Public Key Table Specify the same key in all YAML files. 4.1 YAML file for bootloader Create a YAML file template and prepare spl.yaml and uboot.yaml. (venv) $ nxpimage ahab get-template -f mimx9596 -o ahab_template.yaml (venv) $ cp ahab_template.yaml spl.yaml (venv) $ cp ahab_template.yaml uboot.yaml spl.yaml Specify the files up to the point where they are loaded into the i.MX 95's internal SRAM and perform DRAM initialization training, etc. YAML Key Content binary_container ELE Boot Firmware (Binary specific to Mask Revision) lpddr_imem LPDDR4X or 5 Initialization Firmware lpddr_imem_qb LPDDR4X or 5 Initialization Firmware lpddr_dmem LPDDR4X or 5 initialization data lpddr_dmem_qb LPDDR4X or 5 initialization data oei_ddr OEI system_manager System Manager spl U-boot SPL cortex_m7_app (Option) M7 image image_path (Option) FCB copy generate uboot.yaml U-boot SPL specifies the files to be loaded into DRAM. YAML Key Content atf ARM Trusted Firmware uboot U-boot tee (Option) OP-TEE OS (Option) 4.2 Removing the FCB - FlexSPI NOR Boot Only The YAML file for FlexSPI NOR booting also specifies the FCB (FlexSPI Configuration Block). Therefore, the standard unsigned bootloader (flash.bin) built for FlexSPI NOR booting... Next, we'll extract the FCB using the SPSDK command. The FCB is located at the FlexSPI_NOR_FCB_Offset (default 0x400) of the i.MX 95's built-in eFuse. 512 bytes are extracted from that offset and used to create fcb.bin. (venv) $ nxpimage utils binary-image extract -b flash.bin -a 0x400 -s 0x200 -o fcb.bin 4.3 YAML file for OS container Prepare os_cntr.yaml from the YAML file template. (venv) $ cp ahab_template.yaml os_cntr.yaml In os_cntr.yaml, the key image_path sets the path to the Linux kernel and the device tree to be used, and other necessary parameters are also set. 4.4 Selection of a Digital Signature Algorithm This will be selected using the i.MX 95's built-in eFuse or the Flags in the container header. eFuse Flags field in the container header By setting "Bit 15: Check all signature" = 0x1 in the Flags field of the container header, all signatures within the container will be authenticated regardless of the ELE_BOOT_CRYPTO setting in eFuse. The "Check all signature" field in the container header's Flags section is specified by the YAML key "check_all_signature". 5. Preparing the workspace Create a workspace in SPSDK and place the necessary key files, YAML files, and binary files there. 5.1 Creating a Workspace (venv) $ nxpimage bootable-image get-templates -f mimx9596 -o workspace 5.2 Key File I'll bring over the entire `keys` folder that I created when generating the key . 5.3 Example YAML File The YAML file used for testing is attached to imx95-spsdk-yaml-examples.tar.gz . 5.4 Binary files If you want to get binary files from Yocto Linux BSP, The binary that makes up the boot loader Copy the binary located in iMX95/ from the path displayed by $ bitbake -e imx-boot | grep ^S=. Linux kernel / /tmp/deploy/images/ /Image-- - - .bin Copy this. Device Tree Copy one of the dtb files located in / /tmp/deploy/images/ / that you want to use. If you use the example YAML file , The Linux kernel is an image. The device tree is imx95.dtb They will be placed under these names. 5.5 eMMC / SD Boot The file structure will be as follows: If you use the example YAML file , rename spl.yaml from emmc_sd/spl-lpddr4x.yaml or spl-lpddr5.yaml depending on the DRAM type and place it in the correct location. In the above example, the ELE boot firmware is mx95b0-ahab-container.img for RevC products (B0 mask). 5.6 FlexSPI NOR Boot The file structure will be as follows. fcb.bin is also required. If you want to use the example YAML file , copy bootable_image_fspi_nor.yaml from fspi_nor/. Also, rename spl_fspi_nor-lpddr5.yaml to spl.yaml and place it in the correct location. In the above example, the ELE boot firmware is mx95b0-ahab-container.img for RevC products (B0 mask). 6. Creating a signed image We will create signed bootloader and signed OS container images using the SPSDK. Navigate to the directory created during workspace preparation and begin working there. (venv) $ cd workspace/imx_boot_flash_all/imx95-19x19-lpddr5-evk/ 6.1 Signed Bootloader The spl.yaml and uboot.yaml files, which specify the key file and binary file, are called from bootable_image.yaml. A signed bootloader, signed_flash.bin, and a script (*.bcf) for the SRKH eFuse program will be created. eMMC / SD Boot (venv) $ nxpimage -v bootable-image export --config bootable_image.yaml -o output/signed_flash.bin The following information will be displayed. FlexSPI NOR boot (venv) $ nxpimage -v bootable-image export --config bootable_image_fspi_nor.yaml -o output/signed_flash.bin The following information will be displayed. One difference from eMMC/SD is that it has "FCB" at the beginning. You can perform image verification. // eMMC / SD ブート (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/signed_flash.bin -m serial_downloader // FlexSPI NOR ブート (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/signed_flash.bin -m flexspi_nor 6.2 Signed OS Containers The contents of os_cntr.yaml will be used to create a signed OS container image. (venv) $ nxpimage -v ahab export -c os_cntr.yaml The following information will be displayed. You can perform image verification. (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/os_cntr_signed.bin -m serial_downloader 7. Introduction of signed images This explains how to install the signed bootloader and signed OS container you created. 7.1 Signed Bootloader Write signed_flash.bin to the boot device of the i.MX95 board. Connect the board's debug port and serial download port to your PC. If u-boot starts up, switch to fastboot mode. u-boot=> fastboot 0 Alternatively, you can start the system in BOOT_MODE as serial download mode. We will write the program using SPSDK. // eMMC (venv) $ nxpuuu write -b emmc -f mimx9596 output/signed_flash.bin // SD (venv) $ nxpuuu write -b sd -f mimx9596 output/signed_flash.bin // FlexSPI NOR (venv) $ nxpuuu write -b qspi -f mimx9596 output/signed_flash.bin It is also possible to flash the device using the standard uuu or u-boot command instead of the SPSDK's nxpuuu command. 7.2 Signed OS Containers Place os_cntr_signed.bin into the boot partition of the eMMC or SD card that already has the BSP image written to it. The u-boot command makes the connected eMMC or SD card of the i.MX95 appear as USB storage, allowing it to be mounted on the PC. The serial download port must be connected to your PC. // eMMC u-boot=> ums mmc 0 // SDカード u-boot=> ums mmc 1 After copying os_cntr_signed.bin to the boot partition mounted on your PC, press Ctrl-C in u-boot. Alternatively, you can place os_cntr_signed.bin into the boot partition using another method. When starting a signed OS container, the following message will appear: CONFIG_AHAB_BOOT With u-boot enabled , the os_cntr_signed.bin (signed) image is used instead of the regular Linux Image (unsigned). 7.3 Operation Check At this stage, the i.MX95's lifecycle state is OEM Open, so u-boot or Linux will start, but a KEY HASH verification failure will be detected in the ELE event . 8. SRKH (Super Root Key Hash) eFuse Program 8.1 eFuse Writing Write the hash value of the public key to the i.MX 95 SRKH eFuse. Once you write to it, you cannot undo it. When updating a signed bootloader or signed OS container on the written device, the private key, which is the public key pair underlying the written SRKH, is used to sign it. If you want to use a different key pair, revoke the current SRKH and use one of the four unused key pairs you have created. Connect the i.MX 95 board's serial download port to your PC, and ensure that u-boot is set to fastboot mode beforehand. u-boot=> fastboot 0 SRKH eFuse programming script (*.bcf) created during the creation of a signed image. We will use this and write the program using SPSDK. The SRKH eFuse programming script includes the word index for i.MX 95 eFuse. // OEM_SRKH (venv) $ nxpele -f mimx9596 batch output/ahab_oem0_srk0_hash_nxpele.bcf // OEM_PQC_SRKH (venv) $ nxpele -f mimx9596 batch output/ahab_oem0_srk1_hash_nxpele.bcf 8.2 Checking the eFuse value You can use the SPSDK's nxpele command to specify the word index of eFuse and read it to check the value. // OEM_SRKH[31:0] word index = 128 (venv) $ nxpele -f mimx9596 read-common-fuse -i 128 // OEM_PQC_SRKH[511:480] word index = 463 (venv) nxpele -f mimx9596 read-common-fuse -i 463 など Alternatively, you can access the eFuse via read and write using U-boot commands or System Manager monitor commands, instead of SPSDK. U-boot u-boot=> fuse read u-boot=> fuse prog System Manager >$ fuse.H >$ fuse.w 8.3 Operation Check At this stage, the lifecycle status of the i.MX 95 is OEM Open, but because it is programmed with SRKH, no ELE events will be detected unless it has been tampered with. Even if tampering occurs, if that part does not affect operation, it will boot for OEM Open, but the authentication failure will be detected in the ELE event . 9. Update the lifecycle to OEM Closed. The i.MX 95's lifecycle immediately after shipment is OEM Open. After debugging is complete, change the i.MX 95 lifecycle to OEM Closed. Points to note after closing the OEM You cannot revert to OEM Open. CONFIG_AHAB_BOOT=y When booting with a bootloader that includes u-boot, unsigned images and images with invalid signatures will not be able to boot. CONFIG_AHAB_BOOT=y A bootloader that does not include u-boot can boot with an unsigned Linux image. Therefore, to ensure that the OS container os_cntr_signed.bin is always booted, use a bootloader that includes u-boot with CONFIG_AHAB_BOOT=y . After verifying functionality, unsigned Linux images and device trees will be removed from the boot partition. 9.1 SPSDK Connect the i.MX 95 board's serial download port to your PC, and ensure that u-boot is set to fastboot mode beforehand. u-boot=> fastboot 0 Update the lifecycle using SPSDK. (venv) $ nxpele -f mimx9596 forward-lifecycle-update -l OEM_CLOSED Forward Lifecycle update ends successfully. (venv) $ 9.2 U-boot u-boot=> ahab_close Even after marking the device as OEM Closed, you will still need to use a signed bootloader when writing the BSP image (wic file) with uuu. 10. Checking ELE Events ELE (Edgelock Secure Enclave) is a built-in block in the i.MX 95 that authenticates container images during secure boot. You can check the ELE status using SPSDK, U-boot, and System Manager commands. 10.1 SPSDK Connect the serial download port to your PC and enter fastboot mode using U-boot before proceeding. u-boot=> fastboot 0 We will retrieve ELE events using SPSDK. (venv) $ nxpele -f mimx9596 get-events 10.2 U-boot CONFIG_AHAB_BOOT=y These are commands that can be used with U-boot. Depending on the device's lifecycle, it will also show whether it's OEM Open or OEM Closed. u-boot=> ahab_status 10.3 System Manager >$ ele events 10.4 Display Example When an ELE event (SRKH value mismatch) is detected SPSDK U-boot (when OEM open) System Manager When no ELE event is detected SPSDK U-boot (after OEM closure) System Manager   11. Direct signing of the bootloader It is also possible to directly add a signature to an existing unsigned bootloader binary using the SPSDK. In this case, SPSDK interprets the configuration from the bootloader binary container. While you cannot specify detailed settings for each image in a YAML file, you can create a signed bootloader by simply specifying the container header settings and the paths to the private and public keys. 11.1 Template Creation (venv) $ nxpimage ahab get-template -f mimx9596 -o ahab_sign.yaml --sign (venv) $ cp ahab_sign.yaml sign.yaml 11.2 YAML File Specify the container header settings and the paths to the private and public keys in sign.yaml. If you are using the example YAML file , make a copy of direct_signing/sign.yaml. 11.3 Adding Signatures The existing bootloader binary, flash.bin, will be signed. // eMMC / SD (venv) $ nxpimage ahab sign -c sign.yaml -b flash.bin -o output/flash_directsign.bin -fs output // FlexSPI NOR (venv) $ nxpimage ahab sign -c sign.yaml -b flash.bin -o output/flash_directsign.bin -fs output -m flexspi_nor output/flash_directsign.bin and the SRKH eFuse programming scripts output/*.bcf This will be created. In conclusion This document describes the process of creating a signed image for i.MX 95 Secure Boot using the SPSDK and booting it, in order to protect the SoC boot image. This example demonstrates the procedure using PQC, a new feature added in i.MX 95 AHAB. ========================= We are currently unable to respond to comments left in the "Comment" section of this post. We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making an inquiry. (If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) This course provides hands-on instruction on creating and booting signed container images for secure booting on i.MX95 using the Secure Provisioning SDK (SPSDK) . This document presents an example of implementing signature authentication using both Elliptic Curve Digital Signature Cryptography (ECDSA) and Post-Quantum Cryptography (PQC) ML-DSA in a Hybrid Boot environment. (Estimated work time: half a day *Assuming that the Linux BSP build for i.MX 95 has already been completed once) i.MX Processors Security Japanese Blog
View full article
i.MX 95 SPSDK によるセキュアブート (日本語ブログ) はじめに i.MX 95 でのセキュアブートに使用する署名付きのコンテナ・イメージを Secure Provisioning SDK (SPSDK) で作成し、起動する手順です。 i.MX 95 では、セキュアブートのデジタル署名アルゴリズムとして、クラシックなRSA暗号や楕円曲線デジタル署名暗号 (ECDSA)に加えて、耐量子暗号 (PQC)の ML-DSA もサポートされています。 ここでは、ECDSA と PQC ML-DSA 両方の署名認証を行うHybrid boot での実現例を見ていきます。 セキュアブート・プロセス(概念図) 署名付きイメージの作成 SRKH : Super Root Key Hash i.MX 95 AHAB (Advanced High Accuracy Boot) セキュアブート・フロー 本記事は、i.MX 95 向けのLinux BSP を一度ビルド済みの前提で紹介します。 ビルド方法については以下の記事をご参照ください。 ビルドするターゲットを、i.MX 95 のマシン名とする必要がありますが、同様の方法になります。  [入門] Yocto Linux BSPのビルド方法 - i.MX FRDMボード編 (日本語ブログ) [入門] Yocto Linux BSPのビルド方法 - i.MX 8M Plus編 今回動作確認に使用した環境 ハードウェア:開発ボード i.MX 95 19x19 LPDDR5 EVK ソフトウェア:Linux BSP Version L6.18.2-1.0.0 ツール:SPSDK version 3.9.0, Linux 版 eMMC/SDブートであれば、FRDM i.MX 95開発ボード(FRDM-IMX95 / LPDDR4X対応)でも同様の手順で実施することができます。 目次 1. Linux BSP での準備 2. SPSDK のインストール 3. 鍵の作成 4. YAMLファイルの準備 5. ワークスペースの準備 6. 署名付きイメージの作成  7. 署名付きイメージの導入 8. SRKH (Super Root Key Hash) eFuse のプログラム 9. ライフサイクルを OEM Closed に更新 10. ELE イベントの確認 11. ブートローダの直接署名   eMMC/SDブートとFlexSPI NORブートでは、準備手順や実行するコマンドが一部異なります。そのため、確認したいブートデバイスに応じた手順を実施してください。 1. Linux BSP での準備 1.1 ブートローダ FlexSPI NOR ブート BSP デフォルトでのブートローダは、eMMC/SD ブート用となっています。 FlexSPI NOR ブートの場合には、 / /conf/local.conf ファイルに下記を追記しておきます。 UBOOT_CONFIG = "fspi" eMMC / SD / FlexSPI NOR ブート共通 u-boot の  CONFIG_AHAB_BOOT  を有効にしてビルドしたブートローダを使用します。 $ cd $ source setup-environment $ bitbake u-boot-imx -c cleansstate $ bitbake u-boot-imx -c configure $ bitbake u-boot-imx -c devshell 別のシェルが開きますので、u-boot コンフィグレーションを変更します。 # make O=../../build/ / menuconfig O= で指定するビルド・ディレクトリのパスは、実際の環境に合わせます。 ../../build/ /.config で、 CONFIG_AHAB_BOOT=y  となっていることを確認し、元のシェルに戻ります。 # exit 元のシェルで、再ビルドを行います。 $ bitbake u-boot-imx -c compile -f $ bitbake imx-boot 1.2 Linux カーネルとデバイスツリー BSP でビルドされたバイナリをそのまま利用します。 ビルドされたバイナリは、BSP の  /tmp/deploy/images/ / に作成されています。 2. SPSDK のインストール SPSDK Installation Guide に従い、Python 仮想環境 venv を準備してインストールします。 インストール後、バージョン情報やヘルプ表示ができるかを確認します。 (venv) $ spsdk --version (venv) $ spsdk --help PQCプラグインも追加します。 (venv) $ pip install spsdk-pqc 3. 鍵の作成 ECDSA SECP384 の秘密鍵/公開鍵を、4ペア作成します。 (venv) $ mkdir -p keys/secp384r1 (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk0_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk1_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk2_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk3_secp384r1.pem PQC ML-DSA の秘密鍵/公開鍵も、4ペア作成します。 (venv) $ mkdir keys/mldsa65 (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk0_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk1_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk2_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk3_mldsa65.pem i.MX 95 内蔵eFuse に公開鍵のハッシュ Super Root Key Hash (SRKH) を書いたあと、イメージをビルドしなおした時は、その公開鍵とペアとなる秘密鍵で署名する必要があるので、作成したすべての鍵は保存しておきます。 秘密鍵は、第三者に開示しないようにします。 4. YAMLファイルの準備 SPSDK では、YAMLファイルに、コンテナヘッダ設定や、秘密鍵、公開鍵および、署名付きイメージを構成するバイナリファイルのパスを指定します。 あわせて、今回の動作確認で使用したYAMLファイルの例もご参照ください。 YAMLファイルでのコンテナヘッダ設定や、鍵を指定する項目は、次のようになっています。 コンテナヘッダ YAMLキー 内容 srk_set SRK Set used_srk_id SRK Selection srk_revoke_mask SRK Revoke Mask gdet_runtime_behavior GDET enablement check_all_signatures Check all signatures fastboot Fast Boot fuse_version Fuse Version sw_version SW Version コンテナヘッダの各フィールドは、i.MX 95 Reference Manual の、『Container header details』に記載されています。 鍵の指定 YAMLキー 内容 signer クラシック 秘密鍵 signer_#2 PQC 秘密鍵 srk_table クラシック 公開鍵テーブル srk_table_#2 PQC 公開鍵テーブル すべてのYAMLファイルで同じ鍵を指定します。 4.1 ブートローダ用YAML ファイル YAMLファイルのテンプレートを作成し、spl.yaml と uboot.yaml を準備します。 (venv) $ nxpimage ahab get-template -f mimx9596 -o ahab_template.yaml (venv) $ cp ahab_template.yaml spl.yaml (venv) $ cp ahab_template.yaml uboot.yaml spl.yaml i.MX 95 内蔵SRAM にロードされ、DRAM 初期化トレーニングなどを実施する部分までのファイルを指定します。 YAML キー 内容 binary_container ELE ブート・ファームウエア(マスク・レビジョン専用のバイナリ) lpddr_imem LPDDR4X or 5 初期化ファームウエア lpddr_imem_qb LPDDR4X or 5 初期化ファームウエア lpddr_dmem LPDDR4X or 5 初期化データ lpddr_dmem_qb LPDDR4X or 5 初期化データ oei_ddr OEI system_manager System Manager spl U-boot SPL cortex_m7_app (Option) M7 image image_path (Option) FCB copy image uboot.yaml U-boot SPL でDRAMにロードされる部分のファイルを指定します。 YAML キー 内容 atf ARM Trusted Firmware uboot U-boot tee (Option) OP-TEE OS (Option) 4.2 FCB の取り出し - FlexSPI NOR ブートのみ FlexSPI NOR ブート用のYAMLファイルでは、FCB (FlexSPI Configuration Block)も指定します。そのため、FlexSPI NOR ブート向けにビルドした通常の署名なしブートローダ (flash.bin) から、SPSDK コマンドにて、FCB を取り出しておきます。 i.MX 95 内蔵eFuse のFlexSPI_NOR_FCB_Offset (デフォルト 0x400) にFCB が配置されています。そのオフセットから 512 バイト分を取り出し、 fcb.bin を作成します。 (venv) $ nxpimage utils binary-image extract -b flash.bin -a 0x400 -s 0x200 -o fcb.bin 4.3 OSコンテナ用YAML ファイル YAMLファイルのテンプレートから、os_cntr.yaml を準備します。 (venv) $ cp ahab_template.yaml os_cntr.yaml os_cntr.yaml では、キー image_path で、Linux カーネルと使用するデバイスツリーのパスをセットし、その他必要なパラメータも設定します。 4.4 デジタル署名アルゴリズムの選択 i.MX 95 内蔵eFuse やコンテナヘッダのFlags で選択することになります。 eFuse コンテナヘッダの Flags フィールド コンテナヘッダの Flags フィールドにある "Bit 15: Check all signature" = 0x1 とすることで、eFuse のELE_BOOT_CRYPTO 設定によらず、コンテナ内にあるすべての署名を認証します。 コンテナヘッダの Flags フィールドの "Check all signature"は、YAML キー "check_all_signature" で指定します。 5. ワークスペースの準備 SPSDK でワークスペースを作成し、必要な鍵ファイル、YAML ファイル およびバイナリファイルを配置します。 5.1 ワークスペースの作成 (venv) $ nxpimage bootable-image get-templates -f mimx9596 -o workspace 5.2 鍵ファイル 鍵の作成で作ったkeys フォルダごと持ってきます。 5.3 YAML ファイル例 動作確認に使用したYAMLファイルを、imx95-spsdk-yaml-examples.tar.gz に添付しています。 5.4 バイナリファイル Yocto Linux BSP からバイナリファイルを持ってくる場合、 ブートローダを構成するバイナリ $ bitbake -e imx-boot | grep ^S= により表示されるパスの、 iMX95/ にあるバイナリからコピーします。 Linux カーネル / /tmp/deploy/images/ /Image-- - - .bin を コピーします。 デバイスツリー / /tmp/deploy/images/ /にあるdtb で、使用するもの1つコピーします。 YAMLファイルの例 を使用する場合、 ・Linux カーネルは、Image ・デバイスツリーは、imx95.dtb という名前で、それぞれ配置します。 5.5 eMMC / SD ブート 下記のようなファイル構成となります。 YAMLファイルの例を使用する場合、spl.yaml は、DRAMタイプにより、emmc_sd/spl-lpddr4x.yaml または spl-lpddr5.yaml から名前を変更して配置します。 上記では、ELE ブート・ファームウエア は、RevC 品 (B0マスク)用の mx95b0-ahab-container.img となっています。 5.6 FlexSPI NOR ブート 下記のようなファイル構成となります。fcb.binも必要です。 YAMLファイルの例を使用する場合、fspi_nor/から、bootable_image_fspi_nor.yaml をコピーしてきます。 また、spl_fspi_nor-lpddr5.yaml を spl.yaml に名前を変更し配置します。 上記では、ELE ブート・ファームウエア は、RevC 品 (B0マスク)用の mx95b0-ahab-container.img となっています。 6. 署名付きイメージの作成 署名付きブートローダと署名付き OS コンテナのイメージを、 SPSDK で作成します。 ワークスペースの準備 で作成されたディレクトリに移動して作業します。 (venv) $ cd workspace/imx_boot_flash_all/imx95-19x19-lpddr5-evk/ 6.1 署名付きブートローダ 鍵ファイルとバイナリファイルを指定する spl.yaml と uboot.yaml を、bootable_image.yaml から呼び出します。 署名付きブートローダ signed_flash.bin と、SRKH eFuse プログラム用のスクリプト (*.bcf) が作成されます。 eMMC / SD ブート (venv) $ nxpimage -v bootable-image export --config bootable_image.yaml -o output/signed_flash.bin 下記のような情報が、表示されます。 FlexSPI NOR ブート (venv) $ nxpimage -v bootable-image export --config bootable_image_fspi_nor.yaml -o output/signed_flash.bin 下記のような情報が、表示されます。 eMMC/SDとの違いとして、FCB が先頭についているのが分かります。 イメージの検証を行うことができます。 // eMMC / SD ブート (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/signed_flash.bin -m serial_downloader // FlexSPI NOR ブート (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/signed_flash.bin -m flexspi_nor 6.2 署名付きOSコンテナ os_cntr.yaml の内容で、署名付き OS コンテナのイメージを作成します。 (venv) $ nxpimage -v ahab export -c os_cntr.yaml 下記のような情報が、表示されます。 イメージの検証を行うことができます。 (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/os_cntr_signed.bin -m serial_downloader 7. 署名付きイメージの導入 作成した署名付きブートローダおよび署名付きOSコンテナを導入する方法です。 7.1 署名付きブートローダ i.MX95 ボードのブートデバイスに、signed_flash.bin を書き込みます。 ボードのデバッグ・ポートとシリアル・ダウンロード・ポートを、PC に接続します。 u-boot が起動する場合には fastboot モードにします。 u-boot=> fastboot 0 もしくは、BOOT_MODE を シリアル・ダウンロード・モード として起動しておきます。 SPSDKで書き込みます。 // eMMC (venv) $ nxpuuu write -b emmc -f mimx9596 output/signed_flash.bin // SD (venv) $ nxpuuu write -b sd -f mimx9596 output/signed_flash.bin // FlexSPI NOR (venv) $ nxpuuu write -b qspi -f mimx9596 output/signed_flash.bin SPSDK の nxpuuu コマンドではなく、通常の uuu または u-boot コマンドを使用して書き込むことも可能です。 7.2 署名付きOSコンテナ あらかじめBSP イメージが書き込んであるeMMC もしくはSDカード の boot パーティションに、os_cntr_signed.bin を入れます。 u-boot コマンドで、i.MX95 の接続されたeMMC または SDカードを、USBストレージとしてみせることで、PCにマウントさせます。 シリアル・ダウンロード・ポートをPC に接続しておく必要があります。 // eMMC u-boot=> ums mmc 0 // SDカード u-boot=> ums mmc 1 PC にマウントされた boot パーティションに 、os_cntr_signed.bin をコピーしたあと、u-boot で Ctrl-C を押します。 もしくは、別の手段で os_cntr_signed.bin を、boot パーティションに入れておきます。 署名付きOSコンテナの起動時、下記のような表示が出ます。 CONFIG_AHAB_BOOT  を有効にした u-boot では、通常のLinux Image (署名なし)ではなく、 os_cntr_signed.bin (署名付き)が使用されます。 7.3 動作確認 この段階では、i.MX95 のライフサイクルの状態は、OEM Open のため、u-boot や Linux が起動しますが、KEY HASH の検証失敗が、ELE イベントで検出されます。 8. SRKH (Super Root Key Hash) eFuse のプログラム 8.1 eFuse 書き込み i.MX 95 SRKH eFuse に、公開鍵のハッシュ値を書き込みます。 一度書き込むと元に戻せません。 書き込んだデバイスで、署名付きブートローダや署名付きOS コンテナを更新するときは、書き込んだ SRKH のもととなる公開鍵のペアである秘密鍵を使い署名します。 別の鍵ペアを使う場合には、現在のSRKH をRevoke し、4組作成しておいた鍵ペアで未使用のものを使用します。 i.MX 95 ボードのシリアル・ダウンロード・ポートをPCに接続し、 u-boot はあらかじめ fastboot モードにしておきます。 u-boot=> fastboot 0 署名付きイメージの作成で作られたSRKH eFuse のプログラミング用スクリプト(*.bcf) を使い、 SPSDK で書き込みます。 SRKH eFuse のプログラミング用スクリプトには、 i.MX 95 eFuse の word index が記載されています。 // OEM_SRKH (venv) $ nxpele -f mimx9596 batch output/ahab_oem0_srk0_hash_nxpele.bcf // OEM_PQC_SRKH (venv) $ nxpele -f mimx9596 batch output/ahab_oem0_srk1_hash_nxpele.bcf 8.2 eFuse 値の確認 SPSDK の nxpele コマンドで、 eFuse のword index を指定しリードして、値を確認することができます。 // OEM_SRKH[31:0] word index = 128 (venv) $ nxpele -f mimx9596 read-common-fuse -i 128 // OEM_PQC_SRKH[511:480] word index = 463 (venv) nxpele -f mimx9596 read-common-fuse -i 463 など SPSDK の代わりに、U-boot コマンド もしくは System Manager モニタのコマンドで、eFuse にリード・ライトアクセスすることもできます。 U-boot u-boot=> fuse read u-boot=> fuse prog System-Manager >$ fuse.r >$ fuse.w 8.3 動作確認 この段階では、i.MX 95 のライフサイクルの状態は、OEM Openですが、SRKH プログラム済みのため、改ざんがなければ、ELEイベントは検出されません。 改ざんがあっても、その部分が動作に影響しなければ、OEM Openのため起動しますが、認証の失敗が ELE イベントで検出されます。 9. ライフサイクルを OEM Closed に更新 i.MX 95 出荷直後のライフサイクルは、OEM Open です。 デバッグ終了後に、i.MX 95 のライフサイクルを OEM Closed に変更します。 OEM Closed にしたあとの留意点 OEM Openには戻せません。 CONFIG_AHAB_BOOT=y とした u-boot を含んだブートローダで起動すると、署名の無いイメージや、不正な署名付きイメージは起動できなくなります。 CONFIG_AHAB_BOOT=y としていない u-boot を含んだブートローダでは、署名なし Linux Image で起動できてしまいますので、必ず署名付きOS コンテナ os_cntr_signed.bin で起動させるため、 CONFIG_AHAB_BOOT=y とした u-boot を含んだブートローダを使用します。 動作確認後、署名なしのLinux Image やデバイスツリーは、boot パーティションから削除します。 9.1 SPSDK i.MX 95 ボードのシリアル・ダウンロード・ポートはPCと接続し、u-boot は、あらかじめfastboot モードにしておきます。 u-boot=> fastboot 0 SPSDK でライフサイクルを更新します。 (venv) $ nxpele -f mimx9596 forward-lifecycle-update -l OEM_CLOSED Forward Lifecycle update ends successfully. (venv) $ 9.2 U-boot u-boot=> ahab_close OEM Closed とした後、 uuu で BSP イメージ (wic ファイル) を書き込む場合にも、署名付きブートローダを使用する必要があります。 10. ELE イベントの確認 ELE (Edgelock Secure Enclave) は、i.MX 95 の内蔵ブロックで、セキュアブート時のコンテナ・イメージの認証を行います。 SPSDK および U-boot、System Manager コマンドで、ELE の状態を確認することができます。 10.1 SPSDK シリアル・ダウンロード・ポートとPCを接続し、U-boot でfastboot モードにしてから行います。 u-boot=> fastboot 0 SPSDK でELE イベントを取得します。 (venv) $ nxpele -f mimx9596 get-events 10.2 U-boot CONFIG_AHAB_BOOT=y  としたU-boot で使用できるコマンドです。 デバイスのライフサイクルにより、OEM Open または OEM closed も表示されます。 u-boot=> ahab_status 10.3 System Manager >$ ele events 10.4 表示例 ELE イベント(SRKH 値の不一致)が検出されたとき SPSDK U-boot (OEM open時) System Manager ELE イベント検出がないとき SPSDK U-boot (OEM close後) System Manager   11. ブートローダの直接署名 既存の署名なしブートローダのバイナリに、 SPSDK で直接署名を追加することも可能です。 この場合、SPSDK がブートローダ・バイナリのコンテナから構成を解釈します。 YAML ファイルで、各イメージごとの細かい設定は指定できませんが、コンテナヘッダの設定と秘密鍵および公開鍵のパスを指定するのみで、署名付きブートローダを作成することができます。 11.1 テンプレートの作成 (venv) $ nxpimage ahab get-template -f mimx9596 -o ahab_sign.yaml --sign (venv) $ cp ahab_sign.yaml sign.yaml 11.2 YAML ファイル sign.yaml に、コンテナヘッダの設定と秘密鍵および公開鍵のパスを指定します。 YAMLファイルの例 を使用する場合、 direct_signing/sign.yaml をコピーしておきます。 11.3 署名の追加 既存のブートローダのバイナリ flash.bin に署名処理を行います。 // eMMC / SD (venv) $ nxpimage ahab sign -c sign.yaml -b flash.bin -o output/flash_directsign.bin -fs output // FlexSPI NOR (venv) $ nxpimage ahab sign -c sign.yaml -b flash.bin -o output/flash_directsign.bin -fs output -m flexspi_nor output/flash_directsign.bin と、SRKH eFuse のプログラミング用スクリプト output/*.bcf が作成されます。 おわりに SoC 起動イメージの保護を実現するため、i.MX 95 セキュアブートに使用する署名付きイメージを、SPSDK を使って作成し、起動するまでの流れを紹介しました。今回はi.MX 95 AHAB で新たに追加されたPQCを利用する手順例で示しました。 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 (既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。) i.MX95 でのセキュアブートに使用する署名付きのコンテナ・イメージを Secure Provisioning SDK (SPSDK) で作成し、起動する手順をハンズオン形式で学べる内容となっています。 楕円曲線デジタル署名暗号 (ECDSA)と、耐量子暗号 (PQC) ML-DSA 両方の署名認証を行うHybrid boot での実現例を紹介します。 (作業時間:半日 *一度i.MX 95向けの Linux BSP のビルドが完了している前提) i.MX Processors Security 日本語ブログ
View full article
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
View full article
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.
View full article
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
View full article
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
View full article
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
View full article
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.
View full article
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ブロックによって内部的に処理されます。 よろしくお願いします。
View full article
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,托马斯
View full article
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。
View full article
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 的分辨率。
View full article
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
View full article
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の初期化を完了させる必要がある。
View full article
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.
View full article
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?
View full article
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.
View full article
ニューヨーク州ニューヨーク市の離婚弁護士 ニューヨークの離婚弁護士は家族法を専門とし、離婚、別居、または関連問題の解決を求める方々に専門的な代理を提供します。彼らの専門分野は、離婚、別居合意、子どもの親権、面会、養育費、配偶者扶養、財産分割、婚前および婚後契約、父性紛争、既存契約の修正などです。優れた離婚弁護士は、ニューヨークの家族法の経験、優れた交渉および訴訟スキル、共感力、細部への注意力、そして地元の裁判所や手続きの知識を持っているべきです。離婚弁護士を雇うメリットとしては、権利と利益の保護、複雑な手続きにおける専門家の指導、個別の対応、有利な結果が得られる可能性の向上、ストレスや精神的負担の軽減などが挙げられます。資格のあるニューヨーク州離婚弁護士 を見つけるためのリソース:州弁護士協会、アメリカ婚姻弁護士協会、そして全米州裁判所センター。 Re: new york ny divorce lawyer 深刻な犬の攻撃は、被害者に身体的な怪我や医療費、将来への不確実性をもたらす可能性があります。テキサス州で犬に噛まれたことによる傷害賠償請求を行うことで、治療費、逸失利益、精神的苦痛、その他事故に関連する損害に対する補償を得られる可能性があります。テキサス州の経験豊富な犬咬傷弁護士は、襲撃の状況を確認し、裏付けとなる証拠を集め、被害者を法的手続きに導きます。事件が公共の場所で発生したか私有地で発生したかにかかわらず、自分の権利を理解することは、自分の利益を守るための重要な一歩です。地元の代理を求める方には、アーリントンの犬咬傷弁護士がCASEの詳細に合わせた法的支援を提供できます。テキサス州の信頼できる人身傷害弁護士は、被害者がテキサス州法に基づいて受け取る権利のある賠償金を得られるよう支援します。
View full article
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? 你烧断过熔丝吗? 您提到需要将启动配置恢复到内部闪存模式——您目前使用的是哪种启动配置? 此致, 巴勃罗
View full article