Stable Release Status (5.28)

Summary

The table below gives a summary of the stable release (5.28) readiness of each RISC OS port, based upon a review by RISC OS Open (ROOL) conducted on 19 February 2020 of the code in GitLab. This page will be updated weekly as the planned release date approaches; watch this space…

Beagleboard	IOMD	iMx6	Iyonix	OMAP5	Pandaboard	Raspberry Pi	Titanium
Status	Status	Status	Status	Status	Status	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. The table from the previous readiness test is available for comparison.

Update 23-Feb-2020

Reviewing recent changes to the ports, we’ve updated the table to reflect

• Iyonix – NVidia driver now supports VetMode 2 GraphicsV call (Jeffrey Lee)

Overall, the Iyonix transitioned from amber to green.

Update 09-Mar-2020

Reviewing recent changes to the ports, we’ve updated the table to reflect

• OMAP5 – port status page brought up to date (Sprow)
• IOMD – removed VetMode 2 requirement as VIDC20 doesn’t support extra bytes on each line (Jeffrey Lee, Sprow)

Overall, the IOMD transitioned from amber to green.

Update 22-Mar-2020

Reviewing recent changes to the ports, we’ve updated the table to reflect

• OMAP5 – confirmed system sound on J1500 audio out (Willi Theiss)
• Raspberry Pi – port status page brought up to date (Stuart Painting, Sprow)

Update 06-Apr-2020

Reviewing recent changes to the ports, we’ve updated the table to reflect

• Beagleboard – OMAPVideo driver now supports VetMode 2 GraphicsV call (Jeffrey Lee, Sprow)
• Pandaboard – OMAPVideo driver now supports VetMode 2 GraphicsV call (Jeffrey Lee, Sprow)

Overall, the Beagleboard and Pandaboard transitioned from amber to green.

Update 13-Apr-2020

Reviewing recent changes to the ports, we’ve updated the table to reflect

• OMAP5 – OMAPHDMI driver now supports VetMode 2 GraphicsV call (Willi Theiss)

Update 04-May-2020

Reviewing recent changes to the ports, we’ve updated the table to reflect

• Raspberry Pi – Adds EtherGENET driver (Sprow)

Update 06-Jul-2020

Reviewing recent changes to the ports, we’ve updated the table to reflect

• Titanium – NULL pointer fix when idling in XHCIDriver (Sprow)

Overall, the Titanium port transitioned from amber to green.

Update 14-Sep-2020

Reviewing recent changes to the ports, we’ve updated the table to reflect

• Raspberry Pi – Functioning 4x external USB ports (Sprow)

Update 12-Oct-2020

Reviewing recent changes to the ports, we’ve updated the table to reflect

• Raspberry Pi – Pullup resistors implemented/fixed across models (David Higton, Sprow)
• Raspberry Pi – Gamma remains disabled per RC16 (Jeffrey Lee)

Overall, the Raspberry Pi port transitioned from amber to green.

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 04-Aug-2017 to 19-Feb-2020

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