Configuration settings being lost on boot

There seems to be some sort of conflict between settings that you make in Configure and what happens next time you boot.

This is with RO5.19 and the latest !Boot from HardDisc4 (both dated 15/01/12).

The ones that behave like an A9home that I have noticed are as follows:

1) Discs always reverts back to CD=0 and Floppy=1
2) Fonts always reverts to Desktop font homerton with vertical Sub-pixel anti-aliasing switched off
3) Mouse causes the mouse freeze as soon as set is clicked
4) Windows always reverts to Allow windows off-screen to bottom and right and to top and left on. Cover icon bar when toggling to full size on and Windows have iconise button off

In order to see if it was something I had broken I tried the same thing using the somewhat skeletal !Boot as part of the HardDisc4 image dated as above.

Same behaviour – including another oddity of the Desktop font reverting to homerton when I changed the screen resolution in Screen.

Although this isn’t life threatening it is annoying and odd

Forgot to mention the machine is an ARMini so it’s the OMAP3 ROM being used.

Double check you are using the latest version of !SDCreate to setup your SD card. Some options with regards to loading the CMOS settings from the SD card have been changed recently.

The latest version (v1.16) is available from here – http://www.phlamethrower.co.uk/riscos/sdcreate.php

One of the changes that was made for RISC OS 5.18/5.19 was to the way that CMOS settings are handled in the OMAP3 port. Instead of using Dave Higton’s code for interacting with a CMOS file on the SD card, the ROM now uses some code Sprow wrote which looks for a hardware CMOS widget which plugs onto the JTAG header. I think the main reasoning behind this change was that it will make things a lot easier once the full RISC OS SD driver is ready – the driver won’t have to worry about sharing the interface with the CMOS code, we won’t have to come up with a way for the CMOS code to request that the right card be reinserted if you’ve swapped cards, etc.

I believe the plan is that R-Comp will ship the hardware CMOS widgets free-of-charge to all existing ARMini users, as well as making them available in their shop so non-ARMini users can buy them for use with their BB’s. If the HAL doesn’t detect the hardware widget then it should fall back to using a CMOS file that was loaded from the SD card (which is now expected to be done by u-boot – hence the updated SDCreate that Rob mentions). And if no CMOS file is present then it should fall back to using the default settings. If you don’t have the hardware CMOS widget fitted then any changes will be lost on a reboot.

Now the only thing which is confusing me is that the symptoms you’re describing (mouse freezing, etc.) don’t quite match what should be happening in any of the above situations. Do you have any CMOS file on the SD card? Are you using the updated boot scripts from the latest SDCreate? I might have to have a play around with the different configurations tonight to see if I can recreate the problems you’re experiencing.

If you don’t have the hardware CMOS widget fitted then any changes will be lost on a reboot.

This sounds like a good addition of funtionality for BB/ARMini users.

I think the main reasoning behind this change was that it will make things a lot easier once the full RISC OS SD driver is ready – the driver won’t have to worry about sharing the interface with the CMOS code, we won’t have to come up with a way for the CMOS code to request that the right card be reinserted if you’ve swapped cards, etc.

Does this mean that native saving of CMOS settings is unlikely to be supported on the Pandora, Touch Book and any other gadgets in the gaggle?

I had wondered why !SDcreate was in the zip file…

No worries – I will live with this for now as I don’t want to start breaking things at a too low level given that I will need to revert back to 5.17 when the next ARMini update comes out.

I think that there may still be a slight problem though as twice today switching on the windows have iconise button option (why is this still switched off? – it has been part of the window tools for over 12 years now!) hasn’t worked. It required switching it off and then back on again.

I suspect that the mouse freeze might be to do with !HID – I’ll check later on today.

It is good though to see that the cmos issue is being sorted out :-)

Does this mean that native saving of CMOS settings is unlikely to be supported on the Pandora, Touch Book and any other gadgets in the gaggle?

I think the best solution there would be to have a module as part of the boot sequence or ROM image which saves the CMOS settings back to the SD card whenever they’re changed. We might also need to resurrect the FAT loading code for use on the Touch Book (since the default u-boot configuration seems to ignore any boot script and go straight to loading a uimage).

I think the best solution there would be to have a module as part of the boot sequence or ROM image which saves the CMOS settings back to the SD card whenever they’re changed.

