I am trying to display a static image on the LT161010 display from U-Boot.
I’m using a Colibri iMX8X with the Iris carrier board and have the display working with a modified version of the v7.2.0 reference image
I have seen this post and this post so I’m aware that Toradex does not provide a general solution to this, but I wonder if I could get some input on my specific attempt.
I am building u-boot-toradex_2024.04
I have patched colibri-imx8x_defconfig to add CONFIG_DM_VIDEO=y
I have attempted to patch the u-boot device tree to define the lcdif and panel. 0001-enable-lcdif.patch (4.2 KB)
My patch is attached, but in short I’m attempting to use the simple-panel driver because the drm/kms drivers used in the Linux kernel do not exist in u-boot.
The result of this is that nothing changes, the display is still blank until the user-space splash.
Is my attempt reasonable, should it be possible to use the simple-panel driver with the LT161010?
How can I inspect the result of my changes? (In Linux I can look at /proc/config.gz and /proc/device-tree)
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 and thank you for your detailed description of your setup and efforts so far!
Your questions and observations are excellent. Let’s address them point by point for your Colibri iMX8X on the Iris carrier board with the LT161010 display.
1. Is It Possible to Use the simple-panel Driver in U-Boot on iMX8X?
Unfortunately, the current limitations of U-Boot for iMX8-based modules—including the Colibri iMX8X—make what you’re attempting not feasible at this point:
Mainline U-Boot does not support video output on i.MX8-based modules. The U-Boot video subsystem and drivers you find for i.MX6 and earlier are not yet available or functional for iMX8 SoCs.
The simple-panel approach you outlined was effective with i.MX6 family modules, but iMX8 devices lack the LCDIF/DRM/KMS infrastructure in U-Boot to support this as you’re expecting.
This means your approach is technically sound, but it is not currently possible due to upstream and Toradex U-Boot limitations:
Mainline U-Boot doesn’t support video displays on i.MX8-based modules (reference).
2. Inspecting Your Changes in U-Boot
Config Options: You can check that CONFIG_DM_VIDEO is enabled by interrupting the U-Boot autoboot and using the console to query environment/config settings. However, since the display subsystem isn’t supported, you won’t see any effect even with the option enabled.
Device Tree: Likewise, while you can patch in the device tree nodes, U-Boot on iMX8 won’t process these for display hardware at this time.
For more detail on U-Boot console access and inspecting configuration, see: The U-Boot Console
3. Suggestions for Next Steps
Since U-Boot splash is not supported for iMX8 (including Colibri iMX8X):
Early Userspace Splash: The practical workaround is to show your splash image as early as possible from user space. You might use a custom systemd service or script to display your image as soon as the framebuffer becomes available.
Optimize Boot: Reduce system boot time so that your user-space splash appears quickly. This is currently the recommended approach for iMX8 modules. Discussion and alternatives
Thank you for the link to this post.
It seems to describe a successful method to enable a splash screen from U-Boot on the iMX8 platform, although with LVDS rather than RGB.
I will spend some time understanding that method.
Inspecting Your Changes in U-Boot
I don’t think any of the U-Boot console commands allow inspecting the kernel config or device tree used to build U-Boot.
If I’m incorrect, could you provide a specific example?
If I understand correctly, the LT161010 uses a parallel RGB interface, doesn’t it? Looking into the UBoot source code, it does not have support for i.MX8X processor. Therefore, getting it working would be difficult. LVDS could work (with the same driver that worked with iMX8QM), as you saw in the post that you found before, but you need to test it. That would mean you will have to switch to an LVDS display.
I don’t think any of the U-Boot console commands allow inspecting the kernel config or device tree used to build U-Boot.
If I’m incorrect, could you provide a specific example?
You cannot inspect kernel configs from uboot, however, this is how you can inspect the device tree in U-Boot:
Verdin iMX8MP # fdt addr $fdtcontroladdr
Working FDT set to 55adfc60
Verdin iMX8MP # fdt print
Also, with dm tree command you can inspect the modules that are loaded: dm tree
Thank you for those U-boot commands. I had not seen them and I’m sure they’ll be useful.
You are correct the LT161010 is a parallel RGB display.
I was quite encouraged that @henrique.tx had used the same simple-panel method as me. I’ve been working through those patches and applying to parts that seem relevant.
In my case I don’t need the LVDS support or the backlight (because we’ve wired up the backlight independently).
This is the patch I’m currently working on. I still have no display output from U-boot but it certainly seems to be heading in the right direction. 0002-lt161010-lcdif.patch (7.6 KB)
I currently have the toradex.bmp splash loaded in my bootfs and am attempting to use the U-boot bmp command to display it at runtime, per this article.
Here is a U-boot log, with debug output enabled, from boot up to the bmp display command. u-boot.log (102.8 KB)
I can see the simple-panel and msxfb drivers are loaded as I intended.
I’m not certain if my clock settings are correct, because of these lines:
clk_set_defaults(lcdifgrp)
clk_set_default_parents: could not read assigned-clock-parents for 00000000bc513790
This suggests the device-tree for lcdif@5a180000 incorrect, so I will continue investigating there.
If you have any more input, or if @henrique.tx remembers encountering similar results when he was working on the LVDS patch, then I would be grateful to hear it.
Which suggests a problem with lcdifgrp defined in my patch.
But I’ve ported that from my working kernel device tree so again I’m not sure what the problem is.
Any input on either of those errors (or anything else that stands out in the log)?
I’ve taken a further look at the sc_err_to_linux 1 -22 lines.
These come from the function imx8_scu_call(), but each error has a corresponding successful call. I can’t pin down why imx8_scu_call() runs twice for each pin, but after seeing that one of them succeeds I moved on for now.
The mxsfb driver seems to require a display property, a sub-node doesn’t match. However if I create a separate node for the display and add a property with a reference to that node, U-boot hangs as soon as it reaches the console.
My patch now includes a bunch of debug that will have to cleaned up at some point, but here is the latest: 0002-toradex-lcdif.patch (12.2 KB)
And here is a log from that patch: u-boot.log (164.1 KB)
The mxsfb driver behaviour confuses me, as it doesn’t seem to match the documentation so I’ll probably start by looking at that driver in the linux kernel tomorrow.
Debugging driver issues of this nature often requires significant effort. Therefore, do not expect a simple “enable and display” solution. As we do not support splash screen display in U-Boot, we can unfortunately not provide direct assistance with this.
I was eventually able to get the splash screen working from U-Boot.
As @henrique.tx found in his Apalis patches, nothing too special is required but it took a fair amount of work to get to that point.
Here is my patch, just displaying the default U-Boot logo, which I applied on top of 5c6f89c91d3d631af5c5d1ba198b620fceb138e2 of Index of /u-boot-toradex.git
