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.

Patches 4 and 5 are separable; the series is useful without them if the
reserved memory path is thought to be one mechanism too many.

Not included, though it exists in our downstream version: a hook in
drm_fb_helper so the logo is drawn when CONFIG_FRAMEBUFFER_CONSOLE is
disabled, which is the common case for a product that only wants a splash
screen. Today fb_show_logo() is reached from fbcon alone. That is a DRM
question rather than an fbdev one and deserves a separate posting.

Notes on the binding:

  - The palette size is derived from the length of the "clut" property
    instead of being a separate property, so it cannot disagree with the
    palette actually supplied.
  - "data" holds plain palette indices. The 32 entry offset the frame
    buffer layer reserves for the console is an implementation detail and
    is applied by the kernel.
  - "logo-position" and "logo-offset" are spelled with the prefix because
    plain "position" and "offset" are already used elsewhere in the tree
    with an incompatible type, which dtschema rejects.
  - "logo-centered" overlaps with the existing fb_center_logo, but it is
    per device tree rather than per fbcon command line, and it composes
    with "logo-offset". That combination is what panels with a partially
    visible area need, where the usable region is not the centre of the
    mode; the hardware this came from is an 800x480 panel of which only the
    bottom 320 rows are visible.
  - The reserved memory path takes a "memory-region" phandle rather than a
    bare address. The reservation is what makes the memory safe to read at
    all, and it is what gives the kernel a size to bounds check against.

The byte arrays are not written by hand: patch 6 adds ppmtodtlogo, a host
tool along the lines of the existing pnmtologo -- plain C, no dependencies,
no quantization of its own -- that turns a PPM image into the node or into
the memory region blob. It is what produced everything tested below.

Testing: build tested for arm with CONFIG_LOGO_DT_CLUT224 both enabled and
disabled, W=1 clean, checkpatch --strict clean, dt_binding_check clean. The
schema was also checked against deliberately malformed nodes, including
supplying both image sources at once and neither.

Boot tested under qemu-system-arm -M versatilepb with PL111 and fbcon, at
16bpp. A 160x120 logo placed with "logo-centered" plus a "logo-offset" of
<0 120> lands at exactly the expected coordinates, and every pixel matches
the source image once the source is truncated to RGB565, with identical
per-colour pixel counts. Supplying the same image through a reserved region
loaded at boot produces a bit for bit identical screen. Blobs with a bad
magic, a geometry larger than the reservation, an out of range pixel and an
oversized palette are each rejected with a warning and fall back to the
built-in logo, with no crash.

That boot test earned its keep: the first version of patch 3 drew the logo
correctly and then had it erased, because fb_prepare_logo() still reserved
only the logo's own height while the logo itself had been moved further
down. Nothing in the build or the static checks catches that.

Also boot tested on real hardware: an AM335x board (tilcdc) with an 800x480
panel, migrated from the 4.19 product kernel this derives from. Both image
sources show the product logo where expected -- embedded in the device tree,
and in a bootloader-loaded reserved memory region at the same address the
4.19 system already used. That system builds without
CONFIG_FRAMEBUFFER_CONSOLE, so the drawing there goes through the separate
drm_fb_helper hook mentioned above as not included; the parsing, validation
and placement exercised are those of this series.

Max Pedraza (6):
  dt-bindings: display: add a device tree supplied boot logo
  video: logo: allow the boot logo to come from the device tree
  fbdev: honour the device tree boot logo placement properties
  dt-bindings: display: allow the boot logo in a reserved memory region
  video: logo: allow the boot logo to come from a reserved memory region
  video: logo: add ppmtodtlogo host tool

 .../display/linux,boot-logo-clut224.yaml      | 152 +++++++
 MAINTAINERS                                   |   1 +
 drivers/video/fbdev/core/fb_logo.c            | 174 ++++++++
 drivers/video/logo/Kconfig                    |  13 +
 drivers/video/logo/Makefile                   |   6 +-
 drivers/video/logo/logo.c                     | 256 +++++++++++
 drivers/video/logo/ppmtodtlogo.c              | 402 ++++++++++++++++++
 7 files changed, 1003 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/display/linux,boot-logo-clut224.yaml
 create mode 100644 drivers/video/logo/ppmtodtlogo.c

-- 
2.39.5

Hi Max,

On Fri, 31 Jul 2026 at 23:56, Max Pedraza <maximpedraza@gmail.com> 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.

Thanks for your series!

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

