RC2 - heading towards the finish line

How would I use a ROM on the Pi?

How would I use a ROM on the Pi?

You put the file on the SD card for the bootloader to find.

RC3 is now (today) available for download and still no roms for Pi or Titanium

What is there looks satisfactory on RPCEmu.

What is the issue with the Pi RC ROM ?

The two BCMVideo tasks can’t be fixed until the Pi devs implement firmware changes. Evidence for the video blanking issue was submitted to them back in 2019, where it stalled and the Pi4 missing mailbox issue has been closed as completed although I can’t see where they say they’ve implemented it.

The final issue, EtherGENET, appears to be specific to the Pi400 and in-hand.

Are there other issues that aren’t mentioned? Nightly builds are still occurring, so there’s nothing fundamentally wrong with ROM itself as far as I can tell.

Am I to conclude the Pi won’t see a 5.30 release? Or will it be delayed and have its on RC’s?

As inspected on RPCEmu the IOMD RC3 ROM is largely the same as today’s Dev build. The UtilityModule version is bumped to 5.31 but with the same date, and the Menu module is regressed to 0.40.

A Verma diff :-

--- HostFS::HostFS.$.SymLinks.uHD4._ROOL.RC3.OS529	2023-03-26 08:31:38.0 +0100
+++ HostFS::HostFS.$.SymLinks.uHD4._ROOL.RC3.RC3	2023-03-26 08:31:38.0 +0100
@@ -2,7 +2,7 @@
 -------------------------------------------------------------------------
   ROM   RMA   Status     Title                  Version              32b
   ----- ----- ---------- ---------------------- -------------------- ----
-  0     0     Active     UtilityModule          5.29 (30 Jan 2023)    Y
+  0     0     Active     UtilityModule          5.31 (30 Jan 2023)    Y
   1     1     Active     Podule                 1.72 (24 Jul 2016)    Y
   2     2     Active     FileSwitch             2.92 (25 Mar 2023)    Y
   3     3     Active     ResourceFS             0.26 (18 Aug 2016)    Y
@@ -107,7 +107,7 @@
   100   92    Active     Toolbox                1.60 (15 Feb 2023)    Y
   101   93    Active     Window                 1.80 (25 Jan 2023)    Y
   102   94    Active     ToolAction             0.38 (20 Mar 2016)    Y
-  103   95    Active     Menu                   0.41 (07 Jan 2023)    Y
+  103   95    Active     Menu                   0.40 (01 Nov 2015)    Y
   104   96    Active     Iconbar                1.23 (18 Jun 2016)    Y
   105   97    Active     ColourDbox             0.23 (25 Jan 2023)    Y
   106   98    Active     ColourMenu             0.23 (09 Sep 2018)    Y

the Pi4 missing mailbox issue has been closed as completed although I can’t see where they say they’ve implemented it.

? The final message there says: Gamma is not implemented full stop on Pi4.

the Pi4 missing mailbox issue has been closed as completed

It says “closed as completed” but I think that may be because GitHub doesn’t have a “closed as duplicate” category. If you go to the thread it is a duplicate of, you will find this message which suggests the issue is still to be fixed, but is rather low on their list of priorities.

I think the main focus should be on the raspberry Pi.
This is the computer on which Risc os runs best and is “cheaply” available.

Not to worry. In one case, I am quite happily still using 5.24 on a Raspberry Pi.

There are some strange priorities being applied – obsolete stuff like pandaboard and beagleboard getting an unnecessary 5.30 when they stopped developing a while back and the Raspberry Pi which is still developing, eMMc, CM4 etc. left until last!? Who sets the priorities? Quis custodiet ipsos custodes?

If things aren’t fixed upstream in Pi-central then we can’t use them down in RISC OS.

There are some strange priorities being applied – obsolete stuff like pandaboard and beagleboard getting an unnecessary 5.30 when they stopped developing a while back and the Raspberry Pi which is still developing, eMMc, CM4 etc. left until last!?

I would guess that some ports like PandaBoard, BeagleBoard, IYONIX and IOMD were stable before and therefore no (port-specific) work needed to be done to get them in shape for the upcoming 5.30.

