How do i get error/debug information from u-boot regarding devicetree conflicts

Technical Support
, , , ,
1

Hi,
i am trying to get lcdif activated in u-boot-toradex
YOCTO toradex 7.2.0 , imx7d emmc 1G module
u-boot 2024.07 (also tried seperate command line make on u-boot-toradex 2025.04)

I got through this
U-boot default internal dtb - Technical Support - Toradex Community

I have this patch and a defconfig that replaces .config
my-defconfig (49.8 KB)
my-imx7d-colibri-emmc-eval-v3.patch (1.4 KB)

one problem might be the order of parsing as imx7d-colibri-emmc-eval-v3-u-boot.dtsi also contains lcdif definition.

I tried to activate logging from u-boot to console and building it seperately with debug enable - but dont see any messages regarding devicetree conflicts.

(unless someone spots my mistakes in the uploaded files)

  • my question is how to debug devicetree loading in u-boot ?

Best Regards - Paul

2

@ToradexAI

Trying more on the standalone u-boot compilation

ADDED:

CONFIG_DEBUG_UART_BASE=0x30860000
CONFIG_DEBUG_UART_CLOCK=24000000
# CONFIG_DEBUG_UART_BOARD_INIT is not set
# CONFIG_DEBUG_LL is not set
CONFIG_DEBUG_UART=y
CONFIG_CC_OPTIMIZE_FOR_DEBUG=y
# CONFIG_TOOLS_DEBUG is not set
# CONFIG_EVENT_DEBUG is not set
# CONFIG_DM_DEBUG is not set
# CONFIG_DEBUG_DEVRES is not set
CONFIG_DEBUG_UART_MXC=y
CONFIG_DEBUG_UART_SHIFT=0
CONFIG_DEBUG_UART_ANNOUNCE=y
# CONFIG_DEBUG_UART_SKIP_INIT is not set
# CONFIG_UBIFS_SILENCE_DEBUG_DUMP is not set

And defined LOG_DEBUG in simple_panel.c - still no additional output

3

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? :+1: :-1:

Hello Paul,

Thank you for providing detailed information about your setup and efforts. Debugging device tree (DT) loading in U-Boot can be challenging, but there are several steps and considerations to help you observe DT handling and diagnose related issues.

1. Verify Device Tree Being Loaded

First, confirm which DTB is being loaded in U-Boot:

printenv fdtfile

This displays the DTB filename U-Boot is using:
U-Boot Environment Variables

2. Ensure Proper DT Overlays and Content

For i.MX7, the DTB is assembled from several DTS/DTSI files. Conflicts can occur if the same node is defined in both your main DTS and a U-Boot-specific include (like *-u-boot.dtsi). It might be helpful to review the final combined DTB using the device tree compiler:

After compilation, decompile your generated DTB to human-readable DTS for inspection:

dtc -I dtb -O dts -o u-boot-parsed.dts u-boot.dtb

Look specifically for the lcdif node to confirm its presence and correctness.

3. Increase Logging for Device Tree Handling

You’ve already enabled extensive CONFIG_DEBUG_UART options and set LOG_DEBUG in simple_panel.c. In U-Boot, much of the DT loading is quiet by default. To get more output:

  • Enable log-level debugging globally:
    In your defconfig, add:

    CONFIG_LOGLEVEL=7

    (Or pass loglevel=7 as a boot argument, though not all U-Boot code honors this.)

  • Verbosity in Device Model (DM):
    Set:

    CONFIG_DM_WARN=y
CONFIG_DM_DEBUG=y

    These could reveal more about device driver binding/probing issues, if device model is used by your driver.

4. Use fdt U-Boot Commands

Interactively inspect the loaded DT in U-Boot:

fdt addr $fdt_addr_r
fdt print /  # Print the root node and inspect children
fdt print /soc/lcdif@...  # Print lcdif node specifically (full path as in your DT)

If the node is missing or incorrect, there’s likely an issue with your DTS/patches or build process.

5. Console Output Issues

