Am I now supposed to reverse-engineer the firmware?
Yes
More specifically, you need to
1) Make all the stuff in stubs_entry_2.S and stubs_min.S, makefile.inc files correct for your camera
2) Generate the assembly in boot.c, capt_seq.c etc from your camera, with the various hooks and modifications in the appropriate places
3) Update platform_camera.h to reflect your camera
4) Update the other platform files like kdb.c, shooting.c, lib.c and so on.
#1 involves actual reverse engineering. What ever isn't found automatically, you need to find by analysis. I highly recommend Ghidra with the versioning tool.
#2 is mostly done with code-gen. Update the code_gen.txt to produce boot.c etc with the modifications at the equivalent points in your firmware. Some documentation can be found at the start of tools/code_gen.c. Referring to the disassembly in Ghidra and other ports files can be helpful.
#3 and #4 come from various places: Reverse engineering, testing, reading specs...
Note these aren't really done sequentially in the order above. Instead, you want to get enough correct in each part to have a minimally working build, and then incrementally add stuff to get more features working.
You can dummy things out to make it compile (i.e. using NULL_SUB in stubs_entry_2, or FAKEDEF, or just being sure that some thing copied form another port isn't actually going to be called), but you should try to keep track of which things you've actually done, so at the and you can go through and know that you've made a conscious decision about each item. You'll need to do a fair bit of grepping and wandering through the code to figure out which parts are safe to do when.
So step one is to get a build that boots and blinks an LED. This means setting up the loader directory (which should be mostly copy/paste). You can make an infinite loop that blinks an LED there to make sure you file is running. You don't have to worry if the rest of the code is right, because execution will never get there.
Next step is to set up platform/boot.c, so you can boot through the CHDK process without starting any CHDK tasks. This means you implement boot(), and the following functions up to where diskboot.bin is started (you need to comment it out to prevent a boot loop), but don't implement the task hooks or try to start CHDK tasks. You can start a simple task that blinks LEDs in a loop.
Once that's working, you'll want to implement kbd_task and spytask, so you have input and display capability and
chdkptp for testing and upload. This mostly involves kbd.c, lib.c and platform_camera.h
Once those are working, you can do capt_seq.c to get the shooting functionality, which will give you a minimally useful port. After that you can stuff like filewrite and movierec.
FWIW, if you want some more real time advice I'm often in the IRC channel #chdk on freenode.
I've now copied the ixus310 files
Note the 310 is somewhat newer than your camera. You'll definitely want it as a reference for the touch screen stuff, but cams like the ixus105 and ixus130 will likely be a closer comparison for general reverse engineering. It's often helpful to refer to several cams in any case.
