Pressure sensor recommendation for RDK358BMU pressure sensor bring-up. RD-K358BMU  I am working on the RDK358BMU evaluation board and am planning the pressure sensor bring-up. Could you please help with the following information: 1. What is the recommended pressure sensor part number for use with the RDK358BMU? 2. Is there a specific pressure sensor used or validated in the NXP reference design? 3. Could you also share the sensor interface, connection details, and any software configuration required for bring-up? Any reference documentation or application notes related to pressure sensor integration with the BMU would also be appreciated. Re: Pressure sensor recommendation for RDK358BMU pressure sensor bring-up. Hi @shweta_jagadale, 1. & 2. RDK358BMU uses the Highly Integrated Battery Pressure Monitor Sensor NBP8-9x.  3. You can refer to pressure sensor datasheet for more information about connection and programming of the pressure sensor.  The RD-K358BMU User Guide also describes the pressure sensor hose port. Lastly, you can find all of the related SW needed for the RD-K358 (S32K358) from our Automotive Software Package Manager. There is also the Application Software for the Host MCU connected to the NBP8 – KE15Z FreeMASTER demo. Best regards, Julián 

T2080 ATMUのPCIe1用セットアップ 私は2枚のT2080をPCIe接続で連結しています。1台はRCとして、もう1台はEPとして設定しています。私はRCからEPへのトラフィック（読み取り/書き込み）のみをテストしています。PCIe2またはPCIe4間の接続テストを実行すると、テストは正しく機能し、EPに書き込まれたデータはEPからの読み取り時に正しくエコーバックされます。このテストは、EP社のT2080のDRAMへのマッピングを行うだけのものです。つまり、ATMUレジスタ、LAW、TLBは正しく設定されています。 しかし、PCIe1を使用するとテストは失敗します。3つのコントローラセットアップすべてで設定はまったく同じです。SWは単にコンパイルされ、コントローラに適切なメモリ変更を加えてバスをPCIe4からPCIe1に変更します。バス上にPCIeアナライザを設置しています。書き込みと読み込みが想定どおりに完了していることが確認できました。しかし、読み戻されたデータは、RCが前のステップで書き込んだデータとは一致しない。RCからエミュレータを使用して侵入し、PCIeバスを介してEP DRAM（BAR1）にマッピングされたメモリ空間を調べると、繰り返しパターンが見られます。T2080 EPプロセッサに侵入してDRAMを調べると、DRAM開始時に書き込まれた元の値からは変わっていません。PCIe1の何が違うのか。PCIe1がSR-IOVをサポートしていることは知っていますが、有効にしていません。 Re: T2080 ATMU setup for PCIe1 私もPCIe設定を進めているときに似たような問題に遭遇し、ドキュメントを丁寧に確認したことで大きな違いがありました。別のプロジェクトに関連する情報を整理する際に、ハードウェアのリファレンス情報の一部をPinal Assessor Portalと比較しました。セットアップがスムーズに進むことを願っています。最終的に問題が解決した方法を教えていただけると嬉しいです。この話題を持ち出してくれてありがとう。 Re: T2080 ATMU setup for PCIe1 T2080 ATMUのPCIe1向け設定に関する詳細情報は、ハードウェア構成や最適化を検討しているすべての人にとって有益な情報となる。議論は有益で、さらに関連情報はダラス評価データ を通じてさらに参考にすることができます。設定方法や技術的な更新を追跡することで、システム性能の理解を深めるのに役立ちます。ここで共有された洞察に感謝します。同様の話題でのさらなる議論を楽しみにしています。 Re: T2080 ATMU setup for PCIe1 PCIe1用のT2080 ATMU構成は、特にシステムハードウェアやパフォーマンスチューニングに取り組む人にとって興味深い構成トピックに見えます。信頼できる技術的およびドキュメント関連情報をユーザーが見つけるのに役立つ詳細なリソースを共有することは有用です。参考資料として、体系的に整理された公開情報リソースを調べる上で、セジウィック裁判所の審理記録が役立ちました。明確な説明と共有された経験があれば、複雑なセットアップも他の人が理解しやすく、トラブルシューティングしやすくなります。 Re: T2080 ATMU setup for PCIe1 RCとEPのダンプ、そしてLAWレジスタも提供できます。PCIeインターフェースのダンプに使う特定のアドレス範囲はありますか?欲しい隠しレジスターは何かあります(NXPが過去にいくつか変更するように言ったので存在することは知っています)。通常のレジスタとPCIe設定メモリスペースの両方を聞いているのですか?(これは少し入手が難しいですが、Lauterbachから画面をダンプできます—これは98%正しいです)。 [NXP] はい。通常レジスタとPCIeコンフィギュレーション空間のダンプが必要です。RCとEPの両方についてこの作業を実施してください。PCIeオフセットについては、T2080RMの表2-5「CCSRブロックベースアドレスマップ」を参照してください。さらに、LAWレジスタのレジスタダンプも必要です。 PEXアナライザーのダンプで具体的に何を求めているのかよくわかりません。もし私の言ったことが本当かどうかの証拠(「書いた内容を返さないで」と書かれているなら、それを示すことができます)。 [NXP]PEXアナライザーのダンプは、読み取りが書き込みデータを返さない場合に必要です。通過時の分析ツールのダンプも共有して比較できると助かります。 Re: T2080 ATMU setup for PCIe1 RCとEPのダンプ、そしてLAWレジスタも提供できます。PCIeインターフェースのダンプに使う特定のアドレス範囲はありますか?隠しレジスタは何でも変更してください（NXPから過去にいくつか変更するように指示されたことがあるので、存在することは知っています）。通常のレジスタとPCIe設定メモリスペースの両方を聞いているのですか?(これは少し入手が難しいですが、Lauterbachから画面をダンプできます—これは98%正しいです)。 PEXアナライザーのダンプに関して、具体的に何を求めているのかよく分かりません。もし私の言ったことが本当かどうかの証拠(「書いた内容を返さないで」と書かれているなら、それを示すことができます)。 Re: T2080 ATMU setup for PCIe1 RCとEPのダンプ、そしてLAWレジスタも提供できます。PCIeインターフェースのダンプに使う特定のアドレス範囲はありますか?隠しレジスタは何でも変更してください（NXPから過去にいくつか変更するように指示されたことがあるので、存在することは知っています）。通常のレジスタとPCIe設定メモリスペースの両方を聞いているのですか?(これは少し入手が難しいですが、Lauterbachから画面をダンプできます—これは98%正しいです)。 PEXアナライザーのダンプに関して、具体的に何を求めているのかよく分かりません。もし私の言ったことが本当かどうかの証拠(「書いた内容を返さないで」と書かれているなら、それを示すことができます)。 Re: T2080 ATMU setup for PCIe1   PCIeインターフェース(RCとEPの両方)用のレジスタダンプを教えてください。 コンソールログ全体を提供してください PEXアナライザーのダンプ   LAWレジスタのレジスタダンプも必要です。

