Towards BeagleBoard "CMOS RAM"

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.

Actually an invalid checksum causes default values to be used for certain items but others are used ‘as provided’ without regard to the correctness of the checksum according to the PRM.

Looks like I’m losing another USB stick. That makes three now that don’t react fast enough for RISC OS to boot them. It seems that each stick has a finite lifetime before RISC OS refuses to boot it, even though it’s perfectly readable. To save me a lot of digging, can anyone point me at a timeout in the RISC OS sources that I can increase to keep me going?

I’d be surprised if there was an easily identifiable, easily tweakable timeout value that can be used to fix this. Does it produce an error message or just drop you at the supervisor prompt? (as if the stick wasn’t plugged in at all). If it’s the latter then it’s hopefully something that can be fixed just by making the startup code a bit smarter (i.e. if booting from SCSI, but the required drive doesn’t exist yet, wait a few seconds and try again)

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)?

The wiki isn’t (yet) accurate for RISC OS 5, so at the moment it’s best to just consult this file directly.

Hi, Jeffrey, and a Happy New Year to you. It’s nice to have you back again!

I need to talk to you about merging my code in. One thing that concerns me, though, is a report that the current version of RO breaks storage devices (since the 64 kiB fix).

The wiki isn’t (yet) accurate for RISC OS 5, so at the moment it’s best to just consult this file directly.

I can’t get any sense out of the link you posted (above). The PRM pages 5a-73 to 5a-80 gives the CMOS RAM byte allocation in RISC OS 3.6 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 – this page will be updated in due course, no doubt.

I can’t get any sense out of the link you posted (above).

That’s the CVS history for the file; this link should make more sense, although it’s still a bit unclear what some bytes get used for (e.g. some of the RISCiX bytes have been reused, but both the new and old definitions remain)

Latest update: I have successfully written a block to an MMC card.

Don’t get too excited; there’s still a long way to go.

Who cares about writing (let this not put you off from doing it though!)? I think writing to an SD card from RISC OS is an unnecessary luxury.

I have to disagree with that.
First, this way the “CMOS RAM” can be written back.
Second, it would be nice if we could get a RISCOS harddisc on it. This way we could create a simple system without dangling usb sticks.

But if it ultimately allows the boot sequence (and general file storage) on the card, it could mean a usable RISC OS machine without needing an externally connected USB drive. This would free up one USB port, which could be handy for portables/netbooks.

Who cares about writing (let this not put you off from doing it though!)? I think writing to an SD card from RISC OS is an unnecessary luxury.

Note the title of the thread! The whole point is to get some non-volatile storage that is functionally equivalent to the CMOS RAM that RISC OS needs. Note that RO needs it before the hard drive is booted – it needs it even to decide which device to boot from – so a file on the boot drive doesn’t meet the requirements.

Reading from and writing to SD/SDHC/MMC is the only visible way of doing it.

Reading from and writing to SD/SDHC/MMC is the only visible way of doing it.

Not true. Writing to it under RISCOS is NOT necessary. Only reading from it under RISC OS is necessary. Writing to any network connected storage under RISC OS is sufficient. It can then be copied to the SD card using Linux. This does of course only need to be done once. It will then get read many times from RISC OS - each time you boot.

Writing to it under RISCOS is NOT necessary.

True, but it’ll certainly be convenient.

Hmmm, not writing under RISCOS would make changing configuration settings very difficult. Not impossible, but difficult.

If we can’t write to the SD/MMC card, then we’re not reproducing the functionality of the traditional CMOS RAM. Do you have to unplug the CMOS chip and put it somewhere else to rewrite it? Of course not.

Being able to read a file, and being able to write it via an indirect method, is better than the fixed configuration we have today, but it isn’t a fully functional replacement for CMOS RAM.

Writing to an SD card reduces its lifetime doesn’t it? Let’s hope that adding a write facility doesn’t force unnecessary writes when something capable of being held within the !Boot structure is altered.

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

Andrew Conroy has pointed out to me that one of the benefits that will fall out of my work is the ability to re-flash RISC OS into the SD/SDHC/MMC card without having to unplug it from the BB or BBxM.

