レガシーソフトウェアライセンス Codewarrior 10.4.1 こんにちは、 2026年現在、Power Quicc IIIのような旧型デバイスで、無料ライセンスを使ってCodeWarrior 10.4.1を使用する方法はありますか？ Re: Legacy Software License Codewarrior 10.4.1 こんにちは、 PowerQUICC IIIをサポートするツール(例:MPC85xxファミリー)のためのCodeWarrior for Power Architectureには無料または特別版はありません。 PowerQUICC IIIデバイス(MPC8540、MPC8548、MPC8560、MPC8572など)は CodeWarrior Development Studio for Power Architecture v10.xでサポートされており、 有料ライセンス (Basic、Standard、またはProfessionalスイート)が必要です。 NXPを通じて利用できる有料オプションは以下のとおりです。 CW開発スイート – Basic – 最下位クラスで、Power Architecture(Eclipse、Windows、Linuxホスト)を含みますが、コードやデータサイズの制限がある場合があります。 CW開発スイート – プロフェッショナル – フル機能でサイズ制限なし、ClassicおよびEclipse IDEs、LinuxおよびWindowsを含みます。 ネットワークアプリケーション向けCW開発スイート – 特にPowerQUICC I/II/II Pro/III、QorIQ P/Tシリーズ、Layerscapeを対象としています。   よろしくお願いします。

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 

Methods to update NBU firmware on KW47 and MCX W72 This post provides guidance on how to update the NBU firmware on MCX W72 and KW47 devices through several methods: Bootloader Host Application (blhost), Secure Provisioning Tool, LinkServer. The Narrow Band Unit (NBU) is a dedicated compute subsystem for the Narrowband Radio, present in select NXP wireless microcontrollers. It is comprised of an Arm® Cortex®-M33 and associated peripherals that, in conjunction with the Bluetooth Unit, support the Bluetooth LE protocol. Running at 96 MHz alongside a 2.4 GHz transceiver, the NBU operates independently from the main application core, offloading all radio processing from the primary CPU and freeing it for application tasks. While the NBU allows for flexibility for evolving requirements, firmware to implement radio protocols is intended to be developed and delivered by NXP. Note: It is important that the NBU firmware version matches the SDK version of the application. After downloading the SDK and before running any wireless examples, update the NBU firmware using the binaries provided in the SDK folder. The NBU binary file is located in the SDK folder. Go to the SDK root folder and open the path: path_to_SDK\mcuxsdk\middleware\wireless\ble_controller\bin Prerequisites To follow this guide, the following environment is required: Software Setup Bootloader Host Application (blhost). Download here. MCUXpresso Secure Provisioning Tool. Download here. LinkServer for Microcontrollers. Download here. Hardware Setup Development boards associated with the MCX W72 or KW47 microcontroller families may be used. The ISP button varies by board and is referred to as ISP_button  throughout this guide: Development board ISP_button FRDM-MCXW72 SW3 MCXW72-LOC SW4 KW47-EVK SW4 KW47-LOC SW4 To set the board to the Bootloader ISP mode, press and hold the ISP_button , connect the development board via the MCU-Link connector to the PC, then release ISP_button . Bootloader Host Application (blhost) Place the board in ISP mode by pressing and holding ISP_button . Connect the USB cable to the MCU-Link connector and release ISP_button after the connection is established. Verify the COM port assigned to the board by opening Device Manager in Windows and searching for Ports (COM & LPT). Identify and note the corresponding COM port number. Open a command prompt and change the directory to the location of the blhost.exe file: (BLHost_root_location)\blhost_2.6.7\bin\win Verify communication by running the following command, making sure to replace COMX with the COM port assigned to your device: blhost.exe -p COMX get-property 1 Update the NBU firmware image. First, erase the NBU memory: blhost.exe -p COMX flash-erase-all 2 Write the new firmware image using the following command. The write-memory command uses 0x48800000 as the start address, which corresponds to the NBU memory base. Provide the full path to the binary file, or alternatively, copy the .bin file into the same directory as blhost.exe to simplify the command: blhost.exe -p COMX write-memory 0x48800000 .bin MCUXpresso Secure Provisioning Tool Create a workspace for the device. To use the keys same as the development board, select the processor relevant to the FRDM/EVK board. Place the board in ISP mode by pressing and holding ISP_button . Connect the USB cable to the MCU-Link connector and release ISP_button after the connection is established. To verify communication, click the UART tab, refresh the Port field selection and select the assigned COM Port identified. Click Test connection and confirm that the result displays OK. In the toolbar, select the boot type as Plain unsigned or Plain with CRC. In the Build Image view, load the binary file in Source executable image, enter the start address as  0x48800000  (which corresponds to the NBU memory base), and click Build image. Navigate to the Write Image view, select Use built image, and click Write image. A success message appears when the NBU firmware loading is complete. LinkFlash Tool For this method, a LinkServer debug probe must be available on the board. The steps on how to install the CMSIS-DAP/SEGGER J-link firmware are available here. Navigate to the main LinkServer folder in your computer and execute the  LinkFlash.exe  file. Place the board in ISP mode by pressing and holding ISP_button . Connect the USB cable to the MCU-Link connector and release ISP_button after the connection is established. In the LinkFlash tool, after the device is connected, click the Refresh button to update and set the probe target of the board. Go to the Program tab, click Browse, select the NBU firmware file, and enter the start address  0x48800000 . Ensure to check the boxes Mass erase before programming and Reset target after programming. To load the NBU firmware, click Program.

