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

Hi Uwe,


El dom, 2 ago 2026 a las 15:35, Uwe Kleine-König
([off-list ref]) escribió:

No need to wait for init, the idea is to use init=/usr/sbin/platsch so
it starts before init (and once the display is setup execve()s
/sbin/init).

I think I caused a misunderstanding here: when I wrote "init" I meant
PID 1 itself, not the init system getting far enough to start a service.
Running platsch as PID 1 does not change the part that hurts, because
PID 1 is exactly what I am waiting for.

Numbers from a shipping board, our 4.19 product kernel on an AM335x:

  [    1.065931] tilcdc 4830e000.lcdc: fb0: DRM emulated frame buffer device
  [    3.522118] Run /sbin/init as init process

The display is up and can be drawn on at 1.07 s. PID 1 does not exist
until 3.52 s. Whatever runs as PID 1, platsch included, is roughly 2.4 s
late on this hardware. That gap is the entire problem: the panel is
alive and black while the customer is looking at it.

Also you can put it in an initramfs which gets rid of the dependency on
"rootfs mounted".

Agreed, and that would remove part of those 2.4 s. But not the shape of
it: PID 1 runs after the built-in initcalls have finished, while the
logo is drawn as soon as the display driver's own probe is done. Any
userspace solution is structurally behind that point, and an initramfs
moves it closer without crossing it.

And if your kernel is modular apart from what is needed for the display
the time difference between kernel boot image and platsch might be
negligible compared to the simplification of the software architecture.

That is worth evaluating, and it may well be the right choice for a new
design. It does not change the ordering, though: the display driver has
to stay built in either way, so its probe finishes before PID 1 exists.
Making the rest modular moves PID 1 closer to that moment without ever
reaching it. The kernel logo draws at the earliest point where there is
something to draw on, and nothing in userspace can be earlier than that.

To be clear about what I am not claiming: platsch is the better answer
for anything that can tolerate the delay, it is more flexible, and I
will very likely use it for the parts of our UI that come after the
splash. The kernel logo is not competing with it, it covers the window
platsch cannot reach.

Having said that, I'm against putting boot splash info in the device
tree as the pointed out alternative is IMHO good enough. But my opinion
probably isn't the one that eventually counts.

Understood, and thanks for saying it plainly, it is useful to know where
you stand. For what it is worth, the objection I expected was exactly
that one and I would rather have it on the record than guess at it. If
the conclusion is that a bitmap does not belong in the device tree, the
fallback I would still like to explore is keeping the placement
properties and the reserved memory path while dropping the in-tree
image, since that removes the "bitmap in DT" part while keeping the
early drawing. But that is for Helge and the DT maintainers to weigh.

Thanks for taking the time,
Max