Not true. Writing to it under RISCOS is NOT necessary. Only reading from it under RISC OS is necessary. Writing to any network connected storage under RISC OS is sufficient. It can then be copied to the SD card using Linux.

Sure, because, as we all know, everybody keeps a spare Linux PC around the house at all times for precisely this sort of occasion.

Sure, because, as we all know, everybody keeps a spare Linux PC around the house at all times for precisely this sort of occasion.

My reading of the comment was that you would have a dual boot system, and to update the CMOS file you would save it to a FAT USB stick under RISC OS, then boot in Linux and copy it to the correct location with that.

Is dual booting straightforward?

Otherwise, you would use the same method as you used to copy the ROM image in the first place. (And the OS would be irrelevant)

... to update the CMOS file you would save it to a FAT USB stick under RISC OS, then boot in Linux and copy it to the correct location with that.

But, more fundamentally, if it’s just things like location of the BOOT drive (SCSI:0 or SCSI:4 for example) then when you first download the ROM image you could also select one of half a dozen or so likely BBXM CMOS RAM files (say one for a Pen Drive (SCSI:0) or one for an OTG connected USB drive (SCSI :4)). So if you were going to use an OTG-connected USB drive, then you would not need to format a pen drive at all, by choosing the right CMOS image to download in the first place.

A few points:

1. I agree with Dave that writing the CMOS RAM is a worthwhile aim as it makes the user experience so much better for the fairly non-technical user.

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. I’ve no idea what he altered to prepare this ROM, so if I want to compile my own sometime with more recent modules or my own amendments to the code, I will be in a mess. Reading the boot drive from the CMOS RAM would be much better.

3. Other choices in the CMOS RAM include (it appears) ShareFS discs which are shown on the iconbar (at least, the BeagleBoard fails to remember the choices I save for these) and things like whether to enable double-click-hold and a confirmation prompt on file deleting. All of these would be good to set up to be the same as our Iyonix.

4. Any recent BeagleBoard purchaser will have a spare Linux PC around the house, because the BeagleBoard is supplied with an SD card to boot into Angstrom Linux. But instructions on what to do would be essential for those who are not familiar with Unix.

5. Dual booting the BeagleBoard is possible to achieve. We now have ours booting into RISC OS if the user button is held down on boot, and otherwise booting into Ubuntu. The SD card holds both boot images easily, and each OS boots off the attached USB hard drive, which we have partitioned to hold a RISC OS hard drive at the start and a Linux ext3 partition at the end. It did take most of the weekend to get this working though!

looks like i need to get back at trying to get RISC OS to boot with kexec. If the BeagleBoard could start in Linux it could automate the process and then boot through into RISC OS. Also some people might even like a splash screen for a dualboot ;-)

5. Dual booting the BeagleBoard is possible to achieve. We now have ours booting into RISC OS if the user button is held down on boot, and otherwise booting into Ubuntu. The SD card holds both boot images easily, and each OS boots off the attached USB hard drive, which we have partitioned to hold a RISC OS hard drive at the start and a Linux ext3 partition at the end. It did take most of the weekend to get this working though!

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

Not true. Writing to it under RISCOS is NOT necessary. Only reading from it under RISC OS is necessary. Writing to any network connected storage under RISC OS is sufficient. It can then be copied to the SD card using Linux.

I was puzzled by this reference to copying using Linux. I couldn’t understand why anyone would suggest that such a thing is necessary. Then it occurred to me this morning…

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? The interface is designed for it. So, to rewrite the CMOS file on a BB or BBxM running RISC OS, all you need is an external card reader/writer. You save the file, remove the card from the BB, plug it into the card reader/writer, write the file, dismount it, and put it back in the BB. Job done.

2. ...we are booting of SCSI::4.$ and to do so conveniently I am using a special ROM which someone prepared. I’ve no idea what he altered to prepare this ROM, so if I want to compile my own sometime with more recent modules or my own amendments to the code, I will be in a mess…

Is it one of Tank’s tweaks?