lunedì 25 maggio 2009

Updates, NOR and NAND flash support.

Modifications on mx3fb driver are not to be accepted because of the maintainer won't add machine specific code in that file.. Nevermind, I keep the patch in my hand waiting for another solution :)

In those days I worked on NOR & NAND flash support:
NOR flash device is mounted on the CPU credit card and it works well with physmap mapping driver.
NAND flash device is mounted on the motherboard and supporting it was a bit harder:
In tree there is a NAND flash driver for MXC architecture mxc_nand.c derived from original freescale driver and corrected over coding style and kernel way of doing by Sascha Hauer . Unfortunately this driver do not support flash devices with large page size (2kB wide, over 512 B of small page size devices) and upgrading it was over my capability..
The solution came from a graceful guy called Vladimir Barinov from linux-mtd list where I posted the problem. He gave me the right patch that merged with my work make the NAND flash device working!

So now I can store data in all memory devices mounted on the board! Great!

Alberto!

giovedì 14 maggio 2009

Framebuffer OK!! explanation

OOK what was the problem and what I've understood:
First of all I built with success the OSELAS.BSP-Phytec-phyCORE-10 following the great guide OSELAS.BSP-Phytec-phyCORE-i.MX31-Quickstart.pdf, remember, I had already built the OSELAS toolchain optimized for arm-1136jfs-linux-gnueabi.

Booting with the new filesystem (after some adjustment to /etc/network/interfaces to have eth0 statically assigned ip and /etc/modules to do not try to load unwanted modules) was fine, but fbset was still not working!
From the logo printed on the screen the problem with mx3fb driver was for sure not only in timings parameters of the video mode but also some other timings settings.

Fortunately the driver mx3fb is derived from the Freescale mxcfb making comparison simpler :)
With a deep debugging and comparison between the two drivers: mx3fb and mxcfb (from Atmark version of 2.6.26 kernel) I've found this:
in ipu_sdc.c:ipu_sdc_init_panel

#ifdef CONFIG_MACH_ARMADILLO5X0
old_conf = (div |
((div >> 4) - 1) << 24 | /* DISP3_IF_CLK_DOWN_WR */
((div >> 4) - 2) << 14); /* DISP3_IF_CLK_UP_WR */
mx3fb_write_reg(mx3fb, old_conf, DI_DISP3_TIME_CONF);
#else
/*
* DISP3_IF_CLK_DOWN_WR is half the divider value and 2 fraction bits
* fewer. Subtract 1 extra from DISP3_IF_CLK_DOWN_WR based on timing
* debug. DISP3_IF_CLK_UP_WR is 0
*/
mx3fb_write_reg(mx3fb, (((div / 8) - 1) << 22) | div, DI_DISP3_TIME_CONF);
#endif

The DI_DISP3_TIME_CONF sdc register contain timing configuration for the pixel writing process (from lower bit):
  • DISP3_IF_CLK_PER_WR: 12 bit (8 bit for integer part and 4 bit for fractional) sets the divider for HSP_CLOCK (ipu_clk) to obtain the right pixel period.
  • DISP3_IF_CLK_UP_WR: 10 bit (6 bit for integer part and 4 bit for fractional) sets the rising edge position for display write access.
  • DISP3_IF_CLK_DOWN_WR: 10 bit (6 bit for integer part and 4 bit for fractional) sets the falling edge position for display write access.
The Atmark armadillo 500 board have a Video DAC (ADV7125) that transforms digital synchronous display signals in analog signals to drive a standard VGA connector for standard display devices. Those different timing configurations was due Video DAC timing specifications and so this piece of code must be ported to mx3fb driver in sdc_init_panel function!

Yes! first timing misconfiguration solved!

But the screen was still over margins, not well proportioned and last but not least there was a shadowed band of a few pixels in width on the entire height of the screen!
All those misconfiguration was solved calibrating the timings mode parameters moving the image on right over the shadowed band. This maintaining the timings constraints of the VGA displays.

How work the VGA standard display:
Horizontal sync signal:
__ ______________________________ ___________
|_| |_|
|A|
|---------------B----------------|

Data:
______________________ ________
________| VIDEO |________| VIDEO (next line)
|-C-|----------D-----------|-E-|

A: Horizontal sync pulse.
B: Scanline period made of:
C: Left border (Back porch) waiting for current stability.
D: Valid Video data.
E: Right border (Front porch) cutting off current instability.

Vertical timings definition are similar.
Now for a resolution of 640x480 at 60Hz refresh rate (VGA standard) are defined those frequencies:
Clock frequency 25.175 MHz (Pixel frequency)
Line frequency 31469 Hz -> 800 pixel per line.
Field frequency 59.94 Hz -> 525 lines.
Timing mode parameters must meet those constraints but we can decide amounts of left and upper margins panning the valid image onto a well displayed position!

After many tests, the better result was achieved with this configuration:
{    /* 640x480 @ 60 Hz */
.name = "CRT-VGA",
.refresh = 60,
.xres = 640,
.yres = 480,
.pixclock = 39721, //Period in picos
.left_margin = 35,
.right_margin = 115,
.upper_margin = 43,
.lower_margin = 1,
.hsync_len = 10,
.vsync_len = 1,
.sync = FB_SYNC_OE_ACT_HIGH,
.vmode = FB_VMODE_NONINTERLACED,
.flag = 0,
},
Same process for the resolution 800x600 with 56Hz of refresh rate results in this video mode:
{    /* 800x600 @ 56 Hz */
.name = "CRT-SVGA",
.refresh = 56,
.xres = 800,
.yres = 600,
.pixclock = 30000,
.left_margin = 30,
.right_margin = 108,
.upper_margin = 13,
.lower_margin = 10,
.hsync_len = 10,
.vsync_len = 1,
.sync = FB_SYNC_OE_ACT_HIGH | FB_SYNC_HOR_HIGH_ACT |
FB_SYNC_VERT_HIGH_ACT,
.vmode = FB_VMODE_NONINTERLACED,
.flag = 0,
},

Here a well formed information repository on how VGA work.

Next, USB!

mercoledì 13 maggio 2009

Framebuffer OK!!

Five days spent solving framebuffers problems, but damn! I've got it! :)
Next post will be the full explanation..
Bye!

venerdì 8 maggio 2009

Framebuffer calibration!

I'm trying to calibrate the frame buffer modes.
Basically I tried to apply the same modes from the old Atmark implementation for CRT-VGA and CRT-SVGA in drivers/video/mxc/mxcfb.c to the new mx3fb.c driver in 2.6.30 kernel but the screen look out of borders in left and up. Also words printed have soft yellow shadows and the logo seems to be printed in 16 colours not 16 bpp :)

fbset is the utility made for me now (here the man page) it give me the ability to change geometry and timings of the screen but seems not work!
I've tried for so much time, but no results and every time recompiling the kernel to see changes of adjusting parameters is not a praticable way.

Now I'm trying to build the OSELAS BSP for their i.MX31 board. Thanks to Pengutronix!
Hoping this will help me :)

Bye!

giovedì 7 maggio 2009

Nice Day Today! :)

Guys, I am proud to announce that the console-image from openembedded is working!
I've got full serial login and VGA login prompt!

Next work:
  • RTC not found? maybe shoud be only enabled from kernel config.
  • Adjust VGA output: It print over screen and seems to have only 16 colours not 16bpp!
  • Add USB support: Mouse! Keyboard!
After that i will focus on Android!

Openembedded and a sutable distro

Here all the steps to build a valid root filesystem where I can deal with all my work since here!

I choose Openembedded as build system to build the linux distribution, first for curiosity (in so many place it is mentioned an so many people tell me about), last for no other known choices! (Sorry at anyone that fight to open the way for your own embedded distribuition build system)

Openembedded main page is here and following the Getting Started guide i had been able to create a valid Openembedded enviroment in my workstation:
Base dir
$ mkdir -p /media/dati/oe/stuff/build/conf
$ cd /media/dati/oe/stuff/

For BitBake
$ svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake

For Openembedded
$ git clone git://git.openembedded.net/openembedded
Next I created the BitBake configuration file locale.conf:
$ cd /media/dati/oe/stuff/
$ cp openembedded/conf/local.conf.sample build/conf/local.conf

Editing it for me it result: (without comments..):

TOPDIR = "/media/dati/oe"
DL_DIR = "${TOPDIR}/sources"

BBFILES = "${TOPDIR}/stuff/openembedded/recipes/*/*.bb"

BBMASK = ""

PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-intermediate:gcc-cross-intermediate"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"

MACHINE = "armadillo500"

TARGET_OS = "linux"

DISTRO = "angstrom-2008.1"

GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 it_DE.UTF-8"

IMAGE_FSTYPES = "ext2"

CACHE = "${TOPDIR}/cache"

BBINCLUDELOGS = "yes"
And next the patch to openembedded: 0001-Initial-Armadillo-500-support-for-OpenEmbedded.patch

Applying this the command:
$ cd /media/dati/oe/stuff/
$ bitbake helloworld-image
Produce at /media/dati/oe/tmp/deploy/glibc/images/armadillo500 the file Angstrom-helloworld-image-glibc-ipk-2009.X-test-20090506-armadillo500.rootfs.ext2
that mounted as loopback filesystem on /nfsarmadilloroot:
$ sudo mount Angstrom-helloworld-image-glibc-ipk-2009.X-test-20090506-armadillo500.rootfs.ext2 /nfsarmadilloroot -t ext2 -o loop
Work great as rootfilesystem!

That's all folks :)

Next is a console-image..
Openembedded take so much time building! Sure.. it build also so much software not needed.. nevermind I'm not here to penetrate in that build process. :P

Angsrom Login!!!

Yes YES YESSSSS!
I've got the Angstrom Login prompt on the VGA screen! Yes the problem suggested was true, new kernel, wrong version of glibc.
Next the entire process to have a working Angstrom helloworld-image :)

mercoledì 6 maggio 2009

Revision Point.

Last post in this blog was weeks ago!
I've been far from internet for a while but also not far from my thesis!
What I worked out:
  1. Ethernet support (SMSC 9118) with nfs root capability.
  2. MMC/SD card device support (SDHC).
Since now I worked on Frame buffer support with discrete success (Logo displayed on the screen), but THE problem is not solved! THE problem is that with the latest kernel, the distro given from Atmark crashes in early init process! with no chances of debugging!
The only things that I know are the lists of files that the init process try to load from the nfs root before it crash without outputs.

I think it is a conflict between the new kernel and the precompiled C libraries stored in the root directory.
So now I'm working for building a compatible distro from Openembedded hoping this process is painless :p

Bye!