Don't do that. Most asm routines in camera specific files are simply copied parts of the camera's firmware, with more or less modifications. Those modifications are needed in order to run CHDK.
To elaborate, you can use the capdis tool to generate initial disassembly. The comments in my code like
// -f=chdk -s=0xfc0780e7 -c=18
are what I used to extract a given function. The -s and -c values are the start and length, which must be specific to your firmware . Also, the start address must have the thumb bit set correctly for the kind of code being extracted (almost always set, for d6 code.) Uses the -stubs=platform/sx60/sub/100f to have known functions named in the output.
capdis output is mostly ready to use, but in some cases it can generate incorrect disassembly. If there is data inside the function that the firmware code jumps over, it can get confused. I've also seen do weird things with negative hex constants (see "note capdis bad output" in g7x boot.c)
Aside from srsa's comments, I noticed that you have the capt_seq task hook enabled. I suggest not enabling any task hooks until you have the boot code running correctly. Then you can start a simple LED blinker task, and then start by adding kdb_task and spytask.
The same goes for the init_require_fw_features stuff. These are only required for some overrides, so you don't need to worry about that until you have something booting.
In kbd.c, you are calling kbd_p2_f_my, but you have the body of the function commented out. If you haven't implemented this yet, you should just call kbd_p2_f and comment out all the jogdial stuff (like g7x does)
You can also use capdis to disassemble the whole ROM. This is similar to what srsa's thumb2dis.pl does, but again shows you the the names of all the known functions when they are referenced. For g7x I used
./capdis.exe ../../dumps/g7x/sub/100d/PRIMARY.BIN 0xfc000000 -stubs=../platform/g7x/sub/100d -s=0xfc020001 -e=0xfc5bd39c -f=objdump -d-const -d-addr -d-bin > ../../dumps/g7x/sub/100d/ROMCODE.DIS
The end address (-e) here is the address of the ctypes structure, which (AFAIK) comes after all the actual code. This will take a while to run, and generate a large (~90MB for g7x) file.
You can also do the same for the code copied to RAM, like:
./capdis.exe ../../dumps/g7x/sub/100d/PRIMARY.BIN 0xfc000000 -stubs=../platform/g7x/sub/100d -s=0x10e1001 -e=0x110dc1c -f=objdump -d-const -d-addr -d-bin > ../../dumps/g7x/sub/100d/RAMCODE.DIS
All the addresses above are for g7x, you can get the ones for your camera from stubs_entry.S.
The format options above give output similar to thumd2dis.pl. I used this because I refer to both, and it gives the address and raw hex values in a compact format.
Beware there is a quirk in the current capdis code that function calls are output like bl sub_xxxxxxxx, while the functions are labeled loc_xxxxxxxx, so if you use something like * in vi it wouldn't jump from call to definition.
