Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - names_are_hard

Pages: 1 ... 18 19 [20]
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?


Code: [Select]
kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i edmac | wc -l
kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i pcie | wc -l

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:

[NWCOM] Lime WorkLoad DMA

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:

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


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.

Reverse Engineering / Re: Ghidra scripts
« on: April 07, 2019, 09:51:23 AM »
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.

Reverse Engineering / Ghidra scripts
« on: April 07, 2019, 03:17:37 AM »
Ghidra is a free tool similar to IDA Pro.
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, - you give it a stubs.S file and it names and disassembles the stubs in your listing:
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).

 - 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:

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:

The Finding Stubs tutorial is also handy:

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.

Pages: 1 ... 18 19 [20]