FIPS 140-3 Level 3 Compliance of NXP Code Signing Tool (CST) Hi NXP Team, We are currently using the NXP Code Signing Tool (CST) for secure boot implementation and for generating/managing the keys and certificates used for image signing. As part of our product security requirements, we need to understand the FIPS 140-3 Level 3 compliance of the CST-based code-signing process. Could you please clarify the following: 1. Is the NXP Code Signing Tool (CST) itself FIPS 140-3 compliant or validated, specifically for FIPS 140-3 Level 3 requirements? If yes, could you please share the relevant certification, validation details, or official NXP documentation confirming the compliance? Thanks Re: FIPS 140-3 Level 3 Compliance of NXP Code Signing Tool (CST) CST is documented as an NXP code-signing tool, not as a FIPS 140-3 Level 3 validated cryptographic module.

FRDM-A-S32K358のピン配置の詳細 コミュニティの皆様、こんにちは。 昨日、FRDM-A-S32K358開発キットを購入しました。ピン配置の詳細を探しています。 S32K144_pinout.png という類似ファイルを探しています。迅速なご対応に感謝いたします。 よろしくお願いいたします。 スリラム Re: FRDM-A-S32K358 Pinout Details こんにちは、 VaneBさん リンクをありがとうございます。大変参考になりました。 Re: FRDM-A-S32K358 Pinout Details こんにちは、 @SriramEmbdさん FRDM-A-S32K358に対応する画像は存在しません。ただし、基板回路図にはArduinoヘッダーのピン割り当てを示す専用ページが含まれています。 回路図は FRDM-A-S32K358設計Files.zip パッケージで入手可能です。 BR、VaneB

ECSPI1 does not generate expected SPI clock on custom board Hi Team, We are working with an i.MX8MP custom board based on the i.MX8MP EVK configuration. On the i.MX8MP EVK, we have an SPI device connected through ECSPI2. With the existing EVK Device Tree configuration, SPI communication is working correctly, and we can observe the expected SCLK waveform on the oscilloscope. On our custom board, the SPI interface is connected to ECSPI1 instead of ECSPI2. We therefore modified the Device Tree configuration to use ECSPI1. However, with ECSPI1, we are not able to observe the expected/correct SPI clock pulses on the SCLK pin. We have tried several different Device Tree configurations, but the issue remains. 1. ECSPI1 configured similar to the existing ECSPI2 configuration We changed the controller from ECSPI2 to ECSPI1 and created the corresponding ECSPI1 pinctrl group, including SCLK, MOSI, MISO and CS. 2. Separate CS pinctrl group We also tried defining a separate pinctrl_ecspi1_cs and using it along with the ECSPI1 pinctrl group. 3. Explicit ECSPI1 pinmux configuration We also tried explicitly defining the ECSPI1 pins. However, with ECSPI1, we are still unable to observe the expected SPI clock pulses. We would like to know when configuring ECSPI1 on i.MX8MP, are there any additional Device Tree or pinctrl changes required apart from enabling &ecspi1 and configuring the ECSPI1 SCLK/MOSI/MISO/CS pins? In particular, is there any ECSPI1-specific pinctrl, clock, IOMUX, or other Device Tree configuration that needs to be added for ECSPI1 to operate correctly? The same SPI setup works on ECSPI2, so we would like to understand whether there is any additional configuration required when moving the interface from ECSPI2 to ECSPI1. Thanks in advance for your guidance. Re: ECSPI1 does not generate expected SPI clock on custom board Hi ,  Please find the dts file attached Re: ECSPI1 does not generate expected SPI clock on custom board Hi @SWETHA1  Please share your dts file about ECSPI1.  B.R Re: ECSPI1 does not generate expected SPI clock on custom board Hi @SWETHA1  I have checked your dts file, I found the following errors： 1. ECSPI pins have been reused, causing a pin usage conflict. Please remove this part or use other pins for reuse.     pinctrl_ecspi1: ecspi1grp {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK       0x48             MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI       0x48             MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO       0x48         >;     };     pinctrl_uart3: uart3grp {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SCLK__UART3_DCE_RX      0x140             MX8MP_IOMUXC_ECSPI1_MOSI__UART3_DCE_TX      0x140             MX8MP_IOMUXC_ECSPI1_SS0__UART3_DCE_RTS      0x140             MX8MP_IOMUXC_ECSPI1_MISO__UART3_DCE_CTS     0x140         >;     }; 2. The ECSPI1 chip select (CS) configuration is contradictory. Please change it to the following code.     pinctrl_ecspi1_cs: ecspi1cs {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09     0x40000         >;     }; B.R Re: ECSPI1 does not generate expected SPI clock on custom board Hi @pengyong_zhang, Please find the below observations 1. Logic analayser result when used the suggested changes SWETHA1_1-1786532293061.pngSWETHA1_1-1786532293061.pngSWETHA1_1-1786532293061.png 2. Another observation when used the below patch on top of the previously attached dts SWETHA1_0-1786532274946.pngSWETHA1_0-1786532274946.pngSWETHA1_0-1786532274946.png the above graph observed with this changes pinctrl_ecspi1: ecspi1grp { fsl,pins = < MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x80 MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x80 MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x80 >; }; With the suggested changes, we could see the clock is not as expected.  Re: ECSPI1 does not generate expected SPI clock on custom board Adding a few more details for the last response Observation 1: The result obtained after applying the suggested DTS changes. However, the SPI clock waveform is still not as expected, and the overall SPI signal behavior does not match the expected result. Observation 2: When MISO is left floating, CS shows two unwanted spikes, which is not the desired behavior. CS is initially driven low. Even when CS is configured to be driven high through the DTS, it is initially driven high as expected; however, after a transaction, CS appears to go low again. Could you please share your insights on this and guide to proceed further Re: ECSPI1 does not generate expected SPI clock on custom board Hi @SWETHA1  1. Please share your latest dts file. 2. How did you test the SPI device? You can use the `spidev_test` tool to run SPI tests. Please share the output of your `ls /dev/` command. B.R Re: ECSPI1 does not generate expected SPI clock on custom board Hi  Please find the attached dts files correspoding to shared observations 1 and 2.  The output of ls /dev shows /dev/spidev1.0 As for testing the spidevice , I have used the attached c file , which is verified working in  evk board where the spi is connected to ecspi2 and used the existing pinctrl groups. Now the validation results are taken and shared under the custom board based on evk where spi is connected in ecspi1.

CodeWarrior Build error Every so-often I get a build error:- mingw32-make: *** No rule to make target Dropbox//Projects/\Project_x/\Project_Headers/\../\Sources/\Events.c',                     needed by `Sources/Events_c.obj'.  Stop. The file Events_c.obj does, of course, exist, but the usual remedies do not work. I tried a Clean build, I deleted Events_c.obj', I deleted the whole Flash folder, I tried shutting down and re-starting but nothing worked. I ended up creating a new project and cut and pasted the source file content. This problem occurs once every few weeks and on a couple of occasions, after the computer was "sleeping", the problem cleared itself. Re: CodeWarrior Build error This sounds less like an issue with the .obj file itself and more like a stale or malformed dependency path in the generated Makefile. The Dropbox//Projects/\Project_x... path with the odd slashes is a big clue. I’d check whether the project is being built directly from a Dropbox-synced folder and try moving it to a local, non-synced directory. Also, compare the generated dependency/Makefile entries when the problem occurs with a working build. If the error disappears after the Dropbox folder syncs or the PC wakes, that would further point toward Dropbox/file-system timing rather than the source file.      Re: CodeWarrior Build error Thanks, the sync issue makes sense, but it will be a few days before I can try it. Re: CodeWarrior Build error Hello, Which version of CodeWarrior are you using? Does the Clean build that you tried is by using the commander>Clean (All)? When you move to a new project it works and after a few weeks happens again? Probably your make files doesn’t match according to your directory. Please try this to clean and make a re-creation of the make files On the Project view>Clean>Select your project to build   luis_maravilla_1-1787091476012.pngluis_maravilla_1-1787091476012.png Also, as a recommendation do not use the Dropbox folder, kindly change to a local path and add it or change it in the build directory. Please refer to this post for more information No rule to make target | MCU on Eclipse Best Regards, Luis

CodeWarrior 版本错误 我偶尔会遇到版本错误： mingw32-make：*** 没有规则可以创建目标 Dropbox//Projects/\Project_x/\Project_Headers/\../\Sources/\Events.c'`Sources/Events_c.obj` 需要此文件。  停止。 文件 Events_c.obj 当然存在，但通常的解决方法却不起作用。我尝试了全新版本，删除了 Events_c.obj 文件。我删除了整个 Flash 文件夹，也尝试过关机重启，但都没用。最后我新建了一个项目，然后剪切粘贴了源文件的内容。这个问题每隔几周就会发生一次，而且有几次，在电脑“休眠”后，问题就自行消失了。 Re: CodeWarrior Build error 谢谢，同步问题确实有道理，但我需要几天时间才能尝试。 Re: CodeWarrior Build error 这听起来不太像是 .obj 文件的问题。文件本身有问题，更像是生成的 Makefile 中存在过时或格式错误的依赖路径。Dropbox//Projects/\Project_x... 路径中奇怪的斜杠是一个重要的线索。我会检查项目是否直接从 Dropbox 同步的文件夹构建，并尝试将其移动到本地的非同步目录。此外，请将出现问题时生成的依赖项/Makefile 条目与正常版本时生成的条目进行比较。如果Dropbox文件夹同步或电脑唤醒后错误消失，则进一步表明问题出在Dropbox/文件系统的时序问题上，而不是源文件本身。 Re: CodeWarrior Build error 你好， 你使用的是哪个版本的CodeWarrior？ 您尝试的清理版本是否是通过命令>清理（全部）实现的？ 当你转到新项目时，一切正常，但几周后问题又出现了？ 可能是你的 make 文件与你的目录不匹配。 请尝试此方法清理并重新生成 make 文件。 在“项目”视图中 > “清理” > 选择要版本项目   luis_maravilla_1-1787091476012.pngluis_maravilla_1-1787091476012.png 另外，建议不要使用 Dropbox 文件夹，请更改为本地路径，并将其添加到版本目录中或进行更改。 请参阅此帖子了解更多信息：没有规则可以创建目标 | Eclipse 上的 MCU 此致敬礼，路易斯

