CMOS settings

I am trying to understand the intended behaviour of the various ‘emulations’ of CMOS battery backed non volatile RAM that is required prior to booting RISC OS (so that, inter alia, it knows where to boot from).

The module SDCMOS is present in certain builds (e.g. Raspberry Pi) where an unmodified machine is unable to load both a ROM image and a CMOS setting file into memory before starting the RISC OS image.

When RISC OS starts, it checks each of the possible options in turn:
1.if there is an IIC-connected hardware CMOS dongle then load CMOS settings from there, if not CRC-validated, restore to default;

2.otherwise look in nearby memory for a CRC-validated block of CMOS settings, if there is, use it and assume that it is on the SD card FAT partition called $.CMOS;

3.otherwise if the SDCMOS module is there then look for CRC-validated block of CMOS settings in the ROM image itself and/or in SDFS::0.$.!Boot.Loader.CMOS and/or in SDFS::0.$.CMOS noting which;

4.look to see if DELETE is pressed and, if so, clear CMOS to default

Have I got the heirarchy correct please? Some of these different behaviours are conditioned, I think, by different entry points into the ROM itself which are carefully arranged by the different firmware.

As part of the starting up process, the time is set from the configured method; NetTime; the last shut-down time; 1970 so that (unless all of the first three methods fail) it will not end up as 1970.

When RISC OS starts, it checks each of the possible options in turn:
1.if there is an IIC-connected hardware CMOS dongle then load CMOS settings from there, if not CRC-validated, restore to default;

2.otherwise look in nearby memory for a CRC-validated block of CMOS settings, if there is, use it and assume that it is on the SD card FAT partition called $.CMOS;

3.otherwise if the SDCMOS module is there then look for CRC-validated block of CMOS settings in the ROM image itself and/or in SDFS::0.$.!Boot.Loader.CMOS and/or in SDFS::0.$.CMOS noting which;

4.look to see if DELETE is pressed and, if so, clear CMOS to default

I’m not sure that’s quite correct, at least on a Beagleboard.

My understanding — based on experience with ‘recent’ ROMs, and questions that I subsequently asked at the SW Show — is that points 1. and/or 2. will happen in parallel with 3. if all the necessary hardware and files are present. That is: if the system finds physical hardware /and/ SDCMOS plus a suitably named file, it will keep both in sync (not sure which it reads, however). If that’s wrong, then 3. takes precedence over 1. and 2. — on a widgeted system, there was a noticeable speed improvement when the CMOS file was deleted from the SD card.