S32Gコアリセット こんにちは、NXPさん。 S32G399特定のM7コアの独立リセットを他のコアの通常の動作に影響を与えずにサポートしているのか知りたいです。

FRDM-S32K344 manual error Hello, There is a mistake on page 11 of FRDM-A-S32K344 development board manual (UM12406) . I'm posting this comment for the community and for anyone who runs into the same problem I did. "Specifically, resistor R43 is populated by default to keep the FS26 in debug mode. To enable normal mode, R43 must be removed and R42 must be populated instead." Should be: "Specifically, resistor R43 is populated by default to keep the FS26 in debug mode. To enable normal mode, R43 must be removed. and R42 must be populated instead." or: "Specifically, resistor R43 is populated by default to keep the FS26 in debug mode. To enable normal mode, R43 must be removed. R42 must be populated to enter in OTP emulation mode."

S32K388 JumpApp 仅在核心 0 处于活动状态时运行。 我创建了一个引导加载程序，并将其放置在地址 0x400000 到 0x420000 处。每次我通过串口更新程序时，只有核心 0 继续运行。如何才能让其他核心也运行起来？ S32_SCB->VTOR = 0x00422000; __asm volatile(         "msr msp， % 0" ： : "r" (appStack) ： “记忆” ）; ((pFunction)appEntry)(); Re: S32K388 JumpApp Only runs with core 0 active. 嗨@zhangyu5454 ， 您可以在启动代码中启用核心。请参阅默认 S32DS 项目的启动代码（startup_cm7.s）。 例如，如果 CM7_2_ENABLE == 1，则启动代码将在系统启动期间启用 CM7_2。 也可以稍后通过 CM7_0 应用程序启用内核，方法是直接配置相关寄存器，或者使用 MCU MCAL 驱动程序或 Power_Ip 驱动程序。请参考以下示例： https://community.nxp.com/t5/S32K-Knowledge-Base/S32K358-Multicore-Start-CM7-2-from-CM7-0/ta-p/1923889 BR，丹尼尔

S32G 核心 RESET 您好，NXP： 我想知道S32G399是否支持对特定M7内核进行独立复位，而不影响其他内核的正常运行？

S32G Core RESET Hi NXP: I would like to know if S32G399 supports the independent reset of a specific M7 core without affecting the normal operation of other cores?

Yocto Linuxをビルドする際のbase-filesエラー Build the Yoctoエラー。私が作ったときは、YoctoのNXPガイドに従っています。エラーを修正するにはどうすればよいですか？ 警告:失敗したセットシーンタスクのログファイルは /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/armv8a-poky-Linux/ptest-runner/2.4.5+git/temp/log.do_package_setscene.1680451 です。 警告:セットシーンタスク(/home/vmc/Desktop/imx-Yocto-bsp/sources/poky/meta/recipes-サポート/ptest-runner/ptest-runner_2.4.5.bb:do_package_setscene)が終了コード「1」で失敗しました。代わりに実際のタスクが実行されます エラー:base-files-3.0.14-r0 do_package:exec_func_python()でPython関数を実行する際にエラーが発生します。 この例外/失敗を引き起こしたPython呼び出しのスタックトレースは以下の通りです: ファイル: 'exec_func_python() autogenerated', lineno: 2, function: 0001: 0002:perform_packagecopy(d) 0003: ファイル: '/ホーム/vmc/Desktop/imx-Yocto-bsp/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[指揮] = "${PKGD}" *** 0363: 0364:Python populate_パッケージs () { 0365: oe.package.populate_パッケージs(d) 0366:} 0367:populate_packages[dirs] = " ${D} " ファイル: '/usr/lib/python3.10/subprocess.py'、行番号: 421、関数: check_output 0417: それ以外の場合: 0418: 空 = b'' 0419: kwargs['input'] = 空 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): ファイル: '/usr/lib/python3.10/subprocess.py'、行番号: 526、関数: 実行 0522: # process.wait() は呼び出しませんとして。 __exit__それは私たちのためにやってくれる。 0523: 上げる 0524: retcode = process.poll() 0525: チェックして戻りコードを取得する場合: *** 0526: raise CalledProcessError(retcode, process.args, 0527: 出力=標準出力、標準エラー=標準エラー) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: 例外: subprocess.CalledProcessError: コマンド 'tar --exclude=./sysroot-only'-cf - -C /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/image -p -S .|tar -xf - -C /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/package' は終了ステータス2を返しました。 サブプロセスの出力: 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パス bin 'bin' の絶対パスを割り当てられませんでした。 tar: ./usr/bin:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 tar: ./usr/lib:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、Path Games 『ゲーム』に絶対的な道を割り当てることができませんでした。 tar: ./usr/games:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス TAR: ./USR/Share/DICT:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス タール:./USR/シェア/男:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス tar: ./usr/share/doc:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス tar: ./usr/share/doc/base-files-3.0.14:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス TAR: ./USR/Share/MISC:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス TAR: ./USR/share/common-licenses:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス tar: ./usr/share/info:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスSBIN 「sbin」に絶対的な経路を割り当てることができませんでした。 tar: ./usr/sbin:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスSRC 「SRC」に絶対的な経路を割り当てることができませんでした。 tar: ./usr/src:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底経路、経路TMP 「TMP」の絶対経路を割り当てられませんでした。 tar: ./var/tmp:「volatile/tmp」へのシンプレリックリンクを作成できません:アドレスが悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスローカル 「ローカル」に絶対的な経路を割り当てることができませんでした。 tar: ./var/local:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 tar: ./var/lib:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 tar: ./var/lib:Cannot mkdir: 悪いアドレス tar: ./var/lib/misc:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスボラタイル 「不安定」に絶対的な経路を割り当てることができなかった。 tar: ./var/volatile:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスボラタイル 「不安定」に絶対的な経路を割り当てることができなかった。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスボラタイル 「不安定」に絶対的な経路を割り当てることができなかった。 tar: ./var/volatile:Cannot mkdir: 悪いアドレス TAR:./VAR/Volatile/TMP:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスボラタイル 「不安定」に絶対的な経路を割り当てることができなかった。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスボラタイル 「不安定」に絶対的な経路を割り当てることができなかった。 tar: ./var/volatile:Cannot mkdir: 悪いアドレス タール:./VAR/揮発性/ログ:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路記録 「log」に絶対パスを割り当てることができませんでした。 tar: ./var/log:'volatile/log'へのシンモリンクを作成できません:アドレスが悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスロック 「ロック」の絶対経路を割り当てることができませんでした。 tar: ./var/lock:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底経路、経路スプール 「スプール」の絶対経路を割り当てられませんでした。 tar: ./var/spool:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基地経路、経路バックアップ 「バックアップ」に絶対的な経路を割り当てることができませんでした。 tar: ./var/backups:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基地経路、経路走行 「走る」ための絶対的な経路を割り当てられなかった。 tar: ./var/run:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスNSswitch.conf 'nsswitch.conf' の絶対パスを割り当てられませんでした。 tar: ./etc/nsswitch.conf:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスホスト 「ホスト」に絶対的な経路を割り当てることができませんでした。 tar: ./etc/hosts:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基地経路、経路 issue.net 'issue.net' の絶対パスを割り当てられませんでした。 tar: ./etc/issue.net:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線パス、パスプロファイル 「プロファイル」の絶対パスを割り当てられませんでした。 tar: ./etc/profile:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスデフォルト 「デフォルト」の絶対パスを割り当てられませんでした。 tar: ./etc/default:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスの問題 「問題」の絶対的な経路を割り当てることができませんでした。 tar: ./etc/issue:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パススケル 「スケル」に絶対的な経路を割り当てることができませんでした。 tar: ./etc/skel:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パススケル 「スケル」に絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パススケルトン 'skel' の絶対パスを割り当てられませんでした。 tar: ./etc/skel:Cannot mkdir: 悪いアドレス tar: ./etc/skel/.profile:開けられない:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パススケル 「スケル」に絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パススケルトン 'skel' の絶対パスを割り当てられませんでした。 tar: ./etc/skel:Cannot mkdir: 悪いアドレス tar: ./etc/skel/.bashrc:開けられない:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスMTAB 「MTAB」の絶対経路を割り当てることができませんでした。 tar: ./etc/mtab:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスホスト名 「ホスト名」に絶対パスを割り当てられませんでした。 tar: ./etc/hostname:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスFSTAB 「FSTAB」の絶対パスを割り当てることができませんでした。 tar: ./etc/fstab:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底経路、パスシェル 「砲弾」に絶対経路を割り当てることができませんでした。 tar: ./etc/shells:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスhost.conf 'host.conf' の絶対パスを割り当てられませんでした。 tar: ./etc/host.conf: 開けられない: アドレスが悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基道、パスMODT 『MODD』の絶対的な経路を割り当てることができませんでした。 tar: ./etc/motd:開けられない:住所が悪い tar:過去のエラーにより故障状態で退出 エラー:失敗ログファイルは以下のフォルダに保存されています:/home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/temp/log.do_package.1734591 エラー:タスク(/ホーム/vmc/Desktop/imx-yocto-bsp/sources/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_package)が終了コード「1」で失敗しました Re: base-files error when build the yocto linux ありがとう。起動しました Re: base-files error when build the yocto linux Ubuntu PCで、「sudo apt install tar=1.34+dfsg-1build3」コマンドを実行してください。

FRDM-S32K344 手动错误 你好， FRDM-A-S32K344 开发板手册（ UM12406 ）第 11 页有错误。我发布这条评论是为了帮助社区，也为了帮助任何遇到和我一样问题的人。 具体来说，电阻 R43 默认是安装的，以使 FS26 保持在调试模式。要启用正常模式，必须移除 R43，并换上 R42。 应该是： 具体来说，电阻 R43 默认是安装的，以使 FS26 保持在调试模式。要启用正常模式，必须移除 R43。而R42则必须填充内容。 或者： 具体来说，电阻 R43 默认是安装的，以使 FS26 保持在调试模式。要启用正常模式，必须移除 R43。R42必须填充内存才能进入OTP模拟模式。

PN7160A 和 linux_libnfc-nci 在 Raspberry Pi 5 2026 64 位 Trixie 系统上运行 你好， 我正在尝试为工作项目启动 PN7160A，但始终无法让 linux_libnfc-nci 正常工作。该补丁已过时，lgpiod 在版本 2 中进行了全面改进。 还需要使用标志 sudo make install CFLAGS="-Wno-error=implicit-function-declaration" " 否则我就会 "demoapp/main.c:在函数“onMessageReceived”中： demoapp/main.c:451:5:错误：隐式声明函数“PrintNDEFContent” [-Wimplicit-function-declaration] 451 | PrintNDEFContent(NULL, NULL, message, length); 我找到了 2025 年关于 PN7150 的一篇旧帖子，但是当我尝试编译时，我遇到了奇怪的错误，例如“uint8_t”未在作用域中声明，请使用 。我的树莓派操作系统是最新的Trixie Debian 13.6。 需要一些帮助，谢谢。 Re: PN7160A and linux_libnfc-nci on Raspberry Pi 5 2026 64-bit Trixie 你好@paulwitulski 请将补丁作为附件应用。

需要帮助查找适用于 i.MX95 内核版本 (v6.6.52-2.2.0) 的 Neutron 变流器 SDK。 您好，NXP团队， 我目前正在使用 LF_v6.6.52-2.2.2_images_IMX95 ，并且我正在尝试确定 Neutron Converter SDK 的正确版本，以便将 TensorFlow Lite INT8 量化 模型 转换 为 NPU 格式。 我尝试过多个版本的 Neutron 变流器 SDK，但每次尝试都出现以下错误： 信息：NeutronDelegate 委托：27 个节点中有 1 个节点被委托，共 1 个分区。 信息：已为 CPU 创建 TensorFlow Lite XNNPACK 委托。 警告：微代码版本不匹配！0x359f358d（预期为 0xa186aaf2） 警告：微代码版本不匹配！0x359f358d（预期为 0xa186aaf2） 推理轮询超时 错误：元器件='Neutron Driver'，类别='超时'，代码=754 回溯（最近一次调用）： 文件“/home/object_detc/main.py”，第 80 行，在 中 解释器.调用() 文件“/usr/lib/python3.12/site-packages/tflite_runtime/interpreter.py”，第 941 行，在 invoke 中 self._interpreter.Invoke() RuntimeError: /usr/src/debug/tensorflow-lite-neutron-delegate/2.16.2/neutron_delegate.cc:355 neutronRC != ENONE (193099 != 0)节点编号 27 (NeutronD. 能否解释一下为什么移除了对LF_v6.6.52-2.2.2_images_IMX95的支持？是因为该电路板支持包仍被视为 alpha 版本吗？ 请问您能否也就以下问题提供一些建议： 是否可以将 Neutron 变流器 SDK 与此内核/电路板支持包 版本一起使用？ 如果是这样，那么哪个版本的 Neutron 变流器 SDK 与 LF_v6.6.52-2.2.2_images_IMX95 兼容 ？ 如果没有，是否有其他版本的 eIQ 工具或不同的工作流程可以与此 BSP 一起使用？ 感谢您的帮助。期待您的指导。 疑似软件缺陷 Re: Need help to find Neutron Converter sdk for i.MX95 kernel version (v6.6.52-2.2.0) 你好@boopathi123 ， 感谢您联系恩智浦技术支持！ 看来您使用的是非常早期的芯片版本。在这种情况下，我建议使用 eIQ 工具包中包含的 Neutron 变流器。但是请注意，此 BSP 版本并未得到 i.MX95 的官方支持。 i.MX95 正式发布，采用 B0 硅版本和 BSP 6.12.34。早期的硅片版本旨在用于评估和预生产目的，因此可能无法提供与当前支持的设备相同的功能、稳定性、兼容性或性能。 因此，我强烈建议迁移到以下受支持的组合： i.MX95 B0 硅 BSP 6.12.34 或更高版本 使用受支持的软件和硬件配置将确保您能够享受到 i.MX95 平台的最新修复、优化和 NPU 软件支持。 你观察到的现象可能与早期硅片版本中的局限性或已知问题有关，而不是与模型本身有关。 此致， 查维拉

NXP iMX8MP: U-Boot内のWFIベースのCPUアイドル状態が復帰しない 親愛なるNXPサポートチームへ、 私たちはi.MX8M Plusベースの製品向けにU-Bootの低消費電力待機メカニズムを調査しており、NXPからの指導を歓迎する段階に達しています。 ソフトウェアのバージョン SoC: NXP i.MX8M Plus BSP: ATF: lf_v2.10_android-15.0.0_1.2.0 U-Boot: lf_v2024.04_android-15.0.0_1.2.0 公開されているNXP BSPに基づいています（Varisciteフォークには、ATF/GICコードパスに関する重要な変更は含まれていません）。 ゴール アプリはAndroidを起動する前に、バッテリーが完全に放電された状態で数分間U-Bootに留まっている必要があります。 mdelay()に基づくビジーループは不必要な電力を消費し、追加の熱を発生させるため、ARMジェネリックタイマー(CNTP, PPI 30)を使って定期的に低消費電力のアイドル状態とウェイクに入ろうとしています。 初期実装 CNTPタイマーの設定 PPI 30を有効にする EL2から生のwfi()を実行する プロセッサはwfi()から決して起動しません。UARTの出力は、例外やクラッシュもなく、単に停止するだけです。 PSCIの実装 PSCI_VERSIONは1.1を返します。 PSCI_FEATURES(CPU_SUSPEND) は 0 を返します (サポートされています) CPU_SUSPENDを呼び出してスタンバイ電源状態を要求します これにより、ATFスタンバイ実装であるimx_cpu_standby()に到達しますが、システムは全く同じようにハングアップします。例外も発生せず、UART出力もなく、実行は再開されません。 したがって、両方とも： EL2で実行されたraw wfi() wfi() は ATF を介して PSCI で実行されます 全く同じ動作を生み出す。 既に検証済みのもの CPUとタイマー U-BootはEL2上で実行されます。 CNTPタイマーは正しくプログラムされています。 CNTP_TVAL_EL0 は正しくカウントダウンします。 CNTP_CTL_EL0 には以下が表示されます。 有効 = 1 IMASK = 0 武装直後のISTATUSは0です。 CPUインターフェース ICC_PMR_EL1は正しく設定されています。 ICC_IGRPEN1_EL1が有効になっています。 仮想化 HCR_EL2には以下が含まれます： IMO = 0 FMO = 0 したがって、EL2仮想化による割り込みルーティングは関与しません。 割り込みセキュリティ分類 ATFの情報筋から以下のことを確認しました。 すべてのPPIは、汎用GICv3ヘルパーコードによって最初にグループ1非セキュアとして設定されます。 SGI8 (およびオプションで SDEI SGI) のみがセキュアとして再構成されます。 PPI 30 はセキュア割り込みプロパティテーブルに存在しません。 したがって、Generic Timer 割り込みは予想通りグループ1非安全のままのままです。 SCR_EL3.TWE 当初、非セキュアな wfi() が SCR_EL3.TWE を介して EL3 にトラップされるのではないかと疑っていましたが、wfi() が PSCI を介して ATF 自体の中で実行された場合にも同じ動作が発生するため、これは可能性が低いと思われます。 追加調査 ATFのGIC初期化を追跡していると、gicv3_distif_init()がDistributor EnableGrpビットをクリアし、セキュア割り込みプロパティテーブルで要求されたビットのみを再有効化していることに気付きました。 ヘルパーは Group0 と Group1 の Secure プロパティのみを生成するため、EnableGrp1NS が明示的に再度有効になることはないようです。 これを検証するために、我々は以下のことを行いました。 GICD_CTLR を読み込む EnableGrp1NS = 0 を観測しました EL2からEnableGrp1NSを独自に設定しようと試みました。 意外なことに： 書き込みは問題なく完了します。 RWPは正常に動作します。 しかし、読み戻し後もEnableGrp1NSは0のままです。 また、以下の点も確認しました。 GICD_CTLR.DS == 0 GICメモリ領域に対するRDC保護は無効になっています（ENA = 0）。 RDC違反記録はゼロのままです。 したがって、RDCは書き込みを妨げていないようです。 残りの疑問 現時点で、以下の項目を除外しました。 タイマープログラミング、 CPUインターフェース構成、 割り込み優先度マスキング、 割り込みグループ分類、 SCR_EL3.TWE トラッピング、 PSCIと生のWFI実行の比較、 RDC保護。 残された説明のつかない挙動は、アーキテクチャ的に非安全な書き込み可能なディストリビュータ制御ビット(EnableGrp1NS)がこのプラットフォーム上で書き込みを受け入れていないようで、その結果、生のwfi()もPSCIもGeneric Timer割り込みで起動CPU_SUSPENDしないことです。 この動作はi.MX8M Plus Android 15 BSPで予想されるのでしょうか? 汎用タイマーPPIがwfi()からCPUを起動させるために、公開ATFソース以外でプラットフォーム固有の初期化が欠けているのでしょうか? EnableGrp1NSは、このプラットフォーム上で安全でないソフトウェアによる変更を意図的に防いでいるのでしょうか? U-Bootから定期的にウェイクアップする機能を、以下のいずれかの方法で実装することに成功した人はいますか？ 生のwfi()、または PSCI CPU_SUSPEND ARMのジェネリックタイマーで動かされているのか? 初期化シーケンスやプラットフォーム固有の動作についてのご意見をいただけると大変ありがたいです。 よろしくお願いします。 よろしくお願いいたします。 桟橋

MCUX 25.6.136、newlib-nano、& swprintf 未定義 MCUX 25.6.136でswprintfへの未定義参照が発生しています。& newlib-nano。newlibも試してみましたが、結果は同じでした。 いろいろ調べてみたところ、newlib-nano/newlib に上流の問題が見つかりました。https: //sourceware.org/pipermail/newlib/2024/021012.html NXPが私の推測を裏付けてくれるか気になっています。Newlib-nanoのバンドル版にもこの問題があるのではないかと。もしそうなら、newlib-nano/newlibの新しいバージョンを取り入れて修正する案は考えられていますか? - コナー

MD8LC925NR1アンプのバイアス調整方法を教えてください。 こんにちは、 現在、 MD8LC925NR1パワーアンプを使用したシステムを設計中です。適切な バイアス回路や専用の電源管理部品 をおすすめしていただけるとありがたいです。 この目的のために推奨されるリファレンス・デザイン、アプリケーションノート、または具体的な部品番号を教えていただけますか? ご協力ありがとうございました。 Re: How to bias the amp MD8LC925NR1? こんにちは、 NXPセミコンダクターズの製品にご関心をお寄せいただき、またサポートの機会をいただきありがとうございます。 記載されている部品番号に誤植があるようです。MDL8LC925NR1は、NXPの有効な注文可能部品番号ではありません。最も近い類似デバイスはMD8IC925Nです。このデバイスは現在、販売終了（EOL）となっており、サポートが終了しているため、新規購入はできませんのでご注意ください。 以下のNXP文書は、回路回路図、部品リスト、特性評価データを含む詳細な設計情報を提供しています。 MD8IC925N データシート AN1977 – RF集積回路ファミリにおける静止電流熱追尾回路 AN1987 – RF集積回路デバイスファミリ向けクイセント電流制御(両方のバイアス回路トポロジーと完全な部品リストを含む) AN1955 – RFパワーアンプの熱測定手法 残念ながら、MD8IC925Nの直接的な代替品は存在しません。さらに、 100MHzから1000MHz 帯をカバーする多くのRF製品はEOLに近づいており、現時点では新しい代替機器の発表はありません。 お客様の周波数、電力、供給電圧に関する具体的な要件に基づき、代替ソリューションの特定についてサポートが必要な場合は、お知らせください。 よろしくお願いいたします。

.mexファイル内の警告ファイル （自動生成された）.mexファイル内プロジェクト用のファイルでは、各ペリフェラルは次のような内容です: 1.0.0 「説明」属性の文言に注目してください。他のペリフェラルについては状況が異なりますが、ほとんどの場合、警告やエラーメッセージのようなものです。プロジェクトは正常にコンパイルされ、実行されます。 関連して、『ペリフェラルビュー』から新しいソフトウェアコンポーネントを追加しようとすると、現在選択されていないペリフェラルが黄色い感嘆符でマークされています。添付のスクリーンショットをご覧ください。マウスカーソルをそれらの上に重ねると、「description」属性に表示されているのと同じメッセージが表示されます。しかし、私は問題なくそれらを追加できます。 これらの警告は何に関するものですか？ Re: Warning in the .mex file こんにちは、 @durga_choudhuryさん この警告はプロジェクトには影響しません。対応するドライバーがプロジェクトに追加または設定されていないことを示すだけです。したがって、お客様の現在の実装に機能的な影響は想定されません。 BR、VaneB

Need help to find Neutron Converter sdk for i.MX95 kernel version (v6.6.52-2.2.0) Hello NXP Team, I am currently using LF_v6.6.52-2.2.2_images_IMX95 and I'm trying to identify the correct version of the Neutron Converter SDK to convert a TensorFlow Lite INT8 quantized model for the NPU. I have tried multiple versions of the Neutron Converter SDK, but every attempt results in the following error: INFO: NeutronDelegate delegate: 1 nodes delegated out of 27 nodes with 1 partitions. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. Warning: microcode version mismatch! 0x359f358d (expected 0xa186aaf2) Warning: microcode version mismatch! 0x359f358d (expected 0xa186aaf2) Inference poll timeout Error: component='Neutron Driver', category='timeout', code=754 Traceback (most recent call last): File "/home/object_detc/main.py", line 80, in interpreter.invoke() File "/usr/lib/python3.12/site-packages/tflite_runtime/interpreter.py", line 941, in invoke self._interpreter.Invoke() RuntimeError: /usr/src/debug/tensorflow-lite-neutron-delegate/2.16.2/neutron_delegate.cc:355 neutronRC != ENONE (193099 != 0)Node number 27 (NeutronD. Could you clarify why support for LF_v6.6.52-2.2.2_images_IMX95 was removed? Is this because the BSP is still considered an alpha release? Could you also please advise on the following: Is it possible to use the Neutron Converter SDK with this kernel/BSP version? If so, which version of the Neutron Converter SDK is compatible with LF_v6.6.52-2.2.2_images_IMX95? If not, is there another version of the eIQ tools or a different workflow that should be used with this BSP? Thank you for your help. I look forward to your guidance. Suspected Software Defect Re: Need help to find Neutron Converter sdk for i.MX95 kernel version (v6.6.52-2.2.0) Hi @boopathi123, Thank you for contacting NXP Support! It appears that you are using a very early silicon revision. In that case, I recommend using the Neutron Converter included with the eIQ Toolkit. However, please note that this BSP version is not officially supported for the i.MX95. The i.MX95 was officially released with the B0 silicon revision and BSP 6.12.34. Earlier silicon revisions were intended for evaluation and pre production purposes, and therefore may not provide the same level of functionality, stability, compatibility, or performance as the currently supported devices. For this reason, I strongly recommend migrating to a supported combination of: i.MX95 B0 silicon BSP 6.12.34 or later Using a supported software and hardware configuration will ensure that you benefit from the latest fixes, optimizations, and NPU software support available for the i.MX95 platform. The behavior you are observing may be related to limitations or known issues present in the early silicon revisions rather than the model itself. Best regards, Chavira

NXP iMX8MP: WFI-based CPU idle in U-Boot never wakes Dear NXP Support Team, We are investigating a low-power waiting mechanism in U-Boot for a i.MX8M Plus based product and have reached a point where we would appreciate guidance from NXP. Software versions SoC: NXP i.MX8M Plus BSP: ATF: lf_v2.10_android-15.0.0_1.2.0 U-Boot: lf_v2024.04_android-15.0.0_1.2.0 Based on the public NXP BSP (Variscite fork contains no relevant modifications in the ATF/GIC code paths) Goal The application needs to remain in U-Boot for several minutes while a deeply discharged battery charges before Android is started. A busy-loop based on mdelay() consumes unnecessary power and generates additional heat, so we are trying to periodically enter a low-power idle state and wake using the ARM Generic Timer (CNTP, PPI 30). Initial implementation configure CNTP timer enable PPI 30 execute a raw wfi() from EL2 The processor never wakes from wfi(). UART output simply stops with no exception or crash. PSCI implementation PSCI_VERSION returns 1.1 PSCI_FEATURES(CPU_SUSPEND) returns 0 (supported) invoke CPU_SUSPEND requesting the Standby power state This reaches the ATF standby implementation imx_cpu_standby(), but the system hangs in exactly the same way: no exception, no UART output, and execution never resumes. Therefore, both: raw wfi() executed at EL2 wfi() executed through ATF via PSCI produce identical behavior. What have been already verified CPU and timer U-Boot executes at EL2. CNTP timer is correctly programmed. CNTP_TVAL_EL0 counts down correctly. CNTP_CTL_EL0 shows: ENABLE = 1 IMASK = 0 ISTATUS = 0 immediately after arming. CPU interface ICC_PMR_EL1 is configured correctly. ICC_IGRPEN1_EL1 is enabled. Virtualization HCR_EL2 has: IMO = 0 FMO = 0 so interrupt routing through EL2 virtualization is not involved. Interrupt security classification From the ATF sources we verified that: all PPIs are initially configured as Group 1 Non-secure by the generic GICv3 helper code, only SGI8 (and optionally SDEI SGIs) are reconfigured as Secure, PPI 30 is **not** present in the secure interrupt property table. Therefore the Generic Timer interrupt appears to remain Group 1 Non-secure as expected. SCR_EL3.TWE We originally suspected that non-secure wfi() might be trapped to EL3 via SCR_EL3.TWE, but this now seems unlikely because the same behavior occurs when wfi() is executed inside ATF itself through PSCI. Additional investigation While tracing the ATF GIC initialization we noticed that gicv3_distif_init() clears the Distributor EnableGrp bits and only re-enables those requested by the secure interrupt property table. Since the helper only produces Group0 and Group1 Secure properties, it appears that EnableGrp1NS is never explicitly re-enabled. To verify this we: read GICD_CTLR observed EnableGrp1NS = 0 attempted to set EnableGrp1NS ourselves from EL2. Unexpectedly: the write completes without fault, RWP behaves normally, but EnableGrp1NS remains 0 after readback. We also verified: GICD_CTLR.DS == 0 RDC protection for the GIC memory regions is disabled (ENA = 0) RDC violation registers remain zero. Therefore RDC does not appear to be preventing the write. Remaining question At this point we have eliminated: timer programming, CPU interface configuration, interrupt priority masking, interrupt group classification, SCR_EL3.TWE trapping, PSCI vs raw WFI execution, RDC protection. The remaining unexplained behavior is that an architecturally Non-secure writable Distributor control bit (EnableGrp1NS) does not appear to accept writes on this platform, and consequently neither raw wfi() nor PSCI CPU_SUSPEND ever wake using the Generic Timer interrupt. Is this behavior expected on the i.MX8M Plus Android 15 BSP? Is there any platform-specific initialization missing outside the public ATF sources that is required before the Generic Timer PPI can wake a CPU from wfi()? Is EnableGrp1NS intentionally prevented from being modified by non-secure software on this platform? Has anyone successfully implemented periodic wake-up from U-Boot using either: raw wfi(), or PSCI CPU_SUSPEND  driven by the ARM Generic Timer? Any insight into the expected initialization sequence or platform-specific behavior would be greatly appreciated. Thanks Best Regards Pier

i.MX95カーネルバージョン(v6.6.52-2.2.0)用のNeutron Converter SDKを探すのに助けが必要です NXPチームの皆様、こんにちは。 現在 は LF_v6.6.52-2.2.2_images_IMX95 を使っており、 TensorFlow LiteのINT8量子化 モデルをNPU用 に 変換するための 正しい Neutron コンバータ SDK のバージョンを特定しようとしています 。 Neutron Converter SDKsの複数のバージョンを試しましたが、毎回以下のエラーが発生します。 INFO: NeutronDelegate デリゲート: 27 ノードのうち 1 ノードが委任され、1 つのパーティションがあります。 情報: CPU 用の TensorFlow Lite XNNPACK デリゲートを作成しました。 警告：マイクロコードのバージョンが一致しません！0x359f358d（期待値：0xa186aaf2） 警告：マイクロコードのバージョンが一致しません！0x359f358d(予想された0xa186aaf2) 推論調査のタイムアウト エラー:コンポーネント='Neutron Driver'、カテゴリ='タイムアウト'、コード=754 トレースバック(直近の通話): ファイル「/home/object_detc/main.py」、 interstructer.invoke() ファイル "/usr/lib/python3.12/site-packages/tflite_runtime/interpreter.py",インヴォークの941行 self._interpreter。Invoke() RuntimeError: /usr/src/debug/tensorflow-lite-neutron-delegate/2.16.2/neutron_delegate.cc:355 neutronRC != ENONE (193099 != 0) ノード番号27 (NeutronD. なぜ LF_v6.6.52-2.2.2_images_IMX95 のサポートが削除されたのか 、詳しく教えていただけます か?これはBSPがまだアルファ版とみなされているからでしょうか? 以下の点についてもアドバイスいただけますか: このカーネル/BSPバージョンでNeutron Converter SDKを使うことは可能でしょうか? もしそうなら、どのバージョンのNeutron Converter SDKがLF_v6.6.52-2.2.2_images_IMX95に対応しているのでしょうか? そうでない場合、このBSPで使用するべきeIQツールの別のバージョン、または別のワークフローはありますか？ 助けてくれてありがとう。ご指導を心よりお待ちしております。 ソフトウェア不具合の疑い Re: Need help to find Neutron Converter sdk for i.MX95 kernel version (v6.6.52-2.2.0) こんにちは、@boopathi123。 NXPサポートにご連絡いただきありがとうございます! お使いのチップは非常に初期のシリコンリビジョンのようです。その場合は、eIQ Toolkitに付属しているNeutronコンバーターの使用をおすすめします。ただし、このBSPバージョンはi.MX95では公式にはサポートされていないことにご注意ください。 i.MX95は、B0シリコンリビジョンとBSP 6.12.34で正式にリリースされました。以前のシリコン改訂版は評価および量産前の目的で作成されたため、現在サポートされているデバイスと同等の機能性、安定性、互換性、または性能を提供しない可能性があります。 そのため、以下のサポート対象の組み合わせへの移行を強くお勧めします。 i.MX95 B0シリコン BSP 6.12.34以降 対応するソフトウェアとハードウェア構成を使用することで、i.MX95プラットフォーム向けの最新の修正、最適化、NPUソフトウェアのサポートを享受できます。 あなたが観察している挙動は、モデル自体ではなく、初期シリコン改良版に存在した制限や既知の問題に関連している可能性があります。 よろしくお願いします、 チャビラ

如何调整功放MD8LC925NR1的偏置电压？ 你好， 我们目前正在设计一个使用MD8LC925NR1功率放大器的系统。我们恳请您推荐合适的偏置电路或专用电源管理元器件，以便为该功率放大器提供正确的偏置。 请问您能否提供一些推荐的参考设计、应用笔记或具体零件编号？ 谢谢你的帮助。 Re: How to bias the amp MD8LC925NR1? 你好， 感谢您对恩智浦半导体产品的关注，也感谢您给我们提供支持的机会。 提供的零件编号似乎有误。MDL8LC925NR1不是 NXP 可订购的有效零件编号。最接近的匹配设备是MD8IC925N。请注意，该设备目前已停产，这意味着它不再受支持，也不再接受新的购买。 以下NXP文档提供了详细的设计信息，包括电路原理图、元器件清单和特性数据： MD8IC925N 数据手册 AN1977 –射频集成电路系列中的静态电流热跟踪电路 AN1987 – 射频集成电路设备系列的静态电流控制（包括两种偏置电路拓扑结构及完整的元器件清单） AN1955 – 射频功率放大器的热测量方法 遗憾的是，MD8IC925N 没有直接的替代品。此外，许多涵盖100 MHz 至 1000 MHz频率范围的射频产品即将停产，目前还没有宣布推出新的替代设备。 如果您需要我们根据您的具体频率、功率和供电电压要求，协助您寻找替代解决方案，请与我们联系。 顺祝商祺！

MCUX 25.6.136, newlib-nano, & swprintf undefined I'm experiencing an undefined reference to swprintf with  MCUX 25.6.136 & newlib-nano. I've tried newlib as well and same result.  After some digging I've found an upstream issue with newlib-nano/newlib: https://sourceware.org/pipermail/newlib/2024/021012.html  I'm wondering if NXP can corroborate my guess that the bundled version of newlib-nano contains this issue. If that's the case Is a fix via incorporating a newer version of newlib-nano/newlib on the agenda? - Connor

NXP iMX8MP：基于WFI的CPU在U-Boot中处于空闲状态时不会唤醒 尊敬的恩智浦技术支持团队： 我们正在研究基于 i.MX8M Plus 的产品的 U-Boot 中的低功耗等待机制，现在我们希望得到 NXP 的指导。 软件版本 SoC：NXP i.MX8M Plus BSP： ATF：lf_v2.10_android-15.0.0_1.2.0 U-Boot：lf_v2024.04_android-15.0.0_1.2.0 基于公开的 NXP 电路板支持包（Variscite 分支对 ATF/GIC 代码路径没有相关的修改） 目标 在 Android 系统启动之前，应用程序需要在 U-Boot 模式下停留几分钟，以便为深度放电的电池充电。 基于 mdelay() 的忙循环会消耗不必要的功率并产生额外的热量，因此我们正在尝试定期进入低功耗空闲状态，并使用 ARM 通用定时器 (CNTP, PPI 30) 唤醒。 初始实施 配置 CNTP 定时器 启用 PPI 30 从 EL2 执行原始 wfi() 处理器永远不会从 wfi() 中唤醒。UART 输出突然停止，没有任何异常或崩溃。 PSCI 实现 PSCI_VERSION 返回 1.1 PSCI_FEATURES(CPU_SUSPEND) 返回 0（支持） 调用 CPU_SUSPEND 请求进入待机电源状态 程序会执行 ATF 备用程序实现 imx_cpu_standby()，但系统会以完全相同的方式挂起：没有异常，没有 UART 输出，执行永远不会恢复。 因此，两者： 在 EL2 级别执行原始 wfi() 函数 wfi() 通过 ATF 经由 PSCI 执行 产生相同的行为。 已经核实的内容 CPU 和定时器 U-Boot 在 EL2 层执行。 CNTP定时器已正确编程。 CNTP_TVAL_EL0 倒计时正常。 CNTP_CTL_EL0 显示： 启用 = 1 IMASK = 0 布防后，ISTATUS = 0。 CPU接口 ICC_PMR_EL1 配置正确。 ICC_IGRPEN1_EL1 已启用。 虚拟化 HCR_EL2 具有： IMO = 0 FMO = 0 因此，中断路由不会通过 EL2 虚拟化进行。 中断网络安全分类 我们从美国烟酒枪炮及爆炸物管理局（ATF）的消息来源证实： 所有PPI最初都由通用GICv3辅助代码配置为第1组非安全设备。 只有 SGI8（以及可选的 SDEI SGI）被重新配置为安全模式。 PPI 30 不在安全中断属性表中。 因此，通用定时器中断似乎仍如预期那样保持为第 1 组非安全状态。 SCR_EL3.TWE 我们最初怀疑不安全的 wfi() 可能会通过 SCR_EL3.TWE 被困到 EL3，但现在看来不太可能，因为当 wfi() 通过 PSCI 在 ATF 内部执行时，也会发生同样的行为。 进一步调查 在跟踪 ATF GIC 初始化时，我们注意到 gicv3_distif_init() 会清除 Distributor EnableGrp 位，并且只会重新启用安全中断属性表请求的那些位。 由于该辅助程序只生成 Group0 和 Group1 Secure 属性，因此 EnableGrp1NS 似乎永远不会被显式地重新启用。 为了验证这一点，我们： 读取 GICD_CTLR 观察到 EnableGrp1NS = 0 尝试从 EL2 自行设置 EnableGrp1NS。 不料： 写入操作顺利完成，没有出现任何错误。 RWP运行正常 但读取后 EnableGrp1NS 仍然为 0。 我们还核实了： GICD_CTLR.DS == 0 GIC 内存区域的 RDC 保护已禁用（ENA = 0） RDC违规登记数量仍为零。 因此，RDC 似乎并没有阻止写入操作。 剩余问题 至此，我们已经排除了： 定时器编程 CPU接口配置， 中断优先级掩码 中断组分类， SCR_EL3.TWE 捕获， PSCI 与原始 WFI 执行方式对比， RDC保护。 剩下的未解释的行为是，架构上不安全的可写分发器控制位（EnableGrp1NS）似乎不接受此平台上的写入，因此原始 wfi() 和 PSCI CPU_SUSPEND 都无法使用通用定时器中断唤醒。 i.MX8M Plus Android 15 电路板支持包。 出现这种现象是否正常？ 在公共 ATF 源代码之外，是否存在任何平台特定的初始化缺失，导致通用定时器 PPI 无法通过 wfi() 唤醒 CPU？ EnableGrp1NS 是否被有意阻止在此平台上被不安全的软件修改？ 有没有人成功地使用以下两种方法之一实现了从 U-Boot 定期唤醒： 原始 wfi()，或 PSCI CPU_SUSPEND 由 ARM 通用定时器驱动？ 非常感谢您能提供任何关于预期初始化顺序或平台特定行为的见解。 谢谢！ 顺祝商祺！ 码头

.mex 文件中的警告文件 在（自动生成的）.mex 文件中项目文件中，每个外设的内容大致如下： 1.0.0 请注意“描述”属性中的措辞。对于其他外围设备，情况各不相同，但几乎总是会显示警告或错误消息之类的信息。项目编译和运行都没问题。 另外，如果我尝试从“外围设备视图”添加新的软件组件，所有当前未选择的外围设备都会被标记为黄色感叹号，请参见附件屏幕截图。如果我将鼠标悬停在它们上面，就会得到与“描述”属性中显示的相同的消息。但我添加它们没有任何问题。 这些警告是关于什么的？ Re: Warning in the .mex file 你好@durga_choudhury 此警告不会影响您的项目。这仅表明项目中尚未添加或配置相应的驱动程序。因此，预计不会对您当前的实现造成任何功能影响。 BR，VaneB