The problem of long negotiation time in Ethernet. I am using version ATF35.0 and have referenced the , but I have only built fig.s32(ATF + uboot). I hope to launch my self-developed OS application through ATF+uboot. My self-developed OS requires a normal Ethernet connection during startup, but the Ethernet negotiation/connection time to the PC in uboot is very long，although it was ultimately able to ping successfully. Could you please help me solve this problem？ Thank you. Here is my startup log： NOTICE: Reset status: Power-On Reset NOTICE: BL2: v2.5(release):bsp35.0-2.5-dirty NOTICE: BL2: Built : 14:24:22, Nov 5 2026 NOTICE: BL2: Booting BL31 U-Boot 2020.04-dirty (Nov 05 2026 - 14:22:13 +0800) CPU: NXP S32G274A rev. 2.1 Model: NXP S32G274A-RDB2 DRAM: 3.5 GiB Ignore unsupported SCMI protocol 19 MMC: FSL_SDHC: 0 Loading Environment from SPI Flash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK Failed to lock PCIe phy Failed to power on 'serdes_lane0' PHY In: serial@401c8000 Out: serial@401c8000 Err: serial@401c8000 Board revision: RDB2/GLDBOX Revision C Net: EQOS phy: rgmii @ 1 Warning: eth_eqos MAC addresses don't match: Address in ROM is 02:00:00:00:00:01 Address in environment is 32:94:1b:e9:59:d7 eth0: eth_eqosFailed to set the frequency of mac2_rx_rgmii Failed to enable mac2_rx_rgmii clock PFE: emac0: sgmii emac1: none emac2: rgmii SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB ## No elf image at address 0xffdc8178 PFEng firmware file ' @0x03000000: ' loading failed: -22 Hit any key to stop autoboot: 0 => setenv ethact "eth_eqos" => setenv ipaddr "202.100.0.200" => setenv gatewayip "202.100.0.1" => setenv initnet "for i in 1 2 3 4 5; do ping 202.100.0.1;sleep 5; done;" => setenv bootcmd "run initnet; run bootos" => setenv bootos "sf probe && sf read 0x80022000 0x1f0000 0x200000 && icache off && dcache off && go 80024000" => saveenv Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI flash...done OK => reset resetting ▒NOTICE: Reset status: Destructive Reset (RUN) NOTICE: BL2: v2.5(release):bsp35.0-2.5-dirty NOTICE: BL2: Built : 14:24:22, Nov 5 2026 NOTICE: BL2: Booting BL31 U-Boot 2020.04-dirty (Nov 05 2026 - 14:22:13 +0800) CPU: NXP S32G274A rev. 2.1 Model: NXP S32G274A-RDB2 DRAM: 3.5 GiB Ignore unsupported SCMI protocol 19 MMC: FSL_SDHC: 0 Loading Environment from SPI Flash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK Failed to lock PCIe phy Failed to power on 'serdes_lane0' PHY In: serial@401c8000 Out: serial@401c8000 Err: serial@401c8000 Board revision: RDB2/GLDBOX Revision C Net: EQOS phy: rgmii @ 1 Warning: eth_eqos MAC addresses don't match: Address in ROM is 02:00:00:00:00:01 Address in environment is 32:94:1b:e9:59:d7 eth0: eth_eqosFailed to set the frequency of mac2_rx_rgmii Failed to enable mac2_rx_rgmii clock PFE: emac0: sgmii emac1: none emac2: rgmii SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB ## No elf image at address 0xffdc8178 PFEng firmware file ' @0x03000000: ' loading failed: -22 Hit any key to stop autoboot: 0 eth_eqos Waiting for PHY auto negotiation to complete................. TIMEOUT ! phy_startup() failed: -110FAILED: -110## No elf image at address 0xffdc7ae8 PFEng firmware file ' @0x03000000: ' loading failed: -22 ping failed; host 202.100.0.1 is not alive eth_eqos Waiting for PHY auto negotiation to complete................. TIMEOUT ! phy_startup() failed: -110FAILED: -110## No elf image at address 0xffdc7ae8 PFEng firmware file ' @0x03000000: ' loading failed: -22 ping failed; host 202.100.0.1 is not alive Using eth_eqos device ARP Retry count exceeded; starting again ping failed; host 202.100.0.1 is not alive Using eth_eqos device host 202.100.0.1 is alive Using eth_eqos device host 202.100.0.1 is alive SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB device 0 offset 0x1f0000, size 0x200000 SF: 2097152 bytes @ 0x1f0000 Read: OK ## Starting application at 0x80024000 ... 回复： The problem of long negotiation time in Ethernet. Hello, @Zzzz1  Thanks for your post. According to the log shown and test results you shared, from my experience, it is possibly related with the network negotiation,  the link establishment time when connecting with switch may be longer than the wait time of u-boot, which caused the issue. You may try increasing the timeout value in uboot or use the fixed link with switch to have a test. BR Chenyin 回复： The problem of long negotiation time in Ethernet. Sorry, I tried and encountered issues with slow negotiation or errors when connecting the development board to the switch. However, when connecting the development board directly to the PC, there is no such problem. Have you ever encountered this situation?

イーサネットでの交渉時間が長い問題です。 私はバージョンATF35.0を使用しており、 を参照しましたが、実際にビルドしたのはfig.s32(ATF + uboot)だけです。ATF+ubootを通じて自作のOSアプリケーションを立ち上げたいと考えています。私が自作したOSは起動時に通常のイーサネット接続が必要ですが、ubootでのPCへのイーサネット交渉や接続時間は非常に長いものの、最終的には正常にpingを送ることができました。この問題を解決するのを手伝ってもらえますか? ありがとうございます。 以下は私の起動ログです。 注意：リセット状態：電源オンリセット お知らせ：BL2：v2.5（リリース）：bsp35.0-2.5-dirty お知らせ：BL2：ビルド日時：2026年11月5日 14:24:22 通知: BL2: BL31を起動しています U-Boot 2020.04-dirty(2026年11月5日 14:22:13 +0800) CPU: NXP S32G274A rev.2.1 モデル:NXP S32G274A-RDB2 DRAM:3.5 GiB サポートされていないSCMIプロトコル19を無視してください MMC: FSL_SDHC: 0 SPIフラッシュからの読み込み環境...SF:mx25uw51245gを検出、ページサイズ256バイト、消去サイズ64 KiB、合計64 MiBを検出 わかった PCIe物理ロックに失敗しました 『serdes_lane0』PHYの電源が入らなかった 収録:serial@401c8000 アウト:serial@401c8000 えっと:serial@401c8000 ボードリビジョン:RDB2/GLDBOX リビジョンC ネット:EQOS phy: rgmii @ 1 警告: eth_eqos の MAC アドレスが一致しません: ROM内のアドレスは02:00:00:00:00:01です 環境内のアドレスは 32:94:1b:e9:59:d7 です eth0: eth_eqos mac2_rx_rgmii の周波数設定に失敗しました mac2_rx_rgmiiクロックの有効化に失敗しました PFE: emac0: sgmii emac1: none emac2: rgmii SF: mx25uw51245gを検出しました。ページサイズは256バイト、消去サイズは64 KiB、合計は64 MiBです。 ## アドレス 0xffdc8178 に ELF イメージがありません PFEngファームウェアファイル「 @0x03000000: 」の読み込みに失敗しました: -22 自動起動を停止するには、任意のキーを押してください: 0 => setenv ethact "eth_eqos" => setenv ipaddr "202.100.0.200" => setenv gatewayip "202.100.0.1" => setenv initnet "for i in 1 2 3 4 5; do ping 202.100.0.1;sleep 5; done;" => setenv bootcmd "run initnet; run bootos" => setenv bootos "sf probe && sf read 0x80022000 0x1f0000 0x200000 && icache off && dcache off && go 80024000" => saveenv 環境情報をSPIフラッシュに保存しています... SPIフラッシュを消去しています... SPIフラッシュに書き込み中です...完了 わかりました => リセット リセット中 ▒注意: リセット状態: 破壊的リセット (実行) お知らせ：BL2：v2.5（リリース）：bsp35.0-2.5-dirty お知らせ：BL2：ビルド日時：2026年11月5日 14:24:22 通知: BL2: BL31を起動しています U-Boot 2020.04-dirty(2026年11月5日 14:22:13 +0800) CPU: NXP S32G274A rev.2.1 モデル:NXP S32G274A-RDB2 DRAM:3.5 GiB サポートされていないSCMIプロトコル19を無視してください MMC: FSL_SDHC: 0 SPIフラッシュからの読み込み環境...SF:mx25uw51245gを検出、ページサイズ256バイト、消去サイズ64 KiB、合計64 MiBを検出 わかった PCIe物理ロックに失敗しました 『serdes_lane0』PHYの電源が入らなかった 収録:serial@401c8000 アウト:serial@401c8000 えっと:serial@401c8000 ボードリビジョン:RDB2/GLDBOX リビジョンC ネット:EQOS phy: rgmii @ 1 警告: eth_eqos の MAC アドレスが一致しません: ROM内のアドレスは02:00:00:00:00:01です 環境内のアドレスは 32:94:1b:e9:59:d7 です eth0: eth_eqos mac2_rx_rgmii の周波数設定に失敗しました mac2_rx_rgmiiクロックの有効化に失敗しました PFE: emac0: sgmii emac1: none emac2: rgmii SF: mx25uw51245gを検出しました。ページサイズは256バイト、消去サイズは64 KiB、合計は64 MiBです。 ## アドレス 0xffdc8178 に ELF イメージがありません PFEngファームウェアファイル「 @0x03000000: 」の読み込みに失敗しました: -22 どのキーを押してもオートブートを止める:0 eth_eqos PHY自動交渉完了を待っています.................タイムアウト! phy_startup()失敗:-110 失敗:-110## No elf image at address 0xffdc7ae8 PFEng firmware file ' @0x03000000: ' loading failed: -22 ping failed; host 202.100.0.1 is not alive eth_eqos Waiting for PHY auto negotiation to complete................. TIMEOUT ! phy_startup() failed: -110FAILED: -110## アドレス0xffdc7ae8にエルフ画像がない PFEng ファームウェアファイル ' @0x03000000: ' ロード失敗:-22 pingが失敗しました;ホスト202.100.0.1は生きていません eth_eqos装置の使用 ARP再試行回数を超えた;再開 pingが失敗しました;ホスト202.100.0.1は生きていません eth_eqos装置の使用 ホスト202.100.0.1は生きている eth_eqos装置の使用 ホスト202.100.0.1は生きている SF:mx25uw51245gを検出、ページサイズ256バイト、消去サイズ64 KiB、合計64 MiBを検出 デバイス0オフセット0x1f0000、サイズ0x200000 SF: 2097152バイト @ 0x1f0000 読み込み: OK ## アプリケーション 0x80024000 ... 回复： The problem of long negotiation time in Ethernet. こんにちは、 @Zzzz1 投稿ありがとうございます。 あなたが共有してくれたログとテスト結果によると、私の経験ではネットワーク交渉に関連している可能性があり、スイッチ接続時のリンク確立時間が起動時の待ち時間よりも長くなっている可能性があり、それが問題の原因でした。 uBootでタイムアウト値を上げるか、スイッチの固定リンクを使ってテストしてみるのも良いでしょう。 BR チェイン 回复： The problem of long negotiation time in Ethernet. すみません、開発ボードとスイッチを接続する際に交渉が遅いかエラーの問題に遭遇しました。しかし、開発ボードを直接PCに接続した場合は、そのような問題はありません。あなたはこのような状況に遭遇したことがありますか？