The RPi is more of a moving target (new variants), but I am not sure why it is given the red light – but I have not tried a Nightly in ages, so there might be a serious problem somewhere.

Who sets the priorities?

I am sure the RPi port has the highest priority, but setting the priority unfortunately does not magically deliver the solution.

Who sets the priorities? From what I see in non-sponsored open source projects, it’s quite simple: the person submitting the code. e.g. If I want to work on supporting Econet on a Kinetic Risc PC, then I’m welcome to submit relevant code. Each developer is scratching their own itch.

Where this can get frustrating is when a non-developer really wants bug fix X, change Y or feature Z. They need to find a willing developer and convince them, either with interest or money.

In a professional (literally, as in paid-to-do-it) environment, then it’s totally different. I get paid to work on what I’m told to work on. Doesn’t really matter if I like it or agree with it one iota.

If I want to work on supporting Econet on a Kinetic Risc PC, then I’m welcome to submit relevant code. Each developer is scratching their own itch.

+1 , this is how Open Source actually works, so thanks for mentioning it Richard.

In addition, in the Open Source side, is also common (these days) to have effort sponsored by Corporations, which are more similar to the 3rd case you’ve mentioned (the professional environment) which mix with Open Source and, in recent times, also became the biggest portion of the entire contributions to projects like Linux.

However, RISC OS only seems to have one commercial customer sponsoring for developments, which has lead to get the ROD developed Netowrk Stack adn then ROD funding model that has lead to have Iris, which is now in an “undefined” situation where the sources never seems to reach the community (probably due to the predictable maintenance costs).

The RPi is more of a moving target (new variants), but I am not sure why it is given the red light

It recently transitioned from amber to red due to (i) revision 1.1 Pi 400’s network and (ii) Pi3B SDIO controller. It got a stable release for RISC OS 5.28 before these difficulties surfaced, so it’s going in the wrong direction due to new chips being used. Looks like our close relationship with the Pi Foundation is not as close as it was.

In addition, in the Open Source side, is also common (these days) to have effort sponsored by Corporations, which are more similar to the 3rd case you’ve mentioned (the professional environment) which mix with Open Source and, in recent times, also became the biggest portion of the entire contributions to projects like Linux.

Which does little for the lambda Linux user as it is all server oriented developments. I use the Unix side of the 4té for browsing and watching videos during evenings and I lost count of the times it stops reacting to mouse/keyboard input and all I can do is press the power off button.

It recently transitioned from amber to red due to (i) revision 1.1 Pi 400’s network and (ii) Pi3B SDIO controller.

Things outwith ‘our’ control. The fact that newer hardware exists called ‘Pi’ than is supported by the current OS doesn’t make 5.30 any worse than 5.28, does it? Going ‘red’ for this reason kinda implies that the stable 5.28 should be withdrawn as there is hardware it doesn’t work on?

Which does little for the lambda Linux user as it is all server oriented developments.

Very true, but there is Pop_OS! which, in the other hand, is a distro that gets funded to be developed for Desktop and that seems to be paying off. You may not like it, but surelly the combination of HW/SW is allowing System76 to develop really nice Linux Desktop solutions.

The fact that newer hardware exists called ‘Pi’ than is supported by the current OS doesn’t make 5.30 any worse than 5.28, does it?

Isn’t it the case that some recent releases of the Pi hardware working with RO was more of a happy accident that a small tweak was the only change required?
Except that the small change didn’t magically add support for a second controller (oh, different thread). It did work mostly, though, which was good enough for most of us.

Isn’t it the case that some recent releases of the Pi hardware working with RO was more of a happy accident

For example CM4 which was sufficiently like Pi4B that most things worked (Ben had sorted out SDIO by then but it still hangs if the PCIe bus is not populated due to its assumption that something is on PCIe in hardware on Pi 4) . A small tweak to get eMMc working and to make SDFA::0 and SDFS::4 (SD card and eMMc) the right way round was done. So the only work around on CM4 is to ask ‘is the PCIe populated?’ and if the answer is no, then populate it!

There are some strange priorities being applied – obsolete stuff like pandaboard and beagleboard getting an unnecessary 5.30 when they stopped developing a while back and the Raspberry Pi which is still developing, eMMc, CM4 etc. left until last!?

