Compute Module 4

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?

Yes, RISC OS selects one bus on Pi 1 and the other bus on later Pis, if I remember correctly. One solution is to select the IO board bus (iic_vc) rather than the GPIO bus (iic_arm) on the CM4 but that solution won’t work as it is a custom build rom to support SATA on CM4.

Surely just to support one bus when the RTC and fan controller sit on another bus on the IO board is sloppy programming? Are Risc OS Developments not providing sufficient oversight of ROOL’s activities? Surley ROOL’s standards are higher than this?

Surley ROOL’s standards are higher than this?

…and don’t call me Surley.

Surely just to support one bus when the RTC and fan controller sit on another bus on the IO board is sloppy programming? Are Risc OS Developments not providing sufficient oversight of ROOL’s activities? Surley ROOL’s standards are higher than this?

Perhaps you’d like a full refund?

I’m sure ROOL would be happy to receive a merge request for said functionality. And hey, it’s all open source, so the code is sitting there waiting for attention.

Surely just to support one bus when the RTC and fan controller sit on another bus on the IO board is sloppy programming? Are Risc OS Developments not providing sufficient oversight of ROOL’s activities? Surley ROOL’s standards are higher than this?

Luckily, RISC OS is Open Source, so you’ll be able to submit a fix showing them both how it should be done.

Gosh, so much sarcasm! Isn’t there a good reason to support both IIC buses rather than just do a fudge? I don’t know how to bring up the second IIC bus in the HAL but now that a good reason has been identified (IO board RTC and fan controller use bus #1 not #0) can this not easily be added in the next revision? Once support for the second bus is added in the HAL then the existing OS_IICOp SWI would just work.

Gosh, so much sarcasm!

We’re mostly British. ;)

rather than just do a fudge?

Probably originally there was no real need for anything more than communicating with an RTC, so what was done was “good enough”.

can this not easily be added in the next revision?

Presumably, but if you’re using bus 0 (from the point of view of the Pi, not RISC OS), I should point out the official recommendation:

It… probably shouldn’t be using that bus at all, but there you go. :/

Further to the points people have made. It was highlighted at one of the meetups that one of the least spoken about reality of the open-source community is that it is partly driven by those companies making money from it which hadn’t occurred to me. I’d always viewed it from the FOSS perspective.

about reality of the open-source community

It’s actually pretty obvious when you think about it. Certain open source products have full time developers. Well, if nobody pays for the product, who pays the devs?

That’s partly why RISC OS development is so slow – much of this is being done by people as a labour of love outside of their normal paid work.

It’s also why the stack issue is a disappointment to me. Granted, somebody paid for the ROD stack outside of the bounty scheme, however given our scarce resources (user base, etc etc all in diminishing numbers), I can’t help but feel that we should be embracing every bit of help that comes along. We have, now, a functional modern IPv6 stack with replacements for the binary blob parts, and support for things like WiFi on the horizon. Just think of all of the other things that need attention, rather than… a second stack. Bluetooth, for example? Or the perennial problem of what to do with the other three cores that most machines have. My personal belief is to leave RISC OS as single core (too much would be broken otherwise) and run the others like the Tube. But, lack of time, resources, and most of all money mean that whatever happens happens very slowly.

Because, sadly, all the good ideology in the world doesn’t pay the bills.

While I’m on a soapbox, I’d like to also say that we should be taking Pyromaniac seriously.
Sure, it’s limited in its abilities at this point (being aimed more at debugging than full emulation), but it’s a remarkable achievement that demonstrates an alternative to emulating a machine that’s nearly thirty years old.

32 bit ARM is on the way out. That doesn’t mean capable hardware will vanish overnight, but enough important things (Linux, Android…) have made the transition that there is less and less justification for having 32 bit in silicon at all.

The writing is on the wall, guys, and no, there isn’t going to be a port to 64 bit (certainly a number of people seem to think it can be done keeping the existing API which is ludicrous) because time, money, resources…the old refrain. ;)

The viable future for our preferred platform, once hardware dries up, is going to be emulation. Whether on ARM64 or on something else.

Pyromaniac may well be the answer we didn’t know we needed.

