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

Another confirmed case of firmware bit rot

  • 44 Replies
  • 17629 Views
*

Offline reyalp

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

Offline srsa_4c

  • ******
  • 4451
Re: Another confirmed case of firmware bit rot
« Reply #41 on: 09 / March / 2021, 12:21:10 »
Quote from: reyalp on 09 / March / 2021, 12:09:41
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?
Logged
*

Offline reyalp

  • ******
  • 14134
Re: Another confirmed case of firmware bit rot
« Reply #42 on: 09 / March / 2021, 13:25:19 »
Quote from: srsa_4c on 09 / March / 2021, 12:21:10
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.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14134
Re: Another confirmed case of firmware bit rot
« Reply #43 on: 13 / March / 2021, 02:24:12 »
Quote from: reyalp on 09 / March / 2021, 12:09:41
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.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14134
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.
Logged
Don't forget what the H stands for.
Pages: 1 2 3 4 [5]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal