Took a closer look at the firmware signature - it's affected by our QEMU patches. So, to find it, either debug it without enabling other ROM patches (those with SET), or find it out outside GDB (e.g. print it on the screen), or just keep it commented out.
Next:
[BOOT] changing user_mem_start from 0x17ec74 (1567860) to 0x117940 (1145152)
This one looks fishy to me. Why? Because we "push" this address to the right in order to make room from our application. Let's take a look at the memory map (printed by 0xFF0C6E70).
Start the firmware under GDB, then, once it's running, hit CTRL-C and call this function. The simplest (and most hackish) way to do this, without loading guest code (autoexec.bin), is:
./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S -d debugmsg & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
(wait until it boots)
CTRL-C
set $pc = 0xFF0C6E70
continue
This will break the execution flow (after returning from that function, there will be dragons), but at least we'll get what we are looking for. The function probably has no arguments (R0 and R1 are first written, and then read), therefore simply jumping to it should be fine.
Result:
...
sys_mem_start 0x0018ac00
sys_mem_max 1179648
user_mem_start 0x00100d80
user_mem_max 515828
...
Here, user_mem is malloc, sys_mem is
AllocateMemory the place where DryOS allocats stack space for its tasks.
That means, user_mem_start is not 0x17EC74, but 0x100d80. You'll find that in cstart as well. Set RESTARTSTART to that, or a little bit higher - e.g. 0x100E00). Now, the boot process will "push" user_mem_start to start right where our code ends.
BTW - most models have "RESTARTSTART is selected to be just above the end of the bss". Coincidentally or not, Canon's BSS (the end of what they zero out before cstart) is also 0x100D80; however, it is my understanding that we are not modifying Canon's BSS, but user_mem_start (therefore shrinking their malloc memory pool).
Hence, the 7D2 has an updated comment:
# DryOS memory map
# RESTARTSTART is selected to be at user_mem_start
# (aka heap start / DRY_HEAP_START / malloc memory pool)
#
RESTARTSTART = 0x001CC400
There, Canon's BSS ends at 0x745E8, so the previous comments about BSS were incorrect. Time to fix them.
Having fixed RESTARTSTART and the (misnamed) HIJACK_INSTR_BSS_END, let's check the memory map again, this time loading some minimal ML:
sys_mem_start 0x0018ac00
sys_mem_max 1179648
user_mem_start 0x00104580
user_mem_max 501492
Notice the user_mem (malloc) pool is now smaller and shifted to the right. The size needed by our binary (MemSiz when compiling) is 0x03780 (ymmv), so it appears to match.
How much free space do we have? The 7D2 source contains 3 important hints: malloc_info, sysmem_info and smemShowFix (all easily found in the firmware). Let's call the first one (from GDB, to avoid recompiling):
Without ML:
Malloc Information (onetime type)
Start Address = 0x00100d88
End Address = 0x0017ea60
Total Size = 0x0007dcd8 ( 515288)
Allocated Size = 0x00015ab0 ( 88752)
Allocated Peak = 0x00015ab0 ( 88752)
Allocated Count = 0x0000005a ( 90)
Free Size = 0x00068228 ( 426536)
Free Block Max Size = 0x000681f0 ( 426480)
Free Block Count = 0x00000002 ( 2)
With minimal ML:
Malloc Information (onetime type)
Start Address = 0x00104588
End Address = 0x0017ea60
Total Size = 0x0007a4d8 ( 500952)
Allocated Size = 0x00015ab0 ( 88752)
Allocated Peak = 0x00015ab0 ( 88752)
Allocated Count = 0x0000005a ( 90)
Free Size = 0x00064a28 ( 412200)
Free Block Max Size = 0x000649f0 ( 412144)
Free Block Count = 0x00000002 ( 2)
OK, so we don't have enough space to load the entire ML (maybe only if you compile it without any features). We'll have move somewhere else.
This was the "classic" boot process, originally used by 5D2. Not all models have enough free space here to accommodate the full autoexec.bin.
One option is to try the AllocateMemory (like 550D or 1100D), and another is to hunt for possibly unused memory areas (smemShowFix - FF222B68) - see
http://www.magiclantern.fm/forum/index.php?topic=5071.0.
Note: I wouldn't call random stuff on a real camera without triple-checking the stub, the number of arguments, any prerequisites that might be and so on. Here we are on a virtual machine, so there's nothing to break - feel free to experiment away.