The standard location for configuration that is not hardware
description is under /chosen...

IIRC, real Open Firmware used to have some logo configuration, too...
Yep, /options/oem-logo on CHRP LongTrail[1].
And it's even documented[2], but fixed to 64x64 monochrome.

[1] http://g33rt.be/migrated/Linux/PPC/DeviceTree.html
[2] https://www.djc.id.au/2008/IEEE1275-1994.pdf

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

El mar, 4 ago 2026 a las 15:59, Geert Uytterhoeven
(<geert@linux-m68k.org>) escribió:
> The standard location for configuration that is not hardware
> description is under /chosen...
>
> IIRC, real Open Firmware used to have some logo configuration, too...
> Yep, /options/oem-logo on CHRP LongTrail[1].
> And it's even documented[2], but fixed to 64x64 monochrome.

Thank you, that is the answer I was missing. I had written the "a bitmap
is not hardware" objection into the cover letter as something to defend
against, and /chosen turns it into a matter of putting the node in the
right place instead.

v2 moves it there, and I will post it shortly: the node is a child of
/chosen and the kernel looks it up with of_get_compatible_child(of_chosen,
...). The binding now says why, and points at the oem-logo precedent. It
also puts the node in the same company as simple-framebuffer, which lives
under /chosen for the same reason.

Thanks as well for the references, the CHRP one was new to me.

Max

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

Best regards
Uwe

Hi Màxim,

On Sat, Aug 01 2026 at 10:08 +0200, Uwe Kleine-König <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 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) [...]

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 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.
>
> Best regards
> Uwe
-- 
Pengutronix e.K.                           | Ulrich Ölmann               |
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 |

El lun, 3 ago 2026 a las 14:39, Ulrich Ölmann
(<u.oelmann@pengutronix.de>) escribió:
> 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.

Good point, I had not considered it.

A warning could be added to the binding documentation about the licensing
implications of a proprietary logo, aimed at anyone thinking of
submitting a device tree carrying one to the kernel tree. I am happy to
add that in v2 if it is considered useful.

Patches 4 and 5 also avoid the question by construction: there the image
is a separate binary the bootloader loads, and the device tree carries
only a phandle to the reserved region.

In any case, whether such device trees are accepted is ultimately for the
device tree maintainers to decide.

Best regards,
Max

Hi Max,

On Tue, Aug 04 2026 at 00:04 +0200, Màxim Pedraza Padilla <maximpedraza@gmail.com> wrote:
> El lun, 3 ago 2026 a las 14:39, Ulrich Ölmann
> (<u.oelmann@pengutronix.de>) escribió:
>> 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.
>
> Good point, I had not considered it.
>
> A warning could be added to the binding documentation about the licensing
> implications of a proprietary logo, aimed at anyone thinking of
> submitting a device tree carrying one to the kernel tree. I am happy to
> add that in v2 if it is considered useful.

I think the issue is broader than upstream submissions. Once such a
device tree is shipped as part of a GPL kernel in a product, the GPL
obligations already apply to that distribution. Therefore, the licensing
implications of embedding a proprietary logo are not limited to upstream
acceptance, they also affect downstream product distributions.

> Patches 4 and 5 also avoid the question by construction: there the image
> is a separate binary the bootloader loads, and the device tree carries
> only a phandle to the reserved region.

Right, here everything is clearly uncoupled.

> In any case, whether such device trees are accepted is ultimately for the
> device tree maintainers to decide.

As mentioned above, the issue also extends to deployed products.

Those were just my thoughts on the licensing aspect.

Best regards,
Ulrich


> Best regards,
> Max
-- 
Pengutronix e.K.                           | Ulrich Ölmann               |
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 |

El mar, 4 ago 2026 a las 7:25, Ulrich Ölmann
(<u.oelmann@pengutronix.de>) escribió:
> I think the issue is broader than upstream submissions. Once such a
> device tree is shipped as part of a GPL kernel in a product, the GPL
> obligations already apply to that distribution. Therefore, the licensing
> implications of embedding a proprietary logo are not limited to upstream
> acceptance, they also affect downstream product distributions.

Point taken, thanks for spelling it out. I am not qualified to argue the
legal side and will not try to, but I follow the reasoning.

In practice it reinforces the reserved memory path, which is the one we
ship: there the device tree carries only a phandle and the placement,
and the image stays a separate file with its own licensing, handled like
any other asset in the product.

Max

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

Uwe Kleine-König wrote:
> 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.

