Stable Release Status

Summary

The table below gives a summary of the stable release (5.30) readiness of each RISC OS port, based upon a review by RISC OS Open conducted on 28 May 2022 of the code in GitLab (except for the PineA64 port which is waiting for ROOL to set up a nightly build). This page will be updated weekly as the planned release date approaches; watch this space…

Beagleboard	IOMD	iMx6	Iyonix	OMAP5	Pandaboard	PineA64	Raspberry Pi	Titanium
Status	Status	Status	Status	Status	Status	Waiting	Status	Status

Details

Please note: many of these ports are maintained by other people and companies so this should not be interpreted as indicating the work remaining for ROOL to complete the stable release preparation.

The remainder of this page gives a more detailed breakdown of the status of each port, based upon the criteria specified in our stable release policy. You can also compare this with the previous readiness tests for RISC OS 5.24 or RISC OS 5.28.

Administrative

The port status page should reflect the current status of any known unresolvable problems

Port has “Status of the NNN port” page on the wiki, and is up to date (see policy) so users can compare ports side by side.

A products file must be provided listing the tags of all the components included, and corresponding components file

ROOL will generate the tags prior to building release candidates

If a previous stable release exists, the (autogenerated) change logs must be made available based on the previous products file. Newly stable platforms can’t provide this, so isn’t needed.

ROOL will generate change logs from the previous products files

Peripherals

Accessible plugs and sockets for which there are support in contemporary platforms should be similarly supported

Inaccessible or internal plugs and sockets need not be supported, or can be powered down

Modules

Module names, SWI bases, error bases etc… must be registered using the normal allocation service to avoid clashes.

ROM based modules must be internationalised via MessageTrans, with default en-gb translations in ResourceFS.

Disc based modules can use fixed en-gb strings, since international users can replace those easily by copying a localised version on top.

Programmer’s interfaces

Any newly introduced APIs should be finalised and run past ROOL to check they make provision for future hardware.

From inspection of GitLab and Code review forum from 20-Feb-2020 to 28-May-2022

Any extensions to existing APIs should be finalised, and extended in as backwards compatible manner as practical.

Part of the guarantee of a stable release is that programmer’s can rely on (and test for) APIs and that they will be continue to be supported in the future

Updates to other disc based applications that your platform relies upon should also have been made

Hardware abstraction

Generally the main difference between platforms are involved in the HAL; video; USB; and ethernet, though some platforms might share some of these. Each must implement the entry points that their contemporaries do.

HAL

Video driver

All GraphicsV entry points are implemented

USB

USB sockets act upon overcurrent situations.

USB bulk, control, and interrupt end points are supported.

Ethernet

An autosense file is provided for any new ethernet driver(s), which abandons gracefully on systems that don’t include that driver

The info/self test commands are implemented and follow the general form of the other ethernet drivers (eg. EtherK)

Forum/mailing list chatter