問題: IMX_SEC_ENCLAVE の依存関係と解放後使用を修正する Hello これは、GitHub のこのプルリクエストのフォローアップです。 提供されたパッチは最終的に適用されなかったようで、lf-6.18.y には含まれていません。 Kconfigコミットは、NVMEM_IMX_OCOTP_SCUがmである場合にエンクレイブドライバがyになれないようにするためで、プローブのディフェースを回避するために必要です。 そうしないと、こうなります。 root@colibri-imx8x-14985125:~# dmesg -l err [ 1.708145] rtc-ds1307 1-0068: hctosys: unable to read the hardware clock [ 2.072996] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.078636] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.084513] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.111555] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.117209] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.123110] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.141671] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.147303] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.153200] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.171418] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.177065] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.182929] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 5.744448] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 5.750217] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 5.756186] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 5.877660] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 5.888247] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 5.894232] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 10.324138] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 10.349783] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 10.374692] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 11.731697] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 11.738134] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 11.747692] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.284910] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.295720] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.307723] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.410541] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.426771] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.443446] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.644550] debugfs: '5f1a0000.phy' already exists in 'regmap' [ 12.655906] debugfs: '5f1a0000.phy' already exists in 'regmap' [ 12.670039] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.688813] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.696063] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.765923] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.775810] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.786887] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.839515] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.847285] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.853801] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.936721] nvmem imx-scu-ocotp0: cell mac raw len 6 unaligned to nvmem word size 4 [ 12.951328] nvmem imx-scu-ocotp0: cell mac raw len 6 unaligned to nvmem word size 4 [ 13.708903] genpd_provider mu_a1: failed to power off resource 214 ret -22 [ 16.701904] Bluetooth: hci0: unexpected event for opcode 0x0000 root@colibri-imx8x-14985125:~# 2回目のコミットではドライバにリファクタリングが行われており、NXPが対応しているかはわかりません コミット9703dfecc735(「LF-15802: ドライバ: ファームウェア: imx: SEドライバーの削除を修正」) SEチームに確認してもらえますか? よろしくお願いいたします フランツ Re: ISSUE: fix dependency for IMX_SEC_ENCLAVE and use-after-free こんにちは、 まだ解決していないようですので、社内のソフトウェアチームに確認して確認します。 よろしくお願いいたします。 アルド。

iMX DDR設定ツールのコード生成エラー || iMX95 チームの皆さん、こんにちは。 現在、 i.MX95 DDR構成のためにNXP Config Toolsを使用していますが、DDR初期化/タイミングコードの生成時に問題が発生しています。 以下のターゲットに対してDDR構成を作成/開きました。 プロセッサ: MIMX9596xxxxN コア: Cortex-M33 メモリタイプ： LPDDR5 - Ryzen RS2G32LO5D4FDB-23BT DDRデータレート： 6400 MT/s ランク数： 2 16ビットチャネル数: 2 DRAM構成： 16Gb：2Gb x8 ツールが表示するDRAMの総容量： 16384MB まず、独自のボードDDR設定を適用する前に、NXP i.MX95 19x19 EVKのデフォルトのLPDDR5構成を使用してDDR構成を検証しようとしています。 しかし、DDRコードを生成/更新しようとすると、Config Toolsの「問題」ウィンドウにエラーが表示されます。 コードの生成に失敗しました… コードプレビューウィンドウには以下が表示されます。 コード生成に失敗しました。 問題のスクリーンショットを参考資料として添付します。 Screenshot from 2026-09-15 11-40-00.png2026-09-15 11-40-00 のスクリーンショット.png Re: iMX DDR Config Tool Code Generation Error || iMX95 こんにちは、 この問題についてできるだけ早く確認し、最新情報を提供していただけませんか?現在、プロジェクトのスケジュールが迫っているため、迅速なサポートをいただけると大変ありがたいです。 Re: iMX DDR Config Tool Code Generation Error || iMX95 こんにちは、 .mexファイルを添付しました。参考までにファイルを示しますが、今回は 8GB LPDDR5 Rayson RS2G32LO5D4FDB-23BT を使用します。 Re: iMX DDR Config Tool Code Generation Error || iMX95 検証のため、IMX95LPD5EVK-19.mex ファイルを私に送っていただけますか？ Re: iMX DDR Config Tool Code Generation Error || iMX95 こんにちは、 はい、おっしゃっていたのと同じバージョンをダウンロードしてインストールしました。現在は Linux版 のツールを使っています。参考までにスクリーンショットを添付しました。 Screenshot from 2026-09-15 15-56-04.png2026-09-15 15-56-04 のスクリーンショット.png Re: iMX DDR Config Tool Code Generation Error || iMX95 Config_Tools_for_i.MX_26.06_x64 をインストールしましたか？最新バージョンの26.06ですか？ Linux版を使っていましたか?私はWindows版を使用しています。 検証のため、IMX95LPD5EVK-19.mex ファイルを私に送っていただけますか？ Re: iMX DDR Config Tool Code Generation Error || iMX95 こんにちは、 問題は依然として解決していない。.mexファイルを保存した後でもファイルをローカルディスクに保存しても、コードが生成されません。「コードの更新」をクリックすると、ツールから「コード生成に失敗しました」というエラーが表示されます。 Screenshot from 2026-09-15 15-31-15.png2026-09-15 15-31-15 のスクリーンショット.png Screenshot from 2026-09-15 15-36-58.png2026-09-15 15-36-58 のスクリーンショット.png Re: iMX DDR Config Tool Code Generation Error || iMX95 1.Config_Tools_for_i.MX_26.06_x64 をダウンロードしてインストールしました。 2. 新しい構成を作成し、「ボード」の下にある「IMX95LPD5EVK-19」を選択します。DDRツールを有効にして選択してください。 3. 「ファイル」→「保存」をクリックして、このプロジェクトをディスクに保存します。すると「コードの更新」が利用可能になります。 4. 「コードを更新」ボタンをクリックしてください。私の側にはエラーはありません。 yipingwang_0-1789463155201.pngyipingwang_0-1789463155201.png

S32 Design Studio Platform + SW32G2 + RTD version selection I refer to the S32G-VNP-RDB2 SOFTWARE ENABLEMENT GUIDE, the suggested software version was SW32G2_S32DS_3.4.0_D2012.zip + S32DS.3.4_b201217_win32.x86_64.exe + Real Time Drivers S32_RTD_4.4_1.0.0_HF01_D2102_DS_Updatesite.zip.  But I actually download S32DS.3.4_b201217_win32.x86_64.exe +SW32G2_S32DS_3.4.1_D2104.zip +SW32G_RTD_4.4_3.0.2_HF01_DS_updatesite_D2204.zip.  When I want to new the Light Up RGB LED and open peripherals tool, It will show "Peripherals: [SDK] Failed to update code - Code generation failed“. I'm not sure if the different software version combination causing these error. Re: S32 Design Studio Platform + SW32G2 + RTD version selection Hi, guang1994 I will reply to you internally. BR Joey

ISSUE: fix dependency for IMX_SEC_ENCLAVE and use-after-free Hello This is a follow up from this PR on github. It seems that the patches provided were at the end not applied as it's not present in lf-6.18.y. The Kconfig commit is needed to make sure that the Enclave driver cannot be y when NVMEM_IMX_OCOTP_SCU is m, thus avoiding probe defers. Otherwise you get this: root@colibri-imx8x-14985125:~# dmesg -l err [ 1.708145] rtc-ds1307 1-0068: hctosys: unable to read the hardware clock [ 2.072996] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.078636] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.084513] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.111555] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.117209] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.123110] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.141671] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.147303] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.153200] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.171418] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.177065] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.182929] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 5.744448] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 5.750217] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 5.756186] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 5.877660] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 5.888247] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 5.894232] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 10.324138] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 10.349783] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 10.374692] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 11.731697] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 11.738134] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 11.747692] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.284910] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.295720] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.307723] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.410541] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.426771] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.443446] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.644550] debugfs: '5f1a0000.phy' already exists in 'regmap' [ 12.655906] debugfs: '5f1a0000.phy' already exists in 'regmap' [ 12.670039] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.688813] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.696063] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.765923] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.775810] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.786887] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.839515] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.847285] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.853801] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.936721] nvmem imx-scu-ocotp0: cell mac raw len 6 unaligned to nvmem word size 4 [ 12.951328] nvmem imx-scu-ocotp0: cell mac raw len 6 unaligned to nvmem word size 4 [ 13.708903] genpd_provider mu_a1: failed to power off resource 214 ret -22 [ 16.701904] Bluetooth: hci0: unexpected event for opcode 0x0000 root@colibri-imx8x-14985125:~# On the second commit submitted, there has been some refactoring in the driver and I'm not sure if this has been addressed by NXP with commit 9703dfecc735 ("LF-15802: drivers: firmware: imx: Fix the SE driver remove") Could  maybe the SE team confirm? kinds regards Franz Re: ISSUE: fix dependency for IMX_SEC_ENCLAVE and use-after-free Hello, I see that this has not been solved yet, will check with internal software team and confirm about this. Best regards/Saludos, Aldo.

