What are the CMOS widgets for?

As far as I can tell, this question has never been answered.

We have a fully functional pseudo-CMOS solution for all BeagleBoard and family machines which can transparently load and save a file containing CMOS data from/to the machine’s SD card. This is in full working order on my ARMini, with the caveat that the writing procedure is not automatically performed on a *Configure command, like with other kinds of CMOS. (There is absolutely no reason for this, BTW – why isn’t it automatic?)

So, considering that this grants us a functionally unlimited amount of non-volatile storage suitable for all CMOS settings, what on earth is the point of buying a CMOS widget?

(Apart from providing ROOL with an extra income stream, of course…)

There are two reasons (apart from the income stream): (i) writing to SD card automatically is not a good idea as the card can become corrupted, reading is however OK and (ii) with the widget then the SD card image becomes standard. However I think the two solutions should co-exist – if ‘cmos’ file there then load that, if widget fitted use that, if neither then use defaults.

It also has the advantage that if you need a break to make a cup of tea you can do a ‘Load CMOS’ :-)

ROOL does make a tiny amount of money on the dongles. These aren’t a ROOL product though, they are made by sprow – we’re just selling them on.

Going back to Martin’s question, the answer is that the CMOS dongles implement something which was taken for granted in previous generations of RISC OS hardware (seamless CMOS setting storage and retrieval). The interim code that was implemented to bodge stuff to and from a file on the SD card was never supposed to be a long term solution.

Indeed, the temporary CMOS save/restore mechanism would cause big problems when RISC OS has native SD filesystem support. As an example DOSFS caches information and buffers writes – hence you having to dismount DOS discs before they can be safely removed. The CMOS-emulation could would be very likely to trample over what DOSFS (via SDFS) is writing to disc, and vice versa, leading at best to some confusion and at worst to disc corruption.

And to anyone who says native SD filing system support in RISC OS is a pipe dream, take a look at this

So how do other OSes do it, then? Linux seems to remember its configuration just fine without needing custom hardware!

Using the SD card as a filing system is a bad idea for more reasons than just the CMOS file. Given that that card must hold, in its root directory, the MLO file, uboot binary, the boot script and the ROM image (plus whatever else is there), using it as a hard disc is never going to be a practical (or safe) solution. It would be safer to partition the card and keep the vital low-level stuff in the first partition and access the second partition as a filing system. (This wouldn’t necessarily involve adding full partition support to FileCore – I believe DOSFS is currently hardcoded to ignore all entries in the partition table except the first, so simply change that to the second.)

And once you’ve done that, you might as well just carry on writing the CMOS file as before to the first partition, safe in the knowledge that DOSFS can’t see you.

Ah, good idea. We’ll replace one bodge with some more bodges.

The interim code that was implemented to bodge stuff to and from a file on the SD card was never supposed to be a long term solution.

Speaking as the bloke who implemented it (with Jeffrey’s help), I take exception to what you say. I didn’t and don’t regard it as interim at all. I regarded it as a permanent solution. I still do.

Which also means I’m rather miffed that it has been removed.

I wonder why I bothered.

I think it is a retrograde step to remove the processing of a correctly CRC-checked cmos contents pre-loaded into memory [from the file ‘cmos’] because this cannot trample over anything. After all the ROM has to be loaded and why not load cmos at the same time if it is there on the SD card and process it if its CRC check is OK?

Removing the ‘fatload cmos …’ from the script is not the issue. Removing the processing from the ROM is fundamentally wrong.

I’m with Dave on this issue. As far as I can tell the widget solution is no help to people with Devkit or IGEPv2 or Pandaboards let alone Touchbooks. Also how rubbish must it look to someone with suitable hardware who casually tries out RISC OS only to find they can’t save any settings because they haven’t got a proprietary hardware add on. Very Open!

Surely once there is an SD card filing system up and running then the OS can use this to perform writes to the CMOS file on the card? If the CMOS file should get corrupted then the OS can cope with that, so it’s not the end of the world!

didn’t and don’t regard it as interim at all.

I wasn’t of the impression that it was being developed as an interim solution either. My interpretation of the first steps and “Towards…” thread title was that this was something in development, with writing not being implemented initially.

• Didn’t "at CMOS RAM" arrive when the desired functionality was already implemented?
• A quick review of the thread doesn’t show any obvious comments about it being an interim solution.¹

There’s obviously a place for the hardware solution, or people wouldn’t be buying it. But does it necessarily have to prescribe that “some of Dave Higton’s changes would be made redundant”? I’m sure I’m not alone in hoping that this apparent misunderstanding won’t lead to a falling out amongst the few talented and motivated developers we have working on the shared source version.

¹ "[(tag,value) pairs being stored in CMOS RAM is] a nice way of doing things.", possible suggestion of short-term nature via retrospective interpretation of "fake CMOS".