Thanks for the pointer, I did not know platsch and it looks like a good
fit for the problem it solves. It does not solve mine, though, and I
think the reason is worth spelling out, because it is not about how the
image gets drawn but about when.

These are industrial units, and the requirement is time to first pixel
after power is applied. If the panel stays dark for more than a moment
the unit reads as dead, and that is a support call. Anything running in
userspace is by construction later than the kernel: it needs the kernel
booted, the rootfs mounted and init far enough along to exec it. I can
measure the exact difference on our hardware if that is useful for the
discussion.

We do already paint a BMP from U-Boot, which is as early as we can
possibly be. The problem is the gap that follows: once the display
driver probes, the panel is cleared, and nothing puts anything back
until userspace is running. Moving the logo further out into userspace
widens that gap rather than closing it. The kernel boot logo is what
fills it, and that is the whole reason this series exists.

For completeness, since it is the usual answer to the U-Boot handover
problem: a simple-framebuffer node plus simpledrm does keep the
bootloader image on screen. It moves the gap rather than removing it,
though, because the real driver still has to take over at some point,
and it makes the logo a property of the bootloader instead of the board
description. The two are complementary rather than alternatives:
simpledrm covers up to the driver handover, the boot logo covers from
there.

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

You are right in the general case, but I should be precise about what
happens here, because there is no fbdev to DRM switch on this hardware.
The display driver is tilcdc, which is a DRM driver; the logo ends up in
the fbdev emulation that drm_fb_helper provides, so DRM is scanning out
from the first pixel. Userspace then takes DRM over directly. The
transition that remains is the same one any solution has when the
application starts.

> Max, is this a viable option for your usecase?

Not for the reason above, no. Let me also be explicit about something
the cover letter only mentions in passing, because it is directly
relevant to Uwe's point and I would rather raise it myself.

This series does not draw anything anywhere new. It only teaches the
existing fbdev logo code where the image may come from: a device tree
node instead of a built-in PPM. With CONFIG_FRAMEBUFFER_CONSOLE the
drawing is still done by fbcon, exactly as it is today.

The piece that matters for a product with no text console is a separate
two patch series I have deliberately not posted yet. It exports a
fb_draw_logo() helper from fbdev and calls it from drm_fb_helper when
fbcon is not built in. I am aware that is pushing against the direction
fbdev dependencies are being removed from DRM, which is precisely why I
kept it out of this series: I did not want that discussion to decide the
fate of the binding.

So the honest summary of where I stand: if the device tree part is
acceptable I will post the drawing part separately to dri-devel and let
it be judged on its own merits. If the conclusion there is that DRM
should grow its own way to put an image on screen before userspace
exists, rather than reaching into fbdev, I would rather help build that
than carry a hook downstream forever. What I cannot do is wait for
userspace.

Thanks both for looking at this,
Max

Hi,

On Sun, Aug 02, 2026 at 12:01:58AM +0200, Màxim Pedraza Padilla wrote:
> Uwe Kleine-König wrote:
> > 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.
> 
> Thanks for the pointer, I did not know platsch and it looks like a good
> fit for the problem it solves. It does not solve mine, though, and I
> think the reason is worth spelling out, because it is not about how the
> image gets drawn but about when.
> 
> These are industrial units, and the requirement is time to first pixel
> after power is applied. If the panel stays dark for more than a moment
> the unit reads as dead, and that is a support call. Anything running in
> userspace is by construction later than the kernel: it needs the kernel
> booted, the rootfs mounted and init far enough along to exec it. I can
> measure the exact difference on our hardware if that is useful for the
> discussion.
> 
> We do already paint a BMP from U-Boot, which is as early as we can
> possibly be. The problem is the gap that follows: once the display
> driver probes, the panel is cleared, and nothing puts anything back
> until userspace is running. Moving the logo further out into userspace
> widens that gap rather than closing it. The kernel boot logo is what
> fills it, and that is the whole reason this series exists.

If the sole reason for this series is to keep having something on the
display while the kernel boots until DRM catches up, then you probably
want to check

https://lore.kernel.org/r/20260629-drm-state-readout-v4-0-5966657980ed@kernel.org

Which also does what you're trying to achieve: keep the display running
with the same content while the DRM driver loads, and switch to whatever
comes next without a flicker (if we can).

Maxime

El lun, 10 ago 2026 a las 11:02, Maxime Ripard (<mripard@kernel.org>) escribió:
> If the sole reason for this series is to keep having something on the
> display while the kernel boots until DRM catches up, then you probably
> want to check [drm state readout]

