Author Topic: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2) (Read 338222 times)

names_are_hard · « **Reply #200 on:** June 14, 2019, 10:07:43 PM »

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

totalmichel · « **Reply #201 on:** June 14, 2019, 10:19:15 PM »

Quote from: names_are_hard on June 14, 2019, 10:07:43 PM

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

I dont know much about assembly , but from what i got from the code exemples ML peeks and pokes memory adress to change settings, we already know that 6D2 can run custom codes. so what is necessary is to know where to poke the memory adress to change the codec.
i know how to program c# (not very useful to ml porting), so i'm investigating about arm assembly, and trying to learn basic stuff (as difficult as it may be), i also know that theres a way to log what the camera memory does while using different stuff (its used to find free memory spaces)

what i need to know is theres any way to find where to poke? and any way to make it run on power on? (even if necessary an custom card for it)

i know that is not ML porting, but it could be a temporary patch to enable the native 4k codec

names_are_hard · « **Reply #202 on:** June 14, 2019, 11:14:51 PM »

As I understand it, a lot of the difficulty is in getting ML to stay memory resident through the boot process. There is also a great deal of complexity dealing with an interrupt driven real-time OS with multiple processors. What you're asking would need all of that stuff. And at that point the hard parts of porting ML are done, so you may as well use ML and get the rest for free.

In any case, this is getting quite off-topic for this thread - really you are asking "is there a way to do just one thing on any Canon cam, I don't want all of ML".

totalmichel · « **Reply #203 on:** June 15, 2019, 12:26:38 PM »

Quote from: names_are_hard on June 14, 2019, 11:14:51 PM

As I understand it, a lot of the difficulty is in getting ML to stay memory resident through the boot process. There is also a great deal of complexity dealing with an interrupt driven real-time OS with multiple processors. What you're asking would need all of that stuff. And at that point the hard parts of porting ML are done, so you may as well use ML and get the rest for free.

In any case, this is getting quite off-topic for this thread - really you are asking "is there a way to do just one thing on any Canon cam, I don't want all of ML".

im not asking to be developed for me, im asking the more seasoned devs if theres any way i can try to develop that, or if is just impossible.

names_are_hard · « **Reply #204 on:** June 15, 2019, 04:15:18 PM »

Ah, I see, I hadn't understood that absolute possibility was what you were concerned with. It would certainly be *possible* to do what you're asking. It would probably be easier to port ML, then add the feature you want, than develop the feature you want from scratch.

TolisK · « **Reply #205 on:** June 21, 2019, 08:16:16 PM »

Hi is there a final version of magic lantern for 6DII?

I' tried runnig dumb autoexec with no results.

Any help?
THank you in advance

names_are_hard · « **Reply #206 on:** June 22, 2019, 06:17:18 AM »

If there was any news about 6D2 it would probably be in this thread. I'm not even sure anyone is working on a 6D2 port. Certainly there is not a final version. Sorry to disappoint!

turtius · « **Reply #207 on:** June 22, 2019, 11:39:01 AM »

