Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
i.MX95 Boot ROM: Configuring eMMC Boot0/Boot1 as Primary/Secondary and FlexSPI NOR as Recovery Hello Experts, I am trying to understand how the i.MX95 Boot ROM handles the Primary, Secondary, and Recovery boot stages. I have gone through the Reference Manual and some of the U-Boot spl source code, but I am still not clear on how the Recovery boot mechanism is intended to work. My goal is to implement the following boot architecture: Primary boot: eMMC Boot0 Secondary boot: eMMC Boot1 Recovery boot: FlexSPI NOR flash (Golden Recovery Image) While looking through arch/arm/mach-imx/image-container.c, I noticed the following code: printf("Boot stage: "); if (rom_data.boot_stage == 0x6) printf("Primary\n"); else if (rom_data.boot_stage == 0x9) printf("Secondary\n"); else if (rom_data.boot_stage == 0xa) printf("Recovery\n"); else printf("USB Serial Download\n"); Based on this, it appears that the Boot ROM supports four boot stages: Primary, Secondary, Recovery, and USB Serial Download. However, I could not find sufficient information explaining how the Recovery stage is selected or configured. I would appreciate some guidance on the following questions: Is it possible to configure FlexSPI NOR flash as the Recovery boot device while using eMMC Boot0 and Boot1 as the Primary and Secondary boot partitions? If this configuration is supported, what is the recommended way to configure it? What is the sequence followed by the Boot ROM when selecting between the Primary, Secondary, and Recovery boot stages? If both Primary and Secondary boot attempts fail, what conditions trigger the Recovery boot stage? What failure conditions can be intentionally reproduced to simulate Recovery mode during development and validation?  Is there any documentation or application note that describes the Boot ROM boot selection algorithm and Recovery boot flow in detail? Does the boot device fuse configuration (Fuse Mode) play any role in selecting the Recovery boot device? Is the Recovery device determined by the boot device fuses? Or can the Boot ROM automatically switch to a different boot device (such as FlexSPI NOR) even when the boot device is fused to eMMC? Ultimately, my objective is to have the system normally boot from eMMC Boot0, fall back to eMMC Boot1 if necessary, and finally boot a Golden Recovery Image stored in FlexSPI NOR if both eMMC boot partitions are unavailable or invalid. If anyone has implemented a similar boot architecture or can point me to the relevant documentation or application notes, I would really appreciate your guidance. Thank you in Advance ! BR, Arun Kumar
記事全体を表示
Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Hi, I am having trouble getting the SD card software going. All I need to do is get a few items on power-up, no other active management of the SD Card,although I might need logging later on.. I am trying to use data type sd_card_t, and am getting 'unknown type name' error. I have previously included fsl_sd.h and fsl_sdhc.h. but when I do that I get a multiple definition message for many functions in either.  So I assumed that we don't need fsl_sd.h.   It isn't even in my SDK, so for the original multiple definiiton error I downloaded both from github.  Now I have fsl_sdhc.h from the SDK and am still getting the 'unknown type name' message.  Needless to say I am finding the SD card examples very hard to use! Any help would be very much appreciated! Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Hi @ve3id  Thank you for your post, Please Manage the SDK components in you project and add drivers-> sdhc and middleware->memories->SDMMC Stack->SD At the sdcard_polling example the following components are included: To enter into manage the SDK components you need right click the project and go to SDK Managment -> Manage SDK Components Let me know if this solves the issue.  Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Thank you for the quick reply, Carlos, but I have already done that, so maybe there is something else? Here is my window for the SD management: Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Hi @ve3id  Thanks for clarifying, Could you please share which SDK version you are using?  I tried with 2.11.0 and I'm not able to replicate it at my end.  Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F I am using SDK_2.11.0_FRDM-K64F I removed it, and built and downloaded a new one of the same version using the "download and install sdks' tab and still have the same problem. thanks Nigel
記事全体を表示
熱狂期 TEM説明S32 Design Studio for ARM v2018 注文番号S32-DS-ARM_v2018_169264627 EBF4-DE52-80C0-FD65は、承認された有効期限を延長することができますか? Re: 激活码过期 こんにちは、 お客様のS32DSライセンスが延長されました。
記事全体を表示
NVT4857UKAZの代替部品 これはソフトウェアに直接関係ない話ですが、最近、 NVT4857UKAZ はすでにEOLに達しており、ピン・ツー・ピン対応の交換部品が入手できないことが判明しました。i.MX95ベースのデバイスではSDカード**サポート**が必須機能であるため、この状況を踏まえた代替手段を理解しようとしています。交換可能な選択肢や設計方法について、おすすめを教えていただけますか? Re: Alternative part for NVT4857UKAZ こんにちは! NVT4858を代替と呼んでください。 ただし、NVT4858はそのまま交換できるものではないことにご注意ください。したがって、新しいデバイスに対応するためにハードウェアとソフトウェアの両方の改造が必要になる場合があります。 移行の影響を評価するために、仕様や設計要件を慎重に確認することをお勧めします。 お役に立てば幸いです! Re: Alternative part for NVT4857UKAZ こんにちは! NVT4858を代替と呼んでください。 ただし、NVT4858はそのまま交換できるものではないことにご注意ください。したがって、新しいデバイスに対応するためにハードウェアとソフトウェアの両方の改造が必要になる場合があります。 移行の影響を評価するために、仕様や設計要件を慎重に確認することをお勧めします。 お役に立てば幸いです!
記事全体を表示
IMX6Q U-BooT Hi, I have a custom camera with an IMX6q processor. I have working firmware on an old bootloader and an old kernel. I need to update the bootloader and kernel. But I can't get past the kernel loading stage. The UART log is always empty. Please help. Re: IMX6Q U-BooT Hello @CAT5000  Hope you are doing very well. Please specify the current BSP version and the new one. Also, your Software changes related to the UART where is defined for Console. Best regards, Salas. Re: IMX6Q U-BooT Working bootloader version U-Boot 2018.03 (Apr 22 2021 - 04:17:10 -0400) CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C) at 30C Reset cause: POR Model: Freescale i.MX6 Quad SABER Smart Device Board Board: MX6-SabreSD Watchdog enabled DRAM: 2 GiB PMIC: PFUZE100! DEV_ID=0x10 REV_ID=0x21 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... Card did not respond to voltage My board is a reference board with SabreSD I have all the schematics and data I'm not good at this kind of task, but I'd like to update the firmware to try out the new features. Re: IMX6Q U-BooT Hello! Actually, we have a guide for porting our processors to the last BSP version. Please take a look to the UG10165 (i.MX Porting Guide). There are described the changes that you need to do in U-boot. Also, if you have the Sabre board, you can simply download the last version Pre-compiled image from Embedded Linux for i.MX Applications Processors and flash to your board. Best regards,  Salas.
記事全体を表示
Newbie setting up an autosar environment When downloading S32 Design Studio for ARM 2.2 – Windows/Linux, the above message appears. Hopefully, the official website can be reset so that downloads can proceed normally. Thank you. When downloading S32 Design Studio for ARM 2.2 – Windows/Linux, the above message appears. Hopefully, the official website can reset this so that the download can proceed normally. Thank you. Re: 新手搭载autosar环境 Hello, Please try it now. It should be working. Best regards, Peter
記事全体を表示
IMX6Q U-Boot 您好,我有一台定制相机,搭载IMX6q处理器。 我有一个可以在旧版引导加载程序和旧版内核上运行的固件。 我需要更新引导加载程序和内核。 但我始终无法通过内核加载阶段。 UART 日志始终为空。 请帮忙。 Re: IMX6Q U-BooT 你好@CAT5000 希望你一切都好。 请指定当前 BSP 版本和新版本。 此外,您的软件更改与 UART 相关,其中 UART 已在控制台中定义。 顺祝商祺! 萨拉斯。 Re: IMX6Q U-BooT 您好! 实际上,我们有将我们的处理器移植到最新 BSP 版本的指南。 请参考UG10165 (i.MX 移植指南)。 这里描述了需要在 U-boot 中进行的更改。 另外,如果您有 Sabre 开发板,您可以直接从Embedded Linux for i.MX Applications Processors下载最新版本的预编译镜像,然后刷写到您的开发板上。 此致, 萨拉斯。 Re: IMX6Q U-BooT 工作引导加载程序版本 U-Boot 2018.03(2021年4月22日 - 04:17:10 -0400) CPU:Freescale i.MX6Q rev1.3 996 MHz(运行频率为 792 MHz) CPU:汽车级温度等级(-40℃至125℃),工作温度30℃ 复位原因:POR 型号:飞思卡尔 i.MX6 Quad SABER 智能设备板 板:MX6-SabreSD 已启用看门狗 动态随机存取存储器(DRAM):2 GiB PMIC:PFUZE100!开发版本号=0x10 版本号=0x21 MMC:FSL_SDHC:0,FSL_SDHC:1,FSL_SDHC:2 从MMC加载环境... 卡未响应电压 我的主板是参考板,搭载 SabreSD 卡。 我拥有所有原理图和数据。 我不擅长这类任务,但我很想更新固件,体验一下新功能。
記事全体を表示
新手搭载autosar环境 下载S32 Design Studio for ARM 2.2 – Windows/Linux 的时候,提示如上 希望能官网能重置一下,可以进行正常下载  谢谢 When downloading S32 Design Studio for ARM 2.2 – Windows/Linux, the above message appears. Hopefully, the official website can reset this so that the download can proceed normally. Thank you. Re: 新手搭载autosar环境 你好, 请立即尝试。应该可以正常运行了。 顺祝商祺! Peter
記事全体を表示
MCTPTX1AK324、FreeMASTER接続の問題 0x80000101 モーター開発にはMCTPTX1AK324の開発ボードを使っています。今、ボタン3を押すとモーターは動きます。設定を調整するためにMCATホストコンピュータを使う必要があります。しかし、シリアル接続でfreeMASTERを使うとエラーが表示されます:接続タイムアウト、0x8000 0101。デモプログラムに変更が必要かどうか確認してもらえますか? 現在、デモプログラムの一部のコードがブロックされています。M3でGD3000とIPCFを初期化するとプログラムがフリーズするため、FAEの提案に基づいてブロックしました。 3Q
記事全体を表示
ファルコンモードのOP-TEE || iMX8MP_EVK こんにちは、 i.MX8MP EVKで、OP-TEEとFalcon Modeの両方を有効にしたいです。 マシン: imx8mpevk リポジトリ: https://github.com/nxp-imx/imx-manifest Branch: imx-linux-walnascar XML: imx-6.12.34-2.1.0.xml 現在、私はmeta-imx-fastboot(lf-6.12.20-2.0.0-secure)を使用して、Falcon Mode経由で高速起動を実現しています。しかし、ファルコンモードが有効になっている場合、OP-TEEは無効になります。 私の要望としては、 OP-TEEとファルコンモードの両方を同時に有効にする必要があります。 i.MX8MP EVKのファルコンモードでOP-TEEを有効にする方法を教えていただけますか? i.MX 8ファミリ | 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 こんにちは、 @Sanjiv_Mns 現在、meta-imx-fastbootレイヤーはOP-TEEをサポートしていません。原理的には可能であるはずだが、まだ実現されていない。 説明: デフォルトの BSP では、OP-TEE の開始アドレスとサイズは、 rom_pointerに基づいて U-Boot の適切なブート ステージ中に計算されます (参照: https://github.com/nxp-imx/uboot-imx/blob/lf-6.12.20-2.0.0/arch/arm/mach-imx/dt_optee.c#L13) 。 SPLにおけるrom_pointerは、U-Boot本体とは異なる意味/値を持つ。SO、 ft_add_optee_node 関数はSPLからさらに変更なしで実行できません。 ありがとうございます エレナ Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @elena_popa OP-TEE→LinuxブートフローでSPLを達成するためにさらに進める方法→教えていただけませんか?これを確実に動作させるために必要な正しい手順と構成要素を理解したいです。 また、 STM32MP プラットフォームで同様のフローが実装されているリンクも見つけました。 https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ この方法が私のユースケースに適用できるのか、それとも一部を再利用したり、同じブートシーケンスを実現するために適応できるのか教えていただけますか? Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @Sanjiv_Mns i.MX 8MPでOP-TEEをFalconモードで有効化して実行することに成功しました。 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の予約済みメモリ領域をreserved-memoryノードの下に追加します。 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! イネーブルメント中に問題があれば、ぜひ教えてください。 ありがとうございます エレナ Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @elena_popa この作業は既に完了しており、現在私のi.MX8MPボードで正常に起動しています。 現在の起動フローは以下のとおりです。 SPL → ATF → OP-TEE → Linux すべて想定通りに動作しています。@elena_popaさん、コメントありがとうございます。   [ 0.412349] OPEE:導管方法のプロービング。 [ 0.412373] optee: リビジョン 4.6 (788dc101B05ae47b) [ 0.412678] optee: 動的共有メモリが有効です [ 0.413062] optee: 初期化されたドライバ
記事全体を表示
登録:S32K eMIOSエンコーダーのCW/CCWカウンタの静的ローター位置での挙動 チームの皆さん、こんにちは。 私はS32K322マイクロコントローラを使っており、位置センサーからローター角度を得るためのエンコーダーインターフェースを実装しています。 申請ノートに基づいて、TRGMUX、LCU、eMIOSを含む必要なMCALモジュールを構成しました。エンコーダーの機能は正常に動作していますが、CWカウンターとCCWカウンターで予期しない動作が見られました。 私の質問は以下のとおりです。 ローターが動いていない静的なローター位置では、CWおよびCCWカウンターがフリーランニングカウンターとして振る舞うことが期待されますか? 私の場合、CWとCCWカウンターは増加し続けますが、絶対ポジション値はゼロのままです。これは想定される動作ですか? もしこれが予想されるなら、ローターが静止しているのにCWやCCWカウンターが増加する理由は何ですか? もし予想外の情報があれば、以下の方法を提案していただけませんか: MCALの設定(TRGMUX、LCU、またはeMIOS)において、必要な構成変更はありますか? ローターが静止しているときにCW/CCWカウンターが増加しないように、追加のソフトウェア機構やフィルタリングを実装すべきでしょうか? 参考のために動画を添付しました。 AWSライブラリS32K3 よろしくお願いいたします。 ティル Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position こんにちは、 LCnからのCWおよびCCW出力は、それ自体で位置カウンターではありません。インクリメンタルエンコーダの実装によれば、使用されるLCnは、検出された直交シーケンスに応じて、A/B信号の各エッジでCWまたはCCW出力にパルスストリームを生成します。eMIOSはこれらのパルスをカウントして位置を蓄積します。これは、PHA/PHBがLCUで処理され、eMIOSが位置蓄積のカウンターとして機能するS32K3の直交方式と一致しています。https://community.nxp.com/t5/S32K/Quadrature-decoder-on-S32K344/mp/1507580 ローターが本当に静的でエンコーダのA/B入力が安定している場合、新しいCW/CCWパルスを連続的に生成すべきではありません。したがって、CWとCCWの両方のカウンターが、絶対位置がゼロのまま増加するのは期待される「理想的な」挙動ではありません。 いくつか確認しておくと良い点があります。 eMIOSチャネルが本当にCW/CCWの入力パルスをカウントしているか、内部クロックソースではないか確認してください。 デバッガで使用されているeMIOSチャネルのUINステータスを確認してください。カウンターが増加してもUINが一定のままであれば、チャネルは意図した外部入力を使っていない可能性があります。 もしローターが静止している間にUINがトグルしている場合は、エンコーダA/B信号、TRGMUXルーティング、LCU出力、入力フィルタリングを調べてください。 また、ノイズやグリッチがないことを確認するために、エンコーダのA/B信号とLCUのCW/CCW出力をオシロスコープで監視してください。 これにより、問題の原因がエンコーダ信号の活動/ノイズによるものか、eMIOSの設定の問題によるものかを判断するのに役立つはずです。 BR、ペトル
記事全体を表示
S32K3MCU 发送慢通道 无法接收数据。 大家好 我正在使用 S32K311 的 SENT 接口接收数据,我遇到了这样一种情况:快通道正常接收数据,但慢通道无法接收任何数据。 我监测了 SENT 错误通知功能,没有发现任何异常。 MCU 型号为 S32K311 RTD 版本:S32DS 3.6.2RTD6.0.0 发送传感器:Sensata 压力传感器增强型慢速消息 首先,我知道 SENT 逻辑是在“Flexio_Sent_Ip_ProcessSerialMsg”函数中处理的,随后,在外层函数中,它会监测“Data->SerialState”和“FastMsgCount”变量,以确定慢通道是否已完成接收数据。 于是,我捕获了相关的比特信息。 bit(x):已发送快速通道状态半字节位 S: " STATUS_SENT_SERIAL_SHORT" 。 E:" STATUS_SENT_SERIAL_ENHANCED" 我发现慢速通道的解析逻辑反复跳转,无法正常解析。 在特定情况下,SENT 的处理逻辑是否存在错误? 谢谢! Re: S32K3MCU SENT slow channel Cannot receive data. SOC端有任何错误日志吗? Re: S32K3MCU SENT slow channel Cannot receive data. 你好@khty , 能否分享一下Sensata传感器的发送配置信息?从你的图片中,我可以看到第 8 位 C 位被设置为 0;我假设使用的是 8 位消息 ID,12 位数据格式。 由于您的快速通道已正确接收,并且没有报告 SENT 错误通知,因此我了解到问题与处理功能有关。 我尚未发现任何关于频道接收速度慢的已知问题;但是,我已经与内部团队展开了讨论,让我尝试获取有关此问题的更多信息。 最后,您能否提供至少 18 个连续的 SENT 帧的完整捕获文件?这样我们就可以进一步检查RTD状态机的行为是否与预期的增强型串行解码序列相匹配。 此致, 朱利安 Re: S32K3MCU SENT slow channel Cannot receive data. 您好,感谢您快速回复我的问题。 Sensata提供的传感器配置信息如下图所示: 关于您最后一个要求,我需要至少连续 18 个 SENT 帧的完整捕获数据。我已经将其放在“bitChange.xlsx”文件中。文件在附录中。 我在表格中显示了每个捕获的状态半字的第二位和第三位。 表格中,每一列代表一条已发送的消息。每个大的黑色方框内包含一条 slowChannel 消息。蓝色区域为ID区域,绿色区域为CRC校验区域,黄色区域为数据区域。底部的信息为人工分析结果。 如果您需要任何其他信息,请告诉我,我会尽快回复。 Re: S32K3MCU SENT slow channel Cannot receive data. 发送的快速错误通知和慢速错误通知均未报告任何故障。 您可以读取记录在“bitchange.xlsx”中的数据。用于分析,因为它包含我记录的快速通道的每个状态半字的第 2 位和第 3 位的信息。Bit1 和 Bit0 信息被丢弃,因为它们在慢速信道中没有意义。 同时,我手动解析了慢速频道信息,并用黑色方块进行了标识。 在“bitchange.xlsx”中,“State”行中的数据对应于代码中的“ Flexio_Sent_Ip_axFastData[Instance][ChannelId].SerialState ”。它负责检测和识别慢通道是“短”还是“增强”。“计数”代表“ Flexio_Sent_Ip_axFastData[Instance][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 问题,但是,由于我没有特定的硬件配置,因此我无法重现该问题。 我已经将此信息转发给内部团队,如有任何新消息,我会及时通知您。 此致, 朱利安
記事全体を表示
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`目标的实现)。 此致, 志明
記事全体を表示
Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position Hi Team, I am using the S32K322 microcontroller and have implemented the encoder interface to obtain the rotor angle from a position sensor. I have configured the required MCAL modules, including TRGMUX, LCU, and eMIOS, based on the application note. The encoder functionality is operational; however, I have observed unexpected behavior with the CW and CCW counters. My questions are as follows: During a static rotor position (i.e., when the rotor is not moving), is it expected for the CW and CCW counters to behave as free-running counters? In my case, both the CW and CCW counters continue to increment, while the absolute position value remains at zero. Is this expected behavior? If this is expected, what is the reason for the CW and CCW counters incrementing even though the rotor is stationary? If this is not expected, could you please suggest: Any configuration changes required in the MCAL setup (TRGMUX, LCU, or eMIOS)? Any additional software mechanism or filtering that should be implemented to prevent the CW/CCW counters from incrementing when the rotor is stationary? Attached the video for your reference AWS-LIBRARIES-S32K3  Regards, Thiru Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position Hi, The CW and CCW outputs from LCn are not position counters by themselves. According to the incremental encoder implementation, used LCn generates pulse streams on the CW or CCW output at every A/B signal edge, depending on the detected quadrature sequence. eMIOS then counts these pulses to accumulate position. This matches the S32K3 quadrature approach where PHA/PHB are processed by LCU and eMIOS acts as the counter for position accumulation. https://community.nxp.com/t5/S32K/Quadrature-decoder-on-S32K344/m-p/1507580 If the rotor is truly static and the encoder A/B inputs are stable, then new CW/CCW pulses should not be continuously generated. So both CW and CCW counters incrementing while the absolute position remains zero is not the expected “ideal” behavior. A few things are worth checking: Verify that the eMIOS channel is really counting the CW/CCW input pulses and not an internal clock source. Check the UIN status of the used eMIOS channel in the debugger. If UIN remains constant while the counter increments, the channel may not be using the intended external input. If UIN is toggling while the rotor is stationary, investigate encoder A/B signals, TRGMUX routing, LCU outputs, and input filtering. Also monitor the encoder A/B signals and LCU CW/CCW outputs on a scope to rule out noise or glitches. This should help determine whether the issue is caused by encoder signal activity/noise or by an eMIOS configuration issue. BR, Petr
記事全体を表示
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
記事全体を表示