GitLab

Variant of previous fix but that doesn't corrupt R0.
Retagged as SDCMOS-0_12.

Might fix problem of time jumping backwards on Pis fitted with RTC expansion hardware.

Version 0.12. Tagged as 'SDCMOS-0_12'

Just one message swapped out.

Version 0.11. Tagged as 'SDCMOS-0_11'

Logic is now
 * if NVRAM device is present, go dormant
 * if CMOS file is absent, go dormant
 * otherwise shadow it
or if StoreInHAL, behave as before.
Unrelated, added Hdr prefixes to includes so they can be double clicked on to open. Swap out OS_Word subreasons for symbolic names.

Version 0.10. Tagged as 'SDCMOS-0_10'

Version 0.09. Tagged as 'SDCMOS-0_09'

As the penny pinchers didn't fit a hardware real time clock, on a CMOS write (or desktop shutdown) the HAL CMOS is stamped with the current time. On power up, if the time is found to be 1970 (the kernel default) the last shutdown time is used instead - while this time is going to be incorrect it should at least ensure the time doesn't go backwards in the moments before NetTime manages to find a time server.

Version 0.08. Tagged as 'SDCMOS-0_08'

Detail:
  s/sdcmos - Previous change accidentally resulted in the removal of the branch to the termination code when the initialisation callback fails to find a CMOS file, resulting in the module claiming ByteV and causing shenanigans on CMOS saves.
Admin:
  Tested on BB-xM
  Fixes issue reported on forums with Configure plugins throwing errors:
  http://www.riscosopen.org/forum/forums/11/topics/1329


Version 0.07. Tagged as 'SDCMOS-0_07'

Detail:
  s/sdcmos - Reworked initialisation a bit to allow the code to look for CMOS files in multiple places.
  Specifically, non-StoreInHAL variants now look for both $.CMOS and $.!Boot.CMOS.
  This allows the special FAT+FileCore partitioned SD cards to be used with more than just the Raspberry Pi; specifically Pandora+TouchBook, where not requiring USB or a 2nd SD card for a FileCore partition is desireable
Admin:
  Tested on Pandora


Version 0.06. Tagged as 'SDCMOS-0_06'

Detail:
  s/sdcmos - MyByteV now preserves R7 when StoreInHAL is true, preventing it from being corrupted
Admin:
  Tested on Raspberry Pi with high processor vectors
  Fixes Boot:Choices.Internet.Startup being left as filetype text, due to InetSetup's InternetEnabled pointer being corrupted and left pointing at &000000C3


Version 0.05. Tagged as 'SDCMOS-0_05'

Detail:
  s/sdcmos - The previous change to remove the filetype check when StoreInHAL={TRUE} also had the side-effect of removing the check for whether the file exists.
  This resulted in the module not terminating itself if the file was absent, and consequently all attempts to write to CMOS would generate a 'file not found' error, causing assorted bits of code to malfunction.
Admin:
  Tested on Raspberry Pi


Version 0.04. Tagged as 'SDCMOS-0_04'

Detail:
  Too many people were updating the ROM image file (for example using other
  OSes?) such that its filetype wasn't one of the two SDCMOS considered to
  be valid - EPROM or DOS. This resulted in CMOS support apparently not being
  functional for them. Since the filename tested for ("riscos/img") is
  probably quite a strong indicator that it really is a RISC OS ROM image,
  I think it's safe enough to remove the filetype check altogether.
Admin:
  Tested on a Raspberry Pi

Version 0.03. Tagged as 'SDCMOS-0_03'

Retagged as 'SDCMOS-0_02'

Detail:
  For the Raspberry Pi, the CMOS RAM is embedded within the ROM image, since
  the default bootloader isn't flexible enough to load it from a separate
  file (and we need to know CMOS contents before modules like SDFS have
  initialised). This functionality is enabled by the build switch StoreInHAL
  passed in via the Makefile. Unrelatedly, removed a double free of the module
  workspace on finalisation.
Admin:
  Tested on Raspberry Pi.

Version 0.02. Tagged as 'SDCMOS-0_02'

Detail:
  This module intercepts ByteV so every time a CMOS bte is written, it
  saves the CMOS to the file "CMOS" on whichever card was in drive SDFS::0
  when the module initialised (which will normally be the boot card, since
  the module would not normally be reinitialised after ROM initialisation).
  If you don't want to be nagged to change cards every time the CMOS is
  written, you have two options:
  * Delete the CMOS file from your boot SD card, and update your boot
    script so it doesn't try to load it
  * Use *Unplug SDCMOS
  In either case, you will then require an EEPROM carrier board if you want
  your settings to persist across a reset.
Admin:
  Tested on beagleboard and beagleboard-xM, both with and without a CMOS
  file on the boot card.