在 s32k31XEVB-Q100 评估板上配置 S32K311 和 FS23 的 SPI 你好， 我正在尝试配置 s32k31XEVB-Q100 评估板上的 S32K311 和 FS23 之间的 SPI 通信。 因此，我配置了 LPSPI0 上的引脚。 根据数据手册，首先 CLK 必须启动，然后 CS 必须变为低电平。 如何在S32DS中配置此行为？ 但是当我查看SPI数据时，我发现首先CS变为低电平，然后CLK开始切换。 Re: Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board 嗨@john_2 图中 SCLK 信号的起始位置可能存在一些误解。图表并未表明 SCLK 需要在 CS 变为低电平之前开始切换。相反，这表明在 CS 被钳位之前，SCLK 必须已经处于空闲的低电平。 CS 变为低电平后，第一个 SCLK 边沿会在指定的 PCS 到 SCK 延迟后出现。因此，您应该将 LPSPI0 配置为 SCLK 空闲低电平 (CPOL = 0)，并根据 FS23 时序要求配置 PCS 到 SCK 的延迟。 BR，VaneB Re: Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board 谢谢你提供的信息 😄 我需要这些。 但是通讯仍然无法正常工作。 我正在使用Lpspi和Sbc_fs23_Ip驱动程序。 我想读取 M_DEV_PROG_ID 但我认为这些部件的顺序错了？ 也就是说，第一个字节应该是 00000010 吗？ 在我的配置中 Lpspi驱动程序 如果我理解数据表没错，SpiTransferStart 应该是 MSB 吗？但是，在逻辑分析仪中，CRC校验值显示在第一个字节，地址显示在最后一个字节。 SpiGeneral 和 Sbc_fs23_Ip-通用配置

以太网中协商时间过长的问题。 我正在使用 ATF35.0 版本，并参考了《Linux 电路板支持包。 35.0 S32G2 平台用户手册》，但我只构建了 fig.s32（ATF + uboot）。我希望通过 ATF+uboot 启动我自行开发的操作系统应用程序。我自行开发的操作系统在启动时需要正常的以太网连接，但是 uboot 中与 PC 的以太网协商/连接时间非常长，尽管最终能够成功 ping 通。请问您能帮我解决这个问题吗？ 谢谢。 以下是我的启动日志： 注意：重置状态：上电复位 注意：BL2：v2.5（版本）：bsp35.0-2.5-dirty 通知：BL2：版本：2026年11月5日 14:24:22 注意：BL2：正在启动 BL31 U-Boot 2020.04-dirty（2026年11月5日 14:22:13 +0800） CPU：NXP S32G274A rev.2.1 型号：NXP S32G274A-RDB2 动态随机存取存储器(DRAM)：3.5 GiB 忽略不支持的 SCMI 协议 19 MMC：FSL_SDHC：0 正在从 SPI Flash 加载环境... SF：检测到 mx25uw51245g，页面大小为 256 字节，擦除大小为 64 KiB，总大小为 64 MiB 好的 PCIe PHY 锁定失败 无法为“serdes_lane0”PHY供电。 输入：serial@401c8000 输出：serial@401c8000 错误：serial@401c8000 板版本：RDB2/GLDBOX 版本 C 网络：EQOS phy：rgmii @ 1 警告：eth_eqos MAC 地址不匹配： ROM中的地址是02:00:00:00:00:01 环境地址为 32:94:1b:e9:59:d7 eth0：eth_eqos 无法设置 mac2_rx_rgmii 的频率 启用 mac2_rx_rgmii 时钟失败 PFE：emac0：sgmii emac1：无 emac2：rgmii SF：检测到 mx25uw51245g，页面大小为 256 字节，擦除大小为 64 KiB，总大小为 64 MiB ## 地址 0xffdc8178 处没有 ELF 镜像 PFEng 固件文件“ @0x03000000: ”加载失败：-22 按任意键停止自动启动：0 => 设置环境变量 ethact "eth_eqos" => setenv ipaddr "202.100.0.200" => 设置环境变量 gatewayip "202.100.0.1" => setenv initnet "for i in 1 2 3 4 5; do ping 202.100.0.1;sleep 5; done;" => setenv bootcmd "运行 initnet; 运行 bootos" => setenv bootos "sf probe && sf read 0x80022000 0x1f0000 0x200000 && icache off && dcache off && go 80024000" => 保存环境 正在将环境数据保存到 SPI Flash... 正在擦除 SPI Flash... 正在写入 SPI Flash... 完成 好的 => 重置 重置 ▒注意：重置状态：破坏性重置（运行） 注意：BL2：v2.5（版本）：bsp35.0-2.5-dirty 通知：BL2：版本：2026年11月5日 14:24:22 注意：BL2：正在启动 BL31 U-Boot 2020.04-dirty（2026年11月5日 14:22:13 +0800） CPU：NXP S32G274A rev.2.1 型号：NXP S32G274A-RDB2 动态随机存取存储器(DRAM)：3.5 GiB 忽略不支持的 SCMI 协议 19 MMC：FSL_SDHC：0 正在从 SPI Flash 加载环境... SF：检测到 mx25uw51245g，页面大小为 256 字节，擦除大小为 64 KiB，总大小为 64 MiB 好的 PCIe PHY 锁定失败 无法为“serdes_lane0”PHY供电。 输入：serial@401c8000 输出：serial@401c8000 错误：serial@401c8000 板版本：RDB2/GLDBOX 版本 C 网络：EQOS phy：rgmii @ 1 警告：eth_eqos MAC 地址不匹配： ROM中的地址是02:00:00:00:00:01 环境地址为 32:94:1b:e9:59:d7 eth0：eth_eqos 无法设置 mac2_rx_rgmii 的频率 启用 mac2_rx_rgmii 时钟失败 PFE：emac0：sgmii emac1：无 emac2：rgmii SF：检测到 mx25uw51245g，页面大小为 256 字节，擦除大小为 64 KiB，总大小为 64 MiB ## 地址 0xffdc8178 处没有 ELF 镜像 PFEng 固件文件“ @0x03000000: ”加载失败：-22 按任意键停止自动启动：0 eth_eqos 等待 PHY 自动协商完成................. 超时！ phy_startup() 失败：-110FAILED：-110 ## No elf image at address 0xffdc7ae8 PFEng firmware file ' @0x03000000: ' loading failed: -22 ping failed; host 202.100.0.1 is not alive eth_eqos Waiting for PHY auto negotiation to complete................. TIMEOUT ! phy_startup() failed: -110FAILED: -110##地址 0xffdc7ae8 处没有 elf 镜像 PFEng 固件文件“ @0x03000000: ”加载失败：-22 ping 失败；主机 202.100.0.1 已关闭 使用 eth_eqos 设备 ARP 重试次数已超过限制；重新开始 ping 失败；主机 202.100.0.1 已关闭 使用 eth_eqos 设备 主机 202.100.0.1 处于活动状态 使用 eth_eqos 设备 主机 202.100.0.1 处于活动状态 SF：检测到 mx25uw51245g，页面大小为 256 字节，擦除大小为 64 KiB，总大小为 64 MiB 设备 0 偏移量 0x1f0000，大小 0x200000 SF：2097152 字节 @ 0x1f0000 读取：成功 ## 应用程序从 0x80024000 开始... 回复： The problem of long negotiation time in Ethernet. 你好， @Zzzz1 感谢您的帖子。 根据您提供的日志和测试结果，以我的经验来看，这可能与网络协商有关，连接交换机时的链路建立时间可能比 u-启动 的等待时间长，从而导致了这个问题。 您可以尝试增加 uboot 中的超时值，或者使用带开关的固定链路进行测试。 BR 陈银 回复： The problem of long negotiation time in Ethernet. 抱歉，我尝试连接开发板到交换机时遇到了协商缓慢或出错的问题。但是，当将开发板直接连接到电脑时，就不会出现这样的问题。你遇到过这种情况吗？

i.MX 8ULP uSDHC - HS400拡張ストロボ：検証およびCMD応答サンプリング こんにちは、 私たちは搭載のeMMC(JEDEC 5.1)を、HS400エンハンストロボ(200MHz、8ビット、1.8V)の8ULP(uSDHC0)i.MX 使用しています。当社のU-Boot eMMCホストおよびカード切り替えコードはNXP lf-6.1.55-2.2.1と同一であり、EVKデバイスツリーではmmc-hs400-enhanced-strobeも有効になっています。評価中に、U-BootでのeMMC読み取り時に、データCRCエラーやCMD12/CMD13への応答がないことが時折発生しました。我々のテストでは、ホストのリセットまたはカードの再初期化によってのみ復旧できた。 1. HS400 Enhanced Strobeはi.MX 8ULPで検証済みで推奨されていますか？データシート（IMX8ULPIEC Rev.1）にはその記載はありません。そうでない場合、標準のHS400が推奨構成ですか？また、HS400 / Enhanced Strobe の SoC ピンにおける CMD 応答には、どの AC タイミングが適用されますか？ 2. チューニングを行わない拡張ストローブでは、CMD応答をサンプリングするのはデータストローブですか、それとも内部サンプリングクロックですか？リファレンス・マニュアルの「HS400モードへの切り替え」では、HS200のチューニングが「CMDラインのコマンド応答をCLKに同期させる」必要があり、結果はMIX_CTRL[SMP_CLK_SEL] = 1(ステップ6、10-12)で書き戻されます。「HS400エンハンストモードに切り替える」にはそのようなステップはありません。i.MX 93のリファレンスマニュアル(38.3.10.5)も同じ流れで、説明はありません。 事前に感謝いたします。 よろしくお願いします、 ミオ i.MX8ULP Re: i.MX 8ULP uSDHC - HS400 Enhanced Strobe: validation and CMD response sampling こんにちは、 ご回答ありがとうございます。念のため確認させてください。 1. i.MX 8ULPのHS400拡張ストローブモードでは、uSDHCは内部サンプリングクロック（データストローブではなくCLKベース）を使用してCMD応答をサンプリングし、CMD入出力タイミング要件はデータシートの表35のSD5/SD6/SD7（CLK基準）であり、HS400と同じです。 2. 拡張ストローブではチューニングが行われないため、CMDには固定サンプリングクロックが使用され（このモードではSMP_CLK_SEL = 0と読み取られます）、ストローブ（STROBE_DLL）はDAT[7:0]上のデータのキャプチャにのみ使用されます。 これは正しいですか？ ご協力いただき、誠にありがとうございました。 よろしくお願いします、 ミオ Re: i.MX 8ULP uSDHC - HS400 Enhanced Strobe: validation and CMD response sampling こんにちは、 @mioさん 返信が遅くなり申し訳ありません。 1. i.MX 8ULPはHS400ESモードをサポートしています。 https://github.com/nxp-imx/linux-imx/blob/lf-6.1.55-2.2.2/drivers/mmc/host/sdhci-esdhc-imx.c#L334 CMDの入出力は、SDR104 CMDの入出力タイミング仕様、特にRM表35のパラメータSD5、SD6、SD7に従います。 2. 拡張ストロボモードでは、DATA OUT、CRC応答、CMD応答はすべてストロボクロックに同期されます。CMD応答出力信号とSTROBEクロック間のタイミング関係は、DATA出力からSTROBEクロックへのタイミング関係と同じです。 B.R

Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board Hello, I am trying to configure the SPI for the communication between a S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board. Therefore I configured the pins on LPSPI0. According to the Datasheet first the CLK has to start and then the CS has to go LOW. How can I configure this behavior in S32DS? But When I see the SPI Data I see that first the CS goes to LOW and then the CLK starts toggling Re: Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board Hi @john_2  There may be a small misunderstanding regarding the beginning of the SCLK signal in the diagram. The diagram does not indicate that SCLK needs to start toggling before CS goes LOW. Instead, it shows that SCLK must already be at its idle LOW level before CS is asserted. Once CS goes LOW, the first SCLK edge occurs after the specified PCS-to-SCK delay. Therefore, you should configure LPSPI0 with SCLK idle LOW (CPOL = 0) and configure the PCS-to-SCK delay according to the FS23 timing requirement. BR, VaneB Re: Configure SPI for S32K311 and FS23 on a s32k31XEVB-Q100 Evaluation Board Thanks for the Information 😄 I needed these. But the Communication is still not working correctly. I am using the Lpspi and Sbc_fs23_Ip driver. I want to read the M_DEV_PROG_ID But I think the bits itself are in the wrong order? I.e. the first Byte should be 00000010 ? In the configuration I have  LpspiDriver If I understood the Datasheed correct, the SpiTransferStart should be MSB? But then the CRC is shown in the first Byte and the Address in the last Byte (in the LogicAnalyzer) SpiGeneral and Sbc_fs23_Ip- GeneralConfig

i.MX 8ULP uSDHC - HS400 增强型频闪：验证和 CMD 响应采样 您好， 我们在 HS400 增强型选通（200 MHz，8 位，1.8 V）中使用 i.MX 8ULP (uSDHC0) 上的板载 eMMC (JEDEC 5.1)。我们的 U-Boot eMMC 主机和卡切换代码与 NXP lf-6.1.55-2.2.1 完全相同，并且 EVK 设备树也启用了 mmc-hs400-enhanced-strobe。在评估过程中，我们偶尔会发现 U-Boot 读取 eMMC 时出现数据 CRC 错误或对 CMD12/CMD13 没有响应。在我们的测试中，只有 RESET 主机或重新初始化卡才能恢复它。 1. HS400增强型频闪灯是否已在i.MX 8ULP上得到验证和推荐？数据手册（IMX8ULPIEC Rev.1）中没有提到这一点。如果不是，那么标准 HS400 是推荐配置吗？另外，HS400 / 增强型选通模式下，SoC 引脚上的 CMD 响应采用哪种交流时序？ 2. 在增强型选通模式下，不进行任何调谐，CMD 响应采样的是数据选通还是内部采样时钟？参考手册中的“切换到 HS400 模式”需要 HS200 调谐“将 CMD 线上的命令响应与 CLK 同步”，并将结果写回 MIX_CTRL[SMP_CLK_SEL] = 1（步骤 6、10-12）。“切换到 HS400 增强模式”并没有这样的步骤。i.MX 93 参考手册 (38.3.10.5) 的流程相同，也没有描述。 提前谢谢您。 此致， mio i.MX8ULP Re: i.MX 8ULP uSDHC - HS400 Enhanced Strobe: validation and CMD response sampling 嗨@mio 抱歉回复晚了： 1. i.MX 8ULP 支持 HS400ES 模式。 https://github.com/nxp-imx/linux-imx/blob/lf-6.1.55-2.2.2/drivers/mmc/host/sdhci-esdhc-imx.c#L334 CMD 输入/输出遵循 SDR104 CMD 输入/输出时序规范，特别是 RM 表 35 中的参数 SD5、SD6 和 SD7。 2. 在增强型选通模式下，数据输出、CRC 响应和 CMD 响应都与选通时钟同步。CMD响应输出信号与选通时钟之间的时序关系与数据输出与选通时钟之间的时序关系相同。 B.R Re: i.MX 8ULP uSDHC - HS400 Enhanced Strobe: validation and CMD response sampling 你好， 谢谢你的回答。为了确认我理解正确： 1. 在 HS400 增强选通模式下的 i.MX 8ULP 上，uSDHC 使用其内部采样时钟（基于 CLK，而不是数据选通）对 CMD 响应进行采样，并且 CMD 输入/输出时序要求为数据手册表 35 中的 SD5/SD6/SD7（参考 CLK），与 HS400 相同。 2. 由于增强型选通模式下不进行任何调谐，因此使用固定采样时钟进行 CMD 操作（在此模式下，我们读取 SMP_CLK_SEL = 0），并且选通 (STROBE_DLL) 仅用于捕获 DAT[7:0] 上的数据。 是这样吗？ 非常感谢您的帮助。 此致， 米奥

Re: lx2080(yocto image and debug)   i want answers below quiries: explain SD card image flash .using flex installer tool and other methods flash code  in SD card . in temp/deploy/lx2160ardb  i have n number of bin files which files should select and how to flash in sd card, how to get bootable image . QorIQ LS1 Devices QorIQ LS2 Device Re: lx2080(yocto image and debug) Hi @jagannathr  , flex-installer method uses three part: SD-boot composite firmware, a boot-partition archive, and a root-filesystem archive  In the */tmp/deploy/images/lx2160ardb-rev2 1. SD-boot composite firmware firmware_lx2160ardb...sdboot.img 2. a boot-partition archive boot_lx2160ardb...tgz 3. Yocto root-filesystem archive fsl-image-networking-...lx2160ardb....rootfs.tar.gz The command would be : flex-installer -b -r -f -d Thanks June

imx95 CRA こんにちは、NXPさん EUのCRA（感染症証明書）を移植する必要があります。移植に関する公式文書はどこで入手できますか？（リンクを教えていただけますか？） Linux Re: imx95 CRA こんにちは、 @yrj さん CRAは直接移植可能なソフトウェアコンポーネントではなく、製品が遵守しなければならないサイバーセキュリティ規制です。 i.MXプラットフォーム上でCRA（カナダ歳入庁）の要件を実装する場合は、以下のリソースを優先的に活用することをお勧めします。 1. NXP公式CRA特別ページへのエントリー このページにある「ドキュメント」セクションには、アプリケーションノート、ホワイトペーパー、トレーニング資料が掲載されているほか、セキュアブート、セキュアアップデート、鍵管理などのセキュリティ機能と規制要件との関連性についても説明されています。   2. i.MXプラットフォーム アプリケーションノート このドキュメントでは、i.MX 93 を活用して OEM が CRA 要件を満たすことを支援する方法について説明します。 3.製品全体のコンプライアンス実施に関するホワイトペーパー このセクションでは、セキュリティ製品の設計とライフサイクルに関するコンプライアンス要件を紹介します。BSPや特定のセキュリティ機能だけに焦点を当てるのではなく、まず製品レベルの実装フレームワークを確立するのに適しています。 4. EU公式実施ガイドライン 規制発行機関による実施ガイドラインには、欧州委員会のガイダンス、よくある質問（FAQ）、製造業者の義務、適合性評価、脆弱性報告義務などが含まれます。製品が満たすべき要件を判断する際には、これらのEU公式文書に基づいて判断する必要があります。 よろしくお願いします、 志明 Re: imx95 CRA こんにちは@Zhiming_Liu おっしゃる通りです。私の説明は単純すぎました。 ドキュメントに従って、uboot、イメージ、およびimx95-xxx.dtbに署名と検証を行いました。 私の質問は、rootfsも署名する必要があるかどうかです。rootfsの署名に関する情報はまだ見つかっていません。これは、rootfsは署名する必要がないということでしょうか？ Re: imx95 CRA こんにちは、 @yrj さん 以下のドキュメントを参照してください：10.5.5 CAAMハードウェアIPのないi.MXプラットフォームでのDM-Cryptの使用 https://www.nxp.com/docs/en/user-guide/UG10163.pdf よろしくお願いします、 志明 Re: imx95 CRA こんにちは、 @yrj さん ファイルシステムは通常、dm-verityを使用します。ファイルシステムの保護を有効にするには、次のドキュメントを参照してください。https ://www.nxp.com/docs/en/application-note/AN15078.pdf よろしくお願いします、 志明 Re: imx95 CRA こんにちは@Zhiming_Liu dm-verityは読み取り専用ですが、 dm-cryptのドキュメントはありますか？

参考文献:lx2080(yocto画像とデバッグ) 以下の質問に対する回答が欲しいです。 SDカードイメージのフラッシュについて説明します。Flex Installer Toolやその他の方法でSDカードにコードをフラッシュします。 temp/deploy/lx2160ardb には n 個の bin ファイルがありますが、どのファイルを選択して SD カードにフラッシュするか、ブート可能なイメージを取得する方法を教えてください。 QorIQ LS1デバイス QorIQ LS2デバイス Re: lx2080(yocto image and debug) こんにちは、 @jagannathr さん。 フレックスインストーラー方法は、SDブート複合ファームウェア、ブートパーティションアーカイブ、ルートファイルシステムアーカイブの3つの部分を使用します */tmp/deploy/images/lx2160ardb-rev2 内 1. SDブート複合ファームウェア firmware_lx2160ardb...sdboot.img 2. ブートパーティションアーカイブ boot_lx2160ardb...tgz 3. Yoctoルートファイルシステムアーカイブ fsl-image-networking-...lx2160ardb....rootfs.tar.gz コマンドは次のようになります。 flex-installer -b -r -f -d よろしくお願いします。 6月

imx95 CRA Hi NXP I need to transplant my EU CRA (Certificate of Infectious Disease). Where can I find official documentation on this transplant? (Could you please provide a link?) Linux Re: imx95 CRA Hi @yrj CRA is not a directly portable software component, but rather a cybersecurity regulation that a product must comply with. If you are implementing CRA requirements on the i.MX platform, we recommend prioritizing the following resources: 1. NXP Official CRA Special Page Entry The Documentation section of the page lists application notes, white papers, and training materials, and also introduces the correspondence between security capabilities such as secure boot, secure updates, and key management and regulatory requirements.   2. i.MX Platform Application Notes This document describes how to leverage i.MX 93 to support OEMs in meeting CRA requirements. 3. Product Overall Compliance Implementation White Paper This section introduces compliance requirements for security product design and lifecycle, and is suitable for establishing a product-level implementation framework first, rather than focusing solely on the BSP or a specific security function. 4. Official EU Implementation Guidelines The implementation guidelines from the issuing body of regulations include Commission guidance, FAQs, manufacturer obligations, conformity assessments, and vulnerability reporting obligations. Determining which requirements a product needs to meet should be based on these official EU documents. Best Regards, Zhiming Re: imx95 CRA HI @Zhiming_Liu You're right, my description was too simplistic. I have now followed the documentation to sign and verify uboot, Image, and imx95-xxx.dtb. My question is whether rootfs also needs to be signed. I haven't seen any signing information for rootfs yet. Does that mean it doesn't need to be signed? Re: imx95 CRA Hi @yrj The file system typically uses dm-verity. You can refer to this document to enable file system protection: https://www.nxp.com/docs/en/application-note/AN15078.pdf Best Regards, Zhiming Re: imx95 CRA HI @Zhiming_Liu dm-verity is read-only; is there documentation for dm-crypt? Re: imx95 CRA Hi @yrj Please refer to the following document: 10.5.5 DM-Crypt usage on i.MX Platforms without CAAM hardware IP https://www.nxp.com/docs/en/user-guide/UG10163.pdf Best Regards, Zhiming

imx95 CRA Hi NXP           我需要移植欧盟的CRA，请问官方哪个地方有移植的文档（可以发下链接吗） Linux Re: imx95 CRA Hi @yrj  CRA 不是可以直接移植的软件组件，而是产品需要满足的网络安全法规。 如果你是要在i.MX 平台上落地 CRA 要求，建议优先看以下资料： 1. NXP 官方 CRA 专题入口 页面的 Documentation 栏目列出了应用笔记、白皮书和培训资料，也介绍了安全启动、安全更新、密钥管理等安全能力与法规要求之间的对应关系。   2.i.MX 平台相关应用笔记 这份文档介绍如何利用 i.MX 93支持 OEM 实现 CRA 要求。 3. 产品整体合规实施白皮书 介绍安全产品设计及生命周期方面的合规要求，适合先建立产品级实施框架，而不只是关注 BSP 或某个安全功能。 4. 欧盟官方实施指南 法规发布方的实施入口，包含 Commission guidance、FAQ、制造商义务、符合性评估、漏洞报告义务等资料。判断产品需要满足哪些要求，应以这类欧盟官方资料为依据。 Best Regards, Zhiming Re: imx95 CRA HI @Zhiming_Liu           您说的对，我描述的太通俗了          我现在参考文档对uboot 、Image、imx95-xxx.dtb，进行了签名与验证。          我现在是疑问是rootfs是否也需要签名呢，暂时没有看到rootfs的签名资料，是不需要吗？ Re: imx95 CRA HI @Zhiming_Liu        dm-verity只读的，有dm-crypt的文档吗 Re: imx95 CRA Hi @yrj  文件系统一般用dm-verity。你可以参考这个文档来使能文件系统的保护：https://www.nxp.com/docs/en/application-note/AN15078.pdf Best Regards, Zhiming Re: imx95 CRA Hi @yrj  请参考下面文档中的：10.5.5 DM-Crypt usage on i.MX Platforms without CAAM hardware IP https://www.nxp.com/docs/en/user-guide/UG10163.pdf Best Regards, Zhiming

回复：lx2080（yocto镜像和调试） 我希望得到以下问题的答案： 解释SD卡镜像闪存的使用方法。使用 flex installer 工具和其他方法将代码刷入 SD 卡。 在 temp/deploy/lx2160ardb 目录下，我有 n 个 bin 文件，应该选择哪些文件并将其刷入 SD 卡，如何获取可启动镜像？ QorIQ LS1设备 QorIQ LS2 设备 Re: lx2080(yocto image and debug) 你好@jagannathr ， flex-installer 方法使用三个部分：SD 卡启动复合固件、启动分区归档文件和根文件系统归档文件。 在 */tmp/deploy/images/lx2160ardb-rev2 中 1. SD启动复合固件 firmware_lx2160ardb...sdboot.img 2. 启动分区归档 boot_lx2160ardb...tgz 3. Yocto 根文件系统归档 fsl-image-networking-...lx2160ardb....rootfs.tar.gz 命令是： flex-installer -b -r -f -d 谢谢！ 六月

i.MX9 Power consumption estimation SKILL Here's the imx-power-estimation SKILL for any AI agents: name: imx-power-estimation description: Estimate the Power Consumption for i.MX95/952/943 SoC. Use this skill when user ask for the i.MX SoC power consumption with their application scenarios. Input: Describe your use case in natural language. e.g: "estimate the power consumption of i.MX95 for Automotive IVI use cases.". You can also specify the temperature/corner/mode, as well as the IP modules usage/bandwidth, like 2xA55 core running 50% loading, DDR bandwidth 30%, 1xETH 500Mbps. Output: Detailed power breakdown by voltage rail with total consumption

RAPID BLHOST (RBLHOST) 0.3.0 release We are pleased to announce the release of Rapid Blhost (RBLHOST) 0.3.0. RBLHOST is a host-side utility for communicating with embedded devices over interfaces such as USB and UART. Built in Rust with a focus on high performance for time-critical applications, it can be seamlessly integrated into systems developed in Python, C, or Rust. Features UART communication with configurable baudrate and timeout I2C communication with configurable slave address USB-HID communication with configurable VID/PID, and selection of one specific device by OS path, serial number or USB topology (port) path when several identical boards are connected Command-line interface compatible with the original blhost tool Batch command files executed sequentially in one process and one device session Python bindings for integration with other tools C/C++ bindings supported (UART, I2C and USB-HID, see MBoot C Bindings) ... and more!  Check this out! 🐙 GitHub: https://github.com/nxp-mcuxpresso/rblhost 📦 Crates.io: https://crates.io/crates/rblhost announcement

SPSDK v3.13.0 now available We are excited to announce the release of Secure Provisioning SDK (SPSDK) 3.13.0 🆕 New device support MCXC353, MCXC352 MCXN526T MIMXRT1183, MIMXRT118D ✨ Key new features nxpdebugmbox: new tool execute command, Debug Authentication Response export, improved debug connection diagnostics, and probe discovery without a mandatory family filter. Debug probes: ARM ADIv6 (CoreSight 600 / DPv3) support with automatic ADI-version detection and MEM-AP/debug-mailbox discovery. nxpimage: DevHSM SRK-set support plus secondary-image tables and parallel AHAB verification for MIMXRT266x devices. nxpele: new forward-boot-crypto command, HSE core reset/status support, and second Cortex-M7 core support for MCXE327 and MCXE32B. nxpcrypto: new --fuse-script option for rot calculate-hash to generate device-specific RoT fuse scripts where supported. Migration checks: new SPSDK_DEPRECATED_STRICT environment variable to report deprecated register aliases and schema properties as errors. For more details: Release Notes Supported Devices Github PyPi Documentation SPSDK Plugins: Github (Plugins) PyPi (Plugins) Note: nxp-codecheck was moved to separated repository bellow: SPSDK Codecheck: GitHub: https://github.com/nxp-mcuxpresso/nxp-codecheck PyPi: https://pypi.org/project/nxp-codecheck/ announcement

