new branch - CHDK : Elf Edition - Developers wanted

[mx3]

project is not complited.
no binaries here.
developers wanted.

project goals:
 - implement execution of independent binary modules inside of CHDK environment

benefits:
 - low size of main CHDK binary file
 - CHDK easy extensibility
 - easy porting (no need to know CHDK architecture) - binary form of modules: ARM-ELF
 - huge amount of RAM available to modules
 - platform independency


details:
1) ELF module is built with dynamic linking to chdk.so shared library (also there will be no such file inside camera)
2) CHDK loads module into memory, updates import section, calls entry point inside module.

___________________________________________________



this folder contains example projects of modules.
they are :
- echo - writes string into file
- copy, del, rename, mkdir - file related applets

planning to make(port) following applets:
- encrypt - openssl open key encryption tool. you can encrypt your files in a such way nobody could decrypt them without encryption key which is suppossed to be out of your camera.
- ffmpeg - video conversion tool
- getexiff - tool to extract exiff information from jpeg file into ubasic variable
- bzip2 - compression tool

to keep size of main CHDK bin file low it is desired to migrate all non-photo related code into elf modules:
 - games
 - raw merge
 - calendar
 - file viewer
 - memory dumper and other debug code
_________________________________________________

Q: HOW to build?
A:
1) to make elfs you need to built "../bin/chdk.so"

 cd ../
 gmake PLATFORM=a630 PLATFORMSUB=100c NO_INC_BUILD=1 fir
 gmake PLATFORM=a630 PLATFORMSUB=100c NO_INC_BUILD=1 api

selected platform does not matter because there will be no chdk.so inside camera.
this file only required at compilation time.

2) inside of any elf folder execute: gmake

_________________________________________________

Q: How to make new module?
A:
 1) copy any of example project into new folder
 2) change file files.inc
 3) change source files
 4) run gmake
_________________________________________________

Q: What functions can I use in modules?
A: see ../core/elf_exported_functions.h for list of functions exported by CHDK

_________________________________________________
Q: I don't see function I need in elf_exported_functions.h
A: you can add it into this file and rebuild chdk.so
   function must(?) be declared as extern so compiler could find it in export section of chdk.so
   WARNING: doing this you make new version of CHDK so your module will not be compatible with old versions

________________________________________________

I used gcc_env_for_hdk-3.4.6.rar compiler to build project.


chdk.elf.edition.40314_20080324.rar - 2.12MB

[mx3]

I worked on this project some time but last two weeks did not have time to continue

actually only one function required some tweaking (porting)
unsigned long load_elf_image (void * addr)

I 'm not sure I will be able to work on this project in next 2-3 weeks

so anybody willing can review  and continue this

[cail]

mx3! thats great that you've started this!

I dreamed on this, but had no time to even start working.

I'll definitely try to help you with this, thanks for sharing!

[Allbest]

mx3
Bravo!

[PhyrePhoX]

wow, great stuff. will help as soon as my other projects are coming to an end

[mx3]

just a thought:
Q: what is easier way to port existing application into CHDK?
A:
1) hack it into pieces and change every line which is incompatible with CHDK...
2) make stdlib .so shared library which is compatible with CHDK and can be linked with existing aplication without changing any line in it....

hm....

[PhyrePhoX]

well, the first way can be used to finally clean & comment code (the code that gets "transformed").

other than that, i dont know how to answer that question. i will wait patiently for the first port of an application (like sokoban or filereader, "big" applications with own "screen") before i can start to port apps or create new apps.

keep up the good work!

[cail]

just a thought:
Q: what is easier way to port existing application into CHDK?
A:
1) hack it into pieces and change every line which is incompatible with CHDK...
2) make stdlib .so shared library which is compatible with CHDK and can be linked with existing aplication without changing any line in it....

mx3, all the stdio and much more of other library code is already in there - you just have to scrub through the firmware and collect all the required function addresses.
CHDK will only "link" the dynamic application with the existing firmware code.

This way you don't have to make any additional libraries - just make a single chdk.so with all the imports and link the elf binaries dynamically against it. This was my original thought on this.

This is just an abstract guess, don't mind

There is another potential problem. With all the imported functions (the list may become quite huge) you'll have to store their symbolic names and addresses table inside of the CHDK core. And this takes space.
Probably there'll be required a kind of 'external link base', which'll be readed by chdk linker from SD card.

BTW, I've looked into your code a little. A couple of questions:
1) Why do you use internal memory allocator (elf_suba.c). Why just not to use Canon's one?
2) Why all the binaries has an entry.S with jump to "main"? Why just not to jump there directly?

[mx3]

1) Why do you use internal memory allocator (elf_suba.c). Why just not to use Canon's one?

canon's internal memory size we can allocate is 200-500 kbytes
with elf_malloc we can alloc up to 6-10 mbytes ...

2) Why all the binaries has an entry.S with jump to "main"? Why just not to jump there directly?

I'm not a guru with assembler or with binaries which are intended to be run on new platform.
I want the simplest way to make applets.
If you say it can be accomplished without assembler it would be nice.
maybe it will require tweaking of elf.ld or linker command line.
fill free to change any thing in this experimental code.

[obsidian]

Will be the Elf files same for different models? I know something about elf programming ( under  Siemens mobile phones). Will we create a function library?

[mx3]

Will be the Elf files same for different models?

yes.

Will we create a function library?

it will depend on loader implementation.
I intended to support loading of .so files ( .dll )
correct porting of any loader from freeBSD, netBSD, linux will give this support.
actually it is not done yet so instead elfs anybody can implement PE loader as well (from wine or reactos)... :-)

main purpose of this project to simplify modules development and porting

[obsidian]

How will we compile the elves? Along with the chdk or individually? Which software will we use?What about "IAR embedded workbench for ARM"?

[mx3]

How will we compile the elves? Along with the chdk or individually? Which software will we use?What about "IAR embedded workbench for ARM"?

I used gcc_env_for_hdk-3.4.6.rar compiler to build project.

this project is no complited.
there are no working loader yet.

I planned to support dinamic linking.
I think any compiler which produces elfs could be used.

until loader implemented it is early to speak about making "extentions"
 

[obsidian]

will the cameras support "Daemons"? (elves started on camera startup, something like resident programs. If I place some elves to a specified directory on card, they will be launched.)

[mx3]

will the cameras support "Daemons"? (elves started on camera startup, something like resident programs. If I place some elves to a specified directory on card, they will be launched.)

it is planned.
I was going to add parameter into loader ( enum { RESIDENT, EXCLUSIVE})
when running in "exclusive" mode module uses memory  which is not used at the moment
when running in "resident"  mode module uses small ammount of memory but can run from power on to power off

so it is like applications and drivers

updated:
only difference between these two modes are:
1) loader will give binary different memory management function's entry points
2)
in case of Exclusive modules loader will wait until control returned into loader after module execution
in case of resident modules there are can be two variants:
- launch binary in newly created process(thread)
- launch and wait return (module will himself create task(thread))