Determining the machine type

Since RISC OS does not provide a simple API for determining the machine type, I have provided a rough and ready solution.

There are two ways to do this. The first is to use the API. For RiscPCs and earlier you can ask for the OS ID number. For the modern 32 bit systems you need to enquire from the HAL or fart around reading CPU ID directly.

The other way is to look for modules specific to each build of RISC OS. That’s what I do here. It cannot (currently) tell a Beagle from an IGEP; but it will give you a basic idea of what you are running on. And best yet, it isn’t even a program, just a bunch of commands in an Obey file!

Please note that this is a forum post so it has had zero actual testing (it’s, like, the law!).
I wrote it on an emulator and “tested” it by altering the detection code to fake other machines. It was too much bother to fire up the Beagle and Pi and copy files etc etc etc. ;-)

Possible return values, written as a string to “Machine$Type”:

• “Legacy[26]” – anything prior to RISC OS 5, and RISC OS 6.
• “RiscPC[32]” – IOMD build of RISC OS 5 on a RiscPC.
• “Iyonix”
• “Beagle/IGEP/Pandora” – can we further tell OMAP3 builds apart?
• “OpenPandora” – and anything else with an OMAP4!
• “RaspberryPi” – any version

Here’s the code – it is an Obey file:

| Cheap'n'cheerful way to determine the machine type
| without doing fancy stuff like checking the CPU ID.

| Defaults
Set HWChk$NRPi   0
Set HWChk$NBea   0
Set HWChk$NIyo   0
Set HWChk$NRPC   0
Set HWChk$NPdr   0
Set HWChk$NRO6   0
Set Machine$Type "Unknown"

| State check (relies upon modules specific to certain builds)
RMEnsure VIDC20Video   0.00 Set HWChk$NRPC 1
RMEnsure NVidia        0.00 Set HWChk$NIyo 1
RMEnsure OMAPVideo     0.00 Set HWChk$NBea 1
RMEnsure MUSBDriver    0.00 Set HWChk$NPdr 1
RMEnsure BCMVideo      0.00 Set HWChk$NRPi 1
RMEnsure UtilityModule 6.00 Set HWChk$NRO6 1

| Parse results
If ("<HWChk$NRPC>"="0") Then Set Machine$Type "RiscPC[32]"
If ("<HWChk$NIyo>"="0") Then Set Machine$Type "Iyonix"
If ("<HWChk$NBea>"="0")AND("<HWChk$NPdr>"="1") Then Set Machine$Type "Beagle/IGEP/Pandora"
If ("<HWChk$NBea>"="0")AND("<HWChk$NPdr>"="0") Then Set Machine$Type "OpenPandora"
If ("<HWChk$NRPi>"="0") Then Set Machine$Type "RaspberryPi"
If ("<HWChk$NRO6>"="0") Then Set Machine$Type "Legacy[26]"

| Anything prior to RISC OS 5, and RISC OS 6, is a legacy style 26 bit world.
RMEnsure UtilityModule 5.00 Set Machine$Type "Legacy[26]"

| Tidy up
UnSet HWChk$*

Have fun with this! (^_^)

BTW, to test-drive it, all the following to the end:

Error <Machine$Type>

and when run it’ll pop up an error box giving the detected machine type.

I guess the “OpenPandora” should be “PandaBoard”.

I agree we should have a simple API (as you noticed, I ran into this the other day). The question is, what is it useful for? It’s a multi-level API:

1. Arthur, RO2, RO3, RO4/6, RO5/HAL
2. ARM2, ARM3, ARM610, ARM710, SA110, ARM9, ARM1176, Cortex A8, Cortex A9…
3. ARMv2, ARMv2a, ARMv3, ARMv4, ARMv5T, ARMv6, ARMv7, ARMv7s, …
4. xx KB of instruction cache, yy KB of L1 cache, zzz KB of L2 cache
5. FPE, FPA, VFP2, VFP3, NEON
6. IOC+ MEMC, IOC+MEMC+IOEB, IOMD, CL-PS7500FE, IOP80321, OMAP3xxx, OMAP4xxx, BCM2835, Exynos 5…
7. A3020, Risc PC Kinetic, BeagleXM, Pandora, RaspberryPi, …
8. Motherboard version, firmware version, …

In my particular case, I need to detect that I’m on a BCM2835 with a particular firmware version. ‘RaspberryPi’ isn’t enough because they could release a Raspberry Pi Model T with a new BCM2836 that’s completely different. I don’t care about the CPU core as such, or the FP, or the name of the board.

Some of this can be scraped up from OS_ReadSysInfo and friends, but it’s quite fragmented and tortuous. Do we need some more reason codes? Or possibly something like Podule_ReadInfo where we can invent new fields without disturbing old ones?

https://www.riscosopen.org/wiki/documentation/show/HALDeviceComms_GPIO
tells you some of the boards its running on. It is updated for the Pi as well (rev 1 or 2).
I use it in the GPIO module to decide which tables of addresses are used to access the hardware.

8. Motherboard version, firmware version, …

Would this include emulator version?

We need this doing too, for us it is CPU (SOC) and board type.

SO an emulator should either return the device it is trying to emulate or the fact that it is an emulator? The original concept was that an application should require the earliest support software that it required (RMEnsure …) and this would be sufficient. Perhaps we could look at this from a different perspective. What RMEnsure statements would be required to flag up the various hurdles such as ARM3, StrongARM, XScale, ARM5, ARM6 to mark software that cannot handle future enhancements (which at present are unknown)?

The question is, what is it useful for?

Anything that takes different behaviour depending upon what platform it is running on. For instance, if I was to write some MIDI code, it would appear that input works on the Pi but not the Beagle. For doing stuff with GPIO (independent of Tank’s module) it’d need to know what the environment is. And so on.

1. Arthur, RO2, RO3, RO4/6, RO5/HAL

Well, not really. That can all be condensed to “RISC OS 5/HAL” and “everything else”. Why? Because it is unlikely we’ll be retrofitting RISC OS into older machines; especially given as the typical memory size is 4MiB which isn’t too useful for loading a ROM image of the same size. ;-)

2. ARM2, ARM3, ARM610, ARM710, SA110, ARM9, ARM1176, Cortex A8, Cortex A9…
3. ARMv2, ARMv2a, ARMv3, ARMv4, ARMv5T, ARMv6, ARMv7, ARMv7s, …

