Building an Algol68 interpreter for the Raspberry Pi or How to be a world champion procrastinator
I'm got disgusted with Virtualbox when trying to get a USB webcam working with it so rather than building a new linux system to use for developing some object indentification from a webcam software i decided to see if there were any nice open source compilers or interpreters for things like Algol, Snobol4 etc.
I found an Algol68 interpreter on sourceforge that seems to be still maintained (last update in 2011 and a related piece of software updated this year) http://algol68.sourceforge.net/ so i thought i'd give it a go using an ARM fedora rootfs. I ran the configure script and saw that it would like gsl & ncurses so I added the runtimes and headers using yum inside scratchbox2 and then reran the configure script and then make and after adding the usual "-fsigned-char" it built with non of the usual X86 C to ARM C warnings.
Additional Raspberry Pi VM Information
I was informed yesterday that there seems to be a problem following my VM setup instructions when using Ubuntu 11.10. I spent about 5 hours and 3 Ubuntu 11.10 installs checking this and it certainly seems to be the case that without an awful lot of fiddiling and complications that are just not worth the bother. So for the time being the recommended guest os's for building your own VM are Ubuntu 10.04LTS, Fedora16 or Debian (I haven't built the VM on Debian for a long time so i'm not sure exactly which version to recommend but I can't imagine that Debian will be much of a problem with any recent versions. If anyone has a problem with Debian please let me know.)
Once again if you are using my instructions to build the Raspberry Pi development VM (or a VM for any development using Scratchbox2 and/or qemu) i'd recommend (in no particular order) currently using
- Ubuntu 10.04LTS
- Fedora
- Debian
Now a tip when porting x86 code to ARM using gcc. If you get a lot of warnings when trying to build software originally written in C for x86 for ARM especially things like "comparison is always true/false due to limited range of data type" the chances are that you aree being bitten by the fact that x86 compilers usually default to signed chars if not specified by the variable declaration while ARM compilers usually default to unsigned chars. If you are using gcc (which you are if you are using my VM or your own installation of Scratchbox2 then the fix is to use the
-fsigned-char
gcc option. e.g.
gcc hello.c -o hello -fsigned-char
Another thing that might prove useful when you have access to the real Raspberry Pi hardware and the standardized distro is that by default the codesourcery toolchain included in the VM by default builds for generic ARMv5. On the whole this really shouldn't matter as ARMv6 can run ARMv5 instructions but there maybe times when you are doing something that needs to use an ARMv6 specific instruction or you are including assembler in the C code or something else where a generic ARM version binary just won't cut it. In that case using the gcc option
-mcpu=arm1176jzf-s
which specifies that gcc emits the correct instructions for the specific ARM core that the Raspberry Pi uses might be helpful.
e.g.
gcc -mcpu=arm1176jzf-s hello.c -o hello
Hunter Davis has open sourced QuickGrapher
Hunter Davis, no relation (AFAWK) has made QuickGrapher, an HTML5 Equation Solver & Grapher Open Source. He's placed the source on github and in less than a week someone has ported it to Android. I messed around with the beta about a year ago and was really impressed.
Hunter has also Open Sourced another of his projects as well. Source Tree Visualizer which basically turns your source code tree into a real tree in a pretty landscape 
You can find Hunter's post about QuickGrapher here
and his post on SOurce Tree Visualizer here
Even if these two things don't appeal to you Hunter's blog is always a pretty good read.
Dropbox+Bittorrent trick
I don't particularly like cloud type things, it's my data and i want it completely under my control and I don't particularly like dropbox as I don't think I actually trust them. However, I do have a dropbox account because they were offering extra storage from the default for doing a quiz and we all know I like quizzes. When I finished building the new VM I suddenly remembered that my upstream bandwdth is kind of yukky even on my remote server, which had problems with hits last week anyway and although it seems to be coping now after a couple of tweeks, a few hundred attempts to download the VM might make it melt or at least go on strike for better working conditions so I decided that i'd actually use my dropbox account and publish the public url. i was about 25% of the way through uploading it and I suddenly had a horrible thought dropbox probably has a GB/Day limit and that publishing the public url might not be a good idea. So what to do? I could just give the public link to a couple of people and hope that it doesn't escape or I could see if it was possible to use dropbox as a seedbox for a public file.
After a bit of googling I found the following webpage describing exactly how to do it using uTorrent.
https://sites.google.com/site/torrenttricks/use-dropbox-as-a-free-webseed-for-your-torrents
It's actually pretty good however I think it works better with smaller than 2GB files as i still got an automated suspension email about 10 minutes ago but it looks like it was up long enough for a few people to be able to start seeding it. Once my account suspension is over i'll take a look at the process and limits more closely.
OpenWRT on the Zipit Z2
projectgus has just announced that OpenWRT has been ported to the Zipit Z2.  The base install includes wifi support, ssh server and ZipIt-friendly console and there are nearly 3000 prebuilt binary packages available to install using the opkg package manager. As OpenWRT was designed to run on devices with small (<64M) ram (routers) it should run quite well and will be a nice base for people to use to build their own custom rootfs.
To be able to use the OpenWRT port you must have a u-booted zipit and be able to format an sd card as ext2 which means you'll need to have access to a computer running linux (or have a linux VM) that can write to sd cards (USB SD Card Reader/Writer most likely as most virtualization software, VirtualBox, VMWare and linux generally have problems with builtin sd card reader/writers, especially on HP computers). The reason you need to have a linux system is that the OpenWRT Zipit Z2 port is supplied as a tarball rather than a disk image.
The OpenWRT port contains mostly console/text programs however some graphic programs have been ported from the Ben Nanonote OpenWRT port.
You can find more details about the port on the projectpage
http://www.chainxor.org/openwrt-zipit/
Virtualbox and upgrade bios or force_addr error
I've been using Virtualbox for several years now and one thing that always annoyed me when using a ubuntu or debian based guest OS was the
piix4_smbus 0000.00.07.0: SMBus base address uninitialized - upgrade bios or use force_addr=0xaddr
error when booting. It didn't annoy me enough to actually do anything about it as it didn't seem to cause any problems when running the guest OS but it was there whenever i rebooted the VM. However as I am now making a few VM's for other people I wanted to squash any bugs and uglyness when using one of my VM's and this morning while looking to fix another annoyance I stumbled across Karl Foley's blog which had a solution for the upgrade bios boot error. It's a quick and simple solution and i'm not sure why I didn't think of it myself but I was probably wasn't motivated enough to actually bother or actually thinking about it properly.
The relevant blog post is http://cs.thefoleyhouse.co.uk/blogs/karl/archive/2011/02/19/ubuntu-boot-error-in-virtualbox-piix4-smbus-0000-00-07-0-smbus-base-address-uninitialized-upgrade-bios-or-use-force-addr-0xaddr.aspx
Virtualbox VM for RaspberryPi development
[update: this vm is obsolete. please use the one in the follow post http://russelldavis.org/2012/01/20/new-raspberry-pi-development-vm-v0-2/ ] I am currently in the process of uploading a have uploaded created virtual machine running debian with lxde in which I have installed and configured scratchbox2, qemu and the codesourcery toolchain so that it is possible to build software for the RaspberryPi (although noone actually has one other than the lucky few developers that have access to a alphaboard).
The vm file will be is available from about (it's about 1.3GB so is about 7 hours from completing the upload)  11pm 10/09/11 (uk date format) at http://russelldavis.org/RaspberryPi/RaspberryPi.zip and as a torrent (created by #raspberrypi user obarthelemy)
http://thepiratebay.org/torrent/6667294
http://www.demonoid.me/files/details/2726361/
Although this virtual machine is meant to be used for developing for the RaspberryPi it should be usable for any ARM based device especially if you have a rootfs from the device that you can use to seed the scratchbox2 environment (see http://russelldavis.org/2010/10/20/setting-up-scratchbox2-to-build-software-for-zubuntu/ &Â http://russelldavis.org/2010/11/03/mounting-a-raw-disk-image/ &Â http://russelldavis.org/2011/09/07/setting-up-scratchbox2-from-scratch-for-the-raspberry-pi/ ).
I did forget a couple of important things in the included README. I have installed apache2 and symbolic linked $HOME/raspberrypi-development/build into /var/www and you should build everything in (or under) the $HOME/raspberrypi-development/build directory.
Setting up Scratchbox2 from scratch (for the Raspberry Pi)
It has been confirmed that binaries built using this method will run on real Raspberry Pi hardware (alphaboard).
Below is the method i used to setup Scratchbox2. I am doing this using a Ubuntu 11.4 virtual machine in VirtualBox. It works for me but YMMV.
Because the version of Scratchbox2 and qemu available in the Ubuntu repositories are pretty old and the version of qemu available doesn't have support for the arm1176 I am going to use the git versions of qemu and Scratchbox2.
mkdir RaspberryPi
cd RaspberryPi
git clone git://gitorious.org/scratchbox2/scratchbox2.git
git clone git://git.qemu.org/qemu.git
You'll also need an ARM toolchain. Unless you want to build your own ARM toolchain you'll want to download the codesourcery ARM toolchain. https://sourcery.mentor.com/sgpp/lite/arm/portal/release1803
cd ~/RaspberryPi
wget https://sourcery.mentor.com/sgpp/lite/arm/portal/package8739/public/arm-none-linux-gnueabi/arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
tar xjvf arm-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
You will now have the codesourcery ARM toolchain in the directory ~/RaspberryPi/arm-2011.03
Now that you have a toolchain available it's time to build Scratchbox2 and qemu. Earlier you cloned the latest git versions available and if you haven't already got them installed you'll need to install "fakeroot" and "realpath" using your distributions package management system. To build and install Scratchbox2.
cd ~/RaspberryPi/scratchbox2
mkdir ../sb2
./autogen.sh
make install prefix=$HOME/RaspberryPi/sb2
Then build and install qemu
cd ~/RaspberryPi/qemu
./configure --prefix=$HOME/RaspberryPi/sb2 --target-list=arm-linux-user
make && make install
Now that your toolchain, scratchbox2 and qemu are installed you'll need to seed your development environment with some libs, include files and binaries and initilize Scratchbox2
mkdir ~/RaspberryPi/devel
cd ~/RaspberryPi/devel
export PATH=$HOME/RaspberryPi/sb2/bin:$PATH
cp -a ~/RaspberryPi/arm-2011.03/arm-none-linux-gnueabi/libc/{lib,etc,usr} .
sb2-init Raspi $HOME/RaspberryPi/arm-2011.03/bin/arm-none-linux-gnueabi-gcc
This will generate a working target configuration. If anything fails you can redo it again manually after fixing the problem.
You'll probably want to add
export PATH=$HOME/RaspberryPi/sb2/bin:$PATH
to your .bashrc as well
Now you have a working cross compile environment for the RaspberryPi (it isn't optimised or tweaked for the hardware but it's good enough for now and can be improved at a later date when we have more details about the hardware in particular the GPU and CPU).
To actually test that everything is working correctly write a small program (a hello, world program is a good choice).
raspberry@raspberrypi-VirtualBox:~/RaspberryPi/devel$ gcc hello.c -o hello raspberry@raspberrypi-VirtualBox:~/RaspberryPi/devel$ file hello hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped raspberry@raspberrypi-VirtualBox:~/RaspberryPi/devel$ sb2 gcc hello.c -o hello raspberry@raspberrypi-VirtualBox:~/RaspberryPi/devel$ file hello hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped raspberry@raspberrypi-VirtualBox:~/RaspberryPi/devel$ sb2 ./hello hello, world
If you have any questions you can find me on the raspberrypi forum, the irc channel or contact me via this blog.
[Addendum: Instead of seeding usign the libs and include files etc. from the codesourcery toochain you can use a rootfs of any ARM based distro. Just download an ARM rootfs from somewhere (exercise left for the user) and as root extract it into the ~RaspberryPi/devel directory and then chown -R user ~/RaspberryPi/devel and chgrp -R user ~/RaspberryPi/devel -- If you user a debian based rootfs (squeeze) the you can use apt to update and upgrade the files in the rootfs using the command
sb2 -eR apt-get update
sb2 -eR apt-get upgrade
]
Hunter Davis is an android coding dervish
Hunter Davis is on a 30 apps in 30 days kick at the moment and although I only have one android device (an unrooted nookcolor) and can't actually try them they do look like pretty good little apps and possibly quite useful for some. If you have an android device you might like to give them a try
http://hunterdavis.com/archives/category/programs/android-apps
FlashStock v0.1
Recently #zipit irc channel user mozzwald put together a series of scripts to make flashing from stock, (and .29) to u-boot and back again very easy. I have taken his from stock to u-boot script and made it a bit prettier (dialog) Â and rather than having to "add" the script to an sd card with EZ2S already installed I have created a "special" version of EZ2S with just the flasher script in it. I haven't made any real changes to mozzwald's logic or process so any errors in the flashing are all his fault not really:) -- i've used this last night to take 2 zipits from stock to u-boot so everything seems fine but as per normal if anything goes wrong fix it yourself, mozzwald, marex and I are not responsible for anything that happens in anyway.
You can download FlashStock v0.1 from here
WARNING: FlashStock is alpha grade software. It has been tested and used a couple of times but there is always a possibility that something could go wrong. If you aren't prepared to accept that it might go wrong then please don't use it.
[This is the first stage of making an "all for one, one for all" flasher sd card where you just extract an image file to a small sd card and it will flash from stock to u-boot and back again with all the stops (.29) inbetween.]