Forums

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

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

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

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

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