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

Hello Max,

On 8/1/26 10:08, Uwe Kleine-K=C3=B6nig wrote:
> On Fri, Jul 31, 2026 at 11:50:37PM +0200, Max Pedraza wrote:
>> Embedded products routinely need their own boot logo. Today the only wa=
y 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 no=
de
>> compatible with "linux,boot-logo-clut224" supplies the image in the sam=
e
>> 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 th=
e
>> node is absent or disabled, nothing changes.
>>
>> The image can come from the node itself (patches 1-2) or from a reserve=
d
>> memory region the bootloader filled in (patches 4-5), because the image=
 and
>> its placement are independent axes of variation. One board sold to seve=
ral
>> customers wants several device trees differing in the logo. One custome=
r
>> with several products built on that board, with different panels, wants=
 the
>> same logo placed differently on each: there the image belongs in a shar=
ed
>> 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 rem=
oved
>> a real maintenance burden for us. This is an attempt to find out whethe=
r
>> 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 d=
evice
>> tree is not an obvious place to put one. The argument for it is that th=
e
>> logo identifies the board in the same way the model property does, it i=
s
>> 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 concep=
t is
>> rejected I would still like to know whether a smaller subset -- say the
>> placement properties driven from the fbcon command line, without any im=
age
>> in the device tree -- would be worth submitting separately.
>=20
> My 0.02=E2=82=AC: 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.
>=20
> 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