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エラー リンクが有効になっていません これらのメッセージは通常、配管破損の本当の原因を明らかにします。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 キャプチャを開始する前に、以下のコマンドを使用してパイプラインを設定する必要があります。 $ media-ctl -l "'ap1302 2-003c':2 -> 'csidev-4ae00000.csi':0 [1]" $ media-ctl -V "'ap1302 2-003c':0 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'ap1302 2-003c':2 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'ar0144 0':0 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'csidev-4ae00000.csi':1 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'crossbar':2 [fmt: UYVY8_1X16/1280x800 field:none]"

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. Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 It's required to set up the pipeline using the following commands before capturing. $ media-ctl -l "'ap1302 2-003c':2 -> 'csidev-4ae00000.csi':0 [1]" $ media-ctl -V "'ap1302 2-003c':0 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'ap1302 2-003c':2 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'ar0144 0':0 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'csidev-4ae00000.csi':1 [fmt: UYVY8_1X16/1280x800 field:none]" $ media-ctl -V "'crossbar':2 [fmt: UYVY8_1X16/1280x800 field:none]"

HMAC検証ジョブのリクエスト時にHSEが「HSE_SRV_RSP_INVALID_PARAM」を返す NXPチームの皆様、こんにちは。 HMACのVerifyジョブを使うユースケースがあります。ジョブ暗号ドライバーをトリガーした後、DETを投げると、HSEからの返答は「HSE_SRV_RSP_INVALID_PARAM」でした。 現在の設定のどこが間違っているのか理解できません。添付されたconfig zipファイルを確認していただけますか? 問題解決のためのサポートが必要です。 ありがとうございます アディティヤ Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @lukaszadrapa さん。 詳細： デバイス: S32K311 HSE FW: HSE_FW_S32K311_0_2_55_0 RTD: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 ありがとうございます アディティヤ Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @WagdeoA さん。 どのデバイス、どのRTD、どのHSEファームウェアバージョンを使っているか確認していただけますか? よろしくお願いいたします。 ルーカス Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @WagdeoA さん。 設定に問題はありません。 私の環境では問題なく動作しています。しかし、タグの長さ(secondaryInputLength)が一つの問題かもしれません。 これは関数Crypto_Ipw_HmacVerifyで確認できます: lukaszadrapa_0-1784036699903.png リダイレクトが無効になっている場合は、タグの長さをバイト単位ではなくビット単位で指定する必要があります。これこそが問題なのではないですか？ よろしくお願いいたします。 ルーカス Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、ルーカスさん。 返信が遅くなり申し訳ありません。 はい、タグの長さはビット単位で指定します。私の環境でも問題なく動作します。 ありがとう！ よろしくお願いします、 アディティヤ

SDK 中未实现 IMXRT EDMA 错误 IRQ 处理程序。 您好， SDK 中的 IMXRT EDMA API 似乎能够正确处理“正常情况”中断。然而，似乎没有任何处理错误中断的机制。不仅如此，似乎所有 DMA 都只有一个全局的 DMA_ERROR_IRQHandler。因此，如果您同时使用 DMA0 和 DMA1，当一切正常时，DMA0/DMA1 IRQHandler 将被调用，SDK 可以区分哪个 DMA 收到了正常中断。但是，如果出现 DMA 错误，由于只有一个全局错误中断处理程序，因此没有简单的方法可以知道错误发生在哪个 DMA（0 或 1 或其他）上。 就像我之前关于 LPUART 错误 IRQ 处理的问题一样。为什么 SDK 没有内置处理 DMA 错误并调用相应回调的功能？现在我必须手动确定错误发生在哪个 DMA 上，并在 SDK 之外调用特殊处理，而不是让它为我调用回调。 对于一个本应在生产代码中使用的 SDK 来说，似乎缺少很多健壮性功能，我敢打赌大多数人只是假设这些错误是由 SDK 在底层处理的，而没有考虑到它们实际上并没有被处理。 -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 您使用的是哪款 i.MX RT 设备？当您提到 DMA0 和 DMA1 时，您指的是两个 DMA 通道，还是两个 DMA 控制器外设？ 并非所有 i.MX RT 设备都具有两个 eDMA 控制器。例如： i.MX RT1180 包含两个 eDMA 控制器。在启动文件（例如 startup_mimxrt1189_cm33.c）中，您可以找到两个 DMA 错误处理程序：DMA_ERROR_IRQHandler 和 DMA4_ERROR_IRQHandler。 i.MX RT1050 仅包含一个 eDMA 控制器。在启动文件（例如 startup_mimxrt1052.c）中，只有一个 DMA 错误处理程序：DMA_ERROR_IRQHandler。 一般来说，DMA 错误是相对不常发生的事件。从硬件架构的角度来看，通道错误状态被聚合为模块级错误请求，从而触发 DMA 错误中断。因此，该软件必须检查每个通道的错误状态寄存器（例如，CHn_ES），以确定哪个特定通道导致了错误。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 抱歉，我指的是频道。我使用的是 IMXRT1172。 如果与之连接的外设出现问题，难道不会发生DMA错误吗？也就是说，如果是 LPSPI 和 DMA，那么任何 SPI 错误都会导致 DMA 错误吗？如果不是，那么在使用DMA时，SPI错误是否会触发SPI错误中断？ 谢谢！ -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 不。在使用DMA时发生的外围设备错误并不一定意味着DMA控制器本身会报告错误。大多数情况下，SPI 错误和 DMA 错误由两个独立的状态和中断机制处理。 DMA 只报告 DMA 层、总线层或传输层错误。LPSPI 中的协议级或 FIFO 相关错误应通过 LPSPI 外设自身的状态标志和错误中断来处理。以 DMA 模式运行并不会自动将所有 SPI 错误转换为 DMA 错误。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 我猜也是这样。在这种情况下，SDK 的传输 API 就更不可靠了。必须在 SDK 之外处理外围设备和 DMA 错误，这需要相当多的额外工作，包括对默认 IRQ 处理程序进行一些变通的覆盖，并确保它们在处理任何错误后仍然调用 SDK 处理程序。令人沮丧的是，这些内容并未包含在 SDK 传输 API 中。 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 我理解您的担忧，我也同意将外围错误状态的处理与 SDK 传输 API 分开处理可能会增加所需的应用程序级代码量。感谢您的反馈。我会将您的意见转达给SDK团队。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 实际上，情况比我想象的还要糟糕。使用 EDMA LPSPI 传输 API 无法捕获 SPI 错误，因为 LPSPI_MasterTransferEDMA 调用的函数LPSPI_PrepareTransferEDMA会禁用所有 SPI 中断。因此，在调用它之前不可能启用错误中断，因为它会再次禁用它们，而之后就太晚了，因为 SPI EDMA 传输已经开始了。这是该API的一个重大漏洞。 -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 是的，这正是我目前不得不采取的权宜之计。然而，编辑 SDK 文件并不是一个好的解决方案，因为不幸的是，它们可能会随着 SDK 的更新而改变。 谢谢！ -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 谢谢你指出这一点。 我检查了LPSPI_PrepareTransferEDMA(LPSPI_Type *base) 的实现，发现它调用了LPSPI_DisableInterrupts(base, (uint32_t)kLPSPI_AllInterruptEnable)： ShellyZhang_0-1784514572337.png 作为一种变通方法，您可以考虑修改驱动程序的这一部分，使其不禁用发送错误中断和接收错误中断。换句话说，不要禁用 kLPSPI_AllInterruptEnable ，而只需禁用 EDMA 传输操作所需的中断，同时保持错误中断启用即可。 您可以尝试移除LPSPI_IER_TEIE_MASK 和 LPSPI_IER_REIE_MASK。 ShellyZhang_1-1784514923801.png

新規プロジェクトウィザード失敗: FreeRTOSポートが自動的に追加されませんでした 皆さん、こんにちは。 MCUXpresso IDE V24.12を使って、LPC5536向けのfreeRTOSベースのプロジェクトを作ろうとしています。 「Create a new C/C++ project」ウィザード(Quickstart Panelから利用可能)は、プロジェクトにfreeRTOSのサポートを追加する簡単な方法を提供しているようです(下記スクリーンショットのマークアップ参照)。 danielholala_0-1750771156912.png ご覧の通り、「新しいプロジェクトウィザード」にはfreeRTOSを「オペレーティングシステム」として追加するチェックボックスがあります。このボックスにチェックを入れると、ウィザードは自動的にfreeRTOSのもう一つの重要な部分であるメモリマネージャーを追加します(下記のチェックボックス参照)。 danielholala_1-1750771498221.png しかし、ウィザードはfreeRTOSで最も重要な部分であるMCU固有のコード(下のスクリーンショットのマークアップ参照)を追加していません。 danielholala_2-1750771652430.png このコンポーネントを自分で選択しない場合、生成されたプロジェクトでコンパイルエラーが発生します。新規プロジェクトウィザードは常にコンパイル可能なプロジェクトを生成するべきだと私は考えています。さらに、MCUXpresso IDEのマニュアルには明確に「また、コンポーネントを選択すると依存関係も自動的に選択される」と明記されています。(セクション 5.1.1)SDK New Project Wilzard)。 私の意見では、これはバグ、少なくともユーザーエクスペリエンス上のバグです。 次のSDKやMCUXpressoのバージョンでこの問題が修正されることを期待しています。 ありがとう。 ダニエル Re: New Project Wizard fAiL: no freeRTOS port added automatically MCUXpresso IDE v25.6(執筆時点での現行)とSDK for LPC5536(バージョン25.06、manifest 3.15)で試しましたが、FreeRTOSカーネルとcm33ポート間の依存関係 がまだ存在せず 、手動で選択する必要があります。 Re: New Project Wizard fAiL: no freeRTOS port added automatically こんにちは、 @EdwinHz さん。 迅速なサポートに感謝します。 ありがとう。 ダニエル Re: New Project Wizard fAiL: no freeRTOS port added automatically こんにちは、 @danielholala さん、 この問題を再現できました。プロジェクトウィザードはすべての依存関係を自動的に選択するはずなので、これは間違いなくバグです。この問題をIDEチームに報告し、今後のMCUXpressoプロジェクトウィザードのバージョンで修正してもらうつもりです。 この問題を報告していただきありがとうございます。 BR、 エドウィン。

