RISC OS 5.24 approaches

The latest stable release of RISC OS is now entering its final stages ahead of a planned release date in April 2018. This has been a long, hard slog and represents a significant milestone – it will be the first stable release for the Raspberry Pi.

RISC OS has been ‘ported’ to run on a range of hardware platforms, with the various ports available to download from our downloads pages. Each of these ports is maintained by different groups, for example the iMx6 port is maintained by RComp, Iyonix is maintained by Castle Technology and the Titanium port is maintained by Elesar. RISC OS Open acts as a co-ordinator and helps to ensure that all ports offer a consistent level of functionality and stability.

To help our community to track progress of RISC OS 5.24 as it nears completion, we have created a handy release status page, which shows how close each of the platform ports are to being compliant with our definition of a stable release. There should also be release status pages in our wiki with more detail for each of the ports – but note these are not necessarily created or maintained by ROOL. Our aim is to ensure that by April all ports have the green light!

Congratulations to everyone at ROOL and everyone who has contributed their time and money. Looking forward to trying the stable release in April.

Beagleboard, iMX6, and OMAP5 status pages don’t exist.

The Beagle is easy, it’s here → https://www.riscosopen.org/wiki/documentation/show/Cortex-A8%20port

The others…?

The others…?

Follow the link for release status page.

Great news, well done but looks like much work to be done before April (not 1st April?). Will this version become part of the Noobs distribution. It was very useful being able to set up dual booting on the Pi 2 B+ (version 1) for RC14 and Raspbian.

status pages don’t exist.

Follow the link for release status page.

“…”

I’m assuming that where things are marked as “desirable” or “fail”, the relevant people will be given more information about what could/should be done to improve things? I.e. I don’t need to worry about anything until I receive an email about it.

By happy coincidence the final chapter of the overhauled User Guide slotted in yesterday too (thanks to Chris Mahoney for that last chunk).

We’re now looking for the community to shake out any hidden errors by downloading the draft and reviewing one or more chapters by following the handy 5 step process.

The deadline to complete the book is middle of March (longer lead times than ROMs).

I’m assuming that where things are marked as “desirable” or “fail”, the relevant people will be given more information about what could/should be done to improve things?

I was assuming that everyone that is capable of doing anything would be informed by means of notes on the linked pages and I think Rick was thinking the same way when he looked and discovered missing page links.
After all some of the work is at a simple level and shouldn’t be occupying the time of someone capable of really doing some work on the OS

Correct. The exact reasons for us marking something as “Desirable” or “Fail” will be published shortly and all tied-into the main status page.

I was assuming that everyone that is capable of doing anything would be informed by means of notes on the linked pages and I think Rick was thinking the same way when he looked and discovered missing page links.

That’s what I was initially thinking, but missing pages + lack of edits to existing pages suggests otherwise.

(edit)

Looks like I spoke too late!

Correct. The exact reasons for us marking something as “Desirable” or “Fail” will be published shortly and all tied-into the main status page.

Looks like we all misunderstood certain bits
Perhaps the phrase you used needs a bit of modification:

To help our community to track progress of RISC OS 5.24 as it nears completion, we have created a handy release status page, which shows how close each of the platform ports are to being compliant with our definition of a stable release.

I’d suggest this is modified with:
…we have created a handy release status page and are in the process of creating and linking sub-pages which will show how close each…

Edit: I work in IT support and I’m more familiar than I ever wanted to be with people constantly asking the equivalent of “are we nearly there yet?”

I am probably the only one sensitive to wrong caseing of things – is there a reason why the SoC named i.MX6 (sometimes also referred to as iMX6 or i.MX 6 even by its creators) is constantly referred to as iMx6?

And someone should decide whether it is “Wandboard” or “WandBoard”. The creators say it is “Wandboard”.

is there a reason why the SoC named i.MX6 (sometimes also referred to as iMX6 or i.MX 6 even by its creators) is constantly referred to as iMx6?

If the people that created the board aren’t consistent what chance does anyone else stand of picking the right version(s)?

If the people that created the board aren’t consistent what chance does anyone else stand of picking the right version(s)?

There is no chance to do the “right” thing because nobody knows what is right. But adding one more (and new!) wrong way is certainly completely wrong.

But adding one more (and new!) wrong way is certainly completely wrong.

Is it wrong? because to know something is wrong you need to know what “right” is and as you pointed out:

There is no chance to do the “right” thing because nobody knows what is right.

So it would seem that pretty much anything that contains the characters “i” , “m”, “x” and “6” in upper or lower case in that order is likely to be as correct as anything else.
Note: the “.” seems to be optional as does the " "(space)

Anyway, shouldn’t people be looking for typo’s in the userguide?

Correct. The exact reasons for us marking something as “Desirable” or “Fail” will be published shortly and all tied-into the main status page.

Done. Now all ‘desirable’ and ‘fail’ entries have a mouse-over tooltip describing our rationale.

Thanks also for all the editorial feedback. Please don’t forget to help review the User Guide.

We’re now looking for the community to shake out any hidden errors by downloading the draft and reviewing one or more chapters by following the handy 5 step process.

Is there any way to feed back wrong stuff without reviewing a whole chapter? I don’t have time for the latter at present, but spotted something the other day which looks factually wrong (or at least misleading).

Is there any way to feed back wrong stuff without reviewing a whole chapter?

There is a small corrections page.

https://www.riscosopen.org/wiki/documentation/show/User%20Guide%20small%20corrections

Please note, we’ve just updated the release status page with the current status.

Our latest update has now been uploaded.

• IOMD (e.g. RiscPC), Iyonix and Raspberry Pi are now good to go.
• Beagleboard, Pandaboard and Titanium are getting close.
• iMX6 and OMAP5 still have significant outstanding issues and will not make the initial cut for the 5.24 stable release unless corrective action is made soon.

Raspberry Pi is now good to go

Does that include the new Pi 3B?

Does that include the new Pi 3B?

It seems so. At least the update page includes…

Raspberry Pi – as a bonus, differences between the Pi 3B and 3B+ use of LEDs and faster ethernet controller have been accommodated (Jeffrey Lee)

I am unsure whether that includes all differences, though.

Raspberry Pi are now good to go.

There is still this rather aggravating issue. It is very interment and very elusive, a number of failures occur together then it is good for days on end with no known way to reproduce it!

Other than that the new RPi3B+ is good with current ROMs.

Our latest update has now been uploaded.

• Overall, the OMAP3 (Beagleboard) transitioned from amber to green.
• Overall, the OMAP4 (Pandaboard) transitioned from amber to green.

Many thanks to our selfless volunteers who are doing the work on getting these ports ready.

OMAP5 and iMX6 continue to lag well behind the other ports. There are a number of pretty minor outstanding issues blocking them right now so with a small amount of effort, they could still make the cut. If it doesn’t happen this week, they will not be considered stable and 5.24 will not be released for those platforms.

At present the port consists of three components:

A HAL targetting Broadcom’s BCM2835 system-on-chip.

Is that accurate? I thought the HAL for the Pi covered more than just the one SoC.