chdk in the DIGIC6 world - page 10 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 21   Go Down

chdk in the DIGIC6 world

  • 201 Replies
  • 170417 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #90 on: 19 / March / 2017, 10:29:07 »
Advertisements
It seems Canon is not the only camera maker using Takumi graphic accelerators: GV330 is used in the Nikon D7100. Image comes from the Nikon Hacker forum, I put it here for easier access (their forum server has problems lately).
A very similar code snippet can be found in our Xtensa firmware - with different constants and "GV550". It's likely part of the Takumi provided library.
Logged
*

Online reyalp

  • ******
  • 14126
Re: chdk in the DIGIC6 world
« Reply #91 on: 11 / June / 2017, 20:41:33 »
I added G7 X 100b and 100d to the autobuild, labeled as ALPHA, with FI2 building disabled.

While there are certainly still issues, IMO it's functional enough for general use, and not significantly worse than some of the other ports that have been in the autobuild. When we discussed this before the major stumbling block was the display related features (zebra, histo etc) and those have been mostly addressed. Plus I'm tired of building every firmware and updating the posts in the dev thread ;)

I'm happy to add any other D6 ports the developers think are ready. Until the FI2 boot issues are resolved, I plan to leave FI2 building disabled for all D6 ports.

I'm also open to arguments that this was a bad idea.
Logged
Don't forget what the H stands for.
*

Offline dmitrys

  • ****
  • 267
Re: chdk in the DIGIC6 world
« Reply #92 on: 21 / June / 2017, 15:57:19 »
Quote from: reyalp on 11 / June / 2017, 20:41:33
I added G7 X 100b and 100d to the autobuild, labeled as ALPHA, with FI2 building disabled.

What's the reason for omitting 100c?

BTW I noticed an anomaly in camera_list.csv: sx400is-100b is ALPHA but is still skipped.
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Online reyalp

  • ******
  • 14126
Re: chdk in the DIGIC6 world
« Reply #93 on: 21 / June / 2017, 16:44:35 »
Quote from: dmitrys on 21 / June / 2017, 15:57:19
What's the reason for omitting 100c?
Because it's a blind port and no one has reported whether it runs yet.
Quote
BTW I noticed an anomaly in camera_list.csv: sx400is-100b is ALPHA but is still skipped.
ALPHA doesn't particularly imply "ready for the autobuild". The status labels are set by whoever works on the ports. Generally ports starts as ALPHA and we don't add cameras to the autobuild until a few people have reported it working.

The "PREALPHA" was used on the digic 6 ports, because the new architecture caused a lot of stuff to be broken.
Logged
Don't forget what the H stands for.
*

Offline dmitrys

  • ****
  • 267
Re: chdk in the DIGIC6 world
« Reply #94 on: 21 / June / 2017, 17:07:14 »
Quote from: reyalp on 21 / June / 2017, 16:44:35
ALPHA doesn't particularly imply "ready for the autobuild". The status labels are set by whoever works on the ports. Generally ports starts as ALPHA and we don't add cameras to the autobuild until a few people have reported it working.

So ixus125_elph110hs works, but remains in ALPHA since it has too many features disabled?
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Online reyalp

  • ******
  • 14126
Re: chdk in the DIGIC6 world
« Reply #95 on: 21 / June / 2017, 17:23:21 »
Quote from: dmitrys on 21 / June / 2017, 17:07:14
So ixus125_elph110hs works, but remains in ALPHA since it has too many features disabled?
You really shouldn't read much into the labels. Generally what we aim for is

ALPHA - either very new, very lightly tested, or known significant missing features / problems
BETA - most major features reported working, may have minor know issues or some areas not tested.

However, we have a problem: The core developers don't have access to 99% of the supported hardware. Sometimes ports are done "blind" which makes it very hard to know how well tested they are, others are contributed by people who happen to own and camera and have some programming skill. So we don't directly know the state of most ports, and we depend on others to request the status of a particular port should be updated. So ports that are fine may languish forever as alpha or beta, and ports that have significant problems may have no label.

This comes up for discussion every so often, but we don't have a good solution.

The real solution IMO would be to have much more comprehensive tests and test procedures so we could objectively know how functional a port is, but this is very hard to do in practice.
Logged
Don't forget what the H stands for.
*

Offline Ant

  • *****
  • 509
Re: chdk in the DIGIC6 world
« Reply #96 on: 22 / July / 2017, 18:42:21 »
Quote from: srsa_4c on 26 / June / 2016, 18:57:07
The ID -> name association list is attached to my previous post due to size limitation. I have extracted the function pointers starting from 0x80a001d0, and used a script to extract the debug strings (which appear to be function names) from the disassembly of the 0x80a00000 area.

