What are the CMOS widgets for?

My 2p’s worth.

Why was the using-SD code removed anyway? Please don’t say “for SDFS” as my ROM does not have that, either. Would it have hurt to have retained the CMOS-on-SD code until such time as SDFS was ready?

The way I see it, the options I have right now are:

• Buy the CMOS widget. This isn’t a big deal, it’s like a fiver or something. Probably double that for international postage. It can, however, present a problem for RISC OS when other systems are configurable without it [only a user familiar with RISC OS will understand why].
• Use *SaveCMOS to save the current settings to a USB device. Take that, plus the microSD, and put them into a different computer (or reboot the Beagle to Linux) and copy the CMOS file from USB to SD. Put it all back together and reboot RISC OS.

That latter method (insane as it seems) is the one I used. I plan, for now, subsequent configuration mods (such as DST/NoDST) to be a hack file within !Boot as I don’t plan on messing around like that too frequently. I’d like it to, you know, just work.

Given the new hardware that RISC OS features upon, surely the logical progression would be:

• Is there a widget? If so, flag widget and use it.
• Is there a CMOS file? If so, flag CMOS and use it. [once RISC OS proper has loaded, the routines to read directly from SD can be dropped if SDFS is present; RISC OS already has stuff that operates in a manner not unlike this – look at the boot-time keyboard scan]
• Is there something that looks like valid CMOS settings poked into memory? If so, flag nothing and use the settings.
• Still no joy? Flag nothing and load up defaults.

The “flag nothing” means there’s no recognised device, so settings can’t be saved back.

With respect to the wear levelling issue, I’m writing this on an eeePC with a 4GiB SSD and an 8GiB SSD. It’s coming up to three years old. I’m sure disabling XP’s swapfile has greatly extended the life of the system, however a lot of stuff makes repetitive logfiles. Not to mention things such as the browser cache (the index file updated for every item downloaded). I don’t deny that flash memory devices fail – I had one fail on me after only four months in my PVR – however I believe there are decent devices with wear levelling and other clever features, and there’s crap. I have encountered devices that only perform wear levelling on parts of the drive frequently used/abused by the FAT filesystem (directory structure and map sectors). Given that cheap SD cards barely cost more than the technology in them, it’s probably wise to buy a better quality of card from a reputable brand (ie SanDisk) rather than no-name clones for data you actually value or situations where you can expect a reasonable level of writes. For god’s sake, it’s a live operating system filesystem, not a pile of CAM xvids…..

Best wishes,

Rick.

Or you could use Dave’s (or ours) CMOS writer utility and write direct to the SD card as needed. Or use a SD card reader on your beagle (in RISC OS) – the USB stack would recognise it, then just plug the card in (no need to reboot).

Of course, neither of these are as elegant, but the “different computer” option really isn’t necessary. Remember that there was no dynamic writing of cmos for most of 2011 (it was only present for what, 6 weeks?) and noone seemed overly upset, since workaround’s like Dave’s writer allowed things to be saved as needed.

Indeed, there’s an argument that only saving CMOS when the user commands it (how we shipped the ARMini) is quite desirable as it means there’s never a scenario where a rogue app *configures the wrong settings and borks the computer.

there’s never a scenario where a rogue app *configures the wrong settings and borks the computer.

Hehe, I remember the days of the Archimedes with a mere 1MiB. Some games did quite evil things in order to get the greatest amount of memory.

Or you could use Dave’s (or ours) CMOS writer utility

Is that !BBFlash?

Or use a SD card reader on your beagle (in RISC OS) – the USB stack would recognise it, then just plug the card in (no need to reboot).

It is okay to eject the microSD from the machine while it is running? I guess the OS is loaded and it is no longer needed…?

Best wishes,

Rick.

It is okay to eject the microSD from the machine while it is running? I guess the OS is loaded and it is no longer needed…?

Correct. Until SDFS comes out, and without Dave’s stuff for writing a new CMOS file to the card, the OS has no means of accessing the micro SD card anyway.

With things as they stand, yes, removing card whilst OS is running is fine. If cmos-writing was re-enabled, not so much (for obvious reasons). Similarly SDFS would probably make it a bad idea (but that’s for the future). I’ve regularly used this methodology whilst testing things on various bits of hardware. It is especially useful on Panda right now, as there’s no direct-SD access.

Regarding the other questions, you’ll forgive me for not going into too much detail as I have to draw the line as to how much help I give because we offer the paid-for Beagleboard Support Scheme. Whilst obviously that covers a LOT more (software, accessories, discounts and so on), I need to be fair to BBSS members!

