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:
>> 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