Search This Blog

Sunday, 26 October 2008

Kernel booting - continued

The Ubuntu install on the laptop is now complete. No more Windows :) After a quick and painless install via USB flash keyring, I followed the Wiki to setup the laptop for development. A few steps we're missing in the Wiki setup guide (particularly the GDB/Insight install), so that Wiki page has been updated.

I also spent some time looking into Kernel booting. The 2.6.23 kernel decompresses the zImage, it gets to the 'Done' stage, but goes no further than that. I've checked the ldatags side of uMon and compared that to the setup code in the kernel, and they tied together (as they did in 2.6.22). I've also incrementally patched the 2.6.22 kernel up from the sub-version 6 in the VC CVS, all the way up to, and it boots fine (except for the usual MTD issues). It's only when I move to 2.6.23 that the boot fails.
So it looks like I need to debug further into the boot sequence. Potentially using the 3 LEDs on the VCMX212 board as a limited binary sequence counter to step through the boot sequence. I need to find some time to see whether I debug the kernel startup/boot via GDB. Just need a way of setting up the ATAG info to pass to the kernel.

So I've got a choice. Continue advancing the kernel versions and sorting out the booting issues, to hopefully get to a point whether the MTD problems sort themselves out. Or, stay with 2.6.22 (with MTD/JFFS2 patches) and work out why it is spewing so many errors out (and once into BusyBox, why it is so unstable).....

Saturday, 18 October 2008

Fresh start

So I managed to revert the kernel back to the base version (2.6.22), and had that booting (until it hit the MTD issues, etc.). And it ended up being quite painless to patch to 2.6.23 A relatively small number of files that needed their rej files checking. Most we're VC changes to file header comments. A few we're deleted files.

Unfortunately it fails to get anywhere booting :( The zImage decompresses fine, but halts straight after that. I'll probably take a step back from that, and incrementally apply the 2.6.22 patches first. Narrow down where the boot discrepancy starts. Rather than trying to run straight to 2.6.23

Finally, for today, I've decided to blitz the laptop. The Ubuntu community docs describe a way of installing from a USB stick. I've tried the initial install of this and it works fine (it's a network boot).

As I type the install is setting up the base system. Existing partitions have already been destroyed :O

Tomorrow I should then have a brand new Ubuntu laptop to play with and setup (according to the Wiki) :) Plus 40GB of space to play with, rather than the FAT limited 4GB home space :S


I've reverted the VC CVS coglinux-2.6.22(.6) back to linux-2.6.22 base, and this boots more frequently than the versions!! I'm still getting Magic bitmask issues from JFFS2 and lots of MTD do_erase_oneblock() timeouts :(

I'm going to start applying patches, and see if further kernel versions become more or less stable.

Plus close to deciding whether to blitz WinXP off the laptop and reinstall only Ubuntu on. (As well as testing out all the info on the Wiki to see if all the install and setup steps are correct and nothing is missing)..

Sunday, 12 October 2008

Kernel booting: Good News!! (well almost..)

I persevered late into last night with Buildroot. Eventually I was able to get the make to finish. For it to make the toolchain, uClibc, BusyBox, Linux, and the root JFFS2 FS :)

Reflashed the root FS and zImage to the VCMX212 and tried booting. At first I was getting lots of MTD error messages. After a few boots (usual to init the JFFS2 FS) I managed to get to the BusyBox prompt :)

