Separating RISC OS media from RPi boot SD card
John Williams (567) 768 posts |
David Pitt has outlined how he has arranged for RISC OS to boot from a memory stick/pen drive or whatever using the native filecore format and SCSI to access the drive (https://www.riscosopen.org/forum/forums/4/topics/6400?page=4). Presently the SD card only contains the 5 RPi files necessary for booting into RISC OS, amongst which are the CONFIG/TXT and the RISCOS/IMG file. These are read at start-up, and a RO configuration file is loaded as data pre-pended to the ROM image itself. So far so good! However, on shut-down, the “CMOS” configuration data is resaved as a header for the rom image. This means that the SD card gets re-written each shutdown. If this could be avoided, it might help prolong the life of the card, being used only in read mode. Also, separating the RISC OS media completely could have advantages in backing-up. Within RISC OS, at the time of the RISC PC, there was a utility provided to save and restore a configuration file under RISC OS. There was also a third-party application to edit these “CMOS” files written by Mike Ironmonger and Richard Hallas. This latter required an updated data file to cope with changes in how each RO version used its configuration settings, but this was/is a manageable issue. Using a system like this, only a very basic config file needs to be on the SD card – enough to specify the RO filing system, perhaps a working screen mode, and the fine tuning could be contained in a “CMOS” file on the RISC OS side, fully transparent and editable. However, Chris Evans pointed out that the SD card could not be hardware write-protected to prevent re-writing, and even, further, that micro-SD cards don’t even have a read/write switch! Later Rick Murray asked if the rom image file itself could not be write-protected. This is where we are at present. |
Chris Hall (132) 3512 posts |
If you RMKILL SDCMOS or unplug it then the SD card will not be written to when you change CMOS settings (but the downside is that they won’t be saved unless you add a widget). I think the ROM may still be written to when you shutdown (so that if clock setting fails on next startup, time is set no earlier than the previous shutdown to avoid TARDIS-related errors). |
Raik (463) 2030 posts |
There is cmosd from Carlos aviable.
I add a Obey called !Boot. Set the filesystem to SCSI and Starts the regulary !Boot from a SCSI device. |
David Pitt (102) 743 posts |
For some reason I am thinking the CMOS is at the end of RISCOS/IMG. OTOH as a user I do not need to know where it is nor do I feel any need to have third party editing access to it, long ago that was not so and there were tools to do just that, but now all the required configuration can be done with the !Boot tools or via the command line, unless someone can demonstrate otherwise that is. ROOL may change the CMOS format and locations at any time, third party tools would have to keep up. Some configuration setting are written immediately to RISCOS/IMG and there is a write on closedown. The current system works just fine. A theoretical argument can be made to have the ROM image read only which does require a separate read and write CMOS file but I would guess there was a very good reason for making the ROM and its CMOS a single file though that might not be the case now. Unless someone wants to implement change then there is no point in discussing it further. I does not concern me in the least that my firmware only SD card gets written to sometimes. |
David Pitt (102) 743 posts |
I tried my luck putting a whole !Boot onto the SD card and set the boot filesystem to SDFS. It crashed, don’t really know why, filenames not confirming to DOS 8/3 perhaps, but in any case SDFS reading FAT32 is slow! |
Rick Murray (539) 13430 posts |
Did you try? If I remember correctly, doesn’t FAT update a cycle ID each time a volume is accessed? Or was that just floppies? If so, there’d be no such thing as a read only FAT filesystem unless the firmware just doesn’t bother… The CMOS stuff is near the start, in the HAL section where it can be easily found. Given wear leveling and a mostly empty SD card, I do think this is something of a stroganoff1 in a tea cup. You use flash media for Filecore right? D’you have any idea how much the free space map (same sectors) gets hit in normal use? 1 Wanted “storm”, swipe-type suggested “stroganoff”. I liked that option more. |
Chris Evans (457) 1614 posts |
John: You want to use the new low level boot from USB now available on a Pi: I’ve not tried it but can’t see any reason why it shouldn’t work with RISC OS |
Raik (463) 2030 posts |
If you use a !Boot as a Obey-file (two lines… *SCSI and *SCSI::Devicename.$.!Boot) is very small. SDFS should fast enough ;-) |
John Williams (567) 768 posts |
Interesting. But it looks like what I’m trying to achieve is not sensibly possible or necessary from the information already provided by others. I was unaware that the whole thing was resaved every time something was changed, for example – I had imagined it was only saved on shutdown. The time and date saving bit Chris mentions is another complication. I would, though, like the RO config as a separate file just for transparency, and so that different configurations could be stored separately for later use. I’ve discovered that the config tool does offer a CMOS file save which is saved in Choices as a &ff2 file, and a reload is offered and seems to work OK from that menu, but that double-clicking on this file gives the error “Corrupt CMOS file”. This file is 2,052 bytes long, whereas the old RPC-type file was 240 bytes. The content of the first 240 bytes are identical, and the rest of the longer file is zeros. What the significance of this is, I don’t know! |
Jeffrey Lee (213) 6046 posts |
SDCMOS uses standard filesystem calls to update the CMOS/ROM image. So making the ROM file or the Loader “file” read-only will be enough to prevent it from making any changes. However it is hardwired to look for it SDFS:$.!Boot.Loader.riscos/img (or SDFS:$.riscos/img if the first attempt fails), so using the new USB or network firmware boot modes will prevent it from saving CMOS to the right location. So it’s probably about time we started adding support for alternate “soft” CMOS storage options. |
John Williams (567) 768 posts |
Thanks for that information
and I’m sure any modifications you choose to make will be very helpful! Your noticing this thread is welcome! |