Towards BeagleBoard "CMOS RAM"

How many bytes should the call to NVMem_C_read() load: 2048 or 2052? What is the function of the extra 4 bytes in the file? I take it they are at the finish of the file, not the start?

The extra 4 bytes (which are at the end of the file) are present when you use *SaveCMOS, and are used to store the OS version number. IIRC *LoadCMOS uses it to check that you’re not loading settings from an incompatible OS version. Obviously your code can just ignore the extra bytes.

Taking a lesson from the command line Linux distribution bundled with the Beagleboard XM is there a case for another file on the SD card (which would probably be a bit larger, say 60Mbytes or so) which would be loaded into memory in a similar way to ‘cmos’ but used to initialise the RAM disc with a pre-built boot structure (given the appropriate CMOS setting for the boot drive being the RAM disc). The purpose is to attract new users to a fully functioning RISC OS environment but without the need for an external RISC-OS-formatted drive with a boot structure.

Would RAM disk be the most appropriate location for the included !boot?

Wouldn’t either the extra file being mounted as a read-only filesystem or !boot being included in resources fs be more appropriate means of achieving the aim?

The former would have the advantage of saving system RAM, and I think that the latter would have the advantage of just being a special ROM build (no new drivers).

The extra 4 bytes (which are at the end of the file) are present when you use *SaveCMOS, and are used to store the OS version number. IIRC *LoadCMOS uses it to check that you’re not loading settings from an incompatible OS version.

Ah, OK… I see that the version number is 510, which is clearly not current; I guess that version 5.10 was the first to bring in this particular mapping of the bytes, and it hasn’t changed since?

Obviously your code can just ignore the extra bytes.

OK; and equally, when I’m give 2048 bytes to write, I must append 510 as a 4 byte integer after them.

It’s actually the Boot$OSVersion system variable where the version number comes from, so technically the value that your code writes out should match that. But since it’ll be a bit tricky to get that value from within the HAL (and the variable might not even exist – it gets created by one of the utilities in the boot sequence) I suspect just writing out 510 (or maybe the value the file previously contained?) would be your safest bet.

Would RAM disk be the most appropriate location for the included !boot?

Without significant programing effort, yes. The ‘standard’ boot image is expected to be read/write and occupies about 60Mbytes and so would make a rather large ROM! Reserving about 70Mbytes of the 512Mbytes of RAM for the RAM filing system should make little difference for a new user of RISC OS. After all the 512Mbytes limit is just as arbitrary.

Bear im mind this is just intended for new users who purchase a beagleboard for the Linux and might be persuaded to hold down the USER button and try RISC OS. Serious users would take the next step and add a RISC OS formatted pen drive, which would be very easy to do from the RISC OS desktop and copy over the boot image and then change the ‘cmos’ setting to SCSI drve 0.

Anyway it would NOT save system RAM as the image would be within the resources part of the ROM image (which uses system RAM) or as a filing system in system RAM (which uses system RAM).

Without significant programing effort, yes. The ‘standard’ boot image is expected to be read/write

Doesn’t the hard disk lock facility already write protect most of the !boot folder? (Obviously not scrap, but that could go in RAM disk)

and occupies about 60Mbytes and so would make a rather large ROM!

The components on the downloads page are nothing like that big.

If it could be done in resourse fs, it would also be useful for non beagleboard ROM images.

Anyway it would NOT save system RAM as the image would be within the resources part of the ROM image (which uses system RAM) or as a filing system in system RAM (which uses system RAM)

I was referring to the second suggestion of mounting the file directly as a filesystem. (Like emulators do as an alternative to HOSTFS).
(Though if the contents of resource FS are squashed, then it would make a little saving)

It’s actually the Boot$OSVersion system variable where the version number comes from, so technically the value that your code writes out should match that. But since it’ll be a bit tricky to get that value from within the HAL (and the variable might not even exist – it gets created by one of the utilities in the boot sequence) I suspect just writing out 510 (or maybe the value the file previously contained?) would be your safest bet.

Is there any circumstance under which HAL_NVMemoryWrite can be called when the OS is not up and running?

Is there any circumstance under which HAL_NVMemoryWrite can be called when the OS is not up and running?

Having had a long read of this thread, it appears that it could happen when the year changes.

I am worried that the only ways to determine the value of the last 4 bytes are to re-use the previous value, or to use a fixed value of 510. That means the value will never normally change, and might not match the value of Boot$OSVersion. Later OS ROMs, of course, can update the value, but under what circumstances? If priority is given to re-using the existing value, it will never change except in response to some failure, some abnormal condition.

