SD300 porting: I really need some help... - General Discussion and Assistance - CHDK Forum supplierdeeply

SD300 porting: I really need some help...

  • 21 Replies
  • 12925 Views
SD300 porting: I really need some help...
« on: 06 / December / 2007, 18:41:17 »
Advertisements
Hi all,

I've been trying to port the CHDK to the SD300.
I was able to successfully dump the firmware (see http://HackingHood.googlepages.com/ for the full story).

I then changed the code as much as possible (see SD300 page on CHDK @ Wikia...) finding corresponding functions on the mentioned dump.

It seems all works fine except for the keyboard. I manually started some functions by default and they do work fine.
The problem is that, of course, without the keyboard, it pretty much useless...

It seems the keyboard routines on that firmware are quite different than on SD500 or some of the A- models...


Can anybody help a bit? I've been quite busy lately and I may be lacking enough imagination to make it work  :o

It's a shame I cannot finish the port being so close...

Thanks in advance...

*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: SD300 porting: I really need some help...
« Reply #1 on: 06 / December / 2007, 20:04:36 »
I think this is not very complicated. We change task "SwitchCheckTask" (located at 0xFF830738) to its full copy, with the one exception:

ROM:FF830764                 LDR     R1, =sub_FF8308E8
we change to
"LDR     R1, =sub_FF8308E8_my\n"

Function sub_FF8308E8_my() is full copy of original sub_FF8308E8 with the two exceptions:
ROM:FF83098C                 BL      sub_FF830E90
we replace to
"BL      sub_FF830E90_my\n"
and
ROM:FF830A3C                 LDR     R1, =sub_FF8308E8
we replace to
"LDR     R1, =sub_FF8308E8_my\n"

And sub_FF830E90 (also called platformsub_kbd_fetch_data()) is very similar to SD500 - reads from I/O ports 0xC0220204 (USB power and mode dial in SD500), 0xC0220208 (keyboard in SD500), 0xC022301C(SD card lock switch is SD500), 0xC0223024 (unknown) and stores results in some structure located at 0x117A8 (physw_status[]).
We can modify these variables after call of platformsub_kbd_fetch_data() in sub_FF8308E8_my() or modify sub_FF830E90 as was done in SD500.

Re: SD300 porting: I really need some help...
« Reply #2 on: 17 / December / 2007, 09:10:55 »
Hi el_yopo,

Maybe it would be best to check your changes into svn and maybe others can contribute better then :-).
I'd like to help you with porting but currently I'm just learning C... therefore I am noth the best help you can get maybe.

Regards Chris  :)

Re: SD300 porting: I really need some help...
« Reply #3 on: 30 / December / 2007, 13:00:10 »
I think this is not very complicated. We change task "SwitchCheckTask" (located at 0xFF830738) to its full copy, with the one exception:

ROM:FF830764                 LDR     R1, =sub_FF8308E8
we change to
"LDR     R1, =sub_FF8308E8_my\n"

Function sub_FF8308E8_my() is full copy of original sub_FF8308E8 with the two exceptions:
ROM:FF83098C                 BL      sub_FF830E90
we replace to
"BL      sub_FF830E90_my\n"
and
ROM:FF830A3C                 LDR     R1, =sub_FF8308E8
we replace to
"LDR     R1, =sub_FF8308E8_my\n"

And sub_FF830E90 (also called platformsub_kbd_fetch_data()) is very similar to SD500 - reads from I/O ports 0xC0220204 (USB power and mode dial in SD500), 0xC0220208 (keyboard in SD500), 0xC022301C(SD card lock switch is SD500), 0xC0223024 (unknown) and stores results in some structure located at 0x117A8 (physw_status[]).
We can modify these variables after call of platformsub_kbd_fetch_data() in sub_FF8308E8_my() or modify sub_FF830E90 as was done in SD500.


evawr, you were right. I only needed some time to digest it... After a couple of days, I got the keyboard working...
Well... nearly.
I was able to replace the code and detect the keys being pressed, but for some strange reason when I try to enter ALT mode something happens on "kbd_process()":
- It detects the pressing of "conf.alt_mode_button", enters "gui_kbd_enter()" function, but when it returns to kbd_process() it just hangs (or something I cannot see) until it timesout and shuts down...

I tried turning a LED on and off to trace the code and I can turn it on before the call to gui_kbd_enter(). If I turn it of INSIDE gui_kbd_enter() it does turn off. However, if I turn it off immediately after the call to gui_kbd_enter() it does fail (and timesout and shuts down)...
So it seems the return is not working... Maybe some stack corruption or something??

I'm puzzled by the "stack pointer manipulation" that happens on "mykbd_task"... What's it's purpose?
Also I'm not completely sure that physw_status is 0x117A8 on the SD300 or some number close to that...


Any ideas?

Thanks!

el_yopo


*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: SD300 porting: I really need some help...
« Reply #4 on: 30 / December / 2007, 20:03:59 »
Maybe some stack corruption or something??
I'm puzzled by the "stack pointer manipulation" that happens on "mykbd_task"... What's it's purpose?

