Towards BeagleBoard "CMOS RAM"

.. good article to add to the Wiki on how to set up the SD card and HDD for dual boot.

It’s already been done in one thread. It does mean using Linux on the BBXM to create the boot script however.

Link: https://www.riscosopen.org/forum/forums/5/topics/404?page=5#posts-4481

2. However, I would welcome an interim release with CMOS RAM reading enabled, as it would make things much more convenient. For example, at present we are booting of SCSI::4.$ and to do so conveniently I am using a special ROM which someone prepared.

At present we have the odd position where several different versions of the ROM image are circulating. If we got CMOS RAM (read only) working then we would have a better position where only one, definitive ROM image would be used, with a few different CMOS RAM files to cater for the boot drive location (SCSI:0 or SCSI:4). Let’s move to that position now and worry about write access to the SD card later (as it is much more time consuming). We could then, perhaps, have a full, even numbered, ROM release for the Beagleboard etc.

Dave wrote:

You do all know that an SD/SDHC/MMC card can be unplugged and plugged in while the system and reader/writer are powered up, don’t you?

Good job you mentioned that: it hadn’t occurred to me to try it. This makes writing the CMOS RAM file back to the card even easier than I thought.

Writing to an SD card reduces its lifetime doesn’t it?

Hardly, max number of write is something like 100.000 times.

I have an idea to make progress with the CMOS RAM functionality. The advantage of step one below is that it is a very simple and straightforward step in terms of coding but adds a very large improvement in functionality.

The first step (under the Beagleboard entry point) would be to make RISC OS expect an area of memory, immediately above the ROM image in memory, to contain the desired CMOS RAM contents, including check sum. On entry this area would be checked and if it passed the check sum, it would be used to initialise CMOS RAM and if it failed it would do nothing (as at present).

The second step (under the Beaglebord entry point) would be to make RISC OS (once we have a read only SD card driver) attempt to load a file called ‘CMOS’ from the root directory of the SD card and to use that, after checking the check sum, to initialise CMOS RAM, taking precedence over the results of step one.

The third step (under the Beagleboard entry point) would be to add SD card write capability so that CMOS RAM configuration changes can be written to the file ‘CMOS’ on the SD card whenever they are effected.

The standard boot script would load the RISC OS ROM image into memory and load the file ‘CMOS’ into memory just above before passing control to the Beagleboard entry point in the ROM image. Earlier boot scripts that do not load the file ‘CMOS’ (i.e. like as now) would simply leave that area random and it would fail the checksum and so behave as at present. The ‘vanilla’ file ‘CMOS’ that could be used [created on a Beagleboard XM] can be downloaded from here: http://www.svrsig.org/CMOS.zip

This way the whole process is forwards and backwards compatible, whether or not an SD card read or SD card write capability has yet been introduced.

There is a work-around for the third step which involves double-click on !Boot, select ‘Save CMOS’ from the menu and then copy the file ‘CMOS’ from !Boot.Choices onto a network drive (or FAT formatted pen drive) connected to the BBXM. Rebbot the BBXM under Linux and copy this file into the root directory of the SD card and then reboot RISC OS. Not hugely difficult or time-consuming.

This would allow earlier testing. Any chance of a release that did this for the South West show please? And what about a ‘stable’ even-numbered release that marks a ‘finished product’ so far as Beagleboard is concerned?

...idea to make progress with the CMOS RAM functionality…

Sounds as if it’d work.

And what about a ‘stable’ even-numbered release that marks a ‘finished product’ so far as Beaglebaord is concerned?

I think that’d require Castle’s approval, and therefore probably no major bugs.

If Castle would like to be able to approve an official stable release to demonstrate to manufacturers, it’d be great if they could find time to assist with the development work.

Anyway, I agree that a stable release is desirable. Without that, we’ll miss the boat with respect to companies designing products which can potentially accommodate RISC OS. Hacking the OS onto proprietary closed source products is certainly undesirable.

Any chance of a release that did this for the South West show please?

Sure. If Dave’s SD read code (and potentially write code) isn’t ready by mid-February then I’ll go ahead with the backup plan of making it work with a CMOS file that’s been loaded by the u-boot script.

And what about a ‘stable’ even-numbered release that marks a ‘finished product’ so far as Beagleboard is concerned?

“Stable” and “finished” are two completely different things :)

