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

i.MX6ULL 中断频繁触发（21f4000.serial） 大家好，系统运行时发现卡顿，通过排查发现有一个中断计数异常，这个外设是rs485。在前一天晚上是3亿多次， 67: 334823120 GPC 30 Level 21f4000.serial 第二天变得更多。 我们只有一个进程在使用这个串口收发数据，正常的业务不会这么频繁的发送数据 异常的波形如下 正常波形 当拔掉rs485与外设的通信线后，中断计数增加变为正常，后续重新进行我们设备的业务，中断计数每秒增加几万次。最终是通过重启使用uart的进程恢复的。我们有三台同时运行的设备，只有这一台会这样，并且是突然出现的。正常运行的数据如下图所示 我们想知道为什么会出现这种情况，谢谢！ i.MX6UL Re: i.MX6ULL 中断频繁触发（21f4000.serial） 你好@JosephAtNXP、 非常感谢你们在这个问题上的支持。我想提供一个更新：在我们重新启动使用 UART4 的进程后，设备就恢复了正常运行。从那以后，我们一直在监测，问题没有再出现。 就上下文而言，这条 RS485 总线上有两个从属设备。当时，我们检查了来自从属设备的日志，但没有发现任何明显的异常。实际上，我们已经调整了进程的日志级别，以捕获异常状态下的原始数据包，但是在作为该过程的一部分重新启动 UART4 进程后，问题得到了解决，不幸的是我们无法捕获有问题的数据包。 此致 Re: i.MX6ULL 中断频繁触发（21f4000.serial） 你好@xisuisan222、 这种孤立的行为似乎是物理问题，线路必须有一个代理，如电缆，另一端，硬件故障。 将所有元件通电后，您发现有什么不同吗？ 此致

什么是实时时钟（RTC）芯片？（日文博客） 什么是实时时钟（RTC）芯片？ 在本文中，我们将解释 RTC 的作用以及哪些类型的系统需要外部 RTC ，重点介绍 NXP 的RTC 模块产品，该产品具有最低的电流消耗和最高的计时精度。 使用外部 RTC 有以下优点：1）由于功耗较低，电池寿命更长；2）时间管理更精确；3）系统可靠性更高；4）通过附加功能提高安全性。 在文章的最后，我们还将介绍一个评估环境 （电路板+软件）， 让您可以立即试用RTC 。 カレンダーと時計日历和时钟 图 1：RTC = 时钟和日历集成到系统中 时钟 + 日历 许多家用电器和小工具都具备显示时钟的功能。这些设备内置的时钟不仅用于显示当前日期和时间，还用于多种用途，例如作为定时器自动开关机，以及记录日志以进行调试和系统管理。 这种时钟功能是通过称为实时时钟( RTC ) 的电路实现的，该电路可以内置于微控制器或处理器中，也可以通过外部 RTC 芯片实现。 RTC 使用其自身晶体振荡器产生的时钟来计时。通过计数器对该时钟进行计数，即可得出当前时间和日期[图 2]。 图2：实时时钟 (RTC) 内部结构。晶体、振荡器、计数器和接口 实时时钟（RTC）内置于微控制器和处理器中。 许多微控制器和处理器在其芯片中内置了 RTC 电路[图 3]。 只要这些微控制器或处理器获得电源，即使芯片处于睡眠或断电等非活动状态，RTC 也会继续更新指示当前时间和日期的值（计数器值） 。 这些功能使系统能够在设定的日期和时间准确启动，或者准确记录 RTC 电路断电期间发生的事件的时间。 图 3：内置于微控制器中的 RTC（例如： MCXN94x/MCXN54x ） 保持 RTC 运行：功耗 例如，要实现定时开关电源的功能，设备必须能够在设定的时间操作电源开关。因此，设备内部必须持续记录时间信息，并且必须有机制确保实时时钟（RTC）不会断电。 为了使实时时钟 (RTC)在主电源关闭时也能运行，必须始终由电池供电。如果设备没有电池，则应为 RTC 提供备用电源，例如纽扣电池或超级电容器[图 4]。 由于实时时钟 (RTC) 会不断消耗电池电量，因此降低电流消耗非常重要。 图 4：RTC 评估板示例。PCF2131/PCA2131 Arduino ® Shield 评估板包含一个内置纽扣电池作为备用电源。 时间重新同步：时间精度 启动实时时钟 (RTC) 时，必须设置当前时间。此初始设置可确保 RTC 保持正确的当前日期和时间。如果不进行初始设置，RTC 将继续更新自其重置时的默认日期和时间以来经过的时间。 当前日期和时间可以由用户手动设置（通过按按钮等），也可以通过网络与 NTP 服务器自动同步，或者与 GPS同步。 初始设置完成后，即使主电源关闭，只要实时时钟 (RTC) 继续通电，它就会使用自身的时钟持续更新时间。该时钟的精度决定了时间的精度。时钟精度受多种因素影响，主要因素包括晶体振荡器的精度、振荡器电路的匹配度以及温度。 如果设备频繁开机且每次都能重新同步时间，则可能不需要高精度。但是，如果设备长时间关机，或者系统无法访问 GPS 或时间服务器，则需要一个精度满足系统要求的实时时钟 (RTC) 。 使用外部实时时钟的优势 如果您正在构建的系统使用微控制器或处理器内置的 RTC 就能正常工作，则无需使用外部 RTC芯片。 但是，如果您需要最大限度地延长电池寿命或保持准确的时间，则需要外部 RTC [图 5]。 图 5：使用外部实时时钟的系统。除实时时钟外，其他所有设备的电源均可关闭，以降低功耗。   使用外部实时时钟有四个主要优点。让我们一起来看看。 优势一：延长电池寿命（降低整个系统的功耗） 优势二：精准的时间管理 优势三：可靠性提高 优势 4：附加功能 优势一：延长电池寿命（降低整个系统的功耗） 对于内置于微控制器/处理器中的实时时钟 微控制器和处理器的设计和优化都针对其主要功能：控制和计算能力。这种优化也包括功耗优化，从而提高处理效率。 这些芯片还具有“睡眠”和“关机”模式，旨在通过仅在不需要处理时保持必要的功能来降低电流消耗。 例如，恩智浦半导体最新的MCX系列微控制器具有“深度掉电”功能，此时仅保持内置实时时钟（RTC）运行。此时的电流消耗因芯片型号而异。易于使用的通用微控制器MCX-A系列功耗仅为几百纳安，而处理能力更强的MCX-N系列则功耗为微安级。这些例子中的电流值可以说“相当低”，但如果需要更低的功耗，则需要使用外部RTC。 使用外部实时时钟 另一方面，RTC 芯片的电流消耗因产品而异，例如，电流消耗最低的PCF2131的电流消耗为65nA 。 图 6 显示了上述微控制器/处理器在当前功耗和掉电模式下的对比。这种差异有助于延长电池寿命。 即使不需要更长的使用寿命，较小的电池也能节省空间，使设备更小，并降低成本。 图 6：维持 RTC 运行所需的流动比率（与我公司相比） 优势二：精准的时间管理 实时时钟 (RTC) 的计时基于 32.768kHz 的振荡器。振荡器频率的偏差会导致精度下降。造成精度下降的主要因素是晶体振荡器和振荡器电路的变化，以及温度的变化。 对于内置于微控制器/处理器中的实时时钟 微控制器/处理器内置的实时时钟 (RTC) 所使用的振荡频率精度通常约为 ±100 ppm。这 ±100 ppm 表示 32.768 kHz 频率的偏差量，直接对应于“时钟提前/延迟”。顺便一提，如果将这 ±100 ppm 转换为月差，则为： ±100 * 10 -6 [精度] * 60 [秒] * 60 [分钟] * 24 [小时] * 31 [天] = ±259.2 [秒] 这意味着一个月内可能会有最多四分钟的增减。 除非系统经常开启并且每次都能重新同步时间，否则可能会出现如此大的差异。 使用外部实时时钟 根据所需的精度，外部实时时钟 (RTC) 可从多种型号中选择，包括内置晶体振荡器的模块化型号和内置温度补偿电路的型号。恩智浦 (NXP) 最精确的 RTC 是PCF2131 ，它是一款内置晶体振荡器和内置温度补偿电路的模块化型号，在 -40°C 至 +85°C 的整个工作温度范围内，可保证 ±3 ppm （典型值） （月误差 ±7.8 秒）的精度 [图 7] [图 8]。 对于仅使用实时时钟芯片的产品，精度取决于所使用的外部晶体振荡器。恩智浦的实时时钟产品允许您通过软件微调时钟频率。 图 7：RTC 模块内部结构：PCF2131、PCA2131   图 8：PCF2131 RTC 模块的温度补偿。单晶单元的振荡频率特性随温度呈抛物线变化。   优势三：可靠性提高 如果外部实时时钟具有与系统电源分开的备用电源（例如纽扣电池），则可以保护时间信息免受系统复位和断电的影响，从而提高系统可靠性。 优势 4：附加功能 一些外部实时时钟 (RTC) 具有附加功能。例如，PCF2131 和 PCF85263A 等型号具有时间戳功能，可在 RTC 使用备用电源运行时记录事件。这使得 RTC 能够在主电源关闭时记录诸如设备外壳的打开和关闭等事件，从而方便现场维修和增强安全功能。 时钟输出也是一项可选功能。某些产品可以输出分频至 32.768 kHz 的时钟信号。许多具备此功能的产品允许用户将频率（分频比）设置在 32.768 kHz 到 1 Hz 之间。 中断也是一项可选功能。您可以选择每秒或每分钟生成周期性中断、设置警报，甚至为事件添加时间戳。利用这些功能，您可以创建根据需要唤醒系统的函数。 外部RTC类型 恩智浦提供种类丰富的外部实时时钟 (RTC)。您可以在恩智浦产品选择器页面找到理想的 RTC。该页面详细介绍了各种选项，包括模块或分立芯片、接口类型以及适用于汽车应用的功能。 晶体振荡器内置模块型（高精度、低功耗） 在 RTC 产品中，精度最高、功耗最低的产品是PC F 2131 （一款内置石英振荡器的模块产品）和PC A 2131 （一款具有相同功能的汽车级产品）。 两款产品的工作温度范围均为-40°C至+85°C，精度为±3ppm （典型值） ；而车规级版本具有更宽的温度范围，在85°C至105°C范围内保证精度为±8ppm （典型值） 。非车规级PCF2131在3.3V电源下功耗为65nA （典型值） ，而车规级PCA2131功耗为106nA （典型值） 。 在带有外部晶体振荡器的产品中，有PCF85063TP ，它只有最基本的功能，但也有一些产品具有各种附加功能[图 9]。 图 9：PCF85063TP 内部寄存器：由于其功能仅限于最基本功能，因此寄存器大小仅为 11 字节。其中，4 字节用于控制和状态监控，其余 7 字节提供日期、星期、小时、分钟和秒等信息。 连接方式（I²C、SPI） 微控制器和处理器之间的连接可通过I²C或SPI串行总线实现。部分产品允许用户在 I²C 和 SPI 之间切换，而其他产品则根据型号固定在其中一种模式。 无论哪种情况，微控制器/处理器都通过寄存器读取控制信息和日期/时间信息。除了串行总线之外，一些设备还具有中断信号输出，根据产品的不同，可以使用一个或两个中断输出。 汽车级兼容（符合AEC-Q100标准） 恩智浦半导体提供消费级实时时钟 (RTC) 以及通过AEC-Q100认证的车规级版本。您可以在我们的产品选择页面找到这些版本。 图 10： RTC 产品选择器页面 我们来试试吧！ 图 11：支持 RTC 的 Arduino ®扩展板评估板：PCF2131-ARD、PCF85063TP-ARD、PCF85063AT-ARD 和 PCF85263ATL-ARD   恩智浦提供多种评估板，包括实时时钟（RTC）评估板，方便您立即试用每款产品。对于实时时钟，我们提供一款Arduino ®扩展板，可与各种恩智浦微控制器评估板配合使用进行评估。 此外，我们还分发了与 Arduino ® UNO 系列及其他设备兼容的开源 Arduino ®示例程序/类驱动程序。同时，我们也提供与各种微控制器兼容的 MicroPython 代码。 有关 RTC 兼容的 Arduino ®扩展板评估板的详细信息， 请参阅 本文底部附件中的 Arduino Shield Introduction Document-20250227.pdf 。 图 12：“ Arduino Shield Introduction Material-20250227.pdf ” 第 4 页 参考资料 NXP实时时钟产品门户 Arduino ® Shield 解决方案 NXP系统管理I2C、I3C、SPI选型指南 NXP社区博客：I²C总线概述 NXP社区博客：SPI总线概述 更新日志： 2025年3月3日：第一版 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便，我们深表歉意。如有任何疑问，请参阅“ NXP技术问题-如何联系我们（日语博客） ”。 （如果您已经是恩智浦的分销商或与恩智浦有合作关系，您可以直接询问负责人。） 不仅市面上有很多实时时钟 (RTC) 芯片可供选择，而且微控制器和处理器也内置了该功能。 在本文中，我们将解释从“什么是RTC？”到“使用外部RTC芯片而不是内部RTC有什么好处？”以及“应该如何选择它们？”等所有内容。 界面 介绍 日本博客

