How to break the Internet in 10 easy steps
This morning (February 29th 2012) at some ungodly hour (1am EST/6am UTC) the Raspberry Pi was finally released. Originally the Raspberry Pi Foundation was going to manufacturing the Raspberry Pi themselves and sell it in their own online store but instead they have setup a licensing deal with 2 companies (Premier Farnell/RS Components) who will make the Raspberry Pi themselves, using their manufacturing facilities and sell them in their online stores. There have been some initial teething problems with this but on the whole this is a good thing as it will mean more people will be able to get their hands on the Raspberry Pi much sooner than if the Foundation was handling the manufacture of the Raspberry Pi themselves. The foundation now gets to concentrate on other things such as writing documentation and actually teaching programming to children rather than spending enormous amounts of time on behind the scene things not directly related to their ultimate aims.
Tips for preparing an SD card for the raspberry pi on windows
The Raspberry Pi will probably be available to buy in the store sometime within the next ten days and one of the operating system sd card images is already available (debian) with another to follow in a day or so (fedora) so it's time to start thinking about making an sd card for use with the raspberry pi.
If your main machine is a linux system then you should have no problem, a standard dd will be fine but under windows not only do we not have a dd program (we do but it's not a pleasant experience and windows users are not command line junkies on the whole so use something like Win32DiskImager or equivalent) but there are a couple of gotchas that might catch the unaware out.
The main gotcha is that although your computer has a builtin sd card reader/writer and it works with your cellphone or camera sd card perfectly well it might not work for creating a bootable sd. The biggest problem builtin sd card reader/writer is the ricoh one in HP laptops although other makes of sd card hardware and laptops also have this problem. When you use a builtin reader/writer and it is goingto fail it doesn't always tell you that it's failed so the first thing you now something is wrong is that your raspberry pi (or other target device) won't boot So although you have a builtin sd card reader/writer it is a good idea to get hold of a USB SD card reader/writer and use that for making your bootable SD card. [I have no real idea why builtin reader/writers have problems making bootable sd cards but my thinking is that the controller in the builtin ones was cut down for windows machines to save a few pennies as noone thought that they'd want to write to the 0 to xxxx areas of the SD card]
The other gotcha you should be aware of is that SD cards are formatted and written to in a slightly "weird" way. An unformatted/blank SD card is actually full of 1's and when you write to it it just flips the appropriate bits to 0. An sd card can read at the bit level but only writes at a block level so you'll end up with areas that can't be used for writing any more as they need to reverse a bit back from a 1 to a 0 to perform the write and deleting/erasing the file won't actually free up all that space as it spans several blocks. So if you are going to use an SD card that you have used before you'll want to format it before using it with the raspberry pi. Don't use the windows formatter with your SD card as although it'll sort of work it won't have set all the bits to 1 instead user the panasonic sd card formatter which you can find at http://panasonic.jp/support/global/cs/sd/download/index.html [I can never remember which way around it is for when an sd card is in an unused state, whether it's all 0's or all 1's but i'm leaning towards all 1's as that is what has seemed to have stuck in my head].
To quickly summarize if making a bootable sd card on windows.
- Use a USB SD Card reader/writer
- Use the panasonic sd card formatter
- There is a windows version of dd but use Win32DiskImager or equivalent instead
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
Setting up a VM for Raspberry Pi development using Virtualbox, Scratchbox2 & qemu (Part 3)
I don't claim that the following is the best way to install scratchbox2, qemu and a seed rootfs and configure them to produce binaries that will run on the real Raspberry Pi hardware. I don't even claim it is the correct way but it works for me and I can almost do it in my sleep by now. The way I do things will probably seem a bit inefficient and in some cases just plain wrong but it's how I work and hopefully they are easy to follow and adapt to your style of working. I also make no guarantees that it will actually work for you at all. Hopefully it will but if it doesn't sorry but oh well. I made the decision when I first started building the development vm that I would place all the required software under the users home directory rather than installing it globally as
- Installing in subdirectories in the user's home directory makes it easy to keep things organised.
- It makes things almost idiotproof when you want to upgrade the ARM toolchain, scratchbox2, qemu or change the seed rootfs etc. as it's pretty much just rename the old directory, create a new directory and if neccessary rerun sb2-init.
Setting up a VM for Raspberry Pi development using Virtualbox, Scratchbox2 & qemu (Part 2)
If you decided to use a Debian or Ubuntu based distro then when you booted the Raspberry Pi Development VM that you just created you will have probably noticed an error message flash on the screen saying
piix4_smbus 0000.00.07.0: SMBus base address uninitialized - upgrade bios or use force_addr=0xaddr
and you'll want to fix that before doing anything else. The Fedora16 VM doesn't produce this error so Fedora users can skip straight to the guest addition installation instructions. I wrote a short post about this error last year but to save you having to go there to read that post the fix [Credit for that fix goes to http://finster.co.uk & Karl Foley] is:
- Start a terminal
- sudo vi /etc/modprobe.d/blacklist.conf
- Add the line blacklist i2c_piix4 to the end of the file and save
- sudo update-initramfs -u -k all
- sudo reboot
Setting up a VM for Raspberry Pi development using Virtualbox, Scratchbox2 & qemu (Part 1)
Last week I released version 0.2 of the Raspberry Pi development VM and I thought that I could safely call it a day because in a few weeks the Raspberry Pi hardware will be available and therefore we will no longer need the VM for software development. So yesterday I announced on this blog and the Raspberry Pi forums that I had decided to EOL the VM and would no longer be updating it as I didn't see the need and i'm not going to have the time to maintain it for the next few months as it takes about 12 to 14 hours to create, configure and upload, 8 to 10 hours of that is uploading using all my upstream bandwidth which is no longer feasible for me to do again until after June.
However, almost immediately after posting that I started to receive tweets and PM's asking me not to stop working on the VM or to at least write detailed instructions on how to create your own VM for Raspberry Pi (or other ARM based devices) from scratch. Yesterday I also finally managed to get SDL programs working correctly, not that I had actually tried that hard previously as the majority of software I was personally interested in building and porting to the Raspberry Pi are text based and at most use ncurses. So although I really won't have time to work on upgrading, tweaking and maintaining the VM personally I have decided that it should continue to live in the form of detailed instructions on how to create your own Raspberry Pi development VM, which is almost mostly transferable to other ARM based devices as well, it's actually pretty much transferable to any device that qemu will emulate but that is beyond the scope of this how-to.
Fate of the Raspberry Pi Development VM
[update: looks like i EOL'ed the VM a day or so too soon seeing as I now have SDL working correctly (mostly) in it now. I'll either do one more release or roll a script and detailed instructions on how to install and configure scratchbox2, qemu and a rootfs (and sbrsh/sbrshd for using the real raspberry pi hardware with scratchbox2) before I do actually EOL it. It might take me a day or so to get to it though.]
In a few weeks we'll have our sticky paws on the real Raspberry Pi hardware which on the whole will obsolete the current VM. I could build sbrsh/sbrshd (mount nfs on the real hardware and use that for cpu transparancy, currently using qemu) which might be useful and there are a couple of tiny buglets and uglyness that I could fix but as it takes about 4 hours to create and clone the vm and configure everything and about 8 to 10 hours to upload somewhere using ALL my upstream bandwidth is it worth it?
I don't mind continuing with the VM if anyone else really wants/needs it but if it's only me that is using it then i'll probably not bother as the VM is good enough for a few more weeks until i/we have the real hardware and i'm kind of running short of tuits for anything that isn't related to a couple of projects i'm currently working on at the moment that will enable me to afford the odd raspi, one, three, fifteen...., but I don't want to leave anyone in the lurch if they really use the VM and would prefer not to have to set it up themselves or don't know how to do it.
So can i have a show of hands in the comments of who would like me to do another release of the VM and/or add sbrsh/sbrshd.
The Raspberry Pi (part three)
[Disclaimer: All opinions in this post are mine and mine alone. Although I am a moderator on the forums on http://raspberrypi.org I don't speak for the foundation and any factual errors, upset I may cause or spelling mistakes are completely my responsibility]
I took a bit of a break from writing this series of posts while I did some work on the development vm which I could do lying down using my eCafe Slim ARM based netbook (ta muchly Obarthelemy) as i'm still in a bit of pain from various aches and pains that being an old fogie seem to bring so sitting down typing for long periods is a right PITB. Now get off my lawn you darn kids. I also wanted to spend some time doing some research for a non-Raspberry Pi related project (although I might try to bring the Raspberry Pi into it if I can at some stage if I can).
So where were we upto at the end of part two? Ah yes The logo competition and MakerFaire NY 2011. i did mention MakerFaire and post a video of Eben's presentation a MakerFaire but I'll expand on that a bit for this post.
Building newLISP for the Raspberry Pi using the development VM
I just put together another quick screencast of the development vm in action. A tiny bit more complicated than tiny basic for curses this time as i had to install a library and edit the makefile a tad and i also ran the test suite inside sb2 as well.
ok enough messing around with the vm for the time being. it's time to start writing the raspberry pi (part three) blog post.