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

Another confirmed case of firmware bit rot

  • 44 Replies
  • 3559 Views
*

Offline reyalp

  • ******
  • 13147
Re: Another confirmed case of firmware bit rot
« Reply #40 on: 09 / March / 2021, 12:09:41 »
Advertisements
The first patch doesn't work, for what in hindsight should have been an obvious reason...
Quote
It's notable that all the addresses end in aa4. The space between the addresses doesn't show an obvious pattern. They're multiples of 4k
They all land on the same index :-[

For the instructions, this can be worked around by using the LDR pc trick to jump out one or more cache lines earlier.

For data, one will have to be patched by the instructions that reference it instead.

We could also lock down more segments, but that seems undesirable.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4396
Re: Another confirmed case of firmware bit rot
« Reply #41 on: 09 / March / 2021, 12:21:10 »
They all land on the same index :-[
Oops. Are you saying that addresses, that have certain bits in common, can't be cached at the same time?

*

Offline reyalp

  • ******
  • 13147
Re: Another confirmed case of firmware bit rot
« Reply #42 on: 09 / March / 2021, 13:25:19 »
Oops. Are you saying that addresses, that have certain bits in common, can't be cached at the same time?
Yes. If you look at cache_get_content, it uses "index" to identify where in the cache it is. The tag (generated from remaining bits of the address) identifies which of the possible lines are actually stored. The nest of macros is hard to follow, so I used the attached to verify.

cache_is_patchable actually checks for this, but the check in cache_fake is commented out, and anyway, I didn't check the result.

In normal operation, you could have up to 4 colliding addresses.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13147
Re: Another confirmed case of firmware bit rot
« Reply #43 on: 13 / March / 2021, 02:24:12 »
For the instructions, this can be worked around by using the LDR pc trick to jump out one or more cache lines earlier.

For data, one will have to be patched by the instructions that reference it instead.
I posted a new build using this method: https://forum.chdk-treff.de/viewtopic.php?f=3&t=3664&p=32042#p32042

Additionally, I added calls to cache_is_patchable for each address. I verified that this seems to behave as expected on D10.

I used the cache-calc.c to verify each patch falls in a different index. Note, cache size is hard coded to 8k in that file, it would need to be changed for cameras with different size caches (digic 5 I think has 32k)

Since we can't patch all the data locations, I modified the firmware CRC file to skip all the patched areas. make-fw-crc.py is updated to support this in trunk 5781.

g11 and d10 test patch attached for reference.
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 13147
Re: Another confirmed case of firmware bit rot
« Reply #44 on: 15 / March / 2021, 16:39:12 »
Looking for something else, I noticed there were two previous instances involving G11 back in 2010:
https://chdk.setepontos.com/index.php?topic=5322.0
https://chdk.setepontos.com/index.php?topic=5279.0

Unfortunately, neither provided a firmware dump. The first seems plausibly like firmware damage. The second involved loading the wrong sub.
Don't forget what the H stands for.

 

Related Topics