S32K31XEVB-Q100FlexCAN0 — 环回功能正常，但使用外部 CANoe 工具时无法接收信号。 板： S32K311-EVB 模块： FlexCAN0 工具：通过 J8 连接器连接的 Vector CANoe 调试探针： J-Link 我正在使用 FlexCAN0 在 S32K311-EVB 上实现 CAN 协议。 环回模式测试（正常）： 我首先在内部环回模式下实现了 FlexCAN0 并进行了测试。这成功了——发送的消息通过我的“void CanIf_RxIndication(const Can_HwType* Mailbox, const PduInfoType* PduInfoPtr )”正确接收。 处理功能，确认我的基本 FlexCAN0 配置（时钟设置、位定时、消息缓冲区初始化）运行正常。 外部通信测试（失败）： 然后我开始测试外部CAN通信： 在引脚配置中配置 PTA6 和 PTA7 引脚。 通过J8连接器将 Vector CANoe 连接到电路板。 在 CANoe 配置中，我取消勾选了“CAN 环回模式”。 连接12伏适配器 CANoe 开始传输——CANoe 显示正在发送 CAN 帧。 然而，在 S32K311 端，没有任何信号被接收——CanIf_RxIndication （在环回模式下正常工作的同一函数）从未被调用/触发信号。 我使用 Segger RTT Viewer 通过 JTAG 进行调试。 配置 Sami2098_0-1789478804307.png Sami2098_1-1789478831337.png Sami2098_2-1789478911944.png Sami2098_3-1789478932611.png 此致。   Re: S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool 你好@Sami2098 ， 请问您目前使用的是哪个RTD版本？ 我们社区里有一些例子可以作为参考： 回复：S32K311 的 CAN 示例 - NXP 社区 示例 S32K312 CAN 发送和接收，使用轮询模式 DS3.5 RTD300 [RTD600 MCAL & IP] S32K3X4EVB - T172 FlexCAN 示例（中断/轮询） FlexCAN配置整体看起来没问题。请确认 PTA6/7 是否分别配置为输入和输出，并且您确实调用了 Siul2_Port_Ip_Init() API 来初始化端口？ Julin_AragnM_2-1789514266922.pngJulin_AragnM_2-1789514266922.png 由于您使用的是 S32K1XEVB，使用的收发器是 FS23，当 FS23 处于调试模式时，CAN 收发器默认设置为运行模式，因此无需设置 CAN_MODE = 0b1x。 我还建议检查 S32K311<->CANoe 之间配置的比特率和采样点是否相同。 最后，如果您有逻辑分析仪或示波器，能否分享一下CANTXD、CANRXD、CANH 和 CANL 信号？ 此致， 朱利安

LPSPI3 registers inaccessible from Linux (Bus error on devmem read) — external SPI device on P11 EXP Summary I'm trying to bring up two external MCP2515 CAN controllers (Waveshare 2‑CH CAN HAT, confirmed working on a genuine Raspberry Pi) on the FRDM‑IMX93 board's P11 EXPI header, using LPSPI3 on GPIO_IO08‑11 (the pins that match the Raspberry‑Pi‑compatible header positions per UM12181 Table 21). After fixing every device‑tree‑level issue I could find (power, pinmux, chip‑select, pinctrl‑assert‑gpios), the SPI clock (SCK) never toggles on the physical header pin, and a direct register read of the LPSPI3 block causes a Bus error. A different, known‑working peripheral (LPUART1) reads back fine from the same address space. This points to a resource/bus access restriction (RDC or similar) rather than anything fixable from the Linux device tree. Board / software Board: FRDM‑IMX93 (NXP), SoC: MIMX9352CVVXMAB BSP: NXP i.MX Release Distro, kernel 6.18.2-1.0.0-gf49f45233f7b Target peripheral: lpspi3 (spi@42550000, aliased spi2 in /aliases, real dts label confirmed via /proc/device-tree/__symbols__ to be lpspi3) External device under test: 2× MCP2515 (Waveshare 2‑CH CAN HAT) on CS0/CS1 What's already confirmed working (ruled out) Power to the header. reg_vexp_3v3 / reg_vexp_5v are regulator-fixed nodes that default to disabled (regulator_summary showed use=0). Added regulator-always-on + regulator-boot-on via overlay fragments targeting &reg_vexp_3v3 / &reg_vexp_5v (confirmed real labels via __symbols__). Verified 3.3 V / 5 V physically present on P11 afterwards. Pinmux. GPIO_IO08‑11 correctly muxed to LPSPI3_PCS0/SIN/SOUT/SCK using the official macros from imx93-pinfunc.h. input_reg/input_val are 0x0000/0x0 for these three functions, so no DAISY‑chain select is required (ruled out via macro inspection, no separate register needed). Chip‑select. cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>, <&gpio2 7 GPIO_ACTIVE_LOW>; (bit‑banged GPIO CS, matching NXP's own upstream board‑support pattern for this node). Confirmed via cat /sys/kernel/debug/gpio and multimeter/logic‑analyzer: CS0 toggles correctly and physically reaches the header pin. pinctrl-assert-gpios. NXP's own upstream &lpspi3 reference for this board includes pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; (this line does not appear in most public guides, only in the board's own dts patch). Added it; confirmed via /proc/device-tree/__symbols__ that pcal6408 resolves, and via cat /sys/kernel/debug/gpio that the GPIO is asserted (out hi) once lpspi3's default pinctrl state is requested. Overlay applies cleanly. No FDT_ERR_NOTFOUND from U‑Boot's fdt apply; /sys/bus/spi/devices/ shows spi2.0 and spi2.1 registered by the SPI core. ERR051608 (LPSPI TCR[PRESCALE] errata). Checked spi-fsl-lpspi.c history — the fix (prescale_max = 1 for fsl,imx93-spi) landed in mainline Aug 2024 / stable 6.6.51 & 6.10.10 Sept 2024, well before this kernel version (6.18.2), and the compatible string (fsl,imx93-spi) is already present in the base board dts, so the driver should auto‑apply this limit. Not ruled out with certainty (no direct register confirmation of the actual PRESCALE field written), but timeline strongly suggests it's already handled. The actual symptom With CS0/CS1, MISO, MOSI, SCK probed on the physical P11 pins (multimeter, then a logic analyzer at 10–20 MSa/s triggered on CS0 falling edge) while continuously retrying a transfer (spidev_test in a loop, and separately by repeatedly forcing mcp251x re‑probe via echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind): CS0 toggles. Confirmed on both multimeter and logic analyzer. SCK never toggles. Flat, no activity, regardless of continuous transfer attempts. MOSI never toggles. Both MCP2515s fail identically: mcp251x spi2.0/spi2.1: MCP251x didn't enter in conf mode after reset / Probe failed, err=110 (ETIMEDOUT) — i.e. the driver's own SPI‑level reset+read‑CANSTAT sequence gets no response, consistent with SCK never leaving the SoC. Root cause narrowed to clock / bus access, not device tree   # clk_enable_count AND clk_prepare_count are both 0, despite the controller # actively being used in a continuous retry loop $ cat /sys/kernel/debug/clk/clk_summary | grep -i lpspi3 lpspi3_root 0 0 0 50000000 0 0 50000 N deviceless no_connection_id lpspi3 0 0 0 50000000 0 0 50000 N 42550000.spi per $ cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count 0 lpspi3's functional (per) clock shows clk_enable_count=0 and clk_prepare_count=0 even while 42550000.spi (the real, bound consumer) is actively attempting transfers in a loop (spidev_test loop, and separately by repeatedly forcing mcp251x re‑probe via echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind). clk_prepare() is the step before clk_enable() — the fact that it's never even called suggests the driver's transfer path (or a pm_runtime_get() in front of it) never reaches its own clock‑management code for this device, rather than the clock being requested and then failing to gate on. I don't have kernel build tooling to add tracepoints, so I can't yet tell whether this is a pm_runtime resume that silently no‑ops, a missing dependency (e.g. a power-domains reference this board's lpspi3 node needs but doesn't have), or something else in spi-fsl-lpspi.c for this specific kernel build. The decisive register‑level test — direct devmem read:   $ devmem 0x44380000 32 # LPUART1 base — known-good peripheral 0x04040007 $ devmem 0x42550000 32 # LPSPI3 base (VERID register) Bus error (core dumped) A completely unrelated, working peripheral (LPUART1, used for the debug console) reads back fine from the same CPU/bus context; LPSPI3's base address faults on a plain 32‑bit read. I initially suspected a Resource Domain Controller (RDC) style access restriction specific to this board, but several NXP Community threads (i.MX25/i.MX6ULL "devmem return bus error", i.MX8MP I2C‑from‑DSP thread) point to the same symptom being the normal, expected result of touching an AIPS‑bus peripheral whose clock is gated off — not necessarily a security/domain restriction. That's consistent with clk_enable_count=0 above and makes me now think this is a clock‑enablement bug in the driver/PM path for this device, not (necessarily) an RDC block — though I can't fully rule out RDC without lower‑level tooling. This isn't a general i.MX93 LPSPI3 limitation For context: a separate NXP Community thread ([iMX93AUTO EVK] SPI Configuration for QCA7006AQ, community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ-with-imx93AUTO-EVK/m-p/1839847) shows someone successfully driving an external SPI device over LPSPI3 on the same GPIO_IO08‑11 pins on the i.MX93‑11x11‑EVK (same SoC), using:   c &lpspi3 { compatible = "fsl,imx93-spi", "fsl,lpspi"; cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>; status = "okay"; ... }; &iomuxc { pinctrl_lpspi3_qca: lpspi3grp { fsl,pins = < MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x3fe MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x3fe MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x3fe MX93_PAD_GPIO_IO08__LPSPI3_PCS0 0x3fe /* native PCS0, not plain GPIO */ >; }; }; I tried this exact variant (native LPSPI3_PCS0/LPSPI3_PCS1 instead of plain GPIO2_IO08/GPIO2_IO07, plus the explicit compatible override) on the FRDM board — no change, devmem 0x42550000 32 still faults, clk_enable_count/clk_prepare_count still 0. This rules out pinmux/compatible‑string choice as the cause on this board, and — combined with the EVK success — makes me suspect something FRDM‑board‑specific (either in imx93-11x11-frdm.dts's handling of lpspi3, or in this board's U‑Boot/ATF‑level RDC/power‑domain setup) rather than a general i.MX93 SoC or mainline‑driver limitation. Questions for NXP Given clk_prepare_count/clk_enable_count stay at 0 for lpspi3 even while the SPI core is actively driving transfers to a bound spi2.0/spi2.1 device, and a plain register read of 0x42550000 bus‑faults — what's missing from the FRDM‑IMX93's lpspi3 device‑tree node (or from board‑level RDC/power‑domain setup) that the working EVK config doesn't need? Is LPSPI3 on the FRDM‑IMX93 intentionally reserved for another domain (e.g. Cortex‑M33 / secure world, or the on‑board MAYA‑W2 tri‑radio module path) at the board's default RDC/ATF configuration, unlike the EVK? Is there a reference imx93-11x11-frdm-lpspi.dts (analogous to imx93-11x11-evk-lpspi.dts) for using LPSPI3 externally via P11 on this specific board? How to reproduce Base board dtb: stock imx93-11x11-frdm.dtb shipped with the i.MX Release Distro image (unmodified NXP lpspi3 + pcal6408 + reg_vexp_3v3/reg_vexp_5v nodes — all confirmed present via __symbols__). Apply the overlay described above (regulator always‑on, pinctrl + cs‑gpios + pinctrl‑assert‑gpios on &lpspi3; tried both plain‑GPIO and native‑PCS0/PCS1 pinmux variants, same result both times). Bind spidev (built‑in, CONFIG_SPI_SPIDEV=y) manually to spi2.0:   echo spidev > /sys/bus/spi/devices/spi2.0/driver_override echo spi2.0 > /sys/bus/spi/drivers/spidev/bind spidev_test -D /dev/spidev2.0 -s 1000000 -v — "succeeds" (no I/O error) but RX data is not a loopback of TX even with MOSI/MISO physically shorted; SCK never toggles on a logic analyzer regardless. cat /sys/kernel/debug/clk/clk_summary | grep lpspi3 → clk_enable_count=0. cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count → 0. devmem 0x42550000 32 → Bus error. devmem 0x44380000 32 (LPUART1) → succeeds normally. Happy to provide the full overlay source, dmesg, and clk_summary/gpio dumps if useful.

