Wi-Fi in 5.30

I have retested using ethernet without Wifi but have still got the ROD network stack installed and the machine has run all afternoon for approx 10 hours streaming an internet radio station without any issues. Have just tested again with the replaced !Boot.loader files and running the 5.31 ROM dated 25Apr2024) and still seems to be stable.

CTRL-BREAK works and can reboot

World be interesting to try Alt-Break instead, to see if it reports which application has hung.

Also, 2 hours is a weird time for it to consistently fail. The only thing I can think of that happens about that time is the TCP keep-alive packets will start arriving (IIRC).

DownUnderROUser – any chance you could drop me an email at andrew at riscosdev.com so that I can send you the latest internal build – I think your problem may have been dealt with (there was a counter in the wifi driver that was limited to 16-bit depth, which is now 32bit – that could eventually lead to problems), but if not, we’d like to get more data. Our coders don’t tend to follow forums too much, so direct contact really helps resolve things. Thanks.

would be good if one of the advanced selections boxes was to include the Wifi driver or to leave it out (ie not current default of including it)

If you leave the Wifi interface unconfigured the Wifi module doesn’t get loaded. PartMgr already does this so no need to re-image.

I’m hoping ROOL will see common sense and include it in the ROM at some point, so I don’t have to inkjet it during the drive build.

Before I added WiFi, I contacted Andrew R. about including the ROD WiFi stack, so you have the option but as it’s not officially released that wasn’t feasible yet. It’s a similar issue with the Pinebook Pro boot drive build, although that has more issues, which I raised with Andrew in Jan. Same thing goes for the ROD NVMe driver, which was missing essential SWI (detach / attach physical drive) and was then pulled.

The structure of the ROD download site and the need for a password makes their offerings a non-starter for Partition Manager as PM needs to be able to find the latest version information without authentication.

Whilst I’m publicly disclosing discussions with Andrew, I also offered to rewrite the Pinebook Pro GraphicsV driver, but couldn’t start looking at it until the existing GraphicsV bug which prevents softloading both ADFFS and a replacement GraphicsV driver is fixed.

Adding WiFi and NVMe drivers for the Pinebook Pro to Partition Manager were ruled out by Andrew, neither are free and I wasn’t provided with copies to develop/test the build when I raised it with Andrew.

Also raised was the fact the Pinebook Pro uses an embedded bootloader, instead of U-Boot which prevents me adding dual-boot support in Partition Manager. It also causes a few other issues due to the strict drive structure required.

RISCOSbits also have one outstanding issue. Drive detach/attach were added to the NVMe driver but the change wasn’t merged into the ROOL repository.

TLDR; I’m waiting for ROD to resolve several issues before ADFFS/Partition Manager can support their offerings and RISCOSbits need to merge a change.

Speaking directly to developers does not help speed things up, in fact I think it’s the opposite as developers forget about things and have their own work. If issues are publicly tracked via forums/bug tracker the discussion can both be open and allow progress to be tracked.

find the latest version information without authentication.

The site is currently down, anyway… ;)

there was a counter in the wifi driver that was limited to 16-bit depth, which is now 32bit – that could eventually lead to problems

Ah, it is 16-bit, I thought I had the maths wrong

Getting back on-topic, I noticed the SDIO spin-locks occurred a lot more if I’m using overlays – could the issue be mailbox related?

Perhaps we need a mailbox arbiter that retries mailbox messages when they either can’t be made or are rejected? I’ve not looked at how mailbox messages are currently done in RISC OS, but given overlays can fail due to mailbox issues, I suspect its left to each Module to handle it’s mailbox messages.

I’ve tried dozens of ways to produce a repro for the issue, all without success…and yet I can get it to occur without fail with certain games. That’s not particularly helpful as the SOE isn’t easily determined.

It would really help if the WiFi source was available or debug builds of the WiFi/SDIO Modules where created with info around the blocking actions.

I suspect SDIO’s use of Upcall 6 might also a factor when WiFi is performing background actions that shouldn’t stall the current foreground task.
This week I created a debug info GraphicsV overlay, so I could see where the PC is at every IRQ – primarily to see if the issue only occurs when the Wimp is shelled, or if it also occurs at the desktop. So far, I’ve only reliably created the issue when shelled out of the Wimp.

Getting back on-topic, I noticed the SDIO spin-locks occurred a lot more if I’m using overlays – could the issue be mailbox related?

I found if SDFS is not used then the lock up seems to stop happening. Either boot off SD card but with e.g. ‘configure filesystem scsi’ and !Boot on SCSIFS or booting directly off USB, NVMe, etc.

