eos M10 port - page 3 - DryOS Development - CHDK Forum  
« previous next »
Pages: 1 2 [3] 4 5 6 7 8 ... 33   Go Down

eos M10 port

  • 327 Replies
  • 252168 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: eos M10 port
« Reply #20 on: 07 / January / 2017, 05:46:49 »
Advertisements
Quote from: reyalp on 06 / January / 2017, 21:27:17
IIRC on G7x, rmem'ing MMIO works for single words, but not larger ranges. rmem passes the address range directly to the PTP transfer function, which probably tries to use DMA
It dies even before getting to DMA:
Code: [Select]
Exception!! Vector 0x10
Occured Time  2017:01:06 04:31:47
Task ID: 53149815
Task name: PTPBulkState4
Exc Registers:
0x425B700C
0xD9855000
0x00000020
0xFC338080
0xFC338080
0x00000040
0xFC41D85F
0x0059C170
0xFC41D85F
0xD9855000
0x0059C3B4
0x0059E1C0
0x00000000
0x006F9FA8
0xFC41CA5B
0x01100A98
0x20000053
StackDump:
0x0059C3A0
0xFC41CA5B
0x0059C3A0
0x00000040
0xD9855000
0xFC41D85F
0x0059E1C0
0x0059C170
Code: [Select]
NSTUB(dry_memcpy, 0x1100a8c):
1100a8c: push {r4, lr}
1100a90: subs r2, r2, #32
1100a94: bcc loc_1100ab0
loc_1100a98:
1100a98: ldm r1!, {r3, r4, ip, lr}My guess is that the memcpy is for copying the small block I requested to a larger one that can be DMA'd.
The above example shows that the LDM instruction has generated the exception. Other logs show the same.
I then modified the memory copy routine used in my mw module to use only single LDRs, and it suddenly started to work - I can now look at MMIOs.

So, it looks like the DIGIC / ARM core of this camera doesn't tolerate LDMing MMIO data.

Quote from: Ant on 07 / January / 2017, 04:58:42
I can confirm that on M3 chdkptp and ptpcam allow to read MMIO registers and sometimes allow to read memory ranges(for example "m 0xC0F07000 192")
I see, so the M3 is less sensitive.
Logged
*

Offline Ant

  • *****
  • 509
Re: eos M10 port
« Reply #21 on: 07 / January / 2017, 06:04:11 »
Quote from: srsa_4c on 07 / January / 2017, 05:46:49
So, it looks like the DIGIC / ARM core of this camera doesn't tolerate LDMing MMIO data.
Your CPUINFO exactly matches with mine. But your DryOS version...
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: eos M10 port
« Reply #22 on: 07 / January / 2017, 06:22:20 »
Quote from: Ant on 07 / January / 2017, 06:04:11
Your CPUINFO exactly matches with mine. But your DryOS version...
It's not the OS, it's either a DIGIC hw revision related issue or the DIGIC is configured differently in this cam.
Logged
*

Offline Ant

  • *****
  • 509
Re: eos M10 port
« Reply #23 on: 07 / January / 2017, 06:30:27 »
You can modify CPUINFO to show more information about data abort exception.
Then we can compare its results.

P.S. do you have access to memory-mapped debug registers?
It can be useful to intercept ROM code execution(like cache hacks).
« Last Edit: 07 / January / 2017, 06:34:33 by Ant »
Logged
*

Offline br_andi

  • *
  • 8
Re: eos M10 port
« Reply #24 on: 07 / January / 2017, 10:06:54 »
Hey I want to support you guys, so.
Do you guys still need a Firmware Dump from v1.1.0?
I could make and upload mine, if needed.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: eos M10 port
« Reply #25 on: 07 / January / 2017, 12:55:40 »
Quote from: br_andi on 07 / January / 2017, 10:06:54
Do you guys still need a Firmware Dump from v1.1.0?
I could make and upload mine, if needed.
That would be helpful, thanks.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: eos M10 port
« Reply #26 on: 07 / January / 2017, 13:02:59 »
Quote from: Ant on 07 / January / 2017, 06:30:27
You can modify CPUINFO to show more information about data abort exception.
Have any suggestions?
Quote
P.S. do you have access to memory-mapped debug registers?
It can be useful to intercept ROM code execution(like cache hacks).
We've already had a similar discussion and I can only say the same. I know nothing about the debug registers and how they are accessed.
Logged
*

Offline reyalp

  • ******
  • 14082
Re: eos M10 port
« Reply #27 on: 07 / January / 2017, 13:40:41 »
Quote from: srsa_4c on 07 / January / 2017, 05:46:49
I then modified the memory copy routine used in my mw module to use only single LDRs, and it suddenly started to work - I can now look at MMIOs.

So, it looks like the DIGIC / ARM core of this camera doesn't tolerate LDMing MMIO data.
That wouldn't surprise me at all, more surprising that others do. Puzzling that it differs from the M3 though.
Logged
Don't forget what the H stands for.
*

Offline Ant

  • *****
  • 509
Re: eos M10 port
« Reply #28 on: 07 / January / 2017, 14:19:04 »
Quote from: srsa_4c on 07 / January / 2017, 13:02:59
Have any suggestions?
Maybe A-bit in CPSR ?
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: eos M10 port
« Reply #29 on: 10 / January / 2017, 11:13:50 »
Quote from: srsa_4c on 05 / January / 2017, 20:42:53
As reported on recent models, manipulating the halfshoot and full-shoot bits is no longer effective (that means, CHDK can't simulate button presses on these).
Finally solved this one. Fortunately, Ant's solution can be used with a lot less copied code (study the *first argument of sub_fc07507e in m3 and you'll see).
Also did a bit of debugging on a different camera and found that the button events (that are visible in camera log) are emitted directly by the physw task (in the part identified as 'kbd_p2_f', so the flag often referred to as 'repetition flag' is not about repetition). The WriteEnableMedia event originates from the evaluation of the SD read only bit.

A bit in CPSR (from the manual), I don't see how this is useful for us:
Quote
The A bit is set automatically by certain exceptions and is written by privileged software. It disables asynchronous Data Aborts.

edit:
*first argument
« Last Edit: 10 / January / 2017, 13:25:19 by srsa_4c »
Logged
Pages: 1 2 [3] 4 5 6 7 8 ... 33   Go Up
« previous next »
 

Related Topics