Software development for the Wearable computer (ADS Bitsy)
OUTDATED: Can somebody who knows the score with the /home NFS mounts, the flash file system and the new private NFS mounts update this text please - eg probably Henk
The Bitsy board has a flash memory which holds the files necessary to bootstrap the device.
The ADS linux bootloader is installed on all of the Bitsy boards that we have.
This boot loader will load a compressed kernel image (called zImage) into memory and execute it.
This kernel loads a compressed ramdisk tarball and decompresses it onto a ramdisk.
This provides us with a read/write non-persistant file-system, there is 32Mb of DRAM on the Bitsy and the gzipped file-system is ~2.5Mb.
A secondary ramdisk with more storage can be set up by executing 'mount /dev/ram1'.
A second partition on the flash memory is mounted as /flash.
This will provide a persistant file-store although at present it is read-only and not in use.
Changing the file-system on the Bitsy
Ahh, the exciting part!. Firstly, checkout a copy of the repository into your filespace.
Create a bin directory to store scripts in and add it to your $PATH.
Cd into Utilities/Filesystem and do a 'make install'.
This will install the scripts into your new bin directory so that you can use makeFileSystem and makeBurnCard.
The Ramdisk module contains the file-system for the Bitsy.
Gotcha #1: Certain types of files don't exist very well within CVS so this file-system is not complete.
Cd into the Ramdisk directory and type:
This will add the missing files to your copy (don't then do a cvs add on them as they are not meant to be stored in the repository).
If you now perform a make in this directory it will turn the directory tree under Slash into a filesystem and zip it up for you.
This is performed using the script makeFileSystem which can be called by hand (without any arguments it will give you usage info).
The root of your cvs space contains a makefile that will do nothing by default unless you give it a target to tell it what to do:
This will pull the latest kernel from the website into your cvs root as kernel.gz.
It is given a .gz extension because the makeBurnCard script expects one on the kernel image.
This will call the makefile in the Ramdisk module to ensure that the ramdisk.gz image is up-to-date and then call makeBurnCard for you.
Ensure that there is a compactFlash card in waihona ready to receive it otherwise you will end up with your files written into the mount-point directory when it fails to mount.
NOTE: The Bitsy won't recognise cards larger than about 10Mb so make sure you use one of these:
Sound on the Bitsy
There is currently a bug in the kernel that /dev/dsp can only be opened once.
Attempting to open it twice will cause the board to lock.
This is fine if you have a single controlling process launched at boot-time and running until the board shuts down (e.g. an Event Manager, but a problem for everyone else.
To solve this, rc.local execute /sbin/proxy which is a small program that creates a FIFO called /dev/sound.
This can be opened multiple times and written to as if it were /dev/dsp.
... more to come as it happens!
This page last updated April 23, 2002
The material displayed is
provided 'as is'. Contents may not be reused without prior permission.
For problems or questions regarding this web
contact Cliff Randell.