Producing a stable release should (hopefully) be a lot quicker than producing a ‘finished’ release, since there’s still a lot of features I want to add before I’d class the port as ‘finished’.

As Trevor says, any stable release would likely require Castle’s (or at least ROOL’s) approval before it’s allowed to be given an even version number. Although I generally prefer to work on new features rather than fixing bugs, I’d gladly switch over to full-time bug-fixing once the decision is made that a stable release is needed.

Sure. If Dave’s SD read code (and potentially write code) isn’t ready by mid-February

It’s ready for your review now. Can I e-mail it to you? (I need your address if you say yes.)

Since it wants an additional file in the distribution, are you going to alter your SDCreate to add the default file?

Where is the Help going to go to tell users how to update the file?

Also where is the little BASIC app going to go, the one that reads the CMOS contents and creates a file ready to save to the card? (I have written the app, of course.)

Trevor: a few days ago I e-mailed you a RISC OS image, a CMOS file and a BASIC app to try. Did they arrive with you?

This was in response to an e-mail you sent me, in which you offered to trial the software.

Also where is the little BASIC app going to go, the one that reads the CMOS contents and creates a file ready to save to the card? (I have written the app, of course.)

Why do you need an app? Why not double-click on !Boot, select ‘Save CMOS’ from the menu and then copy the file ‘CMOS’ from the !Boot.Choices directory onto whereever you want it to go. It is &F4 bytes long rather than &F0 (not sure why) but the first &F0 bytes are exactly the same as that created using OS_Byte 161 (Read CMOS RAM) for the &F0 bytes defined..

Actually, we’d really like the CMOS file to be 2048 bytes long. That’s the length I’ve been working with. That’s been the length of the “CMOS RAM” in the BB code for ages.

Actually, we’d really like the CMOS file to be 2048 bytes long. That’s the length I’ve been working with. That’s been the length of the “CMOS RAM” in the BB code for ages.

At present it is only &F4 bytes long – unless the ‘Save CMOS’ and ‘Load CMOS’ code is broken as well. Also the Wiki information states the CMOS RAM is &F0 bytes long (and this entry has been created for RISC OS 5). It’s all very well making the CMOS RAM area longer just because there’s no hardware limitation (on the BB) but what is the extra for?

It’s ready for your review now. Can I e-mail it to you? (I need your address if you say yes.)

Sure.

Since it wants an additional file in the distribution, are you going to alter your SDCreate to add the default file?

Yes.

Where is the Help going to go to tell users how to update the file?

It can probably go in the readme file that gets placed in the ROM archive.

Also where is the little BASIC app going to go, the one that reads the CMOS contents and creates a file ready to save to the card? (I have written the app, of course.)

That can probably go in the ROM archive too.

Why do you need an app?

Apart from allowing a 2K file to be created instead of a 240 byte one, it also (I assume) has code to undo/bypass the address mangling that RISC OS does.

It’s all very well making the CMOS RAM area longer just because there’s no hardware limitation (on the BB) but what is the extra for?

It provides a convenient place to store any new configuration settings which we may want/need to store in CMOS, e.g. the RTC battery charger configuration.

Trevor: a few days ago I e-mailed you a RISC OS image, a CMOS file and a BASIC app to try. Did they arrive with you?

Yes, they did… but I’ve only just seen them now I’ve had a more thorough look. Sorry for apparently ignoring you – I now see it was almost 2 weeks ago! I’d actually been watching out for your email so am surprised I let it become buried amongst the spam.

Anyway, I’ll give it a go as soon as I can. Sorry.

It provides a convenient place to store any new configuration settings which we may want/need to store in CMOS, e.g. the RTC battery charger configuration.

So why does the ‘Save CMOS’ and ‘Load CMOS’ menu option in !Boot.Configure not save and load a 2k byte long file on both the Iyonix and the BB (i.e. under RISC OS 5.16 or 5.17)? Or does it only load and save the extra CMOS bytes over and above &F0 if they are (tagged and) used?

In any case the file ‘cmos’ will need to be compatible between what is produced in !Boot.Choices and what is loaded from the SD card. Otherwise that is a recipe for trouble.

fatload mmc 0:1 0x81000000 riscos
fatload mmc 0:1 0x8100f800 cmos
go 0x81000000

Slow handclap as user reaches his 100th post.

Jeffrey, I’ve just e-mailed you the code to review and hopefully to merge.

Apart from allowing a 2K file to be created instead of a 240 byte one, it also (I assume) has code to undo/bypass the address mangling that RISC OS does.

Actually it doesn’t. Whatever address mangling happens, is reversed by code elsewhere. All the entire save-and-load system has to do is give back exactly what it was given.

Maybe one day we’ll go up to 8 kiB. Who knows.

So why does the ‘Save CMOS’ and ‘Load CMOS’ menu option in !Boot.Configure not save and load a 2k byte long file on both the Iyonix and the BB (i.e. under RISC OS 5.16 or 5.17)?

Two reasons:

1. For the beagleboard, current ROM images only claim that 240 bytes are available, because that’s all that RISC OS provides support for when the HAL says that there’s no CMOS RAM present.
2. For the Iyonix, it’s because Configure uses its own implementation of the CMOS save code instead of using the *SaveCMOS command provided by the BootCommands module (confusingly, it does use *LoadCMOS to do the loading)

And although the BootCommands module will save all of CMOS RAM, at the moment *LoadCMOS looks like it just ignores anything beyond the first 240 bytes. I’m not sure why.

Also the reason why the file is 240+4 bytes long (or 2048+4 if *SaveCMOS is used on an Iyonix) is because the OS version number (as reported by <Boot$OSVersion>) is stored in the last 4 bytes. *LoadCMOS will refuse to load a CMOS file if the OS version is wrong or the file size is wrong (not 240+4, and not ‘CMOS size’+4)

In any case the file ‘cmos’ will need to be compatible between what is produced in !Boot.Choices and what is loaded from the SD card. Otherwise that is a recipe for trouble.

Agreed. I’ll have a go at modifying Dave’s code to do this (if it doesn’t work already).

Why can we not now have the solution…

Because I’m already in the middle of looking at Dave’s code ;)

Actually it doesn’t. Whatever address mangling happens, is reversed by code elsewhere. All the entire save-and-load system has to do is give back exactly what it was given.

Ah, I see that your save app uses OS_Hardware to call the HAL directly, thus bypassing the address mangling.

I see a possible offshoot of Dave’s work to read “cmos ram” settings off the sd card. Would it be desirable to implement a pseudo podule rom loader not unlike the one used by RPCemu to load HostFS? That way modules not compatible with the Castle licence could be run before a filesystem is running, this could help get people going with a !boot application without having a filecore formated disc by loading Fat32fs from the sd card and having it as the default FS.

Just a Thought.

Dave’s read-only CMOS-on-SD/MMC code is now in CVS. Here’s some notes:

• The HAL looks for a file called ‘CMOS’, ‘CMOS.’, or ‘CMOS.DAT’. If found, it uses the first 2K of that file to initialise the CMOS RAM cache.
• When you want to save updated CMOS settings, use the *SaveCMOS command and save/copy the new file to the SD card.
• There’s a new version of SDCreate available here which allows you to place CMOS files into your SD images. It’ll also generate empty dummy images if you don’t provide one yourself; RISC OS should then initialise it with the correct default values on boot (although obviously those changes won’t yet be automatically saved back to the card). This new version of SDCreate will be included in future ROM image distributions.
• Configure has now been changed to use *SaveCMOS instead of its own bespoke code, so will now save the full 2K instead of just the first 240 bytes. Although this doesn’t matter much at the moment, it will matter once we start making use of the extra space.
• Although the HAL does look for three different filenames (not sure why – ask Dave!) I’d recommend just using the first, ‘CMOS’, as that’s the name that SDCreate uses when it adds the file to the image.

The files common.h, NVMem.h and fat.h seem to be missing.

They weren’t missing. I downloaded them manually instead.

They’re definitely in CVS, so I don’t know what’s gone wrong there. What commands did you use to get latest? I usually rerun the checkout script (which will grab any new components, or update a component which has been changed to a different tag), then do ‘cvs update -R’ from each of the bsd/castle/gpl/mixed folders (which will grab all the updates for things which haven’t had changes made in the products file). So far the only time when those steps have failed me is when a file has been deleted from CVS, at which point CVS complains and exits. (Anyone know the right option to get CVS to delete local files?)

Doing a ‘checkout OMAP3Dev’ and then a ‘cvs update -R’ normally works. I can’t seem the get the header folder to download.

I had to rename the ‘CMOS’ file to lowercase for them to take effect. But apart from that excellent! :-)