Why do we use Boot$OSVersion? How is it linked to the meaning of the CMOS file’s contents?

Some good progress to report: I have written a CMOS file to an SD card as a result of re-configuring the mouse speed.

The job is not yet complete; what I wrote was a “CMOS2” file, and it can only write it for the first time; I haven’t put the rewrite code in yet. These are still experimental days. But I’m getting close now.

Re. Boot$OSVersion: I’m proposing these decisions to determine what value to write in the last 4 bytes of the file:

• If the file exists, and its length is exactly 2052, and the last 4 bytes are between 510 and 1024, that value will be written out to the new file;
• Otherwise the last 4 bytes will be written as 510.

Any comments?

The values are #defines, so would be easy to change.

Finally, I can report that I have written the code to rewrite the CMOS file. It’s working on my BB and BBxM.

Files changed: c.fat, c.NVMem, h.common, h.fat, h.NVMem, s.NVMemory, s.RTC, hdr.StaticWS.

Jeffrey, perhaps you would like to review them, and, if you find them satisfactory, put them into CVS after any necessary changes.

It’s working on my BB and BBxM.

Can that. It’s working on the BB, but not reliably on the xM.

My current hypothesis is that the bootloaders leave the SD/MMC interface in different states. This may take some time to resolve.

Why do we use Boot$OSVersion? How is it linked to the meaning of the CMOS file’s contents?

I have no idea. I suspect they were after a version number that would change whenever the CMOS layout changes, but I can’t see why they went with Boot$OSVersion instead of adding a dedicated “CMOS layout” version number to the OS sources.

Re. Boot$OSVersion: I’m proposing these decisions to determine what value to write in the last 4 bytes of the file:

* If the file exists, and its length is exactly 2052, and the last 4 bytes are between 510 and 1024, that value will be written out to the new file;
* Otherwise the last 4 bytes will be written as 510.

Any comments?

That sounds good to me. Feel free to send me your updated sources once you’ve ironed out all the kinks!

Did you receive the sources OK?

Yes, I was going to have a proper look at them today.

Your CMOS save code is now in CVS. There were a couple of tweaks I made to clean up the debug output and to remove some trailing slashes from statements that had been split across multiple lines (there’s generally no need to do that in C). Plus I fixed a bug where the Boot$OSVersion number was being written out as 0 if the CMOS file was missing. But apart from that the code seems fine.

Sometime in the next day or two I’ll probably have a go at hooking up some code to flash an LED while writing to the card, and to poll the write protect pin. That should leave us in a good position for when the full SD driver is ready.

Good stuff; thanks! I was just getting a little worried that I hadn’t heard a word, either here or by e-mail; and I know that e-mail very occasionally goes astray.

I’ve prepared a dead simple little app to read and textify the four entries in a partition table, and to allow swapping the active/inactive state of the first partition. I’m awaiting allocation of the application name, and then I’ll put it on my web site. If anyone should feel that it’s worth making part of RISC OS’s apps, I would be happy for that instead.

I’ve just bought three more 2 GB SD cards, to see if the problem I had with my earlier ones applies to other brands. So far I’ve tried one of the new ones, and it was fine at being written.

I flashed it with all 6 files, and, although I could read all of them using a card reader/writer, the xM wouldn’t boot. As supplied, the SD card’s partition 0 is formatted but flagged as inactive. I used my app to change the flag to active, and the xM booted immediately I plugged the card back in.

I had a random synapse fire and think I’ve come up with a way to transition from “towards CMOS RAM” to “at CMOS RAM”. The solution, being a hardware type, is just to add some CMOS RAM isn’t it?

So I just looked at the schematics for the original Beagleboard/the xM/the Beagle bone. The Beagle bone actually includes a 24C256 EEPROM on the IIC 0 bus so if that ever becomes a target there’s nothing to do since I think that’s one of the types the Kernel sniffs for assuming it’s on a vaguely standard address.

The Beagleboard and xM both have expansion pins with IIC ports on them, but disappointingly they don’t appear to be fitted by default so involves a soldering step. I think that’s probably a step too far for most users.

The only other connector that is always fitted is the JTAG header.

I note it has power, ground, and two pins (13 & 14) which can also be configured in software to be GPIO lines. Bingo.

So – all that’s needed is a little PCB with a board mounting female 2×7 way header, an EEPROM, and some bit bashing code in the HAL. I estimate (in 100’s off) they’d cost about £5 each to make.

Now this would probably be an all or nothing change. ie. if you had the adapter installed it’d be just like using a trusty Risc PC, if the adapter was not installed (such as you’d not bought one) you’d revert to the ROM defaults on every reset.

This does have the advantage of removing the problem of your CMOS settings being splatted onto a card that might be removed, or might be in use by the forthcoming native SD card FS.

Who are the stakeholders here? I can design a PCB, I can bitbash things, ROOL could distribute them. Unfortunately some of Dave Higton’s changes would be made redundant, at least on Beagleboard. Anything else?

A not-necessarily-conflicting idea is to move away from an arbitrary binary format where the layout changes every OS version and is retricted to 240 bytes, to something that has its own structure. So your SD card settings file contains:

language=Desktop
caps=ShiftCaps
boot=1
mousespeed=10
filesystem=ADFS
MACaddress=00:11:22:33:44:55
Unplug=CDFSSoftATAPI,!Edit,WaveSynthBeep
WimpMode=1920×1080×60
etc

The idea is something which is easy to edit from any platform – none of this messing about trying to configure a system that doesn’t have a working disc, or a mouse, or a screenmode that the monitor can’t display.

Such could be stored in an EEPROM/flash chip but I think if the ROM is on an SD card the configuration should probably go with it.

The main issue is that amending it (eg adding something to the Unplug list) means rewriting the whole file. But that’s not so much of a problem – on a storage device it’ll be a sector write anyway, and a flash chip will have to erase a block. It’s just not as convenient for EEPROM use.

I think I’d be in favour of keeping the CMOS as a file on the SD card. Why create extra hardware (and hence extra cost & hassle), when it can be done with existing kit.

Theo, we did talk about using Key/Value pairs for any additional settings, hence Dave’s allocated 2k for the CMOS file, but it was thought that the original 240bytes would have to stay for compatibility reasons.

I had a random synapse fire and think I’ve come up with a way to transition from “towards CMOS RAM” to “at CMOS RAM”.

We’re already at CMOS RAM. Builds of RISC OS in the last week or so include the full functional equivalent.

The other advantage of it being on the SD Card is that the settings go with the card, so the format doesn’t need to be maintained between ROM versions, and you can have different setups.

We’re already at CMOS RAM.

I realise there is a read/write emulation in place now, but was thinking more long term and thinking outside of the xM family.

I think I’d be in favour of keeping the CMOS as a file on the SD card. Why create extra hardware (and hence extra cost & hassle), when it can be done with existing kit.

Because I fear the overall user experience will be compromised as soon as the use cases change from what you have on your desk right now.

Imagine for a moment a full SD card filing system which I see is being worked on, you’ll therefore have a non FAT disc in the drive most of the time but then when you (say) switch to BST then !Alarm will want to update its CMOS. Then we start to need to teach the HAL how to request discs to be reinserted, or some other collusion, and generally diverging from the original HAL concept of skinny & simple. Remember having to eject floppies on the A3010 for !Scrap to be found?

At some point partition support might appear, though the rate of donation to bounties suggests this could be some time off, so a mixed FAT/FileCore image could exist, but again developer time would need to be diverted to make the HAL collude with higher level modules to marshall use of the SD controller. Generally, the simplest engineering solution is the correct one in my experience.

That’s mostly thinking about Pandaboard and xM owners.

For the original Beagleboard, which has onboard NAND flash, the ROM image is reasonably going to sit in that and there may not even be an SD card present.

For the Beagle bone, that does have genuine EEPROM, and a common ROM image would also simplify the user experience. I find the ROM download page here confusing enough already.

and hence extra cost & hassle

The hassle would be zero, since ARMini would be prefitted with them. I hope that £5 isn’t a barrier to entry for any DIY builders here, if it is then RISC OS truly has sunk to a commercially unviable platform.

Imagine for a moment a full SD card filing system which I see is being worked on, you’ll therefore have a non FAT disc in the drive most of the time but then when you (say) switch to BST then !Alarm will want to update its CMOS. Then we start to need to teach the HAL how to request discs to be reinserted, or some other collusion, and generally diverging from the original HAL concept of skinny & simple. Remember having to eject floppies on the A3010 for !Scrap to be found?

Changing your SD is like changing your harddisc. You should not do that while your system is running. Imagine the SD is switch and the system needs something from !Boot (like a font).

When a full SD filing system arrives, it should have the u-boot, rom-image and CMOS file + a kind of riscos filing system on it. There is no other solution.