Thanks, I had missed it. I read it and then measured, having earlier
claimed in this thread that our hardware kept no state worth reading. That
was wrong.

Dumping the LCDC registers at the top of tilcdc's probe, before the driver
touches anything:

  RASTER_CTRL=00280081  FB=9df13cc0..9dfcf4bc

LCD_EN is set and the scanout address is exactly the framebuffer U-Boot
reported, still holding the image. So readout would have something real to
adopt here. tilcdc is not one of the drivers you implement, but that is
work rather than a disagreement.

One observation that may be worth your time. Pointing a simple-framebuffer
node at that same memory, same device tree, only the driver differing:

  simplefb   the image is still there afterwards
  simpledrm  the buffer reads back as all zeros

So where the CRTC is still scanning the bootloader's buffer, simpledrm
wipes the image it was meant to carry over. I have not chased down the call
that clears it.

What readout cannot cover is having no firmware splash to read. U-Boot's
Falcon mode boots the kernel from SPL and skips U-Boot proper, where
display init lives, so there is no image and no programmed CRTC to inherit
-- and Falcon mode exists to shorten boot time, which is the same reason
one cares about the logo appearing early.

So I do not think they are alternatives: readout preserves what firmware
put up, this series lets the kernel put something there when firmware did
not. On hardware with both, readout is the better answer for the handover
and I would rather not duplicate it.

Max

On Wed, Aug 12, 2026 at 02:31:52AM +0200, Màxim Pedraza Padilla wrote:
> El lun, 10 ago 2026 a las 11:02, Maxime Ripard (<mripard@kernel.org>) escribió:
> > If the sole reason for this series is to keep having something on the
> > display while the kernel boots until DRM catches up, then you probably
> > want to check [drm state readout]
> 
> Thanks, I had missed it. I read it and then measured, having earlier
> claimed in this thread that our hardware kept no state worth reading. That
> was wrong.
> 
> Dumping the LCDC registers at the top of tilcdc's probe, before the driver
> touches anything:
> 
>   RASTER_CTRL=00280081  FB=9df13cc0..9dfcf4bc
> 
> LCD_EN is set and the scanout address is exactly the framebuffer U-Boot
> reported, still holding the image. So readout would have something real to
> adopt here. tilcdc is not one of the drivers you implement, but that is
> work rather than a disagreement.
> 
> One observation that may be worth your time. Pointing a simple-framebuffer
> node at that same memory, same device tree, only the driver differing:
> 
>   simplefb   the image is still there afterwards
>   simpledrm  the buffer reads back as all zeros
> 
> So where the CRTC is still scanning the bootloader's buffer, simpledrm
> wipes the image it was meant to carry over. I have not chased down the call
> that clears it.
> 
> What readout cannot cover is having no firmware splash to read. U-Boot's
> Falcon mode boots the kernel from SPL and skips U-Boot proper, where
> display init lives, so there is no image and no programmed CRTC to inherit
> -- and Falcon mode exists to shorten boot time, which is the same reason
> one cares about the logo appearing early.

In such a case, you can (and really should) use KMS, and you should use
an initramfs and setup the splash screen there. There's no need for the
kernel to do that work.

It's still significantly different from your earlier claim, since there
would be no gap between uboot and DRM, and no blanking either.

Maxime

El mié, 12 ago 2026 a las 9:42, Maxime Ripard (<mripard@kernel.org>) escribió:
> In such a case, you can (and really should) use KMS, and you should use
> an initramfs and setup the splash screen there.

Agreed that readout is the right answer where it applies, and I am not
looking to duplicate it. Three cases where it does not:

  - Hardware whose only in-tree display driver is fbdev. There is no KMS
    state to read at all, and there are still around a hundred of those
    drivers.
  - DRM drivers without readout implemented, which today is all of them
    but tidss.
  - Falcon mode, where U-Boot proper never runs, so there is no image and
    no programmed CRTC to inherit.

On the initramfs: it moves the splash earlier, it does not close the gap.
Measured on our 4.19 product kernel:

  1.09 s  tilcdc registers fb0, the logo can be drawn
  2.68 s  ubi0 starts attaching        <- 1.59 s of built-in driver probes
  3.39 s  Run /sbin/init               <- 0.70 s of UBI attach + UBIFS mount

