Introduction[]
The factory firmware is stored in flash memory built into the camera. On rare occasions, this memory can suffer corruption due to age ("bit rot") or other defects unrelated to CHDK.
In some cases, it is possible to repair these errors using CHDK or Canon Basic.
Known cases[]
- An A710IS which crashed in rec mode was found to have one bit flipped and was successfully repaired by re-writing the affected byte. Forum thread
- An SX260 with a non-functional jogdial was found to have one bit flipped. This was worked around by adding the correct code to the CHDK jogdial hook. Forum thread
- A G11 which crashed on startup, except when started in clock mode by holding SET + PLAY. Five words in ROM with addresses ending in AA4 were found to have some 1s changed to 0, implying flash was written, rather than faded due to age. Root cause unclear, error reported after lens replacement and installing CHDK. Worked around using cache lockdown fix or bypass the affected words. CHDK forum thread, CHDKDE forum thread
Additionally, the onboard memory memory is used for camera settings, which have been found to be corrupted and repaired in at least on case. Forum thread
Detecting corruption[]
As of CHDK 1.5 build 5535, CHDK has functionality to detect corruption in some parts of the firmware for most supported models. By default, this check is only done on the first boot after a fresh install. A progress bar will briefly show "ROM CRC". If corruption is detected, a dialog starting with "Possible Canon ROM corruption" will appear and prompt to dump the firmware.
The check can be controlled in the CHDK menu in Miscellaneous - Debug settings - Checksum ROM at boot.
Because the onboard flash also contains dynamic data like settings and camera specific calibration, this built in check only applies to a subset (typically 20-75% depending on model) of the firmware believed to be constant. If a camera behaves unexpectedly while not running CHDK, but corruption isn't reported, you can make a dump using the Canon Basic dumper.
You can compare a dump from your camera with dumps from the dumps archive, but analysis is required to identify whether differences are corruption or are areas that are expected to vary between cameras.
Reporting corruption[]
If you see the "Possible Canon ROM corruption" message or otherwise suspect corruption, please report it in the forum.
Developer information[]
Overview[]
The checksum system works as follows
- tools/make-fw-crc.py uses information from CHDK stubs_entry.S to identify known constant parts of the firmware, including main ROM code, code and data copied to RAM, and code and data used by additional processor cores on digic 6 and later. It then calculates crc32 checksums for the identified regions using firmware dumps
- The rebuild-firmware-crc rule uses make-fw-crc.py to generate platform / sub / firmware_crc_data.h for each non-copied platform sub. The firmware_crc_data.h file contains data for each compatible sub (as defined by copy information in camera_list.csv) for which firmware dumps are available. Missing dumps trigger a warning, but not an error, because dumps are currently not available for some copied subs.
- Note copied platforms like sx270 / sx280 are not handled specially. They use the checksums from the non-copied port. It is believed that subs of these platforms with same version have identical code, so for example sx270 102c has identical checksums to sx280 102c
- The firmware_crc_data.h files are checked in, to allow building without dumps present.
- Each firmware_data_crc.h is compiled into the core for each unique build.
- The checksum check is done by modules/firmware_crc.c (fwcrc.flt), which is invoked from spytask at startup if the config option check_firmware_crc is non-zero.
- The default values of check_firmware_crc is 1, which causes the check to be run at startup and check_firmware_crc be cleared, meaning the check is only run on the first boot of a fresh config.
Updating firmware_crc_data.h[]
- rebuild-firmware-crc should be run when a new port is created, after rebuild-stubs has been run successfully. If it cannot be run for example because a dump is not available, or a suitable python environment is not configured, a firmware_crc_data.h containing only #define FIRMWARE_CRC_DISABLED 1 can be used to disable the check.
- batch-rebuild-firmware-crc should be run if make-fw-crc.py has been updated in a way that affects the output
- Before checking changes in, check to ensure there aren't changes due to missing firmware dumps compared to those used for the currently checked in source.