Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Hello! Thank you for your detailed description and the steps you have already taken. Seamlessly preserving the U-Boot splash screen until your user-space application takes over—especially on i.MX8X with the mxsfb-drm driver and a parallel LCD—can be tricky. You’ve already investigated most of the best-practice options. Let me summarize and add a couple of further suggestions based on the available Toradex documentation and general practices:
Key Steps and Considerations
1. U-Boot Splash Persistence
You’ve already kept the framebuffer content alive by preventing U-Boot from clearing the display buffer (reference), and you’ve also reserved the memory region in the device tree to prevent overwrite by the kernel—this is correct.
2. ** simple-framebuffer Handoff**
Adding a simple-framebuffer node in your Linux device tree is the standard method to pass the splash image from U-Boot to the kernel. Ensure these parameters all match exactly:
- Address
- Format (pixel order, depth)
- Resolution, stride
Any mismatch—especially with BGR666 or custom formats—could cause color or flickering issues. If you had to patch simple-framebuffer for BGR666 support, this increases the risk of format mismatch and flicker.
Tip:
Check that U-Boot and Linux both write and read the framebuffer in precisely the same format and memory alignment. Otherwise, the start of the mxsfb-drm driver may flush or reinitialize the controller, showing artifacts.
3. Disabling Kernel Console Output
Make sure that kernel messages are not being printed to the screen, as these can cause early framebuffers to be invalidated or redrawn (reference). In your U-Boot environment, remove any console=tty1 or similar assignments in your kernel command line:
setenv defargs
saveenv
Or specifically omit framebuffer consoles.
4. DRM/FBDEV Interplay
DRM subsystem initialization often resets the display hardware when starting, which can cause the flicker you see. Setting CONFIG_DRM_FBDEV_EMULATION=n may help, but, as you’ve observed, the flicker comes back when DRM first takes over.
5. Panel Power/Reset Sequence
While direct hardware modification is not advised, review your device tree to ensure:
- Any panel
reset-gpios or enable-gpios are not explicitly toggled by Linux.
- The Linux panel driver does not trigger unnecessary resets unless strictly required.
6. Try a “Dummy” Panel Until App Launch
If the above does not work, consider keeping the simple-framebuffer node active until your application is ready, and only then load/enable the mxsfb-drm and panel drivers. This could be done by delaying the DRM-related modules from loading until your application startup (e.g., disabling the relevant device tree node via status = "disabled"; and re-enabling via overlays or device-tree fragment load at runtime—but this is advanced and not always practical on i.MX8X mainline).
7. Avoid Multiple Initializations
The instability you see when “skipping clock disable” or “CRTC atomic enable” likely results from the state getting out of sync if the hardware/driver expects clean resets. That approach may create new, subtle issues down the line.
Summary of Best Practices
- Perfectly match framebuffer formats and addresses between U-Boot and Linux.
- Use a
simple-framebuffer node and keep mxsfb-drm idle until your app is ready—if possible.
- Prevent the kernel from writing to framebuffer before your app starts (disable console output).
- Do NOT patch DRM/mxsfb/workflow with conditional disables—this usually leads to fragility.
If you’ve done all the above and still see artifacts, it may be an inherent limitation in how the mxsfb-drm driver resets hardware or sequences clocking. For some hardware generations, completely seamless transition is not possible until the in-kernel driver handoff becomes more “handoff aware.”
You might find these resources helpful for additional context and configuration examples:
If you are able to share the relevant sections of your device trees here (panel/lcdif/simple-framebuffer nodes), I can check for format or configuration mismatches that could be tweaked for stability.
Best regards,
Toradex AI Assistant.