Re. corruption of the CMOS file: yes, there was an issue. I’d written a bug in my code. Jeffrey found and fixed it before I did.

I think there is far too much being made of CMOS corruption issues.

When it comes to an SD filing system, I have a couple of points to make.

Firstly, I think it would be sensible to put an ADFS partition as the second partition on an SD card and use that. It really shouldn’t be difficult to respect the partitioning. Nor should it be difficult to prevent corruption due to multiple access attempts; I don’t see it as any different from what ADFS has to do when multiple files are open, for example.

Secondly, even when it’s implemented, I suspect that there will be some disappointed people who discover that their SD card no longer works, because it has been worn out by frequent erase/write cycles. (I’ve got one USB stick that became read-only after a few months of use as the primary drive of my BeagleBoard; I can’t prove or disprove the reason for its demise, but I suspect it wore out.)

worn out by frequent erase/write cycles

What about wear levelling?

Before everyone gets carried away, I haven’t seen anything suggesting support for the use of a CMOS file was being removed from the ROM.

AIUI the widget is just an additional option if you would prefer instant effect CMOS that you don’t have to remember to save!

Isn’t wear levelling only implemented by SSDs, not SDs?

Err, possibly.

Wear levelling merely delays the inevitable. I operate under the assumption that all flash memory devices have it and use it, including the one that became read only for me.

Bryan: the code to write to the CMOS file is no longer called, or no longer present – same result either way.

Some points – the widget saves the settings on the machine. (i.e setting stay when media is SD changed.) When saved on SD, it travels with the OS install. There will be situations where one or the other is desirable.

Once SD cards are writable by the OS, the saving part of the SD ‘CMOS’ should be disabled and saving settings should be done solely by savecmos using the OS (this could be called automatically, if that were considered desirable.)

Since there is now a boot suitable for read only, a variation of this could be used (saving choices at shutdown, perhaps?) to minimize wear on the card.

Partition support would be great. It is probably the most annoying flaw in the OS from my point of view.

(Firstly, sorry for having gone into stealth mode, and sorry if there are outstanding questions for me in other threads – I’m afraid I’m months behind with the forum. But I was specifically asked if I could join this discussion.)

ROOL plans to make an SD stack a more core part of RISC OS than it is at present, at least on platforms that have SD controllers (which is basically all the modern boards, because they are built around chips designed primarily for the mobile market). This was initially prompted by a specific request from the Raspberry Pi Foundation – they want their version of RISC OS to have !Boot on an SD card. But users of other boards stand to gain in terms of the flexibility of configuration this allows – after all, it’s a shame to only use the SD bus, operating at up to 50 MB/s, to access a tiny block of non-volatile RAM.

The reason why Linux doesn’t need custom hardware to decide certain things (like which media to boot from) is because that information is passed to the its kernel on its command line from the bootloader. Thus the information is effectively stored in the boot script file. RISC OS doesn’t have this level of integration with bootloaders, because traditionally it hasn’t used them.

In fact, RISC OS would need a very long command line to handle all the options from CMOS, because RISC OS has an awful lot of CMOS options. The reason it has so many is because so many of its modules need to be configured during ROM initialisation, before the filing system is up and running. And RISC OS is also designed to be relatively usable even without anything on the filing system at all – think back to all those systems like the A3000 that didn’t have a hard disc. Just try doing anything useful on a modern Linux system with no root file system!

Having a fully operational SD stack will open up several different options for users. You can put !Boot on the SD card and do away with (or never buy in the first place) USB storage. You might choose to put it in a separate partition, or not – the choice should be up to you, the user. Even if you use separate partitions, though, you might legitimately want to write to the same partition as the one containing the CMOS file, for example if you’re upgrading your ROM image. At present, if you want to download or build your own ROM on a Beagleboard and copy it to its own SD card, some people would need to go out and buy a USB SD card reader – which is in a sense just another hardware add-on, of a similar cost to the CMOS widget.

The other way of using an SD stack is either to keep using a USB drive to hold !Boot, or to use a “Live” ROM image where !Boot is built into the ROM. That way, you can use the SD slot as a general purpose memory card reader, perhaps to transfer photos from your camera. Or you can plug in an SDIO card, for example to gain WiFi or Bluetooth connectivity. In either of those cases, you really don’t want to be trying to write CMOS settings to the SD card slot!

I wasn’t responsible for removing the SD-NVRAM, and I’m sorry if feelings have been hurt, but on balance I support the change. It’s not a good idea to have two drivers trying to drive the same hardware installed at the same time, whether it’s a question of the coherency of the data stored on the card, the danger of different streams of commands on the SD bus getting jumbled up (say, block lengths and start addresses from the two drivers getting mixed up) or interrupts for one driver getting sent to the other.

