Another confirmed case of firmware bit rot - page 3 - General Discussion and Assistance - CHDK Forum

Another confirmed case of firmware bit rot

  • 24 Replies
  • 1390 Views
*

Offline reyalp

  • ******
  • 12731
Re: Another confirmed case of firmware bit rot
« Reply #20 on: 02 / July / 2020, 00:44:11 »
Advertisements
Updated patch
* Moved the important messages to lang strings
* Add a dummy firmware_crc_desc to core/firmware_crc_data.c, which can be used by defining FIRMWARE_CRC_DISABLED in platform / sub / firmware_crc_data.h. This allows building in cases where the real data isn't available. I didn't make it an OPT_ since it's meant to be a temporary, port specific workaround. The check will still be run, it will just check 0 blocks.

I think this is pretty much done, so I'll plan to check it in if there aren't objections. I successfully did a batch build.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 12731
Re: Another confirmed case of firmware bit rot
« Reply #21 on: 03 / July / 2020, 00:27:57 »
Checked in, trunk 5535.

If you update, the check should run on the first boot, since even though it's not a clean install, the config value is new and starts with the default value.

I would obviously be interested to know if it breaks anything, or if anyone sees checksum failures.

For developers:
The rebuild-firmware-crc rule should only need to be run if a new port is added or additional ranges are added to the checks. If you run batch-rebuild-firmware-crc, you should watch out (check svn diff) for subs added or removed due to not having the same set of dumps that I had.

The script requires python3. It shouldn't require any nonstandard packages or have other unusual requirements. If you don't have python available (it could be inconvenient on windows) and need to build a new port, you can create a firmware_crc_data.h with just #define FIRMWARE_CRC_DISABLED 1. You should not copy a firmware_crc_data.h from another port.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 12731
Re: Another confirmed case of firmware bit rot
« Reply #22 on: 03 / July / 2020, 21:00:38 »
I added a page to the wiki https://chdk.fandom.com/wiki/Canon_Firmware_Corruption mainly to be able to link it from the FAQ and give people a better chance of finding useful results in search.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4285
Re: Another confirmed case of firmware bit rot
« Reply #23 on: 14 / August / 2020, 18:23:08 »
I have a camera that I specifically bought for suspected firmware corruption. It's an a490. I fixed the corrupted byte (bit) approx. 2 years ago. Today I started having the same kind of crash the camera was originally showing. I dumped the firmware and found ... no difference to the original firmware. But, the romlog indicated that the same bit might act up again.
I flashed the corrupted word again and the issue is now gone.

So, bits that only start deteriorating do not necessarily show up in a dump.


*

Offline reyalp

  • ******
  • 12731
Re: Another confirmed case of firmware bit rot
« Reply #24 on: 15 / August / 2020, 02:05:46 »
Hmm, saw this a while back https://twitter.com/whitequark/status/1287628941084303552

Maybe not directly relevant, but flash going a bit random as at fails seems to be a thing. If it happens again, it would be interesting to know if running the CRC check a few times sees it, (if the camera boots far enough to run it)
Don't forget what the H stands for.

 

Related Topics