Towards BeagleBoard "CMOS RAM"

I wish I were going to the SAUG meeting tomorrow!

I’m honoured that you find the prospect so enticing :-)

Where do you live?

Well, it’d just nice to witness the news as it happens! Anyway, I live in Bristol – but unfortunately it’s a no go, as I can’t afford the time.

On the other hand, why does the CMOS file need a valid/correct timestamp?

As with any file, it can be useful to see when the information dates from.

Increment the creation day or hour every time the CMOS file is written. Should be more interesting.

You’ll have access to the source eventually. The version in CVS will have a proper modification date and time.

Sorry Dave, I didn’t want to push you into a direction. I hope to give suggestions how you can proceed more rapidly. If, as suggested, the timer initialisation routine is writing to the CMOS it can become difficult to read the time for the time stamp.

I’ve got the 2011-02-28 OMAP ROM from the ROOL Downloads pages and booted from it. “Save CMOS” from the Configuration window doesn’t save a file on the hard drive. Is that functionality in the ROM (whose date we know) or in the HardDisc4 image (which, in the case of my BB, is probably well out of date)?

Don’t we need to do *SaveCMOS <filename> now? I didn’t think the correct “Save CMOS” functionality had been included in the Configuration window yet.

Yes – thank you, Andrew, that works.

I wonder where I got the idea that the Configuration window’s “Save CMOS” works?

Great.

I guess we need to address the issue of the Configure window not doing it the new way at some point, but as it’s probably written in C then I shall have to leave that for someone else :-(

The “Save CMOS” option should save the file to <Choices$Write>.CMOS. However until I fixed it 6 weeks ago, it would have only saved the first 240 bytes instead of the full amount.

(Also while checking that I did check in that change, I’ve spotted that I’ve accidentally modified the Ursula version of the file and checked it into the main branch. Luckily it doesn’t look like it will cause any problems, although I’m not sure why we’re using the main branch anyway if the Ursula branch is better)

Aha, thanks Jeffrey, missed that change! Just downloaded the HardDisc4 tarball and updated the Configure Runimage file. I should do a complete overwrite of !Boot with the ‘Newer’ option, I guess.

Is this a recent change to !Boot? I’m using an old-ish HardDisc4 image from at least a couple of months back and the CMOS file was written fine without me doing an update.

However until I fixed it 6 weeks ago, it would have only saved the first 240 bytes instead of the full amount.

I’d guess the change is about 6 weeks old :-)

Previous versions would save a CMOS file when you clicked on “Save CMOS” but it was only 240bytes instead of the new 2k size.

Hmm… will check the size of the file I used with SDCreate last time – I think I kept a copy.

244 bytes, which is what I’m also getting with the 28 Feb ROM.

As well as the ROM, you need the new version of !Configure, which is in the HardDisc4 tarball.

Of course – how dopey of me. Thanks.

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?

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

Dave – I still do have your email and its attachments. Because I’m now using a recent ROM which incorporates your work, it perhaps wouldn’t achieve much if I were to test old code now. However, if there’s something there which wasn’t incorporated, then I’ll have a look if you let me know. And I shan’t offer to further test anything related until I’m ready to actually give it a go, i.e. spare SD card(s) and backup boot drive etc. Cheers – hope that’s OK with you.

hope that’s OK with you.

Yes, the need vanished long ago.

However until I fixed it 6 weeks ago, it would have only saved the first 240 bytes instead of the full amount.

I should do a complete overwrite of !Boot with the ‘Newer’ option, I guess.

According to the CVS log entry I don’t think that’s necessary.

244 bytes

Any ideas why I get file sizes 4 bytes greater than expected (with both versions of Configure)? i.e. 244 and 2052.

I’ve just emailed code@riscosopen.org with an updated Res file to match VersionNum (2.03)

According to the CVS log entry I don’t think that’s necessary.

Although it might still be a good idea to update everything, in case there have been improvements/fixes to other components.

Any ideas why I get file sizes 4 bytes greater than expected (with both versions of Configure)? i.e. 244 and 2052.

Originally Configure/*SaveCMOS only used to store the 240 bytes of CMOS, but later it was updated to also save the value of <Boot$OSVersion>. This is why “new” versions (from about RISC OS 4 onwards, I think) always save files which are 4 bytes bigger than the actual CMOS size.

I’ve just emailed code@riscosopen.org with an updated Res file to match VersionNum (2.03)

Another component that needs updating to have the version number baked into the messages file, then!

Another component that needs updating to have the version number baked into the messages file, then!

I didn’t know what to do with the messages file, as there don’t seem to be any version number references. (I did see that the file was referred to in v.1.2 of VersionNum.)

Jeffrey:

Here’s an (untested!) assembler function that should work when called from C:

; int readtimefornvram(struct rtctime *)
; Reads BCD time into given rtctime struct
; Returns zero on success, nonzero on failure
readtimefornvram
  MOV a2, a1
  ADRL a1, RTCDevice
  LDR a3, HALInitialised
  CMP a3, #0
  ADREQL a3, IIC_DoOp_Poll
  LDRNE a3, OSentries+4*OS_IICOpV
  B RTCReadTime

Shouldn’t there be something in a4 – “kernel workspace ptr”? Where do I get that from?

(Sorry, TextSeek falls over when given a large amount of stuff to search through, especially when it includes binary; and the linkages to RTCRead and RTCWrite aren’t obvious.)

I’ve been having an “interesting” time calling that code. I made it into a back door in my NVMemoryRead code (call with length <= 0 and it calls the above code instead). It works sometimes – depending on what lines of code follow the call.

Sorry, TextSeek falls over when given a large amount of stuff to search through, especially when it includes binary

Also grep has just exited with “The area of memory reserved for the system heap is full” which means that neither of the meaningful RISC OS search tools works.

Do you think this means that the included grep source needs ARMv7 compatibility modifications?