FRDM-IMX93: LPSPI3 registers inaccessible from Linux (Bus error on devmem read) — external SPI devic Summary I'm trying to bring up two external MCP2515 CAN controllers (Waveshare 2‑CH CAN HAT, confirmed working on a genuine Raspberry Pi) on the FRDM‑IMX93 board's P11 EXPI header, using LPSPI3 on GPIO_IO08‑11 (the pins that match the Raspberry‑Pi‑compatible header positions per UM12181 Table 21). After fixing every device‑tree‑level issue I could find (power, pinmux, chip‑select, pinctrl‑assert‑gpios), the SPI clock (SCK) never toggles on the physical header pin, and a direct register read of the LPSPI3 block causes a Bus error. A different, known‑working peripheral (LPUART1) reads back fine from the same address space. This points to a resource/bus access restriction (RDC or similar) rather than anything fixable from the Linux device tree. Board / software Board: FRDM‑IMX93 (NXP), SoC: MIMX9352CVVXMAB BSP: NXP i.MX Release Distro, kernel 6.18.2-1.0.0-gf49f45233f7b Target peripheral: lpspi3 (spi@42550000, aliased spi2 in /aliases, real dts label confirmed via /proc/device-tree/__symbols__ to be lpspi3) External device under test: 2× MCP2515 (Waveshare 2‑CH CAN HAT) on CS0/CS1 What's already confirmed working (ruled out) Power to the header. reg_vexp_3v3 / reg_vexp_5v are regulator-fixed nodes that default to disabled (regulator_summary showed use=0). Added regulator-always-on + regulator-boot-on via overlay fragments targeting &reg_vexp_3v3 / &reg_vexp_5v (confirmed real labels via __symbols__). Verified 3.3 V / 5 V physically present on P11 afterwards. Pinmux. GPIO_IO08‑11 correctly muxed to LPSPI3_PCS0/SIN/SOUT/SCK using the official macros from imx93-pinfunc.h. input_reg/input_val are 0x0000/0x0 for these three functions, so no DAISY‑chain select is required (ruled out via macro inspection, no separate register needed). Chip‑select. cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>, <&gpio2 7 GPIO_ACTIVE_LOW>; (bit‑banged GPIO CS, matching NXP's own upstream board‑support pattern for this node). Confirmed via cat /sys/kernel/debug/gpio and multimeter/logic‑analyzer: CS0 toggles correctly and physically reaches the header pin. pinctrl-assert-gpios. NXP's own upstream &lpspi3 reference for this board includes pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; (this line does not appear in most public guides, only in the board's own dts patch). Added it; confirmed via /proc/device-tree/__symbols__ that pcal6408 resolves, and via cat /sys/kernel/debug/gpio that the GPIO is asserted (out hi) once lpspi3's default pinctrl state is requested. Overlay applies cleanly. No FDT_ERR_NOTFOUND from U‑Boot's fdt apply; /sys/bus/spi/devices/ shows spi2.0 and spi2.1 registered by the SPI core. ERR051608 (LPSPI TCR[PRESCALE] errata). Checked spi-fsl-lpspi.c history — the fix (prescale_max = 1 for fsl,imx93-spi) landed in mainline Aug 2024 / stable 6.6.51 & 6.10.10 Sept 2024, well before this kernel version (6.18.2), and the compatible string (fsl,imx93-spi) is already present in the base board dts, so the driver should auto‑apply this limit. Not ruled out with certainty (no direct register confirmation of the actual PRESCALE field written), but timeline strongly suggests it's already handled. The actual symptom With CS0/CS1, MISO, MOSI, SCK probed on the physical P11 pins (multimeter, then a logic analyzer at 10–20 MSa/s triggered on CS0 falling edge) while continuously retrying a transfer (spidev_test in a loop, and separately by repeatedly forcing mcp251x re‑probe via echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind): CS0 toggles. Confirmed on both multimeter and logic analyzer. SCK never toggles. Flat, no activity, regardless of continuous transfer attempts. MOSI never toggles. Both MCP2515s fail identically: mcp251x spi2.0/spi2.1: MCP251x didn't enter in conf mode after reset / Probe failed, err=110 (ETIMEDOUT) — i.e. the driver's own SPI‑level reset+read‑CANSTAT sequence gets no response, consistent with SCK never leaving the SoC. Root cause narrowed to clock / bus access, not device tree   # clk_enable_count is 0 despite the controller actively being used $ cat /sys/kernel/debug/clk/clk_summary | grep -i lpspi3 lpspi3_root 0 0 0 50000000 0 0 50000 N deviceless no_connection_id lpspi3 0 0 0 50000000 0 0 50000 N 42550000.spi per lpspi3's functional (per) clock shows enable_count=0 even while 42550000.spi (the real, bound consumer) is actively attempting transfers in a loop — it isn't simply "unused" (compare to lpspi1/2/4, which are deviceless and also show 0, so that alone isn't conclusive). The decisive test — direct register read via devmem:   $ devmem 0x44380000 32 # LPUART1 base — known-good peripheral 0x04040007 $ devmem 0x42550000 32 # LPSPI3 base (VERID register) Bus error (core dumped) A completely unrelated, working peripheral (LPUART1, used for the debug console) reads back fine from the same CPU/bus context. LPSPI3's base address faults on a plain 32‑bit read, before any clock‑gating or pinmux consideration even matters. This looks like a Resource Domain Controller (RDC) — or similar access‑control mechanism — blocking the Cortex‑A55 (Linux) domain from this peripheral's address range at the hardware level, independent of anything configurable from the Linux device tree. Questions for NXP Is LPSPI3 on the FRDM‑IMX93 intentionally reserved for another domain (e.g. Cortex‑M33 / secure world) in the board's default RDC configuration, making it unusable from Linux without additional SPL/ATF/TF‑A level reconfiguration? If so, is there a documented way to reassign LPSPI3 bus access to the Cortex‑A55 non‑secure domain (RDC config in U‑Boot SPL, or an OP‑TEE/TF‑A change), or is this simply not supported as an external SPI on this board's P11 header despite GPIO_IO08‑11 being broken out there? Is this specific to my board/kernel build, or a known characteristic of the default FRDM‑IMX93 BSP? A reference imx93-11x11-frdm-lpspi.dts (analogous to imx93-11x11-evk-lpspi.dts for the EVK) would be very helpful if one exists. How to reproduce Base board dtb: stock imx93-11x11-frdm.dtb shipped with the i.MX Release Distro image (unmodified NXP lpspi3 + pcal6408 + reg_vexp_3v3/reg_vexp_5v nodes — all confirmed present via __symbols__). Apply the overlay described above (regulator always‑on, pinctrl + cs‑gpios + pinctrl‑assert‑gpios on &lpspi3). Bind spidev (built‑in, CONFIG_SPI_SPIDEV=y) manually to spi2.0:   echo spidev > /sys/bus/spi/devices/spi2.0/driver_override echo spi2.0 > /sys/bus/spi/drivers/spidev/bind spidev_test -D /dev/spidev2.0 -s 1000000 -v — transfer "succeeds" (no I/O error) but RX data is not a loopback of TX even with MOSI/MISO physically shorted. devmem 0x42550000 32 → Bus error. Happy to provide the full overlay source, dmesg, and clk_summary/gpio dumps if useful.

