TI E2E Community
LCD Splash Support in U-Boot (AM3517)
I need to get a splash screen displayed on our LCD ASAP after power on. Currently, there appears to be NO display support in U-Boot for the OMAPs. I was looking at the omapfb support in the Linux kernel and it looks very complicated to others I've worked with in the past.
Is there any chance of getting a minimal omapfb driver for U-Boot to initialize and burn a splash screen at bootup? It really makes the most sense to get the video up as fast as possible so the users aren't wondering if its broken. I have the total boot time to about 10 seconds, but there are some intrinsic delay overheads in the X-Load and U-Boot steps (such as copying the Kernel from NAND and decompressing).
I know there is reference software in U-Boot for Atmel's AT91 framebuffer, but it seems much simpler than the OMAP framebuffer.
As an alternative, does anyone know where the OMAP frame buffer is located (a RAM address)? I could at least dump a raw image file to the framebuffer in the Linux kernel before operation is handed to user space.
I am also facing same issue that you faced. can you let me know the stpes to read/write dss registers from u-boot.
You can directly read/write the memory directly from u-boot using md (read) and mw (write). Before you can access the DSS system, you have to ensure DPLL4 (on AM3517) and the DSS functional and interface clocks are active. The DPLL4 is usually setup by default, so you probably just need to activate the DSS clocks in the Clock (CM) registers. Once the DSS clocks are enabled, you can access the registers.
To read 32 bits from the DISPC status register (ensure you pass the count variable on the first read as U-Boot defaults to a block read which could cause the system to freeze):
md.l 48050440 1
To write 32 bits to the DISPC status register (in this case, activating the LCD interface)
mw.l 48050440 18169
Note also that U-Boot assumes HEX values...the 0x prefix is not necessary.
Be sure to look in the Technical Reference Manual for your CPU for correct register locations
Are you using FAT for your RFS? I don't think I can access my YAFFS2 partition from U-Boot...plus the EXT2/3 support in U-Boot was broken last I tried.
Back from vacation, using u-boot w/ yaffs2 support via yrdm (yaffs read file to memory). It takes seconds to load because of the rfs size.
I experimented with a nand partition for the screen
data and wrote the raw data I want to display into that partition. When the system boots it runs a memory copy to setup the video memory and then the code you provided and this provides a fast and snappy splash screen until linux boots.
I will be looking at protecting the original image (from driver) and any file system aspects now that I have a mechanism to display images.
David, thanks to your work.
Is it a good idea to make "splashscreen" only as uboot commands? Of course, memory map for NAND flash will be adjusted to store my picture.
Therefore I don't need to do something with uboot and use latest version with advanced hardware ECC support.
Aaron LuftI will be looking at protecting the original image (from driver) and any file system aspects now that I have a mechanism to display images.
Did you find such solution?
I did make changes that reduce the splash screen disturbance to just a flutter when the clocks are configured. Attached is a pseudo patch that shows the specific changes.
Here is what I did.
1) In uboot defined splashcmd to load a splash image from disk storage and set a linux command line argument.
2) Add linux command line argument "fbskip" to skip the frame buffer startup code only if uboot has posted a valid splash
3) Switched built-in omap frame buffer to loadable module for better debugging and more tightly coupled with launching ui
4) Fixup the VRAM frame loading warning about ARM not supporting ioremap and a compiler warning in DSI
5) Step thru the frame buffer initialization finding places where the uboot screen is distorted.
a) start device w/o video
b) insmod loadable modules with any debugging to track where the heck the problem is, use early exit techniques and long delays.
c) change code until splash is stable
6) Updated init.d startup script to install the splash screen and start UI program
One more aspect of this approach is uboot vram environment value being setup and correctly choosing the physical address for the frame buffer in uboot that matches the linux omap buffer setup. A better approaches would save the vram buffer contents before initializing in linux. I didn't attempt that.
I looked at the resulting base address utilized by the dispc driver and made that work from uboot. The concept here is that the uboot video setup exactly matches the resulting omap driver setup so any driver changes are just repeating what's already been done.
# cat /mnt/debugfs/omapdss/dispc | grep GFXDISPC_GFX_BA0 8ee7f7fc
Your work sounds good. I was thinking you could specify the framebuffer address on some other Linux framebuffer drivers, but I'm not finding much info about it. This might be possible using a kernel platform structure. Not sure though...maybe with mmap? A quick and dirty way might be to define a located char array in the platform or display driver file.
Having support for a locatable framebuffer would be an important feature as many embedded devices are supporting separate memory interfaces to reduce the bottleneck on the system RAM layer. To make this work, you would need to be able to define the memory space on the second RAM bus for the framebuffer.
I was essentially doing the exact same thing regarding the setting of the framebuffer location. Using the driver as a module is a clever way to delay the re-init, but of course isn't practical if one would want an animated splash screen during init (I guess you could use initrd, but I prefer not to have the extra delay at startup to copy it).
The only downside to making a splash command, rather than support U-Boot native LCD support, is that you don't have the possibility to use the LCD as the U-Boot console. Probably OK for most people, but would provide flexibility for some applications.
Also, if you can init the display prior to the boot prompt, that's just a slight bit faster time-to-splash.
Other than locating the framebuffer, you seem to have already done the rest of what I would need to do.
I need a u-boot splash screen for the AM3517, as some of you do. I've seen in the u-boot guide (http://www.denx.de/wiki/DULG/UBootSplashScreen) discussion of u-boot's existing CONFIG_SPLASH_SCREEN option. I'm wanting to understand how this overlaps with the approach discussed in this thread.In other words, does the u-boot CONFIG_SPLASH_SCREEN option require board-specific code which wasn't yet available for AM3517, and this thread discusses that board-specific code?Or, is this thread about an approach separate from the CONFIG_SPLASH_SCREEN option?Thanks,Ron
Ron OlsonIn other words, does the u-boot CONFIG_SPLASH_SCREEN option require board-specific code which wasn't yet available for AM3517
Yes, of course.
Ron Olsonand this thread discusses that board-specific code?
No. This thread discuss a little different solution. I want to do something at near month to make CONFIG_SPLASH_SCREEN
option working and to run standard command in u-boot working with bitmap pictures.
Do you know what is the difference between CONFIG_LCD and CONFIG_VIDEO options in configuring u-boot board specific file?
Some of displays use CONFIG_LCD, some use CONFIG_VIDEO.
I don't know what is the better way, and can't find additional information.
As I see, u-boot have LCD support for ATMEL chips using ateml_lcdc.h and CONFIG_LCD. Is it a good sample?
I don't need command line at my LCD.
Vitaliy Bortsov I don't know what is the better way, and can't find additional information.
I find additional information in README of u-boot, sorry.
I am still searching a way to enable OMAP3 LCD support in the barebox bootloader and I've found your post about LCD support for U-Boot.
This looks great for me as a starting point. Have you continued your work on bringing your patches mainline for u-boot ?
Is there a chance, that you share the most recent version of your patch ?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.