lx2160a カーネル 5.10.35 の SPI モードについて こんにちは： デフォルトの DSPI_TCF_MODE 送信は非常に遅いことがわかりました。SPI 転送を高速化したいのですが、DSPI_DMA_MODE 転送はサポートされていないようです。モードを DSPI_EOQ_MODE に変更すると、カーネルがクラッシュします。SPI を介したデータ転送を効果的に高速化するには、どのような手順を踏む必要があるかを知りたいです。 私の変更点は次のとおりです。 spi-fsl-dspi.c内 静的定数構造体 fsl_dspi_devtype_data ls2085a_data = { .trans_mode = DSPI_EOQ_MODE、 .max_clock_factor = 8、 }; Re: lx2160a kernel 5.10.35 about spi mode NXP が提供する Linux カーネル ソース コードを参照してください。 https://github.com/nxp-qoriq/linux/blob/lf-5.10.y/drivers/spi/spi-fsl-dspi.c 次の 2 つのモードのみがサポートされます。 列挙型dspi_trans_mode { DSPI_XSPI_MODE、 DSPI_DMA_MODE、 };   lx2160a プラットフォームでは DSPI_XSPI_MODE モードを使用してください。 [LX2160A] = { .trans_mode = DSPI_XSPI_MODE、 .max_clock_factor = 8、 .fifo_size = 4、 },

Jlink fails to debug imx93 When using JLink to debug the M33 core of i.MX93, after setting breakpoints, it seems only the PC pointer is halted, while various internal counters continue counting, preventing normal debugging. What are the solutions for this issue?Thank you for ansering! Re: Jlink fails to debug imx93 Yes, and I tried on single M33 core, the system counter can't be halted as before. I can't find the reason. Best Regards. Re: Jlink fails to debug imx93 Hi @leoX  My test is based on single M33 and Jlink, did you boot M33 with remoteproc? Best Regards, Zhiming Re: Jlink fails to debug imx93 Thank you for your response! I am reading tstmr in a task to calculate the task's execution cycle, but if I add a breakpoint, the calculated cycle increases, indicating that the system counter continues to count when I add a breakpoint. Also, I am starting the M core through the A core. Does setting the download mode for M33 help? Best Regards Re: Jlink fails to debug imx93 Hi, Can you share the screenshot of  various internal counters?  Did you set the m33 download mode? Best Regards, Zhiming

RT1176 SFPD QSPI IS25LP064D-JKLE 私は評価ボードと同じ方法で FlexSPI1 を実装するカスタム RT1176 ボードをフラッシュしようとしていますが、使用しようとしている IS25LP064D-JKLE をサポートするために、フラッシュ VCC に 3.3V を供給しています。flexspi_nor_config.cを添付しました。およびメモリの設定。デフォルトのflexspi_nor_polling_transfer_cm7を使用しています。Link Application to RAM を有効にしてデバッグすると、「プログラムデータ - 読み出しデータ値が正しくありません！」というエラーが返されます（125行目）。設定上の問題が何なのかまだ把握できていません。現在、MCU Link MR を使用していますが、Jlink にもアクセスできます。カスタムボードにはディップ・スイッチがあり、ブートモード 1 を 1、ブートモード 0 を 0 に設定しています。 Re: RT1176 SFPD QSPI IS25LP064D-JKLE こんにちは@AnteoJ 、 NXP MIMXRTシリーズにご興味をお持ちいただきありがとうございます。 RT1020-EVK で使用されるフラッシュは ISSI_IS25LP064A SO、対応する flexspi_nor_config.c は SDKs 内にあります。まずはこれを確認してください。 また、フラッシュを交換するときは、まず SEC/MCUBootUtility に組み込まれているテンプレートのテストに合格すると、独自のフラッシュを LUT の問題から保護することができます。 よろしくお願いします、 ギャビン Re: RT1176 SFPD QSPI IS25LP064D-JKLE データシートに従って特定のフラッシュの値を調べて置き換えましたが、デバッグを開始すると、依然として IMPRECISERR と UNDEFINSTR が発生します。調整する必要がある追加のパラメータがあるかどうかはわかりません。ここに私のコードがあります: /* * 著作権 2018-2022 NXP * 無断転載を禁じます。 * * SPDXライセンス識別子: BSD-3条項 */ #include "evkbmimxrt1170_flexspi_nor_config.h" /* ツールによって使用されるコンポーネント ID 定義。*/ #ifndef FSL_COMPONENT_ID #FSL_COMPONENT_ID "プラットフォーム.ドライバ.xip_board" を定義します #endif /**************************************************************************************** * コード **********************************************************************************/ #定義されている場合(XIP_BOOT_HEADER_ENABLE) && (XIP_BOOT_HEADER_ENABLE == 1) # __CC_ARM が定義されている場合 || __ARMCC_VERSION が定義されている場合 || __GNUC__が定義されている場合 __attribute__ ((セクション(".boot_hdr.conf")),使用済み）） #elif 定義済み( __ICCARM__ ) #pragma location = ".boot_hdr.conf" #endif #FLASH_DUMMY_CYCLES 0x03 を定義する #FLASH_DUMMY_VALUE 0x03 を定義する const flexspi_nor_config_t qspiflash_config = { .memConfig＝ { 。タグ= FLEXSPI_CFG_BLK_TAG、 .バージョン= FLEXSPI_CFG_BLK_VERSION、 .readSampleClksrc=kFlexSPIReadSampleClk_Loopback内部的に、 .csホールド時間= 3u、 .csセットアップ時間= 3u、 // DDRモード、ワードアダッサブル、セーフ構成、差動クロックを有効にする .controllerMiscOption= 0x10, .デバイスタイプ= kFlexSpiDeviceType_SerialNOR、 .sflashPadType= kSerialFlash_4Pads、 .シリアルクロック周波数= kFlexSpiシリアルクロック_60MHz、 .sflashA1サイズ= 8u * 1024u * 1024u、 /* フラッシュ設定機能を有効にする */ .configCmdEnable= 1u、 .configModeType[0]= kDeviceConfigCmdType_Generic、 /* 設定コマンドシーケンスを設定する */ .configCmdSeqs[0]＝ { .seqNum= 1, .seqId= 12, 。予約済み= 0, }, /* フラッシュ内の読み取りレジスタの設定値を準備する */ .configCmdArgs[0]= (FLASH_DUMMY_VALUE << 4)、 .lookupTable＝ { // LUTを読み込む [0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x20), [1] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, FLASH_DUMMY_CYCLES, READ_SDR, FLEXSPI_4PAD, 0x04), // ステータスLUTの読み取り [4 * 1 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04), // 書き込み有効LUT [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x0), // セクターLUTを消去する [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x20, RADDR_SDR, FLEXSPI_1PAD, 0x18), // ブロックLUTを消去する [4 * 8 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xD8, RADDR_SDR, FLEXSPI_1PAD, 0x18), // PapeプログラムLUT [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x02, RADDR_SDR, FLEXSPI_1PAD, 0x18), [4 * 9 + 1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x0), // チップLUTを消去する [4 * 11 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x60, STOP, FLEXSPI_1PAD, 0x0), // 読み取りレジスタLUTを設定する [4 * 12 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xC0, WRITE_SDR, FLEXSPI_1PAD, 0x01), [4 * 12 + 1] = FLEXSPI_LUT_SEQ(STOP, FLEXSPI_1PAD, 0x00, 0, 0, 0), }, }, .ページサイズ= 256u、 .セクターサイズ= 4u * 1024u、 .ipcmdシリアルクロック周波数= 0x1、 .ブロックサイズ= 64u * 1024u、 .isUniformBlockSize= 偽、 }; #endif /* XIP_BOOT_HEADER_ENABLE */

