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

--y7euzt5xlmsr2onq
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [RFC PATCH 0/6] Boot logo supplied by the device tree
MIME-Version: 1.0

Hello Max,

On Fri, Jul 31, 2026 at 11:50:37PM +0200, Max Pedraza wrote:
> 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 th=
at
> 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.
>=20
> 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.
>=20
> 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 a=
nd
> 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 t=
he
> 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 th=
at
> placement.
>=20
> 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 remov=
ed
> 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.
>=20
> I am aware of the contentious part: a bitmap is not hardware, and the dev=
ice
> 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 th=
an
> 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=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.

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.

Best regards
Uwe

--y7euzt5xlmsr2onq
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmptqV0ACgkQj4D7WH0S
/k6bUwf/b3R5nKZ+dHyzlIKZ+XN6rpMjgW3Dl0H1qu406Hg4yhjBwvx8FmRpc3W2
O6jYub6BAi5oZj+FpvzdR63pWRetwzGpigOqsGlUeGjjIrHbCJWONwOCAu3Q8ynB
CfnK2Hg/gWfPSbnzglGMcvjMnOkkBEV9c07rG72C7qPJClOD5n4qPQhh2TwlVHuV
w2uooARlVezImhDjrexVlRSF8RfZ6tfpHG7Tvingt92i/AnRVb233p6a+8cb4nbY
VTJeBWgsBPTUYC3OQYjgqtHPA1ZE+G6ZZCukwZii7myk+Y7Xdf4EaYVnnI69vrGM
4yeJ1GaCsfsBHz5Himv00/m5LkZR0Q==
=xd2+
-----END PGP SIGNATURE-----

--y7euzt5xlmsr2onq--