电池管理系统的重要指标：SOC、SOH、SOP（日本博客） 重要的电池指标 在当今日益电气化的社会中，锂离子电池在电动汽车和储能系统中扮演着核心角色。然而，电池性能并非始终如一，而是会受到多种因素的影响，例如环境条件、老化程度和制造差异。因此，需要电池管理系统（ BMS ）来持续监控和控制电池状态。 电池管理系统（BMS）是电池的核心部件，它负责最大限度地提高电池的安全性、性能和使用寿命，并基于多个指标进行决策和控制。本文将解释BMS处理的三个关键指标：荷电状态（SOC） 、健康状态（SOH）和运行状态（SOP） ，以及它们的定义、概念和各自的作用。 有关 BMS 的基本信息，请参阅我们之前的文章（什么是电池管理系统 (BMS)？ ）。 SOC：目前电量如何？ SOC（充电状态）是衡量电池当前充电量的指标。SOC 的计算公式如下， %が満充電、0%表示电池完全放电的状态。 SOC = 剩余 电量 / 满电电量 × 100 这里，Q 剩余 电量是当前的电量，Q 满电电量 是充满电时的电量。 在表示排放深度（即排放程度）时，有时会使用DOD（排放深度）作为指标，它是通过从 100% 中减去 SOC 来计算的。 SOC（荷电状态）对于控制电池以防止过充和过放至关重要，同时也有助于优化能量效率。如果SOC精度较低，则存在因过充和过放而导致电池性能下降的风险，因此需要精心设计，并为判断阈值留出较大的裕量。 由于这与续航里程和充电容量直接相关，因此可以说 SOC 是用户体验方面一个非常重要的指标。 SOH：电池状况有多糟糕？ SOH（健康状态）是一个指示电池劣化程度的指标。在计算新电池时，用 100 减去 SOH 得到的值%とし、使用や経年によって徐々に低下します。100%有时被称为SOD（劣化状态） 。 SOH 的计算方法如下，它是电池购买时完全充电容量与新电池完全充电容量的百分比。 SOH = Q 满电荷 / Q 初始满电荷 × 100 这里，Q full charge指的是当前充满电时的容量（也称有效容量），Q initial full charge 指的是新电池充满电时的容量（也称额定容量）。Q full charge 与 SOC 计算中使用的 Qfull charge 相同。 电池健康状态 (SOH) 用于预测电池寿命、确定更换时间，并作为保修范围的依据。随着 SOH 的降低，输出功率和容量也会下降，因此从保持性能的角度来看，SOH 是一个重要的指标。 尤其是在汽车应用中，定期监测至关重要，因为电池健康状态 (SOH) 的下降会直接影响续航里程和加速性能。此外，在电动汽车电池的再利用中，SOH 也是判断电池是否可以再次使用以及用于何种用途的重要指标。 标准操作程序：最大瞬时功率输出是多少？ SOP（功率状态）是指电池在任何给定时刻可以安全输入和输出的功率大小。它有时也表示为SOF（功能状态） 。 在电动汽车中，SOP（峰值功率）代表加速性能和应对突发负载变化的能力，也是快速充电时最大功率的指标。SOP值越高，充电速度越快，加速性能越强，从而带来更强劲的驾驶体验。 额定工作功率 (SOP) 受温度和电池老化等因素影响。例如，当温度过高或过低时，出于安全考虑，必须降低充放电功率，这意味着 SOP 会降低。此外，如果电池老化且内阻增大，即使输入电压相同，电流也会减小，而内阻增大又会导致发热，从而产生协同效应，进一步降低 SOP。 无论哪种情况，如果对标准操作程序 (SOP) 没有准确理解，您将被迫按照标准操作程序 (SOP) 预留余量进行设计，这将导致性能下降。 因此，准确理解标准操作规程对于确保电池安全并最大限度地发挥其性能至关重要。 关联指标及楼宇管理系统的作用 与电池管理系统（BMS）相关的三个指标的解释可以概括如下： SOC：电池当前可用容量的指标。 SOH：表示电池劣化程度的指标，以当前电池容量与新电池容量的比值表示。 SOP：表示当前电池能够安全提供的最大输入/输出功率的指标。 这些指标并非单独使用，而是共同构成电池管理系统 (BMS) 的基础。即使每个指标都表现良好，仍可能出现以下问题： 即使 SOC 很高，如果 SOH 很低，充满电后的容量也很小，电池不能长时间使用。 即使 SOC 和 SOH 很高，如果 SOP 很低，丰富的电池容量也无法有效利用。 即使 SOP 很高，如果 SOC 很低，电池也会很快耗尽。 BMS 实时监控和控制这些指标，其中 CMU（电池监控单元）获取电池电压和温度，BMU（电池管理单元）对整体状况进行综合评估，BJB（电池接线盒）在执行安全控制的同时监控电流和总电压。 恩智浦的电池管理系统解决方案可同时提升性能和安全性。 NXP 的BMA7118和MC33777产品对提高 BMS 中关键指标的准确性和确保安全性做出了重大贡献。 BMA7118是一款 CMU IC，可对多达 18 节锂离子电池进行高精度监测。其 ±0.8mV 的电压测量精度和出色的温度补偿功能提高了 SOC 和 SOH 估算的准确性。此外，其电池均衡功能和低功耗设计可提高电池利用率。 MC33777是一款用于 BJB 的监控 IC，能够高速监控电流、电压和温度，从而实时获取确定 SOP 所需的必要信息。通过集成关键功能，MC33777 有望减少高达 80% 的元件数量。此外，其无需 MCU 干预即可运行的事件检测功能，能够对异常情况做出即时响应，从而确保高安全性。 有关 MC33777 的更多信息，请参阅我们的新闻简报。 MC33777MC33777 以上两款产品均能提供文档和生产级软件驱动程序，以支持功能安全。结合使用这两款产品，可实现从电芯到电池组的集成式电池管理，从而为下一代电动汽车和储能系统提供最佳的电池管理系统 (BMS) 配置。 如果您想提高 SOC、SOH 和 SOP 的准确性和可靠性，NXP 的 BMS 解决方案是最佳选择。 =========================== 更改历史记录 2025/09/11：博客文章 ========================= 我们目前无法回复此帖子“评论”部分的评论。 对于由此造成的不便，我们深表歉意。如有任何疑问，请参阅“ NXP技术问题-如何联系我们（日语博客） ”。 （如果您已经是恩智浦的分销商或与恩智浦有合作关系，您可以直接询问负责人。） 下面解释了电池管理系统（BMS）的三个重要指标。 重要的电池指标 SOC：目前电量如何？ SOH：电池状况有多糟糕？ 标准操作程序：最大瞬时功率输出是多少？ 关联指标及楼宇管理系统的作用 恩智浦的电池管理系统解决方案可同时提升性能和安全性。 我们希望您了解需要管理的指标以及楼宇管理系统的重要性。 （阅读时间：10分钟） 日本博客