为什么 i.MX9 上采用 24 MHz TPM 时钟时，TPM 输入捕获会返回较远的距离值（约 12 米） 你好，恩智浦社区、 我正在使用 i.MX93（Cortex-M33），正在尝试使用 TPM 输入捕获来连接 超声波距离传感器（如 HC-SR04 ）。我正在使用TPM3（通道2上的输入捕获）测量ECHO引脚上升沿和下降沿之间的脉冲宽度。 TPM 时钟配置为24 MHz，距离用公式计算： floattimeUs = (ticks / tpmClk) *1e6； floatdistanceCm = timeUs /58.0f； 以下是我的完整代码供参考：- #include "fsl_debug_console.h" #include " board.h " #include "app.h" #include "fsl_tpm.h" #include "fsl_rgpio.h" #include "fsl_lpuart.h" /******************************************************************************* * 定义 ******************************************************************************/ /******************************************************************************* * 原型 ******************************************************************************/ /******************************************************************************* * 变量 ******************************************************************************/ 易变 booltpmIsrFlag = 假; 易变 uint32_t上升时间 = 0; 易变 uint32_tfallingTime = 0; 易变 boolgotRisingEdge = 假; /******************************************************************************* * 代码 ******************************************************************************/ voidInit_LPUART(void) { lpuart_config_t config； /* 获取默认 UART 配置（8N1、无奇偶校验、无流量控制） */ LPUART_GetDefaultConfig(&config)； /* 根据需要修改参数 */ config.baudRate_Bps = 115200U; config.enableTx = true; config.enableRx = true; /* 使用指定参数初始化 UART */ LPUART_Init(BOARD_LPUART,&config、 board_lpuart_clk_freq); } 浮点数计算距离void) { uint32_tticks； 如果(fallingTime>= risingTime) ticks = fallingTime - risingTime； 不然 ticks = (tpm_max_counter_value(demo_tpm_baseaddr) - risingTime)+ fallingTime；/* 处理溢出 */ 浮点数tpmClk = CLOCK_GetIpFreq(lptpm_clock_root);/* 可以调整为 TPM 时钟 */ 浮点数timeUs = (ticks *) 1.0f/ tpmClk） * 1e6; PRINTF("TPM Clock :%.2f\r\n",tpmClk）； 浮点数distanceCm = timeUs / 58.0f; 返回distanceCm； } void设置void) { rgpio_pin_config_t out_config ={ kRGPIO_DigitalOutput, 0, };     /* 触发信号引脚 */ RGPIO_PinInit(BOARD_RGPIO,TRIG_PIN,&out_config）； RGPIO_PinWrite(BOARD_RGPIO,TRIG_PIN,0); } voidSendTrigPulse(void) { RGPIO_PinWrite(BOARD_RGPIO, TRIG_PIN, 1); SDK_DelayAtLeastUs(10，SystemCoreClock）； RGPIO_PinWrite(BOARD_RGPIO, TRIG_PIN, 0); } void tpm_input_capture_handler(处理程序) { uint32_tstatus = TPM_GetStatusFlags(demo_tpm_baseaddr); 如果(状态& tpm_channel_flag)     { uint32_tcapturedValue = TPM_GetChannelValue(demo_tpm_baseaddr, board_tpm_input_capture_channel); 如果(!gotRisingEdge) { risingTime = capturedValue； gotRisingEdge = true; // 切换到下降沿检测 TPM_SetupInputCapture(demo_tpm_baseaddr,TPM_SetupInputCapture(,kTPM_FallingEdge);      } 不然 { fallingTime = capturedValue； tpmIsrFlag = true; gotRisingEdge = 假; //切换回上升边缘检测以进行下次测量 TPM_SetupInputCapture(demo_tpm_baseaddr,TPM_SetupInputCapture(,kTPM_RisingEdge);      } // 清除该通道的中断标志 TPM_ClearStatusFlags(demo_tpm_baseaddr, tpm_channel_flag);    } sdk_isr_exit_barrier; // tpmIsrFlag = true； //* 清除中断标志。 // TPM_ClearStatusFlags(DEMO_TPM_BASEADDR, TPM_CHANNEL_FLAG)； // sdk_isr_exit_barrier； } /*! * @brief主要功能 */ intmain(void) { tpm_config_t tpmInfo； /* 板引脚、时钟、调试控制台初始化 */ BOARD_InitHardware()； setUp (); /* 安装 GPIO */ // Init_LPUART(); /* 再初始化一个 UART */ /* 向终端打印注释 */ PRINTF( "\ r\n TPM 输入捕获示例\ r\n "); PRINTF ("\ r\n 一旦接收到输入信号，就会打印出输入捕获值\ r\n ")； TPM_GetDefaultConfig(&tpmInfo)； /* 初始化 TPM 模块 */ TPM_Init(demo_tpm_baseaddr&tpmInfo）； /* 在 TPM 通道上设置输入捕获 */ TPM_SetupInputCapture(demo_tpm_baseaddr, TPM_SetupInputCapture(, kTPM_RisingEdge); /* 将计时器设置为自由运行模式 */ TPM_SetTimerPeriod(demo_tpm_baseaddr, tpm_max_counter_value(demo_tpm_baseaddr)); /* 检测到第二个边沿时启用通道中断 */ TPM_EnableInterrupts(demo_tpm_baseaddr, tpm_channel_interrupt_enable); /* 在 NVIC 启用 */ 启用 IRQ(tpm_interrupt_number); TPM_StartTimer(demo_tpm_baseaddr, kTPM_SystemClock); 虽然(1)     { tpmIsrFlag = 假; SendTrigPulse()； 当(!tpmIsrFlag) { __NOP ();//等待捕获      } 浮点数distance = CalculateDistance()； PRINTF("RisingTime :%u\r\n",risingTime）； PRINTF("FallingTime :%u\r\n",fallingTime）； PRINTF("Distance:%.2f cm\r\n"距离）； SDK_DelayAtLeastUs(60000,SystemCoreClock)；    } }   但是，我始终得到的距离值在 1228 厘米到 1260 厘米之间，这是不正常的大，即使在离传感器很近的地方有一堵墙（例如<50 厘米）也是如此。下面是一些阅读范例： TPM Clock : 24000000.00 RisingTime : 1172965159 FallingTime : 1174675524 Distance: 1228.71 cm TPM Clock : 24000000.00 RisingTime : 1283028325 FallingTime : 1284738837 Distance: 1228.82 cm TPM Clock : 24000000.00 RisingTime : 1448107508 FallingTime : 1449851665 Distance: 1252.99 cm TPM Clock : 24000000.00 RisingTime : 269392922 FallingTime : 269436317 Distance: 31.17 cm TPM Clock : 24000000.00 RisingTime : 278665048 FallingTime : 278708444 Distance: 31.18 cm TPM Clock : 24000000.00 RisingTime : 287937289 FallingTime : 287977974 Distance: 29.23 cm TPM Clock : 24000000.00 RisingTime : 297205949 FallingTime : 297248662 Distance: 30.68 cm TPM Clock : 24000000.00 RisingTime : 306477012 FallingTime : 306519726 Distance: 30.69 cm 我不知道为什么这些数值总是过大。 i.MX93EVK 时钟|计时器 Re: Why is TPM input capture returning large distance values (~12 meters) with 24 MHz TPM clock on i 谢谢您的答复！ Re: Why is TPM input capture returning large distance values (~12 meters) with 24 MHz TPM clock on i 你好 使用 TPM 输入捕获的 HC-SR04 超声波传感器的大距离值（约 12 米）通常源于信号的脉冲宽度测量不正确。传感器通过计时回波脉冲的持续时间来测量距离，如果测量包括触发信号或不准确，则可能导致距离读数膨胀。   以下是潜在原因和解决方案的详细介绍： 1。脉冲宽度测量不正确： 触发信号脉冲包括： 输入捕获可能捕获从触发脉冲的上升沿到回波脉冲下降沿的时间，而不仅仅是回波脉冲本身。   解决方案： 确保将输入捕获配置为仅测量回波脉冲的持续时间。这通常涉及将计时器设置为在回波信号的上升沿触发并捕获下降沿。   2.信号干扰： 早期回声检测 传感器的接收器可能会在发射器从物体反弹之前检测到信号，从而导致人为的脉冲宽度变长。   斜射反射 倾斜表面的反射会导致回声信号变弱或延迟，从而导致距离读数不准确。   解决方案： 屏蔽：在发射器和接收机上使用小管子或护罩，以最大限度地减少早期检测并改善信号方向性。   多次读数： 读取多个读数，过滤掉过大的数值或计算平均值。   NewPing 库： 考虑使用 NewPing 库，该库专门用于处理这些问题。 4.软件实施： 计时器配置： 不正确的计时器预分频器或时钟设置会影响脉冲宽度测量的精度。   Pings 之间的延迟： 传感器有一个最小间隔时间，超过这个时间会导致读数不准确。   解决方案： 检查定时器设置： 检查定时器的预分频器和时钟配置，确保时间测量准确。   适当的延迟：确保 ping 之间有足够的延迟，以使传感器能够 RESET 和稳定。     此致  