I have been looking through several ram dumps of 200D and i was wondering where is the output of the raw DryOS debug messages and for that i need the following question to be answered.(I'd really appreciate it)

Where is the debug port for the 200D?
can the WIFI or NFC interface be used to send logs to the host (or any suitable interface for logs) ?

I have not been actively working on magic lantern either as i do not know what i am looking at.i just end up brut-forcing stuff which i know is not going to get me anywhere
Thank you,

kitor · « **Reply #208 on:** June 22, 2019, 03:13:36 PM »

By looking at the board photo from Aliexpress, it's the same style connector as on EOS R / RP, located under thumb rubber, near USB connector.
Just educated guess.

As connector is visually the same, pinout for R is here:
https://www.magiclantern.fm/forum/index.php?topic=7531.msg212071#msg212071

If that checks out - FPC that goes into it is less than usuall 0.5mm pitch.

turtius · « **Reply #209 on:** June 22, 2019, 05:26:20 PM »

Quote

By looking at the board photo from Aliexpress, it's the same style connector as on EOS R / RP, located under thumb rubber, near USB connector.
Just educated guess.

It's exactly the same but the pins could be different.Now its time to dissect a old video player and hopefully find the right FPC cable

names_are_hard · « **Reply #210 on:** June 22, 2019, 05:59:40 PM »

Fun to see a debug port! I am still working on 200D but it's very slow, I keep getting stuck with invisible bugs. I can build a CONFIG_HELLO_WORLD autoexec but it doesn't boot and I can't even find a place to LED blink to diagnose, QEMU or real cam (I guess it crashes very early). The same source, built for 50D, does boot in QEMU, so I'm hoping this means my build is okay, but my stubs or similar (register constants? MPU stuff?) are wrong.

Debug port could be very helpful. I'd join you but my electronics stuff is in a shipping contiainer 1000 km away.

Currently I'm working on making gdb go further with 200D, I have some limited progress and I'm improving my gdb scripting.

kitor · « **Reply #211 on:** June 22, 2019, 06:00:30 PM »

So at least location is right. As for this FPC pitch - I doubt you will find one, I measured it to be probably 0.4mm (maybe 0,35mm - hard to measure without desoldering connector), found just a single china source for matching parts...

I don't think they are using different pinouts, as connector is already exotic (it's impossible to use standard 0.5mm cable as it will short pins to ground). But if you find anything (or want to disassemble camera - on R there are testpads near connector that I used for all of my work), please update thread I linked before with your findings

@names_are_hard - debug connector is very useful. In R stubs you can find one for uart_printf, that was the only way I was able to debug R before I found out my RAM dump was wrong and I had 1-byte offset framebuffer location

turtius · « **Reply #212 on:** June 22, 2019, 06:53:24 PM »

@kitor How did you measure the pitch of the FPC connector with that small size?

P.S there is a very slim chance of me opening up the camera and probing points as my parents will most likely evaporate me from existence if they found out.

names_are_hard · « **Reply #213 on:** June 22, 2019, 07:50:35 PM »

Very interesting, mine isn't FPC. Jack's has a K2 label, I have K1 - and inside 3 exposed pads. Serial port without ground?

(my only nice macro lens is on the 200D...)

kitor · « **Reply #214 on:** June 22, 2019, 08:10:35 PM »

Quote from: jack001214 on June 22, 2019, 06:53:24 PM

@kitor How did you measure the pitch of the FPC connector with that small size?

Caliper

Quote

P.S there is a very slim chance of me opening up the camera and probing points as my parents will most likely evaporate me from existence if they found out.

And I disassembled mine. Still over a year to end loan payments, but that's the things you do for Science!

Quote

Very interesting, mine isn't FPC. Jack's has a K2 label, I have K1 - and inside 3 exposed pads. Serial port without ground?

Took me a moment to realize "K1" and "K2" is molded into case. I don't believe it's related to what's inside. More likely different factory code or something.

Side note: While RP on promo video had both debug connectors soldered (like my retail R does, 2nd we guess to be jtag), on photos from retail ones this 2nd connector is missing (pads only).
If those 3 pins are serial, then my bet is rx/tx/gnd, but IIRC all known cameras exposes both CPU and MPU serial ports, so this would be werid.

Since quality of picture is as visible, I see like three pads with solder on them just above those three, and something possibly hidden under sticker... like if connector just isn't soldered in.
That would fit as connector is 8 pin, soldered 4 pins on each side of connector.
I can't find any high res photo of the board to confirm those suspicions. Look at 2nd photo here: Aliexpress - that's best I found.

names_are_hard · « **Reply #215 on:** June 22, 2019, 08:34:15 PM »

Comparing the aliexpress pic, yes, it does look like the connector is missing, nice find, thanks. The sticker thing is the silver braided cushion you can see in aliexpress pic. There are four soldered pins hidden by case (these are ones visible in aliexpress), I think only 3 on the other side. The 3 and 4 are not aligned but do look the same pitch.