T1042 LAW 与 CCSR 内存映射对比 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我试图理解 LAW& CCSR 的概念，以及 LAW 和 CCSR 内存映射之间的区别，但在阅读 T1040 RM 后，我无法澄清自己的观点。例如，T1040 RM 中的表 2-3（LAWs 内存映射）显示 IFC 映射到地址 0x80000000，而表 2-5（CCSR 内存映射）显示 IFC 位于 0xFF124000。 有人能澄清一下司机实际使用哪些地址（LAW 或 CCSR）来访问设备吗。 QorIQ T1 设备 Re: T1042 LAW vs CCSR Memory Maps 这是一个非常有趣的问题，你所指出的区别一开始肯定会让人感到困惑。根据我的了解，驱动程序在与硬件模块交互时通常依赖CCSR视图，而LAWs则在更高层次上描述这些区域是如何转换的。我在查阅蒙哥马利郡法院 时发现了一些有用的背景资料，其中解释了不同的映射如何可以共存，以实现不同的访问目的。将 LAW 视为翻译规则，而将 CCSR 视为实际使用的寄存器访问视图，可能会有所帮助。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 这些是各自的 FCM（闪存控制机器）控制器使用的基地址。例如 与非 使用 SRAM 作为缓冲区，使用 0xFF800000 你可以达到这个缓冲区。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 感谢亚历山大-雅科夫列夫。从理论上讲，我已经理解了其中的区别，但是以下 T1042D4RDB 板的设备树片段中提到的是，IFC 控制器（本地总线）是 @ 0xFFE124000（CCSR 内存映射）。而地址映射属性 “ranges” 提到了来自 LAW 地址空间的父地址（在 u-boot 的定律中，地址 0xfe8000000、0xfff800000、0xfffdf0000 设置为 或非、与非 和 cpld。文件) localbus@ffe124000 {         reg = <0xf 0xfe124000 0x0 0x2000>;         ranges = <0x0 0x0 0xf 0xe8000000 0x8000000 0x2 0x0 0xf 0xff800000 0x10000 0x3 0x0 0xf 0xffdf0000 0x8000>;         #address-cells = <0x2>;         #size-cells = <0x1>;         compatible = "fsl,ifc", "simple-bus";         interrupts = <0x19 0x2 0x0 0x0>;         nor@0,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "cfi-flash";             reg = <0x0 0x0 0x8000000>;             bank-width = <0x2>;             device-width = <0x1>;         };         nand@2,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "fsl,ifc-nand";             reg = <0x2 0x0 0x10000>;         };         cpld@3,0 {             compatible = "fsl,t1040d4rdb-cpld", "fsl,deepsleep-cpld";             reg = <0x3 0x0 0x300>;         };     }; 我希望你能理解我的困惑所在。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本地访问窗口（LAW）用于配置处理器地址空间如何映射到目标接口--DDR 控制器、IFC 控制器、PCI-E 等。 CCSR 空间是处理器内部内存映射寄存器映射到地址空间的空间。 表 2-3 将 IFC 显示为 " 目标 "-可通过此窗口访问连接到 IFC 控制器的目标设备。 表 2-5 列出了与 IFC 相关的内存映射寄存器，即用于配置 IFC 控制器的寄存器。 祝您愉快！ Alexander TIC ----------------------------------------------------------------------------------------------------------------------- 注：如果本帖回答了您的问题，请点击正确答案按钮。Thank you! ----------------------------------------------------------------------------------------------------------------------- Re: T1042 LAW vs CCSR Memory Maps T1042 LAW 和 CCSR 内存映射之间的区别很有意思，尤其是在研究内存区域的组织和访问方式时。清晰的地址范围文档可以大大简化技术比较。我还发现，查阅结构化的格林维尔县记录可以很好地说明组织化的信息如何支持高效的研究。总而言之，对于任何从事内存映射概念研究的人来说，这都是一个很有帮助的主题。

MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremetal S Hi,I am using the FLASH_ECC_Error_Injection_MPC5744P demo project from SDK 2.1 to test FLASH ECC fault handling. In the bare-metal SDK example:After calling Generate_noncorrectable_FLASH_ECC_error, the core properly traps the fault and enters Machine_check_handler (IVOR1 Handler) as expected. After porting the identical ECC injection logic to my RTOS-based project:No machine check exception occurs, and the code never jumps into Machine_check_handler. I have already completed the following porting & configuration steps: Fully ported and defined IVOR1_Handler in the startup .s assembly file, consistent with the bare-metal demo; Full FCCU alarm interrupt configuration is implemented, but no FCCU alarm interrupt is triggered either when injecting the uncorrectable FLASH ECC error. I have 3 core questions to troubleshoot this issue: What mandatory hardware/register configurations are required to enable entry to the Machine Check Handler (IVOR1) for FLASH uncorrectable ECC errors? Are there special considerations or constraints when running ECC fault injection and machine check exception handling under an RTOS? Could you provide a step-by-step debug/troubleshooting workflow to locate the root cause of this missing machine check exception? Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet I don't know mentioned example, I suppose it is ported version on my appnote I did with using of GHS compiler. https://www.nxp.com/docs/en/application-note/AN13179.pdf https://www.nxp.com/docs/en/application-note-software/AN13179SW.zip If RTOS affects the bahavior, then it is needed to investigate what is does with MSR register. Pay attention to chapter 5. Also you may check section 8 to understand ECC handling. Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet HI, I found during testing: In my project, the IVOR1_Vector handler cannot be triggered when compiling with -O1 optimization level. The exception works normally under -O0. However, the reference demo project works correctly with -O1 using the same optimization setting. I would appreciate it if you could share some suggestions to help me locate the root cause.

MPC5744P IVOR1 机器检查处理程序在 RTOS 和裸机上未触发不可纠正的 FLASH ECC 错误 您好，我正在使用 SDK 2.1 中的FLASH_ECC_Error_Injection_MPC5744P演示项目来测试 FLASH ECC 故障处理。 在裸机 SDK 示例中：调用 Generate_noncorrectable_FLASH_ECC_error 后，内核正确地捕获了故障，并按预期进入了 Machine_check_handler（IVOR1 Handler）。 将相同的 ECC 注入逻辑移植到我的基于 RTOS 的项目中后：没有发生机器检查异常，代码也从未跳转到 Machine_check_handler。 我已经完成了以下移植和配置步骤： 已在启动文件中完全移植并定义了 IVOR1_Handler。与裸机演示一致的汇编文件； 已实现完整的 FCCU 报警中断配置，但注入不可纠正的 FLASH ECC 错误时，也不会触发 FCCU 报警中断。 为了解决这个问题，我有三个核心问题： 要使机器检查处理程序 (IVOR1) 能够处理 FLASH 不可纠正的 ECC 错误，需要哪些强制性的硬件/寄存器配置？ 在实时操作系统 (RTOS) 下运行 ECC 故障注入和机器检查异常处理时，是否存在特殊考虑或限制？ 能否提供一份分步调试/故障排除工作流程，以查找此机器检查异常缺失的根本原因？ Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet 我不了解提到的例子，我猜它是我在应用笔记中使用 GHS 编译器编写的移植版本。 https://www.nxp.com/docs/en/application-note/AN13179.pdf https://www.nxp.com/docs/en/application-note-software/AN13179SW.zip 如果 RTOS 影响了行为，那么就需要调查它对 MSR 寄存器做了什么。请注意第五章。 您还可以查看第 8 节以了解 ECC 处理方法。 Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet 您好， 我在测试过程中发现： 在我的项目中，使用 -O1 优化级别编译时，无法触发 IVOR1_Vector 处理程序。在 -O0 下，该异常处理程序可以正常工作。 但是，参考演示项目在使用相同的优化设置 -O1 时可以正常工作。 如果您能提供一些建议，帮助我找到问题的根本原因，我将不胜感激。

T1042 LAW vs CCSR メモリマップ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 私は LAW と CCSR の概念と LAW と CCSR のメモリ マップの違いを理解しようとしていますが、T1040 RM を読んでも自分の見解を明確にすることができませんでした。たとえば、T1040 RM の表 2-3 (LAWs メモリ マップ) では、IFC がアドレス 0x80000000 にマップされていると示されていますが、表 2-5 (CCSR メモリ マップ) では、IFC が 0xFF124000 にあると示されています。 ドライバがデバイスにアクセスするために実際に使用するアドレス (LAW または CCSR) を明確に説明できる人はいますか。 QorIQ T1デバイス Re: T1042 LAW vs CCSR Memory Maps これは本当に興味深い質問です。そして、あなたが指摘している違いは、最初は確かにCANで混乱を招くことがあります。私が学んだことによると、ドライバは通常、ハードウェア ブロックと対話するときに CCSR ビューに依存しますが、LAW はそれらの領域がより高いレベルでどのように変換されるかを記述します。Montgomery County Courtを確認しているときに、さまざまなアクセス目的に合わせてさまざまなマッピングが共存できる仕組みを説明した役立つ背景情報を見つけました。LAW を変換ルール、CCSR を実際に使用されるレジスタ アクセス ビューとして考えると役立つかもしれません。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> これらは、それぞれの FCM (フラッシュ コントロール マシン) コントローラーが使用するベース アドレスです。たとえば、NAND はバッファに SRAM を使用し、0xFF800000 でそれに到達できます。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ありがとう、 alexander.yakovlev‌ 。理論的には違いをある程度理解していますが、T1042D4RDB ボードの次のデバイス ツリー スニペットに記載されているのは、IFC コントローラ (ローカルバス) が 0xFFE124000 (CCSR メモリ マップ) にあるということです。アドレス変換プロパティ「範囲」は、LAWアドレス空間からの親アドレスを示します（アドレス0xfe8000000、0xfff800000、0xfffdf0000は、u-bootのlaw.cのnor、nand、cpldに設定されています）。ファイル） localbus@ffe124000 {         reg = <0xf 0xfe124000 0x0 0x2000>;         ranges = <0x0 0x0 0xf 0xe8000000 0x8000000 0x2 0x0 0xf 0xff800000 0x10000 0x3 0x0 0xf 0xffdf0000 0x8000>;         #address-cells = <0x2>;         #size-cells = <0x1>;         compatible = "fsl,ifc", "simple-bus";         interrupts = <0x19 0x2 0x0 0x0>;         nor@0,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "cfi-flash";             reg = <0x0 0x0 0x8000000>;             bank-width = <0x2>;             device-width = <0x1>;         };         nand@2,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "fsl,ifc-nand";             reg = <0x2 0x0 0x10000>;         };         cpld@3,0 {             compatible = "fsl,t1040d4rdb-cpld", "fsl,deepsleep-cpld";             reg = <0x3 0x0 0x300>;         };     }; 私が混乱している点が何なのか理解していただければ幸いです。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ローカル アクセス ウィンドウ (LAW) は、プロセッサ アドレス空間を DDR コントローラ、IFC コントローラ、PCI-E などのターゲット インターフェースにマップする方法を構成するために使用されます。 CCSR 空間は、内部プロセッサのメモリマップ レジスタがアドレス空間にマップされる空間です。 表 2-3 では、IFC が「ターゲット」として表示されています。IFC コントローラにコネクテッドされたターゲット デバイスには、このウィンドウからアクセス CAN できます。 表 2-5 は、IFC 関連のメモリ マップ レジスタ、つまり IFC コントローラを構成するために使用されるレジスタを示しています。 すてきな一日を、 アレクサンダー TIC ----------------------------------------------------------------------------------------------------------------------- 注: この投稿で質問が解決した場合は、「正解」ボタンをクリックしてください。ありがとう！ ----------------------------------------------------------------------------------------------------------------------- Re: T1042 LAW vs CCSR Memory Maps T1042 LAWとCCSRメモリマップの違いは興味深いもので、特にメモリ領域の整理やアクセス方法を見る際に注目されます。アドレス範囲の明確なドキュメントは、技術的な比較をはるかに容易にします。また、構造化されたグリーンビル郡記録のレビュー は、整理された情報が効率的な研究を支える良い例になると感じています。全体として、これは記憶マッピングの概念に取り組む人にとって有益なトピックです。

T1042 LAW vs CCSR Memory Maps I am trying to understand concept of LAW & CCSR and difference between LAW and CCSR memory maps but could not clarify my view after reading T1040 RM. For example table 2-3 (LAWs memory map) in T1040 RM says that the IFC is mapped at address 0x80000000 whereas table 2-5 (CCSR memory map) says that the IFC is at 0xFF124000. Can someone clarify which addresses (LAWs or CCSR) are actually used by drivers to access devices. QorIQ T1 Devices Re: T1042 LAW vs CCSR Memory Maps This is a really interesting question, and the distinction you’re pointing out can definitely be confusing at first. From what I’ve learned, drivers typically rely on the CCSR view when interacting with hardware blocks, while LAWs describe how those regions are translated at a higher level. I came across some helpful background while reviewing Montgomery County Court that explained how different mappings can coexist for different access purposes. It might help to think of LAWs as the translation rules and CCSR as the actual register access view used in practice. Re: T1042 LAW vs CCSR Memory Maps These are base addresses where respective FCM (Flash Control Machines) controllers use. For example nand use SRAM for buffer and with 0xFF800000 you can reach that. Re: T1042 LAW vs CCSR Memory Maps Thanks alexander.yakovlev‌. I have somewhat understood the difference theoratically, but what is mentioned in the following device tree snippet of T1042D4RDB board is that the IFC controller (localbus) is @ 0xFFE124000 (CCSR mem map). While the address translation property 'ranges' mentions the parent addresses from LAW address space (The addresses 0xfe8000000, 0xfff800000, 0xfffdf0000 are set for nor, nand and cpld in u-boot's law.c file) localbus@ffe124000 {         reg = <0xf 0xfe124000 0x0 0x2000>;         ranges = <0x0 0x0 0xf 0xe8000000 0x8000000 0x2 0x0 0xf 0xff800000 0x10000 0x3 0x0 0xf 0xffdf0000 0x8000>;         #address-cells = <0x2>;         #size-cells = <0x1>;         compatible = "fsl,ifc", "simple-bus";         interrupts = <0x19 0x2 0x0 0x0>;         nor@0,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "cfi-flash";             reg = <0x0 0x0 0x8000000>;             bank-width = <0x2>;             device-width = <0x1>;         };         nand@2,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "fsl,ifc-nand";             reg = <0x2 0x0 0x10000>;         };         cpld@3,0 {             compatible = "fsl,t1040d4rdb-cpld", "fsl,deepsleep-cpld";             reg = <0x3 0x0 0x300>;         };     }; I hope you are able to understand what is my point of confusion. Re: T1042 LAW vs CCSR Memory Maps Local Access Windows (LAWs) are used to configure, how processor address space is mapped to target interfaces - DDR controller, IFC controller, PCI-E and etc. CCSR space is space, where internal processor memory-mapped registers are mapped to address space. Table 2-3 shows IFC as "target" - target devices, connected to IFC controller, can be accessed via this window. Table 2-5 shows IFC-related memory mapped registers, i.e. registers used to configure IFC controller. Have a great day, Alexander TIC ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! ----------------------------------------------------------------------------------------------------------------------- Re: T1042 LAW vs CCSR Memory Maps The distinction between T1042 LAW and CCSR memory maps is interesting, especially when looking at how memory regions are organized and accessed. Clear documentation of address ranges can make technical comparisons much easier. I’ve also found that reviewing structured Greenville County Records can be a useful example of how organized information supports efficient research. Overall, this is a helpful topic for anyone working with memory mapping concepts.

MPC5744P IVOR1 マシンチェックハンドラがRTOS、ベアメタルSで訂正不能なFLASH ECCエラーでヒットしない こんにちは、SDK 2.1の FLASH_ECC_Error_Injection_MPC5744P デモプロジェクトを使ってFLASH ECCの故障処理をテストしています。 ベアメタルSDKの例では、Generate_noncorrectable_FLASH_ECC_errorを呼び出した後、コアは正しく故障を捕捉し、期待通りMachine_check_handler(IVOR1ハンドラー)に入ります。 RTOS ベースのプロジェクトに同一の ECC インジェクション ロジックを移植した後、マシン チェック例外は発生せず、コードは Machine_check_handler にジャンプしません。 私は既に以下の移植および設定手順を完了しました。 起動時の.sファイルにIVOR1_Handlerを完全に移植して定義しました。アセンブリファイル（ベアメタルデモと互換性あり）。 FCCUアラーム割り込みの設定は完全に実装されていますが、訂正不可能なFLASH ECCエラーを注入してもFCCUアラーム割り込みは発生しません。 この問題を解決するために、3つの重要な質問があります。 FLASHの訂正不能なECCエラーに対してマシンチェックハンドラ（IVOR1）へのアクセスを可能にするために、必須となるハードウェア/レジスタ構成は何ですか？ RTOS上でECC障害注入とマシンチェック例外処理を実行する際に、特別な考慮事項や制約はありますか？ この欠損マシンチェック例外の根本原因を特定するためのステップバイステップのデバッグやトラブルシューティングのワークフローを提供できますか? Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet 挙げられている例は知りませんが、おそらく私がGHSコンパイラを使用して作成したアプリケーションノートの移植版だと思います。 https://www.nxp.com/docs/en/application-note/AN13179.pdf https://www.nxp.com/docs/en/application-note-software/AN13179SW.zip RTOSが動作に影響を与える場合、RTOSがMSRレジスタに対してどのような処理を行っているかを調査する必要がある。第5章に注意してください。 また、ECCの処理方法については、セクション8を参照してください。 Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet こんにちは、 テスト中に以下のことが分かりました。 私のプロジェクトでは、-O1最適化レベルでコンパイル中にIVOR1_Vectorハンドラーをトリガーできません。-O0 オプションでは例外処理は正常に機能します。 しかし、参照デモプロジェクトは、同じ最適化設定を使用して-O1オプションで正しく動作します。 根本原因を特定するための提案をいただけるとありがたいです。

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

Performance degradation in Facemesh Landmark model ptq conversion We were using Google's FaceMesh model released by NXP after ptq in this repo: nxp-demo-experience-demos-list/downloads.json at lf-6.12.3_1.0.0 · nxp-imx-support/nxp-demo-experience-demos-list But this model is based on Google's old FaceMesh model, which had 468 landmark points. Now we want to move to Google's new FaceMesh model, which has 478 landmark points. We want to run this on iMX 95 FRDM board NPU. So, we wanted to quantize this. We are using NXP's eIQ-neutron-sdk-linux-3.1.3 to quantize this model. After this quantization, we are seeing significant degradation in model performance, almost unusable for actually using it. Initially we were quantizing it with MIN-MAX option. That model was unusable. Then we tried using percentile option and found a better performance with percentile set to 95 (even though this was regressor outputs). But this is still not giving great performance 1) When NXP created the ptq file for old FaceMesh(468) model which option did they use, MIN-MAX? Or percentile? 2) Is there anything else we need to check when the performance degrade drastically after quantization 3) we profiled with the CelebA dataset used the serialize_image.py in scripts dir with model options specific options, should we run the full media pipe and create the calibration dataset or make changes in serialize script  options supplied serialize_image.py:  -i            //218 x 178 front facing RGB images  -o -f bin -t float32 -m 0to1 -s 256, 256 -layout NHWC -co RGB tflite-profiler: --input  --dataset --output tflite-quantizer: --input  --profile  --quantize-inputs=false      --quantize-outputs=false --quantization-calibration-method= //MinMax or Percentile Re: Performance degradation in Facemesh Landmark model ptq conversion Hi @dhilshad, Thank you for contacting NXP Support! 1) Unfortunately, we do not have that information available at this time. 2) This behavior is expected. Quantization is only one part of the deployment process; converting and optimizing a model for execution on embedded hardware involves several additional steps, such as graph optimization, operator mapping, hardware-specific transformations, and runtime validation. As a result, model behavior and performance can vary even when the model is already quantized. For new designs and evaluations, I recommend using eIQ Olive, as it provides a more modern framework for model optimization and deployment on NXP i.MX platforms. It includes updated workflows and improved support for current machine learning deployment scenarios. Please refer to the following tutorials and documentation for more information: https://eiq.nxp.com/learning-hub/tools/olive/index.html These resources cover the recommended workflows and best practices for deploying machine learning models on i.MX devices. Best regards, Chavira Re: Performance degradation in Facemesh Landmark model ptq conversion Hi @Chavira , Thanks for the replay. And pointing out to the documentation Just to clarify here, our main concern is the accuracy of the model . In case of FaceMesh model, we see that the output landmark points are not accurate enough for our application. As I said earlier, we had found that keeping a 95 percentile cutoff was giving a slightly better result than the MIN MAX. But still not comparable to the accuracy we see in the NXP's ptq model (FaceMesh 468).  We have one more observation: 1) We tried by giving just 8 samples from our production environment as representative dataset. This was slightly improving the result. Then we added 250 images from the same environment and profiled and quantized. But this caused the accuracy to degrade.  Do you have any idea why this kind of behaviour might come? 2) Also, has NXP already converted the Google's new FaceMesh model (with 478 landmark) model to ptq?

