new branch - CHDK : Elf Edition - Developers wanted

[sokoow]

I'm in, you can use me if you want to. I am dealing with optimizations/code profiling, also have experience with ANSI-C (hate ++). Maybe I'll be useful.

[mx3]

I'm in, you can use me if you want to. I am dealing with optimizations/code profiling, also have experience with ANSI-C (hate ++). Maybe I'll be useful.

great.

you can try to port either PE loader or ELF loader.
at the first stage it can be easily tested on PC.

[PhyrePhoX]

*bump* just wanted to ask if there are any news on this project?
also maybe the skilled asm dudes like reyalp havent seen this thread yet, maybe they get interested...

[mx3]

just wanted to ask if there are any news on this project?

no changes

also maybe the skilled asm dudes like reyalp havent seen this thread yet, maybe they get interested...

asm dude is not required here.

it is required to grab some existing elf loader (sections parser) and integrate it into build
I thought someone could do it by now.

[PhyrePhoX]

ah ok, so no ASM skills needed. but certainly some nice C skills i guess - and these i lack, otherwise i would have joined your project by now.

so devs, please join mx3 and help him, for it will boost CHDK significantly.

[mx3]

I tried yerstaday to integrate code from Contiki OS.
it seems one variable is not initialised correctly.

   struct elfloader_output *output = ?? ; - some callback procedures...
   sts=elfloader_load(fp, &output);

attached is new version.

it still does not work.
I shared it so anyone willing to play with it had last version.

[mx3]

and quick fix

it seems contiki code works ok .

todo:
 - change elf examples compilation procedures to satisfy contiki elf loader?
 - find where contiki code stores entry point...

update to todo list
 - analise if contiki processes import section of elf file - this code must be changed or added

[reyalp]

Looking at the earlier versions yesterday, I wondered if we might be better off using something like flt (the binary format used by uclinux), which is designed for MMUless environments and generally a lot lighter weight. Or perhaps xflat Cadenux XFLAT Shared Libraries

Elf would be nice because it is natively supported by the toolchain, but it is pretty large, complex, and aimed at systems with real OSes and MMUs. It would probably make porting applications easier (compared to things like flt), but given the limitations of our platform I'm not sure that's much of an issue.

This isn't at all intended as a flame against the work you've done so far, just a possible alternative.

[mx3]

just found project :
elfs for siemens and sony erricson phones

cbn.narod.ru/elf.html
perk11.info/elf/

svn :// svn.boba.su

archivers
emulators
games

[Kibab]

Hi,
I'm one of Siemens ELF developers. I've had experience of porting our ELFLoader to some firmware versions of different phones, and also developed some elf modules (SieJC, TMOEditor, GPSLogger). Today I'm planning to buy Canon PowerShot SX120 IS, and I'm verry interested in those features CHDK gives to camera owners. Though there is no CHDK for SX120IS yet, I'm planning to try to port it. Then I'll be able to join CHDK/Elf edition :-)

Just a simple note: Siemens ELF loader has no dynamic linking support. Instead it uses "SWI" calls interceptor to invoke firmware routines. Since SWI instruction is guaranteed to store all context and restore it upon return, all that we should to was to call required routine from SWI interception code. This however will not work for Canon cams, because CHDK doesn't modify firmware. (Siemens ELF-Platform required patching existing firmware in Flash ROM).

I know almost nothing about other executable formats, but when talking about them ELF and a.out come in mind. a.out is much simplier than ELF, and may also be used in CHDK...
So, for the beginning I need to buy camera and find a good "reference port"...
Now I'll compile toolchain for CHDK.
I'm using FreeBSD 8.0 as main development platform.

[reyalp]

Welcome Kibab. For SX120 porting, have a look at  http://chdk.wikia.com/wiki/For_Developers  http://chdk.wikia.com/wiki/Adding_support_for_a_new_camera and http://chdk.wikia.com/wiki/SX120 There is already a sx120 porting thread http://chdk.setepontos.com/index.php/topic,4284.msg41200.html#msg41200 but not much progress yet.

There's frequently a few of us in #CHDK in irc.freenode.net if you want to chat.

It would be great to get some kind of loadable binary support. I think we could use SWI for system calls, the exception handlers are in RAM (instruction TCM actually), so we could install our own (and AFAIK canon doesn't use SWI at all) Not sure if there's any real benefit though.

[Kibab]

So, the brand new SX120 IS is in my hands now :-) Its FW version is the same as in CHDK part1 archive, so nothing new here.
Firmware dump is loaded in IDA, initial CHDK.idc run completed, FLIRT signatures applied. Now I will write PM to gajownik -- he seems to have done some initial porting.

A question is to how one should choose a reference port. It seems that I should look for well-supported camera based on DryOS and DIGIC-IV processor. It is either SX10 or SX200, is it right choice?

Also I'd like to know what gcc/binutils version is in use right now. Is gcc 4.3.3 + binutils 2.18 considered to be stable (for generating image, I'm aware of binutils 2.18 bugs described in the wiki). Do do you all use gcc 4.2.1?

EDIT: I've managed to build arm-elf toolchain and gcc 4.3.3, succesfully generated CHDK for Canon SX200IS. Had to build without "--with-cpu=arm9".
Now will poke gajownik...

[reyalp]

So, the brand new SX120 IS is in my hands now :-)

Please take sx120 stuff to http://chdk.setepontos.com/index.php/topic,4284.msg44586.html#msg44586 so as not to drag this thread off track.

[matc]

I believe making first the module format binary at a fixed address should be easier (only one module a the same time)

- allocate a zone where to put the code (in bss data for example)
- define a way to pass entry point
- put it in section .entry
- build the code
- link the code with something like (0x40000 is an example of fixed addr of the code)

Code: [Select]

/opt/arm-2011.03/bin/arm-none-eabi-gcc -Wl,-R -Wl,core/main.elf /tmp/plop.o -T tools/link-boot.ld -o /tmp/plop.elf -Wl,-Ttext,0x400000 -nostdlib
/opt/arm-2011.03/bin/arm-none-eabi-objcopy -O binary /tmp/plop.elf /tmp/plop.bin
/opt/arm-2011.03/bin/arm-none-eabi-size /tmp/plop.elf
- check si code size fit


When loadding :
- load the bin file in the array
- clean the remaining space (could be bss)
- read entry point


PS : even in this limited form it can be used for no resident application : game, ...

[tsvstar]

I do finalize experimental version of CHDK with binary modules. Do not take attention to the "experimental" status - build works completely stable on my CanonS95 (builded by GCC4.5.1)

URL to SVN repository: https://www.assembla.com/code/chdk-ex/subversion/nodes
Or use patch file in attachment to get it from CHDK-1459

Version is based on trunk CHDK-rev1459.

Loader take ~2.5Kb. Result binary is smaller by ~26Kb in compare to trunk version with default settings (and now no limit to complexity and num of modules )
Binary modules are based on modified BinaryFLAT format (thanks for information about this format to reylap).
It was difficult to make and stabilize infrastructure, but easy to use it. I get tetris from DE and snake from forum attachment today and convert them to modules in 10min. (surely zero impact on core size)

Separated to modules:
- games (sokoban.flt, mastmind.flt, 4wins.flt, reversi.flt)
- utilities (fselect.flt, txtread.flt, calend.flt)
- processing(curves.flt,edgeovr.flt, _rawopX.flt)
- debugs( memview.flt, benchm.flt)
- rare utility modes (palette.flt, mpopup.flt)

All of them are platform-independent. I see no problem to separate Lua and basic to modules. I just not spend time to this because this require additional changes to isolate them.

Additional modules:
modinsp.flt - module inspector
snake.flt  - Game from forum. Run directly from browser only (not integrated to menu)
tetris.flt - Last modification by Sektor of DE game. Run directly from file browser only (not integrated to menu)


What help needed:
- test stability of binary generated by autobuild GCC version. (GCC strangely generate incomplete files in case turned on relocs. because this many modules /for example benchmark/ was unstable. I add some hacks during elf conversion, but not sure that this works ok with all GCC)
- test how it build on linux
- test curves module (It require camera with 10pixel depth sensor)
- test stability/perfomance on different cameras. especially on old cameras

I'm open to questions, discussion, proposal, integration into main trunk.