From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Opaniuk Date: Sun, 12 Jul 2020 13:24:57 +0300 Subject: Seemless Boot Splash on iMX-based boards In-Reply-To: <1d498d4e-d290-dc46-9ec9-42c70a3f7f4d@denx.de> References: <1d498d4e-d290-dc46-9ec9-42c70a3f7f4d@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Stefano, On Mon, Jul 6, 2020 at 12:10 PM Stefano Babic 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