Need some help to find message handlers for EOS M3:
My code does not look the same as yours:
Code: [Select]
loc_bff25a00: ; 3 refs
bff25a00: bd01      mov.n a11, a1
bff25a02: a806      l32i.n a10, a6, 0
bff25a04: 25d1ff        excw
bff25a07: 2d0a      mov.n a2, a10
bff25a09: 96baf6        bltz a10, loc_bff25978
bff25a0c: a805      l32i.n a10, a5, 0
bff25a0e: 0c1b      movi.n a11, 1
bff25a10: e52e01        excw
bff25a13: f801      l32i.n a15, a1, 0
bff25a15: 9cff      beqz.n a15, loc_bff25a38
bff25a17: c02000        memw
bff25a1a: 480f      l32i.n a4, a15, 0
bff25a1c: ed04      mov.n a14, a4
bff25a1e: c02000        memw
bff25a21: 381f      l32i.n a3, a15, 4
bff25a23: cbaf      addi.n a10, a15, 12
bff25a25: 473714        bltu a7, a4, loc_bff25a3d
bff25a28: 412a76        l32r a4, 0xbff032d0 ; (0x80a00830)
bff25a2b: 408ea0        addx4 a8, a14, a4
bff25a2e: 8808      l32i.n a8, a8, 0
bff25a30: e00800        excw
bff25a33: dd0a      mov.n a13, a10
bff25a35: 860b00        j loc_bff25a67
loc_bff25a38:
bff25a38: 0c03      movi.n a3, 0
bff25a3a: 42a0f0        movi a4, 240
loc_bff25a3d:
bff25a3d: a2a009        movi a10, 9
bff25a40: c12576        l32r a12, 0xbff032d4 ; *"ID Error[%d] -- msg:0x%08x"
bff25a43: 20d220        or a13, a2, a2
bff25a46: b14175        l32r a11, 0xbff02f4c ; (0xbff04328)
bff25a49: 40e420        or a14, a4, a4
bff25a4c: b80b      l32i.n a11, a11, 0
bff25a4e: 25a8fd        excw
bff25a51: f14075        l32r a15, 0xbff02f54 ; (0x00c1341c)
bff25a54: f80f      l32i.n a15, a15, 0
bff25a56: 8caf      beqz.n a15, loc_bff25a64
bff25a58: cd04      mov.n a12, a4
bff25a5a: a11e76        l32r a10, 0xbff032d4 ; *"ID Error[%d] -- msg:0x%08x"
bff25a5d: bd02      mov.n a11, a2
bff25a5f: d801      l32i.n a13, a1, 0
bff25a61: e00f00        excw
loc_bff25a64:
bff25a64: d2a000        movi a13, 0
loc_bff25a67:
bff25a67: a22600        l32i a10, a6, 0
bff25a6a: 30b320        or a11, a3, a3
bff25a6d: 20c220        or a12, a2, a2
bff25a70: 65ceff        excw
bff25a73: a22500        l32i a10, a5, 0
bff25a76: b2a002        movi a11, 2
bff25a79: 652801        excw
bff25a7c: 06e0ff        j loc_bff25a00
.loc_bff25a80:
bff25a7f: 00a2a0        addx4 a10, a2, a0
bff25a82: 09b2      s32i.n a0, a2, 44
bff25a84: 2b00      addi.n a0, a0, 2
bff25a86: c11476        l32r a12, 0xbff032d8 ; *"MzrmRcvTskMain Start"
bff25a89: a59afd        excw
I've got it using xtensa-lx106-elf-objdump.
Are function pointers situated at 0x80a00830 ?

« Last Edit: 22 / July / 2017, 19:10:05 by Ant »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #97 on: 22 / July / 2017, 21:31:24 »
Quote from: Ant on 22 / July / 2017, 18:42:21
Need some help to find message handlers for EOS M3:
My code does not look the same as yours
That disasm is looking weird.
Instructions decoded as 'excw' are actually not decoded correctly.
For example, e00800 should be 'callx8  a8'.
I'd expect the handler list to start near the beginning of one of the Xtensa blobs - the list will surely contain NULLs.
I can't help more ATM because I have not found/extracted/disassembled the M3 blobs, yet.

It's very much possible that 'our' Xtensa is not lx106. Hmm, isn't that the core used in ESP 8266? Because that's a rather basic core that supports way less instructions, so its disassembler won't do the job.
Logged
*

Offline Ant

  • *****
  • 509
Re: chdk in the DIGIC6 world
« Reply #98 on: 23 / July / 2017, 04:26:52 »
Quote from: srsa_4c on 22 / July / 2017, 21:31:24
I can't help more ATM because I have not found/extracted/disassembled the M3 blobs, yet.
You can take it from ROM dump:
Code: [Select]
dump offset - load address - size
0x09FEFB0 0xBFF20000 0x77B8
0x0A06770 0xBFF00000 0x4AD0
0x0A0B248 0x80A00000 0x106220
Quote
It's very much possible that 'our' Xtensa is not lx106. Hmm, isn't that the core used in ESP 8266? Because that's a rather basic core that supports way less instructions, so its disassembler won't do the job.
Which exactly binutils you've used to get your disassembly?

Finally my message handlers are exactly the same as G7x.
« Last Edit: 23 / July / 2017, 04:36:24 by Ant »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #99 on: 23 / July / 2017, 11:26:23 »
Quote from: Ant on 23 / July / 2017, 04:26:52
You can take it from ROM dump:
Code: [Select]
dump offset - load address - size
0x09FEFB0 0xBFF20000 0x77B8
0x0A06770 0xBFF00000 0x4AD0
0x0A0B248 0x80A00000 0x106220
Yeah, I know. Addresses of blobs can be found in the fw function that references the "zicokick start" string.
Quote
Which exactly binutils you've used to get your disassembly?
An universal one, made with this script (I also posted this link earlier): http://pete.akeo.ie/2011/04/quick-and-dirty-script-to-compile.html
The other script (or the binary) found in my disassembler thread is also usable.
Quote
Finally my message handlers are exactly the same as G7x.
Yep, I checked them too.
Quote
Are function pointers situated at 0x80a00830?
Your guess was correct. The number of functions (or the highest index?) can be found higher in the disassembly, it's the value loaded in the a7 register.
Code: [Select]
bff2596e: 72a0ef                movi a7, 239
...
bff25a25: 473714                bltu a7, a4, loc_bff25a3d
Logged
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 21   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal