SX60HS Porting

  • 901 Replies
  • 186806 Views
*

Offline reyalp

  • ******
  • 11591
Re: SX60HS Porting
« Reply #30 on: 21 / September / 2015, 16:06:58 »
Advertisements
Hello there is no new about the porting?  Iax whas starting but no new since his last message? 
This is a very difficult and time consuming task, and most developers are working in their spare time.
Quote
I really interesting about the sx 60 hs port… is it difficult to learn arm and c language?  If i try to learn it and understant it i can try to port chdk for it?  If you learn me exacly how to do it maybe i can understand?
It is possible to teach yourself programming, but IMO the level of knowledge required for Digic 6 port is equivalent of at least a couple years of a computer science degree. This is not something we can explain in a few forum posts.
Don't forget what the H stands for.

Re: SX60HS Porting
« Reply #31 on: 22 / September / 2015, 04:02:08 »
Ah yes i understand digix 6 is very hard… i waiting for a sx 130 is is it good for trying chdk?

Re: SX60HS Porting
« Reply #32 on: 22 / September / 2015, 21:44:38 »
Ah yes i understand digix 6 is very hard… i waiting for a sx 130 is is it good for trying chdk?
Yes - the SX130 is a good choice for trying CHDK.  However, be aware that it is one of four camera models where CHDK is suspected (but not confirmed) to have caused damage :

link > Camera failures suspected to be caused by CHDK : SX130

Many people have used CHDK successfully on an SX130 but there is always a small chance with any camera that using CHDK could cause a problem.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline iax

  • *
  • 45
Re: SX60HS Porting
« Reply #33 on: 09 / October / 2015, 16:42:44 »
Sorry guys, had to stay away a bit from CHDK! I'm still stuck at the boot phase, the camera hangs somewhere in the main chdk loop and still need to figure out exactly what causes that. For now I'm unable even to display the CHDK logo...

I hope to find some time to work on this soon.
Thanks


Re: SX60HS Porting
« Reply #34 on: 22 / October / 2015, 14:54:37 »
Ah yes take your time,  i tryed chdk with the sx 130 is but it worked for sometime and there where smoke since it don't boot at all i tryed all but i think a little fuse is broken….  So i lost 87 euros…  but i found a sx 240 hs for 120 euros and for now it work well so i can test chdk and its look cooool !

*

Offline iax

  • *
  • 45
Re: SX60HS Porting
« Reply #35 on: 28 / November / 2015, 16:31:08 »
Unfortunately I'm unable to move forward with this attempt, it requires too much time to me. If someone would like to continue my work, the full source code is available here:

https://drive.google.com/open?id=0B6cSQzWU4tHdNkdRellrNlRaZjA

Good luck!


Re: SX60HS Porting
« Reply #36 on: 16 / December / 2015, 06:18:08 »
I will sell this camera because don't have chdk. Is a good camera but have less features than other cameras much cheaper and even chdk don't work.  I bought it for CHDK

Re: SX60HS Porting
« Reply #37 on: 13 / March / 2016, 14:11:16 »
I 've made some effort to continue this work using firmware 100f on the SX60HS. It seems however, I've reached the same impasse that IAX did, where the camera seems to enter a infinite loop.

I used the g7x porting thread and s280 thread to help me with the port.  I found the capstone disassembler (with patch0 and modified finsig as described in the g7x thread to be most useful, finding all but a few stubs, which was very welcome, as I had spent hours and hours finding the equivalent stubs by comparison with sx280 and sx60 firmware 100b.
 See:
https://chdk.setepontos.com/index.php?topic=12692.0

I can get the camera to execute part of boot.c before it goes off into what must be an infinite loop. I've put some comments in boot.c indicating what i've tried, and what i suspect.

As someone who started out programming more than 40 years ago on PDP-8/11 etc and used to have some familiarity with assembler, I thought I would understand more than I apparently do. >:(

I think I've pretty much duplicated the work for g7x (boot.c), simply translating addresses for my firmware.
So I'm hoping someone will discover something obvious I've missed here.
(FYI I'm using a linux environment)

I've attached loader/sx60hs and platform/sx60hs....

thanks in advance for any help.

-af


*

Offline srsa_4c

  • ******
  • 3728
Re: SX60HS Porting
« Reply #38 on: 13 / March / 2016, 15:14:53 »
I think I've pretty much duplicated the work for g7x (boot.c), simply translating addresses for my firmware.
My suspicion is that you're trying to "fix" the code you found in the g7x boot.c. Don't do that. Most asm routines in camera specific files are simply copied parts of the camera's firmware, with more or less modifications. Those modifications are needed in order to run CHDK.

Some asm routines don't come from the firmware, one such routine is CreateTask_my()

So, first you need to identify the equivalent fw routines in your firmware, starting with the first asm routine in boot.c. Then, disassemble them and try modifying them as it was done in the reference port. It is not uncommon to find that those equivalent firmware routines change slightly or substantially.
The modifications may not be immediately obvious, compare the reference port's asm parts with the original disassembly to spot them. Added parts are usually denoted by different indentation or "// +" style comments.

Some problems I found (did not check if all these are actually executed in your code):
- ldr.w   pc, =(hook_CreateTask + 8 + 1) Don't remove the +1, it is needed to tell the CPU to remain in Thumb mode.
- in sub_fc05eec0_my(), red parts are missing - typos. These kind of errors don't happen if you start by modifying original disassembly.
    "strd    r2, r1, [sp, #0xc]\n"
    "str     r0, [sp, #0x14]\n"


*

Offline reyalp

  • ******
  • 11591
Re: SX60HS Porting
« Reply #39 on: 13 / March / 2016, 16:02:49 »
Don't do that. Most asm routines in camera specific files are simply copied parts of the camera's firmware, with more or less modifications. Those modifications are needed in order to run CHDK.
To elaborate, you can use the capdis tool to generate initial disassembly. The comments in my code like


// -f=chdk -s=0xfc0780e7 -c=18


are what I used to extract a given function. The -s and -c values are the start and length, which must be specific to your firmware . Also, the start address must have the thumb bit set correctly for the kind of code being extracted (almost always set, for d6 code.) Uses the -stubs=platform/sx60/sub/100f to have known functions named in the output.

capdis output is mostly ready to use, but in some cases it can generate incorrect disassembly. If there is data inside the function that the firmware code jumps over, it can get confused. I've also seen do weird things with negative hex constants (see "note capdis bad output" in g7x boot.c)

Aside from srsa's comments, I noticed that you have the capt_seq task hook enabled. I suggest not enabling any task hooks until you have the boot code running correctly. Then you can start a simple LED blinker task, and then start by adding kdb_task and spytask.

The same goes for the init_require_fw_features stuff. These are only required for some overrides, so you don't need to worry about that until you have something booting.

In kbd.c, you are calling kbd_p2_f_my, but you have the body of the function commented out. If you haven't implemented this yet, you should just call kbd_p2_f and comment out all the jogdial stuff (like g7x does)

You can also use capdis to disassemble the whole ROM. This is similar to what srsa's thumb2dis.pl does, but again shows you the the names of all the known functions when they are referenced. For g7x I used


./capdis.exe ../../dumps/g7x/sub/100d/PRIMARY.BIN 0xfc000000 -stubs=../platform/g7x/sub/100d -s=0xfc020001 -e=0xfc5bd39c -f=objdump -d-const -d-addr -d-bin > ../../dumps/g7x/sub/100d/ROMCODE.DIS


The end address (-e) here is the address of the ctypes structure, which (AFAIK) comes after all the actual code. This will take a while to run, and generate a large (~90MB for g7x) file.

You can also do the same for the code copied to RAM, like:

./capdis.exe ../../dumps/g7x/sub/100d/PRIMARY.BIN 0xfc000000 -stubs=../platform/g7x/sub/100d -s=0x10e1001 -e=0x110dc1c -f=objdump -d-const -d-addr -d-bin > ../../dumps/g7x/sub/100d/RAMCODE.DIS


All the addresses above are for g7x, you can get the ones for your camera from stubs_entry.S.

The format options above give output similar to thumd2dis.pl. I used this because I refer to both, and it gives the address and raw hex values in a compact format.

Beware there is a quirk in the current capdis code that function calls are output like bl sub_xxxxxxxx, while the functions are labeled loc_xxxxxxxx, so if you use something like * in vi it wouldn't jump from call to definition.
Don't forget what the H stands for.

 

Related Topics