Yes, it could be worth knowing basic CPU features. I’m not sure if it should be like this exactly. Perhaps more akin to:

  block%!0 = ARM family (15-0) and revision (31-16)
  block%!4 = Processor/SoC features
               bit 0 - ARM chipset world (IOC+VIDC / IOMD+VIDC2...)
               bit 1 - is an SoC
               bit 2 - has GPU
               bit 3 - has blah blah blah...
                       (note - features related to CPU activity;
                        not whether or not it has an IDE bus...!)
  block%!8 = Mathematics assistance features
               bit 0 - No FP (using FPE)
               bit 1 - FPA
               bit 2 - VFPLite
               bit 3 - VFP2
               bit 4 - VFP3
               bit 5 - NEON
  block%!12= Device type ID (points to a defined entry)
               0 = Old style Archimedes (ARM/IOC/MEMC... all 26 bit)
               1 = New style Archimedes (RiscPC/7500-based; as 26 bit)
               2 = RiscPC
               3 = Iyonix
               4 = Beagle
               5 = Beagle xM
               6 = IGEP
               7 = DevKitThingy
               8 = RaspberryPi
               9 = Pandora
              10 = Pandaboard
              [etc]
  block%!16= Device revision ID; specific to the above type ID, so
             for a Beagle would be 0 = A, 1 = B, 2 = C and such.
             For a Pi, would be 0 = Model B rev 1, 1 = Model B rev 2,
             3 = Model B rev 2b (the 512MiB upgrade), 4 = Model A
             rev 1 (they're given in order of release). For a RiscPC,
             0 = ARM610, 1 = 710, 2 = SA (bugged), 3 = SA (good),
             4 = Kinetic... You get the idea.

Pretty much all of this can be determined by the HAL, and the information is sufficient to identify what the device is and what sort of facilities are offered.

I have neglected to include things like types of cache and MMU and what sort/size they are. I wouldn’t imagine many user programs will need to know stuff that low level, and those that do could easily-enough probe CP15.

I have also not included a specific “26 bit or 32 bit” indicator. This can be determined by a line of code, or by looking to see if the device ID is zero or one (the two 26 bit options). Though, as I said, probably having this API (in OS_Hardware someplace?) would probably indicate a 32 bit world.

Just my rough thoughts, no doubt it’d need a lot of refinement.

Would this include emulator version?

No. While some low-level stuff needs to know it is running on an emulator (HostFS etc); a proper emulator should not announce the fact that it is an emulator and instead present itself as the machine it is trying to emulate. Hidden APIs to ‘talk’ to the emulator probably shouldn’t be used in general user code; and if you know how to use such APIs, you probably already know the incantation to check for their existence (ie emulator vs real hardware).

What RMEnsure statements would be required to flag up the various hurdles

Remember to look at this both ways. RMEnsure with a version of 0.00 can tell you if something is not present, telling if something is present is more complicated (which is why my above Obey file works by negation).

Hmmm, I’ve just lost an hour of sleep time. %$£#!!!

Because it is unlikely we’ll be retrofitting RISC OS into older machines;

You mean not putting some 5V¹ TSOP 8Mb x 16 packages onto a carrier board and making a RPC a flash based OS machine?
Or was the RPC not in your older machine list.

¹ Newer packages would need level shifters on the carrier board, which would be complicated.

Or was the RPC not in your older machine list.

Did you not read the list? RiscPC is there twice. Once for 26bit world, and again for 32bit RO5+HAL world. You could make a RiscPC into a flash machine, but it’s so much simpler just to softload it!

When I say “old” machine, think ARM+MEMC – A410, A3000, that sort of thing.

Because it is unlikely we’ll be retrofitting RISC OS into older machines;

There are plans to make a Rool uniboot, if I have understood it correctly?

There are plans to make a Rool uniboot, if I have understood it correctly?

Ah, but will we be supporting the older machines? [and by older I mean the ARM2 and ARM3 machines that most likely have <=4MiB on board and would need new ROMs, and perhaps more importantly are physically incapable of running in 32bit mode].

Because it is unlikely we’ll be retrofitting RISC OS into older machines;

There are plans to make a Rool uniboot, if I have understood it correctly?

It’s already available, but requires a bit of fiddling due to the way the autobuilder is set up. Basically, you grab !Boot from the HardDisc4 download, then copy the contents of PlingSystem download on top. That should be all that’s needed, though it’s only received light (“yeah that booted to the desktop”) level of testing on anything prior to 3.70.

You mean not putting some 5V1 TSOP 8Mb x 16 packages onto a carrier board and making a RPC a flash based OS machine?

I did look into this, including a scheme where you use a serial flash (very cheap for 4MByte) hanging off a spare podule connector. But in the end, since the ROMs still exist, it was easier to just burn some ROMs – in fact I just popped today’s into a ROM socket a few minutes ago.

I did look into this, including a scheme where you use a serial flash (very cheap for 4MByte) hanging off a spare podule connector. But in the end, since the ROMs still exist, it was easier to just burn some ROMs – in fact I just popped today’s into a ROM socket a few minutes ago.

Devices big enough to hold two images (switchable) would be handy, almost unbrickable in fact.

Edit. Since a handy pile of ROMS for test after test isn’t a common feature of peoples computer rooms I suppose rewritable devices would probably be in order.

The HAL DeviceComms_GPIO can return the machine type. The official documentation lists only the OMAP3 variations, and does not mention using the CPU type to tell one device from another, etc; nor any mention of the Pi (and, I would imagine, Pandaboard).
Is this mechanism described better elsewhere (that I’ve not seen), or should this page be updated?

Additionally, who is in charge of assigning these things? The people writing the code? allocate@riscosopen? If I was to port RISC OS to <awesomely ancient and obscure hardware>, it would probably need a CPU identifier and a board ID. Is there a central repository for this sort of thing?

Rick, I mentioned this call in the fourth post, and did say that the Pi rev1 and 2 had been included. This call was added by jeffrey so that I could identify the machine for the GPIO module so it might be worth asking him about registering machines.

I mentioned this call in the fourth post,

I nodded to it in the first post (“For the modern 32 bit systems you need to enquire from the HAL”); and I know the Pi is included (<cough>thanks to your GPIO source!</cough>) – though the mechanism is not apparently documented (that a search showed up; or is it offsite?).

For instance, I had thought that each board would have a unique ID; however this turned out not to be the case with my Pi telling me it was a Beagle – your code confirms this, the CPU ID is the initial selector, with the board type extending from that.

Rick, something like what you suggested sounds sensible, though I’d suggest having lists-of-tags (IOC=0×00123456, IOMD=0×45678900, whatever) rather than bitfields, because bitfields would probably run out fairly soon. Or it could be lists of bitfields (N words until find a word with bit 31 set), though the advantage of tags is you can indicate variations (VFP2 = 0×12340200, VFP3=0×12340300, VFP4a=0×12340401, VFP4q=0×12340499).

I note that ARM Linux has a machine registry with every type of machine we’d ever be likely to run on and a ton more, so that might be a handy starter for the ‘machine ID’ field. It’s also something passed in from Linux bootloaders, which is a means for a kernel/HAL to detect what platform they’re running on.