Canon 80D

[RavingRover]

80D has a DIGIC 6, the 5D IV has a DIGIC 6+, i do not know if either has been shown to be multi-core, but then why should that matter.

I believe i saw that typically the '+' DIGICs were just faster clock speeds, maybe something diff about them, don't know.

The 5DIV has only a sinlge DIGIC, & the 80D.

It appears that the 5DIV is progressing well in its port.

So why does not some/most/all of the 80D port (besides addresses) not benefit from the 5DIV effort and success ?

Just wondering since I have used ML on my old orig M model and do see lovely benefits, ML is nice and would love to see some of its benefits on my 80D as we all would.

Happy porting and much success !!

[k!r+]

Keeping in mind I'm new to both RE and open source projects.

As far as I can tell, most of the camera's with NFC are at a similar stage in emulation. I wonder if it is possible that at least one reason for this is to do with NFC.

Looking at the second Debug log from Dj4n90 (near the end), three lines before the line:

Code: [Select]

ASSERT : ./System/MariusAPI/OmarSysInfo.c, Task = RTCMgr, Line 73
there is the line:

Code: [Select]

   456:  1599.232 ERROR [I2C] I2C_Read[CH1] : 0xa8,0x00,0x01,0x00 (Task : NFCMgr)
which made me think that the ASSERT could be related to this error.

I took the camera apart again to take photo's of the NFC board (sorry not as good as the last ones - ISO was too high). From the code on the chip and the chip pin-out I believe the NFC chip is a Panasonic MN63Y1214. The 0xa8 portion of the error code from Dj4n90's debug log is the standard i2c location for reading from this chip, but I don't know what the rest of the codes are asking for in that error.

Which brings me to my questions:

