RISC OS  OPEN

General status

At present the port consists of three components:

• A HAL targetting TI’s OMAP3530 system-on-chip.
• A modified version of the RISC OS kernel containing support for (all) Cortex-A8 CPU cores
• Additional custom driver modules, e.g. MUSBDriver, OMAPVideo

One optional component adds some value:

• A disc image including the boot sequence and some applications (not specific to the port, but useful in getting a viable system running)

At present the port is known to be functional on the following hardware devices:

• BeagleBoard
• DevKit8000
• IGEPv2

In the future, the port is likely to support at least the following additional devices:

• Pandora
• Touch Book
• BeagleBoard XM

In the past, the port has also been used via the QEMU emulator (QEMU-OMAP3, Maemo QEMU). However it is not currently known whether QEMU’s OMAP3 emulation has reached the state where running RISC OS from within QEMU is again feasible.

There is also scope for expanding the port to support other SoC’s made by other manufacturers, e.g. the Freescale i.MX515

Current status

This table lists the current state of all planned major tasks.

Minor todo items and other miscellaneous tasks

• Kernel
  • Need to investigate how to make use of the dual page table pointers to improve task switching; see here for more info.
  • The OMAP ROM uses a special ‘Cortex’ branch of the kernel instead of the HAL branch. Once things settle down the two branches should be merged together again (preferably before too many changes are made – currently there are only a handful of differences between the two kernels, as most of the new code resides in the new VMSAv6 source file). Jeffrey Lee is probably the best person to do this, as he’s made 99% of the kernel changes so far.
  • Write an abort handler to emulate ARMv5 rotated load behaviour. This will fix the majority of ARMv6/v7 compatibility issues. See here for more info.
  • Redo the cache/TLB ops to take advantage of the PIPT/IVIPT cache line tagging used in ARMv7 – see here. To do it properly, we may need to keep a ‘dirty pages’ map which tracks whether any page was ever mapped in with caching enabled – so that should it ever be mapped in uncached, we know to flush the cache first. Needless to say, whoever takes on this task needs to make sure they’re absolutely sure of how everything works!
    • Related to the above, work out why the kernel spends several seconds rearranging the memory map when *desktop is issued from the command line
  • We need to work out how to handle multiple IIC buses within the Kernel/RISC OS. Currently the only API that supports multiple IIC buses is the HAL IIC API.
  • We need to modify the kernel to get rid of the page at &00000000. Instead high processor vectors should be used (if the CPU supports them). Getting rid of the other pages between &1000 and &8000 may be advantageous too, but likely more difficult due to the increased number of addresses/variables that are exposed to the rest of the OS via those pages.
  • Adding support for the nonexecutable bit to the page table-related APIs would be a good idea, even if we can’t automatically mark an AIF programs data areas as nonexecutable due to fears of self-modifying code
  • Making use of the new cache control flags (inner cacheable, outer cacheable) may be advantageous too. E.g. RAM discs are currently uncacheable to avoid polluting the cache, but in CPUs with multiple cache levels it may make sense to make them outer cacheable so we at least get the benefit of the L2 cache.
  • Heap corruption can cause CheckForNullAllocn to get stuck in an infinite loop. It would be nice if the code could detect the infinite loop, even if the heap corruption means there’s little chance of the OS recovering (or even being able to report the occurence to the user)
  • We need a way to allow HAL_CounterDelay to use WFI, or we need to introduce a proper high resolution timer which programs can use instead of calling the HAL directly (especially since there’s currently no control over allocation of HAL resources to programs)
  • Improved machine ID handling – ideally it should be the HAL’s job to decide whether the machine ID is valid or not. HAL should also indicate the machine ID size (e.g. OMAP uses a 128bit ID)
• OMAP3 HAL
  • Needs soft-off support
  • IIC driver needs fixing to not leave the bus in an indeterminate state if an error occurs, and/or needs a way of recovering if the bus gets stuck in ‘claimed’ state. Maye just be a case of clearing I2C_CNT and setting the STP bit.
  • IIC driver needs updating to support speeds > 100kbps
  • DMA driver needs to bundle logical channels in pairs, to allow for double-buffering
    • Also need to work out how to handle the DMA packet size – it looks like both the DMA controller and the device need to know the packet size in order for DMA to work correctly?
  • Need HAL device/API to read temperature sensor(s) – see here
  • Need HAL device/API to read power consumption – see here and the following few posts.
  • Need to verify that the HAL UART driver actually works from within RISC OS!
  • Need HAL device/API to control CPU frequency
  • Make the HAL call RISCOS_InitARM instead of using its own code (unlike the Tungsten HAL, we can safely assume the ROM image is valid)
• RTCAdjust
  • Module needs updating to understand HAL RTC’s before it can be used with the OMAP port
• USB
  • HAL USB enumeration doesn’t work too well; may not even work at all if both HAL & PCI USB controllers are present
  • Need to investiage the problem that causes certain hubs to not report port status change events when using the EHCI port
• Touch Book
  • Someone with a touch book and a few spare hours needs to work out how to get a ROM image to boot. See here for more info.
• Power saving
  • Make more stuff call Portable_Idle. Potential candidates:
    • DebugTerminal code that calls HAL_DebugRX (tricky – HAL isn’t likely to use interrupt driven debug I/O. Plus low priority since only developers would be using the code.)
    • IRQ-based IIC ops
    • SCSISwitch poll loop (when waiting for IRQ-driven driver to complete op)
    • USB driver tsleep() implementations
  • Implement Portable_Stop for suspend-to-RAM functionality
  • Implement Portable_Speed, or newer API, to provide control over CPU frequency
    • May also be possible to do other power-saving tricks, e.g. downclocking RAM, automatically disabling audio if no sounds are playing, etc.
• Audio
  • Fix the pop that occurs when turning sound off
• SCSI
  • Get background transfers working to improve performance
  • Add USB CD support
• Make sure all the corrupt messages files get fixed!
• Investigate the FileCore RAM disc crash
• Fix the boot sequence/network stack so it doesn’t fail if EtherUSB is in use but no NIC is connected
• Do Tank’s tweaks (see here and here)