Unfortunately it is very unstable :( Likely to be issues with MTD. A quick google trawl before bed shown lots of MTD issues with various kernels.

Today I'm going to start afresh with Buildroot and fill in any missing gaps in the Wiki page.

Then on to start looking at the MTD problems...

Saturday, 11 October 2008

Rebuilding JFFS2 file system

I've spent some time today trying to rebuild the COGlinux JFFS2 file system with a custom built (debug version) of BusyBox.

It ended up being fairly easy to build BusyBox with the Crosstool, and then using the VC shell script and device table to rebuild the coglinux.jffs2 file.

Reflashing this new file on the VCMX212 board, and booting into the 2.6.16 version of the kernel unfortunately produce issues with bad/missing magic numbers :( So VFS couldn't get this new JFFS2 FS mounted and the kernel panics not being able to exec post boot steps.

I tried for a while to diagnose this, including creating what should be an identical coglinux.jffs2 file from the original extracted JFFS2 file from VC, and the VC CVS shell scripts. Annoyingly this still had issues getting mounted with the 2.6.16 kernel :(

I've now fallen back to the original VC JFFS2 file and the 2.6.16 kernel image (both taken from the website). But this has allowed me to "rx" the new custom busybox executable to the FS via Xmodem.

Running this new custom busybox executable produces the dreaded "Permission denied" (?) issues. Which is kind of expected considering that the JFFS2 FS contains cClibc libraries rather than libc ones.

So at the moment I've got myself side tracked looking at sorting out a Buildroot setup. I'll persevere with this for a while. Before dropping back and looking into getting the libc shared libraries across to the VCMX212 FS to sort out running the custom busybox executable.

Friday, 10 October 2008

Kernel issues!!! Arghhh!!!

I've only been able to find a few nights to work on this in the last few months :(

Where'd I leave off...

Kernel issues;
Ubuntu setup seems fine. I've tried out different versions/combos with Crosstool compilers. So far, I can get the 2.6.16 kernel rebuilt and working on the VCMX212. But cannot get the 2.6.22 latest CVS snapshot running. It builds fine, but fails to get into BusyBox.

I thought that the issue might have been in the post startup in the kernel. But a rebuilt debug kernel littered with printks shows that is is able to exec post boot commands.

Using the 2.6.16 zImage I can get into Linux and tweak the startup files, inittab etc. Plus I have the coglinux.jffs2 mounted in Ubuntu, so can look at stuff in there (as well as potentionally recreate the file system using BuildRoot or probably MakeRootFS).

So far I've seen it get to the /bin/sh inittab entry. I've tried different Crosstool combos to recompile the kernel, tweaked the 2.6.22 .config to match the 2.6.16 version, reflashed the file system, misc other kernel hacks.. But still no joy to get into BusyBox shell :(

Next step is to start debugging BusyBox startup and ash shell startup..

Thursday, 14 August 2008

Side tracked..

Been on a fitness drive recently (cycling and Taiji) so not had a chance to look further into my current issues and progress further :(

Currently I can get COGLinux built (2.6.16 and 2.6.22), but 2.6.22 halts during boot :( Need to try building under the old WinXP development environment, and if that works/boots ok, work out why the Ubuntu build fails. I'm thinking it somethings to do with the compiler, but who knows :(

PS: Installing lrzsz package in Ubuntu sorted out the minicom transfer issues, from previous post. Wiki has been updated (a while back) to reflect this..

Wednesday, 23 July 2008


Looks like my problems trying to get Ymodem transfers to work in minicom might be related to a missing package, i.e. lrzsz.

Need to try it later tonight, but I'd assumed that minicom came with X/Y/Z modem transfer code. It seems like the lrzsz package is required by minicom to conduct the actual transfers :S

Fingers crossed that'll sort out all the issues with minicom, and I can get into a happy state dealing with the VCMX212 via Ubuntu :)

So, next step is to rebuild the VCMX212 with uMon and linux. To undo experiment work with linux shared libraries. Then onto tslib and QtE :D

Three solid nights

As the title suggests. It's been three solid nights to get the Silabs CP2101 kernel module driver working. A new Wiki page has been created with steps to build and install this kernel module from source files.

Now I just can't get minicom ymodem transfers to work :S Always something...

Going to head back to WinXP to get the latest Virtual Cogs CVS linux kernel flashed onto the VCMX212. Then back to Ubuntu to carry on Wiki'ing about getting the VC21MM1 touch screen kernel module and test code build, before finally arriving back at the Qt Embedded installation.

Sunday, 20 July 2008

Wiki and Kernel rebuilding

Im so frustrated right now. Built up a nice head of steam while setting up Ubuntu and fleshing out the Wiki.. Only to be stumped with an issue with the Silabs cp201x driver crashing!!! I'd been daudalling along nicely until this BHAH!

Anyway, it looks like the Silabs linux driver source requires parts of the kernel source to build the driver module :S

Took a while to chase down the right packages, but have the kernel building now, and the Wiki is up to date with progress.

Thursday, 26 June 2008

Qt for Embedded Linux

Getting the VC21RB1 working with the VC I2C example was a nice step to make. I can now get back to looking at the VC21MM1.
With the COGLinux kernel in the VCMX212 flash ROM, a few people have been asking on the VC google group whether anyone has ported some form of Linux framebuffer based GUIs across. Some suggestiongs have been Qt, Tiny-X, DirectFB. It's taken me a few weeks to check out the various window managers. Finally liking the look of Qt for Embedded Linux.
One deciding factor was a group post about someone that had ported this to another i.MX21 based device called the Chumby, blog link. I've spent the last week going through this, the Qt web site, and getting it all setup in Cygwin (and lately Ubuntu).
I've managed to get the tslib to work on the VCMX212/VC21MM1 :) But the Qt Embedded install has been quite challenging. It took me a while to determine why a cross platform compile of Qt wasn't working under Cygwin. The configure script uses uname to sort out certain paths through the configure scripts, and breaks the cross platform compile!! :( With Wubi installing Ubutu on the development laptop I'm now looking at cross compiling via that and Cygwin.
With the limited time I can spend on home-brew development, this could take (probably) a couple of months to sort out. But so far it's coming along nicely.. Watch this space for updates :) Eventually I'll start filling out the Wiki over on my Google Code page that accompanies this blog with the steps required to get Qt working on the VC21MM1.

Wubi and Ubuntu

When I grabbed a cheap Thinkpad T42 laptop off of Ebay last year I was really pleased. It came with a fresh install of WinXP which allowed me to cleanly partition the single HDD with Partition Magic. With the intention to put Fedora onto that new partition, and do all the Robot development under Linux.
In all the Computer Games companies I've worked for it has always been Windows based development (using Cygwin for HW vendor tool chains). A linux distro is something I had toyed with occasionally, but knew that for embedded work I should really jump ship and develop wholesale under Linux. It was quite annoying to find that the DVD drive on the laptop was flaky :( Anyway, alot of existing Virtual COG'ers, including the guys over at Virtual Cogs, use a Windows/Cygwin setup for VC development. I could have perservered with Fedora (mounting the ISO in Windows to install from, etc.). But didn't require anything else that Cygwin had, so moved on.
This week I came across something really special, namely Wubi :) It cleverly installs Ubuntu onto an existing NTFS/FAT partition. The only thing it changes is to modify the WinXP boot loader to GRUB, to allow for dual booting into XP and Ubuntu. Tried this out, and it works fantastically!! My dev laptop now has Ubuntu!!! :)

Wednesday, 18 June 2008

VC21RB1 board comes alive..

Three posts in one day... A crowded house ;) and probably the topic of some kids docturate somewhere

Hopefully the Virtual Cogs guys aren't reading this (sorry Tarun and Dan if you are). I pushed them at the end of last year to release some example code to driver the motor controller board, VC21RB1. Huge credit to them they did release more than expected. Including a lovely way of using I2C to communicate between the VCMX212 and VC21RB1 :D

Since receiving the Virtual Cogs boards I couldn't remember if I had even tried to determine if the VC21RB1 board was working. All the other delivered boards I had tried, think this one was waiting for some test software before I tried it out. Anyway..

Last night I grabbed the VC21RB1 I2C demo code and apps from the VC wiki. Sorted out a new OpenOCD server connection to the VC21RB1 JTAG. And tried reflashing the VC21RB1 with the example code, which worked first time :) Uploaded the VCMX212 accompanying code with Hyperterminal Ymodem. And launched the Win APP to squirt commands down the USB-UART to the VCMX212, and further via I2C to the VC21RB1. I must admit I did a litte dance when that all worked first time!!! :)

The new motor controller is ALIVE!! :) Superb news. I can now have a look at connecting up some motors, etc..

EFSL (Embedded Filesystems Library)

With the issues faced with uMon FATFS (see last blog post), it was a pleasure to come across EFSL. A little confusing though. The latest stable tarball is 0.2.8, whereas the stable CVS is 0.2.9 :S I had a look at the latest development release in CVS, but looks completely different and un-worked on for quite a few months now.

As with DOSFS/FATFS it only needs three functions to be hooked in. Init, single block read (512 bytes), and similar single block write. Perfect! Just the same requirements as the CF/DOSFS interface in uMon :)