移植CMSIS-DSP库到CodeWarrior的步骤以及Kinetis FPU单元应用的对比 在电机控制，Audio等很多应用中，我们经常会用到一些常见的正余弦，矩阵变换，FFT等一些DSP函数，提到DSP库，通常会想到使用ARM 公司提供的 CMSIS 库。CMSIS 库是ARM和一些半导体厂家针对Cortex-M系列制定的一套接口标准，包括针对内核操作的CMSIS-CORE API，针对DSP应用的CMSIS-DSP Library，针对RTOS的CMSIS-RTOS API，与外设接口的CMSIS-SVD以及提供Debug访问接口的CMSIS-DAP。 其中，又以DSP应用的CMSIS-DSP 库的应用最为广泛。针对Cortex-M4中的DSP功能，CMSIS-DSP部分提供了超过60多种功能的DSP算法库，尤其是随着Cortex-M4中集成了FPU硬件单元，CMSIS-DSP 库的应用也越来越广泛。 在KEIL 和IAR中都集成了对CMSIS的支持，然而在CodeWarrior中没有直接支持CMSIS，需要用户移植到自己的CW工程中，所以就需要使用者了解CMSIS的结构，手动添加库文件和头文件，并完成一些重要的编译参数配置。特别是有些芯片支持FPU浮点运算单元，有些不支持，在配置选项上差别很大。在飞思卡尔Kinetis系列芯片中，FPU浮点运算单元也是一个可选的部件，只有在名称中带有FN和FX的芯片才支持FPU硬件浮点功能，如MK60FN1M0, MK60FX512。本文档分别介绍在使用和不使用FPU的情况下如何一步步移植CMSIS的DSP库到自己的CodeWarrior工程中。 需要注意的是 FPU 单元是指的芯片上的一个独立于 CPU 处理的浮点运算单元，整个单元在大多数厂家的芯片中都是可以被使能和关闭的。相对于芯片，编译器也设置了相应的 FPU 功能开启/关闭的选项，在编译时需要告诉编译器是否开启 FPU 功能。编译器一旦开启 FPU 功能，在处理单精度浮点运算的语句时就会用带 V-开头的汇编指令进行编译。如果编译器使能了 FPU 功能，而芯片未开启 FPU 单元，程序运行到浮点语句时就会出现异常。相反，如果编译器未使能 FPU 功能，芯片即使开启了 FPU单元，程序还是会按照未使能 FPU 的代码进行处理。在本例程中，为对比分析是否采用FPU的编译指令差别以及在板的执行效率，选用Kinetis K70FN1M为实验对象。 硬件平台：TWR-K70F120M核心板      软件环境：CodeWarrior v10.5        CMSIS版本 ：V3.2 一. 准备工作： 下载CMSIS的库，当前最新的版本为V3.2，解压后名称为CMSIS-SP-00300-r3p2-00rel1，其目录结构如下图。分别包含CMSIS-DSP, CMSIS-RTOS和CMSIS-SVD的库文件。在本Cortex M4的CMSIS-DSP的应用中，真正用到的文件包括CMSIS\Include中CM4相关的头文件，CMSIS\Lib\GCC文件夹中的库文件libarm_cortexM4l_math.a(软浮点)和libarm_cortexM4lf_math.a(硬浮点)，以及Device\ARM\ARMCM4\include中外设访问相关的两个头文件。 二. 不使用K70的FPU浮点运算单元，移植CMSIS的DSP库到CW的步骤；      Step 1:    新建一个Baremental的工程，选择器件器件MK70FN1M0（支持硬件FPU）；     Step 2:    选择Floating Point浮点运算实现的类型，即指定编译器将C代码编译成汇编代码时使用的规则； 在Floating Point四个选项含义如下： Software选项：表示不使用FPU硬件，而是使用GCC的整数算术运算来模拟浮点运算； Handware(-mfloat –abi=hard) 选项：表示使用FPU硬件来进行浮点运算，函数的参数直接传递到FPU的寄存器(s0-d0)中； Handware(-mfloat –abi=softfp)选项：表示使用FPU硬件来进行浮点运算，但是函数的参数传递到整数寄存器(r0-r3）中，然后再传递到FPU中； Handware(-mfloat –abi=softfp –fshort -double)选项：其配置项同上，只不过使能了fshort  double功能，并且此处的double数据的宽度等同于float； 有兴趣研究各个选项意义的可以参考CW for MCU技术文档的第3章，在本例程中使用的是软浮点，所以选择Software项。需要注意的是：此配置选项仅出现支持FPU硬件单元的芯片工程中，如MK60FN1M0, MK60FX512等，否则默认没有此选项，默认为软件浮点。 Step 3:    点击“Next”进入下图，选择使用Processor Expert，点击“Finish“完成工程的建立； Step 4:    进入当前工程的文件夹，新建文件夹CMSIS，从之前在准备步骤解压的CMSIS文件包\...\CMSIS-SP-00300-r3p2-00rel1\CMSIS中拷贝Include和Lib文件夹到当前工程新建的CMSIS文件夹。另外，拷贝\...\CMSIS-SP-00300-r3p2-00rel1\Device\ARM\ARMCM4\Include中的ARMCM4.h和system_ARMCM4.h到当前工程新建的CMSIS文件夹中； Step 5:    回到CodeWarrior主界面选择新建的工程文件，F5刷新可以看到CMSIS出现在工程文件中。其中Include是CMSIS库的一些头文件，包括M0+/M3/M4的一些头文件；在Lib文件中是已经编译好的库文件，ARM文件夹是使用在KEIL IDE中的库文件，G++文件夹是使用在IAR中的库文件，而由于当前CW工程使用的GCC的编译器，所以GCC文件夹才是CW需要的，因此，为缩减工程大小可以删除ARM和G++文件夹；     Step 6:    打开工程属性框，选择Target Processor的Float ABI为No FPU； Step 7:    在GCC Complier的Defined symbols中添加编译的宏定义ARM_MATH_CM4； Step 8:    在GCC Complier的Include paths中添加CMSIS库的头文件，路径为：工程目录\CMSIS\Include； Step 9:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中不使用FPU，所以选择libarm_cortexM4l_math.a，此处需要特别注意，否则编译会报错； Step 10: 在ProcessorExpert.c文件中添加代码； #include #include "arm_math.h" #define DELTA    (0.000001f) const float32_t testRefOutput_f32 = 1.000000000; const float32_t radians=1.047197533333333; float32_t  cosOutput, sinOutput, diff; float32_t cosSquareOutput,sinSquareOutput,testOutput; int main(void) {   int m,n;   PE_low_level_init();   cosOutput = arm_cos_f32(radians); /*求正余弦*/                   sinOutput = arm_sin_f32(radians);                                 arm_mult_f32(&cosOutput, &cosOutput, &cosSquareOutput, 1); /*求积运算*/   arm_mult_f32(&sinOutput, &sinOutput, &sinSquareOutput, 1);               arm_add_f32(&cosSquareOutput, &sinSquareOutput, &testOutput, 1); /*求和运算*/   diff = fabsf(testRefOutput_f32 - testOutput);  /* 求绝对值 */                 if(diff > DELTA)   {                         while(1)                                 {                                   for(m=0;m<2000;m++)                                                 for(n=0;n<200;n++){};                                                 D7_NegVal();                                 }     }                 } Step 11:    编译并下载Debug，在  sinOutput = arm_sin_f32(radians);处设置断点，可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常，其反汇编的得到为普通的ARM指令(FPU 单元汇编指令通常在普通指令前加字母V，仅在 FPU 功能被使能时使用)，完成一个正弦计算； 至此，完成了不使用K70的FPU浮点运算单元，移植CMSIS的DSP库到CW的步骤。     三.     使用K70的FPU浮点运算单元，移植CMSIS的DSP库到Codewarrior的步骤 使用K70的FPU硬件浮点运算单元，移植CMSIS的DSP库到Codewarrior的方法有两种：一种是按照上面软浮点的方式Step By Step的建立工程，步骤和上面二的步骤基本一致，主要的两个区别在于：(1). Step 2要选择Handware(-mfloat –abi=hard) 选项，(2). Step 9 改为libarm_cortexM4lf_math.a。另外一种就是在上面工程的基础上修改配置选项。鉴于方便，本教程采用第二种方案，完成在Codewarrior中调用CMSIS的DSP库，通过K70的FPU浮点运算单元执行浮点运算，即硬浮点。 Step 1:    打开工程属性对话框，选择Target Processor的Float ABI为FPU with hard vfp passing(-mfloat –abi=hard)； Step 2:    在GCC Complier的Defined symbols中添加编译的宏定义：_VFPV4； Step 3: 在GCC C Linker的Libraries项的library search path中指定链接的规则，把上面工程中默认的"${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m"修改为 "${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m/fpu"； Step 4:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中使用FPU，所以选择libarm_cortexM4lf_math.a，此处需要特别注意，否则编译会报错； Step 5:    完成以上配置后，编译工程并下载调试（此处建议编译之前先Clean一下整个工程），同样，在  sinOutput = arm_sin_f32(radians);处设置断点，可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常，其反汇编的得到为FPU指令(FPU指令通常是指在普通指令前加字母V，仅在 FPU功能被使能时使用)，并且在Register观察窗口中也多了个FPU寄存器列表，感兴趣的读者可以对比一下和前面实验汇编出代码的差异，此处不再赘述； 至此，分别完成了使用和不适用K70的FPU浮点运算单元情况下， CMSIS的DSP库到Codewarrior的移植。在实际应用中需要用到更多的DSP函数，在项目中直接调用即可。下一步， Just Enjoy The Convenience of  The CMSIS! 有一点需要说明的是，前文中讲到使用FPU单元需要两步设置：(1). 在编译器中开启相应的 FPU 功能选项；(2). 开启芯片FPU 单元。似乎我们前面的设置是完成了第一个步骤，然而第二个步骤呢？仔细查看_arm_atart.c文件，可以发现代码_fp_init()正是完成了开启芯片FPU单元的过程，如下图，是一个条件编译函数，这也就解释了为什么在上面Step 2中定义了_VFPV4，其本质也就是使能芯片的FPU单元，其具体实现可以查看ARM手册的第74页的描述。 #ifdef   __VFPV4__        //Step 2中的宏定义                 __fp_init();      // 开启芯片的FPU单元 #endif Kinetis K Series MCUs

S32K clock mechanism & configuration First let us see the clock tree: Core clock up to 112M, Bus clock up to 56M, Flash clock up to 28M. Clock can been from: System OSC、Slow IRC 、Fast IRC and System PLL 1. OSC SCG_SOSCCFG 2. PLL configuration formula: SPLL_CLK = (VCO_CLK)/2 VCO_CLK = SOSC_CLK/(PREDIV + 1) *(MULT + 16)  3. SCG_SPLLCSR void SystemClockInit(void) { SCG->SOSCCFG = 0x3C; SCG->SOSCCSR |= 1<<0; /* SOSCEN=1 enable SOSC clock */ /*wait clock active*/ while((SCG->SOSCCSR & SCG_SOSCCSR_SOSCVLD_MASK) == 0); SCG->SPLLCSR &= ~(0x1<<0) ; /* SPLLEN=0: disable PLL*/ SCG->SPLLCFG &= ~(0x7<<8); /* PREDIV=0: 1 */ SCG->SPLLCFG |= 0xCU<<16; /* MULT=12: 28   PLL VCO = 8/1*(12+16) = 224M */ SCG->SPLLCSR |= 0x1<<0; /* SPLLEN=1: enable PLL */ /* wait PLL active*/ while((SCG->SPLLCSR & SCG_SPLLCSR_SPLLVLD_MASK) == 0); SCG->RCCR |= SCG_RCCR_DIVCORE(0); /* DIVCORE=0: 1, CORE/SYS_CLK  112MHz */ SCG->RCCR |= SCG_RCCR_DIVBUS(1); /* DIVBUS=1: 2, BUS_CLK  56MHz */ SCG->RCCR |= SCG_RCCR_DIVSLOW(3); /* DIVSLOW=2: 4   FLASH_CLK  is 28MHz */ SCG->RCCR &= 0xFEFFFFFF; /* Initially set to SIRC so that LSB could be set as '0' */ SCG->RCCR |= SCG_RCCR_SCS(6); /* SCS=6: system clock System PLL */ }

現代のサーバーデザインにおける主要なパフォーマンスと電力要因 皆さんこんにちは 私は、今日のコンパクトなサーバー システムを扱う際に、パフォーマンスと電力効率を人々がどのように見ているかについて、一般的な議論を始めたいと思いました。ワークロードの分散化が進むにつれて、効率、安定性、長期的な運用がピークパフォーマンスと同じくらい重要になってきます。 ミニサーバーの場合、パフォーマンスと電力のバランスを取るのは非常に困難です。プロセッサの効率、メモリ容量、ストレージ速度はすべて、これらのシステムが日常のワークロードをどれだけうまく処理できるかに影響し、電力消費と発熱量は、システムをどこにどのように展開できるかに影響します。多くのセットアップでは 24 時間 365 日オンライン状態を維持する必要があるため、アイドル時の電力を低く抑え、効果的な熱マネジメントを行うことが重要な考慮事項になります。特にエッジまたは小規模な展開では、ネットワークのパフォーマンスとスケーラビリティも重要な役割を果たします。 他の人がこれらの要素をどのように評価しているか、実際の使用では何が最も効果的であったかをぜひ聞いてみたいです。

飞思卡尔常用脱机烧写工具 1. CycloneMAX,    支持 Kinetis, ColdFire V2/V3/V4, Power MPC5xx/8xx, Qorivva MPC5xxx, DSC, MAC7xxx    PE Micro, http://www.pemicro.com/ 2. Flasher ARM     支持ARM公司全系列内核，包括传统的ARM7, ARM9和ARM11，已经新的Cortex-A, Cortex-M和Cortex-R系列，可以给目标板供电.    Segger, SEGGER - The Embedded Experts - Flasher ARM 3. Flasher Portable    支持ARM公司全系列内核，包括传统的ARM7, ARM9和ARM11，已经新的Cortex-A, Cortex-M和Cortex-R系列，电池供电，便携式烧写器.    Segger, SEGGER - The Embedded Experts-Flaser Portable 4. SmartPRO    支持 Kinetis, S12, S12X, ColdFireV2.    周立功，http://www.zlgmcu.com/ 5. MCP-104    支持飞思卡尔ARM based Microcontroller Kinetis.    祥佑科技(Micetek), http://www.micetek.com 6. 西尔特编程器，http://www.xeltek.com 7. 河洛编程器，http://www.hilosystems.com.tw Kinetis Hardware Support

[RTD600 MCAL & IP] S32K3X4EVB - T172 FlexCAN 示例（中断/轮询） 这篇文章介绍了S32K3X4EVB-T172 评估板的两个互补的 FlexCAN 通信示例，展示了低级 IP 层和AUTOSAR MCAL 层的实现。这些示例是在正常/用户模式下配置元器件的基本例程，因为 RTD示例配置为环回模式。 要测试 CAN 通信，必须使用另一块开发板或 CAN 分析仪。 由于使用 S32K3X4EVB-T172 的 B2 修订版来测试该项目，因此将 TJA1043 收发器安装在板上并用于测试示例。 ------------------------------------------------------------------------------ * Test HW: S32K3X4EVB-T172 * MCU: S32K344 * Compiler: S32DS 3.6.2 * SDK release: RTD 6.0.0 * Debugger: PE Micro * Target: internal_FLASH ------------------------------------------------------------------------------ 示例 1：FlexCAN IP 层 (LLD) 该项目使用 IP 级驱动程序演示了基本的 FlexCAN 设置。它配置标准的 CAN 报文；通过轮询进行传输，使用中断进行接收。 如果使用TJA1153 收发器，则必须在项目顶部取消注释宏TJA1153 ，并通过自定义配置序列对其进行初始化。如果未使用且宏已被注释，则进行正常的收发器初始化（仅CAN0_EN_PIN & CAN0_STB_PIN设置为高电平）。 Rx 过滤器口罩类型是个人的，设置为接收 STD ID 123h。 Tx MB 设置为 STD ID 001h。 FlexCAN 比特率使用 MPC5xxx/S32Kxx/LPCxxxx 计算 ：CAN / CAN FD 位定时计算。FlexCAN 比特率设置为500kbps， 采样点为 81.25% FPE_CLK: 24MHz 同步间隔：1 提案序号： 4 第 1 阶段：8 第二阶段：3 预分频器：3 RJW: 3 示例 2：FlexCAN MCAL 层 (HLD) 该项目可配置 Can_43_FLEXCAN 和 CanIf 模块进行 CAN 通信。传输通过轮询完成，而接收则通过中断进行配置。 Tx MB 设置为 STD ID 123h。 接受掩码设置为 0x0（接受所有 ID）。 CAN 报文通过Can_43_FLEXCAN_Write() 发送，通过 CanIf_RxIndication() 回调接收。CanIf_bRxFlag设置完成后，系统会发回一条 ACK 报文。 绿色LED 每收到 10 条信息就会切换一次。 FlexCAN 比特率使用 MPC5xxx/S32Kxx/LPCxxxx 计算 ：CAN / CAN FD 位定时计算。FlexCAN 比特率设置为500kbps， 采样点为 81.25% FPE_CLK: 24MHz 同步间隔：1 提案序号： 4 第 1 阶段：8 第二阶段：3 预分频器：3 RJW: 3 如果使用TJA1153收发器，则必须使用 宏TJA1153_EVB_TRCV。否则，使用TJA1043_EVB_TRCV进行标准收发器初始化（CAN0_STB& CAN0_EN 引脚设置为高电平）。 这些示例 按原样提供 ，不提供任何保证，也不提供任何支持。这些基本例程 仅供参考。

eIQ Time Series Studio 命令行界面 eIQ Time Series Studio包含一个命令行界面 (CLI)，允许您通过命令行生成时间序列模型，就像在图形用户界面中一样。有关该功能的完整文档可在eIQ TSS 文档 中找到，还提供了包含基本按键命令的快速入门。 在 TSS 版本 1.5.5 中，有一些命令行界面问题需要注意，这些问题将在下一版 TSS 中得到解决。同时，这里有一些变通办法和说明： 库编译错误 使用库编译选项生成 TSS 库可能并非在所有情况下都有效，可能会返回"Not Found" 错误。 解决方法：将在下一版 TSS 中修复此问题。   Windows 工作区权限 在 Windows PC 上，启动 TSS CLI 服务器时指定工作区位置。由于权限问题，Windows 上的默认工作区可能无法正常工作，从而导致以下错误：[PYI-12556:ERROR]由于未处理异常，执行脚本 "server "失败！ 解决方法：使用 tss_c li 引擎启动--workspace 参数指定 TS S 具有读/写访问权限的工作空间目录位置   不要同时运行 CLI 和图形用户界面 TSS CLI 和 TSS GUI 不应同时运行。此外，如果 TSS 数据库位于共享服务器上，则一次只能有一个用户与 TSS CLI 交互，以避免 TSS 数据库出现竞赛情况。   引擎启动语法更正 TSS CLI 文档使用 t ss_cli 引擎启动 —engine ，但 正确的语法是： tss_cli engine -exe_path   Windows 命令提示符分隔符 使用 Windows 命令提示符和信号导入命令导入传感器数据时，请使用双引号 (" " ) 指定分隔符（即本例中的空格），而不是单引号 (' ')   术语澄清 "文档中的优化" 指的是训练时间序列模型的过程。   在培训过程中查找优化 ID 使用tss_cli optimization list --project_name cli_test_project查看优化列表，可以找到 my-opt-id 值。   查找标签名称 使用tss_cli signal list --project_name cli_test_project查看信号名称，可以找到仿真命令使用的标签名称值。   布尔参数 训练过程中的快速搜索等参数都是布尔值，在作为命令行参数的一部分加入时会自动启用。例如，使用-qs而不是-qs true。 下面是使用 eIQ Time Series Studio 命令行界面的示例： #Assumes the following items： #1) tss_cli 位于可执行路径（C:\Program Files\NXPe\IQ_TimeSeriesStudio-1.5.5） #2）数据集在 C:\tss\dataset 中 #3）将在 C:\tss\workspace 中设置一个工作区 #4) 许可证密钥已经从 TSS GUI 中获取 #5) TSS GUI 没有同时运行 #安装许可证密钥 tss_cli.exe license activate --key #Start TSS CLI t ss_cli 引擎启动-e " C:\Program Files\ NXP\ eiq_TimeseriesStudio-1.5.5\ tss_engine\ tss_engine.exe " —port 18000 —workspace " C:\tss\workspace " #Install license key tss_cli license activate --key #Create FRDM-MCXN947 tss_cli 项目的分类项目 创建--project_name cli_fan_project--algo_type cls--device FRDM-MCXN947--channels 3--label_target_num 4 # 列出工作区中的所有项目，并查看新生成的 cli_fan_project 的详细信息 tss_cli project list tss_cli project query --project_name cli_fan_project #Add training data tss_cli signal list --project_name cli_fan_project tss_cli signal import --project_name cli_fan_project --signal_name ON --file_path C:\tss\data\fan_state_monitoring_3channel\train\train_on.csv --label_id 1 --delimiter" " tss_cli signal import --project_name cli_fan_project --signal_name OFF --file_path C:\tss\data\fan_state_monitoring_3channel\train\train_off.csv --label_id 2 --delimiter" " tss_cli signal import --project_name cli_fan_project --signal_name FRICTION --file_path C:\tss\data\fan_state_monitoring_3channel\train\train_friction.csv --label_id 3 --delimiter" " tss_cli signal import --project_name cli_fan_project --signal_name CLOG --file_path C:\tss\data\fan_state_monitoring_3channel\train\train_clog.csv --label_id 4 --delimiter" " #Check training data tss_cli signal query --project_name cli_fan_project --signal_id 1 #开始训练模型。它将打印出一个 opt_ID 号，第一次运行时将是"1" 。 tss_cli optimization start --project_name cli_fan_project -qs --opt_name cli_fan_opt --signals 1 2 3 4 #Get opt_id number while training is running tss_cli optimization list --project_name cli_fan_project # 检查训练进度，获取模型排名，以选择 result_ids tss_cli optimization progress --project_name cli_fan_project --opt_id 1   #Can stop training if feel like have enough results tss_cli optimization stop --project_name cli_fan_project --opt_id 1 #Get the result_ids of the best result.在检查上述进度时，它也将是最高的 ID。本例中将使用 48 tss_cli optimization results --project_name cli_fan_project --opt_id 1 #Get Execution Time estimate for that model tss_cli library time_estimate --project_name cli_fan_project --opt_id 1 --result_id 48 #获取标签名称 tss_cli signal list --project_name cli_fan_project #Emulate 测试数据库 ts_cli 仿真启动--project_name cli_fan_project--opt_id 1--result_ids 48--test_file_info " 1 " C:\tss\data\fan_state_monitoring_3channel\test\test_on.csv " "--test_file_info " 2 " C:\tss\data\fan_state_monitoring_3channel\test\test_off.csv ""--test_file_info " 3 " C:\tss\data\fan_state_monitoring_3channel\test\test_friction.csv " "--test_file_info " 4 " C:\tss\data\fan_state_monitoring_3channel\test\test_clog.csv " " #Create a TSS library tss_cli library compile --project_name cli_fan_project --opt_id 1 --result_id 48 --save_path"C. \tss\ --arch cortex-m33 --toolchain GCC #Createa TSS library \tss\" --arch"cortex-m33" --toolchain"GCC" #创建 TSS 示例项目 tss_cli library sample_project --project_name cli_fan_project --opt_id 1 --result_id 48 --save_path"C:\tss" --arch"cortex-m33" --toolchain"GCC" NPU|ML

[Introduction] Running the i.MX 93 Cortex-M SDK Sample Code - [Part 2] Running the M Core with U-Boot and remoteproc (Japanese blog) This three-part series provides hands-on instruction on how to build and run SDK sample code for the Cortex-M33 core in the NXP i.MX 93 applications processor . In this second article, we will explain how to run a pre-built M core image on an evaluation board using U-Boot and remoteproc . [ Part 1] Building a development environment and M core image [Part 2] M-core execution using U-Boot and remoteproc (this article) [ Part 3] Automatic startup of M core using boot loader Contents of the 2nd session 3. Running the M core image 3.1 Cortex-M33 TCM Memory Mapping 3.2 Writing to the FAT partition of the SD card 3.3 Running from U-Boot 3.4 Execution from remoteproc 3. Running the M core image There are two ways to run an M33 core image from A55: "running from U-Boot" and "running from remoteproc," as shown in the figure below. Now, I'll explain each method. 3.1 Cortex-M33 TCM Memory Mapping As stated in the ARM documentation below, M33 code must be run in Privileged/Secure mode. The Cortex-M33 processor supports Secure and Non-secure security states, Thread and Handler operating modes, and can run in either Thumb or Debug operating states. In addition, the processor can limit or exclude access to some resources by executing code in privileged or unprivileged mode. Code can execute as privileged or unprivileged. Unprivileged execution limits or excludes access to some resources appropriate to the current security state. Privileged execution has access to all resources available to the security state. Handler mode is always privileged. Thread mode can be privileged or unprivileged. Check the address map of the i.MX 93 TCM (Tightly Coupled Memory) area and organize the access addresses from the Cortex-M33 and Cortex-A55. The following is an excerpt from the i.MX 93 Applications Processor Reference Manual : TCM address for M33 viewpoint: 0x1FFE0000 TCM address for A55 viewpoint: 0x201E0000 *For details, please refer to the following section in the i.MX 93 Applications Processor Reference Manual. " 2.2 System memory map used by all initiators other than the Cortex-M33 core " " 2.3 System memory map (Cortex-M33)" 3.2 Writing to the FAT partition of the SD card This article explains how to write the M core image to an SD card using the uuu tool or the Ubuntu cp command . For more information, please also refer to the article " How to build a Linux BSP and write the generated image to the target board ." Posted by uuu ① Set BOOT_MODE to "Cortex-A55 USDHC1 8-bit eMMC 5.1 [0100]" and start U-Boot. ②Start fastboot with U-Boot Uboot=> fastboot 0 [ Tip ] : "fastboot 0" is a convenient command that allows you to switch to USB Serial Loader mode without changing the DIP SW. ③ Write to the SD card from the host PC with uuu -b fat_write $ uuu -b fat_write power_mode_switch_rtos_imx93.bin mmc 1:1 power_mode_switch_rtos_imx93.bin Writing using the cp command (Ubuntu) Use an SD card reader and copy directly to the FAT partition $ cp power_mode_switch_rtos_imx93.bin /media/xxx/boot $ cp power_mode_switch_rtos_imx93_cm33.elf /media/xxx/boot   3.3 Running from U-Boot This article explains how to load the M33 image on U-Boot and run it with the bootaux command. It also includes setting environment variables before starting Linux. ① Load the M33 image with U-Boot and run it u-boot=> fatload mmc 1:1 ${loadaddr} power_mode_switch_rtos_imx93.bin 36484 bytes read in 6 ms (5.8 MiB/s) u-boot=> cp.b ${loadaddr} 0x201e0000 ${filesize} u-boot=> bootaux 0x1ffe0000 0 ## Starting auxiliary core addr = 0x1FFE0000... ② Before starting Linux, run prepare_mcore in U-Boot and add clk_ignore_unused to the U-Boot mmcargs environment variable. u-boot=>run prepare_mcore u-boot=>setenv mmcargs setenv bootargs ${jh_clk} ${mcore_clk} clk_ignore_unused console=${console} root=${mmcroot} ③ Start Linux u-boot=>boot The following will be displayed on the M33 terminal. By performing the suspend/wakeup operation on the A55, you can check the cooperation with the M33. On the A55, suspend it by running: root@imx93frdm:~# echo mem > /sys/power/state Enter the "W" command on the M33 to wake up the A55: Confirmed return of A55:   3.4 What is remoteproc? remoteproc (Remote Processor Framework) is a mechanism that allows the Linux kernel to control remote processors such as the Cortex-M33. It allows the M33 firmware to be loaded, started, and stopped from Linux, enabling flexible system design in multi-core SoCs. With i.MX 93, remoteproc allows you to dynamically control the M33 from Linux, enabling designs that separate and execute real-time processing and safety functions. Main functional configuration function explanation Loading Firmware Loads an ELF binary into the specified memory location. Processor start/stop Start/stop control Resource Management Shared memory and communication channel configuration using resource_table IPC Collaboration Message communication between Linux and M33 using rpmsg Components component explanation /lib/firmware/ M33 firmware location directory resource_table Resource information structure in firmware remoteproc driver Control driver in the Linux kernel (e.g. imx_rproc) sysfs interface Can be controlled by /sys/class/remoteproc/remoteprocX/   3.5 Execution from remoteproc Learn how to load, run, and stop M33 images using the remoteproc framework ① Run prepare_mcore in U-Boot , add clk_ignore_unused to the U-Boot mmcargs environment function, and start Linux. u-boot=>run prepare_mcore u-boot=>setenv mmcargs setenv bootargs ${jh_clk} ${mcore_clk} clk_ignore_unused console=${console} root=${mmcroot} u-boot=>boot ② After booting Linux, copy the M33 image to /lib/firmware/ root@imx93frdm:~# mount /dev/mmcblk1p1 /mnt root@imx93frdm:~# cp /mnt/power_mode_switch_rtos_imx93_cm33.elf /lib/firmware/ ③ Specify the firmware to remoteproc root@imx93frdm:~# echo /lib/firmware/power_mode_switch_rtos_imx93_cm33.elf >/sys/devices/platform/remoteproc-cm33/remoteproc/remoteproc0/firmware ④ Start the M33 image root@imx93frdm:~# echo start > /sys/devices/platform/remoteproc-cm33/remoteproc/remoteproc0/state The following will be displayed in the M33 terminal.   ⑤Stop the execution of the M33 image from remoteproc. root@imx93frdm:~# echo stop > /sys/devices/platform/remoteproc-cm33/remoteproc/remoteproc0/state In this article, we introduced the steps to run a pre-built M core image on the FRDM-i.MX93 evaluation board using U-Boot and remoteproc . In the next article, we will explain how to automatically start these binaries using the bootloader . → Next time : [ Part 3] Automatic startup of M-core using bootloader ○ This time : [Part 2] M-core execution using U-Boot and remoteproc (this article) ← Previous article: [ Part 1] Building a development environment and M core image =========================== We are currently unable to respond to comments in the " Comment " section of this post . We apologize for the inconvenience, but when making inquiries, please refer to " How to contact NXP with technical questions ( Japanese blog ) " . (If you are already an NXP distributor or have a relationship with NXP , you may contact the person in charge directly. ) This series will cover three hands-on articles that explain how to build and run SDK sample code for the Cortex-M33 core in i.MX 93 using the low-cost, compact development board, the FRDM i.MX 93 Development Board . [Part 1] Building a development environment and M core image [Part 2] M-core execution using U-Boot and remoteproc (this article) [Part 3] Automatic startup of M core using boot loader i.MX Processors Japanese blog

PN7160 PN7220 Android 15 移植到 i.MX8MN EVK 简介 我们有一份官方的PN7160/PN7220 Android 15移植指南（PN7160/PN7220 – Android 15 移植指南）。但这些补丁仅适用于Android 15 AOSP r1（android-15.0.0_r1）。如果用户想移植到较新版本的AOSP，在源代码编译过程中会出现很多错误。本文件供客户参考，以便逐一解决错误。 注意：所有修改仅供参考。它们不是恩智浦官方针对 AOSP 新版本移植提供的补丁。因此，这些修改可能并非最佳解决方案。请客户根据自身需求修改 AOSP 源代码。这不是用于生产。客户仍需在移植后进行全面测试。 硬件板： i.MX8MN EVK (i.MX 8M Nano评估套件 | NXP 半导体) PN7160 EVK （OM27160 | PN7160 即插即用 NFC 控制器开发套件 | NXP 半导体） i.MX8MN EVK 与 PN7160 OM29110ARD-B 之间的连接 i.MX8M Nano EVK 引脚 PN7160 引脚 3.3v J1003-1 VDD（3.3v） J1-4 5V J1003-2 VBAT（5V） J1-5  I2C3 SDA J1003-3 SDA J2-2 I2C3 SCL J1003-5 SCL J2-1 GPIO3_22 J1003-37 IRQ J2-10 GPIO3_21 J1003-38 请求 J4-2 GND J1003-39 GND J1-6 GPIO3_20 J1003-40 VEN J4-1 为 i.MX8MN EVK 构建 Android 我使用的 i.MX Android BSP 是 Android 15.0.0_2.0.0 (L6.12.20_2.0.0 BSP)，可从此处下载：用于 i.MX 应用处理器的 Android 操作系统 | NXP 半导体 1. 下载"文档"和"安装源代码包"。 2. 首先按照 Android 用户指南的步骤为 i.MX8MN EVK 构建 Android BSP。 根据 android_build/.repo/manifests/aosp-android-15.0.0_2.0.0.xml，您将看到 AOSP 版本是 android-15.0.0_r32。 移植参考文件： PN7160/PN7220 – Android 15 移植指南 在 i.MX8M Nano 开发板上将 PN7160 移植至 Android 14 现在，我们开始移植： 1. 内核驱动程序 为了与 PN7220 或 PN7160 建立连接，Android 协议栈使用 nxpnfc 内核驱动。您可以从下面的 GitHub 链接下载驱动程序： nfcandroid_platform_drivers/drivers at br_ar_16_comm_infra_dev ·NXP-NFC-Infra/nfcandroid_platform_d... 命令是： git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_drivers.git" -b br_ar_16_comm_infra_dev 驱动程序适用于 Kernel 6.6 和 6.12。因此，请下载适合您移植的正确版本。例如，i.MX Android BSP Android 15.0.0_2.0.0 中的 Kernel 版本为 6.12。因此，我将使用针对 6.12 的驱动程序进行移植。 在移植过程中，请确保 Makefile 和 Kconfig 文件中的 PATH 设置正确。 例如在我的移植中： . ├── Kconfig ├── Makefile └── pn7160 ├── common.c ├── common.h ├── i2c_drv.c ├── i2c_drv.h ├── Kbuild ├── Kconfig ├── Makefile ├── spi_drv.c └── spi_drv.h 为了简化一切，我们将只添加对 I2C 的支持，而不添加对 SPI 的支持。 用以下代码替换 drivers/nfc/pn7160/Makefile 的默认代码（便于理解） nxpnfc-i2c-objs = i2c_drv.o common.o obj-$(CONFIG_NXP_NFC_I2C) += nxpnfc_i2c.o drivers/nfc/Kconfig 的内容。如下添加 PN7160： source "drivers/nfc/pn7160/Kconfig" source "drivers/nfc/fdp/Kconfig" source "drivers/nfc/pn544/Kconfig" source "drivers/nfc/pn533/Kconfig" source "drivers/nfc/microread/Kconfig" source "drivers/nfc/nfcmrvl/Kconfig" source "drivers/nfc/st21nfca/Kconfig" source "drivers/nfc/st-nci/Kconfig" source "drivers/nfc/nxp-nci/Kconfig" source "drivers/nfc/s3fwrn5/Kconfig" source "drivers/nfc/st95hf/Kconfig" endmenu drivers/nfc/Makefile 的内容。添加 PN7160，如下所示： # SPDX-License-Identifier: GPL-2.0 # # Makefile for nfc devices # obj-$(CONFIG_NXP_NFC_I2C) += pn7160/ obj-$(CONFIG_NFC_FDP) += fdp/ obj-$(CONFIG_NFC_PN544) += pn544/ obj-$(CONFIG_NFC_MICROREAD) += microread/ obj-$(CONFIG_NFC_PN533) += pn533/ obj-$(CONFIG_NFC_MEI_PHY) += mei_phy.o obj-$(CONFIG_NFC_SIM) += nfcsim.o obj-$(CONFIG_NFC_PORT100) += port100.o obj-$(CONFIG_NFC_MRVL) += nfcmrvl/ obj-$(CONFIG_NFC_TRF7970A) += trf7970a.o obj-$(CONFIG_NFC_ST21NFCA) += st21nfca/ obj-$(CONFIG_NFC_ST_NCI) += st-nci/ obj-$(CONFIG_NFC_NXP_NCI) += nxp-nci/ obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5/ obj-$(CONFIG_NFC_ST95HF) += st95hf/ obj-$(CONFIG_NFC_VIRTUAL_NCI) += virtual_ncidev.o 2. 将 “nxpnfc” 添加到 i.MX8MN EVK 设备树文件中。 &i2c3 { clock-frequency = <100000>; pinctrl-names = "default", "gpio"; pinctrl-0 = <&pinctrl_i2c3>; pinctrl-1 = <&pinctrl_i2c3_gpio>; scl-gpios = <&gpio5 18 GPIO_ACTIVE_HIGH>; sda-gpios = <&gpio5 19 GPIO_ACTIVE_HIGH>; status = "okay"; nxpnfc@28{ compatible = "nxp,nxpnfc"; reg = <0x28>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_nfc>; nxp,nxpnfc-irq = <&gpio3 22 0>; nxp,nxpnfc-ven = <&gpio3 20 0>; nxp,nxpnfc-fw-dwnld = <&gpio3 21 0>; }; The GPIO settings in the IOMUXC: &iomuxc { pinctrl_nfc: nfcgrp { fsl,pins = < MX8MN_IOMUXC_SAI5_RXC_GPIO3_IO20 0X19 // VEN MX8MN_IOMUXC_SAI5_RXD0_GPIO3_IO21 0X19 // FW-DWNLD MX8MN_IOMUXC_SAI5_RXD1_GPIO3_IO22 0X19 // IRQ >; }; 3. 修改 imx8mn_gki.fragment 文件： android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/configs/imx8mn_gki.fragment 将 "CONFIG_NXP_NFC_I2C=m" 添加到 imx8mn_gki.fragment 4. 在 Android 系统中，将这些设置添加到对应的板级配置文件中 - 转到 android_build/device/nxp/imx8m/evk_8mn/ - 修改 BoardConfig.mk。 # selinux permissive + BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive BOARD_SEPOLICY_DIRS := \ $(CONFIG_REPO_PATH)/imx8m/sepolicy \ $(IMX_DEVICE_PATH)/sepolicy \ + vendor/nxp/nfc/sepolicy \ + vendor/nxp/nfc/sepolicy/nfc + include vendor/nxp/nfc/BoardConfigNfc.mk - 将 “nxpnfc_i2c.ko” 添加到 ShareBoardConfig.mk 中。请确保路径和文件名正确。 $(KERNEL_OUT)/drivers/net/phy/realtek.ko \ $(KERNEL_OUT)/drivers/pps/pps_core.ko \ $(KERNEL_OUT)/drivers/ptp/ptp.ko \ $(KERNEL_OUT)/drivers/net/ethernet/freescale/fec.ko + $(KERNEL_OUT)/drivers/nfc/pn7160/nxpnfc_i2c.ko endif $(KERNEL_OUT)/drivers/trusty/trusty-core.ko \ $(KERNEL_OUT)/drivers/trusty/trusty-log.ko \ $(KERNEL_OUT)/drivers/trusty/trusty-ipc.ko \ $(KERNEL_OUT)/drivers/trusty/trusty-virtio.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7160/nxpnfc_i2c.ko else BOARD_VENDOR_RAMDISK_KERNEL_MODULES += \ $(KERNEL_OUT)/drivers/input/touchscreen/goodix_ts.ko \ $(KERNEL_OUT)/drivers/input/touchscreen/synaptics_dsx/synaptics_dsx_i2c.ko Endif - 将以下内容添加到 Compatibility_matrix.xml netutils-wrapper 1.0 android.hardware.emvco 1 IEmvco default - 将以下内容添加到 device_framework_matrix.xml nxp.hardware.secureime 1 ISecureIME default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default vendor.nxp.nxpnfc 2 INxpNfc default android.hardware.emvco 1 IEmvco default - 将以下内容添加到 evk_8mn.mk # ------nfc------- $(call inherit-product, vendor/nxp/nfc/device-nfc.mk) $(call inherit-product, vendor/nxp/emvco/device-emvco.mk) PRODUCT_PACKAGES += \ android.hardware.nfc-service.nxp PRODUCT_PACKAGES += \ com.nxp.emvco \ com.nxp.nfc \ nfc_nci_nxp_pn72xx -在 init.rc 中添加 nxpnfc_i2c # Grant permission for fetching available_pages info of statsd chown system system /proc/pagetypeinfo chmod 0440 /proc/pagetypeinfo exec u:r:vendor_modprobe:s0 -- /vendor/bin/modprobe -a -d \ /vendor/lib/modules nxpnfc_i2c write /sys/power/wake_lock nosleep on post-fs-data && property:vendor.skip.charger_not_need=0 setprop vold.post_fs_data_done 1 - 将 nxpnfc 添加到 ueventd.nxp.rc /sys/devices/virtual/thermal/thermal_zone* trip_point_0_hyst 0660 system system /sys/devices/virtual/thermal/thermal_zone* trip_point_1_hyst 0660 system system /dev/dmabuf_imx 0664 system system /sys/class/backlight/* brightness 0660 system system /dev/ttymxc1 0666 nfc nfc /dev/ttymxc2 0666 nfc nfc /dev/nxpnfc 0666 nfc nfc # for libcamera /dev/media* 0660 system camera /dev/v4l-subdev* 0660 system camera 5.应用恩智浦 AOSP 补丁 由于官方 NXP NFC 补丁仅适用于 AOSP android-15.0.0_r1，而 android-15.0.0_r1 与 android-15.0.0_r32 之间存在较大差异。因此，在应用补丁之前，我先将 android-15.0.0_r1 的 NFC 文件夹复制过去，替换 android-15.0.0_r32 中的 NFC 文件夹。 首先，从 github 下载 AOSP android-15.0.0_r1。 $ mkdir android-15.0.0_r1 $ cd android-15.0.0_r1 $ repo init -u https://android.googlesource.com/platform/manifest -b android-15.0.0_r1 $ repo sync 然后，从 android-15.0.0_r32 中删除以下文件夹。然后从 android-15.0.0_r1 复制以下 NFC 文件夹，替换 android-15.0.0_r32 中的对应文件夹。 packages/apps/Nfc 框架/基础/NFC frameworks/base/nfc-extras system/nfc 例如： $ rm -rf android_build/packages/apps/Nfc $ cp -ra android-15.0.0_r1/packages/apps/Nfc android_build/packages/apps/ 我写了一个脚本来从 GitHub 下载补丁。客户可以将以下脚本放在与 android_build 相同的目录中。 AOSP_adaptation.sh # nxp_nci_hal_nfc git clone "https://github.com/nxp-nfc-infra/nxp_nci_hal_nfc.git" cd nxp_nci_hal_nfc git checkout br_ar_15_comm_infra_dev cp -rf * ../android_build/packages/apps/Nfc/ cd .. # nxp_nci_hal_libnfc-nci git clone "https://github.com/nxp-nfc-infra/nxp_nci_hal_libnfc-nci.git" cd nxp_nci_hal_libnfc-nci git checkout br_ar_15_comm_infra_dev cp -rf * ../android_build/system/nfc/ cd .. # nfcandroid_nfc_hidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_nfc_hidlimpl.git" cd nfcandroid_nfc_hidlimpl git checkout br_ar_15_comm_infra_dev cp -rf * ../android_build/hardware/nxp/nfc cd .. # nfcandroid_frameworks git clone "https://github.com/nxp-nfc-infra/nfcandroid_frameworks.git" cd nfcandroid_frameworks git checkout br_ar_15_comm_infra_dev mkdir ../android_build/vendor/nxp/frameworks cp -rf * ../android_build/vendor/nxp/frameworks cd .. # nfcandroid_emvco_aidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_emvco_aidlimpl.git" cd nfcandroid_emvco_aidlimpl git checkout br_ar_15_comm_infra_dev mkdir ../android_build/hardware/nxp/emvco cp -rf * ../android_build/hardware/nxp/emvco cd .. # nfcandroid_platform_reference git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_reference.git" cd nfcandroid_platform_reference git checkout br_ar_15_comm_infra_dev cp -rf vendor/nxp/* ../android_build/vendor/nxp/ cd .. # nfcandroid_infra_test_apps git clone https://github.com/nxp-nfc-infra/nfcandroid_infra_test_apps.git cd nfcandroid_infra_test_apps/ git checkout br_ar_15_comm_infra_dev cd test_apps/ cp -rf SMCU_Switch/ ../../android_build/packages/apps/ cp -rf EMVCoModeSwitchApp/ ../../android_build/packages/apps/Nfc/ cp -rf load_unload/ ../../android_build/hardware/nxp/nfc/ cp -rf SelfTestAidl/ ../../android_build/hardware/nxp/nfc/ cd ../.. # nfcandroid_infra_comm_libs git clone "https://github.com/nxp-nfc-infra/nfcandroid_infra_comm_libs.git" cd nfcandroid_infra_comm_libs git checkout br_ar_15_comm_infra_dev cp -rf nfc_tda/ ../android_build/system/ cp -rf emvco_tda/ emvco_tda_test/ ../android_build/hardware/nxp/emvco/ cp -rf NfcTdaTestApp/ ../android_build/packages/apps/Nfc/ cd .. Apply_patches.sh cd android_build/build/bazel/ patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_bazel.patch cd ../release patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_release.patch cd ../../external/libchrome patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_external_libchrome.patch cd ../../frameworks/base patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_frameworks_base.patch cd ../../system/logging patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_system_logging.patch 因此，先运行 AOSP_adaptation.sh，然后再运行 Apply_patches.sh。 6. 将更改放入 hardware/interfaces/compatibility_matrices 不同 Android 版本的兼容性矩阵不同。 文件: android_build/hardware/interfaces/compatibility_matrices/compatibility_matrix.202404.xml android.hardware.audio.effect 1-2 IFactory default + + nxp.hardware.imx_dek_extractor + 1 + + IDek_Extractor + default + + + + vendor.nxp.nxpnfc + 2 + + INxpNfc + default + + + + vendor.nxp.emvco + 1 + + INxpEmvco + default + + android.hardware.audio.sounddose 1-3 7. 更改设备特定的 .mk 对于 pn7160，NXP_NFC_HW 应等于 pn7160。 对于 pn7220，NXP_NFC_HW 应等于 pn7220_i2cs。 文件 : android_build/vendor/nxp/nfc/device-nfc.mk ##### ##### NXP NFC Device Configuration makefile ###### NXP_NFC_HOST := $(TARGET_PRODUCT) ifndef TARGET_NXP_NFC_HW NXP_NFC_HW := pn7160 else NXP_NFC_HW := $(TARGET_NXP_NFC_HW) endif NXP_NFC_PLATFORM := pn54x NXP_VENDOR_DIR := nxp NXP_I2CM_S := $(TARGET_NXP_I2C_M_S) 文件：android_build/vendor/nxp/emvco/device-emvco.mk NXP_VENDOR_DIR := nxp NXP_NFC_HW := $(TARGET_NXP_NFC_HW) ifeq ($(strip $(TARGET_NXP_NFC_HW)),) NXP_NFC_HW := pn7160 endif # Nfc service has dependency with EMVCo JAR PRODUCT_PACKAGES += \ com.nxp.emvco 8. 现在，你可以开始构建 Android BSP。 对于 i.MX8MN EVK， $ source build/envsetup.sh $ lunch evk_8mn-nxp_stable-userdebug $ export TARGET_RELEASE=nxp_stable $ build_build_var_cache $ ./imx-make.sh -j4 2>&1 | tee build-log.txt 在构建 BSP 时，可能会出现许多错误。我在下方列出了一些错误及参考解决方案，供客户参考。 错误 参考解决方案 报错与 nfc_aconfig_flags 相关。 packages/apps/Nfc/flags/Android.bp aconfig_declarations { // name: "nfc_aconfig_flags", name: "com.android.nfc.flags-aconfig", package: "com.android.nfc.flags", container: "system", srcs: ["nfc_flags.aconfig"], } java_aconfig_library { // name: "nfc_aconfig_flags_lib", // aconfig_declarations: "nfc_aconfig_flags", name: "com.android.nfc.flags-aconfig-java", aconfig_declarations: "com.android.nfc.flags-aconfig", min_sdk_version: "33", apex_available: [ "//apex_available:platform", "com.android.nfcservices", ], } java_library { name: "nfc_flags_lib", sdk_version: "system_current", min_sdk_version: "33", srcs: [ "lib/**/*.java", ], static_libs: [ "com.android.nfc.flags-aconfig-java", ], 报错与 android.hardware.nfc-V2-ndk 相关 文件： hardware/interfaces/nfc/aidl/vts/functional/Android.bp 更改 android.hardware.nfc-V2-ndk到 android.hardware.nfc-V1-ndk platform_testing/build/tasks/tests/native_test_list.mk：错误：continuous_native_tests：模块“libnfc-nci-jni-tests”的未知已安装文件 删除 'libnfc-nci-jni-tests' native_test_list.mk 错误：packages/apps/Nfc/tests/instrumentation/Android.bp:6:1：模块 "NfcNciInstrumentationTests" 变体 "android_common"：无法直接依赖 java_sdk_library "android.test.runner"；尝试依赖于 "android.test.runner.stubs"、"android.test.runner.stubs.system"、"android.test.runner.stubs.test"、或 "android.test.runner.impl"。 错误信息中已经给出了提示。 将 "android.test.runner" 改为 "android.test.runner.stubs"、"android.test.runner.stubs.system"、"android.test.runner.stubs.test"、或 "android.test.runner.impl" 错误：vendor/nxp/frameworks/nfc/Android.bp:12:1:模块 "com.nxp.nfc"不同版本 "android_common"：依赖于 //frameworks/base/nfc:framework-nfc.impl，但该模块对当前模块不可见 你可能需要将 "//vendor/nxp/frameworks/nfc" 添加到其可见性列表中 文件：frameworks/base/nfc/Android.bp permitted_packages: [ "android.nfc", "com.android.nfc", ], impl_library_visibility: [ "//frameworks/base:__subpackages__", "//cts/hostsidetests/multidevices/nfc:__subpackages__", "//cts/tests/tests/nfc", "//vendor:__subpackages__", "//packages/apps/Nfc:__subpackages__", ], packages/apps/Nfc/nci/src/com/android/nfc/dhimpl/NativeT4tNfceeManager.java:20: error: duplicate class: com.android.nfc.dhimpl.NativeT4tNfceeManager 编辑文件 packages/apps/Nfc/nci/src/com/android/nfc/dhimpl/NativeT4tNfceeManager.java 然后注释掉重复的类。 android/R.java:12483:错误：无法解析字段 FLAG_NFC_ASSOCIATED_ROLE_SERVICES     @android.annotation.FlaggedApi(android.nfc.Flags.FLAG_NFC_ASSOCIATED_ROLE_SERVICES) 编辑 frameworks/base/nfc/java/android/nfc/flags.aconfig 添加下面的旗帜。 flag { name: "nfc_associated_role_services" is_exported: true namespace: "nfc" description: "Share wallet role routing priority with associated services" bug: "366243361" } 失败： platform_testing/build/tasks/tests/native_test_list.mk：错误：continuous_native_tests：模块 'libnfc-nci-tests' 的未知版本文件 从 native_test_list.mk 中删除 libnfc-nci-tests。 prebuilts/clang/host/linux-x86/clang-r536225/include/c++/v1/string:780:43: 错误：隐式实例化未定义模板 'std::char_traits ' 780 | static_assert((is_same<_CharT, typename traits_type::char_type>::value),       |                                           ^ packages/apps/Nfc/nci/jni/NativeNfcTda.cpp:32:35: 注意：在此处请求实例化模板类 'std::basic_string '    32 | static std::basic_string sRxTdaDataBuff;       |                                   ^ 编辑 packages/apps/Nfc/nci/jni/NativeNfcTda.cpp using android::base::StringPrintf; extern bool nfc_debug_enabled; SyncEvent sCtLibSyncEvt; //static std::basic_string sRxTdaDataBuff; static std::basic_string sRxTdaDataBuff; packages/apps/Nfc/nci/jni/NativeT4tNfcee.cpp:493:21：错误：没有与调用 'append' 匹配的成员函数   493 |       sRxDataBuffer.append(data.p_data,data.len);       |       ~~~~~~~~~~~~~~^~~~~~ 编辑packages/apps/Nfc/nci/jni/NativeT4tNfcee.cpp void NativeT4tNfcee::t4tReadComplete(tNFA_STATUS status, tNFA_RX_DATA data) { mT4tOpStatus = status; if (status == NFA_STATUS_OK) { if (data.len > 0) { sRxDataBuffer.insert(sRxDataBuffer.end(), data.p_data, data.p_data + data.len); LOG(DEBUG) << StringPrintf("%s: Read Data len new: %d ", __func__, data.len); } } SyncEventGuard g(mT4tNfcEeRWCEvent); mT4tNfcEeRWCEvent.notifyOne(); } frameworks/base/core/java/android/provider/Settings.java：2351：错误：无法解析字段FLAG_NFC_ACTION_MANAGE_SERVICES_SETTINGS @FlaggedApi(android.nfc.Flags.FLAG_NFC_ACTION_MANAGE_SERVICES_SETTINGS) 文件：frameworks/base/nfc/java/android/nfc/flags.aconfig 将以下内容添加到 flags.aconfig： flag { name: "nfc_action_manage_services_settings" is_exported: true namespace: "nfc" description: "Add Settings.ACTION_MANAGE_OTHER_NFC_SERVICES_SETTINGS" bug: "358129872" } 表格中未列出某些错误，因为错误信息中通常会包含相应的修正提示。客户可以根据提示操作，并结合自身需求修改源代码。 有时，客户可以比较 r1 和 r32 的源代码。这是 AOSP 的源代码 android-15.0.0_r32 和 android-15.0.0_r1。 9. 将图像下载到 i.MX8MN EVK 板 - 在 8MN EVK 板上切换到下载模式 - 首先从 Android BSP 网页下载 Android 15 BSP i.MX8MN EVK 演示镜像。因为演示图像包中已经包含了 UUU 脚本和必要的图像文件。 - 从这里下载 UUU：版本 · nxp-imx/mfgtools - 将 UUU 可执行文件放入演示镜像文件夹中。uuu_imx_android_flash.bat 脚本也在同一文件夹中。 - 构建成功后，将图像复制到演示图像文件夹中。这些图像位于 android_build/out/target/product/evk_8mn/ 目录下。 - 运行 UUU 脚本将图像下载到 EVK 板。 参考资料： 运行 Yocto Linux + PN7160 的 i.MX6ULL EVK 在 i.MX8M Nano 开发板上将 PN7160 移植至 Android 14 i.MX 应用处理器的 Android 操作系统 | NXP 半导体 PN7160/PN7220 – Android 15 移植指南 即插即用 NFC 前端集成固件 | NXP 半导体

AP Software Label Definition This table is intended as a reference to add clarity for selecting the correct label for your case. It is not regularly update and may not reflect all currently available products. Label Full Name Products Covered SAFETY_SW Safety Software Safety Software Framework (SAF) SCST (Structural Core Self-Test) SbSW (Safety by Software) FSS_FW Foundation Subsystem Firmware F-SS HPC_BSP LINUX_BSP PFE PFE Linux PFE MCAL PFE QNX QNX Security Layer High Performance Compute/Board Support Package PFE Software (with GMAC for Linux) CAR-V Networking QNX Crypto (QNX Security Layer) HPC OSAL (OS Abstraction Layer) Linux BSP Conti SOM Linux BSP GOLD_VIP GREEN_VIP GRAY_VIP Vehicle Integration Platform Platform integration Common VIP VIP Electrification and Dynamics VIP VNP TSN_STACK Time Sensitive Networking Stack TSN Stack AVB_STACK Audio Video Bridging Stack AVB Stack (ETH) GPTP_STACK Generic Precision Time Protocol Stack gPTP Stack TCPIP_STACK Transmission Control Protocol Internet Protocol Stack TCPIP Stack SDHC_STACK Secure Digital High Capacity Stack SDHC Stack USB_STACK Universal Serial Bus Stack USB Stack LIN_STACK Local Interconnect Network Stack LIN Stack AMMCLib Automotive Math and Motor Control Library AMMCLib ETPU Enhanced Timer Processor Unit eTPU COOLFLUX Cool Flux CoolFlux GTM Generic Timer Module GTM RTOS RealTimeHypervisor Real-Time Operating System L4RE AUTOSAR OS/NXP RTOS FreeRTOS POSIX OS IPCF EL2 Monitor RTD Real-Time Drivers Real Time Drivers/MCAL LLCE Low Latency Communication Engine LLCE IPCF Inter-Platform Communication Framework IPCF HSE_FW SECURITY_CRYPTO High Security HSE Crypto Driver S32DS S32 Design Studio S32 Design Studio IDE S32 Debugger S32 Flash Programmer S32 Trace S32_FLASH_TOOL S32 Flash Tool S32 Flash Tool S32 Flash SDK S32_CONFIG_TOOL S32 Configuration Tools S32 Config Tool PINS Tool CLOCKS Tool PERIPHERALS Tool IVT Tool EENV Tool QSPI Tool DDR Config Tool MBDT Model Based Design Tools Model-Based Design Toolbox MBDT for RADAR MBDT for VISION AUTOSAR SW-C ISELED Intelligent Smart Embedded LED Intelligent Smart Embedded LED AWS_IOT_CORE EB TRESOS LICENSES EB Tresos License topics (NO tool usage topics) AA SW - External Device SBC, PMIC, CAN TRCV, LIN TRCV, SWITCH, PHY AA SW - External Device AMMCLib AVB_STACK AWS_IOT_CORE COOLFLUX EB TRESOS LICENSES ETPU FSS_FW GOLD_VIP GPTP_STACK GRAY_VIP GREEN_VIP GTM HPC_BSP HSE_FW IPCF ISELED LIN_STACK Linux BSP LLCE MBDT PFE PFE Linux PFE MCAL PFE QNX

Building UUU custom built-in script Hello everyone, In this document I'll explain on how to build the UUU (Universal Update Utility) using windows 10 PC. This may be useful in case of adding custom commands to run during the flash using built-in scripts, be it for debugging, fuse blowing, etc. First we need to download and install Visual Studio community, for this guide I'll use community 2019, version it is available here: https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=Community&rel=16 For workloads select Universal Windows Platform development.   When installing, make sure to select and install the Git for windows complement, at the top select Individual components, this will display a new list, scroll down to code tools and you will find Git for windows, check this box In case Visual Studio is already installed, you may open the installer again and chose modify, this will let you install the complement as well. After the installation is complete we may run the git commands on the power shell. Now open the windows power shell and type the following commands: git clone https://github.com/NXPmicro/mfgtools.git // clones the MFGTool (UUU) source code from the github cd mfgtools // enters the mfgtools folder we just cloned git submodule init // creates the local configuration file for the submodules git submodule update // set the submodules to the commit specified by the main repository. At this point we can edit the built in scripts to add our custom commands, for this guide I'll add the printenv uboot command at the end of the flashing process. For this I'll enter the folder mfgtools/uuu, and edit emmc_burn_all.lst with any text editor, i.e. Notepad ++, add the command FB: ucmd printenv.   Save and close the editor, it is possible to add most uboot commands like for example the fuse commands to burn eFuses. Then we can now build the tool, opening msvc/uuu-static-link.sln with Visual studio, select solution uuu-static-link.sln   And finally build the solution: The executable (uuu.exe) would be at the following path: mfgtools\msvc\x64\Debug   Finally we run the built in script we modified and check the results. Find attached both the powershell and uboot logs, I tested this using an i.MX8MN with L5.4.47_2.2.0, running the following command: ./uuu.exe -v -b emmc_all imx-boot-imx8mnevk-sd.bin-flash_evk imx-image-full-imx8mnevk.wic Hope this may found useful for anyone trying to achieve something similar. i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano i.MX6 All Windows

Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Background 1. Generating a PKI tree, and include a subordinate SGK key 2. Generating an SRK Table and SRK Hash 3. Retrieve the chip information 4. Update the configuration files and generate message 5. Signing the message 6. Change lifecycle to PFR by the first method 6.1 Regenerate flash.bin with message_signed.bin 6.2 Regenerate flash-signed.bin 7. Change lifecycle to PFR by the second method 7.1 Add command in uboot-imx 7.2 Boot the board and input command Background The chip fuse has been programmed and closed(Security configuration enabled) following the process described in mx8_mx8x_secure_boot.txt in  mx8_mx8x_secure_boot.txt\guides\ahab\imx\doc - uboot-imx - i.MX U-Boot  There are two ways to change the lifecycle to Partial Field Return (PFR) by the method of a signed message. One is to generate flash.bin with message_signed.bin, another is to write a new command in uboot, then manually add message-signed.bin in uboot. The latter can change the message content more conveniently. Please note that these details/scripts are currently for NXP Internal reference. Please don’t share with customers. Based on the above, the steps for partial field return are like below:    1. Generating a PKI tree, and include a subordinate SGK key   2. Generating an SRK Table and SRK Hash $ cd ../crts/ $ ../linux64/bin/srktool -a -s sha384 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -f 1 -c SRK1_sha384_secp384r1_v3_ca_crt.pem,SRK2_sha384_secp384r1_v3_ca_crt.pem,SRK3_sha384_secp384r1_v3_ca_crt.pem,SRK4_sha384_secp384r1_v3_ca_crt.pem     The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further steps.   3. Retrieve the chip information On the iMX8/8X device, boot the device and on the SCU terminal type and run the command “seco info”. The following output will be seen on the SCU terminal. Save this info as it is needed later on.   4. Update the configuration files and generate message Modify the message_header.json {"container": {"message": {"permission": "0x10", "cert version": "0", "UID": "0C13380E82895B2C", "flags": "0", "monotonic counter": "0x0"}, "header": {"fuse version": "0", "SW version": "0", "version": "0"}}} Modify the message_content.json, from below chart, to change to partial return , the lifecycle needs to change to 0x20 {"Id": "0xa0", "lifecycle": "0x20", "nb words": "1"}   Then generate the message by the following command-line.   $python gen-msg-json.py message_header.json message_content.json -o message.bin   5. Signing the message Like below, modify the permission to Fuse1: SCU Version. Life Cycle, that is 0x10.     [Header] Target = AHAB Version = 1.0 [Install SRK] # SRK table generated by srktool File = "../crts/SRK_1_2_3_4_table.bin" # Public key certificate in PEM format Source = "../crts/SRK1_sha384_secp384r1_v3_usr_crt.pem" # Index of the public key certificate within the SRK table (0 .. 3) Source index = 0 # Type of SRK set (NXP or OEM) Source set = OEM # bitmask of the revoked SRKs Revocations = 0x0   # ******* OPTIONAL COMMAND ***** [Install Certificate] # Public key certificate in PEM format File = "../crts/SGK1_1_sha384_secp384r1_v3_usr_crt.pem" # bitmask of the permissions Permissions = 0x10 # ****************************** [Authenticate Data] # Binary to be signed generated by mkimage File = "message.bin" # Offsets = Container header  Signature block (printed out by mkimage) Offsets   = 0x0             0x48   And run the command: ../linux64/bin/cst -i message.csf -o message_signed.bin and can get message_signed.bin   6. Change lifecycle to PFR by the first method The first method is to regenerate signed flash.bin with message_signed.bin.   6.1 Regenerate flash.bin with message_signed.bin $cp the message_signed.bin to imx-mkimage/iMX8QX/ Go to the imx_mkimage repo and edit the rule flash_msg_block in ./iMX8QX/scripts/misc.mak.   -./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -msg_blk test_block.bin field 0x83000000 -out flash.bin +./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -msg_blk message_signed.bin field 0x83000000 -out flash.bin Then run: $ make SOC=iMX8QX flash_msg_block It will generate a new flash.bin, because the board is on OEM close state, so you need to regenerate flash-signed.bin again.   6.2 Regenerate flash-signed.bin Create the csf_boot_image_csf.csf ,like below: [Header] Target = AHAB Version = 1.0 [Install SRK] # SRK table generated by srktool File = "../crts/SRK_1_2_3_4_table.bin" # Public key certificate in PEM format Source = "../crts/SRK1_sha384_secp384r1_v3_usr_crt.pem" # Index of the public key certificate within the SRK table (0 .. 3) Source index = 0 # Type of SRK set (NXP or OEM) Source set = OEM # bitmask of the revoked SRKs Revocations = 0x0 # ******* OPTIONAL COMMAND ***** #[Install Certificate] #Public key certificate in PEM format #File = "../crts/SGK1_1_sha384_secp384r1_v3_usr_crt.pem" #bitmask of the permissions #Permissions = 0x10 # ****************************** [Authenticate Data] # Binary to be signed generated by mkimage File = "flash.bin" # Offsets = Container header  Signature block (printed out by mkimage) Offsets   = 0x400             0x590 And run the command: ../linux64/bin/cst -i csf_boot_image_csf.csf -o flash_signed.bin and can get flash_signed.bin   Finally, flash-signed.bin will generate, and dd to sd card. The lifecycle will expect to become 0x100.   7. Change lifecycle to PFR by the second method The second method is to write a new command in uboot, then add message-signed.bin in uboot manually by the command.   7.1  Add command in uboot-imx $ git am 0002-add_ahab_return_lifecycle_disable_cache.patch $ source $ unset LDFLAGS $ make -j8 Regenerate the u-boot.bin. $ cp u-boot.bin  $ cd imx-mkimage/ $ make SOC=iMX8QX flash $ cp iMX8QX/flash.bin The has the csf description file for flash-signed.bin $ cd $ ../linux64/bin/cst -i csf_boot_image.txt -o flash-signed.bin $ sudo dd if=flash-signed.bin of=/dev/sdX bs=1k seek=32 ; sync Then generate the flash-signed.bin used this new u-boot.bin.Copy message-signed.bin generated in the fifth step to sdcard. 7.2 Boot the board and input command Power up the board, and stop the uboot. $ fatload mmc 1:1 0x80280000 message_signed.bin $ ahab_status $ ahab_return_lifecycle 0x80280000 $ ahab_status Note that the address is consistent with the address that you input in the first step. Then you can input $seco info in SCU serial port, and see the lifecycle will expect to become 0x100.   Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi @Tia_Lan  Can you provide the Lauterbach script to dump SECO log to Ankit? Best Regards, Frank Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi @frank_zhang  It is not possible as customer performs return LC to OEM Field Return from Linux kernel sysfs driver and then power cycles device. Below are the logs customer observed when they checked ahab_status after performing return LC to OEM Field Return # dd if=signed_msg_512.bin of=/sys/kernel/seco/field_return bs=816 [ 548.708086] imx_scu_call_rpc(...) failed with error -13! [ 548.708097] imx_sc_seco_return_lifecycle(...) failed with error -13 1+0 records in 0+0 records out 0 bytes (0B) copied, 0.066212 seconds, 0B/s # cat /sys/kernel/seco/ahab_status Lifecycle: 0x0080, OEM closed UID_H: 0x1A10B00E UID_L: 0x8292379B Monotonic counter: 0x0000 SECO event[0] = 0x00A0AB29 CMD = AHAB_FIELD_RETURN_REQ (0xA0) IND = Unknown Indicator (0xAB) Found 1 SECO events SECO events found - authenticity check failed! -Ankit. Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi Ankit, Can customer run ahab_dump in uboot after they see error? We can see SECO log. Best Regards, Frank Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi @frank_zhang  Customer did "signed message way". They prepared and signed "Return Lifecycle Update" message using their CST tool. On Target, through Linux console, feed "signed message" to their sysfs driver. And sysfs driver invoke SCU API : sc_seco_return_lifecycle (having  SECO_FUNC_RETURN_LIFECYCLE) function. They have not used signed image way(thus signed message is part of the boot image). -Ankit. Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi Ankit, Did they use signed message way or signed image way(thus signed message is part of the boot image)? Best Regards, Frank Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi @frank_zhang  Yes, I am doing well. Hope everything OK from your side too. Customer has performed below steps: Step-1: On "i.MX8QXP B0" device having OEM Open (NXP Closed) state, first tested returning the LC to OEM Field Return execution using "signed Return Lifecycle Update message" and received the SECO event 0x00A0FA29 (AHAB_BAD_KEY_HASH_IND). This confirm that signed message is ready to use on "OEM Closed" device. Step-2: Burned the OEM SRK Hash fuses. Step-3: Flashed and booted using signed images; confirmed that no SECO events occurred during the boot process. This confirm device is in secure boot. Step-4: Advanced the LC to "OEM Closed" using their sysfs driver. Step-5: Power-cycle the board and attempted to return the LC to OEM Field Return; received SECO event 0x00A0AB29. This event indicates that the "FUSE is write/read locked". Step-6: Power-cycle the board and it was in OEM Field Return state. Do you see any issues with the above steps or have any suggestions? Please note that, we just received an update from customer that they did all the above mentiond steps on another board & seen ""FUSE is write/read locked"" error. And "Despite this, after performing power-cycle on the board, the LC successfully changed to "OEM Field Return" -Ankit. Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi Ankit, Long time no see. Hope you are doing good. I don't think it is expected. But you say the LC is changed. Somethings you might can help me check. Find all LC related fuses(I remember it is not only one), and see if customer program any bits on the same words before. I will check with STEC in next Wendsday call. please give me a reminder on Wendsday. Best Regards, Frank Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family Hi @frank_zhang , We received a customer query regarding the return lifecycle transition to "OEM Field Return" from "OEM Closed" for "i.MX8QXP" device. The customer has implemented a sysfs driver in Linux kernel to invoke SECO APIs. Using this driver, they are able to transition the lifecycle from "NXP Closed (OEM Open)" to "OEM Closed" successfully. However, when they attempt to return the lifecycle state to "OEM Field Return", they encounter an issue and wanted some clarification. After invoking SECO API (SC_SECO_FUNC_RETURN_LIFECYCLE), they receive the following SECO event: SECO event[0] = 0x00A0AB29. This event indicates that the "FUSE is write/read locked". Despite this, after performing power-cycle on the board, the lifecycle appears to be successfully changed to "OEM Field Return". Is this behavior expected?

进入i.MX 8/8X系列部分场回馈生命周期的步骤 背景信息 1. 生成一个 PKI 树，并包含一个下级 SGK 密钥 2. 生成 SRK 表和 SRK 哈希 3. 获取芯片信息 4. 更新配置文件并生成消息 5. 对消息进行签名 6. 通过第一种方法将生命周期更改为PFR 6.1 使用 message_signed.bin 重新生成 flash.bin 6.2 重新生成 flash-signed.bin 7. 通过第二种方法将生命周期更改为PFR 7.1 在 uboot-imx 中添加命令 7.2 启动板并输入命令 背景信息 根据mx8_mx8x_secure_boot.txt中描述的过程，芯片熔丝已编程并关闭（启用网络安全配置） 在mx8_mx8x_secure_boot.txt\guides\ahab\imx\doc - uboot-imx - i.MX U-Boot 有两种方法可以通过签名消息的方法将生命周期更改为部分字段返回(PFR)。一种方法是使用message_signed.bin生成flash.bin，另一种方法是在uboot中编写新命令，然后手动将message_signed.bin添加到uboot中。后者可以更方便地更改消息内容。 请注意，这些细节/脚本目前仅供NXP内部参考。请不要和顾客分享。 基于上述，部分字段返回的步骤如下：   1. 生成一个PKI树，并包含一个下属SGK密钥   2. 生成 SRK 表和 SRK 哈希 $ cd ../crts/ $ ../linux64/bin/srktool -a -s sha384 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -f 1 -c SRK1_sha384_secp384r1_v3_ca_crt.pem,SRK2_sha384_secp384r1_v3_ca_crt.pem,SRK3_sha384_secp384r1_v3_ca_crt.pem,SRK4_sha384_secp384r1_v3_ca_crt.pem     SRK_1_2_3_4_table.bin和SRK_1_2_3_4_fuse.bin文件还可用于后续步骤。   3. 获取芯片信息 在iMX8/8X设备上，启动设备并在SCU终端输入并运行命令“seco info”。下列输出将显示在SCU终端上。保存此信息，以备后用。   4. 更新配置文件并生成消息 修改 message_header.json {"container": {"message": {"permission": "0x10", "cert version": "0", "UID": "0C13380E82895B2C", "flags": "0", "monotonic counter": "0x0"}, "header": {"fuse version": "0", "SW version": "0", "version": "0"}}} 从下图中修改message_content.json，要改为部分返回，生命周期需要改为0x20 {"Id": "0xa0", "lifecycle": "0x20", "nb words": "1"}   然后通过以下命令行生成消息。   $python gen-msg-json.py message_header.json message_content.json -o message.bin   5. 对消息进行签名 如下所示，将权限修改为 Fuse1：SCU 版本。生命周期，即 0x10。     [标题] 目标 = AHAB 版本 = 1.0 [安装SRK] # srktool生成SRK表格 文件 = "../crts/SRK_1_2_3_4_table.bin" # PEM格式的公钥证书 来源 = "../crts/SRK1_sha384_secp384r1_v3_usr_crt.pem" # SRK表中公钥证书的索引(0 .. 3) 源索引 = 0 # SRK集类型（NXP或OEM） 源集 = OEM # 撤销SRK的位掩码 撤销 = 0x0   # ******* 可选命令 ***** [安装证书] # PEM格式的公钥证书 File = "../crts/SGK1_1_sha384_secp384r1_v3_usr_crt.pem" # 权限的位掩码权限 = 0x10# ******************************[验证数据]# mkimage生成的待签名二进制文件文件 = "message.bin"# 偏移量 = 容器标题 签名块（由mkimage打印） 偏移量   = 0x0             0x48   然后执行命令： ../linux64/bin/cst -i message.csf -o message_signed.bin 并且可以获取message_signed.bin   6. 通过第一种方法将生命周期更改为PFR 第一种方法是使用 message_signed.bin 重新生成已签名的 flash.bin。   6.1 使用 message_signed.bin 重新生成 flash.bin $cp message_signed.bin到imx-mkimage/iMX8QX/ 转到imx_mkimage仓库并编辑./iMX8QX/scripts/misc.mak中的flash_msg_block规则。   -./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -msg_blk test_block.bin field 0x83000000 -out flash.bin +./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -msg_blk message_signed.bin field 0x83000000 -out flash.bin 然后运行： $ make SOC=iMX8QX flash_msg_block 它将生成新的flash.bin，因为板处于OEM关闭状态，所以需要重新生成flash-signed.bin。   6.2 重新生成 flash-signed.bin 创建 csf_boot_image_csf.csf 文件，如下所示： [标题] 目标 = AHAB 版本 = 1.0 [安装SRK] # srktool生成SRK表格 文件 = "../crts/SRK_1_2_3_4_table.bin" # PEM格式的公钥证书 来源 = "../crts/SRK1_sha384_secp384r1_v3_usr_crt.pem" # SRK表中公钥证书的索引(0 .. 3) 源索引 = 0 # SRK集合类型（NXP或OEM） 源集合 = OEM # 已撤销SRK的位掩码 撤销 = 0x0 # ******* 可选命令 ***** #[安装证书] # PEM格式的公钥证书 # 文件 = "../crts/SGK1_1_sha384_secp384r1_v3_usr_crt.pem"# 权限的位掩码 # 权限 = 0x10 # ****************************** [认证数据] # mkimage生成的待签名二进制文件 文件 = "flash.bin" # 偏移量 = 容器标题 签名块（由mkimage打印） 偏移量   = 0x400             0x590 然后运行命令： ../linux64/bin/cst -i csf_boot_image_csf.csf -o flash_signed.bin 即可获得flash_signed.bin   最后，将生成flash-signed.bin文件，并使用dd命令将其写入SD卡。生命周期预计将变为0x100。   7. 通过第二种方法将生命周期更改为PFR 第二种方法是在uboot中写一个新命令，然后通过该命令在uboot中手动添加message-signed.bin。   7.1 在uboot-imx中添加命令。 $ git am 0002-add_ahab_return_lifecycle_disable_cache.patch $ source $ unset LDFLAGS $ make -j8 重新生成u-boot.bin。 $ cp u-boot.bin  $ cd imx-mkimage/ $ make SOC=iMX8QX flash $ cp iMX8QX/flash.bin 包含flash-signed.bin的CSF描述文件 $ cd $ ../linux64/bin/cst -i csf_boot_image.txt -o flash-signed.bin $ sudo dd if=flash-signed.bin of=/dev/sdX bs=1k seek=32 ; sync 然后使用这个新的u-boot.bin生成flash-signed.bin。将第五步生成的message-signed.bin复制到SD卡。 7.2 启动板并输入命令 给板上电，并停止uboot。 $ fatload mmc 1:1 0x80280000 message_signed.bin $ ahab_status $ ahab_return_lifecycle 0x80280000 $ ahab_status 请注意，该地址与您在第一步中输入的地址一致。 然后您可以在SCU串口输入$seco info，看看生命周期预期会变成0x100。   Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 你好@Tia_Lan 您能提供 Lauterbach 脚本将 SECO 日志转储到 Ankit 吗？ 顺祝商祺！ 弗兰克 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 你好@frank_zhang 这是不可能的，因为客户从 Linux 内核 sysfs 驱动程序将 LC 返回 OEM 现场操作，然后重启设备电源。 以下是客户在执行 OEM Field Return 返回 LC 后检查 ahab_status 时观察到的日志 # dd if=signed_msg_512.bin of=/sys/kernel/seco/field_return bs=816 [ 548.708086] imx_scu_call_rpc(...) 失败，错误 -13! [ 548.708097] imx_sc_seco_return_lifecycle(...) 失败，错误 -13 0+0 中的 1+0 条记录复制了 0 字节 (0B)，0.066212 秒，0B/s # cat /sys/kernel/seco/ahab_status 生命周期：0x0080，OEM 已关闭 UID_H: 0x1A10B00E UID_L: 0x8292379B 单调性计数器：0x0000 SECO event[0] = 0x00A0AB29 CMD = AHAB_FIELD_RETURN_REQ (0xA0) IND = 未知指示符 (0xAB) 发现 1 SECO 活动 发现 SECO 事件 - 真实性检查失败！ -安基特 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 嗨，安基特、 客户看到错误后，能否在 uboot 中运行 ahab_dump？我们可以查看 SECO 日志。 顺祝商祺！ 弗兰克 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 你好@frank_zhang 客户以"的方式签署了" 。 他们使用 CST 工具编写并签署了"Return Lifecycle Update" 信息。 在目标上，通过 Linux 控制台将"签名信息" 发送到其 sysfs 驱动程序。而 sysfs 驱动程序会调用 SCU API： sc_seco_return_lifecycle（具有 SECO_FUNC_RETURN_LIFECYCLE）函数。 他们没有使用签名映像方式（因此签名消息是启动映像的一部分）。 -安基特 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 嗨，安基特、 他们使用的是签名消息方式还是签名映像方式（因此签名消息是启动映像的一部分）？ 顺祝商祺！ 弗兰克 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 你好@frank_zhang 是的，我做得很好。希望你那边也一切顺利。 客户已执行以下步骤： 第 1 步：在处于 OEM 开放（恩智浦关闭）状态的 " i.mx8QXP B0 " 设备上，首先测试了使用 " 签名的退货生命周期更新消息 " 将 LC 返回 OEM 现场退货 执行状态，并收到了 SECO 事件 0x 00a0fa29（AHAB_BAD_KEY_HAS_IND）。这确认签名消息已准备就绪，可以在 " OEM Closed " 设备上使用。 第 2 步：烧毁 OEM SRK 哈希熔丝。 步骤3：使用签名镜像刷新并启动；确认启动过程中未发生 SECO 事件。此确认设备处于安全启动状态。 第 4 步：使用其 sysfs 驱动程序将 LC 高级到" OEMClosed" 。 第 5 步：重启板并尝试将 LC 返回 OEM 现场退货；收到了 SECO 事件 0x00A0AB29。此事件表示 "熔丝已被写入/读取锁定"。 第 6 步：重新启动板，它处于 OEM 现场返回状态。 您认为上述步骤有问题吗？ 请注意，我们刚刚收到买家的最新消息，称他们在另一块板上完成了上述所有步骤 & 看到 " " 熔丝 被写入/读取锁定 " " 错误。而且 " 尽管如此，在板上进行电源循环后，LC 成功更改为 " OEM Field Return " -安基特 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 嗨，安基特、 好久不见。希望你一切都好。 我不认为这是意料之中的事。但你说 LC 已经改变了。你能帮我检查一下吗？ 找到所有与 LC 相关的熔丝（我记得它不只一个），看看客户之前是否对同一个单词进行了编程。 我将在下周末的电话中向 STEC 询问。请在周末提醒我。 顺祝商祺！ 弗兰克 Re: Steps to enter Partial Field Return LifeCycle on i.MX 8/8X Family 你好@frank_zhang、 我们收到了客户关于从 " OEM 已 关闭 " 向 " i.mx8QXP " 设备的退货生命周期过渡到 " OEM Field Return " 的询问 。 客户在 Linux 内核中实施了一个 sysfs 驱动程序，以调用SECO API。使用该驱动程序，他们能够将生命周期从 "NXP Closed (OEM Open)"成功过渡到"OEM Closed"。 但是，当他们尝试将生命周期状态返回到"OEM Field Return" 时，他们遇到了一个问题，希望得到一些澄清。 调用 SECO API（SC_SECO_FUNC_RETURN_LIFECYCLE）后，它们会收到以下 SECO 事件：SECO event[0] =0x00A0AB29。此事件表示 "熔丝已被写入/读取锁定"。 尽管如此，在板上执行电源循环后，生命周期似乎成功更改为 " OEM Field Return "。 这种行为是预料之中的吗？

KW45/MCXW71 将时钟外设从 FRO6M 更改为其他时钟源 在现代嵌入式系统中，精确且可靠的时钟信号对于数字外设的正确运行至关重要。恩智浦的 KW45 和 MCXW71 等微控制器依赖内部振荡器为 UART、SPI、定时器和 ADC 等外设提供时序参考。其中一种振荡器是 6 MHz 自由运行振荡器（FRO6M），它通常被用作默认时钟源。 本文提供了以下内容的全面指南： 选择和配置备用时钟源 选择替代时钟源 KW45/MCXW71 微控制器提供了多种替代方案，包括 192 MHz 自由运行振荡器（FRO192）、RF_OSC 和外部晶体振荡器。每种方案都有其自身优势：FRO192 稳定且可用，而外部振荡器则能提供长期精度。时钟源的选择应基于外设的时序要求、功耗限制以及当前工作模式下时钟的可用性。 重新配置外设时钟源 使用 SDK 的时钟管理 API，在 KW45 上重新配置外设的时钟源非常简单。CLOCK_SetIpSrc() 函数允许开发人员为特定外设分配新的时钟源。 示例：将 UART 时钟源从 FRO6M 更改为其他时钟源。 UART外设连接到FRO6M uint32_t uartClkSrcFreq = BOARD_DEBUG_UART_CLK_FREQ; CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro6M); DbgConsole_Init(BOARD_DEBUG_UART_INSTANCE, BOARD_DEBUG_UART_BAUDRATE, BOARD_DEBUG_UART_TYPE, uartClkSrcFreq); 例如，要将 UART 从 FRO6M 切换到 FRO-192M，可以使用以下代码： //Replace kCLOCK_Lpuart1 for your peripheral for clicking CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro192M); 同样，在上述示例中，我们必须将 uint32_t uartClkSrcFreq 变量设置为与 FRO192M 相对应的正确频率值，因为 FRO192M 被用作时钟源，但同样的逻辑也适用于该外设的任何其他时钟源。 模块的其他时钟更改可按以下示例操作： //Change clock source for LPIT 0 module from 6M FRO to other clocksources /* Iniital source for the LPIT module */ CLOCK_SetIpSrc(kCLOCK_Lpit0, kCLOCK_IpSrcFro6M); /* Set the new source for the LPIT 0 module */ CLOCK_SetIpSrc(kCLOCK_Lpit0, kCLOCK_IpSrcFro192M); /* Set the corresponding divider for application, need to be decided by developer*/ CLOCK_SetIpSrcDiv(kCLOCK_Lpit0, 15U); /* Set the source for the TPM 0 module */ CLOCK_SetIpSrc(kCLOCK_Tpm0, kCLOCK_IpSrcFro6M); /* Set the source for the TPM 0 module */ CLOCK_SetIpSrc(kCLOCK_Tpm0, kCLOCK_IpSrcFro192M); /* Set the corresponding divider for application, need to be decided by developer*/ CLOCK_SetIpSrcDiv(kCLOCK_Tpm0, 3U); //Change clock source for Luart 1 module from 6M FRO to other clocksources CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro6M); /* Set the source for the Lpuart 1 module */ CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro192M); uartClkSrcFreq = CLOCK_GetIpFreq(kCLOCK_Lpuart1); DbgConsole_Init(BOARD_DEBUG_UART_INSTANCE, BOARD_DEBUG_UART_BAUDRATE, BOARD_DEBUG_UART_TYPE, uartClkSrcFreq); 更改时钟源后，重新初始化外设非常重要，以确保波特率、预分频器或采样间隔等时序参数被正确重新计算。这一步骤确保外设在新时钟配置下可靠运行。 以上是一些更改部分外设时钟源的示例，但同样的逻辑可应用于任何其他模块或外设，这些示例取自 SDK 2.16.00，用以说明如何将配置了时钟源的模块切换到另一个时钟源。

