What are the CMOS widgets for?

All this info and discussion is very useful but there’s also the point raised elsewhere about boards for which the widget is incompatible.

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

I’m guessing if you were going to run such a setup, then a real hard drive might be best.

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

I would expect that there would be a save option added. An extra menu item on switcher would seem obvious. Alternatively it might save on shutdown.

Come on guys, where’s the love!? ;)

I think it’s fair to say that Dave did a sterling job of implementing CMOS on the SD card. As someone who’s looked into the technicalities in a fair bit of detail, I know how tricky that must have been. So I can well understand he’s a bit miffed to have the code disabled without much warning.

But I welcome the CMOS widget too, and I think you can read far too much into the motives for its production. I’m sure ROOL were just trying to address concerns (perhaps their own internal ones) that CMOS on the SD card has its drawbacks.

I can see the arguments against it too, though, and I think Ben’s suggestion of having the OS/HAL access the CMOS file via legit FS channels is eminently sensible, if a CMOS widget is not attached. Perhaps in the meantime, ROOL should send Dave a free widget!

There’s really no need for this developing rift. It’s just the course of ongoing development. We’re all on the same side!

Folks, what we have here is a disagreement on the direction to take between active developers. It won’t be the last, in fact if anything I expect them to become more frequent as the number of developers grows – and after all, haven’t we all been bemoaning the lack of developers in the RISC OS scene for years?

I can see both points of view – on the one hand, yes it’s an inconvenient short-term retrograde step for existing users who like to reconfigure their machines frequently. On the other hand, while not wanting to put words into his mouth, I believe Sprow has taken the more philosophical view that non-volatile settings memory is a distinct type of peripheral, and if you want to OS to make it appear to be present, then there ought to really be that sort of peripheral on the board, and not an emulation of one. I have to say that making an SD card appear to be a NVRAM chip feels like a bodge to me, and bitter experience has taught me to expect that such bodges invariably cause more pain in the long term.

Saving settings to an SD card should be seen as as much of a sticking plaster solution to address the lack of NVRAM, as relying on NetTime is a sticking plaster solution to address the lack of a real-time clock. They both work, up to a point – when you need to use the SD card slot for something else, or when you need to work offline, respectively.

Looking at the CVS logs, I see the change went live back in January. Perhaps it should have been delayed a bit, but I believe Sprow made considerable efforts to soften the blow. Firstly, he designed and hand-assembled hundreds of the widget boards, making them available as soon as the change was made for close to cost price – I think that shows admirable dedication to the RISC OS scene, and isn’t it nice to see new hardware being designed for RISC OS? Secondly, for those who can’t or won’t get a widget, I see that at the same time he changed the HAL to accept initial CMOS values from RAM, meaning that they can be loaded from SD card by your U-boot script if you so desire. That default CMOS file can be saved by moving your SD card to a USB-connected SD card reader, if you can’t wait for SDFS.

To be fair, SDFS is a long way behind schedule – when I started on it six months ago, the plan was to have it ready for Raspberry Pi’s then-planned launch date of Christmas. So in January, Sprow could probably have been forgiven for expecting SDFS to appear before now. I can only apologise for this – it’s been soaking up every free hour I can throw at it, and also cost a surprising amount in purchase of test cards. But it really is nearly ready now, honest…

All this info and discussion is very useful but there’s also the point raised elsewhere about boards for which the widget is incompatible.

I think that affects a tiny minority of boards. Sprow’s product information states it’s compatible with Beagleboard, Beagleboard-xM and Pandaboard. IGEPv2 and DevKit8000 are basically Beagleboard clones and looking at photographs, both appear to have the same JTAG connector fitted as the Beagleboard has, so they are probably compatible (though I don’t have any to test personally). I believe someone else is developing an equivalent widget for the Raspberry Pi which fits on its expansion connector (I’m not sure if this is public knowledge, so I’m withholding their name). Even the Touchbook, though it doesn’t have the JTAG connector fitted, does expose the pads for it, so someone with soldering experience could attach either the connector or (probably better for clearance inside the case) connect the EEPROM directly. Sprow might even do it for you if you ask nicely!

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

In the scenario I was describing, there isn’t anywhere else they can be saved, because the user doesn’t want the SD card written to. Yes, that means you lose the settings on reset – tough, if you wanted them saved, you needed to provide permanent storage. It’s exactly the same as a Linux Live CD, if you’ve ever tried one of those.

And yes, I’m sorry for Dave too – I now know first hand what a pig the SD controller can be to program, and how unreadable the SD and MMC specs are. I’d be gutted too if the code I’d written to drive it had been casually cast aside. It’s just difficult to see how the two approaches can co-exist, and I think I’ve made it clear which I think is the better long-term direction. Sorry.

