GitLab

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.