• Is this assumption likely correct? Or did I wast my time?
• If this assumption is correct and the emulation is ceasing because of this NFC error, what are the next steps? NFC emulation?
• Can NFC emulation be skipped by NOPing NFC related tasks in the ROM1.BIN (for the purpose of camera emulation only)?
• If the NFC needs to be emulated, how would that be done and where should the code go? (remember I'm new to this...)
• Can anyone see anything to indicate that I have identified the wrong chip?

Thanks for your help, and hopefully this info will assist somehow.

[a1ex]

Omar is a secondary CPU; from what I could tell, it does not use I2C at all. The two lines happen to be adjacent because of multitasking.

In particular, the Omar initialization is started in startupPrepareCapture; the patches from 80D/patches.gdb are trying to bypass it, without much success.

I don't think missing NFC emulation does any harm (there are I2C warnings on other cameras that boot the GUI, and you can patch either the I2C routine or the entire NFC task). There are a bunch of debug functions registered for NFC, which makes it a fairly low-hanging fruit for investigating how it works. Some info from real hardware in this log:

With b35a216 as last changeset:
- log

Code: [Select]

2BE98>     NFCMgr:fe71aee7:4d:03:  nfcmgrstate_Initialize:NewsDet_R Hi
2BEF5>     NFCMgr:fe168615:00:01: [I2C] I2CD_Initialize
2BF12>     NFCMgr:fe168683:00:01: [I2C] I2CD_Com mode[3], devAddr[0xA8]
2BF31>     NFCMgr:fe167ec7:00:01: [I2C] CH1 bus ready
2BF46>     NFCMgr:fe167ec7:00:01: [I2C] CH1 bus ready
2BF60>     NFCMgr:fe168465:00:01: [I2C] read start condition
2C03B>   PowerMgr:001ccab0:00:0f: INT-0DDh FE167F29(0)
2C069>     NFCMgr:fe168187:00:01: [I2C] read stop condition
2C091>   PowerMgr:001ccab0:00:0f: INT-0FDh FE167FC7(0)
2C0AB>   PowerMgr:fe2807ed:00:01: [I2C] SIRQ
2C0BC>     NFCMgr:fe168709:00:01: [I2C] CH1 Init

On the other side, I'm pretty sure the incomplete Omar initialization is holding back the startup process (unlike DIGIC 5 models, where Eeko initialization is pretty much skipped without major side effects); this is because other initialization routines are waiting for this step to complete. Unfortunately, Omar communication is not exactly easy to figure out, at least for me. RE notes in the Eeko thread.

To log the info required to emulate this stuff, one has to port the MMIO tracing backend:
- https://bitbucket.org/hudson/magic-lantern/pull-requests/900/mmio-tracing-backend-insanely-powerful
- https://bitbucket.org/hudson/magic-lantern/commits/0a2e116 (same technique in a different context, allowing C callbacks)

If that works, we'll get a huge log with every MMIO access performed by the main CPU, i.e. several megabytes of numbers that have to be interpreted to figure out their meaning, or replayed somehow in the emulator. If there's any more energy left after dealing with trolls, that is.

Thanks for identifying the BLE chip. The pinout makes sense to me (direct link, as it took me a while to find the picture). FYI, @ids1024 managed to reverse the protocol:
https://iandouglasscott.com/2018/07/04/canon-dslr-bluetooth-remote-protocol/

[Hubuki]

Is there a a download for the 80d yet?
Please Please Please say yes!! T^T

[nagamayasi]

please download link for canon 80d

[ricflair4life]

Happy late thanksgiving, everyone! I’m PayPal’ing the person who can provide a working magic lantern for the 80d. Seriously, I check this thread several times a day everyday.. what’s going on???

[nagamayasi]

Happy late thanksgiving, everyone! I’m PayPal’ing the person who can provide a working magic lantern for the 80d. Seriously, I check this thread several times a day everyday.. what’s going on???

yes same with me,
everyday i chehk this thread, and still waiting for magiclantern working on canon 80d.
from 2016.... 

[theBilalFakhouri]

I don't think the right person has arrived to work on this camera seriously.

If you are ready to pay I will suggest to start an offer in freelancer.com for "Making Magic Lantern working in 80D" maybe we will catch him there 

[polkah]

Happy late thanksgiving, everyone! I’m PayPal’ing the person who can provide a working magic lantern for the 80d. Seriously, I check this thread several times a day everyday.. what’s going on???

Yeah, we should make a kickstarter to fund anyone that would make a working port for 80d

[waterfox11]

I agree

[GonJouls]

Yes! I would most definitely support a kickstarter or any thing in that matter to have someone who could work on this port!

[ricflair4life]

So what exactly do we need to do?

[ohdidntcall]

I think that the best thing to do would be to wait and not bother the developers too much. I've been quietly reading this forum for years, and occasionally I see someone ask if the 80D nightly build is available yet, and sometimes even offer money. I dont think that these requests really speed up the process /: though I don't know if making a kickstarter will help. Of course, I'm dying for ML for 80D too (: but I think that it'd be best to just wait and see.

[polkah]

I think that the best thing to do would be to wait and not bother the developers too much. I've been quietly reading this forum for years, and occasionally I see someone ask if the 80D nightly build is available yet, and sometimes even offer money. I dont think that these requests really speed up the process /: though I don't know if making a kickstarter will help. Of course, I'm dying for ML for 80D too (: but I think that it'd be best to just wait and see.

Yeah you're right, I hope the developpers will figure a way out, it's great to have those people doing this amazing work basically as a hobby, I'm not especially in a hurry for ML for my 80d, but thought it could be nice to reward the develloppers for all of their great work

[whoreable]

Lets start the GoFundMe and someone surely will take the challenge

Or atleast this thing will get into the several thousand dollar range enough to purchase an 80D to experiment on

[nikfreak]

Lets start the GoFundMe and someone surely will take the challenge...

magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

Here's the official forum site and the place where developers (new and old) can connect and talk. You need patience. "Someday" "someone" will announce ML for 80D or 5d Mark IV or any other unsupported cam. But that will happen here and not on external funding sites

[Papa Bless Finesse]

Hey guys i hate to be that guy but if someone is currently working on ML for the 80d if you want someone to test it for you i would be happy to be guinea pig. as long as you guide me on how to fix if something goes wrong as im just a wee young lad that is probably stupid for doing this but doesnt care anyway then continues writing like this just because he can and doesnt really have much else to do but bust a nut and hope for ML for his camera sometime soon and yeah ah yeah. swag anyway *dab* if you or you know someone that is working on it. message me i guess but no late night booty calls. thanks guys.

[polkah]

Hey guys i hate to be that guy but if someone is currently working on ML for the 80d if you want someone to test it for you i would be happy to be guinea pig. as long as you guide me on how to fix if something goes wrong as im just a wee young lad that is probably stupid for doing this but doesnt care anyway then continues writing like this just because he can and doesnt really have much else to do but bust a nut and hope for ML for his camera sometime soon and yeah ah yeah. swag anyway *dab* if you or you know someone that is working on it. message me i guess but no late night booty calls. thanks guys.

Same

[a1ex]

Minor update (i.e. what I did last week):

- emulation is able to reach GuiMainTask (after updating the MPU messages and some trivial GDB patches - not yet committed)
- it gets stuck trying to communicate with Zico/MZRM (as expected)
- to understand how that's supposed to work, I need some detailed low-level logs
- I've managed to port io_trace on DIGIC 6 (tested in QEMU; not yet committed)
- "just" debugging io_trace took me a couple of days of intensive work (whew!)
- now, in order to test it on real hardware, I need some preparations
- I want to capture some huge logs (with lots of messages), from early startup until full boot
- problem: memory allocators are not available at early startup
- workaround: I can statically allocate some buffers, where Canon firmware won't touch them
- to find these areas, I need you to run a little test
- compile the latest changeset (bee6ec3) with CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP enabled in config-defines.h
- the startup process will be slower than usual (it might even lock up)
- during the LED blinks (about 1 minute), exercise the camera a bit (open Canon menu, enter LiveView, take a photo and record a short video clip) - important!
- after the LED stops blinking, a log file will be saved
- the log should print a summary of memory areas that were not touched by Canon firmware
- these memory areas, likely unused by Canon code, can probably be reused for saving huge logs (with plenty of details about the startup process)
- if the log file gets full before the memory usage summary is printed, try adjusting what messages should be logged (in my_DebugMsg, identify them by class and level)
- if it's still not working, disable all other messages (e.g. assign a different class/level for the interesting messages, i.e. the ones showing memory usage summary, and drop everything else)
- brain dump complete (to be continued after getting the result of this test)

[Ant123]

- emulation is able to reach GuiMainTask (after updating the MPU messages and some trivial GDB patches - not yet committed)
- it gets stuck trying to communicate with Zico/MZRM (as expected)

Have you tried to apply modified EOS M3 patches? (0xFC3F1110, 0xFC3F1114, 0xFC3F1178)

[OlRivrRat]

           @Alex

Would like to help with this but I am still Completely Compiling Illiterate. If someone could provide, what ever it is, already Compiled I'll give it a Whirl ~

                                                                          ORR ~ DeanB

[Chellyandruu]

I compiled and the camera blinks for 1 minute,did all the test but no logs are saved.

[k!r+]

I have compiled and run the changeset with the config requested on the camera I have.
 
-      DEBUGMSG.LOG
 
The camera did not lock up at the beginning with just the standard configuration and allowed me to open the menu, liveView, movie, playback, etc. But at the end of the script (led stopped flashing) it did appear to "lock up" - the screen went blank and no input appeared to make any difference until the power switch was flicked, at which point the led came on for roughly one second. I don’t think it was a full lockup, as I did not have to remove the battery. The file of the log output did appear to complete fully and provide a summary of memory usage. @a1ex if you want more logs to check against just let me know and the best way to get them to you.
 
Current focus has been on understanding trying to understand way CHDK print to screen in an effort to get “helloworld” happening.

[a1ex]

Looks good. Also got a log from Chellyandruu, so here's a comparison: 80D-memory-map.html

Annotated logs:
DEBUGMSG-ch-a.log
DEBUGMSG-kr-a.log

Unless anyone proves me wrong with further logs, I'd choose:

Code: [Select]

52B00000 - 554FFFFF: 42.0M
55600000 - 57FFFFFF: 42.0M
58100000 - 5A9FFFFF: 41.0M
68000000 - 6A9FFFFF: 42.0M
6AB00000 - 6D4FFFFF: 42.0M
6D600000 - 6FEFFFFF: 41.0M
70000000 - 729FFFFF: 42.0M
72B00000 - 753FFFFF: 41.0M

or their cacheable counterparts (clear 0x40000000 from the address).

These addresses are camera-specific and workload-specific - they are likely unused *only* on 80D and *only* under the scenarios performed by the two testers. That is, roughly:
- plain startup (one of the logs was in M mode, the other in... some sort of Auto mode without flash, I guess)
- entered and exited LiveView (both photo and movie mode)
- video recording
- still photo capture

Some key moments in the two logs ("evf" is LiveView, "scs" is still photo capture):

Code: [Select]

0.081545     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 3
0.099797     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 3
1.411584     PropMgr:fe0fde4d:89:03: PROP_SHOOTING_TYPE : NORMAL
10.113758     PropMgr:fe0fde83:89:03: PROP_SHOOTING_TYPE : LV
10.153722         Evf:fe23c553:a7:03: evfStart
13.181087  ShootCaptu:fe0df243:93:03: scsReleaseOn
13.183348         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:91]
13.197543    EventMgr:fe100683:93:03: scsReleaseDataCBR
13.336106  ShootCaptu:fe0ded0d:93:03: scsReleaseEnd
13.336134  ShootCaptu:fe0df275:93:03: scsReleaseOff
13.489096         Evf:fe23c553:a7:03: evfStart
14.216208  ShootCaptu:fe0df243:93:03: scsReleaseOn
14.217897         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:22]
14.232051    EventMgr:fe100683:93:03: scsReleaseDataCBR
14.371102  ShootCaptu:fe0ded0d:93:03: scsReleaseEnd
14.371128  ShootCaptu:fe0df275:93:03: scsReleaseOff
14.520299         Evf:fe23c553:a7:03: evfStart
14.843084         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:10]
16.639859         Evf:fe23c553:a7:03: evfStart
16.842968     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 3
16.861439         Evf:fe323c75:ab:03: FHD60fps LCD
17.059484         Epp:fe120de3:99:07: VRAM_InitializeVramPath FHD30P
17.103158         Evf:fe323c75:ab:03: FHD60fps LCD
17.393141         Epp:fe120de3:99:07: VRAM_InitializeVramPath FHD30P
18.544355     CtrlSrv:fe59aabd:2f:05: MVR_StartRecord
18.916645     PropMgr:fe0fde95:89:03: PROP_SHOOTING_TYPE : MOVIE
25.327064     CtrlSrv:fe390c67:83:03: EndMovieRecSequence MVR_StopRecord()
26.921164     PropMgr:fe0fde83:89:03: PROP_SHOOTING_TYPE : LV
34.000766     PropMgr:fe0fde4d:89:03: PROP_SHOOTING_TYPE : NORMAL
34.003488         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:414]
34.086513     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 3