If you still want to store CMOS settings on an SD card, I suggest it should sit in a layer above the filing system, and let the filing system arbitrate between that and other users of the SD slot – for example prompting the user to swap cards if the wrong one is inserted. There’s nothing stopping that being written, once SDFS is released. But even then, it may suit some users better to continue using the CMOS widgets.

What about wear levelling?

The controllers inside SD cards take care of this themselves. The SD protocol involves writing data in blocks of multiples of 512 bytes (or for some older cards, multiples of 1 byte). If you’re familiar with flash memory, you’ll know that individual bits can only change from 1 to 0, and to change from 0 to 1 requires an erase operation which can only operate on much larger blocks, say 256K. This implies the controller has to do some buffering, and in practice the new version of that large block is taken from a pool of hidden blocks. In this way, the wearing gets distributed across more parts of the card than you might naively assume. (SD cards are typically even cleverer than this simplistic explanation – I suggest you google it if you’re interested in more. In practice, the SD command set doesn’t let you get at the physical flash blocks, even if you wanted to.)

I have no particular reason to suspect that SD cards will be any more or less susceptible to lifetime issues than a USB flash stick would be – underneath they’re the same technology. You can get particularly good or bad implementations of wear levelling for either one. If you’re particularly concerned about wear on a SD card used to hold !Boot, you can always use the write-protect switch – that USB flash sticks don’t have – and you’ll automatically inherit the new feature of the boot sequence (designed for the Live ROMs) which will place !Scrap and Choices$Write in RAMFS instead.

Also how rubbish must it look to someone with suitable hardware who casually tries out RISC OS only to find they can’t save any settings because they haven’t got a proprietary hardware add on. Very Open!

This is much more important than ROOL like to think. It already looks awful to have to demand that people purchase a closed-source toolkit before they can compile the ROM, but this is much worse.

Why are RISC OS developer efforts concentrated on systems like the BeagleBoard and Raspberry Pi? Because its former proprietary hardware-based business model had failed. It seems to me that the CMOS widgets are the work of people who still think that RISC OS can survive by convincing people to purchase hardware made specifically for it, and while there’ll always be a small group of die-hard users who’ll happily oblige, it’s naive to the point of insanity to believe that it’s in any way a realistic way to ensure the future survival of RISC OS.

The ROOL branch’s chief strength is that you can download a ROM image, install it on hardware you already own, and have it just work. On this basic principle alone, people are being attracted back to (and sometimes even just to) using RISC OS, because you do not have to purchase any proprietary hardware. Would you really willingly throw away all the good ROOL has done over the past six years? Because that’s what demanding that users purchase CMOS widgets will do.

In the main, I’ve been in favour of ROOL, I’ve bought an ARMini, I really appreciate all the progress that’s been made, both technically and from a business point of view. I mean, before the BeagleBoard, when was the last time you read the words “I’m coming back to RISC OS”? And as someone who’s willingly championed the RISC OS 5 branch and all the good work that it’s done over a number of years, I would like to say that this is the first really, really, really, really STUPID thing ROOL has done.

However much it may offend your technical sensibilities, there is no getting away from the fact that RISC OS Open will stop dead the moment it obliges potential users to buy extra hardware. It completely flies in the face of exactly the business model which has enabled us to get to the point where we are today.

If you still want to store CMOS settings on an SD card, I suggest it should sit in a layer above the filing system, and let the filing system arbitrate between that and other users of the SD slot – for example prompting the user to swap cards if the wrong one is inserted.

Good. That would work. Do it. That way, users who have been tempted into trying RISC OS because they already own a Raspberry Pi/BeagleBoard/whatever plus SD card and have spotted that the ROM is free to download won’t be immediately turned off by discovering that they need to configure their boot drive at the command line on every startup unless they go out and buy RISC OS Premium Home Edition.

There’s nothing stopping that being written, once SDFS is released.

And until it’s released, there’s nothing stopping the existing SD card code from being re-enabled, right fucking now.

I would understand this discussion much better if there was a decision to make if a “write CMOS to SD” feature should be implemented or if it would be better to wait for a full SDFS.

However, we already have working code. The work has already been done. It works on the hardware all BeagleBoard users have. I cannot think of a single reason why this working code was disabled. The only reason would be if ROOL was a closed source shop and was making wodges of money by selling the CMOS widget. Which is obviously not the case.

and you’ll automatically inherit the new feature of the boot sequence (designed for the Live ROMs) which will place !Scrap and Choices$Write in RAMFS instead.

This could cause a problem for certain applications – on my Iyonix the !Scrap directory currently has a count of 684 MB :(

… and what is the point of writing an applications choices to a volatile medium?