MiniTime v1.10 available

If you’re proposing changes to SDCMOS, may I request that at the same time we look at allowing CMOS to exist on SCSI as well (I know this introduces complications). The reason I say this is that Pi4s can boot from USB/SSD with no SD card, but SDFS will only read/write CMOS to SDFS::0 unless it is manually recompiled. This makes booting from SSD fiddlier than it ought to be.

I know this introduces complications

What happens if we try to look at the file SCSI:$.!Boot.Loader.CMOS when nothing is connected? Will it fail silently or ask for media to be inserted?

If it fails silently, then I don’t see why there couldn’t be an option 3 to look there?

What happens if we try to look at the file SCSI:$.!Boot.Loader.CMOS when nothing is connected?

SCSI:$.!Boot.Loader.CMOS is not a valid filename.

One of the problems is that looking at the file SCSI::4.$.!Boot.Loader.CMOS can find a file of the right format, but the likelyhood is that the file is very old. Copied there when !Boot was created on the SCSI drive.

Does it make sense to look at the *Configured Filesystem and Drive, which would tell you the boot device?

Of course, those settings are saved on the boot device, so it could get rather cyclical. But presumably once the ROM is loaded RISC OS needs to know where its boot drive is, so the settings should be correct.

Although the failure modes might be tricky: eg if you don’t have a configured drive, maybe you can’t change it because there’s nowhere to save the CMOS file. However maybe you could use Filesystem+Drive as a first try, and fallback to SDFS::0 or SCSI::4 if a suitable file can’t be found?

those settings are saved on the boot device

True, but the CMOS file should be loaded into memory before the OS, so as long as there actually is data there, it ought to be valid.

if you don’t have a configured drive, maybe you can’t change it because there’s nowhere to save the CMOS file

Configure the drive and filesystem. *SaveCMOS the data, put it in the right place (probably Boot→Loader) and then reboot and it ought to be picked up automagically.

Does it make sense to look at the *Configured Filesystem and Drive, which would tell you the boot device?

Bear in mind that the CMOS file may not be on the boot device though. For example my boot device is SCSI but my CMOS file is on SD, and the !Boot on my SCSI drive doesn’t even contain Loader.

Bear in mind that the CMOS file may not be on the boot device though. For example my boot device is SCSI but my CMOS file is on SD, and the !Boot on my SCSI drive doesn’t even contain Loader.

Is that cause or effect? As per the comments from Theo
i.e. Is the reason that the CMOS file isn’t on the SCSI boot device because the means of saving the CMOS doesn’t look to save it on the SCSI despite it being the boot device? and how do you make the system boot from a specific device if all the settings are on that device?

As far as I’m aware, the CMOS file must be in the same place as the ROM, as it’s loaded by the Pi bootloader before RISC OS starts up. The boot device set in *Configure is not necessarily the same device that the Pi itself boots from, and I think that’s the crux of the issue. I have no idea whether there’s some tricky way to determine what the actual Pi boot device is set to.

Is that cause or effect?

I think it is evolutionary. The majority of the ARM boards start up in some manner from a FAT partition on an SD card. They also, unlike the earlier RISC OS machines, tend to not have any NVRAM to hold their settings.
Early versions of RISC OS 5 would store settings by directly messing with the ROM image, but that’s not ideal and makes upgrading the ROM annoying.
So now the settings are a file called CMOS that is loaded into a particular place prior to booting, so the OS can find the information it needs as it starts up.

It’s only been more recently that devices have gained the ability to boot using alternative methods, which does complicate matters somewhat, however it’s worth noting that the module is called “SDCMOS” so there’s a clue in the name right there. ;)

Does it make sense to look at the *Configured Filesystem and Drive, which would tell you the boot device?

Just to muddy the waters even further, this method would fail on my Beagle.
The boot device is an SD card dual formatted to FAT and, I presume, extfs. It’s the Angstrom image that is usually supplied. I’ve put a copy of RISC OS there, and it boots from that.
The RISC OS filesystem is SCSI because the FileCore format device is a (depressingly lethargic) USB key.
It was done this way as SystemDisc wasn’t available back then, and I think it also predates the Pi and it’s dual format image.
I probably ought to revisit that, but it’s not a priority, except to say that if the module was to read the filesystem and drive settings, it would be looking in the wrong place.

[edit: Chris got here first, I was distracted for quite a while reading about how the bootloader works ;) ]

But presumably once the ROM is loaded RISC OS needs to know where its boot drive is

The OS boot drive is not necessarily the one that started the system.
However… I can’t help but think that this sort of thing ought to be available in memory someplace, set up by the bootloader, the device tree.

I would opine that it is all-but-impossible to come up with something that copes with every circumstance. For a start, the Raspberry Pi bootloader (which actually loads the CMOS file) will make its own decisions as to what device it will use, so you are already having to second-guess what device the Raspberry Pi bootloader chose. Also, people can come up with “smart” config.txt arrangements that would allow them to choose absolutely any drive to hold the CMOS file.

