FRDM i.MX93 上的 AP1302 MIPI CSI 流问题 你好， 我使用的是FRDM i.MX93开发板和X-RPI-CAM-MIPI A1摄像头模块。 我遇到的问题是，我无法从此设置中捕获 MIPI CSI 流。 我已将固件二进制文件ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin放置在以下位置：“/lib/firmware” 启动过程中，我看到 AP1302 被成功检测到，但是当我尝试启动视频流时， VIDIOC_STREAMON出现“管道破裂”错误。 以下是相关日志。 内核日志： root@imx93evk:~# dmesg | grep ap1302 [ 0.340980] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.371014] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c ... [ 10.088832] ap1302 2-003c: AP1302 revision 0.2.6 detected 流媒体测试： root@imx93evk:~# v4l2-ctl -d /dev/video0 \ --verbose \ --stream-mmap=3 \ --stream-count=10 VIDIOC_QUERYCAP: ok VIDIOC_REQBUFS returned 0 (Success) VIDIOC_CREATE_BUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_G_FMT returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned -1 (Broken pipe) 请问您能否帮我理解一下为什么VIDIOC_STREAMON会出现“管道破裂”错误？ 在成功开始流媒体传输之前，AP1302 固件、设备树、媒体管道或传感器初始化是否需要任何额外的配置？ 此外，我目前使用的是“LF_v6.18.2-1.0.0_images_IMX93EVK”预构建镜像。 如果您需要任何其他日志或信息，请告诉我。 感谢您的支持。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 与AE团队讨论。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 你好@yipingwang 感谢您的反馈， 我的回答如下，供您参考。 1. 固件位置 我尝试了推荐的固件安装位置，也尝试了每个位置的单独安装。仅当使用ap1302_ar0144_single_fw.bin时，相机探测才会成功。 root@imx93evk:~# ls -la /lib/firmware/ap1302_ar0144_single_fw.bin -rw-r--r-- 1 root root 80528 Aug 5 15:36 /lib/firmware/ap1302_ar0144_single_fw.bin root@imx93evk:~# ls -la /lib/firmware/imx/camera/ap1302.fw -rw-r--r-- 1 root root 80528 Aug 5 15:38 /lib/firmware/imx/camera/ap1302.fw 启动过程中成功检测到 AP1302。 root@imx93evk:~# dmesg | grep -i ap1302 ... [ 9.962705] ap1302 2-003c: AP1302 revision 0.2.6 detected 但是，我在内核日志中没有看到任何与 AP1302 相关的固件加载消息。 2. 软件环境 我使用的是为FRDM i.MX93板提供的预构建镜像。 root@imx93evk:~# cat /proc/device-tree/model NXP FRDM-IMX93 root@imx93evk:~# cat /proc/cmdline console=ttyLP0,115200 earlycon root=/dev/mmcblk0p2 rootwait rw AP1302 检测成功，CSI/ISI 设备也存在。我已附上完整的日志供您参考。 3. 媒体管道 媒体管道似乎已正确创建。 root@imx93evk:~# ls /dev/media0 /dev/media0 root@imx93evk:~# ls /dev/video* /dev/video0 /dev/video1 media-ctl 的输出显示 AP1302、CSI 和 ISI 实体已启用。完整的 media-ctl 输出结果已附上，供您参考。 4. 补充信息 请参考附件fourth_point.txt文件以获取所需信息。 5. 流媒体播放失败 当流媒体命令失败时，我没有看到任何其他内核消息。 root@imx93evk:~# dmesg -c root@imx93evk:~# v4l2-ctl -d /dev/video0 --stream-mmap=3 --stream-count=10 VIDIOC_STREAMON returned -1 (Broken pipe) root@imx93evk:~# dmesg 故障发生后，dmesg 输出仍然为空，因此没有额外的内核日志可以帮助确定根本原因。 由于 AP1302 已被成功检测到，媒体图也已正确创建，并且在 VIDIOC_STREAMON 期间没有报告任何内核错误，请问我应该执行哪些额外的检查或调试步骤来确定为什么流媒体播放失败并出现“管道破裂”错误？ 感谢您的支持。 root@imx93evk:~# v4l2-ctl --list-devices mxc-isi-cap (platform:4ae40000.isi): /dev/video0 /dev/video1 /dev/media0 root@imx93evk:~# v4l2-ctl -d /dev/video0 --all Driver Info: Driver name : mxc-isi Card type : mxc-isi-cap Bus info : platform:4ae40000.isi Driver version : 6.18.2 Capabilities : 0xa4201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Device Capabilities Device Caps : 0x24201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Media Driver Info: Driver name : mxc-isi Model : FSL Capture Media Device Serial : Bus info : platform:4ae40000.isi Media version : 6.18.2 Hardware revision: 0x00000000 (0) Driver version : 6.18.2 Interface Info: ID : 0x0300000a Type : V4L Video Entity Info: ID : 0x00000008 (8) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000009 : 0: Sink Link 0x0200000c: from remote pad 0x1000007 of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled, Immutable Priority: 2 Video input : 0 (mxc_isi.0.capture: ok) Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : sRGB YCbCr/HSV Encoding: ITU-R 601 Quantization : Limited Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 flags=0x00001000 vertical_flip 0x00980915 (bool) : default=0 value=0 flags=0x00001000 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 flags=0x00001000 root@imx93evk:~# media-ctl -p Media controller API version 6.18.2 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ae40000.isi hw revision 0x0 driver version 6.18.2 Device topology - entity 1: crossbar (3 pads, 3 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 0/0 -> 2/0 [ACTIVE] pad0: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "csidev-4ae00000.csi":1 [ENABLED,IMMUTABLE] pad1: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad2: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] - entity 5: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":2 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 8: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 16: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":1 [ENABLED,IMMUTABLE] - entity 23: csidev-4ae00000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "ap1302 2-003c":2 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":0 [ENABLED,IMMUTABLE] - entity 28: ap1302 2-003c (3 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] <- "ar0144 0":0 [ENABLED,IMMUTABLE] pad1: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] pad2: SOURCE [stream:0 fmt:UYYVYY8_0_5X24/4224x4092 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] -> "csidev-4ae00000.csi":0 [ENABLED] - entity 32: ar0144 0 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: SOURCE [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb] -> "ap1302 2-003c":0 [ENABLED,IMMUTABLE] 此致， 米拉夫 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 AP1302 探测成功并不能保证整个摄像机管道已配置完毕并开始传输。在 i.MX93 上，VIDIOC_STREAMON 返回 -1（管道破裂）通常意味着媒体管道元器件之一（AP1302 → MIPI CSI-2 接收器 → ISI 捕获路径）未能启动或协商有效流。您的日志仅确认检测到了 AP1302 I²C 设备： ap1302 2-003c：检测到 AP1302 版本 0.2.6 但这并不能证实这一点： 固件加载成功。 使用了正确的DTB。 媒体关系图已创建完成。 CSI接收器锁定到传入的MIPI数据， AP1302 已配置为匹配的输出格式。 首先我会检查：固件位置/名称 关于 FRDM-i.MX93 AP1302 支持，NXP 文档指出： 下载 ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin 将其重命名为ap1302.fw 放入： /lib/firmware/imx/camera/ap1302.fw 不仅仅是 /lib/firmware。 请核实： ls -l /lib/firmware/imx/camera/ap1302.fw 并检查启动日志： dmesg | grep -i 固件 dmesg | grep -i ap1302 查找类似这样的消息： 请求固件 固件已加载 固件加载失败 第二步：你使用的是正确的DTB吗？ 版本说明表明 AP1302 支持与 i.MX93 EVK 设备树支持相关。 检查： cat /proc/device-tree/model cat /proc/cmdline 并确定实际加载的 DTB。 另请查看： dmesg | grep -i ap1302 dmesg | grep -i csi dmesg | grep -i isi 第三项检查：验证介质拓扑结构 在尝试使用 v4l2-ctl 之前，请先验证媒体图是否存在： shell media-ctl -p 显示更多行 您应该会看到类似以下的实体： ap1302 CSI 伊西 videoX 如果 /dev/media0 不存在，则相机管道创建不正确。一个非常相似的FRDM-i.MX93 AP1302案例显示： media-ctl -p 枚举 /dev/media0 失败 这表明媒体管道尚未实例化。 请检查： ls -l /dev/media* 第四项检查：检查协商好的格式 运行： v4l2-ctl --list-devices 以及 v4l2-ctl -d /dev/video0 --all 另外： media-ctl -p AP1302 固件通常输出处理后的 YUV 格式，而不是 RAW Bayer 格式。另一个常见的故障是： AP1302 输出格式 A ISI 配置为 B 格式 导致流媒体启动失败。格式不匹配通常表现为 STREAMON 故障或 CSI 管道错误。 第五项检查：在 STREAMON 期间检查 CSI 错误 打开另一个终端并进行监测： dmesg -w 然后运行： v4l2-ctl -d /dev/video0 \ --stream-mmap=3 \ --stream-count=10 查找类似这样的消息： CSI超时 帧开始超时 未收到任何数据 先进先出溢出 MIPI错误 链接未启用 这些信息通常会揭示管道破裂的真正原因。