Similar to the RPi 400 revision 1.0 the RPi Zero 2 W can’t connect to Wifi with encryption enabled. Just gets ‘connection refused. I haven’t tried without encryption yet.
Using the same SD card Wifi connects OK on a Zero W,RPi 3B+ and A+.

but this did not fix the problem and the BCM issue also reared its head again with the colour swapping which made me think that the pi firmware must be more recent (even though using partition manager I selected the stable firmware option to create the image).

PartMgr just points to the ‘stable’ folder on the Rpi github site. Currently it’s May 24th 2024.

*vcgencmd version

So then I deleted the contents of !Boot.Loader and then copied the entire !Boot.Loader folder which has the 5.31 RISCOS/IMG from 25Apr2024 as well as the other 8 files (pi firmware etc) over from my other Pi4b8GB and the problem has now resolved.

You may have just got unlucky with the firmware being too new to use with the boot loader version you have.

*vcgencmd bootloader_version

You may have just got unlucky with the firmware being too new to use with the boot loader version you have.

It’s not a bootloader issue, it’s a bug in RISC OS 5.30 (triggered by a firmware change in May 2024). The bug is fixed in recent 5.31 builds.

“Stable” firmware" is a designation by Raspberry Pi Ltd, so is applicable to Raspberry Pi OS only. The current “stable” firmware release is from May 2024, so will exhibit the framebuffer_swap bug on RISC OS 5.30.

The suggested workaround is to change the “framebuffer_swap=0” line in config.txt to read “framebuffer_swap=1”. This will allow RISC OS 5.30 to use recent firmware.

It’s not a bootloader issue, it’s a bug in RISC OS 5.30 (triggered by a firmware change in May 2024). The bug is fixed in recent 5.31 builds.

Yes. But that’s a known problem with a particular version of the firmare onwards and versions of the RISC OS rom before a certain date.

I was referring to a different problem in that if the firmware is too new for the bootloader_version it can cause issues with RISC OS.

“Stable” firmware" is a designation by Raspberry Pi Ltd, so is applicable to Raspberry Pi OS only. The current “stable” firmware release is from May 2024, so will exhibit the framebuffer_swap bug on RISC OS 5.30.

The ‘stable’ option in PartMgr points to that version so it is revelant to RISC OS if you’re using PartMgr.

While testing Wifi on a RPi3 B+. After a few minutes the Wifi network connection stops traffic flow. Disconnecting and reconnecting resumes the flow.
Not the seen the issue on Rpi 4 or CM4.

@ Jon – thank you for sharing some of the background story to development of partition manager. it is great software – so thank you ! and yes very pertinent reminder that the wifi drivers are beta – can understand why ROD would not want them bound up into another software package if still evolving. And also totally understand not being able to integrate the pinebook stuff – ROD / RComp have no doubt invested not small sums of money in getting these platforms up and running.

@ Chris G – I am booting off an SSD on a USB port – not using SD cards at all (set up the SSD using Partition Manager from another pi machine).

Re earlier comments as to IRIS stability.

With the current test setup ie 5.31 with Rod TCPIP stack and using ethernet networking (not wifi) have had a machine running for nearly 24 hours with a rotating graphic web page (my site) and also the ROOL forums open. Have hooked in using VNC both early yesterday morning and again this morning to the same session from a W10 machine and everything has been running well and stable. So it looks like my previous suspicion re IRIS was really more to do with the Wifi drivers (acknowledging that IRIS won’t cope well with some sites)

Having said that I just managed to run a few passes on speedtest.net and they completed successfully (although not used to seeing all the advertising graphics as when run it on my W10 box the adblockers etc keep the appearance much cleaner). it wouldn’t consistently run every time or a second time in succession but a fresh reload of IRIS (and IRISram) managed to get a few runs done…
Not as fast as the W10 box but still not terrible – managed to get 3.54Mbps download and 12.28Mbps upload on RISC OS on 1 test and 5.4Mps download, 9.21Mbps upload on another – compared with 63.43Mps download and 13.91mbps upload on the W10 machine on the same connection (both wired to a router and then using a 4G modem connection).
I could not successfully complete such tests when trying to run using wifi (either version)

Not bad for a web browser running on a single core.

@Andrew R – yes have emailed your directly, apologies for posting via forums etc but came off the back of joining the tail end of a ROUGOL meeting and seemed worthwhile to share experiences with others trying same

Similar to the RPi 400 revision 1.0 the RPi Zero 2 W can’t connect to Wifi with encryption enabled. Just gets ‘connection refused. I haven’t tried without encryption yet.
Using the same SD card Wifi connects OK on a Zero W,RPi 3B+ and A+.

