如何触发 S32K3 上的不同复位事件以进行验证 为了验证目的，是否有推荐的方法来触发评估板上的每个复位源？ 例如： 调试目标 SW_DEST HSE_SNVS_RST ...... 我想知道与 DES 和 FES 寄存器对应的所有位。 Re: How to trigger different reset events on S32K3 for verification 这是一个有点棘手的问题。对于这些重置事件，没有直接的注入机制，我们也没有任何专用的测试代码或脚本可以提供——除了涵盖 FCCU 部分的 SAF/eMCEM API。也就是说，我研究了各种可能的选择，以下是初步设想的、在实践中应该可行的几种方法。 S32K3 上的复位事件根据其触发验证的方式分为两类——软件注入和仅硬件——分别分布在两个 MC_RGM 状态寄存器 DES 和 FES 上。 软件注入式复位可以直接从代码中触发： 直接软件命令——写入 MC_ME.MODE_CONF，参数为 DEST_RST 或 FUNC_RST，并触发 MODE_UPD，分别映射到 DES[SW_DEST] 或 FES[SW_FUNC]。 看门狗过期 — 停止 SWT 服务循环，在每次超时时触发功能重置，递增 FREC；一旦 FREC 达到 FRET，下一次重置将升级为破坏性重置，并设置 DES[MC_RGM_FRE] FCCU故障注入——使用eMcem_InjectFault()或FNCFC伪故障寄存器，根据NCF通道配置触发功能性或破坏性反应；注入不在已配置NCF集中的故障会触发FOSU破坏性复位路径。 CMU阈值操作——将CMU_FC_x.LTCR/HTCR写入实际运行频率之外，以产生CMU频率故障复位，其反应类型（功能性或破坏性）通过DCM配置控制。 纯硬件重置需要物理刺激，没有软件注入途径： STCU_URF 要求在实时 LBIST 或 MBIST 序列期间发生 PLL 失锁。 HSE_TMPR_RST 和 HSE_SNVS_RST 是安全篡改事件——有意设计为无法通过软件注入，因为它们保护加密材料。 FXOSC_FAIL、PLL_LOL 和 低压检测 标志表示硬件层面的晶振、PLL 分频器或电源轨存在故障。 Re: How to trigger different reset events on S32K3 for verification 嗨，大卫： 好的。谢谢你！ 我们将进行全面调查。

IMX8ulp 中的猎鹰模式启动问题 大家好， 我在以 Falcon 模式 启动主板时遇到问题 。 我将meta-imx-fastboot层克隆到我的 Yocto 源代码目录中。 在构建过程中，我遇到了一些与 imx-boot 和设备树 相关的问题 ，因为我使用的是需要加载到我们开发板上的自定义 DTS。为了解决这个问题，我在 machine.conf 文件中配置了 Falcon 模式参数， 如下所示： FALCON_KERNEL_DEVICETREE = "imx8ulp-custom" 完成此配置后，我能够按照 Falcon 模式步骤中所述生成imx8ulp_no_uboot加载器。 我正在使用 fitImage KERNEL_IMAGETYPE = "fitImage" KERNEL_CLASSES:append = " kernel-fitimage" IMAGE_BOOT_FILES = "fitImage" 然后我使用以下命令对开发板进行了烧录： sudo uuu -b emmc_all *.wic sudo uuu -b emmc 刷写固件后，启动开发板时，启动失败并出现以下错误： U-Boot SPL 2025.04-gb9f705c183f0（2025年6月4日 - 09:48:20 +0000） 正常启动 ELE固件版本2.0.2-85b63cb9 upower_apd_inst_isr：入口 upower_init: soc_id=48 upower_init：版本：11.11.13 upower_init：启动 uPower RAM 服务 user_upwr_rdy_callb: soc=b user_upwr_rdy_callb：内存版本：12.18 打开开关…… 打开开关，没问题 唤醒记忆…… 打开记忆功能 清除DDR数据保留... 清除DDR数据保留正常 SEC0：RNG 实例化 尝试从 MMC1 启动 设备 0 上的分区 1 无效 spl_register_fat_device：fat 设备寄存器错误 -1 设备 0 上的分区 1 无效 spl_register_fat_device：fat 设备寄存器错误 -1 spl_load_image_fat：读取镜像 u-boot-atf-container.img 时出错，错误代码 -1 错误：-2 SPL：无法从所有引导设备启动 # ## ERROR ## # 请 RESET 该板 ### 请问您能否帮我了解一下这个错误的原因，并建议一下如何解决 Falcon 模式启动问题？ Re: Falcon Mode Boot Issue in IMX8ulp 你好@elgin_1950 如果将 DTS 内容和 defconfig 同步到 Falcon 默认支持的 EVK 代码，是否还会出现任何问题？ 此致， 志明

S32 Design Studio for Power Architecture、バージョン2.1ライセンス S32 Design Studio for Power Architecture バージョン2.1のライセンスが切れています。更新や新しい申請を手伝ってもらえますか? F379-CD5D-DAD1-7708 Re: S32 Design Studio for Power Architecture, version 2.1 license こんにちは、 お客様のS32DSライセンスが延長されました。以前のコードを使用して、S32DSを再度有効化してください。 Re: S32 Design Studio for Power Architecture, version 2.1 license こんにちは、 更新を申請しました。 よろしくお願いいたします。 ピーター

iMX8qm Boot Core A72_0 Hello NXP Forum, on iMX8qm, can we have the bootup done from A72 core? Does SCUFW permit that. Thanks Re: iMX8qm Boot Core A72_0 Proceed with the existing flash_ca72 target first; do not replace u-boot-atf.bin with u-boot-atf-a72.bin unless you are intentionally using the cockpit / multi-AP image flow. The evidence points to this distinction: flash_ca72 is described as the same basic boot image as the normal A-core boot target, but loaded to the A72 instead of the A53. u-boot-atf.bin is the combined ATF + U-Boot image: bl31.bin plus u-boot.bin / u-boot-hash.bin . u-boot-atf-a72.bin appears in the flash_cockpit target, where the image contains two AP payloads : one for A53 and a separate one for A72: -ap u-boot-atf.bin a53 0x80000000 ... -ap u-boot-atf-a72.bin a72 0xC0000000 ... . So the important selector is not only the filename; it is the imx-mkimage -ap ... a72 ... argument in the target. For a single A72 boot image, flash_ca72 using u-boot-atf.bin is consistent with the documented intent: the payload is loaded to A72 by the target rule, even if the filename is not suffixed -a72 . Recommended path: Build the standard A72-only image using the existing target: make SOC=iMX8QM flash_ca72 Use the CA72 device tree / configuration on the Linux side. NXP documentation notes that the i.MX8QM MEK CA72 DTB supports the two Cortex-A72 cores only and requires the special boot image built with flash_ca72 . Reserve u-boot-atf-a72.bin for flows that explicitly package a second A72 AP image, such as flash_cockpit , unless your BSP’s soc.mak comments or release notes say otherwise. Validate at boot that the image is actually entering the A72 path: check the imx-mkimage command emitted by make V=1 SOC=iMX8QM flash_ca72 or inspect iMX8QM/soc.mak and confirm the AP line uses a72 . Takeaway: treat the current flash_ca72 reference to u-boot-atf.bin as intentional; u-boot-atf-a72.bin is for the separate A72 payload used in cockpit/multi-partition style images, not automatically the replacement for flash_ca72 . Re: iMX8qm Boot Core A72_0 There is a small point we would like to clarify/validate: the `flash_ca72` target currently references `u-boot-atf.bin`, while a separate `u-boot-atf-a72.bin` is also available in the same configuration. How do we proceed Re: iMX8qm Boot Core A72_0 Yes — on i.MX8QM, the application-processor boot image can be targeted to the Cortex-A72 instead of the Cortex-A53, and SCFW permits that flow. NXP’s imx-mkimage has a flash_ca72 target described as the A72 variant of the normal A53 boot image, intended to bring up the A72 as early as possible for boot-time optimization . The important distinction is: First code after reset: not the A72. The device boot flow still starts through ROM/SCU/SCFW. AP-side bootloader / OS bring-up: yes, this can be done on the A72. SCFW initializes DDR, loads Cortex-A images, then boots the cores and sets their start addresses. Configuration mechanism: the boot container can specify an AP image for a72 , e.g. examples show -ap ... a72 ... in imx-mkimage usage. So the answer is: SCFW does allow booting the AP software path from A72, but A72 is not the reset/ROM boot master; it is started by SCFW according to the boot container configuration. Re: iMX8qm Boot Core A72_0 Hello, I have followed the following steps to build bootloader, but the bootloader fails without any logs. Could you please validate attached steps. Thanks mkdir Scarthgap_New cd Scarthgap_New   1. Get the Security Controller Binaries mkdir SECO cd SECO wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-5.9.4.1-0333596.bin chmod +x imx-seco-5.9.4.1-0333596.bin ./imx-seco-5.9.4.1-0333596.bin   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$ ls -al total 976 drwxrwxr-x 2 mkashyap mkashyap   4096 Aug 26 22:21 . drwxrwxr-x 3 mkashyap mkashyap   4096 Aug 26 22:21 .. -rw-r--r-- 1 mkashyap mkashyap    194 Jul 29  2024 commit-id.txt -rw-r--r-- 1 mkashyap mkashyap 163840 Jul 29  2024 mx8dxla1-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap 163840 Jul 29  2024 mx8dxlb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  76944 Jul 29  2024 mx8qmb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  71312 Jul 29  2024 mx8qxb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  78408 Jul 29  2024 mx8qxc0-ahab-container.img -rwxr-xr-x 1 mkashyap mkashyap 423875 Jul 29  2024 SECO_FW_release_note.pdf mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$   we use mx8qmb0-ahab-container.img   cd ../../../..   2. Download and build ATF mkdir ATF cd ATF git clone https://github.com/varigit/imx-atf -b lf_v2.10_6.6.52-2.2.0_var01   cd imx-atf source /opt/fsl-imx-xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux unset LDFLAGS make PLAT=imx8qm bl31   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/ATF/imx-atf/build/imx8qm/release$ ls -al total 76 drwxrwxr-x 7 mkashyap mkashyap  4096 Aug 26 22:37 . drwxrwxr-x 3 mkashyap mkashyap  4096 Aug 26 22:36 .. drwxrwxr-x 3 mkashyap mkashyap  4096 Aug 26 22:37 bl31 -rwxrwxr-x 1 mkashyap mkashyap 45213 Aug 26 22:37 bl31.bin drwxrwxr-x 2 mkashyap mkashyap  4096 Aug 26 22:37 lib drwxrwxr-x 2 mkashyap mkashyap  4096 Aug 26 22:37 libc drwxrwxr-x 2 mkashyap mkashyap  4096 Aug 26 22:37 libwrapper drwxrwxr-x 2 mkashyap mkashyap  4096 Aug 26 22:37 romlib   cd ../../../../../   3. Download and build SCFW    mkdir SCFW    cd SCFW        wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz    sudo tar xf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz -C ./opt        git clone https://github.com/varigit/imx-sc-firmware.git -b 1.17.0    cd imx-sc-firmware/src/scfw_export_mx8qm_b0        export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt    make clean-qm    make qm R=B0 B=var_som V=1        mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0$ ls -al    total 3384    drwxrwxr-x 11 mkashyap mkashyap    4096 Aug 26 22:47 .    drwxrwxr-x  6 mkashyap mkashyap    4096 Aug 26 22:47 ..    drwxrwxr-x  3 mkashyap mkashyap    4096 Aug 26 22:47 board    drwxrwxr-x  3 mkashyap mkashyap    4096 Aug 26 22:44 devices    drwxrwxr-x 25 mkashyap mkashyap    4096 Aug 26 22:47 drivers    drwxrwxr-x  2 mkashyap mkashyap    4096 Aug 26 22:44 main    -rwxrwxr-x  1 mkashyap mkashyap  184448 Aug 26 22:47 scfw_tcm.bin    -rwxrwxr-x  1 mkashyap mkashyap 2787784 Aug 26 22:47 scfw_tcm.elf    -rw-rw-r--  1 mkashyap mkashyap  513123 Aug 26 22:47 scfw_tcm.map    drwxrwxr-x  4 mkashyap mkashyap    4096 Aug 26 22:44 soc    drwxrwxr-x 26 mkashyap mkashyap    4096 Aug 26 22:44 ss    drwxrwxr-x  9 mkashyap mkashyap    4096 Aug 26 22:47 svc    drwxrwxr-x 10 mkashyap mkashyap    4096 Aug 26 22:44 test    drwxrwxr-x  2 mkashyap mkashyap    4096 Aug 26 22:44 utilities        cd ../../../../../     4. Build u-boot    mkdir u-boot    cd u-boot        git clone https://github.com/varigit/uboot-imx.git -b lf_v2024.04_6.6.52-2.2.0_var01    cd uboot-imx        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./mx8qm-ahab-container.img    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./mx8qm-mek-scfw-tcm.bin    make mrproper    make imx8qm_var_som_defconfig    make -j8        cd ../../     5. Make Image     mkdir MkImage    cd MkImage        git clone https://github.com/varigit/imx-mkimage -b lf-6.6.52_2.2.0_var01    cd imx-mkimage        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/spl/u-boot-spl.bin ./iMX8QM/    cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/        make SOC=iMX8QM flash_ca72        cd iMX8QM    make -f soc.mak SOC=iMX8QM MKIMG=../mkimage_imx8 PAD_IMAGE=./pad_image.sh flash_ca72        mkashyap@cse-dev02:~/iMX8/Scarthgap_New/MkImage/imx-mkimage/iMX8QM$ ls -al    total 6792    drwxrwxr-x  3 mkashyap mkashyap    4096 Aug 26 23:08 .    drwxrwxr-x 13 mkashyap mkashyap    4096 Aug 26 23:06 ..    -rwxrwxr-x  1 mkashyap mkashyap   45213 Aug 26 23:06 bl31.bin    -rwxrwxr-x  1 mkashyap mkashyap    2564 Aug 26 22:59 expand_c_define.sh    -rw-rw-r--  1 mkashyap mkashyap 1895424 Aug 26 23:08 flash.bin    -rw-rw-r--  1 mkashyap mkashyap       9 Aug 26 23:06 head.hash    -rwxrwxr-x  1 mkashyap mkashyap    2078 Aug 26 22:59 mkimage_fit_atf.sh    -rw-r--r--  1 mkashyap mkashyap   76944 Aug 26 23:02 mx8qmb0-ahab-container.img    -rwxrwxr-x  1 mkashyap mkashyap  184448 Aug 26 23:03 scfw_tcm.bin    drwxrwxr-x  2 mkashyap mkashyap    4096 Aug 26 22:59 scripts    -rwxrwxr-x  1 mkashyap mkashyap   13271 Aug 26 22:59 soc.mak    -rwxrwxr-x  1 mkashyap mkashyap 1631521 Aug 26 23:06 u-boot-atf.bin    -rw-rw-r--  1 mkashyap mkashyap 1500440 Aug 26 23:04 u-boot.bin    -rw-rw-r--  1 mkashyap mkashyap 1500449 Aug 26 23:06 u-boot-hash.bin    -rw-rw-r--  1 mkashyap mkashyap  139387 Aug 26 23:04 u-boot-spl.bin     The generated flash.bin was used as an bootloader image Re: iMX8qm Boot Core A72_0 For your specific procedure, the important point is this: make SOC=iMX8QM flash_ca72 is the correct target conceptually if your intent is to load the bootloader to the A72 instead of the A53 . NXP community guidance describes flash_ca72 as similar to the basic flash_b0 image, but loaded to the A72 rather than the A53 . The “no logs” symptom does not automatically mean SCFW rejected A72 boot . A known gotcha is that A53 and A72 do not use the same log terminal , so if you monitor the usual A-core/A53 UART you may see nothing even though the A72 image is running or failing later on a different console path. Validation of your steps: Area Assessment SECO container mx8qmb0-ahab-container.img is the right class of container for i.MX8QM B0. ATF make PLAT=imx8qm bl31 is reasonable for i.MX8QM. SCFW Building make qm R=B0 B=var_som V=1 is consistent with an i.MX8QM B0 Variscite target. U-Boot imx8qm_var_som_defconfig is the key item to confirm: it must be compatible with the A72 boot path and console configuration. mkimage target flash_ca72 is the right target only for A72 boot. For normal Linux BSP boot, the documented i.MX8QM command is make SOC=iMX8QM flash . SPL copy u-boot-spl.bin is likely irrelevant for flash_ca72 ; that target is not the SPL-based flow. Duplicate image build Running both top-level make SOC=iMX8QM flash_ca72 and then manually running make -f soc.mak ... flash_ca72 is unnecessary. Use one clean top-level command. I would correct/clean the image-generation part to: cd ~/iMX8/Scarthgap_New/MkImage/imx-mkimage cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/ cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/ cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/ cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/ make clean make SOC=iMX8QM flash_ca72 Then use: iMX8QM/flash.bin Also fix/check this SCFW path: export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt You extracted into ./opt , but exported .../SCFW/Opt . Linux paths are case-sensitive. Since you did produce scfw_tcm.bin , your actual shell may have had a valid tool path, but this line should be verified. Recommended debug sequence: First build and boot the standard image: make SOC=iMX8QM flash This checks that SECO + SCFW + ATF + U-Boot + board DDR/console are basically correct. The Linux User’s Guide documents this standard i.MX8QM flash.bin generation path. Then rebuild with: make SOC=iMX8QM flash_ca72 Monitor the A72 console/UART , not only the normal A53 console. The A53 and A72 log terminals differ. If still silent, compare the generated flash.bin size/layout between flash and flash_ca72 , and confirm that the Variscite U-Boot config actually enables the console used by the A72 boot target. So the direct answer is: SCFW does permit starting the Cortex-A side on A72 through the flash_ca72 image flow, but SCFW still owns the initial boot orchestration. Your procedure is mostly valid for A72 boot, but remove the duplicate soc.mak invocation, verify the SCFW tool path, and most importantly check the A72 UART/console. Takeaway: A72 boot on i.MX8QM is supported via flash_ca72 ; a silent boot is more likely an image/config/console issue than SCFW simply refusing to start A72. Re: iMX8qm Boot Core A72_0 Where can we get SCFW reference manual or design manual to make modification to SCFW firmware Re: iMX8qm Boot Core A72_0 You can start here: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101/ta-p/1124236 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101-Getting-started/ta-p/1121153 The SCFW reference/porting documentation is supplied inside the NXP SCFW Porting Kit , rather than as a separate public reference manual. Download the kit from the NXP i.MX Software and Development page. Select the release corresponding to your i.MX BSP; NXP requires the matching porting kit to maintain compatibility with its supplied binaries. Accept the license and run the included .bin installer. Look under: doc/pdf/sc_fw_port.pdf — detailed SCFW Porting Guide doc/pdf/ — SCFW API User Guide, release notes, and related documentation src/ — SoC-specific SCFW export archives The kit contains a mixture of source and object code. Board-dependent customization is performed in the exported board sources—typically under platform/board/mx8 _ / , including files such as board.c ; much of the core SCFW remains object-only and cannot be modified through the public kit. The general i.MX Porting Guide, UG10165 , also has a “Porting System Controller Firmware” chapter and explains integration with the BSP and meta-imx-scfw.

