Canon 750D

Started by Goonism101, July 27, 2016, 04:44:28 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.


Quote from: 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...

Solved :)


Yay Alex!!!!   :)   seems the hurdles are being cleared for Digic 6!


... and those "year end holidays" around the corner to play :D 


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 :

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

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

00000000 : ATCM_START_ADDR
00004000 : ATCM_END_ADDR
80000000 : BTCM_START_ADDR
80010000 : BTCM_END_ADDR
001cc400 : heap start
002e0df4 : heap end
002e8000 : DRY_SYS_MEM_START
001cc400 : DRY_ERREX_STACK
80000800 : DRY_EXCEP_STACK

memMap returned 0(0x0)


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:

#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 */
  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);

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


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, but I didn't look into them yet.


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?
Canon EOS 750D + Canon 28-80mm USM + Fujifilm Finepix s9200


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


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

b *0x40104DA8
  printf "sf_read_sio(%x { ", $r0
  set $addr = $r0
  while *(int*)$addr != -1
    printf "%x ", *(int*)$addr
    set $addr = $addr + 4
  printf "-1 }, %x, %x, %x)\n", $r1, $r2, $r3

Running on t3r4n's example (type 1234 at the address prompt):

make -C ../magic-lantern/platform/portable.000/ install_qemu ML_MODULES_DYNAMIC= CONFIG_BOOT_DUMPER=y
./ 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 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:

Read Address[0x000000-0x7FFF00]:0x1234
[            :401057dc ] sf_read_sio(80000f00 { 3 0 12 34 -1 }, 80000b00, 100, 1)
[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
[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

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

. ./
mdel -i $MSD ::/AUTOEXEC.BIN
./ 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
Read Address[0x000000-0x7FFF00]:0x10000
[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
[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):

./ 750D,firmware=boot=1 -d romcpy
B[ROMCPY] 0xFC020000 -> 0x0        size 0x40       at 0xFE0200C8
ootL[ROMCPY] 0xFE026450 -> 0x40100000 size 0xE500     at 0xFE0218EC

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

Read Address[0x000000-0x7FFF00]:0x10000
[            :001057dc ] sf_read_sio(80000f20 { 3 1 0 0 -1 }, 80000b20, 100, 1)
[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
[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:

8.Get Info
[            :00105ef8 ] sf_read_sio(80000f4c { 3 0 0 0 -1 }, 80000f1c, c, 1)
[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
[DIGIC6]   at 0x00104F24:00105EFC [0xD20B0D8C] <- 0xD0002   : Serial flash CS

In this case, it reads 12 bytes from address 0. You may look up 0x80000331 here.

Some more calls:

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

7.SROM Dump(QUAD Read)
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):

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)

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

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)


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.
Canon EOS 750D + Canon 28-80mm USM + Fujifilm Finepix s9200


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


Quote from: t3r4n on December 30, 2017, 09:56:23 PM
-I don't have any luck with this 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. 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 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.

Quote from: space928 on December 30, 2017, 06:45:57 PM
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:

Quote from: a1ex on December 20, 2017, 12:38:57 AM
Guide: (README)
Video: this sticky tweet and the same for Mac. GUI not working yet on D6.


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


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

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.


Done, file I/O working in QEMU on 750D/760D as well (same as for 80D) 8)

BTW, you may try to compile a 32-bit GDB for Mac; I've asked around and seems it should work.


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


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?
Canon EOS 750D + Canon 28-80mm USM + Fujifilm Finepix s9200

Walter Schulz

Top of page -> Downloads -> Download nightly builds -> ROM dumpers
or reply #7


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.
Canon EOS 750D + Canon 28-80mm USM + Fujifilm Finepix s9200


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 (look up his earlier posts)

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


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 (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).
Canon EOS 750D + Canon 28-80mm USM + Fujifilm Finepix s9200


If you can get a log on the virtual card by running dumpf 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).


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


I have a camera and some dev experience, how I can help ?


@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...
Canon EOS 750D + Canon 28-80mm USM + Fujifilm Finepix s9200