Unexpected VC_OV Events Below Threshold during Application Timed Measurement Hi,      I'm using the Application Timed Measurement mode with a sample rate of 24, and have set the over-voltage (OV) threshold at 4250 mV. However, during charging when the battery reaches around 80% SoC (approximately 4077 mV), some cells occasionally trigger VC_OV events. After manual measurement, the actual cell voltages do not exceed the OV threshold. What could cause this kind of behavior, where VC_OV events occur even though the measured voltage is clearly below the threshold? Thanks for any help. Mark 回复： Unexpected VC_OV Events Below Threshold during Application Timed Measurement Hi Mark, please download MC33774A safety manual and please refer to the sections 10., 11. in it. There is a description of FTME (Fault Tolerant Measurement Error) for such cases as yours. Please download the safety manual from the MC33774A product page, under the Secure section. With Best Regards, Jozef 回复： Unexpected VC_OV Events Below Threshold during Application Timed Measurement Hi Jozef, Thank you very much for your continued support. The hardware design has already been reviewed and confirmed by our local FAE. Since the MC33774A is already fully integrated into the battery module, we are unfortunately not able to directly probe the individual cell voltages with an oscilloscope. We also suspected that insufficient control of the charging current might be causing transient spikes, which in turn lead to sporadic over-voltage (OV) events. Your professional explanation has further confirmed our assumption that these events are likely caused by transient behavior. As a follow-up, we would like to ask: Are there any software-based methods you would recommend to help identify OV events caused specifically by transient spikes? Thank you again for your valuable assistance. best regards, Mark 回复： Unexpected VC_OV Events Below Threshold during Application Timed Measurement Hi Mark, thank you for the part number and the schematic. However in the schematic I don't see if you have used recommended components between the Cells and CTx CBx pins. For these recommended components please refer to the section 11.1.1.2 in the MC33774A full datasheet.  Please download the MC33774A full datasheet from the MC33774A product page, under the Secure section.  During fast charging, voltage transients can occur that briefly exceed the OV threshold. These spikes may not be captured by manual measurements but can be detected by the MC33774A. Please measure the voltages to individual cells triggering the OV with an oscilloscope, to check if there are any transient voltages. Please make sure, that balancing is not on during charging/measurement. During balancing the measured voltage is not guaranteed.  With Best Regards, Jozef 回复： Unexpected VC_OV Events Below Threshold during Application Timed Measurement Hi Jozef,    Thank you for your response.    Apologies for not providing sufficient information earlier.     we using MC33774ATP1AE. and here is the part Schematic.    Thanks for any help. best regards, Mark Re: Unexpected VC_OV Events Below Threshold during Application Timed Measurement Hi Mark, please share the full part number of the component you are using. Please share your schematic with voltage levels and part values. With Best Regards, Jozef

Jlink 调试 imx93 失败 使用 JLink 调试 i.MX93 的 M33 内核时，设置断点后，似乎只有 PC 指针停止，而各种内部计数器继续计数，导致无法正常调试。有什么办法可以解决这个问题？ Re: Jlink fails to debug imx93 是的，我在单个 M33 内核上试过，系统计数器不能像以前那样停止。我找不到原因。 顺祝商祺！ Re: Jlink fails to debug imx93 你好 @leoX 我的测试基于单个 M33 和 Jlink，你用 remoteproc 启动 M33 了吗？ 最诚挚的问候， 志明 Re: Jlink fails to debug imx93 谢谢您的答复！我正在读取一个任务中的 tstmr，以计算该任务的执行周期，但如果我添加一个断点，计算出的周期就会增加，这表明当我添加一个断点时，系统计数器会继续计数。此外，我正在通过 A 核心启动 M 核心。设置 M33 的下载模式是否有用？ 顺祝商祺！ Re: Jlink fails to debug imx93 你好， ，能否分享各种内部计数器 的截图？ 您是否设置了 m33 下载模式？ 最佳问候， Zhiming

RT1176 SFPD QSPI IS25LP064D-JKLE 我正在尝试使用与评估板相同的方式刷新实现 FlexSPI1 的自定义 RT1176 板，唯一的不同是我提供了 3.3V 的闪存 VCC 来支持我正在尝试使用的 IS25LP064D-JKLE。我附上了我的 flexspi_nor_config.c。和内存设置。我使用的是默认的 flexspi_nor_polling_transfer_cm7。当我在启用 “将应用程序链接到 RAM” 的情况下进行调试时，它返回 " 程序数据-读出的数据值不正确！"（第 125 行）。我还没弄清楚我的配置出了什么问题。我目前正在使用 MCU Link MR，但也可以访问 Jlink。我的自定义板有 DIP 开关，我将启动模式 1 设置为 1，启动模式 0 设置为 0。 Re: RT1176 SFPD QSPI IS25LP064D-JKLE 你好@AnteoJ、 感谢您对 NXP MIMXRT 系列的关注！ RT1020-EVK 使用的闪存恰好是 ISSI_IS25LP064A，因此您可以在其 SDK .NET 中找到相应的 flexspi_nor_config.c。请先检查这一点。 此外，在更换闪光灯时，你可以先通过高效密码学标准(SEC)/MCUBootUtility中内置模板的测试，这些模板能够保护你自己的闪光灯免受LUT问题的影响。 致以最诚挚的问候， Gavin Re: RT1176 SFPD QSPI IS25LP064D-JKLE 尽管我在启动调试时仍会遇到 IMPRECISERR 和 UNDEFINSTR，但我已根据数据手册对特定闪存的值进行了检查和替换。我不确定是否还有其他参数需要调整。以下是我目前的代码：/* * 版权所有 2018-2022 NXP * 保留所有权利。 * * SPDX-License-Identifier：BSD-3-Clause */ #include"evkbmimxrt1170_flexspi_nor_config.h" /* 元器件 ID 定义，由工具使用。*/ #ifndef FSL_COMPONENT_ID #define FSL_COMPONENT_ID"platform.drivers.xip_board" #endif /******************************************************************************* * 代码 ******************************************************************************/ #if defined(XIP_BOOT_HEADER_ENABLE)&& (XIP_BOOT_HEADER_ENABLE == 1) #if defined(__CC_ARM) || defined(__ARMCC_VERSION) || defined(__GNUC__) __attribute__ ((section(".boot_hdr.conf")、used)) #elif defined(__ICCARM__) #pragma location =".boot_hdr.conf" #endif #define FLASH_DUMMY_CYCLES 0x03 #define FLASH_DUMMY_VALUE 0x03 const flexspi_nor_config_t qspiflash_config = { .memConfig= { .tag= FLEXSPI_CFG_BLK_TAG， .version= FLEXSPI_CFG_BLK_VERSION， .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally、 .csHoldTime= 3u, .csSetupTime= 3u, // 启用 DDR 模式、可添加字、安全配置、差分时钟 .controllerMiscOption= 0x10， .deviceType= kFlexSpiDeviceType_SerialNOR， .sflashPadType= kSerialFlash_4Pads， .serialClkFreq= kFlexSpiSerialClk_60MHz， .sflashA1Size= 8u * 1024u * 1024u, /* 启用闪存配置功能 */ .configCmdEnable= 1u, .configModeType[0]= kDeviceConfigCmdType_Generic, /* 设置配置命令序列 */ .configCmdSeqs[0]= { .seqNum= 1, .seqId= 12， .保留= 0, }, /* 为闪存中的读取寄存器准备设置值 */ .configCmdArgs[0].= (FLASH_DUMMY_VALUE<< 4), .lookupTable= { // 读取 LUT [0] = FLEXSPI_LUT_SEQ(CMD_SDR，FLEXSPI_1PAD，0xEB，RADDR_SDR，FLEXSPI_4PAD，0x20)， [1] = FLEXSPI_LUT_SEQ(DUMMY_SDR，FLEXSPI_4PAD、FLASH_DUMMY_CYCLES, READ_SDR, FLEXSPI_4PAD, 0x04), // 读取状态 LUT [4 * 1 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR、FLEXSPI_1PAD, 0x04), // Write Enable LUTs [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x0)、 // 擦除扇区 LUT [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR，FLEXSPI_1PAD，0x20，RADDR_SDR，FLEXSPI_1PAD，0x18), // 擦除块 LUT [4 * 8 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR、FLEXSPI_1PAD, 0xD8, RADDR_SDR, FLEXSPI_1PAD, 0x18), // Pape Program LUTs [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD、0x02, RADDR_SDR, FLEXSPI_1PAD, 0x18), [4 * 9 + 1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x0)、 // 擦除芯片 LUT [4 * 11 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x60, STOP, FLEXSPI_1PAD, 0x0), // 设置读寄存器 LUT [4 * 12 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR、FLEXSPI_1PAD, 0xC0, WRITE_SDR, FLEXSPI_1PAD, 0x01), [4 * 12 + 1] = FLEXSPI_LUT_SEQ(STOP, FLEXSPI_1PAD, 0x00, 0, 0), }, }, .页面大小= 256u, .sectorSize= 4u * 1024u, .ipcmdSerialClkFreq= 0x1, .blockSize= 64u * 1024u, .isUniformBlockSize= false, }; #endif /* XIP_BOOT_HEADER_ENABLE */