imx93 无法加载 mcimx93evk_ethosu_apps.elf，如果 mcimx93evk_ethosu_apps.elf 需要 OCRAM。 我正在尝试示例代码。 mcimx93evk_ethosu_apps。在这种情况下，elf 需要使用 OCRAM（某些变量太大）。 在精灵建造完成后。我将这个 elf 文件加载到 m33 中。 它总是失败： remoteproc remoteproc0：已注册的例外情况不符合请求要求 remoteproc remoteproc0：错误的 phdr da 0x20480000 mem 0x60000 remoteproc remoteproc0：加载程序段失败：-22 远程进程 remoteproc0：启动失败：-22 可能是由于冲突导致内存分配失败。 为什么？ 示例代码如下： 来自 sdk_examples 的 mcimx93evk_ethosu_apps。请您查看一下这个示例好吗？ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. NXP 网站上的 SDK 版本为： 2.14.xx 有人成功将 mcimx93evk_ethosu_apps 加载到 m33 吗？ 如何在m33中成功运行mcimx93evk_ethosu_apps？ 谢谢。 Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. 我没有修改ld。 m_ocram（RW）：ORIGIN = 0x20480000，LENGTH = 0x00060000 __attribute__ ((section(".bss.tensor_arena_ocram"),aligned(32))) uint8_t inferenceProcessTensorArena[TENSOR_ARENA_SIZE]; 将 elf 文件加载到 m33 后的结果： remoteproc remoteproc0：错误的 phdr da 0x20480000 mem 0x60000

バーストレジスタを使用したSPI伝送 こんにちは、NXPさん。 ターゲットMCU:S32K388 私はeDMAを使用したSPI伝送に、バーストレジスタTCBRおよびTDBR0-127を使用しています。 現在のフレームサイズは32ビットで、すべて期待どおりに動作しています。 さて、32ビット未満のSPIフレームサイズの場合、DMA転送サイズを変更せずにバーストレジスタをどのように使えるでしょうか。 TCBRは16ビットまたは8ビット単位で書くことができますか? TDBRnは16ビットまたは8ビット単位で書けますか? もしなければ、16ビットと8ビットのフレームサイズのDMAチャネルの設定方法についてヒントを教えてもらえますか? 前もって感謝します

T2080 ATMU setup for PCIe1 I have 2 T2080s attached to each other on PCIe. I have 1 setup as the RC and the other setup as the EP. I am only testing traffic (reads/writes) to the EP from the RC. When I run the test for connections between PCIe2 or PCIe4 the test functions correctly and data written to the EP is echoed back correctly on reads from the EP. The test is simply mapping to DRAM on the EP's T2080. So the ATMU registers, LAWs, TLBs are set up correctly. However, the test fails when using PCIe1. The configuration is exactly the same for all three controller setups. The SW simply is compiled to change the bus from PCIe4 to PCIe1 with appropriate memory changes to the controllers. We have a PCIe analyzer on the bus. We see the writes and reads complete as expected. But the data read back does not represent the data written in the prior step by the RC. When we break in with an emulator from the RC and examine the memory space mapped to the EP DRAM (BAR1) through the PCIe bus, it appears to be a repeating pattern. When I break in to the T2080 EP processor and examine DRAM it is unchanged from the original values written during DRAM init. What is different about PCIe1. I realize that PCIe1 supports SR-IOV, but I do not have that enabled. Re: T2080 ATMU setup for PCIe1 I ran into something similar while working through a PCIe configuration, and checking the documentation carefully made a big difference. I also compared a few hardware reference details with Pinal Assessor Portal while organizing related information for another project. Hopefully your setup goes smoothly, and I'd be interested to hear what ended up resolving the issue. Thanks for bringing up this topic. Re: T2080 ATMU setup for PCIe1 The details shared about the T2080 ATMU setup for PCIe1 provide useful information for anyone exploring hardware configuration and optimization. I found the discussion informative and more related information can be explored through Dallas Assessment Data for additional reference. Tracking configuration methods and technical updates can help improve understanding of system performance. Appreciate the insights shared here and look forward to more discussions on similar topics. Re: T2080 ATMU setup for PCIe1 The T2080 ATMU setup for PCIe1 looks like an interesting configuration topic, especially for those working with system hardware and performance tuning. It is useful to share detailed resources that help users find reliable technical and documentation related information. For additional reference I found Sedgwick Court Hearings helpful for exploring organized public information resources. Clear explanations and shared experiences can make complex setups easier for others to follow and troubleshoot. Re: T2080 ATMU setup for PCIe1 I can provide the RC and EP dumps along with the LAW registers. Do you have a specific address range you want for the PCIe interface dumps? Any hidden registers you want (I know they exist as NXP has told us to change a couple in the past). Are you asking for both the normal registers and the PCIe configuration memory space (that is a little harder to get, but I can dump the screen from Lauterbach – which is 98% correct). [NXP] Yes. We want the dumps for the normal registers and the PCIe configuration space. Do this activity for both RC and EP. You may refer to Table 2-5. CCSR Block Base Address Map from T2080RM for PCIe offset. In addition, the register dump of LAW registers is also required. I am not sure what exactly you are asking for with the PEX analyzer dumps. If you are just looking for proof that what I said is true (that reads don’t return what was written, I can show that). [NXP] We need PEX analyzer dumps in the failing scenario, i.e., when reads don’t return the written data. It would be great if you also shared analyzer dumps in the passing case to compare. Re: T2080 ATMU setup for PCIe1 I can provide the RC and EP dumps along with the LAW registers. Do you have a specific address range you want for the PCIe interface dumps? Any hidden registers you want (I know they exist as NXP has told us to change a couple in the past). Are you asking for both the normal registers and the PCIe configuration memory space (that is a little harder to get, but I can dump the screen from Lauterbach – which is 98% correct). I am not sure what exactly you are asking for with the PEX analyzer dumps. If you are just looking for proof that what I said is true (that reads don’t return what was written, I can show that). Re: T2080 ATMU setup for PCIe1 I can provide the RC and EP dumps along with the LAW registers. Do you have a specific address range you want for the PCIe interface dumps? Any hidden registers you want (I know they exist as NXP has told us to change a couple in the past). Are you asking for both the normal registers and the PCIe configuration memory space (that is a little harder to get, but I can dump the screen from Lauterbach – which is 98% correct). I am not sure what exactly you are asking for with the PEX analyzer dumps. If you are just looking for proof that what I said is true (that reads don’t return what was written, I can show that). Re: T2080 ATMU setup for PCIe1   Please provide me the register dumps for PCIe interface, both RC and EP. Provide the full console logs PEX analyser dumps   Register dump of LAW registers is also required.

imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. I am try the examples code.    mcimx93evk_ethosu_apps.  in this case,the elf would need use OCRAM (some variable is too much size). after the elf is built. I load this elf file to m33. it always failed to : remoteproc remoteproc0: Registered carveout doesn't fit da request remoteproc remoteproc0: bad phdr da 0x20480000 mem 0x60000 remoteproc remoteproc0: Failed to load program segments: -22 remoteproc remoteproc0: Boot failed: -22 maybe the memory allocat failed for conflict. why? this example code is : mcimx93evk_ethosu_apps from sdk_examples. would you please check this exsample?  i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. sdk version from nxp site is : 2.14.xx anybody success to load mcimx93evk_ethosu_apps to m33? how can i success to run mcimx93evk_ethosu_apps in m33? thanks. Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. I did not modify the ld m_ocram (RW) : ORIGIN = 0x20480000, LENGTH = 0x00060000 __attribute__((section(".bss.tensor_arena_ocram"), aligned(32))) uint8_t inferenceProcessTensorArena[TENSOR_ARENA_SIZE]; the result when I load elf to m33: remoteproc remoteproc0: bad phdr da 0x20480000 mem 0x60000

T2080 ATMU PCIe1 设置 我有两块T2080显卡通过PCIe接口连接在一起。我有一套设备作为遥控器，另一套设备作为执行遥控器。我只是在测试从 RC 到 EP 的流量（读/写）。当我运行 PCIe2 或 PCIe4 之间的连接测试时，测试功能正常，写入 EP 的数据在从 EP 读取时也能正确回显。该测试只是将数据映射到 EP 的 T2080 上的动态随机存取存储器(DRAM)。所以 ATMU 寄存器、LAW、TLB 都已正确设置。 但是，使用 PCIe1 时测试失败。三种控制器配置完全相同。该软件只需进行编译，即可将总线从 PCIe4 更改为 PCIe1，并对控制器进行相应的内存更改。我们在总线上连接了一个 PCIe 分析仪。我们看到读写操作按预期完成。但是，读取回来的数据并不代表 RC 在前一步写入的数据。当我们使用 RC 模拟器入侵并检查通过 PCIe 总线映射到 EP 动态随机存取存储器\(DRAM\) (BAR1) 的内存空间时，它似乎是一个重复的模式。当我进入 T2080 EP 处理器并检查 动态随机存取存储器(DRAM) 时，发现它与 动态随机存取存储器(DRAM) 初始化期间写入的原始值相比没有变化。PCIe1 有何不同？我知道 PCIe1 支持 SR-IOV，但我没有启用该功能。 Re: T2080 ATMU setup for PCIe1 我在配置 PCIe 时也遇到过类似的问题，仔细查阅文档起到了很大的作用。在为另一个项目整理相关信息时，我还将一些硬件参考细节与Pinal Assessor Portal进行了比较。希望你的安装过程一切顺利，我很想知道最终是什么解决了这个问题。感谢你提出这个话题。 Re: T2080 ATMU setup for PCIe1 分享的有关 PCIe1 的 T2080 ATMU 设置的详细信息，可为任何探索硬件配置和优化的人员提供有用的信息。我发现这次讨论很有启发性，更多相关信息可通过达拉斯评估数据进行参考。跟踪配置方法和技术更新有助于提高对系统性能的理解。感谢各位分享的真知灼见，期待就类似话题展开更多讨论。 Re: T2080 ATMU setup for PCIe1 T2080 ATMU PCIe1 的配置看起来是一个有趣的配置话题，特别是对于那些从事系统硬件和性能调优工作的人来说。分享详细的资源有助于用户找到可靠的技术和文档相关信息。另外，我发现Sedgwick Court Hearings为探索有组织的公共信息资源提供了有用的参考资料。清晰的解释和经验分享可以让其他人更容易理解和排除复杂的故障。 Re: T2080 ATMU setup for PCIe1 我可以提供 RC 和 EP 转储以及 LAW 寄存器。您对 PCIe 接口转储有特定的地址范围要求吗？您需要哪些隐藏寄存器（我知道它们存在，因为 NXP 之前要求我们修改过几个）？您是需要常规寄存器还是 PCIe 配置内存空间（这部分比较难获取，但我可以提供 Lauterbach 的屏幕截图——准确率高达 98%）？ [NXP] 是的。我们需要普通寄存器和 PCIe 配置空间的转储数据。请对 RC 和 EP 都执行此操作。您可以参考 T2080RM 中的表 2-5“CCSR 块基址映射”来获取 PCIe 偏移量。此外，还需要 LAW 寄存器的转储数据。 我不确定你具体想从 PEX 分析器转储文件中获取什么信息。如果你只是想证明我所说的是正确的（读取操作不会返回写入的内容，我可以证明这一点）。 [NXP] 我们需要故障情况下的 PEX 分析器转储文件，即读取操作未返回写入数据的情况。如果也能分享成功情况下的分析器转储文件以便对比，那就更好了。 Re: T2080 ATMU setup for PCIe1 我可以提供 RC 和 EP 转储以及 LAW 寄存器。您对 PCIe 接口转储文件有特定的地址范围要求吗？任何你想要的隐藏寄存器（我知道它们存在，因为 NXP 过去曾要求我们更改几个）。您是想要获取普通寄存器和 PCIe 配置内存空间吗？（这有点难获取，但我可以从 Lauterbach 导出屏幕截图——准确率达 98%） 我不太明白您具体需要 PEX 分析器转储文件是什么。如果你只是想寻找证据来证明我所说的是正确的（读取操作不会返回所写的内容，我可以证明这一点）。 Re: T2080 ATMU setup for PCIe1 我可以提供 RC 和 EP 转储以及 LAW 寄存器。您对 PCIe 接口转储文件有特定的地址范围要求吗？任何你想要的隐藏寄存器（我知道它们存在，因为 NXP 过去曾要求我们更改几个）。您是想要获取普通寄存器和 PCIe 配置内存空间吗？（这有点难获取，但我可以从 Lauterbach 导出屏幕截图——准确率达 98%） 我不太明白您具体需要 PEX 分析器转储文件是什么。如果你只是想寻找证据来证明我所说的是正确的（读取操作不会返回所写的内容，我可以证明这一点）。 Re: T2080 ATMU setup for PCIe1   请提供 PCIe 接口的寄存器转储文件，包括 RC 和 EP。 请提供完整的控制台日志 PEX 分析器转储   还需要提供 LAW 寄存器的转储文件。

mcimx93evk_ethosu_apps.elf に OCRAM が必要な場合、imx93 は mcimx93evk_ethosu_apps.elf の読み込みに失敗しました。 サンプルコードを試しています。 mcimx93evk_ethosu_apps。 この場合、エルフはOCRAMを使う必要があります(変数が大きすぎると言われます)。 エルフが完成した後。私はこのelfファイルをm33にロードします。 それは常に失敗した： remoteproc remoteproc0: 登録されたカーブアウトが要求に適合しません remoteproc remoteproc0: 不良なphdr da 0x20480000 mem 0x60000 remoteproc remoteproc0: プログラムセグメントの読み込みに失敗しました: -22 remoteproc remoteproc0: ブート失敗: -22 メモリ割り当てが競合により失敗した可能性があります。 なぜ？ このサンプルコードは次のとおりです。 sdk_examples の mcimx93evk_ethosu_apps。このサンプルを確認していただけますか？ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. NXPサイトからのSDKバージョンは以下の通りです: 2.14.xx M33にmcimx93evk_ethosu_appsをロードできた人はいますか? M33でmcimx93evk_ethosu_appsをうまく動かすにはどうすればいいですか? ありがとうございます。 Re: imx93 failed to load mcimx93evk_ethosu_apps.elf if mcimx93evk_ethosu_apps.elf need OCRAM. 私はldを修正しませんでした m_ocram (RW) : ORIGIN = 0x20480000、LENGTH = 0x00060000 __attribute__ ((section(".bss.tensor_arena_ocram")、aligned(32))) uint8_t inferenceProcessTensorArena[TENSOR_ARENA_SIZE]; elfをm33にロードした結果： remoteproc remoteproc0: 不良なphdr da 0x20480000 mem 0x60000

使用突发寄存器的SPI传输 您好，NXP， 目标微控制器：S32K388 我正在使用突发寄存器 TCBR 和 TDBR0-127 进行 eDMA SPI 传输。 当前帧大小为 32 位，一切运行正常 对于小于 32 位的 SPI 帧大小，如何在不改变 DMA 传输大小的情况下使用突发寄存器？ TCBR 可以用 16 位或 8 位单位写入吗？ TDBRn 可以用 16 位还是 8 位单位写入？ 如果不行，能否提供一些关于如何设置帧大小为 16 位和 8 位的 DMA 通道的提示？ 提前致谢

Spi transmission using burst registers Hello NXP, Target uC : S32K388 I am using the burst registers TCBR and TDBR0-127 for SPI transmissions using eDMA. Current frame size is 32 bits and everything works as expected Now for an SPI frame size which is less than 32 bits, how can the burst registers be used without changing the dma transfer size, in between. Can TCBR be written in 16 or 8 bit units. Can TDBRn be written in 16 or 8 bit units If not, could you give hints as to how to setup the dma channel for frame sizes 16 and 8 bits. Thanks in advance 

