Another confirmed case of firmware bit rot - page 3 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 [3] 4 5   Go Down

Another confirmed case of firmware bit rot

  • 44 Replies
  • 6279 Views
*

Offline reyalp

  • ******
  • 13387
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.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 13387
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.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 13387
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.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4426
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.
Logged
*

Offline reyalp

  • ******
  • 13387
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)
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 13387
Re: Another confirmed case of firmware bit rot
« Reply #25 on: 26 / November / 2020, 20:41:26 »
I'm currently missing the following dumps (this isn't important, just avoiding flooding IRC)

a2000/sub/100a/PRIMARY.BIN
a610/sub/100d/PRIMARY.BIN
d10/sub/100b/PRIMARY.BIN
g11/sub/100h/PRIMARY.BIN
ixus1000_sd4500/sub/100b/PRIMARY.BIN
ixus220_elph300hs/sub/101d/PRIMARY.BIN
ixus70_sd1000/sub/101a/PRIMARY.BIN
ixus75_sd750/sub/101b/PRIMARY.BIN
ixus800_sd700/sub/101a/PRIMARY.BIN
ixus850_sd800/sub/100d/PRIMARY.BIN
s2is/sub/100i/PRIMARY.BIN
sx500is/sub/100e/PRIMARY.BIN
g5x/sub/110a/PRIMARY.BIN
« Last Edit: 26 / November / 2020, 20:59:35 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: Another confirmed case of firmware bit rot
« Reply #26 on: 26 / November / 2020, 20:52:01 »
https://drive.google.com/drive/folders/1SvlgOcHuthr71w3KfI4BPK5TWpuCK5wB?usp=sharing


Dumps for:
- g5x 1.10a
- ixus220 1.01d
- ixus1000 1.00b
- sx500 1.00e

Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline fe50

  • ******
  • 3132
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: Another confirmed case of firmware bit rot
« Reply #27 on: 19 / December / 2020, 05:03:24 »
Logged
*

Offline Caefix

  • *****
  • 596
  • Sorry, busy deleting test shots...
Re: Another confirmed case of firmware bit rot
« Reply #28 on: 24 / February / 2021, 14:51:06 »
Logged
All lifetime is a loan from eternity.
*

Offline reyalp

  • ******
  • 13387
Re: Another confirmed case of firmware bit rot
« Reply #29 on: 24 / February / 2021, 16:17:54 »
Quote from: Caefix on 24 / February / 2021, 14:51:06
:o https://forum.chdk-treff.de/viewtopic.php?f=3&t=3664&p=32014#p32014
If they got a firmware dump after the error, please ask them to upload it somewhere.

0xff810000 in the message means the chunk starting at 0xff810000 (meaning, the main ROM code), not that the difference is at that exact location.
Logged
Don't forget what the H stands for.
Pages: 1 2 [3] 4 5   Go Up
« previous next »
 

Related Topics