Code: [Select]

0.084690     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 15
0.104977     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 15
1.453584     PropMgr:fe0fde4d:89:03: PROP_SHOOTING_TYPE : NORMAL
17.994169     PropMgr:fe0fde83:89:03: PROP_SHOOTING_TYPE : LV
18.003630         Evf:fe323c75:ab:03: FHD60fps LCD
18.014741     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 15
18.035428         Evf:fe23c553:a7:03: evfStart
18.039131         Evf:fe323c75:ab:03: FHD60fps LCD
18.246843         Epp:fe120de3:99:07: VRAM_InitializeVramPath FHD30P
19.719062     CtrlSrv:fe59aabd:2f:05: MVR_StartRecord
20.070081     PropMgr:fe0fde95:89:03: PROP_SHOOTING_TYPE : MOVIE
21.468065     CtrlSrv:fe390c67:83:03: EndMovieRecSequence MVR_StopRecord()
23.116395     PropMgr:fe0fde83:89:03: PROP_SHOOTING_TYPE : LV
23.455943     PropMgr:fe0fde4d:89:03: PROP_SHOOTING_TYPE : NORMAL
23.458682         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:134]
23.597536     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 15
24.613145     PropMgr:fe0fde83:89:03: PROP_SHOOTING_TYPE : LV
24.640969         Evf:fe23c553:a7:03: evfStart
26.879191     PropMgr:fe0fde4d:89:03: PROP_SHOOTING_TYPE : NORMAL
26.883264         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:67]
41.471468  ShootCaptu:fe0df243:93:03: scsReleaseOn
41.472982    EventMgr:fe100683:93:03: scsReleaseDataCBR
41.597757  ShootCaptu:fe0ded0d:93:03: scsReleaseEnd
41.597783  ShootCaptu:fe0df275:93:03: scsReleaseOff

New code committed. Let's see - can we get a large startup log?

[sombree]

Log made on latest (a706877) commit: log and log2. I've stressed camera a little bit - start to M mode, fiddle a bit with touchscreen, switch to LV and back, switch to movie mode -> record few secs -> back to photo mode, switch to play mode etc.
Btw. I had to define CONFIG_80D in log-d6.h - it's used in log-d6.c but it's not defined anywhere