If the three gold pads don't act as test pads for Vcc/GND, Rx, Tx it's going to suck to connect to. I won't have access to tools until next month anyway.

a1ex · « **Reply #216 on:** June 22, 2019, 08:40:01 PM »

Quote from: jack001214 on June 22, 2019, 06:53:24 PM

P.S there is a very slim chance of me opening up the camera and probing points as my parents will most likely evaporate me from existence if they found out.

Don't worry - the UART port is not going to provide much info on top of what you already get from logs saved to the SD card. It's actually the opposite - our logs (i.e. those saved to SD) actually provide a bunch of context info, timestamps, program location and so on, besides the actual messages.

I've also found real-time logging via UART problematic while troubleshooting bricked cameras - it's just too slow to print all Canon's messages in real-time. No wonder they are printing only a tiny subset, and even that happens in a background task.

On EOS R, the UART port was the only way to get in. That's why it was very useful there, but - in my opinion - it's not necessary for ML development or reverse engineering on earlier models (including all DIGIC 6/7, and also the DIGIC 8 "PowerShot" hybrids).

That port is, however, very useful to troubleshoot a camera that doesn't boot (read: a defective camera). It could also also help with debugging early startup code, but that part was already done. Besides, for early startup code, I believe debugging is much easier in QEMU (even with the current limitations). Even if you don't get a display, you do have a way to run the program step by step, to trace calls to arbitrary functions and other stuff like that.

If you just want to read the UART messages, connect the ground to the hot shoe (it worked for me on 5D3), and hold a needle onto the test pin (TX on the camera board, RX on the dongle). That should do the trick, without a FPC.

Quote

can the WIFI or NFC interface be used to send logs to the host (or any suitable interface for logs) ?

Yes, but currently the only notes on the Wi-Fi interface are these (for the old 6D). One could certainly attempt to find the stubs and try that proof of concept code.

An easier way (read: without requiring additional reverse engineering) is to use a Wi-Fi SD card. You don't need a Wi-Fi camera for that.

Quote

As I understand it, a lot of the difficulty is in getting ML to stay memory resident through the boot process.

Actually this step wasn't *that* hard, and is already solved for all DIGIC 6/7/8 models

The minimal "Hello World" code runs on top of that.

turtius · « **Reply #217 on:** June 22, 2019, 10:43:18 PM »

Quote

Yes, but currently the only notes on the Wi-Fi interface are these (for the old 6D). One could certainly attempt to find the stubs and try that proof of concept code.

My new task.

Quote

I've also found real-time logging via UART problematic while troubleshooting bricked cameras - it's just too slow to print all Canon's messages in real-time. No wonder they are printing only a tiny subset, and even that happens in a background task.

Bummer! Well that saved saved me from evaporating.

Quote

Very interesting, mine isn't FPC. Jack's has a K2 label, I have K1 - and inside 3 exposed pads. Serial port without ground?

I think that could be a newer revision.
maybe to keep us out?

names_are_hard · « **Reply #218 on:** June 23, 2019, 09:31:05 PM »

Probably not to keep us out

Really Canon are remarkably friendly for reverse engineering. There are many standard anti-reversing measures they could take that they choose not to.

In other news, I have found a large mistake I had made porting to 200D! I've found a major cause for CONFIG_HELLO_WORLD ML not booting, even though digic6-dumper would boot. I had forgotten / not noticed that the dual-cpu code for avoiding race conditions was only in digic6 branch. So, I've been porting that code into unified for 200D. I've *almost* got it building, but it's failing at link time:

Quote

arm-none-eabi-ld: patch.o: in function `_patch_sync_caches':
patch.c:(.text+0xf4c): undefined reference to `_flush_i_cache'

I'm not sure but I think this code is broken on digic6, too, but digic6 is so stripped down that it doesn't build patch.c.

My changes are here if anyone would like to explain why I'm being stupid

https://bitbucket.org/stephen-e/ml_200d/commits/7ac5c6f5acc78be7df87e853235d52c2d826fa00