iw612 setup mfg mode on i.mxrt1060evkc This document takes i.MXRT 1060 evkc and iw610 M.2 module as example to share how to setup manufactory mode in i.MXRT platform for NXP wifi product.  Hardware Host platform: i.MXRT 1060 evkc Wi-Fi chip: iw610 M.2 evk Software RT1060EVKC SDK 25.12.00 MFG TOOL: MFG-SD-IW610-MF-LABTOOL-Native-BRG-WIN-X86-2.0.0.39.0-18.80.5.p77

i.MX8のAndroidデバイスでIPTV再生パフォーマンスを最適化するにはどうすればいいですか? こんにちは、みんな、 現在、i.MX8プラットフォームをベースにAndroidデバイスでIPTV再生を評価しており、コミュニティの経験から学びたいと思っています。 テスト中に、再生品質は以下のようないくつかの要因によって変動することに気づきました: ハードウェアビデオデコード構成 ネットワークの安定性(イーサネット対Wi-Fi) ライブHLSストリームのバッファサイズ ExoPlayerまたはVLCの設定 再生中のCPUとメモリの使用状況 i.MX プロセッサを扱う方にお聞きしたいのですが、ライブTVストリーミングで最も安定した結果をもたらした設定や最適化は何ですか? 具体的には、以下の点に興味があります。 ExoPlayerの推奨バッファ設定 ハードウェアデコーダーのベストプラクティス ライブイベント中のバッファリングを減らすためのヒント Android TVデバイス向けのパフォーマンスチューニング ネットワークのトラブルシューティング方法 実際の使用経験や、再生安定性を向上させるための推奨事項などをお聞かせいただければ幸いです。 ご回答をお待ちしています。

如何评价基于NXP i.MX处理器的Android TV设备上的IPTV服务质量？ 大家好， 我目前正在评估搭载 NXP i.MX 处理器的 Android TV 设备上的 IPTV 播放性能。我不想仅仅根据频道数量来比较服务提供商，我更感兴趣的是影响播放质量的技术方面。 我正在测试的一些指标包括： 高峰观看时段的视频流稳定性 硬件视频解码性能 HLS 和 MPEG-TS 兼容性 通道切换延迟 缓冲区管理 EPG加载性能 以太网与 Wi-Fi 的可靠性比较 对于任何使用 Android TV 或嵌入式多媒体系统的人来说，在评估流媒体服务时，您认为最重要的标准是什么？ 作为我研究的一部分，我最近写了一篇文章，讨论了美国、加拿大和英国用户在选择 IPTV 提供商时需要考虑的因素。它侧重于技术评估，而不是市场营销。如果有人感兴趣，这篇文章可以在Medium上找到。 我也很想了解您在 i.MX 平台上使用 ExoPlayer、VLC 或其他播放框架的体验。 谢谢！

DPAA2イーサネット・スイッチ(dpsw)はパケットを受信ポートに送ります DPAA2のLX2160プロセッサ搭載のイーサネット・スイッチ(DPSW)で問題や制限に直面しました。 dpsw は、パケットの宛先 MAC が既にそのポートで学習されている場合 (つまり、宛先 MAC がそのポートの FDB に登録されている場合) に、そのパケットを受信ポートに返送します。 これにより、スイッチがCiscoのイーサネット・スイッチに接続されている場合に問題が生じます。Cisco イーサネット・スイッチ CDPは、同じ送信元と宛先MACでパケットを送信することでループバックテストを行うためです。DPSWはCisco Switchがポートをシャットダウンさせます。 NXP社が提案している回避策があります。各ポートのFDBに登録されているMACアドレスをスキャンし、それらをACLに追加して、受信ポートへの送信をブロックするスクリプトを作成してください。 例えば、eth2 の問題を修正する必要がある場合は、次のスクリプトを使用します。 tc qdisc add dev eth2 clsact dest=`bridge fdb show | grep -i eth2 | grep -i self | awk  '{print substr($1,0,17)}'` for dmac in $dest; do tc filter add dev eth2 ingress flower dst_mac $dmac skip_sw action drop done コマンドの機能： - qdiscを作成します（ACLについては、お送りしたリンクを参照してください）。 - ブリッジFDBをダンプし、宛先ポートがeth2で、かつタイプが「self」であるすべてのエントリを表示します。 ダンプの結果はawkに渡され、FDBからdmacのみを出力します。 例: 00:04:9f:05:c3:c8 00:04:9f:05:c3:c9 00:04:9f:05:85:b2 -結果をdestに保存します。- dest を反復処理し、dest 内の各 MAC に対してイングレスに ACL フィルタを追加します。 eth2で受信されるすべてのフローのうち、上記の範囲内のdmacを持つものは、作成されたACLルールによって破棄されます。 しかし、この回避策は場当たり的なやり方のように思える。いくつか問題点があります。 - MACが学習されACLに割り当てられる間には小さなウィンドウが存在し、パケットが受信ポートにループバックされる可能性があります。 - また、デバイスが移動しても、ACL内のMACアドレスは削除されません。移動したデバイスは現在アクセスできない可能性があります。 - 継続的な走査、ACLへの追加およびACLプロセッシングによるパフォーマンスへの影響。 私の質問：これに対処するもっと良い方法はありますか？ Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port 「もしかしたら」この方法が効果的か、役立つかもしれませんか?内容を確認し、動作するか、あるいは理にかなっているかどうかについてフィードバックをお願いします。 -------------------------------------------------------------------------------------------------- DPSWポートに受信するeth型ループバック検出フレーム0x9000ドロップするための代替サンプル方法 ---------------------------------------------------------------------------------------------- 例えば、ループバック検出フレーム（ethタイプ0x9000）パケットがeth5 dpswポート経由で受信されている場合（そして、例えばdpmac-18がこのdpswポートにリンクされている場合）、 その場合、汎用的なethタイプ0x9000フレーム（MACアドレスに関係なく）を破棄することで、ハードウェアオフロードルールを実行する方がより良い選択肢となるでしょう。 1. 一時的または既存の設定をすべて削除します。 tc qdisc del dev eth5 clsact 2>/dev/null tc qdisc add dev eth5 clsact 2. 厳格なハードウェアオフロードのドロップルールを適用する tc filter add dev eth5 ingress protocol 0x9000 flower skip_sw action drop ---------------------- 3. ステータスチェック： tc -s filter show dev eth5 ingress restool dpsw info dpsw.0 | grep -A 10 "dpmac.18"| grep "fltr_frame" または while :; do restool dpsw info dpsw.0 | grep -A 10 "dpmac.18"| grep "fltr_frame"; sleep 1; done Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port 簡単に言えば、お客様に実装を提供する可能性は非常に低いです: -ハードウェアはソースポートのプリミュニングをサポートしておらず、その機能を実現するにはファームウェアも大幅な変更が必要です(実現可能かどうかも不明です)。なぜなら、プリンを自律的にエミュレートする方法が不可能なからです。 Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port AEチームと話し合っています。

