chdk in the DIGIC6 world - page 16 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 11 12 13 14 15 [16] 17 18 19 20 21   Go Down

chdk in the DIGIC6 world

  • 201 Replies
  • 131019 Views
*

Offline reyalp

  • ******
  • 13673
Re: chdk in the DIGIC6 world
« Reply #150 on: 10 / June / 2018, 00:50:54 »
Advertisements
Quote from: srsa_4c on 26 / March / 2018, 18:59:17
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.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4447
Re: chdk in the DIGIC6 world
« Reply #151 on: 10 / June / 2018, 16:21:41 »
Quote from: reyalp on 10 / June / 2018, 00:50:54
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).

Logged
*

Offline reyalp

  • ******
  • 13673
Re: chdk in the DIGIC6 world
« Reply #152 on: 10 / June / 2018, 17:34:08 »
Quote from: srsa_4c on 10 / June / 2018, 16:21:41
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)
Logged
Don't forget what the H stands for.
*

Offline Ant

  • *****
  • 508
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 »
Logged
*

Offline srsa_4c

  • ******
  • 4447
Re: chdk in the DIGIC6 world
« Reply #154 on: 15 / February / 2019, 19:04:08 »
Quote from: Ant on 03 / February / 2019, 16:05:12
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 »
Logged
*

Offline srsa_4c

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

Offline srsa_4c

  • ******
  • 4447
DIGIC 4
« Reply #156 on: 15 / June / 2019, 16:19:27 »
Just a quick note.
I found Xtensa code in DIGIC 4+ firmware dumps. I have no idea what the additional core (cores?) is for, and I don't yet know where it is initialized. Those blobs have no DryOS signature, so they could run some other OS or even no OS. Seems at least partially standard little endian Xtensa, code parts can be identified by searching for the 0x1d, 0xf0 byte sequence (retw.n instruction).
edit:
In vanilla DIGIC 4 also...

edit2:
The blob I looked up is related to the "MechaCPU". I always thought that the MechaCPU refers to something outside the DIGIC. Apparently, not.
« Last Edit: 16 / June / 2019, 04:44:57 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 13673
Re: DIGIC 4
« Reply #157 on: 16 / June / 2019, 15:55:32 »
Quote from: srsa_4c on 15 / June / 2019, 16:19:27
edit2:
The blob I looked up is related to the "MechaCPU". I always thought that the MechaCPU refers to something outside the DIGIC. Apparently, not.
That was my impression too, at least in terms of whether it shared address space (whether it's physically on the Digic SOC is probably irrelevant) Maybe it's transferred to MechaCPU?

Modern cameras (elph130 = d4, sx710 = d6) have filenames like MechaCPUFirmTransfer.c

There are also event procs like "MechaCPUMemoryDump" "MechaCPUMemoryWrite"

D10 (older digic 4) does not have these.

DSLRs have the MPU https://www.magiclantern.fm/forum/index.php?topic=17596.0 which is apparently a Tx19a MIPS in a separate package.

edit:
There are also references to I2c. On SX710, MechaCPUMemoryDump seems to be noop. On elph130 it looks like real code. SX710 has "MechaCpuA Firm Ver." and "MechaCpuB Firm Ver."
« Last Edit: 16 / June / 2019, 17:12:00 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4447
Re: DIGIC 4
« Reply #158 on: 16 / June / 2019, 17:09:34 »
Quote from: reyalp on 16 / June / 2019, 15:55:32
That was my impression too, at least in terms of whether it shared address space (whether it's physically on the Digic SOC is probably irrelevant) Maybe it's transferred to MechaCPU?
It seems to have a data(?) RAM area above 0xc0270000, length 0x2000. There is 'life' in it around offset 0x1900 (on ixus150), bytes are changing. There is no Xtensa code there.
It's also possible that this MechaCPU is not Xtensa, it's just fed from the same ROM blob that has Xtensa code.

I have a feeling that they might use Xtensa as video (and later audio) codec, just like they do in D6 and above. They introduced compressed audio "out of nowhere" on later D4+ cams, which is unlikely to be done on a separate chip.

Quote
DSLRs have the MPU https://www.magiclantern.fm/forum/index.php?topic=17596.0 which is apparently a Tx19a MIPS in a separate package.
Used to be tx19a, but they use other MCUs lately (Renesas). I think the old PowerShot SubCPUs and the new ones in EOS M3 and M10 are also Renesas.
Logged
*

Offline reyalp

  • ******
  • 13673
Re: DIGIC 4
« Reply #159 on: 16 / June / 2019, 18:45:58 »
Quote from: srsa_4c on 16 / June / 2019, 17:09:34
Used to be tx19a, but they use other MCUs lately (Renesas). I think the old PowerShot SubCPUs and the new ones in EOS M3 and M10 are also Renesas.
ShowMechaMacro mentions Renasas on some cameras
D10 "RENESAS R2A30421BM"
G7X, SX710 "RENESAS R2A30447BG"
M3, M10 "R2A30442NP"
ELPH130 "TOSHIBA ALVA MCD"
ELPH180 "GMT G2030" (www.gmt.com.tw/product/datasheet/EDS-2030.pdf ?)

I didn't see data sheets for the specific Renesas models, but R2A30* seem to be motor drivers for cameras. I'm not sure if these are MechaCPU

Logged
Don't forget what the H stands for.
Pages: 1 ... 11 12 13 14 15 [16] 17 18 19 20 21   Go Up
« previous next »
 

Related Topics