割り込みを有効にせずにDMAでLPI2Cペリフェラルを使うにはどうすればいいですか? こんにちは、 私は NXP S32K396 MCU を扱っており、 割り込みを有効にせずにeDMAを使ってLPI2Cマスタートランザクションを実行したいと考えています。私のプロジェクトでは LPI2C1ペリフェラルを使っています。 以下の割り込みが有効であれば、DMAを使ってLPI2Cの読み書きトランザクションを正常に実行できます: LPI2C1_IRQn eDMA0_DMATTCD_CH16_CH17_IRQn しかし、RTD LPI2C DMAの実装はこれらの割り込みに依存しているようです。 Lpi2c_Ip_MasterSendData()では、LPI2Cマスター割り込みは常にドライバによって有効化されます: さらに、Lpi2c_Ip_MasterTxDmaConfig() および Lpi2c_Ip_MasterRxDmaConfig() によって TX および RX 用に構成された DMA TCD は、常に DMA メジャーループ完了割り込みを有効にします。 Lpi2c_DmaTransferList[9u]. Param = DMA_IP_CH_SET_CONTROL_EN_MAJOR_INTERRUPT ; Lpi2c_DmaTransferList[9u]。値= 1U; また、別の関数であるLpi2c_Ip_MasterSendDataBlocking()では、LPI2C転送用のDMA TCDが設定されていないようです。 DMAを使ってLPI2Cの送受信トランザクション全体を行い、DMAを無効にし、eDMAチャネル割り込みを無効にLPI2C1_IRQnしたいと考えています。   可能であれば、NXPが LPI2CとDMAの両方の割り込みを無効にした状態でDMAを使用するLPI2CマスターTX/RXの例を提供していただけますか?   MCU:NXPS32K396 RTD: 6.0.0 NXP Studio: 3.6.1   どんなご支援でも大変ありがたく思います。どうぞよろしくお願いいたします！ 必要なら、プロジェクトを添付できます。 Re: How to use LPI2C peripheral with DMA without enabling any interrupts? こんにちは@rkhw 現在のドライバ実装では、「Lpi2c_Ip_MasterSendData()」は転送完了と状態処理のためにLPI2Cマスター割り込みとDMAメジャーループ完了割り込みの両方に依存しています。 したがって、割り込みを有効にしなければDMAを有効にすることはできません。RTDドライバーはこの使用をサポートしていません。

フラッシュ消去時にRAM内でピット割り込みが実行されます フラッシュを消している間にタイマー割り込みに入れないことがわかりました。私の要件を満たすために、タイマー割り込みをRAM上で実行する予定です。linker_flash_s32k388.ld ファイルを修正して IntCtrl_Ip.o と Pit_Ip.o を RAM に配置するようにしましたが、フラッシュを消去すると、タイマー割り込みの発生により依然としてエラーが発生します。私が見落としている点があれば教えてください。#s32k388 Re: Pit interrupt runs in ram wen flash erase こんにちは、 IntCtrl_Ip.oとPit_Ip.oを配置するだけでRAMに書き込むだけでは通常は不十分です。PFLASH消去操作中は、CPUは影響を受けたフラッシュアレイへのアクセスを避けなければなりません。 割り込みベクタテーブル、PIT ISR、ISRによって呼び出されるすべての関数、およびISRで使用されるすべてのデータ/定数がSRAMに配置されていることを確認してください。さらに、VTORレジスタがRAMベースのベクタテーブルを指していることを確認してください。リンカーマップファイルは通常、残りのフラッシュアクセスを特定する最良の方法です。 S32K3リファレンスマニュアルには、フラッシュ操作が継続実行を必要とする場合はコード実行をSRAMに移す必要があると記載されています。 よろしくお願いいたします。 ピーター Re: Pit interrupt runs in ram wen flash erase 私のISRとISRが呼び出す関数はRAMに配置されており、VTORのアドレスも0x2...0x4ではなく...RTDの設定時にフラッシュドライバーがRAMで動作するのを選びました。PITが閉じている間は正常に動作しますが、PITを有効にするとフリーズします。ただ、デバッグしても問題の原因を特定できません

执行 fls_Erase() 操作期间断电后，数据闪存损坏和 ECC 错误 我们发现，当由于断电/RESET情况导致Fls_Erase()操作中断时，数据闪存会发生损坏。系统重启后，受影响的数据闪存区域似乎已损坏。 在随后尝试使用Fls_Erase()恢复扇区时，当 Flash 驱动程序在执行擦除操作之前尝试访问受影响的地址范围时，会生成 ECC 错误。因此，擦除操作无法成功进行。 我们希望了解闪存控制器在此场景下的预期行为，并请求就以下几点提供指导： 如果在Fls_Erase()操作进行期间断电，数据闪存是否会损坏？ 在发生此类中断后，访问部分擦除/损坏的闪存扇区时，是否预期会出现 ECC 错误？ 是否有任何机制或寄存器可以暂时禁用 Flash ECC 检查，以便擦除和恢复损坏的 Flash 扇区？ 断电后，对于包含无法纠正的ECC错误的闪存扇区，推荐的恢复程序是什么？ 目标设备： [MPC5746C] 软件栈： [AUTOSAR / 裸机] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation 你好， 如果在Fls_Erase()操作进行期间断电，数据闪存是否会损坏？ 是的，这是正确的做法。由于编程/擦除过程中断电，闪存中的数据将与 ECC 纠错码不匹配。 在发生此类中断后，访问部分擦除/损坏的闪存扇区时，是否预期会出现 ECC 错误？ 是的。 是否有任何机制或寄存器可以暂时禁用 Flash ECC 检查，以便擦除和恢复损坏的 Flash 扇区？ 不，这是硬件的永久性功能。 断电后，对于包含无法纠正的ECC错误的闪存扇区，推荐的恢复程序是什么？ 在这种情况下，您需要初始化（擦除）损坏的闪存块。一旦完成 ECC 纠错，闪存中的数据将与 ECC 纠错匹配，访问不会触发 ECC 错误。 有关闪存擦除步骤，请参阅参考手册： 顺祝商祺！ Peter

S32K396的ETPU的例子 您好，我需要一个S32K396的RTD5.0.0用于S32DS3.5中生成的ETPU的demo，然后我想将它用于喷油功能，可以给我一个软件包和代码例子吗 Re: S32K396的ETPU的例子 嗨@大概， 实时驱动程序 (RTD)中已有 ETPU 和 S32K396 的示例： 此外，您可以在S32K3 - eTPU软件包中找到各种示例。它独立于RTD，这意味着可以使用任何版本，但是，eTPU软件仅使用特定的RTD 7.0.0版本进行了验证。版本，且无法保证与其他版本的兼容性。 此致， 朱利安

S32 Design Studio for ARM v2.2许可延期 あなたは好,S32 Design Studio for ARM v2.2提示許可馬上到期,Activation Code:FAF2-FCC2-8A8E-87AC,麻烦延期,谢谢!

i.MX 8M Plus LPDDR4 EVK - eMMC boot0/boot1 の有効化 ボード:i.MX 8M Plus LPDDR4 EVK(MIMX8ML8DVNLZAA年)、IMX8MPEVKHUG rev 0 HAB:融合オープン(SRKは意図的に燃焼せず、まだ評価中) 私はRAUCベースのA/B更新システム向けにブートローダーと更新の冗長性を実装しており、eMMCのハードウェアboot0/boot1パーティション(BOOT_PARTITION_ENABLE)を多くのi.MX8M設計のように使いたいと考えています。つまり、新しいブートローダーを非アクティブなブートパーティションに書き込み、どちらがアクティブかを反転させ、新たにアクティブなブートローダーが故障した場合はROMがもう一方にフォールバックする形です。私は特に、このためにBOOT_CFG/efuseを焼却することを避けたいのです。 EVK上で、poky/oe-core mmc-utilsレシピからビルドしたmmc-utilsを使用して観察した結果は以下のとおりです。 - mmc extcsd read /dev/mmcblk2 は PARTITION_CONFIG を報告し、BOOT_PARTITION_ENABLE は既に boot0 (値 0x08) に設定されています。 - boot0 (/dev/mmcblk2boot0) には有効なイメージ (オフセット 0 に正しい IVT タグ) が含まれていますが、現在デプロイされているブートローダーと一致しません。 - boot1 (/dev/mmcblk2boot1) は完全に空です (すべてゼロ)。 - バイト単位の正確な比較により、ボードは実際には標準の32 KiBオフセットで生のeMMCユーザーエリアから起動していることが確認できます(コンテンツは現在デプロイしているimx-bootと完全に一致します)。boot0から起動しているわけではありません。boot0が有効であることを示すPARTITION_CONFIGもあります。 このボードでは、EXT_CSDのBOOT_PARTITION_ENABLEはROMの実際のブートソースに影響を与えていないようです。IMX8MPEVKHUG 2.2節によると、EVKのSW4スイッチは粗いブートデバイスクラス(eMMC、SD、QSPI、NAND、ヒューズ、USBシリアルダウンロード)のみを選択し、eMMCブートパーティションサブモードのスイッチ位置は存在しません。 質問: 1. LPDDR4 EVK上で「eMMC boot0/boot1ハードウェアパーティションからのROMブート」を特に選択する方法は、BT_FUSE_SEL=1設定やBOOT_CFGエフューズの焼却なしに選択できるサポート方法はありますか?例えば、ジャンパー、抵抗オプション、またはrev 0に記載されていない代替のSW4/SW1101の組み合わせなどIMX8MPEVKHUG?それとも、このボードのPCBにハードストラップされていて、状態に関係なく常にeMMCユーザーエリアから起動するようにEXT_CSD? 2. BOOT_CFG efuseがeMMCブートパーティションモードを有効にする唯一の方法である場合、これを制御するBOOT_CFGヒューズバンクは、HABに使用されるSRKハッシュヒューズとは独立していますか？ヒューズを介してeMMCブートパーティションの冗長性を有効にすると、同時にHAB（SRK書き込み）を終了する必要が生じるのか、それともこれらは別々の決定事項なのかを理解したい。 3. i.MX 8M PlusとeMMCを使ったカスタムボード設計(EVKではありません)の場合、eMMCのboot0/boot1冗長性を最初の起動時から利用可能にする推奨方法は何でしょうか?つまり、BOOT_CFG GPIOのストラップやPCB設計において、後でヒューズのコミットメントを必要としないよう、初日の選択肢として何が真であるべきか? また、eMMCブートパーティション選択のBOOT_CFGビット定義(IMX8MPEVKHUGで既に扱われているSW4デバイスクラスビット以外)を扱ったリファレンスマニュアルのセクションへの指し印も教えていただけると助かります。 ご回答をお待ちしています。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 i.Mx8 UMに関する参考までに、第5章の第5.8.2.2.1章「高レベルeMMCブートフロー」 SCU ROMは4つのeMMCブートシナリオをサポートします: 1.このシナリオでは、「eMMC高速ブート」ヒューズが切れています。一次および二次 イメージコンテナセットは両方ともブートパーティション内にあり、BOOT_PARTITION_ENABLE = 1 または 2 です。 2. このシナリオでは、「eMMC 高速ブート」ヒューズが切れています。小学校と中学校 イメージコンテナセットはどちらもユーザーエリアにあり、BOOT_PARTITION_ENABLE=7です。 3.このシナリオでは、「eMMC高速ブート」ヒューズは切れません。起動モードはノーマルです Bootとプライマリおよびセカンダリイメージコンテナセットはどちらもユーザーエリアにあります。 4. この場合、「eMMCファストブート」ヒューズは 切れていません。起動モードは通常です ブート、プライマリおよびセカンダリイメージコンテナセットは両方ともブート内にあります パーティション、および BOOT_PARTITION_ENABLE = 1 または 2。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 アドバイスありがとうございます。ただ、第5.8.2.2.1章で別のチップファミリが説明されていると思います。「SCU ROM」eMMCブートフローは、専用のシステムコントローラユニット(Cortex-M4ブートサブシステム)を持つi.MX8QuadMax/QuadXPlus/DualXPlus専用です。i.MX8M PlusにはSCUがなく、起動ROMはCortex-A53上で直接動作するため、その章の BOOT_PARTITION_ENABLE=1/2/7 シナリオはここでは当てはまりません。 i.MX8M Plusの場合、冗長性はi.MX8M Plusリファレンスマニュアル(図6-1)のプライマリ/セカンダリイメージ機構で処理されているようです。ROMはBT_FUSE_SEL/BOOT_CFGで選択したデバイスから起動し、故障時には同じブートデバイス上でIMG_CNTN_SET1_OFFSETヒューズオフセットのセカンダリイメージにフォールバックします。 別々のboot0/boot1パーティションではありません。これはLPDDR4 EVKで見ているものと一致します。BOOT_PARTITION_ENABLE=1はEXT_CSDに設定されていますが、ROMはそれを無視し、生のユーザーエリアのオフセットから起動します。 そこで、私の質問はi.MX8M Plusに限定されました: 1. LPDDR4のEVK(ジャンパー、抵抗、または非公式のSW1101/SW4位置)でeMMC boot0/boot1をブートソースとして選択する方法はありますか?それとも純粋にストラップやBT_FUSE_SELの判断BOOT_CFGに過ぎませんか? 2. BOOT_CFGヒューズバンクはHABのSRKハッシュヒューズとは独立しているのか、それともBOOT_CFGヒューズ経由のコミットもHABのクロージングを強制するのか? 3.カスタムボード設計の場合、レイアウト時にハードウェアのブートパーティション冗長性を後でヒューズに縛り付けずに維持するために、どのようなBOOT_CFGものが必要ですか? もし私が第5.8.2.2.1章のどの部分に適用されるのかを誤解しているようでしたら、ご指摘いただければ幸いです。

Example of an ETPU based on S32K396 Hello, I need a demo of RTD 5.0.0 for S32K396 used in an ETPU generated by S32DS3.5. I want to use it for fuel injection functionality. Could you provide a software package and code examples? Re: S32K396的ETPU的例子 Hi @大概, There is an existing example for ETPU & S32K396 inside the Real-Time Drivers (RTD): Additionally, you can find various examples inside the S32K3 - eTPU SW package. It is independent from RTDs, meaning any version can be used, however, the eTPU SW has been validated only with the specific RTD 7.0.0 version, and compatibility with other versions cannot be guaranteed. Best regards, Julián

Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation We are observing Data Flash corruption when a Fls_Erase() operation is interrupted due to a power abort/reset condition. After the system restarts, the affected Data Flash region appears corrupted. During a subsequent attempt to recover the sector using Fls_Erase(), ECC errors are generated when the Flash driver tries to access the affected address range before performing the erase operation. As a result, the erase operation cannot proceed successfully. We would like to understand the expected behavior of the Flash controller in this scenario and request guidance on the following points: Is Data Flash corruption expected if power is lost during an ongoing Fls_Erase() operation? Are ECC errors expected when accessing a partially erased/corrupted Flash sector after such an interruption? Is there any mechanism or register available to temporarily disable Flash ECC checking so that the corrupted Flash sector can be erased and recovered? What is the recommended recovery procedure for handling Data Flash sectors that contain uncorrectable ECC errors following a power interruption? Target Device: [MPC5746C] Software Stack: [AUTOSAR / Bare Metal] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation Hello, Is Data Flash corruption expected if power is lost during an ongoing Fls_Erase() operation? Yes, that is correct behavior. As data in flash will not match ECC syndromes in flash due to power loss during programming / erase process. Are ECC errors expected when accessing a partially erased/corrupted Flash sector after such an interruption? Yes. Is there any mechanism or register available to temporarily disable Flash ECC checking so that the corrupted Flash sector can be erased and recovered? No. It is permanent HW feature. What is the recommended recovery procedure for handling Data Flash sectors that contain uncorrectable ECC errors following a power interruption? You need to initialize (erase) the corrupted flash block in such case. Once done ECC syndrome will match the data in flash and access wont trigger ECC faults. For flash erase procedure please refer to reference manual: Best regards, Peter

i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 Board: i.MX 8M Plus LPDDR4 EVK (MIMX8ML8DVNLZAA), IMX8MPEVKHUG rev 0 HAB: fused OPEN (SRK not burned, deliberately, still evaluating) I am implementing bootloader-update redundancy for a RAUC-based A/B update system and want to use the eMMC's hardware boot0/boot1 partitions (BOOT_PARTITION_ENABLE) the way many i.MX8M designs do — write the new bootloader to the inactive boot partition, flip which one is active, and rely on the ROM to fall back to the other if the newly-active one fails. I specifically want to avoid burning any BOOT_CFG/efuses for this. What I have observed on the EVK, using mmc-utils built from the poky/oe-core mmc-utils recipe: - mmc extcsd read /dev/mmcblk2 reports PARTITION_CONFIG with BOOT_PARTITION_ENABLE already set to boot0 (value 0x08). - boot0 (/dev/mmcblk2boot0) contains a valid-looking image (correct IVT tag at offset 0), but it does not match my currently deployed bootloader. - boot1 (/dev/mmcblk2boot1) is completely empty (all zero). - A byte-exact comparison confirms the board is actually booting from the raw eMMC user area at the standard 32 KiB offset (content matches my currently deployed imx-boot exactly) — not from boot0, despite PARTITION_CONFIG indicating boot0 is enabled. So on this board, EXT_CSD's BOOT_PARTITION_ENABLE appears to have no effect on the ROM's actual boot source. Per IMX8MPEVKHUG section 2.2, the EVK's SW4 switch only selects the coarse boot device class (eMMC vs SD vs QSPI vs NAND vs fuses vs USB serial download) — there is no switch position for the eMMC boot-partition sub-mode. Questions: 1. Is there a supported way to select "ROM boots from eMMC boot0/boot1 hardware partition" on the LPDDR4 EVK specifically, without setting BT_FUSE_SEL=1 / burning BOOT_CFG efuses — e.g. a jumper, resistor option, or alternate SW4/SW1101 combination not documented in IMX8MPEVKHUG rev 0? Or is this hard-strapped on this board's PCB to always boot from the eMMC user area regardless of EXT_CSD state? 2. If BOOT_CFG efuses are the only way to enable eMMC boot-partition mode: are the BOOT_CFG fuse banks that control this independent of the SRK-hash fuses used for HAB? I want to understand whether enabling eMMC boot-partition redundancy via fuses would force me to also commit to closing HAB (SRK burn) at the same time, or whether these are separable decisions. 3. For a custom board design (not the EVK) using the i.MX 8M Plus with eMMC, what is the recommended way to make eMMC boot0/boot1 redundancy available from first bring-up — i.e., what needs to be true in the BOOT_CFG GPIO strapping / PCB design so this is a day-one option rather than something that requires a later fuse commitment? Any pointers to the specific Reference Manual section covering the BOOT_CFG bit definitions for eMMC boot-partition selection (beyond the SW4 device-class bits already covered in IMX8MPEVKHUG) would also be appreciated. Thank you! Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 FYI for i.Mx8 UM at chapter 5.8.2.2.1 High Level eMMC Boot Flow The SCU ROM supports 4 eMMC boot scenarios: 1. In this scenario, the "eMMC fast boot" fuse is blown. The primary and secondary image container set are both in the boot partitions, and BOOT_PARTITION_ENABLE = 1 or 2. 2. In this scenario, the "eMMC fast boot" fuse is blown. The primary and secondary image container set are both in the User Area, and BOOT_PARTITION_ENABLE =7. 3. In this scenario, the "eMMC fast boot" fuse is not blown. The boot mode is Normal Boot, and the primary and secondary image container set are both in the User Area. 4. In this scenario, the "eMMC fast boot" fuse is not blown. The boot mode is Normal Boot, and the primary and secondary image container set are both in the boot partitions, and BOOT_PARTITION_ENABLE = 1 or 2. Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 Thanks for the pointer — though I believe chapter 5.8.2.2.1 describes a different chip family. The "SCU ROM" eMMC boot flow is specific to the i.MX8QuadMax/QuadXPlus/DualXPlus, which have a dedicated System Controller Unit (separate Cortex-M4 boot subsystem). The i.MX8M Plus has no SCU — its boot ROM runs directly on a Cortex-A53 — so the BOOT_PARTITION_ENABLE=1/2/7 scenarios in that chapter don't apply here. For i.MX8M Plus, redundancy appears to be handled via the Primary/Secondary Image mechanism in the i.MX8M Plus Reference Manual (Figure 6-1): the ROM boots from the device selected by BT_FUSE_SEL/BOOT_CFG, and on failure falls back to a Secondary Image at the IMG_CNTN_SET1_OFFSET fuse offset — on the same boot device, not a separate boot0/boot1 partition. This matches what I'm seeing on the LPDDR4 EVK: BOOT_PARTITION_ENABLE=1 is set in EXT_CSD, but the ROM ignores it and boots from the raw user-area offset regardless. So my questions remain, scoped to i.MX8M Plus: 1. Is there any non-efuse way on the LPDDR4 EVK (jumper, resistor, or undocumented SW1101/SW4 position) to select eMMC boot0/boot1 as the boot source, or is that purely a BOOT_CFG strap/BT_FUSE_SEL decision? 2. Are the BOOT_CFG fuse banks independent of the SRK-hash fuses for HAB, or does committing to BOOT_CFG-via-fuse also force HAB closure? 3. For a custom board design, what BOOT_CFG strapping is needed at layout time to keep hardware boot-partition redundancy available without a later fuse commitment? Happy to be corrected if I'm misreading which part chapter 5.8.2.2.1 actually applies to.

Fls_Erase() 操作中の電源中断後のデータフラッシュ破損および ECC エラー 電源の中断/リセットによってFls_Erase()操作が中断された場合、データフラッシュの破損が発生することを確認しています。システムを再起動すると、影響を受けたデータフラッシュ領域が破損しているように見える。 その後、セクターを Fls_Erase()で復旧しようとする際、フラッシュドライバが消去操作を行う前に影響を受けたアドレス範囲にアクセスしようとした際にECCエラーが発生します。その結果、消去作業は成功裏に進められません。 このシナリオにおけるフラッシュコントローラの期待される挙動を理解し、以下の点についての指針をお願いしたいと思います。 Fls_Erase()操作の実行中に電源が切断された場合、データフラッシュの破損が発生する可能性はありますか？ このような中断後に部分的に消去・破損したフラッシュセクターにアクセスする際にECCエラーが起こることは予想されますか? 破損したフラッシュセクターを消去・復元するために 、フラッシュECCチェックを一時的に無効 化する仕組みやレジスタはありますか? 電源遮断後に訂正不可能なECCエラーを含むデータフラッシュセクターを処理するための推奨される復旧手順は何ですか？ ターゲット装置: [MPC5746C] ソフトウェアスタック: [AUTOSAR / ベアメタル] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation こんにちは、 Fls_Erase()操作の実行中に電源が切断された場合、データフラッシュの破損が発生する可能性はありますか？ はい、それは正しい行動です。フラッシュメモリ内のデータは、プログラミング／消去処理中の電源喪失により、フラッシュメモリ内のECC症候群と一致しなくなります。 このような中断後に部分的に消去・破損したフラッシュセクターにアクセスする際にECCエラーが起こることは予想されますか? はい。 破損したフラッシュセクターを消去・復元するために 、フラッシュECCチェックを一時的に無効 化する仕組みやレジスタはありますか? いいえ。これは恒久的なハードウェア機能です。 電源遮断後に訂正不可能なECCエラーを含むデータフラッシュセクターを処理するための推奨される復旧手順は何ですか？ その場合は破損したフラッシュブロックを初期化(消去)する必要があります。一度実行すると、ECC症候群はフラッシュのデータと一致し、アクセスによってECCの故障が起きません。 フラッシュ消去の手順については、リファレンス・マニュアルをご参照ください: よろしくお願いいたします。 ピーター

