From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anatolij Gustschin Date: Thu, 6 Jun 2013 00:31:12 +0200 Subject: [U-Boot] Maintain U-Boot splash until application is loaded In-Reply-To: References: Message-ID: <20130606003112.24fda947@crub> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Otavio, On Tue, 4 Jun 2013 23:13:43 -0300 Otavio Salvador wrote: ... > I am working in a product and we'd like to keep the U-Boot splash until the > application has been loaded so we have a graceful initialization. This > project uses MX23 (so mxs SoC family). > > I tried to check the U-Boot mailing list archive for it but I couldn't find > anything useful. I also did look at kernel source and it seems > CONFIG_FB_PRE_INIT_FB is available for only *one* board. > > Could someone advice me how to do that? the mxs frame buffer driver in mainline linux tree looks in platform data structure "struct mxsfb_platform_data" for fb_phys and fb_size fields and uses this memory range for the frame buffer (if these are initialized by platform code). But the platform code in arch/arm/mach-mxs/mach-mxs.c doesn't initialize them. The platform code could be extended to check if the display controller is initialized by the boot loader and in this case it should read out the frame buffer base address from the display controller registers and calculate the frame buffer size using the resolution and depth values from the controller registers. Then this frame buffer range could be reserved (by reserve_bootmem()) so that the kernel doesn't use it for other purposes, and the reserved range should be passed in mxsfb_platform_data to the frame buffer driver. When booting, the frame buffer could be used by frame buffer console fbcon and in this case your splash will be overwritten. To prevent this you could pass fbcon=map:1 on the kernel command line and if the console on frame buffer is needed later, then map the console to the frame buffer by appropriate ioctl (see con2fbmap utility). Thanks, Anatolij