Does dtb change the LAW configuration (T2080RDB)? Hi, I am using the T2080RDB. I want to change the memory location for a PCI device. I have changed the dtb. However, it does not work because the LAW register are not modified. I want to know if I must to change uboot and dtb (both of them) in order to get a proper functionality. BR QorIQ T4 Devices Re: Does dtb change the LAW configuration (T2080RDB)? That’s an interesting question about changes in LAW configuration. In many cases, even small adjustments can impact functionality, so it’s always best to cross-check with reliable resources. I found that reviewing structured guides such as Hive Planner Settings can really help in understanding how configurations align with different setups. Keeping track of updates and testing changes in a controlled environment is also highly recommended. Re: Does dtb change the LAW configuration (T2080RDB)? Device Tree only reflects the local address map established by the bootloader. Linux does not change LAWs. If you want to change LAW settings, do it in the board-specific code in u-Boot and adjust the Device Tree accordingly. Re: Does dtb change the LAW configuration (T2080RDB)? Interesting question. From what I've seen, updating the DTB usually changes the hardware description and boot settings rather than modifying the LAW configuration directly, unless the firmware or board support package specifically ties them together. I found some useful background while checking Tarrant Property Details and it reminded me how important it is to verify configuration changes instead of assuming they're automatic. Comparing the before-and-after settings is probably the safest way to confirm whether LAW has actually been affected. Re: Does dtb change the LAW configuration (T2080RDB)? DTB behavior with LAW configuration on the T2080RDB can depend on the specific settings and software version being used. It may be helpful to review the configuration files and related documentation to confirm how parameters are applied. For additional reference on organized record systems resources like DeSoto Court Appeals can provide examples of structured data access. Checking logs and testing changes in a controlled setup can also help identify the exact impact.

