CMOS RAM on Pi

The new ROM image, with ability to R/W CMOS RAM info into the rom image has a few issues:

1. On start up the datestamp of the ‘riscos.img’ file is changed from 16th July to 1st Jan 1980

2. If you run !Boot you get the configuration window but if you click on ‘Discs’ you get ‘Invalid object ID (0×11213) (0×45801210) (0×1)’.

3. Setting the number of CDs from 1 to 2 however works (and then resets the datestamp of the ‘riscos.img’ file to current time).

4. Lo and behold on rebooting there are indeed two CD drive icons again.

One diagnostic has now gone – the datestamp of the file ‘riscos.img’. The new ROM announces itself as 9th July 2012 – might be a good idea to make the autobuilder give the ROM the build date not the MOS Utilites date? (We’ve had this discussion before!)

Incidentally no-one had mentioned that CD drives work on the Pi. I plugged a USB CD drive in and just clicked on the icon and the directory opened up.

The new ROM announces itself as 9th July 2012 – might be a good idea to make the autobuilder give the ROM the build date not the MOS Utilites date? (We’ve had this discussion before!)

*FX 0 and the task manager should give the ROM build date. Maybe not the desktop startup banner though; I’ll check tonight. Or maybe there’s something else that’s throwing it off (e.g. I think I made the code verify the ROM checksum before trusting the date stored in the footer, so SDCMOS may need updating to keep the checksum valid)

*FX 0 and the task manager should give the ROM build date

Should, did at one time, but currently do not.

It’s possible (but maybe unlikely) the problem with FX0 is on our autobuild cloud server. It may be that because I restarted the server from an image it thought it was still the time/date from when it was imaged. But this seems unlikely because I’m sure it’s configured to use network time…

…yep, the cloud server has the right time/date. However, will RPCemu (which is running the builds) have that too? Hmmm…

However, will RPCemu (which is running the builds) have that too?

It should do. I’m sure the code in RPCEmu which pokes the time/date into the emulated CMOS/clock chip has been around for well over a year.

I’m still sticking to my “SDCMOS not updating ROM checksum” theory.

Cheers, Jeffrey. I did think it was an outside chance that the autobuilder was itself part of the problem, but it was worth a quick look!

It looks like the problem is that the HAL assumes the ROM has been loaded at physical address &00000000, but that’s no longer true – we’re getting loaded at &8000. So when it works out how much memory to clear and report to the OS, it ends up zapping the extended ROM footer which contains the build date. SDCMOS not updating the ROM checksum doesn’t affect things, since the code in the kernel ignores the main ROM footer and only looks at the CRC of the extended footer.

I’ll have a go at sanitising the startup code a bit, since it doesn’t look like anyone’s currently assigned to that task.

The ROM build date reporting should now be fixed.