Thread (25 messages) flat view 25 messages, 7 authors, 16h ago

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

From: Màxim Pedraza Padilla <hidden>
Date: 2026-08-13 23:50:50
Also in: dri-devel, linux-devicetree, lkml

You're right, on essentially all of it, and I owe you a clearer account
than I gave.

The 3.4s I put up was our 4.19 product kernel: not an SPL/Falcon build,
and not one that has ever been optimized for boot time. I should have
said which system it was instead of holding it up as if it were the
floor. "Suboptimal" is fair.

Reaching for an initramfs purely to paint a splash early isn't free on
my side either: it pushes the start of the actual application out a
little, so it's a trade rather than a clean win. But that's a detail,
not a rebuttal.

The case I actually care about is simpler than the one I was making. As
someone building products on top of the kernel, I reach for the simplest
thing that works, and the kernel already draws a boot logo — so that is
what I used, the built-in CLUT224 image, from day one. What pushed me
past it was not speed: it was one kernel image feeding four panel
variants (two sizes, two orientations), where a single compiled-in logo
no longer fits. Describing the logo per board rather than per build is
the whole of it.

I'm well aware that "convenient for the product engineer" and "worth
carrying in the kernel forever" are different questions, and that the
second one is yours and Helge's to answer, not mine. If the verdict is
that this belongs in userspace or the bootloader, I'll take it — I would
just rather have it decided than keep guessing downstream.

Thanks for taking the time to push back. It was the useful kind.

Max
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help