RT1176 SFPD QSPI IS25LP064D-JKLE I am attempting to flash a custom RT1176 board that implements FlexSPI1 in the same manner as the eval board, except I have supplied flash VCC with 3.3V to support the IS25LP064D-JKLE I am trying to use. I have attached my flexspi_nor_config.c and memory setup. I am using the default flexspi_nor_polling_transfer_cm7. When I debug with Link Application to RAM Enabled, it returns "Program data - read out data value incorrect !" (line 125). I have yet to figure out what the issue is in my configuration. I am currently using an MCU Link MR, but also have access to a Jlink. My custom board has DIP Switches, and I have bootmode 1 set to 1 and bootmode 0 set to 0. Re: RT1176 SFPD QSPI IS25LP064D-JKLE Hi @AnteoJ , Thanks for your interest in NXP MIMXRT series! The flash used by the RT1020-EVK happens to be ISSI_IS25LP064A, so you can find the corresponding flexspi_nor_config.c in its SDK . Please check this first. Also, when replacing the flash you can first pass the tests of the built-in templates in SEC/MCUBootUtility, which are able to shield your own flash from LUT issues. Best regards, Gavin Re: RT1176 SFPD QSPI IS25LP064D-JKLE I have gone through and replaced values for my specific flash according to the datasheet although I still run into a IMPRECISERR and UNDEFINSTR when I start up debug. I am not sure if there are additional parameters that need to be adjusted. Here is my code so far: /* * Copyright 2018-2022 NXP * All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ #include "evkbmimxrt1170_flexspi_nor_config.h" /* Component ID definition, used by tools. */ #ifndef FSL_COMPONENT_ID #define FSL_COMPONENT_ID "platform.drivers.xip_board" #endif /******************************************************************************* * Code ******************************************************************************/ #if defined(XIP_BOOT_HEADER_ENABLE) && (XIP_BOOT_HEADER_ENABLE == 1) #if defined(__CC_ARM) || defined(__ARMCC_VERSION) || defined(__GNUC__) __attribute__((section(".boot_hdr.conf"), used)) #elif defined(__ICCARM__) #pragma location = ".boot_hdr.conf" #endif #define FLASH_DUMMY_CYCLES 0x03 #define FLASH_DUMMY_VALUE 0x03 const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally, .csHoldTime = 3u, .csSetupTime = 3u, // Enable DDR mode, Wordaddassable, Safe configuration, Differential clock .controllerMiscOption = 0x10, .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_60MHz, .sflashA1Size = 8u * 1024u * 1024u, /* Enable flash configuration feature */ .configCmdEnable = 1u, .configModeType[0] = kDeviceConfigCmdType_Generic, /* Set configuration command sequences */ .configCmdSeqs[0] = { .seqNum = 1, .seqId = 12, .reserved = 0, }, /* Prepare setting value for Read Register in flash */ .configCmdArgs[0] = (FLASH_DUMMY_VALUE << 4), .lookupTable = { // Read LUTs [0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x20), [1] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, FLASH_DUMMY_CYCLES, READ_SDR, FLEXSPI_4PAD, 0x04), // Read Status LUTs [4 * 1 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04), // Write Enable LUTs [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x0), // Erase Sector LUTs [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x20, RADDR_SDR, FLEXSPI_1PAD, 0x18), // Erase Block LUTs [4 * 8 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xD8, RADDR_SDR, FLEXSPI_1PAD, 0x18), // Pape Program LUTs [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x02, RADDR_SDR, FLEXSPI_1PAD, 0x18), [4 * 9 + 1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x0), // Erase Chip LUTs [4 * 11 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x60, STOP, FLEXSPI_1PAD, 0x0), // Set Read Register LUTs [4 * 12 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xC0, WRITE_SDR, FLEXSPI_1PAD, 0x01), [4 * 12 + 1] = FLEXSPI_LUT_SEQ(STOP, FLEXSPI_1PAD, 0x00, 0, 0, 0), }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .ipcmdSerialClkFreq = 0x1, .blockSize = 64u * 1024u, .isUniformBlockSize = false, }; #endif /* XIP_BOOT_HEADER_ENABLE */

lx2160a kernel 5.10.35 about spi mode Hi: I found that the default DSPI_TCF_MODE transmission is very slow. I want to speed up the SPI transmission, but I found that it seems that the DSPI_DMA_MODE transmission is not supported. When I change the mode to DSPI_EOQ_MODE, it will cause the kernel to crash. I would like to know what steps I should take to effectively speed up the transmission of data through SPI. My changes are as follows: in spi-fsl-dspi.c static const struct fsl_dspi_devtype_data ls2085a_data = { .trans_mode = DSPI_EOQ_MODE, .max_clock_factor = 8, }; Re: lx2160a kernel 5.10.35 about spi mode Please refer to Linux Kernel source code provide by NXP. https://github.com/nxp-qoriq/linux/blob/lf-5.10.y/drivers/spi/spi-fsl-dspi.c Only the following two modes are supported. enum dspi_trans_mode { DSPI_XSPI_MODE, DSPI_DMA_MODE, };   Please use DSPI_XSPI_MODE mode for lx2160a platform. [LX2160A] = { .trans_mode = DSPI_XSPI_MODE, .max_clock_factor = 8, .fifo_size = 4, },

S32G3 引导加载程序用上市 core0 和 Core1 恩智浦的工程师们，你们好 我目前正在调试启动加载程序，以启动 core0 和 core1。core0 可以从 RESET 中释放并可以启动，但是 core1 无法开始运行。 使用 UDE 调试工具，可以成功调出 core1。在我的引导加载程序 EB 配置中，我已经为 core0 和 core1 配置了 RESET 处理程序地址和加载地址。我该如何进一步调试？如何调试引导加载程序？ 我也在测试 IPCF_Example_multi_instance_S32G399A 项目，但这个项目的 core0 和 core1 都失败了。 谢谢。 Re: S32G3 Bootloader launch core0 and Core1 你好，@xlfd_1981 对您的不便，我深表歉意。 通常，在本社区板中，我们支持所有软件包的基本用法、恩智浦提供的硬件配置，此外，我们支持在软件包中使用演示/示例代码时直接出现的问题等。 对于特定或定制需求，我们通常建议通过 support.nxp.com 提交支持票据，因为这是一个私人渠道，更便于共享代码/项目。 目前，没有这样的演示可以直接支持你的要求，只有 AN1350 中的代码有点相似，但它也涉及 A53 内核，可以禁用 A53 部分来模拟你的请求，不确定你是否参考了它。 对于您的状态，为了直接帮助您调试问题，我建议您直接通过 support.nxp.com 发起私人票据，然后共享您的启动加载程序和应用程序（M7_0 和 M7_1），我们可以帮助您检查。 BR 切宁 Re: S32G3 Bootloader launch core0 and Core1 恩智浦专家 已经过去很多天了，我的问题仍然没有得到答复。现在让我们把问题简单化：请提供一个可以使用引导加载程序同时启动 core0 和 core1 的演示程序。我需要引导程序项目和应用程序项目。另外，请告诉我生成 blob 文件是否有任何特殊要求。我将使用您的演示来验证 core0 和 core1 能否正常启动。 我现在面临的问题是，core1 的映像可以加载，但 core1 就是无法启动。我不知道问题出在启动代码上，还是根本没有触发 core1。也没有寄存器可用于检查是否启动。请提供演示和建议以帮助我。这一点非常紧迫。非常感谢。 Re: S32G3 Bootloader launch core0 and Core1 你好，@xlfd_1981 感谢您的回复。 我能知道你是怎么创建 IVT 的，你在尝试从 QSPI 启动时加入了 DCD 吗？ 我不太清楚您的设计，您是否使用引导加载器（M7_0）加载 core0.bin 和 core1.bin（IPCF）？实例）到相应的核心，还是其他类型的实现？ BR 切宁 Re: S32G3 Bootloader launch core0 and Core1 澄阴 我将调试结果更新如下、 可能与启动程序有关。使用 UDE 调试时，ELF 文件被下载到内存中，我们可以看到 Core1 区域有有效数据。然而，在电源循环（系统从运行引导加载程序代码的闪存启动）后，使用 UDE 观察 Core1 内存区域，我们发现数据已被清零。这可能是引导程序造成的吗？ 此致 Re: S32G3 Bootloader launch core0 and Core1 澄阴 此外，请查看我的 IPCF 代码、 将被编译为 core0.bin 和 core1.bin Re: S32G3 Bootloader launch core0 and Core1 切宁 我们目前正在RDB3 平台上开发基于您的IPCF 多核演示（v4.10.0）的引导加载程序。我们在Core1的启动过程中遇到了问题，感谢您的帮助。 当前设置： 我们的引导加载程序是根据您的演示项目（UM_BOOTLOADER_Rev_2023.02）开发的，并通过 EB 进行配置。 使用 UDE 调试时： 数据同时存在于 Core0 和 Core1 内存区域中 代码成功跳转到 Core0 的 Reset_Handler 然而，我们注意到 Core1 使用的 SRAM 区域（如 0x34680000）清零 因此，Core1 无法启动 问题 谁触发信号了这个 SRAM 清除？ 它是由 UDE 引起的吗？ 还是这是 RESET 行为的一部分？ 会不会是启动程序中的某些初始化代码造成的？ 此外，在函数 Sys_StartSecondaryCores()中，我们设置了 IP_MC_ME->PRTN0_CORE1_ADDR = 0x34780000; 请确认该地址应指向何处： 是否应该是 SRAM 中 Core1 映像的 加载地址 （即 .intc_vector 的位置）？ 还是应该是 向量表偏移量 (VTOR)？ 我们的链接器脚本显示 .intc_vector 位于 0x34780400，而图像从 0x34680000 开始。 非常感谢你们的支持！ 如有需要，我可以提供 .map文件、.ld脚本或截图，以便进一步分析。 顺祝商祺！ Re: S32G3 Bootloader launch core0 and Core1 你好，@xlfd_1981 谢谢您的帖子。 您能否提供更多有关测试的信息？ 1.它是在 S32G3 定制板上完成的，还是在 NXP 的 RDB3/EVB3 上完成的？ 2.引导加载程序来自哪里？是定制的还是恩智浦的？如果是恩智浦的，是哪个版本？ 3.文中提到使用了 core0&1，请问它们是 M7_0 和 M7_1 还是其他组合？ 通常，引导加载程序运行在 M7_0 上，可以直接使用调试器进行调试，这与其他 M7 应用程序并无不同。 BR 切宁

