Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
TED-Kit 2(OM6716)GUIソフトウェアダウンロード手順の要請 親愛なるNXPサポートチームへ、 私はjwヒョンです。 お客様にお渡しできるように、GUIソフトウェアパッケージのダウンロード方法について教えていただけますか? お手数ですが、登録/ダウンロードの手順について、できるだけ早くご教示いただければ幸いです。 サポートにあらかじめ感謝いたします。
記事全体を表示
Technical Inquiry External Pull--down Design for i.MX8 PCIe RC PERST Background: Currently, PERST# is controlled by a normal GPIO of the i.MX8, and no external pull-up or pull-down resistor has been added. During power-on startup, in the Boot ROM/SPL stage, the GPIO PAD is uninitialized and remains in a high-impedance floating state. In a noisy environment, the pin level toggles, causing abnormal reset of the PCIe endpoint device and preventing the link from being established. We now plan to add external resistors to eliminate floating noise, and have drafted two schemes; we would like to obtain NXP's official opinion. Scheme 1: Connect a pull-up resistor to 3.3V Before the bootloader configures the GPIO, the PAD is in a high-impedance state; PERST# is pulled high continuously, and the reset is released early, so it cannot meet the timing requirement of TPV_PERST in the PCIe CEM specification (PERST# must remain asserted for at least 100 ms after power is stable). Will this cause unreliable power-on? Does NXP approve this scheme? Scheme 2: Connect a pull-down resistor to GND During the boot stage, PERST# remains low, which can meet the power-on reset timing requirement. However, the concern is that during normal system operation, the pull-down resistor in combination with external noise may unexpectedly pull PERST# low, triggering an unexpected device reset. Is this risk real? What resistor value does NXP recommend? Key Questions: In the officially recommended scenario where an i.MX8 GPIO controls PERST#, does NXP allow adding an external pull-down resistor, or does it explicitly prohibit external pull-up/pull-down resistors? Is it recommended to use a POR hardware delay circuit to generate PERST#? We look forward to your reply. Thank you!      
記事全体を表示
我不确定这个位的具体含义 屏幕截图_14-9-2026_20244_.jpeg屏幕截图_14-9-2026_20244_.jpeg 对于Authentication Status(AUTHSTTS)寄存器,bit0位置一的含义是已经进入挑战模式了吗,还是说明挑战值准备完成,我对这点非常困惑,有谁能帮我解答一下吗,非常感谢! 屏幕截图_14-9-2026_202943_.jpeg屏幕截图_14-9-2026_202943_.jpeg Re: 我不确定这个位的具体含义 嗨,Vane 如果芯片未启用挑战模式,AUTHSTTS 的第 0 位是否仍设置为 1? Re: 我不确定这个位的具体含义 你好@TakanashiLika AUTHSTTS[CHALRDY] 是一个只读状态位,指示挑战何时准备就绪。调试器应等待 CHALRDY 被置位后再读取 KEYCHALn 寄存器中的挑战信息。 BR,VaneB 回复: 我不确定这个位的具体含义 芯片是S32K314
記事全体を表示
创建安全登录 我正在为我妈妈创建一个网站,现在我正在尝试创建用户注册的登录部分,但在确保密码输入和要发送到数据库的数据受到保护方面遇到了一些问题,请问有什么办法吗?
記事全体を表示
Create a secure login I'm creating a website for my mom, and now I'm trying to create the login part for the user's registration, but I have some problems when I have to make sure that the input of the password and the data to be sent to the database should be protected, some help?
記事全体を表示
この役職が具体的に何を意味するのか、よく分かりません。 屏幕截图_14-9-2026_20244_.jpegScreenshot_14-9-2026_20244_.jpeg 認証ステータス(AUTHSTTS)レジスタのビット0が何を意味するのか、とても混乱しています。チャレンジモードに入ったということでしょうか、それともチャレンジ値が準備できたということでしょうか?どなたかご説明いただけないでしょうか?よろしくお願いいたします! 屏幕截图_14-9-2026_202943_.jpegScreenshot_14-9-2026_202943_.jpeg Re: 我不确定这个位的具体含义 こんにちは、ベイン チップがチャレンジモードを有効にしていない場合でも、AUTHSTTSのビット0は1に設定されますか? Re: 我不确定这个位的具体含义 こんにちは、 @TakanashiLika さん AUTHSTTS[CHALRDY]は、チャレンジの準備が完了したことを示す読み取り専用のステータスビットです。デバッガは、KEYCHALnレジスタ内のチャレンジを読み取る前に、CHALRDYがアサートされるまで待機する必要があります。 BR、VaneB 回复: 我不确定这个位的具体含义 チップはS32K314です。
記事全体を表示
TED-Kit 2 (OM6716) GUI 软件下载说明申请 尊敬的恩智浦技术支持团队: 我是jwHyun, 请问能否提供下载图形用户界面软件包的说明,以便我们将其提供给我们的客户? 请您在方便的时候尽快指导我们完成注册/下载流程。 感谢您提前给予的支持。
記事全体を表示
FRDM I.mx93 desing files for altium HI, I am starting to develop a solution using i.mx93 and i wanted to see the hardware layout and schematics of the development board. I don´t have a cadence license, but i heard i could import it to altium if i had some specific files that cadence can generate... Could someone please provide the Allegro ASCII (.alg) file for LAY-94611.brd (FRDM-i.MX93 PCB) along with the OrCAD Capture schematic (.DSN) file? thanks in advance
記事全体を表示
LX2160A - SerDes 通道编号 您好, 我注意到 LX2160A 参考手册中关于 SerDes 1 通道编号存在不一致之处。 在第 26.1.4 节中(SerDes 选项),使用字母时,SerDes 1 通道的编号是相反的:通道 H = 0 -> 通道 A = 7。 fdekeers_0-1789391391196.pngfdekeers_0-1789391391196.png 在第 26.4.1.19 节(SerDes Lane m RX 通用控制寄存器 1 (LNARGCR1 - LNHRGCR1)),文本说明字母编号递增:Lane A = 0 -> Lane H = 7。 fdekeers_1-1789391514092.pngfdekeers_1-1789391514092.png 我希望配置通用控制寄存器 1 中的寄存器 EXT_REC_CLK_SEL,而正确通道的地址偏移量取决于此编号。请问哪个是正确的? 顺祝商祺! Re: LX2160A - SerDes lanes numbering 你好, 两部分内容均正确——它们使用了两种不同(但一致)的索引规则。 表面上的矛盾可以通过理解这两个部分使用了不同的“变量”来解决: 第 26.1.4 节— 协议表中的泳道编号(H=0 … A=7) 具体来说,对于 SerDes 1 ,RM 从物理层的角度分配通道号: 信 通道号(协议表) H 0 G 1 F 2 E 3 D 4 C 5 B 6 A 7     这是有意为之,并且如文档所述,是正确的。NXP TS 在之前的案例中明确证实了这一点: “SerDes1 的通道字母顺序相反。” 这当有人对 LS1046A 提出类似问题时,也证实了同样的方案适用于 LX2160A。 AN13022 应用笔记也使用了相同的 H/0 … A/7 列标题。 第 26.4.1.19 节— 将后缀字母注册为地址索引(A=0 … H=7) 偏移公式 848h + (a × 100h) 使用 a 作为寄存器名称字母索引,其中 A=0,B=1,… H=7: 寄存器名称 a (字母索引) 偏移量 LN A RGCR1 0 0x848 LN B RGCR1 1 0x948 LN E RGCR1 4 0xC48 LN F RGCR1 5 0xD48 LN H RGCR1 7 0xF48       AN13022 也证实了这一点,其中明确列出了: “LNmRGCR1(A 车道偏移量为 0x0848,B 车道偏移量为 0x0948,E 车道偏移量为 0x0C48,F 车道偏移量为 0x0D48)” — 完全符合 A=0…H=7 字母索引公式。 如何为正确的通道配置 EXT_REC_CLK_SEL 根据 SerDes 1 协议表(第 26.1.4 节)确定您的通道字母,其中第一个物理车道标记为H (车道 0)。 使用以该字母命名的寄存器——例如,H 车道使用 LNHRGCR1 ,A 车道使用 LNARGCR1 。 使用 848h + (letter_index × 100h) 计算地址偏移量 ,其中 A=0,B=1,…,H=7。 例如,要在 H 通道(SerDes 1 的第一个通道,协议表中的通道编号为 0)上配置 EXT_REC_CLK_SEL : 注册号: LNHRGCR1 偏移量: 848h + 7 × 100h = 0xF48 此致
記事全体を表示
技术咨询:i.MX8 PCIe RC PERST 的外部下拉设计 背景: 目前,PERST# 由 i.MX8 的一个普通 GPIO 引脚控制,未添加任何外部上拉或下拉电阻。在上电启动期间,在 Boot ROM/SPL 阶段,GPIO PAD 引脚未初始化,处于高阻抗浮空状态。在噪声环境下,引脚电平会发生翻转,导致 PCIe 端点设备异常复位,从而阻止链路建立。我们计划添加外部电阻以消除浮空噪声,并已设计了两种方案;希望获得 NXP 的官方意见。 方案一:将上拉电阻连接到 3.3V 在引导加载程序配置 GPIO 之前,PAD 处于高阻抗状态;PERST# 持续被拉高,RESET 信号提前释放,因此无法满足 PCIe CEM 规范中 TPV_PERST 的时序要求(电源稳定后,PERST# 必须保持有效至少 100 毫秒)。这会导致上电不稳定吗?NXP 是否认可这种方案? 方案二:将下拉电阻连接到地线 在启动阶段,PERST# 保持低电平,这可以满足上电复位时序要求。然而,令人担忧的是,在系统正常运行期间,下拉电阻与外部噪声结合可能会意外地将 PERST# 拉低,从而触发设备意外复位。这种风险是否真实存在?NXP 推荐使用多大的电阻值? 关键问题: 在官方推荐的方案中,当 i.MX8 GPIO 控制 PERST# 时,NXP 是否允许添加外部下拉电阻,还是明确禁止使用外部上拉/下拉电阻?是否建议使用 POR 硬件延迟电路来生成 PERST#? 我们期待您的回复。谢谢你!      
記事全体を表示
EB Tresos生成のRTDドライバをFreeRTOS + MPUで使用する こんにちは、 当社ではRTD 6.0.0とBMS 0.9.1を使用しています。EB TresosのSDKを使ってドライバーコードを生成します。MPUを使わないCortex M7ポートのFreeRTOSでは問題なく動作します。 今度はMPUを使うFreeRTOSポートに切り替えたいです。これを2つのステップで行いたい。 1) すべてのタスクを特権的に設定しつつMPUを使用する、すなわち各コンテキストスイッチでMPUを再プログラムすること 2) すべてのタスクを非特権にする。つまり、非特権タスクで使われるドライバーで「ユーザーモードのサポートを有効にする」を有効にする必要があります 今のところ、私は1)で苦戦しています。ドライバ機能は安定して動作しません。例えば、SPIは断続的にしか動作しない。MPU領域が正しく動作していないようです。たとえこれが解決したとしても、2)どうやって実装できるのでしょうか?スーパーバイザコールハンドラは、FreeRTOSとRTDによって提供されます。それらを統合するべきでしょうか? Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU こんにちは、 @Julián_AragónM。 私はFreeRTOSを公式サイトからダウンロードし、Cortex M7とMPUの両方に対応しているポートを使っていました。私の理解が正しければ、NXPが提供するFreeRTOSを使用する必要があるということですね。私はS32DSで設定可能なNXPのFreeRTOSしか見つけられず、EB Tresosは見つかりませんでした。私の質問は以下の通りです: - 正しいM7+MPUポートが付いている汎用FreeRTOSを使えますか? - もしなければ、NXPが提供するFreeRTOSでEB Tresosで設定できるものはありますか? Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU こんにちは、 @PhilippH さん、 まず、FreeRTOS 7.0.0でMPUの初期サポートが追加されましたCD1、これがあなたが使っているパッケージであることを確認できますか?(または最新リリースである0.8.0 CD1)。 1) どのMPUリージョンが正しく動作していないか教えてもらえますか?可能であれば、設定と手順を共有してください。 また、S32K3 FreeRTOSユーザーマニュアルに含まれる推奨事項に従ってください: 「Use mpu」および「Use mpu wrappers v1」オプションを有効にします。 RTDのMPU領域との競合を避けるため、最初の設定可能領域を0ではなく9に設定してください。 注記: FreeRTOSをMPUサポートと統合するには、FreeRTOSで使用される必要なメモリセクションを定義するためにRTDリンカーファイルを修正する必要があります。アプリケーションに変更を適用する際は、サンプルファイルを参考にしてください。 2) FreeRTOSConfig.h なのでマージは不要だと思います以下のマクロを宣言します。 /* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS standard names. */ #define vPortSVCHandler SVC_Handler #define xPortPendSVHandler PendSV_Handler #define xPortSysTickHandler SysTick_Handler これにより、FreeRTOSのSVC呼び出しが、exceptions.cにあるRTD提供のSVC_Handlerにリダイレクトされます。 よろしくお願いします、 ジュリアン
記事全体を表示
Fit Data 您好,请问哪里可以找到NX5P3090 的FIT数据?帮忙发我一下吧,谢谢.
記事全体を表示
How to Flash P89C52X2BN MCU? Hi all, I need to program two old MCUs: P89C52X2BN and P89C52RD2. For the P89C52RD2, I understand it supports ISP via serial. But not known how to active and ISP/IAP protocol? For the P89C52X2BN, How do I flash it? Does it need a parallel programmer? If need, how protocol and how to active flash mode? I'm mainly looking for the official programming documentation for these two chips (especially the X2BN), so I can reference the correct flash programming interface and timing. If you have the datasheet's programming section or a link, please share. Thanks! Re: How to Flash P89C52X2BN MCU? Hello I apologize for the inconveniences this might cause you, The P89C52 family is no longer manufactured and because of this is no longer supported, the information for this family is no longer available. If it could work for you there is this information for the 89C51; Important: I can't confirm or test whenever this information work and/or apply for the 89C52. In-circuit and In-application programming of the 89C51Rx+/Rx2/66x microcontrollers Best Regards,
記事全体を表示
LX2160A - SerDes lanes numbering Hi, I noticed an inconsistency in the LX2160A reference manual regarding the numbering of SerDes 1 lanes. In section 26.1.4 (SerDes options), SerDes 1 lanes' numbering is reversed when using letters: Lane H = 0 -> Lane A = 7. fdekeers_0-1789391391196.pngfdekeers_0-1789391391196.png In section 26.4.1.19 (SerDes Lane m RX General Control Register 1 (LNARGCR1 - LNHRGCR1)), the text states that the letter numbering is increasing: Lane A = 0 -> Lane H = 7. fdekeers_1-1789391514092.pngfdekeers_1-1789391514092.png I wish to configure register EXT_REC_CLK_SEL in the General Control Register 1, and the address offset for the correct lane depends on this numbering. Can you please confirm which one is correct ? Best regards. Re: LX2160A - SerDes lanes numbering Hello, Both sections are correct — they use two different (but consistent) indexing conventions The apparent contradiction is resolved by understanding that the two sections use different "variables": Section 26.1.4 — Lane number in the protocol table (H=0 … A=7) For SerDes 1 specifically, the RM assigns lane numbers from the physical-layer perspective: Letter Lane # (protocol table) H 0 G 1 F 2 E 3 D 4 C 5 B 6 A 7     This is intentional and correct as documented. NXP TS confirmed this explicitly in a prior case: "SerDes1 has opposite order of lane letters."The same scheme was also confirmed to apply to the LX2160A when a similar question was raised for the LS1046A. The AN13022 application note also uses this same H/0 … A/7 column header. Section 26.4.1.19 — Register suffix letter as address index (A=0 … H=7) The offset formula 848h + (a × 100h) uses a as the register-name letter index, where A=0, B=1, … H=7: Register name a (letter index) Offset LNARGCR1 0 0x848 LNBRGCR1 1 0x948 LNERGCR1 4 0xC48 LNFRGCR1 5 0xD48 LNHRGCR1 7 0xF48       This is cross-confirmed by AN13022, which lists exactly: "LNmRGCR1 (offsets 0x0848 for lane A, 0x0948 for lane B, 0x0C48 for lane E, 0x0D48 for lane F)"— all consistent with the A=0…H=7 letter-index formula. How to configure EXT_REC_CLK_SEL for the correct lane Identify your lane letter from the SerDes 1 protocol table (section 26.1.4), where the first physical lane is labeled H (lane 0). Use the register named after that letter — e.g., for Lane H use LNHRGCR1 , for Lane A use LNARGCR1 . Calculate the address offset using 848h + (letter_index × 100h) , where A=0, B=1, …, H=7. For example, to configure EXT_REC_CLK_SEL on Lane H (the first lane of SerDes 1, lane number 0 in the protocol table): Register: LNHRGCR1 Offset: 848h + 7 × 100h = 0xF48 Regards
記事全体を表示
Altium用FRDM I.mx93設計ファイル こんにちは、i.mx93を使ってソリューションの開発を始めていて、開発ボードのハードウェアレイアウトと回路図を見たいと思っています。 Cadenceのライセンスは持っていませんが、Cadenceが生成できる特定のファイルがあればAltiumにインポートできると聞きました... どなたか、LAY-94611.brd(FRDM-i.MX93 PCB)用のAllegro ASCII(.alg)ファイルと、OrCADキャプチャの回路図(.dsn)ファイルを提供していただけませんか?DSNファイル? よろしくお願いします
記事全体を表示
Altium 的 FRDM I.mx93 设计文件 您好,我正在使用 i.mx93 开发一个解决方案,我想查看开发板的硬件布局和原理图。 我没有 Cadence 的许可证,但我听说如果我有一些 Cadence 可以生成的特定文件,就可以把它导入到 Altium 中…… 请问谁能提供 LAY-94611.brd(FRDM-i.MX93 PCB)的 Allegro ASCII (.alg) 文件以及 OrCAD Capture 原理图 (.DSN) 文件? 提前致谢
記事全体を表示
Example S32K344EVB_T172 UART_ETH_Gateway HLD S32DS368 RTD701 **************************************************************************************** * Detailed Description: * * UART <-> Ethernet gateway demo for S32K344EVB-T172. * * UART messages are encapsulated into raw Ethernet frames * and transmitted over the Ethernet link. Received Ethernet * frames are decapsulated and forwarded to the UART terminal. * * Key Functionality: * - UART TX/RX interrupt driven communication. * - GMAC TX confirmation and RX indication interrupt processing. * - Four-deep message queue for UART/Ethernet decoupling. * - Runtime MAC address configuration. * - TJA1103 loopback, MASTER and SLAVE operation. * - Raw Ethernet frame transport (EtherType 0x88B5). * - RTD MCAL/HLD implementation (EthIf, Eth_43_GMAC, CDD_UART). * * Runtime status information including node configuration, * MAC addresses and link status is displayed on the UART terminal. * * Test Configurations: * * Single board: * GATEWAY_MODE_NODE_1_LOOPBACK * * Two-board setup: * Board 1 : GATEWAY_MODE_NODE_1_MASTER * Board 2 : GATEWAY_MODE_NODE_2_SLAVE * * Boards are connected using a 100BASE-T1 cable. * * Notes: * - EthIf.c contains custom gateway callback implementation. * - During S32 Configuration Tool code generation select "Keep Existing" for EthIf.c. * - Do not overwrite EthIf.c. * - On PC terminal enable local echo * * -------------------------------------------------------------------------------------- * Test HW: S32K3x4EVB-T172 Rev B * MCU: S32K344_172HDQFP * IDE: S32DS 3.6.8 * RTD release: S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 * Debugger: Lauterbach, P&E Micro * Target: Internal_FLASH * Serial: 115200, 8N1 *****************************************************************************************   Terminal prints between two S32K344EVB-T172 boards PetrS_0-1789458752395.pngPetrS_0-1789458752395.png In case of single board in PHY loopback PetrS_1-1789458817163.pngPetrS_1-1789458817163.png  
記事全体を表示
(PN7642)- How to Prevent the ULPCD Freeze State Introduction  Based on ES_PN7642 , the PN7642 operating in ULPCD mode may, in very rare cases, enter an unresponsive state. This is caused by very strong distortion of the power supplies or GND of the IC during this boot-up time can cause a loss of the internal reset state and the boot-up sequence gets stuck. This article describes method for evaluating whether a design is sensitive to this phenomenon and provides guidance on how to monitor it.    The primary indicator is the LFO (Low-Frequency Oscillator). In particular, instability of the LFO during the ULPCD "Active" period may indicate an increased risk of the device entering the ULPCD Freeze (unresponsive) state.   This LFO instability may be caused by external events, such as ESD (Electrostatic Discharge), or by interference from other electronic circuits integrated on the PCB.    LFO instability is characterized by deviations in the oscillator's duty cycle and/or the occurrence of missing LFO cycles.   1// Where to measure the LFO ?  The measurement is done during the ULPCD "Active" phase  Tomas_Parizek_0-1789453318198.pngTomas_Parizek_0-1789453318198.png   Time window where to measure the LFO stability    Tomas_Parizek_2-1789453587804.pngTomas_Parizek_2-1789453587804.png Detail of the "LFO" Start. Please start the measurement when the LFO frequency gets stable.  Tomas_Parizek_3-1789454620348.pngTomas_Parizek_3-1789454620348.png   At the end of the ULPCD active phase, the last LFO clock cycle typically exhibits a slight deviation. This behavior is expected and should not be interpreted as an indication of LFO instability.     Tomas_Parizek_4-1789454768289.pngTomas_Parizek_4-1789454768289.png 2// How to enable LFO observability The LFO can be routed with the help of ULPCD test buses on GPIO2.  For firmware versions up to PN7642 FW v03.01. -> AN14518 (5.4 How to use test signals for PN7642) Write xx before entering ULPCD mode  For firmware versions from PN7642 FW v03.01 onward -> PN7642 Datasheet (9.14.3.17.12 ULPCD_TESTBUS_MUX_SETTINGS (0702)) Write xx before entering ULPDC mode 
記事全体を表示
How to use the GPU of the NXP Layerscape LS1028A with Yocto    Yocto Project Configuration The most modern and NXP-recommended method for developing with the LS1028A is the Layerscape Linux Distribution POC (LLDP) based on Yocto. Unlike the LSDK (which uses Flexbuild), LLDP uses Yocto/Bitbake and is the long-term supported path. 1 Host Requirements Requirement Details Operating System Ubuntu 20.04 LTS (Focal) — official recommendation RAM Minimum 8 GB (16 GB+ recommended) Disk Space Minimum 100 GB free CPU Minimum 4 cores (more cores = faster builds) Tools git, repo, python3, wget, curl, build-essential Install dependencies on Ubuntu: sudo apt-get update && sudo apt-get install -y  gawk wget git diffstat unzip texinfo gcc-multilib \   build-essential chrpath socat cpio python3 python3-pip  python3-pexpect xz-utils debianutils iputils-ping \   python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev  pylint xterm rsync curl locales zstd liblz4-tool \   repo ca-certificates # Configure git (required by repo) git config --global user.name "Your Name" git config --global user.email "[email protected]" 2 Download the LLDP Repository (Yocto for LS1028A) # Create working directory mkdir ~/lldp-ls1028a && cd ~/lldp-ls1028a # Initialize repo with the LLDP manifest (Kirkstone, kernel 5.15) repo init -u https://github.com/nxp-qoriq/yocto-sdk.git \           -b kirkstone \           -m ls-5.15.71-2.2.0_distro.xml # Sync all repositories (may take 30-60 minutes) repo sync Note: For the latest version (LLDP L6.1.1, kernel 6.1), check the updated manifest at: https://github.com/nxp-qoriq/yocto-sdk 3 Set Up the Build Environment for LS1028A # Initialize Yocto environment for the LS1028A # (run from the lldp-ls1028a/ directory) DISTRO=fsl-qoriq-distro MACHINE=ls1028ardb source distro-setup-env # This automatically creates and enters the build directory # You are now in: ~/lldp-ls1028a/build_ls1028ardb/ 4 local.conf File — GPU Configuration The conf/local.conf file inside the build directory controls compilation options. For the LS1028A with GPU, verify or add: # Edit the configuration file nano conf/local.conf Key parameters for GPU and desktop: # Target machine MACHINE = "ls1028ardb" # Distribution with GPU and Wayland support DISTRO = "fsl-qoriq-distro" # Enable display and GPU features DISTRO_FEATURES:append = " wayland opengl" # GPU driver: use Etnaviv (open-source) for LS1028A # DO NOT use imx-gpu-viv (i.MX only, requires ARCH_MXC) PREFERRED_PROVIDER_virtual/libgl = "mesa" PREFERRED_PROVIDER_virtual/libgles1 = "mesa" PREFERRED_PROVIDER_virtual/libgles2 = "mesa" PREFERRED_PROVIDER_virtual/egl = "mesa" # Enable OpenCL support via Vivante GPU IMAGE_INSTALL:append = " clinfo" # Accept NXP proprietary licenses (required for GPU firmware) LICENSE_FLAGS_ACCEPTED = "nxp-proprietary" # Parallel build threads (adjust to your host PC) BB_NUMBER_THREADS = "8" PARALLEL_MAKE = "-j8" # (Optional) Use ccache to speed up recompilations INHERIT += "ccache" 5 Required Yocto Layers (bblayers.conf) Verify that conf/bblayers.conf includes these layers: cat conf/bblayers.conf It must contain at least: BBLAYERS ?= " \   ${BSPDIR}/sources/poky/meta \   ${BSPDIR}/sources/poky/meta-poky \   ${BSPDIR}/sources/meta-openembedded/meta-oe \   ${BSPDIR}/sources/meta-openembedded/meta-multimedia \   ${BSPDIR}/sources/meta-openembedded/meta-python \   ${BSPDIR}/sources/meta-openembedded/meta-networking \   ${BSPDIR}/sources/meta-freescale \   ${BSPDIR}/sources/meta-qoriq \   ${BSPDIR}/sources/meta-nxp-desktop \ " The meta-nxp-desktop layer is what provides GPU support for the LS1028A with the ls-image-desktop image. 6 Build the Image with GPU Support # Recommended: Desktop image with full GPU support (LS1028A only) # Includes: GNOME desktop, Weston/Wayland, Vivante GPU drivers, OpenCL bitbake ls-image-desktop # Alternative: download all packages first before building # (useful for catching network errors before the long build) bitbake ls-image-desktop --runall fetch bitbake ls-image-desktop # Minimal: main image without desktop (no GPU by default) bitbake ls-image-main # Lite: minimal image bitbake ls-image-lite Estimated build time: Between 4 and 8 hours on the first build (depending on host hardware). Incremental builds are much faster. 7 Install the Image to the SD Card After compilation, output files are located in: tmp/deploy/images/ls1028ardb/ # Identify the SD card (verify with lsblk) lsblk # Install image using flex-installer (included in the SDK) flex-installer \   -b tmp/deploy/images/ls1028ardb/boot_ls1028ardb.tgz \   -f tmp/deploy/images/ls1028ardb/firmware_ls1028ardb_sdboot.img \   -r tmp/deploy/images/ls1028ardb/ls-image-desktop-ls1028ardb.tar.zst \   -d /dev/sdX    # replace with your SD device Practical Example: OpenCL Application on LS1028A This example shows how to compile and run a program that uses the GC7000UL GPU to add two vectors with OpenCL. 8.1 Source Code: vector_add.cl (OpenCL Kernel) Create the kernel file on the LS1028A board: # On the LS1028A (via serial or SSH) cat > /home/root/vector_add.cl << 'EOF' __kernel void vector_add(     __global const float* a,     __global const float* b,     __global float* c,     const int n) {     int gid = get_global_id(0);     if (gid < n) {         c[gid] = a[gid] + b[gid];     } } 8.2 Source Code: vector_add.c (OpenCL Host) cat > /home/root/vector_add.c << 'EOF' #include #include #include #include #define VECTOR_SIZE 1024 int main() {     cl_platform_id   platform;     cl_device_id     device;     cl_context       context;     cl_command_queue queue;     cl_program       program;     cl_kernel        kernel;     cl_mem           buf_a, buf_b, buf_c;     cl_int           err;     // 1. Get Vivante GPU platform and device     err = clGetPlatformIDs(1, &platform, NULL);     err = clGetDeviceIDs(platform, CL_DEVICE_TYPE_GPU, 1, &device, NULL);     // Print device name     char device_name[128];     clGetDeviceInfo(device, CL_DEVICE_NAME, sizeof(device_name), device_name, NULL);     printf("GPU detected: %s\n", device_name);     // 2. Create context and command queue     context = clCreateContext(NULL, 1, &device, NULL, NULL, &err);     queue   = clCreateCommandQueue(context, device, 0, &err);     // 3. Read kernel source from file     FILE* f = fopen("vector_add.cl", "r");     fseek(f, 0, SEEK_END);     size_t src_size = ftell(f);     rewind(f);     char* src=(char*)malloc(src_size + 1);     fread(src, 1, src_size, f);     src[src_size] = '\0';     fclose(f);     // 4. Compile OpenCL program     program = clCreateProgramWithSource(context, 1, (const char**)&src, &src_size, &err);     err = clBuildProgram(program, 1, &device, NULL, NULL, NULL);     if (err != CL_SUCCESS) {         char log[2048];         clGetProgramBuildInfo(program, device, CL_PROGRAM_BUILD_LOG,                               sizeof(log), log, NULL);         printf("Compilation error:\n%s\n", log);         return 1;     }     kernel = clCreateKernel(program, "vector_add", &err);     // 5. Prepare input data     float* h_a = (float*)malloc(VECTOR_SIZE * sizeof(float));     float* h_b = (float*)malloc(VECTOR_SIZE * sizeof(float));     float* h_c = (float*)malloc(VECTOR_SIZE * sizeof(float));     for (int i = 0; i < VECTOR_SIZE; i++) {         h_a[i] = (float)i;         h_b[i] = (float)(VECTOR_SIZE - i);     }     // 6. Create GPU buffers     buf_a = clCreateBuffer(context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR,                            VECTOR_SIZE * sizeof(float), h_a, &err);     buf_b = clCreateBuffer(context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR,                            VECTOR_SIZE * sizeof(float), h_b, &err);     buf_c = clCreateBuffer(context, CL_MEM_WRITE_ONLY,                            VECTOR_SIZE * sizeof(float), NULL, &err);     // 7. Set kernel arguments and execute on GPU     int n = VECTOR_SIZE;     clSetKernelArg(kernel, 0, sizeof(cl_mem), &buf_a);     clSetKernelArg(kernel, 1, sizeof(cl_mem), &buf_b);     clSetKernelArg(kernel, 2, sizeof(cl_mem), &buf_c);     clSetKernelArg(kernel, 3, sizeof(int), &n);     size_t global_size = VECTOR_SIZE;     err = clEnqueueNDRangeKernel(queue, kernel, 1, NULL,                                   &global_size, NULL, 0, NULL, NULL);     clFinish(queue);     // 8. Read result     clEnqueueReadBuffer(queue, buf_c, CL_TRUE, 0,                         VECTOR_SIZE * sizeof(float), h_c, 0, NULL, NULL);     // 9. Verify result (each element should equal VECTOR_SIZE = 1024)     int ok = 1;     for (int i = 0; i < VECTOR_SIZE; i++) {         if (h_c[i] != (float)VECTOR_SIZE) { ok = 0; break; }     }     printf("Result: %s\n", ok ? "CORRECT - GPU works!" : "CALCULATION ERROR");     printf("Example: a[0]=%.0f + b[0]=%.0f = c[0]=%.0f\n",            h_a[0], h_b[0], h_c[0]);     // Free resources     clReleaseMemObject(buf_a); clReleaseMemObject(buf_b); clReleaseMemObject(buf_c);     clReleaseKernel(kernel); clReleaseProgram(program);     clReleaseCommandQueue(queue); clReleaseContext(context);     free(h_a); free(h_b); free(h_c); free(src);     return 0; } 8.3 Compile and Run on the LS1028A On the LS1028A board (connected via serial or SSH): # Install build tools and OpenCL headers apt-get install -y gcc clinfo ocl-icd-libopencl1 opencl-headers # Compile gcc -o vector_add vector_add.c -lOpenCL -I/usr/include # Run ./vector_add Expected output: GPU detected: Vivante OpenCL Device GC7000UL.6202.0000 Result: CORRECT - GPU works! Example: a[0]=0 + b[0]=1024 = c[0]=1024 12.4 Yocto Recipe to Include the Example in the Image To include the example directly in the Yocto image, create a recipe in your custom layer: mkdir -p ~/lldp-ls1028a/sources/meta-my-layer/recipes-examples/opencl-vector/files cp vector_add.c vector_add.cl \    ~/lldp-ls1028a/sources/meta-my-layer/recipes-examples/opencl-vector/files/ Recipe file opencl-vector_1.0.bb: SUMMARY = "OpenCL vector addition example for LS1028A GPU" LICENSE = "MIT" LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302" SRC_URI = "file://vector_add.c \            file://vector_add.cl" DEPENDS = "virtual/opencl-icd opencl-headers" S = "${WORKDIR}" do_compile() {     ${CC} ${CFLAGS} -o vector_add vector_add.c -lOpenCL ${LDFLAGS} } do_install() {     install -d ${D}${bindir}     install -m 0755 vector_add ${D}${bindir}/     install -d ${D}/home/root     install -m 0644 vector_add.cl ${D}/home/root/ } FILES:${PN} += "/home/root/vector_add.cl" Add to local.conf and rebuild: IMAGE_INSTALL:append = " opencl-vector" bitbake ls-image-desktop Practical Example: OpenGL ES Rendering with Wayland/Weston This example shows how to render an animated triangle using OpenGL ES 2.0 with EGL on the Weston (Wayland) compositor — the standard "Hello World" of embedded graphics on the GC7000UL GPU. 9.1 Graphics Stack Diagram C Application      ↓ OpenGL ES 2.0  (libGLESv2.so — Vivante GC7000UL)      ↓ EGL 1.4        (libEGL.so — interface between GLES and Wayland)      ↓ Wayland Client (libwayland-client, libwayland-egl)      ↓ Weston Compositor (DRM/KMS + Mali-DP500)      ↓ DisplayPort → 4K Monitor 9.2 Install Dependencies On the LS1028A (with ls-image-desktop): apt-get install -y libgles2-mesa-dev libegl1-mesa-dev libwayland-dev libwayland-egl-backend-dev gcc pkg-config 9.3 Source Code: triangle_gles.c cat > /home/root/triangle_gles.c << 'EOF' /**  * OpenGL ES 2.0 + EGL + Wayland example  * Renders a colored spinning triangle on the Vivante GC7000UL GPU of the LS1028A  * Compile: gcc -o triangle_gles triangle_gles.c -lwayland-client -lwayland-egl -lEGL -lGLESv2 -lm  */ #include #include #include #include #include #include #include #include #define WIDTH  800 #define HEIGHT 600 static struct wl_display       *wl_display    = NULL; static struct wl_compositor    *wl_compositor = NULL; static struct wl_shell         *wl_shell      = NULL; static struct wl_surface       *wl_surface    = NULL; static struct wl_shell_surface *shell_surface = NULL; static struct wl_egl_window    *egl_window    = NULL; static EGLDisplay egl_display; static EGLContext egl_context; static EGLSurface egl_surface; static const char *vertex_shader_src=     "attribute vec2 a_position;          \n"     "attribute vec3 a_color;             \n"     "varying vec3 v_color;               \n"     "uniform float u_angle;              \n"     "void main() {                       \n"     "  float c = cos(u_angle);           \n"     "  float s = sin(u_angle);           \n"     "  vec2 rot = vec2(                  \n"     "    a_position.x*c - a_position.y*s,\n"     "    a_position.x*s + a_position.y*c \n"     "  );                                \n"     "  gl_Position = vec4(rot, 0.0, 1.0);\n"     "  v_color = a_color;                \n"     "}                                   \n"; static const char *fragment_shader_src=     "precision mediump float;            \n"     "varying vec3 v_color;               \n"     "void main() {                       \n"     "  gl_FragColor = vec4(v_color, 1.0);\n"     "}                                   \n"; /* Vertices: position (x,y) + color (r,g,b) */ static const float vertices[] = {      0.0f,  0.8f,  1.0f, 0.0f, 0.0f,   /* Top    - Red   */     -0.7f, -0.5f,  0.0f, 1.0f, 0.0f,   /* Left   - Green */      0.7f, -0.5f,  0.0f, 0.0f, 1.0f,   /* Right  - Blue  */ }; static void registry_global(void *data, struct wl_registry *reg,                              uint32_t name, const char *iface, uint32_t ver) {     if (strcmp(iface, "wl_compositor") == 0)         wl_compositor = wl_registry_bind(reg, name, &wl_compositor_interface, 1);     else if (strcmp(iface, "wl_shell") == 0)         wl_shell = wl_registry_bind(reg, name, &wl_shell_interface, 1); } static void registry_global_remove(void *d, struct wl_registry *r, uint32_t n) {} static const struct wl_registry_listener registry_listener = {     registry_global, registry_global_remove }; static GLuint compile_shader(GLenum type, const char *src) {     GLuint shader = glCreateShader(type);     glShaderSource(shader, 1, &src, NULL);     glCompileShader(shader);     GLint ok; glGetShaderiv(shader, GL_COMPILE_STATUS, &ok);     if (!ok) {         char log[512]; glGetShaderInfoLog(shader, 512, NULL, log);         printf("Shader error: %s\n", log); exit(1);     }     return shader; } int main() {     wl_display = wl_display_connect(NULL);     if (!wl_display) { printf("Error: could not connect to Wayland\n"); return 1; }     struct wl_registry *registry = wl_display_get_registry(wl_display);     wl_registry_add_listener(registry, &registry_listener, NULL);     wl_display_dispatch(wl_display);     wl_display_roundtrip(wl_display);     wl_surface = wl_compositor_create_surface(wl_compositor);     shell_surface = wl_shell_get_shell_surface(wl_shell, wl_surface);     wl_shell_surface_set_toplevel(shell_surface);     egl_display = eglGetDisplay((EGLNativeDisplayType)wl_display);     eglInitialize(egl_display, NULL, NULL);     eglBindAPI(EGL_OPENGL_ES_API);     EGLint config_attribs[] = {         EGL_SURFACE_TYPE,    EGL_WINDOW_BIT,         EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,         EGL_RED_SIZE,   8, EGL_GREEN_SIZE, 8,         EGL_BLUE_SIZE,  8, EGL_ALPHA_SIZE, 0,         EGL_DEPTH_SIZE, 16, EGL_NONE     };     EGLConfig egl_config; EGLint num_configs;     eglChooseConfig(egl_display, config_attribs, &egl_config, 1, &num_configs);     EGLint ctx_attribs[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };     egl_context = eglCreateContext(egl_display, egl_config, EGL_NO_CONTEXT, ctx_attribs);     egl_window  = wl_egl_window_create(wl_surface, WIDTH, HEIGHT);     egl_surface = eglCreateWindowSurface(egl_display, egl_config,                                           (EGLNativeWindowType)egl_window, NULL);     eglMakeCurrent(egl_display, egl_surface, egl_surface, egl_context);     printf("GPU: %s\n", glGetString(GL_RENDERER));     printf("OpenGL ES Version: %s\n", glGetString(GL_VERSION));     GLuint vs = compile_shader(GL_VERTEX_SHADER,   vertex_shader_src);     GLuint fs = compile_shader(GL_FRAGMENT_SHADER, fragment_shader_src);     GLuint program = glCreateProgram();     glAttachShader(program, vs); glAttachShader(program, fs);     glLinkProgram(program); glUseProgram(program);     GLint pos_loc   = glGetAttribLocation(program,  "a_position");     GLint color_loc = glGetAttribLocation(program,  "a_color");     GLint angle_loc = glGetUniformLocation(program, "u_angle");     glViewport(0, 0, WIDTH, HEIGHT);     float angle = 0.0f;     int frames = 0;     printf("Rendering spinning triangle (Ctrl+C to exit)...\n");     while (1) {         wl_display_dispatch_pending(wl_display);         glClearColor(0.1f, 0.1f, 0.15f, 1.0f);         glClear(GL_COLOR_BUFFER_BIT);         glUniform1f(angle_loc, angle);         glEnableVertexAttribArray(pos_loc);         glVertexAttribPointer(pos_loc,   2, GL_FLOAT, GL_FALSE, 5*sizeof(float), vertices);         glEnableVertexAttribArray(color_loc);         glVertexAttribPointer(color_loc, 3, GL_FLOAT, GL_FALSE, 5*sizeof(float), vertices + 2);         glDrawArrays(GL_TRIANGLES, 0, 3);         eglSwapBuffers(egl_display, egl_surface);         angle += 0.02f;         if (angle > 6.2832f) angle -= 6.2832f;         frames++;         if (frames % 300 == 0)             printf("Frame %d — angle: %.2f rad\n", frames, angle);     }     eglDestroyContext(egl_display, egl_context);     eglDestroySurface(egl_display, egl_surface);     eglTerminate(egl_display);     wl_display_disconnect(wl_display);     return 0; } 9.4 Compile and Run # Compile gcc -o triangle_gles triangle_gles.c \     -lwayland-client -lwayland-egl \     -lEGL -lGLESv2 -lm # Make sure Weston is running and set Wayland environment export XDG_RUNTIME_DIR=/run/user/0 export WAYLAND_DISPLAY=wayland-0 # Run ./triangle_gles Expected terminal output: GPU: Vivante GC7000UL OpenGL ES Version: OpenGL ES 3.1 V6.4.3.p4.398061 Rendering spinning triangle (Ctrl+C to exit)... Frame 300 — angle: 6.00 rad Frame 600 — angle: 5.68 rad A RGB triangle spinning on a dark background will appear on screen, rendered by the GC7000UL GPU. Bio_TICFSL_0-1789407894776.pngBio_TICFSL_0-1789407894776.png 9.5 Yocto Recipe SUMMARY = "OpenGL ES 2.0 spinning triangle example — LS1028A" LICENSE = "MIT" LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302" SRC_URI = "file://triangle_gles.c" DEPENDS = "virtual/libgles2 virtual/egl wayland" S = "${WORKDIR}" do_compile() {     ${CC} ${CFLAGS} -o triangle_gles triangle_gles.c \         -lwayland-client -lwayland-egl -lEGL -lGLESv2 -lm ${LDFLAGS} } do_install() {     install -d ${D}${bindir}     install -m 0755 triangle_gles ${D}${bindir}/ } 9.6 Yocto Recipe for OpenCV with GPU Add to local.conf: IMAGE_INSTALL:append = " opencv python3-opencv" PACKAGECONFIG:append:pn-opencv = " opencl" bitbake ls-image-desktop Regards
記事全体を表示
EL2 Monitor: Simplifying Software Partitioning for Automotive Safety Systems The automotive industry is undergoing a fundamental architectural shift. Where vehicles once relied on dozens of dedicated ECUs — one function, one controller — modern designs are consolidating multiple software functions onto a single, powerful processor. This consolidation reduces cost, weight, and complexity, but it introduces a critical challenge: how do you run a safety-critical AUTOSAR brake control application on the same chip as a less-critical body control stack, and guarantee they can never interfere with each other? Full hypervisors are one answer — but they come with significant drawbacks. They are complex to integrate, expensive to license, difficult to certify to ISO 26262, and introduce latency that real-time systems cannot tolerate. NXP's EL2 Monitor (EL2M) was designed to solve exactly this problem: delivering robust, hardware-enforced software isolation with the simplicity, determinism, and safety pedigree that automotive programs demand. What Is EL2 Monitor? EL2 Monitor is a partitioning hypervisor that runs at Exception Level 2 (EL2) — the hypervisor privilege level defined by the Arm® architecture — on Arm® Cortex®-R52 cores. It sits between the hardware and the application software, acting as a lightweight isolation layer that enforces strict boundaries between software partitions running on the same processor. In simple terms: EL2 Monitor takes a single physical processor and divides it into independent, isolated software environments — called R52 partitions — each running its own RTOS instance with exclusive access to its assigned resources. A fault, crash, or security breach in one partition cannot affect any other. Unlike a full hypervisor, EL2 Monitor does not perform CPU scheduling, device virtualization, or dynamic resource management. Its scope is deliberately narrow: isolate partitions, protect shared hardware resources, and do so in a way that is statically configured, deterministic, and certifiable to ASIL D. This focused design philosophy is what makes it practical for production automotive programs. The Core Problem: The Shared GIC Distributor To understand why EL2 Monitor exists, it helps to understand a specific hardware constraint of the Arm Cortex-R52 architecture. In an R52-based Real-Time Unit (RTU), every two or four cores share a single GIC (Generic Interrupt Controller) Distributor — the hardware block that routes interrupts to cores. Without protection, any software running on one core has direct access to the GIC Distributor and could — accidentally or maliciously — reroute or disable interrupts belonging to another core's partition. This makes true isolation impossible without a dedicated software layer at EL2. EL2 Monitor fills this gap. It intercepts all GIC Distributor accesses from partitions and virtualizes them, giving each partition its own exclusive Virtual GIC Distributor while the real hardware GIC remains protected. nxf94150_1-1789390949734.png How It Works: Two Virtualization Modes   Trap & Emulate GIC Distributor accesses from EL1 software are automatically trapped to EL2, where EL2 Monitor validates and emulates them. The EL1 application is completely unaware of the virtualization — it behaves as if it has exclusive hardware access. Access operations complete in < 3 µs, making this mode suitable for standard AUTOSAR applications that require zero code changes.   Paravirtualization For performance-sensitive applications, EL2 Monitor provides ready-to-use Arm CMSIS GIC Driver APIs. The EL1 software calls these APIs directly instead of accessing GIC hardware registers. This cooperative approach achieves < 1.5 µs latency — half that of full emulation — while also reducing memory usage and development time. nxf94150_2-1789391007259.png Hardware-Enforced Memory Protection Beyond GIC virtualization, EL2 Monitor uses the EL2 Memory Protection Unit (MPU) to enforce strict memory boundaries between partitions in hardware. Each partition is assigned its own memory regions at configuration time. Even if an EL1 guest OS is compromised, it cannot access memory belonging to another partition. This is complemented by NXP's XRDC (Extended Resource Domain Controller) silicon feature, creating a layered hardware + software protection architecture that is unique to NXP's S32 platform. MRU Channel Isolation EL2 Monitor also virtualizes MRU (Messaging Resource Unit) channels within each R52 partition. Each software entity running at a lower privilege level accesses the MRU through its own dedicated virtualized instance — inter-core communication channels cannot be accessed or corrupted by other software entities. MRU handlers are serviced in < 1.5 µs. Static, Deterministic Configuration All partition assignments — CPU cores, memory regions, peripherals, interrupt routing — are defined at build time using the EB Tresos or S32CT configuration plugins. There is no runtime reconfiguration, no dynamic scheduling, and no hidden shared state. This static model makes system behavior fully predictable, simplifies safety analysis, and keeps the trusted computing base small and auditable. Safety and Quality EL2 Monitor is qualified to ASIL D per ISO 26262:2018 — the highest automotive functional safety integrity level. Development follows NXP's Software Development Process, which is Automotive SPICE 3.1 · IATF 16949:2016 · ISO 26262:2018 · ISO 21434:2021 · ISO 9001:2015 compliant. The complete package delivered to customers includes: Quality Package: SW Traceability Matrix (Req → Design → Code → Tests), Test Specs & Reports at all levels, MISRA/CERT-C/CWE Static Analysis, Code Coverage, Benchmark & Memory Reports Safety Package: Safety Manual, FMEA Software Package: Source code, Release Notes, User Manual, SBOM Development teams do not need to perform their own safety analysis of the partitioning layer — NXP provides the complete collateral, significantly reducing the certification effort for the overall system. Developer Experience: Fits Into Your Existing Workflow EB Tresos and S32CT plugins for AUTOSAR-based configuration S32 Design Studio (S32DS) for build, debug, and deployment Multi-compiler support for toolchain flexibility Sample application included to accelerate first-time integration Available via the NXP software distribution portal (Flexera) 6 on-demand training videos on nxp.com: Hello World, Configuration & Build, RTOS Integration, Download & Install, Tools & Compilers, Support Channels Supported Platforms nxf94150_3-1789392707431.png Why EL2 Monitor — and Why Now? The industry trend toward software-defined vehicles and centralized compute is accelerating. Zonal and domain controllers are replacing distributed ECU networks, and the software running on these controllers is growing in both complexity and safety criticality. The need for a reliable, certified, and cost-effective partitioning solution has never been more urgent. ASIL D certified — highest automotive safety integrity level, full collateral included Simpler than a full hypervisor — static, deterministic, minimal trusted computing base Unique NXP HW+SW stack — XRDC hardware isolation + EL2 Monitor software protection Sub-1.5 µs performance — paravirtualized GIC access Production-ready — full safety collateral, AUTOSAR toolchain integration, multi-platform Explore EL2 Monitor and discover how NXP's partitioning software can help you consolidate your automotive software architecture — safely, simply, and at no additional cost. Learn more about EL2 Monitor on nxp.com » Daniel Hermenczi Product Owner, EL2 Monitor — System Services, Automotive & Edge Solutions, NXP Semiconductors Daniel is a software project manager and product owner for EL2 Monitor and IPCF at NXP Semiconductors, driving roadmap execution and customer deliveries for automotive partitioning and inter-platform communication software. He is based in Sibiu, Romania. As vehicles consolidate more software onto fewer chips, keeping safety-critical functions truly isolated is no longer optional. EL2 Monitor delivers hardware-enforced partitioning for Arm® Cortex®-R52 — without the complexity of a full hypervisor.
記事全体を表示