iMX8qm ブートコア A72_0 こんにちは、NXPフォーラムの皆様、 iMX8qmで、A72コアから起動できますか?SCUFWはそれを許可していますか? よろしくお願いします。 Re: iMX8qm Boot Core A72_0 まず既存の flash_ca72 ターゲットで処理を進めてください。u-boot-atf.bin は置き換えないでください。u-boot-atf-a72.bin を使用コックピット/マルチAPイメージフローを意図的に使用しない限り。 証拠はこの違いを示している。 flash_ca72は、通常のAコアブートターゲットと同じ基本ブートイメージですが、A53ではなくA72にロードされるものとして説明されています。 u-boot-atf.bin は、ATF と U-Boot を組み合わせたイメージです: bl31.bin加えて u-boot.bin/ u-boot-hash.bin . u-boot-atf-a72.binflash_cockpitターゲットに表示され、イメージには2つのAPペイロードが含まれています。1つはA53用、もう1つはA72用です。 -ap u-boot-atf.bin a53 0x80000000 ... -ap u-boot-atf-a72.bin a72 0xC0000000 ... 。 したがって、重要なセレクタは単なるファイル名ではありません。それはIMX-MKIMAGE -APです...A72 ...ターゲットの議論。単一の A72 ブート イメージの場合、u-boot-atf.bin を使用する flash_ca72 は、文書化された意図と一致しています。ファイル名に -a72 が付加されていなくても、ターゲット ルールによってペイロードが A72 にロードされます。 推奨パス： 既存のターゲットを使用して、標準のA72専用イメージを作成します。 SOC=iMX8QM flash_ca72 を作成します Linux側ではCA72デバイスツリー/設定を使いましょう。NXPのドキュメントによると、i.MX8QM MEK CA72 DTBは2つのCortex-A72コアのみをサポートし、flash_ca72で構築された特別なブートイメージが必要です。 u-boot-atf-a72.bin を予約するflash_cockpitのように、2つ目のA72 APイメージを明示的にパッケージ化するフローの場合、ただしBSPのsoc.makが使わない限りコメントやリリースノートには、それとは異なる記載がある。 起動時にイメージが実際にA72パスに入っていることを確認します。make V=1 SOC=iMX8QM flash_ca72によって生成されるimx-mkimageコマンドを確認するか、iMX8QM/soc.makを調べます。AP ラインが a72 を使用していることを確認してください。 要点：現在の flash_ca72 参照を u-boot-atf.bin として扱う。意図的なものです。u-boot-atf-a72.bin は、コックピット/マルチパーティション スタイルのイメージで使用される個別の A72 ペイロード用であり、flash_ca72 の自動的な代替ではありません。 Re: iMX8qm Boot Core A72_0 明確に/検証したい小さな点があります: `flash_ca72` ターゲットは現在 `u-boot-atf.bin` を参照しています。同じ構成で、別の `u-boot-atf-a72.bin` も利用可能です。 どのように進めていくべきか Re: iMX8qm Boot Core A72_0 はい、i.MX8QMではアプリケーションプロセッサのブートイメージをCortex-A53ではなくCortex-A72にターゲットに設定でき、SCFWはその流れを許可しています。NXPのimx-mkimageには、通常のA53ブートイメージのA72バリアントとして説明されているflash_ca72ターゲットがあり、ブート時間の最適化のためにA72をできるだけ早く起動することを目的としています。 重要な違いは次のとおりです。 リセット後の最初のコード： A72ではない。デバイスの起動フローは、引き続きROM/SCU/SCFWを経由して開始されます。 AP側ブートローダー/OSの起動:はい、A72で可能です。SCFWはDDRを初期化し、Cortex-Aイメージを読み込み、コアを起動して開始アドレスを設定します。 設定機構:ブートコンテナはa72用のAPイメージを指定することができます。例:例として、imx-mkimage の使用例で -ap ... a72 ... が示されています。 つまり答えはこうです:SCFWはA72からAPソフトウェアパスを起動できますが、A72はリセットやROMのブートマスターではなく、SCFWによってブートコンテナの設定に従って起動されます。 Re: iMX8qm Boot Core A72_0 あなたの具体的な手順に関して、重要な点は以下のとおりです。 SOC=iMX8QM flash_ca72 を作成します ブートローダーをA53ではなくA72にロードすることが目的であれば、概念的にはこれが正しいターゲットです。NXPコミュニティのガイダンスでは、flash_ca72は基本flash_b0イメージに似ていますが、A53ではなくA72に読み込まれています。 「ログなし」という症状は、必ずしもSCFWがA72ブートを拒否したことを意味するものではありません。よく知られている落とし穴として、A53とA72は同じログターミナルを使っていないため、通常のAコア/A53 UARTを監視しても、A72イメージが別のコンソールパスで動作しているか、後で失敗しても何も見つからないことがあります。 手順の検証： エリア 評価 SECOコンテナ mx8qmb0-ahab-container.img は i.MX8QM B0 に適したコンテナのクラスです。 ATF make PLAT=imx8qm bl31 は i.MX8QM に対して妥当です。 SCFW qm=B0 B=var_som V=1の構築はi.MX8QM B0 Varisciteターゲットと一致します。 U-Boot imx8qm_var_som_defconfig は確認すべき重要な項目です。A72 のブートパスおよびコンソール構成と互換性がある必要があります。 mkimageターゲット flash_ca72 は A72 ブートの場合にのみ適切なターゲットです。通常のLinux BSP起動では、文書化されたi.MX8QMコマンドがmake SOC=iMX8QM flashです。 SPLコピー u-boot-spl.bin は flash_ca72 にはおそらく関係ありません。そのターゲットは SPL ベースのフローではありません。 イメージの複製 トップレベルの make SOC=iMX8QM flash_ca72 を実行してから、手動で make -f soc.mak ... flash_ca72 を実行する必要はありません。簡潔なトップレベルコマンドを1つだけ使用してください。 画像生成部分を以下のように修正・整理します。 cd ~/iMX8/Scarthgap_New/MkImage/imx-mkimage cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/ cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/ cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/ cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/ make clean SOC=iMX8QM flash_ca72 を作成します 次に以下を使用します。 iMX8QM/flash.bin また、このSCFWパスも修正/確認してください。 export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt ./opt に展開しました、ただしエクスポートされた…/SCFW/Opt。Linuxのパスは大文字を区別しています。scfw_tcm.bin を生成したので実際のシェルには有効なツールパスが設定されていたかもしれませんが、この行を確認する必要があります。 推奨デバッグ手順： まず、標準イメージをビルドして起動します。 make SOC=iMX8QM flash これは、SECO + SCFW + ATF + U-Boot + ボードのDDR/コンソールが基本的に正しいことを確認するものです。Linuxユーザーガイドにはこの標準i.MX8QMが記載されていますflash.bin生成パス。 次に、以下のコマンドで再構築します。 SOC=iMX8QM flash_ca72 を作成します 通常のA53コンソールだけでなく、 A72コンソール/UARTも監視してください。A53とA72のログ端末は異なります。 それでも音がしない場合は、生成された flash.bin を比較してください。flash と flash_ca72 間のサイズ/レイアウトを確認し、Variscite U-Boot の設定が実際に A72 ブートターゲットで使用されるコンソールを有効にしていることを確認します。 つまり、直接的な答えはこうです:SCFWはflash_ca72イメージフローを通じてA72のCortex-A側を起動することを許可していますが、SCFWは初期のブートオーケストレーションを所有しています。あなたの手順はA72ブートにはほぼ有効ですが、重複したsoc.mak呼び出しを削除し、SCFWツールパスを確認し、そして何よりもA72のUART/コンソールを確認してください。 要点：i.MX8QM での A72 ブートは flash_ca72 を介してサポートされています。サイレントブートは、SCFW が単に A72 の起動を拒否しているというよりも、イメージ/設定/コンソールの問題である可能性が高いです。 Re: iMX8qm Boot Core A72_0 こんにちは、 以下の手順に従ってブートローダーを構築しましたが、ログも出力されずにブートローダーが失敗します。 添付された手順を検証していただけますか? よろしくお願いします。 mkdir Scarthgap_New cd Scarthgap_New   1. セキュリティ・コントローラバイナリーを入手する mkdir SECO CDセコ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-5.9.4.1-0333596.bin chmod +x imx-seco-5.9.4.1-0333596.bin ./imx-seco-5.9.4.1-0333596.bin   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$ ls -al 合計976 drwxrwxr-x 2 mkashyap mkashyap   4096 8月26日 22:21 . drwxrwxr-x 3 mkashyap mkashyap   4096 8月 26 22:21 .. -rw-r--r-- 1 mkashyap mkashyap    194 7月29日  2024 commit-id.txt -rw-r--r-- 1 mkashyap mkashyap 163840 2024年7月29日 mx8dxla1-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap 163840 2024年7月29日 mx8dxlb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap 76944 Jul 29 2024 mx8qmb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  71312 7月29日  2024 mx8qxb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  78408 7月29日  2024 mx8qxc0-ahab-container.img -rwxr-xr-x 1 mkashyap mkashyap 423875 Jul 29 2024 SECO_FW_release_note.pdf mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$   私たちはmx8qmb0-ahab-container.imgを使用します   CD ../../../..   2. ATFをダウンロードしてビルドする mkdir ATF cd ATF git clone https://github.com/varigit/imx-atf-b lf_v2.10_6.6.52-2.2.0_var01   cd imx-atf 出典 /opt/FSL-IMX-Xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux LDFLAGSを解除します PLAT=imx8qm bl31 を作成します   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/ATF/imx-atf/build/imx8qm/release$ ls -al 合計76 drwxrwxr-x 7 mkashyap mkashyap  4096 8月26日 22:37 . drwxrwxr-x 3 mkashyap mkashyap  4096 8月 26 22:36 .. drwxrwxr-x 3 mkashyap mkashyap  4096 8月26日 22:37 bl31 -rwxrwxr-x 1 mkashyap mkashyap 45213 8月26日 22:37 bl31.bin drwxrwxr-x 2 mkashyap mkashyap 4096 8 月 26 日 22:37 ライブラリ drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:37 libc drwxrwxr-x 2 mkashyap mkashyap 4096 8 月 26 日 22:37 libwrapper drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:37 romlib   CD ../../../../../   3. SCFWをダウンロードしてビルドする    mkdir SCFW    cd SCFW     wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz sudo tar xf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz -C ./opt     git clone https://github.com/varigit/imx-sc-firmware.git -b 1.17.0 cd imx-sc-firmware/src/scfw_export_mx8qm_b0     export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt clean-qm を作成する    qm R=B0 B=var_som V=1 にする     mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0$ ls -al 合計 3384    drwxrwxr-x 11 mkashyap mkashyap    4096 8月26日 22:47 .    drwxrwxr-x  6 mkashyap mkashyap    4096 8月26日 22:47 ..    drwxrwxr-x  3 mkashyap mkashyap    4096 8月26日 22:47 掲示板    drwxrwxr-x  3 mkashyap mkashyap    4096 8月26日 22:44 デバイス    drwxrwxr-x 25 mkashyap mkashyap    4096 Aug 26 22:47 ドライバ    drwxrwxr-x  2 mkashyap mkashyap    4096 8月26日 22:44 main    -rwxrwxr-x 1 mkashyap mkashyap 184448 8 月 26 日 22:47 scfw_tcm.bin -rwxrwxr-x 1 mkashyap mkashyap 2787784 8月26日 22:47 scfw_tcm.elf    -rw-rw-r-- 1 mkashyap mkashyap 513123 8 月 26 日 22:47 scfw_tcm.map    drwxrwxr-x  4 mkashyap mkashyap    4096 8月26日 22:44 soc    drwxrwxr-x 26 mkashyap mkashyap    4096 8月26日 22:44 ss    drwxrwxr-x  9 mkashyap mkashyap    4096 8月26日 22:47 svc    drwxrwxr-x 10 mkashyap mkashyap    4096 8月26日 22:44 test    drwxrwxr-x  2 mkashyap mkashyap    4096 8月26日 22:44 utilities     CD ../../../../../     4. u-bootをビルドする    mkdir u-boot    cd u-boot     git clone https://github.com/varigit/uboot-imx.git -b lf_v2024.04_6.6.52-2.2.0_var01 cd uboot-imx        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./mx8qm-ahab-container.img    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./mx8qm-mek-scfw-tcm.bin mrproper を作る    imx8qm_var_som_defconfig を作成する    make -j8     CD ../../     5. 画像を作成する mkdir MkImage cd MkImage     git clone https://github.com/varigit/imx-mkimage-b lf-6.6.52_2.2.0_var01 cd imx-mkimage        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/spl/u-boot-spl.bin ./iMX8QM/    cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/     SOC=iMX8QM flash_ca72 を作成します     cd iMX8QM    make -f soc.mak SOC=iMX8QM MKIMG=../mkimage_imx8 PAD_IMAGE=./pad_image.sh flash_ca72        mkashyap@cse-dev02:~/iMX8/Scarthgap_New/MkImage/imx-mkimage/iMX8QM$ ls -al 合計6792    drwxrwxr-x  3 mkashyap mkashyap    4096 8月26日 23:08 .    drwxrwxr-x 13 mkashyap mkashyap    4096 8月 26 23:06 ..    -rwxrwxr-x  1 mkashyap mkashyap   45213 8月26日 23:06 bl31.bin    -rwxrwxr-x  1 mkashyap mkashyap    2564 8月 26 22:59 expand_c_define.sh    -rw-rw-r-- 1 mkashyap mkashyap 1895424 8 月 26 日 23:08 flash.bin    -rw-rw-r--  1 mkashyap mkashyap       9 Aug 26 23:06 head.hash    -rwxrwxr-x  1 mkashyap mkashyap    2078 Aug 26 22:59 mkimage_fit_atf.sh    -rw-r--r-- 1 mkashyap mkashyap 76944 8 月 26 日 23:02 mx8qmb0-ahab-container.img    -rwxrwxr-x 1 mkashyap mkashyap 184448 8 月 26 日 23:03 scfw_tcm.bin    drwxrwxr-x  2 mkashyap mkashyap    4096 8月26日 22:59 scripts    -rwxrwxr-x 1 mkashyap mkashyap 13271 8 月 26 日 22:59 soc.mak    -rwxrwxr-x 1 mkashyap mkashyap 1631521 8 月 26 日 23:06 u-boot-atf.bin    -rw-rw-r-- 1 mkashyap mkashyap 1500440 8 月 26 日 23:04 u-boot.bin    -rw-rw-r-- 1 mkashyap mkashyap 1500449 8 月 26 日 23:06 u-boot-hash.bin    -rw-rw-r-- 1 mkashyap mkashyap 139387 8 月 26 日 23:04 u-boot-spl.bin     生成された flash.bin はブートローダーイメージとして使用されました Re: iMX8qm Boot Core A72_0 こちらから始められます: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101/ta-p/1124236 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101-Getting-started/ta-p/1121153 SCFWのリファレンス/ポーティングドキュメントは、独立した公開リファレンスマニュアルではなく、NXP SCFWポーティングキット内に提供されています。 NXPの i.MX ソフトウェア&開発ページからキットをダウンロードしてください。ご使用のi.MX BSPに対応するリリースを選択してください。NXPは、提供するバイナリとの互換性を維持するために、対応するポーティングキットを必要とします。 ライセンスに同意し、付属の.binファイルを実行してください。インストーラ。 以下をご覧ください： doc/pdf/sc_fw_port.pdf — SCFW移植ガイドの詳細 doc/pdf/ — SCFW APIユーザーガイド、リリースノートおよび関連ドキュメント src/ — SoC固有のSCFWエクスポートアーカイブ このキットには、ソースコードとオブジェクトコードが混在して含まれています。基板依存のカスタマイズは、エクスポートされたボードソースで行われます。通常はplatform/board/mx8 _ /の下で、board.cなどのファイルも含まれます;SCFWのコアの多くはオブジェクトのみのままで、パブリックキットを通じて変更することはできません。 UG10165年の一般的な i.MX Porting Guideには「Porting System Controller Firmware」の章があり、BSPやmeta-imx-scfwとの統合について説明しています。 Re: iMX8qm Boot Core A72_0 SCFWファームウェアの修正を行うためのSCFWリファレンスマニュアルや設計マニュアルはどこで入手できますか?

iMX8qm 启动核心 A72_0 大家好，NXP论坛， 在 iMX8qm 上，我们能否从 A72 核心启动？SCUFW 是否支持这样做？ 谢谢！ Re: iMX8qm Boot Core A72_0 请先使用现有的 flash_ca72 目标；不要替换 u-boot-atf.bin 文件。使用 u-boot-atf-a72.bin除非您有意使用驾驶舱/多 AP 图像流。 证据表明存在这种区别： flash_ca72 被描述为与普通 A-core 启动目标相同的基本启动映像，但加载到 A72 而不是 A53。 u-boot-atf.bin 是 ATF 和 U-Boot 的组合镜像：bl31.bin加上 u-boot.bin/ u-boot-hash.bin。 u-boot-atf-a72.bin出现在 flash_cockpit 目标中，其中镜像包含两个 AP 有效载荷：一个用于 A53，另一个用于 A72：-ap u-boot-atf.bin a53 0x80000000 ... -ap u-boot-atf-a72.bin a72 0xC0000000 ... 。 因此，重要的选择器不仅是文件名；它还是目标中的 imx-mkimage -ap ... a72 ... 参数。对于单个 A72 启动映像，使用 u-boot-atf.bin 的 flash_ca72 与文档中所述的意图一致：即使文件名没有后缀 -a72，有效载荷也会通过目标规则加载到 A72。 推荐路径： 使用现有目标构建标准的仅限 A72 的镜像： 制作 SOC=iMX8QM flash_ca72 在 Linux 端使用 CA72 设备树/配置。NXP 文档指出，i.MX8QM MEK CA72 DTB 仅支持两个 Cortex-A72 内核，并且需要使用 flash_ca72 构建的特殊启动映像。 预留 u-boot-atf-a72.bin对于显式打包第二个 A72 AP 映像的流程（例如 flash_cockpit），除非您的 电路板支持包的 soc.mak评论或发行说明另有说法。 启动时验证镜像是否实际进入 A72 路径：检查 make V=1 SOC=iMX8QM flash_ca72 命令发出的 imx-mkimage 命令，或检查 iMX8QM/soc.mak 文件。并确认 AP 线路使用 a72。 要点：将当前 flash_ca72 引用视为对 u-boot-atf.bin 的引用这是有意为之；u-boot-atf-a72.bin 是用于驾驶舱/多分区风格镜像中单独使用的 A72 有效载荷，而不是 flash_ca72 的自动替代品。 Re: iMX8qm Boot Core A72_0 我们想澄清/确认一个小问题：`flash_ca72` 目标目前引用了 `u-boot-atf.bin`，同时，在相同的配置中，还有一个单独的 `u-boot-atf-a72.bin` 可用。 我们该如何进行？ Re: iMX8qm Boot Core A72_0 是的——在 i.MX8QM 上，应用程序处理器启动映像可以面向 Cortex-A72 而不是 Cortex-A53，SCFW 允许这种流程。NXP 的 imx-mkimage 有一个 flash_ca72 目标，被描述为普通 A53 启动映像的 A72 变体，旨在尽早启动 A72 以优化启动时间。 重要的区别在于： First code after RESET: 不是 A72。设备启动流程仍然从 ROM/SCU/SCFW 开始。 AP 端引导加载程序/操作系统启动：是的，这可以在 A72 上完成。SCFW 初始化 DDR，加载 Cortex-A 映像，然后启动内核并设置其起始地址。 配置机制：启动容器可以为 a72 指定一个 AP 镜像，例如示例显示 imx-mkimage 中的 -ap ... a72 ...。 所以答案是： SCFW 确实允许从 A72 启动 AP 软件路径，但 A72 不是 RESET/ROM 启动主控；它是由 SCFW 根据启动容器配置启动的。 Re: iMX8qm Boot Core A72_0 你好， 我按照以下步骤构建引导加载程序，但引导加载程序构建失败，没有任何日志记录。 请您核对一下附件中的步骤。 谢谢！ mkdir Scarthgap_New cd Scarthgap_New   1. 获取网络安全控制器二进制文件 mkdir SECO 光盘 SECO wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-5.9.4.1-0333596.bin chmod +x imx-seco-5.9.4.1-0333596.bin ./imx-seco-5.9.4.1-0333596.bin   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$ ls -al 总计 976 drwxrwxr-x 2 mkashyap mkashyap   4096 8月26日 22:21 . drwxrwxr-x 3 mkashyap mkashyap   4096 8月26日 22:21 .. -rw-r--r-- 1 mkashyap mkashyap    194 7月 29  2024 commit-id.txt -rw-r--r-- 1 mkashyap mkashyap 163840 2024年7月29日 mx8dxla1-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap 163840 2024年7月29日 mx8dxlb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap 76944 2024 年 7 月 29 日 mx8qmb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  71312 7月29日  2024 mx8qxb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  78408 7月29日  2024 mx8qxc0-ahab-container.img -rwxr-xr-x 1 mkashyap mkashyap 423875 2024 年 7 月 29 日 SECO_FW_release_note.pdf mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$   我们使用 mx8qmb0-ahab-container.img   光盘 ../../../..   2. 下载并构建 ATF mkdir ATF 光盘 ATF git clone https://github.com/varigit/imx-atf-b lf_v2.10_6.6.52-2.2.0_var01   cd imx-atf 源 /opt/fsl-imx-xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux unset LDFLAGS 制作 PLAT=imx8qm bl31   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/ATF/imx-atf/build/imx8qm/release$ ls -al 总计76 drwxrwxr-x 7 mkashyap mkashyap  4096 8月26日 22:37 . drwxrwxr-x 3 mkashyap mkashyap  4096 8月26日 22:36 .. drwxrwxr-x 3 mkashyap mkashyap  4096 8月26日 22:37 bl31 -rwxrwxr-x 1 mkashyap mkashyap 45213 8月 26日 22:37 bl31.bin drwxrwxr-x 2 mkashyap mkashyap 4096 8 月 26 日 22:37 lib drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:37 libc drwxrwxr-x 2 mkashyap mkashyap 4096 八月 26 22:37 libwrapper drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:37 romlib   光盘 ../../../../../   3. 下载并构建 SCFW mkdir SCFW    cd SCFW     wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz sudo tar xf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz -C ./opt     git clone https://github.com/varigit/imx-sc-firmware.git -b 1.17.0 cd imx-sc-firmware/src/scfw_export_mx8qm_b0     export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt    执行 clean-qm    使 qm R=B0 B=var_som V=1     mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0$ ls -al 总计 3384 drwxrwxr-x 11 mkashyap mkashyap 4096 8月26日 22:47 . drwxrwxr-x 6 mkashyap mkashyap 4096 8月26日 22:47 .. drwxrwxr-x 3 mkashyap mkashyap 4096 8月26日 22:47 板 drwxrwxr-x 3 mkashyap mkashyap 4096 8月26日 22:44 设备 drwxrwxr-x 25 mkashyap mkashyap 4096 8月26日 22:47 司机 drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:44 main    -rwxrwxr-x 1 mkashyap mkashyap 184448 8 月 26 日 22:47 scfw_tcm.bin -rwxrwxr-x 1 mkashyap mkashyap 2787784 8月26日 22:47 scfw_tcm.elf    -rw-rw-r-- 1 mkashyap mkashyap 513123 8 月 26 日 22:47 scfw_tcm.map drwxrwxr-x 4 mkashyap mkashyap 4096 8月26日 22:44 soc drwxrwxr-x 26 mkashyap mkashyap 4096 8月26日 22:44 ss drwxrwxr-x 9 mkashyap mkashyap 4096 8月26日 22:47 svc drwxrwxr-x 10 mkashyap mkashyap 4096 8月26日 22:44 测试 drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:44 实用程序     光盘 ../../../../../     4. 构建 u-boot mkdir u-boot    cd u-boot     git clone https://github.com/varigit/uboot-imx.git -b lf_v2024.04_6.6.52-2.2.0_var01    cd uboot-imx        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./mx8qm-ahab-container.img    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./mx8qm-mek-scfw-tcm.bin    让 mrproper    制作 imx8qm_var_som_defconfig make -j8     光盘 ../../     5. 制作图像 mkdir MkImage    cd MkImage     git clone https://github.com/varigit/imx-mkimage-b lf-6.6.52_2.2.0_var01    cd imx-mkimage        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/spl/u-boot-spl.bin ./iMX8QM/    cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/        制作 SOC=iMX8QM flash_ca72        cd iMX8QM make -f soc.mak SOC=iMX8QM MKIMG=../mkimage_imx8 PAD_IMAGE=./pad_image.sh flash_ca72        mkashyap@cse-dev02:~/iMX8/Scarthgap_New/MkImage/imx-mkimage/iMX8QM$ ls -al 总计 6792 drwxrwxr-x 3 mkashyap mkashyap 4096 8月26日 23:08 . drwxrwxr-x 13 mkashyap mkashyap 4096 8月26日 23:06 .. -rwxrwxr-x 1 mkashyap mkashyap 45213 8月26日 23:06 bl31.bin -rwxrwxr-x 1 mkashyap mkashyap 2564 8月26日 22:59 expand_c_define.sh    -rw-rw-r--  1 mkashyap mkashyap 1895424 8 月 26 日 23:08 flash.bin -rw-rw-r-- 1 mkashyap mkashyap 9 Aug 26 23:06 head.hash -rwxrwxr-x 1 mkashyap mkashyap 2078 年 8 月 26 日 22:59 mkimage_fit_atf.sh    -rw-r--r-- 1 mkashyap mkashyap 76944 8 月 26 日 23:02 mx8qmb0-ahab-container.img    -rwxrwxr-x 1 mkashyap mkashyap 184448 8 月 26 日 23:03 scfw_tcm.bin drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:59 脚本    -rwxrwxr-x 1 mkashyap mkashyap 13271 8 月 26 日 22:59 soc.mak    -rwxrwxr-x 1 mkashyap mkashyap 1631521 8 月 26 日 23:06 u-boot-atf.bin    -rw-rw-r-- 1 mkashyap mkashyap 1500440 8 月 26 日 23:04 u-boot.bin    -rw-rw-r-- 1 mkashyap mkashyap 1500449 8 月 26 日 23:06 u-boot-hash.bin    -rw-rw-r-- 1 mkashyap mkashyap 139387 8 月 26 日 23:04 u-boot-spl.bin     生成的 flash.bin 文件被用作引导加载程序镜像。 Re: iMX8qm Boot Core A72_0 就您的具体手术而言，关键在于： 制作 SOC=iMX8QM flash_ca72 如果您打算将引导加载程序加载到 A72 而不是 A53 ，那么从概念上讲，这是正确的目标。NXP 社区指南将 flash_ca72 描述为类似于基本的 flash_b0 映像，但加载到A72而不是A53 。 “无日志”症状并不一定意味着 SCFW 拒绝了 A72 启动。一个已知的陷阱是A53 和 A72 不使用同一个日志终端，因此，如果您监测通常的 A-core/A53 UART，即使 A72 镜像正在运行或稍后在不同的控制台路径上出现故障，您可能也看不到任何东西。 验证您的步骤： 面积 评估 SECO集装箱 mx8qmb0-ahab-container.img 是 i.MX8QM B0 的正确容器类别。 ATF 使 PLAT=imx8qm bl31 对于 i.MX8QM 来说是合理的。 SCFW 构建 qm R=B0 B=var_som V=1 与 i.MX8QM B0 Variscite 目标一致。 U-Boot imx8qm_var_som_defconfig 是需要确认的关键项：它必须与 A72 启动路径和控制台配置兼容。 mkimage 目标 flash_ca72 仅适用于 A72 启动。对于正常的 Linux 电路板支持包。启动，文档中记录的 i.MX8QM 命令是 make SOC=iMX8QM flash。 SPL副本 u-boot-spl.bin 可能与 flash_ca72 无关；该目标不是基于 SPL 的流程。 重复镜像版本 同时运行顶层 make SOC=iMX8QM flash_ca72 和手动运行 make -f soc.mak ... flash_ca72 是不必要的。使用一条简洁的顶级命令。 我会修改/优化图像生成部分，使其： cd ~/iMX8/Scarthgap_New/MkImage/imx-mkimage cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/ cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/ cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/ cp ../../ATF/imx-atf/build/imx8qm/版本/bl31.bin ./iMX8QM/ make clean 制作 SOC=iMX8QM flash_ca72 然后使用： iMX8QM/flash.bin 同时修复/检查此 SCFW 路径： export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt 您已将文件提取到 ./opt 目录。但是导出了.../SCFW/Opt。Linux 路径区分大小写。既然你已经生成了scfw_tcm.bin你的 shell 可能确实有有效的工具路径，但这一行需要验证。 推荐的调试顺序： 首先构建并启动标准镜像： 让 SOC=iMX8QM 闪存 这会检查 SECO + SCFW + ATF + U-Boot + 板 DDR/控制台是否基本正确。Linux 用户指南中记录了此标准 i.MX8QM flash.bin 文件。生成路径。 然后使用以下命令重新构建： 制作 SOC=iMX8QM flash_ca72 监控A72 控制台/UART ，而不仅仅是普通的 A53 控制台。A53 和 A72 日志终端有所不同。 如果仍然没有反应，请比较生成的 flash.bin 文件。比较 flash 和 flash_ca72 之间的大小/布局，并确认 Variscite U-Boot 配置是否真正启用了 A72 启动目标使用的控制台。 所以直接的答案是： SCFW 确实允许通过 flash_ca72 镜像流程启动 A72 上的 Cortex-A 端，但 SCFW 仍然负责初始启动编排。你的步骤对 A72 启动基本有效，但需要移除重复的 soc.mak 调用，验证 SCFW 工具路径，最重要的是检查 A72 的 UART/控制台。 要点：i.MX8QM 上的 A72 启动是通过 flash_ca72 实现的；静默启动更有可能是镜像/配置/控制台问题，而不是 SCFW 拒绝启动 A72。 Re: iMX8qm Boot Core A72_0 哪里可以找到SCFW参考手册或设计手册，以便对SCFW固件进行修改？ Re: iMX8qm Boot Core A72_0 您可以从这里开始： https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101/ta-p/1124236 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101-Getting-started/ta-p/1121153 SCFW 参考/移植文档包含在 NXP SCFW 移植工具包中，而不是作为单独的公开参考手册提供。 从 NXP i.MX 软件和开发页面下载工具包。选择与您的 i.MX BSP 对应的版本；NXP 需要匹配的移植工具包以保持与其提供的二进制文件的兼容性。 接受许可协议并运行包含的 .bin 文件安装程序。 请查看下方： doc/pdf/sc_fw_port.pdf — 详细的 SCFW 移植指南 doc/pdf/ — SCFW API 用户指南、版本说明及相关文档 src/ — SoC 专用 SCFW 导出归档 该工具包包含源代码和目标代码的混合体。针对特定电路板的定制是在导出的电路板源代码中进行的，通常位于 platform/board/mx8 _ / 目录下，包括 board.c 等文件。; SCFW 的核心大部分仍然是对象式的，无法通过公共工具包进行修改。 通用 i.MX 移植指南 UG10165 中也有一个“移植系统控制器固件”章节，解释了与 BSP 和 meta-imx-scfw 的集成。

