LCD Splash Support in U-Boot (AM3517)

David Paden said:

Is there any chance of getting a minimal omapfb driver for U-Boot to initialize and burn a splash screen at bootup? 

This is certainly possible, though it is something that would have to be unique to your particular board. There is something similar I have seen done on the Beagle Board U-Boot which has a splash screen (or at least used to), there is a patch for it  posted up at http://groups.google.com/group/beagleboard/browse_thread/thread/3ad9b803a3418624. Of course this patch is somewhat specific to the Beagle, but it would be a fine place to start for your own splash screen on the AM3517.

David Paden said:

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.

The location of the frame buffer is not really a constant, it is defined in the display sub system registers that are typically configured by the display driver, so your U-Boot splash screen patch will have to configure the DSS a bit, than dump the data to the frame buffer location you configured the DSS for.

Well, it looks like I'll be working on this in the near future.  I'll look in to the link you sent me as soon as I can.

How similar is the Beagle's DSS system to the AM3517?  Is the register layout the same?

David Paden said:

How similar is the Beagle's DSS system to the AM3517?  Is the register layout the same?

They should be almost identical however I have not made a register by register comparison, the DSS used in both is based on the same design, though you may have to make adjustments for your own external display hardware (i.e. set up a LCD, DVI transmitter, etc.).

I've begun adding a omapdss driver to uboot based on the Beagle Board patch you sent me.  It appears that the DSS register layout is nearly (if not) identical to the AM3517, so I've used it for reference.

If I use the Beagle Board patch verbatim, U-Boot throws an error and halts...if I remove the DSS initialization code it runs fine.

So, it seems I have a problem however with accessing the VENC/DSS/DISPC registers.  I've been using devmem2 to read out registers to compare the values to those used on the Beagle Board.  It seems the first few registers are OK (0x48310034 [GPIO1 GPIO_OE], 0x48310094 [GPIO1 GPIO_SETDATAOUT], 0x48004D44 [CM_CLKSEL2_PLL], 0x48004E40 [CM_CLKSEL_DSS], 0x48004D00 [CM_CLKEN_PLL])

The problem is accessing, for example, 0x48050C00 [VENC_REV_ID] or 0x48050000 [DSS_REVISIONNUMBER].  I get the error message:

Unhandled fault: external abort on non-linefetch (0x1018) at ...

Which I have read elsewhere may be because the clocks aren't enabled properly.  I checked multiple CM registers and it looks to me like everything is enabled properly and the clocks are running (CM_FLKEN_DSS, CM_ICLKEN_DSS, CM_IDLEST_DSS, CM_CLKSEL_DSS, CM_CLKSTST_DSS).

What's the proper clock startup sequence to be able to read from the DSS, DISPC, and VENC modules?

Good news!

I have a working U-Boot "driver" for the OMAP DSS system.  It's been tested using AM3517 and is based on the Beagle Board patch.

This driver takes the Linux Kernel LCD Panel Timings structure and some additional information, then calculates a rough guesstimate for the needed LCD Logic and Pixel Clocks (based on the hard-coded 13MHz sys_clk and DPLL4 settings)

You can provide the splash screen in a GIMP header file as well.

Will post a patch for the driver and AM3517 EVM board file once I've cleaned it up a bit more.  It should only take minor revising to implement DVI and VENC.  Also some revision to add DSI and/or DSI PLL support might be nice.

I wonder if this is the correct place to post such a patch if someone wants to review it and see about pushing it into the main U-Boot release package...

Right place to submit the patch would be the u-boot mailing list: u-boot@lists.denx.de - though you can attach here just for sharing.

Since you mentioned use of GIMP header file, you may want to search the mailing list for a similar patch on splash support for beagleboard. This patch was not accepted. I believe the reason was use of C array to store the logo.

The discussion on this patch should help you prepare a good patch.

Indeed, in the past I remember U-Boot wants to use a bitmap (BMP) in an additional NAND location.  This will be slightly annoying to adjust the NAND partitioning, but not impossible.

For a 800x480 LCD at 16bpp, I'm looking at 750KB for such a file.  Maximum resolution on AM3517 is 1400x1050@24bit, so I'd probably need 4.5MB to support everything.

Personally, I didn't like the Beagle patch because it used static addresses for all registers and was not easily altered for different displays.

I will check out U-Boot's intended BMP implementation and try to adapt my software accordingly.

This looks useful, looking  forward to seeing the patch.  Any way to get a version to try today?

Here is the patch in its current condition.  There are some extra register structures for the PRCM I'd like to add to finish removing the hardcoded register addresses and some comments about register addresses that can be removed now that they've been verified.  I have also included a sample logo header as I've not had time to switch over to U-Boot's bitmap method yet.

It should be set up to use the AM3517 EVM LCD, but should be reasonably portable with extra comments to aid anyone who needs to modify it.  All configuration is done in the AM3517EVM configuration file in include/configs.  The driver is located in drivers/video.

