S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt Hi, I'm using the following configuration: S32K388EVB-Q289 S32DS 3.6.8 RTD 7.0.1 I used the provided Eth_InternalLoopback_S32K388 example project as base, and modified it so that it can receive frames from my PC through a media converter. I have added in the RTD fix which was mentioned in Example S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600. I was able to hit the breakpoint in  Eth_43_GMAC_Receive(EthConf_EthCtrlConfig_EthCtrlConfig_0, 0U, &Status); And was able to inspect the Ethernet frame in EthIf_RxIndication(Eth_43_GMAC_apxInternalCfg[PartitionId]->Eth_43_GMAC_apCtrlConfig[CtrlIdx]->EthCtrlEthIfIdx, FrameType, IsBroadcast, MacSrcAddr, Payload, PayloadLength, IngressTimeTuplePtr, RxHandleId); However, when I added a while 1 loop, enabled the Rx Interrupt and linked it to the GMAC0_CH0_RX_IRQHandler I was not able to get any interrupt anywhere. I have attached my project below. James_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.png S32K3 AUTOMOTIVE-RTD  Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt Hello @James_Zhang_SE , I checked the attached project. To enable RX IRQ in RTD7.0.1, you need to change Ingress QueueHandlerFunction and enable QueueInterrupt: PavelL_0-1788263577590.pngPavelL_0-1788263577590.pngPavelL_0-1788263577590.png After that change, I hit breakpoint at GMAC_RxIRQHandler(), resp. at Eth_43_GMAC_Receive(). I also noticed that your RGMII TXCLK is defined as Input -> it should be Output. However, to see your TX frame in Wireshark, you need to change the init sequence accordingly to  Example S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600. So, in your project, it looks like: PavelL_1-1788264277735.pngPavelL_1-1788264277735.pngPavelL_1-1788264277735.png Best regards, Pavel Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt Hi Pavel, Thank you very much for your support. After applying the fixes you suggested, the GMAC driver is now working for me. I do have a few additional questions, and I would appreciate your guidance: Is there any detailed documentation that describes the complete procedure for configuring and using the GMAC driver? I would like to go through the documentation myself first so that I can better understand the driver before asking too many questions. Inside EthIf_RxIndication(), do I need to call Eth_43_GMAC_ReleaseRxBuffer(CtrlIdx, RxHandleId); at the end of the function to release the received buffer? There are quite a few GMAC configuration options available. Is there any documentation or reference that explains what each configuration parameter does and how it should be configured? Thank you again for your help. I really appreciate your support. Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt Hi @James_Zhang_SE , Thank you for sharing your update. I am glad to hear that the GMAC driver is now working for you. Regarding your additional questions: 1. The main reference for configuring and using the driver is the Eth_43_GMAC User Manual, which is included in the RTD installation, e.g.: C:\NXP\S32DS.3.6.6_RTD701\S32DS\software\PlatformSDK_S32K3\RTD\Eth_43_GMAC_TS_T40D34M70I1R0\doc\RTD_ETH_43_GMAC_UM.pdf I also recommend reviewing the corresponding Eth_43_GMAC Integration Manual (RTD_ETH_43_GMAC_IM.pdf), saved in the same directory, and the available GMAC example projects.   2. Whether Eth_43_GMAC_ReleaseRxBuffer() must be called depends on the EthCtrlReleaseResourceAfterReception configuration parameter. PavelL_0-1789024403441.png If automatic release after reception is enabled, the driver releases the RX resource after EthIf_RxIndication() returns and you should not release it explicitly. If automatic release is disabled, the received buffer remains allocated after EthIf_RxIndication() returns. In that case, the application must eventually call: Eth_43_GMAC_ReleaseRxBuffer(CtrlIdx, RxHandleId);   This mode is useful when the application needs to retain the received data for further processing. However, the buffer must be released after the application has finished using it. Otherwise, the available RX buffers will eventually be exhausted. Please also note that the received Payload pointer should not be used after the corresponding buffer has been released. 3. The Eth_43_GMAC User Manual is also the primary reference for the individual configuration parameters. In addition, S32 Configuration Tools displays a description for many parameters when the corresponding setting is selected or hovered over. For hardware-level behavior, such as MAC filtering, DMA operation, MTL queues, timestamps and interrupt status, please refer to the GMAC/EMAC chapter of the S32K3 Reference Manual. As a practical starting point, I recommend referencing GMAC examples provided by the RTD package. There are also functional lwIP examples on the page: https://community.nxp.com/t5/S32K-Knowledge-Base/S32K-Examples/ta-p/1108990 Please do not hesitate to ask for support in case you observe any issue. A dedicated thread for each topic is preferred. It helps keep us clarity of cases for other users. Best regards, Pavel

S32K388 GMAC0 Eth_43_GMAC 驱动程序未收到 RX 中断 您好， 我使用的是以下配置： S32K388EVB-Q289 S32DS 3.6.8 RTD 7.0.1 我以提供的 Eth_InternalLoopback_S32K388 示例项目为基础，并对其进行了修改，使其可以通过媒体转换器从我的 PC 接收帧。我添加了示例 S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600中提到的 RTD 修复程序。我成功达到了断点 Eth_43_GMAC_Receive(EthConf_EthCtrlConfig_EthCtrlConfig_0, 0U, &Status); 并且能够检查以太网帧 EthIf_RxIndication(Eth_43_GMAC_apxInternalCfg[PartitionId]->Eth_43_GMAC_apCtrlConfig[CtrlIdx]->EthCtrlEthIfIdx, FrameType, IsBroadcast, MacSrcAddr, Payload, PayloadLength, IngressTimeTuplePtr, RxHandleId); 但是，当我添加了一个 while 1 循环，启用了 Rx 中断并将其链接到 GMAC0_CH0_RX_IRQHandler 时，我却无法在任何地方获得任何中断。我的项目文件附在下面。 James_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.png S32K3汽车-RTD Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt 你好@James_Zhang_SE ， 我查看了附件中的项目。要在 RTD7.0.1 中启用 RX IRQ，您需要更改 Ingress QueueHandlerFunction 并启用 QueueInterrupt： PavelL_0-1788263577590.pngPavelL_0-1788263577590.pngPavelL_0-1788263577590.png 更改之后，我在 GMAC_RxIRQHandler() 处触发了断点。在 Eth_43_GMAC_Receive()。 我还注意到您的 RGMII TXCLK 被定义为输入 -> 它应该是输出。 但是，要在 Wireshark 中查看您的 TX 帧，您需要相应地更改初始化序列。 例如，S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600 。因此，在您的项目中，它看起来像这样： PavelL_1-1788264277735.pngPavelL_1-1788264277735.pngPavelL_1-1788264277735.png 顺祝商祺！ 帕维尔 Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt 你好，帕维尔， 非常感谢您的支持。按照您建议的修复方法操作后，GMAC 驱动程序现在可以正常工作了。 我还有几个问题，希望您能指导我： 是否有详细的文档描述了配置和使用 GMAC 驱动程序的完整步骤？我想先自己仔细阅读一下文档，以便在提出太多问题之前更好地了解驱动程序。 在EthIf_RxIndication() 函数内部，我需要调用吗？ Eth_43_GMAC_ReleaseRxBuffer(CtrlIdx, RxHandleId); 在函数结束时释放接收缓冲区？ GMAC提供了相当多的配置选项。是否有任何文档或参考资料解释每个配置参数的作用以及应该如何配置？ 再次感谢您的帮助。我非常感谢您的支持。 Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt 你好@James_Zhang_SE ， 感谢您分享最新情况。很高兴得知 GMAC 驱动程序现在对您有效。 关于您提出的其他问题： 1.配置和使用驱动程序的主要参考资料是 Eth_43_GMAC 用户手册，该手册包含在 RTD 安装包中，例如：C:\NXP\S32DS.3.6.6_RTD701\S32DS\software\PlatformSDK_S32K3\RTD\Eth_43_GMAC_TS_T40D34M70I1R0\doc\RTD_ETH_43_GMAC_UM.pdf 我还建议查阅保存在同一目录下的相应 Eth_43_GMAC 集成手册 (RTD_ETH_43_GMAC_IM.pdf) 以及可用的 GMAC 示例项目。   2. 是否必须调用 Eth_43_GMAC_ReleaseRxBuffer() 取决于 EthCtrlReleaseResourceAfterReception 配置参数。 PavelL_0-1789024403441.png 如果启用接收后自动释放，驱动程序会在 EthIf_RxIndication() 返回后释放 RX 资源，您不应该显式地释放它。 如果禁用自动释放，则在 EthIf_RxIndication() 返回后，接收缓冲区仍保持分配状态。在这种情况下，应用程序最终必须调用： Eth_43_GMAC_ReleaseRxBuffer(CtrlIdx, RxHandleId);   当应用程序需要保留接收到的数据以进行进一步处理时，此模式非常有用。但是，应用程序使用完毕后，必须释放缓冲区。否则，可用的接收缓冲区最终会耗尽。 另请注意，在相应的缓冲区释放后，不应再使用接收到的有效载荷指针。 3. Eth_43_GMAC 用户手册也是各个配置参数的主要参考资料。此外，S32 配置工具在选择或将鼠标悬停在相应设置上时，会显示许多参数的描述。有关硬件级行为，例如 MAC 过滤、DMA 操作、MTL 队列、时间戳和中断状态，请参阅 S32K3 参考手册的 GMAC/EMAC 章节。 作为实际的起点，我建议参考 RTD 软件包提供的 GMAC 示例。页面上还有一些功能性的 lwIP 示例： https://community.nxp.com/t5/S32K-Knowledge-Base/S32K-Examples/ta-p/1108990 如果您发现任何问题，请随时寻求帮助。建议每个主题单独开一个帖子。这有助于我们清晰地了解案例，以便其他用户使用。 顺祝商祺！ 帕维尔

iMX8M Plus CC Controller Hii, We are developing the custom som based on the iMX8M plus processors with custom carrier board. In this, We have a requirement for USB1 OTG supported with ID pin. We have taken ID pin from GPIO1_IO4. Due to board space constraint and ID Pin requirement we are planning to use HD3SS3220IRNH - TI (CC Controller with diff mux) in our design. Please confirm whether i.mx8m plus supports HD3SS3220IRNH as OTG. Specifically for Flashing purpose whether this controller is supported? Re: iMX8M Plus CC Controller Hi @govind18  The i.MX 8M Plus can be configured in system designs to work with the TI HD3SS3220 to implement a dual-role USB Type-C port; however, this device is not a Type-C controller that has been officially verified or supported by NXP‘s EVK. GPIO1_IO4 can be used as USB ID in Uboot/Linux and does not affect UUU programming. It is recommended that the HD3SS3220 be configured to UFP/Sink by default at power-on. Best Regards, Zhiming Re: iMX8M Plus CC Controller Hi @Zhiming_Liu  Could you please suggest any other tested CC controller that has ID pin Supported? Re: iMX8M Plus CC Controller Hi  On EVK board, the i.MX8MP is using  PTN5110NHQZ  as CC controller. Please refer the EVK design here. Zhiming_Liu_0-1789018946469.pngZhiming_Liu_0-1789018946469.png https://www.nxp.com/design/design-center/development-boards-and-designs/8MPLUSLPD4-EVK Best Regards, Zhiming Re: iMX8M Plus CC Controller Hi @Zhiming_Liu Could you please suggest CC controller?

LPC1778 IAP烧录CCLK越大反而烧录越慢 您好，我在使用LPC1778的IAP模式进行烧录时，发现CCLK越大反而烧录越慢。 IAP指令大多可以传入CCLK参数，手册中的描述是：Param3: CPU Clock Frequency (CCLK) in kHz。 我在调试LPC1778时，将驱动默认的CCLK值从12000（12MHz）改为4000（4Mhz），发现烧录速度反而变快了。我尝试了多个值，发现CCLK参数越大，烧录反而越慢，请问这是什么原因？这个CCLK指的是什么频率？ 回复： LPC1778 IAP烧录CCLK越大反而烧录越慢 Hi @BianHaopeng1  CCLK 在 LPC1778/LPC178x 文档中指 ARM processor clock frequency / Main CPU clock ，也就是内核 CPU 时钟，IAP 的擦除命令明确要求传入 CPU Clock Frequency (CCLK) in kHz 。 原因大概率不是“CCLK 越低 Flash 物理写入越快”，而是 IAP ROM 例程把你传入的 CCLK 当作当前 CPU 主频来计算 Flash 擦写时序/等待时间 。因此，如果实际 CPU 仍在较高频率运行，而你只把传给 IAP 的参数从 12000 改成 4000 ，IAP 会按 4 MHz 去生成更短的延时/时序，表现上烧录变快；但这属于给 IAP 传了错误时钟，Flash 擦写可靠性、温度/电压边界和长期保持不一定有保证。 正确做法是： CCLK 参数应填写调用 IAP 时真实的 CPU 主频，单位 kHz 。 BR Harry Re: LPC1778 IAP烧录CCLK越大反而烧录越慢 在 LPC1778 中，CCLK 指的是实际的 CPU 核心时钟频率（以 kHz 为单位），而不是晶振/XTAL 频率。IAP 引导加载程序使用 CCLK 参数来计算其内部时序，特别是对于闪存编程和 UART 通信。如果您提供的值与 MCU 的实际 CPU 时钟不匹配，或者时钟配置与 IAP 代码预期的不同，则时序计算可能会出错，导致编程或通信速度变慢。因此，请确保 CCLK 参数与 PLL/分频器配置后的 CPU 时钟完全匹配（例如，120 MHz 应指定为 120000 kHz，而不是 12000）。

RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Hi Team  , I downloaded SAFERTOS from SAFERTOS® Archives - High Integrity Systems I am following below S32 design studio and RTD version for SAFERTOS.(Version as they mentioned in document) ComponentVersion S32 Design Studio IDE v3.6.4 ARM GCC Compiler 11.4 S32K3 Real-Time Drivers (RTD) 6.0.0 I am facing some error, Vardhman_0-1788413006999.pngVardhman_0-1788413006999.png I tried with different S32 design studio( Version 3.5) and RTD version RTD (2.0.0. and 5.0.0) Is this .mex created with different version ?  Can you please provide what could be the solution. Thanks. Re: RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Hello @Vardhman , I am glad to hear that the SafeRTOS demo is now running on the board.   The standard Variables and Expressions views normally display values only when the target is halted. Since the project uses the PEmicro debugger, please open: Window → Show View → Other… → PE Microcomputer Systems → Real Time Expressions Add ulTickHookCallCount to this view and resume the application. This view is specifically intended for monitoring variables while the target is running. If required, declare the debug variable as volatile and use a debug build with low or disabled compiler optimization. Please also refer to the following NXP Community threads, which describe how to enable and use the Real Time Expressions view for monitoring variables while the target is running: How to watch variables live - NXP Community Solved: How do I enable Live View for variables when debugging? - NXP Community Best regrads, Pavel Re: RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Hello Team, Vardhman_0-1788508409179.pngVardhman_0-1788508409179.png S32 was removing this double quotes and modifying path when I copied to local directory. when I corrected path. Demo RTOS is running on board. Query - I am not able to see global variable live on S32 design studio.What setting I need to do ?? Everytime I suppose to halt the code then I can able to see variable values. Vardhman_1-1788508801698.pngVardhman_1-1788508801698.png      Re: RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Hello, Step 1 - I installed S32-3.6.4 version RTD 6.0.0. I was facing this issue now its resolved. I was installing wrong RTD package. Now its working. Vardhman_0-1788436426474.pngVardhman_0-1788436426474.png Step 2 - Now I have imported the Demo SAFERTOS project provided by highintegrity systems see below snip. Vardhman_1-1788436679719.pngVardhman_1-1788436679719.png Step 3 - I went in manage SDK there I found that PlatformSDK_S32K344_M7 giving error or its not supported, what could be the possibility? to resolve this  Vardhman_2-1788436993601.pngVardhman_2-1788436993601.png Step 4 - When I am creating new project not able to see SDK there still. How to resolve this ?  Step 5 - I have one query I installed 3.6.4 S32 design studio when I am installing this RTD package(6.0.0) I can see S32 design studio updated to 3.6.10. If this S32 design studio updating to 3.6.10 then this version will not supported by  highintegrity systems as they mentioned compatible version for DEMO SAFERTOS IS 3.6.4 - pls give openion on this.  Step 6 - S32 design studio updated to 3.6.10  Vardhman_4-1788437960107.pngVardhman_4-1788437960107.png Step 7 - I am getting this error after building code, Vardhman_3-1788437895528.pngVardhman_3-1788437895528.png I have attached RTD that i have installed. SW32K3_S32M27x_RTD_R21-11_6.0.0_D2506_DesignStudio_updatesite Thanks ,  Re: RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Hello @Vardhman , Please check that NXP GCC 10.2 is installed. Also, make sure that the GCC 10.2 toolchain is selected when creating the application project. A similar issue is described in the following Community thread, including screenshots. Although the thread refers to the S32K1xx RTD, the reported dependency-related symptoms are similar: S32DS 3.6.7: S32K1xx RTD 3.0.0 not detected when creating a new project Best regards, Pavel Re: RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Thanks this is working.

