Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
DDR 工具发送 pmic_set 命令失败。 您好, 目前,我正在尝试在 DDR Tool 中调整 PCA9450C 的 BUCK6 输出电压,但我遇到了一个问题。 我将以下命令烧录到 i.MX8M Plus 开发板上,并确认 PCA9450C 确实已连接到 I2C1: 内存集 0x30330200 32 0x00000010 # I2C1_SCL 多路复用器 (SION=1) 内存集 0x30330204 32 0x00000010 # I2C1_SDA 多路复用器 (SION=1) 内存集 0x30330460 32 0x000001C6 # I2C1_SCL 焊盘 内存集 0x30330464 32 0x000001C6 # I2C1_SDA 焊盘 sysparam set pmic_cfg 0x004A sysparam set pmic_set 0x1E11 下载完 .ds 文件后文件执行后,UART 控制台返回了以下日志: PMIC 在 DDR 脚本中初始化 I2C_I2SR(0x30a2000c):0x81 总线还没准备好 错误:PMIC 寄存器[0x1e]初始化失败,值为[0x11] 用示波器检查 I2C1 SCL 和 SDA 线时,我发现两条线都被拉低并锁存。只有在断电重启后,它们才会恢复到默认的高电平状态。 此外,我已经验证,如果我注释掉 #sysparam 命令,就可以在 I2C 总线上成功观察到默认的 PMIC 初始化波形,并且 UART 日志正确地表明 PCA9450 已被检测到。 Re: Failed to send the pmic_set command in the DDR Tool. 我找到了根本原因。IOMUXC_I2C1_SDA_IN_SELECT_INPUT (0x303305A4) 和 IOMUXC_I2C1_SCL_IN_SELECT_INPUT (0x303305A8) 寄存器未配置。我建议将这些细节添加到应用笔记中,以供将来参考。谢谢!” Re: Failed to send the pmic_set command in the DDR Tool. 注释掉#sysparam后,我使用示波器捕获了 i.MX8M Plus 写入 PCA9450C 的默认配置。捕获到的序列如下: 0x25W,0x00 0x25R,0x31 0x25W、0x0C、0x29 0x25W、0x11、0x1C 0x25W、0x12、0x14 0x25W、0x10、0x59 0x25W、0x1E、0x14 基于这些发现,我将这些命令添加到了 .ds 文件中。文件: # 2. IOMUX 配置。(SION=1,ODE=1,内部上拉) 内存集 0x30330200 32 0x00000010 # I2C1_SCL 多路复用器 (SION=1) 内存集 0x30330204 32 0x00000010 # I2C1_SDA 多路复用器 (SION=1) 内存集 0x30330460 32 0x00000176 # I2C1_SCL 焊盘 内存集 0x30330464 32 0x00000176 # I2C1_SDA PAD sysparam set pmic_cfg 0x0025 # PMIC 地址 sysparam set pmic_set 0x0C29 # 将 BUCK1 和 BUCK3 设置为 0.85V,将 BUCK2 设置为 0.9V sysparam set pmic_set 0x111C # BUCK1 DVS0 = 0.95V 系统参数设置 pmic_set 0x1214 # BUCK1 DVS1 = 0.85V sysparam set pmic_set 0x1059 # BUCK1CTRL = 0x59(通过 PMIC_STBY_REQ 进行 DVS 控制) sysparam set pmic_set 0x1E11 # BUCK6 设置为 1.025V 然而,UART 控制台仍然卡在这个阶段。与之前略有不同,它不再抛出任何错误信息,而是直接停止运行: 下载完成 等待目标板启动…… 使用示波器检查 I2C1 SCL 和 SDA 线时,其行为与之前相同:两条线都被拉低并锁定,只有在断电重启后才会恢复到默认的高电平状态。 Re: Failed to send the pmic_set command in the DDR Tool. 如果禁用预配置的 PMIC 初始化,则需要手动完成所有操作。 在i.MX 93 EVK板上,默认的 PMIC I2C 总线是 I2C 2。 要将其更改为 I2C 1,您需要设置正确的引脚复用: 然后你需要发送正确的命令:(例如) 命令说明: 数量 Command Value 说明 0 pmic_cfg 0x0025 I2C总线1 (0 代表 I2C1,1 代表 I2C2,2 代表 I2C3,3 代表 I2C4……) PMIC 地址 0x25 1 pmic_set 0x0C29 寄存器=0x0C BUCKxOUT_DVS0/1 预设降压电压1=0.8V,preset_buck2=0.7V,预设降压3=0.8VPCA9451_BUCK123_DVS 值=0x29 2 pmic_set 0x1118 寄存器=0x11 BUCK1OUT_DVS0=0.9V PCA9451_BUCK1OUT_DVS0 值=0x18 3 pmic_set 0x1718 寄存器=0x17 BUCK3OUT_DVS0=0.9V PCA9451_BUCK3OUT_DVS0 值=0x18 4 pmic_set 0x1428 寄存器=0x14 将 VDDQ 设置为 1.1V PCA9451_BUCK2OUT_DVS0 值=0x28 BUCK6 设置将位于寄存器 0x1D 和 0x1E 中。 希望对您有所帮助。 伯恩哈德。 Re: Failed to send the pmic_set command in the DDR Tool. 哦,对了,就是著名的DAISY收银机。抓得好! 选择自定义配置时,所有设置都需要手动完成。你说得对,在引脚配置方面,DAISY 寄存器并不是重点。对于 UART 引脚复用设置,除了标准的引脚复用和焊盘设置外,它还出现在 RX 信号的 ds 中。但对于 I2C,固件会在后台进行默认配置,您在 ds 文件中看不到这些设置。 顺便提一下,对于 i.MX 93,I2C1 和 I2C2 没有 DAISY 链寄存器,但 I2C3-8 有。 我会将您的反馈意见反馈给我们的工具组,这个细节应该包含在配置工具的用户手册中。或者,或者此外,I2C 接口设置应该出现在 ds 文件中。 问候, 伯恩哈德。
記事全体を表示
Failed to send the pmic_set command in the DDR Tool. Hi, Currently, I am trying to adjust the BUCK6 output voltage of the PCA9450C in the DDR Tool, but I have run into an issue. I flashed the following commands onto the i.MX8M Plus board and confirmed that the PCA9450C is indeed connected to I2C1: memory set 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) memory set 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) memory set 0x30330460 32 0x000001C6 # I2C1_SCL PAD memory set 0x30330464 32 0x000001C6 # I2C1_SDA PAD sysparam set pmic_cfg 0x004A sysparam set pmic_set 0x1E11 After downloading the .ds file, the UART console responded with the following logs: PMIC is initialized in DDR script I2C_I2SR(0x30a2000c):0x81 bus is not ready Error: PMIC reg[0x1e] initilaization failed with value[0x11] When checking the I2C1 SCL and SDA lines with an oscilloscope, I observed that both lines are pulled low and latched. They only return to their default pulled-high state after a power cycle. Furthermore, I have verified that if I comment out the #sysparam commands, I can successfully observe the default PMIC initialization waveforms on the I2C bus, and the UART log correctly indicates that the PCA9450 has been detected. Re: Failed to send the pmic_set command in the DDR Tool. I have found the root cause. The IOMUXC_I2C1_SDA_IN_SELECT_INPUT (0x303305A4) and IOMUXC_I2C1_SCL_IN_SELECT_INPUT (0x303305A8) registers were not configured. I suggest adding this details to the application note for future reference. Thanks!" Re: Failed to send the pmic_set command in the DDR Tool. After commenting out #sysparam I used an oscilloscope to capture the default configurations that the i.MX8M Plus writes to the PCA9450C. The captured sequence is as follows: 0x25W, 0x00 0x25R, 0x31 0x25W, 0x0C, 0x29 0x25W, 0x11, 0x1C 0x25W, 0x12, 0x14 0x25W, 0x10, 0x59 0x25W, 0x1E, 0x14 Based on these findings, I appended these commands to the .ds file: # 2. IOMUX config. (SION=1, ODE=1, internal pull up) memory set 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) memory set 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) memory set 0x30330460 32 0x00000176 # I2C1_SCL PAD memory set 0x30330464 32 0x00000176 # I2C1_SDA PAD sysparam set pmic_cfg 0x0025 # PMIC address sysparam set pmic_set 0x0C29 # BUCK1&3 set to 0.85V, BUCK2 set to 0.9V sysparam set pmic_set 0x111C # BUCK1 DVS0 = 0.95V sysparam set pmic_set 0x1214 # BUCK1 DVS1 = 0.85V sysparam set pmic_set 0x1059 # BUCK1CTRL = 0x59 (DVS control through PMIC_STBY_REQ) sysparam set pmic_set 0x1E11 # BUCK6 set to 1.025V However, the UART console still gets stuck at this stage. Slightly different from before, it no longer throws any error messages, and just stops here: Download is complete Waiting for the target board boot... When checking the I2C1 SCL and SDA lines with an oscilloscope, the behavior remains the same as before: both lines are pulled low and latched, and they only return to their default pulled-high state after a power cycle. Re: Failed to send the pmic_set command in the DDR Tool. If you disable the pre-configured PMIC initialisation, you need to do everything by hand. On the i.MX 93 EVK board, the default PMIC I2C Bus is I2C2. To change it to I2C1, you need to set the right pinmux: Then you need to send the right commands: (example) Explanation of the commands: # Command Value Description 0 pmic_cfg 0x0025 I2C bus 1 (0 for I2C1, 1 for I2C2, 2 for I2C3, 3 for I2c4 …) PMIC address 0x25 1 pmic_set 0x0C29 register=0x0C BUCKxOUT_DVS0/1 preset_buck1=0.8V, preset_buck2=0.7V, preset_buck3=0.8V PCA9451_BUCK123_DVS value=0x29 2 pmic_set 0x1118 register=0x11 BUCK1OUT_DVS0=0.9V PCA9451_BUCK1OUT_DVS0 value=0x18 3 pmic_set 0x1718 register=0x17 BUCK3OUT_DVS0=0.9V PCA9451_BUCK3OUT_DVS0 value=0x18 4 pmic_set 0x1428 register=0x14 Set VDDQ to 1.1V PCA9451_BUCK2OUT_DVS0 value=0x28 BUCK6 settings would be in registers 0x1D and 0x1E. Hope it helps, Bernhard. Re: Failed to send the pmic_set command in the DDR Tool. Oh yes, the famous DAISY register. Good catch!  When a custom configuration is selected, EVERYTHING needs to be set by hand. And you're right, the DAISY registers are not really in the focus when it comes to pin configurations. For the UART pin mux settings it appears in the ds for the RX signal, besides the  standard pin mux and pad settings. But for I2C the firmware is doing it as a default configuration in the background, you don't see the settings in the ds file. As a side note, for the i.MX 93, the DAISY chain register does not exist for I2C1 and I2C2, but it does for I2C3-8. I feed you input back into our tool group, this detail should be part of the User's Manual for the Config Tool. Alternatively, or in addition, the I2C interface settings should appear in the ds file. Regards, Bernhard.
記事全体を表示
OP-TEE in Falcon Mode || iMX8MP_EVK Hi, I want to enable OP-TEE along with Falcon Mode on the i.MX8MP EVK. Machine: imx8mpevk Repository: https://github.com/nxp-imx/imx-manifest Branch: imx-linux-walnascar XML: imx-6.12.34-2.1.0.xml Currently, I am using meta-imx-fastboot (lf-6.12.20-2.0.0-secure) to achieve fast boot via Falcon Mode. However, when Falcon Mode is enabled, OP-TEE gets disabled. As per my requirement, I need both OP-TEE and Falcon Mode to be enabled simultaneously. Could you please guide me on how to enable OP-TEE in Falcon Mode on the i.MX8MP EVK? i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Security Yocto Project Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @Sanjiv_Mns  Currently, the meta-imx-fastboot layer does not support OP-TEE. It should be possible in principle, but it is not implemented yet. Explanation: In the default BSP, the OP-TEE start address and size are calculated during the U-Boot proper boot stage based on the rom_pointer (see: https://github.com/nxp-imx/uboot-imx/blob/lf-6.12.20-2.0.0/arch/arm/mach-imx/dt_optee.c#L13). The rom_pointer has different meaning/values in the SPL, compared to U-Boot proper. So, the ft_add_optee_node function cannot be executed from SPL without further changes. Thanks, Elena Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @elena_popa  Could you please guide me on how to proceed further to achieve the SPL → OP-TEE → Linux boot flow? I’d like to understand the correct steps and components involved to make this work reliably. I also came across the following link where a similar flow was implemented on STM32MP platforms: https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ Could you please let me know whether this approach is applicable to my use case, or if parts of it can be reused or adapted for achieving the same boot sequence on my platform? Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @elena_popa I have already completed this activity, and it is now booting successfully on my i.MX8MP board. The current boot flow is: SPL → ATF → OP-TEE → Linux Everything is working as expected. Thank you for your comments @elena_popa   [ 0.412349] optee: probing for conduit method. [ 0.412373] optee: revision 4.6 (788dc101b05ae47b) [ 0.412678] optee: dynamic shared memory is enabled [ 0.413062] optee: initialized driver Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @Sanjiv_Mns  I managed to enable and run OP-TEE in Falcon Mode for i.MX 8MP.  The boot flow on i.MX 8MP will be: SPL -> ATF -> OP-TEE -> Linux Here are the steps: 1. Remove the following line in the conf/layer.conf of the meta-imx-fastboot layer. MACHINE_FEATURES:remove = "optee"  2. In imx-boot mkimage source code, modify the iMX8M/mkimage_fit_atf_kernel.sh script to add the OP-TEE binary into the FIT image. 6a7,9 > # keep backward compatibility > [ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0xfe000000" > 19a23,41 > [ -z "$BL32" ] && BL32="tee.bin" > PAD=../scripts/pad_image.sh > > if [ ! -f $BL32 ]; then > BL32=/dev/null > else > echo "Building with TEE support, make sure $BL31 is compiled with spd. If you do not want tee, please delete $BL32" >&2 > if [ $TEE_COMPRESS_ENABLE ]; then > echo "Start compress $BL32" >&2 > rm -f $BL32.lz4 > lz4 -9 $BL32 $BL32.lz4 >&2 > BL32=$BL32.lz4 > ./$PAD $BL32 >&2 > fi > echo "$BL32 size: " >&2 > ls -lct $BL32 | awk '{print $5}' >&2 > LOADABLES="$LOADABLES, \"tee-1\"" > fi > 71a94,103 > tee-1 { > description = "TEE firmware"; > data = /incbin/("$BL32"); > type = "firmware"; > arch = "arm64"; > compression = "none"; > load = <$TEE_LOAD_ADDR>; > entry = <$TEE_LOAD_ADDR>; > }; > 87c119 < loadables = "kernel","dtb"; --- > loadables = "tee-1","kernel","dtb"; 3. In the kernel device tree, add manually the OP-TEE nodes (firmware and reserved memory). Edit the imx8mp.dtsi device tree and: - add the following OP-TEE firmware node in the root node ("/"). firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; }; }; - add the OP-TEE reserved memory regions under the reserved-memory node: optee_core@56000000 { reg = <0 0x56000000 0 0x1e00000>; no-map; }; optee_shm@57e00000 { reg = <0 0x57e00000 0 0x200000>; no-map; };  4. Build the image and write it on the boot device. 5. To check that OP-TEE has started and Linux probed the driver, run: root@imx8mp-lpddr4-evk:~# dmesg | grep optee [ 0.000000] OF: reserved mem: 0x0000000057e00000..0x0000000057ffffff (2048 KiB) nomap non-reusable optee_shm@57e00000 [ 0.000000] OF: reserved mem: 0x0000000056000000..0x0000000057dfffff (30720 KiB) nomap non-reusable optee_core@56000000 [ 2.581777] optee: probing for conduit method. [ 2.590862] optee: revision 4.8 (e7ed997213779e3d) [ 2.596363] optee: dynamic shared memory is enabled [ 2.601567] optee: initialized driver 6. If you want to test the OP-TEE you can run xtest. root@imx8mp-lpddr4-evk:~# xtest Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression+pkcs11+regression_nxp # ###################################################### * regression_1001 Core self tests o regression_1001.1 Core self tests regression_1001.1 OK o regression_1001.2 Core dt_driver self tests regression_1001.2 OK o regression_1001.3 Core transfer list self tests ..... +----------------------------------------------------- 49354 subtests of which 0 failed 161 test cases of which 0 failed 0 test cases were skipped TEE test application done! Please, let me know if you have issues during enablement. Thanks, Elena
記事全体を表示
カーネル6.6.92ではPN7160が応答しません 当チームはPN7160をカーネル6.6.92に移植しました。 しかし現在、NFCタグを 読み取ることができません 。 以下は、当社の被試験デバイス(DUT)に関する情報です。 カーネルバージョン: 6.6.92 OS: ヨクト・スカースギャップ PN7160 ドライバーパッチファイル: 0003-nfc-nxpnfc-add-NXP-PN7160-i2c-spi-kernel-driver.patch(NFCのGitHubリポジトリからクローンし、カーネル6.6に対応するように修正しました) nfcDemoApp レシピ: recipes-nfc.7z (NFC GitHub からクローンし、ビルドエラーを修正するために変更しました) カーネルログ: nfc-log.txt この問題を解決するためのアドバイスをいただけますか? 回复: PN7160 no response with kernel 6.6.92 libnfc-nxp.conf ファイルで LOGLEVEL を 0x03 に設定してください。次に、nfcDemoAppを実行したときのログを送ってください。確認のため、libnfc-nci.confとlibnfc-nxp.confも送ってください。
記事全体を表示
LSDK 25.12 udev 自动加载与 /boot/modules 布局的竞争 NXP团队您好, 我们使用的环境如下: * 平台:i.MX8MP * 发行版:Debian 13 / trixie * LSDK 版本:LSDK-25.12_DEBIAN-13_LF-6.12.20 * 内核版本:6.12.20 * systemd / udev: 257.x * kmod / libkmod:34.x 我们遇到了一个间歇性的冷启动问题,其中某些内核模块无法通过 udev 自动加载。就我们而言,受影响的设备主要是音频编解码器/音频链和 WLAN 模块。 症状包括: * `snd_soc_wm8962` 未加载 音频编解码器和音频平台设备仍然不受限制 `aplay -l` 报告没有声卡 * 无线局域网接口缺失 * 启动后手动运行 `modprobe` 或 `udevadm trigger --action=add` 可以恢复设备。 经过调试,我们发现该问题似乎与此 flexbuild 版本使用的内核模块布局有关。 在 `LSDK-25.12_DEBIAN-13_LF-6.12.20` flexbuild 标签中,`configs/debian/debian_post_config.sh`创建以下符号链接: ```sh ln -sf /boot/modules /lib/modules ``` 此外,`tools/create_bootpartition` 会将内核模块复制到启动分区: ```sh cp -rf $KERNEL_OUTPUT_PATH/$KERNEL_BRANCH/tmp/lib/modules $bootpartdir ``` 因此,在运行时,`/lib/modules` 依赖于 `/boot/modules`,而 `/boot` 稍后由 `boot.mount` 挂载。 我们还注意到 `src/system/启动.mount`包含: ```ini [Unit] Description=启动分区 Before=systemd-modules-load.service [山] What=UUID=PARTUUID 地点=/启动 类型=ext4 选项=默认值 [安装] WantedBy=local-fs.target ``` 这似乎是为了确保在由 `systemd-modules-load.service` 处理的静态模块加载路径之前挂载 `/boot`。 然而,我们的问题并非出在 `systemd-modules-load.service` 上。受影响的音频/WLAN模块由udev通过设备`MODALIAS`事件动态加载。 在启动失败的情况下,我们观察到受影响的设备事件是在 `boot.mount` 之前由 udev 处理的。已完成。此时,`/lib/modules` 指向 `/boot/modules`,但 `/boot` 尚未挂载。因此,libkmod 无法访问模块别名/索引文件或相应的 `.ko` 文件,所以 udev 模块自动加载路径失败。由于 udev 事件已被处理,除非我们手动重新触发 udev 或运行 `modprobe`,否则驱动程序不会再加载。 我们对失败路径的理解是: ```文本 内核设备添加事件 → udev 接收到 MODALIAS 事件 → udev/libkmod 尝试访问 /lib/modules → /lib/modules 指向 /boot/modules。 → /boot 尚未挂载 → 模块别名/索引文件或 .ko 文件文件不可用 → 模块自动加载失败 ``` 我们想确认以下事项: 1. 对于 LSDK 25.12 Debian 13 版本,`/lib/modules -> /boot/modules` 的布局是否符合预期? 2. 早期 udev 的 `MODALIAS` 处理和后期的 `boot.mount` 处理之间存在竞争关系吗?这是该布局的已知问题或已知局限性吗? 3. 我们注意到,当前的上游 flexbuild 主分支似乎已经改变了这种架构:内核模块不再通过 `create_bootpartition` 复制到启动分区,并且 `debian_post_config.sh` 中不再创建 `/lib/modules -> /boot/modules` 符号链接。 这种架构变更是否与避免这种早期启动模块自动加载竞争有关? 4. 对于 LSDK 25.12 Debian 13,NXP 针对此问题推荐的修复方案或变通方法是什么? 请与我们联系,告知我们我们的理解是否正确,以及该版本是否有官方补丁或推荐的更新途径。 谢谢。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: LSDK 25.12 udev autoload race with /boot/modules layout 您好, Q1:这样做的初衷是将内核映像和模块放在启动分区上,这样在升级内核时,只需要替换启动分区,而无需修改根文件系统。这种布局是故意设计的,并非错误。 Q2:你的推理是正确的;这是这种布局固有的局限性。 Q3:构建镜像时,您可以进行一次性调整,将根文件系统中的 `/boot/modules` 内容移动到 `/lib/modules`,并删除符号链接: rm -f /lib/modules mkdir -p /lib/modules cp -a /boot/modules/* /lib/modules/ 同时, 1. 修改构建脚本中的 `tools/create_bootpartition`,并删除 `cp -rf .../lib/modules $bootpartdir` 这行; 2. 修改 `debian_post_config.sh` 文件,并删除 `ln -sf /boot/modules /lib/modules` 这行; 3. 配置 `bld linux / modules_install` 目标,将模块安装到根文件系统中(参见 `main` 分支中 ` linux-modules`目标的实现)。 此致, 志明
記事全体を表示
S32K3MCU SENT slow channel Cannot receive data. Hello everyone I am using the SENT interface of the S32K311 to receive data, and I have encountered a situation where the fast channel receives data normally, but the slow channel is unable to receive any data. And I monitor the SENT error notification function, there are no exceptions. The MCU is S32K311 RTD version :S32DS 3.6.2 RTD6.0.0 SENT Sensor: Sensata Pressure Sensor Enhanced Slow message Firstly, I know that the SENT logic is processed in the "Flexio_Sent_Ip_ProcessSerialMsg" function, and subsequently, in the outer layer function, it monitors the "Data->SerialState" and "FastMsgCount" variables to determine if the slow channel has completed receiving data. So, I captured the relevant bit information. bit(x) : SENT Fast Channel Status Nibble bit S : "STATUS_SENT_SERIAL_SHORT". E : "STATUS_SENT_SERIAL_ENHANCED" I discovered that the parsing logic for the slow channel is repeatedly jumping and cannot be parsed normally. Does the processing logic of SENT have any errors when in a certain situation? thanks Re: S32K3MCU SENT slow channel Cannot receive data. any error log from SOC side? Re: S32K3MCU SENT slow channel Cannot receive data. Hello @khty, Could you share the Sensata sensor's sent configuration? From your images, I can see bit C in position 8 is set as 0; I assume 8-bit message ID, 12-bit data format is being used. Since your fast channel is received correctly and no SENT error notification is reported, I understand the issue is related to the processing function. I've not been able to find any known issues regarding slow channel reception; however, I've triggered a discussion with the internal team, let me try and get further information regarding this issue. Finally, are you able to provide a full capture of at least 18 consecutive SENT frames? This way we can further check whether the RTD state machine behavior matches the expected enhanced serial decoding sequence. Best regards, Julián Re: S32K3MCU SENT slow channel Cannot receive data. hello,and thank you for your quick response to my question. The sensor configuration information provided by Sensata is shown in the following figure: For your last request, a full capture of at least 18 consecutive SENT frames.I have provided it in the "bitChange.xlsx" file in the appendix. I have displayed the second and third bits of each captured status half-word in the table. In the table, each column represents a SENT message. Each large black square frame encompasses one slowChannel message. The blue area is the ID region, the green area is the CRC region, and the yellow area is the data region.And the information at the bottom is the result of manual analysis. If you need any additional information, please let me know, and I will respond as soon as possible. Re: S32K3MCU SENT slow channel Cannot receive data. The FAST Error Notification and SLOW Error Notification of SENT have reported no faults. You can read the data recorded in "bitchange.xlsx" for analysis, as it contains information on the 2 and 3 bits of each status half-word of the fast channel that I have recorded. Bit1 and Bit0 information are discarded because they have no meaning in the slow channel. At the same time, I have manually parsed the slow channel information and identified it with black squares. In "bitchange.xlsx", the data in the "State" row corresponds to "Flexio_Sent_Ip_axFastData[Instance][ChannelId].SerialState" in the code. This is responsible for detecting and identifying whether the slow channel is "Short" or "Enhanced". The "count" represents "Flexio_Sent_Ip_axFastData[Instance][ChannelId].FastMsgCount", which is responsible for counting the receive length of the slow channel. I believe the reason we are not receiving any Slow Channel data is that the code cannot correctly identify whether the slow channel is "Short" or "Enhanced". You can read "bitchange.xlsx" to discover that the identification state is constantly jumping between "STATUS_SENT_SERIAL_IDLE", "STATUS_SENT_SERIAL_SHORT", and "STATUS_SENT_SERIAL_ENHANCED". When the identification state transitions, the "Flexio_Sent_Ip_ProcessSerialMsg()" function returns "STATUS_FLEXIO_SENT_IP_ERROR", but this return value is only resetting SerialState and FastMsgCount in the upper-level function "Flexio_Sent_Ip_DmaDataProcessing()", and it does not call SentFastErrorNotif(). Therefore, I cannot obtain any error information through the fast Error Notification. In “bitChange.xlsx” We can start from column T, at this time SerialState = STATUS_SENT_SERIAL_IDLE, FastMsgCount = 0. When we receive column U, Flexio_Sent_Ip_ProcessSerialMsg()  believes bit3 == 1, so it considers this a start signal for slow channel and sets SerialState = STATUS_SENT_SERIAL_SHORT and FastMsgCount = 1. When we receive column V,Flexio_Sent_Ip_ProcessSerialMsg() believes bit3 == 0, so it keeps SerialState = STATUS_SENT_SERIAL_SHORT and increments FastMsgCount = 2. When we receive column W, Flexio_Sent_Ip_ProcessSerialMsg() believes bit3 == 1. At this point, since FastMsgCount == 2, it does not meet the condition to jump to STATUS_SENT_SERIAL_ENHANCED, and can only return STATUS_FLEXIO_SENT_IP_ERROR. In Flexio_Sent_Ip_DmaDataProcessing(), it resets SerialState and FastMsgCount. By the way, I am using DMA to receive SENT data, and I have only confirmed that there is an issue with the DMA reception method. At present, I cannot confirm whether the interrupt and polling methods also have the same problem. Re: S32K3MCU SENT slow channel Cannot receive data. Hi @khty, Thank you for the additional information. This makes it clearer.  This does seem to point to a potential RTD issue for parsing enhanced slow messages, however, since I lack the specific HW setup, I have not been able to reproduce the issue. I've forwarded this information to the internal team, and I will keep you updated on any new information. Best regards, Julián
記事全体を表示
LSDK 25.12 udev autoload race with /boot/modules layout Hi NXP team, We are using the following environment: * Platform: i.MX8MP * Distribution: Debian 13 / trixie * LSDK release: LSDK-25.12_DEBIAN-13_LF-6.12.20 * Kernel: 6.12.20 * systemd / udev: 257.x * kmod / libkmod: 34.x We encountered an intermittent cold boot issue where some kernel modules are not automatically loaded by udev. In our case, the affected devices are mainly the audio codec/audio chain and WLAN module. The symptoms include: * `snd_soc_wm8962` is not loaded * the audio codec and audio platform devices remain unbound * `aplay -l` reports no sound cards * the WLAN interface is missing * manually running `modprobe` or `udevadm trigger --action=add` after boot can recover the devices After debugging, we found that the issue seems related to the kernel module layout used by this flexbuild release. In the `LSDK-25.12_DEBIAN-13_LF-6.12.20` flexbuild tag, `configs/debian/debian_post_config.sh` creates the following symlink: ```sh ln -sf /boot/modules /lib/modules ``` Also, `tools/create_bootpartition` copies the kernel modules into the boot partition: ```sh cp -rf $KERNEL_OUTPUT_PATH/$KERNEL_BRANCH/tmp/lib/modules $bootpartdir ``` Therefore, at runtime, `/lib/modules` depends on `/boot/modules`, and `/boot` is mounted later by `boot.mount`. We also noticed that `src/system/boot.mount` contains: ```ini [Unit] Description=Boot Partition Before=systemd-modules-load.service [Mount] What=UUID=PARTUUID Where=/boot Type=ext4 Options=defaults [Install] WantedBy=local-fs.target ``` This appears to ensure that `/boot` is mounted before the static module loading path handled by `systemd-modules-load.service`. However, our issue is not from `systemd-modules-load.service`. The affected audio/WLAN modules are loaded dynamically by udev through device `MODALIAS` events. In failing boots, we observed that the affected device events are processed by udev before `boot.mount` has completed. At that moment, `/lib/modules` points to `/boot/modules`, but `/boot` has not been mounted yet. As a result, libkmod cannot access the module alias/index files or the corresponding `.ko` files, so the udev module auto-loading path fails. Since the udev event has already been processed, the driver is not loaded later unless we manually retrigger udev or run `modprobe`. Our understanding of the failing path is: ```text kernel device add event → udev receives the MODALIAS event → udev/libkmod tries to access /lib/modules → /lib/modules points to /boot/modules → /boot is not mounted yet → module alias/index files or .ko files are not available → module auto-loading fails ``` We would like to confirm the following: 1. Is the `/lib/modules -> /boot/modules` layout expected for the LSDK 25.12 Debian 13 release? 2. Is the race between early udev `MODALIAS` handling and the later `boot.mount` a known issue or known limitation of this layout? 3. We noticed that the current upstream flexbuild main branch appears to have changed this architecture: kernel modules are no longer copied into the boot partition by `create_bootpartition`, and the `/lib/modules -> /boot/modules` symlink is no longer created in `debian_post_config.sh`. Is this architecture change related to avoiding this kind of early boot module auto-loading race? 4. For LSDK 25.12 Debian 13, what is NXP’s recommended fix or workaround for this issue? Please let us know whether our understanding is correct and whether there is an official patch or recommended update path for this release. Thanks. i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: LSDK 25.12 udev autoload race with /boot/modules layout Hi, Q1: The original intention behind this was to place the kernel image and modules together on the boot partition, so that when upgrading the kernel, only the boot partition needs to be replaced, without having to modify the root filesystem. This layout is intentional and is not a bug. Q2:Your line of reasoning is correct; this is an inherent limitation of this layout. Q3: When building the image, you can make a one-time adjustment to move the contents of `/boot/modules` to `/lib/modules` in the root filesystem and remove the symbolic links: rm -f /lib/modules mkdir -p /lib/modules cp -a /boot/modules/* /lib/modules/ At the same time, 1. modify `tools/create_bootpartition` in the build script and remove the line `cp -rf .../lib/modules $bootpartdir`;  2. Modify `debian_post_config.sh` and remove the line `ln -sf /boot/modules /lib/modules`;  3. Configure the `bld linux / modules_install` target to install modules into the root filesystem (see the implementation of the `linux-modules` target in the `main` branch). Best Regards, Zhiming
記事全体を表示
DDRツールでpmic_setコマンドの送信に失敗しました。 こんにちは、 現在、DDR ToolでPCA9450CのBUCK6出力電圧を調整しようとしていますが、問題が発生しました。 以下のコマンドをi.MX8M Plusボードに書き込み、PCA9450Cが確かにI2C1に接続されていることを確認しました: メモリ設定 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) メモリセット 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) メモリセット 0x30330460 32 0x000001C6 # I2C1_SCL PAD メモリセット 0x30330464 32 0x000001C6 # I2C1_SDA PAD sysparam set pmic_cfg 0x004A sysparam set pmic_set 0x1E11 .dsファイルをダウンロードした後ファイルに対して、UARTコンソールは以下のログを出力しました。 PMICはDDRスクリプトで初期化されます I2C_I2SR(0x30a2000c):0x81 バスはまだ準備ができていません エラー: PMIC reg[0x1e] の初期化が値[0x11]で失敗しました オシロスコープでI2C1のSCLとSDAラインをチェックしたところ、両方のラインがプルダウンされてラッチされていることが確認できました。それらは電源を再投入した後にのみ、デフォルトのプルアップ状態に戻ります。 さらに、#sysparam コマンドをコメントアウトすると、I2Cバス上のデフォルトのPMIC初期化波形を正常に観察でき、UARTログもPCA9450が検出されたことを正しく示しています。 Re: Failed to send the pmic_set command in the DDR Tool. 根本原因を突き止めました。IOMUXC_I2C1_SDA_IN_SELECT_INPUT (0x303305A4) および IOMUXC_I2C1_SCL_IN_SELECT_INPUT (0x303305A8) レジスタが設定されていません。この詳細は将来の参考のためにアプリケーションノートに添付することをお勧めします。ありがとう!" Re: Failed to send the pmic_set command in the DDR Tool. #sysparamをコメントアウトした後、オシロスコープを使用して、i.MX8M Plus が PCA9450C に書き込むデフォルト設定をキャプチャしました。キャプチャされたシーケンスは以下のとおりです。 0x25W、0x00 0x25R、0x31 0x25W、0x0C、0x29 0x25W、0x11、0x1C 0x25W、0x12、0x14 0x25W、0x10、0x59 0x25W、0x1E、0x14 これらの調査結果に基づき、私は.dsファイルに以下のコマンドを追加しました。ファイル: # 2. IOMUX 設定。(SION=1、ODE=1、内部プルアップ) メモリ設定 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) メモリセット 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) メモリセット 0x30330460 32 0x00000176 # I2C1_SCL PAD メモリセット 0x30330464 32 0x00000176 # I2C1_SDA PAD sysparam set pmic_cfg 0x0025 # PMICアドレス sysparam set pmic_set 0x0C29 # BUCK1&3を0.85Vに設定、BUCK2を0.9Vに設定 sysparam set pmic_set 0x111C # BUCK1 DVS0 = 0.95V sysparam セット pmic_set 0x1214 # BUCK1 DVS1 = 0.85V sysparam set pmic_set 0x1059 # BUCK1CTRL = 0x59 (PMIC_STBY_REQ を介した DVS 制御) sysparam set pmic_set 0x1E11 # BUCK6 を 1.025V に設定 しかし、UARTコンソールはこの段階で依然として停止してしまう。以前とは少し異なり、エラーメッセージは表示されなくなり、ここで停止します。 ダウンロードが完了しました ターゲットボードの起動を待っています... オシロスコープでI2C1のSCL線とSDA線をチェックしたところ、動作は以前と同じで、両方の線ともプルダウンされてラッチされており、電源を入れ直した後にのみデフォルトのプルアップ状態に戻ります。 Re: Failed to send the pmic_set command in the DDR Tool. 事前設定されたPMIC初期化を無効にすると、すべて手動で行う必要があります。 i.MX 93 EVKボードでは、デフォルトのPMIC I2CバスはI2C2です。 I2C 1に変更するには、適切なピンマルチプレクサを設定する必要があります。 次に、適切なコマンドを送信する必要があります。(例) コマンドの説明: 件 コマンド バリュー 説明 0 pmic_cfg 0x0025 I2Cバス1 (0はI2C1、1はI2C2、2はI2C3、3はI2C4…) PMICアドレス0x25 1 pmic_set 0x0C29 レジスタ=0x0C BUCKxOUT_DVS0/1 preset_buck1=0.8V、preset_buck2=0.7V、preset_buck3=0.8VPCA9451_BUCK123_DVS 値=0x29 2 pmic_set 0x1118 レジスタ=0x11 BUCK1OUT_DVS0=0.9V PCA9451_BUCK1OUT_DVS0 値=0x18 3 pmic_set 0x1718 レジスタ=0x17 BUCK3OUT_DVS0=0.9V PCA9451_BUCK3OUT_DVS0 値=0x18 4 pmic_set 0x1428 レジスタ=0x14 VDDQを1.1Vに設定 PCA9451_BUCK2OUT_DVS0値=0x28 BUCK6の設定は、レジスタ0x1Dと0x1Eに格納されます。 お役に立てば幸いです。 ベルンハルト。 Re: Failed to send the pmic_set command in the DDR Tool. ああ、そうそう、あの有名なDAISYレジスターですね。よく気づいたね! カスタム設定を選択した場合、すべてを手動で設定する必要があります。おっしゃる通り、ピン構成に関しては、DAISYレジスタはあまり重要視されません。UARTピン多重化設定については、標準のピン多重化設定とパッド設定に加えて、RX信号のdsに表示されます。しかし、I2Cに関してはファームウェアがバックグラウンドでデフォルト設定として処理するため、dsファイルに設定内容は表示されません。 補足として、i.MX 93の場合、I2C1とI2C2にはDAISYチェーンレジスタは存在しませんが、I2C3~8には存在します。 この詳細はツールグループにフィードバックします。この詳細は設定ツールのユーザーマニュアルの一部になるべきです。あるいは、または追加して、I2Cインターフェースの設定がdsファイルに表示されるはずです。 よろしくお願いいたします。 ベルンハルト。
記事全体を表示
猎鹰模式下的 OP-TEE || iMX8MP_EVK 您好, 我想在 i.MX8MP EVK 上启用OP-TEE 和 Falcon 模式。 机器: imx8mpevk 代码库: https://github.com/nxp-imx/imx-manifest 分支: imx-linux-walnascar XML: imx-6.12.34-2.1.0.xml 目前,我使用meta-imx-fastboot (lf-6.12.20-2.0.0-secure)通过 Falcon 模式实现快速启动。但是,当启用猎鹰模式时,OP-TEE 将被禁用。 根据我的要求,我需要同时启用 OP-TEE 和 Falcon 模式。 请问如何在 i.MX8MP EVK 的 Falcon 模式下启用 OP-TEE? i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano 安全 Yocto Project Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@Sanjiv_Mns 目前 meta-imx-fastboot 层不支持 OP-TEE。理论上是可行的,但目前尚未实现。 说明:在默认的 电路板支持包。 中,OP-TEE 的起始地址和大小是在 U-Boot 的正确启动阶段根据rom_pointer计算的(参见: https://github.com/nxp-imx/uboot-imx/blob/lf-6.12.20-2.0.0/arch/arm/mach-imx/dt_optee.c#L13) 。 与 U-Boot 本身相比,SPL 中的rom_pointer具有不同的含义/值。因此,如果不进行进一步修改,就无法从 SPL 执行ft_add_optee_node函数。 谢谢! 埃琳娜 Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@elena_popa 请问如何才能进一步实现SPL → OP-TEE → Linux启动流程?我想了解使其可靠运行所需的正确步骤和元器件。 我还找到了以下链接,其中在STM32MP平台上实现了类似的流程: https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ 请问这种方法是否适用于我的使用场景,或者其中的部分内容是否可以重复使用或修改,以在我的平台上实现相同的启动顺序? Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@elena_popa 我已经完成了这项操作,现在它在我的 i.MX8MP 开发板上启动成功了。 当前启动流程如下: SPL → ATF → OP-TEE → Linux 一切运行正常。感谢你的评论@elena_popa   [ 0.412349] optee:探测管道方法。 [ 0.412373] optee:修订版 4.6 (788dc101b05ae47b) [ 0.412678] optee:动态共享内存已启用 [ 0.413062] optee:已初始化驱动程序 Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@Sanjiv_Mns 我成功地在 Falcon 模式下为 i.MX 8MP 启用并运行了 OP-TEE。 i.MX 8MP 的启动流程为:SPL -> ATF -> OP-TEE -> Linux 步骤如下: 1. 删除 meta-imx-fastboot 层的 conf/layer.conf 中的以下行。 MACHINE_FEATURES:remove = "optee" 2.在imx-boot mkimage 源代码中,修改iMX8M/mkimage_fit_atf_kernel.sh脚本,将 OP-TEE 二进制文件添加到 FIT 镜像中。 6a7,9 > # keep backward compatibility > [ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0xfe000000" > 19a23,41 > [ -z "$BL32" ] && BL32="tee.bin" > PAD=../scripts/pad_image.sh > > if [ ! -f $BL32 ]; then > BL32=/dev/null > else > echo "Building with TEE support, make sure $BL31 is compiled with spd. If you do not want tee, please delete $BL32" >&2 > if [ $TEE_COMPRESS_ENABLE ]; then > echo "Start compress $BL32" >&2 > rm -f $BL32.lz4 > lz4 -9 $BL32 $BL32.lz4 >&2 > BL32=$BL32.lz4 > ./$PAD $BL32 >&2 > fi > echo "$BL32 size: " >&2 > ls -lct $BL32 | awk '{print $5}' >&2 > LOADABLES="$LOADABLES, \"tee-1\"" > fi > 71a94,103 > tee-1 { > description = "TEE firmware"; > data = /incbin/("$BL32"); > type = "firmware"; > arch = "arm64"; > compression = "none"; > load = <$TEE_LOAD_ADDR>; > entry = <$TEE_LOAD_ADDR>; > }; > 87c119 < loadables = "kernel","dtb"; --- > loadables = "tee-1","kernel","dtb"; 3. 在内核设备树中,手动添加 OP-TEE 节点(固件和保留内存)。编辑imx8mp.dtsi设备树并: - 在根节点(“/”)中添加以下 OP-TEE 固件节点。 firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; }; }; - 在保留内存节点下添加 OP-TEE 保留内存区域: optee_core@56000000 { reg = <0 0x56000000 0 0x1e00000>; no-map; }; optee_shm@57e00000 { reg = <0 0x57e00000 0 0x200000>; no-map; }; 4. 构建镜像并将其写入启动设备。 5. 要检查 OP-TEE 是否已启动以及 Linux 是否已探测到驱动程序,请运行: root@imx8mp-lpddr4-evk:~# dmesg | grep optee [ 0.000000] OF: reserved mem: 0x0000000057e00000..0x0000000057ffffff (2048 KiB) nomap non-reusable optee_shm@57e00000 [ 0.000000] OF: reserved mem: 0x0000000056000000..0x0000000057dfffff (30720 KiB) nomap non-reusable optee_core@56000000 [ 2.581777] optee: probing for conduit method. [ 2.590862] optee: revision 4.8 (e7ed997213779e3d) [ 2.596363] optee: dynamic shared memory is enabled [ 2.601567] optee: initialized driver 6.如果你想测试 OP-TEE,你可以运行xtest 。 root@imx8mp-lpddr4-evk:~# xtest Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression+pkcs11+regression_nxp # ###################################################### * regression_1001 Core self tests o regression_1001.1 Core self tests regression_1001.1 OK o regression_1001.2 Core dt_driver self tests regression_1001.2 OK o regression_1001.3 Core transfer list self tests ..... +----------------------------------------------------- 49354 subtests of which 0 failed 161 test cases of which 0 failed 0 test cases were skipped TEE test application done! 如果您在启用过程中遇到任何问题,请告诉我。 谢谢! 埃琳娜
記事全体を表示
S32K3MCU SENDの遅いチャネルがデータを受信できません。 こんにちは、みんな 私はS32K311のSENDインターフェースを使ってデータを受け取っていますが、高速チャネルは通常通りデータを受信しているのに、遅いチャネルはデータを受け取れない状況に遭遇しました。 また、送信エラー通知機能を監視していますが、例外はありません。 MCUはS32K311 RTDバージョン:S32DS 3.6.2RTD6.0.0 SENT センサ:センサタ圧力センサ強化スローメッセージ まず、SENTロジックは「Flexio_Sent_Ip_ProcessSerialMsg」関数で処理され、その後外層関数で「Data->SerialState」と「FastMsgCount」変数を監視して、遅いチャネルが受信データを完了しているかを判断していることがわかっています。 SO、関連するビット情報を取得しました。 bit(x) : SENT Fast チャネル Status ニブルビット S : " STATUS_SENT_SERIAL_SHORT" 。 E : " STATUS_SENT_SERIAL_ENHANCED" 遅いチャネルの解析ロジックが繰り返しジャンプしていて、通常通り解析できないことがわかりました。 ある状況でSENTのプロセッシングロジックにエラーはありますか? よろしくお願いします。 Re: S32K3MCU SENT slow channel Cannot receive data. こんにちは、 @khty さん。 センサタセンサーの送信済み設定を共有してもらえますか?画像から、位置8のビットCは0に設定されているのがわかります。8ビットのメッセージID、12ビットのデータフォーマットが使われていると仮定しています。 あなたの高速チャネルは正しく受信されており、SENDエラー通知も報告されていないので、問題はプロセッシング機能に関連していると理解しています。 チャネル受信の遅さに関する既知の問題は見つかっていません。しかし、社内チームと話し合いを始めたので、この問題についてさらに情報を得ようとします。 最後に、少なくとも18フレーム連続した送信済みフレームの完全なキャプチャを提供していただけますか?これにより、RTD状態機械の挙動が期待される強化シリアル復号シーケンスに合致しているかどうかをさらに確認できます。 よろしくお願いします、 ジュリアン Re: S32K3MCU SENT slow channel Cannot receive data. こんにちは。私の質問に迅速にご回答いただき、ありがとうございます。 センサタが提供するセンサー構成情報は以下の図に示されています。 前回のご要望につき、少なくとも18個の連続した送信フレームの完全なキャプチャを「bitChange.xlsx」に含めました。付録のファイルを参照してください。 表には、キャプチャされた各ステータスハーフワードの2番目と3番目のビットを表示しました。 表の各列は、送信されたメッセージを表しています。それぞれの大きな黒い四角い枠は、1つのslowChannelメッセージを囲んでいます。青色の部分はID領域、緑色の部分はCRC領域、黄色の部分はデータ領域です。下部の情報は手動分析の結果です。 他に何か情報が必要な場合はお知らせください。できるだけ早くお返事いたします。 Re: S32K3MCU SENT slow channel Cannot receive data. SOC側からのエラーログはありますか? Re: S32K3MCU SENT slow channel Cannot receive data. SENTのFASTエラー通知とSLOWエラー通知は、エラーを報告していません。 「bitchange.xlsx」に記録されたデータを読むことができます。分析のために、私が記録した高速チャネルの各ステータスハーフワードの2ビットと3ビットに関する情報が含まれているためです。Bit1とBit0の情報は、スローチャネルでは意味がないため破棄されます。 同時に、遅いチャネル情報は手動で解析し、黒い四角で識別しました。 「bitchange.xlsx」では、「State」行のデータはコード内の「 Flexio_Sent_Ip_axFastData[Instance][ChannelId].SerialState 」に対応します。これは、遅いチャネルが「ショート」か「エンハンスド」かを検出・識別する役割を担っています。「count」は「Flexio_Sent_Ip_axFastData[インスタンス][ChannelId]」を表します。FastMsgCount」は、遅いチャネルの受信長をカウントする役割を担っています。 スローチャネルのデータが受信できない理由は、コードがスローチャネルが「ショート」か「エンハンスド」かを正しく識別できないからだと思います。「bitchange.xlsx」を読むと、識別状態が「STATUS_SENT_SERIAL_IDLE」「STATUS_SENT_SERIAL_SHORT」「STATUS_SENT_SERIAL_ENHANCED」の間を絶えず行き来していることがわかります。 識別状態が遷移すると、「Flexio_Sent_Ip_ProcessSerialMsg()」関数は「STATUS_FLEXIO_SENT_IP_ERROR」を返しますが、この返り値は上位関数「Flexio_Sent_Ip_DmaDataProcessing()」のSerialStateとFastMsgCountをリセットするだけで、SentFastErrorNotif()を呼び出すことはありません。そのため、高速エラー通知からエラー情報を取得できません。 「bitChange.xlsx」内 この時点で列Tから始めることができます。この時点で SerialState = STATUS_SENT_SERIAL_IDLE、 FastMsgCount = 0です。 列Uを受け取ると、 Flexio_Sent_Ip_ProcessSerialMsg()はbit3 == 1と認識するため、これをスローチャネルの開始信号とみなし、 SerialState = STATUS_SENT_SERIAL_SHORT、 FastMsgCount = 1を設定します。 列 V,Flexio_Sent_Ip_ProcessSerialMsg() は bit3 =0 を認識し、 SerialState = STATUS_SENT_SERIAL_SHORT のまま FastMsgCount = 2 を増分します。 列Wを受け取ると、 Flexio_Sent_Ip_ProcessSerialMsg()はbit3 == 1を信じます。この時点で FastMsgCount == 2なので、 STATUS_SENT_SERIAL_ENHANCEDへのジャンプ条件を満たさず、 STATUS_FLEXIO_SENT_IP_ERRORだけ戻すことができます。Flexio_Sent_Ip_DmaDataProcessing () では、 SerialStateとFastMsgCountをリセットします。 ちなみに、私はDMAを使ってSENTデータを受け取っており、DMA受信方法に問題があることを確認しただけです。現時点では、割り込みやポーリング方法にも同じ問題があるかどうか確認できません。 Re: S32K3MCU SENT slow channel Cannot receive data. こんにちは、 @khty さん。 追加情報ありがとうございます。これでより明確になった。 これは、拡張スローメッセージの解析におけるRTDの潜在的な問題を示唆しているように思われますが、私にはその特定のハードウェア構成がないため、問題を再現できていません。 この情報は社内チームに転送しました。新しい情報があれば随時お知らせします。 よろしくお願いします、 ジュリアン
記事全体を表示
PN7160 no response with kernel 6.6.92 Our team has ported the PN7160 to the kernel 6.6.92,  but it currently cannot read any NFC tags. Here is the information for our DUT: Kernel version: 6.6.92 OS: Yocto Scarthgap PN7160 driver patch file: 0003-nfc-nxpnfc-add-NXP-PN7160-i2c-spi-kernel-driver.patch (Cloned from the NFC GitHub and modified to fit kernel 6.6) nfcDemoApp recipes: recipes-nfc.7z (Cloned from the NFC GitHub and modified to fix build errors) Kernel log: nfc-log.txt Could you please provide some advice to help us resolve this issue? 回复: PN7160 no response with kernel 6.6.92 Please set the LOGLEVEL to 0x03 in libnfc-nxp.conf. Then send me the log of when you running the nfcDemoApp. Please also send me the libnfc-nci.conf and libnfc-nxp.conf to me for checking.
記事全体を表示
LSDK 25.12 udev オートロードと /boot/modules レイアウトの競合 NXPチームの皆様、こんにちは。 私たちは以下の環境を使用しています。 * プラットフォーム:i.MX8MP * 配布:Debian 13 / trixie * LSDKリリース:LSDK-25.12_DEBIAN-13_LF-6.12.20 * カーネル:6.12.20 * systemd / udev: 257.x * kmod / libkmod: 34.x udevによって一部のカーネルモジュールが自動的にロードされないという、断続的なコールドブートの問題が発生しました。私たちの場合、影響を受けるデバイスは主にオーディオコーデック/オーディオチェーンとWLANモジュールです。 症状は以下のとおりです。 * 'snd_soc_wm8962'は無装填です * オーディオコーデックおよびオーディオプラットフォームデバイスはバインドされません * 『aplay -l』はサウンドカードがないと報告 * WLAN インターフェースが欠落しています * 起動後に手動で「modprobe」または「udevadm trigger」--action=add」を実行することでデバイスを復元できます デバッグの結果、この問題は今回のflexbuildリリースで使用されているカーネルモジュールのレイアウトに関連していることが判明しました。 `LSDK-25.12_DEBIAN-13_LF-6.12.20` flexbuild タグ内の `configs/debian/debian_post_config.sh`以下のシンボリックリンクを作成します。 「`sh ln -sf /boot/modules /lib/modules 「`」 また、`tools/create_bootpartition` はカーネルモジュールをブートパーティションにコピーします。 「しっ cp -rf $KERNEL_OUTPUT_PATH/$KERNEL_BRANCH/tmp/lib/modules $bootpartdir ``` したがって、実行時には `/lib/modules` は `/boot/modules` に依存し、`/boot` は後で `boot.mount` によってマウントされます。 また、`src/system/boot.mount` も確認しました。内容物: 「`ini」 [ユニット] 説明=ブートパーティション 変更前=systemd-modules-load.service [マウント] What=UUID=PARTUUID 場所=/boot タイプ=ext4 オプション=デフォルト [インストール] WantedBy=local-fs.target 「`」 これは、`systemd-modules-load.service` によって処理される静的モジュール読み込みパスの前に `/boot` がマウントされることを保証するようです。 しかし、私たちの問題は`systemd-modules-load.service`に起因するものではありません。影響を受けたオーディオ/WLANモジュールは、udevによってデバイス「MODALIAS」イベントを通じて動的にロードされます。 失敗した起動では、影響を受けたデバイスイベント情報がudevによって処理され、「boot.mount」が行われることが観察されました。完了しました。その時点では、`/lib/modules` は `/boot/modules` を指していますが、`/boot` はまだマウントされていません。その結果、libkmodはモジュールのエイリアス/インデックスファイルや対応する「.ko」ファイルにアクセスできず、udevモジュールの自動読み込みパスが失敗します。udevイベントはすでに処理済みなので、手動でudevを再トリガーするか「modprobe」を実行しない限り、ドライバは後から読み込まれません。 私たちが理解している失敗経路は以下のとおりです。 「テキスト カーネルデバイス追加イベント →udevはMODALIASイベントを受け取る →udev/libkmodは/lib/modulesにアクセスしようとします → /lib/modules は /boot/modules を指しています → /bootはまだマウントされていません →モジュールのエイリアス/インデックスファイルまたは.koファイルは利用できません →モジュールの自動読み込みが失敗します ``` 以下の点について確認させていただきたい。 1. LSDK 25.12 Debian 13 リリースでは、`/lib/modules -> /boot/modules` というレイアウトが想定されていますか? 2. udev の初期の `MODALIAS` 処理と後の `boot.mount` 処理の間に競合が発生していますか?このレイアウトに関する既知の問題点または既知の制限事項はありますか? 3. 現在の上流のflexbuildメインブランチでは、このアーキテクチャが変更されているようです。カーネルモジュールは`create_bootpartition`によってブートパーティションにコピーされなくなり、`debian_post_config.sh`で`/lib/modules -> /boot/modules`シンボリックリンクが作成されなくなりました。 このアーキテクチャの変更は、このような早期起動モジュールの自動読み込み競争を避けるためでしょうか? 4. LSDK 25.12 Debian 13の場合、NXPが推奨するこの問題の修正方法または回避策は何ですか? 私たちの理解が正しいかどうか、また、このリリースに対する公式パッチや推奨アップデートパスがあるかどうかをお知らせください。 ありがとうございます。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: LSDK 25.12 udev autoload race with /boot/modules layout こんにちは、 Q1: この設計の当初の意図は、カーネルイメージとモジュールをブートパーティションにまとめて配置し、カーネルをアップグレードする際にルートファイルシステムを変更せずにブートパーティションだけを交換すれば済むようにすることでした。このレイアウトは意図的なものであり、バグではありません。 Q2: あなたの考え方は正しいです。これはこのレイアウトの本質的な制約です。 Q3: イメージを構築する際に、一度だけ「/boot/modules」の内容をrootファイルシステムの「/lib/modules」に移動し、記号リンクを削除することができます: rm -f /lib/modules mkdir -p /lib/modules cp -a /boot/modules/* /lib/modules/ 同時に、 1. ビルドスクリプトの「tools/create_bootpartition」を修正し、「cp -rf .../lib/modules $bootpartdir」の行を削除します。  2. `debian_post_config.sh` を変更し、`ln -sf /boot/modules /lib/modules` の行を削除します。 3. 「bld linux / modules_install」ターゲットを設定し、ルートファイルシステムにモジュールをインストールする( 「main」ブランチの「linux-modules」ターゲットの実装を参照)。 よろしくお願いします、 志明
記事全体を表示
PN7160 在内核版本 6.6.92 下无响应 我们的团队已将PN7160移植到内核6.6.92 , 但它目前无法读取任何NFC标签。 以下是我们的DUT信息: 内核版本: 6.6.92 操作系统: Yocto Scarthgap PN7160 驱动程序补丁文件: 0003-nfc-nxpnfc-add-NXP-PN7160-i2c-spi-kernel-driver.patch(克隆自 NFC GitHub 项目并修改以适配内核 6.6) nfcDemoApp 配方: recipes-nfc.7z(从 NFC GitHub 克隆并修改以修复构建错误) 内核日志: nfc-log.txt 您能否提供一些建议,帮助我们解决这个问题? 回复: PN7160 no response with kernel 6.6.92 请在 libnfc-nxp.conf 中将 LOGLEVEL 设置为 0x03。然后把运行 nfcDemoApp 时的日志发给我。请同时将 libnfc-nci.conf 和 libnfc-nxp.conf 文件发送给我,以便我检查。
記事全体を表示
MPC5777 BSDL BGA_512 您好,我正在寻找该组件的BSDL文件: MPC5777 BGA-512 你能把文件发给我吗? 谢谢! Re: MPC5777 BSDL BGA_512 你好, 我将通过私信发送给你。以后如有任何问题,请在NXP.com上提交工单。 顺祝商祺! Peter
記事全体を表示
MCUXpresso for VSCode SWO 控制台输出存在问题 你好! 设置 适用于 VSCode 的 MCUXpresso 电路板 KW47-LOC 项目 kw47loc_hello_world_swo_cm33_core0 链接服务器 25.6.131或 26.3.123 描述 我想测试SWO的功能,以便将其与我的定制板一起使用。在 MCUXpresso IDE 中运行良好,但在 MCUXpresso for VSCode 中,我遇到了 SWO 控制台在大约 30 秒后停止显示串口输出的问题。这一点一直如此。 重现步骤 - 使用开发板和项目启动调试会话 - 先在主菜单上暂停,然后按继续键 - 暂停执行,然后通过分析窗口配置 SWO 时钟 - 通过探测窗口运行 SWO ITM - 通过输出选择 MCUXpresso SWO 控制台,然后恢复执行 串口输出开始显示,大约30秒后卡住。 感谢您抽出时间!
記事全体を表示
このエラーメッセージの原因は何ですか?また、どのように解決すればよいですか? Re: 请问这个报错是什么原因,如何解决 ご質問はフォーラムに直接投稿してください。 新規ユーザーの場合、S32DSの旧バージョンやパッチパッケージの多くはダウンロードできなくなっている可能性があります。そのため、解決策が変更されました。 Re: 请问这个报错是什么原因,如何解决 インストール後も動作しません。 Re: 请问这个报错是什么原因,如何解决 こんにちは このタイプの「open configuration.mex」エラーメッセージ「現在のツールバージョンはプロセッサバージョンをサポートしていません」は、通常、S32DS Update n または S32K3 Development Package に RTD リリースノートに記載されているバージョンがインストールされていないことが原因です。 S32DS v3.4にインストールしてください。 3.4.3_D2112   S32プラットフォーム用S32デザインスタジオ v.3.4S32K3デバイスをサポートするアップデート3 よろしくお願いします、 ロビン ------------------------------------------------------------------------------- 注記: この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう! - 最後の投稿から7週間はスレッドをフォローしますが、それ以降の返信は無視されます。 後日、関連する質問がある場合は、新しいスレッドを作成し、閉じられたスレッドを参照してください。 ------------------------------------------------------------------------------- 回复: 请问这个报错是什么原因,如何解决 この問題は解決しましたか?私も現在同様の問題に直面しています。PlatformSDKのS32K5バージョンはS32K566プロセッサをサポートしていません。 回复: 请问这个报错是什么原因,如何解决 こんにちは S32K5はまだ正式にリリースされておらず、NXPのウェブサイトにはRTDや開発パックなどのソフトウェアパッケージをダウンロードするための公開リンクはありません。このような問題は通常、これらのソフトウェアパッケージが正しくインストールされていないことが原因です。 ご不明な点がございましたら、貴社のFAE(フィールドアプリケーションエンジニア)までお問い合わせください。オンライン技術サポートは、このタイプのNPI(新製品導入)製品の正式リリース後にのみご利用いただけます。 よろしくお願いします、 ロビン
記事全体を表示
TJA1120A RGMII 車載イーサネット 私たちはTI AM62A7をベースにしたカスタムボード上でTJA1120A RGMII車載イーサネットの開発に取り組んでいます。 Yocto Linuxでこのインターフェースを有効にする方法について教えてください。 私たちは、 https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/nxp%2Ctja11xx.yamlに記載されている DTS ノード形式に従って試してみました。 しかし、ドライバはカーネルdmesgを調べなかった このPHYのベンダーIDはD001B:B031であると理解しています。 また、カーネル設定でCONFIG_NXP_C45_TJA11XX_PHYを有効にしました。 Re: TJA1120A RGMII Auto-Ethernet こんにちは、 @vikyhre さん。 絞り込むために、以下の情報を共有していただけますか? 1) U-Bootは、MDIOバス上のPHYを想定されたアドレスで検出しますか?(例えば「mdio list」/「mii info」の出力) 2) CPSWポートノードとMDIO/PHYノード(phy-handle、phy-mode、PHY reg/address)に関する関連するDTSスニペットと、MDIO/PHY初期化に関連するブートログ行を共有してください。 dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" これら2つの項目があれば、PHYがMDIO(ハードウェア/ピンマルチプレクサ/リセット/アドレス)上で認識されていないのか、それともDTバインディング/参照の問題なのかを迅速に判断できます。 よろしくお願いいたします。 パベル Re: TJA1120A RGMII Auto-Ethernet 私たちはAM62A7ベースのiWave SoMを使用しており、現時点ではeMMCに格納されているu-boot/ブートローダーファームウェアには手を加えていません。 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done SPL initial stack usage: 17040 bytes am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed Starting ATF on ARM64 core... NOTICE: BL31: v2.9(release):d7a7135d3-dirty NOTICE: BL31: Built : 09:34:15, Aug 24 2023 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed U-Boot 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SoC: AM62AX SR1.0 HS-FS Model: iW-RainboW-G55M-TI-AM62AX OSM DRAM: 2 GiB Core: 60 devices, 29 uclasses, devicetree: separate MMC: mmc@fa10000: 0, mmc@fa00000: 1 Loading Environment from nowhere... OK In: serial@2800000 Out: serial@2800000 Err: serial@2800000 Board Info: BSP Version : iW-PRHAZ-SC-01-R2.0-REL1.0-Linux6.1.46 SOM Version : iW-PRHAZ-AP-01-R2.0 Net: eth0: ethernet@8000000port@1 Hit any key to stop autoboot: 0 iWave-G55M > mdio list mdio@f00: ethernet@8000000port@1: 4 - Generic PHY <--> ethernet@8000000port@1 iWave-G55M > mii info U-Bootのファームウェアは変更せず、LinuxをSDカードから起動しています k3-am62a7-iwg55m.dtsi を添付しました。ここで、両方のイーサネットeth0、eth1が無効化されています &cpsw3g { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_rgmii1_pins_default>, <&main_rgmii2_pins_default>; cpts@3d000 { /* MAP HW3_TS_PUSH to GENF1 */ ti,pps = <2 1>; }; }; &cpsw_port1 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy0>; }; &cpsw_port2 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy1>; }; &cpsw3g_mdio { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_mdio1_pins_default>; cpsw3g_phy0: ethernet-phy@0 { reg = <4>; adi,rx-internal-delay-ps = <2000>; }; cpsw3g_phy1: ethernet-phy@1 { reg = <5>; qca,disable-smarteee; vddio-supply = <&vddio0>; vddio0: vddio-regulator { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; }; }; k3-am62a7-iwg55s-prgjj-41.dts では、適切な DT エントリを使用して eth0 と eth1 の両方を有効にしました。 &cpsw_port1と&cpsw3g_phy0はオートイーサネットに対応しています &cpsw_port1 { status = "okay"; phy-mode = "rgmii"; }; &cpsw_port2 { status = "okay"; phy-mode = "rgmii"; }; &cpsw3g_phy0 { //compatible = "ethernet-phy-id001b.b031", "ethernet-phy-ieee802.3-c45"; compatible = "ethernet-phy-id001b.b030"; nxp,rmii-refclk-in; reg = <4>; }; &cpsw3g_phy1 { compatible = "ethernet-phy-id0022.1620"; reg = <0>; txc-skew-ps = <900>; rxc-skew-ps = <900>; rxd0-skew-ps = <420>; rxd1-skew-ps = <420>; rxd2-skew-ps = <420>; rxd3-skew-ps = <420>; txd0-skew-ps = <420>; txd1-skew-ps = <420>; txd2-skew-ps = <420>; txd3-skew-ps = <420>; rxdv-skew-ps = <420>; txen-skew-ps = <420>; }; ここで、私のPHY TJA1120AにはPHY識別レジスタ1:1BとPHY識別レジスタ2:B030があります。 したがって、適切なドライバーは イーサネット と互換性があるはずです = "ethernet-phy-id001b.b030" dmesg | egrep -i "mdio|cpsw|phy|tja|nxp"に対する応答 root@am62ax-iwg55m-osm:/sys/class/hwmon/hwmon0# dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys). [ 1.349271] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000 [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown [ 1.375925] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.388839] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.395108] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.402236] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512 [ 1.412875] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.422952] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 6.876699] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 6.893353] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode [ 6.937861] am65-cpsw-nuss 8000000.ethernet eth0: validation of rgmii with support 00000000,00000000,00006280 and advertisement 00000000,00000000,00002280 failed: -EINVAL dmesgも添付しました。 Re: TJA1120A RGMII Auto-Ethernet こんにちは、 @vikyhre さん。 コミュニティスレッドは前回の投稿から7日間、積極的に監視されていることにご注意ください。この期間以降、私たちは最新情報の購読メール通知のみを受け取り、そのような通知を見逃すこともあります。   今後追加の支援が必要な場合は、新しいコミュニティクエリを作成するか、サポートチケット を作成 https://support.nxp.com/s/?language=en_US することをお勧めします。 さて、私の分析結果は以下の通りです。 以下のLinuxコマンドは推奨される診断チェックとして提供されていることに注意してください。正確なビルドやランタイム環境にアクセスできないため、セットアップ上で直接検証できず、システム構成によっては軽微な調整が必要になるかもしれません。 以下のスレッドが参考になるかもしれません: TJA1120とi.MX8評価用ハードウェアではパケット送信は行われません。 ログを見る限り、MDIOアクセス自体は動作しているようです。なぜならLinuxはMDIOバス上の2つのPHYデバイスを検出しているからです。 [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown つまり、TJA1120AはMDIOアドレス4で見えるようですが、まだNXP C45のTJA11xx PHYドライバには割り当てられていません。これが、CPSWポートが後にRGMII検証中に失敗する理由である可能性が高い。 まず最初のステップとして、TJA1120A PHYノードを更新して、条項45を明示的に指定してみてください。 &cpsw_port1 { status = "OK"; phy-mode = "RGMII";     /* または rgmii-id / rgmii-rxid / rgmii-txid(ボードの遅延設計によります)*/ phy-handle = <&cpsw3g_phy0>; };   &cpsw3g_phy0 { コンパソコント = 「イーサネット-PHY-ID001B.B030」、「イーサネット-PHY-IEEE802.3-C45」; reg = <4>; status = "OK"; }; また、TJA1120Aノードからこのプロパティを削除してください。  nxp,rmii-refclk-in; このプロパティはRMIIリファレンスクロックの設定に関連するものであり、RGMII TJA1120Aの設定には使用しないでください。   再構築して更新されたDTBで起動した後は、ドライバが接続されているか確認してください。例えば: dmesg | egrep -i "mdio|cpsw|phy|tja|nxp"   予想される結果として、アドレス4のPHYはもはや driver unknown として表示されず、NXP C45 TJA11xx/TJA1120ドライバに接続されます。 もしまだ driver unknown のままであれば、実行中のカーネルに本当にドライバーのサポートが含まれているかも確認してください。 zcat /proc/config.gz | egrep "NXP.*TJA|C45|PHYLIB" find /lib/modules/$(uname -r) -name "*tja*"   よろしくお願いいたします。 パベル Re: TJA1120A RGMII Auto-Ethernet こんにちは、 @vikyhre さん。 最新情報のご提供ありがとうございます。新しいdmesgの出力は以前よりずっと見やすくなりました。TJA1120AはMDIOアドレス4で検出され、NXP C45のTJA1120ドライバに正しくバインドされています。 [    1.476820] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver NXP C45 TJA1120 [    6.654104] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:04] driver [NXP C45 TJA1120]  つまり、ドライバーサポートが欠けていた以前の問題は解決したようです。 現在のリンクパートナーについてですが、Microchip EVB-LAN8770M_MCは100BASE-T1メディアコンバーターで、TJA1120Aは1000BASE-T1 PHYです。これらは異なる自動車用イーサネットPHY規格や速度なので、LAN8770Mベースの100BASE-T1コンバータがTJA1120Aの1000BASE-T1 PHYとリンクを確立することは期待されません。一方が100BASE-T1をサポートし、もう一方が1000BASE-T1 PHYである場合、オートネゴシエーションは共通モードを交わせることができません。 TJA1120自動車用1000BASE-T1 PHYであり、自動車用イーサネット**アプリケーション**ではリンク構成が通常**デターミニスティック**かつ明示的に定義されることが期待されます。したがって、自動交渉は必須ではなく、サポートされていません。 TJA1120Aリンクのテストには、1000BASE-T1対応のリンクパートナー(例えば、別のTJA1120/TJA1121ベースの基板や1000BASE-T1メディアコンバーターなど)を使用してください。 このスレッドは解決済みとマークされていますので、追加の支援が必要な場合はフォーラムに 新しい質問を開 いてください。 よろしくお願いいたします。 パベル Re: TJA1120A RGMII Auto-Ethernet もちろん、パベルさん。返信が遅れて申し訳ありません。 あなたの言う通りでした。古いカーネルでCONFIG_NXP_C45_TJA11XX_PHY=yを有効にしていたにもかかわらず、カーネルはTJA1120をサポートしていなかったのです。ドライバのソースコードを確認するべきだったようですが、古いカーネル(https://github.com/torvalds/linux/blob/v6.12/drivers/net/phy/nxp-c45-tja11xx.c)にはTJA1120がないことが分かりました。 root@am62axx-evm:~# dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys). [ 1.383879] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.397521] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.438966] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000 [ 1.448696] NXP C45 TJA1120 8000f00.mdio:04: the phy does not support MACsec [ 1.466641] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.476820] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver NXP C45 TJA1120 [ 1.486189] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.494016] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512, Policers 32 [ 1.502639] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.521311] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 6.654104] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:04] driver [NXP C45 TJA1120] (irq=POLL) [ 6.665485] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii link mode [ 6.756195] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 6.767993] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode root@am62axx-evm:~# zcat /proc/config.gz | egrep "NXP.*TJA|C45|PHYLIB" CONFIG_PHYLIB=y CONFIG_PHYLIB_LEDS=y CONFIG_BCM_NET_PHYLIB=m CONFIG_NXP_C45_TJA11XX_PHY=y CONFIG_NXP_TJA11XX_PHY=y CONFIG_QCOM_NET_PHYLIB=y # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. # CONFIG_TI_TLC4541 is not set PHYはカーネルによって検出され、プローブされる。 現在はMicrochip EVB-LAN8770M_MC Media Converterを使っており、100BASET1 SPEにサポートしています。TJA1120A(1000BASE-T1)と互換性があり、オートネゴシエーションに対応していますか?
記事全体を表示
i.MX95でセキュアブートを実装するにはどうすればよいですか? imx8mpのセキュアブートプロセスを完了しました。 セキュアブートは、8mp上でHABv4を使用して実現されます。 imx95もセキュアブートの実装にHABv4を使用していますか? flash.binをコンパイルした際、CSFブロックやsld habブロックなどの情報は表示されませんでした。 IMX95でセキュアブートを実行するにはどうすればよいですか? Re: How do I implement Secure Boot on the i.MX95? こんにちは@yyn お元気でお過ごしのことと思います。 U-ブート のドキュメントにある introduction_ahab をご覧ください。 i.MX9ファミリーのSecure Bootプロセスについて説明しています。 よろしくお願いいたします。 サラス。
記事全体を表示
About the Finite-State Machine (FSM) of i.MX8Mplus We use Toradex's Veridin i.MX8Mplus at our company. At that time, the SOM_PW_ON signal is input to control the SoM's power supply. (Directly connected to the ON/OFF signal of the i.mx8MPlusSoC). *Please refer to the waveform on the attached oscilloscope.   Due to the circuit configuration on the SoM side, the voltage should be High (1.8V), but for about 800 msec after startup, it remains at an intermediate potential of approximately 0.3-0.4V. I'd like to know how this voltage (0.3 to 0.4V) is handled as an ON/OFF signal on the SoC side. This information was not included in the datasheet or reference manual. I think that in cases of very short ON/OFF operations (<5s), the system may proceed to shutdown. Would the operation detection criteria be the transition from High to Low edge state and the duration of the Low state? I would also like to know the exact minimum/maximum times for those times. i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MplusのFinite-State Machine (FSM)について For i.MX8M Plus, ONOFF is handled as a level-held button input with configurable 0/50/100/500 ms qualification and 5/10/15 s forced-off timing, and your observed 0.3–0.4 V on a 1.8 V ONOFF net is most consistently interpreted as logic Low by the available input-threshold documentation. Re: i.MX8MplusのFinite-State Machine (FSM)について Thank you for your reply. The observed V values of 0.3–0.41.8V on the ONOFF network are most consistently interpreted as logically low by the available input threshold documentation. By the way, could you also tell me about the voltage threshold that is interpreted as logically low? Furthermore, if interpreted as logically low, the ON/OFF state will remain logically low for approximately 800 msec after startup before changing to logically high. In that case, would it be considered that a button input occurred? My concern is whether a button press might cause the system to automatically shut down immediately after startup. Re: i.MX8MplusのFinite-State Machine (FSM)について By the way, could you also tell me about the voltage threshold that is interpreted as logically low? I apologize. I would like to know the voltage threshold at which the logic value is interpreted. Re: i.MX8MplusのFinite-State Machine (FSM)について Thank you for your reply. The observed V values of 0.3–0.41.8V on the ONOFF network are most consistently interpreted as logically low by the available input threshold documentation. By the way, could you also tell me about the voltage threshold that is interpreted as the logical high? Furthermore, if interpreted as logically low, the ON/OFF state will remain logically low for approximately 800 msec after startup before changing to logically high. In that case, would it be considered that a button input occurred? My concern is whether a button press might cause the system to automatically shut down immediately after startup. To the NXP TechSupport representative What do you think about this matter? I have one more question: ON/OFF is processed as a level hold button input, with conditions of 0/50/100/500 ms. Regarding that point, I believe the default is 0. In this case, if the level momentarily exceeds the logical high or logical low threshold due to noise or other factors, will the level be held? I am concerned that with this default setting, if noise is received, there is a possibility of malfunction if something that causes a logic judgment opposite to the currently held level logic is introduced, even for a moment. Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang I have added a few more questions. We apologize for the inconvenience, but please provide your response.
記事全体を表示
FRDM-i.MX95の外部JTAGデバッガ接続で、期待されるJTAG信号が出力されない。 こんにちは、 FRDM-i.MX95ボードに外部JTAGデバッガを接続しようとしています。 基板の回路図によると、JTAG/DAP信号はPCB上のテストポイントに配線されているようで、関連する一部の部品はDNP(未実装)とマークされている。 これに基づき、基板を以下のように改造しました。 テストポイントからのJTAG信号をコネクテッド JTAG/DAP信号経路に関連するDNP抵抗器を取り付けました 外部デバッガ用のコネクタを追加しました VTref、GND、TCK、TMS、TDI、TDO、RESETを外部デバッガにコネクテッド しかし、デバッガやボード側からの期待されるJTAG信号の出力は観測できません。 例えば、デバッガ接続シーケンス中にTCK/TMS/TDIが期待どおりに表示されない。 以下の点を確認していただけますか? 上記の改造方法は、外部JTAGデバッガをFRDM-i.MX95ボードに接続するのに正しいのでしょうか? 外部JTAG/DAPインターフェースを有効にするために追加の抵抗、ジャンパー、はんだブリッジ、基板の改造などが必要ですか? 外部デバッガがJTAG信号の駆動を開始する前に、VTref電圧レベルや電源シーケンスに関する要件はありますか? FRDM-i.MX95上のi.MX95は、JTAG/DAPインターフェースにアクセスできるようになる前に、ブートモード、ヒューズ設定、セキュリティ設定、ソフトウェア初期化が必要ですか? 外部JTAGデバッガはこのボード上でCortex-A55、Cortex-M33、Cortex-M7コアに直接アクセスできますか?それともブートローダーやファームウェアによる追加の初期化が必要ですか? FRDM-i.MX95で外部デバッガを使用する際に推奨されるコネクタピンの割り当てや、参照変更ガイドはありますか? FRDM-i.MX95ボードで外部JTAGデバッグを有効にするためのガイダンスや回路図の参考、必要な改造の詳細を教えていただけるとありがたいです。 よろしくお願いいたします。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 1. あなたの修正方法は正しいですか? 原則的には、そうです。 FRDM回路図に以下が含まれている場合: TCK TMS TDI TDO nTRST または RESET VTref GND テストポイントやDNP(デジタルノイズプロテクタリング)オプションを通して信号を取り出し、それらの信号をコネクタにルーティングするのが、一般的に正しいアプローチです。 しかし、回路図自体が検索結果に返ってこなかったため、 必要なDNP抵抗 がすべて入力されているかは確認できません。ユーザーマニュアルにはJTAG回路は含まれていません。 2. なぜTCK/TMS/TDIの活性が見られないのでしょうか? 通常、JTAGプローブが接続されると: TCK/TMS/TDIはデバッガによって駆動されます。 ターゲットボードはそれらを生成しません。 TCK/TMSで全く切り替えが見られない場合: 最も一般的な原因その1:VTrefが検出されない 多くのプローブ(Lauterbach、J-Link、PE Micro、ULINKなど)は、VTrefが存在し、かつ有効な範囲内にあるまでJTAGピンを駆動しません。 確認: コネクタにおけるVTref電圧。 共通接地接続。 プローブソフトウェアは目標電圧を報告します。 FRDM-i.MX95の場合、DAP I/O電源は3.3Vドメイン(NVCC_CCM_DAP)に関連しているようです。ボードのドキュメントには、このドメインがVDD_3V3から電源を供給されていることが示されています。 最も一般的な原因その2:ボードに電源が供給されていない ほとんどのデバッガは、センシングのためだけにVTrefを使用します。 それらは標的に電力を供給しない。 確認する: 基板はJ25から給電されます。 PMICが起動しました。 VDD_3V3が存在します。 基板のLEDが点灯しています。 この基板には外部PD電源が必要です。 最も一般的な原因その3:信号ルーティングの再作業の不足 JTAGパスに以下が含まれる場合: 0Ω DNP抵抗器 絶縁抵抗 代替の詰め物オプション 抵抗が1つでも欠けていると、TCK/TMSが切断されることがあります。 回路図は検索結果に含まれていないため、正確な抵抗数リストを検証できません。 最も一般的な原因その4:ピンマッピングの間違い オームメーターで確認してください。 プローブピン → コネクタピン → 抵抗器 → テストポイント → i.MX95 ボール。 テストポイントラベルが標準的なARM 20ピンの順序と一致しているとは限りません。 3. 特別な起動モードが必要ですか? セキュリティ保護されていないデバイスの場合: JTAGクロックの動作を監視するだけであれば、ブートモードは必要ないはずです。 TCK/TMSは、デバッガがVTrefを検出してスキャンシーケンスを開始するとすぐに切り替わるはずです。 ブートスイッチは以下に影響します: eMMCブート SDブート シリアルダウンローダー そして、これらはデバッガがTCKを生成するかどうかとは無関係です。 4. セキュリティ設定やヒューズは関係していますか? 可能性はある。 i.MX95は認証済みデバッグおよびデバッグアクセス制御を実装しています。[i.MX95RM_Rev4 | PDF] 、 [i.MX95RM_Rev2 | PDF] 、 [i.MX95 Sec...2026-final | PowerPoint] しかし: セキュリティ設定は通常、デバッグアクセスを妨げます。 通常、それらはデバッガがTCK/TMS自体を生成することを妨げるものではありません。 TCK活性が全く見られないとの報告ですので、まずは以下を調査します。 VTref プローブ構成 ケーブルのピン配列 人口に関する選択肢が不足しています セキュリティを疑う前に。 5. A55、M33、M7はデバッグ可能か? i.MX95デバッグアーキテクチャは以下をサポートしています: コルテックス-A55 Cortex-M33 Cortex-M7 CoreSight/DAPインフラストラクチャを通じて。[i.MX95RM_Rev2 | PDF] 、 [i.MX95RM_Rev5 | PDF] シリコンの能力の観点から見ると、はい、そうです。 すべてのドメインがすぐに表示されるかどうかは、以下の要因によって決まります。 システムの状態、 セキュリティ構成、 デバッガのサポート。 しかし、デバッガがDAP自体を検出するために、通常は追加のブートローダー初期化は必要ありません。 推奨寸法 基板の再加工を行う前に、以下の点を確認します。 パワー VTref = ?V VDD_3V3 が存在する ボードは正常に起動しています 連続 TCKコネクタ ↔ SoCパス TMSコネクタ↔SoCパス TDIコネクタ↔SoCパス TDOコネクタ↔SoCパス リセットコネクタ ↔ SoCパス プローブ側 デバッガソフトはターゲット電圧を報告しますか? 「ターゲット検出」と表示されますか? JTAGチェーンスキャンが試行されたと報告されますか? オシロスコープ プローブを直接以下へ: デバッガーコネクタピン SoC側テストポイント 接続試行中。 デバッガーコネクタにTCKが存在するのに、SoCテストポイントにTCKが存在しない場合、問題はほぼ間違いなく基板の再加工にある。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 再開まで今しばらくお待ちください。 外部JTAGデバッガー接続を見直したところ、 問題は、FRDM-i.MX95 ボードと 外部JTAGデバッガ。 JTAG信号線を短くして再配置した後、デバッガは ターゲットを正しく検出することができ、JTAG信号は次のように観測された。 期待される。 そのため、この問題はJTAG配線の改良によって解決されました 長さと接続品質。 ご協力いただき、改めて感謝申し上げます。
記事全体を表示