I’m looking for some help in getting a u-boot splash screen logo displayed when an Apalis T30 first runs.
I’m about 95% of the way there with the implementation however, I have a colour issue whereby any logo I use for the splash logo bitmap is only shown in a couple of colours, even though the LVDS/display is configured for 16-bit colour.
Here is an image showing what I mean (the picture is crap, taken quickly because my iPhone changes the colours). The only colours which are represented are blue and black however checking through the various source files ( cfb_console.c, lcd.c, etc) then there appears to be no reason why this should not work. The source image used for testing is the Toradex logo (8-bit colour as a BMP).
This is the original source image:
The following sequence is used for loading the bitmap:
splashimage 0x80000000
splashfile /boot/logo.bmp
load mmc 0:2 ${splashimage} ${splashfile}
bmp display ${splashimage}
I fully understand that I’m running quite old versions of things.
I’ve tried printing a test pattern by using #define LCD_TEST_PATTERN but this also scrambles the colours. I’ve tried converting the BMP to a 5-6-5 (16-bit) bitmap but this then displays weirdly also (a stride issue, by the looks of things).
Does anyone have any advice, please, on what I could try or where else I could look?
I’m also wondering whether it is possible to persist the same splash logo in u-boot through to the end of the Linux kernel booting but this is a separate task…
TIA!
Ah, solved it.
Turns out that there was no colormap allocated in the panel_info struct for the LCD so when it came to doing the colour profile mapping, it was using some random memory locations.
Hi @kwebster83
Perfect that you solved the issue. Thanks for the feedback.
Best regards,
Jaski
@jaski.tx yep - I even impressed myself by getting it to work. It’s the most deep and dirty I’ve ever gone with the u-boot sources.
As a side question - with the Apalis T30 - do you know if it is possible to share the framebuffer between u-boot and the kernel, so that a single logo can be displayed throughout the boot process?
Digging into the kernel sources, it doesn’t look so straightforward as various framebuffer memory is released/reallocated but maybe you know more about this than I do?
Actually you are talking about seamless splash screen. We did some research on iMX7 for a customer and the output was that it is just impossible. Linux kernel will always need to reinitialize the frame-buffer, therefore we just disabled the frame-buffer in U-Boot starting from Bsp 3.0 for the supported modules.
Anyway the time till the frame-buffer is up on Kernel side is relatively short, so we decided to not put any more resources into this.
@jaski.tx yes, a seamless splash screen is what I mean. It does look quite impossible to be honest but, I was wondering whether the framebuffer address in RAM would be the same and thus could maybe be shared (and not re-initialised) between u-boot and the kernel.
The one thing which our customers report is that there is still quite a lot of “blank screen” time while the Apalis T30 is booting. Currently, it takes about 3 seconds from initial power on before the u-boot splash is displayed (for 2 seconds), then there is a black screen for another nearly 4 seconds before the kernel splash appears (for 4 seconds) and then there is another blank screen for 5 seconds until the kernel finishes booting and our end application is launched.
I’ve trimmed out some unnecessary userspace services to improve the boot time (using systemd-analyze to get rid of the unnecessary slow ones) however I’m wondering if you can advise further about these periods of “blank screen” as mentioned above and whether there is scope to either reduce these (by initialising the LCD sooner and de-initialising later) or whether there are other tricks I can use?
Hi @kwebster83
We tried all this but there were no positive results.
You can shrink the kernel and delete configs which are not needed. Disabling the console output reduces also the boot-up time a lot.
Best regards,
Jaski
@jaski.tx ah, ok - understood. I won’t put too much effort into digging further then. I’ve removed the bootdelay and a few other things which have helped speed up the boot process.
Some of the systemctl services which were running at boot time, I’m now launching once our application is initialising (and the display is visible) - likewise with kernel modules. This is probably as good as I can get it.
I have actually thought about whether it would be possible to boot straight into the kernel and forget about u-boot entirely but this is not only waaaaay above my understanding, it would probably take me far too long!
Hi
What is delay from power-on till something is shown on the screen?
The time spent in U-Boot is less than 1s, so it does not make sense to delete it.
@jaski.tx as mentioned previously, it’s about 3 seconds from initial power on until the u-boot splash appears. The splash screen is shown for about 2 seconds (just under) and then there is a “blank” period of about 4 seconds before the kernel splash appears.
I can see that there is a lot of hardware peripheral initialisation going on before the kernel splash is shown which is why I was wondering whether I could bring up the display and framebuffer earlier in the sequence to reduce the “blank” period.
I believe the downstream NVIDIA BSP used to have such “framebuffer sharing” feature likely used in their Android implementation back at that time. We just disabled it as it was never working. But maybe if you figure out how exactly to make sure U-Boot and the Linux kernel both use the same framebuffer address it may work. Here a pointer:
https://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/mach-tegra/board-ventana-panel.c?h=tegra#n439
Thanks @marcel.tx, that’s useful. I’ll do some digging
Perfect. Let us know about your findings.