S32G_M7_STBYFULLBOOT_A53STR this doc and project explain how to integrate S32G M stby demo and Linux STR demo to one demo to achieve the fast boot, chinese version: 本文说明如何在S32G2 RDB2板上搭建 一个M7 MCAL Standby Fullboot GPIO resume Demo加A53 Suspend to RAM的Demo，主要的 应用场景是电动汽车的快速启动。 G3与更新版本BSP的支持情况与此类 似，不再另外说明，客户可以自行参考开发。 请注意本文为培训和辅助文档，本文不是 官方文档的替代，请一切以官方文档为准。 目录 1 参考资料说明与声明 .................................................. 2 2 STBY+STR的硬件注意点 .......................................... 3 3 修改M7 MCAL Standby Demo代码 ............................ 5 3.1 Clock相关修改 ........................................................ 5 3.2 MCU相关修改 ......................................................... 5 3.3 UART Clock相关修改 ............................................. 7 3.4 Port相关修改 .......................................................... 7 3.5 I2C相关修改 ........................................................... 7 3.6 实现M核进入STDY状态等待功能 ........................... 8 3.7 Main函数的修改 ..................................................... 8 4 修改Bootloader工程来支持同时Boot M/A核Demo ... 10 4.1 I2C Clock相关修改 ............................................... 10 4.2 Port相关修改 ........................................................ 11 4.3 其它修改 ............................................................... 12 5 修改A53 Linux代码 .................................................. 13 6 Demo 运行测试 ........................................................ 13 6.1 硬件连接 ............................................................... 13 6.2 镜像烧写 ............................................................... 13 6.3 Demo运行 ............................................................ 14 7 工程发布包............................................................... 15 8 未来开发建议 ........................................................... 17 8.1 M/A核同步机制 ..................................................... 17 8.2 功能安全与信息安全 ............................................. 17 9 遗留问题 .................................................................. 17 9.1 IPCF STR支持 ...................................................... 18 9.2 PFE Slave STR支持 ............................................. 18 注意以下说明与声明： 说明： 汽车网关有快速启动要求，而电动车因为驻车时有更大的电池提供待机电源，所以希望是使 用Linux 的suspend to ram 的功能来实现Linux 的快速启动，而在S32G 上则需要考虑将M 核的 Standby 功能 与A 核的STR 功能 结合起来，目前可用的资源包括：  从BSP32 起支持ATF，可以支持Linux 端的STR 功能，文档《S32G_Linux_STR_V1-*.pdf》 (John.Li)说明linux STR 的原理和与M7 Standby Demo 结合时所需要的修改。  NXP 的M7 内部standby demo，可以支持M 核端的standby 功能，支持full boot 和standby ram boot。文档《S32G_Standby_Demo_V4-*.pdf》(John.Li)有详细说明，本文使用MCAL full boot+GPIO resume Demo。  本Demo 与本文主要说明如何将这两个Demo 结合起来，形成一个整体的Demo。  由于需要Boot M 核加A 核，所以也需要Bootloader 工程的支持，文档 《S32G_Bootloader_V1-*.pdf》(John.Li)说明了如何创建一个MCAL sample 加Linux 的 Bootloader 工程。 声明： 请注意：  M7 standby demo 本来为NXP 内部Demo，不保证运行质量。而Linux 本身也是reference software。  Linux STR 本身会引入比较复杂的电源管理切换，也会引起系统级的不稳定性。  本文所说的方法也是实验性质，不保证运行质量。 所以客户应该谨慎决定其产品功能并自行保证其产品质量，本文及本Demo 仅为Demo 性质。 This article explains how to build a demo of M7 MCAL Standby Fullboot GPIO resume Demo plus A53 Suspend to RAM on the S32G2 RDB2 board. The main application scenario is the quick start of electric vehicles. The support situation of G3 and the newer version of BSP is similar to this, no further explanation is given, customers can refer to it for development by themselves.  Please note that this article is a training and auxiliary document. This article is not a substitute for the official document. Please refer to the official document. Contents 1    Reference materials and statement 2 2    STBY+STR hardware checkpoints. 3 3    Modified M7 MCAL Standby Demo codes. 5 3.1  Clock modification. 5 3.2  MCU related modification. 6 3.3  UART Clock related modificaiton. 7 3.4  Port related modification. 8 3.5  I2C related modification. 8 3.6  Enable the waiting function of M core entering STDY. 9 3.7  Main function modification. 9 4    Modify the Bootloader project to support simultaneous M/A core demo  11 4.1  I2C Clock related modification. 11 4.2  Port related modifcaiton. 11 4.3  Others modificaiton. 13 5    Modify A53 Linux codes. 14 6    Demo running and testing. 14 6.1  Hardware link. 14 6.2  Image burning. 14 6.3  Demo running. 15 7    Project release package. 16 8    Suggestion for the future development 17 8.1  M/A core sync mechanism.. 17 8.2  Function safety and Information security. 17 9    Remaining issues. 18 9.1  IPCF STR support 18 9.2  PFE Slave STR support 18 as need refer: S32G_Linux STR This doc explain S32G Linux STR details and modify to integrate with M stdy demo https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Linux-STR/ta-p/1652680 S32G Standby Demo the project build a new Mcal standby demo and explain its details https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-M-kernel-Standby-demo-and-how-to-porting-to-Mcal/ta-p/1556313 S32G Boot customization doc how to run bootloader to run mcal&linux https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Bootloader-Customzition/ta-p/1519838 Automotive Re: S32G_M7_STBYFULLBOOT_A53STR Update my issue state: Modify as following, use EB to build can success but boot failed. No console output. - bootloader >> MCU >> MCU >> General >> Config Variant => VariantPreCompile - Bootloader >> SysDal >> SysDal >> General >> SysDalGeneral 的 Enable MCU from sysdal = unchecked Hi John, Did you meet the build error?  Thanks. Re: S32G_M7_STBYFULLBOOT_A53STR Hi John, We want to open ivt tool but met some troubles: Does it look like software version mismatch? Another trouble is build failed: May I lose some steps? Thanks. Allen