Yes, this is stack overflow. Keyborad task in CHDK have own stack.    
Unfortunately, currently I cannot look in SD300 dump and to give advice...
You need:
1. Allocate some memory block (0x2000 bytes) for new stack
2. At entry point of new keyboard task assign SP register to end of this memory block (mov SP, new_value)
« Last Edit: 30 / December / 2007, 20:18:15 by ewavr »

Re: SD300 porting: I really need some help...
« Reply #5 on: 02 / January / 2008, 18:10:49 »
I think there might be an issue with the keyboard routine.
On the SD300 firmware (contrary to what the sd500 SwitchCheckTask routine) there are TWO arguments in
the funtion call.
From IDA dissassembly:

ROM:FF830738 SwitchCheckTask                         
ROM:FF830738
ROM:FF830738 var_20          = -0x20
ROM:FF830738 var_1C          = -0x1C
ROM:FF830738
ROM:FF830738                 STMFD   SP!, {R4-R8,LR}
ROM:FF83073C                 LDR     R3, =0x20F8
ROM:FF830740                 SUB     SP, SP, #8
ROM:FF830744                 LDR     R2, [R3]
ROM:FF830748                 CMP     R2, #2
ROM:FF83074C                 BNE     loc_FF830870
ROM:FF830750                 LDR     R6, =0x11AC8
ROM:FF830754                 MOV     R8, SP
ROM:FF830758                 ADD     R7, SP, #0x20+var_1C
ROM:FF83075C
ROM:FF83075C loc_FF83075C                           
ROM:FF83075C                 MOV     R0, R8
ROM:FF830760                 BL      GetSystemTime
ROM:FF830764                 LDR     R1, =wrap_kbd_p1_f
ROM:FF830768                 LDR     R0, [SP,#0x20+var_20]
ROM:FF83076C                 MOV     R3, R7


So, given that this routine is replaced by our own "mykbd_task_proceed", and called inside "mykbd_task" AFTER
stack manipulation, I think that either the pointer goes to hell or we are completely loosing those two arguments...

I still have not a clear idea of the ARM call procedure, but what I found puzzling is that (supposedly) the STACK pointer DECREASES with each value pushed into the stack, that is, if I push 0x41 and then I push 0x42 on the stack I get something like:

BFFF001C 0x41
BFFF0008 0x42   <----- And now SP points here...

Am I right?

If so, I think I don't get IDA convention. I imagine that when I enter the routine, after the first STDMF I have a stack like this:

XXXXXX20 var_20
XXXXXX1C var_1C
XXXXXX18 LR
XXXXXX14 R8
XXXXXX10 R7
XXXXXX0C R6
XXXXXX08 R5
XXXXXX04 R4   <---- And SP points here...

So after I do "SUB SP, #0x08", If I want to point to var_1c shouldn't I do [SP+#0x20+0x04] so I get SP=XXXXXX1C???
Why does IDA say [SP+#0x20-1C]?


Re: SD300 porting: I really need some help...
« Reply #6 on: 05 / January / 2008, 07:30:29 »
Well, as usual, just some time fooling around with the code fixes most of the stuff...  :D

Regardless of the stack workings, I found that my problem was actually after the "disable_shutdown" call inside gui_kbd_enter...

If I comment out this call, then everything works as expected... I get to the ALT menu and can change all the stuff in there.

My problem now (besides debugging the disable_shutdown routine) is that I do not know the physw_status address. I tried to compare the codes of SD500 and SD300 but it seems I cannot do better that trying some addresses (with no luck, so far)...

Any hints that I can use when looking at the firmware dump to try and get it? What is written on it and on which routines/tasks?  :blink:


Anyway, next step is re-coding Capt_seq task for SD300... So far I did not try it (so all I did was not replacing that task at all in the code and leave the original). So, I get all the functionalit of CHDK except for RAW shooting...

el_yopo

Re: SD300 porting: I really need some help...
« Reply #7 on: 12 / January / 2008, 15:38:18 »
hi el_yopo,

it's nice to hear you making progress in porting chdk to the sd300 (ixus 40) - i'm planning to dump the firmware of my sd200 (ixus 30) maybe this weekend (just bought the plug and the phototransistor for it today :o) and hope that your port helps me to get it working on the ixus 30 as well ... maybe it works out of the box, because i think, that the two cameras are completely identical despite of the sensor mpix and the name and maybe the firmware is similar enough as well (mine is also a 1.0k and it seems to have been built at around the same time as the ixus 40 1.0k firmware i had access to for comaprison - so, maybe they are the same with just the name and the image size changed but the same code and data structures) ... i'm looking forward to you first captured raw image file :o)

keep up the good work - best wishes

  image13


Re: SD300 porting: I really need some help...
« Reply #8 on: 12 / January / 2008, 15:40:45 »
just a little correction - the smileys above were supposed to be  :)

  image13

Re: SD300 porting: I really need some help...
« Reply #9 on: 16 / January / 2008, 10:27:12 »
Thanks for posting your code so far.  Any chance you could also post the other "stubs" files you are using?

 

Related Topics