i.MX ProcessorsのトピックRe: i.MX8QXP: Recommended architecture for display variant selection during AB FOTA when display ID

i.MX8QXP: Recommended architecture for display variant selection during AB FOTA when display ID

Ram2 — Wed, 06 May 2026 06:38:30 GMT

Hi NXP Team,

Greetings to All,

Product: i.MX8QXP
Platform: Custom board based on i.MX8QXP / i.MX8QXP MEK reference
OS: Yocto Linux
Boot flow: U-Boot → Linux kernel → user-space middleware
OTA: A/B partition-based MPU software update
Display interface: TFT display with touch controller
Issue type: BSP architecture clarification / display driver selection,FOTA handling

We need your recommendation on a BSP architecture concern related to display variant detection and driver selection on an i.MX8QXP-based platform.

We are planning to support two TFT display variants in the same MPU software image due to EOL of the existing display/touch controller IC.

Current display:

H40109-V4

New alternate display:

H40170

The change impacts:

Display driver parameters
Touch driver
Power ON/OFF sequence timing
Possibly display initialization sequence

Currently, display presence/type is detected using a hardware signal named DISP_LOOP_DIAG.

The logic is:

DISP_LOOP_DIAG LOW  → current display H40109-V4
DISP_LOOP_DIAG HIGH → new display H40170

However, this DISP_LOOP_DIAG signal is connected to the VIC/microcontroller side, not directly to the i.MX8QXP MPU.

The VIC communicates with the MPU through our UART-based middleware protocol called TVSMIPC. But TVSMIPC is a user-space middleware service. It becomes available only after the MPU Linux boot is completed and after the UART handshake between VIC and MPU starts.

Because of this, the display type information is not available during early boot, whereas display driver selection, panel timing, bridge configuration, touch driver probing, and display power sequencing are normally handled during U-Boot/kernel/device-tree initialization.

Since the display variant is available only after Linux user-space TVSMIPC starts, what is NXP’s recommended method on i.MX8QXP Yocto BSP to select the correct display DTB/driver during early boot, especially for A/B OTA/FOTA where the first boot after update must be validated successfully?

Re: i.MX8QXP: Recommended architecture for display variant selection during AB FOTA when display ID

AldoG — Fri, 08 May 2026 21:40:02 GMT

Hello,

Your question seems that was created using some kind of AI based tool so I'm not quite sure if this use case scenario is correct or just mere speculation, but anyway, please see below.

Since you are using a custom service using Linux, you may change device tree on the go and then trigger a reset, this is the worst kind of sollution but it is possible.

Another way would be using an available GPIO and have it connected directly to the i.MX8QXP so it is read during SPL so the correct device tree is being used.

Regarding driver for one or another display, I will suggest having both enabled the kernel will use the one that is selected during uboot.

In both cases note that display won't be available during uboot, but later on during kernel initalization.

Best regards/Saludos,
Aldo.

Re: i.MX8QXP: Recommended architecture for display variant selection during AB FOTA when display ID

Ram2 — Thu, 14 May 2026 06:12:10 GMT

Hi @AldoG

Use case is the requirement so in order to put in correct format I have just used AI tool to fetch the information.

Let me give background idea
Currently we have D1 Display variant which is on vehicle , but due to some technical challenges
We are migrating to D2 Display variant . Which will go in to vehicle in next few months.

So consider in Store we have 50 vehicles with D1 samples and 50 vehicles with D2 samples
If we give any upgrade through OTA, for so what could be technical challenges we might face
And in D2 in production we can handle very first boot we will fetch the D2 panel info and will store in the NVM but in D1 still we didn't handle those info

So need to know from your expertise knowledge will it work or will create a bottleneck problem on the vehicle.