Hey space928,
maybe I go first and tell my understanding and a1ex can correct me
.
So lets start with a working autoexec.bin for the 750D, the SFDUMPER
I understand that there is a part in DryOS which looks for an autoexec.bin if the boot flag is enabled.
This happens after the Bootloader finished and some hardware is set up and the main kernel is being copied to RAM (we see later) .
enter minimal.c
this seems to be our main()
void
__attribute__((noreturn,noinline,naked))
copy_and_restart( int offset )
{
here we clean some memory with 0 values:
zero_bss();
This part is well documented:
// Copy the firmware to somewhere safe in memory
const uint8_t * const firmware_start = (void*) ROMBASEADDR;
const uint32_t firmware_len = RELOCSIZE;
uint32_t * const new_image = (void*) RELOCADDR;
blob_memcpy( new_image, firmware_start, firmware_start + firmware_len );
/*
* in cstart() make these changes:
* calls bzero(), then loads bs_end and calls
* create_init_task
*/
// Reserve memory at the end of malloc pool for our application
// Note: unlike most (all?) DIGIC 4/5 cameras,
// the malloc buffer is specified as start + size (not start + end)
// so we adjust both values in order to keep things close to the traditional ML boot process
// (alternative: we could adjust only the size, and place ML at the end of malloc buffer)
uint32_t ml_reserved_mem = (uintptr_t) _bss_end - INSTR( HIJACK_INSTR_BSS_END );
INSTR( HIJACK_INSTR_BSS_END ) += ml_reserved_mem;
INSTR( HIJACK_INSTR_BSS_END + 4 ) -= ml_reserved_mem;
Now its becoming interesting we "bend" the vector for the init_task:
// Fix the calls to bzero32() and create_init_task()
FIXUP_BRANCH( HIJACK_FIXBR_BZERO32, my_bzero32 );
FIXUP_BRANCH( HIJACK_FIXBR_CREATE_ITASK, my_create_init_task );
// Set our init task to run instead of the firmware one
INSTR( HIJACK_INSTR_MY_ITASK ) = (uint32_t) my_init_task;
// Make sure that our self-modifying code clears the cache
sync_caches();
and last we call the function:
// We enter after the signature, avoiding the
// relocation jump that is at the head of the data
// this is Thumb code
MEM(0xD20C0084) = 0;
thunk __attribute__((long_call)) reloc_entry = (thunk)( RELOCADDR + 0xC + 1 );
reloc_entry();
so at the moment we don't return from this but normally this would be just a call for a task in DryOS and the normal boot routine resumes at the vector we've bend above.
So the tasks at the moment:
- find the stubs (addresses) of the functions needed for the blind dump to work, as we experienced with the dumper these can hide in RAM or ROM as the kernel gets copied at startup (see above)
- with the stubs in place the firmware can resume booting and have our code as a task.
- we can dump the memory and search for whatever is needed
Question from me if ant123 is still reading on the CHDK M3 porting thread you mentioned finsig back in 2015 I haven't read all the 47 Pages yet but did you have any luck with the new finsig_thumb2? The M3 seems to be on the same DryOS release (55) as the 750D. If I try to generate stubs as described in the wiki it it will produce some warnings and then nothing more after 4 hours of generating sporadic high CPU Load I killed it.
