OS on the wearable
The bitsy has on-board flash memory which contains the operating system and
user applications. On start-up, some file systems are mounted, and some
programs are executed. The command set is not GNU, it is a minimal command set provided by BusyBox. This is a single binary that support multiple functions. Each of the standard commands (eg touch,ls etc) are symbolic links in /bin to the /bin/busybox binary. The name of the symbolic link is used by the binary to decide which function to carry out.
The bitsy is configured to have the following file systems:
On startup, the system will check for a file 'autostart' in
/flash. If it is present, and it is executable, then this file will
be executed. This will allow you to install a stand-alone application on the
Bitsy. ***IS THIS TRUE???***
This is a RAM file system. It is read from FLASH memory
on startup. Creating and updating ram-disks is documented in the page on playing God.
This is an NFS mounted read-only file system. It is
mounted from the wearable user on the server, which is accessible to
wearable staff. Note that this is an NFS file system. Only useful as long
as you are within range of the 802.11 network.
This is an NFS mounted read-only file system. It is
mounted from the students user directory on the server. You can copy files
and directories into this space by using scp file
m0xx@waihona:Exported/. For example, if you have created an executable
execfile, then you can copy it from any linux box onto the bitsy
with scp execfile m0xx@waihona:Exported/, and then execute it by
logging in as above and typing /rd/execfile. Note that this is an
NFS file system. Only useful as long as you are within range of the 802.11
This is a file system that is permanent on the bitsy,
but not (yet) mounted on startup.
- type makejffs2 on the bitsy once to make the file system. This
will erase the whole flash filesystem, and will take a while.
- type mount /flash on the bitsy to mount the permanent
filesystem (needs to be done after every boot - for now). Warning: this
takes a while the first time.
- You can now put files in /flash permanently.
If necessary, one can make an extra ramdisk by first creating the file
system "mke2fs /dev/ram1", and subsequently mount it somewhere
"mkdir /blah ; mount /dev/ram1 /blah".
The flash memory is divided in four partitions.
The kernel hardly ever needs modifying. It should be in a fit state to
run any user application.
- The first partition is the boot-loader of the bitsy. This partition is
not to be erased at any time!
- The second partition stores the gzipped kernel. This partition is loaded
by the boot-loader of the bitsy on startup. Creating and updating kernels is
documented in the page on playing
- The third partition stores the gzipped root-device. On startup of the
kernel, this data is unzipped onto a ram disk, and mounted on /.
Note that any changes made to files on / are not stored on
flash. Note that it is impossible to change just one file on this device,
because it is stored compressed; you must load an entire new file
system. See also the utility Loadflash
- The fourth partition stores the user partition. On startup of the
system, this partition is mounted read-only on /flash. Note that if
it is mounted read-write, this partition can be changed, and changes are
The root partition needs to be modified only if the startup sequence is
changed. It maybe a good idea to invoke /flash/rc.local at the end
of the sequence; if present. This way, we can change the start sequence
without modifying the second partition.
The third partition contains root data. Note that data stored on the second
partition is copied to ram disk and hence occupies RAM; while data stored on
the third partition stays there and therefore only occupies flash
memory. All files on this partition are owned by the user `cyber' (to be
done), so that they can be updated with rsync.
Resetting the disk partitions
The disk partitions can be reset to safe values by popping the rescue flash
card in the PCMCIA slot, and powering up the Bitsy. After the reset, wait a
couple of minutes until all flash memory is written, and then take the card
out, put the 802.11 back in and reset again.
The card runs linux with the 2.4.9 kernel. It does not run any compilers;
only a core operating system. with some features like a minimal shell and
the like. The base patch-tree for the kernel is 2.4.9-ac10-rmk2-np1-ads2. There are some custom patches to be applied to the tree once it is in this state.
On startup, the rc scripts will launch pump on eth1, in order to
discover its IP address etc. Pump is not started on eth0; this must be
enabled manually in /etc/rc.d/init.d/network; if required. Pump
will find the IP address for the buffalo card (assuming that a DHCP server
is contactable over the wireless network), and a network connection is
The DHCP server on waihona knows the mac-addresses of all Buffalo cards, and
gives them static IP addresses; it could be made dynamic, but this way we
have a bit of control over which machine has which name. Pele runs a local
name-daemon who maintains a network 'wear.cs.bris.ac.uk' with in it machines
'pele', 'm001', 'm002', 'm003', etc. All have IP addresses in the range
192.168.250.XXX; this is a set of private addresses, not visible to the
outside world. All traffic is masqueraded by pele. ***IS THIS TRUE???***
This page last updated February 24, 2003
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.