eos M10 port - page 14 - DryOS Development - CHDK Forum
supplierdeeply
« previous next »
Pages: 1 ... 9 10 11 12 13 [14] 15 16 17 18 19 ... 33   Go Down

eos M10 port

  • 327 Replies
  • 235694 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: eos M10 port
« Reply #130 on: 22 / May / 2017, 12:52:45 »
Advertisements
Quote from: axman on 22 / May / 2017, 12:40:01
I can provide a firmware dump of 1.1.0 d from my recently-upgraded camera, if that's still useful.
It's no longer necessary, user br_andi has provided one in January.
Logged
*

Offline axman

  • ***
  • 145
Re: eos M10 port
« Reply #131 on: 25 / May / 2017, 20:26:29 »
Tested my m10 using your provided build, following your basic tests.

- llibtst.lua      GOOD
- setmode.lua - GOOD
- ubtest.bas - GOOD
- hooktest.lua (Av, Tv, M, P) - GOOD
- isobase.lua  -  it said 200
- chdkptp cam tests - GOOD ( ~/chdkptp/lua/camtests.lua )
paramdmp.lua - when in PLAY mode, and when in REC mode
chdkptp gui - live view CHDK gui looked great, all Stream option boxes ticked.
  Live view (play & rec modes) is razor sharp.  Only 3:2 a/r tested.

chdkptp gui - rec / play mode switch had issues, as did cli.  Seem to relate to hot-plug usb, or with the cam being recognized by OS before or after chdkptp is run.

My chdkptp version circa May 23, 2017.

Case where cam is present in the OS before launching chdkptp, rec/play work correctly.  Eg - both cli and gui switch the camera from rec to play and play to rec correctly.
-------------------------------------------
Case where chdkptp is running,  cam has already booted CHDK and is running in PLAY mode, and cam is then plugged into USB:

  a) plug in USB
  b) gui: connect
  c) gui: live tab, Stream boxes ticked - see flawless display
  d) gui: click rec
  e) viewport LCD goes dark;
  f) gui: hesitates, then informs with I/O err
  g) cam looks dead except OnOff LED flashes a few times, then cam reboots ! and CHDK splash is displayed..

I reproduced the crash twice, once using the chdkptp cli, and once using chdkptp gui.  I have the romlogs and Gk.log files from each, if it's of interest.  Also have all the logs from above named tests.  The 4th attempt, cam did not crash, but rebooted (steps a-g above).

Verified that my ixus160 tolerates this hot-plugging case, and switches from rec to play correctly.

I read the thread about overrides..  More than happy to test / provoke / dump.  Hopefully I can be a bit useful with minimum handholding.


Logged
*

Offline axman

  • ***
  • 145
Re: eos M10 port
« Reply #132 on: 26 / May / 2017, 16:48:18 »
Using trunk, I built a working version.  Camera booted CHDK and m10 normal controls operated, as advertised.

Then I dumped the fresh 110d firmware, and placed copies of the .BIN in /tools and sub/110d respectively.

make clean; make fir;  Compile fails, when dealing with stubs_entry.S.

Restore as-downloaded state, move the PRIMARY.BIN out of the way; builds GOOD again.

Compare files, try to account for the diffs I see.

I have diffs between funcs_by_address.csv, funcs_by_name.csv (build-GOOD and fail), the previous (working) stubs_entry.S, stubs_entry.S.err, and stubs_not_found_names.err from the failed compilation. 

Since trunk m10 builds good for me, and cam operates ok for the fw ver that I have (110d), why does my build fail - on stubs_entry.S - with dump of Canon's 110d -> PRIMARY.BIN present in platform/sub/110d/ ? And succeed when it's not present?  Wondering if the following reasoning is true;

1) differences in firmware versions [function addresses, etc found in the dis-assembled PRIMARY.BIN] from the original-Canon-firmware to recent-Canon-upgrade-firmware that relate to stubs_entry.S have already been resolved MANUALLY.

2) Meaning: The automated sig find process simply fails for some elements (most every time on certain things, perhaps), and someone skilled in the art has already looked through PRIMARY.BIN and made educated guesses about the missing addrs, and has already filled in what the automated sig finder missed or got wrong.

3) Eg - those educated (now somewhat proven) addr guesses are already expressed in the stubs_entry.S from trunk.

True?

Could there also be small differences inside one version of '110d' that occur between cameras in a production run?

Could also be the possibility that something about the way I'm doing universal dumper this time is wrong, (as if I have to trim 0x?? off the beginning of the dump ?)

What's nagging me is, I'm trying to resolve and understand diffs between the trunk version of funcs_by_address.csv [that builds good] and funcs_by_addr that is generated during my failed build process.  I assume the proc that generates funcs_by_addr is looking at sub/110d/PRIMARY.BIN to try and get those funcs.

Could it be that the automated 'func finder' which is activated during build process behaves similar to the process that generates stubs_entry.S - in that it simply does not find some funcs correctly?  Not being critical, just trying to reconcile my understanding of the process with the evidence..

As if, "I did not trim any data from PRIMARY.BIN as dumped, therefore my funcs are lining up in a different place in the firmware dump.." ? )

func                            @srsa_4c      @failed build
-----------------------------------------------------------
time                            0x010e11eb        0xfc314a50
CreateRecursiveLockStrictly        0xbfe15577        0xfc314a30
GetSemaphoreValue                  0xbfe1548d        0xfc314a60
CreateRecursiveLock                0xbfe158ad        0xfc314a80
TryReceiveMessageQueue            0xbfe1518b        0xfc314a90
CreateEventFlag                    0xbfe14c71      0xfc314ae8
TryPostMessageQueue                0xbfe15253        0xfc314b00
CheckAnyEventFlag                  0xbfe14ce5        0xfc314b20
_pow                              0x01103a40        0xfc314b40
CheckAllEventFlag                  0xbfe14d1b        0xfc314b58
RegisterInterruptHandler          0xbfe14f05        0xfc314b90
WaitForAllEventFlag                0xbfe14dd3        0xfc314bf0
TakeSemaphoreStrictly              0xbfe15591        0xfc314c00
CreateMessageQueueStrictly        0xbfe1550f        0xfc314c88
CreateTaskStrictly                0xbfe154ed        0xfc314c90
SetEventFlag                      0xbfe14e53        0xfc314c98
DeleteSemaphore                    0xbfe15375        0xfc314cb0
_log10                            0x011038d8        0xfc314d10

Having a go with capdis, against original fw dump (100a?) and what I have now, to see if I can follow what's going on.
Logged
*

Offline reyalp

  • ******
  • 14035
Re: eos M10 port
« Reply #133 on: 26 / May / 2017, 17:34:21 »
@axman

Did you use the patched capstone library? If not, the sig finder will produce bad output.
Logged
Don't forget what the H stands for.
*

Offline axman

  • ***
  • 145
Re: eos M10 port
« Reply #134 on: 27 / May / 2017, 13:53:21 »
Quote from: reyalp on 26 / May / 2017, 17:34:21
Did you use the patched capstone library? If not, the sig finder will produce bad output.
@reyalp,  thanks for the reminder.

re: capstone, I used pkgs from distro, ubuntu 16.04 x86_64, libcapstone-dev ver 3.0.4-0.2, and libcapstone3.  I think they are patched.  Tested with latest capstone source, 3.0.5-rc2, tests/test_ARM.  Results attached.

Curious, I compared to srsa_4c's patch [discussed in topic=12714.20].  The most recent capstone source has srsa_4c's suggested lines in it, but remarked out.. 

re: sig finding, I think I'm doing it wrong.  I'm now sig finding the same 3 funcs between the 160, m10, and sx530hs, to see if I'm getting how it works.
Logged
*

Offline reyalp

  • ******
  • 14035
Re: eos M10 port
« Reply #135 on: 27 / May / 2017, 14:27:58 »
Quote from: axman on 27 / May / 2017, 13:53:21
re: capstone, I used pkgs from distro, ubuntu 16.04 x86_64, libcapstone-dev ver 3.0.4-0.2, and libcapstone3.  I think they are patched.  Tested with latest capstone source, 3.0.5-rc2, tests/test_ARM.  Results attached.
You need to check for

"WARNING! Incorrect dissassembly is likely"

in the output when you rebuild stubs.

Edit:
I confirmed that 3.0.5-rc2 does not fix this issue. It was fixed in the "next" branch, but that branch has changed in other incompatible ways. So, you need to build from source with the attached patch.

Also, I fixed the typo "dissassembly" in the message quote above, so if you search after r4814, it will be "disassembly"
« Last Edit: 27 / May / 2017, 17:42:39 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: eos M10 port
« Reply #136 on: 28 / May / 2017, 09:02:27 »
Quote from: axman on 25 / May / 2017, 20:26:29
Tested my m10 using your provided build
Build 4806? It matters when evaluating romlogs.
Quote
Case where chdkptp is running,  cam has already booted CHDK and is running in PLAY mode, and cam is then plugged into USB
(...)
I reproduced the crash twice, once using the chdkptp cli, and once using chdkptp gui.  I have the romlogs and Gk.log files from each, if it's of interest.
Yes, I'd like to see them if possible.
Turns out, this specific scenario is problematic on my side too. However, I'm experiencing different behaviour.
I usually have to switch between play->rec multiple times to trigger the crash. The camera does not reboot, it remains off.
After the crash, I can't get any romlog. That means, no romlog is saved when I attempt to get one. When I crashed the cam again this way, I got romlogerr.txt on the next attempt.
This is worrying, there might be memory corruption somewhere.
Logged
*

Offline Márk Sörös

  • *
  • 2
Re: eos M10 port
« Reply #137 on: 28 / May / 2017, 09:55:30 »
Can I ask a question?
When a CHDK is made for the M10, will it be able to record video in RAW format?
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: eos M10 port
« Reply #138 on: 28 / May / 2017, 10:29:23 »
Quote from: Márk Sörös on 28 / May / 2017, 09:55:30
When a CHDK is made for the M10, will it be able to record video in RAW format?
The potential is there.
However.
It would require tons of research. CHDK would need features it currently doesn't have. No DIGIC 6 cameras run ML either (at the moment), so detais and potential issues are not known.
If RAW video ever gets implemented on CHDK, it's likely that the first camera supporting it won't be the M10 (or even DIGIC 6).
Logged
*

Offline Márk Sörös

  • *
  • 2
Re: eos M10 port
« Reply #139 on: 28 / May / 2017, 11:20:18 »
Quote from: srsa_4c on 28 / May / 2017, 10:29:23
Quote from: Márk Sörös on 28 / May / 2017, 09:55:30
When a CHDK is made for the M10, will it be able to record video in RAW format?
The potential is there.
However.
It would require tons of research. CHDK would need features it currently doesn't have. No DIGIC 6 cameras run ML either (at the moment), so detais and potential issues are not known.
If RAW video ever gets implemented on CHDK, it's likely that the first camera supporting it won't be the M10 (or even DIGIC 6).
Thank you for the fast answer!
Logged
Pages: 1 ... 9 10 11 12 13 [14] 15 16 17 18 19 ... 33   Go Up
« previous next »
 

Related Topics