Seemless Boot Splash on iMX-based boards

[Igor Opaniuk]

Hi Stefano,

On Mon, Jul 6, 2020 at 12:10 PM Stefano Babic <sbabic at denx.de> wrote:
>
> 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
> =====================================================================

Thanks a lot for your valuable input!

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opaniuk at gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk