Canon 750D

[lidjaj]

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

[xMASEx]

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.

[Arnaud Brb]

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 !

[Walter Schulz]

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.

[Arnaud Brb]

Ok, isn't it yet possible to use ml on T6i even in version of development?

[space928]

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.

[Arnaud Brb]

Ok, i'm looking this

[danieljanderson]

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?

[t6i-user]

So just to confirm, (without reading all the other model threads  ), ML has not been accomplished on any D6 cameras to date??

[space928]

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.

[t3r4n]

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.

[Ant123]

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.

[space928]

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.

Oh great, I didn't know we had specific details on which graphics core is used!

[t3r4n]

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 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). 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.

[a1ex]

This post (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, 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. The io_trace experiment will also likely reveal the complete communication between the two CPUs.

[space928]

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




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




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




What should I do next?

[a1ex]

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

[space928]

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

[ddelreal]

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 (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
Features:
- LED blinking
- Still photo capture after 10 seconds
- Diagnostic log

Release 0.002
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.



Source code: open the binaries with a text editor.
For other D6 models, adapting the source should be straightforward.
For DIGIC 7, see here. Emulation-wise it's mostly identical to D6.

Have fun!

[t3r4n]

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.

[space928]

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:



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

[t3r4n]

space928 did you try https://bitbucket.org/t3r4n/magic-lantern/commits/da8cd6246673b1512749bd5919279ff956d9e62e?at=sf_dump_trial on your camera?

[space928]

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?



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?

[a1ex]

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 in the digic6-dumper branch.

[space928]

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.