Streamer

This is some quick notes on cross compiling xawtv. I had to get a webcam working on an embedded device this week and after not getting much success with a simple v4l app, (derived from simplewebcam android app's native library), I decided to cross compile xawtv. The only interesting part was the streamer console application.

I cross compiled this for arm. There was not much support for cross compilation as far as I could see.

XawTv depended on libv4l for which I had to compile v4l utils. This in turn needed libjpeg support. SourceForge gave me version 6 of libjpeg which had issues with libtool while cross compiling. Eventually I built version 9 which was obtained from some other location. To get the library, i had to use --enable-shared flag at the time of configuring. Then I compiled v4l utils. All this was done by setting LDFLAGS, CFLAGS and CXXFLAGS appropriately. As I remember, compiling v4l utils needed -Wl,-rpath-link=path_to_jpeglib in compiled flags.

There was some code that needed x11 libraries and I just commented them using # if 0. Another point to note is that output goes to .lib for these packages.

Now, for xawtv, I set the compiler and linker flags and configured using --host option to indicate that it is a cross compilation. However, I ran into problems as LDFLAGS was not honoured. After a long struggle, I figured out that flag was called DLFLAGS or something similar in Makefile. I set that to my current LDFLAGS value. Things went fine to some extend and I got streamer compiled. However, I was getting many warnings and errors since the build kept looking at /usr/include though I was cross compiling. Using -nostdinc only worsened the pain as I had to then use -I flag for each standard include folder and sub folders. So, I gave up on that and looked at what was causing the error. I could see that among many warnings there was only one error. It was related to FD_XXX macros of select.

Though I first ignored all these and decided to use only streamer (which was already compiled at this stage), my happiness was short lives as I found that the streamer used libng and the plugins present inside that folder.

I then commented many places where select appeared. However, same was appearing in v4l drivers. There alone I replaced select with Poll. My streamer and drivers were now ready. But, while running, streamer was not able to load drivers due to some unresolved symbols in drivers.

After a feel in entire source code, I found that they were present in libng and I only had a static library for libng. At this point, a word about makefiles in xawtv. The top folder has main Makefile. It then had Subdir.mk in each sub-folder which is included by main make file. Quick look at Subdir.mk Will give one a good idea about how to build an application/library. After seeing the objects that go into libng.a, I wrote a simple make file to get a corresponding .so file (arm-xxx-gcc -fPIC -shared needed.o -o libng.so). Then I wrote a similar make file for streamer and used this so to build streamer. (Streamer was using .a earlier). Then I copied the streamer and new libng.so to target.

Viola! "./streamer -o image.ppm -D v4l2" gave me my first image and I ended my day's work after seeing it via ppm2tiff. Well, I was really refreshing to see the same old mundane scenes via that image :)

Kernel oops

I had to look into a kernel oops recently. This was produced on a ARM machine. It was relatively easy to understand this message. These messages have become much more simple to analyse these days. I am making this quick post to remember one register: LR

LR: This register holds the address to which PC will be set to once you hit return. This simply means, this is the caller of the function where the trouble occurred.

The point where failure happened can be seen by looking at PC. Also, SP points at the current stack location. When I scrolled down, I could see some good back tracing information too.

QEMU/ARM hands-on (FOSS.IN)

https://github.com/tuxdna/arm-experiments (Saleem Ansari)

This was the most interesting and useful session that I had in entire FOSS.IN. Above site will give details. However, I guess, there are some issues with instructions. For example, the kernel link is broken. But, it will work if you remove the .af from the url. Also, the image did not load the rootfs. I tried ext2fs instead of cpio and gzip and that loaded the image. Also, rcS is not present at the site. I wrote that from memory. Again, I seem to have missed something there. It fails with the message that "could not open initial console". I guess /dev/ttyX stuff might be missing. Will try to fix that later and post back here once I do that. Anyway, this was a enlightening talk and it now gives me enough confidence to try my own rootfs on different architecture. Many thanks to the presenter.

Update:
I fixed this stuff. For those who are interested, I am listing the important changes
0. The correct link for kernel is: http://www.kernel.org/pub/linux/kernel/v2.6/testing/v2.6.24/linux-2.6.24-rc7.tar.gz
0.1 May be this was not needed. But, I did create a symlink from busybox to /init. Also, it only worked when I did a static build of busybox
1. Some device inodes were missing. Created /dev/{null,console,tty,tty0,tty1,tty2,tty3,tty4,tty5}
2. Created /etc/init.d/rcS and made it executable

#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sys /sys
/sbin/mdev -s

3. Most important of all, EABI support needs to be turned on in kernel. Else, nothing will work. Turn it on before compiling the kernel
4. The filesystem cannot be cpio. May be it can still work with a kernel config change. However, I tried with ext2fs and it worked perfectly well
4.1 To create a ext2fs,

dd if=/dev/zero of=root.fs bs=1M count=4
(As a side note, if you refer to the commands given in the above link, you will see bs=1. That is very slow)

mkfs -t ext2 root.fs
(Press 'y' for the question about root.fs not being a real device)

mkdir rootfs
mount -o loop root.fs rootfs
(Mount your new filesystem somewhere so that you can copy the contents to it)

cd $ROOTFS_PATH
(go to where your rootfs is)

tar c * | tar x -C /path/to/rootfs
(copy the contents to new your new filesystem)

umount /path/to/rootfs
(Now you can start using your root.fs just like rootfs.cpio.gz as described in the link at the top of this post and continue from mkimage part)

Thats all! you will have a bootable setup. I am thinking of creating a small script that will automate all these. Will post it here if I ever do that.
Update: I did make a script. Unfortunately, I was in office and our security policy does not allow me to upload that. Its like magic, u run it, have a coffee and when you come back,  you will see qemu running your own small Linux image :)

Linux IPI handling for ARM11MPCore (ASMP)

We have been struggling for a while with this. Last Friday, I nailed him down.Ok, the background story...

We knew that IPI (Inter Processor Interrupt) can be used to communicate with other processor. Linux has support for this in SMP mode. However, we are doing ASMP. We wanted to use it slightly differently to device a custom communication module with another core running VxWorks. Now, the first hurdle came in the form of not being able to write to some registers. That was a dumb mistake of not ioremapping the register addresses. After that we faced another problem of not being able to register an interrupt. After a bit of debugging, we found that the reason is that there is no chip descriptor registered for interrupts 1-16 (They are the interrupt numbers for IPI). Well, the init code for interrupt was doing it for interrupts >= 29. But why?

It is this question that forced us to spend a week to resolve. There was one guy working on it continuously and I will break my head whenever I get time. Now, we tried the most obvious. We changed 29 to 1 in init code for interrupts. This enabled us to register the interrupt. However, this did not cause our interrupt function to be called when we wrote to the register. Last Friday, I decided to look at realview code. And it paid off. I could see that, they are also registering the interrupt from 29 onwards in the initialization code. Now, what was the problem? To know that, I had to delve much deeper. The answer came from the low level vector interface routines. The do_IRQ was not responsible for handling IPI. Instead, there was a do_IPI function. We immediately reverted the changes done in the irq initialization code. Then, we put some code into do_IPI

Well, thats it! our interrupts started working. We did face some issues while writing to the shared memory. All about that in another post.

pxa255 again

We need to bring up a board based on pxa255. The following drivers needs to be added

1. P33 Intel flash driver
2. DM9k driver

We have no idea how the devices are connected as of now. When I last looked at it, I had merged the drivers for these devices. But the platform device structure needs to be populated and I am stuck there.