i.MX 8M Plus LPDDR4 EVK - 启用 eMMC boot0/boot1 主板：i.MX 8M Plus LPDDR4 EVK (MIMX8ML8DVNLZAA), IMX8MPEVKHUG rev 0 HAB：熔断 OPEN（SRK 未烧毁，故意，仍在评估中） 我正在为基于 RAUC 的 A/B 更新系统实现启动加载程序更新冗余，并希望像许多 i.MX8M 设计那样使用 eMMC 的硬件 启动0/启动1 分区（BOOT_PARTITION_ENABLE）——将新的启动加载程序写入非活动启动分区，切换哪个分区处于活动状态，并依靠 ROM 在新激活的分区发生故障时回退到另一个分区。我特别想避免为此烧毁任何 BOOT_CFG/efuse。 我在 EVK 上使用基于 poky/oe-core mmc-utils 配方构建的 mmc-utils 时观察到以下情况： - mmc extcsd 读取 /dev/mmcblk2 报告 PARTITION_CONFIG 中 BOOT_PARTITION_ENABLE 已设置为 boot0（值为 0x08）。 - boot0 (/dev/mmcblk2boot0) 包含一个看起来有效的映像（偏移量 0 处有正确的 IVT 标签），但它与我当前部署的引导加载程序不匹配。 - boot1 (/dev/mmcblk2boot1) 完全为空（全部为零）。 - 逐字节比较证实，该板实际上是从标准的 32 KiB 偏移处的原始 eMMC 用户区启动（内容与我当前部署的 imx-boot 完全匹配）——而不是从 boot0 启动，尽管 PARTITION_CONFIG 指示 boot0 已启用。 因此，在这个板上，EXT_CSD 的 BOOT_PARTITION_ENABLE 似乎对 ROM 的实际启动源没有影响。根据 IMX8MPEVKHUG 第 2.2 节，EVK 的 SW4 开关仅用于选择粗略的启动设备类别（eMMC vs SD vs QSPI vs NAND vs 熔丝 vs USB 串行下载）——没有用于 eMMC 启动分区子模式的开关位置。 问题： 1. 在LPDDR4 EVK上，是否有支持的方法可以选择“ROM从eMMC boot0/boot1硬件分区启动”，而无需设置BT_FUSE_SEL=1或烧录BOOT_CFG熔丝？例如，是否可以通过跳线、电阻或IMX8MPEVKHUG rev 0中未记录的SW4/SW1101组合来实现？或者，该板的PCB是否已硬性规定始终从eMMC用户区启动，而不管EXT_CSD状态如何？ 2. 如果 BOOT_CFG 熔丝是启用 eMMC 启动分区模式的唯一方法：控制此模式的 BOOT_CFG 熔丝组是否独立于用于 HAB 的 SRK 哈希熔丝？我想了解通过熔丝启用 eMMC 启动分区冗余是否会迫使我同时关闭 HAB（SRK 烧录），或者这些是否是可分离的决定。 3. 对于使用 i.MX 8M Plus 和 eMMC 的定制板设计（非 EVK），推荐的方法是如何在首次启动时就使 eMMC boot0/boot1 冗余可用？也就是说，BOOT_CFG GPIO 跳线/PCB 设计中需要满足哪些条件，才能使其成为第一天就能使用的功能，而不是需要稍后进行熔丝位绑定？ 如果能提供一些关于 eMMC 启动分区选择的 BOOT_CFG 位定义的具体参考手册章节的链接（除了 IMX8MPEVKHUG 中已经涵盖的 SW4 设备类位之外），我们将不胜感激。 谢谢！ Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 供参考，请参阅 i.Mx8 UM 第 5.8.2.2.1 节“高级 eMMC 启动流程”。 SCU ROM 支持 4 种 eMMC 启动方案： 1.在这种情况下，“eMMC 快速启动”熔丝被烧断。小学和中学 镜像容器集均位于启动分区中，且 BOOT_PARTITION_ENABLE = 1 或 2。 2. 在这种情况下，“eMMC 快速启动”熔丝烧断了。小学和中学 镜像容器集均位于用户区域，且 BOOT_PARTITION_ENABLE =7。 3.在这种情况下，“eMMC 快速启动”熔丝没有熔断。启动模式为正常模式 启动、主镜像容器集和辅助镜像容器集都在用户区域。 4. 在这种情况下，“eMMC 快速启动”熔丝没有熔断。启动模式为正常模式 启动时，主镜像容器集和辅助镜像容器集都在启动过程中。 分区，并且 BOOT_PARTITION_ENABLE = 1 或 2。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 谢谢你的指点——不过我认为第 5.8.2.2.1 章描述的是不同的芯片系列。“SCU ROM” eMMC 启动流程是 i.MX8QuadMax/QuadXPlus/DualXPlus 特有的，它们具有专用的系统控制器单元（独立的 Cortex-M4 启动子系统）。i.MX8M Plus 没有 SCU – 其启动 ROM 直接在 Cortex-A53 上运行 – 因此该章节中的 BOOT_PARTITION_ENABLE=1/2/7 场景不适用于这里。 对于 i.MX8M Plus，冗余似乎是通过 i.MX8M Plus 参考手册中的主/辅助映像机制来处理的（图 6-1）：ROM 从 BT_FUSE_SEL/BOOT_CFG 选择的设备启动，如果失败，则回退到 IMG_CNTN_SET1_OFFSET 熔丝偏移处的辅助映像——在同一引导设备上，而不是单独的 boot0/boot1 分区。这与我在 LPDDR4 EVK 上看到的情况一致：EXT_CSD 中设置了 BOOT_PARTITION_ENABLE=1，但 ROM 忽略了它，仍然从原始用户区偏移量启动。 所以我的问题仍然是，仅限于 i.MX8M Plus： 1. 在 LPDDR4 EVK 上，是否有任何非熔丝方法（跳线、电阻或未记录的 SW1101/SW4 位置）来选择 eMMC boot0/boot1 作为启动源，还是这完全取决于 BOOT_CFG 跳线/BT_FUSE_SEL 的决定？ 2. BOOT_CFG 熔丝组是否独立于 HAB 的 SRK 哈希熔丝，或者通过熔丝提交 BOOT_CFG 是否也会强制关闭 HAB？ 3.对于定制板设计，在布局时需要进行哪些 BOOT_CFG 绑定才能在不进行后续熔丝分配的情况下保持硬件启动分区冗余？ 如果我误解了第 5.8.2.2.1 章实际适用的部分，请指正。

S32K396をベースとしたETPUの例 こんにちは。S32DS3.5で生成されたETPUで使用されるS32K396用のRTD 5.0.0のデモが必要です。燃料噴射機能に使用したいと考えています。ソフトウェアパッケージとコード例を提供していただけますでしょうか？ Re: S32K396的ETPU的例子 こんにちは@大概さん リアルタイム・ドライバ内にETPUおよびS32K396の既存例があります: さらに、S32K3 - eTPU SWパッケージの中には様々な例も見つかります。RTDとは独立しており、どのバージョンでも使用可能ですが、eTPUのSWは特定のRTD 7.0.0でのみ検証されていますバージョンや他のバージョンとの互換性は保証できません。 よろしくお願いします、 ジュリアン

