As most of you probably know by now, a few months ago I started work on porting RISC OS Open's RISC OS kernel to TI's OMAP3 platform - a group of SoC's (Systems on a Chip) which use ARM Cortex-A8 cores. To date, OMAP3 SoC's have been confirmed as being used in various products, including the Pandora handheld gaming console, the Touch Book convertible netbook/tablet, and the BeagleBoard development board. For years RISC OS users have been asking for a new portable RISC OS machine, and soon they may find that they have several available.Out with the old, in with the new
The Cortex-A8 and Cortex-A9 cores from ARM are the latest and greatest iteration of ARM chips. Although the 600MHz CPU in the OMAP3530 doesn't offer any increase in clock speed compared to the XScale-based CPU in the Iyonix, it has several advantages in other key areas:
- Dual-issue superscalar design - Previous ARM CPUs that have run RISC OS were all based around scalar designs, i.e. they only had one instruction pipeline and therefore were only capable of processing a maximum of one instruction per clock cycle. But the Cortex-A8 uses two instruction pipelines operating in parellel, allowing it to process up to two instructions per clock cycle. This means that although the CPU is only clocked at 600MHz it has a maximum theoretical performance of 1,200 MIPS, twice that of the IOP321 in the Iyonix.
- Vector Floating Point Unit - For many years ARM CPUs as used by RISC OS have lacked floating point units, resulting in poor performance in many modern number-crunching tasks such as audio/video encoding/decoding or 3D games. With the Cortex-A8 that's all about to change, as it contains support for both the VFPv3 and NEON instruction sets. Although this new floating point instruction set isn't backwards-compatible with the old FPA10/11 instruction set that RISC OS has historically used, the new instructions are far more powerful and look to be a key part of ARM CPUs for many years to come.
- L2 cache - The CPU core in the OMAP3530 has 256KB of L2 cache. This is practically nothing when compared to modern x86 CPUs, but this is the first time a CPU with an L2 cache has been available for use by RISC OS, and should help to speed up many common memory-intensive tasks.
- Improved memory interface - As many people will testify, the memory interface of XScale-based CPUs contains flaws that severly limit the available bandwidth. Cortex-based CPUs do not suffer from these flaws, and as a result the CPU has approximately 4x greater memory bandwidth available, despite the fact the RAM is often clocked slower (165MHz DDR on a BeagleBoard compared to 200MHz DDR in an Iyonix).
- MMU enhancements - The addition of a second L1 page table pointer allows for much faster task switching than the current lazy task switching system, and as a result a more responsive desktop (Although it is questionable whether anyone will notice the difference!)
- Flexible display controller - The display controller supports upscaling/downscaling and rotation of the display, helping to make the OS more usable on portable devices with small or irregularly-sized screens.
- Hardware YUV overlay - Nowadays this is an essential feature for video playback. When used together with the VFPU, it should greatly improve RISC OS's media player capabilites.
- C64x+ DSP - A second processor capable of running programs independently of the main CPU. Its instruction set is tailored to performing audio/video codec functions; once suitable drivers exist for RISC OS it will be able to alleviate the CPU of much of the work needed for video playback.
- SGX 3D core - Although the SGX drivers remain closed-source, there is some hope that in the future RISC OS will gain the ability to use it for hardware acceleration of 3D games or other rendering tasks.
- No IDE/SATA controller. Instead builtin flash memory (typically 256-512MB) and SD/MMC cards are used for primary storage. Although the price of SD cards has dropped significantly in recent years, they still don't offer the same price/GB ratio, speed, or total capacity as a hard disc. Secondary storage devices such as floppy or optical discs must be connected via USB.
- No PCI/podule bus. Instead USB is used as the main form of expansion, which could cause problems with device/driver compatability, or the poor CPU performance currently offered by the Castle USB stack.
- Limited display resolutions. The maximum pixel rate the OMAP3530 is capable of is 86.5MHz - which is just about enough for 1280x1024 at 57Hz. For portable devices like the Pandora or Touch Book this isn't much of an issue, but for people planning on using a BeagleBoard as their main computer it may be very important. The display controller is also incapable of generating the timings required for many standard VESA modes, so you may find that some tweaking is required to get an MDF that works well on your monitor.
Getting started
A while ago I got my hands on a BeagleBoard of my own, to help me more effectively work on the RISC OS port. For anyone else looking to get involved with porting RISC OS to the board, here's a rough getting-started guide, along with a few of the things I've learnt whilst working with the system.
List of parts
The first thing you'll need to do is draw up your shopping list.
- A BeagleBoard. The only official retailer is Digi-Key, who use UPS express delivery to get your board to you within a couple of days, even if it's been sent from the USA. Most other vital equipment can be ordered from Digi-Key also, although not always at the best of prices. Just be aware that if you are in the EU, you'll have to pay the delivery man VAT when he delivers your board (This will be about £20 in the UK if you just buy a board and a serial cable). You may also have to answer a couple of questions from Digi-Key via email to help convince the US export officials that you're not an evil terrorist, or put up with their ordering system mistakenly flagging the beableboard as export-prohibited and cancelling your order - but since it's free delivery for orders over $50 you can't really complain.
- A case. Although not mandatory, a case will help protect your board from knocks, bumps and spills. Currently Special Computing are the only supplier known to sell cases, although at $29 for a case and $42 for international shipping it's hardly a cheap addition if that's all your in interested ordering from them. Special Computing also sell BeagleBoards and a few other supplies, so if you aren't worried about the fact that the Beagle Hospital only accepts RMAs on boards bought from Digi-Key then an order from Special Computing may be more appropriate for you.
- A power supply. You have a few options available here:
- A USB cable plugged into the USB OTG port. All that you'll need for this is a standard USB A to mini-B cable and something to plug the other end into (e.g. a PC or a powered hub). If you own a PDA, PSP, digital camera, or fancy mobile phone then you may already have an appropriate cable.
- A dedicated power supply plugged into the DC jack. 1A at 5V is all that's needed, although you should also be careful to make sure the jack is the right size and polarity (check the reference manual if you're in doubt)
- A USB cable plugged into the DC jack. Special Computing are the only place I know of that sell an appropriate cable; I've had trouble tracking down suppliers in the UK.
- A serial cable. Although you might be able to get by without one, it's strongly recommended that you have a serial cable available as it's the only sure-fire way of configuring the U-Boot bootloader that's used by the board. It's also the easiest way of debugging nasty RISC OS crashes, or setting up a different operating system such as Linux.
The serial cable header on the BeagleBoard is suitable for an IDC10 connector. This is the same as used in most old PC's, so you may find that you've already got a suitable ribbon cable to convert from IDC10 to DB9M (The standard 9-pin serial connector). Then you can use an ordinary null modem cable to connect it to your host machine. If you don't have a suitable IDC10 cable handy, then both Digi-Key and Special Computing sell cables that can be used. - HDMI/DVI cable. HDMI is backwards-compatible with DVI-D, so to save space on the board a HDMI socket is used instead of DVI/VGA. This means that with the appropriate cable you can connect the board to either an HDMI or DVI display - but not to VGA, as the board doesn't supply any appropriate analogue signals. With a good HD TV or monitor you may find that you can use high screen resolutions such as 1920x1080 @ 30Hz. For ordinary monitors 1280x1024 @ 57Hz is about the best you can expect. If you have a choice between HDMI and DVI, DVI is perhaps the best, since it allows the board to read the EDID information of the monitor (assuming the OS is capable of doing something with it!)
- Powered USB hub. The board itself is usually only capable of providing a small amount of power to the USB ports, plus there are only two ports available. A hub is therefore mandatory if you're planning on using the board for any serious work. Almost any powered USB hub should do, although you'll have to take into account how many ports you'll be using. The good news is that you can use the hub to power the board itself - i.e. one USB cable running from the hub to the board to provide power, and a second cable running from the board to the hub to provide the extra USB ports.
- USB keyboard/mouse. Technically you could use a USB switch/KVM to connect the board to your existing keyboard and mouse, but since my board was going to be connected to the same monitor as my RiscPC (which doesn't use a USB keyboard or mouse) I figured it would be a better idea to buy a dedicated device just for the board itself. Since I'm short on desk space I decided to try something new, and went for a mini keyboard with builtin trackball. Wireless keyboard+trackball/touchpad combos are easy to come by, but since I can't abide by replacing/recharging the batteries in wireless peripherals I went for a more expensive wired version. The only downside to a keyboard+trackball/touchpad combo is that most seem to only have two mouse buttons, so a seperate utility will be needed to use them properly with RISC OS (or in my case, a few minutes of hacking around in the USB HID driver to remap the Windows key to the middle mouse button).
- USB network adaptor. Not a necessity, but it's the easiest way to get programs to and from the board once the OS is installed. Although I have a couple of USB wifi dongles lying around the place, I wasn't sure if any of them worked with Linux, or even worse, whether any of them had open enough drivers and documentation for a RISC OS port to be made. With that in mind I decided to buy one of the cheapest USB ethernet adaptors I could find, under the assumption that cheap + mass-produced = high chance of open source drivers. Luckily this plan worked, as the device I bought has open source drivers available for both Linux and NetBSD. Plans are already in place to add support for the device to James Peacock's EtherUSB module so that it can be used under RISC OS. Note that you can also get USB hubs with builtin ethernet adaptors, such as the one sold by Special Computing, or by searching for 'laptop docking station' on any big retailers website. However these devices are often more expensive than if you were to buy a seperate hub + network adaptor, or may come with extra unwanted features (e.g. audio in/out, USB VGA adaptors, etc.)
- USB cables. To make the most of the OTG port you'll probably want two cable. The first is a male A to male mini-B cable to allow the board to be used in gadget mode. This cable will also allow you to power the board via USB. The other type of cable is a male mini-A to female A cable, which allows the OTG port to act as host - but since all new BeagleBoards have a standard full-size USB host port this could be an optional purchase. Finding places selling male mini-A to female A cables is a bit tricky - Special Computing sell them, as does this amazon seller.
- SD/MMC cards. Although the BeagleBoard does have 256MB of internal flash, it's not the best choice of storage medium for a writeable filesystem because it lacks hardware wear levelling. The NAND chip on the BeagleBoard is soldered ontop of the CPU and RAM, so there's no way of replacing it - unlike a cheap and disposable SD/MMC card.
With that in mind you'll want at least one SD/SDHC or MMC card to use with the board, or more if you're doing serious development work or want to easily use multiple operating systems. For maximum compatability you'll want to make sure that the cards are supported by the ROM bootloader - this means they must be 3V 4 bit cards. Even though new versions of X-loader and U-Boot will work with cards which the ROM bootloader won't, it's a good idea to have at least one ROM bootable card around the place in case you corrupt the copies of X-loader/U-Boot that are held in the internal NAND memory. Also remember to get a USB SDHC/MMC card reader if your computer lacks one. - Audio, S-Video cables. Depending on exactly what you're using the board for, you may want audio and/or S-Video cables to hook it up to speakers, a mic, and/or a TV/monitor with S-Video input.
- Formatting SD cards. The ROM bootloader only accepts them if they're formatted correctly, which they might not be when you purchase them. A Windows, Linux or Mac OS X PC should suffice for this.
- Compiling OS images. For compiling RISC OS you'll need a RISC OS machine to do the compiling, and a Windows/Linux/Mac machine for fetching source from CVS using ROOL's shell scripts. For compiling other operating systems, such as Linux or Android, you'll most likely need a real Linux machine, or at least a virtual machine - I don't think there's any guarantee that Cygwin or Mac OS will work correctly with the build systems that most OS distributions use.
- Installing OS images. Most BeagleBoard linux distributions use SD cards with two partitions - a bootloader-compatible FAT partition containing the kernel, and an ext2/3 partition containing the OS filesystem. To set this up correctly a Linux PC or a virtual machine is needed (Mac OS X will probably do the trick also). Windows alone is unlikely to work, due to poor support for ext2/3 and SD cards with multiple partitions.
- Communicating with the board. Any computer with a serial port, including RISC OS machines, should be able to do this. You can communicate with recent versions of U-Boot using the USB OTG port instead of the serial port, but unless the OS you're running on the board also supports using the OTG port in that manner you may run into some difficulty if the OS takes a dislike to your keyboard/mouse/monitor.
What to do when your board arrives
The first thing to do when your board arrives is to make sure that it works! The best way to do this is by following the instructions in the BeagleBoard System Reference Manual, or on the BeagleBoard wiki. This should also serve to familiarise you with terminology such as X-loader, U-boot, and the tasks required to create bootable SD cards. If you want to try a more complete system to test out your board, you can also try out the Angstrom Linux demo image, although if you're unfamiliar with linux you may struggle to do some of the more useful tasks such as changing the screen mode, running the omapfbplay video player, or installing new software.
After that you'll probably be wanting to try out RISC OS - in which case the guide on the ROOL wiki should contain everything you need to know about building the source and starting the ROM image (skip the start bit and scroll down to 'Getting started with the source code').
BeagleBoard impressions
There are several operating systems available for the BeagleBoard at the moment - Angstrom Linux, Ubuntu Linux, Android (itself based around a Linux kernel), Windows CE, and of course RISC OS. Angstrom is widely regarded as being the Linux distribution with the most support for the board and its features, so here I take a look at how it compares to RISC OS in terms of functionality and ease of use.
Angstrom Linux
After playing with Angstrom for a while, using both the demo image and my own self-built one, a few things became clear to me. Angstrom Linux, despite having its roots in ARM-powered PDAs such as the Zaurus range, still appears to suffer from the same problem as most other Linux distributions - the desktop experience is rather lacking. Beyond the SD indicator light flashing there's no indication whether the program you just clicked on is launching or whether it has silently failed. The Angstrom display manager doesn't yet support the new OMAP display drivers, so you're only able to change the desktop resolution by changing the kernel boot parameters, or entering the right values into a terminal window and restarting X. Angstrom also seems to be rather heavy on memory utilisation, with the memory monitor app reporting that around 100MB of the boards 256MB had been used by the time the desktop was reached.
But on the bright side, Angstrom does get several things right. It's the only Linux distribution to support all of the boards hardware features out-of-the-box, and installing extra software using the Angstrom package manager is easy (even if the online package browser is a bit broken at the moment). Firefox 3 seemed responsive, apart from the long time it takes to load pages - although I have a feeling that was more to do with dodgy USB drivers than a fault in Firefox itself.
It will be interesting to see what improvements are made to Angstrom once commercial devices such as the Pandora start shipping.
RISC OS
A lot of people seem to be interested in when the right time is to start buying BeagleBoards, Pandoras, Touch Books or whatever for general RISC OS work, so I might as well give an overview of where the RISC OS port currently stands and how it stands up to its main competitor, Angstrom Linux.
The most important thing to mention is that it's not yet a polished experience. There's no support for automatically loading/saving the CMOS RAM state, so the OS will always boot to the supervisor prompt. RISC OS also takes several seconds to reach the supervisor prompt instead of 1-2 seconds, due to the current slow implementation of the RAM clear code. If you're board is powered by the hub that the board is using for USB ports, then it will take even longer, as RISC OS attempts to poll the unresponsive USB OTG port. There's no !Boot sequence publicly available that is tailored to the hardware, so you'll have to build your own if you want to try running most apps from the desktop. The driver for the USB host port, although mostly functional, appears to have flaky device insertion/removal detection, so hotplugging storage devices often results in the dreaded 'Ambiguous disc name' error from SCSIFS. Performance of filecore-formatted USB drives is atrocious - an 8GB class 6 SDHC card, which should give at least 6MB/s read/write performance, takes up to two minutes to mount and only offers ~500KB/s transfer rate. Changing screen mode runs a risk of about 1 in 5 that the computer will lock up. Changes in the instruction set related to unaligned loads/stores means that, for the moment at least, most precompiled software won't run. A bug somewhere prevents you from setting the system clock to the correct time and date. Even if you could set the correct time and date, the lack of backup battery on current BeagleBoards means you'd have to reset the clock each time the computer boots (although this could be fully automated once the USB network drivers are more mature). There's currently no support for hardware acceleration of graphics redraws, so although some aspects of the desktop are responsive others are not (e.g. the 10 or so seconds it takes for '*modules' to complete its listing if you enter it after hitting F12 while in a high-resolution screen mode). There's also no support for any hardware differences between devices that use the OMAP3530, so even if you had a Pandora or Touch Book in your hands right now the chances are that RISC OS won't run on it.
But on the bright side, all of the above can and will be fixed, hopefully in time for the first consumer-oriented machines to start hitting the market. Even at this early stage it's clear to me that RISC OS still beats Linux in terms of memory usage, desktop responsiveness, and user-friendliness of application launching. If netbook manufacturers think that ARM netbook users won't be too worried about their inability to run Windows apps on ARM Linux, perhaps we'll be able to tempt a few ARM Linux users onto an operating system that provides a better desktop experience?
Benchmarks
Enough of the pointless speculation of about the OMAP's performance relative to existing RISC OS machines. Let's have some pointless benchmarks instead!
Dhrystone
Dhrystone is a benchmark that's often abused by people using compilers that detect the Dhrystone source code and replace it with hand-optimised assembler. But regardless of that, it can still be a useful benchmark, especially if you're in control over which compiler and settings are used.
Using RISC OS GCC 3.4.6 r3, I compiled the Dhrystone benchmark program, using the sources that are supplied with GCC. The Dhrystone program was then used to compare the performance of a BeagleBoard (running at the default CPU clock speed of 500MHz) and my Iyonix, resulting in performance figures in both Dhrystones/sec and DMIPS. Overall I ran the test twice - once without any optimisation, and once with ordinary -O2 optimisation. In the results, higher numbers = better.
| Compiler setting | Iyonix score | BeagleBoard score | Relative performance |
|---|---|---|---|
| -O0 -mlibscl | 395296.6 dhry/s = 225 DMIPS | 467289.7 dhry/s = 266 DMIPS | 118% |
| -O2 -mlibscl | 806451.6 dhry/s = 459 DMIPS | 1176470.6 dhry/s = 670 DMIPS | 145% |
Although these results fall rather short of the 1,200 DMIPS that ARM claim, they do show the speed advantage the Cortex has when performing CPU-intensive tasks using code produced by a standard compiler using standard optimisation settings.
Ackermann
The Ackermann benchmark is meant to be something to do with measuring the coding efficiency of procedures. That's about all I know about it, except that depending on the input parameters it will either complete the benchmark almost immediately or take longer than my patience (e.g. 10 seconds). Once again GCC 3.4.6 r3 was used to compile the source, both with and without optimisation. The resulting executables were run with '3 9' as the parameters. In the results, lower numbers = better.
| Compiler setting | Iyonix score | BeagleBoard score | Relative performance |
|---|---|---|---|
| -O0 -mlibscl | 534 | 150 | 356% |
| -O2 -mlibscl | 203 | 96 | 211% |
RISC OS mark
Finally something a bit easier to understand, and with benchmark results readily available for a variety of RISC OS machines. For these tests, RISC OS mark 1.01 was used to compare my RISC OS 5.12 Iyonix, running at 1920x1200x16M, against the 500MHz BeagleBoard at 1280x1024x16M. Note that the percentage scores as produced by RISC OS mark are relative to the base system of a 200MHz StrongARM RiscPC, so if you own one of those you'll have an indication of how well a BeagleBoard compares to that.
| Test | Iyonix score | BeagleBoard score | Relative performance |
|---|---|---|---|
| Processor | 260% | 294% | 113% |
| Memory (copy 128KB block) | 187% | 1089% | 582% |
| Memory (copy 1MB block) | 200% | 832% | 416% |
| Rectangle copy | 1483% | 38% | 2.5% |
| Icon plotting | 181% | 305% | 168% |
| Draw path | 95% | 163% | 171% |
| Draw fill | 53% | 150% | 283% |
| HD read (MB/s) | 15 | 1.3 | 8.6% |
| HD write (MB/s) | 39 | 1.3 | 3.3% |
| FS read (KB/s) | 2520 | 2 | 0.0008% |
| FS write (KB/s) | 2719 | 2 | 0.0008% |
A few notes about these scores:
- The default RISC OS mark memory test of copying a 128KB block would have caused the results to be heavily skewed by the 256KB L2 cache on the beagleboard, so the memory test was performed twice - once with a 128KB block and once with a 1MB block.
- The rectangle copy operation has the potential to be sped up significantly once code is written to make use of the OMAP's DMA engine for hardware acceleration. The DMA engine in the OMAP is capable of rectangle copies, fills, and rotations, so should easily provide a level of hardware acceleration similar to that available with the Iyonix or ViewFinder/V-Pod equipped RiscPCs
- The Iyonix was using an IDE hard disc, whereas the BeagleBoard was using dog-slow USB mass storage. This is why the filesystem scores for the BeagleBoard are so low. These scores should improve over time now that the USB stack and USB mass storage drivers are a more important part of the OS.
!Befunge
I would have chosen something more useful for this last test, such as compressing files using command-line zip, but I was unable to find a compiler setting that would produce a working executable (presumably due to unaligned load/store issues). So instead I decided to try !Befunge, my WIMP Befunge interpreter, which luckily ran without any problems. To test the relative performance of the two systems I ran my turtle quine through the interpreter. On the Iyonix it completed in approximately 70 seconds, while on the BeagleBoard it took approximately 23, resulting in a relative performance of 304% (saving the resulting DrawFile to RAM disc instead of USB to avoid a nasty penalty).
Conclusion
What the OMAP3530 gives with one hand it takes away with the other. Although it's undoubtedly going to be the most powerful ARM CPU to run RISC OS, it's also going to require a certain amount of hard work from OS and application developers in order to support the new hardware features such as the VFPU, and to work around architecture changes such as the handling of unaligned loads/stores. The OMAP3530 may not offer high-resolution screen modes or a fast expansion bus, but it's an important platform to support if we want to see RISC OS running natively on affordable new hardware instead of just under emulators or geriatric RiscPC's.
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
anyway emailed you 