An initramfs removes the 0.70 s of storage. It cannot remove the 1.59 s,
because PID 1 does not exist until the initcalls have run. So the gap goes
from 2.3 s to roughly 1.6 s, before the splash binary has loaded and drawn
anything. That figure is an estimate; the breakdown it comes from is not.

It is also worth saying what this series is and is not. The kernel has
drawn a boot logo for decades; this does not add that. It changes where the
image comes from, so that one kernel binary can serve products that differ
only in branding. If the position is that the kernel should not draw a logo
at all, that is an argument about CONFIG_LOGO rather than about these
patches -- and drm_panic already calls fb_find_logo(), so the logo is not
purely an fbdev concern either.

On doing it through KMS: you are right, and the follow-up series should be
a DRM client alongside drm_log rather than a hook in drm_fb_helper. I will
rework it that way before posting it.

Max

Hi Maxim.

> On doing it through KMS: you are right, and the follow-up series should be
> a DRM client alongside drm_log rather than a hook in drm_fb_helper. I will
> rework it that way before posting it.

Take a look at:
https://lkml.iu.edu/2605.1/03465.html

The work Francesco Valla did seems to overlap a lot with what you
suggest.

From the intro mail:

"
in a nutshell, the splash DRM client can draw a splashscreen using:

- the BMP image supplied by the EFI BGRT;
- a BMP image loaded as firmware (either built-in or loaded from the
filesystem);
- a colored background.
"

	Sam

Hi Sam,

Thank you -- that's a useful pointer, and it settles the question of how
a splash should be drawn without fbcon: a DRM client at
drm_client_setup(), next to drm_log, not a drm_fb_helper hook.

Francesco's series is genuinely inspiring work, and it would be very
useful to me if it could take a CLUT224 image -- unfortunately it can't.
It only accepts an uncompressed 24-bit RGB888 BMP, whereas our logo is
paletted, which is what keeps it small: 17 KiB for 800x480 rather than
around a megabyte. So as it stands the format doesn't line up with what
we carry.

Reading it did make the distinction clearer to me, though. drm_splash
*draws* an image into a fresh buffer, which means a first modeset and the
blanking that comes with it. What our hardware leaves us with is a
framebuffer U-Boot has already drawn and a CRTC still scanning it out, so
for our case the natural thing is to *adopt* that state rather than
redraw it -- which is what hardware state readout does, with no redraw
and no flicker.

Where drm_splash is the right tool is the case with no state to adopt --
Falcon boot, where U-Boot proper never runs, or a handover where the
buffer doesn't survive. I'll follow Francesco's series for that.

Thanks again -- it helped me draw the line between the two.

Max

Hi Màxim,

On Tue, Aug 18, 2026 at 12:48:21AM +0200, Màxim Pedraza Padilla wrote:
> Hi Sam,
> 
> Thank you -- that's a useful pointer, and it settles the question of how
> a splash should be drawn without fbcon: a DRM client at
> drm_client_setup(), next to drm_log, not a drm_fb_helper hook.
> 
> Francesco's series is genuinely inspiring work, and it would be very
> useful to me if it could take a CLUT224 image -- unfortunately it can't.
> It only accepts an uncompressed 24-bit RGB888 BMP, whereas our logo is
> paletted, which is what keeps it small: 17 KiB for 800x480 rather than
> around a megabyte. So as it stands the format doesn't line up with what
> we carry.

Format concerns are - in addition to lack of time to work on it - what
is keeping me from sending a new revision. Any kind of compression would
need to be unwinded - probably on a per-pixel basis - making the
required CPU time unreasonable for large images (at least if boot time
optimization is the ultimate goal - linke in my case).

Of course, on "low-resolution" displays the size-vs-time tradeoff might
be the sweet spot - but the target here was to being as much generic as
possible.

> 
> Reading it did make the distinction clearer to me, though. drm_splash
> *draws* an image into a fresh buffer, which means a first modeset and the
> blanking that comes with it. What our hardware leaves us with is a
> framebuffer U-Boot has already drawn and a CRTC still scanning it out, so
> for our case the natural thing is to *adopt* that state rather than
> redraw it -- which is what hardware state readout does, with no redraw
> and no flicker.
> 
> Where drm_splash is the right tool is the case with no state to adopt --
> Falcon boot, where U-Boot proper never runs, or a handover where the
> buffer doesn't survive. I'll follow Francesco's series for that.

My typical embedded setup is exactly that one - Falcon boot, a simple
boot logic inside the SPL, and possibly no initramfs. I find this to be
the most portable solution, as it does not require complex drivers and
handover logic in the bootloader.