Hooking up the SD driver code was easy. Creating a simple uMon API based test app, just as easy. And bonus, it all worked first time. Result!!

Even though having SD card support within uMon is nice. It's nicer to know that with EFSL I can use that standalone or within uMon API test apps.

Back on the case...

After a nice long hiatus I'm back on the case with the Robot development :) Actually I started back a few weeks ago, but only now have found the time to update the blog :S

The Virtual Cogs guys have done a superb job creating a Linux kernel image for the VCMX212. So far I've been reluctant to delve into Linux remote source level debugging. Although it is looking increasingly likely that I should switch over to it soon. As such I've been happily delving into creating apps using the uMon API. But it has it's shortfalls;

A few weeks back someone asked on the Virtual Cogs Google group about accessing the miniSD card on the VC21BR1 board not from Linux. Something I had been looking at last year. If you boot into Linux on the VCMX212, the kernel mounts and supports the SD card. But no other support is available outside Linux, sounds like a challenge :) This was something that I wanted to get implemented myself. So I took up the mantle..

At first it looked like a daunting proposition to implement the driver. As usual I google'd as far as I could to work out what others had done before. Most of the searching pointed at setting up an SPI based SD/MMC card driver. Which was confusing at first, considering the i.MX21 processor on the VCMX212 has built in SD Host Controller circuity.