i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear NXP Support Team, Following Weidong’s recommendation, we are opening a new ticket for Bluetooth bring-up on our i.MX95 platform. Wi-Fi is now working, but we need guidance on restoring Bluetooth UART communication while maintaining the correct reference-clock selection during reset. 1. Hardware and software configuration Host board: NXP i.MX95 19×19 EVK, B0 Wireless module: u-blox JODY-W263-00B, based on 88W8987, connected through M.2 Key-E BSP: Automotive Android 15.0.0_2.1.0 Kernel: 6.12.23 Wi-Fi interface: SDIO through uSDHC3 Bluetooth interface: LPUART5, exposed as /dev/ttyLP4 Wi-Fi driver: NXP mwifiex from automotive-15.0.0_2.1.0, release 537.p9 Firmware: sduart8987_combo.bin from the corresponding Android BSP firmware repository Firmware version: 16.92.21.p151.4 Firmware size: 628,200 bytes We intend to continue with the recommended SDIO + UART configuration. 2. Wi-Fi activation failure and switch observation Previously, the module was detected over SDIO and firmware transfer completed, but firmware activation failed with: Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! During investigation, NXP advised that 88W8987 GPIO[8]/UART_SOUT is sampled during reset to select the reference clock: LOW: 38.4 MHz HIGH: 26 MHz This signal also serves as the Bluetooth UART TX output during normal operation and connects to the host LPUART5 RX input. On our EVK, the relevant connection is: Module Bluetooth TX → M.2 J24 pin 22 → R607 → BT_UART5_RXD → R17 → SW1 contacts 7–8 → host LPUART5 RX Our repeatable observation is: SW1 contacts 7–8 ON during cold boot: Wi-Fi firmware activation fails with 0xf005. SW1 contacts 7–8 OFF during cold boot: Wi-Fi initializes successfully and is operational. We also tested the suggested host RX pad pull-down configuration: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e However, the earlier tests did not resolve the failure with SW1 contacts 7–8 ON. The running device tree we subsequently extracted showed RX pad configuration 0x31e, so we would appreciate guidance on the complete configuration and when it takes effect during boot/reset. 3. Bluetooth failure with the working Wi-Fi configuration Keeping SW1 contacts 7–8 OFF allows Wi-Fi to work, but it also disconnects the module Bluetooth TX from the host UART RX. We therefore expect Bluetooth initialization to fail because the host cannot receive controller responses. Bluetooth is tested through ADB because the board has no connected display. The installed vendor configuration is: mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 The vendor library defaults baudrate_bt to 3000000. UART firmware download is disabled by default; the current configuration relies on the combo firmware loaded through the Wi-Fi driver. The Bluetooth vendor HAL reports version 009.030 and successfully opens the UART device: bt_vnd_init --- BT Vendor HAL Ver: 009.030 --- mchar_port set to /dev/ttyLP4 baudrate_fw_init is set to 3000000 open uart port successfully, fd=6, mchar_port=/dev/ttyLP4 However, the Bluetooth stack remains in BLE_TURNING_ON and eventually aborts: Can't start stack, last instance: starting HciHal During close/recovery, the vendor library also reports: Read hci complete event failed timed out Failed to read HCI RESET CMD response! The source configuration sequence begins with an HCI Reset command. Opening the UART device succeeds, but successful controller communication has not been established. 4. Guidance requested Could you please advise on the following? How should this shared clock-configuration/Bluetooth UART signal be handled on i.MX95? We need the module TX/host RX line LOW during reset for 38.4 MHz selection, followed by a connected, functional UART receive path during normal operation. What is the recommended configuration for SW1 contacts 7–8 and the LPUART5 RX pad? Should the switch remain ON with a specific pad configuration, or is an additional board-level change required? At which boot stage must the pull-down be applied? Is the Linux device-tree setting sufficient, or must U-Boot, System Manager/SCMI pin control, or another earlier initialization stage configure this pad before module reset is released? Please provide the recommended power/reset and pin-control sequence, including any required handling of W_DISABLE2#/Bluetooth enable, to ensure correct clock sampling and subsequent UART operation. Please confirm the Bluetooth configuration for the BSP-provided sduart8987_combo.bin: initial UART baud rate, operating baud rate, RTS/CTS flow control, and any required wake/sleep settings or vendor configuration entries. Is there a validated DTS/patch and Bluetooth vendor configuration for an 88W8987 module on this BSP? If available, please share the reference configuration and module part number used for validation. We investigated the SDIO-SDIO alternative, but understand from Weidong that those specialized packages are outdated and have not kept pace with kernel upgrades. We have not validated an SDSD firmware on this target and would like to resolve the issue using the standard SDIO + UART architecture. We can provide full Bluetooth logs, the running device tree, schematic excerpts, and oscilloscope measurements of the shared strap/UART line during reset and Bluetooth initialization. Please advise which measurement points and timing conditions would be most useful. Thank you for your continued support in enabling Wi-Fi. We would appreciate your guidance on completing Bluetooth bring-up while preserving the working Wi-Fi configuration. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , Please change  baudrate_fw_init = 3000000 to baudrate_fw_init = 115200 Then try. Thanks, Regards, weidong Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , Please confirm if baud rate is fixed in your wifi/bt module with u-blox. if the fixed baud rate is 115200, try the configuration: mchar_port = /dev/ttyLP4 baudrate_fw_init = 115200 If the fixed baud rate is 3000000, use the configuration mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 Then try it. I will have time to test it next week. you can try it first. BYW，I'm not quite sure I understand your operation. To turn Wi-Fi off and back on, you can simply do it through Android. There is no need to operate the SW1 switch on the board. Thanks, Best Regards, Weidong Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Subject: i.MX95 / JODY-W263: Baud-rate test results and request for a permanent solution without manual SW1 switching Dear Weidong, Thank you for your support. We tested your recommendation to change baudrate_fw_init from 3000000 to 115200. Below are the results and the remaining boot-time issue. We need a permanent solution for our next week’s integration activities, so your guidance on the required configuration or patch would be appreciated. Platform Board: NXP i.MX95 19×19 EVK, B0 Module: u-blox JODY-W263-00B / 88W8987, M.2 Key-E BSP: Automotive Android 15.0.0_2.1.0 Kernel: 6.12.23 Bluetooth Vendor HAL: 009.030 Wi-Fi interface: SDIO through uSDHC3 Bluetooth interface: UART5, /dev/ttyLP4 Firmware: sduart8987_combo.bin Switch under investigation: SW1, switch section 4, contacts 7–8, on the Bluetooth UART RX path toward the host. 1. Boot with SW1 contacts 7–8 ON Wi-Fi firmware activation fails: Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! WLAN: Fail download FW with nowwait: 0 Bluetooth also fails to reach the ON state. We have applied the recommended Linux RX pad configuration: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e We extracted the running device tree and verified that this value is present and referenced by the enabled UART5 node. However, the switch-ON boot issue remains. 2. Working sequence with initialization baud rate 3000000 The following sequence allows Wi-Fi and Bluetooth to operate: Keep SW1 contacts 7–8 OFF before power-on. Power on the board and allow firmware initialization to complete. Confirm: [12.738590] WLAN FW is active [12.954531] wlan: Driver loaded successfully Disable Bluetooth and confirm STATE_OFF. With the board running, physically turn SW1 contacts 7–8 ON. Enable Bluetooth. With: baudrate_fw_init = 3000000 baudrate_bt = 3000000 we obtained: wait-for-state:STATE_ON: Success enabled: true state: ON Wi-Fi remained connected to P3-Devices, with IP address 10.17.36.30, supplicant state COMPLETED, and network status VALIDATED. Bluetooth scanning and pairing had also worked previously using this manual switch sequence. In the latest 3M comparison run, Bluetooth ON and the Wi-Fi connection were confirmed. 3. Test of your recommended initialization baud rate 115200 We rebuilt and flashed the vendor/super images and matching board-specific AVB metadata with: mchar_port = /dev/ttyLP4 baudrate_dl_image = 115200 iSecondBaudrate = 3000000 baudrate_fw_init = 115200 baudrate_bt = 3000000 Both the deployed configuration and HAL logs confirmed that 115200 was used. We followed the same sequence: boot with contacts 7–8 OFF, confirm WLAN firmware active, disable Bluetooth, physically turn contacts 7–8 ON, and enable Bluetooth. Wi-Fi continued to operate, but Bluetooth initialization failed: baudrate_fw_init is set to 115200 open uart port successfully, fd=6, mchar_port=/dev/ttyLP4 Read hci complete event failed timed out. Total_duration = 1000 Failed to read HCI RESET CMD response! config_uart failed The adapter did not reach STATE_ON; repeated Bluetooth stack initialization failures occurred. After restoring only the initialization baud setting to 3000000 and rebuilding the images while retaining the same experimental bootloaders and kernel, Bluetooth reached ON using the same OFF-at-boot → ON-after-initialization sequence. 4. Additional boot-time experiments We also tested: Adding the RX 0x51e configuration to the U-Boot early pinctrl hog. An experimental SCMI pinctrl-driver change to include a mux request for the zero-offset DAP_TDI pin. The original driver condition, if (mux_ofs), skips the mux request for this pin because its mux offset is zero. These experiments did not resolve the switch-ON boot failure. We have not yet confirmed through early serial logs when the configuration is applied or whether the SCMI request succeeds. We therefore do not consider these changes proven fixes. Request for a permanent solution The manual switch sequence is useful for debugging, but it is not suitable for normal operation. We need Wi-Fi and Bluetooth to initialize reliably with SW1 contacts 7–8 left ON throughout power-on and runtime, without user intervention. Could you please review these results and provide: The correct initialization baud rate for JODY-W263 / 88W8987 with this combo firmware, given that 115200 failed and 3000000 succeeded in our comparison. The required pin configuration and module power/reset sequence to maintain the correct GPIO[8]/UART_SOUT strap state during initialization while preserving UART operation afterward. The appropriate implementation location—System Manager, SPL/U-Boot, Linux pinctrl/MMC power sequencing, or a hardware change. A specific patch or validated configuration for our board/BSP, including any required GPIO polarity, reset timing, or pin-ownership changes. Please also confirm whether the zero-offset mux handling in the SCMI pinctrl driver is intentional for i.MX95. We can provide the complete successful and failed logs, running device tree, source diffs, and SW1 photographs. Please let us know which additional early-boot traces you require. Thank you for helping us move from the working manual sequence to a reliable permanent solution. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear Weidong, Thank you for your reply and for offering to test this next week. We checked the u-blox JODY-W2 System Integration Manual, UBX-18068879, revision R14: Page 17 documents the default UART baud rate as 3000000. Section 2.4.2, page 29, states that the baud rate after firmware loading is 3000000, and that other supported rates can be configured using the dedicated HCI baud-rate command. Therefore, the documented default is 3M; the UART is not described as permanently restricted to this rate. Our tests also support the following configuration: mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 baudrate_bt = 3000000 With WLAN firmware active and the UART path connected, initialization at 115200 repeatedly timed out waiting for the HCI Reset response. Restoring 3000000 allowed Bluetooth to reach enabled: true, state: ON, while Wi-Fi remained connected. I would also like to clarify the physical switch operation. We are not operating SW1 to toggle Wi-Fi ON/OFF. According to the i.MX95 EVK baseboard schematic, SPF-87753-B, sheet 4, we operate SW1 section 4, contacts 7–8, on this path: Host JTAG_TDI / LPUART5_RX ↔ SW1 contacts 7–8 ↔ R17 (49.9 Ω) ↔ BT_UART5_RXD toward M.2. Here, R17 is the board resistor reference. It is separate from the u-blox document revision R14. Board resistor R14 belongs to the different CTS channel. Our observed behavior is: Contacts 7–8 ON before power-on: WLAN firmware activation fails with firmwarestat=0xf005. Contacts 7–8 OFF before power-on: WLAN firmware initializes successfully. After firmware initialization, contacts 7–8 turned ON: Bluetooth initializes at 3M, and Wi-Fi remains connected. The recommended Linux RX pull-down configuration is already applied: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e We verified this value and the enabled UART5 node’s reference in the running device tree. However, the manual switch sequence is still required. Android Wi-Fi toggling does not physically disconnect/reconnect this UART signal path. The remaining problem is therefore reliable initialization with SW1 contacts 7–8 left ON throughout boot and runtime. Could you please investigate the required early pin configuration and module power/reset sequence, and advise whether the permanent solution requires a System Manager, U-Boot, Linux, or hardware change? We can provide the schematic excerpt, switch photographs and early serial logs for your testing. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , OK, understood. Sorry , I ignored the switch. Yes, if you want to use LPUART5 on M.2,  need to enable all LPUART5 signals through SW1. Because LPUART5 signals are multiplexed through these JTAG PADs. But SW1 doesn't affect system boot.   The configuration ,  IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e is only needed to be configured in linux device tree. Not needed in u-boot device tree. Thanks, Regards, weidong Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear Weidong, Thank you for clarifying the SW1 routing and that the RX pull-down configuration is required only in the Linux device tree. Could you please confirm whether this configuration alone is the complete fix for the 88W8987 initialization issue on both Linux and Automotive Android 15.0.0_2.1.0? IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e This setting is already applied and verified in our running Android device tree. However, our observed behavior remains: SW1 contacts 7–8 ON before power-on: WLAN firmware activation fails with firmwarestat=0xf005. Contacts OFF before power-on: WLAN firmware activates successfully. Contacts turned ON after firmware activation: Bluetooth initializes at 3M, and Wi-Fi remains connected. To clarify, our issue concerns WLAN firmware activation, rather than the i.MX95 system boot itself. Have you verified Wi-Fi and Bluetooth initialization from a cold power-on with all required SW1 sections left ON throughout, on both Linux and Automotive Android? Please share the tested module part number, BSP versions, and any additional patches or power/reset sequencing changes required. Our goal is reliable initialization without manually operating SW1. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Hi @Rakesh_Kumar_Thakur , I also use the schematic.  But no problem on my side. Could you send me your 8987 Wi-Fi module? I'd like to test it on my side.     Thanks, Best Regards, Weidong Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , I have tested this many times on my i.MX95-EVK, including simultaneous Wi-Fi and Bluetooth operation, cold reset, and complete power-off/power-on cycles. All four SW1 switches are kept ON throughout my testing, because the LPUART5 signals are routed through these four JTAG pins. I do not change the SW1 settings during power-on or Wi-Fi/Bluetooth initialization. Here is a photo of the i.MX95-EVK used for my testing. Please check whether your i.MX95-EVK is the same hardware revision. I do not see this issue on my setup. The behavior of your board is quite unusual. There is also another point I noticed: you are using the Android 15.0.0_2.1.0 BSP, but the kernel version you mentioned does not match the actual kernel version included in our BSP. I am not sure why there is this discrepancy.     Thanks, Best Regards, Weidong     Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear Weidong, Thank you for confirming that Wi-Fi and Bluetooth work on your setup through repeated cold resets and complete power cycles, with all four SW1 sections kept ON. Our setup is: Board: NXP i.MX95 19×19 EVK, B0 silicon Module: u-blox JODY-W263-00B, based on 88W8987, connected through an M.2 adapter Interfaces: Wi-Fi over SDIO and Bluetooth over LPUART5 BSP: Automotive Android 15.0.0_2.1.0 Previously observed running kernel: 6.12.23-4k-ge0732a9b6eb5-dirty Bluetooth UART: /dev/ttyLP4, initialization and runtime baud rates both set to 3000000 The Linux RX pull-down setting below is already applied and verified in our running device tree: IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e However, we still require SW1 contacts 7–8 to be OFF during power-on and WLAN firmware initialization, then ON for Bluetooth operation. With these contacts ON from power-on, WLAN firmware activation fails with firmwarestat=0xf005. Our board will be unavailable for the next two days. Meanwhile, could you please provide the complete details of your validated setup so we can compare it with ours and assess which changes can be ported to our Android BSP? Exact hardware: Wi-Fi/Bluetooth module manufacturer and full part number, M.2 adapter part number/revision, and EVK baseboard/SOM revisions. Please confirm whether you have tested JODY-W263-00B specifically. Exact software: Whether the reported successful tests were performed on Linux, Automotive Android, or both. For each tested setup, please provide the BSP release, kernel version and commit, and preferably the uname -a output. You mentioned a discrepancy in our kernel version; please identify the expected kernel version for our stated BSP. Complete device-tree changes: The final working board DTS, included DTSI files, any DT overlays/DTBO sources, and relevant build configuration. A patch against the exact BSP baseline would be particularly helpful. Driver and firmware: The Wi-Fi driver version/branch/commit, exact Wi-Fi/Bluetooth firmware filenames and versions, and Bluetooth HAL/vendor configuration, including UART baud rate and flow control. Other required changes: Any kernel configuration, pinctrl, regulator, SDIO power/reset sequencing, System Manager, U-Boot, or hardware changes used in your working setup. Please confirm explicitly if no changes are required in any of these areas. Reproduction flow: The steps from the clean BSP to the working image, including all patches, build targets, flashing steps, switch/jumper positions, and the Wi-Fi/Bluetooth initialization sequence used during cold power-on testing. Please also confirm whether the Linux DTS RX pull-down is the only change needed for this issue, or whether your working image includes additional changes. Our target remains Automotive Android 15.0.0_2.1.0. We would like to evaluate porting the necessary changes to this BSP, with the goal of reliable Wi-Fi and Bluetooth initialization while all required SW1 sections remain ON throughout boot and runtime. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , It seems that your i.MX95-EVK may be different from mine. Do you have the schematic for the i.MX95 19×19 EVK with B0 silicon? Could you please share it with me for comparison?     Thanks, Best Regards, Weidong Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear Weidong, I am unable to upload the schematic files here, so I am sharing the official NXP page containing both design packages: https://www.nxp.com/design/design-center/development-boards-and-designs/IMX95LPD5EVK-19 Under Design Files, please download: SPF-87753-B — i.MX 95 19EVK Base Board Design Files SPF-87754-B — i.MX 95 19EVK Compute Module Design Files These are the schematic references we are using for our i.MX95 19×19 EVK setup with the u-blox JODY-W263-00B (88W8987) module. Could you please compare them with your tested hardware, particularly the SW1/LPUART5 routing, M.2 interface, and module power/reset circuitry? Please let us know whether any differences could explain the need to disconnect SW1 contacts 7–8 during firmware initialization, and advise on the required changes. Best regards, Rakesh Kumar Thakur Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue Dear @Rakesh_Kumar_Thakur , First, could you please confirm whether your u-blox JODY-W263-00B is using a 26 MHz reference clock?  If it is using 26 MHz, IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e should be the correct setting. Please try the following: Set all four SW1 switches to ON and keep them ON. Set IMX95_PAD_DAP_TDI__LPUART5_RX to 0x31e . Power off the board completely and power it on again. Check whether the WLAN firmware can be initialized successfully. Please share the result with me. Thanks, Regards, Weidong

