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

Hi M=C3=A0xim,

On Sat, Aug 01 2026 at 10:08 +0200, Uwe Kleine-K=C3=B6nig <u.kleine-koenig@=
baylibre.com> wrote:
> 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 t=
hat
>> 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) [...]

independently of the specific implementation, please keep in mind that
the kernel is distributed under the GPLv2, which may have implications
for a proprietary image embedded in the device tree. That doesn't
necessarily have to be a deal-breaker, but it's probably something that
should be considered carefully.

Best regards,
Ulrich


>> [...] 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 sever=
al
>> 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 t=
hat
>> 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 remo=
ved
>> 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 de=
vice
>> 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 t=
han
>> 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 ima=
ge
>> 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 f=
b 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
--=20
Pengutronix e.K.                           | Ulrich =C3=96lmann            =
   |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |