Stable Release Status (5.24)

Summary

The table below gives a summary of the stable release (5.24) readiness of each RISC OS port, based upon a review by RISC OS Open (ROOL) conducted on 27 January 2018.

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.

Update 02-Feb-2018

The sections now detail specifics when hovering over the word Desirable or Fail, so that port maintainers can see what needs to be addressed before the April cutoff.

Update 26-Feb-2018

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

• Beagleboard – port status page updated (Jeffrey Lee, Sprow)
• Raspberry PI – Gamma curve supported for GraphicsV (Jeffrey Lee)
• Iyonix – HAL now implements TimerIRQClear (Jeffrey Lee)
• Titanium – Some brands of external hub used to cause hang at power on (Elesar)
• iMX6 – IMXVideo search for HAL device type loop exit now uses CMP to avoid infinite loop (John Ballance)
• iMX6 – GraphicsV despatch now respects the driver number in b24-b31 of GraphicsV reason (John Ballance)
• iMX6 – IMX6Video is now in the right order of RegisterDriver; claim GraphicsV; StartDriver (John Ballance)
• iMX6 – Debugging command ReadEDID and hardwired MDF removed from IMXVideo (Jeffrey Lee)
• iMX6 – Gamma curve supported for GraphicsV (Jeffrey Lee)
• iMX6 – Video mode vetting now vets the mode and has internationalised text (Jeffrey Lee)
• iMX6 – Failures during IMXVideo initialisation are now correctly cleaned up after (Jeffrey Lee)
• iMX6 – The missing IMXVideo colour depths are now reported via GraphicsV (Jeffrey Lee)
• iMX6 – Video driver no longer peeks MonitorType CMOS, which the kernel and ScrModes handle (Jeffrey Lee)

Overall, the Raspberry Pi transitioned from red to amber.

Update 25-Mar-2018

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

• Iyonix – Removal of NVidia straps deferred (see port status)
• Raspberry Pi – 3.5mm audio out tested on socket J7 (Sprow)
• Raspberry Pi – GPIO table updated to cover model ZeroW (Sprow)
• OMAP5 – gained a port status page in the wiki (Willi Theiss)
• Raspberry Pi – as a bonus, differences between the Pi 3B and 3B+ use of LEDs and faster ethernet controller have been accommodated (Jeffrey Lee)

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

Update 01-Apr-2018

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

• OMAP3 – GPIO HAL device updated from obsolete API 0.0 to API 1.0 and GPIO module now included (Sprow)
• OMAP4 – GPIO HAL device updated from obsolete API 0.0 to API 1.0 and GPIO module now included (Sprow, Willi Theiss)

Overall, the OMAP3 transitioned from amber to green.
Overall, the OMAP4 transitioned from amber to green.

Update 08-Apr-2018

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

• Titanium – big video modes such as 1920×1200@60Hz no longer tear due to the video DMA not getting enough bus time (Elesar)
• OMAP5 – port status page brought up to date declaring the boot mode multicolour problem (Willi Theiss)

Overall, the Titanium 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 CVS and Code review forum from 01-Apr-2015 to 03-Aug-2017

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

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)

USB sockets act upon overcurrent situations.

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

All GraphicsV entry points are implemented

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

USB

Ethernet

Forum/mailing list chatter