In case you decide to take my series for a re-spin, feel free to ask if
something is unclear.

> Thanks again -- it helped me draw the line between the two.
> 
> Max

Reagrds,

Francesco

Hi Sam, Francesco,

Sam -- thanks, and you're right that it's doable. One honest nuance on
where it would live: CLUT224 isn't a DRM fourcc, it's the kernel logo's
own container -- a palette plus one index byte per pixel. drm_format_helper
converts between pixel formats, which is a symmetric operation; turning
CLUT224 into RGB is a palette decode, not a reformat. It can certainly sit
there, but it's worth calling it what it is: a decompression step in front
of the scanout, not a format conversion next to the xrgb8888->rgb565 helpers.

Francesco -- that's exactly the crux, and I think we agree completely. The
palette expansion is cheap for me only because the image is small and
low-resolution: one lookup per pixel at 800x480 costs nothing, so I get the
17 KiB on flash for free at boot. But that's the "low-resolution sweet spot"
you describe, not the general case -- at a generic resolution the per-pixel
decode stops being free, and boot time is the whole point. So I don't think
paletted input belongs in a client whose goal is to stay generic; it's a
trade that only pays off when the image is deliberately small.

For the case where nothing lights the panel before Linux -- Falcon boot,
or a handover where the buffer doesn't survive -- I do have to draw, and
there I'd rather build on your series than start from scratch. I can't use
it unchanged, since my logo isn't a BMP: it's a small CLUT224 (paletted)
blob carried in the device tree, so I'd add a source alongside your BGRT
and firmware-BMP ones that recognises it by a magic and decodes the palette.
But the client structure, the drm_client_setup() hook, the scanout path --
that's all your groundwork, and I'd be leaning on it. Thanks for the offer
to help on a respin, and for the series, which is what made the distinction
clear to me.

Max

El mar, 18 ago 2026 a las 21:39, Francesco Valla
(<francesco@valla.it>) escribió:
>
> Hi Màxim,
>
> On Tue, Aug 18, 2026 at 12:48:21AM +0200, Màxim Pedraza Padilla wrote:
> > Hi Sam,
> >
> > Thank you -- that's a useful pointer, and it settles the question of how
> > a splash should be drawn without fbcon: a DRM client at
> > drm_client_setup(), next to drm_log, not a drm_fb_helper hook.
> >
> > Francesco's series is genuinely inspiring work, and it would be very
> > useful to me if it could take a CLUT224 image -- unfortunately it can't.
> > It only accepts an uncompressed 24-bit RGB888 BMP, whereas our logo is
> > paletted, which is what keeps it small: 17 KiB for 800x480 rather than
> > around a megabyte. So as it stands the format doesn't line up with what
> > we carry.
>
> Format concerns are - in addition to lack of time to work on it - what
> is keeping me from sending a new revision. Any kind of compression would
> need to be unwinded - probably on a per-pixel basis - making the
> required CPU time unreasonable for large images (at least if boot time
> optimization is the ultimate goal - linke in my case).
>
> Of course, on "low-resolution" displays the size-vs-time tradeoff might
> be the sweet spot - but the target here was to being as much generic as
> possible.
>
> >
> > Reading it did make the distinction clearer to me, though. drm_splash
> > *draws* an image into a fresh buffer, which means a first modeset and the
> > blanking that comes with it. What our hardware leaves us with is a
> > framebuffer U-Boot has already drawn and a CRTC still scanning it out, so
> > for our case the natural thing is to *adopt* that state rather than
> > redraw it -- which is what hardware state readout does, with no redraw
> > and no flicker.
> >
> > Where drm_splash is the right tool is the case with no state to adopt --
> > Falcon boot, where U-Boot proper never runs, or a handover where the
> > buffer doesn't survive. I'll follow Francesco's series for that.
>
> My typical embedded setup is exactly that one - Falcon boot, a simple
> boot logic inside the SPL, and possibly no initramfs. I find this to be
> the most portable solution, as it does not require complex drivers and
> handover logic in the bootloader.
>
> In case you decide to take my series for a re-spin, feel free to ask if
> something is unclear.
>
> > Thanks again -- it helped me draw the line between the two.
> >
> > Max
>
> Reagrds,
>
> Francesco
>

Hi Màxim.