A rather pessimistic view .

There are many peaple still using RISC PCs today.

In the same timespan, I and others will still be using todays harrdware. In my case, the Raspberry Pi.

Probably originally there was no real need for anything more than communicating with an RTC, so what was done was “good enough”.

I completely agree. Meanwhile I shall pursue a hardware solution with a CJE RTC board on the GPIO header (which will ‘just work’) plus a fan control board (Adafruit EMC2101 I2C PC Fan Controller and Temperature Sensor) soldered to the side of it to control the fAN. That should give a variable speed fan and RTC on the CM4/IO board sitting on the only IIC bus that RISC OS can see. With a hardware solution for a few pounds, the argument to spend time on programming is weak.

It is recommended that you only use i2c_vc and i2c_vc_baudrate if you really need to […]. Enabling i2c_vc can stop the Raspberry Pi Camera or Raspberry Pi Touch Display functioning correctly.

Of course this does not really apply to RISC OS where these don’t work anyway. Perhaps the Pi Foundation should have listened to their own advice when designing the IO board!

A rather pessimistic view .

True, but more realistic than thinking a 64 bit version can be rolled out anytime soon (“soon” being measured in decades).

There are many peaple still using RISC PCs today.

Sure, the existing hardware won’t go away, but it’ll reach a sort of roadblock point, like “this is as far and as fast as you can go”.

Besides, with the skyrocketing price of electricity, ditching the power hungry big machines (like the RiscPC) for something like the Pi makes sense. In terms of memory, processing speed, screen resolution, colour depth, and the ability to use modern storage like flash drives and SD cards, the lowly Pi delivers an effortless curb stomp battle.
Plus, aging hardware, failure modes, harder and harder to get replacements (some day even CJE won’t have it in stock).

But looking to the past and using today’s hardware doesn’t really make inroads into tomorrow. Imagine where we’d be if the latest available machine was the Iyonix? We got really lucky with the Pi.
What’s tomorrow?

should have listened to their own advice

Yup.

With a hardware solution for a few pounds, the argument to spend time on programming is weak.

;) On the other hand, when it’s done once it’s done for everybody.

Plus, aging hardware, failure modes, harder and harder to get replacements (some day even CJE won’t have it in stock).

I can tell you, stocks are steadily decreasing, but the demand for them is still there!

Imagine where we’d be if the latest available machine was the Iyonix?

With it’s dodgy motherboard I’m constantly surprised there’s any out there still working (semi) reliably!

Hello all,
I had not noticed this thread so far but have just read it all with interest. I bought a CM4 IO board over a year ago and it has been waiting for a CM4 Lite module all this time. This arrived last week and I have been having very similar troubles in getting 5.28 working reliably. With DHCP selected I can get about 70% successful boots, but with unique IP address, only about 10%. When I get the bootup error, sometimes this can be escaped from and then the system works completely correctly. Is work in progress behind the scenes to get this IO board fully compatible or do we have to adopt some of the measures described above.
Thank to Chris H. for your sterling work in this regard.
Kim

The trick for now, is to plug something/anything into the PCIe slot (well, not anything, but something that should go into the PCIe slot). This could be an NVME drive, a USB 3 card, or better still a fully functional SATA card. It will then pass by the network issues every time. And you get the added advantage of it being probably the fastest RISC OS computer to date!

Again, more information discovered by Chris H.

The credit for the discovery must go to Rob Sprowson. He has identified that the PCI Manager assumes there is something connected to the PCIe slot (as it is a Pi 4 and that has USB sockets connected) tries to cache the vendor IDs, during boot just after the DHCP process, and, if there is nothing there, aborts almost silently. A fix has been identified as of today.

After the abort the network is flaky, the mouse may freeze but these are all consequential.

Daily roms after 1 Feb 2023 can also handle eMMc if you have a CM4 with eMMc.

If you have a revision 1 CM4 (code A03141/B03141/C03141/D03141 for 1/2/4/8GB of RAM) then there is a fix for that also in the pipeline. Most CM4 are revision 0 (code A03140/B03140/C03140/D03140). Symptom with rev. 1 is GPIO module being dormant rather than active but IIC still works. The utility !ScrnHelp from !Store will show the revision code.

