Magic Lantern Forum

Magic Lantern Releases => Camera-specific discussion => Topic started by: Goonism101 on July 27, 2016, 04:44:28 AM

Title: Canon 750D
Post by: Goonism101 on July 27, 2016, 04:44:28 AM
@Alex I've been lurking these forums a while now. I've been waiting for some 7d Mark ii love and you guys are making progress with that (so thank you). However I also own a 750d. I wouldn't mind helping if it isn't too complicated. So let me know if you still need a volunteer for that. Thanks to all of you that put in this work for so many others.
Title: Re: Canon 750D
Post by: a1ex on July 28, 2016, 11:08:08 PM
(http://a1ex.magiclantern.fm/bleeding-edge/750D/6dflLnVM.jpg%3Alarge.jpeg)

Thanks Goonism101 and Austin Tsai.
Title: Re: Canon 750D
Post by: jacoblukas on July 29, 2016, 06:53:17 PM
I just stumbled upon this post, while browsing for some software tricks for my 750D. Having ML in my dslr would be a great thing, so I wonder how's the progress of implementing it in this model.
I could also help with testing and 'no-coding' related problems. Cheers. (:
Title: Re: Canon 750D
Post by: Walter Schulz on August 11, 2016, 10:22:21 AM
Just a reminder to whom it may concern: If you want to make things work you have to do something.

For 760D/750D [...] I have no feedback (I sent a few copies of the firmware dumper, but there was no response from the testers).

Sorry for double post!
Title: Re: Canon 750D
Post by: Roknix on August 16, 2016, 01:07:59 PM
Hello,

I'm also new here. I have a 750D and I can help maybe?

I have some skills in C#/C++ programming. But I never made a firmware like that. So I'm not sure where you need help and how I can help.

I also can test the Firmware if there are versions which are ready for testing. The only thing I need to know is, what I have to test ;)

Greez

Rok
Title: Re: Canon 750D
Post by: Walter Schulz on August 16, 2016, 04:09:42 PM
At the moment a1ex is looking for feedback from testers using his fimware dumper. If you want to take part contact a1ex.
Title: Re: Canon 750D
Post by: Roknix on August 16, 2016, 09:52:49 PM
Hello,

okey I've wrote him a PM. Thank you :)
Title: Re: Canon 750D
Post by: a1ex on August 20, 2016, 12:28:56 PM
Please find a ROM dumper for 750D that does not require additional hardware:

DMPD750D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/750D/DMPD750D.FIR)

The dumper built from the same source code was confirmed to work on 80D, so be sure to read these details (http://www.magiclantern.fm/forum/index.php?topic=17360.msg171019#msg171019) before trying it. If you manage to get it working, please send me a PM.
Title: Re: Canon 750D
Post by: Roknix on August 20, 2016, 08:19:08 PM
Hello

I got this:

https://www.dropbox.com/s/ioumocc1foep3my/20160820_200801.jpg?dl=0

Nothing changing after minutes.

I think my SD-Card is to big. I will try a smaller one.

greez
Title: Re: Canon 750D
Post by: danielmcarmelo on August 21, 2016, 10:04:22 AM
Hello

I got this:

https://www.dropbox.com/s/ioumocc1foep3my/20160820_200801.jpg?dl=0

Nothing changing after minutes.

I think my SD-Card is to big. I will try a smaller one.

greez
I have the same problem and I have a micro sd of 64GB. Have you resolved? Thanks
Title: Re: Canon 750D
Post by: Walter Schulz on August 21, 2016, 12:45:54 PM
Try a smaller card. 64 GB might cause troubles.
Title: Re: Canon 750D
Post by: Roknix on August 22, 2016, 06:54:10 PM
Hello I can confirm it is working. I've used a 16 GB SD-Card.

Please find the following picture:

https://www.dropbox.com/s/tuoo947hde67942/20160822_184151.jpg?dl=0

Just let me know if you need more help.

Greez Rok
Title: Re: Canon 750D
Post by: joopdehoop on August 23, 2016, 11:54:53 AM
Have been using ML on my own 600d for a while now. Bought a 750d for work (I work at a university magazine) and was expecting ML to work on that too since the models are so similar. I see now that it's not as easy as I thought, so I'd like to help out to make it happen. Bit of an amateur programmer and comfortable , so maybe I can help out if somebody points me in the right direction. Testing for example.
Title: Re: Canon 750D
Post by: julienpierb on August 24, 2016, 02:08:13 AM
Hi!
I would like to help but I have about zero programming knowledge, but I know I can somehow be useful!
Please, point me in the right direction and I'll do my best.
Title: Re: Canon 750D
Post by: Randyc714 on October 19, 2016, 02:00:25 AM
Like others I stumbled into this when I upgraded from a T3i to the t6i and found out ML wasn't available. 

I did the load referenced in an earlier message and was able to get the same screen about removing the battery.  Of course, it didn't mean much to me other than to whet the appetite. 

How can I help? I'm perfectly willing to run tests whenever needed.
Title: Re: Canon 750D
Post by: thiagolobo on November 14, 2016, 07:46:29 PM
I am also willing to help. I am pretty familiar with embedded programming and own a 750D.
Title: Re: Canon 750D
Post by: Walter Schulz on November 15, 2016, 10:02:57 AM
Start reading dmilligan's reply in this thread: http://www.magiclantern.fm/forum/index.php?topic=18222
Title: Re: Canon 750D
Post by: Haldi on December 04, 2016, 03:48:03 PM
I've Upgraded from my 500D to 750D on Black Friday.
I'm looking Forward to the development done here.
If some Testing is needed i Can help out.
Title: Re: Canon 750D
Post by: Vandaalite on December 09, 2016, 09:39:20 PM
Okay guys,
I tried to put ML on my 750D, and the first step is working (launch the .FIR on an SD Card and see it working on the screen) but then, a1ex told me to run it in QEMU and to reverse engineer the ROM.
I absolutely don't know anything about Linux, so I give it to one of my friends which tried to launch the script (the one of a1ex on this topic : http://www.magiclantern.fm/forum/index.php?topic=2864.0) but he didn't managed it :/
So, if anyone could help ^^'

Thanks  :)