BBFlash is mine. (I’ve never actually seen the ARMini app; I don’t even know what it’s called.)

I would like to see these options when a CMOS file is used.

1: Read only (As is now)

2: Save dialogue box on shutdown, if the CMOS has been changed.
(With the option to have a countdown to a default answer)

3: Silently save on shutdown (if needed).

4: Save as changes are made.

I tried BBFlash to write only the CMOS file. SD was detected, FAT, >2GB, but when it came to the actual writing, I had an SDMMC timeout, twice.

System – Beagle xM running Jeffrey’s s-video enabled version of RISC OS; the microSD is the original supplied with the Beagle, modified so uEnv.txt starts RISC OS and user.txt starts Angstrom. The existing CMOS file was called “rocmos”, there was no preexisting “cmos” file. Is there a debug option? If not, I would be happy to give a debug build a whirl, and send back whatever it logs.

Best wishes,

Rick.

PS: I like some of the other stuff on your site. Kinda makes me want to go out and buy a USB controlled missile launcher! (^_^)

Two red herrings:
Wear levelling:BBFlash will write very infrequently! !Scrap will do a couple of orders of magnitude more and Linux has a swap file…

Problems if SD card being removed: Why is anyone going to do remove it? Error trapping could be added.

Almost everyone agrees Dave’s code should be put back in! So what is stopping it going back in?

I tried BBFlash to write only the CMOS file. SD was detected, FAT, >2GB, but when it came to the actual writing, I had an SDMMC timeout, twice.

Does this still happen after a reboot?

Can you please post full details of your SD card (in fact, since you say >2GB, I assume it’s not an SD card, but SDHC?)

What exactly was the error message?

What version (and date, if it’s a development version) of RISC OS are you using?

Dave – I’m not ignoring you, I’ll try this again possibly today, maybe tomorrow. I’ve only had my xM on briefly to compile and test some code I wrote on the PC (and, believe it or not, in a text editor on my phone, yuck, please somebody give me a serial port and I’d do it on my Psion!). There’s only a small time frame between getting home from work (a few hours ago) and crashing (&now) when I get time to myself in order to geek out. <sigh>

Dave – followup.

RISC OS version by UtilityModule is:
MOS Utilities 5.19 (15 May 2012)

The microSD card is a 4GiB dual-partition. A FAT partition of around 120MiB, an ext3 partition of most of the rest of it, and about 200MiB at the end that appears to be unallocated. It is the microSD “test 4.25” that came supplied with the Beagle xM.

If a cmos file exists on the microSD card, flashing a new version results in the following:

Source file name: SCSI::HardDisc0.$.!Boot.Choices.CMOS

File size: 2052, object type: 1

Loaded file

Card IS High Capacity

Checking FATS…

FATs are consistent

…..

Finished

However, if a cmos file does not exist (I renamed it), then the following happens:

Source file name: SCSI::HardDisc0.$.!Boot.Choices.CMOS

File size: 2052, object type: 1

Loaded file

Card IS High Capacity

Checking FATS…

FATs are consistent

.SendSDMMCCommand timed out at the top

SendSDMMCCommand timed out at the top

Finished

Tried twice. Didn’t reboot, just ejected the card and renamed the cmos file. Behaviour is repeatable. Here, at least… ;-)

Hope this helps.

Best wishes,

Rick.

OK, thanks for the info, I’ll take a look.

If you’re looking at BBflash, dave, could I bother you with another bug report? We’ve found that overwriting an old 4Mb “riscos” ROM file with a newer compressed 2Mb one works fine, but then “rolling back” to a 4Mb one results in a corrupt SD card. I’m guessing the problem is in overwriting the 2Mb file with a 4Mb one. At the moment I’m simply advising manual roll-backs of the OS file, but if you’re looking at BBflash anyway, I figured I should report it.

OK, thanks, Andrew, I’ll look at that too.

Rick, have you got another micro SD or micro SDHC card, of a different type or make, that you can try?

I can’t reproduce your symptoms, though there are more things that I can try yet. I did have trouble initially writing some cards from one batch from one vendor, and the symptoms may be related.

I’ve just tried a sequence that probably mimics more accurately what you did, Rick. I wrote the cmos file, then MLO, u-boot.bin, boot.scr, uenv.txt and riscos. Next I renamed cmos as cmos2, and finally wrote cmos. It went without a problem. All files, read via a separate reader/writer, compared identically with the originals.

