Towards BeagleBoard "CMOS RAM"

OK, what’s the story with “CMOS RAM” in OMAP3 5.18?

I’ve (belatedly) flashed another microSD card with 5.18 stable and all the other files from the working 5.16 card. The BBxM just sits there waiting for the boot drive to be ready. I have a rotating drive (:4); the BBxM is waiting for :0.

It doesn’t even appear to read the CMOS file from the card.

Is the CMOS read functionality still in there?

I flashed the card on the BBxM itself, so it must be able to read and write the card.

Dave,

I have the same set up as you with a hard disc , drive 4/SCSI:4, and I’m using RISC 5.19 OK and also have used 5.18 OK.

How are you writing the files to your card, is it with SDCreate or manually.

If with SDCreate which version are you using, 1.24 is the latest and resolves some issues.

If manually then you should make sure you write the correct MLO file to the card first if you need to update it.

Basically you have to copy and end up with the following files on the card:

MLO
U-BOOT/BIN
BOOT/SCR
UNEV/TXT
RISCOS
CMOS

Doug

OK, thanks. Does that mean that the MLO file has been recently updated?

I used BBFlash to write all 6 files to the card: the new RISCOS image, and the other five files from my current 5.16 working system.

I think the order in which the files are written is important. From the ARMini micro SD card image download:

IMPORTANT: The MLO file must be the first file stored on the disc, so if you erase the contents of your SD card, please put the MLO file on first.

Dave

As I and Chris have stated it is important to make sure that the MLO file is the first written to the card.

SDCreate writes the files in the order that I set out.

I also believe that the latest MLO file also has something to do with the way that it looks for the other things in particular the UNEV/TXT file. I think SDCreate has the latest MLO built in so you could create a card using SDCreate and extract it or just use SDCreate to build your image and use that as this should be a one off change due to changes in the way 5.18 works.

I believe the uenv.txt file is read by uboot.bin, and it is that that has been updated, rather than the MLO file. Older versions used boot.scr.

Note that according to sprow, both the boot.scr and uenv.txt files have been updated to load the CMOS settings from the card, assuming you’re using a recent SDcreate. I’m afraid I haven’t looked at a recent version, as we look after our own SD images here, and duplicate them separately.

Certainly we had a few issues with older ARMini users running early uboot.bin files needing updates to correctly use uenv.txt – hence we put out the ARMini micro-SD image that Chris refers to.

OK, thanks, everybody. I’m now running 5.18 on the xM.

I intend to modify BBFlash so that it writes the files in the same order by default.

Next problem: updated configuration isn’t written to the CMOS file, it seems. I checked by clearing the “Allow windows off-scren” boxes, clicked “Set”, and re-booted. The settings were not written to the CMOS file; the CMOS file still has yesterday’s date/time stamp. RISC OS is 5.18 (16-Jan-12).

If you have the ‘cmos’ file on SD card as your ‘CMOS RAM’ then from version 5.18 the ‘CMOS save’ that occurs on changing configuration only saves to the widget. You need to manually copy the ‘CMOS’ file from where it is created within the boot stucture to the SD card yourself.

I think this is correct: the reason is that RISC OS can corrupt the SD card when it writes to it. Linux occasionally corrupts the SD card when writing to it and there are lot more people out there to fix Linux things than RISC OS!

the reason is that RISC OS can corrupt the SD card when it writes to it

But the source of the corruption was found and fixed.