The Zero 2W connects to my router OK using WPA2-PSK according to WiFi Manager. For reference, the Zero 2W has the same chipset as a Pi 3 and Zero W, so those 3 should all behave the same, and in addition all 3 only support 2.4GHz while the other WiFi-capable Pi models are dual band 2.4 or 5GHz.

can understand why ROD would not want them bound up into another software package if still evolving. And also totally understand not being able to integrate the pinebook stuff – ROD / RComp have no doubt invested not small sums of money in getting these platforms up and running.

Slight tangent here, but I can’t understand that all. As usual, everything is shrouded in secrecy – but it’s not clear why.

Browse some projects on GitHub – from big-ticket items to minor utilities. Notice anything? Very few are ‘finished’ or ‘ready’ – they are all constantly evolving in their own little ways. Yet we still have open discussion, issues/tickets, source code, pull/merge-requests etc. It only seems to be RISC OS land, where this is ignored.

And I’m not only pointing the finger at ROD. We can download WiFi software from this very web site, but the source isn’t visible in GitLab. Hmm.

The Zero 2W connects to my router OK using WPA2-PSK according to WiFi Manager. For reference, the Zero 2W has the same chipset as a Pi 3 and Zero W, so those 3 should all behave the same, and in addition all 3 only support 2.4GHz while the other WiFi-capable Pi models are dual band 2.4 or 5GHz.

Just tried it again to make sure. ‘Connection refused’ almost immediately after clicking connect. Works if encryption is disabled on the router. Also fails in the same way on my phone hotspot.

Whereas Zero W and Pi 3B both work fine.

The Zero 2W connects to my router OK using WPA2-PSK according to WiFi Manager. For reference, the Zero 2W has the same chipset as a Pi 3 and Zero W, so those 3 should all behave the same

Just tried it again to make sure. ‘Connection refused’ almost immediately after clicking connect. Works if encryption is disabled on the router. Also fails in the same way on my phone hotspot.

Whereas Zero W and Pi 3B both work fine.

What does *WBWInfo say is the chip? Should be a 43438 but I suppose it’s possible there are variant Zero 2W’s out there – the date code on the top of the main processor chip on mine is week 40 of 2023, and the PCB just says ©2021 on the back.

Or, perhaps more insightful for you: do the Zero W/Zero 2W/3B all report the same chipset as expected?

What does *WBWInfo say is the chip? Should be a 43438

Shows the same chipset as RPi Zero W and RPi 3B. The date code on the Zero 2 W is a bit worn. Think it’s week 04 of 2021. Got it a few days after it was released. (Nov 2021).

*wbwinfo WLanBW interface statistics

Type 8035 (AddrLvl 01, ErrLvl 00) handler=(fc3a2924/300035a4)
Type 0806 (AddrLvl 01, ErrLvl 00) handler=(fc3a2924/300035a4)
Type 0800 (AddrLvl 02, ErrLvl 00) handler=(fc3a2924/300035a4)


What does *WBWInfo say is the chip? Should be a 43438

Shows the same chipset as RPi Zero W and RPi 3B. The date code on the Zero 2 W is a bit worn. Think it’s week 04 of 2021. Got it a few days after it was released. (Nov 2021).

After a bit more mining of the Pi forums, it seems that there are some pandemic era Zero 2W’s which were made with a different rev chip which still reports itself as a 43438 despite being different to the “other” 43438, which probably accounts for the difference you observe. I’m not volunteering to desolder the tin can off the top of mine to see which is fitted, sorry.

Could you download this firmware and place it in !Boot.Resources.Firmware.WLanBWFM overwriting the same named file which mentions 43436 (go figure!). Power cycle so it gets reloaded. Any different?

It’s a little outside the scope of this thread but I just updated RO on a SD card I’ve been using to 5.31. Newest HD4, newest ROM and newest Pi bootloader files. I updated a version that was a month or so old that had WiFi. I had to install the separate WiFi driver after the other updates this time around because something seemed to be silently failing. It could see the 2.4Ghz, not the 5Ghz, and had that timeout failing issue. After using those drivers it worked. this is on a Pi 4.

I tried to use it on my Pi Zero W just because. It seems to be in a boot loop. It does the boot text with splash screen, and the other screen with all the modules loading. It’s very quick and just goes back to the splash screen again to repeat the loop. I can escape out of it and RO loads, not that it’s much use. I can hit scroll lock during the module load and see that the loading the module for the broadcom ethernet (rightly) fails. before I put the SD card in the Zero W I made sure I made sure ethernet was disabled in the network configure. I don’t know if it’s the issue because it wasn’t the last module loaded, but I thought I’d mention it because I thought that the module wouldn’t be loaded on reboot.

is there some way I can do a “one shot” logging of startup that doesn’t overwrite itself with subsequent reboots?