names_are_hard · « **Reply #219 on:** June 24, 2019, 07:58:12 AM »

More progress. Couldn't work out why the symbol isn't visible to the linker, so I faked that out. Some gdb work later and I realised I hadn't defined SIG_START so it was picking up a default. It now passes FW checksum code. Crashes very early, but, it now gets far enough to show a stuck LED in real cam - before it was failing too early even for that. I can now crash ML, not just digic6-dumper

I guess now I'll be spending lots of time in gdb. If only it didn't have the worst UI of any debugger I've ever used. Oh well, I do keep telling myself it's a useful tool to learn.

totalmichel · « **Reply #220 on:** June 24, 2019, 10:56:46 PM »

Quote from: names_are_hard on June 24, 2019, 07:58:12 AM

More progress. Couldn't work out why the symbol isn't visible to the linker, so I faked that out. Some gdb work later and I realised I hadn't defined SIG_START so it was picking up a default. It now passes FW checksum code. Crashes very early, but, it now gets far enough to show a stuck LED in real cam - before it was failing too early even for that. I can now crash ML, not just digic6-dumper

I guess now I'll be spending lots of time in gdb. If only it didn't have the worst UI of any debugger I've ever used. Oh well, I do keep telling myself it's a useful tool to learn.

very nice, thumbs up

names_are_hard · « **Reply #221 on:** June 30, 2019, 05:19:20 PM »

Some progress and an unexpected problem - QEMU now gets further than real hardware. I'm comparing a CONFIG_HELLO_WORLD build from my patched unified branch against a digic6-dumper build. I'll call these ML200 and D6. Here's the 200D code:
https://bitbucket.org/stephen-e/ml_200d/commits/f3d7f1c6face84e4d4f7d01125ded4e56b939144

Debugging via LED blinking, ML200 on real HW is locking up when cstart() tries to transfer control to copy_and_restart(). In QEMU this call works okay! D6 transfers control okay on QEMU and HW. I don't know what might cause this, and I'm unsure how to debug it - can anyone help? Perhaps something to do with the larger size of ML200 vs D6? Here's the build output for that:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000100 0x001b6300 0x001b6300 0x33ef4 0x3e8fc RWE 0x100 (ML200)
LOAD 0x000060 0x001b6300 0x001b6300 0x01b4c 0x02ea8 RWE 0x10 (D6)

Looks boring to me. Any ideas on how to debug appreciated.

names_are_hard · « **Reply #222 on:** July 03, 2019, 03:29:22 AM »

Significant progress: now gets as far as my_init_task()! This is nice, many more functions are available, logging to disk should be possible. My previous problem was defining a static function with the same name in boot-hack.c and reboot.c. Ordinarily that wouldn't be a problem, static, so only visible within that file == no name conflict. But here we copy raw mem from boot-hack object file while in reboot code - the compiler can't save me from that conflict. So, don't do that. Don't know why it doesn't break in Qemu.

It's currently failing the ml_used_mem > ml_reserved_mem check and therefore LED blinking forever.

names_are_hard · « **Reply #223 on:** July 04, 2019, 03:35:36 AM »

Can now boot a fair way, it returns from Canon's init task, power on switch works, buttons are responsive (they all make it crash, that's a response). No back screen and cam generally errors out quite quickly (with Err in viewfinder). The good news: I can log to DEBUGMSG.LOG and see asserts so I have good hints on how to proceed.

The code is kind of ugly, in particular I'm not sure the changes in qemu-util.c and .h should go into unified. I don't recommend running this one, but here it is:
https://bitbucket.org/stephen-e/ml_200d/commits/57efead89219199cfaab686d72b0fb532d5afe2e

turtius · « **Reply #224 on:** July 04, 2019, 08:05:39 PM »

Impressive! Keep it up! I do not have knowledge on disassembly and reverse engineering and i wish i could help.
Don't stop keep on going(you know i might own a 200D).

News:

Author Topic: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2) (Read 338222 times)