Thank you both for this most useful information. I have ordered a PCIe card which will arrive in a few days. For now, the system has been put to one side as I need my workbench space for something else. At the moment I cannot determine which CM4 revision I have, but will look again and report back after the board has arrived.
Thank you.

The part number on the box tells you whether it has eMMc or Wifi. Both the part number and the revision code tell you how much memory it has. The revision number may be either ending in a 0 (revision 0) or a 1 (revision 1). There is a fixed rom that will work with the PCIe slot empty and both revisions but not yet available on line.

The trick for now, is to plug something/anything into the PCIe slot (well, not anything, but something that should go into the PCIe slot).

The bug that caused this (the PCI Manager aborting when it looked for the USB sockets on the PCIe bus) has been identified and a fix submitted – the work around was to ensure something was plugged into the PCIe slot.

A fix for revision 1 CM4 boards has also been submitted (symptom is that the GPIO module remains dormant). Both fixes are in ROMs built after 11 Jun 2023.

The supply of CM4 appears to be easing as one CM4 on ebay went for (just) less than the official price. The one puzzle I am still trying to understand is that the CMOS file datestamp in Loader is changed during start up. Not sure if this only occurs when its checksum is wrong (which also leaves SDCMOS dormant).

The eMMc/SD Card storage are seen correctly as SDFS::4 and SDFS::0 since 1 Feb 2023, so boot correctly with SDFSDrive set to 4 and 0 respectively.

Testing shows:
Revision   Part No      Ordered   IO board    ROM          EEPROM       SDFS     SDFSDrive  Stack      CM4 description
A03140    CM4001000    09-Nov-2020   WS-B    31-May 2023*  02-Oct-2020   :0        0         ROOL      1GB Lite No WiFi
C03140    CM4104032    12-Jan-2021   WS-B    01-Feb-2023*  16-Feb-2021   :4        4         ROD       4GB 32GB eMMc WiFi (freeze with empty Ethernet socket - WIP)
A03140    CM4001032    03-Nov-2020   Pi-C    01-Feb-2023+  02-Oct-2020   :0        0         ROOL      1GB 32GB eMMc No WiFi (SDFS drive wrong) 
D03141    CM4108032    26-Feb-2023   Pi-C    01-Feb-2023+  26-Apr-2022   :0        0         ROOL      8GB 32GB eMMc WiFi (GPIO dormant, SDFS drive worng)
D03141    CM4108032    26-Feb-2023   Pi-C    31-May-2023+  26-Apr-2022   :0        0         ROOL       ditto  (GPIO active, SDFS drive wrong)
B03141    CM4002000    31-May-2023   Pi-C    31-May-2023   26-Apr-2022   :0        0         ROOL      2GB Lite No WiFi (GPIO active)
C03141    CM4004008    02-Jun-2023   WS-A    31-May-2023   11-Jan-2023   :0        0         ROOL      4GB 8GB eMMc No WiFi (SDFS drive wrong)
C03141    CM4004008    02-Jun-2023   WS-A    12-Jun-2023   26-Apr-2022   :0        0         ROOL      4GB 8GB eMMc No WiFi (SDFS drive wrong)

For simplicity, each CM4 is on a separate IO board, so no swopping around! It is confusing enough as it is!
    
A - Waveshare Mini-A IO baord
B - Waveshare Mini-B IO board
C - Pi Foundation IO board
* - dual boots into Linux on NVMe
+ - dual boots into SATA FAST

Updating EEPROM firmware to Jan 2023 seems to cause eMMc to be reported as SDFS::0. EEPROM dates added above – older than Feb 2021 or newer than April 2022 seem to get SDFS drive wrong…

Another theory gone west. Perhaps it correlates with presence or absence of WiFi? SDFS::0 is default, seen as :4 if WiFi fitted?

That too is wrong. It is only on the waveshare IO board that eMMc shows as SDFS drive 4. On the Pi Foundation IO board it shows as :0 whether eMMC or SD card. I had been fooled by a bit of software that caused SDFS::0 to show as a hard disc using OmniDisc.