S32K31XEVB-Q100FlexCAN0 — ループバックは正常に動作しますが、外部CANoeツールでは受信できません。 ボード: S32K311-EVB モジュール: FlexCAN0 ツール: J8コネクタで接続されたベクターCANoe デバッグプローブ: Jリンク 私はFlexCAN0を使ってS32K311-EVBでCANプロトコルを実装しています。 ループバックモードテスト（動作確認済み）： 私はまず、FlexCAN0を内部ループバックモードで実装し、テストしました。これはうまくいきました。送信されたメッセージは、私の「void CanIf_RxIndication(const Can_HwType* Mailbox, const PduInfoType* PduInfoPtr )」を通じて正しく受信されました。 処理機能により、FlexCAN0の基本設定（クロック設定、ビットタイミング、メッセージバッファ初期化）が正しく機能していることを確認します。 外部コミュニケーションテスト(効果なし): 次に外部CAN通信のテストに移りました: ピン構成でPTA6とPTA7のピンを設定してください。 J8コネクターでVector CANoeをボードに接続しました。 CANoe構成では、私は チェックされていない「CAN Loopback Mode」 12Vアダプターを取り付ける CANoeの送信を開始しました — CANoeはCANフレームを送信していることを示しています。 しかし、S32K311側では何も受信されず、 CanIf_RxIndication （ループバックモードでは正しく動作していた同じ関数）は呼び出されたりトリガーされたりしません。 デバッグには、JTAG を使用した Segger RTT Viewer を使用しています。 設定 Sami2098_0-1789478804307.png Sami2098_1-1789478831337.png Sami2098_2-1789478911944.png Sami2098_3-1789478932611.png よろしくお願いします。   Re: S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool こんにちは、 @Sami2098 さん。 現在使っているRTDバージョンを教えてもらえますか? 私たちのコミュニティには参考にできるいくつかの例があります: Re: S32K311のCAN例 - NXPコミュニティ ポーリングモードDS3.5 RTD300を使用したS32K312 CAN送受信の例 [RTD600 MCAL & IP] S32K3X4EVB-T172 FlexCAN 割り込みのサンプル / ポーリング FlexCANの設定は全体的に問題なさそうです。PTA6/7がそれぞれ入力と出力として設定されていること、そして実際にSiul2_Port_Ip_Init()APIを呼び出してポートの初期化をしているのか確認できますか? Julin_AragnM_2-1789514266922.pngJulin_AragnM_2-1789514266922.png S32K1XEVBを使っている場合、使用されているトランシーバはFS23で、FS23がデバッグモードの場合、CANトランシーバはデフォルトでアクティブモードに設定されているため、CAN_MODE = 0b1xを設定する必要はありません。 S32K311<->CANoeの間で設定されているビットレートとサンプリングポイントが同じであることを確認することもお勧めします。 最後に、もしロジックアナライザーやオシロスコープをお持ちなら、CANTXD、CANRXD、CANH、CANLの信号を共有してもらえますか? よろしくお願いします、 ジュリアン

LPSPI3レジスタがLinuxからアクセス不能(devmem読み取り時のバスエラー)— P11 EXP上の外部SPIデバイス 概要 FRDM-IMX93ボードの P11 EXPIヘッダーに LPSPI3 を使って、2つの外部MCP2515 CANコントローラー(Waveshare 2-CHAN HAT、本物のRaspberry Piで動作確認)を起動しようとしています(GPIO_IO08 UM12181表21参照、Raspberry-Pi互換ヘッダー位置に一致するピンです)。 見つけたデバイスツリーレベルの問題(電源、ピンマックス、チップセレクト、pinctrl-assert-gpio)をすべて修正した後、SPIクロック(SCK)は物理ヘッダーピンを切り替え ず 、LPSPI3ブロックの直接レジスタ読み込みは バスエラーを引き起こします。別の既知の動作ペリフェラル(LPUART1)は同じアドレス空間から問題なく読み返します。これはLinuxデバイスツリーから修正できるものではなく、リソース/バスアクセス制限(RDCなど)を示しています。 ボード/ソフトウェア ボード：FRDM-IMX93（NXP）、SoC：MIMX9352CVVXMAB BSP: NXP i.MX リリース ディストリビューション、カーネル 6.18.2-1.0.0-gf49f45233f7b ターゲット周辺機器:lpspi3(spi@42550000、/aliasesでエイリアスされたspi2、/proc/device-tree/で確認された本物のdtsラベル__symbols__ lpspi3) テスト中の外部デバイス:CS0/CS1上の2× MCP2515(Waveshare 2-CH CAN HAT) 既に動作が確認されているもの（除外されたもの） ヘッダーに電力を供給します。reg_vexp_3v3 / reg_vexp_5v は、デフォルトで無効になっているレギュレータ固定ノードです (regulator_summary では use=0 と表示されています)。レギュレーター常時オン+レギュレーターブートオンを追加し、オーバーレイフラグメントのターゲティング&reg_vexp_3v3/&reg_vexp_5vを追加しました( __symbols__で実際のラベルが確認されました)。その後、P11に3.3V/5Vの電圧が物理的に存在していることを確認しました。 Pinmux。GPIO_IO08-11 は、imx93-pinfunc.h の公式マクロを使用して、LPSPI3_PCS0/SIN/SOUT/SCK に正しく多重化されています。input_reg/input_valはこれら3つの機能に対して0x0000/0x0であるため、DAISYチェーンセレクトは不要です(マクロ検査で除外され、個別レジスタは不要)。 チップセレクト。cs-gpios = 、（ビットバンギングされたGPIO CS。このノードに対するNXP独自のアップストリームボードサポートパターンに一致）。cat /sys/kernel/debug/gpio とマルチメーター/ロジックアナライザーで確認したところ、 CS0 は正しくトグルし、物理的にヘッダーピンに到達していることがわかりました。 pinctrl-assert-gpios。NXP独自のこのボード用アップストリーム&lpspi3リファレンスには、pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; が含まれています（この行はほとんどの公開ガイドには記載されておらず、ボード独自のdtsパッチにのみ記載されています）。追加しました。/proc/device-tree/__symbols__ で pcal6408 が解決されること、および cat /sys/kernel/debug/gpio で lpspi3 のデフォルトの pinctrl 状態が要求されると GPIO がアサートされる (出力 hi) ことを確認しました。 オーバーレイはきれいに適用されます。U-Bootのfdt applyからFDT_ERR_NOTFOUNDは発生せず、/sys/bus/spi/devices/にはSPIコアによってspi2.0とspi2.1が登録されていることが示されています。 ERR051608 (LPSPI TCR[PRESCALE] のエラータ)。spi-fsl-lpspi.c を確認しました履歴 — 修正（fsl、imx93-spi の prescale_max = 1）は、2024年8月 / 安定版 6.6.51 でメインラインに取り込まれました。2024年9月6.10日は、このカーネルバージョン(6.18.2)よりずっと前のもので、互換文字列(fsl、imx93-spi)はすでにベースボードのdtsに存在しているため、ドライバはこの制限を自動的に適用すべきです。完全に否定できるわけではないが（実際にPRESCALEフィールドが書き込まれたという直接的なレジスタ確認はない）、タイムラインから判断すると既に処理済みである可能性が高い。 実際の症状 CS0/CS1、MISO、MOSI、SCKが物理的なP11ピン(マルチメーター、CS0落ち込みエッジで10〜20 MSa/sのロジックアナライザーをトリガー)でプローブしつつ、転送を繰り返し再試行(ループ内でspidev_testし、Echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bindを経て繰り返しMCP251xの再プローブを強制することで別々に実行しました): CS0の切り替え。マルチメーターとロジックアナライザーの両方で確認済み。 SCKは切り替えません。継続的に転送を試みても、変化はなく、活動は見られない。 MOSIは切り替えません。 両方のMCP2515が同じように失敗します：mcp251x spi2.0/spi2.1：リセット/プローブ失敗後、MCP251xはコンフモードに入らなかった。err=110(ETIMEDOUT)。つまり、ドライバ自身のSPIレベルのリセット+read-CANSTATシーケンスは応答せず、SCKがSoCを出ないのと一致している。 根本原因はデバイスツリーではなくクロック/バスアクセスに絞られます   # clk_enable_count AND clk_prepare_count are both 0, despite the controller # actively being used in a continuous retry loop $ cat /sys/kernel/debug/clk/clk_summary | grep -i lpspi3 lpspi3_root 0 0 0 50000000 0 0 50000 N deviceless no_connection_id lpspi3 0 0 0 50000000 0 0 50000 N 42550000.spi per $ cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count 0 LPSPI3の機能クロック(per)はclk_enable_count=0 、 clk_prepare_count=0を示します。これは425550000.SPI(実際のバインドされた消費者)がループ(spidev_testループ、そしてEcho SPI2.>0を経て/sys/bus/spi/ドライバ/mcp251x/bindを繰り返し強制してMCP251Xを再プローブを繰り返し試みている間でもです)。clk_prepare()はclk_enable() の前の ステップです。呼び出されないことから、ドライバーの転送経路(またはその前のpm_runtime_get())がこのデバイスの独自のクロック管理コードに到達しないことを示唆しており、クロックを要求してゲートオンに失敗したわけではありません。 トレースポイントを追加するカーネルビルドツールは持っていないので、これがサイレントノーオプスの繰り返しpm_runtimeなのか、依存関係が欠落しているのか(例:power-domainsがこのボードのlpspi3ノードが必要とするが持っていない)、あるいはこの特定のカーネルビルドに対するspi-fsl-lpspi.cの別の何かなのか、まだ判断がつきません。 決定的なレジスタレベルのテスト ― 直接的なdevmem読み取り：   $ devmem 0x44380000 32 # LPUART1 base — known-good peripheral 0x04040007 $ devmem 0x42550000 32 # LPSPI3 base (VERID register) Bus error (core dumped) 全く関係のない動作するペリフェラル(LPUART1、デバッグコンソール用)は同じCPU/バスコンテキストから問題なく読み戻します。 LPSPI3のベースアドレスフォルトは、単なる32ビット読み取りで発生します。当初はこの基板特有のリソースドメインコントローラー(RDC)スタイルのアクセス制限かと疑いましたが、いくつかのNXPコミュニティスレッド(i.MX25/i.MX6ULL「devmem return bus error」やi.MX8MP I2C-from-DSPスレッド)は、 クロックが制限されているAIPSバス周辺機器に触れた場合の正常で予想される症状 であり、必ずしもセキュリティやドメイン制限ではないと指摘しています。これは上記のclk_enable_count=0と一致しており、これはこの デバイスのドライバー/PMパスのクロック有効化バグであり、必ずしもRDCブロックではないと考えています。ただし、低レベルのツールがなければRDCを完全に除外することはできません。 これは一般的な i.MX93 LPSPI3 の制限ではありません 参考までに:別のNXPコミュニティThread([iMX93AUTO EVK] SPI Configuration for QCA7006AQ, community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ-with-imx93AUTO-EVK/m-p/1839847)i.MX93-11x11-EVK （同じSoC）の同じGPIO_IO08-11ピン上で、LPSPI3を介して外部SPIデバイスを正常に駆動する様子が示されています。   c &lpspi3 { compatible = "fsl,imx93-spi", "fsl,lpspi"; cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>; status = "okay"; ... }; &iomuxc { pinctrl_lpspi3_qca: lpspi3grp { fsl,pins = < MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x3fe MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x3fe MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x3fe MX93_PAD_GPIO_IO08__LPSPI3_PCS0 0x3fe /* native PCS0, not plain GPIO */ >; }; }; FRDM ボードでこのまったく同じバリアント (通常の GPIO2_IO08/GPIO2_IO07 の代わりにネイティブ LPSPI3_PCS0/LPSPI3_PCS1、さらに明示的な互換性オーバーライド) を試しましたが、変化はありませんでした。devmem 0x42550000 32 は依然としてフォルトを起こし、clk_enable_count/clk_prepare_count は依然として 0 です。これにより、このボードではピンmux/compatible-stringの選択が原因ではないことがわかり、EVKの成功と合わせて、 FRDMボード固有の何か（imx93-11x11-frdm.dtsのlpspi3 の処理、またはこのボードの U-Boot/ATF レベルの RDC/電源ドメイン設定）によるものであり、一般的な i.MX93 SoC またはメインラインドライバの制限ではありません。 NXPへの質問 SPIコアがバインドされたspi2.0/spi2.1デバイスへの転送をアクティブに実行している間も、lpspi3のclk_prepare_count/clk_enable_countが0のままであり、0x42550000の単純なレジスタ読み取りでバスフォルトが発生する場合、FRDM-IMX93のlpspi3デバイスツリーノード（またはボードレベルのRDC/電源ドメイン設定）には、正常に動作するEVK構成に不要なものが欠けているのでしょうか？ FRDM-IMX93 の LPSPI3 は、別のドメイン (例:Cortex-M33 / セキュアワールド、またはオンボードの MAYA-W2 トライラジオモジュールパス）は、EVK とは異なり、ボードのデフォルトの RDC/ATF 構成で動作しますか？ この特定のボードでP11経由でLPSPI3を外部から使用するための参照ファイルimx93-11x11-frdm-lpspi.dts（imx93-11x11-evk-lpspi.dtsに相当）はありますか？ 再現方法 ベースボードdtb: i.MXリリースディストリビューションイメージに同梱されている標準のimx93-11x11-frdm.dtb（変更されていないNXP lpspi3 + pcal6408 + reg_vexp_3v3/reg_vexp_5vノード - すべて__symbols__経由で存在が確認されています）。 上記のオーバーレイを適用します（レギュレータ常時オン、&lpspi3 上で pinctrl + cs-gpios + pinctrl-assert-gpios を使用。plain-GPIO と native-PCS0/PCS1 pinmux の両方のバリアントを試しましたが、どちらの場合も同じ結果でした）。 spidev（組み込み、CONFIG_SPI_SPIDEV=y）を手動でspi2.0にバインドします。   echo spidev > /sys/bus/spi/devices/spi2.0/driver_override echo spi2.0 > /sys/bus/spi/drivers/spidev/bind spidev_test -D /dev/spidev2.0-s 1000000 -v — 「成功」(I/O エラーなし) だが、MOSI/MISO を物理的に短絡しても RX データは TX のループバックではない。ロジック アナライザで SCK がトグルすることはない。 cat /sys/kernel/debug/clk/clk_summary | grep lpspi3 → clk_enable_count=0. cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count → 0. devmem 0x42550000 32 → バスエラー。devmem 0x44380000 32 (LPUART1) → 正常に成功しました。 必要であれば、オーバーレイのソースコード、dmesgログ、clk_summary/gpioダンプなど、すべての情報を提供いたします。

iMX DDR Config Tool Code Generation Error || iMX95 Hi Team, We are currently working with the NXP Config Tools for i.MX95 DDR configuration and are facing an issue while generating the DDR initialization/timing code. We created/opened the DDR configuration for the following target: Processor: MIMX9596xxxxN Core: Cortex-M33 Memory Type: LPDDR5 - Ryzen RS2G32LO5D4FDB-23BT DDR Data Rate: 6400 MT/s Number of Ranks: 2 Number of 16-bit Channels: 2 DRAM Configuration: 16Gb:2Gb x8 Total DRAM Density shown by the tool: 16384 MB Initially, we are trying to validate the DDR configuration using the NXP i.MX95 19x19 EVK default LPDDR5 configuration before applying our custom board DDR settings. However, when we try to generate/update the DDR code, the Config Tools reports an error in the Problems window: “Failed to generate code…” and the Code Preview window shows: “Code generation failed.” The screenshot of the issue is attached for reference: Screenshot from 2026-09-15 11-40-00.pngScreenshot from 2026-09-15 11-40-00.png Re: iMX DDR Config Tool Code Generation Error || iMX95 Hi, Could you please check and provide an update on this issue at the earliest? We are currently running short on the project timeline, so your prompt support would be greatly appreciated. Re: iMX DDR Config Tool Code Generation Error || iMX95 Hi, I have attached the .mex file for your reference but we are going to use 8GB LPDDR5 Rayson RS2G32LO5D4FDB-23BT. Re: iMX DDR Config Tool Code Generation Error || iMX95 Would you please send your IMX95LPD5EVK-19.mex to me to do verification? Re: iMX DDR Config Tool Code Generation Error || iMX95 Hi,  Yes, we have downloaded and installed the same version that you mentioned. We are currently using the Linux version of the tool. I have attached a screenshot for your reference. Screenshot from 2026-09-15 15-56-04.pngScreenshot from 2026-09-15 15-56-04.png Re: iMX DDR Config Tool Code Generation Error || iMX95 Did you install Config_Tools_for_i.MX_26.06_x64? The latest version 26.06? Did you using the Linux version? I am using the Windows version. Would you please send your IMX95LPD5EVK-19.mex to me to do verification? Re: iMX DDR Config Tool Code Generation Error || iMX95 Hi,  The issue still persists. Even after saving the .mex file to the local disk, the code is not being generated. When I click Update Code, the tool throws the error “Code generation failed.” Screenshot from 2026-09-15 15-31-15.pngScreenshot from 2026-09-15 15-31-15.png Screenshot from 2026-09-15 15-36-58.pngScreenshot from 2026-09-15 15-36-58.png Re: iMX DDR Config Tool Code Generation Error || iMX95 1. I downloaded and installed Config_Tools_for_i.MX_26.06_x64. 2. I created a new configuration, select "IMX95LPD5EVK-19" under "Boards". Enable DDR tool and select it. 3. Click "File->Save" to save this project to the disk. Then "Update Code" is avaiable. 4. Click "Update Code" button, there is no error on my side. yipingwang_0-1789463155201.pngyipingwang_0-1789463155201.png

S32 Design Studio プラットフォーム + SW32G2 + RTD バージョン選択 私はS32G-VNP-RDB2 ソフトウェア イネーブルメント ガイドを参照しており、推奨されているソフトウェアバージョンはSW32G2_S32DS_3.4.0_D2012.zip+R S32DS.3.4_b201217_win32.x86_64.exe+リアルタイム・ドライバ S32_RTD_4.4_1.0.0_HF01_D2102_DS_Updatesite.zipでした。 しかし、実際にダウンロードしたのは S32DS.3.4_b201217_win32.x86_64.exe +SW32G2_S32DS_3.4.1_D2104.zip +SW32G_RTD_4.4_3.0.2_HF01_DS_updatesite_D2204.zip です。 RGBLEDを点灯してペリフェラルを起動しようとすると、「ペリフェラル:[SDK] コード更新に失敗 - コード生成に失敗」と表示されます。ソフトウェアのバージョンが違うからこそエラーが原因なのかは分かりません。 Re: S32 Design Studio Platform + SW32G2 + RTD version selection こんにちは、 guang1994 社内で返信させていただきます。 BR ジョーイ

