Messages

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

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.

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?

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: [email protected]

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

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?

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!

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.

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.

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

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:






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,

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)



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:



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





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:





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.

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?

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:




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.

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?