Is there any way to read the status of the signal ‘SD_POWER_ON’ which comes out of pin 75 on the CM4 socket and goes to the switch IC (pin 4). It tells the switch IC whether to provide power to the SD card slot on the IO board (power off if eMMc, power on if SD card).
There may be a magic number for the mailbox property interface or it may be a GPIO line that is not normally used.

One possibility is tag 0×00020001 get power state from here

Get power state (tag 0x020001)

    Tag: 0x00020001
    Request:
        Length: 4
        Value:
            u32: device id

    0x00000000: SD Card
    0x00000001: UART0
    0x00000002: UART1
    0x00000003: USB HCD
    0x00000004: I2C0
    0x00000005: I2C1
    0x00000006: I2C2
    0x00000007: SPI
    0x00000008: CCP2TX
    0x00000009: Unknown (RPi4)
    0x0000000a: Unknown (RPi4)

    Response:
        Length: 8
        Value:
            u32: device id
            u32: state
        State:
            Bit 0: 0=off, 1=on
            Bit 1: 0=device exists, 1=device does not exist
            Bits 2-31: reserved for future use

Response indicates current state.

Perhaps something like:

   10REM >Test
   20DIM buf% 3000
   30b%=0:REM or 9 or 10
   40a%=FNask(&20001,4,b%,8)
   50IF a% THEN
   60  PRINT "Status is: device id=";buf%!20;" flags: bit0 (off/on) bit 0 (exist/not exist)":buf%!24  
  
  110ELSE
  120  PRINT "No power data read - flag%=";flag%
  130ENDIF
  140END
  150:
  160DEFFNask(tag%,lrq%,req%,lrs%)
  170LOCAL ERROR
  180flag%=0
  190buf%!0=232  :REM Buffer size
  200buf%!4=0    :REM buffer request/response code
  210buf%!8=tag% :REM &40003 - Get physical display width height
  220buf%!12=lrs%:REM value buffer size
  230buf%!16=lrq%:REM value length
  240buf%!20=req%:REM send/rec value
  250buf%!24=0   :REM send/rec value
  260buf%!28=0:REM buffer end tag
  270ON ERROR LOCAL flag%=2
  280IF flag%=0 THEN SYS "XBCMSupport_SendTempPropertyBuffer",buf%,buf% TO ;flag%:IF (flag% AND 1)=0 THEN flag%=0
  290RESTORE ERROR
  300IF (flag% AND 1) OR flag%=2 THEN =0 ELSE =buf%+20

But this just returns id=0 (SD Card) device exists power on, id=9 device exists power off and id=10 device exists power off on both SDFS::0 and SDFS::4

There is now a documented way of discovering whether the CM4 has WiFi and/or eMMc fitted. The command vcgencmd otp_dump will show both revision code (at word 30) and extd revision code (at word 33). For the CM4 bits 31 and 30 of word 33 indicate whether WiFi (bit 31) or eMMc (bit 30) are fitted (zero = fitted). This can be used to decide whether the SDFS drive should be 0 or 4.

I am trying to work out how RISC OS decides whether SDFS storage is ‘fixed’ (:4) or ‘removable’ (:0) and it seems to depend on IO board and CM4 type as well as (possibly) EEPROM version and RISC OS version. I am trying to work out whether there is a ‘sweet spot’ rom that gets it right.

* – cannot use later version as it won’t read the SD card

storage is ‘fixed’ (:4) or ‘removable’ (:0)

Is this not largely an anachronism of the past? USB (SCSI) for example, could be flash drives or harddiscs (both of which are technically removable even if they’re used like a fixed disc). SDFS could be MMC modules or SD cards. And so on.

Perhaps these days it’s best to start at :0 and just count up, with no more removable/fixed distinction?

[the exception being ADFS on a RiscPC – old machine, old ways…]

Perhaps these days it’s best to start at :0 and just count up, with no more removable/fixed distinction?

That’s the sort of thing that uncovers all the assumptions about which drive is what.

Bit like how every Windows machine has A: as the floppy and C: as the harddrive… except if you stumble upon an NEC PC98 style machine where A: is the harddrive.