Ben, you have completely and utterly ignored the main – indeed, only – point of my argument. ROOL have built a virtue out of being able to get a fully-functioning RISC OS system using only components which one already owns (a BeagleBoard, an SD card, and a hard disc of some kind for Linux purposes) plus a few extra which are free to download. It is almost exclusively this which has afforded us the luxury of having enough developers to make an argument.

You are now suggesting that, in the future, it will not be possible to get a fully-functioning RISC OS system without going out and purchasing extra hardware. It doesn’t matter how cheap it is, the moment you ask potential new users to spend one penny on a personal experiment, you’ve driven away 99% of them. How many people have spent £5 on buying the so-called “Virtually Free” ROMs, compared to the number who have been tempted to try ROOL’s free-to-download ROMs? Would you really wilfully jeapordise RISC OS for the sake of the “philosophical view that non-volatile settings memory is a distinct type of peripheral”?

EDIT: To make it absolutely clear how I think this has been mishandled:

• Dave’s SD read/write code should never have been disabled until SDFS is released. It gets in the way of nothing and causes no problems while nothing else is using the card, however much of a “bodge” you may wish to dismiss it as.
• SDFS should never be released until a fully functional replacement for Dave’s code has been finished, which is a much simpler task. Use the standard FileSwitch APIs to access, read and write the file as appropriate, and if it doesn’t exist, prompt for either a disc change or offer to create it with the default values (if reading) or the new ones (if writing).

The lengthy gap in the middle where only those who buy an extra piece of hardware have functioning CMOS is in no way necessary, technically or ideologically.

You are now suggesting that, in the future, it will not be possible to get a fully-functioning RISC OS system without going out and purchasing extra hardware.

If ROOL wanted to force people into buying hardware then they wouldn’t have added the ability for the ROM to use CMOS settings that have been loaded into memory by u-boot.

Yes, this lengthy gap where settings aren’t automatically saved is undesireable, and yes the situation has been mishandled, but it’s not the end of the world.

the ability for the ROM to use CMOS settings that have been loaded into memory by u-boot.

Does this mean that the same cmos file that used to work would work with the right u-boot settings?

If so, could Dave’s saving code be made into a module that updates this? (Which would need to be updated to use the OS calls once they exist.)

Does this mean that the same cmos file that used to work would work with the right u-boot settings?

Have a look at the comments on this CVS checkin;
https://www.riscosopen.org/viewer/revisions/logs?ident=1325971332-331698.html

There is a specific switch for this – “TryLoadedCMOS”

Does this mean that the same cmos file that used to work would work with the right u-boot settings?

Yes. SDCreate 1.16 and newer contains the right u-boot scripts to load the cmos file for people without widgets.

I was going to comment in this thread but now I’m confused. Is SDCreate 1.16 in 5.18 and does it get updated when configuration changes are made? i.e. is its use fully implemented or is it an interim load a standard CMOS file if no widget found? Or am I even more confused than I thought!

Well, Ben, your logic as to what is a proper solution versus what is a “sticking plaster”, completely escapes me.

At one stage, I did use another fatload command so that the CMOS file was loaded into memory. I definitely regarded that as a bodge or a sticking plaster. Blow me, what are we using now? Exactly that bodge, that sticking plaster.

Every RISC OS machine ever sold, AFAIK, has had its configuration stored in non-volatile memory, has booted up according to its contents, and has stored modified configuration values immediately without needing to buy an add-on accessory. We reached that state with the BeagleBoard family by use of a CMOS file and SD/MMC drivers. That tradition has now been broken, and for no good reason that I can see.

Has it been done to ensure compatibility with an SD filing system that we don’t yet have? (And if so, why don’t we ensure that the forthcoming SDFS handles requests to write the CMOS file?)

I can see an advantage of the u-boot method, you can have a choice of configurations.

Isn’t it possible to put your cmos saving code into a module that updates the file loaded by u-boot? (And this be included in the live !Boot, at least)

Hello,
I came across this discussion via google and felt it to be such an important subject I had to join the forum so I may comment.
I’m a long-time RISCOS user: A hacker of hardware rather than a software-type and so why I’ve not joined before. My sincere apologies for my first post being somewhat controversial. I’m going in to ramble mode now, but with I hope a point.

Just to be sure I’ve not misunderstood things, with regard to the implications of this specific discussion:
ROL OS = Locked in to propriety hardware – not good for such a niche platform IMO
ROOL OS = Choose an off-the-shelf ARM-based platform and if someone cleaver has done the work away you go – RISCOS goodness is yours to have

