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

Hello Max,

On 8/1/26 10:08, Uwe Kleine-König wrote:

On Fri, Jul 31, 2026 at 11:50:37PM +0200, Max Pedraza wrote:

quoted

Embedded products routinely need their own boot logo. Today the only way to
get one is to replace one of the logo_*_clut224.ppm files in the kernel
source tree, which bakes the image into the kernel image. Two products that
share a board support package but differ in branding therefore need two
kernel builds, and rebranding an existing product means rebuilding and
requalifying a kernel for what is purely a cosmetic change.

This series lets the logo be described by the device tree instead: a node
compatible with "linux,boot-logo-clut224" supplies the image in the same
paletted format the built-in CLUT224 logos already use, and the kernel
prefers it over the built-in ones when it is present and enabled. If the
node is absent or disabled, nothing changes.

The image can come from the node itself (patches 1-2) or from a reserved
memory region the bootloader filled in (patches 4-5), because the image and
its placement are independent axes of variation. One board sold to several
customers wants several device trees differing in the logo. One customer
with several products built on that board, with different panels, wants the
same logo placed differently on each: there the image belongs in a shared
binary and only the placement belongs in the device tree. Patch 3 adds that
placement.

We have been carrying a cruder version of this downstream on an AM335x
product since 2020, across a handful of board revisions, and it has removed
a real maintenance burden for us. This is an attempt to find out whether
something along these lines is wanted upstream, and if so in what shape --
hence RFC.

I am aware of the contentious part: a bitmap is not hardware, and the device
tree is not an obvious place to put one. The argument for it is that the
logo identifies the board in the same way the model property does, it is
available before any filesystem is mounted, and it is per board rather than
per kernel. The argument against is presumably that this is policy and
belongs in userspace or in the bootloader. I would rather hear that
explicitly than keep the patch downstream on a guess, and if the concept is
rejected I would still like to know whether a smaller subset -- say the
placement properties driven from the fbcon command line, without any image
in the device tree -- would be worth submitting separately.

My 0.02€: Usually you want to use the display using drm and not fb once
the machine is fully booted. If you're using fb during boot to display a
logo, it's hardly possible to switch to drm later in the boot process
without flicker.

So my recommendation for your usecase is to not use the kernel boot logo
stuff, but something like https://github.com/pengutronix/platsch.  Then
all the configuration is in userspace and modifyable using kernel
parameters. Or you create your own application using libplatsch that
selects the image based on the actual product derived from the dt
compatible or some EEPROM's content.

Max, is this a viable option for your usecase?

Helge