カメラセンサーOS02G10 MIPI CSI for IMX8MM こんにちは、みんな。 OS02g10のドライバーは以下から入手しました: https://github.com/Shaggy013/kernel-5.10 ドライバーをパッチとして追加しました。 私のデバイスツリーは次のようになっています。 csi1_bridge: csi1_bridge@32e20000 { compatible = "fsl,imx8mm-csi", "fsl,imx8mq-csi", "fsl,imx6s-csi"; reg = <0x32e20000 0x1000>; interrupts = ; clocks = <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_CSI1_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "disp-axi", "csi_mclk", "disp_dcic"; power-domains = <&dispmix_pd>; status = "disabled"; }; mipi_csi_1: mipi_csi@32e30000 { compatible = "fsl,imx8mm-mipi-csi"; reg = <0x32e30000 0x1000>; interrupts = ; clock-frequency = <360000000>; clocks = <&clk IMX8MM_CLK_CSI1_CORE>, <&clk IMX8MM_CLK_CSI1_PHY_REF>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "mipi_clk", "phy_clk", "disp_axi", "disp_apb"; bus-width = <2>; resets = <&mipi_csi_resets>; power-domains = <&mipi_pd>; status = "disabled"; }; os02g10: os02g10@3c { compatible = "ovti,os02g10"; reg = <0x3c>; // spec (manual) says that I2c addres is 0x3d status = "okay"; pinctrl-names = "rockchip,camera_default", "rockchip,camera_sleep"; pinctrl-0 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; pinctrl-1 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; csi_id = <0>; pwdn-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; mux-gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; mclk = <24000000>; mclk_source = <0>; rockchip,camera-module-index = <1>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "OS02G10 camera"; rockchip,camera-module-lens-name = "1//2.9 inch 15*"; rockchip,camera-hdr-mode = <0>; // kernel-5.10\include\uapi\linux\rk-camera-module.h:307 (enum rkmodule_hdr_mode) mipi_csi; port { os02g10_ep: endpoint { remote-endpoint = <&mipi1_sensor_ep>; }; }; }; }; &csi1_bridge { fsl,mipi-mode; status = "okay"; port { csi1_ep: endpoint { remote-endpoint = <&csi1_mipi_ep>; }; }; }; &mipi_csi_1 { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; mipi1_sensor_ep: endpoint@1 { reg = <1>; remote-endpoint = <&os02g10_ep>; data-lanes = <2>; csis-hs-settle = <13>; csis-clk-settle = <2>; csis-wclk; }; csi1_mipi_ep: endpoint@2 { reg = <2>; remote-endpoint = <&csi1_ep>; }; }; }; &clk { init-on-array = ; }; カメラドライバーとmxc_mipi-csi.c用にプローブ機能を修正しました。mx6s-csi.c 以前はフォーマット一致エラーが2回発生しましたが、mx6s-csiに追加しました { .name = "RAWRGB10 (SBGGR10)", .fourcc = V4L2_PIX_FMT_SBGGR10, .pixelformat = V4L2_PIX_FMT_SBGGR10, .mbus_code = MEDIA_BUS_FMT_SBGGR10_1X10, .bpp = 1, } そしてmxc_mipi-csi.cに追加されました { .code = MEDIA_BUS_FMT_SBGGR10_1X10, .fmt_reg = MIPI_CSIS_ISPCFG_FMT_RAW10, .data_alignment = 8, } v4l2 APIは正常に動作し、エラーは発生しません。以下は画像を取得するためのコマンドです v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw そして、デバッグメッセージの結果 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_power os02g10 3-003c: in function: os02g10_s_power os02g10 3-003c: in function: os02g10_runtime_resume os02g10 3-003c: in function: __os02g10_power_on os02g10 3-003c: OS02G10_REG_SOFTWARE_RESET mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clk_enable mxc_mipi-csi 32e30000.mipi_csi: enable mipi_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable phy_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_axi returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_apb returns: 0 VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_fmt VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 1920 Size Image : 2073600 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags: mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clear_counters mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_start_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_sw_reset: REG CMN_CTRL 0x32E30004 = 0x00004000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format mxc_mipi-csi.0: fmt: 0x3007, 1920 x 1080 mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format: REG ISPRESOL_CH0 0x32E30044 = 0x04380780 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_hsync_settle: REG DPHYCTRL 0x32E30024=0x0d800000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params: REG CMN_CTRL 0x32E30004 = 0x00004104 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG CMN_CTRL 0x32E30004=0x00004105 VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG DPHYCTRL 0x32E30024=0x0d800007 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enable_interrupts: REG CSIS_INTMSK 0x32E30010 = 0xf00fffff mxc_mipi-csi.0: --- mipi_csis_start_stream --- mxc_mipi-csi.0: 0x04 CMM CTRL : 0x00004105 mxc_mipi-csi.0: 0x08 CLK CTRL : 0x000f0000 mxc_mipi-csi.0: 0x10 INT MASK0: 0xf00fffff mxc_mipi-csi.0: 0x14 INT SRC0 : 0x00000000 mxc_mipi-csi.0: 0x18 INT MASK1: 0x00000000 mxc_mipi-csi.0: 0x1c INT SRC1 : 0x00000000 mxc_mipi-csi.0: 0x20 PHY STAT : 0x000000f1 mxc_mipi-csi.0: 0x24 PHY CTRL : 0x0d800007 mxc_mipi-csi.0: 0x30 PHY M/S-L: 0x000001f4 mxc_mipi-csi.0: 0x34 PHY M/S-H: 0x00000000 mxc_mipi-csi.0: 0x38 PHY S-CTL: 0x00000000 mxc_mipi-csi.0: 0x3C PHY S-CTH: 0x00000000 mxc_mipi-csi.0: 0x40 ISP CONF : 0x000000ac mxc_mipi-csi.0: 0x44 ISP RESOL: 0x04380780 mxc_mipi-csi.0: 0x48 ISP SYNC : 0x04380780 os02g10 3-003c: in function: os02g10_s_stream os02g10 3-003c: in function: __os02g10_start_stream os02g10 3-003c: in function: __os02g10_start_stream __v4l2_ctrl_handler_setup returns: 0 os02g10 3-003c: in function: os02g10_s_stream: unlock_and_return VIDIOC_STREAMON returned 0 (Success) その後は何も起こらず、ただ待って待つだけで何も起こらない。 20MHzオシロスコープではMIPI DATAおよびMIPI CLKラインのトラフィックを観測できません。（帯域幅が低いのは承知していますが、データ回線であれば何らかの変化が見られるはずです。しかし、全く反応がありません。） clkノードが正しいかどうか確信が持てません。クロック名によるmipi_csiクロックと一致する&clkノードがない可能性もあります。どなたか使用経験のある方はいらっしゃいますか？ どうすればいいでしょうか? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Camera sensor os02g10 MIPI CSI for IMX8MM こんにちは、Linuxのアップストリームドライバーを使えます。 私たちはこれをi.mx8MPベースのDebixプラットフォームでテストしました。 こちらがドライバです https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad こちらが当社のDTです https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- ルトヴィイ シリコンシグナルズ Re: Camera sensor os02g10 MIPI CSI for IMX8MM うまくいきました。 .bpp2でなければならない しかし主な問題はハードウェアにあった

S32K388 GMAC0 Eth_43_GMACドライバーがRX割り込みを受け取らない こんにちは、 私は以下の設定を使用しています。 S32K388EVB-Q289 S32DS 3.6.8 RTD 7.0.1 提供されたEth_InternalLoopback_S32K388例プロジェクトをベースにし、PCからメディアコンバーター経由でフレームを受け取れるように改良しました。例 S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600で言及されていた RTD 修正を追加しました。ブレークポイントを達成できました Eth_43_GMAC_Receive(EthConf_EthCtrlConfig_EthCtrlConfig_0、0U、&Status); そして、イーサネットフレームを点検できました EthIf_RxIndication(Eth_43_GMAC_apxInternalCfg[PartitionId]->Eth_43_GMAC_apCtrlConfig[CtrlIdx]->EthCtrlEthIfIdx, FrameType, IsBroadcast, MacSrcAddr, Payload, PayloadLength, IngressTimeTuplePtr, RxHandleId); しかし、while 1 ループを追加し、Rx 割り込みを有効にして GMAC0_CH0_RX_IRQHandler にリンクしても、どこにも割り込みが発生しませんでした。プロジェクトを以下に添付しました。 James_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.png S32K3 オートモーティブ-RTD  Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt こんにちは、 @James_Zhang_SE さん、 添付のプロジェクトを確認しました。RTD7.0.1でRX IRQを有効にするには、Ingress QueueHandlerFunctionを変更してQueueInterruptを有効にする必要があります。 PavelL_0-1788263577590.pngPavelL_0-1788263577590.pngPavelL_0-1788263577590.png その変更後、GMAC_RxIRQHandler() でブレークポイントに到達しました。Eth_43_GMAC_Receive() にて。 また、RGMII TXCLKが入力として定義されていますが、出力として定義されるべきです。 ただし、WiresharkでTXフレームを見るには、イニットシーケンスを適切に変更する必要があります。 例S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600 。あなたのプロジェクトでは、次のように見え ます: PavelL_1-1788264277735.pngPavelL_1-1788264277735.pngPavelL_1-1788264277735.png よろしくお願いいたします。 パベル Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt こんにちは、パベルさん。 サポートありがとうございます。ご提案の修正を適用した後、GMACドライバーが動作するようになりました。 いくつか追加の質問がありますので、ご教示いただければ幸いです。 GMACドライバーの設定や使用手順を完全に説明した詳細なドキュメントはありますか?まずは自分でドキュメントを確認して、ドライバのことをもっと理解したいと思っています。 EthIf_RxIndication()の中で、呼び出す必要がありますか？ Eth_43_GMAC_ReleaseRxBuffer(CtrlIdx, RxHandleId); 関数の最後に受信バッファを解放する処理はありますか？ GMACの設定オプションは数多く用意されています。各設定パラメータが何をするのか、どのように設定すべきかを説明するドキュメントや参考文献はありますか? ご協力ありがとうございました。皆さんのサポートに本当に感謝しています。 Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt こんにちは、 @James_Zhang_SE さん。 最新情報のご共有ありがとうございます。GMACドライバーが今あなたのために使えるようになったと聞いて安心しました。 追加のご質問について： 1.ドライバーの設定および使用に関する主な参照は、RTDインストールに含まれているEth_43_GMACユーザーマニュアルです。例:C:\NXP\S32DS.3.6.6_RTD701\S32DS\software\PlatformSDK_S32K3\RTD\Eth_43_GMAC_TS_T40D34M70I1R0\doc\RTD_ETH_43_GMAC_UM.pdf 同じディレクトリに保存されている対応するEth_43_GMAC統合マニュアル（RTD_ETH_43_GMAC_IM.pdf）と、利用可能なGMACサンプルプロジェクトも確認することをお勧めします。   2. Eth_43_GMAC_ReleaseRxBuffer() を呼び出す必要があるかどうかは、EthCtrlReleaseResourceAfterReception 設定パラメータによって決まります。 PavelL_0-1789024403441.png 受信後の自動リリースが有効の場合、ドライバーはEthIf_RxIndication()が戻った後にRXリソースを解放するため、明示的にリリースすべきではありません。 自動解放が無効になっている場合、EthIf_RxIndication() が戻った後も、受信バッファは割り当てられたままになります。その場合、アプリケーションは最終的に以下を呼び出さなければなりません。 Eth_43_GMAC_ReleaseRxBuffer(CtrlIdx, RxHandleId);   このモードは、アプリケーションが受信データを保持してさらなるプロセッシングを行う必要がある場合に有用です。ただし、バッファはアプリケーションが使用を終えた後に解放されなければなりません。そうしないと、利用可能な受信バッファが最終的に枯渇してしまう。 また、受信したペイロードポインタは、対応するバッファが解放された後は使用しないでください。 3. Eth_43_GMACユーザーマニュアルは個々の構成パラメータの主要な参照資料でもあります。さらに、S32設定ツールでは、対応する設定を選択またはマウスオーバーすると、多くのパラメーターの説明が表示されます。MACフィルタリング、DMA操作、MTLキュー、タイムスタンプ、割り込み状態などのハードウェアレベルの動作については、S32K3リファレンスマニュアルのGMAC/EMAC章を参照してください。 実用的な出発点として、RTDパッケージで提供されているGMACの例を参照することをお勧めします。このページには、lwIPの機能的なサンプルも掲載されています。 https://community.nxp.com/t5/S32K-Knowledge-Base/S32K-Examples/ta-p/1108990 何か問題を感じたら、遠慮なくサポートをお願いしてください。各トピックごとに専用スレッドを設けることが望ましいです。これにより、他のユーザーにとってケースの明確さを保つことができます。 よろしくお願いいたします。 パベル

