Compute Module 4

I have tried running RISC OS on the CM4.

The Lite version uses the SD card slot on the IO board and (apart from referring to it as SDFS::4 rather than SDFS::0 which needs a very small blob of solder in the right place to sort out as this decision is made by looking at an unused GPIO line, given that the revision codes of all the CM4 variants are the same) works up to a point. There are occasional errors which I have not yet pinned down – I can’t get networking to work for example.

The version with eMMC starts up in RISC OS in supervisor mode (after writing the 5.28 SD card image and 5.29 rom to the on-board eMMC, another bit of hand to hand fighting with Windows 7) but the filecore partition is not fully seen by RISC OS. There is a drive icon marked :4 but it is seen as empty. It reads SCSI pen drives OK and runs software. There are, again, occasional errors (including an abort on data transfer at &2000453C after displaying the supervisor prompt). The eMMC uses an 8-bit eMMC2 interface which is said to be much faster than the SD card slot.

Haven’t tried the real time clock (PCF85063AT) on the IO board as I do not have a battery yet. One thing it will do is to wake up a CM4 that is frozen: enable the timer function at say 120s, and also enable the timer interrupt. Every 90s reset the timer from the CM4. If the CM4 is frozen, the timer would eventually reach 0s, triggering the Global_En and forcing a hard reset.

Nice start Chris,
I have a couple of CM4, but still no board to try them, so will have to wait to start playing with RISC OS on it, but it’s an interesting start, thanks for the info! :)

The Lite version

sometimes starts up with the displayed mouse pointer fixed at the centre of the screen, usually showing an hourglass, sometimes though it starts up correctly. In both cases the mouse moves OK and works but things are a bit tricky if you don’t know where the pointer is.

occasionally (about 1%) starts up with an abort on data transfer at &2000453C (offset &453C in RMA) and the splash screen shows only that error in the small black window. The CM4 revision number is A03140.

On a good day I get:

RISC OS 960MB

Cortex-A72 Processor
Piccolo Systems SDFS
Boot:Choices.Boot.PreDesk.Alarm

Boot:Choices.Boot.PreDesk.ARPlayer

Boot:Choices.Boot.PreDesk.CPUSetup

CPU Setup: Enabling legacy ARMv5 compatibility mode for old software

Boot:Choices.Boot.PreDesk.DALimit

Boot:Choices.Boot.PreDesk.PrintPDF

Boot:Choices.Boot.PreDesk.SetupNet

Contacting DHCP server for Broadcom GENET interface

Repeat: Internal error: abort on data transfer at &2000453C

Boot:Choices.Boot.PreDesk.Configure

Boot:Choices.Boot.PreDesk.Fat32FS
*fx 0
RISC OS 5.29 (09 Jan 2021) (Error number &F7)

the Lite version

Not getting that far, here.

Gets as far as a black screen with Abort on data transfer at &2000477C (which is in the Module area)

Last module that gets loaded is SDIODriver. *Desktop will take it to the desktop, but with only the Resource filer, Display manager and Task Manager on the icon bar.

Unfortunately it all seems to have gone quiet on CM4 with no evidence that anything is being done.

I’m abroad at this moment so I don’t know if the compute module and IO board have arrived yet.

Got it going with 5.29 – some issues, though, mainly networking. Has to be set to DHCP or it crashes on startup if set manually. Have to boot without the cable plugged in, then use Raik Fischer’s NetCheck to kick the network to rerun the DHCP to get an IP address and set the Gateway. Seems fine after that. Did accidentally run it at 2.14GHz for a couple of hours before I realised, and it only go to 56C CPU temp, just sat on a mousemat, not in a case.

Couldn’t get the WIFI HAT to work – didn’t crop up in Interfaces, or illuminate its LEDs. All the right software is installed correctly. GPIO module is Active.

Mine is a 4GB Lite version. SD card shows as SDFS::4 but I can live with that!

My understanding of the CM4s is the PCIe bus is tracked out. Can RISC OS talk to that?

My understanding of the CM4s is the PCIe bus is tracked out.

Correct.

Can RISC OS talk to that?

Kinda. There is PCIe support in the HAL/ROM, but currently there’s no code to probe for devices (the HAL’s hardcoded for just the Pi4 USB3 controller).

Presumably it won’t be too hard to add the necessary probing code to allow arbitrary devices to be exposed to the OS (although I’ve got no idea how complicated things become once you start adding PCIe switches into the mix)

although I’ve got no idea how complicated things become once you start adding PCIe switches into the mix

