Blog Sturntech

Archive for the ‘BeagleBoard’ Category

Changing Live Video Modes with OMAPDSS

with one comment

The OMAP documentation has plenty of information on how to configure a desired video mode at boot by way of kernel boot parameters. See

Recently I was tasked with implementing a method of dynamically changing video mode timings without rebooting the system. Additionally the system is very bare-bones, consisting of essentially sysvinit, sysfs and Qt/Embedded. Size requirements dictated the absence of fbset and other nice applications in the rootfs, so a more direct route to changing the video timings was needed.

The embedded system uses a TFT LCD screen that requires a particular timing video pattern. These timings are non-VESA, meaning that while the video stream will be properly parsed by the TFT’s processor, there can be no expectation for the video stream to be parsed by any other VGA device.

The timings required for the TFT (640x480M-32@60) are:

The timings for VESA compliance (640×480-32@60) are:

These timings are relatively close, but different enough that distortion would appear on the opposite device. The TFT screen will show scattered lines and garbling when using the VESA-compliant timings. VGA devices would show an assortment of results when using the TFT timings, including fully functional, entirely non-functional, screen clipping, screen shifting, and distortion.

My solution was to allow our sales staff a key sequence to directly modify the timings held in the display0 entry found at /sys/devices/platform/omapdss/display0 entry. The device would boot with the TFT timings, and on a key-press, would switch to the VESA-timings. The idea is that the sales staff can switch to “projector” mode when training, allowing the audience to see a clean image at the cost of slight distortion on the handheld display.

The basic approach was the following:

# Change to TFT timings
echo “23750,640/80/16/64,480/3/13/4” > /sys/devices/platform/omapdss/display0/timings

# Change to VESA timings
echo “25175,640/40/24/96,480/32/11/2” > /sys/devices/platform/omapdss/display0/timings

Written by sturnfie

January 19th, 2012 at 3:27 pm

Embedded Linux: Changing TFT-LCD screens

without comments

A general approach to changing TFT-LCD screens is documented here. The platform for this posting is OMAP3 (gumstix overo and beagleboard -xm).

The OMAP2/3 Display Sub-System is nicely documented in this dev repository.

A common method for configuring omapfb is to pass the configuration parameters as boot arguments when the linux kernel is initialized.

You can find this list in the development repository at the top of this post.
This is a listing of the configuration parameters for omapfb.
- Amount of total VRAM to preallocate. For example, "10M".

- Default video mode for default display. For example, "dvi:800x400MR-24@60". See drivers/video/modedb.c

- VRAM allocated for each framebuffer. Normally omapfb allocates vram
depending on the display size. With this you can manually allocate
more. For example "4M,3M" allocates 4M for fb0, 3M for fb1.

- Enable debug printing. You have to have OMAPFB debug support enabled
in kernel config.

- Name of default display, to which all overlays will be connected.
Common examples are "lcd" or "tv".
- Enable debug printing. You have to have DSS debug support enabled in
kernel config.

The kernel bootloader must be modified by adding these variables to the boot arguments. If you already have a working omapfb framebuffer, then most likely these variables are already being set to non-configured values.

If you are using the U-boot bootloader (found here) then it is a simple task to modify the bootargs variable. There is a pretty good writeup by Texas Instruments detailing how to modify U-boot (found here).

My bootargs line reads:
console=ttyS2,115200n8 mpurate=500 vram=12M omapfb.mode=dvi:640x480@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait

So you’ve configured omapfb and your embedded linux system is outputting a LCD signal suitable for driving a TFT-LCD panel. If the image is distorted, a possible cause is that your particular panel is not supported by the display device driver you chose to use.

The Linux Kernel has drivers. Some of these drivers were written to support TFT-LCD screen devices.

I’d suggest finding the datasheet for the new panel. Find the timing value ranges for the pixel clock, the vertical sync pulses, the horizontal sync pulses, the “front” and “back” porches, and the data enable signals.

Here is an example set of specifications (taken from the datasheet for an NEC NL6448AC33)

Find the source code for the display device driver you are using. The display device driver was selected when the “omap_dss.def_disp” and “omapfb.mode” bootargs variables were set. The various text strings used to configure that option (example, “tv”, “dvi”, “lcd”) are mapped to a device driver in the board file used to configure the linux kernel. It is usually found in the /arch/ directory of the kernel source. For example: When configuring the linux kernel for a beagleboard, it is found at /arch/arm/mach-omap2/board-omap3beagle.c

Here are the mappings for “dvi” and “tv”:

static struct omap_dss_device beagle_dvi_device = {
.name = "dvi",
.driver_name = "generic_panel",
.phy.dpi.data_lines = 24,
.platform_enable = beagle_enable_dvi,
.platform_disable = beagle_disable_dvi,

static struct omap_dss_device beagle_tv_device = {
.name = "tv",
.driver_name = "venc",
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
.platform_enable = beagle_panel_enable_tv,
.platform_disable = beagle_panel_disable_tv,

The driver_name variable indicates the device driver that is being used. These are found in the /drivers/ directory of the linux kernel source. For example, the “panel-generic” driver linked to the “dvi” text can be found in /drivers/video/omap2/displays/panel-generic.c

The timings can be found near the top of this file:

static struct omap_video_timings generic_panel_timings = {
/* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
.x_res = 640,
.y_res = 480,
.pixel_clock = 23500,
.hfp = 48,
.hsw = 32,
.hbp = 80,
.vfp = 3,
.vsw = 4,
.vbp = 7,

Configuring these values to match those specified by your LCD panel should be a simple task from here. After that you can rebuild your kernel and hopefully enjoying a functional embedded display running on your new LCD.

If you need to do more than simply tune the timing values, I like to find kernel patches that modified something similar in the kernel for hints on where to look for the files I would need to modify. For the task of specifying a custom driver, here’s the kernel patch that changed a set of arch board files to use generic device drivers instead of the old default drivers (found here).

Significant development for the display you’re supporting can be submitted as a patch to the Linux Kernel Development Lists to possibly become part of the Linux Kernel and allow your work to benefit the Open-Source community.

Written by sturnfie

March 26th, 2011 at 7:36 pm

Linux: ELF file extraction of 32-bit binaries on a 64-bit system (Error)

without comments

I use OpenEmbedded and Bitbake to build cross-compiled bootloaders, linux kernels, and filesystems for embedded device projects. I’m currently working with several OMAP35x based boards (BeagleBoard, Gumstix). My development system runs on an AMD64 architecture (Ubuntu 10.10 (Maverick)). My target architecture is ARMv7.

I’ve been working on building a variation of the “omap3-sgx-modules” bitbake recipe. This recipe uses the SGX SDK provided by Texas Instruments for their access functions for off-loading the graphics-processing from the Cortex-A8 ARMv7 core to the TMS320C64x+ DSP core.

When “baking” the recipe, I was getting the following error output:
OE:beagleboard lucas@godzilla:~/oe$ bitbake omap3-sgx-modules
Build Configuration:
BB_VERSION = "1.10.2"
METADATA_BRANCH = "beagleboard"
TARGET_OS = "linux-gnueabi"
MACHINE = "beagleboard"
DISTRO = "angstrom"
DISTRO_VERSION = "2010.7-20110218"
TARGET_FPU = "hard"
NOTE: Running task 96 of 213 (ID: 13, /home/lucas/oe/, do_compile)
ERROR: Task 13 (/home/lucas/oe/, do_compile) failed with 256
ERROR: '/home/lucas/oe/' failed
NOTE: package omap3-sgx-modules- task do_compile: Started
ERROR: Function do_compile failed
Log data follows:
| NOTE: make -j 4 -e MAKEFLAGS= KERNEL_PATH=/home/lucas/oe/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/kernel KERNEL_SRC=/home/lucas/oe/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/kernel KDIR=/home/lucas/oe/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/kernel KERNELDIR=/home/lucas/oe/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/kernel KERNEL_DIR=/home/lucas/oe/tmp/sysroots/beagleboard-angstrom-linux-gnueabi/kernel KERNEL_VERSION=2.6.29-omap1 CC=arm-angstrom-linux-gnueabi-gcc -mno-thumb-interwork -mno-thumb LD=arm-angstrom-linux-gnueabi-ld AR=arm-angstrom-linux-gnueabi-ar BUILD=release
| make: *** No targets specified and no makefile found. Stop.
| FATAL: oe_runmake failed
ERROR: '/home/lucas/oe/' failed

If you didn’t modify the file and left the patches as part of the bitbake recipe, bitbake will crash on the do_patch step with a quilt-related error. It won’t make it far enough to reach the make related error statements shown above. The function call to quilt (and the call to make) fail due to missing files. These files were supposed to be extracted from an archive file that passed an md5sum check.

Very strange. A glance at the OpenEmbedded temporary work directory: oe/tmp/work/beagleboard-angstrom-linux-gnueabi/omap3-sgx-modules/ shows that only a skeleton of a filesystem was created (some folders, no files). It seems that bitbake tried to initiate the ELF-file’s self-extraction but something silently failed in the process.

The root problem was the lack of the ia32-libs libraries. This library is required to read the 32-bit ELF binary-file.

Written by sturnfie

February 18th, 2011 at 6:17 pm