S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool Board: S32K311-EVB Module: FlexCAN0 Tool: Vector CANoe connected via J8 connector Debug probe:  J-Link  I am implementing the CAN protocol on the S32K311-EVB using FlexCAN0. Loopback mode test (working): I first implemented and tested FlexCAN0 in internal loopback mode. This worked successfully — messages transmitted were correctly received back through my "void CanIf_RxIndication(const Can_HwType* Mailbox, const PduInfoType* PduInfoPtr )"  handling function, confirming that my basic FlexCAN0 configuration (clock setup, bit timing, message buffer initialization) is functioning correctly. External communication test (not working): I then moved to testing external CAN communication: Configure PTA6 and PTA7 pin in pin configuration. Connected Vector CANoe to the board via the J8 connector. In CANoe configuration, I unchecked "CAN Loopback Mode." Attach 12 V Adapter  Started CANoe transmission — CANoe shows it is sending CAN frames. However, on the S32K311 side, nothing is received — CanIf_RxIndication(the same function that worked correctly in loopback mode) is never called/triggered. For debugging i use segger RTT viewer using JTAG Configuration Sami2098_0-1789478804307.png Sami2098_1-1789478831337.png Sami2098_2-1789478911944.png Sami2098_3-1789478932611.png  Best regards.   Re: S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool Hello @Sami2098, Could you share RTD version you are currently using? There are some examples in our community you can use as reference:  Re: CAN Example for S32K311 - NXP Community Example S32K312 CAN Transmit & Receive Using Polling mode DS3.5 RTD300 [RTD600 MCAL & IP] S32K3X4EVB-T172 FlexCAN Example Interrupt/Polling FlexCAN configuration overall looks OK. Can you confirm PTA6/7 are configured as input and output, respectively, and you are indeed calling Siul2_Port_Ip_Init() API to initialize Port? Julin_AragnM_2-1789514266922.pngJulin_AragnM_2-1789514266922.png Since you are using S32K1XEVB, transceiver used is FS23, and when the FS23 is in Debug mode, the CAN transceiver is set to Active mode by default, thus there is no need to set CAN_MODE = 0b1x. I would also suggest checking that the bitrate and sampling point configured is the same between S32K311<->CANoe. Lastly, if you have a logic analyzer or an oscilloscope, could you share the CANTXD, CANRXD, CANH and CANL signals? Best regards, Julián

Linux 无法访问 LPSPI3 寄存器（读取设备内存时出现总线错误）——P11 EXP 上的外部 SPI 设备 摘要 我正在尝试在 FRDM-IMX93 板的P11 EXPI 接头上使用LPSPI3在 GPIO_IO08-11 上启动两个外部 MCP2515 CAN 控制器（Waveshare 2-CH CAN HAT，已确认在真正的 Raspberry Pi 上工作）（引脚与 UM12181 表 21 中 Raspberry Pi 兼容接头的位置相匹配）。 在修复了我能找到的所有设备树级问题（电源、引脚复用、片选、引脚控制断言-GPIO）之后，SPI 时钟 (SCK)始终无法在物理接头引脚上切换，并且直接读取 LPSPI3 块的寄存器会导致总线错误。另一个已知工作正常的外部设备（LPUART1）可以从相同的地址空间正常读取数据。这表明存在资源/总线访问限制（RDC 或类似限制），而不是 Linux 设备树中可以修复的问题。 板/软件 开发板：FRDM-IMX93（恩智浦），SoC：MIMX9352CVVXMAB BSP：NXP i.MX 发布发行版，内核版本 6.18.2-1.0.0-gf49f45233f7b 目标外设：lpspi3（spi@42550000，别名在 /aliases 中为 spi2，通过 /proc/device-tree/__symbols__ 确认实际 dts 标签为 lpspi3） 被测外部设备：CS0/CS1 上的 2 个 MCP2515（Waveshare 2 通道 CAN HAT） 已确认有效（已排除） 给排气歧管供电。reg_vexp_3v3 / reg_vexp_5v 是默认禁用的调节器固定节点（regulator_summary 显示 use=0）。通过覆盖片段添加了 regulator-always-on + regulator-boot-on，目标为 &reg_vexp_3v3 / &reg_vexp_5v（通过 __symbols__ 确认了真实标签）。事后验证 P11 上实际存在 3.3 V / 5 V 电压。 Pinmux。使用 imx93-pinfunc.h 中的官方宏，GPIO_IO08‑11 已正确复用到 LPSPI3_PCS0/SIN/SOUT/SCK。对于这三个函数，input_reg/input_val 均为 0x0000/0x0，因此不需要 DAISY 链选择（通过宏检查排除，不需要单独的寄存器）。 芯片选择。cs-gpios = , （位操作 GPIO CS，与 NXP 针对此节点的上游板级支持模式相匹配）。通过 cat /sys/kernel/debug/gpio 和万用表/逻辑分析仪确认： CS0 切换正常，并且物理上连接到了接头引脚。 pinctrl-assert-gpios。NXP自己的上游 &lpspi3 参考中包含 pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>;（此行并未出现在大多数公开指南中，仅出现在板自己的 dts 补丁中）。已添加；通过 /proc/device-tree/__symbols__ 确认 pcal6408 已解析，并通过 cat /sys/kernel/debug/gpio 确认，一旦请求 lpspi3 的默认 pinctrl 状态，GPIO 就会被钳位（输出 hi）。 覆盖层涂抹顺畅。U-Boot 的 fdt apply 没有出现 FDT_ERR_NOTFOUND；/sys/bus/spi/devices/ 显示 SPI 内核已注册 spi2.0 和 spi2.1。 ERR051608（LPSPI TCR[PRESCALE] 勘误）。已检查 spi-fsl-lpspi.c历史记录——该修复（fsl、imx93-spi 的 prescale_max = 1）已于 2024 年 8 月合并到主线版本 / 稳定版 6.6.51。& 6.10.10 2024 年 9 月，远早于此内核版本 (6.18.2)，并且兼容字符串 (fsl,imx93-spi) 已存在于主板 dts 中，因此驱动程序应该自动应用此限制。虽然不能完全排除这种可能性（没有直接的注册确认实际写入了 PRESCALE 字段），但时间线强烈表明此事已经处理完毕。 实际症状 使用万用表探测物理 P11 引脚上的 CS0/CS1、MISO、MOSI、SCK，然后使用逻辑分析仪以 10–20 MSa/s 的采样率在 CS0 下降沿触发，同时不断重试传输（在循环中使用 spidev_test，以及通过 echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind 反复强制 mcp251x 重新探测）： CS0切换。经万用表和逻辑分析仪验证。 SCK 从不切换。平坦，无任何活动，无论持续尝试转移。 MOSI 从不切换。 两个 MCP2515 的故障情况完全相同：mcp251x spi2.0/spi2.1：MCP251x 在复位后未进入配置模式 / 探测失败，错误代码为 110 (ETIMEDOUT) — 即驱动程序自身的 SPI 级复位 + 读取 CANSTAT 序列未得到响应，这与 SCK 从未离开 SoC 的情况一致。 根本原因已缩小到时钟/总线访问，而非设备树。   # clk_enable_count AND clk_prepare_count are both 0, despite the controller # actively being used in a continuous retry loop $ cat /sys/kernel/debug/clk/clk_summary | grep -i lpspi3 lpspi3_root 0 0 0 50000000 0 0 50000 N deviceless no_connection_id lpspi3 0 0 0 50000000 0 0 50000 N 42550000.spi per $ cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count 0 即使 42550000.spi（真正的绑定消费者）正在循环中积极尝试传输（spidev_test 循环，以及通过 echo spi2.0 > /sys/总线/spi/drivers/mcp251x/bind 反复强制 mcp251x 重新探测），lpspi3 的功能（每个）时钟显示 clk_enable_count=0 和 clk_prepare_count=0。clk_prepare() 是 clk_enable()之前的步骤——它甚至从未被调用，这表明驱动程序的传输路径（或其前面的 pm_runtime_get()）从未到达该设备的时钟管理代码，而不是请求时钟然后无法开启。 我没有内核构建工具来添加跟踪点，所以我还无法判断这是 pm_runtime 恢复时静默执行空操作，还是缺少依赖项（例如，此板的 lpspi3 节点需要但没有的功率域引用），或者是此特定内核构建的 spi-fsl-lpspi.c 中的其他问题。 决定性的寄存器级测试——直接读取 devmem：   $ devmem 0x44380000 32 # LPUART1 base — known-good peripheral 0x04040007 $ devmem 0x42550000 32 # LPSPI3 base (VERID register) Bus error (core dumped) 一个完全无关的、工作正常的外部设备（LPUART1，用于调试控制台）从相同的 CPU/总线上下文中读取数据正常； LPSPI3 的基地址在普通的 32 位读取中出现故障。我最初怀疑是该板特有的资源域控制器 (RDC) 式访问限制，但 NXP 社区的几个帖子（i.MX25/i.MX6ULL“devmem 返回总线错误”，i.MX8MP I2C 来自 DSP 的帖子）指出，同样的症状是触摸时钟被关闭的 AIPS 总线外设的正常预期结果，而不一定是安全/域限制。这与上面的 clk_enable_count=0 一致，现在让我觉得这是该设备的驱动程序/PM 路径中的时钟使能错误，而不是（不一定）RDC 块——尽管在没有底层工具的情况下，我无法完全排除 RDC 的可能性。 这并非 i.MX93 LPSPI3 的普遍限制 上下文：NXP 社区的另一个帖子（[iMX93AUTO EVK] QCA7006AQ 的 SPI 配置，community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ-with-imx93AUTO-EVK/m-p/1839847）展示了如何使用 LPSPI3 在i.MX93-11x11-EVK （同一 SoC）的相同 GPIO_IO08-11 引脚上成功驱动外部 SPI 设备：   c &lpspi3 { compatible = "fsl,imx93-spi", "fsl,lpspi"; cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>; status = "okay"; ... }; &iomuxc { pinctrl_lpspi3_qca: lpspi3grp { fsl,pins = < MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x3fe MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x3fe MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x3fe MX93_PAD_GPIO_IO08__LPSPI3_PCS0 0x3fe /* native PCS0, not plain GPIO */ >; }; }; 我在 FRDM 板上尝试了完全相同的变体（使用原生 LPSPI3_PCS0/LPSPI3_PCS1 而不是普通的 GPIO2_IO08/GPIO2_IO07，加上显式兼容覆盖）——没有变化，devmem 0x42550000 32 仍然出错，clk_enable_count/clk_prepare_count 仍然为 0。这排除了引脚复用/兼容字符串选择是此板卡上的原因，并且——结合 EVK 的成功——让我怀疑是FRDM 板卡特有的问题（要么在 imx93-11x11-frdm.dts 中）。处理 lpspi3（或该板的 U-Boot/ATF 级 RDC/电源域设置）而不是一般的 i.MX93 SoC 或主线驱动程序的限制。 向恩智浦提出的问题 即使 SPI 内核正在积极地向绑定的 spi2.0/spi2.1 设备进行传输，lpspi3 的 clk_prepare_count/clk_enable_count 仍然保持为 0，并且普通的寄存器读取 0x42550000 会导致总线故障——FRDM-IMX93 的 lpspi3 设备树节点（或板级 RDC/电源域设置）缺少什么，而正常工作的 EVK 配置不需要这些？ FRDM-IMX93 上的 LPSPI3 是否故意保留给另一个功能域（例如，Cortex-M33 / 安全世界，或板载 MAYA-W2 三射频模块路径）在板的默认 RDC/ATF 配置下，与 EVK 不同？ 是否有类似 imx93-11x11-frdm-lpspi.dts 的参考文件，用于在该特定电路板上通过 P11 外部使用 LPSPI3？ 如何重现 底板 dtb：随 i.MX 版本 发行版镜像一起提供的标准 imx93-11x11-frdm.dtb（未修改的 NXP lpspi3 + pcal6408 + reg_vexp_3v3/reg_vexp_5v 节点 — 全部通过 __symbols__ 确认存在）。 应用上述覆盖（稳压器始终开启，pinctrl + cs-gpios + pinctrl-assert-gpios on &lpspi3; 尝试了 plain-GPIO 和 native-PCS0/PCS1 pinmux 变体，两次结果相同）。 手动将 spidev（内置，CONFIG_SPI_SPIDEV=y）绑定到 spi2.0：   echo spidev > /sys/bus/spi/devices/spi2.0/driver_override echo spi2.0 > /sys/bus/spi/drivers/spidev/bind spidev_test -D /dev/spidev2.0-s 1000000 -v — “成功”（无 I/O 错误），但即使 MOSI/MISO 物理短路，RX 数据也不是 TX 的环回；无论如何，逻辑分析仪上的 SCK 都不会切换。 cat /sys/kernel/debug/clk/clk_summary | grep lpspi3 → clk_enable_count=0. cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count → 0。 devmem 0x42550000 32 → 总线错误。devmem 0x44380000 32 (LPUART1) → 正常成功。 如果需要，我很乐意提供完整的 overlay 源代码、dmesg 和 clk_summary/gpio 转储。

