Preserve U-Boot splash on Colibri-iMX6DL

Technical Support
, , ,
1

I have a Colibri iMX6DL running a custom version of Toradex BSP 7.2
I have U-Boot configured to show a splash screen and Linux configured to drive a parallel display, both working fine individually.
However between U-Boot jumping to the kernel and my user-space application running the display goes blank.
I would like to preserve the U-Boot splash screen until my application runs.

I have done this before on the iMX8X, my strategy was to prevent U-Boot from disabling the driver, reserve the U-Boot framebuffer memory in the Linux device tree and then have the mxsfb driver re-use that framebuffer.

Trying the same strategy on the iMX6DL I am able to prevent U-Boot from disabling the driver, and to reserve the U-Boot framebuffer.
However I can’t find a way to have the imx-drm driver re-use the framebuffer, it always creates its own buffer(s).

Has anyone else worked on this problem? Is there a method to pass an existing buffer to a DRM driver? Is this even the right way to tackle this problem?

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

i.MX6 DRM Driver Behavior and Framebuffer Reuse

Based on the available documentation, the challenge you’re experiencing with the imx-drm driver on Colibri iMX6DL is well-documented. The imx-drm driver has specific limitations regarding framebuffer reuse that differ from other platforms.

Key Limitations with i.MX6 DRM

The i.MX6 DRM implementation creates its own framebuffer buffers and doesn’t provide a straightforward mechanism to reuse existing U-Boot framebuffers (1). This is a known limitation of the current imx-drm driver architecture.

Alternative Approaches for i.MX6

For i.MX6-based modules, the documentation suggests working with the framebuffer configuration through kernel command line parameters (1):

"video=mxcfb<number>:dev=<Output>,<Mode Specifier>,if=<Output Format>,[bpp=<Framebuffer Depth>]"

For parallel RGB displays, you would use:

video=mxcfb0:dev=lcd,EDT-WVGA,if=RGB24

Device Tree Memory Reservation

You can reserve memory regions in the device tree as you’ve done before (2). The /reserved-memory node can be defined at SoC or SoM level:

/reserved-memory

However, the imx-drm driver’s behavior of creating its own buffers means this reserved memory approach may not work as expected with the DRM subsystem.

Framebuffer vs DRM Considerations

The documentation notes an important limitation: “The Vivante X driver can only make use of the first framebuffer /dev/fb0 while the others can be used through the fbdev framebuffer interface” (1). This suggests that applications using DRM may face different constraints than those using the traditional framebuffer interface.

Community Discussion

There has been discussion in the community about similar challenges with i.MX6 DRM drivers, particularly regarding color depth and framebuffer management (3). The consensus indicates that the imx-drm driver has architectural limitations that make framebuffer reuse difficult.

Recommended Approach

Given the documented limitations of the imx-drm driver on i.MX6, you might need to consider:

  1. Using the traditional mxcfb framebuffer interface instead of DRM if your application allows it
  2. Implementing a custom solution that works with the DRM driver’s buffer allocation behavior
  3. Exploring kernel-level modifications to the imx-drm driver (though this would require significant development effort)

The approach that worked on i.MX8X unfortunately doesn’t translate directly to i.MX6DL due to the different driver architectures and capabilities.

**

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

I am indeed using a reserved-memory node to preserve the U-Boot framebuffer.
I am only attempting to use /dev/fb0 (and indeed, CAN use /dev/fb0) so I don’t think that reference is relevant, at any rate it comes from an older BSP.

I’m not sure what the AI is suggesting with the command line parameters. My parallel display is already working and those parameters don’t provide any additional information.

Likewise the community post referenced seems to be about getting the parallel display working in the first place, not about framebuffer reuse.

I have not explored using the mxcfb driver on the iMX6, since the BSP already provides a device tree configured to use imx-drm, but I suppose that would be possible.

I am currently looking at modifications to the imx-drm driver, but I’m not very familiar with the drm subsystem.

Any input on where to make changes, or a general approach, would be helpful.

4

Based on the available documentation and your specific requirements for preserving the U-Boot framebuffer with the imx-drm driver on Colibri iMX6DL, you’re facing a well-documented architectural challenge.

DRM Driver Buffer Allocation Behavior

The community discussion confirms that the imx-drm driver on i.MX6 “always creates its own buffer(s)” and doesn’t provide a straightforward mechanism for reusing existing framebuffers (1). This is indeed a driver limitation rather than a hardware restriction (1).

Potential DRM Subsystem Modification Approach

Since you’re exploring modifications to the imx-drm driver, the key areas to investigate would be:

  1. Buffer allocation during DRM initialization - The driver typically allocates its own framebuffer memory during the modeset process
  2. Memory mapping in the DRM framework - Look for where the driver maps physical memory to the DRM framebuffer objects
  3. Integration with reserved memory - You’ll need to modify how the driver handles memory allocation to use your reserved region instead

Alternative: mxcfb Driver Consideration

For BSP 7.x on i.MX6, the documentation shows that the traditional mxcfb framebuffer interface was available in earlier kernel versions (2). The mxcfb driver supported direct framebuffer access through /dev/fb0 and had more straightforward memory management that might be more compatible with your framebuffer preservation approach (2).

However, transitioning from imx-drm back to mxcfb would require significant device tree modifications and potentially kernel configuration changes.

Framebuffer Console Considerations

The documentation provides some insights on framebuffer console management that might be relevant (3). You could explore disabling the framebuffer console entirely during the transition period to prevent conflicts:

# systemctl disable getty@tty1.service

(3)

Or use kernel parameters to redirect console output away from your display framebuffer (3).

Summary

Unfortunately, the available documentation confirms that achieving framebuffer reuse with imx-drm on i.MX6DL requires kernel driver modifications, as there’s no documented standard mechanism for this functionality (1). The driver architecture differences between i.MX6 and i.MX8X explain why your previous approach doesn’t translate directly.

Your current path of exploring imx-drm driver modifications is likely the most viable approach, though it requires deep DRM subsystem knowledge.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

Hi @SamM,

I’m working on this topic at the moment. I will also need to a look a bit deeper into the imx-drm driver and also check if there are any upstream implementations already. I will update you soon.

6

Hi Rudhi,

I’ll definitely be interested to hear what you find.
I’ve realised my original strategy was bad. I don’t need the imx-drm driver to use the same framebuffer as U-Boot. It is enough to avoid committing to the new framebuffer until there is something to display.

I’ve been able to determine where imx-drm creates the framebuffer (drm_fbdev_dma.c), and at that point I can copy my splash out of the original framebuffer and into the drm framebuffer and it appears on the screen. That reduces the time my screen is blank, but is too hacky for me to consider it a solution.

I’m now getting my head around the hardware registers, with the aim of just keeping the U-Boot framebuffer active until imx-drm is ready to take over.