RPi CM4 lite* NVMe build

Is it now possible to buy a RPi computer module 4 lite, IO board, and NVMe SSD and build our own RISC OS systems? If so has anyone done this and documented the process of setting everything up?

It absolutely is! https://www.pihard.co.uk

To my mind, the advantage of NVMe is the small footprint, so I’d tend to avoid the Pi IO board as it’s quite big and doesn’t lend itself to smaller systems. There are plenty of other boards out there that serve the purpose better, are cheaper, and more readily available.

Yes, but the DIY solution is not straightforward.

There is a bug (#611) with SD cards larger than 16GB. A fix has been tested but is not yet in daily roms. You also need start4.elf and fixup4.dat from after 29 Feb 2024 for the fix to work.

I have done a talk to ROUGOL in February and there are some notes here

The Waveshare IO board is available in two versions – Mini-A (without fan controller/RTC) and Mini-B (with fan controller and RTC) but these are not accessible to RISC OS. Both have an M.2 NVMe slot underneath for 2230 or single-sided 2242 drive. No access to ‘RUN’ pin. A separate PCB is needed to carry a fan controller and RTC that RISC OS can ‘see’.

The Pi Foundation IO board is rather larger and needs a PCIe to NVME adapter, which will take drives up to 2280 (80mm long).

The GeekPi DeskPi Mini (aka PiRO Qube) has a built in fan which is controlled by CPUClock but no RTC accessible to RISC OS. You need to plug in a RTC to the 40 pin header but the header points the wrong way so you need a custom PCB (which I have designed and will be selling at the Wakefield show if all goes well). It has a fitting for 2242 only but can accommodate double sided drives.

HDForm can now format NVMe and an open source NVMe driver is available for RISC OS. PartMan will soon be able to create the ‘2-partition’ disc format (the FAT partition is used for the Linux kernel) and then you can add a Linux rootfs partition (using Linux).

Not all NVMe drives work with the RISC OS Bits drivers.

The DIY solution using the DeskPi is not much cheaper than the fully assembled and tested PiRO Qube from RISC OS Bits.

There is a bug (#611) with SD cards larger than 16GB. A fix has been tested but is not yet in daily roms. You also need start4.elf and fixup4.dat from after 29 Feb 2024 for the fix to work.

I can confirm the same is true for the TuringPi 2 where the CM4 has to be plugged on a dedicated SO-DIMM module that offers the SD I/O. However when taken care of the bug it works. CM4 on the Turing Pi does NOT support NVMe, so don’t bother with it (nothing to do with RISC OS). I use an RK3588 sharing an NVMe disc on a cluster (via NFS and SMB).

Side note for the the Turing Pi 2: RISC OS image also needs to be modified, can’t be used as is. So, I am thinking of releasing a “Cluster orientated” distribution soon (probably October this year), if there is enough interest. Which boots into a cluster node instead of a RISC OS Desktop as the vanilla does.

Apart from that, CM4 seems to be working fine with latest builds. I had 3 CM4 on a Turing Pi 2 running RISC OS at the RISC OS Show in Bristol few weeks ago.

There is a bug (#611) with SD cards larger than 16GB.

Because there are issues with the SD card slot and the current OS5.29 builds I went for an eMMC equipped CM4. (I think RISCOSbits can side step that with a custom ROM for their products.) The IO board is from Waveshare. The NVMe is noticeably vertical in a PCIe carrier

It works just fine. There is a bit of learning curve required to flash the eMMC, but that is all part of the fun.

The CM4 is RISC OS only, the HD4 image and firmware partition are on the eMMC as the NVMe is to be considered as alpha for now, though there have been no issues here. (The faster Pi5 is available for Linux duties while it awaits its RISC OS image.) No dual booting or partitioning is thus required, keeping it simple.

The IO board is big, but the CM4 is passively cooled so any fan issues are avoided, plus I do prefer fanless. The illustration shows the CM4 alongside an Pimoroni NVMe Base equipped RPi5, which has a particularly inaudible fan. (It has to said that the RPi5 and NVMe board was ‘rotten fiddly’ to put together.)

With images on fixed drives some consideration can given be to boot order to enable recovery should something unfortunate happen.

(I think RISCOSbits can side step that with a custom ROM for their products).

We do for FAST because that needs the drivers to be built into the ROM to be able to boot from it. With the NVMe work, we purposely avoided custom built ROMs so that people could just use the nightly builds. And we opted for eMMC CM4s for a few reasons: speed, robustness as opposed to SD cards, and bug #611! It also worked out about the same price to get hold of a 32GB eMMC CM4, than trying to source the one variant of SD card that seemed to work around Bug #611!

And now ROOL have started to incorporate our driver into the source, and ultimately into the nightly builds, that will make things much easier, and booting from NVMe will then be built in by default.

There is a bit of learning curve required to flash the eMMC

Isn’t there just! This initially put us off doing too much work to make FAST work on eMMC, but this looks likely to change imminently. :-)

So this looks a good a cheap option for an IO board and case as a starting point. I can live without RTC but is there a PCB fan controller for wave share mine A board or just the B? Does RISC OS tax the CPU so much that a fan is required??

thanks for the info.

https://www.waveshare.com/cm4-io-base-box-a.htm

You definitely need a decent heatsink at the very least. Bizarrely, I’d say the CPU runs hotter under RISC OS in normal use than it does under Linux in normal use. Maxed out may be a different issue…

the CPU runs hotter under RISC OS in normal use

Running CPUClock, I’ve noticed my Pi4B seems to get ‘stuck’ at the higher end of the speed range (1800MHz here), especially after a prolonged period of continuous use (+24 hours). Usage indicates 100% idle, yet the processor continues to run at top speed. It’s not a problem, inasmuch as I now have an effective switchable fan/heatsink setup, just inexplicable. Presumably some very low level background activity is persuading the CPU to keep going flat out?

Check if you’ve run a null poll claiming application, which will stop the CPU from going idle.

Check if you’ve run a null poll claiming appkication,

Avalanche?? This has come up previously.

Check if you’ve run a null poll claiming appkication.

Which I discover how?

Avalanche??

Guilty as charged. Avalanche is launched on booting, and I have a remote PC laptop running VNC.

UPDATE: quitting Avalanche produced an immediate change in behaviour, with CPUClock regularly cycling between 600 and 1800MHz, and spending the bulk of its time at the lower frequency.
Apologies for diverting the thread, but hopefully the information will be useful generally.

Druck has some test progs that let you know what is using null polls.

Which I discover how?

Martin Avison’s TaskUsage is a good place to start.

Druck’s AppStat should also tell you.

In both cases, you’re looking for apps that are consuming processor resources when idle; in AppStat, you can click on an application to see the different sorts of events that they’re cliaming.

According to TaskUsage, Avalanche doesn’t use null polls. Iris does, and so do the associated WebKitNetworkProcess and WebKitWebProces, who even keep polling nulls after Iris has quit with or without an error message (which happens quite often).

I have just tried TaskUsage as well, and as well as Iris, I noticed Sargasso, Artworks and Hermes used null points. Hermes only used null points when connecting to servers.

According to TaskUsage, Avalanche doesn’t use null polls.

It certainly does here: AppStat shows them if you drill down into it.

Using Null events isn’t inherently evil. Using them in conjunction with Wimp_Poll (instead of Wimp_PollIdle) is, outside of some specific circumstances, and not turning them off when they’re not required is antisocial.

VNC involves very heavy network traffic, so it’s pretty much inevitable that Avalanche will use lots of null polls.

I think I understand it now (pudding brains): Avalanche does use null polls, but when idle, it doesn’t use processor power. Iris does, and a lot too!

Avalanche idles when it is first run, until it connects to a server when not unsurprisingly it runs the processor continuously at full speed. The catch is that on disconnecting from all servers Avalanche continues to run the processor at full speed when it might have been expected to return to idling. The processor stays permanently at full speed and only returns to idling when Avalanche is quit.

Avalanche … runs the processor continuously at full speed.

I have not seen that.

From what I can see here, using TaskUsage, Avalanche v0.28 uses PollIdle, with about 20 polls/sec and 0% processor when started but not connected. When connected (to a RPi4 from a Titanium) it increases to about 30 polls/sec. When there are screen changes or mouse movements it can increase to several hundred polls/sec and 10-20% processor, but it drops back to around 30 polls/sec and 0% processor when there is no activity.

Mind you, I have seen tasks becoming ‘stuck’, not reducing their polling when they should.

Incidentally, I can get no response from James’s website at http://www.effarig.co.uk/riscos/ Has it bitten the dust?

Incidentally, I can get no response from James’s website at http://www.effarig.co.uk/riscos/

Try https://effarig.co.uk/riscos/

Sorry didn’t get chance to expand on my post this morning. Using Null events with Wimp_PollIdle is OK, !APPstat that will show anything from 1 to 100 events per second. However if an application enables Null events with Wimp_Poll and there isn’t much else running, you will see thousands of nulls per second. Those are the sorts of applications you should only have running when needed if you wan to keep the CPU cool.

I’ve patched dozens of applications to use Wimp_PollIdle rather than Wimp_Poll, but someone keeps writing them!

I’ve patched dozens of applications to use Wimp_PollIdle rather than Wimp_Poll, but someone keeps writing them!

<shrug>

Unless something needs to check status constantly (like maybe a net fetch?) then there’s no point in using plain Wimp_Poll and nulls other than plain cluelessness.

It isn’t as if Wimp_PollIdle is hard to use. Just give it a time in the future and it’ll give you a null poll then (if you’ve enabled them) or any Wimp event earlier as it happens.

Like, literally:

  SYS "Wimp_Poll",, block% TO event%

can be made:

  comeback% = TIME + 500
  SYS "Wimp_PollIdle",, block%, comeback% TO event%

And instead of polling constantly, you’ll get a prod once at least every five seconds (adjust the comeback offset as you require) unless there’s something else (click, redraw, window event…) that needs sorted sooner.
[hint: Alarm PollIdles with a delay of 100 as it only needs to update the clock once every second]

I just tried this with a quick program I threw together. The basic Poll version ran about 50% processor use. The PollIdle version behaved identically (scrolling and redraws were no slower) and it used an average of 0% processor time. Indeed, it only got paged in and control handed to it when something needed done.

Which is exactly as it should be.

PollIdle, people! It’s not hard.

https://effarig.co.uk/riscos/

Yes indeed – without the www it works … shame the app help includes the www!

Poll_Idle

Agree with everything Druck & Steve F say – far too many apps were (are) lazily written with Wimp_Poll and a mask of zero.