ISTR that PCIex multipliers/multiplexers/switches work more or less transparently, i.e. for the “user” (the OS) it just looks like multiple slots/devices, whatever is connected. A bit like S-ATA port multipliers.

Wasn’t it already the same with the IYONIX PCI subsystem? I think it was based internally on PCI-X on XScale SoC level, and had a PCI-X-to-PCI-bridge to provide the multiple slots.

Using a 4GB 32Gb eemc wifi compute module. Couldn’t get it to usb boot using the built in USB ports.
Plugging in a PCI 1x USB VL805 chipset card into the 1x slot, USB boot worked using these ports. Rapsberry Pi OS boots OK using the onboard USB ports.

There’s an extra ‘:4’ icon on the icon bar. Just gives ‘The disc drive is empty’ when clicked on. Assume this is the built-in emmc module.
The RTC doesn’t get picked up. IICdevices shows nothing.

Over clocking to 2.2GHz runs stable with passive cooling. Higher than this gets unstable or fails to boot even with active cooling.

Everything else seems to work fine. No problems with the network or booting/stability.

I have just received my 4GB/32GB emmc/WiFi CM 4, so I now have a 1GB/Lite/No Wifi CM4 and a 1GB/32GB emmc/No Wifi CM4 as well as 2 IO boards.

On both Lite and emmc boards, the SD card icon appears as drive :4 (this also happened on CM3 but Rob found where to drop a blob of solder on an unused GPIO line so that RISC OS could discriminate and show the SD card as :0 or :4, also to supply a binary blob to do the same thing – I suspect that these GPIOlines have been utilisied for something else on CM4).

I understand that on the Lite models, the mouse pointer freezes on three start ups out of 4. The mouse position does move, just not the pointer, making it a bit difficult to see what you are clicking on.

On the eMMc models, I understand it uses an 8 bit data bus and eMMc2 and so the on board eMMc is not ‘seen’ by RISC OS. You can’t use the SD card on the IO board as the lines are used for the eMMc.

Also the RTC chip is connected to a different IIC bus.

After discussion at the virtual Wakefield show, I raised (on advice from ROOL) these issues on the ‘Bug’ tab on the forum so that someone more knowledgable could raise a Bug ticket.

Unplugging SDIODriver gets rid of the spurious ‘:4’.

On the Lite models, the :4 is, of course, not spurious (it should be :0 but hey ho).

I’ve now added a VL805 PCIe board the Compute Module IO board, and this has resolved issues of the network not working, and the mouse pointer not moving even though the mouse was. The mouse is still plugged into the onboard USB 2 port.

Seems to function like a normal Pi 4 now. Apart from the SD card being drive 4.

The ‘light’ module seems to be the best for over-clocking.

Runs stable at 2.4GHz passively cooled with the following in config.txt,

[cm4]
hdmi_enable_4kp60=1
enable_gic=1
arm_freq=2400
over_voltage=10

At present I am running my 4GB/WiFi/32GB CM4 at 2000MHz (no cooling, running at 63 deg C) and have updated the benchmarks. I shall be trying the Lite version (1GB) later this week.

The CM4 is currently the fastest machine on which to unpack (18s) and compile (2m46s) a Pi ROM using RAMfs. Disc storage speeds (using a USB to SATA convertor and a 120GB SSD) not quite so good as Titanium (direct SATA) by a factor of about 4 or 10 but hopefully Ben may get eMMc working.

I now realise that I had included

over_voltage=6
arm_freq=2000

accidentally in the config.txt for my CM4 so I have updated my benchmarks to show results for a CM4 Lite with no overclocking as well as the CM4 with eMMc overclocked to 2000MHZ. This does introduce a bit of controversy as the temptation is to offer a machine overclocked quite heavily but which runs hotter. Gets good press but the Pandaboard that I overclocked to 1500MHz just died on me after a few months.

The storage speeds quoted for ‘hard disc’ is my choice (listed at the foot of the table) for what medium proves to be both reliable and fast. A Crucial SSD attached to USB via a Crucial USB to SATA adapter seems to work well (write speeds are faster than read as it has on-board RAM buffering), only the native SATA of the Titanium and ARMX6 seem to beat it (VRPC benefits from fast m.2 SSD drives on a PC).

Storage speed for RAMfs gives a good idea of the maximum storage speed that RISC OS and the filecore filing system can offer when there is no physical medium – i.e. just showing the overhead of the file operations with an infinitely fast storage medium. I don’t know why reads from RAMfs are three times slower than writes for file save/load operations.