NTAG 424 更改密钥 0 后无法登录 大家好， 我遇到了一个无法解决的奇怪问题。我完成了为网络安全平台配置 #NTAG424 的所有步骤：一切都很好，但还有最后一件事 我不得不更改所有 5 个按键，并从这个"循环" 开始，将 4 改为 0： 使用密钥 0 登录 更改按键 X 我知道更改 K0 与更改 K4-1 是不同的，而响应是 91-00，因此似乎一切正常。 现在的问题是：我可以用所有 Kyes 4-1 登录，但用 K0 登录第 2 部分时会出现 91-AE。 我想可能是加密出错了，所以密钥和我想的不一样，但我检查了很多次代码都没问题。我只是根据数据表和 AN12196 更改了密码计算。 有什么提示吗？ 谢谢 Re: NTAG 424 no login possible after key 0 change 您好@MPucci, 在您的帖子中是否已经实现了 ChangeKey 0 和 1-4？我目前正在实施，但遇到了一些问题。我无法成功修改 Key1-4 以响应 911E，而修改 Key0 后，验证响应是 91AE。我想寻求您的帮助，不胜感激。 Re: NTAG 424 no login possible after key 0 change 你好@KaiLi 我在 AN12196 中没有看到 6.16.2。是因为文件版本不同吗？ 有什么提示吗？ 谢谢！ Re: NTAG 424 no login possible after key 0 change 你好@MPucci 根据您的问题描述，建议您尝试 AN12196 第 6.16.2 章中的步骤。例如 1.通过密钥进行身份验证No 0x00 2. 输入新建键 3. 执行 ChangeKey 命令 4. 重复检查使用新密钥验证 NTAG424 的情况。 BR 凯利 Re: NTAG 424 no login possible after key 0 change 更多信息：我知道这样做不对，但在更改密钥之前，我在所有登录中都使用了相同的 RndA。我无法确定问题的根源，但如果我在登录时使用 5 个不同的 RndA，密钥（甚至 K0）不会出现问题，但如果我在登录时使用相同的 RndA，K0 就会损坏。 所以现在问题解决了，但还不知道原因。

How to Build & Test OPTEE on iMX91 processor Hi,    I am trying to understand the OPTEE functionality. Requesting support on following:    1. OPTEE documentation/ tutorial w.r.t. iMX91    2. How to Build & Test OPTEE on iMX91 processor with YOCTO.    Currently I have a YOCTO base developed from  -  repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-styhead -m imx-6.12.3-1.0.0_security-reference-design.xml Please find below the list of files generated from it ls tmp/deploy/images/imx91-11x11-lpddr4-evk ├── bl31-imx91.bin ├── bl31-imx91.bin-optee ├── core-image-base.env ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.manifest ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.spdx.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.testdata.json ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.bmap ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.manifest -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.manifest ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.spdx.tar.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.spdx.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.tar.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.testdata.json -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.testdata.json ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.wic.bmap -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.bmap ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.wic.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.zst ├── core-image-base-imx-imx-boot-bootpart.wks ├── core-image-minimal-secure-boot.env ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.manifest ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.spdx.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.testdata.json ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.bmap ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.manifest -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.manifest ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.spdx.tar.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.spdx.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.tar.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.testdata.json -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.testdata.json ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.wic.bmap -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.bmap ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.wic.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.zst ├── core-image-minimal-secure-boot-imx-imx-boot-bootpart.wks ├── files.txt ├── flash.bin ├── flash_os.bin ├── Image -> Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── Image-imx91-11x11-lpddr4-evk.bin -> Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── imx91-11x11-evk--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk.dtb ├── imx91-11x11-evk-aud-hat--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk-aud-hat-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk.dtb ├── imx91-11x11-evk-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk.dtb ├── imx91-11x11-evk-ld--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-ld-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-lpuart--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-lpuart-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-mt9m114--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-mt9m114-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-tianma-wvga-panel--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx91-11x11-evk-tianma-wvga-panel-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx-boot -> imx-boot-tagged ├── imx-boot-imx91-11x11-lpddr4-evk-sd.bin-flash_singleboot ├── imx-boot-tagged ├── imx-boot.tagged ├── imx-boot-tools │ ├── bl31-imx91.bin │ ├── bl31-imx91.bin-optee │ ├── csf_ahab.cfg.sample │ ├── csf_hab4.cfg.sample │ ├── imx_signer │ ├── lpddr4_dmem_1d_v202201.bin │ ├── lpddr4_dmem_2d_v202201.bin │ ├── lpddr4_imem_1d_v202201.bin │ ├── lpddr4_imem_2d_v202201.bin │ ├── mkimage_imx8 │ ├── mx91a0-ahab-container.img │ ├── soc.mak │ ├── spsdk_ahab.cfg.sample │ ├── tee.bin │ ├── u-boot-imx91-11x11-lpddr4-evk.bin-sd │ └── u-boot-spl.bin-imx91-11x11-lpddr4-evk-sd ├── imx-boot-untagged ├── lpddr4_dmem_1d_v202201.bin ├── lpddr4_dmem_2d_v202201.bin ├── lpddr4_imem_1d_v202201.bin ├── lpddr4_imem_2d_v202201.bin ├── modules--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.tgz ├── modules-imx91-11x11-lpddr4-evk.tgz -> modules--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.tgz ├── mx91a0-ahab-container.img ├── optee │ ├── ta │ │ ├── 023f8f1a-292a-432b-8fc4-de8471358067.elf │ │ ├── 023f8f1a-292a-432b-8fc4-de8471358067.stripped.elf │ │ ├── 02a42f43-d8b7-4a57-aa4d-87bd9b5587cb.elf │ │ ├── 02a42f43-d8b7-4a57-aa4d-87bd9b5587cb.stripped.elf │ │ ├── 25497083-a58a-4fc5-8a72-1ad7b69b8562.elf │ │ ├── 25497083-a58a-4fc5-8a72-1ad7b69b8562.stripped.elf │ │ ├── 380231ac-fb99-47ad-a689-9e017eb6e78a.elf │ │ ├── 380231ac-fb99-47ad-a689-9e017eb6e78a.stripped.elf │ │ ├── 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.elf │ │ ├── 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.stripped.elf │ │ ├── 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.elf │ │ ├── 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.stripped.elf │ │ ├── 5c206987-16a3-59cc-ab0f-64b9cfc9e758.elf │ │ ├── 5c206987-16a3-59cc-ab0f-64b9cfc9e758.stripped.elf │ │ ├── 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.elf │ │ ├── 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.stripped.elf │ │ ├── 731e279e-aafb-4575-a771-38caa6f0cca6.elf │ │ ├── 731e279e-aafb-4575-a771-38caa6f0cca6.stripped.elf │ │ ├── 80a4c275-0a47-4905-8285-1486a9771a08.elf │ │ ├── 80a4c275-0a47-4905-8285-1486a9771a08.stripped.elf │ │ ├── 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.elf │ │ ├── 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.stripped.elf │ │ ├── 8aaaf200-2450-11e4-abe20002a5d5c51c.elf │ │ ├── 8aaaf200-2450-11e4-abe20002a5d5c51c.stripped.elf │ │ ├── a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.elf │ │ ├── a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.stripped.elf │ │ ├── a720ccbb-51da-417d-b82e-e5445d474a7a.elf │ │ ├── a720ccbb-51da-417d-b82e-e5445d474a7a.stripped.elf │ │ ├── b3091a65-9751-4784-abf7-0298a7cc35ba.elf │ │ ├── b689f2a7-8adf-477a-9f99-32e90c0ad0a2.elf │ │ ├── b689f2a7-8adf-477a-9f99-32e90c0ad0a2.stripped.elf │ │ ├── c3f6e2c0-3548-11e1-b86c-0800200c9a66.elf │ │ ├── c3f6e2c0-3548-11e1-b86c-0800200c9a66.stripped.elf │ │ ├── cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.elf │ │ ├── cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.stripped.elf │ │ ├── d17f73a0-36ef-11e1-984a-0002a5d5c51b.elf │ │ ├── d17f73a0-36ef-11e1-984a-0002a5d5c51b.stripped.elf │ │ ├── e13010e0-2ae1-11e5-896a-0002a5d5c51b.elf │ │ ├── e13010e0-2ae1-11e5-896a-0002a5d5c51b.stripped.elf │ │ ├── e6a33ed4-562b-463a-bb7e-ff5e15a493c8.elf │ │ ├── e6a33ed4-562b-463a-bb7e-ff5e15a493c8.stripped.elf │ │ ├── f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.elf │ │ ├── f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.stripped.elf │ │ ├── f157cda0-550c-11e5-a6fa-0002a5d5c51b.elf │ │ ├── f157cda0-550c-11e5-a6fa-0002a5d5c51b.stripped.elf │ │ ├── fd02c9da-306c-48c7-a49c-bbd827ae86ee.elf │ │ ├── fd02c9da-306c-48c7-a49c-bbd827ae86ee.stripped.elf │ │ └── ffd2bded-ab7d-4988-95ee-e4962fff7154.elf │ ├── tee.bin │ ├── tee.elf │ ├── tee-header_v2.bin │ ├── tee.mx91evk.bin │ ├── tee-pageable_v2.bin │ ├── tee-pager_v2.bin │ └── tee-raw.bin ├── os_cntr_signed.bin ├── signed-imx-boot-imx91-11x11-lpddr4-evk-sd.bin-flash_singleboot ├── tee.bin -> optee/tee.mx91evk.bin ├── u-boot.bin -> u-boot-sd-2024.04-r0.bin ├── u-boot.bin-sd -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx91-11x11-lpddr4-evk.bin -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx91-11x11-lpddr4-evk.bin-sd -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd -> u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-imx-initial-env-sd -> u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-sd-2024.04-r0.bin ├── u-boot-spl.bin -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-imx91-11x11-lpddr4-evk -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-imx91-11x11-lpddr4-evk-sd -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-sd -> u-boot-spl.bin-sd-2024.04-r0 └── u-boot-spl.bin-sd-2024.04-r0 4 directories, 153 files Thx, Kiran Re: How to Build & Test OPTEE on iMX91 processor Hi @KiranM7! Thank you for contacting NXP Support! OP-TEE is enabled by default in our BSP. While we currently do not have an official guide for running optee-test, you can refer to the official OP-TEE documentation for detailed instructions: optee_test Best regards, Chavira

OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi all, I'm trying to integrate the SE050 to be used in a node.js webserver. I successfully compiled the middleware including the OpenSSL provider and also got the ssscli to work. With ssscli I created a keypair, injected it into the SE and created a refpem key. I also adapted the openssl.cnf of the system to match the one in simwtop/demos/linux/common/openssl30_sss_se050.cnf. But any TLS connection to the server fails in the handshake as OpenSSL uses the reference to the key slot as actual private key instead of calling the SE050 provider. I also tried to get it to work with OpenSSL CLI, i.e., openssl s_server. I can get a connection using the nxp: scheme but not using the refpem key file. The following command leads to the error: openssl s_server -accept 12345 -cert server.pem -key server.refpem.key -CAfile root.pem  Error: SSL3 alert read:fatal:decrypt error SSL_accept:error in error ERROR 20203CA4FFFF0000:error:1B80006E:lib(55):ossl_parse_query:trailing characters:../openssl-3.0.13/crypto/property/property_parse.c:454:HERE-->/usr/lib/libsssProvider.so 20203CA4FFFF0000:error:0A00041B:SSL routines:ssl3_read_bytes:tlsv1 alert decrypt error:../openssl-3.0.13/ssl/record/rec_layer_s3.c:1590:SSL alert number 51 shutting down SSL If I use the nxp url scheme, though, I can successfully connect to the server. openssl s_server -accept 12345 -cert server.pem -key nxp:0x6789ABCD -CAfile root.pem However, I can't specify the nxp:0x6789ABCD key reference in the node.js code but have to use the refpem file. Is there anyway to do that? I also tried to make OpenSSL prioritize the SE050 provider over the default one by specifiying a propquery in the config file. But no luck so far. # Relevant parts from openssl.cnf [openssl_init] providers = provider_sect alg_section = evp_properties [provider_sect] default = default_sect nxp_prov = nxp_prov_sec [default_sect] activate = 1 [nxp_prov_sec] identity = nxp_prov module = /usr/local/lib/libsssProvider.so activate = 1 [evp_properties] default_properties = ?provider=nxp_prov Any help would be highly appreciated! SE050 Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working I forgot to mention that the Node version I'm using is 20.12.2. Versions later than 20.x may not have this issue, I have no way to verify this at this time. After further investigation, it emerged that the client-side decryption issue was caused by an incorrect provider loading order. That said, it turns out that this version of Node has a problematic handling of random number generation. The problem is related to how Node initializes providers. Specifically, in the initialization of the random generators, which leads to an infinite loop of calls to sss_rand_get_ctx_params. The node.cc file contains a fix (with a comment in the source), but it doesn't work with libsssProvider.so. I'm sharing a series of workarounds in case anyone finds themselves in a similar situation. I'll start by saying that these are all related to the libsssProvider and are primarily intended to NOT change Node or OpenSSL, so other much cleaner solutions are obviously possible. I can't share the code; I hope the information below is clear enough. Available options: 1. In the CMakeLists.txt file, set the SSS_PROV_DISABLE_SE05X_RNG variable. This completely disables the use of SE05X for randoms. It's not ideal, but if you don't have any special needs, it works. 2. In the sssProvider_main.c file, change the algorithms of the srands structure so that the name provided is NOT one of the known ones (and especially NOT the default). This still makes it possible to use the SE05X random module if needed, by setting the random key in the openssl config file. 3. Similar to point 2, but in this case the name is optionally provided with an environment variable (srands obviously can't be constant). This way, only in the case of Node applications you can avoid using the SE05X random generator, leaving it active for other uses instead. The refpems work correctly with these options. Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working I am experiencing the same exact problem of @tksec. If using OpenSSL cli tools everything is fine, I can establish a TLS connection that uses a key in the SE052 module via libsssProvider.so. On Node.js, I verified that libsssProvider is loaded, but handshake always fails, as per error below: SSL3 alert write:fatal:decrypt error SSL_connect:error in error 20109DB6FFFF0000:error:0A00007B:SSL routines:tls_process_cert_verify:bad signature:/usr/src/debug/openssl/3.2.1/ssl/statem/statem_lib.c:584: It seems that referring the key by id as suggested by @Kan_Li  does not actually work: -  If I provide in options.key the path to the refpem file, server starts w/o issues and listens for connections, but handshake fails as reported. - If I provide in options.key the key path as urk (nxp: ) applications crashes - If I provide in options.key the key reference (nxp: ) applications crashes So, can you @Kan_Li  please share a piece of Node.js code that can successfully initialize a server, assuming that, as stated, this should just work fine? Thanks Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @tksec, have you found a suitable way to use the key reference in node.js? I have a similar issue. I am using the se05x-openssl-provider (v01.00.03) with OpenSSL 3.0.14 to generate a key pair, but I am unable to use "Reference Keys in file format" as described in the Readme-File of the Github Repo of the openssl provider. The other two versions (Labels with reference key (Example - nxp:"path to reference key file") and Labels with key id (Example - nxp:0x12345678) just work fine. The Readme says the following: "NOTE: When using this method, the sss provider has to be loaded first. This will ensure that the sss provider can decode the key id information present in the reference key." Unfortunately, I don't know how to do this. Loading the provider by adding it to the openssl.cnf file did not work for me. I still get an decrypt error if I want to use the Reference Key in file format. Thank you in advance. Best regards Thomas Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @tksec , Thanks for the information! What is the use case you are using with refpem file? sign&verify? I may try to reproduce this issue here. Best Regards, Kan Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @Kan_Li , yes, I used the ssscli tool. I'm running MW v4.05.00. I created the original key with OpenSSL on a different system. Loaded it into SE using ssscli set command and created the refpem with ssscli refpem command. The key can successfully be used and parsed when using the openssl commands like s_client, s_server, rsa, etc. It can also be converted to a EVP_PKEY using OSSL_STORE API (what the openssl commands do internally) but it fails to parse using PEM_read_bio_PrivateKey which is used by both the NXP engine (in EmbSe_LoadPrivKey) and node.js. Thanks! Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @tksec , How did you generate the refpem for RSA key? by the tool of ssscli? which version of MW are you using now? Please kindly clarify. Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @Kan_Li  thanks for clarifying that the refpem key is only useable for the openssl engine. The issue with node.js in particular is that they call the PEM_read_bio_PrivateKey function directly on any key string that is provided, which obviously fails when the key string is not a PEM string or file path but a uri. There is no direct support for OpenSSL providers, yet. I reverted back to using the OpenSSL engine instead and got into similar problems. While using an EC key is working perfectly, using an RSA key fails again while parsing the PEM file with error:1E08010C:DECODER routines::unsupported from OpenSSL. I debugged the code and could trace the error back to the function PEM_read_bio_PrivateKey which is called from within EmbSe_LoadPrivKey in the engine's code. Are you aware of such an issue to handle an RSA refpem key in the OpenSSL engine? How can this be solved? For me it looks like the refpem is more invasive for RSA than it is for EC keys which might be an issue? Re: OpenSSL doesn't handle refpem key correctly, nxp scheme is working Hi @tksec , The refpem key file is only for openssl engine, but since you use openssl 3.xx with provider, please use "nxp:key_id" instead. You may compare "se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient.sh" with "se05x_mw_v04.05.01\simw-top\demos\linux\tls_client\scripts\tlsSeClient_3_0.sh" to check the difference.  and I am also wondering if you have any security concern regarding this, actually from my option, it is just a string should be accepted by most of the scripts, why not able to specify the nxp:0x6789ABCD key reference in the node.js code? Please kindly clarify. Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