This ‘CMOS’ issue:
RISCOS has always used ‘CMOS’ as a way of storing its settings, assuming you don’t want to break stuff by going down an alternate path how do you replicate that in off-the-shelf hardware?
1) Save your ‘CMOS’ to a file that will be loaded on the next boot
2) Make a hardware add-on to do the job as Acorn did
1+2) Ideally allow for both as a ‘best of both’
If one goes for ‘1+2’ I would say it’s vitally important that neither the OS nor the user can functionally distinguish between the two, and for preference it works exactly as Acorn intended.
As a long-time RISCOS user I’d like ‘1+2’ because it would be ‘cool’ to have ‘proper’ CMOS in my machine and I think I see / understand / sympathise with the ‘developers point of view’ that a proper CMOS solution is ‘good’ and that there are pit-falls to be considered when one looks at ‘1’ and ‘1+2’, especially with developments in the pipeline.
But even I can see with my limited coding skills that said pit-falls aren’t insurmountable even if the solutions are seen as a little ‘kludgy’.

Here comes the really important bit:
However RISCOS saves it’s ‘CMOS’ settings in relation to off-the-shelf hardware, apart from the given that it should work ‘as one would expect’, the process absolutely must not require any propriety add-on hardware to achieve that aim. If that means dropping hardware CMOS support entirely because option ‘1+2’ cannot reasonably be made to work reliably then so be it. A ‘CMOS file’ (or some equivalent) however that is made to work MUST be part of current and future ROOL builds.

Why?
Quite apart from the perfectly reasonable point(s) made above that ANY extra hurdle to RISCOS use will put off a great many potential users which in the long run could kill the platform and negate all the excellent work put in over the years by the ROOL devs, any avoidable hurdles to using RISCOS should be squashed on principle.
Also:
What about the future? For now ‘we’ have the Beagle and the Panda (maybe the Pi). Both the former, I believe, will accept the current CMOS ‘dongle’. What if the next target platform needs a new ‘dongle’? Worse, what if the next target platform is incapable of accepting such hardware add-ons..? Users will be pretty ticked of if:
-The ROOL OS becomes locked in to increasingly ancient hardware, like the ROL OS
-They have to go buy a new ‘dongle’ with new hardware
-Worst of all, they have to accept there is no (OS) method to save their CMOS because of a decision made at this point

Here’s an example of a current device that could conceivably run RISCOS but would never be able to take a CMOS add-in. SmartQ T20

I’m sorry to go on, but as I said I feel this is a very important subject. As would be any development that had similar implications.
To summarise:
-Being able to save your ‘CMOS’ settings – most important
-Having the option to do that to ‘proper hardware’ – nice
-‘Proper hardware’ required – Don’t ever consider it as a viable option!

My vote goes for a solution which allows people to download RISCOS to any platform, so that they can try it out and when its shutdown and they come back their settings are still there.

Where’s the love? It’s here!

Thank you for all your hard work, commitment and dedication to this superb platform :-)

I don’t understand how replacing one NVRAM system (RiscPC CMOS RAM) with another (File on SD card) can possible be a wrong concept. The method to achieve this is obviously up for discussion and then there is the quality of the actual code written.

Using SDFS is the long term way forward that I think is not contentious, but…
This does not sound imminent i.e. within the next couple of weeks.
So why can’t a CMOS Widget and a CMOS file can’t coexist. Ben can you expand on why you think they can’t?
If ROOL decided using a CMOS file was not considered appropriate for a ‘Release’ version (5.18) then so be it, but why can’t it be in the beta version (5.19)?

Red herrings
CMOS corruption: I gather a beta version could corrupt the CMOS file, well that is why its called beta!
Revenue making: Having just had to have some PCB’s done, components bought and assembled I know that at best the widgets will only make a small profit and could end up making a loss.

n.b. It may be me, that Ben mentions as planning CMOS RAM for the Raspberry Pi, well now that I know there are two other alternatives (SDFS & CMOS file) I doubt I’ll use the chip that had CMOS RAM additional to its main function, as they are considerably more expensive and no one from the Linux community expressed any interest in having CMOS RAM!

This thread raises the general question of:
If in an Official Release something is being considerded for being dropped, then should it not be discussed/explained openly before hand?

With the ability now of anyone to build a ROM Image, there is a risk of another OS fork if people disagree, so wouldn’t it be best to try and find a way for a consensus to be reached?