By clicking on the ‘Show’ and ‘Hide’ buttons you can directly compare two particular machines. If you compare the nominal and overclocked CM4 you can see the extra processor speed makes very little difference to to disc speeds.

I am a little suspicious of fat32fs as I have found that it errors when compiling a rom which SCSIfs and SDFS do not (using the identical DDE and rom source). It offers faster speeds on some drives but is not so reliable. Fat32fs also has problems when accessing smaller drives (FAT16 formatted?) failing to read subdirectories that SCSIfs handles correctly via DOSFS. A SCSI drive with FileCore and FAT partitions will only see the filecore partition if fat32fs is RMKilled.

ROOL do not ‘curate’ fat32fs so reporting bugs on the ROOL bug tracker for fat32fs does not work.

The ROM compiling issue with FAT32FS is not on the FAT32FS side but in the build tools (it expect directory content to provided alphabetically order, which is only true for Filecore based FSes). See my post here and a fix that was proposed even earlier by Timothy Baldwin as a consequence of his work on “RISC OS on Linux”.

If anyone has a neglected and underused Compute Module 4 Lite, you’ll definitely be wanting to pop along to our stand at the SouthWest 2023 Show. But be FAST.

Good news – the DS3231 RTC chip is compatible with RISC OS.
Bad news – the chip on the IO board is PCF85063.
Bad news – it is at IIC address &51 (I think) on bus 1 rather than &68 on bus 0 so RISC OS does not see it.

I am trying to control the fan on the IO board which uses an EMC2301 PWM chip at address &2F on IIC bus 1 (i.e. the i2c_vc bus rather than bus 0 which is the i2c_arm bus). Address &30 on that chip is used to read or write the fan speed (00..80..FF in eight steps from off to half to full speed).

The following code says there is only one bus on the CM4 but this is wrong? My code returns an error as below, please help.

>LIST
   10REM >TestFan
   20:
   30REM Check number of IIC buses
   40SYS "OS_ReadSysInfo",14 TO nob%
   50PRINT "There are ";nob%;" buses"
   60DIM mem% 80
   70flag%=(1<<24)
   80read%=(&2F<<1) OR 1
   90write%=(&2F<<1)
  100REM Fan controller on IO board is at &2F on bus #1
  110:
  120REM Read fan speed
  130!mem%=write%
  140mem%!4=mem%+40
  150mem%!8=1:REM write one byte - select chip register &30
  160mem%?40=&30
  170mem%!12=read%
  180mem%!16=mem%+50
  190mem%!20=1:REM read one byte
  200mem%?50=&77
  210SYS "OS_IICOp",mem%,flag%+2:REM two transfers in mem%
  220PRINT "Fan speed (8 steps 00..80..FF) is ";mem%?50
  230REM Now set fan to half speed
  240!mem%=write%
  250mem%!4=mem%+40
  260mem%!8=1:REM write one byte - select chip register &30
  270mem%?40=&30
  280mem%!12=write%
  290mem%!16=mem%+50
  300mem%!20=1:REM read one byte
  310mem%?50=&80
  320SYS "OS_IICOp",mem%,flag%+2:REM two transfers in mem%
>RUN
There are 1 buses

Parameters not recognised at line 210
>

Yeah, about that.

I think you might need to bash the hardware directly.
RISC OS sets up the one bus it uses and ignores [any|every]thing else. :/

So the documentation for OS_IICOp is wrong then. Curses!

No, it’s correct. It’s just that when it says about IIC buses present on the system, it’s referring to what RISC OS can see rather than what’s actually physically there. ;)

It seems odd that the Pi builds don’t support two buses. Wasn’t there an issue a (long) while back when the IIC bus (that RISC OS uses) was moved from one port to the other?

I mean, come on, the Pi4 supports six IIC ports (or six UARTs, or six I2S ports, or various combinations of the above).

So the solution may be to do a bit of wiring on the IO board so that the fan controller is actually connected to the SDA and SCL lines on the GPIO pins rather than those on bus 1?

If the IIC bus #1 is not being used (it has to be specifically enabled) then just connecting SDA1 to SDA0 and SCL1 to SCL0 would make the RTC and fan controller accessible to RISC OS. The options to enable the CSI and DSI (SDA/SCL not connected at the headers) would have to be left unenabled. I’ll try connecting J6 pins 2 and 4 to pins 5 and 3 on the 40 pin header …. but I get no acknowledge …