中断在内存中运行，闪存擦除 我发现擦除闪存时无法进入定时器中断。为了满足我的需求，我计划在 RAM 中运行定时器中断。我修改了 linker_flash_s32k388.ld 文件，将 IntCtrl_Ip.o 和 Pit_Ip.o 放入 RAM 中，但是当我擦除闪存时，由于定时器中断的到来，我仍然会遇到错误。请告诉我我遗漏了哪些细节。#s32k388 Re: Pit interrupt runs in ram wen flash erase 你好， 只需放置 IntCtrl_Ip.o 和 Pit_Ip.o仅仅存入内存通常是不够的。在 PFLASH 擦除操作期间，CPU 必须避免对受影响的闪存阵列进行任何访问。 请确认中断向量表、PIT ISR、ISR 调用的所有函数以及 ISR 使用的任何数据/常量也位于 SRAM 中。此外，确保 VTOR 寄存器指向基于 RAM 的向量表。链接器映射文件通常是识别剩余闪存访问的最佳方法。 S32K3 参考手册还指出，当闪存操作需要持续执行时，代码执行必须移至 SRAM。 顺祝商祺！ Peter Re: Pit interrupt runs in ram wen flash erase 我的中断服务例程 (ISR) 和 ISR 调用的函数都已放置在 RAM 中，VTOR 的地址也是 0x2...而不是 0x4...我的闪存驱动程序在 RTD 配置期间选择在 RAM 中运行。只要 PIT 关闭，程序就能正常运行；但启用 PIT 后就会卡死，但我无法通过调试找到问题所在。

Pit interrupt runs in ram wen flash erase I found that I cannot enter the timer interrupt while erasing flash. To meet my requirements, I plan to run the timer interrupt in RAM. I modified the linker_flash_s32k388.ld file to place IntCtrl_Ip.o and Pit_Ip.o in RAM, but when I erase flash, I still encounter errors due to the arrival of the timer interrupt. Please tell me what details I have overlooked.#s32k388 Re: Pit interrupt runs in ram wen flash erase Hello, Simply placing IntCtrl_Ip.o and Pit_Ip.o into RAM is usually not enough. During a PFLASH erase operation, the CPU must avoid any access to the affected flash array. Please verify that the interrupt vector table, the PIT ISR, all functions called by the ISR, and any data/constants used by the ISR are also located in SRAM. Additionally, ensure that the VTOR register points to a RAM-based vector table. A linker map file is typically the best way to identify remaining flash accesses. The S32K3 Reference Manual also notes that code execution must be moved to SRAM when flash operations require continued execution. Best regards, Peter Re: Pit interrupt runs in ram wen flash erase My ISR and the functions called by ISR have been placed in RAM, and the address of VTOR is also 0x2... rather than 0x4... My flash driver chose to run in RAM during configuration in RTD. It runs normally as long as the PIT is closed, but it freezes when the PIT is enabled, but I cannot trace where the problem is through debugging

How to use LPI2C peripheral with DMA without enabling any interrupts? Hello, I am working with an NXP S32K396 MCU and would like to perform an LPI2C master transaction using eDMA without enabling any interrupts. In my project, I am using the LPI2C1 peripheral. I can successfully perform LPI2C read and write transactions using DMA when the following interrupts are enabled: LPI2C1_IRQn eDMA0_DMATTCD_CH16_CH17_IRQn However, it appears that the RTD LPI2C DMA implementation depends on these interrupts. In Lpi2c_Ip_MasterSendData(), the LPI2C master interrupts are always enabled by the driver: In addition, the DMA TCDs configured for TX and RX by Lpi2c_Ip_MasterTxDmaConfig() and Lpi2c_Ip_MasterRxDmaConfig() always enable the DMA major-loop completion interrupt: Lpi2c_DmaTransferList[9u].Param = DMA_IP_CH_SET_CONTROL_EN_MAJOR_INTERRUPT; Lpi2c_DmaTransferList[9u].Value = 1U; I also noticed that in other function - Lpi2c_Ip_MasterSendDataBlocking() does not appear to configure a DMA TCD for the LPI2C transfer. I would like to perform the complete LPI2C transmit and receive transaction using DMA while keeping LPI2C1_IRQn disabled and the eDMA channel interrupt disabled.   If possible, could NXP provide an example for LPI2C master TX/RX using DMA with both LPI2C and DMA interrupts disabled?   MCU: NXPS32K396 RTD: 6.0.0 NXP Studio: 3.6.1   Any help would be greatly appreciated. Thanks a lot in advance! If needed, I can attach my project. Re: How to use LPI2C peripheral with DMA without enabling any interrupts? Hi@rkhw From the current driver implementation, the “Lpi2c_Ip_MasterSendData()” depend on both LPI2C master interrupts and DMA major-loop completion interrupts for transfer completion and state handling. Therefore, you cannot enable DMA without enabling interrupts. The RTD driver does not support this usage.

S32 Design Studio for ARM v2.2许可延期 您好，S32 Design Studio for ARM v2.2提示许可马上到期，Activation Code：FAF2-FCC2-8A8E-87AC，麻烦延期，谢谢！

