chdk in the DIGIC6 world - page 16 - General Discussion and Assistance - CHDK Forum supplierdeeply

chdk in the DIGIC6 world

  • 155 Replies
  • 68275 Views
*

Offline reyalp

  • ******
  • 11755
Re: chdk in the DIGIC6 world
« Reply #150 on: 10 / June / 2018, 00:50:54 »
Advertisements
Later cameras do more stuff in their avcore initialization routines, I don't know if those affect the success of the method I found.
It would be great if anyone could try this workaround on other models (it involves hooking TricInitTask, plus doing the eventflag manipulation, as described above).
Thanks for investigating this. I finally got around to trying this on g7x, following the sx280 example. g7x does not have a direct equivalent of M10 110d fc07ed70.

I initially thought it worked, but it turns to *sometimes* have similar but not identical problems.

Without the change, hybrid auto crashes immediately, and the orientation sensor sometimes freaks out alternating between 0 and 90.

With the change, the orientation sensor problem still happens sometimes, and if it's happening, hybrid auto becomes unresponsive or eventually crashes, but not instantly. If the orientation sensor doesn't freak out, hybrid auto seems to work fine. I got the impression the orientation sensor freakout happens more often if the camera is moving or off level in boot, but it could be random.

I made finsig_thumb2 put task_TricInitTask and SetEventFlag in stubs_entry.S by default.

edit:
Code attached.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3819
Re: chdk in the DIGIC6 world
« Reply #151 on: 10 / June / 2018, 16:21:41 »
With the change, the orientation sensor problem still happens sometimes, and if it's happening, hybrid auto becomes unresponsive or eventually crashes, but not instantly.
That's weird. Neither of my D6 cams show anything similar.
I don't think the orientation sensor has anything to do with the codec core.
A couple of thoughts:
- When the issue occurs, does the IS continue to work normally? It's possible that some (or all) orientation related data is retrieved from the IS system.
- If you'd like to investigate codec core related problems/crashes, try using (or hooking) the logger functions used in the ARM side tasks: sub_FC351FD6 (regular log), sub_FC352036 (error log).


*

Offline reyalp

  • ******
  • 11755
Re: chdk in the DIGIC6 world
« Reply #152 on: 10 / June / 2018, 17:34:08 »
That's weird. Neither of my D6 cams show anything similar.
I don't think the orientation sensor has anything to do with the codec core.
FWIW, the orientation sensor issue is confirmed on g7x and sx60 (https://chdk.setepontos.com/index.php?topic=12532.msg128897#msg128897). You may need to have a still image present at boot to see it. I always assumed it was a hardware initialization issue, but it agree it's probably different hardware.

I thought I had confirmed it on sx710 as well, but wasn't able to reproduce it just now (no FI2 fix applied)
Don't forget what the H stands for.

*

Offline Ant

  • ****
  • 416
Re: chdk in the DIGIC6 world
« Reply #153 on: 03 / February / 2019, 16:05:12 »
@a1ex  implemented MMIO trace that can be usefull for CHDK development.

But on my EOS M3 it works only in playback mode. Probably because of intensive traffic in EVF mode.

This also can be used to intercept rom code execution. But the minimum MPU region size is 32 byte and there is only one unused.
« Last Edit: 04 / February / 2019, 09:34:02 by Ant »


*

Offline srsa_4c

  • ******
  • 3819
Re: chdk in the DIGIC6 world
« Reply #154 on: 15 / February / 2019, 19:04:08 »
a1ex implemented MMIO trace that can be usefull for CHDK development.
(...)
This also can be used to intercept rom code execution. But the minimum MPU region size is 32 byte and there is only one unused.
Attached is a "library" that allows intercepting code, using parts of a1ex's code and other ML snippets.
It is not perfect and has not been tested for heavy usage. I think it does not handle prefetch aborts that are not handled by our code - maybe because the exception handler does not disable interrupts.
It uses the last MPU region (which is actually used by fw on newer cams such as my m10) with fixed size (32 bytes).
For exception stack, it uses an arbitrary location in the 0xbfe10000 area which is TCM on newer cameras and some unknown RAM on others. That may need to be adjusted on cameras other than m10 and sx280. See the variable aborttrick_sp.
To use it, select a part of firmware code that does not have a branch target inside and make a copy of it. The intercepted area needs to start at an address divisible by 32, the area is 32 bytes long.
Use the following function to register your replacement code:
install_aborttrick(uint32_t original_loc, uint32_t new_loc)
where original_loc is the start of the intercepted area and new_loc is where code execution will continue.
« Last Edit: 24 / February / 2019, 12:27:31 by srsa_4c »

*

Offline srsa_4c

  • ******
  • 3819
Re: chdk in the DIGIC6 world
« Reply #155 on: 24 / February / 2019, 12:27:14 »
Modified the aborttrick library: cases where the first half of a 32bit instruction is outside the protection region were not handled. Such cases need the following registration function:
install_aborttrick_customloc(uint32_t regionstart, uint32_t original_loc, uint32_t new_loc)
Where regionstart is the 32 byte aligned start of the protection region, original_loc is the address of the first instruction and new_loc is the start of the replacement code.

 

Related Topics