Save time and effort with Buildroot

OK, so now that I have the board up and running I decided to put

“DirectFB” on it. DirectFB will need tslib if you want to use the
touch screen, png, gif and jpeg libraries and png it needs zlib.
I started to build everything individually but I ran into problems
trying to compile and glue all this together and it was time
consuming.

For example, tslib will not work asd it keeps complaining about
protocol version mismatch plus other stuff so I decided to get
“Buildroot” and do the lot from scratch except for the kernel
and uboot.

First, I found out the reason tslib was complaining is the
last compiler I got for the board did not have the kernel
headers that matches the kernel I am using, mainly 3.0.1.

So first I need to extract the header files from the same kernel
source code tree that I have used to compile for the board.

In the kernel source code tree I did the following:

“make INSTALL_HDR_PATH=/home/<yourhomedirectory>/dst headers_install”

INSTALL_HDR_PATH is where you want to be installed (I copy to
a tmp directory and copy the lot to my compiler/usr/include.

This got rid of tslib erros and it works fine now.

Download Builtroot from here:

http://www.buildroot.org/

install wherever you want. Go to where you installed it,
and do “make clean” and “make distclean” (I know I am just
paranoid).

now do “make menuconfig” and start configuring what you want.

I did:

Target Architecture (arm)
Target Architecture Variant (arm1176jzf-s)
Target ABI (EABI)
Build Options
I left all defaults and enabled
[*] Enable compiler cache
Toolchain
Toolchain type (External toolchain)
Toolchain (Custom toolchain)
(/usr/loca/arm/4.3.2) Toolchain path
($(ARCH)-none-linux-gnueabi) Toolchain prefix
External Toolchain C library (glibc)
[*] Toolchain has C++ support?
/* used rest for default but make mmu is enabled */
System Configuration
(OK6410) System hostname
(Welcome to OK6410) System banner
/dev management (dynamic using mdev)
(ttySAC0) port to run a getty (login prompt) on
/* rest default */
Package Selection for the target
Bysubox
BusyBox version (busybox 1.118.x)
Graphics Libraries and applications (graphic/text)
directfb
/dev/input/eventX
keyboard
touchscreen support
GIF
JPEG
PNG
directfb examples
SawMan
LiTE
File system Images
cramfs root filesystem
tar the root filesystem

that is it.

exit Buildroot and save the configurations.

type make and do a cup of tea for about half hour (depends on your hardware).

When finished you will end with downloaded packages in “dl” directory.
You will also have an “output” directory that contains:

build (where packages are compiled)
host (where host toolchain is copied)
images (where the tarred target filesystem goes)
target (the actual target filesystm)
staging (target filesysem but with development files. I use this to develop application)
….

I use the tarred filesystem (rootfs.tar) in images and extract to
be exported over NFS. This what the actual target use for booting
and mounting over NFS.

With this in mind, I had a filesystem populated with BusyBox,
libraries, and whatever I decided to put there including DurectFB,
examples, tslib etc..

Note about tslib. By default it uses /dev/input/event0 for touch screen
but on OK6410 this is for the on board keyboard. To properly configure
tslib do the following:

On youe target filesystem, goto /etc and

edit ts.conf

uncomment the first line and please make sure there is no space at the
beginning or you will get segmentation fault (don’t ask).

Next export the following tslib environment variables:

TSLIB_TSDEVICE=/dev/input/event1
TSLIB_CONFFILE=/etc/ts.conf
TSLIB_CALIBFILE=/etc/pointercal
TSLIB_FBDEVICE=/dev/fb0
TSLIB_PLUGINDIR=/usr/lib/ts
TSLIB_CONSOLEDEVICE=/dev/tty

For DirectFB, create a file called “directfbrc” and add the following:

wm=sawman
tslib-devices=/dev/input/event1

save and quit.

Now you shoudl be able to run all directfb examples, start with df_andi, df_fire
and then use df_input to test that touchscreen and pen works.

That is it. ENJOY.

NOTE: You can also configure buildroot to build “dbg” and “dbg server”
for remote debugging. I download and insight and compield that for
remote debugging (it comes with gdb and gdbserver
plus an easy to use GUI and reasonably fast for debugging).

Linux framebuffer on OK6410

Framebuffer programming:

There are very few information on how to use the framebuffer on the user side rather than frambuffer
developers.

I put this together and it is not complete by any means. It is what I managed to find and experiment with.

Devices:

You will need to compile the kernel with framebuffer support. Most kernels are configured by default to support
frame buffers.

For the OK6410 it comes with excellent support for Frame Buffers. Open your .config or OK6410_CFG found
in the Linux directory (unpack the kernel that comes with the board), and here is the section:

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y

CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
CONFIG_FB_S3C_EXT=y
CONFIG_FB_S3C_EXT_TFT480272=y

CONFIG_FB_S3C_EXT_BPP=y

CONFIG_FB_S3C_EXT_BPP_16=y
# CONFIG_FB_S3C_EXT_BPP_24 is not set
# CONFIG_FB_S3C_EXT_BPP_28 is not set
# CONFIG_FB_S3C_EXT_BPP_32 is not set
CONFIG_FB_S3C_EXT_NUM=4
CONFIG_FB_S3C_EXT_VIRTUAL_SCREEN=y
CONFIG_FB_S3C_EXT_DOUBLE_BUFFERING=y

This will support 4 frame buffers with 16BPP.

Once the kernel is compiled you will see them in /dev, like so:

root@OK6410 /]# ls /dev/fb*
/dev/fb0 /dev/fb1 /dev/fb2 /dev/fb3

Accessing the framebuffer:

You access the framebuffer by opening the device as a file (standard UNIX) and getting an file descriptor to it (fd):

#include

// open framebuffer device and read out info
int fd = open(“/dev/fb0”, O_RDWR);

(don’t forget to check for errors).

Next to start issuing IOCTL commands to the buffer. Possible cmds are:

/*
* ioctl values
*
* FBIOGET_VSCREENINFO get variable information of the framerbuffer
* FBIOPUT_VSCREENINFO put variable informaton of the framebuffer
* FBIOGET_FSCREENINFO get fixed information of the framebuffer
* FBIOGETCMAP get colour palette (I think for 8BPP or less)
* FBIOPUTCMAP put own colour palette
* FBIOPAN_DISPLAY move physical display within the virtual
* FBIOGET_CON2FBMAP save contents of console
* FBIOPUT_CON2FBMAP restore contents of console
* FBIOBLANK delete contents of console
* FBIOGET_VBLANK get current raster beam position
* FBIO_ALLOC allocate graphics memory for own purposes for dual buffering etc.
* FBIO_FREEF free graphics memory assigned above
*
* */

Next we need to determine the screen dimensions, bits per pixel, and the color layout, RGB (565, or 555 etc).
You get these as follows:

struct fb_var_screeninfo varscreeninfo;
struct fb_fix_screeninfo fixscreeninfo;
ioctl (fd, FBIOGET_VSCREENINFO, &varscreeninfo);
ioctl (fd, FBIOGET_FSCREENINFO, &fixscreeninfo);

Those will return all the iformation you will need. Check the structures layout in fb.h.

Next you will need to access the frambuffer memory, and it is best to mmap the address or let it
handle it for you:

unsigned char *fbScreen;
fbScreen = (unsigned char*) mmap(0, fixscreeninfo.smem_len ,PROT_READ|PROT_WRITE, MAP_SHARED, fd,0);

Next you will need to know how many bits per pixel there is :

check

varscreeninfo->bits_per_pixel (mine = 16)

the bitfield structure is like this:

// bitfields
// struct fb_bitfield {
// __u32 offset; /* beginning of bitfield */
// __u32 length; /* length of bitfield */
// __u32 msb_right; /* != 0 : Most significant bit is */
// /* right */
// };

printf (“\toffset %d\n”, screeninfo->red.offset); red.length); green.offset); green.length); blue.offset);
printf (“\tlength %d\n”, screeninfo->blue.length);

(mine is 5 bits for red, 6 for green and 5 gor blue. So it is RGB 565).

Now setting a pixel is really simple. Yo can now access the framebuffer as an array of positions:

fbScreen[x + y * fixscreeninfo.line_length] = color;

depending on how you setup the physical and virtual screen you might need to adjust the pixel
location to cater for offsets as follows:

pixel = (x+varscreeninfo.xoffset) * (varscreeninfo.bits_per_pixel/8) +
(y+varscreeninfo.yoffset) * fixscreeninfoinfo.line_length;

If you get color as RGB (separate red, green and blue components) then you will need to pack
the colors into an unsigned short and use that to set the pixel. For example:

it will in this format A RRRRR GGGGGG BBBBB
A = alpha channel (maybe used by graphics hardware maybe not, check the value in the strcutures above)
R = 5 bits of red
G = 6 bits of green
A = 5 bits of blue

