This page documents the current state of the in-progress attempt to port the shared-source RISC OS to the new ARM Cortex-A8 based processors. The code is available in CVS as the ‘OMAP3Dev’ product. At present the port consists of a HAL targetting TI’s OMAP3530 SoC, as well as a modified RISC OS kernel intended to support all Cortex-A8 implementations.
Current hardware known to use the OMAP3530 SoC, with which this RISC OS port will most likely be compatible, include the BeagleBoard, Pandora, and Touch Book. Two variants of QEMU are also known to emulate the OMAP3530, and can be made compatible with RISC OS with some simple patches: QEMU-OMAP3 and Maemo QEMU
This table lists the current state of all planned tasks.
Task | Description/Status | Assigned to |
---|---|---|
OMAP3 HAL – Basic implementation | Implementation is complete and functional under qemu/beagleboard. However further work may still be needed. | Jeffrey Lee, Uwe Kall |
OMAP3 HAL – Video driver | Not yet functional. | Jeffrey Lee |
OMAP3 HAL – Audio driver | Unassigned | – |
OMAP3 HAL – SD/MMC support | – | Uwe Kall |
OMAP3 HAL – GPMC support | Support for devices connected to the GPMC controller (extra RAM, onboard NAND, etc.) | – |
OMAP3 HAL – CMOS/NVRAM support/emulation | Unassigned | – |
OMAP3 HAL – Keyboard scan at boot | Unassigned | – |
OMAP3 HAL – DMA support | Unassigned | – |
Kernel – Basic support | Kernel is functional on both qemu and beagleboard. But further work may still be needed. | Jeffrey Lee |
Kernel – ARM feature registers | Extend OS_PlatformFeatures (or similar) to allow reading of ARM feature registers. Provide suitable feature register values for old ARMs that don’t implement the feature registers. | – |
VFPU support | Code to initialise VFPU. APCS amendments and compiler/OS support to allow its use by programs. New FPEmulator to provide VFPU emulation for old ARMs. Possibility of special FPEmulator that emulates old FPU instructions by executing new VFPU instructions instead of using software emulation. | – |
ARM v6/v7 instruction set support | Assembler support in BASIC, objasm and cc, and disassembler support in decaof and Debugger. Contact ROOL if you’re interested in working on objasm, cc or decaof under NDA, these are closed-source. | – |
Pandora support | Support for Pandora-specific hardware – keyboard, touchscreen, RTC, etc. | – |
Touch Book support | Support for TouchBook-specific hardware – keyboard, touchscreen, accelerometer, etc. | – |
i.MX515 support | New HAL and associated code to support Freescale’s i.MX515 Cortex-A8 implementation, which has a good chance of being used in the first ARM based netbooks to hit the (UK) market (Pegatron – Prototype, |
– |
Kernel – New video mode support | Support for video modes with new pixel formats (R5G5B5, A4R4G4B4, etc.) See here | – |
USB – OHCI | Will require a revision C beagleboard. May not even be possible, if the new USB port is hardwired to EHCI. But if it is possible, it should just be a case of implementing the eixsting HAL USB functions. | – |
USB – EHCI | Will require a revision C beagleboard. The NetBSD USB code that RISC OS uses at least partially supports EHCI, but source code notes suggest it is unfinished. Implementation would presumably involve fixing the USB modules to support EHCI, and adding an EHCI HAL interface in a similar way to the existing OHCI one. Worth discussing with ROOL to determine the actual state of the EHCI driver and any existing plans to finish it. | – |
USB – OTG | Can be developed using existing rev B beagleboards. However the NetBSD code in RISC OS lacks OTG support, and I believe the latest official NetBSD source lacks OTG also. Unless the programmer feels like writing an OTG driver from scratch, it may be possible to pull in OTG code from another OS (assuming it fits the existing internal interface used by the USB module, and the source code licensing doesn’t cause any problems). Definitely something to talk with ROOL about! | – |
find . -name "CVS" -or -name ".cvstag" | xargs rm -rf
The RISC OS ROM image expects to be loaded in place of u-boot. So to run the build on from an SD card, follow the instructions in section 12.3 of the beagleboard manual (page 110 or thereabouts), except the ‘u-boot.bin’ you copy onto the card should be the RISC OS ROM image. There’s no need to copy the linux kernel, ramdisk or sample video file since they won’t be needed (But you probably do want flash-uboot.bin as a real copy of u-boot). Then follow the subsequent instructions for starting the board.
Note that X-Loader seems to be very picky about the layout of the SD card. You need to use this Windows-only formatter utility, which only understands USB SD card readers, to format the card to FAT32. If you only have a native SD card controller (common on built-in card readers) then you’re out of luck. Even the formatter built into Windows Explorer doesn’t appear to generate bootable SD cards. The “MLO” file (get one of the ones from here) has to be the first thing copied onto the SD card, and you have to copy it using Windows, or again you won’t able to boot the board with it.
To make things easier, you can create a script that will build the NAND image for you:
#!/bin/bash
rm -f beagle-nand.bin
./bb_nandflash.sh x-load-bin.ift beagle-nand.bin x-loader
./bb_nandflash.sh riscos.rom beagle-nand.bin u-boot
./bb_nandflash_ecc beagle-nand.bin 0x0 0xe80000
The script will put the ‘riscos.rom’ ROM image into a NAND image, ‘beagle-nand.bin’, suitable for use by QEMU.
Get in touch with ROOL, they can provide CVS write access to those who need it. A guide should also appear on the wiki at some point.