Obtaining the required documentation was quite easy. Here's some links to the pertinant docs;

Using the i.MX21 SDHC on-chip module ended up being quite straight forward. Quite quickly I was sending SD commands to the card and getting responses back. Late on a Friday night during that first week of development the card sent back it's CID and CSD structures. I.e. it said 'Hello, my name is ...' :) After that was cracked, the rest progressed nicely. Slowly due to busy life etc. but certainly shaping up.

After a few weeks of the odd evening and weekend work I finally managed to get the code into a usable state. Posting my results onto the Virtual Cogs Google group;

So here's where I have got to so far;

Card Initialization;
This has been working great with Sandisk 16MB and Sandisk 1GB microSD cards. Support has been added to detect MMC, SD, SDHC, and SDIO. Only the SD path has been tested. I don't have access to a SDHC or SDIO card, so that needs further testing. Plus I don't think MMC cards fit into the VC21BR1 microSD slot, so don't envisage further work on the MMC path. I'm hoping that at least the SDHC path is correct.

Single block read/write (no interrupts or DMA) has been tested in isolation. Writing 128 single blocks of test patterns works, and they can be read back correctly. Support has been added to loop across multiple blocks, but that hasn't been tested. SDHC card (and 4 bit bus) support has been added but not tested.

Using the latest version of uMon (v1.15), cf functions have been added that hook into the SD init, read, and write functions. CF can initialize the SD card and provided the function hooks to DOSFS. FATFS can then be used to ls, cat, and get a file from the SD card into TFS. I came across problems using rm, qry, and put FATFS commands. put command seemed to work, but Windows (XP and Vista) complained that the file was corrupt :S So I tried a different route to test the SD init, read, and write functions...

EFSL (Embedded Filesystems Library);
I grabbed the latest stable CVS version of EFSL (v0.2.9), and updated it with Martin Thomas's upgrades (see link below). Then dropped in support for VCMX212. A simple uMon API based test program using this EFSL library, can read a text file from the SD card, and write out a copy of the file contents to a new file on the SD card. Windows can read this new text file back from the SD card :)

Martin's changes -