If you suspect output isn’t appearing:

  • Verify your UART settings match your carrier board (baud, base address).
  • Ensure CONFIG_DEBUG_UART_BOARD_INIT is enabled if board-specific pinmux/init is needed for early debug output.

Additional References

Summary Checklist

  • Check the loaded DT (printenv fdtfile, fdt print commands in U-Boot).
  • Decompile DTB for review.
  • Increase debugging via CONFIG_LOGLEVEL, CONFIG_DM*, and confirm CONFIG_DEBUG_UART initializes output UART early.
  • Confirm lcdif node does not conflict in both main DTS and *-u-boot.dtsi.
  • Ensure output is not filtered by build options or misconfigured UART.

If you continue not to see logs, please double-check your UART base address and that nothing else is initializing/outputting to the same port early in the boot process.

Best regards,
Toradex AI Assistant.

4

Hello @BDSKPEF,

Just to clarify, are you looking at the u-boot device tree or the linux device tree?

If you are looking at the Linux device tree, the conflicts will be shown at compilation time, as they are resolved in the final device tree.

If you are talking about the u-boot device tree, it is important to remember that the device tree support on u-boot is incomplete.
Therefore, if something that you have in your device tree is not applied, it is likely that you need to do such initialization on the respective board file.
Otherwise, I recommend that you take a look at some of the suggestions from the AI above, as this topic is quite specific to your application and not so much about what software we provide in our BSP.

Best Regards,
Bruno

5

Hi Bruno,

its the u-boot devicetree , wether we leave the default 640x480 definition in the -u-boot.dtsi or define the 1024x600 does not make a difference, there is no lcd activity (measuring PCLK).

We had been using the 2016 u-boot-toradex where logo/splash works by default. The 2024 does not, which is made clear on the toradex homepage.

Was trying to look into the 2025.07 uboot-imx from github but “make colibri_imx7_emmc_defconfig” and “make” has an error

multiple definition of 'reset_cpu'
board/toradex/colibri_imx7/colibri_imx7.c:257
arch/arm/mach-imx/mx7/soc.c:536

Torizon solution with plymouth is too slow to finish booting, our current tdx-reference-minimal-image based solution activates lcd after 9 sec.

6

Hello @BDSKPEF,

When it comes to more recent u-boot versions on the Colibri iMX7, we have moved to upstream u-boot.
This can be seen in our release matrix: Release Matrix - Kernel/U-Boot Version | Toradex Developer Center

I expect it to be possible to adapt upstream u-boot to use a parallel RGB display for the splash screen, but maybe something from downstream u-boot needs to be brought to your upstream u-boot.
As this is not a supported feature, there is not a lot I can do to help you get this working.
If you want, I could recommend a few partners which are familiar with such development.
Otherwise, I can give some guesses on what may be needed. Using the Toradex AI here on the community may also be helpful, as it has access to all our documentation on developer.toradex.com.

Best Regards,
Bruno

7

@bruno.tx

Using the Toradex AI here on the community may also be helpful,

can i use the AI somehow directly or is it just setting @ ToradexAI in the support request ?

8

Hello @BDSKPEF,

You can tag it into your response and it will respond to your query.
It only responds to public posts.
You can see an example here: GPIO Power-Off Overlay Not Working After Migration to Scarthgap (Apalis iMX8QP) - #4 by ToradexAI

So a possible approach would be to just continue the conversation here and tag it.
If you have some question for me or would like something to be clarified, you can tag me instead, I am following the conversation.

Best Regards,
Bruno

9

@ToradexAI

psplash loading during kernel boot shows failed after approx 4 seconds

Failed to start Start psplash boot splash screen
See 'systemctl status psplash-start.service' for details.

but actually loads correctly later after 12 seconds. This is also after the framebuffer driver has loaded

[    9.541185] mxsfb 30730000.lcdif: [drm] fb0: mxsfb-drmdrmfb frame buffer device

And systemctl status psplash-start.service shows this after booting:

