Re: [RFC PATCH 0/6] Boot logo supplied by the device tree

On Wed, Aug 12, 2026 at 02:31:52AM +0200, Màxim Pedraza Padilla wrote:

El lun, 10 ago 2026 a las 11:02, Maxime Ripard ([off-list ref]) escribió:

quoted

If the sole reason for this series is to keep having something on the
display while the kernel boots until DRM catches up, then you probably
want to check [drm state readout]

Thanks, I had missed it. I read it and then measured, having earlier
claimed in this thread that our hardware kept no state worth reading. That
was wrong.

Dumping the LCDC registers at the top of tilcdc's probe, before the driver
touches anything:

  RASTER_CTRL=00280081  FB=9df13cc0..9dfcf4bc

LCD_EN is set and the scanout address is exactly the framebuffer U-Boot
reported, still holding the image. So readout would have something real to
adopt here. tilcdc is not one of the drivers you implement, but that is
work rather than a disagreement.

One observation that may be worth your time. Pointing a simple-framebuffer
node at that same memory, same device tree, only the driver differing:

  simplefb   the image is still there afterwards
  simpledrm  the buffer reads back as all zeros

So where the CRTC is still scanning the bootloader's buffer, simpledrm
wipes the image it was meant to carry over. I have not chased down the call
that clears it.

What readout cannot cover is having no firmware splash to read. U-Boot's
Falcon mode boots the kernel from SPL and skips U-Boot proper, where
display init lives, so there is no image and no programmed CRTC to inherit
-- and Falcon mode exists to shorten boot time, which is the same reason
one cares about the logo appearing early.

In such a case, you can (and really should) use KMS, and you should use
an initramfs and setup the splash screen there. There's no need for the
kernel to do that work.

It's still significantly different from your earlier claim, since there
would be no gap between uboot and DRM, and no blanking either.

Maxime