PS : Sorry if there's some English mistakes, I'm French :s
Title: Re: Canon 750D
Post by: Tchello on December 22, 2016, 02:50:28 PM
So...
I bought the T6i about 2 months ago, and i'm looking for ML.
I wanna know in which stage are you guys on, and if I could help even though I don't know anything about programming.
If there's any update/progress/super-early version, can you send me with the instructions about how to install?
Thanks to you all, and sorry for the bad english(I'm Brazilian)
Title: Re: Canon 750D
Post by: DanielDeclap on December 30, 2016, 09:32:06 AM
I have recently upgraded to a 750d and am interested in participating in testing.
Title: Re: Canon 750D
Post by: pablumm on January 09, 2017, 10:08:01 PM
Hello ML community. I got a brand new T6i for Christmas. You can count on my help for testing and minor debugging.
I had the chance to play with ML on an older camera model, it was awesome. Thanks for the tremendous work.
Title: Re: Canon 750D
Post by: transporter on January 18, 2017, 05:18:25 PM
Hi all, I would like to help with getting ml to run on the 750d.
I ran the rom dumper on my camera, and this is the result.
six files were written to the sd card, but i've no idea what to do with them.
A guide for old folk would be handy.

(https://dl.dropboxusercontent.com/u/16703480/eos750d.jpg)

Title: Re: Canon 750D
Post by: agilb01 on February 03, 2017, 07:13:50 PM
I would be willing to help test.  Please let me know what in particular you would like help testing. Or is this just general bug finding at the moment?
Title: Re: Canon 750D
Post by: a1ex on February 10, 2017, 09:57:54 PM
A generous user just offered to give a T6i (750D) to the ML community. The camera is currently in US, but can be sent to Europe as well.

If you are interested, please prove your skills by showing the firmware running in QEMU (loading autoexec.bin and starting your own task alongside Canon's). This step was already done for 80D. All the files required to complete this task are public, assuming you can borrow this camera from a friend to get a ROM dump.

There's no need to show the GUI, but you'll get massive credits if you manage to do that.
Title: Re: Canon 750D
Post by: Lenodroid on February 12, 2017, 01:23:01 PM
So im getting a bit far...

I managed to decompile (Dissambly) the Rom dumps now i quite need someone's help to get more far.... Because I am basically a Designer not more :/

Anyways i will publish the stubs in 10 Minutes :D

Thanks
Title: Re: Canon 750D
Post by: Lenodroid on February 13, 2017, 09:39:19 AM
So Quick Update:

I need someone who is ready to work with me. The .dis file is 410MB big the firmware dump.......

If someone is ready to bring ML to 750D please PM me...
Title: Re: Canon 750D
Post by: matteopd on February 27, 2017, 11:33:54 PM
Hi, how may I help? I'm ready to test!
Title: Re: Canon 750D
Post by: anh.102w on March 28, 2017, 07:09:47 AM
I have a 750D. I ready for testing if anyone need
Title: Re: Canon 750D
Post by: Krakl on March 29, 2017, 01:48:18 AM
hey guys is the ML already running on the T6i?
Title: Re: Canon 750D
Post by: Walter Schulz on March 29, 2017, 07:16:53 AM
No
Title: Re: Canon 750D
Post by: Vandaalite on March 29, 2017, 10:41:20 PM
Hi,
I still have my 750D, and I'm ready to run any build of ML on it, so if you need, send a message ;)
Title: Re: Canon 750D
Post by: felipemazieri on April 03, 2017, 04:07:08 AM
Hi, I have a T6i (750D) and tested the file DMPD750D.FIR, after I start the file on the camera, (which I had to do on an 8GB card that I had lost here, my 64GB 2 did not want to accept, it was locked on the first attempt) the camera generated these files:
(https://drive.google.com/file/d/0B6ZLuNNAGb0ZaWZLQTQtaW5iOU0/view?usp=sharing)

https://mega.nz/#F!cpph3TQB!sA5bKeagRAMkdipH6ygeHw
Title: Re: Canon 750D
Post by: spichtig on April 04, 2017, 12:32:50 PM
hey i'm also interested in ml for the 750d. i'm also willing to help.
i do have basic programming knowledge in java an c++, but i haven't even installed ml on another camera.
let me know if i can help, or if anyone already got ml running on an 750d.
Title: Re: Canon 750D
Post by: mkroshana on May 11, 2017, 12:53:19 PM
Any progress ?
Even it is buggy, I would like to test it.
Title: Re: Canon 750D
Post by: Greg on May 11, 2017, 05:15:46 PM
qemu job rom      - Firmware version: 1.0.0 / 8.5.1 B4 (52)
felipemazieri rom - Firmware version: 1.0.0 / 8.7.1 B5 (53)

(https://s30.postimg.org/lfwvvk3r5/750_D.png)

So 750D has several firmware versions something like 70D?
Title: Re: Canon 750D
Post by: nikfreak on May 11, 2017, 06:34:55 PM
Yes, 70D had two revisions and 100D even three revisions to deal with.
Around ~2.5 years after anouncing the cams Canon decided to release the first firmware.

Wish ya good luck and even less waiting time!

Edit: Still got the old branches active in my repo if you are interested to see how we dealt with the fw revisions:

https://bitbucket.org/nikfreak/magic-lantern/branch/70D-merge
Title: Re: Canon 750D
Post by: Greg on May 11, 2017, 08:09:29 PM
No worries, I prefer to buy the D3300 (it's cheaper than 1300D) than get a free 750D.
Title: Re: Canon 750D
Post by: OlliDeluxe85 on May 21, 2017, 11:50:12 PM
Hey Guys,

is there still anybody working on ML for the 750d?

I bought my cam yesterday without the knowledge, that ML doesn't work. If I had known that, I had bought the 700d.

Hope anybody get ML working  8)
Title: Re: Canon 750D
Post by: matteopd on June 30, 2017, 12:02:48 AM
I'm still here willing to help if someone more skilled tells me what to do or with what to start with.
Thank you
Title: Re: Canon 750D
Post by: rejathcr on July 04, 2017, 07:46:10 AM
(http://a1ex.magiclantern.fm/bleeding-edge/750D/6dflLnVM.jpg%3Alarge.jpeg)

Thanks Goonism101 and Austin Tsai.



Do u have the firmware file? If so plzzz send me it
Title: Re: Canon 750D
Post by: rejathcr on July 04, 2017, 07:48:06 AM
So Quick Update:

I need someone who is ready to work with me. The .dis file is 410MB big the firmware dump......

If someone is ready to bring ML to 750D please PM me...



I'm ready,I have a 750D,so let me check it out
Title: Re: Canon 750D
Post by: rejathcr on July 04, 2017, 07:55:24 AM
Hello I can confirm it is working. I've used a 16 GB SD-Card.

Please find the following picture:

https://www.dropbox.com/s/tuoo947hde67942/20160822_184151.jpg?dl=0

Just let me know if you need more help.

Greez Rok
I too installed the DMPRD759D.FIR and it took 14gb out 16gb and how to use ML in 750D
Title: Re: Canon 750D
Post by: snewpers on July 10, 2017, 10:57:02 AM
This was all so simple on my 550D  :-\

I'm confused to be honest, is there a working version for the 750D now or is this a bit of a dead end for the 750? If there's anything I can do to 'help' it would be no problem.

Thanks!
Title: Re: Canon 750D
Post by: Walter Schulz on July 12, 2017, 03:05:18 PM
Again: If there is no ML for your cam (and there isn't for 750D) act like there will be no ML port for this cam ever.

You can buildup your skills in programming ARM architecture in C and assembler.
Title: Re: Canon 750D
Post by: Ant123 on July 12, 2017, 06:33:45 PM
Walter Schulz

Are not you tired of answering stupid questions from new members?
Maybe it's need to oblige them to read the FAQ before they can leave comments?
Title: Re: Canon 750D
Post by: matteopd on August 09, 2017, 11:43:43 PM
Again: If there is no ML for your cam (and there isn't for 750D) act like there will be no ML port for this cam ever.

You can buildup your skills in programming ARM architecture in C and assembler.

Is there a guide to follow step by step to help?
Title: Re: Canon 750D
Post by: matteopd on August 09, 2017, 11:47:17 PM
So Quick Update:

I need someone who is ready to work with me. The .dis file is 410MB big the firmware dump.......

If someone is ready to bring ML to 750D please PM me...

Are you still here? I've tried to PM you several times.
Title: Re: Canon 750D
Post by: a1ex on August 10, 2017, 04:12:58 PM
Is there a guide to follow step by step to help?

To quote from another firmware project (https://www.snbforums.com/threads/asuswrt-merlin-on-rt-n18u.19305/page-2#post-180983):
Quote
It's not as simple as "copy these two or three files, then compile and it will work". I won't know what it specifically takes until I go through the trouble of doing it myself [...]

However, you can take a look at the recent ports (EOS M2, 1300D, 1200D, 100D, 70D) or the other D6 threads (80D, 7D2, 760D, 5D4, don't forget CHDK) or the sticky threads from development or reverse engineering areas. You'll find this question already answered.

This is a good overview for pre-D6 models: https://www.magiclantern.fm/forum/index.php?topic=19417.0
This is an easy coding task for D6: http://www.magiclantern.fm/forum/index.php?topic=17360.msg184533#msg184533
This is another one (to be done with QEMU): http://www.magiclantern.fm/forum/index.php?topic=17360.msg187372#msg187372
This is yet another one: http://www.magiclantern.fm/forum/index.php?topic=17627.msg179772#msg179772
Title: Re: Canon 750D
Post by: a1ex on September 03, 2017, 10:01:44 PM
Ready to enable the boot flag: http://www.magiclantern.fm/forum/index.php?topic=17360.msg189584#msg189584

BOOTU750.FIR (http://a1ex.magiclantern.fm/bleeding-edge/750D/BOOTU750.FIR)
Title: Re: Canon 750D
Post by: Vandaalite on September 18, 2017, 02:40:17 PM
Try to run it on my 750D, with the Firmware 1.0.0
It works :)
Title: Re: Canon 750D
Post by: matteopd on September 22, 2017, 02:12:22 PM
Ready to enable the boot flag: http://www.magiclantern.fm/forum/index.php?topic=17360.msg189584#msg189584

BOOTU750.FIR (http://a1ex.magiclantern.fm/bleeding-edge/750D/BOOTU750.FIR)

What's a boot flag?
Title: Re: Canon 750D
Post by: Walter Schulz on September 22, 2017, 02:20:00 PM
http://www.magiclantern.fm/forum/index.php?topic=7569.msg65360#msg65360
Title: Re: Canon 750D
Post by: matteopd on September 22, 2017, 02:33:19 PM
http://www.magiclantern.fm/forum/index.php?topic=7569.msg65360#msg65360

I thank you very much.

So what a1ex said in his last message is to use his file to enable the camera boots from the SD? But then, what to do if we do not have a proper ML file to upload on the SD cause it's on development?

Thank you
Title: Re: Canon 750D
Post by: Walter Schulz on September 22, 2017, 02:42:32 PM
That's the point.  We have a method to set bootflag on Digic 6 cams but we don't have much else. Portable Display Test file may work, though.
But still looking for something like "Hello, World!" running along with Canon's firmware loaded.

Tons and tons of work and unchartered waters ahead.
Title: Re: Canon 750D
Post by: matteopd on September 22, 2017, 10:06:59 PM
Ready to enable the boot flag: http://www.magiclantern.fm/forum/index.php?topic=17360.msg189584#msg189584

BOOTU750.FIR (http://a1ex.magiclantern.fm/bleeding-edge/750D/BOOTU750.FIR)

It's working.
(http://thumb.ibb.co/d5TOpQ/ML.jpg) (http://ibb.co/d5TOpQ)
Title: Re: Canon 750D
Post by: a1ex on September 22, 2017, 10:16:21 PM
Alright then - here's the FIR to enable the boot flag (on any firmware version):

BOOTF750.FIR (http://a1ex.magiclantern.fm/bleeding-edge/750D/BOOTF750.FIR).

This will modify your camera.

After enabling the boot flag in the camera, you may run:

- the portable display test (http://www.magiclantern.fm/forum/index.php?topic=14732.0) (copy autoexec.bin and make your card bootable)
- the portable ROM dumper (http://www.magiclantern.fm/forum/index.php?topic=16534.0) (you may have to format the card to a very small size, or dd this 256MB image (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/sd.img.xz) - howto (https://thepihut.com/blogs/raspberry-pi-tutorials/17789160-backing-up-and-restoring-your-raspberry-pis-sd-card))
- anything compiled from the recovery (https://bitbucket.org/hudson/magic-lantern/branch/recovery) branch (it runs from bootloader context); check Makefile.user.default for options
- the digic6-dumper (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper) branch (start by adapting the 80D boot code, and aim for launching a user task alongside Canon firmware)

Good luck!
Title: Re: Canon 750D
Post by: Flance on September 24, 2017, 06:15:44 PM
Hey Alex, can’t I help out by being one your 750D testers if you need because I have my 750D whenever you need me :) look at message under
Title: Re: Canon 750D
Post by: Flance on September 24, 2017, 11:24:18 PM

(http://thumb.ibb.co/fzW5ok/image.jpg) (http://ibb.co/fzW5ok)

works perfectly fine.
Title: Re: Canon 750D
Post by: Chris71 on October 04, 2017, 08:11:22 PM
Hi Alex,

I haven't been on this forum since the ML development for the 550D.  :)

Recently I purchased a 750D. Since I enjoyed ML on the 550D, I hope that it will be possible to make it run on the 750D too.

Technically, I'm wondering if the 750D could be able to record 1080p videos at 50 or even 60 fps with ML. I guess that the Digic 6 processor would be able to handle this, because the 80D also has a Digic 6 and is able to record 1080p@60fps.
Title: Re: Canon 750D
Post by: a1ex on October 05, 2017, 09:02:49 PM
Hey - yeah, I remember the good old days :)

Here, it all depends on other 750D owners to jump in - you have ROM dumper, bootflag enabler, emulator, guides, docs, notes... even a free 750D (still) available for whoever decides to port ML on this camera (and proves their abilities).

I don't currently have a DIGIC 6 model, and unfortunately I no longer have the time and patience to do another ML port from scratch. Now it's your (DIGIC 6 and 7 owners') turn to drive the project forward.

I'll keep analyzing the DIGIC 6 models (look at 80D thread), maybe - hopefully - providing some GUI emulation for these models (that alone might take a couple of months or years), maybe a Hello World, and - of course - helping out whoever has the time, skills and motivation to complete and maintain the port (whether it's a DIGIC 2 or a DIGIC 7 or 8 or anything in-between).

This still applies: http://www.magiclantern.fm/forum/index.php?topic=17695.msg178750#msg178750

Good luck!
Title: Re: Canon 750D
Post by: t3r4n on October 21, 2017, 05:35:29 PM
Hi,
thanks to a1ex for his work.
So OK I'm willing to step in and help. My skillset includes programming micro controllers in assembler (back in the days it was the only "free" option to program atmel AVR chips before we got gcc and for the tiny ones still the best way). I can do a fair bit in C even though I'm not using it on a daily basis. Atlassian is not git but seems to be quite similar (no war regarding this statement please ;-) ).
   
So far I've been able to:
a) dump my ROM using the DMDP750.FIR
b) set the BOOT FLAG with BOOT750F.FIR

Questions
a) I've been reading here and in the CHDK wikis and found several Versions of the disassemble.pl script anyone with an idea which one to use best?  Does anyone use the CAPDIS and finish2 tools from CHDK? Is ARM-Console still usable with the digic6 and thumb2 processor?

b) with the bootflag enabled I've not been able to run any of the tools from a1ex post from 22nd of September. The card I'm using is a very old 256 MB card and according to fdisk on my Mac the partition is marked bootable. If I understand it right put the autoexec.bin on the card, put the camera dial on M and insert battery and turn on.
 
Title: Re: Canon 750D
Post by: a1ex on October 21, 2017, 09:18:38 PM
a) The one for ARMv7. For some reason I'm unable to load their wiki right now, so can't tell the exact link. Capdis works, ARM-console doesn't. There are many RE tools I didn't look into yet, and I expect many of them to work (look for Thumb2 or ARMv7 support).

b) The card must be bootable, see http://wiki.magiclantern.fm/install. The size restriction is only for the bootloader-based ROM dumper; other tools should work from any card (FAT12/16/32/EXFAT).

Knowing the AVR assembler will help a lot (the differences are small).

There are some half-successful experiments on the 80D thread, and some others with 5DS (recovery branch) so I recommend looking into these. You may try them in QEMU first (I'm looking for some help with proof-reading its README (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/) anyway).
Title: Re: Canon 750D
Post by: t3r4n on October 22, 2017, 09:24:46 AM
Hi a1ex,
thanks for the reply regarding booting I was able to solve that. On my way to the qemu directory I saw the the makeboot script and inside there I saw my fault of not giving the right name to the card ...  :-\

CPU Info from here http://www.magiclantern.fm/forum/index.php?topic=17714.25 (http://www.magiclantern.fm/forum/index.php?topic=17714.25) works as FIR not the autexec.bin Version (stalls after the second line). I will try to post some good images in the relevant thread later (during blanking the phone focusses out and when it has gained focus again the data already scrolled away  >:( and the camera with manual focus is not able to shoot its own back  ;)
The display Test http://www.magiclantern.fm/forum/index.php?topic=14732.0 (http://www.magiclantern.fm/forum/index.php?topic=14732.0) works but will show only one solid colour as background.
Model ID: 0x393 750D, Camera Model: EOS K393, Firmware 1.0.0 / 8.7

Regarding qemu after some trouble with python pip not working with the compiler I had enabled in my environment I was able to compile qemu and boot it with the default ML and my ROM in the end I got the same result as above.
 
Title: Re: Canon 750D
Post by: matteopd on November 11, 2017, 10:02:05 AM
Hi a1ex,
thanks for the reply regarding booting I was able to solve that. On my way to the qemu directory I saw the the makeboot script and inside there I saw my fault of not giving the right name to the card ...  :-\

CPU Info from here http://www.magiclantern.fm/forum/index.php?topic=17714.25 (http://www.magiclantern.fm/forum/index.php?topic=17714.25) works as FIR not the autexec.bin Version (stalls after the second line). I will try to post some good images in the relevant thread later (during blanking the phone focusses out and when it has gained focus again the data already scrolled away  >:( and the camera with manual focus is not able to shoot its own back  ;)
The display Test http://www.magiclantern.fm/forum/index.php?topic=14732.0 (http://www.magiclantern.fm/forum/index.php?topic=14732.0) works but will show only one solid colour as background.
Model ID: 0x393 750D, Camera Model: EOS K393, Firmware 1.0.0 / 8.7

Regarding qemu after some trouble with python pip not working with the compiler I had enabled in my environment I was able to compile qemu and boot it with the default ML and my ROM in the end I got the same result as above.

Hi t3r4n, where are you from?
Title: Re: Canon 750D
Post by: t3r4n on November 13, 2017, 10:10:24 PM
Hi,
@matteopd : is europe precise enough

@all :
I would like to summarise  the information I researched from various sources and garnish them with some questions:
- so my 750D has a processor called digic6 which is in fact 2(3?) processors in one chip the main one being an arm7 cortex
- being an arm7 cortex it understands two dialects of opcodes: arm and thumb2. To switch between the two a ldx or blx instruction is used. Our disassemblers have a problem in deciding when to use which dialect (still true or old information?)
- there is a co processor handling much of the io stuff the main processor talks to it via e.g. cdp mcr
- there is a tool enabling the boot flag on the camera. is there a source for that (could be that I'm missing the obvious)?
- qemu enters the firmware at 0x7c000008 why this odd (even though it is even :) ) address and not 0x7e02000 which is the firmware start? The first eight bytes at 0x7c000000 are no legal opcodes I understand.
- in the qemu code it says under digic6 .rom0 not yet dumped. is that something we are missing? haven't found anything in the forum on the topic
- I have been casually stepping through the startup code and noticed several loop doing nothing else but counting down r0 from e.g.. 0x20a or 0xf there are other loop copying stuff (e.g. from rom at 0xfe020000..40 to 0x0 in tcm.code) I assume these are to sync stuff and wait for some things to settle or is there any "magic" arm stuff I'm missing out?

At the moment I'm experimenting with radare2 as a replacement for gdb. It has some nice analysis features (if I had the money for IDA I would have bought a different camera instead ;) ) it is even possible to dry simulate an arm system without qemu attached.
The camera itself seems to have an interface in the battery compartment (JTAG? serial? ) Does anyone have information on that? I could 3D print a battery dummy an put connectors as they're used on testbeds for PCBs on it to get an interface but I'm a  bit reluctant to do this to my camera.

Well so far, more questions as they arise.
 




 

Title: Re: Canon 750D
Post by: a1ex on November 13, 2017, 11:07:05 PM
Cortex R4.

Start address: 0xFC000008 = *(uint32_t*)0xFC000000. Cross-check with EOS M3/M10 (dumps available on CHDK forum) - these have a really odd start address. Earlier models (before D6) start at FFFF0000.

Portable dumper source (works on all models): recovery branch, CONFIG_BOOT_DUMPER=y .

No idea what's in ROM0 - M3 has one at 0xFB800000, size 0x800000. I remember trying to dump from 0xF0000000 (where ROM0 is on earlier models) unsuccessfully, a long time ago. Can you try poking around?

There are a bunch of things copied from ROM to RAM before execution (-d romcpy to identify them from qemu). If some piece of code is copied to RAM, it's meant to run from there; otherwise, it's meant to run directly from the ROM.

Battery pins info: https://www.magiclantern.fm/forum/index.php?topic=7531

Most of the I/O (with hardware devices) is MMIO (C0000000 - DFFFFFFF) and there's also a custom interrupt controller. Coprocessors handle stuff like cache configuration, memory attributes, system registers etc - they can be found in ARM docs (ARM ARM v7 and Cortex R4 TRM). There are secondary processors as well - in particular, the MPU (http://www.magiclantern.fm/forum/index.php?topic=17596.0) handles buttons, shutter mechanism, lens communication, stores a few settings and maybe other stuff. Zico is likely the display controller, Xtensa (look it up on CHDK).
Title: Re: Canon 750D
Post by: t3r4n on November 14, 2017, 08:18:18 PM
Hey a1ex,
thanks for the quick reply.
Got the portable dumper working (on cam and qemu), someone posted two updates on the recovery branch yesterday  ;D.
About the rom0 I read about it in the qemu/hw/eos/mode_list.c under default digic6.
I will do some poking.

With the hardware in the battery compartment hmm looks doable. I'm missing the information on Voltage levels but other than that, by looking at the strings output of the rom, the factory menu behind akashimorino seems to offer some more "poking" options.
Title: Re: Canon 750D
Post by: a1ex on November 14, 2017, 11:34:47 PM
Yes, the dry-shell console is definitely useful; unfortunately it only works in QEMU on DIGIC 4 and 5. On D6, it only recognizes the first character, then it locks up...

To debug this: -d io,uart,int

I'm also interested in checking MPU serial console logs from older cameras (in particular, DIGIC 4, where the MPU architecture is known and documented, unlike newer models where it's just a black box), but it's a low-priority task for me (more like a curiosity).
Title: Re: Canon 750D
Post by: t3r4n on November 20, 2017, 07:10:02 PM
Is this picture https://www.aliexpress.com/item-img/The-original-mother-board-big-board-PCB-for-Canon-EOS-750D-Rebel-T6i-DS126571SLR-camera/32693901124.html (https://www.aliexpress.com/item-img/The-original-mother-board-big-board-PCB-for-Canon-EOS-750D-Rebel-T6i-DS126571SLR-camera/32693901124.html) all that is available? I'm not really willing to open mine. Someone must have dropped one so we can do an autopsy.
Title: Re: Canon 750D
Post by: spankyhiney on November 26, 2017, 06:21:27 PM
I also have a T6i 750D, I am a willing to help in anyway to forward progress on this ML project. 
Title: Re: Canon 750D
Post by: totka on November 29, 2017, 10:48:37 PM
Hey folks, I also happen to have a 750D and I would be glad to help you out. Unfortunately I have no programming skills.
Thank you all for all your work on this project !
Title: Re: Canon 750D
Post by: A8M on December 06, 2017, 04:19:39 AM
Well my T7i had a issue and wound up coming home with a new but older T6i.  Exactly where is everybody at on the development.  Just in the few minutes I've played with this thing the firmware is glitchy. 
Title: Re: Canon 750D
Post by: t3r4n on December 06, 2017, 07:35:19 PM
Development is a high word. Let's call it discovery.
When time permits I'm stepping through with qemu and start reading the arm docs with every new discovery. Understanding the minimal.c in the recovery branch and changing bits and pieces (@a1ex haven't found a ROM0 either all dumps in the 0xFxxxxxxx below 0xfc000000 returned nothing)

Question: does anybody know why the interrupt vector table gets build in the boot loader and then again once the "Bootloader END" is on stderr?
 
Title: Re: Canon 750D
Post by: a1ex on December 06, 2017, 07:46:12 PM
One is meant to be used in the bootloader (maybe some parts of the code require interrupts), the other is for main firmware. The two are separate pieces of code - you can't call bootloader functions from main firmware, or the other way.

If you look at M5 firmware, they went even further - there is a tiny bootloader, then a secondary bootloader that uses a DryOS core (!), and then it jumps to a second DryOS core which is probably the main firmware.
Title: Re: Canon 750D
Post by: a1ex on December 20, 2017, 12:57:50 AM
Yes, the dry-shell console is definitely useful; unfortunately it only works in QEMU on DIGIC 4 and 5. On D6, it only recognizes the first character, then it locks up...

Solved (http://www.magiclantern.fm/forum/index.php?topic=2864.msg194899#msg194899) :)
Title: Re: Canon 750D
Post by: t6i-user on December 20, 2017, 06:31:15 PM
Yay Alex!!!!   :)   seems the hurdles are being cleared for Digic 6!
Title: Re: Canon 750D
Post by: t3r4n on December 21, 2017, 09:21:20 PM
... and those "year end holidays" around the corner to play :D 
Title: Re: Canon 750D
Post by: t3r4n on December 22, 2017, 07:16:45 PM
So I couldn't wait like a child before Christmas  ::) and started with the SFDATA I got from an 700D without wasting time on patching and after the magic word and and "i" I get this :
Code: [Select]
Name            ID   State Pri         Wait(ID)      Stack  % StackTop StackEnd       SP
EventMgr   0037000c    WAIT  13  RCVMQ(00360006)  01a0/1000 10 002f0560 002f1560 002f14a8
EFLensComT 0042000d    WAIT  15    SEM(003f0025)  0098/0400 14 002e8520 002e8920 002e88b8
MainCtrl   007c0016    WAIT  16  RCVMQ(007b001a)  01d0/1000 11 002f7598 002f8598 002f8510
RTCMgr     00520010    WAIT  17  RCVMQ(00510012)  0288/0400 63 002ecd38 002ed138 002ed080
RscMgr     005a0012    WAIT  17  RCVMQ(00590014)  02f0/1000 18 002f3578 002f4578 002f44c0
OmarInit   00280009    WAIT  18  RCVMQ(00270003)  02f0/0400 73 002e8118 002e8518 002e8460
PropMgr    0031000a    WAIT  20  RCVMQ(00300004)  0378/1000 21 002ee550 002ef550 002ef498
MainSubTas 0047000e    WAIT  20  RCVMQ(0043000e)  00b0/0400 17 002e8928 002e8d28 002e8ca8
FileCache  00570011    WAIT  20  RCVMQ(00560013)  00e8/1000 05 002f2570 002f3570 002f34b8
GuiLockTas 00730013    WAIT  23  RCVMQ(00720017)  00b8/1000 04 002f4580 002f5580 002f54f8
EvShel     008f001c RUNNING  24         -------   0320/8000 02 002fc5c0 003045c0 --------
ConsoleSvr 0097001e    WAIT  24  RCVMQ(00920020)  01e8/0800 23 00304dd0 003055d0 00305540
Startup    00220005    WAIT  25  RCVMQ(00210002)  03a8/2800 09 002ea530 002ecd30 002ecca8
FileMgr    004b000f    WAIT  25  SLEEP(004b000f)  02a8/1000 16 002f1568 002f2568 002f23e0
TOMgr      00750014    WAIT  25  RCVMQ(00740018)  0140/1000 07 002f5588 002f6588 002f64d0
Fstorage   007a0015    WAIT  25  RCVMQ(00790019)  00e8/1000 05 002f6590 002f7590 002f74d8
HDRMgr     00800018    WAIT  25  RCVMQ(007f001b)  00e8/1000 05 002f85a0 002f95a0 002f94e8
HDRStage   00820019    WAIT  25  RCVMQ(0081001c)  00e8/1000 05 002f95a8 002fa5a8 002fa4f0
GISMgr     0086001a    WAIT  25  RCVMQ(0085001d)  00e8/1000 05 002fa5b0 002fb5b0 002fb4f8
GISStage   0088001b    WAIT  25  RCVMQ(0087001e)  00e8/1000 05 002fb5b8 002fc5b8 002fc500
LowConsole 0096001d SUSPEND  25         -------   00d4/0800 10 003045c8 00304dc8 00304d58
NFCMgr     0033000b    WAIT  26  RCVMQ(00320005)  01c0/1000 10 002ef558 002f0558 002f04a0
AEmodeJudg 007e0017    WAIT  26    SEM(007d0045)  0090/0400 14 002ed140 002ed540 002ed4e0
DbgMgr     001e0004    WAIT  31  RCVMQ(001d0001)  0288/1000 15 002e9528 002ea528 002ea470
PowerMgr   001c0003   READY  32         -------   0060/0400 09 002e9120 002e9520 002e9500
idle       00010001   READY  33         -------   006c/0100 42 002e8010 002e8110 002e80d8

or sysConfig

Code: [Select]
K393[1]>sysConfig
vers_dry                 DRYOS version 2.3, release #0055+p4
vers_mk                  2.63
use_smp                  0
act_spi_sem              1
act_spi_event            1
act_spi_mq               1
act_spi_mutex            1
act_spi_cond             1
act_spi_timer            1
act_spi_clock            1
act_spi_isr              0
act_spi_objlist          1
act_spi_objinfo          1
act_spi_objsetname       1
act_timeout              1
act_objname              1
dbg_stack_check          1
dbg_error_check          1
dbg_logging              0
pu_max                   1
sys_mem_start   0x002e8000
sys_mem_max         933888
user_mem_start  0x001cc400
user_mem_max       1133044
sys_objs_start  0x002e0df4
sys_objs_end    0x002e8000
priority_max            34
task_max               119
semaphore_max          317
event_max               80
message_q_max          150
mutex_max              100
condition_max            0
timer_max                0
vector_max               0
it4_mbx_max              0
it4_mpf_max              0
it4_mpl_max              0
level_low                0
level_timer            128
level_kern             128
prio_default            16
stack_default         4096
stack_idle             256
stack_init            4096
stack_addr_idle 0x00000000
stack_addr_init 0x00000000
use_barrier              0
barrier_max              0

 sysConfig returned 1(0x1)

endless fun  :D
Code: [Select]
K393[1]>memMap
00000000 : DRY_EXCEP_VECTOR
00000000 : ATCM_START_ADDR
00004000 : ATCM_END_ADDR
80000000 : BTCM_START_ADDR
80010000 : BTCM_END_ADDR
001cc400 : heap start
           0x001149f4(1133044)
002e0df4 : heap end
002e0df4 : DRY_SYS_OBJS_START
           0x0000720c(29196)
002e8000 : DRY_SYS_MEM_START
           0x000e4000(933888)
001cc000 : DRY_ERREX_STACK_START
           0x00000400(1024)
001cc400 : DRY_ERREX_STACK
80000000 : DRY_EXCEP_STACK_START
           0x00000800(2048)
80000800 : DRY_EXCEP_STACK

 memMap returned 0(0x0)
Title: Re: Canon 750D
Post by: t3r4n on December 28, 2017, 10:10:46 PM
Hmm,
so I thought I had found the entry of SF_CreateSerial and SF_readSerialFlash.
With that I thought I can take the digic_dumper branch and the sf_dump.c from unified branch and do something like this in reboot.c:
Code: [Select]
...
#define BUF_SIZE    1024
static void __attribute__((long_call)) (*SF_CreateSerial)() = NULL;
static void __attribute__((long_call)) (*SF_readSerialFlash)(int src, void* dest, int size) = NULL;
//static int (*SF_Destroy)() = NULL;

/* optional; dumping more will just repeat the contents */
static int SF_flash_size = 0x1000000;

static void sf_dump(int drive)
{
  SF_CreateSerial     = (void*) 0xfe32a226;
  SF_readSerialFlash  = (void*) 0xfe32a1ea;
  //SF_Destroy          = (void*) 0xFF13AF5C;
  // TODO correct size
  SF_flash_size       = 0x800000;
  // This is where the magic happens
  printf("Opening serial flash...\n");
  /* todo: check return values */
  SF_CreateSerial();
  char buffer[BUF_SIZE];
  int filecount =0;
  char sffile[10];
  printf("Reading serial flash...\n");
  /* TODO testing, only 10 files */
  for (int i=0;(i<SF_flash_size)&&(filecount<10);i+=BUF_SIZE) {
    SF_readSerialFlash(i, &buffer, BUF_SIZE);
    snprintf(sffile, sizeof(sffile), "SF%03d.MD5\0", filecount);
    save_file(drive, sffile, (void *)buffer, sizeof(buffer));
    printf("\b\b\b\b%3d%%", (i + BUF_SIZE) * 100 / SF_flash_size);
    filecount++;
  }
}
...
I didn't see any malloc being used hence the idea of using static blocks of char.
But sadly when being run this will fail as the functions are being reached (confirmed by hitting the breakpoint) but some other stuff isn't properly aligned at this stage and they wind up in a loop in memory locations I don"t see when run under firmware conditions.
Maybe I should be looking into starting a thread first and then dump ... guess more debugging
Title: Re: Canon 750D
Post by: a1ex on December 28, 2017, 10:18:55 PM
You cannot mix functions between bootloader and main firmware - they are two different codebases. When in bootloader, you can only call bootloader functions (except maybe for trivial functions that do not use any global variables). The same applies after you jump to main firmware - you can no longer call bootloader functions.

There seem to be serial flash routines in the bootloader (http://www.magiclantern.fm/forum/index.php?topic=17360.msg195249#msg195249), but I didn't look into them yet.
Title: Re: Canon 750D
Post by: space928 on December 29, 2017, 12:31:41 PM
I just got my 750D and would love to help with the development of Magic Lantern for it, I have experience with programming in c based languages, shaders, some electronics and photography. How can I help?
Title: Re: Canon 750D
Post by: t3r4n on December 29, 2017, 10:02:59 PM
Yes there are more routines :) .

The Bootloader copies 0xe500 bytes of code into RAM at location 0x40100000.
In there I found a routine at 0x40106200 that dumps a few bytes of the serial flash.
I put a simple jump to this in the rebbot.c code. If you switch qemu to serial console you can see it waiting for input. If you enter e.g. 0 and press enter it will show the first few bytes from the sflash. After that it returns to the main SIO Menu where there is another function (enter 7) which will let you choose the range of bytes to dump (don"t have that exact entry point as I messed up). I expect them to have maybe a function underneath to access the sflash. I don't know whether I will have some more time this year  ;) I put a messy (but working) bit up in bitbucket. Compile it
Code: [Select]
make clean ;make install_qemu ML_MODULES_DYNAMIC= CONFIG_BOOT_DUMPER=y
in the portable dir and open in qemu with an attached debugger set breakpoint at said dress and happy tracing.
https://bitbucket.org/t3r4n/magic-lantern/branch/sf_dump_trial (https://bitbucket.org/t3r4n/magic-lantern/branch/sf_dump_trial)
Title: Re: Canon 750D
Post by: a1ex on December 30, 2017, 09:03:46 AM
Nice find - who expected this to be called SROM? :D

Just like with the boot flag routine, we need to skip the interactive part (since we don't have access to the serial console on a real camera - or maybe we do? (http://www.magiclantern.fm/forum/index.php?topic=7531) hint for @space928 - "some electronics" sounds useful) and call the read routine directly. This appears to do all the interesting stuff, but has an unusual syntax: 0x40104DA8 sf_read_sio. Fortunately, it's called from many other places, so we can look at those to understand how to call it.

First argument is a pointer to a data structure. It's not obvious to me what that structure should contain (I'm not that skilled in reading ARM disassembly), so I'm going to trace the calls in the emulator. Notice how it's used in the routine: in the loop at 40104DE4 it reads each int32 until encountering -1, so it's probably a variable-sized list.

Second argument looks like an output buffer (written at 40104F0C), and third argument looks like its size.

Fourth argument looks like some boolean flag.

With this initial info, we can write the following GDB script for tracing the calls to this function (I usually place these in debugmsg.gdb):
Code: [Select]
b *0x40104DA8
command
  silent
  print_current_location
  printf "sf_read_sio(%x { ", $r0
  set $addr = $r0
  while *(int*)$addr != -1
    printf "%x ", *(int*)$addr
    set $addr = $addr + 4
  end
  printf "-1 }, %x, %x, %x)\n", $r1, $r2, $r3
  c
end

Running on t3r4n's example (type 1234 at the address prompt):
Code: [Select]
make -C ../magic-lantern/platform/portable.000/ install_qemu ML_MODULES_DYNAMIC= CONFIG_BOOT_DUMPER=y
./run_canon_fw.sh 750D,firmware="boot=1" -d io,sflash -s -S & arm-none-eabi-gdb -x 750D/debugmsg.gdb

Read Address[0x000000-0x7FFF00]:0x1234
[            :401057dc ] sf_read_sio(80000f00 { 3 0 12 34 -1 }, 80000b00, 100, 1)
[DIGIC6]   at 0x40104DC0:401057E0 [0xD20B0D8C] <- 0xC0003   : SPI
(some activity on SIO2)
[DIGIC6]   at 0x40104F24:401057E0 [0xD20B0D8C] <- 0xD0002   : SPI
          4  5  6  7  8  9  A  B  C  D  E  F  0  1  2  3
00001234 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...

What does that mean?

- it seems to work
- print_current_location only prints the call address, but no task info (we are in bootloader, no tasks were started, so it's OK)
- that data structure appears to encode the serial flash address (still unsure what's up with that 3)
- [0xD20B0D8C] is the chip select (https://en.wikipedia.org/wiki/Chip_select) GPIO for our serial flash (same as 80D, nothing much to do - maybe some refactoring)
- SIO channel is 2 (serial_flash_sio_ch in model_list.c is declared correctly)
- however, this SIO activity is not forwarded to serial_flash.c, because serial flash is not enabled on 750D in QEMU (to do so, copy the serial_flash_size line from 80D in model_list.c)

This changes the output to:
Code: [Select]
Read Address[0x000000-0x7FFF00]:0x1234
[            :401057dc ] sf_read_sio(80000f00 { 3 0 12 34 -1 }, 80000b00, 100, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x40104DC0:401057E0 [0xD20B0D8C] <- 0xC0003   : Serial flash CS
[EEPROM] Verbose: Got READ (03h)
[EEPROM] Verbose: address is now: 0x001234
[EEPROM] Verbose: Sent 256 bytes
[EEPROM] CS = 1
[DIGIC6]   at 0x40104F24:401057E0 [0xD20B0D8C] <- 0xD0002   : Serial flash CS
          4  5  6  7  8  9  A  B  C  D  E  F  0  1  2  3
00001234 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
...

It worked!

Still, let's not forget our initial goal - we need to figure out how to call sf_read_sio. Let's trace other calls - to get the FROMUTILITY menu, we can simply delete AUTOEXEC.BIN from the card image, but leave it bootable (yes, that happens when your camera locks up):
Code: [Select]
. ./mtools_setup.sh
mdel -i $MSD ::/AUTOEXEC.BIN
./run_canon_fw.sh 750D,firmware="boot=1" -d io,sflash -s -S & arm-none-eabi-gdb -x 750D/debugmsg.gdb
...
**** SROM(SIO2) Menu ****
0.Exit from SROM Menu
1.Erase Chip   0x00800000
2.Erase Block  0x00010000
3.Erase Sector 0x00001000
4.Write Data
5.Write from Card
6.SROM Dump(SIO Read)
7.SROM Dump(QUAD Read)
8.Get Info
>>6
Read Address[0x000000-0x7FFF00]:0x10000
[EEPROM] CS = 0
[DIGIC6]   at 0x00104DA8:001057E0 [0xD20B0D8C] <- 0xC0003   : Serial flash CS
[EEPROM] Verbose: Got READ (03h)
[EEPROM] Verbose: address is now: 0x010000
[EEPROM] Verbose: Sent 256 bytes
[EEPROM] CS = 1
[DIGIC6]   at 0x00104EC8:001057E0 [0xD20B0D8C] <- 0xD0002   : Serial flash CS
          0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
00010000 0F FF F0 00 00 00 01 20 00 00 00 00 10 01 41 90
...

We've got valid data!

However, our logging hook is no longer called. Why? Notice Canon code calls this routine from 0x0010smth, rather than 0x4010smth (0x40000000 is the uncacheable flag). However, it's their code that copied the bootloader routines at 0x40100000 (they copy to uncacheable memory, but execute from a cacheable address):

Code: [Select]
./run_canon_fw.sh 750D,firmware=boot=1 -d romcpy
B[ROMCPY] 0xFC020000 -> 0x0        size 0x40       at 0xFE0200C8
ootL[ROMCPY] 0xFE026450 -> 0x40100000 size 0xE500     at 0xFE0218EC
oadSLOT_A LOAD OK.
...

Anyway, let's adjust the address in the GDB script (b *0x104DA8) and run again.

Code: [Select]
>>6
Read Address[0x000000-0x7FFF00]:0x10000
[            :001057dc ] sf_read_sio(80000f20 { 3 1 0 0 -1 }, 80000b20, 100, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x00104DC0:001057E0 [0xD20B0D8C] <- 0xC0003   : Serial flash CS
[EEPROM] Verbose: Got READ (03h)
[EEPROM] Verbose: address is now: 0x010000
[EEPROM] Verbose: Sent 256 bytes
[EEPROM] CS = 1
[DIGIC6]   at 0x00104F24:001057E0 [0xD20B0D8C] <- 0xD0002   : Serial flash CS
          0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
00010000 0F FF F0 00 00 00 01 20 00 00 00 00 10 01 41 90
...

The logging hook is alive!

Another try:
Code: [Select]
8.Get Info
>>8
[            :00105ef8 ] sf_read_sio(80000f4c { 3 0 0 0 -1 }, 80000f1c, c, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x00104DC0:00105EFC [0xD20B0D8C] <- 0xC0003   : Serial flash CS
[EEPROM] Verbose: Got READ (03h)
[EEPROM] Verbose: address is now: 0x000000
[EEPROM] Verbose: Sent 12 bytes
[EEPROM] CS = 1
[DIGIC6]   at 0x00104F24:00105EFC [0xD20B0D8C] <- 0xD0002   : Serial flash CS
0x80000331

In this case, it reads 12 bytes from address 0. You may look up 0x80000331 here (https://sno.phy.queensu.ca/~phil/exiftool/TagNames/Canon.html).

Some more calls:
Code: [Select]
Read Address[0x000000-0x7FFF00]:0x123456
[            :001057dc ] sf_read_sio(80000f20 { 3 12 34 56 -1 }, 80000b20, 100, 1)

7.SROM Dump(QUAD Read)
>>7
Read Addr[0x000000-0x7FFF00]:0x1234
Read Size[0x4-0x800000]:0x100
[            :001059d0 ] sf_read_sio(80000ef8 { 9f -1 }, 80000eec, 3, 1)
[EEPROM] Verbose: Got RDID

[            :00104f78 ] sf_read_sio(80000ecc { 6 -1 }, 0, 0, 1)
[EEPROM] Verbose: Set Write Enable Latch

[            :00104fa4 ] sf_read_sio(80000ecc { 5 -1 }, 80000ec4, 1, 1)
[EEPROM] Verbose: [SR] >> 0x2

[            :00105b68 ] sf_read_sio(80000f14 { 6b 0 12 34 -1 }, 0, 0, 0)
[EEPROM] Verbose: Got QOFR (6Bh)
[EEPROM] Verbose: address is now: 0x001234

A-ha! The first parameter in arg0 is the raw serial flash command (see serial_flash_spi_write) and the remaining ones are its arguments (if any are required). The parameter we are interested in is 3 = READ, and its arguments are 3 bytes representing the read address. Our routine accepts an array of uint32_t's though.

The last parameter (R3) is used to enable the CS signal (now that we know the register, it's obvious what it does):
Code: [Select]
40104DB4                 LDR             R9, =0xD20B0000
40104DB8                 CMP             R3, #0
40104DBC                 BEQ             loc_40104DC8
40104DC0                 LDR             R12, =0xC0003
40104DC4                 STR             R12, [R9,#0xD8C]

Now we can write the function declaration (and maybe rename it to sf_command_sio, as it doesn't do just reads)
Code: [Select]
void sf_command_sio(uint32_t command[], uint32_t * out_buffer, int out_buffer_size, int toggle_cs);

Sample call (edit: output buffer is an array of uint32_t, not char):
Code: [Select]
uint32_t buffer[0x100];
int addr = 0x1234;
sf_command_sio((uint32_t[]) {3, (addr >> 16) & 0xFF, (addr >> 8) & 0xFF, addr & 0xFF, -1}, buffer, COUNT(buffer), 1);

"Beware of bugs in the above code; I have only proved it correct, not tried it." (source (https://en.wikiquote.org/wiki/Donald_Knuth))
Title: Re: Canon 750D
Post by: space928 on December 30, 2017, 06:45:57 PM
The 750D doesn't have all the battery pins shown in that thread. In the thread there are 16 pads in the battery compartment and in the 750D there are only 12 (and no they are not in a similar layout either, on the 750D the second row is offset from the right). I've not been able to find any information yet on the exact functioning of each of the pins but it's probably safe to assume that there isn't a serial interface. On another note, please don't get your hopes to high about testing stuff on my camera, I just got as a gift and I'm kinda paranoid about bricking/breaking it; sorry for hyping it up.
One suggestion though which I don't if it has been looked at yet is the USB interface on the camera it seems to have a lot of control over the camera, while using the software, you can control a lot of the different settings on the camera and shoot remotely. In brief: I feel like there's potentially a lot of potential using the usb interface. I'll look into it myself but if anyone else wants to as well, feel free.

EOS Utility Software:

(http://thumb.ibb.co/hS3kEw/image.png) (http://ibb.co/hS3kEw)


PS: I'm new to mercurial, could I have some help setting up qemu (and getting the correct branch and ROMs) so I can start playing with the emulator. Thanks.
Title: Re: Canon 750D
Post by: t3r4n on December 30, 2017, 09:56:23 PM
Great explanation. Espescially the bit on removing autoexec.bin to get to FROM Utility. That makes me really thinking on ordering some pogo pins a Bus pirate http://dangerousprototypes.com/docs/Bus_Pirate (http://dangerousprototypes.com/docs/Bus_Pirate) and either a cheap grip, a cheap fake battery and dismantle or make an adapter with the 3D Printer...

-I've enabled the SROM in qemu and made a pull request.

-I don't have any luck with this https://bitbucket.org/t3r4n/magic-lantern/commits/0676ba7fab9259607393a821a150f88e0f60cec3 (https://bitbucket.org/t3r4n/magic-lantern/commits/0676ba7fab9259607393a821a150f88e0f60cec3) my C seems a bit rusty but as a start. The qemu and camera survived but all empty. Its prepared for 80D as well.

-Playing around with the SROM utility and dry shell I noticed that they are using some opcodes that the emulator doesn't understand right now.

-If I interpret some of the boot code right they have code for different FLASH manufacturers in place (not sure yet).

-I have definitely seen a reference to a Marconix MX29GL256F NOR Flash driver (look into Strings but could bet the coprocessor section, anyway seems to be a beast with password protection and and so on) . 
Title: Re: Canon 750D
Post by: a1ex on December 30, 2017, 10:36:26 PM
-I don't have any luck with this https://bitbucket.org/t3r4n/magic-lantern/commits/0676ba7fab9259607393a821a150f88e0f60cec3 (https://bitbucket.org/t3r4n/magic-lantern/commits/0676ba7fab9259607393a821a150f88e0f60cec3) my C seems a bit rusty but as a start. The qemu and camera survived but all empty.

Odd - your code worked out of the box here in QEMU. Got a file named SFDATA.BIN, size 4096 bytes. Contents starting with 31 00 00 00 03 00 00 00 00 00 00 00 80 00 00 00, but the reference SFDATA.BIN starts with: 31 03 00 80, so the output buffer must be uint32_t * and each element is holding one byte. No big deal. Updated the declaration and the sample code.

I'd suggest trying to revert the vanilla SD image from sd.img.xz, on both QEMU and the physical SD card (http://www.magiclantern.fm/forum/index.php?topic=19417.msg183579#msg183579). Also, once you've got a SFDATA.BIN on the card, you may have to delete it if you want to run the dumper again (otherwise it will just create more files with the same name; how your file browser will react to that is... undefined behavior.)

Memory allocation: you have the entire 1GB 512MB (http://www.magiclantern.fm/forum/index.php?topic=5071.msg195400#msg195400) space that you can manage as you wish, as long as you are not overwriting Canon bootloader routines you may wish to call afterwards (the block at 0x40100000 and other memory addresses it might be touching - likely the TCMs). The display buffer is hardcoded at 0x04000000 / 0x04080000, so by hardcoding your buffer at 0x42000000, you've got 32MB of space (if you write more than that, you'll see it overflowing on the screen). The malloc_init call in this case does nothing interesting (it only makes sense if you call malloc afterwards). TLDR: it's fine, don't change it.

PS: I'm new to mercurial, could I have some help setting up qemu (and getting the correct branch and ROMs) so I can start playing with the emulator. Thanks.

Should be easy: watch these videos, then follow the guide:

Guide: https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/ (README)
Video: this sticky tweet (https://twitter.com/autoexec_bin/status/913530810686418944) and the same for Mac (http://www.magiclantern.fm/forum/index.php?topic=16012.msg191686#msg191686). GUI not working yet on D6.
Title: Re: Canon 750D
Post by: Smartservant on January 02, 2018, 04:54:00 PM
So... I have the same Problem and did anybody try the new link on the Camera? Or didn't I get it and sombody has already done it? Happy New Year and sorry for my English I'm German  ;D
Title: Re: Canon 750D
Post by: t3r4n on January 04, 2018, 09:13:08 PM
Code: [Select]
**** SROM(SIO2) Menu ****
0.Exit from SROM Menu
1.Erase Chip   0x00800000
2.Erase Block  0x00010000
3.Erase Sector 0x00001000
4.Write Data
5.Write from Card
6.SROM Dump(SIO Read)
7.SROM Dump(QUAD Read)
8.Get Info
>>8
0x80000393
:D
To be honest I've cheated when looking for the address and took the same offset as a1ex found on the 80D (0x5c from the address shown in SIO2 line) and then found it when "unaligning" in radare2. Mac has only 64bit GDB which really seems to have some issues (i.e. crashes).
I pushed the dumper and even did some progress counter while the user waits for the dump.

@a1ex do I get my ".serial_flash_size      = 0x800000," line in model_list.c now  ;)
maybe also the ram size?

There seems to be a lot of momentum and I'm trying to catch up with you guys and get the 80D stuff to 750D as my time permits.
Title: Re: Canon 750D
Post by: a1ex on January 05, 2018, 06:38:51 PM
Done, file I/O working in QEMU on 750D/760D as well (same as for 80D (http://www.magiclantern.fm/forum/index.php?topic=17360.msg194996#msg194996)) 8)

BTW, you may try to compile a 32-bit GDB for Mac; I've asked around and seems it should work (http://www.magiclantern.fm/forum/index.php?topic=16012.msg190687#msg190687).
Title: Re: Canon 750D
Post by: KJ M on January 12, 2018, 08:09:42 AM
Hey guys! I'm an amateur photographer and happened upon a t6i. I used a Lumix prior and am very happy with the camera but find many feature particularly the video lacking. I would like to help if I can in anyway possible. I will be shooting a week long event for a company both photo and video and would like to put some features the ML has. Let me know how I might be able to help and make this awesome software work properly on this camera.
Thanks Cheers from Sweden
Title: Re: Canon 750D
Post by: space928 on January 18, 2018, 11:29:24 AM
Ok, I know I'm probably missing something really obvious, but I can't for the life of me figure out where to get any of the ROM files from, I'd like to get my qemu to the point where I can at least start it without it crashing. Where do I get these ROM files?
Title: Re: Canon 750D
Post by: Walter Schulz on January 18, 2018, 01:31:57 PM
Top of page -> Downloads -> Download nightly builds -> ROM dumpers
or reply #7
Title: Re: Canon 750D
Post by: space928 on January 22, 2018, 07:30:54 AM
Ok, so I realise most people have probably got much further than me but here is what I've found (well got to work really) so far.
DryShell works when in "boot=0" (bootflag set to 0 I presume, this means it tries to boot from internal firmware)

(https://thumb.ibb.co/kJdGmw/image.png) (https://ibb.co/kJdGmw)

By setting "boot=1", such that it boots from the virtual sd card, I can boot into the magiclantern portable display test and the 750D ROMdumper which both work as expected:

(https://thumb.ibb.co/d7MizG/image.png) (https://ibb.co/d7MizG)

Booting without an AUTOEXEC.BIN results in the FORMUTILITY menu in the serial console as is already documented.

(https://thumb.ibb.co/eWuiYb/2018_01_22_3.png) (https://ibb.co/eWuiYb)

(https://thumb.ibb.co/gv01KG/2018_01_22_2.png) (https://ibb.co/gv01KG)

One interesting thing I found was that typing in the option U for firmware update here will cause the below error to show on the screen:

(https://thumb.ibb.co/chqCRw/2018_01_22_4.png) (https://ibb.co/chqCRw)

 (https://fr.imgbb.com/)

I can understand why the portable display test should work but I don't understand why the only bit of Canon code to display stuff on the screen should be the firmware update error message (is it maybe something to do with the fact that both the portable display test and the firmware updater run at the kernel level?)
Anyway, if none of this is new, I hope someone can at least point me in the right direction, thanks.

PS: Sorry for all the pics.
Title: Re: Canon 750D
Post by: a1ex on January 22, 2018, 09:34:16 AM
That's right. There's a whole lot more to understand about DIGIC 6 before it can print things on the screen from main firmware in the emulator - in particular, see the comments from Ant123 (http://www.magiclantern.fm/forum/index.php?topic=17360.msg196114#msg196114) (look up his earlier posts (http://www.magiclantern.fm/forum/index.php?action=profile;area=showposts;u=58043))

However, you can now run user code on the camera, log things to file (see the recent 80D progress), find the image buffers, write to them and check if any changes appear on the screen... so figuring this out is now a matter of "when" (the hard part - running user code alongside Canon's main firmware - was done for 80D).

Some notes: HACKING.rst (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst)
Title: Re: Canon 750D
Post by: space928 on January 23, 2018, 08:30:55 PM
Right, I've been fiddling around, but I hit a roadblock, I need a patched "SFDATA.BIN" to boot to the main firmware, I don't know where everyone else got there's, and from what I can tell, to proceed I need it:

(https://thumb.ibb.co/kA55Yb/image.png) (https://ibb.co/kA55Yb)


(https://thumb.ibb.co/gbKAzG/2018_01_23.png) (https://ibb.co/gbKAzG)

In the second picture, notice that I commented out part of the qemu command in qemu750D.sh (top-left). In the first, it's uncommented.
While, I'm not certain these two particular errors are caused by the lack of SFDATA.BIN, I realise I'll probably still need it later anyway.

At the moment I don't have access to any physical camera.
If anyone has any insight about these errors or how/where to get SFDATA.BIN, let me know (or PM it to me).
Thanks,
Title: Re: Canon 750D
Post by: a1ex on January 23, 2018, 09:13:38 PM
If you can get a log on the virtual card by running dumpf (http://www.magiclantern.fm/forum/index.php?topic=17360.msg194996#msg194996) in the serial console, that's pretty much the current state of the emulation. Using the right SFDATA.BIN won't bring the emulation much further; there is a dumper on t3r4n's repo (previous posts here and on the 80D topic), that I have yet to integrate in the main tree (it's on the list).
Title: Re: Canon 750D
Post by: t3r4n on January 30, 2018, 06:38:50 PM
Hello world,
back from where there is no internets  :( (but cool photo spots  :D).
@space928 : did you manage to get the SFDATA?
I see more then 100 change sets I think I need to catch up ...
 
Title: Re: Canon 750D
Post by: Iurii.favi on February 03, 2018, 11:07:27 PM
I have a camera and some dev experience, how I can help ?
Title: Re: Canon 750D
Post by: space928 on February 04, 2018, 09:34:24 PM
@t3r4n So sorry, but no. I don't have much time at the moment due to exams, I hope to get back on this project when I have more time though.


PS: I will still keep an eye on the forums for interesting developments though...
Title: Re: Canon 750D
Post by: lidjaj on February 09, 2018, 08:50:28 PM
Have been using ML on my own 600d for a while now. Bought a 750d for work (I work at a university magazine) and was expecting ML to work on that too since the models are so similar. I see now that it's not as easy as I thought, so I'd like to help out to make it happen. Bit of an amateur programmer and comfortable , so maybe I can help out if somebody points me in the right direction. Testing for example.

Its the same for me but then nothing happens, nothing changes
Title: Re: Canon 750D
Post by: xMASEx on February 16, 2018, 08:37:53 AM
Hello guys, I have the 750D and I want to help and try the ML on my camera.

I've looked but didn't quite understand where we at now, are we have unstable version, or it's not working at all yet ??

And how can I help to advance the development ??

Thanks.
Title: Re: Canon 750D
Post by: Arnaud Brb on February 17, 2018, 03:35:47 AM
Hello  :)

I discovered your work on the integration of ML on the Canon EOS T6i and I would wish to take part in the development, I do not know anything in coding, nevertheless I have T6i available for any test…

Did I download the file firmware“BOOTF750.FIR”, I need only this file?

Because the other versions of ml have one file "autoexec" and a folder “ML” which I do not find on your post…
 

I would thus expect some answers before trying the installation on my T6i

Still thank you for your work on this project !
Title: Re: Canon 750D
Post by: Walter Schulz on February 17, 2018, 08:22:20 AM
BOOTF750.FIR is a ROM dumper. It writes parts of cam's memory area into a file.
It's essential to run a cam inside a software emulator (QEMU).
Already been done.

Right now there is nothing to do for us mere mortals (=non-developers). Porting ML to Digic 6 will take serious time and effort.
Title: Re: Canon 750D
Post by: Arnaud Brb on February 17, 2018, 08:49:28 PM
Ok, isn't it yet possible to use ml on T6i even in version of development?
Title: Re: Canon 750D
Post by: space928 on February 18, 2018, 05:18:32 PM
Ok, isn't it yet possible to use ml on T6i even in version of development?
No, ML for DIGIC 6 based cameras is still in the reverse engineering phase. Until any porting, and that includes even the most basic ML features can start, the camera and it's inner workings (including the new DIGIC 6 processor and the Canon) must be fully understood at a low level before we can run anything on the camera.

If you want to help with development, clone the ML repository and get qemu (a generic CPU emulator) working for your camera, read through the rest of the thread for information on what has already been done. This will take a long time and will involve a lot of shots in the dark and head scratching, but we encourage anyone to help at this stage.
Title: Re: Canon 750D
Post by: Arnaud Brb on February 18, 2018, 10:47:48 PM
Ok, i'm looking this :)
Title: Re: Canon 750D
Post by: danieljanderson on March 11, 2018, 12:09:06 AM
I am new to this thread.  I always wanted ML for the t6i.  what language do you need to know to program hacks for the camera?
Title: Re: Canon 750D
Post by: t6i-user on March 11, 2018, 04:28:49 PM
So just to confirm, (without reading all the other model threads  ::)), ML has not been accomplished on any D6 cameras to date??
Title: Re: Canon 750D
Post by: space928 on March 11, 2018, 05:34:41 PM
I am new to this thread.  I always wanted ML for the t6i.  what language do you need to know to program hacks for the camera?
Hi at the moment we need a lot of help with reverse engineering so if you have any experience or can quickly get up to speed with qemu (and a little assembly) then I can help you get to where we are now. While doing this you will need some experience in bash and gdb scripts (if you do it on linux), other debuggers can also be used. Once we have overcome the first few roadblocks then most of the programming will be done in C.

To everyone else: I've had a little bit more time to further my understanding on the use of gdb and qemu and am currently digging into the ROM disassembly. Right now we are still at the stage where the camera boots into the bootloader and immediately drops you into the shell. This means the bootloader is functional but something is not being initialised/a flag is not set correctly/some hardware emulation problem (correct me if I'm wrong) making it abort the main boot sequence into the main firmware and GUI. At this stage I think what needs to be done is to trace all the calls to functions and try and guess where something isn't working, this will take a while, I don't know if there is anything else I can do to speed this up (maybe a call trace log in a working boot to see where it differs would help?).

Good luck.
Title: Re: Canon 750D
Post by: t3r4n on March 12, 2018, 08:39:59 PM
Hey space928,
what do you mean by "abort at boot"?
Do you stay at the bootloader shell or the dryos shell (the one where you enter akashimorino)?
The latter should be possible. We don't have a GUI at the moment as, as far as I understand it, as the memory address of the frame buffer is unknown.  Look here on 80D thread:
found in RAM dump
See also what alex wrote as a reply.
I'm tight on time at the moment and only looking up the forum from time to time to see what is happening.
Title: Re: Canon 750D
Post by: Ant123 on March 12, 2018, 09:30:33 PM
We don't have a GUI at the moment as, as far as I understand it, as the memory address of the frame buffer is unknown.
Even if you will know this address you will not get Canon GUI emulation because it's rendered by graphical core GV550 (http://www.gshark.com/en/products/gv550/index.html).
Title: Re: Canon 750D
Post by: space928 on March 13, 2018, 06:29:22 AM
Do you stay at the bootloader shell or the dryos shell (the one where you enter akashimorino)?
It gets into the dryos shell (the one where you enter akashimorino) if that helps.

Even if you will know this address you will not get Canon GUI emulation because it's rendered by graphical core GV550 (http://www.gshark.com/en/products/gv550/index.html).
Oh great, I didn't know we had specific details on which graphics core is used!
Title: Re: Canon 750D
Post by: t3r4n on March 13, 2018, 10:36:02 PM
Hmm,
from what I find about this thing it is quite nice, providing OpenGL and vector graphics. I found a japanese PDF https://www.khronos.org/assets/uploads/developers/library/2010-tokyo-press-update/Takumi-GShark_Tokyo-Dec10.pdf (https://www.khronos.org/assets/uploads/developers/library/2010-tokyo-press-update/Takumi-GShark_Tokyo-Dec10.pdf) stating that the core is implemented using the AXI Interface from ARM https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture#Advanced_eXtensible_Interface_(AXI) (https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture#Advanced_eXtensible_Interface_(AXI)). There seems to be an Android driver, haven't found it yet as OpenSource might be helpful.

So after some googling I found another user by the Name Ant on the CHDK Forum talking about this device ;)
And I now understand the sw command that doesn't work on the emulation.
So to make it work we would need to implement at last two more processors into the qemu emulation ( a xtensa and the gshark) to get it to work... maybe start again looking for real serial io on the camera itself.
Title: Re: Canon 750D
Post by: a1ex on March 13, 2018, 10:50:39 PM
This post (https://www.magiclantern.fm/forum/index.php?topic=21526.msg196300#msg196300) (from our friend Ant who ported CHDK on EOS M3) and the one after it suggests the communication might be using a SIO channel (SPI), just like the MPU. He has a very good suggestion here (https://www.magiclantern.fm/forum/index.php?topic=2864.msg194932#msg194932), alongside with some initial findings.

That said, the image buffer can be found in RAM, so a (possibly easier) task would be to find a spot in Canon code where we can draw directly into the VRAM, before it gets picked up by the display hardware. The best hint I can give right now is this (https://www.magiclantern.fm/forum/index.php?topic=17695.msg197085#msg197085). The io_trace (https://www.magiclantern.fm/forum/index.php?topic=2388.msg196941#msg196941) experiment will also likely reveal the complete communication between the two CPUs.
Title: Re: Canon 750D
Post by: space928 on April 01, 2018, 02:23:50 PM
So after learning the tools a bit better and some poking about, I've found... A SCREEN BUFFER, which I can write into. So the setup: I booted the firmware with the boot flag set to 1 (though I don't know if this is necessary) so that I could access the FROMUTILITY menu because I know that it has a command which will draw stuff to the screen, the Update Firmware command causes a bitmap in the rom to be copied onto the screen. After dumping the ram and fiddling with http://rawpixels.net/ (http://rawpixels.net/) I found the exact address of the display buffer which using gdb I can dump and restore to and from a file so I modified the file to prove it was a display buffer because as soon as that memory is changed, the results display immediately on the screen in qemu. So the screen is at 0x40370000 to 0x403c4600 and it's a 720x480 paletted display buffer. I found 16 colours I can display on it but I presume the palette can changed somewhere because the colours are non standard to EGA/VGA.

I can modify the display buffer at will, in this case I opened it as an 8bit grayscale raw image in photoshop and modified it before saving it and restoring it back to the emulator:

(https://thumb.ibb.co/h56N27/2018_04_01_2.png) (https://ibb.co/h56N27)


I also found where bitmaps are in the ROM, they're right at the start, stored as half height raw bitmaps which are lined doubled when copied onto the screen. I modified part of one of the bitmaps in the rom to show all the colours (I think):

(https://thumb.ibb.co/iA7LN7/image.png) (https://ibb.co/iA7LN7)


Another thing I'm curious about is the fact that I actually found more than one buffer in the ram, with different things in them, I've not tried writing into the other buffers yet but here they are as well (ignore the fact that there is a horizontal offset it's just because I got it a bit wrong, but you get the picture):

(https://thumb.ibb.co/kKgmvS/image.png) (https://ibb.co/kKgmvS)


What should I do next?
Title: Re: Canon 750D
Post by: a1ex on April 01, 2018, 03:53:18 PM
That's the display used by the bootloader (mostly for firmware updates). ML also uses it when enabling the bootflag, but things are a little different once you jump to main firmware.

Next step: adapt the 80D boot process (debuggable in QEMU), dump the RAM and try the DIGIC 6 Blind Edition :)
Title: Re: Canon 750D
Post by: space928 on April 01, 2018, 07:07:01 PM
try the DIGIC 6 Blind Edition :)
I don't understand what you mean by this, could you give me a link to a post?

Next step: adapt the 80D boot process
Again, sorry to pester you but could you give me a link where to find this.
Thanks
Title: Re: Canon 750D
Post by: ddelreal on April 01, 2018, 07:17:27 PM
Here you go, from the 80D thread:

Today, April 1st, announcing...

Magic Lantern Blind Edition for DIGIC 6 :)

Step 0: make sure you are running firmware 1.0.2 (ML does not check for that!)
Step 1: enable the boot flag (https://www.magiclantern.fm/forum/index.php?topic=17360.msg189646#msg189646) (if you haven't already)
Step 2: copy autoexec.bin to your card (download links below)
Step 3: pray that your camera won't explode
Step 4: start the camera
Step 6: report back

Release 0.001 (https://a1ex.magiclantern.fm/bleeding-edge/80D/0.001/autoexec.bin)
Features:
- LED blinking
- Still photo capture after 10 seconds
- Diagnostic log

Release 0.002 (https://a1ex.magiclantern.fm/bleeding-edge/80D/0.002/autoexec.bin)
Features:
- LED blinking
- Silent photo capture (without shutter actuation) after 10 seconds (camera must be in PLAY mode started from LiveView; ML does NOT check for that!)
- Diagnostic log

Keep in mind these binaries are truly blind (I could not test this functionality in QEMU). Anything can happen if you try to run them. Your 80D may very well turn into 1DX or it may explode. If it breaks, I'm unable to pay for repairs, sorry.

(https://a1ex.magiclantern.fm/bleeding-edge/80D/80D-blind.png)

Source code: open the binaries with a text editor.
For other D6 models, adapting the source should be straightforward.
For DIGIC 7, see here (https://www.magiclantern.fm/forum/index.php?topic=19737). Emulation-wise it's mostly identical to D6.

Have fun!
Title: Re: Canon 750D
Post by: t3r4n on April 02, 2018, 08:11:59 AM
Oh some easter eggs from a1ex. They have a filling too  ;). So I need to read the man page for patch(1) on my old days...
On the graphics buffer I had been tinkering with opencv on the dumps and making a kind of more universal tool for it, but nothing of value has yet been created.
Also on the electronics route I've got a cheap battery grip lying here waiting for autopsy on the pins.
I've also noted there is some software on the market claiming to be able to talk to the factory settings and dump eeprom for MainPCB change etc., all over USB... The new versions of wireshark can now log USB traffic if you do "sudo ifconfig XHC20 up" before and then choose XHC20 device.
Title: Re: Canon 750D
Post by: space928 on April 02, 2018, 01:07:23 PM
Hi, I'm still still looking for an SFDATA.BIN dump because I don't have access to one and I have a feeling it's what's stopping the boot:

(https://thumb.ibb.co/jn8rfS/image.png) (https://ibb.co/jn8rfS)

Right now I just renames ROM1.BIN to SFDATA.BIN to see if it would read, and it does, I can read data off it in FROMUTILITY (and I confirmed it's the right data and not garbled nonsense).
Reply or fire me an email at: thomas.glacticstudios@gmail.com
Title: Re: Canon 750D
Post by: t3r4n on April 02, 2018, 05:38:26 PM
space928 did you try https://bitbucket.org/t3r4n/magic-lantern/commits/da8cd6246673b1512749bd5919279ff956d9e62e?at=sf_dump_trial (https://bitbucket.org/t3r4n/magic-lantern/commits/da8cd6246673b1512749bd5919279ff956d9e62e?at=sf_dump_trial) on your camera?
Title: Re: Canon 750D
Post by: space928 on April 04, 2018, 08:17:55 PM
Thanks to @OlRivrRat I now have a Serial Flash dump for an 80D (pm him if you want it). I'm still having trouble to get it to work in qemu though and to be honest I have no idea if the dump is corruptor even compatible with the 750D, does anyone have any insight into this?

(https://thumb.ibb.co/kcJm1c/image.png) (https://ibb.co/kcJm1c)

In rawpixels.net, it looks like nothing I've ever seen, and I have no extra insight from looking at it in a hex editor. Any idea how to get something legible out of it?
Title: Re: Canon 750D
Post by: a1ex on April 04, 2018, 08:20:08 PM
You need a RAM dump from a real camera in order to locate the image buffer; emulation doesn't reach this stage.

See 80D.102/minimal.c (https://bitbucket.org/hudson/magic-lantern/src/digic6-dumper/platform/80D.102/minimal.c?fileviewer=file-view-default#minimal.c-118) in the digic6-dumper branch.
Title: Re: Canon 750D
Post by: space928 on April 05, 2018, 09:32:47 AM
Ahh, so we need a RAM dump of the camera once it has actually booted into the main firmware. I don't really know much about how to start all the tasks required to get the main firmware in a state where the physical camera will display things on the screen (or at least be ready to) and there's no way of knowing exactly how to as qemu won't emulate the camera to that stage yet.
Out of curiosity, @A1ex could I look at the source code for your Magic Lantern Blind Edition to help me understand how it works?
Otherwise help to get my autoexec.bin to boot the camera into the main firmware would be helpful.
Title: Re: Canon 750D
Post by: t3r4n on April 05, 2018, 07:10:26 PM
Hey space928,
maybe I go first and tell my understanding and a1ex can correct me  ;D.
So lets start with a working autoexec.bin for the 750D, the SFDUMPER :)

I understand that there is a part in DryOS which looks for an autoexec.bin if the boot flag is enabled.
This happens after the Bootloader finished and some hardware is set up and the main kernel is being copied to RAM (we see later) .

enter minimal.c

this seems to be our main()
Code: [Select]
void
 __attribute__((noreturn,noinline,naked))
 copy_and_restart( int offset )
 {
here we clean some memory with 0 values:
Code: [Select]
     zero_bss();
This part is well documented:
Code: [Select]

     // Copy the firmware to somewhere safe in memory
     const uint8_t * const firmware_start = (void*) ROMBASEADDR;
     const uint32_t firmware_len = RELOCSIZE;
     uint32_t * const new_image = (void*) RELOCADDR;

     blob_memcpy( new_image, firmware_start, firmware_start + firmware_len );

     /*
      * in cstart() make these changes:
      * calls bzero(), then loads bs_end and calls
      * create_init_task
      */
     // Reserve memory at the end of malloc pool for our application
     // Note: unlike most (all?) DIGIC 4/5 cameras,
     // the malloc buffer is specified as start + size (not start + end)
     // so we adjust both values in order to keep things close to the traditional ML boot process
     // (alternative: we could adjust only the size, and place ML at the end of malloc buffer)
     uint32_t ml_reserved_mem = (uintptr_t) _bss_end - INSTR( HIJACK_INSTR_BSS_END );
     INSTR( HIJACK_INSTR_BSS_END     ) += ml_reserved_mem;
     INSTR( HIJACK_INSTR_BSS_END + 4 ) -= ml_reserved_mem;

Now its becoming interesting we "bend" the vector for the init_task:

Code: [Select]
     // Fix the calls to bzero32() and create_init_task()
     FIXUP_BRANCH( HIJACK_FIXBR_BZERO32, my_bzero32 );
     FIXUP_BRANCH( HIJACK_FIXBR_CREATE_ITASK, my_create_init_task );

     // Set our init task to run instead of the firmware one
     INSTR( HIJACK_INSTR_MY_ITASK ) = (uint32_t) my_init_task;

     // Make sure that our self-modifying code clears the cache
     sync_caches();
and last we call the function:
Code: [Select]
     // We enter after the signature, avoiding the
     // relocation jump that is at the head of the data
     // this is Thumb code
     MEM(0xD20C0084) = 0;
     thunk __attribute__((long_call)) reloc_entry = (thunk)( RELOCADDR + 0xC + 1 );
     reloc_entry();
so at the moment we don't return from this but normally this would be just a call for a task in DryOS and the normal boot routine resumes at the vector we've bend above.

So the tasks at the moment:
- find the stubs (addresses) of the functions needed for the blind dump to work, as we experienced with the dumper these can hide in RAM or ROM as the kernel gets copied at startup (see above)
- with the stubs in place the firmware can resume booting and have our code as a task.
- we can dump the memory and search for whatever is needed

Question from me if ant123 is still reading on the CHDK M3 porting thread you mentioned finsig back in 2015 I haven't read all the 47 Pages yet but did you have any luck with the new finsig_thumb2? The M3 seems to be on the same DryOS release (55) as the 750D. If I try to generate stubs as described in the wiki it it will produce some warnings and then nothing more after 4 hours of generating sporadic high CPU Load I killed it.
Title: Re: Canon 750D
Post by: Ant123 on April 05, 2018, 11:44:08 PM
did you have any luck with the new finsig_thumb2?
No. There was no luck with finsig_thumb2 & DSLR's firmware. But it found more than hundred functions (https://app.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/platform/m3/sub/101a/stubs_entry.S#ln143) in M3 firmware.

To find bitmap, raw, video buffers in RAM dump I recommend this tool (https://chdk.setepontos.com/index.php?topic=12721.0).
Title: Re: Canon 750D
Post by: ruedigers on April 14, 2018, 10:03:08 AM
Hello to all,
I am new here in the forum. I read thru most of the thread, but will have to start over to gather where I need to start off.
My reasons 'd like to unlock my firmware:
I will try to help once I have figured out the basics (without bricking my camera).
Cheers,
Rudy
Title: Re: Canon 750D
Post by: a1ex on April 24, 2018, 12:38:42 PM
Hi, I'm still still looking for an SFDATA.BIN dump

Added support for serial flash to the portable ROM dumper (https://www.magiclantern.fm/forum/index.php?topic=16534.0).
Title: Re: Canon 750D
Post by: t3r4n on May 01, 2018, 03:12:36 PM
Some observations:
I got myself a cheap camera grip with battery that has the needle connections for the "maybe" serial IO equipped. I soldered some connections to it and with a hint from ant123 I've been able to identify some candidates
original thread
But so far I can't get it to talk to me properly.... so I watched the output of qemu with -d uart :
Code: [Select]
[UART]         at 0xFE0204F4:FE02013C ESC[1;33m[0xC0800010] <- 0x19     : ???
[UART]         at 0xFE020500:FE02013C ESC[1;33m[0xC0800018] <- 0x4       : interrupt flags?
[UART]         at 0xFE02050C:FE02013C ESC[1;33m[0xC0800008] <- 0x8081  : Flags?
After some reading on the arm website I suspect the UART to be similar to an IP core they call PL010, as the registers only match here and not the newer PL011. According to the doc the 0x19 in register 0x10 set the divider to 25 which doesn't make sense on a 3.988... clock as in the dock, but if they use a 4Mhz clock that would give exactly 9600 baud. But the other two registers are not to senseful (DCD enable, two stop bits? line return to 0 after send?).  As written above I can't get any senseful bytes out of it, at the moment I suspect my resistor based level shifter puts to much load on the interface.
Also by reading the docs I noticed that newer memory coupled devices on the AXI bus have something like an IDRegister so they can be identified in code. Maybe of interest with other function blocks.
Title: Re: Canon 750D
Post by: samuk190 on May 04, 2018, 11:48:29 AM
Hello to all,
I am new here in the forum. I read thru most of the thread, but will have to start over to gather where I need to start off.
My reasons 'd like to unlock my firmware:
  • unlock time limit for videos - apparently the video duration is limited to something below to 30 minutes (to avoid being taxed at a higher rate for video cameras)
  • unlock exposure time / shutter speed to for long time or manual exposure
I will try to help once I have figured out the basics (without bricking my camera).
Cheers,
Rudy
AS far as I Read in this forum post, the progress is 80% done.. they can run some code inside the firmware I think...
Title: Re: Canon 750D
Post by: CorneliaPablo on May 17, 2018, 04:52:54 AM
Can someone tell me how to get magic lantern in Rebel T6i or Canon 750D. If there isnt, can I help and can someone teach me on what is happening right now?

It would be an honor to learn. Can someone message me private to learn more about magic lantern.
Title: Re: Canon 750D
Post by: Zzii on May 24, 2018, 11:41:11 PM
ive been lurking this for hours but I have no coding skills. willing to be a tester though...hmu
Title: Re: Canon 750D
Post by: Tchello on July 05, 2018, 03:14:07 AM
I could be another potential tester!
I don't really know much about programming, most I have done is an AFK XP farming bot for a game.
Anyways, if I can help in any possible way, tell me!
Title: Re: Canon 750D
Post by: Treshet on July 07, 2018, 11:40:14 PM

(https://thumb.ibb.co/b80UK8/DSC03684_1.jpg) (https://ibb.co/b80UK8)


 :D
Title: Re: Canon 750D
Post by: space928 on July 29, 2018, 09:02:43 PM

(https://thumb.ibb.co/b80UK8/DSC03684_1.jpg) (https://ibb.co/b80UK8)


 :D
Great job Treshet! Now the stage we're currently at is basically all within the emulator so set up a VM (or a use a real machine if that's your style) and get QEMU running with the ROMS, you'll see you can only get so far into the boot process before it stops, see some of my earlier posts and what people like A1lex have said about them for tips on what to do next. The gist of it is that we need to disassemble the ROMs, and identify any parts where it breaks in qemu (I recommend using GDB to debug and then looking in the disassembly for how it's meant to works) and try patching any bits you can. I use Cutter as a disassembler because it's quite powerful and offers a QUI wrapper for the popular radare disassembler (which is entirely CLI but still very good).
Title: Re: Canon 750D
Post by: matteopd on August 21, 2018, 12:13:15 PM
Hi All! How are you?

@t3r4n it seems you are the one with deeper experience in this porting.

Months ago I helped with the ROM dumpering but I wasn't able to go further due to my lack of programming knoledge.

Is there anything I can help now, for example testing something with a real 750D?

Thank you
Title: Re: Canon 750D
Post by: a1ex on September 07, 2018, 09:54:00 AM
Just a heads up - porting the 80D startup code to other models is really just a matter of updating the stubs and startup constants, and can be tested/debugged in QEMU. Verified on 5D4 (https://www.magiclantern.fm/forum/index.php?topic=17695.msg205735#msg205735) and 200D (https://www.magiclantern.fm/forum/index.php?topic=19737.msg205290#msg205290). Source code (still) on the digic6-dumper (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper) branch.
Title: Re: Canon 750D
Post by: premiumkaza on October 04, 2018, 12:27:15 PM
Any updates for the 750d yet?
Title: Re: Canon 750D
Post by: mkroshana on October 06, 2018, 02:48:33 PM
We won't get ML ?  :(
Title: Re: Canon 750D
Post by: Walter Schulz on October 06, 2018, 02:58:24 PM
Asking "Are we there yet?" surely doesn't help getting there.
Title: Re: Canon 750D
Post by: Helpseeker on December 16, 2018, 08:12:39 PM
Hello!
Immediately apologize for the English language. I use google translator.
I understand that all the results are written here, but still ask.
Is there any progress in the development of firmware? Has anyone managed to run it on canon 750d?


And congratulations to all on the upcoming holidays! :)