Adding support for a new camera

The original article was copied from here.

Introduction

This manual assumes that

• firmware dump
• basic ARM assembler knowledge
• decent ARM reversengineering tool
• C knowledge
• chdk building environment

are already available/known/setup correctly. Making above things to work/etc. is not part of this document.

It is recommended that you use the sources from the trunk, as they contain fewer bells and whistles, and thus there are fewer things that can go wrong.

Source tree

/bin	- results ready for usage
/core	- glue that makes it all work together
/doc	- some docs...
/include	- headers
camera.h	- Camera-dependent settings
/lib	- various libraries. BASIC handling, some math and standard C functions, font, other "separate" stuff goes here
/loader   + <platform>	- initial code ran by camera. Setups various things.
/platform   + <platform>   + <platformsub>	- camera-/firmware- dependent code
/script	- BASIC scripts
/tools	- tools to make life easier :)

Source is build in the following order: tools, lib, platform, core, loader. The result of 'core' is main.bin. It contains injected code and code to startup camera in special way.

'loader is a, well, loader for the 'core'. It handles camera's software reset, loading 'core' to specific address and finally running it.

Files that are not included into source tree are

• /tools/sig_ref_<X>.bin (see description below)
• /platform/<NAME>/sub/<VER>/PRIMARY.BIN - fw dump for camera NAME version VER

Take a look at Makefiles, some of them must be modified.

Tools

pakwif - utility to build FIR - fw update files
hexdmplt - utility to dump files

gensig.sh - "signature" generator to simplify search of known functions in fw dumps. File signatures.h is generated from data from the set of sig_ref_#.txt and sig_ref_#.bin. Txt contains function names and virtual offsets and bin is a corresponding fw dump.

Basics

So, the goal is to add things that are missing in /loader and /platform directories. The good starting point is copying of loader and platform stuff from another camera that may be very alike to the one your are trying to port to.

makefile.inc in platform/sub dir should be edited, it contains these parameters:

PLATFORMID=12345	- decimal ModelID so valid FIRs were built, refer to P-ID (Table).
MEMBASEADDR=0x1900	- address where wif or diskboot code will be loaded by camera. As code is mostly position dependent it's important to know. Used by loader.
RESTARTSTART=0x50000	- address of a free region. memmove() to setup core in memory and reset code lives here. Obviously it must not intersect with whats already loaded in RAM. Usually: MEMBASEADDR - (MEMBASEADDR+FIRSIZE) and MEMISOSTART - (MEMISOSTART+MEMISOSIZE)
ROMBASEADDR=0xffc00000	- base address of fw. Used by function signature finder.
MEMISOSTART=0xABCDE	- these will be adjusted later. Depends on particular firmware.
MEMISOSIZE=0x20000	- size of region where core will have its .text, .data and .bss segments.

Corresponding fw dump must be placed into PRIMARY.BIN in platform/sub/<VER> directory.

Edit Makefile and disable generation of Thumb code.

Memory layout

Example memory layout while CHDK is running:

0x00000000-0x00001000	- interrupt related stuff.
0x00001000-0x00001900	- kernel stack.
0x00001900-0x00012340	- .data
0x00012340-0x000ABCD0	- .bss
0x000ABCD0-0x000CBCD0	- 'core' lives here. <- thing we change
0x000CBCD0-0x00200000	- VxWorks Primary memory pool.
0x00200000-0x02000000	- "Extended" RAM. Various buffers, etc.
0x10000000-0x1fffffff	- same as 0x0-0x0fffffff but with no caching
...mmio regions...
0xffc00000-0xffffffff	- Firmware flash

Platform/Sub

stubs_min.S	- usually data pointers to make keyboard driver work. 'physw_status is where kbd state is kept. Address is inside PhySw task depending on kbd architecture.
stubs_entry.S	- entry points found by finsig. I.e. generated.
stubs_entry_2.S	- functions addresses 'fixups'. Here go functions that were mistakenly identified by finsig or completely missed.
stubs_auto.S	- file generated from boot.c. Entry points for original fw functions referenced by boot.c assembler inlines.
lib.c	- various fw-dependent stuff. Pointers, sizes, etc.
boot.c	- FW startup and basic hook installation code.

File boot.c

Most functions are copied and have straight equivalent inside of FW at early initialization stages but ours are with minor modifications. :)

void boot() - setup .data and .bss

void h_usrInit() - Nothing interesting here. Just don't forget to fix the call to h_usrKernelInit().

void h_usrKernelInit() - fix R0 (h_usrRoot) and (IMPORTANT!) R2 (pMemPoolStart) parameters of kernelInit() call like that:

"LDR     R0, =h_usrRoot\n"
"MOV     R1, #0x4000\n"
"LDR     R2, =0xC0000\n"   <--- 0xA0000 + 0x20000
"STR     R12, [SP]\n"
"STR     R4, [SP,#4]\n"
"BL      sub_FFEC9DA8\n"   kernelInit()

here 0xA0000 is an original value and 0x20000 is MEMISOSIZE. Now return to makefile.inc and modify MEMISOSTART so it pointed to *original* pMemPoolStart, i.e. 0xA0000 in this example.

h_usrRoot() - two modifications: add calls to taskCreateHookAdd and taskDeleteHookAdd to install hooks on task creation (further CHDK startup/initialization depends on these) and drv_self_hide() to "hide" A/DISKBOOT.BIN file. Later is required to diskboot successfully - without it camera will stuck in permanent diskboot :)

File stubs_entry.S

Yes, this is a generated file but it must be reviewed and every questionable entry point must be checked and fixed if needed by corresponding line in stubs_entry_2.S.

Some functions are not required by CHDK to function properly but are used to get some valuable information by hand or are left there for historical reasons.