S32 Power Architecture 设计工作室，版本 2.1 许可 我的 S32 Design Studio for Power Architecture 2.1 版许可证已过期。请问您能帮我续期或者申请新卡吗？ F379-CD5D-DAD1-7708 Re: S32 Design Studio for Power Architecture, version 2.1 license 你好， 您的S32DS许可证已延期。请使用您之前的激活码重新激活S32DS。 Re: S32 Design Studio for Power Architecture, version 2.1 license 你好， 我已经申请续约。 顺祝商祺！ Peter

S32 Design Studio for Power Architecture, version 2.1 license My license for S32 Design Studio for Power Architecture version 2.1 has expired. Could you help me renew it or apply for a new one. F379-CD5D-DAD1-7708 Re: S32 Design Studio for Power Architecture, version 2.1 license Hi,  your S32DS license has been extended. Please activate S32DS again with your old code.  Re: S32 Design Studio for Power Architecture, version 2.1 license Hello, I have asked for renewal. Best regards, Peter

我可以在哪里获取AN12064文件？ 我可以在哪里获取AN12064文件？ 评估板

FRDM-K64F PITの異なるRevボード こんにちは、 私はNRF23L01トランシーバを搭載した6枚のFRDM-K64Fボードを使った無線ネットワークの実験を行っています。 1秒を10のタイムスロットに分割しています。つまり、スロット1の送信はタイムスロット2で繰り返され、タイムスロット2はタイムスロット3に繰り返される、という中継の目的です。 PITを使って100ms間隔で割り込みを発生させており、スコープで確認しています。 リビジョンC、F、Fの3枚の基板では正常に動作しており、データが無線で繰り返し送信されているのを確認しています。しかし、3つのリビジョンF1ボードでは、送信ルーチンがタイムスロット1が回ってくるのを待ってハングアップしてしまいます。割り込みが発生しません！ 例えば、Rev FとRev F1の間で何が変わったことで、このような挙動が引き起こされたのか、ご存知の方はいらっしゃいますか？ これが私の初期化ルーチンです。 SIM->SCGC6 |= SIM_SCGC6_PIT_MASK; // PIT のクロックをオンにするPIT- > MCR = 0x1; // PIT タイマーを有効にする PIT>チャネル[0]。LDVAL = 5999999; リロード値を100mSに設定 PIT->チャネル[0].TCTRL = 0x03; // Turn PIT timer 0 on, interrupts on そして主な内容は： NVIC_EnableIRQ(PIT0_IRQn); // PIタイマー、ch 0割り込みを有効にする そしてISR： void PIT0_IRQHandler ( void ) { /* 割り込みフラグをクリアする */ ピット・>チャネル[0]。TFLG = PIT_TFLG_TIF_MASK; NVIC_ClearPendingIRQ( PIT0_IRQn ); // 保留中のPIタイマー、 ch 0割り込みをクリアします //scope_trigger(); time_lot +=1; if (time_slot > 10) time_slot = 0; __DSB(); ARM の訂正 838869を追加し、Cortex-M4に影響します } どんな助けでもありがたいです！ 乾杯 ナイジェル Kinetis KシリーズMCU Re: FRDM-K64F PIT on different Rev boards ああ！ありがとうございます。はい、そのマスクは3つのチップすべてに付いています。これまでとても役に立ったあなたのAIエンジンがそれを出さなかったのは驚きです!何か代替策はありますか？遅延か、それとも失敗か？はい、 PIT->MCR = 0x1; は別の行にあるべきで、 は切り取りと貼り付けの際に抜け落ちてしまったのでしょう。 Re: FRDM-K64F PIT on different Rev boards こんにちは、 @ve3id さん。 投稿ありがとうございます！ e7914があなたのMCUに適用されているか確認してください:Kinetis_K_1N83J.pdf FRDM-K64F REV F1でテストしましたが動作しました。SDK 2.11.0とMCUXpresso IDE 25.06を使っていました。 また、共有したコードの中で「PIT->MCR = 0x1;」がSCGC6のイネーブルメントにコメントとして含まれているのに気づきましたが、投稿中のタイプミスかどうか確認したいだけです Re: FRDM-K64F PIT on different Rev boards 遅延時間を100秒に変更しても、PITアクションは発生しませんでした。 Re: FRDM-K64F PIT on different Rev boards イニットコードをこのように変えましたが、同じ問題が続いています: 遅延(10); 揮発性uint32_t PIT_MCR_read = PIT->MCR;1N83Jマスクセットの問題を克服するために 2026-09-22 NWJ PIT->MCR = 0x1;PITタイマーを有効にする ピット>チャネル[0]。LDVAL = 5999999;リロード値を100mSに設定 PIT->CHANNEL[0]。TCTRL = 0x03;PITタイマー0をオンにし、割り込みをオンにします Re: FRDM-K64F PIT on different Rev boards こんにちは、 @ve3id さん。 正誤表に記載されている回避策は、PIT_MCRレジスタに書き込む前に、そのレジスタを読み取ることです。 私はPITのSDK例をベースにして、FRDM REV F1で何をしているかをテストしています。以下のように修正しました carlos_o_0-1790096350978.png 問題なく動作します。

