Towards BeagleBoard "CMOS RAM"

Since the SD card can’t currently be written to from RISC OS, (I wasn’t even aware RO could read from it yet.)

I’m getting very close to being able to read from it!

I’m getting very close to being able to read from it!

Is it a fair assumption that full read/write access is far more difficult than read only? (If nothing more than the consequences of a failure, requiring far more testing for a write capable system.)

It’s substantially more difficult because there are more cases to consider. Does the file already exist? How big? Is there spare space in the directory? In the data space? Is the card write protected?

You could always use code from Fat32fs – the source is included. Should give you an idea how to (or not) do it. The underlying library code is generic, and has been used on other projects to access SD cards directly using the SPI protocol. I also have the necessary code to access SDHC cards.

Sorry, deleted double post

Isn’t FAT32fs GPL?

Isn’t FAT32fs GPL?

I had a look at some of the source a couple of days ago; the licence I saw was LGPL. Unfortunately this is incompatible with the Shared Source Licence of RISC OS.

Time for an update. I’ve been quiet for a few days because I’ve been away, without the BB. The family did make up for it, though – I have a lovely son, a lovely daughter-in-law, and two lovely grandsons :-)

Today I’ve got the HAL implementation working as far as matching the directory entry for “cmos”, and thus giving me the file size and cluster pointer. It shouldn’t be long now before the file is being read in and used, if it exists. (The matching is already case insensitive – subject to test, anyway! – and I will add a couple of lines so that the test is for “cmos” or “cmos.dat”.)

The progress throws up some questions:

• If the file is not present, can I return all 0, or do I have to supply the default CMOS contents, address mangled? (I don’t know if there is code elsewhere to substitute default contents if the checksum is wrong. I don’t want to duplicate it.)

• Bearing in mind that there is likely to be a long-ish delay before writing also works, is it worth integrating with the RISC OS sources with only read working? I’ve written a dead simple app that creates a file from the contents, so the file could be created after a user makes a change to the “CMOS”, and written back to the SD card using an SD reader/writer; it’s just another file on the card, in exactly the same way as boot.scr and riscos.

is it worth integrating with the RISC OS sources with only read working?

Does your system load the contents of the file into the BB RAM and use it from there?

I’ve written a dead simple app that creates a file from the contents, so the file could be created after a user makes a change to the “CMOS”,

Would this be better merged with the savecmos in configure?

written back to the SD card using an SD reader/writer;

Isn’t FAT32fs GPL? LGPL.

As I understand the situation this means it can’t be part of the main ROM Image, but it could be a module.

If that were implemented, wouldn’t that mean you could leave your HAL system read only? (Saving would only work after a succesful boot loaded the FAT32FS based module.)

Does your system load the contents of the file into the BB RAM and use it from there?

Yes, a cache that is part of the HAL’s workspace.

Would this be better merged with the savecmos in configure?

No:

• it still wouldn’t automate the process of updating the “CMOS” file; it would merely automate one small step – the easiest step;

• when the writing facility is working, we’d have to un-merge it again.

As I understand the situation this means it can’t be part of the main ROM Image, but it could be a module.

If that were implemented, wouldn’t that mean you could leave your HAL system read only? (Saving would only work after a succesful boot loaded the FAT32FS based module.)

Gosh, what a lot of extra complexity. Your solution is more difficult than the original problem.

when the writing facility is working, we’d have to un-merge it again.

I have obviously missed how this (interim) app would work, my reading was it would act like save cmos, (but in the file format you use).

Your solution is more difficult than the original problem.

It relies on another desired feature being implemented, so if you include that, obviously.

Of course the first step is the same as your current roadmap.

(edit:)

I was attempting to give a reason that you should put a read only version into the sources. (i.e an alternative solution could be built on top of it, if other things happened to be developed first.)

As far as I can see, a read only system, with a (fiddly) manual save, would be a 90% fix of the problem from the user’s perspective, anyway.

Today I’ve got the HAL implementation working as far as matching the directory entry for “cmos”, and thus giving me the file size and cluster pointer. It shouldn’t be long now before the file is being read in and used, if it exists. (The matching is already case insensitive – subject to test, anyway! – and I will add a couple of lines so that the test is for “cmos” or “cmos.dat”.)

Excellent.

The progress throws up some questions:

Q1: If the file is not present, can I return all 0, or do I have to supply the default CMOS contents, address mangled? (I don’t know if there is code elsewhere to substitute default contents if the checksum is wrong. I don’t want to duplicate it.)

My suggestion is that if the file is not present then you simply do nothing – i.e. behaviour unchanged from present.