IMX95 datasheet Hello, How can I get imx95 datasheet with register maps, peripherals, etc.? Regards, Artur Re: IMX95 datasheet Thank you and have a nice day Regards, Artur Re: IMX95 datasheet The datasheet alone does not contain the full register maps and peripheral descriptions. For that, you need the https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf. Thanks

IMX95 数据手册 你好， 如何获取包含寄存器映射、外设等信息的imx95数据手册？ 问候， 阿图尔 Re: IMX95 datasheet 谢谢，祝您愉快！ 问候， 阿图尔 Re: IMX95 datasheet 单凭数据手册无法包含完整的寄存器映射和外设描述。 为此，您需要https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf 。 谢谢！

LPC1778 IAPプログラミングにおいて、CCLKの値が大きいほどプログラミング速度は遅くなります。 こんにちは。LPC1778のIAPモードを使用してプログラムを書き込んでいたところ、CCLKの値が大きいほど書き込み処理が遅くなることがわかりました。 ほとんどの IAP 命令は CCLK パラメータを受け入れることができます。これはマニュアルでは次のように説明されています: Param3: CPU クロック周波数 (CCLK) (kHz)。 LPC1778のデバッグ中に、ドライバのデフォルトのCCLK値を12000（12MHz）から4000（4MHz）に変更したところ、書き込み速度が実際に向上しました。いくつかの値を試したところ、CCLKパラメータが大きいほど書き込み処理が遅くなることがわかりました。これはなぜでしょうか？CCLKはどの周波数を指しているのでしょうか？ 回复： LPC1778 IAP烧录CCLK越大反而烧录越慢 こんにちは@BianHaopeng1 LPC1778/LPC178xのドキュメントでは、CCLKはARMプロセッサのクロック周波数、つまりメインCPUクロック（コアCPUクロック）を指します。IAP消去コマンドでは、CPUクロック周波数（CCLK）をkHz単位で指定する必要があります。 その理由は、「CCLKが低いほど物理的なフラッシュ書き込みが速くなる」ということではなく、IAP ROMルーチンが渡されたCCLKを現在のCPU周波数として扱い、フラッシュ消去/書き込みのタイミング/待機時間を計算しているためである可能性が高い。したがって、実際のCPUがより高い周波数で動作している状態で、IAPに渡されるパラメータを12000から4000に変更した場合、IAPは4MHzに基づいてより短いレイテンシ/タイミングを生成し、書き込みが速くなる。しかし、これはIAPに誤ったクロックが渡されることを意味し、フラッシュ消去/書き込みの信頼性、温度/電圧の許容範囲、および長期安定性が保証されない。 正しい方法は、IAP呼び出し時の実際のCPUクロック速度をkHz単位でCCLKパラメータに入力することです。 BR ハリー Re: LPC1778 IAP烧录CCLK越大反而烧录越慢 LPC1778では、CCLKは水晶発振器の周波数ではなく、実際のCPUコアクロック周波数（kHz単位）を意味します。IAPブートローダーは、特にフラッシュメモリのプログラミングやUART通信において、内部タイミングを計算するためにCCLKパラメータを使用します。提供した値がMCUの実際のCPUクロックと一致しなかったり、クロックがIAPコードの期待値と異なる設定をしていると、タイミング計算が誤り、プログラミングや通信が遅くなることがあります。したがって、PLL/分周器の設定後、CCLKパラメータがCPUクロックと完全に一致するようにしてください（例えば、120MHzは120000kHzと指定する必要があり、12000とは指定しません）。