FRDM i.MX93におけるAP1302 MIPI CSIストリーミングの問題 こんにちは、 私はFRDM i.MX93ボードとX-RPI-CAM-MIPI A1カメラモジュールを使用しています。 私が直面している問題は、この設定からMIPI CSIストリームをキャプチャできないことです。 ファームウェアバイナリap1302_60fps_ar0144_27M_2Lane_awb_tuning.binを次の場所に配置しました: "/lib/firmware" 起動時にAP1302が正常に検出されていることは確認できますが、ビデオストリーミングを開始しようとすると、 VIDIOC_STREAMONが 「パイプが壊れています」という エラー で失敗します 。 以下に、関連するログを示します。 カーネルログ: root@imx93evk:~# dmesg | grep ap1302 [ 0.340980] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.371014] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c ... [ 10.088832] ap1302 2-003c: AP1302 revision 0.2.6 detected ストリーミングテスト: root@imx93evk:~# v4l2-ctl -d /dev/video0 \ --verbose \ --stream-mmap=3 \ --stream-count=10 VIDIOC_QUERYCAP: ok VIDIOC_REQBUFS returned 0 (Success) VIDIOC_CREATE_BUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_G_FMT returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned -1 (Broken pipe) なぜ VIDIOC_STREAMON が「 Broken pipe(パイプ破損) 」エラー で故障しているのか 、教えていただけません か? ストリーミングを正常に開始する前に、AP1302のファームウェア、デバイスツリー、メディアパイプライン、またはセンサの初期化に追加の設定が必要ですか? さらに、現時点では「LF_v6.18.2-1.0.0_images_IMX93EVK」というプリビルドイメージを使用しています。 追加のログや情報が必要な場合はお知らせください。 再開まで今しばらくお待ちください。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 AEチームと話し合っています。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 こんにちは@yipingwang ご返信ありがとうございます。 参考までに、私の回答を以下に記載します。 1. ファームウェアの場所 推奨されているファームウェアのインストール場所と、それぞれの場所を個別に試してみました。カメラプローブは、 ap1302_ar0144_single_fw.binを使用した場合にのみ成功します。 root@imx93evk:~# ls -la /lib/firmware/ap1302_ar0144_single_fw.bin -rw-r--r-- 1 root root 80528 Aug 5 15:36 /lib/firmware/ap1302_ar0144_single_fw.bin root@imx93evk:~# ls -la /lib/firmware/imx/camera/ap1302.fw -rw-r--r-- 1 root root 80528 Aug 5 15:38 /lib/firmware/imx/camera/ap1302.fw AP1302は起動時に正常に検出されました。 root@imx93evk:~# dmesg | grep -i ap1302 ... [ 9.962705] ap1302 2-003c: AP1302 revision 0.2.6 detected しかし、カーネルログにはAP1302に関連するファームウェアの読み込みメッセージは一切見当たりません。 2. ソフトウェア環境 私はFRDM i.MX93ボード用に提供されているプリビルドイメージを使用しています。 root@imx93evk:~# cat /proc/device-tree/model NXP FRDM-IMX93 root@imx93evk:~# cat /proc/cmdline console=ttyLP0,115200 earlycon root=/dev/mmcblk0p2 rootwait rw AP1302は正常に検出され、CSI/ISIデバイスも存在しています。参考までに、ログ全体を添付しました。 3. メディアパイプライン メディアパイプラインは正しく作成されているようです。 root@imx93evk:~# ls /dev/media0 /dev/media0 root@imx93evk:~# ls /dev/video* /dev/video0 /dev/video1 media-ctlの出力はAP1302、CSI、ISIエンティティが有効であることを示しています。参照のために、完全なmedia-ctl出力を添付します。 4. 追加情報 ご依頼いただいた情報については、添付ファイルfourth_point.txtをご参照ください。 5. ストリーミングの失敗 ストリーミングコマンドが失敗した際に、カーネルから追加のメッセージは表示されません。 root@imx93evk:~# dmesg -c root@imx93evk:~# v4l2-ctl -d /dev/video0 --stream-mmap=3 --stream-count=10 VIDIOC_STREAMON returned -1 (Broken pipe) root@imx93evk:~# dmesg 障害後もdmesg出力は空のままなので、根本原因を特定するための追加のカーネルログはありません。 AP1302が正常に検出され、メディアグラフも正しく作成され、VIDIOC_STREAMON中にカーネルエラーも報告されていないので、「 Broken pipe」 エラーでストリーミングが失敗する原因を特定するために、どのような追加のチェックやデバッグステップを教えていただけますか? 再開まで今しばらくお待ちください。 root@imx93evk:~# v4l2-ctl --list-devices mxc-isi-cap (platform:4ae40000.isi): /dev/video0 /dev/video1 /dev/media0 root@imx93evk:~# v4l2-ctl -d /dev/video0 --all Driver Info: Driver name : mxc-isi Card type : mxc-isi-cap Bus info : platform:4ae40000.isi Driver version : 6.18.2 Capabilities : 0xa4201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Device Capabilities Device Caps : 0x24201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Media Driver Info: Driver name : mxc-isi Model : FSL Capture Media Device Serial : Bus info : platform:4ae40000.isi Media version : 6.18.2 Hardware revision: 0x00000000 (0) Driver version : 6.18.2 Interface Info: ID : 0x0300000a Type : V4L Video Entity Info: ID : 0x00000008 (8) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000009 : 0: Sink Link 0x0200000c: from remote pad 0x1000007 of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled, Immutable Priority: 2 Video input : 0 (mxc_isi.0.capture: ok) Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : sRGB YCbCr/HSV Encoding: ITU-R 601 Quantization : Limited Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 flags=0x00001000 vertical_flip 0x00980915 (bool) : default=0 value=0 flags=0x00001000 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 flags=0x00001000 root@imx93evk:~# media-ctl -p Media controller API version 6.18.2 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ae40000.isi hw revision 0x0 driver version 6.18.2 Device topology - entity 1: crossbar (3 pads, 3 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 0/0 -> 2/0 [ACTIVE] pad0: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "csidev-4ae00000.csi":1 [ENABLED,IMMUTABLE] pad1: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad2: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] - entity 5: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":2 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 8: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 16: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":1 [ENABLED,IMMUTABLE] - entity 23: csidev-4ae00000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "ap1302 2-003c":2 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":0 [ENABLED,IMMUTABLE] - entity 28: ap1302 2-003c (3 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] <- "ar0144 0":0 [ENABLED,IMMUTABLE] pad1: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] pad2: SOURCE [stream:0 fmt:UYYVYY8_0_5X24/4224x4092 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] -> "csidev-4ae00000.csi":0 [ENABLED] - entity 32: ar0144 0 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: SOURCE [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb] -> "ap1302 2-003c":0 [ENABLED,IMMUTABLE] よろしくお願いします、 ミラフ Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 AP1302プローブが成功したとしても、カメラパイプライン全体が構成され、ストリーミングが開始されることを保証するものではありません。i.MX93では、VIDIOC_STREAMONが-1(破損パイプ)を返すと、通常、メディアパイプラインのコンポーネント(AP1302→MIPI、CSI-2レシーバ、→ISIキャプチャパス)が有効なストリームを開始または交渉できなかったことを意味します。ログには、AP1302 I²Cデバイスが検出されたという情報しか記録されていません。 ap1302 2-003c: AP1302 リビジョン 0.2.6 が検出されました しかし、それは以下のことを確認するものではありません。 ファームウェアのロードに成功しました。 正しいDTBが使用されました。 メディアグラフが作成されました。 CSIレシーバは受信するMIPIデータにロックされています。 AP1302は、対応する出力フォーマットで設定されています。 まず最初に確認すべきことは、ファームウェアの場所と名前です。 FRDM-i.MX93 AP1302のサポートについては、NXPのドキュメントには以下が記載されています: ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin をダウンロードしてください。 名前をap1302.fwに変更してください。 配置場所： /lib/firmware/imx/camera/ap1302.fw 単に /lib/firmware ではない。 ご確認ください： ls -l /lib/ファームウェア/imx/カメラ/ap1302.fw そしてブートログを確認してください。 dmesg | grep -i firmware dmesg | grep -i ap1302 次のようなメッセージを探してください。 ファームウェアを要求する ファームウェアがロードされました ファームウェアの読み込みに失敗しました 2つ目の確認事項：正しいDTBを使用していますか？ リリースノートによると、AP1302のサポートはi.MX93 EVKデバイスツリーのサポートと関連しています。 確認： cat /proc/device-tree/model cat /proc/cmdline そして、実際にロードされるDTBを特定します。 こちらもご確認ください： dmesg | grep -i ap1302 dmesg | grep -i csi dmesg | grep -i isi 三つ目のチェック:メディアトポロジーの検証 v4l2-ctlを試す前に、メディアグラフが存在するか確認してください: シェル media-ctl -p もっと行を表示 以下のようなエンティティが表示されるはずです。 ap1302 CSI イシ ビデオX /dev/media0が存在しない場合、カメラパイプラインが正しく作成されていません。非常に似たFRDM-i.MX93 AP1302 CASEは以下の通りでした: media-ctl -p /dev/media0 の列挙に失敗しました これはメディアパイプラインがインスタンス化されていないことを示していました。 チェックしてください： ls -l /dev/media* 4つ目の確認事項：交渉済みのフォーマットを検査する 次を実行します。 v4l2-ctl --list-devices そして、 v4l2-ctl -d /dev/video0 --all また： media-ctl -p AP1302のファームウェアは通常、RAWベイヤーではなく、処理済みのYUVフォーマットを出力します。もう一つよくある失敗例は次のとおりです。 AP1302はフォーマットAを出力する ISIはフォーマットB用に構成されています ストリームの起動失敗を引き起こしています。フォーマットの不一致は、STREAMONの失敗やCSIパイプラインのエラーとして現れることが多い。 5回目のチェック：STREAMON実行中のCSIエラーを検査する 別のターミナルを開いて監視します。 dmesg -w そして、以下を実行します。 v4l2-ctl -d /dev/video0 \ --stream-mmap=3 \ --stream-count=10 次のようなメッセージを探してください。 CSIタイムアウト フレーム開始タイムアウト データを受信しませんでした FIFOオーバーフロー MIPIエラー リンクが有効になっていません これらのメッセージは通常、配管破損の本当の原因を明らかにします。

S32 Design Studio for ARM v2.2 许可延期 您好，S32 Design Studio for ARM v2.2提示立即授权，激活码：FAF2-FCC2-8A8E-87AC，麻烦延期，谢谢！

AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 Hello, I am using an FRDM i.MX93 board with the X-RPI-CAM-MIPI A1 camera module. The issue I am facing is that I am unable to capture the MIPI CSI stream from this setup. I have placed the firmware binary ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin in the following location: "/lib/firmware" During boot, I see that the AP1302 is detected successfully, but when I attempt to start video streaming, VIDIOC_STREAMON fails with a "Broken pipe" error. Below are the relevant logs. Kernel log: root@imx93evk:~# dmesg | grep ap1302 [ 0.340980] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.371014] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c ... [ 10.088832] ap1302 2-003c: AP1302 revision 0.2.6 detected Streaming test: root@imx93evk:~# v4l2-ctl -d /dev/video0 \ --verbose \ --stream-mmap=3 \ --stream-count=10 VIDIOC_QUERYCAP: ok VIDIOC_REQBUFS returned 0 (Success) VIDIOC_CREATE_BUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_G_FMT returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned -1 (Broken pipe) Could you please help me understand why VIDIOC_STREAMON is failing with a "Broken pipe" error? Is there any additional configuration required for the AP1302 firmware, device tree, media pipeline, or sensor initialization before streaming can start successfully? Furthermore, i am using "LF_v6.18.2-1.0.0_images_IMX93EVK" pre-built images for now. Please let me know if you need any additional logs or information. Thank you for your support. Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 Discussing with the AE team. Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 Hello @yipingwang  Thank you for your response. Please find my answers below for your reference. 1. Firmware Location I tried both the recommended firmware locations as well as each location individually. The camera probe is successful only when using ap1302_ar0144_single_fw.bin. root@imx93evk:~# ls -la /lib/firmware/ap1302_ar0144_single_fw.bin -rw-r--r-- 1 root root 80528 Aug 5 15:36 /lib/firmware/ap1302_ar0144_single_fw.bin root@imx93evk:~# ls -la /lib/firmware/imx/camera/ap1302.fw -rw-r--r-- 1 root root 80528 Aug 5 15:38 /lib/firmware/imx/camera/ap1302.fw The AP1302 is detected successfully during boot. root@imx93evk:~# dmesg | grep -i ap1302 ... [ 9.962705] ap1302 2-003c: AP1302 revision 0.2.6 detected However, I do not see any firmware loading messages related to AP1302 in the kernel log. 2. Software Environment I am using the pre-built images provided for the FRDM i.MX93 board. root@imx93evk:~# cat /proc/device-tree/model NXP FRDM-IMX93 root@imx93evk:~# cat /proc/cmdline console=ttyLP0,115200 earlycon root=/dev/mmcblk0p2 rootwait rw The AP1302 is detected successfully, and the CSI/ISI devices are also present. I have attached the complete logs for your reference. 3. Media Pipeline The media pipeline appears to be created correctly. root@imx93evk:~# ls /dev/media0 /dev/media0 root@imx93evk:~# ls /dev/video* /dev/video0 /dev/video1 The outputs from media-ctl show that the AP1302, CSI, and ISI entities are enabled. The complete media-ctl output is attached for your reference. 4. Additional Information Please refer to the attached file fourth_point.txt for the requested information. 5. Streaming Failure I do not see any additional kernel messages when the streaming command fails. root@imx93evk:~# dmesg -c root@imx93evk:~# v4l2-ctl -d /dev/video0 --stream-mmap=3 --stream-count=10 VIDIOC_STREAMON returned -1 (Broken pipe) root@imx93evk:~# dmesg The dmesg output remains empty after the failure, so there are no additional kernel logs to help identify the root cause. Since the AP1302 is detected successfully, the media graph is created correctly, and no kernel errors are reported during VIDIOC_STREAMON, could you please suggest what additional checks or debugging steps I should perform to identify why streaming fails with a "Broken pipe" error? Thank you for your support. root@imx93evk:~# v4l2-ctl --list-devices mxc-isi-cap (platform:4ae40000.isi): /dev/video0 /dev/video1 /dev/media0 root@imx93evk:~# v4l2-ctl -d /dev/video0 --all Driver Info: Driver name : mxc-isi Card type : mxc-isi-cap Bus info : platform:4ae40000.isi Driver version : 6.18.2 Capabilities : 0xa4201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Device Capabilities Device Caps : 0x24201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Media Driver Info: Driver name : mxc-isi Model : FSL Capture Media Device Serial : Bus info : platform:4ae40000.isi Media version : 6.18.2 Hardware revision: 0x00000000 (0) Driver version : 6.18.2 Interface Info: ID : 0x0300000a Type : V4L Video Entity Info: ID : 0x00000008 (8) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000009 : 0: Sink Link 0x0200000c: from remote pad 0x1000007 of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled, Immutable Priority: 2 Video input : 0 (mxc_isi.0.capture: ok) Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : sRGB YCbCr/HSV Encoding: ITU-R 601 Quantization : Limited Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 flags=0x00001000 vertical_flip 0x00980915 (bool) : default=0 value=0 flags=0x00001000 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 flags=0x00001000 root@imx93evk:~# media-ctl -p Media controller API version 6.18.2 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ae40000.isi hw revision 0x0 driver version 6.18.2 Device topology - entity 1: crossbar (3 pads, 3 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 0/0 -> 2/0 [ACTIVE] pad0: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "csidev-4ae00000.csi":1 [ENABLED,IMMUTABLE] pad1: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad2: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] - entity 5: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":2 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 8: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 16: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":1 [ENABLED,IMMUTABLE] - entity 23: csidev-4ae00000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "ap1302 2-003c":2 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":0 [ENABLED,IMMUTABLE] - entity 28: ap1302 2-003c (3 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] <- "ar0144 0":0 [ENABLED,IMMUTABLE] pad1: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] pad2: SOURCE [stream:0 fmt:UYYVYY8_0_5X24/4224x4092 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] -> "csidev-4ae00000.csi":0 [ENABLED] - entity 32: ar0144 0 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: SOURCE [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb] -> "ap1302 2-003c":0 [ENABLED,IMMUTABLE] Best regards, Milav Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 the AP1302 probe succeeding does not guarantee that the complete camera pipeline is configured and streaming. On i.MX93, a VIDIOC_STREAMON returned -1 (Broken pipe) typically means that one of the media pipeline components (AP1302 → MIPI CSI-2 receiver → ISI capture path) failed to start or negotiate a valid stream. Your log only confirms that the AP1302 I²C device was detected: ap1302 2-003c: AP1302 revision 0.2.6 detected but it does not confirm that: the firmware was loaded successfully, the correct DTB was used, the media graph was created, the CSI receiver is locked to incoming MIPI data, the AP1302 has been configured with a matching output format. First thing I would check: firmware location/name For the FRDM-i.MX93 AP1302 support, NXP documentation indicates: Download ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin Rename it to ap1302.fw Place it in: /lib/firmware/imx/camera/ap1302.fw not simply /lib/firmware. Please verify: ls -l /lib/firmware/imx/camera/ap1302.fw and check boot log: dmesg | grep -i firmware dmesg | grep -i ap1302 Look for messages such as: request firmware firmware loaded failed to load firmware Second check: are you using the correct DTB? The release notes indicate AP1302 support is associated with the i.MX93 EVK device tree support. Check: cat /proc/device-tree/model cat /proc/cmdline and determine the actual DTB being loaded. Also check: dmesg | grep -i ap1302 dmesg | grep -i csi dmesg | grep -i isi Third check: verify media topology Before trying v4l2-ctl, verify that the media graph exists: Shell media-ctl -p Show more lines You should see entities similar to: ap1302 csi isi videoX If /dev/media0 does not exist, the camera pipeline is not being created correctly. A very similar FRDM-i.MX93 AP1302 case showed: media-ctl -p Failed to enumerate /dev/media0 which indicated the media pipeline was not instantiated. Please check: ls -l /dev/media* Fourth check: inspect the negotiated formats Run: v4l2-ctl --list-devices and v4l2-ctl -d /dev/video0 --all also: media-ctl -p The AP1302 firmware normally outputs processed YUV formats rather than RAW Bayer. Another common failure is: AP1302 outputs format A ISI configured for format B causing stream startup failure. A format mismatch often surfaces as STREAMON failure or CSI pipeline errors. Fifth check: inspect CSI errors during STREAMON Open another terminal and monitor: dmesg -w then run: v4l2-ctl -d /dev/video0 \ --stream-mmap=3 \ --stream-count=10 Look for messages such as: CSI timeout frame start timeout no data received FIFO overflow MIPI error link not enabled These messages usually reveal the real reason behind the Broken pipe.