Q2: Bearing in mind that there is likely to be a long-ish delay before writing also works, is it worth integrating with the RISC OS sources with only read working? I’ve written a dead simple app that creates a file from the contents, so the file could be created after a user makes a change to the “CMOS”, and written back to the SD card using an SD reader/writer; it’s just another file on the card, in exactly the same way as boot.scr and riscos.

Definitely merge it now.

If a user needs to change the default start up, then the saved CMOS image (a simple thing to do) can simply be written onto the SD card by writing it onto an external ethernet-connected device from RISC OS and then (using Android) written onto the card from within the WIMP version of Linux – i.e. no need to remove the SD card from the Beagleboard. As the CMOS-RAM only needs to contain a very small number of settings (those that must be known before !Boot is seen) users are unlikely to have to do this more than once.

In fact if the ‘popular’ choices are already prepared (such as SCSI drive number =0, =4 etc.) then one would simply download the ROM image and the correct ‘cmos.dat’ file for one’s own particular configuration in the first place and NEVER need a SD card write facility on the beagleboard.

Thanks for your vote, Chris.

Any more votes – either way?

Just another quick update: I’ve got some code working for MMC cards too. This is at present still only in my application version (which is easier to work on, and therefore always precedes, the HAL version), and is at present specific to MMC. I still have to devise some code that will work for all three card types: SD, SDHC and MMC.

• If the file is not present, can I return all 0, or do I have to supply the default CMOS contents, address mangled? (I don’t know if there is code elsewhere to substitute default contents if the checksum is wrong. I don’t want to duplicate it.)

I think that Chris’s “do nothing” suggestion is logical and presumably easy to implement.

• Bearing in mind that there is likely to be a long-ish delay before writing also works, is it worth integrating with the RISC OS sources with only read working? I’ve written a dead simple app that creates a file from the contents, so the file could be created after a user makes a change to the “CMOS”, and written back to the SD card using an SD reader/writer; it’s just another file on the card, in exactly the same way as boot.scr and riscos.

Read-only implementation in the RO sources would be good. The file created by your app could also possibly be an optional inclusion in the creation of a card image using SDCreate (if Jeffrey sees fit to include this in a subsequent version – if there is one before write access permits ultimately including the full boot sequence).

I think that Chris’s “do nothing” suggestion is logical and presumably easy to implement.

Overall, doing nothing isn’t an option. If all the contents of the CMOS RAM were 0, I suspect you’d have a very strangely configured computer – possibly unusable. The checksum would be wrong, I believe. AIUI, somehow a default CMOS RAM image must be presented. I’m just not sure whether I have to do that, or whether I can present all 0 and some other code substitutes the default.

RISC OS must have some concept of what the default values are, since if it detects an invalid checksum, it uses default values, so I’d guess that if you presented something with an invalid checksum, then RISC OS will use default values instead.

Overall, doing nothing isn’t an option… I’m just not sure whether… I can present all 0 and some other code substitutes the default.

So what happens if you load a ‘zeroed’ cmos file at power-on?

So what happens if you load a ‘zeroed’ cmos file at power-on?

A very good point, thank you, Trevor. The answer is that it comes up with default values – therefore the code to substitute defaults must already be present and be called after mine. Not a problem, then!

Good! Sounds like a good time to shutdown and get into your New Year’s Eve fancy dress costume, or whatever you’re doing!

Unfortunately I seem to have got a virus (aches, shivers, the occasional nasty cough) and my wife has the mother and father of all colds, so we won’t be partying this New Year. (Never mind, maybe we’ll catch up later!) It’s not bad; if this is all the discomfort I get from it, I shan’t complain.

I have a few hours of dev and testing to do before I shut down tonight. Fortunately the virus doesn’t seem to have stopped my brain.

I think there’s some danger that the read only version of my code is ready to merge.

In that case, I think there’s some danger of user excitement!

Steady…

Is there a list of the configuration parameters stored in CMOS RAM under RISC OS 5.17? I know that it is dependent on the particular ROM build, but not (I think) on the configuration plug-ins present on the computer (which store their configuration with the !Boot structure)?

It includes as many ROM modules as can be fitted into the remaining CMOS space, in the order they are present in the ROM, for marking as ‘unplugged’, I think?

The PRM pages 5a-73 to 5a-80 gives the CMOS RAM byte allocation in RISC OS 3.6 (and presumably later versions as there doesn’t seem to be anything later than PRM 5a) for all 239 bytes (plus a checksum byte). Seems to be the same in RISC OS 4 and 5 judging by this page: https://www.riscosopen.org/wiki/documentation/pages/OS_Byte+CMOS+Settings