I.MX95 LVDS clock output can not be changed Hello everyone, Q1: I am working on single port LVDS display in the kernel lf-6.12y. I added my own panel config in driver/gpu/drm/panel/panel-simple.c, but the clock always be around 150Mhz when I was measuring the clock pins. But the other signals were working. But, In the lf-6.18y, the clock can output correctly, and in dual-port mode clock changing is also ok in the both versions. Is it a known problem or my mistake. Because some reasons I hope I can solve this problem in lf-6.12y.  The following are my settings panel-simple.c: static const struct display_timing lt9211_test_timing = { .pixelclock = { 35916000, 35916000, 35916000 }, .hactive = { 280, 280, 280 }, .hfront_porch = { 40, 40, 40, }, .hback_porch = { 60, 60, 60 }, .hsync_len = { 30, 30, 30 }, .vactive = { 1424, 1424, 1424 }, .vfront_porch = { 15, 15, 15 }, .vback_porch = { 17, 17, 17}, .vsync_len = { 4, 4, 4 }, .flags = DISPLAY_FLAGS_DE_HIGH, }; static const struct panel_desc lt9211_test = { .timings = &lt9211_test_timing, .bpc = 8, .num_timings = 1, .size = { .width = 292, .height = 111, }, .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, .bus_flags = DRM_BUS_FLAG_DE_HIGH, .connector_type = DRM_MODE_CONNECTOR_LVDS, }; my lvds config in the device-tree &{/}{     lvds1_panel {         //compatible = "3ascreen,sa123hwv-l51";        compatible = "lt9211_test";        backlight = <&lvds_backlight>;        status = "okay";        port {            panel_in: endpoint {                remote-endpoint = <&lvds1_out>;            };        };     }; Q2: Under some conditions, the LVDS common voltage will not be aligned between the data lanes and clock in the same hardware. Or some signal missing like LVDS1 D3P has signal but D3N doesn't. Do you have ideas why this happened? Could some programs cause this? Q3: Is any config can shift the LVDS clock phase. Thanks

问题：修复 IMX_SEC_ENCLAVE 和释放后使用依赖项。 Hello 这是对 GitHub 上这个 PR的后续跟进。 提供的补丁似乎最终没有应用，因为 lf-6.18.y 中没有这些补丁。 需要 Kconfig 提交来确保当 NVMEM_IMX_OCOTP_SCU 为 m 时 Enclave 驱动程序不能为 y，从而避免探测延迟。 否则你会看到这样的结果： root@colibri-imx8x-14985125:~# dmesg -l err [ 1.708145] rtc-ds1307 1-0068: hctosys: unable to read the hardware clock [ 2.072996] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.078636] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.084513] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.111555] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.117209] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.123110] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.141671] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.147303] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.153200] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.171418] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.177065] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.182929] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 5.744448] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 5.750217] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 5.756186] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 5.877660] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 5.888247] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 5.894232] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 10.324138] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 10.349783] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 10.374692] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 11.731697] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 11.738134] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 11.747692] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.284910] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.295720] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.307723] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.410541] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.426771] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.443446] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.644550] debugfs: '5f1a0000.phy' already exists in 'regmap' [ 12.655906] debugfs: '5f1a0000.phy' already exists in 'regmap' [ 12.670039] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.688813] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.696063] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.765923] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.775810] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.786887] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.839515] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.847285] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.853801] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.936721] nvmem imx-scu-ocotp0: cell mac raw len 6 unaligned to nvmem word size 4 [ 12.951328] nvmem imx-scu-ocotp0: cell mac raw len 6 unaligned to nvmem word size 4 [ 13.708903] genpd_provider mu_a1: failed to power off resource 214 ret -22 [ 16.701904] Bluetooth: hci0: unexpected event for opcode 0x0000 root@colibri-imx8x-14985125:~# 在提交的第二个版本中，驱动程序进行了一些重构，我不确定NXP是否已经解决了这个问题。 提交 9703dfecc735（“LF-15802：驱动程序：固件：imx：修复 SE 驱动程序移除”） SE团队能否确认一下？ 此致敬礼 弗朗茨 Re: ISSUE: fix dependency for IMX_SEC_ENCLAVE and use-after-free 你好， 我看到这个问题还没有解决，我会和内部软件团队确认一下。 此致敬礼/Saludos， 阿尔多。

I.MX95 LVDS 时钟输出无法更改 大家好， 问题1： 我正在内核 lf-6.12y 中开发单端口 LVDS 显示功能。我在 driver/gpu/drm/panel/panel-simple.c 中添加了自己的面板配置，但是当我测量时钟引脚时，时钟频率始终在 150Mhz 左右。但其他信号都正常。 但是，在 lf-6.18y 中，时钟可以正确输出，并且在双端口模式下，两个版本的时钟切换也都可以。这是已知问题还是我的操作失误？由于某些原因，我希望能在lf-6.12y版本中解决这个问题。 以下是我的设置 panel-simple.c： static const struct display_timing lt9211_test_timing = { 像素时钟= { 35916000, 35916000, 35916000 }, .hactive= { 280, 280, 280 }, .hfront_porch= { 40, 40, 40, }, .hback_porch= { 60, 60, 60 }, .hsync_len= { 30, 30, 30 }, .vactive= { 1424, 1424, 1424 }, .vfront_porch= { 15, 15, 15 }, .vback_porch= { 17, 17, 17}, .vsync_len= { 4, 4, 4 }, .flags= DISPLAY_FLAGS_DE_HIGH， }; static const struct panel_desc lt9211_test = { 时间= &lt9211_test_timing， .bpc= 8， .num_timings= 1， 。尺寸= { 。宽度= 292， 。高度= 111， }, .bus_format= MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA， .bus_flags= DRM_BUS_FLAG_DE_HIGH， .连接器类型= DRM_MODE_CONNECTOR_LVDS， }; 设备树中的 lvds 配置 &{/}{ lvds1_panel { //兼容 = "3ascreen,sa123hwv-l51"; 兼容 = "lt9211_test"; 背光 = <&lvds_backlight>; 状态 = "正常"; 港口 { panel_in: 端点 { 远程端点 = <&lvds1_out>; }; }; }; Q2： 在某些情况下，同一硬件中的数据通道和时钟之间的 LVDS 公共电压将无法对齐。或者某些信号缺失，例如 LVDS1 D3P 有信号但 D3N 没有信号。你知道这是为什么吗？某些程序会导致这种情况吗？ Q3： 是否有任何配置可以改变LVDS时钟相位？ 谢谢！

FRDM-IMX93:LinuxからLPSPI3レジスタにアクセスできない(devmem読み取り時のバスエラー) — 外部SPIデビック 概要 FRDM-IMX93ボードの P11 EXPIヘッダーに LPSPI3 を使って、2つの外部MCP2515 CANコントローラー(Waveshare 2-CHAN HAT、本物のRaspberry Piで動作確認)を起動しようとしています(GPIO_IO08 UM12181表21参照、Raspberry-Pi互換ヘッダー位置に一致するピンです)。 見つけたデバイスツリーレベルの問題(電源、ピンマックス、チップセレクト、pinctrl-assert-gpio)をすべて修正した後、SPIクロック(SCK)は物理ヘッダーピンを切り替え ず 、LPSPI3ブロックの直接レジスタ読み込みは バスエラーを引き起こします。別の既知の動作ペリフェラル(LPUART1)は同じアドレス空間から問題なく読み返します。これはLinuxデバイスツリーから修正できるものではなく、リソース/バスアクセス制限(RDCなど)を示しています。 ボード/ソフトウェア ボード：FRDM-IMX93（NXP）、SoC：MIMX9352CVVXMAB BSP: NXP i.MX リリース ディストリビューション、カーネル 6.18.2-1.0.0-gf49f45233f7b ターゲット周辺機器:lpspi3(spi@42550000、/aliasesでエイリアスされたspi2、/proc/device-tree/で確認された本物のdtsラベル__symbols__ lpspi3) テスト中の外部デバイス:CS0/CS1上の2× MCP2515(Waveshare 2-CH CAN HAT) 既に動作が確認されているもの（除外されたもの） ヘッダーに電力を供給します。reg_vexp_3v3 / reg_vexp_5v は、デフォルトで無効になっているレギュレータ固定ノードです (regulator_summary では use=0 と表示されています)。レギュレーター常時オン+レギュレーターブートオンを追加し、オーバーレイフラグメントのターゲティング&reg_vexp_3v3/&reg_vexp_5vを追加しました( __symbols__で実際のラベルが確認されました)。その後、P11に3.3V/5Vの電圧が物理的に存在していることを確認しました。 Pinmux。GPIO_IO08-11 は、imx93-pinfunc.h の公式マクロを使用して、LPSPI3_PCS0/SIN/SOUT/SCK に正しく多重化されています。input_reg/input_valはこれら3つの機能に対して0x0000/0x0であるため、DAISYチェーンセレクトは不要です(マクロ検査で除外され、個別レジスタは不要)。 チップセレクト。cs-gpios = 、（ビットバンギングされたGPIO CS。このノードに対するNXP独自のアップストリームボードサポートパターンに一致）。cat /sys/kernel/debug/gpio とマルチメーター/ロジックアナライザーで確認したところ、 CS0 は正しくトグルし、物理的にヘッダーピンに到達していることがわかりました。 pinctrl-assert-gpios。NXP独自のこのボード用アップストリーム&lpspi3リファレンスには、pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; が含まれています（この行はほとんどの公開ガイドには記載されておらず、ボード独自のdtsパッチにのみ記載されています）。追加しました。/proc/device-tree/__symbols__ で pcal6408 が解決されること、および cat /sys/kernel/debug/gpio で lpspi3 のデフォルトの pinctrl 状態が要求されると GPIO がアサートされる (出力 hi) ことを確認しました。 オーバーレイはきれいに適用されます。U-Bootのfdt applyからFDT_ERR_NOTFOUNDは発生せず、/sys/bus/spi/devices/にはSPIコアによってspi2.0とspi2.1が登録されていることが示されています。 ERR051608 (LPSPI TCR[PRESCALE] のエラータ)。spi-fsl-lpspi.c を確認しました履歴 — 修正（fsl、imx93-spi の prescale_max = 1）は、2024年8月 / 安定版 6.6.51 でメインラインに取り込まれました。2024年9月6.10日は、このカーネルバージョン(6.18.2)よりずっと前のもので、互換文字列(fsl、imx93-spi)はすでにベースボードのdtsに存在しているため、ドライバはこの制限を自動的に適用すべきです。完全に否定できるわけではないが（実際にPRESCALEフィールドが書き込まれたという直接的なレジスタ確認はない）、タイムラインから判断すると既に処理済みである可能性が高い。 実際の症状 CS0/CS1、MISO、MOSI、SCKが物理的なP11ピン(マルチメーター、CS0落ち込みエッジで10〜20 MSa/sのロジックアナライザーをトリガー)でプローブしつつ、転送を繰り返し再試行(ループ内でspidev_testし、Echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bindを経て繰り返しMCP251xの再プローブを強制することで別々に実行しました): CS0の切り替え。マルチメーターとロジックアナライザーの両方で確認済み。 SCKは切り替えません。継続的に転送を試みても、変化はなく、活動は見られない。 MOSIは切り替えません。 両方のMCP2515が同じように失敗します：mcp251x spi2.0/spi2.1：リセット/プローブ失敗後、MCP251xはコンフモードに入らなかった。err=110(ETIMEDOUT)。つまり、ドライバ自身のSPIレベルのリセット+read-CANSTATシーケンスは応答せず、SCKがSoCを出ないのと一致している。 根本原因はデバイスツリーではなくクロック/バスアクセスに絞られます   # clk_enable_count is 0 despite the controller actively being used $ cat /sys/kernel/debug/clk/clk_summary | grep -i lpspi3 lpspi3_root 0 0 0 50000000 0 0 50000 N deviceless no_connection_id lpspi3 0 0 0 50000000 0 0 50000 N 42550000.spi per LPSpi3の機能クロック(per)クロックはenable_count=0と表示されますが、42550000.SPI(実際のバインドされた消費者)がループ内で転送を試みている間も、単に「未使用」ではありません(lpspi1/2/4はデバイス レスで0 と表示されるため、それだけでは決定的ではありません)。 決定的なテスト ― devmem を介したレジスタの直接読み取り：   $ devmem 0x44380000 32 # LPUART1 base — known-good peripheral 0x04040007 $ devmem 0x42550000 32 # LPSPI3 base (VERID register) Bus error (core dumped) 全く関係のない動作するペリフェラル(LPUART1、デバッグコンソール用)は同じCPU/バスのコンテキストから問題なく読み戻せます。LPSPI3のベースアドレスフォルトは、クロックゲーティングやピンマックスの考慮が問題になる前に、単純な32ビット読み取りで発生します。これはリソースドメインコントローラー(RDC)やそれに類するアクセス制御機構が、ハードウェアレベルでCortex-A55(Linux)ドメインをこのペリフェラルのアドレス範囲からブロックしているように見えます。Linuxデバイスツリーから設定可能なものとは無関係です。 NXPへの質問 FRDM-IMX93 の LPSPI3 は、別のドメイン (例:Cortex-M33 / Secure World)をボードのデフォルトのRDC構成に含めて、追加のSPL/ATF/TF-Aレベルの再構成なしでLinuxからは使えなくなるのでしょうか? もしそうなら、LPSPI3バスアクセスをCortex-A55の非セキュアドメインに再割り当てする方法(U-Boot SPLのRDC設定やOP-TEE/TF-Aの変更)は文書で記載されているのでしょうか?それとも、GPIO_IO08-11が壊れているにもかかわらず、このボードのP11ヘッダーで外部SPIとしては単純にサポートされていないのでしょうか? これは私のボード/カーネルビルド特有の問題でしょうか、それともデフォルトのFRDM-IMX93 BSPの既知の特性でしょうか？参照用のimx93-11x11-frdm-lpspi.dts（EVKの場合はimx93-11x11-evk-lpspi.dtsに相当）があれば非常に助かります。 再現方法 ベースボードdtb: i.MXリリースディストリビューションイメージに同梱されている標準のimx93-11x11-frdm.dtb（変更されていないNXP lpspi3 + pcal6408 + reg_vexp_3v3/reg_vexp_5vノード - すべて__symbols__経由で存在が確認されています）。 上記で説明したオーバーレイを適用します（レギュレータ常時オン、&lpspi3 上の pinctrl + cs-gpios + pinctrl-assert-gpios）。 spidev（組み込み、CONFIG_SPI_SPIDEV=y）を手動でspi2.0にバインドします。   echo spidev > /sys/bus/spi/devices/spi2.0/driver_override echo spi2.0 > /sys/bus/spi/drivers/spidev/bind spidev_test -D /dev/spidev2.0-s 1000000 -v — 転送は「成功」します（I/O エラーなし）が、MOSI/MISO が物理的に短絡されていても、RX データは TX のループバックではありません。 devmem 0x42550000 32 → バスエラー。 必要であれば、オーバーレイのソースコード、dmesgログ、clk_summary/gpioダンプなど、すべての情報を提供いたします。

S32K358 about Cache operation I am writing an S32K358 program in S32DS. To create an OTA upgrade program, I need to manipulate the internal FLASH. When I call the above function, I can compile it successfully, but I cannot find the above function by pressing CTRL+left mouse button. Is this normal? Screenshot 2026-09-15 141928.png Screenshot 2026-09-15 141953.png Re: S32K358 about Cache operation Hi @sunshine88, Can you try rebuilding the index? danielmartynek_0-1789469464382.pngdanielmartynek_0-1789469464382.png Thank you, BR, Daniel

S32K358 キャッシュ操作について S32DSでS32K358プログラムを作成しています。OTAアップグレードプログラムを作成するために、内部FLASHを操作する必要があります。上記の関数を呼び出すとコンパイルは正常に完了しますが、Ctrlキーを押しながらマウスの左ボタンを押しても上記の関数が見つかりません。これは正常な動作でしょうか？ スクリーンショット 2026-09-15 141928.png スクリーンショット 2026-09-15 141953.png Re: S32K358 about Cache operation こんにちは@sunshine88 さん インデックスを再構築してみることはできますか? danielmartynek_0-1789469464382.pngdanielmartynek_0-1789469464382.png ありがとうございました。 BR、ダニエル

Does NXP official have a code routine for configuring external boot for S32K344 chip? Does NXP official have a code routine and tutorial for configuring external boot for S32K344 chip? We would like to configure the chip to boot from the SD card？ Re: Does NXP official have a code routine for configuring external boot for S32K344 chip? In a nonsecure boot configuration - does the first bootloader run from ROM (is it immutable)? Can this first bootloader be configured to boot the subsequent bootloaders/application images from an external source/flash? Re: Does NXP official have a code routine for configuring external boot for S32K344 chip? This device does not offer an option to boot from external memory. Device supports secure and nonsecure boot modes but in both cases it is internal flash boot.