CHDK-PT : A tool for porting CHDK to different firmware versions of the same camera

CHDK-PT tool offers a basic ARM dissassembler that works well with Canon camera ROM dumps, interprets CHDK stub_entry.S files, producing output as gcc compatible C files, and will convert stubs files and source code between firmware versions with a only little effort from the developer.

Porting CHDK to a new camera for the first time is really hard and very time consuming. Porting to a different firwmare version of the same camera is much easier. With the introduction on CHDK-PT tool, it has become even easier. At least that's the hope.

link to : CHDK Forum Thread for CHDK-PT

Prerequisites

• the CHDK-PT porting tool CHDK-PT

  

  CHDK-PT main window

  CHDK-PT Mirror
• a working CHDK build environment like CHDK-Shell
• a good text editor, preferrably with a built-in diff function like Notepad++
• a basic knowledge of software, although you will not really be writing code, just changing existing code to reflect difference between firmware versions of the same camera.
• a little knowledge of CHDK software development - check out the links in the "Common Articles" section of For_Developers but don't spend too much time getting lost over there.
• the firmware dump (primary.bin) file from a working port of a different firmware version of your camera
• the camera specific files (boot.c, capt_seq.c, lib.c, movie_rec.c etc) from that same working port
• for the new firmware version you are trying to support, a firmware dump (primary.bin). If you don't have this, a good place to start is Firmware Dumping

Steps

Intial Setup

• Locate your camera model in the CHDK trunk directory

• Create a new trunk/platform/<camera>/sub/<firmware> directory for your camera where <firmware> is your firmware version

• Copy all files from the numerically closest version subdirectory to the new subdirectory (e.g. trunk/platform/ixus120_sd940/sub/103c -> trunk/platform/ixus120_sd940/sub/103d )

• Find and move the firmware dump file (primary.bin) for your camera into your new subdirectory, naming it primary.bin.

Testing the initial configuration

• Now you are ready to start updating files. I suggest keeping notes of which files you change and what ever else you do - things get confused fast so its nice to have a record.

• To start, you need to add your camera model to the build. In newer source trees, add your camera name to the camera_list.csv file located in the current trunk directory. For older source trees, edit the Makefile and makefile.inc in the trunk/trunknnnn directories to include your firmware version - search the files for the existing references to your camera and duplicate the lines you find, changing as necessary to point to your new firmware version.

• Build the new firmware version with the PRIMARY.BIN file in place and OPT_GEN_STUBS is selected (CHDK-shell). This will obviously not be a working port, you just want to generate stubs_entry.S and make sure that you have set things up correctly.

• Use Notepad++ to diff the newly generated stubs_entry.S and the one for the already supported firmware. While many of the addresses will have changed, you are looking to see if the same stubs were found with the same percentage of success. You will need to later update stubs_entry_2.S to cover any differences.

Converting stubs_entry_2.S

• The CHDK build process tries to find addresses in the camera ROM for CHDK code to connect with. This information is stored automatically in a file called stubs_entry.s by the build process. When the build process cannot fnd a good link, you must manually add it to the file stubs_entry_2.S. When porting different firmware versions across the same camera, CHKD-PT can convert the stubs_entry_2.S file from your existing reference port to a new version of stubs_entry_2.S for your new port.
• Use the CHDK-PT Convert : Stubs button to create a new stubs_entry_2.S file for your new port. The tool will let you select the ROM image file and stubs_entry_2.S file for the reference camera port and the ROM image file for the new camera. Once you have selected those, it will generate a new stubs_entry_2.S type file for your new camera based on finding the approriate code in your new ROM image using information about what that code looked like in the reference ROM image. Use the Save button to create the new stubs_entry_2.S file if you are happy with what you see in CHDK-PT's text box.

• Next use CHDK-PT Analyze : Stubs function to dissassemble and create C file versions of the stubs_entry_2.S files for the existing port and for your new port (the file you just saved in the step above). Use the diff function in Notepad++ to compare the two resulting files. When the routines match, your are done! If they don't match then you need to go searching for a better match with Dissassemble mode in CHDK-PT.

Converting the C language CHDK task files

• In the previous step of these instructions, where you copied files into trunk/platform/<camera>/sub/<firmware>, you will have created (amongst other things) three C language files - boot.c, movie_rec.c and capt_set.c. These files contain ARM assembler code written in a format that the gcc compiler can compile. Each of these files contains small programs that are actually copies of some of the tasks in the original camera. What happens with CHDK is that these copied tasks are slightly modified to support the additional functionality that CHDK provides and are then compiled as part of the CHDK executable code. When you copied the files, you got code suitable for use with your reference camera, so you need to create new files suitable for your new target camera.
• The easiest way to create these three files is to use CHDK-PT. But first you need to figure out where the original code was taken from in the original camera port. You can then let CHDK-PT produce code for the new versions of boot.c, movie_rec.c and capt_set.c that matches your new camera. You need to create an address.txt file by looking at the original tasks, where labels and maybe comments provide clues as to where the code was taken from. You can also use the dissassembler function in CHDK-PT to explore in the ROM image, looking for code matches based on the clues provided by the labels in the original files.
• Take a look at the example file (addresses_ctasks_103c.txt) provide with CHDK-PT. Or, as an example of what you need to do, you can try using the examples included with CHDK-PT to create new C task code for a new camera (primary_101a.bin) based on the address_ctasks_103c.txt and primary_103c.bin files for an original reference camera.
• The C task files ( boot.c, capt_seq.c & movie_rec.c) should be pretty much the same between firmware versions of the same camera. However, these routines reference addresses specific to each firmware version and so are not the same. Using CHDK-PT, you can create new versions of these C routine, and then use Notepad++ to make them equivalent to the routines from your reference port.
• Use the CHDK-PT Convert : Addresses function to create new C code task files for your new port (boot.c, capt_seq.c, movie_rec.c). The tool will let you select the ROM image file and and address file for the reference port and the ROM image file for the new camera. You need to create that address file so that it gives the starting address and length of each routine in the original ROM image file. Once you have selected those, it will generate a new C code file for your new camera based on finding the appropriate code in your new ROM image using information about what that code looked like in the reference ROM image. You then need to use your by now old friend diff in Notepad++ to figure out the CHDK customizations that were applied to the original C code and port those changes to your new C code.

• Follow the same procedure for each of the files boot.c, capt_seq.c and movie_rec.c
• here are some forum threads on this topic :

CHDK-PT : Using the addresses.txt file - thread 1

CHDK-PT : Using the addresses.txt file - thread 2

CHDK-PT : Using the addresses.txt file - thread 3

Converting lib.c and stubs_min.S

• lib.c: If no variables have moved, you probably don't have to do anything here. Hardware addresses are unlikely to have changed.

• stubs_min.S: pretty much the same as lib.c, except levent_table & FlashParamsTable which will probably have moved by the same amount as the Canon data.

Note : if there are already two or more firmware versions supported for your camera, use diff to look for changes between versions in these files.

Warnings

• makefile.inc: MEMISOSTART will need updating if the size of canon DATA + BSS has changed. Hopefully that will not be the case across different version of firmware on the same camera

• some of the assumptions above (like variables not moving) are just educated guesses. Canon could have changed the order of variables or functions but had them come out the same size.

Cleaning up

• That's it, you are done. Build it (from scratch with clean !) and find someone to try it it out...

• OK, you weren't actually quite done yet. Assuming it works, update the toplevel makefile to include your new sub, and commit or submit a patch.