NXP i.MX プロセッサベースのAndroid TVデバイスでのIPTVサービス品質はどのように評価しますか? こんにちは、みんな、 現在、NXP i.MX プロセッサを搭載したAndroid TVデバイスでのIPTV再生性能を評価しています。チャネル数だけでプロバイダを比較するのではなく、再生品質に影響を与える技術的な側面に興味があります。 私がテストしている指標には以下のようなものがあります。 ピーク視聴時間帯のストリームの安定性 ハードウェアビデオデコード性能 HLSおよびMPEG-TSとの互換性 チャネル切り替えレイテンシ バッファ マネジメント EPG読み込みパフォーマンス イーサネットとWi-Fiの信頼性の比較 Android TVや組み込みマルチメディアシステムに取り組んでいる方へ、ストリーミングサービスを評価する際に最も重要な基準は何だと考えますか? 私の調査の一環として、最近、米国、カナダ、英国のユーザーがIPTVプロバイダーを選ぶ際に考慮すべき要素について論じた記事を書きました。マーケティングよりも技術評価に重点を置いている。興味のある方は、 Mediumに掲載されている記事をご覧ください。 また、i.MX プラットフォームでのExoPlayerやVLC、その他の再生フレームワークの経験もぜひ聞かせてください。 ご回答をお待ちしています。

DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port I encountered a problem or limitation with their Ethernet Switch (dpsw) in the DPAA2 with LX2160 processor. dpsw sends a packet back to its incoming port if the destination MAC of the packet is already learned on that port (i.e., the destination MAC is in FDB on that port). This creates a problem when the switch is connected to a Cisco Ethernet Switch. Because Cisco Ethernet Switch CDP will perform loopback test by sending packets with the same source and destination MAC. dpsw will cause Cisco Switch shutting down the port. There is a workaround suggested by NXP. Write a script that scans the MAC addresses in FDB on each port, and add them to ACL to block them sending back to incoming port. For example, if I need to fix the problem on eth2, use the following script tc qdisc add dev eth2 clsact dest=`bridge fdb show | grep -i eth2 | grep -i self | awk  '{print substr($1,0,17)}'` for dmac in $dest; do tc filter add dev eth2 ingress flower dst_mac $dmac skip_sw action drop done What commands do:  - create a qdisc (see the link I sent you with the ACLs)  - dump the bridge FDB and display all the entries with dest port eth2 that also are of type "self" The result of the dump is passed to awk that will print only the dmacs from the FDB: e.g.: 00:04:9f:05:c3:c8 00:04:9f:05:c3:c9 00:04:9f:05:85:b2 -save the result in dest. -iterate in dest and add ACL filter on ingress for each mac in dest. All the flows that will be received on  eth2  and will have a dmac in the above range will be dropped by the ACL rules created. But this workaround seems kluge.  Here are some issues.  - There is still a small window (between MAC is learned and MAC is placed on ACL), packets still could loopback to incoming port.  - Also when device moves, the MAC in the ACL will not be removed. The moved device may not be reachable now.  - The performance impact with constant scanning, adding to ACL and processing ACL. My question: Are there any better ways to handle this? Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port "Maybe" this below method would work/help? Please check it and provide feedback whether it works or makes sense: -------------------------------------------------------------------------------------------------- Alternate sample method to drop 0x9000 eth-type loopback-detection frames inbound on dpsw ports ---------------------------------------------------------------------------------------------- say if the loopback-detection frames (eth-type 0x9000) packets are coming in through eth5 dpsw-port (and for example if dpmac-18 is linked to this dpsw-port), then running the hardware-offloaded rule would be better option by dropping the generic eth-type 0x9000 frames (irrespective of the mac-addresses) 1. Clean up any temporary/existing configuration tc qdisc del dev eth5 clsact 2>/dev/null tc qdisc add dev eth5 clsact 2. Apply the strict hardware-offload drop rule tc filter add dev eth5 ingress protocol 0x9000 flower skip_sw action drop ---------------------- 3. Status checks: tc -s filter show dev eth5 ingress restool dpsw info dpsw.0 | grep -A 10 "dpmac.18" | grep "fltr_frame" OR while :; do restool dpsw info dpsw.0 | grep -A 10 "dpmac.18" | grep "fltr_frame"; sleep 1; done Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port The short answer is that it is very unlikely to provide an implementation for the customer: -hardware does not support source port pruning and the firmware requires significant changes (not even sure if it's feasible) for such a feature as there is no possibility to emulate the  pruning in an autonomous way. Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port Discussing with the AE team.

製造中止部品の代替品に関するお問い合わせ：FXTH8709116T1 こんにちは、その部分が見えました FXTH8709116T1 は廃盤となりました。このモデルに適した交換部品をおすすめしてもらえますか?ありがとうございます! インテリジェント・センシング・フレームワーク センサ・フュージョン Re: Replacement Inquiry for Discontinued Part: FXTH8709116T1 こんにちは、 FXTH8709116T1 NXPの FXTH87ファミリー のタイヤ空気圧監視センサ \(TPMS）に属しています。このファミリは公式に生産 終了 (製造停止)となっています。 公式推奨交換部品 NXPは、すべての新しい設計に対して NTM88ファミリ への移行を公式に推奨しています。 公式声明:「 NTM88はFXTH87ファミリが生産終了となったため、新しいデザインの推奨ファミリです。」 移行ガイド： AN12524 – FXTH87/87EからNTM88への移行 主要仕様の比較と推奨事項 品番 FXTH8709116T1 (オリジナル) 推奨 NTM88 取扱説明書 圧力範囲 約100～900 kPa NTM88Hシリーズ（90～930 kPa） 最も近い一致 加速度センサ 二軸（X軸＋Z軸） デュアル軸（XZ）対応 マッチングオプションあり パッケージ 7 × 7 mm QFN 4×4mm QFN ピン互換性なし - 基板の再設計が必要 MCU+RF 統合8ビットMCU+RF 統合8ビットMCU+RF 機能的に同等 ステータス 製造中止 アクティブ版（末尾に「S」が付いているバージョンを使用） -     推奨される出発点（最終的な選択は、お客様の具体的なご要望によって異なります）： NTM88H125Sまたは90～930 kPa範囲の類似の二軸バリアント 代替案：NTM88Jシリーズ（より高い圧力範囲、例：90～1110 kPa） 重要な注意事項 ドロップインやピン・トゥ・ピンの交換ではありません パッケージサイズは7×7 mmから4×4 mmに変更されたため、PCBの再設計が必須となっています。 ファームウェア/ソフトウェア移行が必要です 詳細な移行ガイダンスについては、NXPのアプリケーションノート AN12524 を参照してください。ファームウェアとライブラリの機能は異なります。 短期的な生産に関するアドバイス もし生産のためにオリジナル部品が必要な場合は、できるだけ早く代理店やグレーマーケットで残FXTH8709116T1存在庫を確認してください。 長期生産にはNTM88ファミリーに移行する必要があります。 WeChat:+85259975614で連絡できます。彼らは残りの在庫を、COC証明書とともにまとめて売り払っている。 Re: Replacement Inquiry for Discontinued Part: FXTH8709116T1 すみません、あなたの製品がSTマイクロエレクトロニクスに移管されたことを見落としていました。直接連絡します。 Inquiry about NTM88H distributor ご返信いただき、誠にありがとうございます。まず、この部品の特性を評価したいと思います。サンプル検査が成功したら、代理店に連絡します。あるいは、適切な代理店をおすすめしてもらえますか? Re: Replacement Inquiry for Discontinued Part: FXTH8709116T1 こんにちは、 このFXTH8709116T1とFXTH87 TPMSファミリ全体が生産終了であることは確認できます。新設計の推奨代替ファミリはNTM88です。 現在のデバイス(100–900 kPa圧力範囲、XZ二軸加速度センサ)に合わせるために、対応するNTM88バリアントは930 kPaの範囲とXZ軸オプションを持つNTM88Hシリーズです。 移行をサポートするために、専用の移行アプリケーションノートがあります:AN12524 – FXTH87/87EからNTM88への移行。このANは、既存のFXTH87/87E設計をNTM88ファミリに適応させるのに役立つリソースです。 重要な点として、2026年2月2日現在、当社のMEMSセンサー製品(TPMSポートフォリオを含む)はSTMicroelectronicsに移行されました。製品の入手状況、サンプル、さらなる設計サポートについては、STMicroelectronicsに直接お問い合わせください。 BRs、トーマス

DPAA2 以太网交换机 (dpsw) 将数据包发送回入端口 我在使用配备 LX2160 处理器的 DPAA2 时，遇到了以太网交换机 (dpsw) 的问题或限制。 如果数据包的目标 MAC 已在该端口上学习到（即，目标 MAC 在该端口的 FDB 中），则 dpsw 会将数据包发送回其传入端口。 当交换机连接到思科以太网交换机时，就会出现问题。因为思科以太网交换机 CDP 将通过发送源 MAC 地址和目标 MAC 地址相同的包来执行环回测试。dpsw 会导致思科交换机关闭端口。 NXP 提出了一种变通方法。编写一个脚本，扫描每个端口上 FDB 中的 MAC 地址，并将它们添加到 ACL 中，以阻止它们向传入端口发送数据。 例如，如果我需要修复 eth2 上的问题，请使用以下脚本 tc qdisc add dev eth2 clsact dest=`bridge fdb show | grep -i eth2 | grep -i self | awk  '{print substr($1,0,17)}'` for dmac in $dest; do tc filter add dev eth2 ingress flower dst_mac $dmac skip_sw action drop done 命令的作用： - 创建一个 qdisc（请参阅我发给你的包含 ACL 的链接） - 导出桥接 FDB 并显示所有目标端口为 eth2 且类型为“self”的条目 转储结果将传递给 awk，awk 将仅打印 FDB 中的 dmacs： 例如： 00:04:9f:05:c3:c8 00:04:9f:05:c3:c9 00:04:9f:05:85:b2 -将结果保存到目标位置。-遍历目标地址，并为目标地址中的每个 MAC 地址添加入口 ACL 过滤器。 所有在 eth2 上接收且 DMAC 在上述范围内的流都将被创建的 ACL 规则丢弃。 但这种变通方法似乎不太妥当。以下是一些问题。 - 在 MAC 地址被学习到和 MAC 地址被添加到 ACL 之间仍然存在一个很小的时间窗口，数据包仍然可能环回到入端口。 - 此外，当设备移动时，ACL 中的 MAC 地址不会被删除。已移动的设备现在可能无法访问。 - 不断扫描、添加到 ACL 和处理 ACL 对性能的影响。 我的问题是：有没有更好的处理方法？ Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port 或许以下方法会有效/有帮助？请检查一下，并提供反馈意见，看看它是否有效或合理： -------------------------------------------------------------------------------------------------- 另一种采样方法，用于丢弃 dpsw 端口上入站的 0x9000 eth 类型环回检测帧。 ---------------------------------------------------------------------------------------------- 假设环回检测帧（eth 类型 0x9000）数据包通过 eth5 dpsw 端口进入（例如，如果 dpmac-18 链接到此 dpsw 端口）， 那么，运行硬件卸载规则会是更好的选择，方法是丢弃通用的以太网类型 0x9000 帧（无论 MAC 地址如何）。 1. 清理所有临时/现有配置 tc qdisc del dev eth5 clsact 2>/dev/null tc qdisc 添加设备 eth5 clsact 2. 应用严格的硬件卸载丢弃规则 tc filter add dev eth5 ingress protocol 0x9000 flower skip_sw action drop ---------------------- 3. 状态检查： tc -s filter show dev eth5 ingress restool dpsw info dpsw.0 | grep -A 10 "dpmac.18"| grep "fltr_frame" 或者 while :; do restool dpsw info dpsw.0 | grep -A 10 "dpmac.18"| grep "fltr_frame"; sleep 1; done Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port 简而言之，不太可能为客户提供实施方案： -硬件不支持源端口修剪，固件需要进行重大更改（甚至不确定是否可行）才能实现此功能，因为无法以自主方式模拟修剪。 Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port 与AE团队讨论。

Replacement Inquiry for Discontinued Part: FXTH8709116T1 Hi, I see that the part FXTH8709116T1 has been discontinued. Could you please recommend a suitable replacement part for this model? Thanks! Intelligent Sensing Framework SensorFusion Re: Replacement Inquiry for Discontinued Part: FXTH8709116T1 Hello, FXTH8709116T1 belongs to NXP’s FXTH87 family of Tire Pressure Monitoring Sensors (TPMS). This entire family has been officially discontinued (No Longer Manufactured). Official Recommended Replacement NXP officially recommends migrating to the NTM88 family for all new designs. Official statement: “NTM88 is the recommended family for new designs as the FXTH87 family is discontinued.” Migration guide: AN12524 – Migration from FXTH87/87E to NTM88 Key Specification Comparison & Recommendation Item FXTH8709116T1 (Original) Recommended NTM88 Direction Notes Pressure Range Approx. 100–900 kPa NTM88H series (90–930 kPa) Closest match Accelerometer Dual-axis (X + Z) Dual-axis (XZ) supported Matching options available Package 7 × 7 mm QFN 4 × 4 mm QFN Not pin-compatible – board redesign required MCU + RF Integrated 8-bit MCU + RF Integrated 8-bit MCU + RF Functionally equivalent Status Discontinued Active (use “S” suffix versions) -     Recommended starting points (final selection depends on your exact requirements): NTM88H125S or similar dual-axis variants in the 90–930 kPa range Alternative: NTM88J series (higher pressure range, e.g. 90–1110 kPa) Important Notes Not a drop-in / pin-to-pin replacement The package size has changed from 7×7 mm to 4×4 mm, so a PCB redesign is mandatory. Firmware / software migration required Please refer to NXP’s application note AN12524 for detailed migration guidance. Firmware and library functions differ. Short-term production advice If you still need the original part for ongoing production, check remaining stock of FXTH8709116T1 through distributors or the gray market as soon as possible. For long-term production, you must transition to the NTM88 family. You can contact them via wechat:+85259975614. They are selling off their remaining inventory in bulk, along with COC certificates. Inquiry about NTM88H distributor Thank you very much for your reply. I would like to first evaluate the characteristics of this component. If the sample testing is successful, I will reach out to your distributor. Alternatively, could you recommend a suitable distributor? Re: Replacement Inquiry for Discontinued Part: FXTH8709116T1 Apologies, I missed the fact that your products have been transferred to STMicroelectronics,I will reach out to them directly。 Re: Replacement Inquiry for Discontinued Part: FXTH8709116T1 Hi, I can confirm that the FXTH8709116T1, along with the entire FXTH87 TPMS family, has been discontinued. The recommended replacement family for new designs is the NTM88. To match your current device (100–900 kPa pressure range, XZ dual-axis accelerometer), the corresponding NTM88 variant with the 930 kPa range and XZ-axis option is indeed the NTM88H series. To support the transition, there is available a dedicated migration application note: AN12524 – Migration from FXTH87/87E to NTM88. This AN is a helpful resource for adapting your existing FXTH87/87E design to the NTM88 family. One important note: as of February 2, 2026, our MEMS sensor products (including the TPMS portfolio) have been transitioned to STMicroelectronics. For product availability, samples, and further design support, please contact STMicroelectronics directly. BRs, Tomas

How do you evaluate IPTV service quality on Android TV devices based on NXP i.MX processors? Hello everyone, I'm currently evaluating IPTV playback performance on Android TV devices powered by NXP i.MX processors. Rather than comparing providers based only on channel count, I'm interested in the technical aspects that affect playback quality. Some of the metrics I'm testing include: Stream stability during peak viewing hours Hardware video decoding performance HLS and MPEG-TS compatibility Channel switching latency Buffer management EPG loading performance Ethernet versus Wi-Fi reliability For anyone working with Android TV or embedded multimedia systems, what criteria do you consider most important when evaluating a streaming service? As part of my research, I recently wrote an article discussing the factors to consider when choosing an IPTV provider for users in the USA, Canada, and the UK. It focuses on technical evaluation rather than marketing. If anyone is interested, the article is available on Medium. I'd also appreciate hearing about your experiences with ExoPlayer, VLC, or other playback frameworks on i.MX platforms. Thank you!