RPi CM4 lite* NVMe build
Pages: 1 2
andrew k (267) 76 posts |
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? |
RISCOSBits (3000) 139 posts |
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. |
Chris Hall (132) 3554 posts |
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. |
Paolo Fabio Zaino (28) 1853 posts |
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. |
David Pitt (9872) 362 posts |
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. |
RISCOSBits (3000) 139 posts |
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.
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. :-) |
andrew k (267) 76 posts |
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. |
RISCOSBits (3000) 139 posts |
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… |
George T. Greenfield (154) 748 posts |
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? |
David J. Ruck (33) 1629 posts |
Check if you’ve run a null poll claiming application, which will stop the CPU from going idle. |
David Pitt (9872) 362 posts |
Avalanche?? This has come up previously. |
George T. Greenfield (154) 748 posts |
Which I discover how?
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. |
Colin Ferris (399) 1809 posts |
Druck has some test progs that let you know what is using null polls. |
Steve Fryatt (216) 2103 posts |
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. |
Paul Sprangers (346) 523 posts |
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). |
Chris Hughes (2123) 336 posts |
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. |
Steve Fryatt (216) 2103 posts |
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. |
Dave Higton (1515) 3497 posts |
VNC involves very heavy network traffic, so it’s pretty much inevitable that Avalanche will use lots of null polls. |
Paul Sprangers (346) 523 posts |
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! |
David Pitt (9872) 362 posts |
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. |
Martin Avison (27) 1491 posts |
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? |
Steve Fryatt (216) 2103 posts |
|
David J. Ruck (33) 1629 posts |
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! |
Rick Murray (539) 13806 posts |
<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. 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. |
Martin Avison (27) 1491 posts |
Yes indeed – without the www it works … shame the app help includes the www!
Agree with everything Druck & Steve F say – far too many apps were (are) lazily written with Wimp_Poll and a mask of zero. |
Pages: 1 2