I’m using a SanDisk 16 GB micro SDHC in my BBxM. I don’t actually have any 4 GB micro SDHCs to try. All the other micro cards I have are micro SD, not SDHC.

Dave,

have you got another micro SD or micro SDHC card, of a different type or make, that you can try?

Not right now. I have a 4GiB card (Verbatim) and I was going to recreate the default Angstrom but 7zip didn’t want to unpack it. I might have another go this weekend.

I can’t reproduce your symptoms,

Not a surprise. Murph’s Law. ;-) I notice there’s one dot before the error message. Thus, if you have a debug build, I’ll be happy to give it a whirl and report back (assuming that one doesn’t work flawlessly just because).

I wrote the cmos file, then MLO, u-boot.bin, boot.scr, uenv.txt and riscos.

No.
The MLO, u-boot, uImage, etc are the originals from the card supplied with the board.
I added “riscos” (later renamed as “riscos_5-18” as 5.19 installed). The uEnv was copied then modified various times. A “user.txt” was created (I’ve never had to use a .scr file). The CMOS RAM was originally “rocmos” but is now called just “cmos” (might be in uppercase from RISC OS). Either way, nothing particularly unexpected.

By the way, doesn’t the internal bootloader require that MLO is the very first thing on the drive? Does !BBFlash enforce/ensure this?

Logically, it is a 4GiB allocated in three pieces: 1: A FAT32 partition of 118MiB. 2: A 3.29GiB Linux partition (I’d guess ext3 but Windows can’t tell that). 3: 235MiB apparently unallocated.

I ran “chkdsk” and it reported:

The type of the file system is FAT32.
Volume boot created 3/9/2011 1:11 PM
Volume Serial Number is E630-BB7D
Windows is verifying files and folders...
File and folder verification is complete.
Windows has checked the file system and found no problems.

Physically, it is a Kingston SDC4/4GB. Looks like a clone if you ask me… Anyway, the serial number is One One Four Six W Zero Eight Zero Eight Three N (written so it won’t be Googleable).

I’m using a SanDisk 16 GB micro SDHC in my BBxM.

Hehe, as microSDs are a little pricey over here, anything that big would go in my phone. I’m still hoping I’ll see a 32GiB one (though, frankly, the SonyEricsson Xperia Mini Pro (Android 2.3.4) is highly eccentric (borderline “just plain f’d”) when it comes to handling storage – you don’t expect to plug the phone in as a mass storage device, and have it crash/reboot while copying a large file (doing, I might add, some random damage to the filesystem in the process)).

Anyway, yes, by preference I get SanDisk. Usually class 4 (there’s little I do that demands faster, even the PVR writes slower than that). Failing that, I’ll buy Verbatim as I have had good results so far with them. I’m on the border about Transcend having had one of their USB things fail on me after ~5 months in the PVR (so much for lifetime warranties, huh?). Other brands (some of which sound made up in the kitchen of the nearest asian food joint) are avoided. Purely, simply, not touched. If you find a few gigabytes of data wiped out, you’re bound to be annoyed about it. It might be irreplacable photos, or a load of animé that is no longer around since the fall of MU. Whatever, if you have any desire to keep your data sane and safe, you’ll not buy the cheapest rubbish around.

Anyway, if you have a debug/test build, I’ll be happy to try it for you.

Best wishes,

Rick.

If it is one of the standard Kingston, Angstrom-preload cards that come with the BB, I confirm there shouldn’t be any card-specific problem, as I must have flashed and reflashed dozens of those.

By the way, doesn’t the internal bootloader require that MLO is the very first thing on the drive?

It is so rumoured.

Does !BBFlash enforce/ensure this?

Enforce or ensure: no. I don’t know of any sensible way to do this.

It works like this:

If a file is to be written and it already exists, the directory entry is re-used. This means the position doesn’t change as a result of using BBFlash.

If a file doesn’t already exist, the directory entry goes into the first free slot in the directory.

BBFlash writes the selected files in the order, top to bottom, as they appear in the main window. This means that, if you start from an empty card and do the most obvious thing – attempt to write all six in one session – they will go into the first six directory slots, in the order top to bottom as you see them in the main window.

So, although it doesn’t enforce or ensure the correct order on someone who’s messing about and doing something they shouldn’t, it attempts to do the correct thing.

The order changed between the first and second releases, so please ensure you use the current one: 0.02 (2012 March 31).