* psplash-start.service - Start psplash boot splash screen
     Loaded: loaded (/usr/lib/systemd/system/psplash-start.service; enabled; preset: enabled)
     Active: active (exited) since Wed 2025-01-08 18:23:08 UTC; 7 months 1 day ago
    Process: 477 ExecStart=/usr/bin/psplash (code=exited, status=0/SUCCESS)
   Main PID: 477 (code=exited, status=0/SUCCESS)
        CPU: 75ms

Jan 08 18:23:08 localhost systemd[1]: Starting Start psplash boot splash screen...
Jan 08 18:23:08 localhost psplash[477]: warning: FBIOPUT_VSCREENINFO failed, double buffering disabled
Jan 08 18:23:08 localhost systemd[1]: Started Start psplash boot splash screen.

Can it be that it attempts to load before the framebuffer is ready and then again afterwards ?

10

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Hello,

Yes, your analysis is correct. The psplash service is trying to start before the framebuffer device is ready. On the Colibri iMX7, the framebuffer driver (mxsfb) is typically loaded several seconds into the boot process. If psplash is started before the /dev/fb0 device is available, it will initially fail, but systemd may later retry or psplash may succeed once the framebuffer node appears. This is why you observe a warning and apparent failure during early boot, yet see it running after the framebuffer comes up.

To ensure psplash only starts after the framebuffer is ready, you should adjust its systemd unit file to include proper dependencies on the framebuffer device. Here’s a recommended snippet for your /usr/lib/systemd/system/psplash-start.service:

[Unit]
Description=Start psplash boot splash screen
After=multi-user.target
Wants=dev-fb0.device
After=dev-fb0.device

[Service]
Type=notify
ExecStart=/usr/bin/psplash
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Key points:

  • Wants=dev-fb0.device and After=dev-fb0.device ensure the service waits for the framebuffer to be available before launching.
  • You may also want to ensure you are not overriding these dependencies via drop-in configuration or elsewhere.

For further explanation and more details, see:

The warning FBIOPUT_VSCREENINFO failed, double buffering disabled is commonly seen and usually not a problem unless your application requires double-buffering for smooth updates; the basic framebuffer functionality will still work.

Summary:
Adjust your service file as above, so psplash waits for the framebuffer to be initialized. That should prevent the early boot failure and race condition you’re observing.

Best regards,
Toradex AI Assistant.

11

@ToradexAI

this results in several

[***   ] A start job is running for /dev/fb0 (8s / 1min 30s)

and splash is not shown until the service is started manually

12

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Hello,

This is a known issue with relying on systemd device units (e.g., dev-fb0.device): if the framebuffer device appears late, systemd can hang the service start for up to 90 seconds (the default timeout), causing delays in the boot process and psplash not appearing until much later.

A more reliable method is to manage psplash startup with a wrapper script that polls for the framebuffer device. Here’s how to do it:

1. Create a psplash wrapper script

Save this as /usr/bin/psplash-wrapper and make it executable (chmod +x /usr/bin/psplash-wrapper):

#!/bin/sh
# Wait for framebuffer to be available
while [ ! -c /dev/fb0 ]; do
    sleep 0.1
done
# Small extra delay to ensure driver is fully ready
sleep 0.5
exec /usr/bin/psplash "$@"

2. Update your systemd service

Edit your service (/usr/lib/systemd/system/psplash-start.service) to call the wrapper instead:

[Unit]
Description=Start psplash boot splash screen
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/psplash-wrapper
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

3. Reload systemd and enable the service (if not already enabled):

systemctl daemon-reload
systemctl enable psplash-start.service

4. Why this works

  • The wrapper waits for /dev/fb0 to appear, avoiding any race between psplash and the framebuffer driver.
  • No systemd device dependency is needed, so you avoid long waits if the device appears late.
  • This method has proven reliable for boards where the framebuffer is initialized significantly after systemd is running.

Reference:

Let me know if you have further questions or issues!

Best regards,
Toradex AI Assistant.