On Tue, Aug 18, 2026 at 12:48:21AM +0200, Màxim Pedraza Padilla wrote:
> Hi Sam,
> 
> Thank you -- that's a useful pointer, and it settles the question of how
> a splash should be drawn without fbcon: a DRM client at
> drm_client_setup(), next to drm_log, not a drm_fb_helper hook.
> 
> Francesco's series is genuinely inspiring work, and it would be very
> useful to me if it could take a CLUT224 image -- unfortunately it can't.
> It only accepts an uncompressed 24-bit RGB888 BMP, whereas our logo is
> paletted, which is what keeps it small: 17 KiB for 800x480 rather than
> around a megabyte. So as it stands the format doesn't line up with what
> we carry.

Without looking at it in detail I would assume adding CLUT224 support
would be doable. Step 1 would be to add a format conversion in
drm_format_helper and use that. You may also find this useful for other
purposes.

	Sam

On Thu, Aug 13, 2026 at 01:50:47AM +0200, Màxim Pedraza Padilla wrote:
> El mié, 12 ago 2026 a las 9:42, Maxime Ripard (<mripard@kernel.org>) escribió:
> > In such a case, you can (and really should) use KMS, and you should use
> > an initramfs and setup the splash screen there.
> 
> Agreed that readout is the right answer where it applies, and I am not
> looking to duplicate it. Three cases where it does not:
> 
>   - Hardware whose only in-tree display driver is fbdev. There is no KMS
>     state to read at all, and there are still around a hundred of those
>     drivers.

Which are entirely deprecated, and kept mostly for historical reason.
It's kind of irrelevant to this discussion.

>   - DRM drivers without readout implemented, which today is all of them
>     but tidss.

The obvious answer to that being "just implement readout then". We won't
merge a core feature to accomodate a driver not implementing an existing
feature.

>   - Falcon mode, where U-Boot proper never runs, so there is no image and
>     no programmed CRTC to inherit.

In this case, the first modeset is fine, and whoever does it doesn't
matter, so it might as well be userspace.

> On the initramfs: it moves the splash earlier, it does not close the gap.

Which gap are you talking about?

> Measured on our 4.19 product kernel:
> 
>   1.09 s  tilcdc registers fb0, the logo can be drawn
>   2.68 s  ubi0 starts attaching        <- 1.59 s of built-in driver probes
>   3.39 s  Run /sbin/init               <- 0.70 s of UBI attach + UBIFS mount
> 
> An initramfs removes the 0.70 s of storage. It cannot remove the 1.59 s,
> because PID 1 does not exist until the initcalls have run.

I mean, sure it can. Move built-in drivers to modules, and load them in
the initramfs. It will reduce the kernel image size (so load and
decompression time) and the kernel boot time itself.

I personally did a subsecond boot to userspace with Falcon Boot, UBI and
a similar platform (and no initramfs). 3.4s to run init seems subobtimal
to me.

> So the gap goes from 2.3 s to roughly 1.6 s, before the splash binary
> has loaded and drawn anything. That figure is an estimate; the
> breakdown it comes from is not.
> 
> It is also worth saying what this series is and is not. The kernel has
> drawn a boot logo for decades; this does not add that. It changes where the
> image comes from, so that one kernel binary can serve products that differ
> only in branding. If the position is that the kernel should not draw a logo
> at all, that is an argument about CONFIG_LOGO rather than about these
> patches -- and drm_panic already calls fb_find_logo(), so the logo is not
> purely an fbdev concern either.

I understand where you're coming from. On the flip-side, why should we
add an interface we'll have to maintain forever, while making a
compromise because the fact that it should be in the DT to begin with is
arguable, on a deprecated subsystem, for something where we have
alternatives.

Maxime

You're right, on essentially all of it, and I owe you a clearer account
than I gave.

The 3.4s I put up was our 4.19 product kernel: not an SPL/Falcon build,
and not one that has ever been optimized for boot time. I should have
said which system it was instead of holding it up as if it were the
floor. "Suboptimal" is fair.

Reaching for an initramfs purely to paint a splash early isn't free on
my side either: it pushes the start of the actual application out a
little, so it's a trade rather than a clean win. But that's a detail,
not a rebuttal.

The case I actually care about is simpler than the one I was making. As
someone building products on top of the kernel, I reach for the simplest
thing that works, and the kernel already draws a boot logo — so that is
what I used, the built-in CLUT224 image, from day one. What pushed me
past it was not speed: it was one kernel image feeding four panel
variants (two sizes, two orientations), where a single compiled-in logo
no longer fits. Describing the logo per board rather than per build is
the whole of it.

