Blog Sturntech

Archive for the ‘u-boot’ Category

Designing with Gumstix Overo: SYSEN floating is a major flaw (boot failure)

without comments

Gumstix Overo Fire COM

Gumstix Overo Fire COM

I designed my first embedded system that uses a Gumstix Overo FE COM for my employer about 11 months ago. The prototype circuit passed all functional tests and my PCB layout kept clean signal isolation and near-ideal power integrity (no ground/power ripples). The Gumstix Overo was easy to interface with and aside from learning how to configure X-Load and U-Boot to properly set the OMAP pin MUXs for the various system functions, use of the module was problem-free.

The system I designed for my employer is essentially a tablet computer that is dedicated to running an analysis application that receives and processes the output of a Photon Detector. The Photon Detector interfaced to the Overo via a UART link.

During bench testing I encountered only one unresolved ambiguity. This ambiguity was an Overo Fire whose NAND chip became irreversibly corrupted at the memory location read for U-Boot’s default environmental configuration. Since my employer wished to keep the entire system software on an MMC card, and since the system was executing U-Boot from the MMC storage anyway, I modified the U-Boot source to read the default configuration from a local configuration file instead of touching the NAND. That broken Gumstix became usable after the hack and the problem has not been seen again on any system. I have not been able to replicate the error that caused only that area of the one Overo’s NAND memory to become corrupted.

So after bench validation, a unit was placed into the hands of a technician for field testing. All was well for about 4 months when I’m contacted by the technician with word that the system is no longer booting. We replaced the unit and I set about determining the root cause for how and why the system broke.

The mode of failure is describable as “failure to boot”. The Gumstix Overo had a single green LED lit (middle of row of three) when power was applied, but no other LEDs lit (in particular the blue LED on the right did not light). The three inductors on the top of the Overo had voltages matching a working Overo (L1: +1.211V, L2: +1.201V, L3: +1.801V). The serial console would chirp the following characters out the console serial line during boot “@É ¼c”.

Reading chapter 29 (Initialization) of the 35xx OMAP Technical Reference Manual (linked at bottom) indicates that the broken piece is somewhere in the Stage 1 boot of the initialization sequence. In this Stage, the OMAP CPU copies the boot code from static ROM to the RAM. The chirps on the console serial line are a boot location request by the OMAP. Properly configured, the OMAP checks the MMC and NAND modules for bootability before checking the UART(s). The fact that the OMAP was failing to check the NAND or MMC modules, but seems to check the UART indicates that there is a mis-configuration or wide-spread sub-system failure.

Regardless of how/if the ROM became corrupted, the Overo was not reaching X-Load in the NAND or the MMC card.

The cause of the problem was found to be the support circuitry initializing before the Overo’s OMAP CPU fully initialized. In particular, the level shifters (used to interface the +3.3V logic of external systems to the +1.8V logic of the Overo) were immediately in Operating mode after Power-On. The OMAP on the Overo module, however, waits for the PMIC to initialize before beginning its initialization sequence. This allowed the level shifters to pass signals to the OMAP before it was ready.

My design included the external UART serial communication from the Photon Detector. This UART line was allowed to reach the OMAP CPU pins before the chip was initialized. All other interfaces used in this design were slaves to the OMAP and would not otherwise toggle the OMAP pins without communication from the OMAP (implying the OMAP had initialized at that point). The Photon Detector sends “am-alive” pulses every 500ms.

The timing of the Photon Detector initializing and the timing of the Overo initializing had never overlapped enough to expose this flaw in bench testing. It took one occasion during field testing where the photon detector initialized extra-fast and the Overo extra-slow to create the “system not booting” problem. This occurred when the “am-alive” pulse hit the Overo during the Overo’s initialization process.

The solution to is to couple all in-bound signal interfaces to the SYSEN signal provided on the Overo’s J1 connector (pin 59). This signal pulls Low when the OMAP is ready to go. Do not pull High any I/O line directly attached to the Overo prior to the signal of SYSEN.

Some very useful information sources for debugging this problem:
The OMAP 35xx Technical Reference Manual strongly discourages letting this happen (http://www.ti.com/lit/ug/spruf98u/spruf98u.pdf).
The Gumstix Signals Document lists the pins and implies their uses (http://www.gumstix.org/images/overo_signals_latest.pdf)

Written by sturnfie

November 8th, 2011 at 2:44 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.
vram
- Amount of total VRAM to preallocate. For example, "10M".

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

omapfb.vram
- 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.

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

omap-dss.def_disp
- Name of default display, to which all overlays will be connected.
Common examples are "lcd" or "tv".
omap-dss.debug
- 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 = {
.type = OMAP_DISPLAY_TYPE_DPI,
.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",
.type = OMAP_DISPLAY_TYPE_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