wiki:HDK/Adding support for new camera
Last modified 7 years ago Last modified on 05/08/07 21:12:45


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 to use sources from the trunk as it
contains much less bells and whistles thus less
things can go wrong.

/bin              - results ready for usage

/core             - glue that makes it all work together

/doc              - some docs...

/include          - headers

/lib              - various libraries. BASIC handling,
                    some math and standart C functions,
                    font, other "separate" stuff goes

/loader           - initial code ran by camera. Setups
   + <platform>     various things.

/platform         - camera-/firmware-dependent code
   + <platform>
   + <platformsub>

/script           - BASIC scripts

/tools            - tools to make life easier :)

Source is build in the folowwing 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.


pakwif - utility to build FIR - fw update files
hexdmplt - utility to dump files - "signature" generator to simplify search of known functions
in fw dumps. File signatures.h is generated from data from the set of
sig_ref_<X>.txt and sig_ref_<X>.bin. Txt contains function
names and virtual offsets and bin is a corresponding fw dump.


So, the goal is to add things that are missing in /loader and /platform
directories. The good starting point is coping of loader and platform
stuff from another camera that may be very alike to the being hacked one. in platform/sub dir should be edited, it contains
these parameters:

  PLATFORMID=12345        - decimal ModelID so valid FIRs were built

  MEMBASEADDR=0x1900      - address where wif or diskboot code will
                            be loaded by camera. As code is mostly
                            position dependant 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. Obviuosly it must not
                            intersect with whats already loaded in RAM.
                            MEMBASEADDR - (MEMBASEADDR+FIRSIZE) and
                            MEMISOSTART - (MEMISOSTART+MEMISOSIZE)

  ROMBASEADDR=0xffc00000  - base address of fw. Used by function signature

  MEMISOSTART=0xABCDE     - these will be adjusted later. Depends on
                            particuliar firmware.
  MEMISOSIZE=0x20000      - size of region where core will have its
                            .text, .data and .bss segments.

Corresponding fw dump should be placed into PRIMARY.BIN in platform/sub

Edit Makefile and disable generation of Thumb code.


Example memory layout while hack is runnig:

0x00000000-0x00001000 - interrupt reated 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-0x20000000 - sameas 0x0-0x10000000 but with no cacheing

...mmio regions...

0xffc00000-0xffffffff - Firmare flash


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's assembler inlines.

lib.c - various fw-dependent stuff. Pointers, sizes, etc.

boot.c - FW startup and basic hook installation code.


Most functions are copied and have straigh 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 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
hack 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 :)


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 to hack function properly but are
used to get some valuable information by hand or are left there
for historical reasons.


This manual will be extended some day...