CMOS RAM on Pi
Chris Hall (132) 3554 posts |
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. |
Jeffrey Lee (213) 6048 posts |
*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) |
Chris Hall (132) 3554 posts |
*FX 0 and the task manager should give the ROM build date Should, did at one time, but currently do not. |
Steve Revill (20) 1361 posts |
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… |
Jeffrey Lee (213) 6048 posts |
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. |
Steve Revill (20) 1361 posts |
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! |
Jeffrey Lee (213) 6048 posts |
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. |
Jeffrey Lee (213) 6048 posts |
The ROM build date reporting should now be fixed. |