ICEを使用したPROFINET上の周期的および非周期的通信 こんにちは、 私はFRDM i.MX RT1186ボード用のPROFINET入出力デバイスを開発しています。ICCツールでアプリケーションを作成し、ICEツールを使って動作を確認しました。 これまでにサイクリック通信をテストしましたが、wiresharkでコントローラが定期的にパケットを送受信していることがわかります。非巡回通信をテストすることは可能でしょうか？例えば、コントローラからIOデバイスを設定するための通信です。 goal_appl.c のappl_pnioCbWriteRecord 関数とappl_pnioCbReadRecord 関数は、私がやりたいことに関連しているようですが、ICE を介して非巡回通信をどのように実装すればよいのかわかりません。   よろしくお願いします！

Cyclic and acyclic communications on PROFINET with ICE Hi,  I'm working on a PROFINET I/O device for the FRDM i.MX RT1186 board. I have managed to create the application with the ICC tool and have used the ICE tool to verify that the application works. So far I have tested cyclic communications, and I can see on wireshark that the controller sends/receives packets periodically. I was wondering if it's possible to test acyclic communications. For example, communications intended to configure the IO device from the controller.   The functions appl_pnioCbWriteRecord, and appl_pnioCbReadRecord in goal_appl.c seem relevant for what I want to do, but I'm not sure how to implement the acyclic communications through ICE.   Thanks!

