i've just written up a blog post on how I have setup Scratchbox2 to build binaries that run on a real RaspberryPi alphaboard (according to jamesh).
There is no tweaking or optimizing for the hardware as none of us have the hardware in hand yet but it should help with people wanting to check how hard it would be to port and build s/w for the RaspberryPi when we have them in our paws.
there was a small typo in there. brain said one thing, fingers typed another. my only excuse is the lateness of the hour and the lap full of cats who wanted to help. it's fixed now so if you tried the instructions last night/first thing this morning and cloning qemu failed change the http:// in the qemu git clone line to git://
Thanks for doing the legwork there, ukscone. Now I can add a toolchain to my current set of them (I've got X86, X86-64, and working up an ARM sandbox for OpenPandora handheld and for Android NDK...) for this and start working on a few things.
there actually wasn't any real work involved except checking that files and git repositoires were located where they used to be, which i mucked up anyway.
It was mostly the same as a previous blog post i wrote on scratchbox2 and then merging in the README from scratchbox2 and keeping everything nice and tidy in it's own set of directories.
There are some tricks for scratcbox2 that can really help when using it. i'll write them up in a few days. One is that if you have a real rootfs for your target device then you can use the -eR options for sb2 and use the target's rootfs package management system to update it or grab extra libraries without having to build them yourself.
Unfortunatly there are some gotchas too where qemu will segfault on a couple of c functions or signals but on the whole you can ignore that.