iMXRT10xx SDK MCUBoot version Hi, I'm using the iMXRT1021 MCU with MCUXpresso SDK 24.12.00 and MCUBoot as middelware component from SDK. Is there a way to know which MCUBoot version is included with SDK? I searched in code but no version is defined for MCUBoot... Thanks! Re: iMXRT10xx SDK MCUBoot version Hi! Just found in SDK documentation the MCUBoot Release Notes: it should be 2.0.0 MCUboot release notes — MCUXpresso SDK Documentation

推荐使用 MX8QM PMIC 我正在规划一个基于 MX8QM 处理器的设计。我们将使用以下接口 A72 2x 内核 PCIe 接口 eMMC 接口 以太网接口 我们不会使用 GPU、VPU 和显示器等。 在 PMIC 选择页面上，https://www.nxp.com/products/power-management/pmics-and-sbcs:POWR_MAN_USER_INTERFACE 推荐的设备是 PF81-PF82，根据产品页面，不推荐使用。 那么推荐的设备是什么？ 我们可以使用PCA9450C 吗？ 此致 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Re: MX8QM recommended PMIC 你好 遗憾的是，恩智浦没有 PF81-PF82 的替换零件编号。 我建议您寻找第三方解决方案： 针对恩智浦 i.MX8 QuadMax 处理器的集成电源设计 此外，PCA9450 PMIC 与 i.MX8QM 不兼容，因为与 i.MX8MN/M/P 处理器相比，PCA9450 PMIC 需要更高的电流功耗和不同的上电/断电顺序。 请记住，在 2034 年 5 月之前，PF81-PF82 产品系列是我们的长寿计划的一部分 顺祝商祺！

iMXRT10xx SDK MCUBoot バージョン こんにちは、 私は、iMXRT1021 MCU を MCUXpresso SDK 24.12.00 と、SDK からのミドルウェア コンポーネントとして MCUBoot とともに使用しています。 SDKs に含まれている MCUBoot のバージョンを確認する方法はありますか? コードで検索しましたが、MCUBoot のバージョンは定義されていません... よろしくお願いします！ Re: iMXRT10xx SDK MCUBoot version こんにちは！ SDKドキュメントのMCUBootリリースノートで見つけました: 2.0.0のはずです MCUboot リリースノート — MCUXpresso SDK ドキュメント

带 ATF 调整时钟的 S32G Linux 用于扩频 你好 Linux 电路板支持包 团队， 客户询问了有关如何调整带有 ATF 的 Linux 电路板支持包中的时钟扩频设置的指南。 我检查了最新的 S32G 电路板支持包，找不到以下与时钟扩频相关的锁相环频率调制 (PLLFM) 寄存器配置。 我的问题是，我们有计划在 Linux 电路板支持包 中添加这种支持吗？ BRs， 天祥 Linux BSP Re: S32G Linux with ATF adjust clock for spread spectrum 理论上，扩频只能在 1516MHz（DS 值略低于 1600MHz）的频率下工作，因为它不能向下扩频，否则就意味着要对 DDR 进行超频，而法雷奥则决定将 DDR 频率提高到 1590MHz（更接近 1600MHz），因为它比 SS 更容易实现。但由于 1590MHz 不在 DS 和校准工具中，因此风险自负。下面是这篇文章： [S32G]将 DDR 频率改为 1590MHz，并使用 20 欧元的 SDR 加密狗测量结果 Re: S32G Linux with ATF adjust clock for spread spectrum 你好，根纳迪 知道了，谢谢你的快速确认。 BRs， 天祥 Re: S32G Linux with ATF adjust clock for spread spectrum 你好@Tianxiang_Huang、 目前还不支持用于 DDR PLL 频率调制的时钟扩频，也不打算在短期内添加。如果这与一个或多个客户相关，则需要详细的变更申请。请注意，鉴于 TF-A 集成了该工具生成的代码，因此任何与 DDR 相关的更改都必须与 DDR 工具同步。 此致， 根纳迪