I'm well aware that "convenient for the product engineer" and "worth
carrying in the kernel forever" are different questions, and that the
second one is yours and Helge's to answer, not mine. If the verdict is
that this belongs in userspace or the bootloader, I'll take it — I would
just rather have it decided than keep guessing downstream.

Thanks for taking the time to push back. It was the useful kind.

Max

Hello Màxim,

On Sun, Aug 02, 2026 at 12:01:58AM +0200, Màxim Pedraza Padilla wrote:
> Uwe Kleine-König wrote:
> > 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.
> 
> Thanks for the pointer, I did not know platsch and it looks like a good
> fit for the problem it solves. It does not solve mine, though, and I
> think the reason is worth spelling out, because it is not about how the
> image gets drawn but about when.
> 
> These are industrial units, and the requirement is time to first pixel
> after power is applied. If the panel stays dark for more than a moment
> the unit reads as dead, and that is a support call. Anything running in
> userspace is by construction later than the kernel: it needs the kernel
> booted, the rootfs mounted and init far enough along to exec it. I can
> measure the exact difference on our hardware if that is useful for the
> discussion.

No need to wait for init, the idea is to use init=/usr/sbin/platsch so
it starts before init (and once the display is setup execve()s
/sbin/init). Also you can put it in an initramfs which gets rid of the
dependency on "rootfs mounted". And if your kernel is modular apart from
what is needed for the display the time difference between kernel boot
image and platsch might be negligible compared to the simplification of
the software architecture.

Having said that, I'm against putting boot splash info in the device
tree as the pointed out alternative is IMHO good enough. But my opinion
probably isn't the one that eventually counts.

Best regards
Uwe

Hi Uwe,


El dom, 2 ago 2026 a las 15:35, Uwe Kleine-König
(<u.kleine-koenig@baylibre.com>) escribió:
> No need to wait for init, the idea is to use init=/usr/sbin/platsch so
> it starts before init (and once the display is setup execve()s
> /sbin/init).

I think I caused a misunderstanding here: when I wrote "init" I meant
PID 1 itself, not the init system getting far enough to start a service.
Running platsch as PID 1 does not change the part that hurts, because
PID 1 is exactly what I am waiting for.

Numbers from a shipping board, our 4.19 product kernel on an AM335x:

  [    1.065931] tilcdc 4830e000.lcdc: fb0: DRM emulated frame buffer device
  [    3.522118] Run /sbin/init as init process

The display is up and can be drawn on at 1.07 s. PID 1 does not exist
until 3.52 s. Whatever runs as PID 1, platsch included, is roughly 2.4 s
late on this hardware. That gap is the entire problem: the panel is
alive and black while the customer is looking at it.

> Also you can put it in an initramfs which gets rid of the dependency on
> "rootfs mounted".

Agreed, and that would remove part of those 2.4 s. But not the shape of
it: PID 1 runs after the built-in initcalls have finished, while the
logo is drawn as soon as the display driver's own probe is done. Any
userspace solution is structurally behind that point, and an initramfs
moves it closer without crossing it.

> And if your kernel is modular apart from what is needed for the display
> the time difference between kernel boot image and platsch might be
> negligible compared to the simplification of the software architecture.

That is worth evaluating, and it may well be the right choice for a new
design. It does not change the ordering, though: the display driver has
to stay built in either way, so its probe finishes before PID 1 exists.
Making the rest modular moves PID 1 closer to that moment without ever
reaching it. The kernel logo draws at the earliest point where there is
something to draw on, and nothing in userspace can be earlier than that.

To be clear about what I am not claiming: platsch is the better answer
for anything that can tolerate the delay, it is more flexible, and I
will very likely use it for the parts of our UI that come after the
splash. The kernel logo is not competing with it, it covers the window
platsch cannot reach.

> Having said that, I'm against putting boot splash info in the device
> tree as the pointed out alternative is IMHO good enough. But my opinion
> probably isn't the one that eventually counts.

Understood, and thanks for saying it plainly, it is useful to know where
you stand. For what it is worth, the objection I expected was exactly
that one and I would rather have it on the record than guess at it. If
the conclusion is that a bitmap does not belong in the device tree, the
fallback I would still like to explore is keeping the placement
properties and the reserved memory path while dropping the in-tree
image, since that removes the "bitmap in DT" part while keeping the
early drawing. But that is for Helge and the DT maintainers to weigh.

Thanks for taking the time,
Max