unsigned short pixel = (red << 11) | (green <> 11;
unsigned char green = (pixel & green_mask) >> 5;
unsigned char blue = (pixel & blue_mask);

If the framebuffer is 8BPP then yo don’t need to do anything and just use the value directly. However, it is possible to set the
OK6410 to 24 bits (1 byte for each color) so the calculations above will not apply. Use the info in the returned structures above.

When finished working with framebuffer, you will need to do :

close(fd);

// unmap framebuffer out of memory
munmap(fbScreen, fixscreeninfo.smem_len);

Once you have your setpixel(x,y,color) routine working, you can start writing other drawing primitives.

Or if you are feeling adventurous, cross compile DirectFB http://www.directfb.org, a powerful graphics layer with acceleration. I might do that and post results here.

Another project would be to download libjpeg library and cross compile as follows:

./configure –target=arm-linux –host=arm-linux CROSS_COMPILE=arm-linux- –prefix=

then

make all
make install

(I am using the compiler that came with the board (arm-linux-gcc-4.3.2).

with this library you can pack/unpack jpeg images (and you can even scale them down for the OK6410
screen size) and display them.

Same goes for libpng .
You will need zlib first.

Cross compile and then cross compile libpng.

Testing the board

I wrote to arm9board.net support and they were extremely helpful and fast. They gave me links to latest kernel and uboot.

First step is to test the board. I already have a bootable SD card. If you don’t have one then you need to use IROM_Fusion tool which only works on Windows XP.  To download the new uboot (mine is version 1.1.6), you will need to use DNW. I used teh DNW on Windows. Just follow the document on how to do that. Once I had the new uboot installed on the board I moved to Linux (Fedora 16). Here I compiled DNW,  then  you will need to compile “secbulk” as a module. This is the USB bulk driver for Linux.  Both of these utilities are on the DVD (dnw_linux.rar). Unrar the file and go to “dnw” directory and compile “dnw” as follows:

make dnw

then go to “secbulk directory”and compile it secbulk.c as a module as follows:

first you will need to do some changes to the device id. To find your device (should be the same as mine) , connect the usb cable to the board and then connect the other end to the usb port on your computer.  From a terminal do:

usb-devices

and you should get something like:

T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=03 Dev#= 13 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=04e8 ProdID=1234 Rev=01.00
S: Manufacturer=System MCU
S: Product=SEC S3C6400X Test B/D
C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=50mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=secbulk

Notice the Vendor ID, you will need to change the vendor ID in secbulk.c, like this:

static struct usb_device_id secbulk_table[]= {
{ USB_DEVICE(0x04e8, 0x1234)},
{ }
};

then compile as follows:

make -C /lib/modules/’uname -r’/build M=’pwd’ modules

insert the module

sudo insmod ./secbulk.ko

confirm that secbulk device has been created by looking at /dev directory:

crw——-. 1 root root 180, 100 Nov 29 21:43 secbulk0

you might need to disconnect and reconnect the board a couple of times (reboot the board first). Also, you will need to sudo when using DNW since it opens a device and needs superuser permission.

Follow the document on how to burn Uboot, linux zimage and a filesytem. If all works well then yo should get Qtopia up and running.

My next blog will be about setting up the cross compiler, GDB and Insight for debugging and of course busybox.

ENJOY.

New Kernel 3.0 for OK6410

OK, so I lost my backup and I have to do the board all over again. The following tasks must be completed before Christmas.

1. Install Arm Cross Compiler

2. Build new Uboot and install

3. Build and install the new linux kernel

4. Build and install a file system

5. Configure NFS to use Host as development system

6. Build and install busybox

7. build and install GDB and GDB server

8. Build and install insight for debugging

9. Build DNW as kernel module to install uboot.

10. Cross compile DirectFB and install

My aim is to finish this before Christmas. I have installed Fedora 16 and will be using that for development.

I have contacted arm9baord.net support and they gave me new links to download the latest software for OK6410 board (kernel, filesystem, cross compiler, utilities, images, filesystem and also Android 2.3.4).

Now when this is finished I would like to start a project that uses the board. Any ideas?  🙂

OK6410 (AKA Samsung S3C6410 SOC)

Welcome and hope you enjoy  my blogs. In return I hope you can contribute back so that we can all benefit from our experiences.

Ok let’s get started. I want to talk about the OK6410 board, which I bought from here http://www.arm9board.net. Specifically, I want to record my experience using this board. This is a hobby for me (I am a noob 🙂 ) and so I do it when I have time. In the immediate future I will cover the following:

1. Putting and configuring Linux on the board.

2. Framebuffer.

3. Input system

4. Graphics

5.Fonts.

6. Touch screen calibration..

7… and whatever I come across along the journey.

Today I’ll just talk about the board which you can find here http://www.arm9board.net. This is a company based in China, and the board reasonably price. It was delivered in about week. It was sent by DHL and when it is delivered, you still have to pay customs duty (you pay to DHL). In my case it cost me an extra 29 GBP on top of the board price.

As you can see from the web page. it is pretty good and comes with a lot of software,  Qtopia, Android and Windows CE. The software listed on the website is old but if you call support then they will dispatch a newer version.  My aim is put Linux on it and write programs/utilities from scratch as I wanted it to be as light as possible. Therefore, I will not be talking about Android or Qtopia or Windows CE. I’ll leave that for later. The version of Linux they give you is full configured and comes with all the needed drivers and configuration file.

On my part, I had Linux configured and running with all the hardware on the board functioning except the temperature sensor as the driver is no longer provided. I think you can get it if you email support. I might do that later. I also have the framebuffer running in 24 bits mode and wrote a small graphics primitives. I also had the touchscreen utility written but I still need to test it.  I am now investigating FreeType2. Libjpeg and Png and I hope to be able to write utilities for these. I will also publish the development tools I use such as Fedora 15, Eclipse (configured for cross compiling) , Insight (cross-platform debugger). I use the compiler from CodeSourcery (other compilers did  not work when compiling the kernel).

To finish my first blog, I would like to thank you for your time and look forward to seeing you again. If you have any questions, suggestions, corrections, fixes, or experience, at any time, please feel free to ask/publish here in the comment section. If you want to contribute something for all to share then send it to me (stating your name, your license policy and any special permission) and I will check it first and publish it here.