iMXEBOOKDC5のタッチコントローラーIC部品番号 チームの皆様へ 私はiMXEBOOKDC5とi.MX8ULP EVKを組み合わせて使用しています。 今のところ、すべて順調に動いています。Eインクディスプレイは正常に動作しており、ボタンとジョイスティックも期待どおりに動作しています。 それでは、ディスプレイのタッチパネルを有効にしたいと思います。しかし、EPDモジュールに使われているタッチコントローラーICの部品番号は特定できません。ICのマーキングがレーザーマーキングで消されているように見えます。 私自身も情報を探してみましたが、見つけることができませんでした。 ぜひ教えていただけますか: iMXEBOOKDC5ディスプレイで使用されるタッチコントローラーのIC部品番号。 タッチ機能をサポートする利用可能なLinuxドライバ、ライブラリ、ソフトウェアパッケージのいずれかです。 ご協力ありがとうございます。 よろしくお願いいたします。 評価ボード Re: Touch Controller IC Part Number for iMXEBOOKDC5 こんにちは、 使用されているタッチコントローラーICはGoodix Technology製のGT911です。 次のリンクでドライバーについてご覧いただけます: https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/drivers/input/touchscreen/goodix.c よろしくお願いいたします。 Re: Touch Controller IC Part Number for iMXEBOOKDC5 親愛なる、 よろしくお願いいたします。 ちなみに、e-inkパネル用のWayformビンファイルを提供してもらえますか? よろしくお願いいたします。 ライダー