HOW TO DEFINE I2S DMA PARA hi NXP team, #define DEMO_I2S_TX_INSTANCE_INDEX      (7U) #define DEMO_DMA_INSTANCE_INDEX         (0U) #define DEMO_I2S_TX_CHANNEL             (19) #define DEMO_I2S_MASTER_CLOCK_FREQUENCY (24576000)   The above definitions use DMA to transmit I2S TX (I2S7). Now I want to use I2S6 for I2S DMA reception. How should I configure these values? 上面这些定义是使用DMA 传输 I2S TX （I2S7）, 我现在要使用I2S6 做i2s dma rx。改如何配置这几个值呢？ #define DEMO_I2S_RX_INSTANCE_INDEX      (????) #define DEMO_RX_DMA_INSTANCE_INDEX         (????) #define DEMO_I2S_RX_CHANNEL             (????)   Thanks Harry  Re: HOW TO DEFINE I2S DMA PARA Hi @harry3  May i ask which chip you are using? BR Harry Re: HOW TO DEFINE I2S DMA PARA Check your chip's Reference Manual / DMA Mux request source table for I2S6 RX / SAI6 RX (often sequential or offset from the TX channel).

Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning tool Hi, I am able read, write, program and erase the custom board flash (W25Q01NWZEIQ) via secure provisioning tool (serial downloader mode enabled and FLASH_AUTO_PROBE_EN = 1). We are using FlexSPI_1 primary configuration pin as an interface to flash  But in MCUXpresso IDE we are not able to flash the .axf file. We modified few parameters of evkbmimxrt1170_flexspi_nor_config.c file such as look up table, size as 128 MB etc. The flash error appears like below. ProgramPage (0x30000000, 0x20002838, 0x4000) status 0x1 - driver reported driver error - EXTSPIJ driver rc -96 (0xFFFFFFA0).  For more details, please find the attached files. Thanks in advance Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning Hello @Raj_01, The error occurs because the .cfx file used by MCUXpresso IDE is designed specifically for the memories populated on the EVK. As you may know, different flash memories can require different command sets, initialization sequences, and configurations. Therefore, the EVK flash loader may not be compatible with your custom memory device. To debug your application in MCUXpresso IDE, you will need to create and use a custom .cfx flash driver that supports your specific memory. The following links offers a guide to make this file, although these guides are not specifically designed for the RT1170, you can follow the same procedure: AN13386: RT600 Flash Loader for Custom Flash Device How to Create a New Flash Driver for MCUXpresso IDE Please let me know if you have any further questions. BR Habib Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning Hi Habib, I followed the same instructions as you mentioned in the last reply, also modified some files such as  flashprg.c , flashConfig.h, flexspi_nor_flash.h, flasdev.c to match our custom board flash features and built new .cfx file and flashed. But still, we are unable to flash.  We are getting some error and warnings, please find the error files are attached. Please suggest solution for this.  Thanks in advance. Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning Hello @Raj_01, In order to support you better, could you please provide me the following information? -Could you describe the steps you performed in the Secure Provisioning Tool? Did you use the Boot memory configuration to test your flash? -Are you currently using the FLASH_AUTO_PROBE_EN fuse, or are you using GPIO_DISP_B1_6 to enable this bit? -If you test your custom .cfx flash loader without FLASH_AUTO_PROBE_EN enabled, do you observe the same behavior? -When you launch a debug session, what is the current boot pin configuration? -Could you also share the reason for using FLASH_AUTO_PROBE_EN in your application? BR Habib Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning Hello @Raj_01, Based on your description that the same error occurs even when AUTO_PROBE_EN is not enabled, the issue could be related to the .cfx implementation. I would recommend using the Boot Memory Configuration Tool available in the Secure Provisioning Tool. This utility allows you to select and validate the configuration parameters for your flash device, helping you verify that the selected settings are compatible with your memory and compare them with the implemented in your .cfx file. In addition, you can use this tool to generate the FCB. I recommend reviewing this community post, particularly the steps starting from point 15. That section provides a more detailed explanation of how the Secure Provisioning Tool generates the FCB and may help clarify the parameters and output produced by the tool. Also, could you also clarify me what is the purpose for using FLASH_AUTO_PROBE_EN in your application? BR Habib Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning 1. In the secure provisioning tool, the size of the flash has been modified to 128MB and FLASH_AUTO_PROBE_EN was set to 1 in the SW1. Hence we were able to flash through secure provisioning tool. We are using serial downloader mode for flashing and switching back to boot mode for running application. Modified the flash drivers as per the previous replies and trying to flash it through MCU Xpresso IDE. As the requirement is to debug flashing through Secure Provisioning tool will not resolve my issue.  2 and 5.  FLASH_AUTO_PROBE_EN  - Yes. After enabling it only, we were able to flash through secure provision.  3. Yes. 4. Refer the attached image.  Attaching the error log and the modified files. The below is the evkbmimxrt1170_flexspi_nor_config.c containing the LUT code to create FCB from MCU IDE:    /* * 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 (8U) #define FLASH_DUMMY_VALUE (0x03U) 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 = (1UL << kFlexSpiMiscOffset_SafeConfigFreqEnable),//0x10, .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_100MHz, //kFlexSpiSerialClk_133MHz, .sflashA1Size = 128U * 1024U * 1024U, .timeoutInMs = 5000U, .sflashA2Size = 0U, .sflashB1Size = 0U, .sflashB2Size = 0U, /* Enable flash configuration feature */ .configCmdEnable = 1U, .configModeType[0] = kDeviceConfigCmdType_Generic, /* Set configuration command sequences */ .configCmdSeqs[0] = { .seqNum = 1U, .seqId = 12U, .reserved = 0U, }, /* Prepare setting value for Read Register in flash */ .configCmdArgs[0] = (FLASH_DUMMY_VALUE << 4U), .lookupTable = { // Read LUTs [4U * 0U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEC, RADDR_SDR, FLEXSPI_4PAD, 0x20), [4U * 0U + 1U] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, FLASH_DUMMY_CYCLES, READ_SDR, FLEXSPI_4PAD, 0x04), // Read Status LUTs [4U * 1U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04), // Write Enable LUTs [4U * 3U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x00), // Erase Sector LUTs [4U * 5U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x21, RADDR_SDR, FLEXSPI_1PAD, 0x20), // Erase Block LUTs [4U * 8U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xDC, RADDR_SDR, FLEXSPI_1PAD, 0x20), // Pape Program LUTs [4U * 9U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x12, RADDR_SDR, FLEXSPI_1PAD, 0x20), [4U * 9U + 1U] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x00), // Erase Chip LUTs [4U * 11U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x60, STOP, FLEXSPI_1PAD, 0x00), // Set Read Register LUTs [4U * 12U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xC0, WRITE_SDR, FLEXSPI_1PAD, 0x01), [4U * 12U + 1U] = FLEXSPI_LUT_SEQ(STOP, FLEXSPI_1PAD, 0x00, STOP, FLEXSPI_1PAD, 0x00), }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .ipcmdSerialClkFreq = 1U, .isUniformBlockSize = 0U, //false, .isDataOrderSwapped = 0U, .serialNorType = 0U, .needExitNoCmdMode = 0U, .halfClkForNonReadCmd = 0U, .needRestoreNoCmdMode = 0U, .reserved0 = 0U, .FlashStateCtx = 0U, }; #endif /* XIP_BOOT_HEADER_ENABLE */   Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning The NOR used is 1Gb/W25Q01NWZEIQ while on i.MX RT1170 refer device is 128Mb or 512Mb. So the config file is different . You may update the config file and share the config file for review is possible. Since the error informaton is 'driver reported driver error - EXTSPIJ driver rc -96', the drive command could be different as well may need to double check

多核触发信号 使用 multicore_trigger 和 cm7_helloworld 这两个演示程序时，我没有为 CM7 ITCM 启用 ECC。我使用 SPT 工具将 CM33 镜像和 CM7 镜像（旨在从内存运行）合并成一个镜像，然后通过 UART 将合并后的镜像编程到或非 Flash 中。然而，启动过程失败了。根据手册，一个容器最多可以包含 8 个 OEM 图像条目。在我的测试中，我只包含了两张图片：一张 CM33 图片和一张 CM7 图片。CM7 ITCM ECC 未启用。 CM33 和 CM7 镜像均未启动。但是，当我检查容器头时，发现其中只有 CM33 镜像。CM33 镜像本身单独使用时可以正常启动，不会出现任何问题。 我想了解为什么 CM7 镜像没有被包含或按预期处理，以及缺少 CM7 ITCM ECC 配置是否会影响 Boot ROM 处理 CM7 镜像的方式。 问题2： 如果我将 8 个 CM7 镜像和 1 个 CM33 镜像合并到一个容器中，启动过程中 Boot ROM 会执行什么操作？ 由于只有一个 CM7 内核，启动 ROM 如何确定应该启动哪个 CM7 镜像？如果所有 8 个图像条目都是 CM7 图像，启动 ROM 会加载所有 8 个图像、只选择一个图像，还是将选择权交给 CM33 应用程序？ Boot ROM 如何识别和处理同一容器中的多个 CM7 映像条目？是否存在优先级、映像索引、核心 ID、加载地址、入口点或其他机制来确定执行哪个 CM7 映像？ 我还想了解启用 CM7 ITCM ECC 和未启用 CM7 ITCM ECC 时启动 ROM 的确切行为。 启用 CM7 ITCM ECC 时，启动 ROM 是否会初始化 CM7 ITCM ECC 存储器，将 CM7 映像从 NOR Flash 复制到 CM7 ITCM，然后释放 CM7 的 RESET 状态？或者说，Boot ROM 只负责加载 CM7 镜像，而 CM33 应用程序负责解除 CM7 的 RESET 状态并启动它？ 当 CM7 ITCM ECC 未启用时，启动 ROM 在遇到加载地址位于 CM7 ITCM 中的 CM7 映像时会做什么？启动 ROM 是否会跳过 CM7 镜像、无法加载、使 CM7 保持重置状态，或者导致整个容器启动过程失败？ 我尤其想确认一下是否支持以下容器： 图片 0：CM33 图1：CM7 图2：CM7 图3：CM7 图4：CM7 图5：CM7 图6：CM7 图7：CM7 图8：CM7 如果支持，那么在启动 ROM 时，这 8 个 CM7 镜像究竟会发生什么？哪个元器件负责选择实际执行的 CM7 镜像？ 最后，我想澄清一下，最多 8 个 OEM 镜像条目是指容器可以简单地存储 8 个不同的镜像，还是 Boot ROM 也提供了一种机制，可以为给定的核心选择和启动特定的镜像。 Re: multicore trigger 嗨@yanyanwang ， 如果容器头只显示 CM33 映像，则 Boot ROM/ELE 永远不会有 CM7 条目要处理，这可能是您看到的行为的原因。 另外，需要注意的是，集装箱的顺序也很重要。正如RM所提到的：“OEM容器最多可以有8个图像。Cortex-M33 内核（启动内核）镜像必须位于其他镜像之后。 换句话说，你提到的用一个 CM33 图像跟 8 个 CM7 图像的方案是不可行的。您需要将 CM7 图像的数量减少一张，并反转顺序。 如果存在多个图像，ELE 会验证每个图像的哈希值，如果任何哈希值验证失败，设备将进入重置循环。 该机制采用数组处理，这意味着每张图片都是按顺序加载的，并且每张图片都有自己的标志来标识。 BR， 埃德温。 Re: multicore trigger 你好， @EdwinHz 如下图所示，我在构建可引导镜像时选择了 CM7 镜像，然后解析了容器头。容器中包含 CM7 镜像的条目。 但是，将镜像写入闪存并重启设备后，设备无法启动，而且我也无法使用调试器连接到它。 请问在这种配置下，RT1180 Boot ROM 是如何处理 CM7 镜像的？ 如果可以的话，请您在 FRDM-IMXRT1186 开发板上重现并验证此行为？ yanyanwang_1-1787018660982.pngyanyanwang_1-1787018660982.png

通过安全配置工具对带有闪存 (W25Q01NWZEIQ) 的定制板 (MIMXRT1176CVM8B) 进行编程 您好， 我能够通过安全配置工具（启用串行下载器模式且 FLASH_AUTO_PROBE_EN = 1）对定制板闪存 (W25Q01NWZEIQ) 进行读取、写入、编程和擦除。我们使用 FlexSPI_1 主配置引脚作为闪存接口。 但是，在 MCUXpresso IDE 中，我们无法烧录 .axf 文件。文件。我们修改了 evkbmimxrt1170_flexspi_nor_config.c 文件中的一些参数，例如查找表、大小为 128 MB 等。闪存错误如下所示。 ProgramPage (0x30000000, 0x20002838, 0x4000) 状态 0x1 - 驱动程序报告驱动程序错误 - EXTSPIJ 驱动程序返回码 -96 (0xFFFFFFA0)。 更多详情请见附件。 提前致谢 Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning 你好@Raj_01 ， 出现此错误的原因是 .cfx 文件。MCUXpresso IDE 使用的文件是专门为 EVK 上填充的内存设计的。您可能知道，不同的闪存可能需要不同的命令集、初始化序列和配置。因此，EVK 闪存加载器可能与您的自定义存储设备不兼容。 要在 MCUXpresso IDE 中调试应用程序，您需要创建并使用自定义的 .cfx 文件。支持您特定内存的闪存驱动程序。以下链接提供了创建此文件的指南，虽然这些指南并非专门针对 RT1170 设计，但您可以按照相同的步骤操作： AN13386：RT600 自定义闪存设备刷机程序 如何为 MCUXpresso IDE 创建新的闪存驱动程序 如果您还有其他问题，请告诉我。 BR 哈比卜 Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning 你好，哈比卜， 我按照您上次回复中提到的步骤操作，也修改了一些文件，例如 flashprg.c。flashConfig.h，flexspi_nor_flash.h，flasdev.c 文件与我们的自定义板闪存功能相匹配，并构建了新的 .cfx 文件。文件已刷写。但是，我们仍然无法刷机。我们收到了一些错误和警告，请查看附件中的错误文件。请提供解决方案。 先行致谢。 Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning 你好@Raj_01 ， 为了更好地为您提供支持，请您提供以下信息？ -能否描述一下您在安全配置工具中执行的步骤？你是否使用启动内存配置来测试你的闪存？ -您目前使用的是 FLASH_AUTO_PROBE_EN 熔丝，还是使用 GPIO_DISP_B1_6 来启用此位？ -如果您测试自定义的.cfx文件如果未启用 FLASH_AUTO_PROBE_EN，是否也会观察到相同的行为？ -启动调试会话时，当前的启动引脚配置是什么？ -能否也说明一下在您的应用程序中使用 FLASH_AUTO_PROBE_EN 的原因？ BR 哈比卜 Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning 你好@Raj_01 ， 根据您的描述，即使未启用 AUTO_PROBE_EN 也会出现同样的错误，因此该问题可能与 .cfx 文件有关。执行。我建议使用安全配置工具中提供的启动内存配置工具。此实用程序允许您选择和验证闪存设备的配置参数，帮助您确认所选设置与您的存储器兼容，并将其与 .cfx 文件中实现的设置进行比较。文件。 此外，您还可以使用此工具生成 FCB。我建议查看这篇社区帖子，特别是从第 15 点开始的步骤。该部分更详细地解释了安全配置工具如何生成 FCB，并有助于阐明该工具生成的参数和输出。 另外，能否请您解释一下，在您的应用程序中使用 FLASH_AUTO_PROBE_EN 的目的是什么？ BR 哈比卜 Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning 1.在安全配置工具中，闪存大小已修改为 128MB，并且在 SW1 中将 FLASH_AUTO_PROBE_EN 设置为 1。因此，我们能够通过安全配置工具进行烧录。我们使用串口下载器模式进行烧录，然后切换回启动模式运行应用程序。根据之前的回复修改了闪存驱动程序，并尝试通过 MCU Xpresso IDE 进行烧录。由于需求是调试烧录，因此通过安全配置工具进行烧录无法解决我的问题。 2 和 5. FLASH_AUTO_PROBE_EN - 是。启用此选项后，我们才能通过安全配置进行刷写。 3. 是的。 4. 请参考附图。 附件包含错误日志和修改后的文件。以下是 evkbmimxrt1170_flexspi_nor_config.c 文件，其中包含用于从 MCU IDE 创建 FCB 的 LUT 代码： /* * 版权所有 2018-2022 NXP * ALL RIGHTS RESERVED. * * SPDX 许可证标识符：BSD-3-Clause */ #include "evkbmimxrt1170_flexspi_nor_config.h" /* 组件 ID 定义，供工具使用。*/ #ifndef FSL_COMPONENT_ID #define FSL_COMPONENT_ID "platform.drivers.xip_board" #endif /******************************************************************************* * 代码 ******************************************************************************/ #如果已定义(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 (8U) #define FLASH_DUMMY_VALUE (0x03U) 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 = (1UL << kFlexSpiMiscOffset_SafeConfigFreqEnable ), //0x10, .deviceType = kFlexSpiDeviceType_SerialNOR ， .sflashPadType = kSerialFlash_4Pads , .serialClkFreq = kFlexSpiSerialClk_100MHz , //kFlexSpiSerialClk_133MHz, .sflashA1Size = 128U * 1024U * 1024U, .timeoutInMs = 5000U, .sflashA2Size = 0U， .sflashB1Size = 0U， .sflashB2Size = 0U， /* 启用闪存配置功能 */ .configCmdEnable = 1U， .configModeType[0] = kDeviceConfigCmdType_Generic , /* 设置配置命令序列 */ .configCmdSeqs[0] = { .seqNum = 1U， .seqId = 12U， .reserved = 0U， }, /* 准备闪存中读取寄存器的设置值 */ .configCmdArgs[0] = (FLASH_DUMMY_VALUE < 4U), .lookupTable = { // 读取查找表 [4U * 0U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEC, RADDR_SDR, FLEXSPI_4PAD, 0x20), [4U * 0U + 1U] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, FLASH_DUMMY_CYCLES, READ_SDR, FLEXSPI_4PAD, 0x04), // 读取状态查找表 [4U * 1U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04), // 写入使能 LUT [4U * 3U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x00), // 删除扇区查找表 [4U * 5U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x21, RADDR_SDR, FLEXSPI_1PAD, 0x20), // 擦除块查找表 [4U * 8U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xDC, RADDR_SDR, FLEXSPI_1PAD, 0x20), // Pape程序查找表 [4U * 9U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x12, RADDR_SDR, FLEXSPI_1PAD, 0x20), [4U * 9U + 1U] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x00), // 擦除芯片查找表 [4U * 11U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x60, STOP, FLEXSPI_1PAD, 0x00), // 设置读取寄存器查找表 [4U * 12U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xC0, WRITE_SDR, FLEXSPI_1PAD, 0x01), [4U * 12U + 1U] = FLEXSPI_LUT_SEQ(STOP, FLEXSPI_1PAD, 0x00, STOP, FLEXSPI_1PAD, 0x00), }, }, .pageSize = 256u， .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u， .ipcmdSerialClkFreq = 1U， .isUniformBlockSize = 0U, //false, .isDataOrderSwapped = 0U, .serialNorType = 0U， .needExitNoCmdMode = 0U, .halfClkForNonReadCmd = 0U, .needRestoreNoCmdMode = 0U, .reserved0 = 0U， .FlashStateCtx = 0U， }; #endif /* XIP_BOOT_HEADER_ENABLE */   Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning 所使用的 或非 为 1Gb/W25Q01NWZEIQ，而i.MX RT1170参考设备为 128Mb 或 512Mb。所以配置文件不一样。您可以更新配置文件，如果可以，也可以分享配置文件以供审核。 由于错误信息为“驱动程序报告驱动程序错误 - EXTSPIJ 驱动程序返回码 -96”，因此驱动命令可能有所不同，需要仔细检查。

セキュアプロビジョニングツールを使用して、カスタムボード（MIMXRT1176CVM8B）にフラッシュメモリ（W25Q01NWZEIQ）をプログラムする こんにちは、 セキュアプロビジョニングツール（シリアルダウンローダーモード有効、FLASH_AUTO_PROBE_EN = 1）を使用して、カスタムボードのフラッシュメモリ（W25Q01NWZEIQ）の読み取り、書き込み、プログラミング、消去が可能です。プライマリ設定ピンFlexSPI_1フラッシュのインターフェースとして使っています しかしMCUXpresso IDEでは.axfをフラッシュできませんファイル。evkbmimxrt1170_flexspi_nor_config.c ファイルのルックアップテーブルやサイズ（128 MB）などのパラメータをいくつか変更しました。フラッシュエラーは以下のように表示されます。 ProgramPage(0x30000000、0x20002838、0x4000)ステータス0x1 - ドライバーがドライバーエラーを報告 - EXTSPIJドライバーRC -96(0xFFFFFFA0)。 詳細については、添付ファイルをご覧ください。 前もって感謝します Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning こんにちは、@Raj_01 さん。 エラーは.cfxファイルが原因で発生します。MCUXpresso IDEで使用されるファイルは、EVKに埋め込まれたメモリ専用に設計されています。ご存知かもしれませんが、フラッシュメモリーによっては異なるコマンドセット、初期化シーケンス、構成が必要になることがあります。したがって、EVKフラッシュローダーは、お使いのカスタムメモリデバイスと互換性がない可能性があります。 MCUXpresso IDEでアプリケーションをデバッグするには、カスタムの.cfxを作成して使用する必要があります特定のメモリをサポートするフラッシュドライバー。以下のリンクにはこのファイルの作成ガイドがありますが、これらのガイドはRT1170専用ではありませんが、同じ手順で行えます。 AN13386:カスタムフラッシュデバイス用のRT600フラッシュローダー MCUXpresso IDEs用の新しいフラッシュドライバの作成方法 他に質問がありましたら、お気軽にお知らせください。 BR ハビブ Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning こんにちは、ハビブさん。 前回の返信で述べられた手順に従い、flashprg.cなどのファイルもいくつか変更しました。flashConfig.h、flexspi_nor_flash.h、flasdev.c をカスタムボードのフラッシュ機能に合わせて作成し、新しい .cfx ファイルを構築しました。ファイルとフラッシュが行われました。しかし、それでもフラッシュすることができません。エラーと警告が発生しています。エラーファイルは添付ファイルをご確認ください。この問題に対する解決策を提案してください。 よろしくお願いいたします。 Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning こんにちは、@Raj_01 さん。 より良くサポートするために、以下の情報を教えていただけませんか? -Secure Provisioning Toolで実行した手順を教えてもらえますか?ブートメモリ構成を使用してフラッシュメモリをテストしましたか？ -現在、FLASH_AUTO_PROBE_ENヒューズを使用していますか、それともGPIO_DISP_B1_6を使用してこのビットを有効にしていますか？ -カスタム.cfxをテストする場合FLASH_AUTO_PROBE_ENが有効になっていないフラッシュローダーでも、同じ動作が見られますか？ デバッグセッションを開始したとき、現在のブートピン構成はどうなっていますか？ -応募でアプリケーションを使う理由も教えていただけますか? BR ハビブ Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning こんにちは、@Raj_01 さん。 AUTO_PROBE_ENを有効にしていなくても同じエラーが起きるというあなたの説明から、問題は.cfxに関連している可能性があります実装。セキュアプロビジョニングツールに含まれるブートメモリ構成ツールを使用することをお勧めします。このユーティリティを使用すると、フラッシュデバイスの構成パラメータを選択して検証できます。選択した設定がメモリと互換性があることを確認し、.cfx ファイルに実装されている設定と比較できます。ファイル。 さらに、このツールを使ってFCBを生成することもできます。このコミュニティ投稿、特に15番目の手順から始まる部分を確認することをお勧めします。そのセクションでは、セキュアプロビジョニングツールがどのようにFCBを生成するかについてより詳細な説明を提供しており、ツールによって生成されるパラメータと出力の理解に役立つ可能性があります。 また、申請でFLASH_AUTO_PROBE_ENを使う目的も教えていただけますか? BR ハビブ Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning 使用されているNORは1Gb/W25Q01NWZEIQですが、 i.MX RT1170の参照デバイスでは128Mbまたは512Mbです。つまり、設定ファイルが異なります。設定ファイルを更新し、可能であればレビューのために設定ファイルを共有してください。 エラー情報が「ドライバがドライバエラーを報告した - EXTSPIJ ドライバ rc -96」なので、ドライブコマンドが異なる可能性があり、再確認が必要かもしれません Re: Programming the custom board(MIMXRT1176CVM8B) with flash (W25Q01NWZEIQ) via secure provisioning 1.セキュアプロビジョニングツールでは、フラッシュのサイズが128MBに変更されています。 FLASH_AUTO_PROBE_ENはSW1で1に設定されていました。そのため、セキュアプロビジョニングツールをフラッシュで使うことができました。私たちはシリアルダウンローダーモードでフラッシュし、アプリケーションを起動する際には再び起動モードに戻しています。前の回答通りフラッシュドライバーを修正し、MCU Xpresso IDEでフラッシュしようとしています。デバッグが必要なため、Secure Provisioningツールを使ったフラッシュは解決しません。 2番と5番。 FLASH_AUTO_PROBE_EN - はい。それを有効にした後、セキュアプロビジョニングをフラッシュで通過できました。 3. はい。 4. 添付の画像を参照。 エラーログと修正ファイルを添付します。以下はMCU IDEからFCBを作成するためのLUTコードを含むevkbmimxrt1170_flexspi_nor_config.cです:    /* * 著作権 2018-2022 NXP * 無断転載を禁じます。 * * SPDX-License-Identifier: BSD-3-Claise */ #include "evkbmimxrt1170_flexspi_nor_config.h" /* ツールで使用されるコンポーネント ID 定義。*/ #ifndef FSL_COMPONENT_ID #define FSL_COMPONENT_ID 「プラットフォーム.ドライバ.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" ), 使用済み)) #elif defined( __ICCARM__ ) #pragma location = ".boot_hdr.conf" #endif #define FLASH_DUMMY_CYCLES (8U) #define FLASH_DUMMY_VALUE (0x03U) 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 = (1UL << kFlexSpiMiscOffset_SafeConfigFreqEnable ), //0x10, .deviceType = kFlexSpiDeviceType_SerialNOR 、 .sflashPadType = kSerialFlash_4Pads 、 .serialClkFreq = kFlexSpiSerialClk_100MHz , //kFlexSpiSerialClk_133MHz, .sflashA1Size = 128U * 1024U * 1024U、 .timeoutInMs = 5000U、 .sflashA2Size = 0U、 .sflashB1Size = 0U、 .sflashB2Size = 0U、 /* フラッシュ構成機能を有効にする */ .configCmdEnable = 1U、 .configModeType[0] = kDeviceConfigCmdType_Generic 、 /* 設定コマンドシーケンスを設定します */ .configCmdSeqs[0] = { .seqNum = 1U、 .seqId = 12U、 .reserved = 0U、 }、 /* フラッシュメモリ内の読み出しレジスタの設定値を準備する */ .configCmdArgs[0] = (FLASH_DUMMY_VALUE <4U) .lookupTable = { // LUTを読み込む [4U * 0U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEC, RADDR_SDR, FLEXSPI_4PAD, 0x20), [4U * 0U + 1U] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, FLASH_DUMMY_CYCLES, READ_SDR, FLEXSPI_4PAD, 0x04), // 読み取りステータスLUT [4U * 1U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04), // LUTの書き込み有効化 [4U * 3U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x00), // セクターLUTを消去する [4U * 5U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x21, RADDR_SDR, FLEXSPI_1PAD, 0x20), // ブロックLUTを消去する [4U * 8U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xDC, RADDR_SDR, FLEXSPI_1PAD, 0x20), //ペーパープログラムLUT [4U * 9U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x12, RADDR_SDR, FLEXSPI_1PAD, 0x20), [4U * 9U + 1U] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x00), // チップLUTを消去する [4U * 11U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x60, STOP, FLEXSPI_1PAD, 0x00), // 読み出しレジスタLUTを設定する [4U * 12U + 0U] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xC0, WRITE_SDR, FLEXSPI_1PAD, 0x01), [4U * 12U + 1U] = FLEXSPI_LUT_SEQ(STOP, FLEXSPI_1PAD, 0x00, STOP, FLEXSPI_1PAD, 0x00), }、 }、 .pageSize = 256u、 .sectorSize = 4u * 1024u、 .blockSize = 64u * 1024u、 .ipcmdSerialClkFreq = 1U、 .isUniformBlockSize = 0U, //false, .isDataOrderSwapped = 0U、 .serialNorType = 0U、 .needExitNoCmdMode = 0U、 .halfClkForNonReadCmd = 0U、 .needRestoreNoCmdMode = 0U、 .reserved0 = 0U、 .FlashStateCtx = 0U、 }; #endif /* XIP_BOOT_HEADER_ENABLE */  

Unprotecting Flash in PB16 Hi, Folks! Please I need to find the way to unsecure the first sector (0xC000 - 0xDFF) of a MC9S08PB16 for to save that are in RAM in this part of the flash using the flash commands described on Chapter 10 of the PB16 Reference Manual. Hope anybody can help me. Regards! Re: Unprotecting Flash in PB16 Hello, Could you help us describe the commands and process you use to protect the memory sector? Are you referring to the commands in Chapter 10.3.5.2 Table 10-4 or the Flash commands in Chapter 10.3.9.1 Table 10-10? Have you set the FPROT register to protect the region in flash memory? Chapter 10.3.8.2 describe the method to unsecure the MCU by erasing the flash memory if that could help you to unsecure the sector. Best Regards, Luis

i.mx8M Plus 上的 wm8962 错误 我们正在设计基于 NXP i.MX 8M Plus (i.MX8MP) 处理器和 Wolfson WM8962 音频编解码器的定制电路板。我们目前正在将驱动程序移植到Linux 内核 5.4。以下是错误日志和我们的 DTS（设备树源）配置。 日志： [ 2.097680] imx-wm8962 sound-wm8962: 2111111111111111111111111 [ 2.103533] imx-wm8962 sound-wm8962: 22222222222222222222222222 [ 2.109467] imx-wm8962 sound-wm8962: 333333333333333333 [ 2.114705] imx-wm8962 sound-wm8962: 888888888888888888 [ 2.119953] imx-wm8962 sound-wm8962: failed to find codec platform device [ 2.126759] imx-wm8962: probe of sound-wm8962 failed with error -22 [ 2.995796] wm8962 2-001a: afrrgrgtrggggggggggggggggggg [ 3.001038] wm8962 2-001a: bbbbbbbbbbbbbbbbbbbbbbbbb [ 3.008259] random: fast init done [ 3.011807] wm8962 2-001a: customer id 0 revision F​ DTS：   sound-wm8960-forenex { compatible = "fsl,imx-audio-wm8962"; model = "wm8962-audio"; audio-codec = <&codec>; audio-cpu = <&sai3>; audio-routing = "Headphone Jack", "HPOUTL", "Headphone Jack", "HPOUTR", "Ext Spk", "SPKOUTL", "Ext Spk", "SPKOUTR", "AMIC", "MICBIAS", "IN3R", "AMIC", "IN1R", "AMIC"; }; &i2c3 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c3>; status = "okay"; pca6416: gpio@20 { compatible = "ti,tca6416"; reg = <0x20>; gpio-controller; #gpio-cells = <2>; }; ov5640_1: ov5640_mipi@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_csi0_pwn>, <&pinctrl_csi0_rst>, <&pinctrl_csi_mclk>; clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; clock-names = "xclk"; assigned-clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; assigned-clock-parents = <&clk IMX8MP_CLK_24M>; assigned-clock-rates = <24000000>; csi_id = <0>; powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; mclk = <24000000>; mclk_source = <0>; mipi_csi; status = "disabled"; port { ov5640_mipi_1_ep: endpoint { remote-endpoint = <&mipi_csi1_ep>; data-lanes = <1 2>; clock-lanes = <0>; }; }; }; codec: wm8962@1a { compatible = "wlf,wm8962"; reg = <0x1a>; clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; clock-names = "mclk"; wlf,shared-lrclk; AVDD-supply = <&reg_audio_pwr>; CPVDD-supply = <&reg_audio_pwr>; DBVDD-supply = <&reg_audio_pwr>; DCVDD-supply = <&reg_audio_pwr>; MICVDD-supply = <&reg_audio_pwr>; PLLVDD-supply = <&reg_audio_pwr>; SPKVDD1-supply = <&reg_audio_pwr>; SPKVDD2-supply = <&reg_audio_pwr>; gpio-cfg = < 0x0000 /* 0:Default */ 0x0000 /* 1:Default */ 0x0000 /* 2:FN_DMICCLK */ 0x0000 /* 3:Default */ 0x0000 /* 4:FN_DMICCDAT */ 0x0000 /* 5:Default */ >; }; };​ 根据我们的分析，当内核尝试初始化 imx-wm8962 机器驱动程序时，I2C 总线上的 WM8962 编解码器尚未完成探测/注册。WM8962 之后才会完成初始化。这种探针顺序不一致会导致驱动程序初始化失败并出现错误。 请问您能否帮忙分析一下这个问题，并提出解决此问题的建议？ IMX8MPLUS音频软件 NXP_MICR Android Linux Re: wm8962 on i.mx8M Plus error 当编解码器或 SAI 平台设备未准备就绪时，返回 -EPROBE_DEFER 在你的 imx-wm8962.c 中探测路径，区分以下几种情况： 缺少/无效的 DT 句柄 → 实际错误，返回 -EINVAL； 句柄存在，但引用的设备尚未注册 → 依赖项未准备就绪，返回 -EPROBE_DEFER。 例如，从概念上讲： codec_np = of_parse_phandle(np, "audio-codec", 0); 如果 (!codec_np) { dev_err(&pdev->dev, "音频编解码器缺失或无效\n");         返回-EINVAL； } codec_dev = of_find_i2c_device_by_node(codec_np); 如果 (!codec_dev) { dev_info(&pdev->dev, "编解码器设备未就绪，延迟探测\n"); of_node_put(codec_np); 返回 -EPROBE_DEFER； } 同样适用于 CPU DAI / SAI 节点： cpu_np = of_parse_phandle(np, "audio-cpu", 0); 如果 (!cpu_np) { dev_err(&pdev->dev, "audio-cpu 缺失或无效\n");         返回-EINVAL； } cpu_pdev = of_find_device_by_node(cpu_np); 如果 (!cpu_pdev) { dev_info(&pdev->dev, "SAI 平台设备未就绪，延迟探测\n"); of_node_put(cpu_np); 返回 -EPROBE_DEFER； } 如果您保留当前的机器驱动程序，这是最直接的解决方法。 如果可用，请优先选择 Linux 5.4 fsl-asoc-card 路径。 对于 Linux 5.4 时代的 NXP 内核，compatible = "fsl,imx-audio-wm8962" 由 sound/soc/fsl/fsl-asoc-card.c 处理，其中显式地处理了 WM8962，包括编解码器 DAI 名称 "wm8962" 和 WM8962 时钟/FLL ID。还要验证 snd-soc-fsl-asoc-card.ko 是否已加载或已构建。 这意味着您应该避免让旧版/自定义 imx-wm8962 机器驱动程序和 fsl-asoc-card 尝试绑定同一个兼容字符串。推荐方法： 启用/使用 CONFIG_SND_SOC_FSL_ASOC_CARD； 确保您的声音节点使用兼容的 = "fsl,imx-audio-wm8962";  ; 除非您有意保留，否则请移除或禁用该兼容字符串的旧版/自定义 imx-wm8962 绑定。 确保DTS具有所需的SAI和编解码器DAI属性 您的编解码器节点大致符合预期形状：WM8962 的示例使用 compatible = "wlf,wm8962" 、 reg = <0x1a> 、 clocks、 supply properties 和 gpio-cfg。但是，请确认您的DTS中未显示的部件： &sai3 { #sound-dai-cells = <0>         pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai3>;         assigned-clocks = <&clk IMX8MP_CLK_SAI3>;         assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT> assigned-clock-rates = <12288000>; /* 或板要求的 MCLK */         status = "okay"; }; 此外，编解码器通常还应公开以下内容： 编解码器：wm8962@1a { 兼容 = "wlf,wm8962"; reg =<0x1a> � #sound-dai-cells = <0> clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; 时钟名称 = "mclk"; …… }; 同时确保 reg_audio_pwr 引用的稳压器已定义、已启用，并且具有有效的电压范围。您的编解码器已被检测到，因此电源可能不是造成此特定错误的原因，但不良的电源或 MCLK 设置可能会导致以后的音频故障。 验证 MCLK 是否使能。 已知有一类 WM8962 启动问题，需要在音频机器驱动程序中启用编解码器 MCLK；据报道，在 imx_wm8962_probe() 中添加 clk_prepare_enable(codec_clk) 可以使 WM8962 音频工作。如果编解码器探测成功，但之后播放/捕获失败，请检查在编解码器初始化和流启动期间，SAI3 MCLK 是否实际存在于编解码器引脚上。 检查是否存在重复或冲突的声卡节点 确保只有一个活动的声音节点指向此编解码器/SAI 对，并且模型字符串是唯一的。在 NXP 社区调试中，还出现了类似的故障，即找不到编解码器平台设备，这与声卡命名/重复卡冲突有关。您的节点名称显示为 sound-wm8960-forenex，而兼容/型号为 WM8962；节点名称本身通常不起作用，但我建议您将其重命名以使其更清晰，并确认其他地方没有第二个已启用的 sound-wm8962 节点。 推荐的最短路径 如果可能，请使用适用于 Linux 5.4 的 fsl-asoc-card。 如果 WM8962 节点缺少 #sound-dai-cells = <0>;，请添加它。 确认 &sai3 已启用且已配置时钟/引脚控制。 如果保留自定义的 imx-wm8962 驱动程序，请修补失败的编解码器/CPU 查找路径，使其返回 -EPROBE_DEFER 而不是 -EINVAL。 确认 MCLK 已启用且存在。

multicore trigger Using the two demos, multicore_trigger and cm7_helloworld, I did not enable ECC for the CM7 ITCM. I used the SPT tool to merge the CM33 image and the CM7 image, which is intended to run from memory, into a single image, and then programmed the merged image into NOR Flash through UART. However, the boot process failed. According to the manual, a container can contain up to 8 OEM image entries. In my test, I only included two images: one CM33 image and one CM7 image. CM7 ITCM ECC was not enabled. Neither the CM33 nor the CM7 image started. However, when I checked the container header, I found that only the CM33 image was present. The CM33 image itself can boot normally without any issues when used alone. I would like to understand why the CM7 image was not included or processed as expected, and whether the lack of CM7 ITCM ECC configuration affects how Boot ROM processes the CM7 image. Question 2: If I merge 8 CM7 images and 1 CM33 image into a single container, what will the Boot ROM do during the startup process? Since there is only one CM7 core, how does Boot ROM determine which CM7 image should be booted? If all 8 image entries are CM7 images, will Boot ROM load all 8 images, select only one image, or leave the selection to the CM33 application? How does Boot ROM identify and process multiple CM7 image entries in the same container? Is there a priority, image index, Core ID, load address, entry point, or another mechanism used to determine which CM7 image is executed? I would also like to understand the exact Boot ROM behavior when CM7 ITCM ECC is enabled and when it is not enabled. When CM7 ITCM ECC is enabled, does Boot ROM initialize the CM7 ITCM ECC memory, copy the CM7 image from NOR Flash into CM7 ITCM, and then release CM7 from reset? Or does Boot ROM only load the CM7 image, while the CM33 application is responsible for releasing CM7 from reset and starting it? When CM7 ITCM ECC is not enabled, what does Boot ROM do when it encounters a CM7 image whose load address is in CM7 ITCM? Does Boot ROM skip the CM7 image, fail to load it, leave CM7 in reset, or cause the entire container boot process to fail? In particular, I would like to clarify whether the following container is supported: Image 0: CM33 Image 1: CM7 Image 2: CM7 Image 3: CM7 Image 4: CM7 Image 5: CM7 Image 6: CM7 Image 7: CM7 Image 8: CM7 If it is supported, what exactly happens to these 8 CM7 images during Boot ROM startup, and which component is responsible for selecting the CM7 image that will actually execute? Finally, I would like to clarify whether the maximum of 8 OEM image entries means that the container can simply store 8 different images, or whether Boot ROM also provides a mechanism to select and boot a specific image for a given core. Re: multicore trigger Hi @yanyanwang, If the container header showed only the CM33 image, then the Boot ROM/ELE never had a CM7 entry to process, which might be the cause of the behavior you are seeing. Also, it's important to note that the container order is also relevant. As the RM mentions: "The OEM container can have 8 images at the maximum. The Cortex-M33 core (booting core) images must be located after the other ones." In other words, the scheme you mention of having one CM33 followed by 8 CM7 images is not possible. You would have to reduce the number of CM7 images by one, and invert order. If multiple images are present, ELE verifies the hash for each one, and if any fail, the device enters the reset loop. The mechanism used array processing, meaning that each image is loaded in order, having their own flags to identify each. BR, Edwin. Re: multicore trigger Hi,  @EdwinHz  As shown in the figure below, I selected the CM7 image when building the bootable image and then parsed the container header. The container contains an entry for the CM7 image. However, after programming the image into flash and rebooting the device, the device fails to boot, and I am also unable to connect to it using the debugger. Could you please explain how the RT1180 Boot ROM processes the CM7 image in this configuration? If possible, could you please reproduce and verify this behavior on the FRDM-IMXRT1186 development board? yanyanwang_1-1787018660982.pngyanyanwang_1-1787018660982.png

I2S DMA PARAの定義方法 こんにちは、NXPチームの皆様、 #DEMO_I2S_TX_INSTANCE_INDEX ( 7U )を定義します #DEMO_DMA_INSTANCE_INDEX ( 0U )を定義します #DEMO_I2S_TX_CHANNEL を定義する( 19 ) #DEMO_I2S_MASTER_CLOCK_FREQUENCY ( 24576000 )を定義します   上記の定義では、DMA を使用して I2S TX (I2S7) を送信します。ここで、I2S DMA 受信に I2S6 を使用したいと思います。これらの値をどのように設定すればよいでしょうか? これらの設定は DMA 転送 I2S TX (I2S7) を使用することですが、私たちは I2S6 を使用して i2s dma rx を使用する予定です。この値をどのように構成しますか? #DEMO_I2S_RX_INSTANCE_INDEXを定義します( ???? ) #DEMO_RX_DMA_INSTANCE_INDEXを定義します( ???? ) #DEMO_I2S_RX_CHANNELを定義します( ???? )   よろしくお願いします。 ハリー Re: HOW TO DEFINE I2S DMA PARA こんにちは@harry3 どのチップを使っているか教えていただけますか？ BR ハリー Re: HOW TO DEFINE I2S DMA PARA チップのリファレンス・マニュアル/DMAのMuxリクエストソーステーブルでI2S6 RX / SAI6 RX(多くの場合はシーケンシャルまたはTXチャネルからオフセット)を確認してください。

如何定义 i2s dma 段落 您好，NXP团队： #define demo_i2s_tx_instance_index (7U) #define demo_dma_instance_index (0U) #define demo_i2s_tx_channel (19) #define demo_i2s_master_clock_frequency(24576000)   上述定义使用 DMA 传输 I2S TX (I2S7)。现在我想使用 I2S6 进行 I2S DMA 接收。我应该如何配置这些值？ 上面这些定义是使用 DMA 传输 I2S TX （I2S7）, 我现在要使用 I2S6 做 I2S DMA RX。改如何配置这几个值呢？ #define demo_i2s_rx_instance_index (????) #define demo_rx_dma_instance_index (????) #define demo_i2s_rx_channel (????)   谢谢！ 哈利 Re: HOW TO DEFINE I2S DMA PARA 你好@harry3 请问您使用的是哪种芯片？ BR 哈利 Re: HOW TO DEFINE I2S DMA PARA 查看芯片的参考手册/DMA Mux 请求源表，了解 I2S6 RX/SAI6 RX（通常是顺序的或与 TX 通道偏移的）。

マルチコアトリガー multicore_triggerとcm7_helloworldという2つのデモを使用した際、CM7 ITCMのECCは有効にしませんでした。私はSPTツールを使用して、メモリから実行することを目的としたCM33イメージとCM7イメージを1つのイメージに統合し、その後、統合したイメージをUART経由でNORフラッシュに書き込みました。しかし、起動プロセスが失敗しました。マニュアルによると、コンテナには最大8つのOEM画像エントリーを含めることができます。今回のテストでは、CM33画像とCM7画像の2枚のみを使用しました。CM7 ITCM ECCは有効になっていませんでした。 CM33イメージもCM7イメージも起動しなかった。しかし、コンテナヘッダーを確認したところ、CM33イメージしか存在しないことがわかりました。CM33イメージ自体は単独で使っても問題なく正常に起動できます。 CM7イメージが想定どおりに含まれなかった、あるいは処理されなかった理由、そしてCM7 ITCM ECC構成の欠如がブートROMによるCM7イメージの処理方法に影響を与えるかどうかを理解したいと考えています。 質問2： 8つのCM7イメージと1つのCM33イメージを1つのコンテナに統合した場合、ブートROMは起動プロセス中にどのような動作をしますか？ CM7コアは1つしかないのに、ブートROMはどのCM7イメージを起動するかをどのように判断するのでしょうか？もし8枚の画像エントリすべてがCM7の画像なら、Boot ROMは8枚すべての画像を読み込むのか、1枚だけを選択するのか、それとも選択はCM33アプリケーションに任せるのか? Boot ROMは、同じコンテナ内の複数のCM7イメージエントリをどのように識別し、処理するのですか？どのCM7イメージを実行するかを決定するために使用される優先順位、イメージインデックス、コアID、ロードアドレス、エントリポイント、またはその他のメカニズムはありますか？ また、CM7 ITCM ECCが有効になっている場合と無効になっている場合における、ブートROMの正確な動作についても理解しておきたい。 CM7 ITCM ECCが有効になっている場合、ブートROMはCM7 ITCM ECCメモリを初期化し、NORフラッシュからCM7イメージをCM7 ITCMにコピーし、その後CM7をリセット状態から解放するのでしょうか？それとも、Boot ROMはCM7イメージだけを読み込み、CM33アプリケーションはCM7のリセット解除と起動を担当しているのでしょうか? CM7 ITCM ECCが有効になっていない場合、ブートROMは、ロードアドレスがCM7 ITCM内にあるCM7イメージを検出したときにどのような動作をしますか？Boot ROMはCM7イメージをスキップしたり、ロードに失敗したり、CM7をリセット状態にしたり、コンテナのブートプロセス全体を失敗させたりしますか？ 特に、以下のコンテナがサポートされているかどうかを確認したいです。 画像0：CM33 画像1：CM7 画像2：CM7 画像3：CM7 画像4：CM7 画像5：CM7 画像6：CM7 画像7：CM7 画像8：CM7 もしサポートされている場合、ブートROM起動時にこれら8つのCM7イメージは具体的にどのように処理されるのでしょうか？また、実際に実行されるCM7イメージを選択する役割を担うコンポーネントはどれでしょうか？ 最後に、最大8つのOEMイメージエントリがコンテナに8つの異なるイメージを保存できるのか、それともBoot ROMが特定のコアに対して特定のイメージを選択して起動する仕組みを提供しているのかを明確にしたいと思います。 Re: multicore trigger こんにちは@yanyanwangさん コンテナヘッダーにCM33イメージしか表示されていなかった場合、ブートROM/ELEには処理すべきCM7エントリが存在しなかったことになり、それが現在発生している現象の原因である可能性があります。 また、コンテナの順序も重要であることに留意する必要があります。RMが述べているように、「OEMコンテナは最大8枚の画像を収録できます。Cortex-M33コア(起動コア)イメージは他のイメージの後に位置しなければなりません。」 つまり、CM33を1枚撮影した後にCM7を8枚撮影するという、あなたが言及したような構成は不可能です。CM7画像の数を1つ減らし、順序を反転させる必要があります。 複数のイメージが存在する場合、ELEはそれぞれのハッシュを検証し、いずれか1つでも検証に失敗した場合、デバイスはリセットループに入ります。 この仕組みは配列プロセッシングを用いており、各画像は順番に読み込まれ、それぞれを識別するためのフラグが付けられていました。 BR、 エドウィン。 Re: multicore trigger こんにちは、 @EdwinHz 下の図に示すように、起動可能なイメージを構築する際にCM7イメージを選択し、コンテナヘッダーを解析しました。コンテナにはCM7イメージのエントリが含まれています。 しかし、イメージをフラッシュメモリに書き込み、デバイスを再起動した後、デバイスが起動せず、デバッガーを使用して接続することもできません。 RT1180ブートROMがこの構成でCM7イメージをどのように処理しているのか説明していただけますか? 可能であれば、この動作をFRDM-IMXRT1186開発ボード上で再現し、検証していただけますか? yanyanwang_1-1787018660982.pngyanyanwang_1-1787018660982.png

i.mx8M Plus の wm8962 エラー NXP i.MX 8M Plus(i.MX8MP)プロセッサとWolfson WM8962オーディオコーデックをベースにカスタムボードを設計しています。現在、このドライバーをLinuxカーネル5.4に移植中です。以下に、エラーログとDTS（デバイスツリーソース）の設定を示します。 ログ： [ 2.097680] imx-wm8962 sound-wm8962: 2111111111111111111111111 [ 2.103533] imx-wm8962 sound-wm8962: 22222222222222222222222222 [ 2.109467] imx-wm8962 sound-wm8962: 333333333333333333 [ 2.114705] imx-wm8962 sound-wm8962: 888888888888888888 [ 2.119953] imx-wm8962 sound-wm8962: failed to find codec platform device [ 2.126759] imx-wm8962: probe of sound-wm8962 failed with error -22 [ 2.995796] wm8962 2-001a: afrrgrgtrggggggggggggggggggg [ 3.001038] wm8962 2-001a: bbbbbbbbbbbbbbbbbbbbbbbbb [ 3.008259] random: fast init done [ 3.011807] wm8962 2-001a: customer id 0 revision F​ DTS:   sound-wm8960-forenex { compatible = "fsl,imx-audio-wm8962"; model = "wm8962-audio"; audio-codec = <&codec>; audio-cpu = <&sai3>; audio-routing = "Headphone Jack", "HPOUTL", "Headphone Jack", "HPOUTR", "Ext Spk", "SPKOUTL", "Ext Spk", "SPKOUTR", "AMIC", "MICBIAS", "IN3R", "AMIC", "IN1R", "AMIC"; }; &i2c3 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c3>; status = "okay"; pca6416: gpio@20 { compatible = "ti,tca6416"; reg = <0x20>; gpio-controller; #gpio-cells = <2>; }; ov5640_1: ov5640_mipi@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_csi0_pwn>, <&pinctrl_csi0_rst>, <&pinctrl_csi_mclk>; clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; clock-names = "xclk"; assigned-clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; assigned-clock-parents = <&clk IMX8MP_CLK_24M>; assigned-clock-rates = <24000000>; csi_id = <0>; powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; mclk = <24000000>; mclk_source = <0>; mipi_csi; status = "disabled"; port { ov5640_mipi_1_ep: endpoint { remote-endpoint = <&mipi_csi1_ep>; data-lanes = <1 2>; clock-lanes = <0>; }; }; }; codec: wm8962@1a { compatible = "wlf,wm8962"; reg = <0x1a>; clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; clock-names = "mclk"; wlf,shared-lrclk; AVDD-supply = <&reg_audio_pwr>; CPVDD-supply = <&reg_audio_pwr>; DBVDD-supply = <&reg_audio_pwr>; DCVDD-supply = <&reg_audio_pwr>; MICVDD-supply = <&reg_audio_pwr>; PLLVDD-supply = <&reg_audio_pwr>; SPKVDD1-supply = <&reg_audio_pwr>; SPKVDD2-supply = <&reg_audio_pwr>; gpio-cfg = < 0x0000 /* 0:Default */ 0x0000 /* 1:Default */ 0x0000 /* 2:FN_DMICCLK */ 0x0000 /* 3:Default */ 0x0000 /* 4:FN_DMICCDAT */ 0x0000 /* 5:Default */ >; }; };​ 私たちの分析によれば、カーネルがimx-wm8962マシンドライバの初期化を試みる際、I2Cバス上のWM8962コーデックはまだプローブ/登録を完了していません。WM8962はその後になってようやく初期化を完了する。このプローブの順序不一致により、ドライバーの初期化がエラーで失敗します。 この問題を分析し、この行動を解決するための解決策を提案していただけませんか? IMX8MPLUSオーディオソフトウェア_NXP_MICR Android Linux Re: wm8962 on i.mx8M Plus error コーデックやSAIプラットフォームデバイスが準備できない場合は-EPROBE_DEFER返します imx-wm8962.c でプローブパス、以下を区別する： DT phandle が欠落/無効です → 実際のエラー、-EINVAL を返します。 phandle は存在しますが、参照されているデバイスがまだ登録されていません → 依存関係が準備できていないため、-EPROBE_DEFER を返します。 例えば、概念的には： codec_np = of_parse_phandle(np、「オーディオコーデック」、0); if (!codec_np) { dev_err(&pdev->dev、「オーディオ-codec missing またはinvalid\n」);         -EINVAL を返します。 } codec_dev = of_find_i2c_device_by_node(codec_np); if (!codec_dev) { dev_info(&pdev->dev, "codec device not ready, defer probe\n"); of_node_put(codec_np);         return -EPROBE_DEFER; } CPU DAI / SAIノードについても同様です。 cpu_np = of_parse_phandle(np、「audio-cpu」、0); if (!cpu_np) { dev_err(&pdev->dev、「audio-cpu missing or invalid\n」);         -EINVAL を返します。 } cpu_pdev = of_find_device_by_node(cpu_np); if (!cpu_pdev) { dev_info(&pdev->dev、「SAIプラットフォームデバイスは準備完了、プローブを延期\n」); of_node_put(cpu_np);         return -EPROBE_DEFER; } 現在のマシンドライバーを使い続けるなら、これが最も直接的な解決策です。 可能であればLinux 5.4のFSL-asoc-cardパスを推奨します Linux 5.4時代のNXPカーネルでは、互換=「fsl,imx-audio-wm8962」はsound/soc/fsl/fsl-asoc-card.cによって処理され、コーデックDAI名「wm8962」やWM8962クロック/FLL IDを含む明示的なWM8962処理が行われます。また、snd-soc-fsl-asoc-card.ko がロードされているか、組み込まれていることを確認してください。 つまり、レガシー/カスタムのimx-wm8962マシンドライバーとFSL-ASOC-cardの両方が同じ互換文字列をバインドしようとするのは避けるべきです。推奨されるアプローチ： CONFIG_SND_SOC_FSL_ASOC_CARD を有効化/使用する; サウンドノードがCompatible = "FSL,IMX-オーディオ-WM8962"; 意図的に維持する場合を除き、その互換性のある文字列のレガシー/カスタム imx-wm8962 バインディングを削除または無効にします。 DTSに必要なSAIとコーデックDAIプロパティが備わっていることを確認してください。 コーデックノードは概ね想定どおりの形状です。WM8962 の例では compatible = "wlf,wm8962"、reg =<0x1a> �、clocks、supply properties、gpio-cfg を使用します。ただし、DTSに表示されていない部品を確認してください。 &sai3 {      #sound-dai-cells = <0>;         pinctrl-names = "default";      pinctrl-0 = <&pinctrl_sai3>;         assignment-clocks = <&clk IMX8MP_CLK_SAI3>;         assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assignment-clock-rates = <12288000>; /* またはボード指定のMCLK */ status = "オーケー"; }; また、コーデックは通常、以下の情報も公開する必要があります。 コーデック: wm8962@1a { 互換性 = "wlf,wm8962";      reg = <0x1a>;      #sound-dai-cells = <0>;      clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>;      clock-names = "mclk";      ... }; また、reg_audio_pwr で参照されるレギュレータが定義され、有効になっており、有効な電圧範囲を持っていることを確認してください。コーデックが検出されているので、電源がこの特定のエラーの原因ではない可能性が高いですが、電源の不具合やMCLKの設定不良が後のオーディオ故障の原因になることがあります。 MCLKイネーブルメントの検証 WM8962のブリングアップ問題の中には、オーディオマシンドライバでコーデックMCLKを有効にする必要があることが知られています。imx_wm8962_probe()にclk_prepare_enable(codec_clk)を加えると、WM8962の音声が動作すると報告されています。コーデックのプローブが成功したにもかかわらず、その後の再生/キャプチャが失敗する場合は、コーデックの初期化時およびストリームの起動時に、SAI3 MCLKが実際にコーデックピンに存在していることを確認してください。 サウンドカードのノードに重複や競合がないか確認してください。 このコーデック/SAIペアをターゲットにしているアクティブなサウンドノードは1つだけ、モデル文字列が一意であることを確認しましょう。コーデックプラットフォームデバイスの見つかりに失敗した類似の失敗は、NXPコミュニティデバッグにおけるサウンドカード命名や重複カードの競合に関連していました。ノード名はsound-wm8960-forenexと表示されていますが、対応モデルはWM8962です。ノード名自体は通常機能しませんが、明確にするために名前を変更し、他に2つ目のSound-WM8962ノードがないか確認したほうがいいでしょう。 推奨される最小パス 可能であればLinux 5.4用にFSL-asoc-cardを使いましょう。 WM8962 ノードに #sound-dai-cells = <0> が追加されている場合は、追加してください。 &sai3 が有効になっており、clocks/pinctrl が設定されていることを確認してください。 カスタムのimx-wm8962ドライバーを維持する場合は、失敗したコーデックやCPUの検索パスを-EINVALではなく-EPROBE_DEFERにパッチしてください。 MCLKが有効になっており、存在していることを確認してください。

wm8962 on i.mx8M Plus error We are designing our custom board based on the NXP i.MX 8M Plus (i.MX8MP) processor with the Wolfson WM8962 audio codec. We are currently porting the driver to the Linux kernel 5.4. Below are the error logs and our DTS (Device Tree Source) configuration. LOG: [ 2.097680] imx-wm8962 sound-wm8962: 2111111111111111111111111 [ 2.103533] imx-wm8962 sound-wm8962: 22222222222222222222222222 [ 2.109467] imx-wm8962 sound-wm8962: 333333333333333333 [ 2.114705] imx-wm8962 sound-wm8962: 888888888888888888 [ 2.119953] imx-wm8962 sound-wm8962: failed to find codec platform device [ 2.126759] imx-wm8962: probe of sound-wm8962 failed with error -22 [ 2.995796] wm8962 2-001a: afrrgrgtrggggggggggggggggggg [ 3.001038] wm8962 2-001a: bbbbbbbbbbbbbbbbbbbbbbbbb [ 3.008259] random: fast init done [ 3.011807] wm8962 2-001a: customer id 0 revision F​ DTS:   sound-wm8960-forenex { compatible = "fsl,imx-audio-wm8962"; model = "wm8962-audio"; audio-codec = <&codec>; audio-cpu = <&sai3>; audio-routing = "Headphone Jack", "HPOUTL", "Headphone Jack", "HPOUTR", "Ext Spk", "SPKOUTL", "Ext Spk", "SPKOUTR", "AMIC", "MICBIAS", "IN3R", "AMIC", "IN1R", "AMIC"; }; &i2c3 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c3>; status = "okay"; pca6416: gpio@20 { compatible = "ti,tca6416"; reg = <0x20>; gpio-controller; #gpio-cells = <2>; }; ov5640_1: ov5640_mipi@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_csi0_pwn>, <&pinctrl_csi0_rst>, <&pinctrl_csi_mclk>; clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; clock-names = "xclk"; assigned-clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; assigned-clock-parents = <&clk IMX8MP_CLK_24M>; assigned-clock-rates = <24000000>; csi_id = <0>; powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; mclk = <24000000>; mclk_source = <0>; mipi_csi; status = "disabled"; port { ov5640_mipi_1_ep: endpoint { remote-endpoint = <&mipi_csi1_ep>; data-lanes = <1 2>; clock-lanes = <0>; }; }; }; codec: wm8962@1a { compatible = "wlf,wm8962"; reg = <0x1a>; clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; clock-names = "mclk"; wlf,shared-lrclk; AVDD-supply = <&reg_audio_pwr>; CPVDD-supply = <&reg_audio_pwr>; DBVDD-supply = <&reg_audio_pwr>; DCVDD-supply = <&reg_audio_pwr>; MICVDD-supply = <&reg_audio_pwr>; PLLVDD-supply = <&reg_audio_pwr>; SPKVDD1-supply = <&reg_audio_pwr>; SPKVDD2-supply = <&reg_audio_pwr>; gpio-cfg = < 0x0000 /* 0:Default */ 0x0000 /* 1:Default */ 0x0000 /* 2:FN_DMICCLK */ 0x0000 /* 3:Default */ 0x0000 /* 4:FN_DMICCDAT */ 0x0000 /* 5:Default */ >; }; };​ Based on our analysis, when the kernel attempts to initialize the imx-wm8962 machine driver, the WM8962 codec on the I2C bus has not yet completed its probing/registration. The WM8962 only finishes its initialization afterward. This probe ordering discrepancy causes the driver initialization to fail with an error. Could you please help analyze this issue and suggest solutions to resolve this behavior? IMX8MPLUS AUDIO_SOFTWARE_NXP_MICR  Android Linux Re: wm8962 on i.mx8M Plus error Return -EPROBE_DEFER when the codec or SAI platform device is not ready In your imx-wm8962.c probe path, distinguish between: missing/invalid DT phandle → real error, return -EINVAL ; phandle exists, but referenced device is not registered yet → dependency not ready, return -EPROBE_DEFER . For example, conceptually: codec_np = of_parse_phandle(np, "audio-codec", 0); if (!codec_np) {         dev_err(&pdev->dev, "audio-codec missing or invalid\n");         return -EINVAL; } codec_dev = of_find_i2c_device_by_node(codec_np); if (!codec_dev) {         dev_info(&pdev->dev, "codec device not ready, defer probe\n");         of_node_put(codec_np);         return -EPROBE_DEFER; } Similarly for the CPU DAI / SAI node: cpu_np = of_parse_phandle(np, "audio-cpu", 0); if (!cpu_np) {         dev_err(&pdev->dev, "audio-cpu missing or invalid\n");         return -EINVAL; } cpu_pdev = of_find_device_by_node(cpu_np); if (!cpu_pdev) {         dev_info(&pdev->dev, "SAI platform device not ready, defer probe\n");         of_node_put(cpu_np);         return -EPROBE_DEFER; } This is the most direct fix if you keep your current machine driver. Prefer the Linux 5.4 fsl-asoc-card path if available For Linux 5.4-era NXP kernels, compatible = "fsl,imx-audio-wm8962" is handled by sound/soc/fsl/fsl-asoc-card.c , which has explicit WM8962 handling, including codec DAI name "wm8962" and WM8962 clock/FLL IDs . Also verify that snd-soc-fsl-asoc-card.ko is loaded or built in . That means you should avoid having both a legacy/custom imx-wm8962 machine driver and fsl-asoc-card trying to bind the same compatible string. Recommended approach: enable/use CONFIG_SND_SOC_FSL_ASOC_CARD ; ensure your sound node uses compatible = "fsl,imx-audio-wm8962"; ; remove or disable the legacy/custom imx-wm8962 binding for that compatible string, unless you intentionally maintain it. Make sure the DTS has the required SAI and codec DAI properties Your codec node is broadly in the expected shape: examples for WM8962 use compatible = "wlf,wm8962" , reg = <0x1a> , clocks , supply properties, and gpio-cfg . However, confirm the parts not shown in your DTS: &sai3 {         #sound-dai-cells = <0>;         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_sai3>;         assigned-clocks = <&clk IMX8MP_CLK_SAI3>;         assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;         assigned-clock-rates = <12288000>; /* or board-required MCLK */         status = "okay"; }; And the codec should also normally expose: codec: wm8962@1a {         compatible = "wlf,wm8962";         reg = <0x1a>;         #sound-dai-cells = <0>;         clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>;         clock-names = "mclk";         ... }; Also ensure the regulator referenced by reg_audio_pwr is defined, enabled, and has a valid voltage range. Your codec is being detected, so the supplies are probably not the cause of this specific error, but bad supply or MCLK setup can cause later audio failures. Verify MCLK enablement There is a known class of WM8962 bring-up issues where enabling the codec MCLK in the audio machine driver was required; adding clk_prepare_enable(codec_clk) in imx_wm8962_probe() was reported to make WM8962 audio work . If your codec probe succeeds but playback/capture later fails, check that SAI3 MCLK is actually present at the codec pin during codec initialization and stream startup. Check for duplicate or conflicting sound-card nodes Make sure only one active sound node targets this codec/SAI pair and that the model string is unique. A similar failure involving failed to find codec platform device was also associated with sound-card naming / duplicate-card conflicts in NXP community debugging . Your node name says sound-wm8960-forenex while the compatible/model are WM8962; the node name itself is not normally functional, but I would rename it for clarity and verify there is no second enabled sound-wm8962 node elsewhere. Recommended minimal path Use fsl-asoc-card for Linux 5.4 if possible. Add #sound-dai-cells = <0>; to the WM8962 node if missing. Confirm &sai3 is enabled and has clocks/pinctrl configured. If keeping your custom imx-wm8962 driver, patch the failed codec/CPU lookup paths to return -EPROBE_DEFER instead of -EINVAL . Confirm MCLK is enabled and present.

FRDM-IMX95でWi-Fi接続を自動で行うスクリプトの書き方 (日本語ブログ) ​ 1. はじめに FRDM-IMX95のようなボードで開発を進めていると、起動後に毎回手作業でWi-Fiに接続するのが煩わしくなってきます。そこで、モジュールのロードからDHCPによるIPアドレス取得までを一気に行うシェルスクリプト connect_wifi.sh を用意すると便利です。 一見単純なタスクですが、組み込みLinux環境（特にNXPの *moal ドライバや、機能を絞った wpa_supplicant ビルド）では、デスクトップLinuxでは遭遇しないいくつかの落とし穴があります。ここでは、実際に動作するスクリプト(connect_wifi.sh)を1行ずつ解説しながら、それぞれの処理がなぜ必要なのかを説明します。 対象は、i.MX 8M / i.MX 93 / i.MX 95 などNXP SoC上でYoctoベースのLinuxを扱う開発者を想定しています。 *MOAL（MAC OS/A-kernel/OS-adaptor Layer）ドライバとは？ 　主にNXP Semiconductors（旧Marvell）製の無線LAN（Wi-Fi）チップセットにおいて、LinuxやAndroidなどのOS上で動作するOS依存型のホストドライバモジュールです。   ＜目次＞ 1. はじめに 2.  完成版スクリプト (connect_wifi.sh) 3. 各ブロックの解説 3.1 前提チェック — 静かに失敗させない 3.2 認証情報の読み込み — クオートという落とし穴 3.3 ドライバのロードとインターフェース起動 3.4 PSKをPBKDF2で計算 — wpa_passphraseを使わない理由 3.5 wpa_supplicant.conf の生成 — ctrl_interfaceを忘れない 3.6 wpa_supplicant の起動 — 既存プロセスの掃除 3.7 接続完了のポーリング — 固定sleepにしない 3.8 DHCPでIPアドレス取得 3.9 DNS設定 4. スクリプトの実行 5. まとめ 6. 関連情報   ​ 2.  完成版スクリプト (connect_wifi.sh) まずconnect_wifi.shの全体像を示します。以降のセクションで各ブロックを順に解説します。 #!/bin/bash set -uo pipefail readonly CRED_FILE="/etc/wifi/wifi.conf" readonly WPA_CONF="/etc/wpa_supplicant.conf" readonly IFACE="mlan0" # --- 1. 前提チェック --- if [[ ${EUID} -ne 0 ]]; then     echo "[ERROR] root権限で実行してください" >&2     exit 1 fi if [[ ! -f "${CRED_FILE}" ]]; then     echo "[ERROR] 認証情報ファイルが見つかりません: ${CRED_FILE}" >&2     exit 1 fi # --- 2. 認証情報の読み込み --- SSID=$(grep -E '^SSID=' "${CRED_FILE}" | cut -d= -f2-) PASSWORD=$(grep -E '^PASSWORD=' "${CRED_FILE}" | cut -d= -f2-) # 前後のクオートを防御的に除去 SSID="${SSID%\"}"; SSID="${SSID#\"}" SSID="${SSID%\'}"; SSID="${SSID#\'}" PASSWORD="${PASSWORD%\"}"; PASSWORD="${PASSWORD#\"}" PASSWORD="${PASSWORD%\'}"; PASSWORD="${PASSWORD#\'}" if [[ -z "${SSID}" || -z "${PASSWORD}" ]]; then     echo "[ERROR] SSID または PASSWORD が読み取れません" >&2     exit 1 fi echo "[OK] 認証情報を読み込みました (SSID=${SSID})" # --- 3. ドライバのロードとインターフェース起動 --- modprobe moal mod_para=nxp/wifi_mod_para.conf echo "[OK] モジュールをロードしました" ip link set "${IFACE}" up 2>/dev/null echo "[OK] ${IFACE} をupにしました" # --- 4. PSKをPBKDF2で計算 --- PSK_HEX=$(python3 -c " import sys, hashlib, binascii ssid = sys.argv[1] passphrase = sys.stdin.readline().rstrip('\n') psk = hashlib.pbkdf2_hmac('sha1', passphrase.encode(), ssid.encode(), 4096, 32) print(binascii.hexlify(psk).decode()) " "${SSID}" <<< "${PASSWORD}") unset PASSWORD if [[ -z "${PSK_HEX}" ]]; then     echo "[ERROR] PSKの計算に失敗しました" >&2     exit 1 fi # --- 5. wpa_supplicant.conf の生成 --- cat > "${WPA_CONF}" <<EOF ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 network={     ssid="${SSID}"     psk=${PSK_HEX} } EOF chmod 600 "${WPA_CONF}" # --- 6. wpa_supplicant の起動 --- pkill -f "wpa_supplicant.*${IFACE}" 2>/dev/null sleep 1 wpa_supplicant -B -i "${IFACE}" -c "${WPA_CONF}" if [[ $? -ne 0 ]]; then     echo "[ERROR] wpa_supplicantの起動に失敗しました" >&2     exit 1 fi echo "[OK] wpa_supplicantを起動しました" # --- 7. 接続完了のポーリング --- connected=0 for i in $(seq 1 20); do     state=$(wpa_cli -i "${IFACE}" status 2>/dev/null | grep ^wpa_state | cut -d= -f2)     echo "  [${i}/20] wpa_state=${state:-unknown}"     if [[ "${state}" == "COMPLETED" ]]; then         connected=1         break     fi     sleep 1 done if [[ ${connected} -eq 0 ]]; then     echo "[ERROR] Wi-Fi認証に失敗しました(タイムアウト)" >&2     exit 1 fi echo "[OK] Wi-Fi認証に成功しました" # --- 8. DHCPでIPアドレス取得 --- udhcpc -i "${IFACE}" -n -t 5 -T 3 if [[ $? -ne 0 ]]; then     echo "[ERROR] DHCPによるIPアドレス取得に失敗しました" >&2     exit 1 fi echo "[OK] DHCPでIPアドレスを取得しました" # --- 9. DNS設定 --- if ! grep -q "nameserver 8.8.8.8" /etc/resolv.conf 2>/dev/null; then     echo "nameserver 8.8.8.8" >> /etc/resolv.conf fi echo "=== 接続完了 ===" ip addr show "${IFACE}" 認証情報は、スクリプト本体とは分離した /etc/wifi/wifi.conf に置きます。 root@frdm-imx95:~# mkdir -p /etc/wifi root@frdm-imx95:~# cat > /etc/wifi/wifi.conf <<'EOF' SSID=exampleSSID PASSWORD=examplePassword EOF 認証情報は他のユーザーからアクセスできないよう、権限を変更しておきます。 root@frdm-imx95:~# chmod 600 /etc/wifi/wifi.conf   ​ 3. 各ブロックの解説 ​ 3.1 前提チェック — 静かに失敗させない set -uo pipefail '-u'オプション は未定義変数の参照をエラーにし、'-o pipefail' はパイプ内のいずれかのコマンドが失敗した場合に終了コードへ反映します。 なお、あえて '-e'（エラーで即終了）は付けていません。ネットワーク系のコマンドは「失敗しても後続の診断を続けたい」ケースが多く、'-e' があると失敗した瞬間に何のメッセージも出さずにスクリプトが終わってしまうためです。代わりに、各コマンドの直後で '$?' を明示的にチェックし、どの段階で失敗したかを '[OK]' / '[ERROR]' のログとして残す方針にしています。 root権限チェックと認証情報ファイルの存在チェックも、後続処理が意味不明なエラーで落ちる前に、原因を明確にして早期終了させるためのものです。 ​ 3.2 認証情報の読み込み — クオートという落とし穴 SSID=$(grep -E '^SSID=' "${CRED_FILE}" | cut -d= -f2-) 認証情報ファイルから 'SSID=' で始まる行を取り出し、'=' 以降を値として抽出します。'cut -d= -f2-' の '-f2-'（2フィールド目以降すべて）がポイントで、これによりパスワードに '=' が含まれていても正しく取り出せます。 続く4行のクオート除去が、実は本スクリプトで最も重要な防御処理です。 SSID="${SSID%\"}"; SSID="${SSID#\"}" これはbashのパラメータ展開で、'${var%\"}' が末尾のダブルクオート、'${var#\"}' が先頭のダブルクオートを除去します。 なぜ必要かというと、認証情報ファイルにうっかり 'SSID="exampleSSID"' とクオート付きで書いてしまった場合、'cut' はクオートも含めて値として取り込みます。その状態で後段の 'wpa_supplicant.conf' 生成時に 'ssid="${SSID}"' とさらにクオートを付けると、 ssid=""exampleSSID"" という二重クオートになります。'wpa_supplicant' のパーサーは外側の1組しか想定していないため、内側のクオートまでSSIDの一部として解釈してしまい、スキャン結果に存在するはずのAPとマッチしません。結果として 'wpa_state' が 'SCANNING' から一切進まないという、原因の分かりにくい症状になります。 この防御処理を入れておけば、認証情報ファイルの記法がクオートあり・なしのどちらでも正しく動作します。 ​ 3.3 ドライバのロードとインターフェース起動 modprobe moal mod_para=nxp/wifi_mod_para.conf ip link set "${IFACE}" up 2>/dev/null NXPのWi-Fiは 'moal' カーネルモジュールで提供され、'mod_para' でファームウェアの動作パラメータファイルを指定します。ロード後にインターフェース（ここでは 'mlan0'）を明示的にupしておきます。 ​ 3.4 PSKをPBKDF2で計算 — wpa_passphraseを使わない理由 通常、WPA2-PSKの設定生成には 'wpa_passphrase' コマンドを使います。しかし組み込み環境では2つの問題に直面しました。 パスワードの露出です。'wpa_passphrase SSID PASSWORD' のように引数で渡すと、実行中に 'ps' コマンドや '/proc/ /cmdline ' から平文パスワードが見えてしまいます。 標準入力経由での動作不良です。露出を避けるため 'wpa_passphrase "$SSID" <<< "$PASSWORD"' とヒアストリングで渡すと、環境によっては次のエラーが出て空のファイルが生成されました。 reading passphrase from stdin tcgetattr: Inappropriate ioctl for device これは 'wpa_passphrase' が端末のエコーを制御しようと 'tcgetattr()' を呼ぶものの、標準入力が実端末（TTY）ではないために失敗し、その後のパスフレーズ読み込みも中断されるためです。 そこで、WPA2-PSKの鍵導出仕様をそのままpython3で実装しました。 psk = hashlib.pbkdf2_hmac('sha1', passphrase.encode(), ssid.encode(), 4096, 32) WPA2-PSKのPSKは、仕様上 PBKDF2-HMAC-SHA1(パスフレーズ, SSID, 4096回, 256bit) という決まった計算で導出されます。これを直接計算することで、'wpa_passphrase' のTTY依存を完全に回避できます。パスワードは引数ではなく 'sys.stdin' から受け取るため 'ps' にも露出しません。 unset PASSWORD 計算が終わったら、平文パスワードを保持する変数は速やかに破棄します。 ​ 3.5 wpa_supplicant.conf の生成 — ctrl_interfaceを忘れない cat > "${WPA_CONF}" <<EOF ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 network={     ssid="${SSID}"     psk=${PSK_HEX} } EOF このブロックで見落としやすいのが冒頭の `ctrl_interface` の指定です。 'wpa_cli' は '/var/run/wpa_supplicant/<インターフェース名>' というUNIXドメインソケット経由で 'wpa_supplicant' と通信します。このソケットは 'ctrl_interface' を設定ファイルに書かないと生成されません。これを忘れると、後段のポーリング（'wpa_cli status'）が次のエラーで動かず、実際には接続に成功していても状態を取得できないため「失敗」と誤判定してしまいます。 Failed to connect to non-global ctrl_ifname: mlan0  error: No such file or directory また、'psk=' 行の値（'PSK_HEX'）は16進のハッシュ値なのでクオートを付けません。クオートを付けると平文パスフレーズとして再解釈されてしまうため注意が必要です。一方 'ssid=' は文字列なのでクオートで囲みます。 生成後は 'chmod 600' で他ユーザーから読めないようにします。 ​ 3.6 wpa_supplicant の起動 — 既存プロセスの掃除 pkill -f "wpa_supplicant.*${IFACE}" 2>/dev/null sleep 1 wpa_supplicant -B -i "${IFACE}" -c "${WPA_CONF}" 再実行時に古い 'wpa_supplicant' プロセスが残っていると、新しいプロセスとソケットが競合したり、古い設定のまま動き続けたりします。起動前に 'pkill' で確実に掃除しておきます。'-B' はバックグラウンド実行を指定するオプションです。 デバッグ時にログをファイルへ出したくなりますが、ビルドによっては '-B'（バックグラウンド）と '-f'（ログファイル）を併用できないことがあります（'-f' 未サポートのビルドでは引数解析に失敗し、ヘルプが表示されて起動しません）。その場合は次のようにシェルのリダイレクトを使います。 wpa_supplicant -dd -i "${IFACE}" -c "${WPA_CONF}" > /var/log/wpa_supplicant.log 2>&1 &   ​ 3.7 接続完了のポーリング — 固定sleepにしない for i in $(seq 1 20); do     state=$(wpa_cli -i "${IFACE}" status 2>/dev/null | grep ^wpa_state | cut -d= -f2)     echo "  [${i}/20] wpa_state=${state:-unknown}"     if [[ "${state}" == "COMPLETED" ]]; then         connected=1         break     fi     sleep 1 done 電波状況によって認証完了までの時間は変動するため、固定待機は「まだ繋がっていないのに次へ進む」「無駄に待ちすぎる」のどちらかになりがちです。 代わりに 'wpa_cli status' の 'wpa_state' を1秒間隔でポーリングし、'COMPLETED' になった時点で先へ進みます。各ステップで状態を出力しているので、認証がどのフェーズで止まっているか（'SCANNING' / 'ASSOCIATING' / '4WAY_HANDSHAKE' など）がリアルタイムに見えるのも利点です。 'wpa_state' の正常な遷移は次のとおりです。 DISCONNECTED → SCANNING → AUTHENTICATING → ASSOCIATING → ASSOCIATED → 4WAY_HANDSHAKE → GROUP_HANDSHAKE → COMPLETED どこで止まるかによって原因の切り分けができます。'SCANNING' から進まなければAPが見つかっていない（SSID誤り、電波、バンド設定など）、'4WAY_HANDSHAKE' で 'WRONG_KEY' が出れば鍵（パスワードまたはSSID）の不一致、といった具合です。   ​ 3.8 DHCPでIPアドレス取得 udhcpc -i "${IFACE}" -n -t 5 -T 3 BusyBoxの 'udhcpc' (Micro DHCP Client) でIPアドレスを取得します。 オプションは、 '-n'（リース取得失敗時に終了） '-t 5'（リクエスト再送を最大5回） '-T 3'（再送間隔3秒） です。これらを指定しないと、DHCPサーバに到達できない環境でスクリプトが無限に待ち続けてしまうため、必ず入れておきます。 ​ 3.9 DNS設定 if ! grep -q "nameserver 8.8.8.8" /etc/resolv.conf 2>/dev/null; then     echo "nameserver 8.8.8.8" >> /etc/resolv.conf fi '/etc/resolv.conf' にフォールバック用のDNSサーバを追記します。既に同じ行があれば重複追記しないよう 'grep' でチェックしています。 なお、DHCP取得したDNS情報をネットワーク管理系（udhcpcのデフォルトスクリプトやsystemd-resolvedなど）が '/etc/resolv.conf' に書き込む構成では、手動追記が上書きされることがあります。固定DNSを確実に効かせたい場合は、udhcpc側のフックスクリプトで制御するのが本来は堅実です。   ​ 4. スクリプトの実行 作成したスクリプトに'chmod'コマンドで実行権限を付加し、実行します。 root@frdm-imx95:~# chmod +x connect_wifi.sh root@frdm-imx95:~# ./connect_wifi.sh ​ 5. まとめ FRDM-IMX95上でのWi-Fi自動接続スクリプトを題材に、組み込みLinux特有の注意点を解説しました。デスクトップLinuxでは意識する必要のない、次のようなポイントがつまずきどころになります。 'wpa_passphrase' はヒアストリング入力でTTYエラーになることがあり、PBKDF2の自前計算が確実 'wpa_supplicant.conf' に 'ctrl_interface' がないと 'wpa_cli' で状態を取得できない SSIDのクオートの二重化は 'SCANNING' から進まない原因になる SSIDはPSK計算の入力の一部であり、SSIDの誤りは鍵の不一致として現れる ビルドによっては '-B' と '-f' を併用できない 同様の課題に取り組まれている方の参考になれば幸いです。 ​ 6. 関連情報 i.MX FRDMボードの部屋 Yocto Linux BSPの利用方法 ～まとめページ～ (日本語ブログ) ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） FRDM-IMX95に搭載されているWi-Fiモジュールを、起動後に毎回手作業で接続するは非常に煩わしいです。そこで本記事では、起動時に自動でWi-Fi接続するための方法と、スクリプトの書き方例について紹介します。 同様のWi-Fiモジュールを搭載しているi.MXファミリの評価ボードにも流用できます。 (読了：20分) (作業時間: 10分) ※i.MX向けYocto Linuxをビルド、動作確認している前提 i.MX Processors 日本語ブログ

LX2162A USXGMII link never completes Hey all, I have an LX2162A SoM manufactured by Solidrun. I'm using a Clearfog devkit but moving to a custom carrier soon.  Solidrun provides base RCW/DCP/DPL and I've verified functionality. In my case, the DPC for dpmac3 works for the SFP cage and I get an XFI link via SFP DAC cable and various SFP modules. The RCW "rcw_2000_650_2900_3_11_0_auto" sets to SerDes1=3, SerDes2=11 and I'm using a QorIQ kernel (lf-6.6.52-2.2.0) and mc-utils (10.39.0) but with some Solidrun patched applied to both. Uboot and other things are also patched. All patches come from here: https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 I have a MaxLinear GPY245-EKV-1 (and -2) devkit(s) that wants USXGMII over DAC cable to connect the phy to the device. Apparently this is pretty normal. Eventually this phy chip will be integrated into SerDes2=7 Lane6 and Lane7 but I have to use the SFP cage on the Clearfog for testing. Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP I'm only trying to configure dpmac3 to use this USXGMII link via DPC: mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; (I've also tried MAC_LINK_TYPE_BACKPLANE) Confirmed via "restool dpmac info dpmac.3" shows "DPMAC ethernet interface: DPMAC_ETH_IF_USXGMII". In Linux, I added the MaxLinear driver and patched a few things: gpy_update_interface() fix (LKML, Daniel Golle). This was returning -EINVAL for USXGMII interface, crashing phy_state_machine. Patched lynx_pcs_config_usxgmii() in pcs-lynx.c to also write MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART) via mdiobus_c45_modify(), since the function only ever wrote MII_ADVERTISE and never enabled AN on the Replicator block itself. This gap matches another post on this forum ("LS1028A 10g-qxgmii phy bring-up") which found the identical symptom (MMD31.0/Replicator control register stuck at 0) and got AN to kick in after manually setting bit 12. This is the DPMAC3 Linux devicetree entry: &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; where `gpy245_0` is the MDIO node. MDIO traffic to the phy is working. I added a printout in the lynx_pcs driver which shows the readback: mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 Question: Given writes to MDIO_MMD_VEND2 registers on this PCS instance don't appear to persist, is there a known additional step (SerDes/PCS block enable, protocol-specific initialization, or similar) required before the USXGMII on the LX2162A family SoCs will accept configuration? Is protocol 3 fully validated for USXGMII on dpmac3, or primarily intended/tested for XFI? Other questions: Maybe I don't understand GPY245 and USXGMII. I see some folks refer to this as QXGMII and I can't tell if the LX2162A is even capable of that working. Maybe I need to reach out to Solidrun, but all of their patches do not seem to limit the LX2162A's capability. Thanks! Re: LX2162A USXGMII link never completes @yipingwang I really appreciate the detailed response! Everything you said makes sense and I've started learning more about the platform. I've started using the advice in AN13329.pdf. Some of the addresses and things aren't working (probably a version mismatch) but at least I can get the MC log as shown below: => md 0x8340020 10 08340020: e0000006 00000021 00060000 00000000 ....!........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ => md 0x21e1000000 21e1000000: 4d430100 00000000 01400000 00300000 [email protected]. 21e1000010: 00000073 00000000 00000000 00000000 s............... 21e1000020: 00000000 00000000 00000000 00000000 ................ 21e1000030: 00000000 00000000 00000000 00000000 ................ => md 0x21e1400000 50 21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U 21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed 21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data 21e1400030: 6c697720 6562206c 69727020 6465746e will be printed 21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn 21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait 21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events . 21e1400070: 000a2e2e 00000000 00000000 00000000 ................ 21e1400080: 00000000 00000000 00000000 00000000 ................ 21e1400090: 00000000 00000000 00000000 00000000 ................ 21e14000a0: 00000000 00000000 00000000 00000000 ................ 21e14000b0: 00000000 00000000 00000000 00000000 ................ 21e14000c0: 00000000 00000000 00000000 00000000 ................ 21e14000d0: 00000000 00000000 00000000 00000000 ................ 21e14000e0: 00000000 00000000 00000000 00000000 ................ 21e14000f0: 00000000 00000000 00000000 00000000 ................ 21e1400100: 00000000 00000000 00000000 00000000 ................ 21e1400110: 00000000 00000000 00000000 00000000 ................ 21e1400120: 00000000 00000000 00000000 00000000 ................ 21e1400130: 00000000 00000000 00000000 00000000 ................ I've attempted to poke at the PCCC via uboot. Here are the relevant things: crc32+ MC firmware version 10.39.0 fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1) Autoboot in 3 seconds => mmc read 0x80d00000 0x6800 0x800 => fsl_mc apply dpl 0x80d00000 fsl-mc: Deploying data path layout ... SUCCESS => md.l 0x1ea10b0 1 01ea10b0: 88889991 .... I really hope 0x1ea10b0 is the right address. According the LX2162ARM.pdf, that *could* be the right address and decoding the bits shows: A (lane 0) bit 31 1 = XFI/SFI B (lane 1) bit 27 1 = XFI/SFI C (lane 2) bit 23 1 = XFI/SFI D (lane 3) bit 19 1 = XFI/SFI Is the right right register address (PCCC) to observe? Is there any other information I can provide? Thanks! Re: LX2162A USXGMII link never completes The LX2162A side is documented to support USXGMII on the paths you are using , but the symptom you show looks less like a missing Linux pcs-lynx write and more like the selected PCS instance is still not actually in USXGMII application mode, or MC firmware is programming the wrong 10G PCS selector. For SerDes1 protocol 3 , the LX2162A reference manual lists all four SerDes1 lanes as USXGMII / XFI , including USXGMII / XFI.3 for the first lane, which corresponds to the DPMAC3 use case you are testing on the Clearfog SFP path . For your future custom-carrier target, SerDes2 protocol 7 also documents lane 6 and lane 7 as USXGMII / XFI.13 and USXGMII / XFI.14 . The important catch is that the USXGMII / XFI entry is not automatically “USXGMII.” The reference manual says that between USXGMII and XFI on a lane, the default is XFI . The mode is selected through PCCC , the Protocol Configuration Register C, and its SXGMII*_XFI bits select 0b = USXGMII and 1b = XFI/SFI . So the first thing I would check is not the Linux BMCR write itself, but whether the specific SXGMII instance for DPMAC3 has its PCCC XFI-select bit cleared after MC/DPC initialization. There is also precedent for this exact class of failure being in MC firmware , not in the Linux PCS driver: one LX2162A ticket shows MC clearing the wrong 10G interface selector in PCCC for a USXGMII configuration, and an MC firmware engineering build, version 10.35.101 , resolved the issue . Another ticket notes that MC settings are done by MC firmware, with NXP providing MC as a binary . Since you are on MC 10.39.0 , you should be beyond that specific old fix, but the failure mode you see is still consistent with “MC did not put the intended PCS into USXGMII mode” or “the wrong PCS instance is being addressed.” What I would do next: Read PCCC before Linux changes anything. After RCW + MC + DPL/DPC load, but before the Linux PCS driver runs, read PCCC and confirm the relevant SXGMII*_XFI bit is 0 . For DPMAC3 / USXGMII/XFI.3 , expect the first SXGMII selector, not the selector for MAC13/14. If that bit remains 1 , the lane is still XFI/SFI and your VEND2/USXGMII PCS writes are not being applied to a live USXGMII PCS path. Check that the MDIO access is hitting the intended PCS management port. The SXGMII protocol-control register has an MDEV_PORT field used to match MDIO accesses, and the manual says software must wait at least 3 platform clocks after changing it before MDIO accesses to the SGMII/PCS target . If the MDIO address decode is wrong, writes can appear to “not persist” because you are reading a different or reset/default PCS window. Confirm the USXGMII AN registers are meaningful only after the mode select is correct. The USXGMII PCS CONTROL register has AUTO_NEGOTIATION_ENABLE at bit 12, and DEV_ABILITY / PARTNER_ABILITY are RW registers . The DEV_ABILITY lower vendor arbitrary speed field must be non-zero, because zero can cause auto-negotiation failure . But if PCCC still selects XFI, these BMCR/ability writes are not the real root problem. Do not treat QXGMII as a separate required external protocol unless the GPY245 board documentation explicitly says so. LX2162A documentation does contain QXGMII protocol-converter registers, including reset/powerdown control bits such as PD_QXGM and RST_QXGM . NXP community material for LS1028A also refers to a 10G_QXGMII Lynx SerDes driver path . But the documented LX2162A DPMAC interface you are selecting is still USXGMII / XFI , and NXP documentation separately states that LX2160-class devices support USXGMII and that “SXGMII” is not the same thing . In other words: “QXGMII” references in driver/community discussions may describe an internal converter/driver naming path, not necessarily a different MAC-to-PHY contract than the USXGMII mode you configured. For this Clearfog SFP test, keep the DPC simple. MAC_LINK_TYPE_PHY with enet_if = "USXGMII" is the more natural model for a managed external PHY over MDIO. I would not expect MAC_LINK_TYPE_BACKPLANE to fix a PHY-facing USXGMII setup unless you are intentionally using a backplane/KR-style flow. I would not conclude that protocol 3 is “primarily XFI-only.” The reference manual documents protocol 3 as USXGMII / XFI for DPMAC3’s SerDes1 lane . What I cannot verify from the retrieved material is a separate validation statement saying “protocol 3 + DPMAC3 + USXGMII was validated with GPY245.” The stronger, evidence-backed statement is: the hardware mode exists, defaults to XFI unless PCCC selects USXGMII, and there is known MC-firmware precedent for programming the wrong 10G PCS selector . For your specific readback: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 that is exactly the kind of result I would expect if the PCS instance is not fully enabled/selected for USXGMII, or the MDIO management window is not addressing the intended PCS instance. I would verify PCCC and the MC log first, before adding more Linux-side writes. LX2162A protocol 3 is documented for USXGMII / XFI on DPMAC3, but USXGMII depends on MC/PCCC selecting the USXGMII PCS; if VEND2/BMCR writes do not persist, first prove the correct PCCC bit is cleared for DPMAC3 and that MDIO is addressing the correct SXGMII PCS instance. Re: LX2162A USXGMII link never completes Yes. For SerDes1 ,  0x1ea10b0  is the right address for PCCC : LX2162A CCSR map lists SerDes 1 at  0x1EA_0000–0x1EA_FFFF  . The SerDes memory map lists Protocol Configuration Register C / PCCC at offset  0x10B0  . Therefore: 0x1EA0000+0x10B0=0x1EA10B00x1EA0000+0x10B0=0x1EA10B0 So your U-Boot read: Copy => md.l 0x1ea10b0 1 01ea10b0: 88889991   is observing the expected SerDes1 PCCC register. The important caveat is the naming: I would not describe those fields as physical SerDes lane A/B/C/D for your current setup. In the LX2162A SerDes1 protocol table, protocol  3  maps physical lane H / lane 0 to  USXGMII / XFI.3  , then lane G/lane 1 to  .4  , lane F/lane 2 to  .5  , and lane E/lane 3 to  .6  . PCCC field names such as  SXGMIIA_XFI  ,  SXGMIIB_XFI  , etc. are PCS/protocol-control fields, not necessarily the same naming convention as the physical lane letters. For your value  0x88889991  , the high nibbles decode like this: Copy PCCC = 0x88889991 bits 31:28 = 0x8 -> SXGMIIA_XFI = 1, CFG = 000 bits 27:24 = 0x8 -> SXGMIIB_XFI = 1, CFG = 000 bits 23:20 = 0x8 -> SXGMIIC_XFI = 1, CFG = 000 bits 19:16 = 0x8 -> SXGMIID_XFI = 1, CFG = 000 bits 15:12 = 0x9 -> SXGMIIE_XFI = 1, CFG = 001 bits 11:8 = 0x9 -> SXGMIIF_XFI = 1, CFG = 001   The key bit is the  _XFI  bit. The RM defines  0  as USXGMII mode and  1  as XFI/SFI mode for these fields . So the value you read strongly suggests the relevant USXFI/SXGMII PCS instances are still being selected as XFI/SFI , not USXGMII. That lines up with your symptom: Linux/restool may report  DPMAC_ETH_IF_USXGMII  , but if PCCC still has the relevant  _XFI  select bit at  1  , the underlying SerDes/PCS selection is still effectively in XFI/SFI mode. The RM also explicitly says that to enable 10G-SXGMII, software must set  PCCC[SGMIIa_XFI] = 0  . Your MC log extraction also looks sane. AN13329 says to read MCFBAL/MCFBAH at  0x8340020  , build the MC firmware base, then dump the log-buffer structure at offset  0x01000000  ; the structure contains the magic, log-buffer offset, and log-buffer length . Your  0x21e1000000  dump shows the expected  0x4d430100  magic and points to log offset  0x01400000  , which matches your later dump at  0x21e1400000  . What I would capture next: PCCC snapshots at each stage Copy md.l 0x1ea10b0 1 Capture it: immediately after reset / before MC boot if possible, after MC boot, after DPC/DPL apply, after Linux boots, after the DPMAC is probed/configured. Adjacent protocol config registers Copy md.l 0x1ea10a0 1 # PCC8 md.l 0x1ea10a4 1 # PCC9 md.l 0x1ea10b0 1 # PCCC PCC8/PCC9 contain other SGMII configuration fields, while PCCC is the SXGMII/XFI selector register . Confirm which PCCC field changes when you try forcing USXGMII If you can safely poke in U-Boot for experiment only, try clearing the candidate  _XFI  bit and reading it back immediately. For example, if dpmac3 corresponds to the first SXGMII/USXFI control field, clearing bit 31 would be the experimental check: Copy mw.l 0x1ea10b0 0x08889991 1 md.l 0x1ea10b0 1 If it immediately reads back as  0x88889991  , then either the write is blocked/overridden, or that field is not writable in the current block state. If it sticks until MC or Linux runs, then MC/Linux is likely restoring XFI/SFI mode. Full RCW SerDes decode You already have  SerDes1=3, SerDes2=11  ; that matches the dpmac3 lane being available as  USXGMII / XFI.3  under SerDes1 protocol 3 . Still, include the full RCW string and raw RCW dump when escalating, because MC firmware often keys off the complete protocol set. MC firmware + DPC/DPL artifacts Since your MC is  10.39.0  , include: MC firmware version, DPC source, DPL source, exact  dpmac@3  block, restool dpmac info dpmac.3  , the PCCC value after each step. My current read of your data: yes,  0x1ea10b0  is the correct SerDes1 PCCC address, and  0x88889991  looks like the relevant PCS selectors are still in XFI/SFI mode. That is consistent with XFI working through the SFP cage and USXGMII not accepting/retaining the expected PCS configuration.