Messages

Very unlikely. Magic Lantern is the "special code" that allows changing how the cam behaves.

Porting to a new camera will be very difficult if you have no knowledge of coding.  It's possible, but could easily take months.  It would be very helpful if you learn C, and how to read ARM assembly code.  You can learn this at the same time as some basic ML tasks that you will need later on.

While you are practising that, here are some early steps you can take:
- dump your 80D rom.  This is explained earlier in this thread
- Clone the main ML repo and learn how to build ML: https://bitbucket.org/hudson/magic-lantern/src/unified/
- get ML Qemu to build, too: https://bitbucket.org/hudson/magic-lantern/branch/qemu
- get ML Qemu working with your rom (it won't *do* much, but earlier in this thread you can see that it does start to boot)

If you need help with these things, it will be best to ask outside of this thread, as your early questions will probably be nothing to do with 80D

Your download of the source didn't work, that's the "abort: error" message.  Can you download anything in the VM?  Does web browsing work?  You might not have networking configured right for the VM.

Added a named-functions.idc -> Ghidra importer script.

https://bitbucket.org/stephen-e/ml_200d/commits/a5be5fc744098e746c3af41d4866ba1a0781e898

Hi!  I'm fairly new here, working on 200D, so I'm not too sure about anything either.  However, I think the best way to share code is fork the Hudson repo and work on your fork.  When it gets to a useful stage, it can be merged back in.

My guess would be that QEMU is failing because of some hardware in the 80D that is not yet emulated (eg, some flash ROM, or a secondary processor).  I don't have enough experience to diagnose beyond that, and I could easily be wrong.  There are other threads about how QEMU was made to work on older hardware, which might help.

You could try building with CONFIG_HELLO_WORLD set - I've been told this is a simplified build.  Using less functionality means if you do have some stubs wrong it may not hit them.  I can build this but it doesn't boot for me.  Another approach that I have started trying is using digic6-dumper, and calling one untested stub at a time, to see if it crashes horribly.

Are you able to compare the stubs you've found with roms from a different camera?  From what I've seen, it is often fairly clear when you have it right (especially with a decompiler, not just a disassembler - Ghidra gives you this for free, if you don't have access to IDA).

The 80D is fairly close to the 200D - maybe you could help me?  I have found almost all of the stubs I need, but can't find any of the EDMAC functions.  If you can share any addresses with me that would help a great deal.

I think for 200D that the signature for LoadCalendarFromRTC() has changed. In older cams it looks to take a single argument, a pointer to struct tm. For 200D I see it as taking 5 arguments, with the 5th being the pointer to the struct.

I have two questions: am I right about the sig change? I think LoadCalendarFromRTC() is at 0xe05cd1fe in 200D. A useful comparison point is 0xe00742fc 200D, which == 0xff885058 50D - both call LoadCalendarFromRTC().

Second, and more important; how should I generally handle this problem? Are there existing examples of function signatures differing across camera models that I could copy?
- I could maybe write a 200D specific wrapper function that takes one arg and supplies the extra ones to the real call.  I believe it's possible to have platform/XXX functions override src/ functions?  I haven't tried this yet.
- I could use lots of #ifdef CONFIG_200D whenever LoadCalendarFromRTC() is called.  This seems very ugly.
- I could have an #ifdef CONFIG_200D macro that mangles calls of LoadCalendarFromRTC() to have 5 params and guesses values for the other 4.  I hate this idea.

Can you describe your problem in more detail?  Does video work if you use a different card, without ML on it?  When you are using ML, do other features of ML work okay - is it only video that doesn't work?  When you say video doesn't work - what goes wrong?  Are there any error messages?

Thanks

Code Select Expand

kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i edmac | wc -l
121
kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i pcie | wc -l
70


So it seems Digic 7 is the strange one! I have found some DMA related code now, "DmacCh" was a useful string. I can see some possible init code around 0xe007e02c.

Thanks for the comparison.  How many edmac strings do you have?  EOS R is Digic 8, it would be interesting if it still had the 100s that old cameras have.  My guess is it'll have 10s like 200D.

Also perhaps noteworthy, a family of new "lime" strings, eg:

LimeXdmac/XdmacApi.c
LimeSdIo/SdWlanIf/SdWlanIf.c
[NWCOM] Lime WorkLoad DMA
LimeSdIo/SdWlanIf/SdWlanIf.c
platform/lime/sd_wif11n.c

Many, though not all, seem to be wifi related - 200D does have wifi.  So perhaps this is a dma controller for that only, and doesn't replace Edmac?  Or perhaps Canon consolidated all DMA with a new controller.
I found this Fujitsu link which might be relevant, but could just be a naming coincidence:
https://www.fujitsu.com/us/products/devices/semiconductor/gdc/doc/an-dma.html

Possibly related, 200D has PCIe related strings, including:

WriteDMAPCIeCom
WriteDMAPCIeCom
ReadDMAPCIeCom
ReadDMAPCIeCom
CompletePCIe_DMA
CompletePCIe_DMA

There are also xdmac strings, not very many, some are close to some PCIe strings.  I'm not convinced there's a link to edmac, but I'll explore further.

I'm having problems finding stubs for 200D.  I have almost all of them found (can probably mock out the rest for now), except the EDMAC family, which look quite important.  Does anybody on a Digic 7 cam have any found?  It looks to me that something important changed.  There are very few EDMAC related strings on 200D.  Case insensitive grep for edmac gives me 138 unique strings on 50D, 12 on 200D.

The only one that looks like a function name is WriteEDmacCompleteCBR, but that's not in stubs for other cams and hasn't been a good enough clue for me so far to locate the rest.

There is the expected slow progress.  It will likely be several months minimum before anything major happens.

I was aware he'd made those changes, but they're not in the code I'm working from, so, didn't bother.  Easy to add, but see "cstart" in stubs: this is listed as THUMB_FN, but it's not a function.  Perhaps it should be named THUMB_CODE?  I guessed the thumb bit wouldn't cause problems for disassembly, since Ghidra knows that ARM functions must be even-aligned - have you seen problems?

EDIT: I take it back, cstart is a function.  Pretty sure I've seen some names that aren't, ones that point into middle of functions at useful places.

Ghidra is a free tool similar to IDA Pro.  https://ghidra-sre.org/
You can extend it with scripts, in Java or Python.  I thought we could make some useful ones and collect them here.  I'm going to assume everyone wanting to run scripts has already got Ghidra working and loaded the rom dumps and extra memory regions (eg, parts of the rom that get copied to different locations at runtime).

Here's my first useful script, StubNamer.py - you give it a stubs.S file and it names and disassembles the stubs in your listing:
https://drive.google.com/open?id=17QJSAd-72z_Kp_GgoS6Qn1HdOsQVc832
In Linux, copy to /home/<your_user>/ghidra_scripts/, then it will be visible under Magiclantern when you open "Display Script Manager" (white triangle in green circle icon in button bar).

Limitations:
- it doesn't define a function at the address, because not all stub addresses are at function starts so I didn't want to force this.  Often Ghidra will work out it's a function due to xrefs etc, but sometimes it doesn't.  Could be made better by inspecting the disassembly, detecting common function starts, only then defining a function?
- the NSTUB address extraction only handles the simplest case.  If it's a computed address, it will fail (and report this in Ghidra console so you can manually define it)

You could create a PR from your own fork. But you can't directly push to another repository if permissions haven't been setup.

Okay, makes sense, thanks.

I will check this. I though ARM v7 architecture is correct for the Cortex A9 processor? Actually I'm a bit confused by the choices in Ghidra...

Earlier in this thread Alex says it's Cortex.  I may be wrong that it makes a difference, I thought that all Cortex were v7 but not all v7 were Cortex, but now I'm not sure.  I looked at the Ghidra definitions in Ghidra/Processors/ARM/data/languages and it seems they're treated very similarly.  I think Cortex might default to Thumb, where v7 doesn't.  Might explain why D works fine for me most of the time?

...and also for named_functions.idc :-)

Yes, similar thing, should be easy.  Although named_functions doesn't find much for me.  I guess because emulation is quite limited so far.

It's a nice Ghidra guide, I like it!  I made some changes but git push gave me a 403, so I guess I can't submit a pull request?  I'm not very good with git, maybe it's something else.  I put my edits here: https://pastebin.com/vP5TNPt1

There are two things that I think will make your life much easier - I think you have the "language" wrong, and should be using ARM Cortex 32 little endian, not ARM v7. Second, you shouldn't load each ROM as a file in your Ghidra project (I made this mistake too).  This makes each file separate and disassembly can't see stuff in the other files, so you will get lots of broken refs.  Instead, load the main ROM, then use File -> Add To Program.  This puts all the files in the same address space and disassembly works much better.

Third...  I should really write a Ghidra script that reads stubs.S and disassembles and labels every code address.

This is a useful starting place:
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default#rst-header-adding-support-for-a-new-camera-model

The Finding Stubs tutorial is also handy:
https://www.magiclantern.fm/forum/index.php?topic=12177.0

IRC is a good place to ask "how do I find out about X?".

The stephen-e repo is mine, I am working on stub hunting currently.  There's about 80 stubs I haven't tried to locate yet, when I've taken a first pass through that I'll need to ask more questions.  If anyone with a 200D finds stubs further down in stubs.S them my "UNSURE or untested" section, let me know and I can add them.  Currently I have the hack hello world working, and the official CONFIG_HELLO_WORLD Magiclantern *building*, but it won't run; it will need some of the stubs that I haven't yet found.  I guess it might take 40 hours to try and find the 80 I know are currently wrong.  Then maybe another 40 to find the ones that are hard to find?  Then I don't know what is next; I guess maybe correcting the ML source code for assumptions it makes that aren't true for Digic 7.  I have noticed that some functions seem to have a changed number of parameters, perhaps that will become important.

If you can't afford IDA Pro + decompiler (about $4000), then I highly recommend Ghidra.  It's free, and has very similar features.  If you've not used something like that before I can get you started.  This lets you better compare a known good camera with a new camera, so you can find the equivalent functions in the new version.

You can stay logged into IRC permanently by using an IRC Proxy / Bouncer, then your IRC client connects to that.  ZNC looks alive, I've not tried it.

Hey guys! I recently bought a 200D and am quite stoked at the development on this forum! Would just like to know if there is anything I could do to help?

What kind of programming experience do you have?  I have a 200D and am slowing porting magiclantern.  There is not enough done yet to safely try running magiclantern, but if you are happy with C, ARM assembly, or reverse engineering, there's lots you could help with.

Progress pic

https://imgur.com/a/VUFcvou