Canon 750D

[Vandaalite]

Try to run it on my 750D, with the Firmware 1.0.0
It works

[matteopd]

Ready to enable the boot flag: http://www.magiclantern.fm/forum/index.php?topic=17360.msg189584#msg189584

BOOTU750.FIR

What's a boot flag?

[Walter Schulz]

http://www.magiclantern.fm/forum/index.php?topic=7569.msg65360#msg65360

[matteopd]

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

[Walter Schulz]

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.

[matteopd]

Ready to enable the boot flag: http://www.magiclantern.fm/forum/index.php?topic=17360.msg189584#msg189584

BOOTU750.FIR

It's working.

[a1ex]

Alright then - here's the FIR to enable the boot flag (on any firmware version):

BOOTF750.FIR.

This will modify your camera.

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

- the portable display test (copy autoexec.bin and make your card bootable)
- the portable ROM dumper (you may have to format the card to a very small size, or dd this 256MB image - howto)
- anything compiled from the recovery branch (it runs from bootloader context); check Makefile.user.default for options
- the digic6-dumper branch (start by adapting the 80D boot code, and aim for launching a user task alongside Canon firmware)

Good luck!

[Flance]

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

[Flance]

works perfectly fine.

[Chris71]

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.

[a1ex]

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!

[t3r4n]

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.
 

[a1ex]

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

[t3r4n]

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

[matteopd]

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

[t3r4n]

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.
 




 

[a1ex]

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

[t3r4n]

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

[a1ex]

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

[t3r4n]

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 all that is available? I'm not really willing to open mine. Someone must have dropped one so we can do an autopsy.

[spankyhiney]

I also have a T6i 750D, I am a willing to help in anyway to forward progress on this ML project. 

[totka]

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 !

[A8M]

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. 

[t3r4n]

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?
 

[a1ex]

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.