AR1335 カメラセンサドライバ @kerryzhou このカメラ センサ AR1335 を NXP MCU で使用したことがあるかどうかお聞きしたいのですが。もしそうなら、ドライバのソースコードを共有してください。 よろしくお願いいたします。 ファリド Re: AR1335 camera sensor driver こんにちは、ファビオさん。 私はyoctoを使用しています。 最新の ar1335 センサ カーネル ドライバはここにあります: https://github.com/nxp-imx/isp-vvcam/tree/lf-5.15.y_2.0.0/vvcam/v4l2/sensor/ar1335 Yocto を使用する場合は、上記のisp-vvcamに加えてisp-imxも必要です。 このソース コードに興味がある場合は、Ubuntu ホストで bin ファイルをダウンロードして実行することで入手できます。 https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/isp-imx-4.2.2.20.0.bin バージョンをBSPで使用しているものに置き換えます（ここではv20を使用します） 別のセンサ用のドライバを展開する方法の例を次に示します。 https://www.nxp.com/docs/en/application-note/AN13712.pdf Re: AR1335 camera sensor driver こんにちは、ありがとうございます。私はこの分野の初心者なので、質問がおかしくなるかもしれません。Debian または Yocto を使用しましたか?標準ドライバへのリンクを教えていただけますか? Re: AR1335 camera sensor driver こんにちは、ファビオさん。 はい、標準ドライバを使用して実行できました。 これまではHD 1080pの解像度を使用していました。 数日中に4K以上も試してみる予定です。 Re: AR1335 camera sensor driver こんにちは、 カメラAR1335とMx8 plusの接続に成功したかどうかを知りたいです お願いします ファビオ Re: AR1335 camera sensor driver こんにちは、マイケル。 >>このセンサはNXP iMX8M Mini SoCを使用してすでに動作しています 私はこれにとても興味があります。ソースコードとデバイスツリーファイルを提供する事は可能でしょうか？ 私はこれを非常によく似た iMX8M-plus でも動作させようとしています。 ありがとう、MC Re: AR1335 camera sensor driver こんにちは、 michael_partheiさん すでに弊社の社内専門家に確認していただき、新しい投稿で返信させていただきます。 新しい問題が発生した場合は、新しい投稿をフォローしてください。 よろしくお願いいたします。 kerry Re: AR1335 camera sensor driver ありがとう、ケリー！この問題について議論するために新しいトピックを開きました: https://community.nxp.com/t5/i-MX-RT/RT1170-Using-MIPI-CSI-with-grayscale-or-raw-image-sensors/mp/1270310#M14031 Re: AR1335 camera sensor driver こんにちは、 michael_partheiさん 内部 AE の説明によると、これは SDK の問題ではなく、チップ MIPI CSI がサポートできない問題です。 SO、リファレンス・マニュアルにはFUTUREに関連する説明が追加される予定です。 ただし、生データを使用する場合は、mipi-csi ではなくパラレル CSI インターフェースを使用する必要があります。 ご不便をおかけして申し訳ございません。 よろしくお願いいたします。 kerry Re: AR1335 camera sensor driver こんにちは、ケリーさん。 明確にするために：これは、RT1176（正確にはOV9281、データ形式はRAW8）では8ビットモノクログレースケールセンサの使用は不可能だという意味ですか？これはハードウェアの根本的な制限でしょうか、それともFUTURE修正される予定の SDKs の問題でしょうか? 同様の MIPI CSI ペリフェラルを使用していると思われる NXP iMX8M Mini SoC を使用して、このセンサをすでに実行していますが、RT1176 に移植する必要があります。 ベスト、マイケル Re: AR1335 camera sensor driver Jetson nano 用の AR1335 Linux ドライバ: https://www.arducam.com/docs/camera-for-jetson-nano/mipi-camera-modules-for-jetson-nano/driver-installation/ Re: AR1335 camera sensor driver こんにちは、 fmabroukさん 返信が遅くなって本当に申し訳ありません。 内部 AE 応答を取得すると、本当に悲しい話になりますが、MIPI-CSI2 は VIDEO_MUX のバグのために生データをサポートできず、この情報は RT1170 リファレンス・マニュアルに追加されます。 SO、外部 AR1335 がサポートされるように構成できるかどうかを確認してください。RGBですか? 現在、生のデータは 10 ビットですが、回避策はありません。 返信が遅くなってしまい申し訳ございません。ご尽力いただきまして誠にありがとうございます。 よろしくお願いいたします。 kerry Re: AR1335 camera sensor driver フォーラムの他のメンバーまたは NXP チームからの私の問題に対するフィードバック。本当に時間がないので、これを整理する必要があります。CAN助けてください。 Re: AR1335 camera sensor driver @kerryzhou お元気でお過ごしでしょうか？あなたに連絡して、私の問題に関して何か最新情報があるかどうかを確認したいだけです。 ここでも、出力ピクセル データごとに 10 ビットの生データをキャプチャできるように CSI ドライバを構成するための支援が必要です。データをキャプチャした後、独自のソフトウェアを使用してデータを RGB 888 形式に変換できます。 よろしくお願いいたします。 Re: AR1335 camera sensor driver こんにちは、ケリーさん。 もう 1 つお知らせしたいのは、カメラ センサの出力形式は RAW10 (10 ビット) ですが、現在の nXP CSI/カメラ ドライバではこの形式はサポートされていないということです。私が目にしたのは以下のものだけです: /*! @brief ピクセル形式の定義。 */ typedef enum _video_pixel_format { /* RGB */ kVIDEO_PixelFormatXRGB8888 = FSL_VIDEO_FOURCC('X', 'R', '2', '4'), /*!< 32ビットXRGB8888。 */ kVIDEO_PixelFormatRGBX8888 = FSL_VIDEO_FOURCC('R', 'X', '2', '4'), /*!< 32ビットRGBX8888。 */ kVIDEO_PixelFormatXBGR8888 = FSL_VIDEO_FOURCC('X', 'B', '2', '4'), /*!< 32ビットXBGR8888。 */ kVIDEO_PixelFormatBGRX8888 = FSL_VIDEO_FOURCC('B', 'X', '2', '4'), /*!< 32ビットBGRX8888。 */ kVIDEO_PixelFormatRGB888 = FSL_VIDEO_FOURCC('R', 'G', '2', '4'), /*!< 24ビットRGB888。 */ kVIDEO_PixelFormatBGR888 = FSL_VIDEO_FOURCC('B', 'G', '2', '4'), /*!< 24 ビット BGR888。 */ kVIDEO_PixelFormatRGB565 = FSL_VIDEO_FOURCC('R', 'G', '1', '6'), /*!< 16 ビット RGB565。 */ kVIDEO_PixelFormatBGR565 = FSL_VIDEO_FOURCC('B', 'G', '1', '6'), /*!< 16 ビット BGR565。 */ kVIDEO_PixelFormatXRGB1555 = FSL_VIDEO_FOURCC('X', 'R', '1', '5'), /*!< 16 ビット XRGB1555。 */ kVIDEO_PixelFormatRGBX5551 = FSL_VIDEO_FOURCC('R', 'X', '1', '5'), /*!< 16ビットRGBX5551。 */ kVIDEO_PixelFormatXBGR1555 = FSL_VIDEO_FOURCC('X', 'B', '1', '5'), /*!< 16 ビット XBGR1555。 */ kVIDEO_PixelFormatBGRX5551 = FSL_VIDEO_FOURCC('B', 'X', '1', '5'), /*!< 16ビットBGRX5551。 */ kVIDEO_PixelFormatXRGB4444 = FSL_VIDEO_FOURCC('X', 'R', '1', '2'), /*!< 16 ビット XRGB4444。 */ kVIDEO_PixelFormatRGBX4444 = FSL_VIDEO_FOURCC('R', 'X', '1', '2'), /*!< 16ビットRGBX4444。 */ kVIDEO_PixelFormatXBGR4444 = FSL_VIDEO_FOURCC('X', 'B', '1', '2'), /*!< 16ビットXBGR4444。 */ kVIDEO_PixelFormatBGRX4444 = FSL_VIDEO_FOURCC('B', 'X', '1', '2'), /*!< 16ビットBGRX4444。 */ /* YUV */ kVIDEO_PixelFormatYUYV = FSL_VIDEO_FOURCC('Y', 'U', 'Y', 'V'), /*!< YUV422, YUYV。 */ kVIDEO_PixelFormatYVYU = FSL_VIDEO_FOURCC('Y', 'V', 'Y', 'U'), /*!< YUV422, YVYU. */ kVIDEO_PixelFormatUYVY = FSL_VIDEO_FOURCC('U', 'Y', 'V', 'Y'), /*!< YUV422, UYVY。 */ kVIDEO_PixelFormatVYUY = FSL_VIDEO_FOURCC('V', 'Y', 'U', 'Y'), /*!< YUV422, VYUY. */ kVIDEO_PixelFormatXYUV = FSL_VIDEO_FOURCC('X', 'Y', 'U', 'V'), /*!< YUV444, XYUV. */ kVIDEO_PixelFormatXYVU = FSL_VIDEO_FOURCC('X', 'Y', 'V', 'U'), /*!< YUV444, XYVU. */ } ビデオピクセルフォーマットt; アプリケーションコードでRaw10をRGB888に変換できますか？ 参考までにデータシートをいくつか添付しました。 Re: AR1335 camera sensor driver こんにちは、 fmabroukさん 情報をいただきありがとうございます。 しばらくお待ちください。コードの詳細を確認し、社内の CSI エキスパートに確認します。 有益な情報が入りましたら、できるだけ早くお知らせいたします。 もう少しお時間をください、SOありがとうございます！ よろしくお願いいたします。 kerry Re: AR1335 camera sensor driver @kerryzhou @ジンパン カメラ センサがデータをストリーミングしていることをスコープで確認し、コードのデバッグ中に CSI 読み取りレジスタをキャプチャできました。添付のスクリーン ショットを参照してください。ただし、完全なフレーム バッファーの CSI 割り込みを取得できません。これも MIPI CSI を初期化した方法に関係しています。前回の電子メールで述べたイメージ要件に基づいて、これを適切に設定するのに、あなたまたは他の誰かが協力してくれませんか。 乾杯！ Re: AR1335 camera sensor driver @kerryzhou 以下は私が興味を持っている画像パラメータの概要です。 [PLLパラメータ] ; ターゲットVtピクセル周波数: 220 MHz ; 入力クロック周波数: 24 MHz ; ; 実際のVtピクセルクロック: 220 MHz ; 実際のオペレーションピクセルクロック: 110 MHz ; ; pll_multiplier (M値) = 55 ; pre_pll_clk_div (N値) = 2 ; pll_multiplier2 (M2値) = 55 ; pre_pll_clk_div2 (N2値) = 2 ; Fpfd = 12 MHz ; Fvco = 660 MHz ; Fvco2 = 660 MHz ; Vt システム除算器 = 1 ; Vt Pix Divider = 3 ; オペレーションシステム除算器 = 1 ; Op Pix Divider = 6 ; ; [画像パラメータ] ; 要求フレーム数/秒: 30 ; 出力列数: 640 ; 出力行数: 480 ; Y合計を使用する: チェックなし ; Xのみのビニング: チェックなし ; スキップを許可する: チェックあり ; ブランキング計算: HB Max、次にVB ; ; 最大フレーム時間: 33.3333 ミリ秒 ; 最大フレームクロック: 7333333.3時計 ; 読み出しモード: 1、YSum: いいえ、XBin: いいえ ; 水平クロック: 640 アクティブ + 1688 ブランク = 合計 2328 ; 垂直行: 480 アクティブ + 2674 空白 = 合計 3154 ; 出力列数: 640 ; 出力行数: 480 ; 視野角: 640 ; 視野行数: 480 ; 実際のフレームクロック: 7342512 クロック ; 行時間: 10.582 マイクロ秒 / 2328 クロック ; 積分時間: 33 ミリ秒。 ; フレーム時間: 33.375055 ミリ秒 ; 最大フレームレート: 191.739fps ; フレームレート: 29.962 fps Re: AR1335 camera sensor driver @kerryzhou 私はimx RT1170でmipi CSI2デモ コードを使用して、AR1335から480x640の画像を取得しています。 このカメラセンサの出力形式は 10 ビットであることがわかりました。必要なイメージをキャプチャできるようにするには、CSI ドライバでどのような変更を行う必要がありますか。 メーカーのツールを使用して構成ファイルを生成しましたが、CSI ドライバが誤って構成されているため、イメージを取得できません。 AR1335 からイメージをキャプチャするためにデモ コード CSI ドライバで何を変更する必要があるかアドバイスをお願いします。 敬具 Re: AR1335 camera sensor driver こんにちは、 fmabroukさん 今のところ、別のカメラセンサをインポートすることに関する直接的なドキュメントはまだありません。 私の知る限り、カメラ センサには、構成を行ってコードを生成できる構成ツールも必要です。AR1335には、すでにNXPについての関連ドライバがありますか？ 内部的にも確認しましたが、今まで AR1335 RT 関連のドライバは見つかりませんでした。 よろしくお願いいたします。 kerry Re: AR1335 camera sensor driver @kerryzhou 私は、imX RT1170 開発ボードで OV5640 の代わりにこのカメラセンサ AR1335 を使用しています。AR1335 は 10 ビットの画像のみを送信します。OV5640 ピクセル データ バスは 16 ビットだと思います。 このセンサで画像を取得できるように、NXP SDK に付属の mipi csi デモ コードを変更するにはどうすればよいですか? このデモ コードに別のカメラ センサをインポートするプロセスをガイドするドキュメントがあればいいと思います。 よろしくお願いします！   Re: AR1335 camera sensor driver こんにちは、 fmabroukさん あなたが言及した時計については、RT1170 リファレンス・マニュアルから見つけることができます。 お役に立てれば幸いです! よろしくお願いいたします。 kerry Re: AR1335 camera sensor driver @kerryzhou @ジンパン 上記に投稿した質問の他に、ピクセル クロックを 80MHz に設定する必要があります。imx RT1170 の CSI2 mipi デモ コードでどのレジスタを変更する必要がありますか? ご回答をお待ちしています。 Re: AR1335 camera sensor driver @ジンパン @kerryzhou 私はまだ AR1335 カメラ ドライバを ImX RT1170 CCI2 mipi デモ コードに移植しようとしています。 CS2 mipi コードで次のクロックを見つけました: CLOCK_SetRootClock(kCLOCK_Root_Csi2、&csi2ClockConfig); CLOCK_SetRootClock(kCLOCK_Root_Csi2_Esc、&csi2EscClockConfig); CLOCK_SetRootClock(kCLOCK_Root_Csi2_Ui、&csi2UiClockConfig); これらの時計の用途を説明できる人はいますか? ご回答をお待ちしています。 Re: AR1335 camera sensor driver こんにちは、 fmabroukさん 今まで、 AR1335 に関する RT チップ ドライバは見つかりませんでした。内部的に検索しても見つかりませんでした。 インターネットで検索すれば、サードパーティ製の製品に AR1335 ドライバがあるかもしれません。 Nxp の公式側では見つけられませんでしたが、今までのところ、RT は主に MT9M114 または OV7725 カメラ モジュールを使用しています。 ご不便をおかけして申し訳ございませんが、ご理解のほどよろしくお願いいたします。 よろしくお願いいたします。 kerry

基于 Layerscape 平台上 OpenCV 神经网络框架的 EIQ 软件应用程序 NXP 为 QorIQ Layerscape 应用处理器创建了 eIQ 机器学习软件，这是一套 ML 工具，允许在 QorIQ Layerscape 系列设备上开发和部署 ML 应用程序。 OpenCV 是一个开源计算机视觉库。它为神经网络推理（DNN模块）和标准机器学习算法（ML模块）提供了统一的解决方案。它包含许多计算机视觉功能，可以更轻松地在短时间内构建复杂的机器学习应用程序，而无需依赖其他库。 本文档介绍了基于 OpenCV DNN 框架开发的 YOLO 对象检测、图像分割、图像着色、图像分类、人体姿势估计和文本检测应用程序。