Error message

Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in menu_set_active_trail() (line 2405 of /var/www/html/includes/

Getting started with pre-release Angstrom on Collie (Zaurus SL-5500)

  • Posted on: 1 October 2007
  • By: agittins

WIP: This page is an incomlete work-in-progress. Furthermore, this is about using Alpha software that may or may not work at all the way you expect it to. Proceed carefully, and just stick with OpenZaurus or similar for now if you are not feeling brave.

This page very briefly describes the steps I took to get Angstrom working on my SL-5500 Collie Zaurus. Angstrom has not reached release status yet, so this is not something for the faint-hearted. It's likely to be a pretty bumpy ride. Just for starters - yes, this is using a 2.6 kernel, on the Collie, which we all thought would be forever impossible since Sharp could not / would not release the source or specs for the SD controller in this device. Thankfully, some clever beans managed to reverse engineer the driver and then create a clean-room implementation of an open source driver, which means we have working SD support for collie with an open driver, on 2.6+ kernels - Yay!

This page has evolved from two earlier pages which dealt specifically with OpenZaurus. I also ran 3.5.4 for a while but never got around to doing a page specifically for that version:

Angstrom Collie pre-release images are posted at . Releases are named according to the date that the build was done.
Because the Collie has limited storage, you can't fit a full GUI environment in the flash. So we'll have to install a basic console image into flash, and use altboot to pivot to an image on SD or CF storage. These instructions are all about using SD, as I need to keep the CF slot free for Wifi and Bluetooth.

Not as easy as you'd hope..
The image 20070709 (and later ones to come too, possibly) contain kernel 2.6.21, which as at this time (30/09/2007) still contains a problem with some SD cards which causes a kernel oops on SD card insertion. Until this is fixed, the only way to get SD support working is with an older kernel. What I've done is used the most recent root image, but with an older kernel and modules to get SD working. Here's what we need:

  • 20070709/zImage-2.6.21-collie-20070710163105.bin - we'll flash this kernel initially so that we can get the system up enough to replace the modules to suit the older kernel that we'll flash later. It will be named "zImage" on the CF card for flashing.
  • 20070709/console-image-collie.jffs2 - this is the root filesystem, it will be put on the CF card as "initrd.bin"
  • 20070703/zImage-2.6.20-collie-20070620221652.bin - a slightly older kernel that works with SD.
  • 20070703/modules- - the modules for this kernel image

Standard process for flashing applies (reset-C-D etc). I suggest you use the md5sum tool to make sure that the files you copy on to your CF card arrive intact. Using corrupt image files is both common and disastrous.

First we will flash the latest kernel and rootfs, then replace the modules in the rootfs with the modules for the older kernel, then we will flash the older kernel.

Initial Flash

  • Copy zImage-2.6.21-collie-20070710163105.bin onto your CF card as "zImage" (case won't matter if it's a FAT card)
  • Copy console-image-collie.jffs2 onto your CF card as "initrd.bin"
  • Use md5sum to make sure the files were downloaded and copied intact
  • Insert the CF card into your Zaurus
  • Make sure your Z is plugged into power
  • While holding the C and D keys down, press the Reset button (under the battery cover) and release all
  • Mail and Charge lights should both come on steady, and stay on for a minute or two
  • When the lights go out, press reset, replace the battery cover and power on

Prepare for kernel downgrade

  • Once it's booted, you should get a login or command prompt (just login as root, no password)
  • Take your CF card back to your PC
  • Delete the zImage and initrd.bin files from the CF card
  • Copy zImage-2.6.20-collie-20070620221652.bin to the CF card as "zImage"
  • Copy modules- to the CF card as "modules.tgz"
  • Put the CF card back in your zaurus, I think it mounts automatically
  • Check that you have the CF card mounted and can view it's contents on the zaurus before proceeding
  • Scary bit - remove the old modules so that we'll have space for the new ones. Note that after doing this your system will be pretty much broken until you get the new modules on and the new kernel flashed. "rm -rf /lib/modules/2.6.*"
  • "cd /"
  • Now unpack the new modules "tar xvzf /media/cf/modules.tgz". You should see the contents fly by on the screen as it unpacks the new modules.
  • Verify they went where they should "ls /lib/modules/"
  • You are now ready to flash the new (older) kernel

Flash the older kernel
Since we already have the old kernel on the CF card as zImage, just go through the normal flash steps - C-D-Reset. It should take less time because we are only flashing the kernel (about 1mb) and not the entire rootfs (around 14mb). Once done, your system should boot up to a login prompt where you can login as root.

Getting Altboot to work with SD
Altboot knows about the kernel needing specific module support for SD cards, but there seems to be an issue with it not loading all the required modules even after you configure it. My guess is that because it uses insmod it doesn't load all the dependent modules correctly, or maybe there are other services that normally run after altboot that get things working properly. At any rate, what worked for me was adding this to /etc/altboot.func, just before the section where it tries to load the SD module and mount the card:

/sbin/modprobe locomo_spi
/sbin/modprobe mmc_block
/sbin/modprobe mmc_spi
sleep 5

I don't know if the sleep is actually necessary, I added it while testing thinking things might need time to settle before mounting and haven't yet tried without it.

Save the file and reboot. You should now be able to get altboot to try mounting your SD card. Just press a key to enter altboot, and select 3, boot from sd card. It should attempt to mount the card. If you get errors here about not being able to mount it then re-examine altboot.func to make sure your changes were correct. Also check the output of "lsmod | grep mmc\|spi" to see if the three modules above (and others, like mmc_core) have loaded.

Assuming it mounted ok, you should be good to go with either booting an image you already had on the SD card, or now setting up a rootfs to boot from on your SD card.

Touch Screen

Now is a good time to get your device loading the touch screen driver on boot, since you're gonna want that to work later on. Create a file at /etc/modutils/touch with a single line in it: "ucb1x00_ts" (without the quotes). Then run update-modules, and check that the ucb1x00_ts line now appears in /etc/modules.

Make a new SD RootFS

My preference is to have root filesystems as images on the SD card, rather than using the whole card as one root filesystem. This means you can try out new releases etc as easily as copying a new file onto the SD card, and selecting it at boot with altboot, rather than having to use a separate SD card.

We'll build the new rootfs on the PC first, then we'll copy the finished article over to the SD card.

Download the tarball for the image

Angstrom devs are releasing tarballs as well as jffs2 images, which makes this really easy. As of this writing, the latest full image is 20070709/Angstrom-x11-image-glibc-test-20070711-collie.rootfs.tar.gz but it's worth checking for the latest.

Create your new image and populate it

dd if=/dev/zero of=base.img bs=1M count=256
mke2fs base.img
losetup /dev/loop0 base.img
mkdir base
mount -t ext2 /dev/loop0 base
cd base
tar xvzf ../Angstrom-x11-image-glibc-test-20070711-collie.rootfs.tar.gz
cd ..
umount base

See what we did there?

  • the count parameter of the dd command decides how big our image will be (in MB). I chose 256MB.
  • We then created a filesystem on the resulting "base.img" file, and mounted it.
  • Then we unpacked the downloaded image into the mounted filesystem, unmounted it, and just for paranoia's sake, sync'd to make sure everything had finished writing to disk.

You can now copy that base.img file to your SD card. For altboot to recognise it, you must put in on the SD card under a directory named "boot-images", and the file must be named with -rootfs.bin at the end. eg: "cp base.img /mnt/card/boot-images/angbase-rootfs.bin"

Now when you boot your Z and tell altboot to use the SD card, it will present you a menu with a list of images found in boot-images. Now you're up an running with a full Angstrom image, booting from SD card on a 2.6 kernel on Collie. Life is sweet.


Since people were interested, the 2.6.20 series of images and modules have been put back on and are dated December 20, 2007 If they by chance disappear, I will host them on my homepage until a working newer version is released - I would feel like I lost my arm and legs without my sl5500. Lots of info on my homepage too for it but is mostly related to how I use it for work (security and network stuff). I am not real sure I would like the default image sizes because I got so used to running the 64-0 series, but I guess I can use swap space and test the 2.6 series....which offers a lot of potential to custom compile software on the zaurus.

any chance you have copies of the 2.6.20.x modules, zimage, and image for collie so I can play with this on my zaurus? All files at angstrom are now gone. If I could grab a working copy or whatever was somewhat stable, would be willing to mirror them since they are now offline.

A better way to include the mmc_* modules is to add them to the /etc/altboot-2.6.cfg file in the INITIAL_MODULES variable.

Also, SD_KERNEL_MODULE should be "locomo_spi.ko" and not "locomo_spi" (the altboot script doesn't locate the module correctly if you forget the .ko)

Seconded! If anyone has them, please make them available somewhere!

by directory browsing, I found these files but dont know if any of them are helpful

ed wiget

Yes, I made some suggestions on the list and they've set collie to build 2.6.20 now by default (see RC2). It's still pretty bodgy though - the device nodes don't seem to get created for the mmc device, but I haven't had time to look into it properly yet. Also the device seems to stop processing just past halfway on the splash screen - but this is past the altboot menu so may not matter for just getting it to start booting off SD.

Yes, this is where it hangs. But: how and when do i get into altboot?

You get into altboot where it says "press any key to enter altboot". You need to be running the altboot-console image to get altboot, though.

It hangs on /etc/init.d/

I put an 'exit 0' in there and that solves the hang during boot.
With opie image however, the date&time applet which is started automatically still makes the collie hang.

The links to the 2.6.20 kernel and modules are broken as of 15th Feb 2009.


where did you get Altboot from? There's no packet for the Collie in Angstrom and it wasn't in the image. Even the official download site is down :-(

If my memory serves me (it often does not), altboot is built-in, either that or it was a simple matter of "ipkg install altboot" in which case, it _is_ in the feeds, but you'll need to come up with some way of getting the ipkg onto your collie (either via cf or using ipkg directly with a wifi card). If I do a bare-metal install again I'll verify that and update the directions accordingly.

everything has worked well with the install up untill i get to the part about editing the /etc/altboot.func file. i can't seem to find a program to edit the file. i have tried nano and vim both return an error nano/vim can't be found. can you please tell me how to edit that file. thank you


Hi, have you tried just vi? I had no problems just using vi from the console image, I don't think busybox sets up a symlink for vim, so give vi a shot.

Since you did not unpack modules-2.6.20-collie.tgz into the lib directory of your image, doesn't your image have the wrong set of modules on it?

Why does it work? Does the kernel look for modules on /dev/mtdblock2 even if rootfs is moved to the sd card?

Ooops... that would be the "work in progress" part :-)

Absolutely right, I think I missed that part - you need to unpack the modules tarball into your images - on the root flash you'll need to remove the old modules to create space, then untar the new ones. For the flash you can untar it there in addition to the other kernel's libs, since you will likely have the space.


There is now a 11/07/2007 folder. Does anyone know if we still need to roll kernel module back to like the author did?

I am kind of new to this SD stuff. I am going to format the card using Ubuntu and know I should use EXT2. My question is do I select primary or logical partition?

Thanks, Rich

I don't know if the new kernel re-fixes SD support or not. I think the guy doing SD/Collie work (I'm sorry, I don't recall his name right now) is more or less offline for a while so AFAIK the SD issues haven't been resolved - but try it anyway. You may as well grab the latest images, test to see if SD works, then if not, install the older kernel. It's not really any extra work than downgrading to start with, you just have to do a test in the middle there.

Sorry I don't have the time right now to check it myself, but if you're doing a reflash anyway it should be no harder using the newest images.


Do I format the SD card as a primary or logical partition?


Ah sorry, skipped the most important part of your question! Partition your SD card with one or more primary partitions, and make sure you set the correct partition type (83 for ext2/3).


Thanks for partitioning info.

I also tried to use 'vi' to update altboot.func but when I try to save changes, Angstrom tells me there is not enough space. What am I missing? I have done nothing except install initrd.bin & zImage.


Hi Rich,
Interesting. I think the images I last used had some space on them, but maybe the one you are using just doesn't have any left over. If you did an ipkg update for instance that might fill the partition. See if you can remove some stuff to free up a bit of space (you are only going to need a few kb I'd say). But if the flash is now full you will have to start again - one of the joys of jffs seems to be that once it's full you can't even remove anything! vi also keeps a swap/backup file so maybe try another editor (is pico or nano in the image you have?).


I have removed a few things but "df -h" shows that it is still 100%.



Angstrom downloads no longer seem to be available. I wonder if that was on purpose? I know of no way to contact them to ask.


Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.