MCSPTR2AK396——旋转变压器的激励极限？ 你好！我正在使用 MCSPTR2AK396 开发套件（S32K396，带旋转变压器的三相 PMSM，3 并联 FOC）。我使用的是标准的解析器到数字信号链：SGEN → SDADC → DSPSS → eTPU 解析器函数。 据我了解，标准激励频率为 10 kHz（SGEN 正弦波驱动旋转变压器激励绕组），eTPU 旋转变压器每 50 µs 处理一次角度更新，使用来自 SDADC 的 16+16 采样缓冲器，并通过慢速 PI 调节器调整激励相移。但我还有一些疑问。 MCSPTR2AK396 套件中使用的具体解析器型号是什么？提供数据手册参考资料将非常有帮助。 该旋转变压器的最大激励频率是多少？例如，能否在不修改 SGEN 寄存器以外的任何内容的情况下，将 SGEN 提高到 100 kHz？或者 SDADC/DSPSS/eTPU 链或模拟正弦/余弦滤波器是否施加了远低于此的硬性限制？ 旋转变压器本身允许的最小激励频率是多少？推荐的频率范围是多少？ 如果可以提高激励强度，还需要重新配置哪些参数——SDADC 采样率、DMA 缓冲区传输、eTPU HSR 速率、激励相移调节器增益、模拟滤波器？ 谢谢！ Re: MCSPTR2AK396 — resolver excitation limits? 你好， MCSPTR2AK396 套件中使用的具体解析器型号是什么？ 在 TG Drives 电机制造商的网站上，有一个配置器列出了三种可能的旋转变压器选项：ER5Kd411、TS2620N21E11 和 RE-15-1-A15。 如果我没记错的话，当时要求的是成本最低的解析器方案，也就是 ATAS Náchod 公司的 ER5Kd411。 https://www.atas.cz/files/ER5Kd.pdf 打开后盖即可确定具体型号。 MCSPTR2AK396 旋转变压器解决方案是在 10 kHz 激励下设计和验证的。根据应用说明，虽然 SGEN 支持高达 50 kHz 的频率，但高于 10 kHz 的操作需要重新配置和验证 SDADC、DSPSS、DMA、eTPU 解析器处理和模拟信号调理链。此外，对于 TS2620N21E11 等旋转变压器，我们只找到了已公布的标称激励规格为 10 kHz 时 7 Vrms；在可用的旋转变压器数据表中没有指定支持的激励频率范围。因此，根据现有资料，不建议在 100 kHz 频率下运行。 顺祝商祺！ Peter