Looks like this forum is going to insert the text from the patch below...is there a way to attach a binary file on the forum since this is pretty large (so I don't have to do it this way in the future)?

---

7220.u-boot-2009.11-psp03.00.01.06.sdk-omapdss.patch.txt

David Paden said:

Looks like this forum is going to insert the text from the patch below...is there a way to attach a binary file on the forum since this is pretty large (so I don't have to do it this way in the future)?

Oh yeah, need to add licensing information at the top of the driver files, too.  Some of that source code was copied out of the Kernel sources.

And never mind about that last question about posting the patch text, looks like the forum doesn't just insert it after all.

Well, I was going to attach a tar.bz2 rather than a zip file.  It doesn't like .patch or .bz2 extensions.  I'll use zip then.

It looks like U-Boot has a common LCD framework for drawing logos and printing the boot console on the display.  It seems the right way to do this is to implement the LCD in such a way to work with the common framework.  Once this is done, U-Boot should be able to do the bitmap logos and console support on the display itself.

We'll see when I have some time to work on it...

Thank you, this worked well and the complete regs definition are an improvement over what exists in the include/asm-arm/arch-omap3/dss.h file.

Was easy to use and modify, I am planning to store my splash screen in the root fs.

Thanks again!

Oh...my version of U-Boot didn't even come with DSS register definitions...I should probably add them

I prefer the structure access over the raw register addressing that is currently used in the Linux kernel, but whatever.  They both get the job done.

What board and LCD did you try it on?  I had a bug this afternoon on my AM3517 EVM, but it was probably a change a made today.

David

    I am also facing same issue that you faced. can you let me know the stpes to read/write dss registers from u-boot.

Raman VC

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

Aaron,

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.

Hi David,

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.

Regards,

Aaron

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 Luft said:

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.

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

Aaron

 1754.psuedo-splash.zip

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 GFX
DISPC_GFX_BA0                       8ee7f7fc

Aaron,

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).

Aaron,

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 Olson said:

In 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 Olson said:

and 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.

David Paden,

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.

Good news!

http://git.denx.de/?p=u-boot/u-boot-ti.git;a=commit;h=de701d118380de12a48c8a4fb345e9f909329432

Vitaliy Bortsov said:

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.

Hi David,

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 ?

Thanks !

Jürgen

Hii David

I seen the patch codes..

But am bot getting why to configure VENC registers for gfx display..?

Is it necessary .?

can you clarify.?

Regards,

vineet

Hi Vineet,

This is a pretty old issue.  We use the GFX in uboot to let user know a lengthy process is happening.  In our case the splash screen appears from power on until QT starts.  Once QT starts a progress bar is added to the screen.  After that the application is running the splash screen is removed and normal operation begins.

Additionally, having GFX in uboot allows developer modes with uboot output onto the LCD and accepts touch screen inputs for simplistic choices like "reset to defaults", when a USB keyboard is attached the LCD and keyboard make a complete terminal without having another computer attached.

All the best,

Aaron

Hi,

As Aaron said, you only need the VENC code if you want to use the LCD framebuffer in U-Boot.  Those registers were copied from the Kernel DSS init code to just "get it working."

From the customer point-of-view, the startup time from initial power-up to something displayed on the LCD is very important.  If the display doesn't get initialized until late in the Kernel boot, they perceive a slow bootup.  If you can minimize the U-Boot time (such as bootdelay = 0) you may not need LCD support in U-Boot.

Also, you can use psplash (this is what TI uses for their kernel boot splash) to show a custom boot progress image so you don't have to wait all the way until you can run an app, as in Aaron's application.

Dave

Hi,

I got output, but the image is not coming properly..

its coming 4 time in a row and in the 20% of screen.

i have 800*480 lcd.

what can be the problem.?

how to map a line or draw a pixel on frame buffer.?

Vineet

First check your VSYNC and HSYNC timings.  In the code, you'll see Vertical Front Porch (VFP), Vertical Back Porch (VBP), Vertical Sync or Pulse (VS), and the same for Horizontal (HBP, HFP, HS).  These are defined by your LCD manufacturer and you need to adjust the DSS driver code accordingly.

The timings in the patch were for my 800x480 panel (very similar to the one used on the kit).  Not all panels use the same settings.

A framebuffer address should have been specified in the initialization code as well.  If you want to write data, you just write your pixel data in the framebuffer (offset 0 = first pixel).  Just use whatever format specified in the driver (typically 8:8:8, or 5:6:5).  You can write a bunch of 0xFF to set some white pixels for initial testing.

Hi David

Thanx for your reply.

Here is my timing setting look whether its ok or not .?

        DISPC_TIMING_H = 0x00100130;
        DISPC_TIMING_V = 0x01900C03;
        DISPC_POL_FREQ = 0x0003001C;
        DISPC_DIVISOR = 0x00010002;
        DISPC_SIZE_LCD = 799 | (479 << 16);
        DISPC_GFX_BA0 = 0x80500000;
        DISPC_GFX_BA1 = 0x80500000 ;

i have attached lcd panel datasheet also ..

Hi,

how to display characters(fonts) on lcd.?

BR

vineet

Hi Vineet,

So, you'll have to do it manually (yourself).  U-Boot has a built-in graphics system, but the display driver is not at all setup to work with it.  When setup properly, it can provide on an-screen boot-console (with keyboard support), status messages, etc.  You could take the time to figure all that out if you have the time...I'm sure some would greatly appreciate the work.

If you don't want to do that you could easily do one of two options: (1) Copy the FreeType2 sources into U-Boot, compile them and a Font face file in, and use freetype to render the characters directly to the framebuffer, or (2) Generate one font face (glyphs) into a particular size, compile them into U-Boot, and copy them to the framebuffer.  You'd create a function to print the text to the screen and the function would copy the needed glyph based on the ASCII codes.

You might also look into Barebox.  It is the "next gen" bootloader and is more closely based on the Linux Kernel sources.  If AM3517 is supported in Barebox, framebuffer console support should be easy to get running.