I would guess that some ports like PandaBoard, BeagleBoard, IYONIX and IOMD were stable before and therefore no (port-specific) work needed to be done to get them in shape for the upcoming 5.30.

Steffen has it right: when the race to 5.30 started nothing significant (if anything) turned up in the time consuming review of the ports so they go green, therefore release candidates are now available to test. Quoting the very same status page

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

In other words ROOL are managing the submissions and source code, and turning the handle on the release candidate sausage machine, but they aren’t offering to fix everyone’s bugs for them too. The stable release process isn’t a secretive affair – the source code, judging criteria, identified bugs and targeted features are all there to see. I just hope Chris’ table top banging hasn’t scared off anyone thinking about mucking in, a little gratitude will likely yield better results.

[Pi] recently transitioned from amber to red due to (i) revision 1.1 Pi 400’s network and (ii) Pi3B SDIO controller.

The download for 5.28 indicates it doesn’t work on revision 1.1 Pi 400, and the Pi3B SDIO issue has occurred because work was done in that area after 5.28 which has unwittingly broken something. It seems reasonable to require these issues to be addressed for 5.30 so that someone with a Pi has as high odds as possible of it working.

e.g. If I want to work on supporting Econet on a Kinetic Risc PC

You working on Econet too? Cool. It’s nearly the Econet LAN party!

Grateful for the explanation. One thing that might be worth considering for the Pi is a ‘snapshot’ of a rom that includes the excellent work to support some of the new features, recognising cm4, supporting eMMc, etc. that 5.28 did not support but allows particularly new users to download a ‘known good’ rom rather than only 5.28 or a daily 5.31 build which may have glitches.

That is an argument for a 5.30 Pi rom even if it has to exclude latest models of the Pi 400. But I do agree that the Pi3B SDIO issue is a problem (hadn’t known about that). The Pi400 is a timing issue: if 5.30 stable had been issued the day before the 1.1 Pi 400 was created … There is a risk that, with Pi development proceeding, we will never get to a stable version. Table top now muffled.

the Pi3B SDIO issue has occurred because work was done in that area after 5.28 which has unwittingly broken something

I was not aware of a Pi3B SDIO issue which from here is specifically, “Pi 3B hangs on Boot due to unique SDIO controller”

My RPi3B does boot into RISC OS. There is a bit of a snag in that updated SDIODriver does not show all the devices.

*FX0
RISC OS 5.29 (30 Mar 2023)

Platform      : Raspberry Pi 3 Model B

*sdiodevices
Bus Slt  RCA Fun  Description        Capacity     Vendor    Product Rev Date
  0   0  59B4  0  SDHC card            30 Gbytes  LS        USD00   1.0 2020-07
*sdioslots
Bus Slt  Voltage  Width  Frequency
  0   0   3.3 V   4-bit   50 MHz SDR
*

An RPi3B+ and the RPi4’s show 4 devices and 2 slots.

However with Raspberry Pi OS on the RPi3B there is absolutely no sign of bluetooth or WiFi, no icons in the top bar, and nothing from ifconfig -a or rfkill. The same SD card works fully in the RPi3B+. I am reasonably convinced that the RPi3B is a bit RPi3B-. The WiFi/Bluetooth chip might have got unchipped somehow but the SDIO slots are a function of the processor

I fired up the RPi3B in case it might be of diagnostic use.

It is possible that a fault on my RPi3B evades the SDIO boot up failure that would occur in a fully functioning RPi3B.

I don’t whether this helps are not but I post it just in case.

So I’m running 5.29 22-Dec-2022 on both RPI-3B V1.2 and RPI 3B+. The above messages seem to be saying that at least one of these should be failing to boot, but both boot perfectly. (REF: Work done after 5.28 caused a problem.)

I just tried a recent (26 March 2023) 5.29 build on both of my Pi 3B devices. With 10 January 2019 firmware, *SDIODevices shows 1 device on bus 0 (the SD card) and 2 devices on bus 1 (both labelled “SDIO non-standard function”). I guess that means I’m not using the updated SDIO driver.

In case it mattered, I also tried 17 March 2023 firmware (the release that fixed the unfortunate “try to boot all kernels as 64-bit” firmware bug) – the output from *SDIODevices was unchanged.