FRDM-K64F PIT 在不同版本的板上 您好， 我正在尝试使用六块配备 nrf23l01 收发器的 FRDM-K64F 板进行无线电联网。 我将一秒钟分成十个时隙，其目的是让时隙 1 中的传输在时隙 2 中重复，时隙 2 中的传输在时隙 3 中重复，依此类推进行转发。 所以我使用 PIT 以 100 毫秒的周期生成中断，我已经用示波器检查过了。 在三块电路板（C、F 和 F 版本）上，此功能运行正常，我看到空中数据重复出现。然而，使用这三块 rev F1 电路板时，我的发射程序会卡住，等待时间段 1 到来。我没有收到中断！ 有人知道版本 F 和版本 F1 之间发生了什么变化会导致这种现象吗？ 这是我的初始化程序： SIM->SCGC6 |= SIM_SCGC6_PIT_MASK; // 开启 PIT 时钟 PIT - > MCR = 0x1; // 启用 PIT 定时器 PIT -> CHANNEL [0]. LDVAL = 5999999; // 设置重载值为 100 毫秒 PIT -> CHANNEL [0]. TCTRL = 0x03; // 开启 PIT 定时器 0，中断开启 主要内容： NVIC_EnableIRQ(PIT0_IRQn); // 启用 PI 定时器，通道 0 中断 以及 ISR： void PIT0_IRQHandler ( void ) { /* 清除中断标志 */ PIT-> CHANNEL [0]. TFLG = PIT_TFLG_TIF_MASK; NVIC_ClearPendingIRQ( PIT0_IRQn ); // 清除待处理的 PI 定时器，通道0 中断 //scope_trigger(); time_slot += 1; 如果（时间段 > 10）时间段 = 0； __DSB(); // 添加以应对 ARM勘误表838869，影响 Cortex-M4 } 非常感谢您的帮助！ 干杯 奈杰尔 Kinetis K系列MCU Re: FRDM-K64F PIT on different Rev boards 啊哈！谢谢。是的，我的三个芯片上都装了那个面罩。我很惊讶，你们的AI引擎（到目前为止，我觉得它非常有用）竟然没有提出这个问题！是否有建议的解决方法？延迟或失败？是的， PIT->MCR = 0x1; 应该单独一行， 肯定是在剪切粘贴过程中丢失了。 Re: FRDM-K64F PIT on different Rev boards 嗨@ve3id 感谢您的帖子！ 请检查勘误表 e7914 是否适用于您的 MCU： Kinetis_K_1N83J.pdf 我在 FRDM-K64F REV F1 上测试过，可以正常工作，我使用了 SDK 2.11.0 和 MCUXpresso IDE 25.06。 另外，我注意到您分享的代码中，在启用 SCGC6 的代码里，有一行“PIT->MCR = 0x1”作为注释，我想确认一下这是否是帖子中的笔误。 Re: FRDM-K64F PIT on different Rev boards 嗨@ve3id 勘误表中提到的解决方法是在写入 PIT_MCR 寄存器之前先读取该寄存器。 我以SDK中的PIT示例为基础，在FRDM板REV F1上测试您正在进行的操作，并进行了如下修改： carlos_o_0-1790096350978.pngcarlos_o_0-1790096350978.pngcarlos_o_0-1790096350978.png 运行正常，没有任何问题。 Re: FRDM-K64F PIT on different Rev boards 我已将初始化代码更改为以下内容，但问题仍然存在： 延迟(10)； volatile uint32_t PIT_MCR_read = PIT->MCR; // 为了解决 1N83J 掩码集勘误表中的问题（2026-09-22 NWJ） PIT->MCR = 0x1; // 启用 PIT 定时器 PIT->CHANNEL[0].LDVAL = 5999999; // 设置重载值为 100 毫秒 PIT->CHANNEL[0].TCTRL = 0x03; // 开启 PIT 定时器 0，中断开启 Re: FRDM-K64F PIT on different Rev boards 我甚至把延迟时间改成了 100 微秒，但 PIT 仍然没有反应。

在线ECC验证方法 你好， 我正在研究 iMX8M Plus 在外部 DDR 内存上的内联 ECC 实现。 ECC 似乎正在工作（U-Boot 修改已完成，EDAC 驱动程序出现在 Linux 中，/sys/devices/system/edac/mc/mc0/ 虚拟文件存在）。 我正在寻找测试和验证该保护措施的方法。 我的理解是，错误注入不可能直接发生在数据本身，而是必须破坏 ECC 奇偶校验位。 AN 13566 第 3.2.9 节声明：“有关此功能的更多信息可应要求提供。” 我该如何获取这些信息？NXP方面是否有专门的联系人/渠道负责此事？ 先感谢您， Re: Inline ECC validation method 你好， 我正在使用外置DDR在i.MX 8M Plus上实现内联ECC。ECC 似乎工作正常：U-Boot 已配置，Linux EDAC 驱动程序已激活，并且 /sys/devices/system/edac/mc/mc0/ 存在。 现在我想通过故意生成可纠正和不可纠正的错误来验证 ECC 保护。 AN13566，第 3.2.9 节，声明指出，可以通过使用 ECC_REGION_PARITY_LOCK 解锁 ECC 区域并覆盖 ECC 奇偶校验位来注入内联 ECC 错误。文中还提到，如有需要，可提供有关此功能的更多信息。 Re: Inline ECC validation method 你好， 当然可以，但需要您创建一个支持工单。 https://support.nxp.com/s/?language=en_US 您可以在请求正文中提及我，以便我跟踪工单并提供所需材料。 此致敬礼/Saludos， 阿尔多。

FRDM-K64F PIT on different Rev boards Hi, I am experimenting with radio networking using six FRDM-K64F boards equipped with nrf23l01 transceivers. I am splitting a second into ten time slots, the idea being that a transmission in slot 1 gets repeated in time slot 2, time slot 2 into time slot 3 etc for relaying. So I am using PIT to generate interrupts at 100 ms periods, which I have checked on a scope. On three boards, rev C,F, and F this is working fine and I am seeing the data on air being repeated.  However with the three rev F1 boards my transmit routine gets hung waiting for time slot 1 to come around. I am not getting the interrupt! Does anybody know what changed between, say rev F and Rev F1 that would cause this behaviour? Here is my init routine: SIM->SCGC6 |= SIM_SCGC6_PIT_MASK; // Turn on clock to to the PIT PIT->MCR = 0x1; // Enable PIT timers PIT->CHANNEL[0].LDVAL = 5999999; // Set reload value to 100mS PIT->CHANNEL[0].TCTRL = 0x03; // Turn PIT timer 0 on, interrupts on and in main: NVIC_EnableIRQ(PIT0_IRQn); // Enable PI timer, ch 0 interrupt and the ISR: void PIT0_IRQHandler(void) { /* Clear interrupt flag */ PIT->CHANNEL[0].TFLG = PIT_TFLG_TIF_MASK; NVIC_ClearPendingIRQ(PIT0_IRQn); // Clear pending PI timer, ch 0 interrupt //scope_trigger(); time_slot +=1; if (time_slot >10) time_slot=0; __DSB(); // Add for ARM errata 838869, affects Cortex-M4 } any help appreciated! cheers nigel Kinetis K Series MCUs Re: FRDM-K64F PIT on different Rev boards Aha! Thanks for that. Yes I have that mask on all three chips. I'm surprised that your AI engine that I have found very useful so far did not bring that up! Is there a suggested work-around? A delay or nops maybe? And yes, the PIT->MCR = 0x1; should be on a separate line, the   must have have slipped out during cut and paste. Re: FRDM-K64F PIT on different Rev boards Hi @ve3id  Thank you for your post!  Please review if the errata e7914 applies for your MCU: Kinetis_K_1N83J.pdf I've tested it in FRDM-K64F REV F1 and it works, I used SDK 2.11.0 and MCUXpresso IDE 25.06. Also, I notice that in the code you share the "PIT->MCR = 0x1;" is included as a comment in the enablement of the SCGC6, I only want to confirm if that is a typo in the post Re: FRDM-K64F PIT on different Rev boards Hi @ve3id  The workaround mentioned with the errata is to put a read of the PIT_MCR register before writing it. I use the PIT example of the SDK as base to test what you are doing in a FRDM board REV F1, I modified as following  carlos_o_0-1790096350978.pngcarlos_o_0-1790096350978.pngcarlos_o_0-1790096350978.png It works without issues.  Re: FRDM-K64F PIT on different Rev boards I even changed the delay to 100 us and still no PIT action Re: FRDM-K64F PIT on different Rev boards I've changed my init code to this and still have the same problem: delay(10); volatile uint32_t PIT_MCR_read = PIT->MCR; // to overcome problem in 1N83J mask set errata 2026-09-22 NWJ PIT->MCR = 0x1; // Enable PIT timers PIT->CHANNEL[0].LDVAL = 5999999; // Set reload value to 100mS PIT->CHANNEL[0].TCTRL = 0x03; // Turn PIT timer 0 on, interrupts on