Like the !WriteCMOS in $.Utilities.Caution.!WriteCMOS on the ARMini? OK this is a manual method just to be used when you decide to change the CMOS settings.

We might also need to resurrect the FAT loading code for use on the Touch Book (since the default u-boot configuration seems to ignore any boot script and go straight to loading a uimage).

A manual soloution here would simply be slightly more complicated in that it would need to create a new uImage file from the ROM image and the CMOS settings – again this could be hidden inside the same application.

We might also need to resurrect the FAT loading code

It is not necessary to resurrect any FAT loading code in the HAL – all that is needed is a u-boot command to ‘fatload .. cmos’ at the same time as ‘fatload .. riscos’ [or load then both together in a uImage file] so that the ROM can find the CMOS settings in memory (and checksum it) if no hardware widget is found (or contains non checksum data).

I’m surprised at the objections to the use of the CMOS file, which is the cheapest and simplest solution to the problem of getting a functional equivalent of CMOS RAM.

Sharing the interface is no more difficult than sharing the IIC bus – in fact it’s easier, because reading or writing a block from/to the SD card is an atomic operation, unlike IIC transactions which often require a sequence of operations. And we never thought sharing the IIC bus was an issue. Though, I grant you, the use of the SD card would be far more intensive than any use of IIC that I’ve ever heard of.

I also don’t consider that checking for swapping the card should be considered as an issue. If it is, then any use of the SD card as a filing system (rather than just something to boot from) is utterly doomed – it would be the equivalent of swapping the hard drive without shutting down. But if the SD card is only to be used for booting and storing the CMOS settings, you can swap the card all you like; the CMOS save searches for the file, it doesn’t blindly save the data where it last saw the file.

I’m surprised at the objections to the use of the CMOS file, which is the cheapest and simplest solution to the problem of getting a functional equivalent of CMOS RAM.

What objections? I agree a file ‘cmos’ on the SD card is an elegant and effective solution to provision of CMOS RAM settings. My original suggestion (September 10th 2010) was that it just got ‘fatloaded’ along with the RISC OS ROM image and it was up to the user to figure out how to change it to get different settings [most people have access to a PC that can write to SD cards]. The advantage was that it would work from day 1 and not be dependent on an SD card filing system.

We might also need to resurrect the FAT loading code

It is not necessary to resurrect any FAT loading code in the HAL – all that is needed is a u-boot command to ‘fatload .. cmos’ at the same time as ‘fatload .. riscos’ [or load then both together in a uImage file] so that the ROM can find the CMOS settings in memory (and checksum it) if no hardware widget is found (or contains non checksum data).

The problem is that with the default settings AI are using with their version of u-boot is for it to ignore any boot script and go straight to loading a uimage file. As far as I know it should be possible to get it to load a custom x-loader/u-boot from the SD card and override the behaviour that way, but that would be a bit of a pain to set up and maintain compared to just reintroducing the FAT loading code.

Sharing the interface is no more difficult than sharing the IIC bus

I think the problem is more to do with sharing the filesystem than sharing the bus. Plus there’s a desire to keep the RISC OS SD driver clean and free of any special hacks/workarounds necessary for making it interoperate cleanly with the CMOS code.

I think the idea of storing the CMOS settings on the SD card is a good one, but by having the code implemented wholly within the HAL it was only going to cause us problems once we started work on a fully-featured SD driver.

I suspect that the mouse freeze might be to do with !HID – I’ll check later on today.

I found !HID completely froze the keyboard/mouse on the ARMini with AEs on. I stopped using it.

As I suspected our friend !HID was to blame for the freeze when hitting the set button in the Mouse part of configure.

I’ll just have to start it manually until I can actually save a cmos.

Just a quick comment that we hope to have a formal 5.18 automatic OS update out in the next week for ARMini/BB-Support-Scheme users, so I’d recommend our users hold off 5.19 “DIY” just yet (unless there’s some specific feature you’re after), as it’ll all be considerably less confusing/painful/obtuse with the “official” release :)

We’re just trying to get things properly tested before release, and make sure that updating is as smooth as possible, and that all instructions are clear/accurate. It isn’t quite as simple as previous updates, so doing things in the right order is fairly important (or at least, quite helpful).