auto_initramfs=0 with fullscreen kernel splash image prevents the kernel from booting

[JinShil]

Describe the bug

With auto_initramfs=0 in config.txt and fullscreen_logo_enabled=1 and fullscreen_logo_name=logo.tga in cmdline.txt, the kernel will not boot.

Steps to reproduce the behaviour

1. Enable the fullscreen splash image as documented at https://github.com/raspberrypi/rpi-splash-screen-support
2. Add auto_initramfs=0 to config.txt
3. Boot. If console logging is enabled in the bootloader and kernel, you'll only see log messages from the bootloader, not the kernel. The kernel will not boot
4. Remove fullscreen_logo_enabled=1 and fullscreen_logo_name=logo.tga from cmdline.txt. Notice it boots fine

Device (s)

Raspberry Pi CM5 Lite

System

pi@raspberrypi:~ $ cat /etc/rpi-issue
Raspberry Pi reference 2025-10-01
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7dadcf1fc5ce1648ab09409ab978831690c9a955, stage4

pi@raspberrypi:~ $ vcgencmd version
2025/09/23 12:05:55
Copyright (c) 2012 Broadcom
version 02da46a3 (release) (embedded)

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 6.12.47+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1 (2025-09-16) aarch64 GNU/Linux

Logs

No response

Additional context

No response

[6by9]

The logo is loaded from /lib/firmware, so unless you have an initramfs that provides /lib/firmware then the kernel won't be able to display a logo.

Admittedly it sounds like the error handling if it can't find the logo file has issues, but AIUI your test case is fundamentally flawed.

[JinShil]

Admittedly it sounds like the error handling if it can't find the logo file has issues

Yes, that's the fundamental problem I'm trying to bring attention to with this issue.

However, why does the fullscreen splash image feature need to be dependent on initramfs? If the .tga file is in /lib/firmware, why can't it just read the file from there and display it?

[pelwell]

It's probably a question of initialisation order. With a splash screen there is the desire to get it on the display as early as possible, but waiting for some USB mass storage device to enumerate in order for the rootfs to be loaded will clearly delay the presentation.

[6by9]

The logo is only loaded from the con_switch hook when fbcon initialises. If the logo isn't available at that point then it is too late. This is reusing the mechanism that puts up the N raspberries with a larger logo.

I've found a couple of niggles with the handling, but actually the handling if the file isn't present seems to be reasonable. Fixes are in #7088

[6by9]

#7088 is now merged. That seems fairly robust to me, so please retest.

[6by9]

@JinShil Are you happy to close?

[JinShil]

@6by9 I'm sorry, but I haven't had an opportunity to retest this, as I've had to abandon this feature due to the fact that the bootloader does not support the display resolution (800x480) and timings I need. See https://github.com/raspberrypi/rpi-eeprom/issues/479 Testing this is on my todo list, but I'm under tight deadlines at the moment and can't afford the resource spend to test a feature I can't use.

I was told by your applications team that a new bootloader would be released soon (~1 month) with the ability to specify additional timings, and I'm waiting for that to drop before I pick this up again.