ls1043a - Linux BSP 中是否应该启用 thermal_zone5？ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我正在使用 ls1043 处理器的参考板 ls1043ardb，遇到了散热子系统的问题。我看到的错误是： [ 116.704475] thermal thermal_zone5：已达到临界温度 (104°C)，正在关闭 虽然看起来有点零星，但一旦出现，通常会在启动后不久发生。它并非总是发生。当系统稳定时，thermal_zone5 的温度始终为 0。 dts 文件 fsl-ls1043a.dtsi 中已激活 thermal_zone0 - thermo_zone5。（ fsl-ls1043a.dtsi\freescale\dts\boot\arm64\arch - qoriq-components/linux - 用于 QorIQ 支持的 Linux 树） 问题是 ls1043 是否应该启用 thermal_zone5？查阅“QorIQ LS1043A 参考手册，修订版 5，04/2019”第 35.1.1 章“本地温度传感器位置”，我可以看到一个表格，其中指出 ls1043 的温度传感器 ID 为 0-4，而 ID 5-15 被标记为保留。hte dtsi 文件是否启用 thermal_zone5，并且在 ls1043 中是否可用？ 谢谢， 彼得 Re: ls1043a - should thermal_zone5 be active in the Linux BSP? 你好， 我们在运行 Linux 4.19.68 的 LS1043A 平台上也遇到了类似的问题。 系统偶尔会报告： Thermal_zone5：温度已达临界值（104℃），正在关闭   观察发现，热区 0-4 通常彼此密切相关，而热区 5 经常报告明显不同的值，并且与其他区域的行为不同。   停机前，各热区报告的值与以下值类似： thermal_zone0: 75000 thermal_zone1：76000 thermal_zone2：76000 thermal_zone3：75000 thermal_zone4：74000 thermal_zone5：0 NXP 在之前的回复中提到 thermal_zone5 的值不确定，并将在未来的 LSDK 版本中提供修复程序。 请问这个问题是否已经修复？如果已修复，请问是哪个 LSDK/内核版本包含了该修复？ 谢谢。 Re: ls1043a - should thermal_zone5 be active in the Linux BSP? 我在最新的LSDK 20.12（内核版本5.4.47）上也遇到了类似的问题。 [ 2115.927267] thermal thermal_zone1：已达到临界温度（85°C），正在关闭 [ 2116.951246] thermal thermal_zone1：已达到临界温度（85°C），正在关闭 [ 2117.975285] thermal thermal_zone1：已达到临界温度（85°C），正在关闭 请问是否有任何变通方法可以解决这个问题？ 这个问题的根本原因是什么？ Re: ls1043a - should thermal_zone5 be active in the Linux BSP? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我们已确认该问题，目前热区 5 报告的值不确定，可能会在任何随机时间点导致此类问题。我们将在即将发布的 LSDK 版本中提供正式修复程序。 目前你可以从 dtsi 中移除热区 5，看看是否有帮助。

Where can I obtain the AN12064 document？ Where can I obtain the AN12064 document？ Evaluation Board

S32K3 浮動小数点設定ファイル こんにちは、チームの皆さん、 私のプロジェクトでは、浮動小数点数データを使用して算術演算を行おうとしていますが、計算が期待どおりに行われません。 #define macro -31.374 UTILS PRINTF を使用してマクロ値を表示しようとすると、 -32.374 になります。同様に他の値についても、値は1ずつ増加します。 そのため、計算結果が期待通りにならなかった。 これに関して何か設定ファイル（cfg）を作成する必要はありますか？ 現在の目標設定 nirmal_masilamani_0-1790009448678.pngnirmal_masilamani_0-1790009448678.png Re: S32K3 Floating point cfg こんにちは、 @nirmal_masilamani さん。 「UTILS PRINTF」とは具体的に何を指しているのか教えていただけますか? どのように計算を行っていますか？結果は浮動小数点変数に格納されますか？はいの場合、デバッガーで確認した時点で既に変数に誤った値が含まれているのでしょうか、それとも問題はそれを印刷した時のみ発生するのでしょうか？ BR、VaneB Re: S32K3 Floating point cfg こんにちは、 @VaneB さん。 サポートありがとうございます。はい、問題はPRINTF関数にありました。デバッグ中に正しいデータを読み取ることができました。

MCSPTR2AK396 — resolver excitation limits? Hello! I'm working with the MCSPTR2AK396 development kit (S32K396, 3-phase PMSM with resolver, 3-shunt FOC). I'm using the stock resolver-to-digital chain: SGEN → SDADC → DSPSS → eTPU RESOLVER function. As far as I understand, the stock excitation frequency is 10 kHz (SGEN sine wave driving the resolver excitation winding), and the eTPU RESOLVER processes angle updates every 50 µs with a 16+16 sample buffer from SDADC, with a slow PI regulator adjusting the excitation phase shift. But I have a questions. What is the exact resolver model used in the MCSPTR2AK396 kit? A datasheet reference would be very helpful. What is the maximum excitation frequency this resolver ? Can SGEN be raised, for example, to 100 kHz without modifying anything except SGEN registers? Or does the SDADC/DSPSS/eTPU chain, or the analog sin/cos filters, impose a hard limit well below that? What is the minimum excitation frequency allowed by the resolver itself, and what is the recommended range? If higher excitation is possible, what else must be reconfigured — SDADC sampling rate, DMA buffer transfer, eTPU HSR rate, excitation phase-shift regulator gains, analog filters? Thank you. Re: MCSPTR2AK396 — resolver excitation limits? Hello, What is the exact resolver model used in the MCSPTR2AK396 kit? On the TG Drives motor manufacturer's website, there is a configurator that lists three possible resolver options: ER5Kd411, TS2620N21E11, and RE-15-1-A15. If I remember correctly requested was lowest-cost resolver option, which was the ER5Kd411 from ATAS Náchod. https://www.atas.cz/files/ER5Kd.pdf The exact type could be determined by opening the rear cover. The MCSPTR2AK396 resolver solution is designed and validated at 10 kHz excitation. While SGEN supports frequencies up to 50 kHz according to the application note, operation above 10 kHz requires reconfiguration and validation of the SDADC, DSPSS, DMA, eTPU resolver processing and analog signal-conditioning chain. In addition, for resolvers such as TS2620N21E11 we only found a published nominal excitation specification of 7 Vrms at 10 kHz; no supported excitation-frequency range is specified in the available resolver datasheet. Therefore, operation at 100 kHz cannot be recommended based on available documentation. Best regards, Peter

AN12064書類はどこで入手できますか? AN12064書類はどこで入手できますか? 評価ボード

MCSPTR2AK396 — レゾルバの励起限界？ こんにちは！MCSPTR2AK396開発キット(S32K396、リゾルバ付き3相PMSM、3シャントFOC)を使っています。私は標準のリゾルバからデジタルへのチェーン、つまりSGEN → SDADC → DSPSS → eTPU RESOLVER関数を使用しています。 私の理解では、標準の励起周波数は10kHz（SGEN正弦波がレゾルバ励起巻線を駆動）であり、eTPUレゾルバはSDADCからの16+16サンプルバッファを使用して50µsごとに角度更新を処理し、低速PIレギュレータで励起位相シフトを調整します。しかし、私には疑問があります。 MCSPTR2AK396キットで使われている正確なリゾルバーモデルは何ですか?データシートの参照情報があると大変助かります。 このレゾルバの最大励起周波数はどれくらいですか？例えば、SGENをSGENレジスタ以外に変更せずに100 kHzに上げることは可能でしょうか?それともSDADC/DSPSS/eTPUチェーンやアナログのsin/cosフィルターが、それよりはるかに低い厳しい制限を課しているのでしょうか? レゾルバ自体が許容する最小励起周波数はどれくらいですか？また、推奨される範囲はどれくらいですか？ より高い励起が可能なら、他に何を再構成する必要がありますか — SDADCサンプリングレート、DMAバッファ転送、eTPU HSRレート、励起位相シフトレギュレータゲイン、アナログフィルターなど? よろしくお願いします。 Re: MCSPTR2AK396 — resolver excitation limits? こんにちは、 MCSPTR2AK396キットで使われている正確なリゾルバーモデルは何ですか? TG Drivesモーターメーカーのウェブサイトには、ER5Kd411、TS2620N21E11、RE-15-1-A15という3つのレゾルバオプションを表示するコンフィギュレーターがあります。 私の記憶が正しければ、最も低価格なリゾルバの選択肢が求められており、それはATAS Náchod社のER5Kd411でした。 https://www.atas.cz/files/ER5Kd.pdf 正確なタイプはリアカバーを開けて確認できました。 MCSPTR2AK396レゾルバソリューションは、10kHzの励起周波数で設計および検証されています。SGENはアプリケーションノートによると最大50kHzまでの周波数をサポートしていますが、10kHz以上の動作にはSDADC、DSPSS、DMA、eTPUリゾルバプロセッシングおよびアナログ信号調整チェーンの再構成と検証が必要です。さらに、TS2620N21E11などのレゾルバについては、10kHzで7Vrmsという公称励起仕様しか公表されておらず、利用可能なレゾルバのデータシートには、サポートされる励起周波数範囲は記載されていません。したがって、利用可能なドキュメントに基づき100 kHzでの運用は推奨できません。 よろしくお願いいたします。 ピーター