Change to storing Pi CMOS settings

It appears that current Pi builds are not only reading CMOS defaults from the end of the ROM image file but that they are also being stored there!

This strikes me as being a bad idea.

1. The most critical file on the SD card is being written to and just when people might be pulling the power.
2. Users lose the ability to identify the build date from the ROMs file date.
3. This becomes a special case build as the Panda, BB etc use a CMOS file (if no widget fitted)

Have I missed something and other people think it the best idea since sliced bread?

This isn’t a recent change – it’s been like it ever since the CMOS code was implemented on the Pi (i.e. over a year ago).

Obviously it’s not an ideal solution, but at the time I think it was the only one we had available (or at least the only one which could be implemented in the required timeframe).

However things have moved on by now, and it looks like the firmware now allows you to specify an extra file to load on startup. This is intended to be a Linux initramfs image, but I can’t see any reason why we can’t use it to load a CMOS file.

So if nobody objects, it should be pretty straightforward for me to modify the ROM to use a CMOS file on the SD card instead of stashing it in the ROM image.

If only you’d had the foresight to include a 256+ byte CMOS chip in your RTC modules!

We did consider putting an EEPROM on the Pi RTC module but there were various technical issues, the use of a CMOS file was already in place, we knew that not all RISC OS users would have one of our modules and we knew some systems like Pandora can’t ever have an EEPROM added and hopefully there will be more ports to other hardware that can’t have an EEPROM. The main market for the RTC modules is price sensitive.
Also looking forward I think Dave Higton’s idea of storing the settings in text so that modules are unplugged by name, should be our aim with EEPROM use deprecated for new hardware.
n.b. We have put an EEPROM on our PandaBoard RTC/Power control module but there we had lots of space to play with, cost wasn’t so important and we were thinking of non RISC OS users.

I really, really believe that a hardware solution is the wrong one, and a file on the SD card is the right one. It has zero marginal cost to everybody, and it has no size limit (within reason).

I really, really believe that a hardware solution is the wrong one

Depends upon your outlook.

Sure, a CMOS file on SD makes sense…

…but if you need a hardware solution in order to have an RTC, then why not have a hardware solution for CMOS as well?

…but if you need a hardware solution in order to have an RTC, then why not have a hardware solution for CMOS as well?

…because RTC needs to be updated when the machine is switched off, and CMOS doesn’t?

Hardware CMOS is a legacy of the days when a RISC OS machine was expected to boot up with no storage devices whatsoever. It essentially does exactly the same job as a hard disc, or SD card or whatever. A Pi requires an SD card to be inserted in order to run RISC OS in the first place, so there’s zero advantage to any additional hardware.

There are other snags associated with hardware “CMOS”. Usually we would use an EEPROM. Sadly, they don’t write as easily as RAM; you have to write a page at a time. And here’s the snag: there is no way to read back the page size. You just have to know the device involved.

Writes wrap within the page. So if, for example, you have a device with a 32 byte page size (I have one that I’m using for something entirely unrelated, that has 32 byte pages – yes, really!), and you attempt to write past the page boundary, it wraps back to the first byte within the page. What you end up writing, and where you end up writing it, may not be what and where you expected.

[I scratched my head for a long time when I saw the symptoms. It didn’t occur to me that anyone would create a large-ish EEPROM with such a tiny page size. They did, though. When I finally resorted to the data sheet, all became clear.]

Again: please, please, let’s keep the “CMOS” as a file on the SD card.

so there’s zero advantage to any additional hardware.

…except the Pi has no RTC so something additional is already required.

FWIW, I think the CMOS on the RTC module is around 64 bytes, so it would need to be a file on disc. Just saying there is already a need for some hardware…

When I finally resorted to the data sheet, all became clear.

This is why it is good to read the data sheet first – all sorts of word things become clear, like the weird clocking the original xx86 processors required…

At a pre-christmas meal yesterday I observed people reading the instructions for something from a cracker.
When I made the comment “what kind of techie reads the manual?” my director quipped “Thank goodness someone said that, I beginning to wonder about the quality of staff I had” :)

As they always say, as a last resort read the manual.

So if nobody objects, it should be pretty straightforward for me to modify the ROM to use a CMOS file on the SD card instead of stashing it in the ROM image.

That sounds like a good idea, with one caveat. On current systems, if the ROM is upgraded the CMOS is reset to defaults. Which is annoying, but at least the machine boots. Have to consider the case that the ROM doesn’t notice the CMOS is outdated and some critical module is unplugged. Does power-on-delete work on a USB keyboard, and will people remember to do it?