Yocto wrynose 版本“imx-car-navigation”失败 您好， 尝试在最新的 6.18.20-2.0.0 电路板支持包。 上为 FRDM-IMX93 构建“imx-image-full”时失败，失败情况如下： ERROR: imx-car-navigation-1.0-r0 do_compile: Execution of '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/run.do_compile.1753043' failed with exit code 1 ERROR: Logfile of failure stored in: /media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/log.do_compile.1753043 Log data follows: | DEBUG: Executing shell function do_compile | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode'. Retry scheduled | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode' a second time, aborting | WARNING: exit code 1 from a shell command. ERROR: Task (/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb:do_compile) failed with exit code '1' 请注意，这个问题是 100% 可复现的——在这里总是会失败。另请注意，即使 bitbake 正在执行“编译”步骤，存储库的下载也会失败。目前，我认为这可能与不应该在编译步骤中进行下载有关，也许 bitbake 现在将网络功能限制在了下载步骤中？最近有人试过这个配方吗？ Re: Yocto wrynose build failure for 'imx-car-navigation' 看来我的直觉是对的。以下补丁解决了我的问题： --- sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb.ORIG 2026-07-13 16:02:28.733344421 +0200 +++ sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb 2026-07-13 16:02:11.178539144 +0200 @@ -14,6 +14,7 @@ do_configure[noexec] = "1" +do_compile[network] = "1" do_compile() { cd ${S} 但请注意，这只是一个权宜之计。默认情况下不允许这样做是有原因的——编译步骤不应该进行任何网络访问。

Problem with DDRv tool on LS1088A Hi, I am trying to validate a new type of DDR4 SO-DIMM on a custom board based on LS1088A SoC, but I am encountering problems with DDRv. I have already validated several other models of DDR4 in the past, and I did not encounter any problems. The new model of DDR that I am trying to validate is IMM2G72D4SOD8AG-B075I from Memphis. Its speed-grade is 2,666, but we would like to run it at 2,100 MT/s. I have created a new QorQ configuration project and successfully read DDR configuration via SPD. However, the first step (Centering the clock) consistently fails at 0.04%, on the 'Auto search & detect for write leveling start values' part. In the Test Results summary, I see that the test failed with the reason: "DDR interface is failing due to an issue other than WRLVL_START values, please investigate HW issues on the board." In the Logs section, I see the following information: #################### Result for: wrlvl_searcher ###### Run  1 ######################################   Test result: [ ============================================================ Updated: WRLVL_CNTL = 0x86550605, WRLVL_CNTL_2 = 0x00000000, WRLVL_CNTL_3 = 0x00000000, SDRAM_CLK_CNTL = 0x02800000     ============================================================ Updated: WRLVL_CNTL = 0x86550607, WRLVL_CNTL_2 = 0x09060C0F, WRLVL_CNTL_3 = 0x0E110B0E, SDRAM_CLK_CNTL = 0x02800000     ============================================================ Updated: WRLVL_CNTL = 0x86550607, WRLVL_CNTL_2 = 0x09050C0F, WRLVL_CNTL_3 = 0x1611130E, SDRAM_CLK_CNTL = 0x02800000     DDR interface is failing due to an issue other than WRLVL_START values, please investigate HW issues on the board. < > {{DDR interface is failing due to an issue other than WRLVL_START values, please investigate HW issues on the board.}}     Err. capture registers: 0xE20, 0x00000000     0xE24, 0x00000000     0xE28, 0x00000000     0xE40, 0x00000080      0xE44, 0x00000000     0xE48, 0x0000001D     0xE4C, 0x00000000     0xE50, 0x00000000      0xE54, 0x00000000     0xE58, 0x00010000          Dump: 0xF00, 0x00000000     0xF04, 0x00001002     0xF08, 0x0000000A     0xF0C, 0x14000C20      0xF10, 0x00000000     0xF14, 0x00000000     0xF18, 0x00000000     0xF1C, 0x00000000      0xF20, 0x00000000     0xF24, 0x2F003500     0xF28, 0x2A003600     0xF2C, 0x3E004A00      0xF30, 0x44004600     0xF34, 0x3A007000     0xF38, 0x00000000     0xF3C, 0x00000000      0xF40, 0x00000000     0xF44, 0x00000000     0xF48, 0x00000001     0xF4C, 0x94000000      0xF50, 0x0F001300     0xF54, 0x0C001800     0xF58, 0x1F002C00     0xF5C, 0x22002700      0xF60, 0x1C000000     0xF64, 0x00009000     0xF68, 0x00000020     0xF6C, 0x00000000      0xF70, 0x0060007B     0xF74, 0x00000000     0xF78, 0x00000000     0xF7C, 0x00000000      0xF80, 0x00000000     0xF84, 0x00000000     0xF88, 0x00000000     0xF8C, 0x00000000      0xF90, 0x00000000     0xF94, 0x80000000     0xF98, 0x00000000     0xF9C, 0x29002B00      0xFA0, 0x2B002B00     0xFA4, 0x27002D00     0xFA8, 0x28002E00     0xFAC, 0x27000000      0xFB0, 0x10000003     0xFB4, 0x42344241     0xFB8, 0x40334332     0xFBC, 0x43404150      0xFC0, 0x00004133     0xFC4, 0x44424444     0xFC8, 0x44415134     0xFCC, 0x51414251      0xFD0, 0x42414241     0xFD4, 0x50434252     0xFD8, 0x50444342     0xFDC, 0x42413444      0xFE0, 0x43514340     0xFE4, 0x44424444     0xFE8, 0x42514441     0xFEC, 0x40423443      0xFF0, 0x43424342     0xFF4, 0x43415042     0xFF8, 0x51415341     0xFFC, 0x54000D0D            Data:  0x00000005 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000    ]   I have attached the verbose CCS log from the failed validation procedure as well.   Could you please explain what this means and how we can debug the issue? QorIQ LS1 Devices Re: Problem with DDRv tool on LS1088A Compare with new type of DDR4 SO-DIMM, what kind of SODIMM used before? Any change between the new one and the old one Re: Problem with DDRv tool on LS1088A Hello, For your specific dump, the most actionable interpretation is: the controller raised an automatic calibration error ( ACE ) during training, and DDRv’s write-leveling search could not find a valid operating region by adjusting WRLVL_START . That points first to reset/clock/configuration/DQ-map/SI checks, with DDR reset and DQn_MAP high on the list because both are repeatedly tied to this exact DDRv failure class in NXP debug history. So, verify DDR clock/RCW, DDR reset timing, SPD-derived rank/geometry, DQ mapping, and power/SI before tuning margins. Regards

HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi NXP Team, I am currently working on the i.MX95 FRDM EVK board using Zephyr RTOS. On the Linux side, HDMI output is already supported and working correctly. However, I would like to know how to enable and configure HDMI in Zephyr. Could you please guide me on the following? Does Zephyr support HDMI output on the i.MX95 FRDM EVK? If yes, what drivers and Device Tree configurations are required? Is there any reference implementation or sample application available for HDMI on Zephyr? Any guidance or documentation would be greatly appreciated. Thank you. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK I confirmed with the AE team. HDMI is not supported in IMX95 Zephyr currently.  Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi NXP Team, I am looking for the IT6263 Reference Manual or Register Programming Manual. Could you please share the detailed register descriptions (register map with bit-level definitions) for the IT6263 HDMI bridge, or let me know how I can obtain this documentation? Note: I am specifically looking for the chip-level register documentation itself, not the Linux kernel driver source. Thank you, Karthikeyan M Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK IT6263 is not an NXP product, so NXP does not provide a Reference Manual for this device. For configuration and initialization details, you can refer to the IT6263 Linux driver source code. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for your response and for providing the Arm Support links. I will contact Arm Support regarding the Arm Mali-G310 Technical Reference Manual and the CSF/Firmware Interface documentation. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK I have successfully ported HDMI on Zephyr OS, and it is currently running on the CPU. My next goal is to port it to run on the GPU. For this, I need the Arm Mali-G310 Technical Reference Manual, specifically the CSF/Firmware Interface section. Should I request this document from NXP Support, or do I need to contact Arm Support directly? Having access to this reference manual would be very helpful for implementing the GPU port on Zephyr Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please contact Arm Support directly. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for your response. Could you please share the specific contact email or support portal for Arm Support? If you have a direct contact or the appropriate email address, it would be very helpful. I will contact them regarding this issue. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Arm Support Hub: https://support.arm.com/support-cases   Support Inquiries Form: https://www.arm.com/company/contact-us/support-inquiries Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for the links to the Arm portal and the i.MX Graphics User's Guide. We looked at both, but they don't cover what we need. Those guides explain how to use the GPU under Linux, and we are writing our own low-level GPU driver on i.MX95 (bare-metal, using Zephyr, not Linux). So we need lower-level, register-level information than those documents provide. In the ARM portal, we have searched for the TRM, but it is unavailable. Here is our situation in short:   We have got the Mali-G310 GPU working up to a certain point. The GPU is detected correctly, powered on, reset, and we have loaded the GPU firmware into memory successfully. Everything up to this stage works and is verified.   We are stuck at one step: starting the GPU's firmware microcontroller (the MCU). After we enable it, its status stays "disabled" and it never starts running. There is no error and no interrupt - it simply does not boot.   Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi   NXP Team, I contacted Arm support to request the required documentation, and they replied with the following: "Please reach NXP support if you see obstacles developing on their silicon. Again, these documents are NOT supposed to be available for silicon vendor's customers." Based on their response, I am reaching out to NXP for assistance. I have successfully enabled HDMI on Zephyr OS, and it is currently running using the CPU. My next objective is to enable GPU-based rendering. To proceed, I require the Arm Mali-G310 Technical Reference Manual, particularly the CSF/Firmware Interface documentation. As the Mali-G310 GPU is integrated into the NXP i.MX95 platform, could you please advise how I can obtain access to this documentation? If the document cannot be shared, I would appreciate any alternative guidance or references that would help me continue the GPU bring-up on Zephyr. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please check whether the following information would be helpful. If no, I need to contact the AE team. The Arm Mali-G310 Technical Reference Manual is available from Arm’s documentation portal: search Arm Developer / Arm Documentation for “Mali-G310 Technical Reference Manual” or “Mali-G310 TRM” . It may require an Arm account or acceptance of Arm documentation terms, depending on access level. For NXP i.MX95 work, NXP’s public documentation points to the Mali-G310 GPU through the i.MX Graphics User’s Guide , and the FRDM-i.MX95 getting-started page links that guide for GPU usage details. The FRDM-i.MX95 page states that the board has a Mali-G310 GPU and links the i.MX Graphics User’s Guide for more details: https://www.nxp.com/docs/en/user-guide/UG10159.pdf  Start here: Arm documentation portal:https://developer.arm.com/documentation NXP i.MX Graphics User’s Guide:https://www.nxp.com/docs/en/user-guide/UG10159.pdf Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi   NXP Team, I contacted Arm support to request the required documentation, and they replied with the following: "Please reach NXP support if you see obstacles developing on their silicon. Again, these documents are NOT supposed to be available for silicon vendor's customers." Based on their response, I am reaching out to NXP for assistance. I have successfully enabled HDMI on Zephyr OS, and it is currently running using the CPU. My next objective is to enable GPU-based rendering. To proceed, I require the Arm Mali-G310 Technical Reference Manual, particularly the CSF/Firmware Interface documentation. As the Mali-G310 GPU is integrated into the NXP i.MX95 platform, could you please advise how I can obtain access to this documentation? If the document cannot be shared, I would appreciate any alternative guidance or references that would help me continue the GPU bring-up on Zephyr. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please refer to the following update from the AE team. Regarding the Arm Mali-G310 TRM, this document is Arm confidential IP. NXP is not permitted to forward it to end customers, so it is essentially unavailable through NXP channels. A formal request would have to go through Arm directly, which takes a long time and is unlikely to be granted. In addition, the i.MX95 GPU is still in the pre-production stage, so there is no officially validated bare-metal/Zephyr reference at this time. Regarding the MCU staying "disabled" after enable, this step does not require the TRM. The complete boot flow is available in the following two public sources, both accessible directly on GitHub: Panthor — mainline driver, the main one to look at (it actually boots the MCU and supports i.MX95): https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/panthor kbase — Arm's official driver, for cross-checking: https://github.com/JeffyCN/mirrors/blob/kernel/drivers/gpu/arm/bifrost/csf/mali_kbase_csf_firmware.c

Run External Flash Hello everyone, I am using the MCXN547-EVK development board and trying to interface an external W25Q64JWTBJQ flash memory using Quad SPI (FlexSPI). I am building the project with IAR Embedded Workbench. While building the spi_flash example from the MCUXpresso SDK, I encounter the following error: CMake Error: Cannot find source file: .../examples/_boards/mcxn5xxevk/demo_apps/spi/spi_flash/cm33_core0/pin_mux.c Has anyone encountered this issue before? Could you please help me understand what is causing it and how to resolve it? Any suggestions would be greatly appreciated. Thank you! MCXN Re: Run External Flash Hello @Ashish-625  Could you please verify whether the pin_mux.c file exists at the following path? examples/_boards/mcxn5xxevk/demo_apps/spi/spi_flash/cm33_core0/pin_mux.c   In addition, please confirm which MCUXpresso SDK version you are using and whether the spi_flash demo is download based on  IAR Embedded Workbench.   Thank you.   BR Alice

贡献内容：完整的 S32DS PFE 插件、LWIP 集成和 tcpip/LLCE 修复 NXP团队和S32G社区的各位好， 我为 S32 设计工作室 (S32DS) / S32 配置工具开发了一个完整的 PFE 插件。此前，PFE 配置支持仅可通过 EB Tresos 获得。新插件包含： 在 S32DS 环境中完全原生集成 与 NXP 官方 TCP/IP 插件无缝集成，支持 LWIP 协议栈 完整的TSN流量整形器配置（TAS和CBS） 使用 LWIP 和 LLCE 进行全面测试，包括卸载场景 在此过程中，我还发现并解决了官方 tcpip 和 LLCE 插件中的几个错误。 这项改进使得在 S32G 平台上更顺利地开发高级以太网和 TSN 应用成为可能。 我想向 NXP 贡献完整的插件、集成元器件、错误修复、文档和测试结果。这可以集成到未来的 RTD 或 S32 配置工具版本中，或者作为官方参考资料与社区共享。 向恩智浦团队提出的问题： 提交此贡献的推荐流程是什么（例如，通过技术支持案例或其他渠道）？ 关于文件、包装或协议（例如保密协议）是否有任何特殊要求？ 我已准备好包含插件文件、安装/集成指南、详细变更日志和验证结果的完整代码包，软件包。我乐意私下分享，并支持任何技术审查或讨论。 感谢您事先的指导。期待您的反馈。 此致， 阿尔萨尔·伊玛目 SDV架构师 @ GK Automobiltechnologie (Disrupt) 金VIP Re: Offering Contribution: Complete PFE Plugin for S32DS, LWIP Integration & tcpip/LLCE Fixes 你好， arsalimam 首先，感谢您分享这项令人印象深刻的工作，并感谢您愿意将其贡献给恩智浦半导体。 您描述的功能——包括原生 S32 Design Studio 集成、LWIP/tcpip 集成、TSN 流量整形支持 (TAS/CBS)、LLCE 验证以及相关的错误修复——对于 S32G 以太网和 TSN 开发来说似乎非常有价值。 现阶段，对 NXP 现有工具的软件组件、插件和修改的贡献需要相关产品和软件团队进行审查。因为验收过程可能涉及技术评估以及知识产权和法律方面的考虑。 您可以通过我们的客户支持系统分享您的资料： https://support.nxp.com 我们感谢您为改进 S32G 软件生态系统所付出的努力和关注。 BR 乔伊

提供内容：S32DS用PFEプラグインの完全実装、LWIP統合、およびtcpip/LLCEの修正 NXPチームとS32Gコミュニティの皆様、こんにちは。 私はS32 Design Studio(S32DS)/S32設定ツール用の完全なPFEプラグインを開発しました。以前は、PFEの設定サポートはEB Tresosのみで利用可能でした。新しいプラグインには以下が含まれます。 S32DS環境内での完全なネイティブ統合 NXP公式tcpipプラグインとのシームレスな統合によるLWIPスタックサポート 完全なTSNトラフィックシェーパー構成(TASおよびCBS) LWIPおよびLLCEを用いた徹底的なテスト（オフロードシナリオを含む） その過程で、公式のtcpipおよびLLCEプラグインに存在するいくつかのバグも特定し、解決しました。 この強化により、S32Gプラットフォーム上で高度なイーサネットおよびTSNアプリケーションの開発がよりスムーズに可能となります。 プラグイン全体、統合コンポーネント、バグ修正、ドキュメント、テスト結果をNXPに提供したいと考えています。これは将来のRTDやS32構成ツールのリリースに統合されるか、コミュニティの公式参考資料として共有される可能性があります。 NXPチームへの質問： この貢献を正式に提出する際の推奨プロセス(例:技術サポートCASEやその他のチャネルを通じて)はどのようなものですか? ドキュメント、梱包、契約(NDAなど)に関して特別な要件はありますか? プラグインファイル、インストール・統合ガイド、詳細な変更履歴、検証結果を含む包括的なパッケージを用意しました。私は喜んでプライベートで共有し、技術的なレビューや議論もサポートします。 ご指導をよろしくお願いいたします。ご意見をお待ちしております。 よろしくお願いします、 アルサル・イマーム SDVアーキテクト @ GK Automobiltechnologie (Disrupt) ゴールドVIP Re: Offering Contribution: Complete PFE Plugin for S32DS, LWIP Integration & tcpip/LLCE Fixes こんにちは、アルサリマム まず、この素晴らしい成果を共有していただき、またNXPに貢献してくださる意思を示していただき、ありがとうございます。 あなたが説明した機能、例えばネイティブのS32 Design Studio統合、LWIP/tcpip連携、TSNトラフィックシェーピングサポート(TAS/CBS)、LLCE検証、関連するバグ修正などは、S32GイーサネットおよびTSN開発にとって非常に価値があるようです。 この段階では、既存のNXPツールへのソフトウェアコンポーネント、プラグイン、修正の提供は、関連製品およびソフトウェアチームによるレビューが必要です。受入プロセスには、技術的な評価だけでなく、知的財産権や法的側面に関する検討も含まれる場合がある。 カスタマーサポートシステムを通じて資料を共有することができます: https://support.nxp.com S32Gソフトウェアエコシステムの改善に尽力し、ご関心を持ってくださったことに感謝いたします。 BR ジョーイ

私たちが使っている i.mx RT1062全体でイーサネットMACアドレスを一意に取得するにはどうすればいいですか? こんにちは、 私たちは イーサネットでMIMXRT1062DVL6Bし、製品を実現させてください。 まず、製品のMACアドレスを「SILICONID_ConvertToMacAddr」で実装します。「fsl_silicon_id.c」上で、NXPのOUIとシリコンIDを持つデバイスごとのユニークなMACアドレスを取得するために。 でもMACアドレスは SILICONID_ConvertToMacAddrは唯一無二ではなく、すべて同一だった。 質問があります。 「SILICONID_ConvertToMacAddr」と呼ぶ前に何か設定はありますか? それとも、「SILICONID_ConvertToMacAddr」はNXPデバイス上で一意のMACアドレスを取得するために機能しませんか? 2026年1月4号のIMXRT1060RM.pdfでは答えが見つかりませんでした。 答えを教えていただけますか? ありがとうございます。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? やあ、アブナー ご支援ありがとうございます。 MACアドレスを使えることは理解しましたSILICONID_ConvertToMacAddr製品に。しかし、SILICONID_ConvertToMacAddrはあくまで例であり、大量生産には使えないと理解しています。そして、OUIのMACアドレスを使わなければなりません。 よろしくお願いいたします。 茂 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? こんにちは、@shigeru辻田  この状況を見つけてくれてありがとうございます。SILICONID_ConvertToMacAddrはNXP MCUX SDKの例として、テスト環境でのMACアドレスの競合を減らすために使われています。同じスイッチで異なるSocsのETHに接続しています。同じシリーズのSocの状況については、ここでは触れないかもしれません。 しかし、なぜこの方法で製品のMACアドレスを生成するのかが混乱しています。まず第一に、あなたのOUIは会社のものを使うべきです。そして、ユニークIDについては、会社内に特別な定義があるはずです。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? こんにちは、メイ。 SILICONID_ConvertToMacAddrは、固定のNXP OUIと3バイトのシリコンID（OCOTP->CFG0/1の一部）を使用してMACアドレスを生成すると理解しています。 ターゲット製品のOCOTP->CFG0/1を観察しました。 それらの値は以下のとおりです。 - MIMXRT1062 1個 - OCOTP->CFG0: (uint32_t)0x615c'faa4 - OCOTP->CFG1: (uint32_t)0x2a1e'61d7 - その他のMIMXRT1062 - OCOTP->CFG0: (uint32_t)0x615c'faa4 - OCOTP->CFG1: (uint32_t)0x4922'61d7 OCOTP->CFG0 の下位 3 バイトが SILICONID_ConvertToMacAddr の MAC アドレスに使用されるため、両者の MAC アドレスは類似しています。 SO、多くの製品は似たMACアドレスを持っています。（現在、数百個のプロトタイプを保有しており、すべてのMACアドレスをチェックしているわけではありませんが、54:27:8D:A4:FA:5Cとは異なるMACアドレスはまだ見つかっていません。） ありがとう。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? こんにちは@shigeru-tsujitaさん 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 SDK silicon_idコンポーネントが正しく統合されていると仮定すれば、MIMXRT1062のためにSILICONID_ConvertToMacAddr()を呼び出す前に追加の設定は必要ありません。 SILICONID_ConvertToMacAddr() は、MAC アドレスを生成する際に、完全な 64 ビットのシリコン ID を使用しないことにご注意ください。最初の3バイトには固定のNXP OUIを使用し、最後の3バイトにはシリコンIDから3バイトのみを使用します。 SDKコードによると: mayliu1_0-1783917944104.png 複数のデバイスから64ビットシリコンのユニークIDを読み取り、ID値が正しく読み取られているか確認してもらえますか?また、siliconId[0]、siliconId[1]、siliconId[2]も比較してください。これらはMACアドレスを生成するために使用されるバイトです。 これらの3バイトがデバイス間で同一であれば、生成されるMACアドレスも同一になります。 よろしくお願いいたします。 5月 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? ここで難しいのは、OCOTP->CFG1とOCOTP->CFG0によって形成される64ビットデータはチップごとに常に一意であるにもかかわらず、値の違いはわずか数ビットしかない場合があることです。だからこそ、情報を失わないようにそれらを組み合わせる方法を見つけなければなりません。私は、OCOTP->CFG1とOCOTP->CFG0のCRC32を取得し、その32ビットの結果を使用してMACアドレスを構築することで、かなりうまくいっています。 実際にMACを生成するには、「ローカル管理」MACアドレス(定数2バイトの後に32ビットCRC)を使うか、組織のOUIを最初の3バイトに使い、残りの3バイトをCRCの値から取る方法もあります。

Yocto wrynose build failure for 'imx-car-navigation' Hi, trying to build 'imx-image-full' for an FRDM-IMX93 on the latest 6.18.20-2.0.0 BSP fails like this: ERROR: imx-car-navigation-1.0-r0 do_compile: Execution of '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/run.do_compile.1753043' failed with exit code 1 ERROR: Logfile of failure stored in: /media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/log.do_compile.1753043 Log data follows: | DEBUG: Executing shell function do_compile | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode'. Retry scheduled | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode' a second time, aborting | WARNING: exit code 1 from a shell command. ERROR: Task (/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb:do_compile) failed with exit code '1' Note that this is 100% reproducible - it always fails here.  Please also note that a download of a repository fails, even though bitbake is executing a "compile" step.  Currently, I think it may be related that downloads should not be done in compilation steps and maybe bitbake now limits network functionality to the download step?  Did anyone test this recipe recently? Re: Yocto wrynose build failure for 'imx-car-navigation' It seems my gut feeling was right.  The following patch solves the problem for me: --- sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb.ORIG 2026-07-13 16:02:28.733344421 +0200 +++ sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb 2026-07-13 16:02:11.178539144 +0200 @@ -14,6 +14,7 @@ do_configure[noexec] = "1" +do_compile[network] = "1" do_compile() { cd ${S} But note that this is just a workaround.  There is a reason why this is not allowed by default - the compile step should not do any network access.

New Project Wizard fAiL: no freeRTOS port added automatically Hello all, I'm trying to create a freeRTOS based project for LPC5536 using MCUXpresso IDE V24.12. The "Create a new C/C++ project" wizard (available from Quickstart Panel) seems to offer a simple means to add freeRTOS support to a project (see markup in screenshot below): danielholala_0-1750771156912.png As you can see, the "New Project Wizard" offers a checkbox to add freeRTOS as "operating system". When checking this box, the wizard automatically adds another crucial part of freeRTOS, the memory manager (see marked checkboxes below): danielholala_1-1750771498221.png However, the wizard fails to add the most important part of freeRTOS, the MCU-specific  code (see markup in screenshot below): danielholala_2-1750771652430.png If you don't select this component by yourself, the generated project throws compilation errors. I believe that the New Project Wizard should always result in a compilable project. Further the MCUXpresso IDE manual clearly states:"Also, selecting a component automatically selects any dependencies." (section 5.1.1. SDK New Project WIzard). In my opinion, this is a bug, at least a UX bug.  I'd like to see this fixed in the next SDK / MCUXpresso version. Thanks. Daniel Re: New Project Wizard fAiL: no freeRTOS port added automatically Tried it with MCUXpresso IDE v25.6 (current as of writing) with SDK for LPC5536 (version 25.06, manifest 3.15) and the dependency between FreeRTOS kernel and the cm33 port is still missing and needs to be selected manually.  Re: New Project Wizard fAiL: no freeRTOS port added automatically Hello @EdwinHz , I appreciate your prompt support. Thank you. Daniel Re: New Project Wizard fAiL: no freeRTOS port added automatically Hi @danielholala, I was able to replicate this issue, and it is definitely a bug, since the project wizard should automatically select all of the dependencies. I will report this issue to the IDE team so they can correct it in a future version of MCUXpresso's project wizard. Thanks for reporting this issue. BR, Edwin.

Connectivity issue in SJA1110 Dear NXP members, This ticket may be related to the following topics: SJA-1110-Configuration-of-Qbv  SJA1110-Qbv-AdminBaseTime-Configuration  During the configuration of Qbv on the SJA1110 switch present in the S32G-VNP-RDB3 board, I have been using the SJA1110 SDK for S32G from NXP for setting the gPTP/Qbv parameters, compiling the new sja1110_uc.bin file, and deploying it on the firmware folder of the A-core Linux BSP. Initially, I have been using the PFE0 interface (SJA1110 switch Port 4) as the gPTP grandmaster, with ADMINBASETIME set to 0. I performed some tests and validations and everything indicates that it behaves as expected. However, during the course of the project, I had to reassign the roles so that now the gPTP grandmaster would come from an external device which is connected to the Port 3. From the moment I would connect this external device, the Qbv performance would behave quite erratically. I did some tests starting with large cycle values, for instance: Cycle = 1 sec -> 125000000 CycleExt (12.5%) = 15625000 segment 1 = 0.25 sec TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 0.25 sec TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 0.25 sec TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 0.25 sec TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 1250000 (2x625000) port 4: TRIGGER_TIME = 3125000 (4x781250) ports 5...: TRIGGER_TIME = 125000 For testing, I send UDP packets from the client (S32G PFE0 interface) to another Linux device connected on the same network acting as server. I capture the packets using the tcpdump tool on the server side, and analyze the results. In this case, the transmission would start after a few seconds, but once started, it would behave correctly (1 second cycle, 25% for the given traffic priority): Screenshot 2026-07-08 084413.png  Then, I used the GATESTATUS division into four segments, but reduced the cycle time to 200 ms: Cycle = 200ms -> 25000000 CycleExt = 3125000 segment 1 = 50 ms TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 50 ms TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 50 ms TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 50 ms TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 250000 port 4: TRIGGER_TIME = 625000 ports 5...: TRIGGER_TIME = 25000 It would work, but I needed to start between 30 seconds and 2 minutes for the transmission of the packets start. Screenshot 2026-07-08 085025.png   In the subsequent tests, I observed the same pattern: When the cycle time was reduced to 100 ms, I would have to wait between 2 and 4 minutes before transmission started; When the cycle time was reduced to 50 ms, I would have to wait between 5 and 6 minutes before transmission started. And so on. So, the shorter the cycle length, the larger the wait time before Qbv effectively started. Until then, the traffic was blocked. But there is another weird behavior observed when I did the following configuration: Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 2 = 300 μsec TC 6: GATESTATUS 4 segment 3 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 In this case, all of the traffic would pass except TC6. When I invert the configuration: Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TC 6: GATESTATUS 4 segment 2 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 3 = 300 μsec TC 6: GATESTATUS 4 in this case, only the TC6 traffic would be transmitted while the other TCs would be blocked. From my opinion, it points in the direction of the time synchronization issue. Here is how I have configured gPTP on the S32DS: Screenshot 2026-07-08 090805.png   Screenshot 2026-07-08 091033.png   It is also worth mentioning that this external gPTP Grandmaster provides Sync timestamps based on the current Unix epoch:   Screenshot 2026-07-01 110153.png While when the PFE0 was used as the Grandmaster, it would provide Sync timestamps starting with 0: Screenshot 2026-07-08 091440.png   What would explain this behavior? Thank you for your support! Best regards, Guilherme Re: Connectivity issue in SJA1110 Hello @GuilhermeS32G , Yes, please wait to get access. Besides NDA, Automotive Ethernet belongs to export control policy. In my opinion, the ECT tool is a great source of code related to switch's dynamic reconfiguration. Yes, split the Unix epoch gPTP timestamp into ADMINBASETIME[0:31] and ADMINBASETIME[32:63] is the right way. Best regards, Pavel Re: Connectivity issue in SJA1110 Hi @PavelL , Thank you for your response. Indeed, this ECT tool seems to be the right way to go. However, I still have no access for downloading it. It says: "SJA11XX Standard Software - Your Request form has been received". I may need to wait for some time to see if I can get access. In the meanwhile, just to clarify, let's say the current Unix epoch (with nanoseconds) is: 1784013205012345678 Which represents, in UTC: Tuesday, July 14, 2026 at 7:13:25 AM What is the correct way to split this timestamp into ADMINBASETIME[0:31] and ADMINBASETIME[32:63]? Best regards, Guilherme Re: Connectivity issue in SJA1110 Hello @GuilhermeS32G , Thank you for creating a follow up thread - it help us to keep clarity on cases. Thank you for sharing all the details and test results at once. I checked provided data and your gPTP configuration appears to be correct.   Based on your observations, the behavior strongly suggests that the issue is related to the Qbv schedule activation time rather than to the gate list entries themselves. If the ADMINBASETIME being configured as 0 while the external gPTP Grandmaster provides an epoch-based PTP time value, ADMINBASETIME = 0 is far in the past relative to the current synchronized gPTP time domain and the switch needs to resolve the Qbv change/start time based on that value. This may lead to unexpected schedule activation behavior compared with a setup where the PTP time starts close to zero, and it is therefore safer to program ADMINBASETIME as a future value in the currently synchronized PTP time domain.   Therefore, for this use case, I would recommend configuring ADMINBASETIME dynamically based on the current synchronized PTP/gPTP time (and still using a fixed value of 0 in the static configuration). A typical sequence would be: 1. Start gPTP and wait until the switch is synchronized to the external Grandmaster. 2. Read the current PTP clock from the switch. 3. Set ADMINBASETIME to a future time value, for example current PTP time + sufficient safety margin. 4. Write the TAS/Qbv administrative parameters. 5. Trigger the TAS/Qbv configuration change. You may use the ECT server implementation as a reference. In particular, please check file udp_traffic.c ; routine udpReceiveCallback() . It doesn't matter if you use SDK or RTD version of ECT server. PavelL_0-1783939380327.png In the TAS configuration handling, the ECT server (SDK version) reads the current PTP time using SWITCH_DRV_GetPtpClk(), assigns this value to the TAS baseTime, adds a margin of 2 seconds, and then calls SWITCH_DRV_WriteTasAdminParameters() followed by SWITCH_DRV_ChangeTasConfig().   This approach avoids using ADMINBASETIME = 0 and aligns the Qbv schedule activation with the actual synchronized PTP time domain. Best regards, Pavel

SJA1110のコネクティビティ問題 NXPメンバーの皆様へ このチケットは以下のトピックに関連する場合があります: SJA-1110-Qbvの構成 SJA1110-Qbv-AdminBaseTime-Configuration S32G-VNP-RDB3ボードにあるSJA1110スイッチでQbvの設定中、NXPのS32GのSJA1110 SDKを使ってgPTP/Qbvパラメータの設定、新しい sja1110_uc.bin ファイルのコンパイル、そしてAコアLinux BSPのファームウェアフォルダにデプロイしています。 最初は、PFE0インターフェース(SJA1110スイッチポート4)をgPTPグランドマスターとして使い、ADMINBASETIMEを0に設定していました。いくつかのテストや検証を行いましたが、すべて期待通りに動作しています。 しかし、プロジェクトの進行中に役割を再割り当てし、gPTPグランドマスターはポート3に接続された外部デバイスから出力されるようになりました。 この外部デバイスを接続した瞬間から、Qbvのパフォーマンスが非常に不安定になった。 例えば、大きなサイクル値から始めていくつかのテストを行いました。 Cycle = 1 sec -> 125000000 CycleExt (12.5%) = 15625000 segment 1 = 0.25 sec TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 0.25 sec TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 0.25 sec TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 0.25 sec TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 1250000 (2x625000) port 4: TRIGGER_TIME = 3125000 (4x781250) ports 5...: TRIGGER_TIME = 125000 テストのために、クライアント(S32G PFE0インターフェース)から同じネットワークにコネクテッドされた別のLinuxデバイスへUDPパケットを送信しています。 サーバー側でtcpdumpツールを使用してパケットをキャプチャし、結果を分析します。 この場合、送信は数秒後に開始されますが、一度開始すると正しく振る舞います(1秒サイクル、指定されたトラフィック優先度の25%)。 Screenshot 2026-07-08 084413.png 次に、GATESTATUSを4つのセグメントに分割しましたが、サイクルタイムを200msに短縮しました。 Cycle = 200ms -> 25000000 CycleExt = 3125000 segment 1 = 50 ms TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 50 ms TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 50 ms TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 50 ms TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 250000 port 4: TRIGGER_TIME = 625000 ports 5...: TRIGGER_TIME = 25000 うまくいくはずだったが、パケットの送信開始まで30秒から2分の間に開始する必要があった。 Screenshot 2026-07-08 085025.png   その後のテストでも、同じパターンが観察された。 サイクルタイムを100ミリ秒に短縮すると、送信が開始されるまでに2分から4分待たなければなりませんでした。 サイクルタイムが50ミリ秒に短縮された場合、送信が開始されるまでに5分から6分待たなければなりませんでした。 などなど。したがって、 サイクルの長さが短いほど、Qbvが実質的に始まるまでの待ち時間が長くなります。それまで、交通は遮断されていた。 しかし、以下の設定を行った際に、別の奇妙な動作が観察されました。 Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 2 = 300 μsec TC 6: GATESTATUS 4 segment 3 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 この場合、TC6以外のすべてのトラフィックは通過します。 設定を反転すると： Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TC 6: GATESTATUS 4 segment 2 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 3 = 300 μsec TC 6: GATESTATUS 4 この場合、TC6のトラフィックのみが送信され、他のTCはブロックされます。 私の見解では、これは時刻同期の問題を示唆している。 S32DSでgPTPを設定した方法を以下に示します。 Screenshot 2026-07-08 090805.png   Screenshot 2026-07-08 091033.png   また、この外部gPTPグランドマスターは、現在のUnixエポックに基づいた同期タイムスタンプを提供する点も特筆すべきである。   Screenshot 2026-07-01 110153.png PFE0がグランドマスターとして使用された場合、同期タイムスタンプは0から始まる。 Screenshot 2026-07-08 091440.png   この行動を説明できるものは何だろうか？ サポートありがとうございます! よろしくお願いいたします。 ギレルメ Re: Connectivity issue in SJA1110 こんにちは、 @GuilhermeS32G さん、 はい、アクセスを待ってください。NDAに加えて、自動車用イーサネットは輸出管理政策に属しています。 私の意見では、ECTツールはスイッチの動的再構成に関連する優れたコードソースです。 はい、UnixエポックgPTPタイムスタンプをADMINBASETIME[0:31]とADMINBASETIME[32:63]に分割するのが正しい方法です。 よろしくお願いいたします。 パベル Re: Connectivity issue in SJA1110 こんにちは、 @PavelL さん。 ご返信ありがとうございます。 確かに、このECTツールは正しい方向性のように思えます。 しかし、まだダウンロードのアクセス権はありません。そこには「標準ソフトウェアSJA11XX - リクエストフォームが受領されました」と表示されます。アクセスできるかどうか、しばらく待つ必要があるかもしれません。 念のため、現在のUnixエポック（ナノ秒単位）を以下のように定義します。 1784013205012345678 これはUTCで表すと次のようになります。 2026年7月14日（火）午前7時13分25秒 このタイムスタンプをADMINBASETIME[0:31]とADMINBASETIME[32:63]に分割する正しい方法は何ですか？ よろしくお願いいたします。 ギレルメ Re: Connectivity issue in SJA1110 こんにちは、 @GuilhermeS32G さん、 フォローアップスレッドを作ってくださりありがとうございます。CASEの明確さを保つ助けになりました。 詳細情報と検査結果を一度に共有していただき、ありがとうございます。 ご提供いただいたデータを確認したところ、gPTPの設定は正しいようです。   あなたの観察から判断すると、この挙動はゲートリストのエントリ自体よりもQbvのスケジュール有効化時間に関連していることを強く示唆しています。 ADMINBASETIMEが0に設定されている一方で、外部gPTPグランドマスターがエポックベースのPTP時間値を提供する場合、ADMINBASETIME = 0は現在の同期gPTP時間領域に比べてかなり過去のことであり、スイッチはその値に基づいてQbvの変更/開始時間を解決する必要があります。これにより、PTP時間がほぼゼロから始まるセットアップと比べて予期しないスケジュール起動動作が生じる可能性があるため、現在同期されたPTP時間領域においてADMINBASETIMEを将来の価値としてプログラムする方が安全です。   したがって、このユースケースでは、現在の同期PTP/gPTP時間に基づいて動的にADMINBASETIMEを設定することをおすすめします(静的設定では固定値の0を使い続けます)。 典型的な手順は次のとおりです。 1. gPTPを起動し、スイッチが外部グランドマスターと同期するまで待ちます。 2. スイッチから現在のPTPクロックを読み取る。 3. ADMINBASETIMEを将来の時間値に設定します。例えば、現在のPTP時間+十分なセーフティマージン。 4. TAS/Qbvの管理パラメータを記述します。 5. TAS/Qbvの設定変更をトリガーします。 ECTサーバーの実装を参考にしても構いません。特に、ファイルudp_traffic.cを確認してください; routine udpReceiveCallback() .SDK版でもRTD版でも、ECTサーバーのどちらを使っても関係ありません。 PavelL_0-1783939380327.png TASの設定処理では、ECTサーバー(SDKバージョン)が現在のPTP時間をSWITCH_DRV_GetPtpClk()で読み取り、この値をTASのbaseTimeに割り当て、2秒の余裕を加えてからSWITCH_DRV_WriteTasAdminParameters()を呼び出し、続いてSWITCH_DRV_ChangeTasConfig()。   このアプローチでは、ADMINBASETIME = 0 の使用を回避し、Qbv スケジュールの有効化を実際の同期された PTP タイムドメインに合わせます。 よろしくお願いいたします。 パベル

Zephyrにおけるi.MX95 FRDM EVK向けHDMI構成サポート こんにちは、NXP チームの皆様、 現在、Zephyr RTOSを使って i.MX95 FRDM EVK ボードを開発中です。 Linux側ではHDMI出力がすでにサポートされていて正常に動作しています。しかし、ZephyrでHDMIを有効にする方法や設定方法を知りたいです。 以下の点について教えていただけませんか? Zephyrはi.MX95 FRDM EVKのHDMI出力に対応していますか? もしそうなら、どんなドライバーやデバイスツリーの設定が必要ですか? ZephyrのHDMI用の参考実装やサンプルアプリケーションはありますか? どんなガイダンスやドキュメントでも大変ありがたいです。 よろしくお願いします。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK AEチームに確認しました。 現在、IMX95 ZephyrではHDMIはサポートされていません。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK こんにちは、NXP チームの皆様、 IT6263のリファレンスマニュアルかレジスタプログラミングマニュアルを探しています。 IT6263 HDMIブリッジの詳細なレジスタ説明(ビットレベルの定義付きレジスタマップ)を教えていただけるか、このドキュメントを入手する方法を教えていただけますか? 注:私は特にチップレベルのレジスタのドキュメント自体を探しており、Linuxカーネルドライバーのソースではありません。 ありがとう、 カルティケヤン M Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK IT6263はNXP製品ではないため、NXPはこの装置のリファレンスマニュアルを提供していません。設定や初期化の詳細については、IT6263 Linuxドライバのソースコードをご参照ください。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK ご回答ありがとうございます。 Armサポートの具体的なお問い合わせメールアドレスやサポートポータルを教えていただけますか?もし直接の連絡先や適切なメールアドレスがあれば、とても助かります。この件については彼らに連絡してみます。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK アームサポートハブ: https://support.arm.com/support-cases   サポートお問い合わせフォーム:https://www.arm.com/company/contact-us/support-inquiries Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 私はZephyr OSでHDMIを成功裏に移植でき、現在CPU上で動作しています。次の目標はGPUで動かすように移植することです。 そのためにArm Mali-G310の技術リファレンスマニュアル、特にCSF/ファームウェアインターフェースのセクションが必要です。この書類はNXPサポートに依頼すべきでしょうか、それとも直接Armサポートにお問い合わせする必要がありますか? このリファレンスマニュアルにアクセスできれば、ZephyrのGPUポートを実装するのに非常に役立ちます Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Armサポートに直接お問い合わせください。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK ご回答とArmサポートリンクの提供に感謝します。 Arm Mali-G310技術リファレンス・マニュアルとCSF/ファームウェアインターフェースのドキュメントについてArmサポートにお問い合わせします。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 以下の情報がお役に立つかどうかご確認ください。もし違うなら、AEチームに連絡する必要があります。 Arm Mali-G310技術リファレンス・マニュアルはArmのドキュメントポータルから入手可能です:「Arm Developer / Arm ドキュメント」で「Mali-G310 Technical Reference Manual」または「Mali-G310 TRM」を検索してください。アクセスレベルに応じて、ArmアカウントやArmのドキュメント条件の承認が必要になる場合があります。 NXP i.MX95の作業に関しては、NXPの公開ドキュメントではMali-G310 GPUについてi.MX グラフィックスユーザーガイドを示しており、FRDM-i.MX95の起動ページはGPU使用状況の詳細についてそのガイドにリンクしています。FRDM-i.MX95のページには、このボードがMali-G310 GPU搭載と記載されており、詳細は i.MX グラフィックスユーザーガイドへのリンクがあります:https://www.nxp.com/docs/en/user-guide/UG10159.pdf  ここから始めましょう： Armのドキュメントポータル:https://developer.arm.com/documentation NXP i.MX グラフィックスユーザーガイド:https://www.nxp.com/docs/en/user-guide/UG10159.pdf Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Armポータルと i.MX グラフィックスユーザーガイドへのリンクをありがとうございます。両方とも検討しましたが、私たちのニーズを満たしていませんでした。そのガイドにはLinuxでのGPUの使い方が説明されており、私たちはi.MX95(ベアメタルで、LinuxではなくZephyr使用)で自分たちの低レベルのGPUドライバーを書いています。ですから、これらの文書が提供するよりも低レベルのレジスターレベルの情報が必要です。 ARMポータルでTRMを検索しましたが、利用できません。 簡単に言うと、私たちの状況は以下のとおりです。   Mali-G310 GPUはある程度動作しています。GPUは正しく検出され、電源を入れてリセットされ、GPUファームウェアも正常にメモリに読み込みました。この段階までは全て正常に動作し、検証済みです。   私たちは一段階で行き詰まっています。GPUのファームウェアマイクロコントローラ(MCU)を起動することです。有効化しても、そのステータスは「無効」のままで、決して実行されません。エラーも割り込みも発生せず、単に起動しないだけです。   Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK こんにちは、NXPチームの皆さん、 必要なドキュメントを求めてArmサポートにお問い合わせしたところ、以下の返信がありました。 「シリコンに障害が発生しているのを見かけたら、NXPサポートに連絡してください。繰り返しますが、これらの文書はシリコンベンダーのお客様に提供されるべきではありません。" 彼らの回答に基づき、NXPに支援を要請することにしました。 Zephyr OSでHDMIを有効にすることに成功し、現在CPUで動作しています。次の目標はGPUベースのレンダリングを有効にすることです。 進めるには、Arm Mali-G310技術リファレンスマニュアル、特にCSF/ファームウェアインターフェースのドキュメントが必要です。 Mali-G310 GPUはNXP i.MX95プラットフォームに統合されているため、このドキュメントへのアクセス方法を教えていただけますか?もしドキュメントを共有できない場合は、ZephyrでのGPU起動を続けるための代替のガイダンスや参考文献があれば教えていただけるとありがたいです。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK こんにちは、NXPチームの皆様。 必要なドキュメントを求めてArmサポートにお問い合わせしたところ、以下の返信がありました。 「シリコンに障害が発生しているのを見かけたら、NXPサポートに連絡してください。繰り返しますが、これらの文書はシリコンベンダーのお客様に提供されるべきではありません。" 彼らの回答に基づき、NXPに支援を要請することにしました。 Zephyr OSでHDMIを有効にすることに成功し、現在CPUで動作しています。次の目標はGPUベースのレンダリングを有効にすることです。 進めるには、 Arm Mali-G310技術リファレンスマニュアル、特に CSF/ファームウェアインターフェース のドキュメントが必要です。 Mali-G310 GPUはNXP i.MX95プラットフォームに統合されているため、このドキュメントへのアクセス方法を教えていただけますか?もしドキュメントを共有できない場合は、ZephyrでのGPU起動を続けるための代替のガイダンスや参考文献があれば教えていただけるとありがたいです。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK AEチームからの以下のアップデートをご参照ください。 Arm Mali-G310 TRMに関しては、この文書はArmの機密知的財産(IP)です。NXPはエンドお客様への転送が許可されていないため、NXPのチャネルを通じて実質的に利用できません。正式な申請は直接Armを経由しなければならず、時間がかかり、承認される可能性は低いです。さらに、i.MX95 GPUはまだ試作段階にあり、現時点で公式に検証されたベアメタル/Zephyrのリファレンスはありません。 有効化後にMCUが「無効化」のままになることについては、このステップにはTRMは必要ありません。完全なブートフローは、以下の2つの公開ソースで確認できます。どちらもGitHubから直接アクセス可能です。 Panthor — メインラインのドライバで、主に注目すべきもの(実際にMCUを起動し、i.MX95をサポートしています): https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/panthor kbase — Armの公式ドライバ、クロスチェック用: https://github.com/JeffyCN/mirrors/blob/kernel/drivers/gpu/arm/bifrost/csf/mali_kbase_csf_firmware.c

SJA1110 的连接问题 尊敬的恩智浦半导体成员们： 此工单可能与以下主题相关： SJA-1110-Qbv配置 SJA1110-Qbv-AdminBaseTime-Configuration 在配置 S32G-VNP-RDB3 板上的 SJA1110 交换机的 Qbv 时，我一直使用 NXP 的 S32G SJA1110 SDK 来设置 gPTP/Qbv 参数，编译新的sja1110_uc.bin文件，并将其部署到 A-core Linux 电路板支持包 的固件文件夹中。 最初，我使用 PFE0 接口（SJA1110 交换机端口 4）作为 gPTP 主服务器，并将 ADMINBASETIME 设置为 0。我进行了一些测试和验证，一切迹象都表明它的行为符合预期。 然而，在项目进行过程中，我不得不重新分配角色，以便现在 gPTP 主控节点将来自连接到端口 3 的外部设备。 从我连接这个外部设备的那一刻起，Qbv 的性能就会变得非常不稳定。 我进行了一些测试，例如从较大的循环值开始： Cycle = 1 sec -> 125000000 CycleExt (12.5%) = 15625000 segment 1 = 0.25 sec TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 0.25 sec TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 0.25 sec TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 0.25 sec TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 1250000 (2x625000) port 4: TRIGGER_TIME = 3125000 (4x781250) ports 5...: TRIGGER_TIME = 125000 为了进行测试，我从客户端（S32G PFE0 接口）向连接在同一网络上的另一个 Linux 设备（作为服务器）发送 UDP 数据包。 我在服务器端使用 tcpdump 工具捕获数据包，并分析结果。 在这种情况下，传输会在几秒钟后开始，但一旦开始，它就会正常工作（1 秒周期，给定流量优先级的 25%）： Screenshot 2026-07-08 084413.png 然后，我将 GATESTATUS 分成四个段，但将周期时间缩短至 200 毫秒： Cycle = 200ms -> 25000000 CycleExt = 3125000 segment 1 = 50 ms TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 50 ms TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 50 ms TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 50 ms TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 250000 port 4: TRIGGER_TIME = 625000 ports 5...: TRIGGER_TIME = 25000 这样做是可行的，但我需要等待 30 秒到 2 分钟才能开始传输数据包。 Screenshot 2026-07-08 085025.png   在随后的测试中，我观察到了同样的模式： 当循环时间缩短至 100 毫秒时，我需要等待 2 到 4 分钟才能开始传输； 当循环时间缩短到 50 毫秒时，我需要等待 5 到 6 分钟才能开始传输。 等等。因此，周期长度越短，Qbv 实际开始前的等待时间就越长。在此之前，交通一直处于阻塞状态。 但是，当我进行以下配置时，观察到了另一种奇怪的现象： Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 2 = 300 μsec TC 6: GATESTATUS 4 segment 3 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 在这种情况下，除了TC6之外，所有交通流量都将通过。 当我反转配置时： Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TC 6: GATESTATUS 4 segment 2 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 3 = 300 μsec TC 6: GATESTATUS 4 在这种情况下，只有 TC6 的流量会被传输，而其他 TC 的流量将被阻止。 我认为，这指向了时间同步问题。 以下是我在S32DS上配置gPTP的方法： Screenshot 2026-07-08 090805.png   Screenshot 2026-07-08 091033.png   值得一提的是，这个外部 gPTP 主服务器提供的同步时间戳基于当前的 Unix 纪元：   Screenshot 2026-07-01 110153.png 当 PFE0 用作主控时，它会提供从 0 开始的同步时间戳： Screenshot 2026-07-08 091440.png   这种行为该如何解释？ 感谢您的支持！ 顺祝商祺！ 吉列尔梅 Re: Connectivity issue in SJA1110 你好@GuilhermeS32G ， 是的，请稍候，您将获得访问权限。除了保密协议外，汽车以太网还属于出口管制政策的范畴。 我认为，ECT 工具是交换机动态重配置相关代码的绝佳来源。 是的，将 Unix epoch gPTP时间戳拆分为 ADMINBASETIME[0:31] 和 ADMINBASETIME[32:63] 是正确的方法。 顺祝商祺！ 帕维尔 Re: Connectivity issue in SJA1110 嗨@PavelL ， 感谢您的反馈， 确实，这种ECT工具似乎是正确的选择。 但是，我仍然无法下载它。上面写着：“SJA11XX 标准软件 - 您的申请表已收到”。我可能需要等待一段时间才能获得访问权限。 同时，为了更清楚地说明，我们假设当前的 Unix 时间戳（精确到纳秒）是： 1784013205012345678 这在世界协调时 (UTC) 代表： 2026年7月14日星期二上午7:13:25 如何正确地将此时间戳拆分为 ADMINBASETIME[0:31] 和 ADMINBASETIME[32:63]？ 顺祝商祺！ 吉列尔梅 Re: Connectivity issue in SJA1110 你好@GuilhermeS32G ， 感谢您创建后续讨论帖——这有助于我们了解案件的最新进展。 感谢您一次性分享所有细节和测试结果。 我已检查所提供的数据，您的 gPTP 配置似乎是正确的。   根据您的观察，该行为强烈表明问题与 Qbv 调度激活时间有关，而非门控列表条目本身。如果外部 gPTP 主时钟提供基于纪元的 PTP 时间值，而 ADMINBASETIME 配置为 0，则 ADMINBASETIME = 0 相对于当前同步的 gPTP 时域而言非常遥远，交换机需要基于该值解析 Qbv 更改/启动时间。与 PTP 时间接近零的设置相比，这可能会导致意外的调度激活行为。因此，将 ADMINBASETIME 设置为当前同步的 PTP 时域中的未来值更为安全。   因此，对于此用例，我建议根据当前同步的 PTP/gPTP 时间动态配置 ADMINBASETIME（并在静态配置中仍然使用固定值 0）。 典型的序列如下： 1. 启动 gPTP 并等待交换机与外部主控交换机同步。 2. 从交换机读取当前的 PTP 时钟。 3. 将 ADMINBASETIME 设置为未来的时间值，例如当前 PTP 时间 + 足够的安全裕度。 4. 编写 TAS/Qbv 管理参数。 5. 触发 TAS/Qbv 配置更改。 您可以参考 ECT 服务器的实现。特别是请查看udp_traffic.c文件中的 udpReceiveCallback() 函数。无论您使用的是 ECT 服务器的 SDK 版本还是 RTD 版本，都无关紧要。 PavelL_0-1783939380327.png 在 TAS 配置处理中，ECT 服务器（SDK 版本）使用 SWITCH_DRV_GetPtpClk() 读取当前 PTP 时间，将此值赋给 TAS 基准时间，加上 2 秒的裕量，然后调用 SWITCH_DRV_WriteTasAdminParameters()，再调用 SWITCH_DRV_ChangeTasConfig()。   这种方法避免使用 ADMINBASETIME = 0，并将 Qbv 调度激活与实际同步的 PTP 时间域对齐。 顺祝商祺！ 帕维尔

Zephyr 中对 i.MX95 FRDM EVK 的 HDMI 配置支持 您好，NXP团队： 我目前正在使用 Zephyr RTOS 在i.MX95 FRDM EVK板上进行开发。 Linux 系统方面，HDMI 输出已经得到支持，并且运行正常。但是，我想知道如何在 Zephyr 中启用和配置 HDMI。 请问您能否指导我完成以下事项？ Zephyr 是否支持 i.MX95 FRDM EVK 的 HDMI 输出？ 如果需要，需要哪些驱动程序和设备树配置？ Zephyr 上是否有 HDMI 的参考实现或示例应用程序？ 任何指导或文件都将不胜感激。 谢谢！ Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 我已向AE团队确认过。 IMX95 Zephyr 目前不支持 HDMI。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 您好，NXP团队： 我正在寻找IT6263参考手册或寄存器编程手册。 请问您能否分享 IT6263 HDMI 桥接器的详细寄存器描述（带有位级定义的寄存器映射），或者告诉我如何才能获得这些文档？ 注意：我需要的是芯片级寄存器文档，而不是 Linux 内核驱动程序源代码。 谢谢你， 卡尔蒂凯扬·M Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK IT6263 不是 NXP 的产品，因此 NXP 不提供该设备的参考手册。有关配置和初始化的详细信息，您可以参考 IT6263 Linux 驱动程序源代码。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 感谢您的回复。 请问能否提供Arm技术支持的具体联系邮箱或支持门户网站？如果您有直接联系人或合适的电子邮件地址，那将非常有帮助。我会就此事与他们联系。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 感谢您的回复以及提供的 Arm 支持链接。 我将联系 Arm 支持部门，以获取 Arm Mali-G310 技术参考手册和 CSF/固件接口文档。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Arm 支持中心： https://support.arm.com/support-cases   支持咨询表单： https://www.arm.com/company/contact-us/support-inquiries Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 我已经成功地将 HDMI 移植到 Zephyr 操作系统上，目前它正在 CPU 上运行。我的下一个目标是将其移植到GPU上运行。 为此，我需要Arm Mali-G310技术参考手册，特别是其中的CSF/固件接口部分。我应该向NXP技术支持索取这份文档，还是需要直接联系Arm技术支持？ 如果能查阅这份参考手册，对于在 Zephyr 上实现 GPU 移植将非常有帮助。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 请直接联系Arm 支持团队。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 感谢您提供的 Arm 门户网站和 i.MX 图形用户指南的链接。我们两种都看过，但它们都不能满足我们的需求。这些指南解释了如何在 Linux 下使用 GPU，而我们正在 i.MX95 上编写我们自己的底层 GPU 驱动程序（裸机，使用 Zephyr，而不是 Linux）。因此，我们需要比这些文件提供的更低层级、登记级别的信息。 我们在 ARM 门户网站上搜索了 TRM，但找不到。 简而言之，我们的情况是这样的：   我们已经让 Mali-G310 GPU 运行到一定程度。GPU 已正确检测、通电、RESET，并且我们已成功将 GPU 固件加载到内存中。到目前为止，一切运行正常，并且已经过验证。   我们卡在了其中一个步骤：启动 GPU 的固件微控制器（MCU）。启用后，它的状态始终为“已禁用”，并且永远不会开始运行。没有错误提示，也没有中断提示——就是无法启动。   Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK NXP团队您好， 我联系了 Arm 技术支持索取所需文档，他们回复如下： “如果您发现NXP芯片出现任何问题，请联系NXP技术支持。”再次强调，这些文件不应该提供给芯片供应商的客户。 根据他们的回复，我正在联系恩智浦半导体寻求帮助。 我已经成功在 Zephyr OS 上启用了 HDMI，它目前正在使用 CPU 运行。我的下一个目标是启用基于GPU的渲染。 要继续进行，我需要 Arm Mali-G310 技术参考手册，特别是 CSF/固件接口文档。 由于 Mali-G310 GPU 集成在 NXP i.MX95 平台中，请问我如何才能获得该文档？如果无法共享该文档，我希望得到任何其他指导或参考，引用，以帮助我继续在 Zephyr 上启动 GPU。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 请查看以下信息是否对您有所帮助。如果没有，我需要联系AE团队。 Arm Mali-G310 技术参考手册可从 Arm 的文档门户获取：在 Arm Developer / Arm Documentation 中搜索“Mali-G310 技术参考手册”或“Mali-G310 TRM” 。根据访问级别，可能需要 Arm 帐户或接受 Arm 文档条款。 对于 NXP i.MX95 的工作，NXP 的公开文档通过i.MX 图形用户指南指向 Mali-G310 GPU，而 FRDM-i.MX95 入门页面链接提供了有关 GPU 使用详情的指南。FRDM-i.MX95 页面显示该板配备Mali-G310 GPU ，并提供了i.MX 图形用户指南的链接，以便了解更多详情： https://www.nxp.com/docs/en/user-guide/UG10159.pdf 从这里开始： Arm 文档门户： https://developer.arm.com/documentation NXP i.MX 图形处理器用户指南： https://www.nxp.com/docs/en/user-guide/UG10159.pdf Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 您好，NXP团队， 我联系了 Arm 技术支持索取所需文档，他们回复如下： “如果您发现NXP芯片出现任何问题，请联系NXP支持部门。”再次强调，这些文件不应该提供给芯片供应商的客户。 根据他们的回复，我正在联系恩智浦半导体寻求帮助。 我已经成功在 Zephyr OS 上启用了 HDMI，它目前正在使用 CPU 运行。我的下一个目标是启用基于GPU的渲染。 要继续进行，我需要Arm Mali-G310 技术参考手册，特别是CSF/固件接口文档。 由于 Mali-G310 GPU 集成在 NXP i.MX95 平台中，请问我如何才能获得该文档？如果无法共享该文档，我希望得到任何其他指导或参考，引用，以帮助我继续在 Zephyr 上启动 GPU。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 请参考AE团队的以下更新。 关于 Arm Mali-G310 TRM，本文档属于 Arm 机密知识产权。NXP 不允许将其转发给最终客户，因此基本上无法通过 NXP 渠道获得。正式请求必须直接通过 Arm 公司提出，这需要很长时间，而且不太可能获得批准。此外，i.MX95 GPU 仍处于预生产阶段，因此目前还没有官方验证的裸机/Zephyr 参考，引用。 关于启用后 MCU 保持“禁用”状态的问题，此步骤不需要 TRM。完整的启动流程可在以下两个公开来源中找到，这两个来源均可直接在 GitHub 上访问： Panthor — 主线驱动程序，主要关注的驱动程序（它实际上启动了 MCU 并支持 i.MX95）： https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/panthor kbase — Arm 的官方驱动程序，用于交叉检查： https://github.com/JeffyCN/mirrors/blob/kernel/drivers/gpu/arm/bifrost/csf/mali_kbase_csf_firmware.c