MFRC630とCLRC663は互換性がありますか？ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 現在、当社の製品は2台のCLRC663を使用しています。これらは50オームのインピーダンスにマッチングされているため、CLRC663の「高電流」機能を活用しません。未来では制作コストを節約し、1 CLRC663(14443と15693をサポートする必要があるため必要)と1 MFRC630(2つ目のリーダーはmifareのみで済みます)だけを使いたいと考えています。 両方の製品で自社ライブラリをテストすることに成功しましたが、「変更可能な」UIDチップタイプでも動作しているようです 良い。つまり、ソフトウェアの問題ではないということです。私の推測では、MFRC630はCLRC630とは別のファームウェアで、サポートしていないのだと思いますISO15693 フットプリントとピン配置は同じです 唯一気になるのは、マッチングについてです。 ミフェアでマッチングされたCLRC663を、マッチングネットワークを変えずにドロップインMFRC630に置き換えることは可能でしょうか? NFCコントローラーソリューション NFCフロントエンド・ソリューション Re: MFRC630 and CLRC663 Interchangeability? すでに答えは見つかっていると思いますが、これを見つけた方のために、アプリケーションノート(https://www.nxp.com/docs/en/application-note/AN11256.pdf)に「変更は不要」と書かれています。 私もMFRC630を使用するプロジェクトに取り組んでいますが、開発段階ではCLRC663を使用しています。CLRC663用の基板が存在するからです。プロジェクトが終わったら、移行が申請書の通りスムーズに進んだかどうかを確認する投稿を追加します。 Re: MFRC630 and CLRC663 Interchangeability? こんにちは、 @jof さん、 はい、これらのICは「チューニング」に対応しています。シリコンは同じですが、MFRC660 MIFAREテクノロジ(ISO 14443、タイプA)のみをサポートし、CLRC663はタイプA、タイプB、その他すべてのテクノロジをサポートしていますISO15693... BR トマス

MFRC630 and CLRC663 Interchangeability? Currently our product uses two pcs of CLRC663. They are matched to 50Ohms impedance, so they will not make use of the "high current" capability of the CLRC663. For the furture, we want to save on production costs and use just one CLRC663 (needed because it must support 14443 and 15693) and one MFRC630 (second reader only needs mifare). I succesfully tested our own library on both products and they seem to work, even with "changeable" uid chip types very well. So it wouldn't be a software thing. My guess is that the MFRC630 is just a different firmware than CLRC630, to not support ISO15693 Footprint and pinout are the same The only thing i wonder is about the matching. Could the CLRC663 which is matched for mifare, replaced by a drop-in MFRC630 without changing the matching network? NFC Controller Solutions NFC Frontend Solutions Re: MFRC630 and CLRC663 Interchangeability? I assume you've already found the answer, but for anyone who might find this, there is an application note ( https://www.nxp.com/docs/en/application-note/AN11256.pdf) which says that no changes need to be made. I am also working on a project which will use the MFRC630, but for development, I'm using CLRC663 because there is a board for it. I shall add a post here after finishing the project, confirming whether the migration went as smoothly as the application note says. Re: MFRC630 and CLRC663 Interchangeability? Hello @jof ,  Yes, the ICs are "tuning" compatible. The silicon is the same but MFRC660 supports only MIFARE technology (ISO 14443, Type A) while the CLRC663 supports all technologies as Type A, Type B, ISO15693...  BR Tomas 

适用于 IMX8MM 的 OS02G10 MIPI CSI 摄像头传感器 大家好。 我从以下位置获取了 os02g10 的驱动程序： https://github.com/Shaggy013/kernel-5.10 我以补丁的形式添加了驱动程序。 我的设备树如下所示： csi1_bridge: csi1_bridge@32e20000 { compatible = "fsl,imx8mm-csi", "fsl,imx8mq-csi", "fsl,imx6s-csi"; reg = <0x32e20000 0x1000>; interrupts = ; clocks = <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_CSI1_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "disp-axi", "csi_mclk", "disp_dcic"; power-domains = <&dispmix_pd>; status = "disabled"; }; mipi_csi_1: mipi_csi@32e30000 { compatible = "fsl,imx8mm-mipi-csi"; reg = <0x32e30000 0x1000>; interrupts = ; clock-frequency = <360000000>; clocks = <&clk IMX8MM_CLK_CSI1_CORE>, <&clk IMX8MM_CLK_CSI1_PHY_REF>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "mipi_clk", "phy_clk", "disp_axi", "disp_apb"; bus-width = <2>; resets = <&mipi_csi_resets>; power-domains = <&mipi_pd>; status = "disabled"; }; os02g10: os02g10@3c { compatible = "ovti,os02g10"; reg = <0x3c>; // spec (manual) says that I2c addres is 0x3d status = "okay"; pinctrl-names = "rockchip,camera_default", "rockchip,camera_sleep"; pinctrl-0 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; pinctrl-1 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; csi_id = <0>; pwdn-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; mux-gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; mclk = <24000000>; mclk_source = <0>; rockchip,camera-module-index = <1>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "OS02G10 camera"; rockchip,camera-module-lens-name = "1//2.9 inch 15*"; rockchip,camera-hdr-mode = <0>; // kernel-5.10\include\uapi\linux\rk-camera-module.h:307 (enum rkmodule_hdr_mode) mipi_csi; port { os02g10_ep: endpoint { remote-endpoint = <&mipi1_sensor_ep>; }; }; }; }; &csi1_bridge { fsl,mipi-mode; status = "okay"; port { csi1_ep: endpoint { remote-endpoint = <&csi1_mipi_ep>; }; }; }; &mipi_csi_1 { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; mipi1_sensor_ep: endpoint@1 { reg = <1>; remote-endpoint = <&os02g10_ep>; data-lanes = <2>; csis-hs-settle = <13>; csis-clk-settle = <2>; csis-wclk; }; csi1_mipi_ep: endpoint@2 { reg = <2>; remote-endpoint = <&csi1_ep>; }; }; }; &clk { init-on-array = ; }; 我修改了相机驱动程序和 mxc_mipi-csi.c 的探测函数，mx6s-csi.c 之前我遇到过两次格式匹配错误，但我添加了 mx6s-csi { .name = "RAWRGB10 (SBGGR10)", .fourcc = V4L2_PIX_FMT_SBGGR10, .pixelformat = V4L2_PIX_FMT_SBGGR10, .mbus_code = MEDIA_BUS_FMT_SBGGR10_1X10, .bpp = 1, } 并添加到 mxc_mipi-csi.c { .code = MEDIA_BUS_FMT_SBGGR10_1X10, .fmt_reg = MIPI_CSIS_ISPCFG_FMT_RAW10, .data_alignment = 8, } v4l2 API 工作正常，没有错误。以下是我获取图片的命令 v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw 结果以及我的调试信息 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_power os02g10 3-003c: in function: os02g10_s_power os02g10 3-003c: in function: os02g10_runtime_resume os02g10 3-003c: in function: __os02g10_power_on os02g10 3-003c: OS02G10_REG_SOFTWARE_RESET mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clk_enable mxc_mipi-csi 32e30000.mipi_csi: enable mipi_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable phy_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_axi returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_apb returns: 0 VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_fmt VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 1920 Size Image : 2073600 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags: mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clear_counters mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_start_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_sw_reset: REG CMN_CTRL 0x32E30004 = 0x00004000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format mxc_mipi-csi.0: fmt: 0x3007, 1920 x 1080 mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format: REG ISPRESOL_CH0 0x32E30044 = 0x04380780 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_hsync_settle: REG DPHYCTRL 0x32E30024=0x0d800000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params: REG CMN_CTRL 0x32E30004 = 0x00004104 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG CMN_CTRL 0x32E30004=0x00004105 VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG DPHYCTRL 0x32E30024=0x0d800007 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enable_interrupts: REG CSIS_INTMSK 0x32E30010 = 0xf00fffff mxc_mipi-csi.0: --- mipi_csis_start_stream --- mxc_mipi-csi.0: 0x04 CMM CTRL : 0x00004105 mxc_mipi-csi.0: 0x08 CLK CTRL : 0x000f0000 mxc_mipi-csi.0: 0x10 INT MASK0: 0xf00fffff mxc_mipi-csi.0: 0x14 INT SRC0 : 0x00000000 mxc_mipi-csi.0: 0x18 INT MASK1: 0x00000000 mxc_mipi-csi.0: 0x1c INT SRC1 : 0x00000000 mxc_mipi-csi.0: 0x20 PHY STAT : 0x000000f1 mxc_mipi-csi.0: 0x24 PHY CTRL : 0x0d800007 mxc_mipi-csi.0: 0x30 PHY M/S-L: 0x000001f4 mxc_mipi-csi.0: 0x34 PHY M/S-H: 0x00000000 mxc_mipi-csi.0: 0x38 PHY S-CTL: 0x00000000 mxc_mipi-csi.0: 0x3C PHY S-CTH: 0x00000000 mxc_mipi-csi.0: 0x40 ISP CONF : 0x000000ac mxc_mipi-csi.0: 0x44 ISP RESOL: 0x04380780 mxc_mipi-csi.0: 0x48 ISP SYNC : 0x04380780 os02g10 3-003c: in function: os02g10_s_stream os02g10 3-003c: in function: __os02g10_start_stream os02g10 3-003c: in function: __os02g10_start_stream __v4l2_ctrl_handler_setup returns: 0 os02g10 3-003c: in function: os02g10_s_stream: unlock_and_return VIDIOC_STREAMON returned 0 (Success) 之后什么都不会发生，只有等待、等待，什么也不会发生。 我用20MHz示波器观察不到MIPI DATA和MIPI CLK线上的任何信号。（我知道带宽很低，但对于数据线路来说，任何变化都应该能被察觉，然而却一片寂静。） 我不确定clk节点是否正确，也许没有与mipi_csi时钟名称匹配的&clk节点。有人用过吗？ 我能做些什么 ？ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Camera sensor os02g10 MIPI CSI for IMX8MM 您好，您可以使用我们已向上游提交的 Linux 驱动程序。 我们已在基于 i.mx8mp 的 debix 平台上进行了测试。 这是我们的司机。 https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad 这是我们的DT https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- 鲁特维 SiliconSignals Re: Camera sensor os02g10 MIPI CSI for IMX8MM 我成功了。 .bpp必须等于 2 但主要问题出在硬件上。

Camera sensor os02g10 MIPI CSI for IMX8MM Hi all. I got the driver for os02g10 from: https://github.com/Shaggy013/kernel-5.10 I added driver as a patch. My DeviceTree looks that: csi1_bridge: csi1_bridge@32e20000 { compatible = "fsl,imx8mm-csi", "fsl,imx8mq-csi", "fsl,imx6s-csi"; reg = <0x32e20000 0x1000>; interrupts = ; clocks = <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_CSI1_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "disp-axi", "csi_mclk", "disp_dcic"; power-domains = <&dispmix_pd>; status = "disabled"; }; mipi_csi_1: mipi_csi@32e30000 { compatible = "fsl,imx8mm-mipi-csi"; reg = <0x32e30000 0x1000>; interrupts = ; clock-frequency = <360000000>; clocks = <&clk IMX8MM_CLK_CSI1_CORE>, <&clk IMX8MM_CLK_CSI1_PHY_REF>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "mipi_clk", "phy_clk", "disp_axi", "disp_apb"; bus-width = <2>; resets = <&mipi_csi_resets>; power-domains = <&mipi_pd>; status = "disabled"; }; os02g10: os02g10@3c { compatible = "ovti,os02g10"; reg = <0x3c>; // spec (manual) says that I2c addres is 0x3d status = "okay"; pinctrl-names = "rockchip,camera_default", "rockchip,camera_sleep"; pinctrl-0 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; pinctrl-1 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; csi_id = <0>; pwdn-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; mux-gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; mclk = <24000000>; mclk_source = <0>; rockchip,camera-module-index = <1>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "OS02G10 camera"; rockchip,camera-module-lens-name = "1//2.9 inch 15*"; rockchip,camera-hdr-mode = <0>; // kernel-5.10\include\uapi\linux\rk-camera-module.h:307 (enum rkmodule_hdr_mode) mipi_csi; port { os02g10_ep: endpoint { remote-endpoint = <&mipi1_sensor_ep>; }; }; }; }; &csi1_bridge { fsl,mipi-mode; status = "okay"; port { csi1_ep: endpoint { remote-endpoint = <&csi1_mipi_ep>; }; }; }; &mipi_csi_1 { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; mipi1_sensor_ep: endpoint@1 { reg = <1>; remote-endpoint = <&os02g10_ep>; data-lanes = <2>; csis-hs-settle = <13>; csis-clk-settle = <2>; csis-wclk; }; csi1_mipi_ep: endpoint@2 { reg = <2>; remote-endpoint = <&csi1_ep>; }; }; }; &clk { init-on-array = ; }; I modified probe function for camera driver and for mxc_mipi-csi.c, mx6s-csi.c Before I had 2 times format match error but I added to the mx6s-csi { .name = "RAWRGB10 (SBGGR10)", .fourcc = V4L2_PIX_FMT_SBGGR10, .pixelformat = V4L2_PIX_FMT_SBGGR10, .mbus_code = MEDIA_BUS_FMT_SBGGR10_1X10, .bpp = 1, } and added to mxc_mipi-csi.c { .code = MEDIA_BUS_FMT_SBGGR10_1X10, .fmt_reg = MIPI_CSIS_ISPCFG_FMT_RAW10, .data_alignment = 8, } and v4l2 API works, there is no error. Below my command to get picture v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw and the result with my debug messages mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_power os02g10 3-003c: in function: os02g10_s_power os02g10 3-003c: in function: os02g10_runtime_resume os02g10 3-003c: in function: __os02g10_power_on os02g10 3-003c: OS02G10_REG_SOFTWARE_RESET mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clk_enable mxc_mipi-csi 32e30000.mipi_csi: enable mipi_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable phy_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_axi returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_apb returns: 0 VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_fmt VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 1920 Size Image : 2073600 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags: mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clear_counters mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_start_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_sw_reset: REG CMN_CTRL 0x32E30004 = 0x00004000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format mxc_mipi-csi.0: fmt: 0x3007, 1920 x 1080 mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format: REG ISPRESOL_CH0 0x32E30044 = 0x04380780 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_hsync_settle: REG DPHYCTRL 0x32E30024=0x0d800000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params: REG CMN_CTRL 0x32E30004 = 0x00004104 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG CMN_CTRL 0x32E30004=0x00004105 VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG DPHYCTRL 0x32E30024=0x0d800007 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enable_interrupts: REG CSIS_INTMSK 0x32E30010 = 0xf00fffff mxc_mipi-csi.0: --- mipi_csis_start_stream --- mxc_mipi-csi.0: 0x04 CMM CTRL : 0x00004105 mxc_mipi-csi.0: 0x08 CLK CTRL : 0x000f0000 mxc_mipi-csi.0: 0x10 INT MASK0: 0xf00fffff mxc_mipi-csi.0: 0x14 INT SRC0 : 0x00000000 mxc_mipi-csi.0: 0x18 INT MASK1: 0x00000000 mxc_mipi-csi.0: 0x1c INT SRC1 : 0x00000000 mxc_mipi-csi.0: 0x20 PHY STAT : 0x000000f1 mxc_mipi-csi.0: 0x24 PHY CTRL : 0x0d800007 mxc_mipi-csi.0: 0x30 PHY M/S-L: 0x000001f4 mxc_mipi-csi.0: 0x34 PHY M/S-H: 0x00000000 mxc_mipi-csi.0: 0x38 PHY S-CTL: 0x00000000 mxc_mipi-csi.0: 0x3C PHY S-CTH: 0x00000000 mxc_mipi-csi.0: 0x40 ISP CONF : 0x000000ac mxc_mipi-csi.0: 0x44 ISP RESOL: 0x04380780 mxc_mipi-csi.0: 0x48 ISP SYNC : 0x04380780 os02g10 3-003c: in function: os02g10_s_stream os02g10 3-003c: in function: __os02g10_start_stream os02g10 3-003c: in function: __os02g10_start_stream __v4l2_ctrl_handler_setup returns: 0 os02g10 3-003c: in function: os02g10_s_stream: unlock_and_return VIDIOC_STREAMON returned 0 (Success) After that nothing is going to happen, just waiting and waiting and nothing. I can not observe any traffic on MIPI DATA and MIPI CLK lines by 20MHz oscilloscope. (I know the bandwidth is low but for data lines there should be anything seen - any change but there is completely silence)  Im not sure if clk node is correct and maybe there is no match &clk node with mipi_csi clocks by clock names. Has anyone experience with it? What can I do ? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Camera sensor os02g10 MIPI CSI for IMX8MM Hi, you can use our linux upstreamed driver,  we have tested this on i.mx8mp based debix platform.  Here is our driver  https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad Here is our DT https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- Rutvij  SiliconSignals Re: Camera sensor os02g10 MIPI CSI for IMX8MM I got it to work. .bpp has to be = 2 but main issue was with hardware

MFRC630 和 CLRC663 可以互换吗？ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 目前我们的产品使用了两颗 CLRC663。它们的阻抗匹配度为 50 欧姆，因此无法利用 CLRC663 的“大电流”能力。展望未来，我们希望节省生产成本，只使用一个 CLRC663（因为它必须支持 14443 和 15693）和一个 MFRC630（第二个读卡器只需要 mifare）。 我已成功在两款产品上测试了我们自己的库，它们似乎都能正常工作，即使是“可变”的uid芯片类型也是如此。 出色地。所以这应该不是软件问题。我猜测MFRC630只是固件版本与CLRC630不同，所以才不支持ISO15693。 封装尺寸和引脚排列相同 我唯一想知道的就是匹配方面的问题。 与 mifare 匹配的 CLRC663 能否在不改变匹配网络的情况下，被即插即用的 MFRC630 取代？ NFC 控制器解决方案 NFC 前端解决方案 Re: MFRC630 and CLRC663 Interchangeability? 我假设你已经找到了答案，但为了方便可能看到这条信息的人，这里有一份应用笔记（ https://www.nxp.com/docs/en/application-note/AN11256.pdf ），其中指出无需进行任何更改。 我目前也在做一个使用 MFRC630 的项目，但为了开发，我使用的是 CLRC663，因为有相应的开发板。项目完成后，我将在此处发布一篇帖子，确认迁移是否像应用笔记中所说的那样顺利。 Re: MFRC630 and CLRC663 Interchangeability? 你好@jof ， 是的，这些集成电路是“调谐”兼容的。虽然芯片相同，但MFRC660仅支持MIFARE技术（ISO 14443，A型），而CLRC663支持所有技术，包括A型、B型、ISO15693等。 BR 托马斯

The larger the CCLK for LPC1778 IAP programming, the slower the programming speed. Hello, when I was using the IAP mode of the LPC1778 to burn the program, I found that the larger the CCLK, the slower the burning process became. Most IAP instructions can accept the CCLK parameter, which is described in the manual as: Param3: CPU Clock Frequency (CCLK) in kHz. When debugging the LPC1778, I changed the default CCLK value of the driver from 12000 (12MHz) to 4000 (4MHz), and found that the burning speed actually increased. I tried several values and found that the larger the CCLK parameter, the slower the burning process. What could be the reason for this? What frequency does CCLK refer to? 回复： LPC1778 IAP烧录CCLK越大反而烧录越慢 Hi @BianHaopeng1 In the LPC1778/LPC178x documentation, CCLK refers to the ARM processor clock frequency / Main CPU clock, which is the core CPU clock. The IAP erase command explicitly requires the CPU Clock Frequency (CCLK) to be passed in kHz. The reason is most likely not that "a lower CCLK results in faster physical Flash writes," but rather that the IAP ROM routine treats the CCLK you pass in as the current CPU frequency to calculate the Flash erase/write timings/wait times. Therefore, if the actual CPU is still running at a higher frequency, and you only change the parameter passed to IAP from 12000 to 4000, IAP will generate a shorter latency/timing based on 4 MHz, resulting in faster burning; however, this means that an incorrect clock is being passed to IAP, and the reliability of Flash erase/write, temperature/voltage boundaries, and long-term stability are not guaranteed. The correct approach is to fill in the actual CPU clock speed at the time of the IAP call, in kHz, for the CCLK parameter. BR Harry Re: LPC1778 IAP烧录CCLK越大反而烧录越慢 On the LPC1778, CCLK means the actual CPU core clock frequency (in kHz), not the crystal/XTAL frequency. The IAP bootloader uses the CCLK parameter to calculate its internal timing, particularly for flash programming and UART communication. If the value you provide does not match the MCU’s real CPU clock—or if the clock is configured differently from what the IAP code expects—the timing calculations can become incorrect, causing slower programming or communication. Therefore, make sure the CCLK parameter exactly matches the CPU clock after PLL/divider configuration (e.g., 120 MHz should be specified as 120000 kHz, not 12000).

[SPSDK][i.MX95] nxpele 读取公共熔丝失败 您好， 我正在研究如何在 IMX95 19x19 EVK 板上启用安全启动。我已经使用 SPSDK 成功对我的镜像进行了签名。现在，在写入熔丝之前，我想使用 `nxpele` 读取它们，但我遇到了以下错误。 ``` $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-熔丝 --index 136 SPSDK解析错误：SPSDK：响应中的消息大小无效：0x4 请查看调试日志文件：/home/user/.local/state/spsdk/3.11.0/log/debug.log 获取更多信息 ``` 日志中显示以下内容： ``` $ tail -60 /home/user/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"响应中的消息 SIZE 无效：{hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: 响应中的消息大小无效: 0x4 调试：spsdk：***************************************************（自启动以来已耗时 206 毫秒，spsdk_logger.py:212） DEBUG:spsdk:* SPSDK 调试日志记录已启动 2026-09-03 15:58:44 * (自启动以来耗时 207 毫秒，spsdk_logger.py:213) 调试信息：spsdk：* SPSDK 版本：3.11.0* (自启动以来耗时 207 毫秒，spsdk_logger.py:215) 调试信息：spsdk：* Python 版本：3.14.4* (自启动以来耗时 207 毫秒，spsdk_logger.py:216) 调试：spsdk：* 操作系统版本：Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * （自启动以来耗时 208 毫秒，spsdk_logger.py:217） DEBUG:spsdk:* 最后一条命令：['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-熔丝', '--index', '136'] * (自启动以来已过去 208 毫秒，spsdk_logger.py:218) 调试：spsdk：***************************************************（自启动以来已运行 208 毫秒，spsdk_logger.py:219） 跟踪：spsdk.uboot.uboot：Uboot写入 -> 无效（自开始以来已耗时 210 毫秒， __init__ .py:50） 调试：spsdk.uboot.uboot：Uboot读取直到 <- => (自启动以来已过去 210 毫秒，uboot.py:271) 调试：spsdk.uboot.uboot：正在检查如果串口控制台因发送无效命令而打开：“无效\r\n未知命令‘无效’ - 请尝试‘帮助’\r\nu-boot=>”（自启动以来 224 毫秒，uboot.py:209） 调试：spsdk.utils.database：当前数据库指纹哈希值：f0f0598d4e6ae6c755d693693f232e30537cfb3b（自启动以来耗时 226 毫秒，database.py:1967） 调试信息：spsdk.utils.database：已加载从缓存读取数据库：/tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache（自启动以来耗时 226 毫秒，database.py:1976） 调试：spsdk.utils.misc：正在加载从 /usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml 读取文本文件（自启动以来耗时 226 毫秒，misc.py:312） 信息：spsdk.ele.ele_comm：ELE通信器在 mimx9596 中使用 92800000 地址处的 196608 B 大小的缓冲区，版本：最新目标。 调试：spsdk.ele.ele_comm：ELE消息 0x92800000 0x30000 0602971788000000 (自启动以来已过去 245 毫秒，ele_comm.py:502) 跟踪：spsdk.uboot.uboot：Uboot写入 -> ele_message 0x92800000 0x30000 0602971788000000 (自开始以来耗时 246 毫秒， __init__ .py:50) 调试：spsdk.uboot.uboot：Uboot读取直到 <- => (自启动以来 246 毫秒，uboot.py:271) 调试：spsdk.ele.ele_comm：原始ELE消息输出： ele_message 0x92800000 0x30000 0602971788000000 060497e1d60000000000000000000200u-boot=> (自启动以来 256 毫秒，ele_comm.py:422) 调试：spsdk.ele.ele_comm：已剥离输出：060497e1d600000000000000（自启动以来耗时 256 毫秒，ele_comm.py:460） 调试：spsdk.apps.utils.utils：SPSDK：响应中的消息大小无效：0x4（自启动以来耗时 257 毫秒，utils.py:182） 回溯（最近一次调用）： 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py”，第 172 行，包装纸 retval = function(*args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”，在 safe_main 函数的第 2189 行 sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 1631 行，在__call__ 返回 self.main(*args,**kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 1552 行，主线 rv = self.invoke(ctx) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 2032 行，在 invoke 中 返回 _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 1415 行，在 invoke 中 返回 ctx.invoke(self.callback,**ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 910 行，在 invoke 中 返回回调函数(*args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py”，第 46 行，在 new_func 中 返回 f(get_current_context().obj, *args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”，第 575 行，在 cmd_read_common_fuse 中 ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”，第 588 行，在 ele_read_common_fuse 中 ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py”，第 519 行，在 send_message 函数中 msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py”，第 1235 行，在 decode_response 中 super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py”，第 346 行，在 decode_response 中 raise SPSDKParsingError(f"响应中的消息 SIZE 无效：{hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: 响应中的消息大小无效: 0x4 ``` 注：我使用的是 `SPSDK 3.11.0` 我已在 SPSDK 的 GitHub 页面上创建了一个 issue： https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614 非常感谢您的帮助。 谢谢！ BR， Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 嗨joanxie 我使用的是 Linux 电路板支持包 版本 LF6.18.20_2.0.0 (yocto wrynose) 以下是 nxpele get-info 的输出结果 $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 请问您执行此命令时使用的是哪个 EL 固件版本？让我再确认一下。 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 我重现了这个问题，并检查了内部数据库，确认这是一个已存在的问题，将在 spsdk 3.12.0 中修复。

S32K3x4EVB-T172 PIL通信エラー/タイムアウト（MBDT S32K3xx 1.4.0使用時） こんにちは、 MATLAB 2023a上で、MBDT S32K3xx (v1.4.0)を使用してPIL S32CTのサンプルを実行してみました。私のセットアップは、S32K3x4EVB-T172をオンボードのOpenSDAポートに接続しています。 試み1(OpenSDA COM): 生成されたターゲットモデルのフラッシュは成功しますが、PIL実行はすぐに以下のエラーで失敗します。 「通信チャネルが開かれませんでした」(添付のエラーメッセージのスクリーンショット参照) 試み2(外部USB2シリアルコンバータ) OpenSDAポートはフラッシュ用に繋いだままにしつつ、外部USB2SirealコネクタをJ44(1からTX、2からRX)に接続してPIL通信を行い、ハードウェア設定でCOMポートを更新しました。モデルは正常にフラッシュしますが、実行時にタイムアウトするとエラーがあります。 エラー:rtiostreamインターフェースからのデータ受信に10秒のタイムアウトが超過しました。この通信障害には複数の原因が考えられます。 あなたは以下のことをすべきです: (a) ターゲットハードウェア構成が正しいか、例えばバイトの順序が正しいかを確認します。 (b) ターゲットアプリケーションがターゲットハードウェア上で動作していることを確認。 (c) アプリケーションの実行時障害(例:例外で割り算、誤ったカスタムコード統合など)の可能性を考慮します。 注(c):実行時の失敗の原因を特定するために、シグナルハンドラとデバッグをサポートするSILの使用を検討してください。 解決策が見つからない場合は、rtw.connectivity.RtIOStreamHostCommunicatorのsetTimeoutRecvSecs方法を使ってタイムアウト値を増加させることを検討してください。   質問: 1.S32K3x4EVB-T172ボードはPIL用に外部USB2Serialコンバータが必要ですか?それとも内蔵のOpenSDAポート経由でPILを動かせますか? 2. 外部USB-シリアル変換が必要な場合、想定されるハードウェアUART構成は具体的にどのようなものですか？ 3. 何か設定が抜けているのでしょうか？ どんなアドバイスでも大変ありがたく思います！ Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 こんにちは、 @PruthviB さん、 さらに調査する前に、なぜ MBDT S32K3xx v1.4.0を使っているのか、もう少し詳しく教えていただけますか?最新のリリースはv1.8.0で、いくつかの修正と改善が含まれています。まずはバージョン1.8.0にアップグレードして、問題が再現するかどうかを確認することをお勧めします。 あなたの構成についてですが、S32K3X4EVB-T172のPIL通信には外部のUSB-シリアル変換器は必須ではありません。オンボードの OpenSDAインターフェースはすでにホスト-ターゲット通信に使われるターゲットUARTへのアクセスを提供しているため、同じUSB接続でプログラミングとPIL通信の両方に使用できます。 OpenSDAはUARTピンに直接アクセスできるため、追加のUSBからシリアルアダプターへの接続は一般的に不要であり、複数のシリアルインターフェースが同時に動作している場合には設定競合を引き起こすことさえあります。 以下のような例を試してみていただけますか: MBDT S32K3xx v1.8.0 オンボードのOpenSDA USB接続のみ ハードウェア設定で選択された、OpenSDAによって公開されるCOMポート よろしくお願いします、 ドラゴス Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 やあ、 @dragostoma OpenSDAのオンボードインターフェースに関するご案内ありがとうございます。 バージョンに関しては、MBDT for BMSではMBDT v1.4.0が推奨バージョンでした。v1.4.0でのPILシミュレーションの実行についてのガイダンスを教えていただけますか? よろしくお願いいたします。 プルートヴィ Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 こんにちは、 @PruthviB さん、 確かに、おっしゃる通りです。BMS Toolboxには、S32K3 Toolboxバージョン1.4.0が必要です。最初の議論ではBMSツールボックスについて言及されていなかったので、問題は古いバージョンのS32K3ツールボックスを使用していることに関連していると考えました。 バージョン1.4.0におけるPILシミュレーションに関しては、ワークフローに変更はありません。ツールボックスに付属する例モデルは、 LPUARTインスタンスを使用し、そのRXおよびTX信号がOpenSDAインターフェースを通じてルーティングされるように設定されています。専用の USBからシリアルコンバータを使用する場合は、別のLPUARTインスタンスを設定し、コネクテッドする受信および送信ピンを割り当てる必要があります。 要約すると： OpenSDAインターフェースの使用:ツールボックスに付属する例モデルは、追加の修正なしで動作するはずです。必要なLPUARTインスタンスと関連するRX/TXピンは既に設定済みです。 専用のUSBからシリアルコンバータを使用する場合:コンバーターは対象機器の特定のRXピンおよびTXピンに接続する必要があります。したがって、これらのピンは構成され、利用可能なLPUARTインスタンスにマッピングされる必要があり、それに伴いプロジェクト構成も更新する必要があります。 USB2Serialコンバーターを使用する際は、正しいCOMポートを使用し、J44のRXピンとTXピンが設定されているか確認してください。 どのように機能するか教えてください。 ドラゴス

Audifort Review: Does It Really Stop Tinnitus Overnight? Audifort Review: Does It Really Stop Tinnitus Overnight? If you are dealing with a non-stop ringing, buzzing, or clicking sound in your ears every single day, you know how desperate the search for relief can get. When looking for solutions online, you may come across aggressive advertisements for liquid dietary drops like Audifort that imply instant results or overnight relief from tinnitus. The short answer is no: Audifort does NOT stop tinnitus overnight. No oral supplement or natural drop can instantly cure chronic tinnitus or rebuild damaged auditory nerves in 24 hours. However, that does not mean the formula is useless. When evaluated realistically as a natural dietary supplement rather than a miracle cure, Audifort provides supportive nutrients that nourish inner ear blood vessels and calm overactive nerve signals over time. In this Audifort review, we look beyond the sales marketing to analyze how the drops actually work, its core ingredients, realistic expectation timelines, potential side effects, and how to avoid fake online listings.

i.MX95 Neutron:同じINT4 LLMで4問中1回答でNPU/CPUの不一致が発生します 概要 i.MX95 上で量子化された ONNX を 1 つ実行します。1 つは CPUExecutionProvider の下、もう 1 つは ニュートロン実行プロバイダー。2つの腕は同じ答えを出しません:2,466対 選択式問題では25.7%が異なる答えを返します(MMLUでは43.6%)。無料で 世代ごとに同じことが起こります - MMLU プロンプトでは、19 世代のうち 13 世代で 異なる回答の手紙。 これは言葉遣いの違いではありません。それはモデルが答える内容の違いです。一方、総合的なベンチマーク精度はわずか-1.8ポイントの変動にとどまった。 私たちは、Neutronランタイムが数値的に何をして生成するかを理解したいのです この大きさが予想されるかどうかも重要です。 設定 あなたの側で再現可能:モデルは表2からUG10166、量子化は 自分だけのレシピ、修正なし。 - ボード:i.MX95 19x19 EVK(IMX95LPD5EVK-19)、LPDDR5 - BSP: LF6.18.2_1.0.0、デバイスツリー imx95-19x19-evk-neutron.dtb - ランタイム:BSP + NeutronExecutionProviderからのONNX Runtime 1.22.0 - Neutron コンバータ:3.1.3 - モデル:meta-llama/Llama-3.2-1B-Instruct - 量子化:NXP/eiq-olive rev aae820e、 例/Llama3/llama3_2-1B_Spinquant_RTN_ONNX_4bits.json - 変換:convert_ort_models_to_neutron.py、CPU Armのモデルに適用されます。onnx - 環境: NEUTRON_CMA_512SLOTS=6 両方のArmは1つの量子化されたモデルから来ています。NPUアームはそのモデルを通過させるものです convert_ort_models_to_neutron.py。ソースのSHA-256を記録します - グラフ と 外部重み - 換算時に測定し、測定のたびに再確認します。 2回目の量子化実行や2回目のエクスポートはありません。 私たちが観察すること 1.4つの項目のうち1つは異なる回答が得られる。 MMLU、ARC-Challenge、PIQAからの2,466組のペアアイテム、0ショット、対数尤度でスコアリング 候補者の継続については、候補者ごとに1つのフォワード、生成なし、サンプリングなし。 各ベンチマークについて、ANSWER が変化した項目の割合、次に、 正確性が変更されました: - MMLU（4つの選択肢）：回答変更率43.6%、正誤変更率27.1% - ARCチャレンジ（4つの選択肢）：回答変更率21.3%、正誤変更率13.3% - PIQA（2つの選択肢）：回答変更率9.4％、正誤変更率9.4％ - 合計：回答変更率25.7%、正誤変更率17.3% 2つの数字が異なるのは、変更の3分の1（634件中208件）が1つの間違いから移動しているためです。 別の間違った答えへの答え - 正確さを失わせる真の行動の変化 手つかず。PIQAはバイナリであるため、そのような盲点はなく、2つの数値は一致する。 その通り。 2. 自由生成の場合も同様で、答え自体が変わります。 プロンプト数50、貪欲解読、トークン数64。MMLUプロンプトでは期待される出力が始まります 回答文字を含んで、その答えは世代から直接読み取ることができます (n = 19): - 両Arm間で異なる回答文字:19件中13件 - CPUで正解:19中7 - Neutronで正解:19題中6題 - 両Armが間違っていて、異なる誤答が出る意見の相違:13回中6回 回答の3分の2が変わったが、点数はほぼ同じだった（7対6）。 サンプル数は少ないので、ここでは例として報告します。上記の2,466項目の測定結果 これは定量的なものです。 以下に、一字一句そのままの例を示します。プロンプトには 4 つの選択肢がリストされており、文字を求められ、 期待される答えは 😧 CPU: " A\n説明: 式 9(9m + 3t) は 81m + 27t と同等です。 正解はAです。 NPU：「C\n正解はCです。」 どちらも間違っているが、その間違い方は異なり、それを記録できるベンチマークスコアは存在しない。 3. 乖離は累積ではなく、最初のフォワードで発生します。 このレター形式では、最初に生成されたトークンが答えであり、生成の 60% が 既に違いが生じているのは、デコードを行う前の、プリフィルパスのみで生成されたトークンである。 ステップ。50のプロンプトすべてにおいて、乖離曲線は急激に上昇した後、平坦化する。84%は トークン4、トークン64による98%。これが初期差分の伝播の様子です 貪欲なデコードの場合、KVキャッシュを通じてエラーが蓄積されることはありません。 4. 集計精度はそれらすべてを隠してしまう。 CPUは50.28%、Neutronは48.50%、-1.78ポイント差、そして 3つのベンチマークは個別に重要です。634項目に限定して 意見は異なっています。CPUは37.1%の確率で正しかったのに対し、Neutronは30.1%、235%の確率で正解です。 決定された項目のうち191、すなわち対称ノイズが50/50となる場合、55/45です。 除外したもの - サイレントCPUフォールバック: ORTプロファイリングレポートでは、80/80 MatMulNBitsが NeutronExecutionProvider、CPU使用率0。部分的な配置はできません。 - 2つの異なるモデル:同じソースファイル、グラフのSHA-256および外部重み コンバージョン時に記録され、得点前に再確認されました。 - サンプリング: 全体を通して貪欲なデコード。温度、トップk、トップpは使用しません。 - 異なる入力:両方のアームが同じアイテムファイルを同じ順序で消費します。 同じ固定シードです。 - 成果物のスコアリング:ボードはトークンごとの対数確率のみを捉えます;すべての決定 ロジックはホスト側でオフラインで動作し、両アームで同じように動作します。 - NPUのラン・トゥ・ランノイズ:同じNeutronセッション内で同じ項目を再生すること ビット同一の対数確率が得られます。NPUアームは再現可能であり、その不一致 それはCPUに対してであり、自分自身に対してではありません。 私たちの質問 これはニュートロンSのINT4経路に期待される挙動でしょうか?もしそうなら、どのようにすべきでしょうか NPU上でのLLM展開を検証し、集計ベンチマーク精度を明確に示します 表面に浮かび上がらない? 私たちは欠陥を想定しているわけではありません。浮動小数点CPUカーネルと 整数のNPU経路は通常であり、どのくらいの大きさを考えているのか知りたいです 通常、そしてどの基準でNEUTRONへのLLMポートを受け入れますか?もし 回答の4分の1が変わるのは期待内であり、それは私たちにとって有益なことです 知っていて、それを中心に設計する。 Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM 迅速なご回答ありがとうございます！ DS Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM こんにちは、 @DamienSCHNEBELEN さん。 IMX95 NPUはmatmulしか動作できず、NPUでのLLMのパフォーマンスは実際には平均的なレベルです。したがって、あなたが観察した現象は予測可能な範囲内であり、NPU上でLLMモデルを動かすことは推奨しません。 B.R