I wonder if it’s possible to put some kind of ROM id in the file so the OS knows that the ROM has been changed and the CMOS hasn’t? This would make it feasible to deal with upgrades, though I’m not completely sure at what point something could be called to fixup the CMOS between different ROM versions. It would have to know about the layout of all previous versions too, which would be awkward.

Some further thought indicates it’s even worse than this. Consider:

1. A module is unplugged
2. You upgrade the ROM which has a different module layout
3. The Unplug lottery causes a USB module to be unplugged
4. The keyboard doesn’t work, so you can’t do a power-on-delete to reset the CMOS to fix the USB problem

There is a way to get out of that hole by deleting the CMOS file on the SD card, but you need another machine to do it. You could delete it in the upgrade process, but you need to be really careful that your running OS (if you’re doing this from RISC OS) won’t re-write it.

(My post above is itself slightly wrong. In the current scheme, if you upgrade the ROM and just kill the power, you get the CMOS from the new ROM. If you shutdown, you get the new ROM with its CMOS overwritten with the old ROM’s settings. Which just goes to show how tricky this is to get right)

I think it’s high time we moved to a text-based CMOS system (with a translation layer for ‘traditional’ CMOS RAM) because this problem means upgrading your system has a moderate risk of rendering it broken. It was enough of a headache to write something to fix up the CMOS between RC6 and RC8, and this requirement is only going to get worse as more ROM versions appear.

Could we use the NVRAM modules that exist from the NC work? They have key/value support already and did for CMOS on NCs which didn’t have the I2C clock+CMOS chip.

unplug has lots of problems with testing and softloading on an Iyonix too. If you want to record debug output during the initialisation of the rom adding the dadebug module early in the romlist changes what is unplugged. Softloading just makes the cmos entries entries for a different rom.

Do usb keyboards work during boot my Iyonix always says ‘keyboard not found – autobooting’.

The only solution I can see is fix the module that a bit represents in CMOS but that doesn’t help if you go back to earlier versions of the OS.

Might this work?
The first time a new ROM is loaded it initially uses a set of ‘Standard’ CMOS values. Then a utility is run on the first boot which displays any modules that would be unplugged if the CMOS file is used and the user is asked if he wants use Standard or old stored CMOS.

Two negatives I can think of:
It is not very user friendly for inexperienced users.
The ROM image will have to be modified after the first boot so that it doesn’t go through the process above.

All of this hassle reinforces the advantages of having the CMOS settings as text parameters as Dave Higton suggested

Is there a valid case for unplugging modules anyway? I would just reinstate all modules after an OS ROM change.

Is there a valid case for unplugging modules anyway?

What he said.

I am aware of two specific instances where modules were unplugged:

1. Horribly overzealous games back in the Archie era would do some really unpleasant things in an attempt to get more memory, including unplugging stuff left right and centre. I wonder how long it took people to figure out that $GAME is what killed Econet, for instance.
2. The new toolbox routinely killed the in-ROM versions on RISC OS 3.5+. There’s probably a reason for this, but I can’t figure it out, since it looks like this is done in the boot every boot (so wouldn’t RMKill get rid of ’em?).

Certainly, in the case of modern RISC OS – is there a need to unplug stuff?
Firstly, it is easy enough nowadays for knowledgeable people to put together a specific ROM build if a case exists (for example, Jeffrey made me an OMAP build that worked via s-video until it was a part of the mainstream code); secondly, since different versions of RISC OS are built for different devices (it isn’t a one-size-fits-all), there is no need to unplug or otherwise disable OMAPVideo on the Pi build – ‘cos it simply won’t be there. It’ll be BCMVideo there instead.

I would just reinstate all modules after an OS ROM change.

What occurs to me – when looking at the point of view of RISC OS booting itself up… how do you tell the difference between an OS ROM change and any other boot up? Maybe some sort of ID in the CMOS data itself? Like the last two bytes of the build date (depending on how many bytes are spare)?

Toolbox modules were never unplugged, but replaced early in boot with the latest versions.

There was one situation where unplugging CDFSSoftATAPI was a good idea to reduce boot time by 30 seconds. Other than that, I cannot remember a need to unplug since RISC OS 3.1.

I think a build ID for ROMs is necessary to identify when CMOS Unplug state should be reinstated to default. ROMs could even know when incompatible changes to CMOS have been made and migrate CMOS content.