你好
我目前正在尝试使用与 IW612 配对的 i.MX 8ULP 启用线程(802.15.4)功能。但是,ot-daemon 无法启动。内核日志显示以下错误:
spidev spi0.0:设置:不支持的模式 位数 20000
出现这个问题的原因是 i.MX 8ULP 上的 lpspi 主机驱动程序不支持 SPI_MOSI_IDLE_LOW (0x20000) 模式位。尽管ecspi(在较早的i.MX系列中使用)支持这一点,但从lpspi硬件寄存器来看,似乎无法本机控制MOSI IDLE状态。
在研究 ot-daemon 源代码后,我发现 SPI_MOSI_IDE_LOW 被明确设置为在 MOSI 上产生上升沿,将 RCP 从深度睡眠中唤醒。以下补丁引入了这一行为:
https://github.com/nxp-imx/meta-nxp-connectivity/blob/imx_matter_2026_q1/meta-nxp-openthread/recipes...
在 Linux 6.12 上运行 OpenThread、我正在考虑恢复或放弃这个补丁。能否请您澄清以下几点?
环境详情:
内核:Linux 6.12(lf-6.12.y 分支)
OpenThread:openthread-iwxxx(meta-nxp-连接/imx_matter_2026_q1)IW612 固件:sduart_nw61x_v1.bin.se(imx-固件/lf-6.12.49_2.2.0)
谢谢,
mizo
你好,@水渊大辅
感谢您为我们创建案例。
让我仔细核对一下信息。
请给我一点时间。
我会尽快回复您。
顺祝商祺!
Christine。
你好,@水渊大辅
对不起,我的回复晚了。
在我检查了您的需求并与我们的内部团队讨论后,我需要创建一个内部案例,向我们的专家团队寻求进一步帮助。 这样我们才能给你一个确定的答复。因为正如您所提到的,这是有关补丁的详细信息。
请再给我一些时间,一旦有任何更新,我会通知你们的。
顺祝商祺!
Christine。
你好,@水渊大辅
感谢您的耐心等待。
我们的内部团队已对该问题进行了调查,并确认了问题的根本原因和建议的解决方法。下面是我们对您所提问题的答复。
关于这个问题,错误是 spidev spi0.0:设置:不支持的模式位数 20000 是由补丁 0062-host-host-handle-patch 上的 power-save-save-mode-on-ssp-rxd.patch(存在于 meta-nxp-connectivity/imx_matter_2026_q1 中)在初始化期间无条件调用 ioctl(SPI_IOC_WR_MODE32、SPI_MOSI_IDLE_LOW)造成的。
i.MX8ULP 上的 LPSPI 控制器在硬件级不支持 SPI_MOSI_IDLE_LOW (0x20000) 模式位。这与支持该功能的旧版 ECSPI 不同。因此,ioctl 调用返回 EINVAL,从而产生内核警告。
问 1: IW612 RCP 在正常运行期间(如边界路由器或路由器)是否真的会进入深度睡眠模式?
[恩智浦]:没有。只有当线程无线电明确进入休眠状态时,IW612 RCP 才会进入深度睡眠模式(DSM)。在边界路由器或路由器角色中,无线电持续处于接收状态,在正常网络运行期间不会进入 DSM。
问题 2: 如果无法进入深度休眠状态,是否可以使用 0062 补丁作为安全有效的解决方法?
[恩智浦]: 是的,对于边界路由器/路由器用例,这是可以接受的。由于 RCP 在活动网络运行期间不会进入深度休眠状态,因此这里不需要 0062 补丁提供的唤醒机制,放弃该补丁将允许 ot-daemon 启动,而不会出现错误。
问题 3:对于基于 LPSPI 的平台,是否有任何官方推荐的变通方法或设备树配置?
[恩智浦]:无需更改设备树。这纯粹是用户空间 ot-daemon SPI 接口的问题。推荐的修复程序是0074-fix-spi-idle-low-warning-setting.patch 补丁,我会单独发送到您的私人邮箱,这将有助于您的修复、
请帮助在 imx_matter_2026_q1 版本的基础上手动应用共享用户空间 ot-daemon 应用程序端补丁,并确认它是否有助于解决此内核警告。
如果在应用更改后仍遇到问题,请帮助分享详细的重现步骤和驱动程序日志。
顺祝商祺!
Christine。