Seemless Boot Splash on iMX-based boards
Stefano Babic
sbabic at denx.de
Mon Jul 6 11:10:15 CEST 2020
Hi Igor,
my two cents from previous experience:
On 06.07.20 10:34, Igor Opaniuk wrote:
> Hi,
>
> Does anyone have experience in setting up seamless
> boot splash on iMX-based platforms?
>
> I'm currently trying to do that on iMX7-based board with
> 4.9 2.3.x IMX downstream kernel running.
>
Well, i.MX7 have a chance because it has no GPU. I did this for TI based
boards, too.
But let me say that it is tricky and it creates big dependencies between
U-Boot and kernel. And to get a flicker-free images, the clock setup
should be exactly the same between U-Boot and kernel, and this is not
often (or never) the same because we need a lot of more features
(layers, overlays, ..) in kernel, while we just to need to show
something like a logo in U-Boot.
With the introduction of DRM, things are more difficult. Take also into
account that a small change in kernel can be enough to have a weird
transition on the framebuffer, and it is more nasty as to start with a
black screen.
> I've backported console deferred takeover patch-series for fbcon [1],
> which permits the contents of the framebuffer (initialized before in U-Boot)
> to stay in place as is till error message is shown
> or boot is finished.
>
> The initial splash is shown in U-Boot(mainline) (mxsfb driver is used
> for controller/fb initialization).
>
> Nevertheless, MXSFB controller every time keeps resetting just after
> U-Boot->Linux takeover and fb is cleared (I see a black screen) till
> login request shows up.
Right.
>
> Questions:
> 1. Did anyone have a chance to work on such setups based on deferred
> console "feature"?
> 2. Does it make sense at all to continue moving towards with this approach
> (we initialize graphics core and show boot splash by firmware/bootloader,
> then hand over it to Linux).
My personal point of view: it makes much more sense to invest the time
to speed up the boot process, and let the kernel to boot in a shorten
time. And if this time is short enough, kernel has initialized the
framebuffer and can show something. This leads also to the main focus
for U-Boot, that should be to start the kernel in the shortest time
possible.
> Taking into account on-going transition to DRM/KMS in the mainline kernel
Fully agree.
> and that fact that there is no any mainline compatible way to take over
> an initialized graphics core, I assume the only generic solution could be
> avoiding showing boot logo
This is my position, too, and I do not show logo in U-Boot since some
years (ok, since starting from DRM /KMS). And well, with i.MX6 / i.MX8,
I do not see a chance without a very big effort, and IMHO it is not
worth of it.
> at all and do that only from the Linux (
> Plymouth-based etc.)
Agree.
>
> Any comments are welcome. Thanks!
>
> [1] https://patchwork.kernel.org/patch/10432641/
>
Best regards,
Stefano
--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
More information about the U-Boot
mailing list