如何在 iMX91 处理器上版本 & 测试 OPTEE 您好， 我想了解 OPTEE 的功能。请求在以下方面提供支持 1.有关 OPTEE 的文件/教程iMX91 2.如何使用 YOCTO 在 iMX91 处理器上版本 & 测试 OPTEE。 目前，我有一个 YOCTO 基础，它是由--......开发的。 仓库 init-u https://github.com/nxp-imx/imx-manifest-b imx-linux-styhead -m imx-6.12.3-1.0.0_security-参考设计.xml 下面是由它生成的文件列表 ls tmp/deploy/images/imx91-11x11-lpddr4-evk ├── bl31-imx91.bin ├── bl31-imx91.bin-optee ├── core-image-base.env ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.manifest ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.spdx.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.testdata.json ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.bmap ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.manifest -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.manifest ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.spdx.tar.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.spdx.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.tar.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.tar.zst ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.testdata.json -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.testdata.json ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.wic.bmap -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.bmap ├── core-image-base-imx91-11x11-lpddr4-evk.rootfs.wic.zst -> core-image-base-imx91-11x11-lpddr4-evk.rootfs-20250630102959.wic.zst ├── core-image-base-imx-imx-boot-bootpart.wks ├── core-image-minimal-secure-boot.env ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.manifest ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.spdx.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.testdata.json ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.bmap ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.manifest -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.manifest ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.spdx.tar.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.spdx.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.tar.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.tar.zst ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.testdata.json -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.testdata.json ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.wic.bmap -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.bmap ├── core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs.wic.zst -> core-image-minimal-secure-boot-imx91-11x11-lpddr4-evk.rootfs-20250627055427.wic.zst ├── core-image-minimal-secure-boot-imx-imx-boot-bootpart.wks ├── files.txt ├── flash.bin ├── flash_os.bin ├── Image -> Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── Image-imx91-11x11-lpddr4-evk.bin -> Image--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.bin ├── imx91-11x11-evk--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk.dtb ├── imx91-11x11-evk-aud-hat--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk-aud-hat-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-aud-hat.dtb ├── imx91-11x11-evk.dtb ├── imx91-11x11-evk-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk.dtb ├── imx91-11x11-evk-ld--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-ld-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-ld.dtb ├── imx91-11x11-evk-lpuart--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-lpuart-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-lpuart.dtb ├── imx91-11x11-evk-mt9m114--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-mt9m114-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-mt9m114.dtb ├── imx91-11x11-evk-tianma-wvga-panel--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.dtb -> imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx91-11x11-evk-tianma-wvga-panel-imx91-11x11-lpddr4-evk.dtb -> imx91-11x11-evk-tianma-wvga-panel.dtb ├── imx-boot -> imx-boot-tagged ├── imx-boot-imx91-11x11-lpddr4-evk-sd.bin-flash_singleboot ├── imx-boot-tagged ├── imx-boot.tagged ├── imx-boot-tools │ ├── bl31-imx91.bin │ ├── bl31-imx91.bin-optee │ ├── csf_ahab.cfg.sample │ ├── csf_hab4.cfg.sample │ ├── imx_signer │ ├── lpddr4_dmem_1d_v202201.bin │ ├── lpddr4_dmem_2d_v202201.bin │ ├── lpddr4_imem_1d_v202201.bin │ ├── lpddr4_imem_2d_v202201.bin │ ├── mkimage_imx8 │ ├── mx91a0-ahab-container.img │ ├── soc.mak │ ├── spsdk_ahab.cfg.sample │ ├── tee.bin │ ├── u-boot-imx91-11x11-lpddr4-evk.bin-sd │ └── u-boot-spl.bin-imx91-11x11-lpddr4-evk-sd ├── imx-boot-untagged ├── lpddr4_dmem_1d_v202201.bin ├── lpddr4_dmem_2d_v202201.bin ├── lpddr4_imem_1d_v202201.bin ├── lpddr4_imem_2d_v202201.bin ├── modules--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.tgz ├── modules-imx91-11x11-lpddr4-evk.tgz -> modules--6.6.36+git0+d23d64eea5-r0-imx91-11x11-lpddr4-evk-20250627055427.tgz ├── mx91a0-ahab-container.img ├── optee │ ├── ta │ │ ├── 023f8f1a-292a-432b-8fc4-de8471358067.elf │ │ ├── 023f8f1a-292a-432b-8fc4-de8471358067.stripped.elf │ │ ├── 02a42f43-d8b7-4a57-aa4d-87bd9b5587cb.elf │ │ ├── 02a42f43-d8b7-4a57-aa4d-87bd9b5587cb.stripped.elf │ │ ├── 25497083-a58a-4fc5-8a72-1ad7b69b8562.elf │ │ ├── 25497083-a58a-4fc5-8a72-1ad7b69b8562.stripped.elf │ │ ├── 380231ac-fb99-47ad-a689-9e017eb6e78a.elf │ │ ├── 380231ac-fb99-47ad-a689-9e017eb6e78a.stripped.elf │ │ ├── 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.elf │ │ ├── 528938ce-fc59-11e8-8eb2-f2801f1b9fd1.stripped.elf │ │ ├── 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.elf │ │ ├── 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.stripped.elf │ │ ├── 5c206987-16a3-59cc-ab0f-64b9cfc9e758.elf │ │ ├── 5c206987-16a3-59cc-ab0f-64b9cfc9e758.stripped.elf │ │ ├── 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.elf │ │ ├── 5ce0c432-0ab0-40e5-a056-782ca0e6aba2.stripped.elf │ │ ├── 731e279e-aafb-4575-a771-38caa6f0cca6.elf │ │ ├── 731e279e-aafb-4575-a771-38caa6f0cca6.stripped.elf │ │ ├── 80a4c275-0a47-4905-8285-1486a9771a08.elf │ │ ├── 80a4c275-0a47-4905-8285-1486a9771a08.stripped.elf │ │ ├── 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.elf │ │ ├── 873bcd08-c2c3-11e6-a937-d0bf9c45c61c.stripped.elf │ │ ├── 8aaaf200-2450-11e4-abe20002a5d5c51c.elf │ │ ├── 8aaaf200-2450-11e4-abe20002a5d5c51c.stripped.elf │ │ ├── a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.elf │ │ ├── a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.stripped.elf │ │ ├── a720ccbb-51da-417d-b82e-e5445d474a7a.elf │ │ ├── a720ccbb-51da-417d-b82e-e5445d474a7a.stripped.elf │ │ ├── b3091a65-9751-4784-abf7-0298a7cc35ba.elf │ │ ├── b689f2a7-8adf-477a-9f99-32e90c0ad0a2.elf │ │ ├── b689f2a7-8adf-477a-9f99-32e90c0ad0a2.stripped.elf │ │ ├── c3f6e2c0-3548-11e1-b86c-0800200c9a66.elf │ │ ├── c3f6e2c0-3548-11e1-b86c-0800200c9a66.stripped.elf │ │ ├── cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.elf │ │ ├── cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.stripped.elf │ │ ├── d17f73a0-36ef-11e1-984a-0002a5d5c51b.elf │ │ ├── d17f73a0-36ef-11e1-984a-0002a5d5c51b.stripped.elf │ │ ├── e13010e0-2ae1-11e5-896a-0002a5d5c51b.elf │ │ ├── e13010e0-2ae1-11e5-896a-0002a5d5c51b.stripped.elf │ │ ├── e6a33ed4-562b-463a-bb7e-ff5e15a493c8.elf │ │ ├── e6a33ed4-562b-463a-bb7e-ff5e15a493c8.stripped.elf │ │ ├── f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.elf │ │ ├── f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c.stripped.elf │ │ ├── f157cda0-550c-11e5-a6fa-0002a5d5c51b.elf │ │ ├── f157cda0-550c-11e5-a6fa-0002a5d5c51b.stripped.elf │ │ ├── fd02c9da-306c-48c7-a49c-bbd827ae86ee.elf │ │ ├── fd02c9da-306c-48c7-a49c-bbd827ae86ee.stripped.elf │ │ └── ffd2bded-ab7d-4988-95ee-e4962fff7154.elf │ ├── tee.bin │ ├── tee.elf │ ├── tee-header_v2.bin │ ├── tee.mx91evk.bin │ ├── tee-pageable_v2.bin │ ├── tee-pager_v2.bin │ └── tee-raw.bin ├── os_cntr_signed.bin ├── signed-imx-boot-imx91-11x11-lpddr4-evk-sd.bin-flash_singleboot ├── tee.bin -> optee/tee.mx91evk.bin ├── u-boot.bin -> u-boot-sd-2024.04-r0.bin ├── u-boot.bin-sd -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx91-11x11-lpddr4-evk.bin -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx91-11x11-lpddr4-evk.bin-sd -> u-boot-sd-2024.04-r0.bin ├── u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd -> u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-imx-initial-env-sd -> u-boot-imx-initial-env-imx91-11x11-lpddr4-evk-sd-2024.04-r0 ├── u-boot-sd-2024.04-r0.bin ├── u-boot-spl.bin -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-imx91-11x11-lpddr4-evk -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-imx91-11x11-lpddr4-evk-sd -> u-boot-spl.bin-sd-2024.04-r0 ├── u-boot-spl.bin-sd -> u-boot-spl.bin-sd-2024.04-r0 └── u-boot-spl.bin-sd-2024.04-r0 4 directories, 153 files 谢谢， 基兰 Re: How to Build & Test OPTEE on iMX91 processor 嗨，@KiranM7！ 感谢您联系恩智浦支持中心！ 在我们的 BSP 中，OP-TEE 默认处于启用状态。虽然我们目前没有运行 optee-test 的官方指南，但您可以参考官方 OP-TEE 文档以获取详细说明： 选项测试 致以最崇高的敬意， Chavira

MX8QM推奨PMIC MX8QM プロセッサをベースにした設計を計画しています。以下のインターフェースを使用します A72 2コア PCIeインターフェース eMMCインターフェース イーサネットインターフェース GPU、VPU、ディスプレイなどは使用しません。 PMIC 選択ページ ( https://www.nxp.com/products/power-management/pmics-and-sbcs:POWR_MAN_USER_INTERFACE ) では、推奨デバイスは PF81-PF82 ですが、製品ページによると推奨されていません。 SO、推奨されるデバイスは何でしょうか? PCA9450Cは使えますでしょうか？ よろしくお願いします。 i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Re: MX8QM recommended PMIC こんにちは、 残念ながら、NXP の PF81-PF82 の交換部品番号はありません。 次のようなサードパーティのソリューションを探すことをお勧めします。 NXP i.MX8 QuadMaxプロセッサ向け統合電源デザイン また、PCA9450 PMIC は、i.MX8MN/M/P プロセッサと比較して、電力要件がより高い電流消費と異なる電源オン/電源オフ シーケンスであるため、i.MX8QM と互換性がありません。 PF81-PF82製品ファミリは、2034年5月まで当社の長寿プログラムの一部であることをご留意ください。 よろしくお願いいたします。

NTAG 424 no login possible after key 0 change Hi all, i'm facing a strange behaviour that i can't solve. I completed all my steps to configure a #NTAG424 for a security platform: everything is ok BUT one last thing I had to change all the 5 keys and started with this "loop" for 4 to 0: Login with key 0 Change key X I'm aware that changing K0 is different from K4-1 and the response is 91-00 so seems everything is correct. Now the problem: i can login with all the kyes 4-1 but with K0 i get a 91-AE in login part 2. I suppose that the encryption is wrong so the key is different from what i think, but i checked a lot of time the code and is ok. I only changet the cryptogram calculation as per data sheet and AN12196.  Any hint? Thank Re: NTAG 424 no login possible after key 0 change Hello @MPucci , Have you already implemented ChangeKey 0 and 1-4 in your post? I am currently implementing this, but I have encountered some issues. I am unable to successfully modify Key1-4 to respond to 911E, and after modifying Key0, the authentication response is 91AE. I would like to seek some help from you, and I would greatly appreciate it. Re: NTAG 424 no login possible after key 0 change Hello @KaiLi  I didn't see 6.16.2 in AN12196. Is it because the version of the document is different? Any hints？ Thank you! Re: NTAG 424 no login possible after key 0 change Hello @MPucci  Thanks for contacting us and based on your issue description, it's recommended that you try the steps of chapter 6.16.2 of AN12196. For example: 1. Authentication by keyNo 0x00 2. input the New key  3. execute ChangeKey command 4. double check using the new key to authenticate NTAG424. BR Kelly Re: NTAG 424 no login possible after key 0 change Some more info: i know is not correct but i use the same RndA in all login before change the keys. I can't identify the root of the issue, but if i use 5 different RndA in login, no problems with keys (even K0), if i use the same RndA in login, K0 is corrupted. So for now the problem is solved, without knowing the cause.