i.MX95 Android 15：88W8987 蓝牙 UART 超时和共享时钟带/UART RX 引脚问题 尊敬的恩智浦技术支持团队： 根据魏东的建议，我们正在为 i.MX95 平台上的蓝牙启动创建一个新的工单。Wi-Fi 现在可以正常工作了，但是我们需要指导如何在RESET期间保持正确的参考时钟选择的同时恢复蓝牙 UART 通信。 1. 硬件和软件配置 主机板：NXP i.MX95 19×19 EVK，B0 无线模块：u-blox JODY-W263-00B，基于 88W8987，通过 M.2 Key-E 接口连接。 电路板支持包。：汽车 Android 15.0.0_2.1.0 内核版本：6.12.23 Wi-Fi接口：通过uSDHC3的SDIO 蓝牙接口：LPUART5，暴露为/dev/ttyLP4 Wi-Fi 驱动程序：NXP mwifiex，来自automotive-15.0.0_2.1.0 ，版本 537.p9 固件：来自相应 Android 电路板支持包。固件库的sduart8987_combo.bin文件 固件版本：16.92.21.p151.4 固件大小：628,200 字节 我们打算继续采用推荐的 SDIO + UART 配置。 2. Wi-Fi激活失败及交换机观察 之前，已通过 SDIO 检测到该模块并完成固件传输，但固件激活失败，错误信息如下： Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! 调查期间，NXP 指出，RESET期间会对 88W8987 GPIO[8]/UART_SOUT 进行采样，以选择参考时钟： 低频：38.4 MHz 高：26 MHz 该信号在正常操作期间也用作蓝牙 UART TX 输出，并连接到主机 LPUART5 RX 输入。 在我们的 EVK 中，相关连接是： Module Bluetooth TX → M.2 J24 pin 22 → R607 → BT_UART5_RXD → R17 → SW1 contacts 7–8 → host LPUART5 RX 我们可重复观察到的现象是： 冷启动期间 SW1 触点 7–8 ON： Wi-Fi 固件激活失败，错误代码为0xf005 。 冷启动期间 SW1 触点 7–8 关闭： Wi-Fi 初始化成功并可运行。 我们还测试了建议的主机 RX 焊盘下拉配置： IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 然而，之前的测试并未解决SW1触点7-8导通的问题。我们随后提取的运行设备树显示RX焊盘配置为0x31e，因此我们希望获得关于完整配置及其在启动/RESET过程中生效时间的指导。 3. Wi-Fi 配置正常，但蓝牙功能失效 将 SW1 触点 7-8 保持关闭状态可使 Wi-Fi 工作，但也会断开模块蓝牙 TX 与主机 UART RX 的连接。因此，我们预计蓝牙初始化会失败，因为主机无法接收控制器响应。 由于该板没有外接显示屏，因此蓝牙功能是通过 ADB 进行测试的。 已安装的供应商配置如下： mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 供应商库默认将baudrate_bt设置为 3000000。UART 固件下载默认处于禁用状态；当前配置依赖于通过 Wi-Fi 驱动程序加载的组合固件。 蓝牙供应商 HAL 报告版本为 009.030，并成功打开 UART 设备： bt_vnd_init --- BT Vendor HAL Ver: 009.030 --- mchar_port set to /dev/ttyLP4 baudrate_fw_init is set to 3000000 open uart port successfully, fd=6, mchar_port=/dev/ttyLP4 然而，蓝牙协议栈仍处于BLE_TURNING_ON状态，最终中止： Can't start stack, last instance: starting HciHal 在关闭/恢复期间，供应商库还会报告： Read hci complete event failed timed out Failed to read HCI RESET CMD response! 源配置序列以 HCI RESET 命令开始。UART 设备打开成功，但尚未建立成功的控制器通信。 4. 请求指导 请问您能否就以下问题提供建议？ 在 i.MX95 上应该如何处理这个共享时钟配置/蓝牙 UART 信号？ 我们需要在 RESET 期间将模块的 TX/主机 RX 线置低，以选择 38.4 MHz 频率，然后在正常运行期间保持 UART 接收路径连接正常。 SW1 的 7-8 号触点和 LPUART5 RX 焊盘的推荐配置是什么？在特定的焊盘配置下，开关是否应该保持开启状态，还是需要进行额外的板级更改？ 下拉电阻必须在启动的哪个阶段应用？ Linux 设备树设置是否足够，还是必须在模块 RESET释放之前，由 U-Boot、系统管理器/SCMI 引脚控制或其他更早的初始化阶段配置此焊盘？ 请提供推荐的电源/RESET 和引脚控制顺序，包括对 W_DISABLE2#/蓝牙使能的任何必要处理，以确保正确的时钟采样和后续的 UART 操作。 请确认电路板支持包。提供的sduart8987_combo.bin：初始 UART 波特率、工作波特率、RTS/CTS 流控制以及任何所需的唤醒/睡眠设置或供应商配置条目。 此电路板支持包。中是否存在针对88W8987模块的已验证的DTS/补丁和蓝牙供应商配置？如有，请分享用于验证的参考配置和模块部件号。 我们研究了 SDIO-SDIO 替代方案，但从 Weidong 那里了解到，这些专用软件包已经过时，没有跟上内核升级的步伐。我们尚未在此目标设备上验证 SDSD 固件，希望使用标准的 SDIO + UART 架构来解决此问题。 我们可以提供完整的蓝牙日志、运行中的设备树、原理图摘录以及RESET和蓝牙初始化期间共享跳线/UART线的示波器测量结果。请告知哪些测量点和时间条件最有用。 感谢您一直以来对启用Wi-Fi的支持。我们恳请您指导我们如何在保持现有 Wi-Fi 配置的情况下完成蓝牙启动。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 请更改 baudrate_fw_init = 3000000 至 baudrate_fw_init = 115200 那就试试。 谢谢！ 此致， 卫东 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 主题：i.MX95 / JODY-W263：波特率测试结果及无需手动切换SW1的永久解决方案请求 亲爱的卫东， 感谢您的支持。我们已测试了您提出的将baudrate_fw_init从3000000更改为115200的建议。以下是测试结果以及仍然存在的启动时间问题。 我们需要为下周的集成活动找到一个永久解决方案，因此，如果您能就所需的配置或补丁提供指导，我们将不胜感激。 平台 板：NXP i.MX95 19×19 EVK，B0 模块：u-blox JODY-W263-00B / 88W8987，M.2 Key-E 电路板支持包。：汽车 Android 15.0.0_2.1.0 内核版本：6.12.23 蓝牙供应商 HAL：009.030 Wi-Fi接口：通过uSDHC3的SDIO 蓝牙接口：UART5， /dev/ttyLP4 固件： sduart8987_combo.bin 被调查的开关： SW1，开关部分 4，触点 7–8 ，位于通往主机的蓝牙 UART RX 路径上。 1. 将 SW1 的 7-8 号触点拨至 ON 位置进行启动 Wi-Fi固件激活失败： Fail to poll firmware status: firmwarestat=0xf005 FW failed to be active in time! WLAN: Fail download FW with nowwait: 0 蓝牙也无法进入开启状态。 我们已应用推荐的Linux RX焊盘配置： IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 我们提取了运行中的设备树，并验证了该值存在，并且已被启用的 UART5 节点引用。然而，开机启动问题仍然存在。 2. 初始化波特率为 3000000 的工作序列 以下步骤可使 Wi-Fi 和蓝牙正常工作： 开机前 请保持SW1触点7-8 关闭 。 接通板电源，等待固件初始化完成。 确认： [12.738590] WLAN FW is active [12.954531] wlan: Driver loaded successfully 关闭蓝牙并确认STATE_OFF 。 在板运行的情况下，将 SW1 触点 7-8 物理打开。 启用蓝牙。 其中： baudrate_fw_init = 3000000 baudrate_bt = 3000000 我们获得了： wait-for-state:STATE_ON: Success enabled: true state: ON Wi-Fi 仍然连接到P3 设备，IP 地址为10.17.36.30 ，请求状态为COMPLETED ，网络状态为 VALIDATED 。 之前使用这种手动切换顺序也能成功进行蓝牙扫描和配对。在最新的 3M 对比测试中，蓝牙开启和 Wi-Fi 连接均已确认。 3. 测试推荐的初始化波特率 115200 我们重新构建并刷写了厂商/超级镜像以及匹配的板 AVB 元数据，内容如下： mchar_port = /dev/ttyLP4 baudrate_dl_image = 115200 iSecondBaudrate = 3000000 baudrate_fw_init = 115200 baudrate_bt = 3000000 已部署的配置和 HAL 日志均证实使用了115200 。 我们按照相同的步骤进行操作：启动时触点 7-8 关闭，确认 WLAN 固件已激活，禁用蓝牙，物理打开触点 7-8，然后启用蓝牙。 Wi-Fi 可以继续运行，但蓝牙初始化失败： baudrate_fw_init is set to 115200 open uart port successfully, fd=6, mchar_port=/dev/ttyLP4 Read hci complete event failed timed out. Total_duration = 1000 Failed to read HCI RESET CMD response! config_uart failed 适配器未达到STATE_ON 状态；蓝牙协议栈初始化反复失败。 仅将初始化波特率设置恢复为3000000 ，并在保留相同的实验性引导加载程序和内核的情况下重建映像后，蓝牙通过相同的启动时关闭 → 初始化后开启的序列实现了开启。 4. 额外的启动时间实验 我们还测试了： 将 RX 0x51e配置添加到 U-Boot 早期引脚控制占用中。 一项实验性的 SCMI pinctrl 驱动程序更改，旨在为零偏移的 DAP_TDI 引脚添加多路复用请求。原始驱动程序条件if (mux_ofs)会跳过此引脚的多路复用请求，因为其多路复用偏移量为零。 这些实验并没有解决启动失败的问题。我们尚未通过早期串行日志确认何时应用了配置，或者 SCMI 请求是否成功。因此，我们认为这些改动并不能证明是有效的解决方案。 请求提供永久解决方案 手动切换顺序对于调试很有用，但不适用于正常运行。我们需要 Wi-Fi 和蓝牙在整个上电和运行过程中，无需用户干预，就能可靠地初始化，并且开关 SW1 的 7-8 号触点始终保持开启状态。 请您审核这些结果并提供以下信息： 鉴于在我们的比较中，115200 波特率失败而 3000000 波特率成功，因此，对于使用此组合固件的 JODY-W263 / 88W8987，正确的初始化波特率是 3000000。 初始化期间保持正确的 GPIO[8]/UART_SOUT 跳线状态，同时保持 UART 操作，所需的引脚配置和模块电源/RESET 顺序。 合适的实施位置——系统管理器、SPL/U-Boot、Linux pinctrl/MMC 电源时序控制或硬件更改。 针对我们的板/电路板支持包。 的特定补丁或已验证的配置，包括任何所需的 GPIO 极性、复位时序或引脚所有权更改。 另外，请确认 SCMI pinctrl 驱动程序中的零偏移多路复用器处理是否是 i.MX95 的有意设计。 我们可以提供完整的成功和失败日志、运行中的设备树、源代码差异和 SW1 照片。请与我们联系您还需要哪些早期启动跟踪信息。 感谢您帮助我们从手动操作流程过渡到可靠的永久解决方案。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 请确认您的 u-blox wifi/bt 模块的波特率是否固定。 如果固定波特率为 115200，请尝试以下配置： mchar_port = /dev/ttyLP4 baudrate_fw_init = 115200 如果固定波特率为 3000000，请使用以下配置 mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 那就试试吧。 我下周有时间测试一下。你可以先试试。 BYW，我不太明白你的操作。要关闭再重新打开 Wi-Fi，您只需通过 Android 系统即可完成。无需操作板上的SW1开关。 谢谢！ 顺祝商祺！ 卫东 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 亲爱的卫东， 感谢您的回复，也感谢您愿意下周进行测试。 我们查阅了u-blox JODY-W2系统集成手册，UBX-18068879，修订版R14 ： 第 17 页记录了默认的 UART 波特率为3000000 。 第 2.4.2 节，第 29 页指出，固件加载后的波特率为3000000 ，其他支持的波特率可以使用专用的 HCI 波特率命令进行配置。 因此，官方记录的默认值为 3M；UART 并未被描述为永久限制于此速率。 我们的测试也支持以下配置： mchar_port = /dev/ttyLP4 baudrate_fw_init = 3000000 baudrate_bt = 3000000 在 WLAN 固件激活且 UART 路径连接的情况下，初始化过程在115200处反复超时，等待 HCI RESET 响应。恢复到3000000后，蓝牙状态变为启用：true，状态：开启，而 Wi-Fi 连接仍然保持连接。 我还想澄清一下物理开关的操作。我们并非通过操作 SW1 来切换 Wi-Fi 的开关状态。 根据 i.MX95 EVK 底板原理图 SPF-87753-B，第 4 页，我们按以下路径操作SW1 第 4 部分，触点 7–8 ： 主机 JTAG_TDI / LPUART5_RX ↔ SW1 触点 7–8 ↔ R17 (49.9 Ω) ↔ BT_UART5_RXD 朝向 M.2。 此处，R17 为板电阻参考。与 u-blox 文档修订版中的 R14 不同。板电阻 R14 属于不同的 CTS 通道。 我们观察到的行为是： 开机前触点 7–8 接通： WLAN 固件激活失败，固件状态为 0xf005 。 开机前触点 7–8 关闭： WLAN 固件初始化成功。 固件初始化后，触点 7-8 开启：蓝牙初始化至 3M，Wi-Fi 保持连接。 已应用推荐的 Linux RX 下拉配置： IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 我们验证了该值以及运行设备树中已启用 UART5 节点的引用。但是，仍然需要手动切换顺序。 Android 的 Wi-Fi 开关操作并不会物理断开/重新连接此 UART 信号路径。因此，剩下的问题是如何在整个启动和运行时保持 SW1 触点 7-8 开启的情况下可靠地进行初始化。 请您调查一下所需的早期引脚配置和模块电源/RESET 顺序，并告知永久解决方案是否需要系统管理器、U-Boot、Linux 或硬件更改？ 我们可以提供原理图摘录、开关照片和早期串行日志供您测试。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 好的，明白了。抱歉，我忽略了开关。 是的，如果要在 M.2 上使用 LPUART5，需要通过 SW1 启用所有 LPUART5 信号。 因为 LPUART5 信号是通过这些 JTAG 焊盘进行多路复用的。 但SW1不影响系统启动。 配置， IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 只需在 Linux 设备树中进行配置即可。 u-boot 设备树中不需要。 谢谢！ 此致， 卫东 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 亲爱的卫东， 感谢您澄清了 SW1 的路由，并说明 RX 下拉配置仅需要在 Linux 设备树中进行。 请问仅此配置是否能完全解决 Linux 和 Automotive Android 15.0.0_2.1.0 上的 88W8987 初始化问题？ IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 此设置已在我们正在运行的 Android 设备树中应用和验证。然而，我们观察到的现象依然存在： SW1 触点 7–8 在上电前处于 ON 状态：WLAN 固件激活失败，固件状态为 0xf005 。 开机前触点断开：WLAN固件成功激活。 固件激活后联系人开启：蓝牙初始化距离为 3 米，Wi-Fi 保持连接。 需要澄清的是，我们的问题与 WLAN 固件激活有关，而不是 i.MX95 系统本身的启动有关。 您是否已验证在 Linux 和车载 Android 系统上，从冷启动开始，所有必需的 SW1 部分始终保持开启状态，Wi-Fi 和蓝牙初始化是否正常？请提供测试模块的部件号、电路板支持包。版本以及所需的任何其他补丁或电源/复位顺序更改。 我们的目标是在无需手动操作SW1的情况下实现可靠的初始化。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 我已经在我的 i.MX95-EVK 上多次测试过，包括同时进行 Wi-Fi 和蓝牙操作、冷 RESET 以及完全断电/开机循环。 在我的测试过程中，所有四个 SW1 开关都保持开启状态，因为 LPUART5 信号是通过这四个 JTAG 引脚传输的。开机或Wi-Fi/蓝牙初始化期间，我不会更改SW1设置。 这是我用于测试的 i.MX95-EVK 的照片。请检查您的 i.MX95-EVK 是否为相同的硬件版本。 我的设备上没有出现这个问题。 您的电路板运行情况非常不寻常。我还注意到另一点：您使用的是 Android 15.0.0_2.1.0 版本。电路板支持包。，但是您提到的内核版本与我们 BSP 中包含的实际内核版本不匹配。我不确定为什么会出现这种差异。     谢谢！ 顺祝商祺！ 卫东     Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 亲爱的卫东， 感谢您确认 Wi-Fi 和蓝牙在您的设置中能够正常工作，经过反复冷 RESET 和完全断电重启，并且所有四个 SW1 部分都保持开启状态。 我们的配置如下： 电路板：NXP i.MX95 19×19 EVK，B0 硅 模块：u-blox JODY-W263-00B，基于 88W8987，通过 M.2 适配器连接 接口：通过 SDIO 实现 Wi-Fi，通过 LPUART5 实现蓝牙 电路板支持包。：汽车 Android 15.0.0_2.1.0 先前观察到的运行内核版本： 6.12.23-4k-ge0732a9b6eb5-dirty 蓝牙 UART： /dev/ttyLP4 ，初始化波特率和运行时波特率均设置为3000000 下面列出的 Linux RX 下拉设置已在我们的运行设备树中应用并验证： IMX95_PAD_DAP_TDI__LPUART5_RX 0x51e 但是，我们仍然要求在开机和 WLAN 固件初始化期间，SW1 的 7-8 号触点保持关闭状态，然后在蓝牙运行时保持开启状态。如果这些触点在开机时处于开启状态，则 WLAN 固件激活会失败，并显示firmwarestat=0xf005错误。 我们的板将在未来两天内无法提供服务。同时，能否请您提供已验证设置的完整详细信息，以便我们将其与我们的设置进行比较，并评估哪些更改可以移植到我们的 Android 电路板支持包。中？ 请提供确切的硬件信息： Wi-Fi/蓝牙模块制造商及完整零件编号、M.2适配器零件编号/版本号，以及EVK底板/SOM版本号。请确认您是否专门测试过JODY-W263-00B模块。 具体软件：请说明所报告的成功测试是在 Linux、车载 Android 系统还是两者上进行的。对于每个测试环境，请提供电路板支持包。版本、内核版本和提交记录，最好还能提供`uname -a`命令的输出结果。您提到我们的内核版本存在差异；请确定我们所提供的电路板支持包。对应的预期内核版本。 完整的设备树更改：最终可用的电路板设备树 (DTS)，包括 DTSI 文件、所有设备树覆盖层/DTBO 源文件以及相关的版本配置。针对精确的电路板支持包。基线提供补丁将尤为重要。 驱动程序和固件： Wi-Fi 驱动程序版本/分支/提交、确切的 Wi-Fi/蓝牙固件文件名和版本，以及蓝牙 HAL/供应商配置，包括 UART 波特率和流控制。 其他必要的更改：您当前工作环境中使用的任何内核配置、引脚控制、稳压器、SDIO 电源/RESET 顺序、系统管理器、U-启动 或硬件更改。请明确确认是否需要对这些方面进行任何更改。 复现流程：从干净的电路板支持包。到工作镜像的步骤，包括所有补丁、构建目标、烧录步骤、开关/跳线位置以及冷上电测试期间使用的 Wi-Fi/蓝牙初始化序列。 请确认 Linux DTS RX 下拉包是否是解决此问题的唯一必要更改，或者您的工作镜像是否包含其他更改。 我们的目标仍然是 Automotive Android 15.0.0_2.1.0。我们希望评估将必要的更改移植到此 电路板支持包。中，目标是在启动和运行时保持所有必需的 SW1 部分开启的情况下，可靠地初始化 Wi-Fi 和蓝牙。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 亲爱的卫东， 我无法在此处上传原理图文件，因此我分享一下NXP的官方页面，其中包含这两个设计包： https://www.nxp.com/design/design-center/development-boards-and-designs/IMX95LPD5EVK-19 请从“设计文件” 下 下载： SPF-87753-B — i.MX 95 19EVK 底板设计文件 SPF-87754-B — i.MX 95 19EVK 计算模块设计文件 这些是我们在 i.MX95 19×19 EVK 设置中使用 u-blox JODY-W263-00B (88W8987) 模块时所用的原理图参考。 请您将它们与您测试过的硬件进行比较，特别是 SW1/LPUART5 路由、M.2 接口和模块电源/RESET 电路？请与我们联系，告知是否有任何差异可以解释在固件初始化期间需要断开 SW1 触点 7-8 的原因，并就所需的更改提出建议。 此致， 拉凯什·库马尔·塔库尔 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 看来你的 i.MX95-EVK 可能和我的不一样。请问您有采用 B0 硅片的 i.MX95 19×19 EVK 的电路图吗？您能否也分享给我一份，以便我进行比较？     谢谢！ 顺祝商祺！ 卫东 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 你好@Rakesh_Kumar_Thakur ， 我也用到了原理图。 但我这边没问题。 能否将您的 8987 Wi-Fi 模块寄给我？我想在我这边测试一下。     谢谢！ 顺祝商祺！ 卫东 Re: i.MX95 Android 15: 88W8987 Bluetooth UART timeout and shared clock-strap/UART RX pin issue 尊敬的@Rakesh_Kumar_Thakur ， 首先，请问您的u-blox JODY-W263-00B是否使用26MHz的参考时钟？ 如果使用的是 26 MHz，则 IMX95_PAD_DAP_TDI__LPUART5_RX 0x31e 应该是正确的设置。 请尝试以下步骤： 将四个 SW1 开关全部设置为ON并保持 ON 状态。 将 IMX95_PAD_DAP_TDI__LPUART5_RX 设置为 0x31e 。 完全关闭板电源，然后再重新开启电源。 检查WLAN固件是否可以成功初始化。 请把结果告诉我。 谢谢！ 此致， 卫东