A better idea would be to concentrate on the most likely arrangements. For example:

1. SDFS:$.!Boot.Loader.CMOS (people booting from SD with !Boot on SD)
2. SDFS:$.CMOS (people who boot from SD with !Boot moved to a USB drive)
3. <Boot$Dir>.Loader.CMOS (people who boot from USB, without an SD card at all)

This won’t cope with people who boot from USB then subsequently insert a card in the SD slot, nor will it cope with people who have multiple USB drives connected at boot time, and I expect there are other failure modes I haven’t thought of. But it should handle the vast majority of use-cases (for the purposes of this discussion I am assuming that people who are fiddling around with “smart” config.txt settings do Know What They Are Doing and can sort out the consequences themselves).

1 and 3 make sense.
2 should be gotten rid of entirely.

Why? Because the CMOS file needs to exist on a FAT partition on order that the bootloader can place it in memory for the OS to use
If it exists on any FileCore format, it is useless for this purpose and will just confuse people by saving things that will have no effect.

It may be like that ($.CMOS first) in order to try to make the system “more secure” (note the scare quotes) by allowing a root based CMOS file to take precedence. But like the mind numbingly dumb Special Secret Sauce preventing the Econet station number being changed, it’s utterly and entirely the wrong way to go about doing such a thing ¹. Plus, I would imagine the number of Pi machines running RISC OS in a school environment are few and far between these days. Children using them are probably your own and you’d get pretty rapid obedience if you threaten to firewall Tiktok. ;)

So rather than improving things, it just ends up annoying or inconveniencing legitimate users.

¹ A CMOS bit to disable further writes to CMOS (except setting the clock), and to also mark Boot.Loader as read only would be much better against halfhearted tampering.
*Configure Lockdown and the way to undo that would be to put the SD card into another machine and wipe the CMOS file…

however it’s worth noting that the module is called “SDCMOS” so there’s a clue in the name right there. ;)

Well, I didn’t like to make too much noise on that nit-picky detail :)

It was done this way as SystemDisc wasn’t available back then, and I think it also predates the Pi and it’s dual format image

Which, in itself, is a bodge job¹ to deal with the lack of partition support in RO at the moment.
How is that partition support coming along? Not seen any clues recently.

¹ It works, but don’t poke it.

2 should be gotten rid of entirely.

Why? Because the CMOS file needs to exist on a FAT partition on order that the bootloader can place it in memory for the OS to use
If it exists on any FileCore format, it is useless for this purpose and will just confuse people by saving things that will have no effect.

Like a number of aspects of RO, it might have had a reason for a while. Now there’s a reason for a bit of housekeeping¹ to clear out the old fluff in the corners.

¹ I made the mistake of saying something about much needed “housekeeping” work on the NAT tables and ACLs on our firewalls. That was January, I’m making progress (e.g. one of the NAT tables is about 1/3 of its previous size) but I don’t see me completing the work before Christmas given the lack of time for all the other work and the need to fully document every change.

Since this now has nothing to do with MiniTime, perhaps a new thread in “Code Review” or “Wish Lists” is in order?

2 should be gotten rid of entirely.

Why? Because the CMOS file needs to exist on a FAT partition on order that the bootloader can place it in memory for the OS to use

But, option 2 works very well if the SD card is fat32fs formated. The bootloader places the file in memory as required and the OS can write to the file on shutdown to keep the CMOS data up-to-date.

It is very simple to do and very simple to keep the SD card boot files up to date – there are only 5 of them on a Pi 4.

So, a 32 Mbyte SD card will do very nicely, with 7 MBytes to spare. (Or, a bigger card with a 32 MByte image on it)

2 should be gotten rid of entirely.

I do like it when Rick lapses back into Shakespearian English despite never having lived in the USA.

Mom’s influence lives on, as does she in the memories of those who knew her.

Sorry, a bit off-topic.

it’s worth noting that the module is called “SDCMOS” so there’s a clue in the name right there. ;)

Before you get too excited, recall that AcornSSL isn’t made by Acorn and doesn’t support SSL :)

But, option 2 works very well if the SD card is fat32fs formated. The bootloader places the file in memory as required and the OS can write to the file on shutdown to keep the CMOS data up-to-date.

Yep. My card contains a single FAT32 partition but is still addressable as SDFS::0. You don’t need to use Fat32FS: (in fact I haven’t even tried this).

Since this now has nothing to do with MiniTime, perhaps a new thread in “Code Review” or “Wish Lists” is in order?

That occurred to me a couple of days ago, but alas we can’t bulk-move posts into a new thread so it makes things a bit harder to follow.

recall that AcornSSL isn’t made by Acorn and doesn’t support SSL :)

True, but the original was and it did. ;)