p.s. Maybe it is a generational think but to me calling someone else’s work a bodge is rather derogatory at best.
Calling your own work a bodge is obviously up to the author. If you need to point out short comings in other work then:
‘A bit of a bodge’ is not quite so negative.
‘Fudge’ & ‘non ideal workaround’ etc. as appropriate could be used.

Guys, I do apologise for any offence caused by saying the old code was a bodge. I really didn’t mean that in any negative way, just that it was (I certainly believed) a stop-gap solution which was not a true reflection of the more architecturally-correct solution.

The guys at ROOL use ‘bodge’ a lot when talking about stuff that’s relatively quick to develop and fills a gap, hopefully temporarily. That doesn’t mean we don’t try to make the code well engineered.

Seeing as it’s a touchy subject, I’ll try to say “stop-gap” about this sort of thing next time. :)

Suggestion for approach to CMOS issue.

The OS as shipped on a bare board would load a CMOS file via uboot, settings would be saved manually via save CMOS (directly to the file, once the location is writable from RISC OS).

The get Acorn-style CMOS behaviour you would have two choices:

Add a widget, in which case the default settings would use use it (if valid, if not valid the system would ask if you want to load defaults or load it with the values from the CMOS file.)

Add a module that either simulates the CMOS by writing to the file, or monitors changes and writing them at shutdown (with the option of asking.)

I believe this would address the concerns about filing systems from ROOL, but give the option for the behaviour that many desire without a widget.

(i.e if you’ve added a module that writes to the SD card when it wants and you unplug the SD card when the machine is own, it’s your lookout when the system gets corrupted.)

Jess, that’s very sensible, and is in fact pretty much what already exists anyway (well, assuming user has our cmos tool, or dave’s equiv). CMOS widgets are in no way compulsory, and this behaviour hasn’t changed since (95% of) 5.17 releases.

My main concern isn’t one of functionality, but rather that Dave only found his code disabled/removed “after the fact” and wasn’t involved in the decision-making-process. However, I don’t think that’s really a matter for public/forum discussion.

However, I don’t think that’s really a matter for public/forum discussion.

Apologies Andrew, but I have to express my disagreement. Thanks to ROOL, the shared source OS coexists with this forum they host. ROOL staff should be applauded for not censoring discussions or brushing things under the carpet. Most of us (yourself certainly included, in case someone infers the opposite) are adult enough to apologise where necessary and discuss things, with the hopeful end result of reaching a mutually agreeable compromise.

Long live open discussions (although I do of course understand that commercially sensitive stuff is another matter entirely.)

ROOL staff should be applauded for not censoring discussions or brushing things under the carpet

Well, it does make me uncomfortable having heated debates on the forum but it’s right to let this one flow because we did make some mistakes here and valid points have been raised. I think we should’ve talked more on the forums about what the thinking was (note: it wasn’t actually ROOL that moved the CMOS-saving stuff into a build option – but we were aware of it) – we also probably should’ve waited before allowing that change to go ahead until the long-term solution was in place. We just underestimated the difficulty of doing a pukka SDFS (and all the related stuff: HAL, Kernel, device driver, file system, desktop filer, formatter, etc) so the expected alternative hasn’t arrived yet.

Anyway, keep the ideas flowing…

Well, it does make me uncomfortable having heated debates on the forum

You could hardly call this one heated.

moved the CMOS-saving stuff into a build option

What build option is this? (I haven’t built from source in a while now, so I apologise if this is something that should be obvious.)

IMHO, the code should look for the existence of the widget and use it if present, otherwise use the file. It’s easy (at least, in principle) to detect the presence of an IIC device.

If we do that, then everyone should be happy.

I can’t speak about the technical issues; but it seems to me that both options should be available. If we want the Raspbery-pi to be successful in schools it will look very odd if RISC OS requires an extra bit of hardware, whereas Linux doesn’t. As others have said, this will put RISC OS at a disadvantage compared to Linux. Also there is the cost: Needing a widget will increase the cost of the Raspbery-pi by 20 to 25% which could be quite a lot when ordered in large numbers for schools.
Will potential developers around the world want the hassle of ordering and waiting for the widgets to come from ROOL or R-Comp?
Perhaps I have misunderstood the situation and someone will correct me.

IMHO, the code should look for the existence of the widget and use it if present, otherwise use the file. It’s easy (at least, in principle) to detect the presence of an IIC device.

I think I agree. The current approach, while possibly “geekily correct” and good for sales of widgets, seems to make life extremely difficult for those new to the system or trying to get it working. Unless I’ve misunderstood Dave’s system, I think I’d have found my recent learning curve a lot easier if it had still been in place as a fall-back from the widget.