Virtual Dev Environment For Chumby
As an alternative to cross-compiling software for the Chumby platform with the help of a toolchain, you can also install a virtual environment compiled to run for the ARM platform.
This will allow you to compile Perl and other tools you might find useful on a Chumby.
Contents
Description
These are the steps needed to set up a complete dev environment for ARM.
We use QEMU on Debian to run a Debian instance emulated for ARM.
The only system where this works reliably is Debian.
You have to:
- Get a Debian vmware machine from the appliance marketplace.
or
- Download and install the latest Debian (40.r3)
I tried to set the environment below on other linuxes, with mixed results:
- on Redhat Fedora 8, the ARM emulator crashes throughout the installation, it was impossible to get anything installed consistently. Even with a pre-configured environment it was not possible to get a stable ARM system working.
- on Ubuntu and Suse you can get the install to complete, but at first boot you run into issues with the framebuffer support. The kernel would have to be eventually recompiled with different parameters to get this working.
- on (Free|Open)BSD there is not only the framebuffer issue, but also it is rather difficult to get a bridged networking working.
- on Windows XP, setting up a bridged networking with the recommended TAP driver never worked right, I gave up after many tries.
Building the ARM emulator image
Build the environment in /root/arm. These are the files you should have to start:
initrd.img-2.6.18-6-versatile linux-image-2.6.18-6-versatile_2.6.18.dfsg.1-18etch1+versatile_arm.deb vmlinuz-2.6.18-6-versatile
To get the files above, as well as to set up your system properly, follow closely the instructions to build the ARM environment at:
http://www.aurel32.net/info/debian_arm_qemu.php
If QEMU cannot be installed in the Debian host with apt-get, download QEMU from
http://packages.debian.org/qemu
It is recommended to use the packaged QEMU that came with your Debian, sometimes this will be 0.8.x, which is the highest version that is stable on that platform. The versions before 0.9 do not have qcow2 support, so for the sake of portability, do not create anything above the qcow version.
I found it eventually more reliable to actually install everything on a raw file, then convert the raw to qcow. For example, neither qcow nor qcow2 were stable on other linuxes, but once installed on raw and converted back to qcow, the system booted fine.
QEMU has a tool named qemu-img that you can use to convert images between the supported formats. Do not use the compressed format, it causes serious issues when trying to update existing packages.
To start the system, use a shell file (i.e. startQemu.sh) with the following contents:
#!/bin/bash qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.18-6-versatile \ -initrd initrd.img-2.6.18-6-versatile \ -hda hda.img -append "root=/dev/sda1" \ -net nic,macaddr=00:16:3e:00:00:01 -net tap
You should change the macaddr to a different value, to allow for uniqueness of mac addresses on the network. On some versions of QEMU, removing the macaddr parameter is required, otherwise the -net nic does not bind properly.
Add -m256 to the command to make 256MB available to the ARM environment, if your virtual host has enough memory. This is also the top limit, the default is 128MB.
With the way the ARM is supported, there is no way to get the system time propagate correctly with QEMU. The system will always atart with the unix 0 date (1969), and this will cause serious issues when trying to install/update packages. Therefore, the first priority was to set the time right from the beginning.
After booting the arm environment, if the system date was not set, set it like:
date -s "03/21/2008 +12:00:00"
It is recommended to put the above statement in an rc2.d linked script that will set the system time early in the boot process.
Install NTP client support
For correct behavior of the emulator, the real date has to be set after boot. For that, we use NTP:
apt-get install ntpdate
You have to create and customize the file /etc/ntp.conf:
# /etc/ntp.conf, configuration for xntpd logfile /var/log/xntpd driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable server 64.125.79.28 server 192.73.48.1 server 64.125.79.29 server 192.73.48.2 server 64.125.79.30 server 131.216.22.15 server 69.36.249.227 server 132.236.56.250 server 131.216.22.9 server 192.73.48.6
Of course, you could use foll host names instead of the IPs above:
server pubts0-sj.witime.net server chronos1.umt.edu server pubts1-sj.witime.net server chronos2.umt.edu server pubts2-sj.witime.net server tick.cs.unlv.edu server stratum2.sjc1.publicntp.net server ntp0.cornell.edu server tock.cs.unlv.edu server chronos3.umt.edu
You also have to create the start file /etc/init.d/ntpdate:
#!/bin/sh # /etc/init.d/ntpdate # NTPDATE=/usr/sbin/ntpdate LOGFILE=/var/log/xntpd NTPCONFFILE=/etc/ntp.conf NTPSERVERS= GREP=/usr/bin/grep CUT=/usr/bin/cut if [ -f $NTPCONFFILE ] ; then echo "===========================" >> $LOGFILE echo "<<< `date` " >> $LOGFILE for i in `grep ^server $NTPCONFFILE | $CUT --fields 2 --delimiter \ ` do NTPSERVERS="$NTPSERVERS $i" done $NTPDATE $NTPSERVERS >> $LOGFILE # echo $NTPDATE $NTPSERVERS $LOGFILE echo ">>> `date` " >> $LOGFILE fi exit 0
Link this file in the rc2.d as follows:
cd /etc/rc2.d/ ln -s S19ntpdate -> ../init.d/ntpdate
To make sure the date setting works one way or another, we also set the date to something in the current time, in case the NTP connectivity fails.
The best way is to edit the /etc/rc.local, and add:
date -s 03/21/2008 /etc/init.d/ntpdate
Install dev packages
apt-get install build-essential
This will install GCC and all other packages needed to build stuff.
Install the SSH daemon
apt-get install ssh /etc/init.d/ssh start
Issues with moving the appliance
Every time you move the appliance (or if you run it from a notebook and reconnect to a different network), it is possible the the eth0 becomes eth1, etc. In this case you will have to reconfigure the network bridge for the ARM emulator to be able to connect to the TAP device.
For that, you modify the statement in the /etc/network/interfaces to reflect the current eth card ID:
auto br0 iface br0 inet dhcp bridge_ports eth1 bridge_maxwait 0
Full documentation for QEMU can be found at:
http://fabrice.bellard.free.fr/qemu/qemu-doc.html