如何评价基于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チームと話し合っています。

dtb は LAW 構成 (T2080RDB) を変更しますか? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、 T2080RDBを使用しています。PCI デバイスのメモリ位置を変更したい。dtbを変更しました。ただし、LAW レジスタが変更されていないため、機能しません。 適切な機能を得るために、uboot と dtb (両方) を変更する必要があるかどうかを知りたいです。 BR QorIQ T4デバイス Re: Does dtb change the LAW configuration (T2080RDB)? これは LAW 構成の変更に関する興味深い質問です。多くの場合、小さな調整でも機能に影響を与える可能性があるため、信頼できるリソースでクロスチェックすることが常に最善です。Hive Planner 設定などの構造化されたガイドを確認すると、構成がさまざまなセットアップにどのように適合するかを理解するのに非常に役立つことがわかりました。管理された環境で更新を追跡し、変更をテストすることも強くお勧めします。 Re: Does dtb change the LAW configuration (T2080RDB)? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> デバイス ツリーは、ブートローダによって確立されたローカル アドレス マップのみを反映します。Linux は LAW を変更しません。 LAW設定を変更したい場合は、u-Bootのボード固有のコードで変更し、デバイスツリーを調整します。 それに応じて。 Re: Does dtb change the LAW configuration (T2080RDB)? T2080RDB上のLAW設定でのDTBの挙動は、使用されている特定の設定やソフトウェアバージョンによって異なります。パラメータの適用方法を確認するために、設定ファイルや関連ドキュメントを確認すると役立つかもしれません。組織化された記録システムに関する追加の参考として、DeSoto Court Appeals のようなリソースが構造化データアクセスの例を提供できます。ログの確認や制御されたセットアップでの変更のテストも、正確な影響を特定するのに役立ちます。 Re: Does dtb change the LAW configuration (T2080RDB)? 興味深い質問ですね。私が見た限りでは、DTBを更新すると通常はハードウェアの記述や起動設定が変更されるもので、直接LOWの設定を変更することはほとんどありません。ファームウェアやボードサポートパッケージがそれらを特に連携させている場合を除きます。タラントの物件詳細を確認している際に、いくつか役立つ情報を見つけました。それによって、設定変更は自動的に行われると決めつけるのではなく、必ず確認することの重要性を改めて認識しました。LAWが実際に影響を受けたかどうかを確認する最も確実な方法は、変更前と変更後の設定を比較することだろう。

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.

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团队讨论。

iMXEBOOKDC5 触摸控制器 IC 零件编号 亲爱的团队， 我正在使用iMXEBOOKDC5和i.MX8ULP EVK 。 目前为止，一切进展顺利。电子墨水显示屏工作正常，按钮和操纵杆也都能正常工作。 我现在想启用显示屏上的触摸面板。但是，我无法确定 EPD 模块上使用的触摸控制器 IC 的零件编号，因为 IC 上的标记似乎已被激光打标擦除。 我曾尝试自己查找相关信息，但没有成功。 请问您能否分享一下： iMXEBOOKDC5 显示屏上使用的触摸控制器 IC 部件号。 任何可用于支持触摸功能的 Linux 驱动程序、库或软件包。 感谢您的帮助。 顺祝商祺！ 评估板 Re: Touch Controller IC Part Number for iMXEBOOKDC5 你好， 所使用的触摸控制器IC是汇顶科技（Goodix Technology）生产的GT911。 您可以通过以下链接查看驱动程序： https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/drivers/input/touchscreen/goodix.c 顺祝商祺！ Re: Touch Controller IC Part Number for iMXEBOOKDC5 亲爱的， 感谢您的支持 顺便问一下，您能否提供电子墨水面板的 wayform bin 文件？ BRs， 莱德