IXUS160/ELPH160 Porting attempt

  • 497 Replies
  • 85916 Views
*

Offline adong

  • **
  • 66
IXUS160/ELPH160 Porting attempt
« on: 06 / April / 2015, 09:21:10 »
Advertisements
Firmware dump: http://chdk.setepontos.com/index.php?topic=288.msg121543#msg121543

Hello,

I tried to start porting for a r55 camera but am facing some issues...

I figured out how people found the values for the power-on trick in code_gen, but in my case, there are no obvious LDR instructions...

I guess it should be something like
Code: [Select]
*(int*)(0x2A04 + 4) = (*(int*)0xXXXXXXXX)&1 ? 0x400000 : 0x200000;but I don't know how to find the 0xCXXXXXXX value (see pictures).


https://imgur.com/MOf19cp,K9GZh92

Thanks for the help!

Edit: new keysys and dancingbits:
0x216EA8C8 and { 6,5,3,7,0,2,4,1 }.
« Last Edit: 03 / August / 2015, 03:28:52 by adong »

*

Offline srsa_4c

  • ******
  • 3654
Re: IXUS160/ELPH160 Porting attempt
« Reply #1 on: 06 / April / 2015, 19:36:29 »
I figured out how people found the values for the power-on trick in code_gen, but in my case, there are no obvious LDR instructions...

I guess it should be something like
Code: [Select]
*(int*)(0x2A04 + 4) = (*(int*)0xXXXXXXXX)&1 ? 0x400000 : 0x200000;but I don't know how to find the 0xCXXXXXXX value (see pictures).


https://imgur.com/MOf19cp,K9GZh92
You need to find the equivalent of sub_ff86b2e8 in a "reference" firmware and track back its input parameters. Then, do the same on yours and try replicating the hack that was done in the reference port. You probably want to look at one of the most recent ported cameras (DryOS r52).
I've not seen the disassembly for this cam yet, it could be that GPIOs are read indirectly. Newer firmwares appear to often use tables of MMIO addresses via getter/setter functions.

*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #2 on: 08 / April / 2015, 14:32:32 »
Thanks! I'll try to do that  :)

*

Offline srsa_4c

  • ******
  • 3654
Re: IXUS160/ELPH160 Porting attempt
« Reply #3 on: 08 / April / 2015, 15:37:07 »
My guess, based on the sx280.
I think you can just remove the call to sub_FF82D94C, continue at loc_FF8285FC to avoid the infinite loop. You of course need to set the right bit(s?) on (0x2A04 + 4).
Code: [Select]
loc_ff86b8c4: ; 4 refs
ff86b8c4: b loc_ff8693a4

loc_ff8693a4: ; 8 refs
ff8693a4: ldr r1, =0xffbc0738         ; 'GPIO + bit' table
ff8693a8: ldr r2, [r1, r0, lsl #3]
ff8693ac: ldr r2, [r2]                ; read GPIO
ff8693b0: add r0, r1, r0, lsl #3
ff8693b4: ldr r0, [r0, #4]            ; read bitmask
ff8693b8: ands r0, r0, r2              ; return bit's state
ff8693bc: movne r0, #1
ff8693c0: bx lr

loc_ff838500: ; 3 refs
ff838500: mov r0, #0x80000000
ff838504: ldr r0, [r0, #0xffc]        ; read last word of data TCM
ff838508: ldr r1, =0x12345678
ff83850c: cmp r0, r1                  ; is it 0x12345678?, return the result
ff838510: movne r0, #0
ff838514: moveq r0, #1
ff838518: bx lr

ff82d94c: push {r2, r3, r4, r5, r6, r7, r8, lr}
ff82d950: mov r7, r0
ff82d954: mov r5, #0
ff82d958: bl loc_ff86b2e0    ; nullsub
ff82d95c: mov r0, #5          ; read GPIO bit (5), ON/OFF button?
ff82d960: bl loc_ff86b8c4
ff82d964: mov r4, #1
ff82d968: bic r6, r4, r0
ff82d96c: mov r0, #6          ; read GPIO bit (6)
ff82d970: bl loc_ff86b8c4
ff82d974: cmp r7, #0
ff82d978: bic r4, r4, r0
ff82d97c: beq loc_ff82d988
ff82d980: orrs r0, r6, r4      ; one of the above 2 buttons has to be pressed, otherwise shutdown
ff82d984: beq loc_ff82d9b0
loc_ff82d988:
ff82d988: bl loc_ff838500    ; data TCM check
ff82d98c: mov r2, r0
ff82d990: mov r3, r5          ; unused argument
ff82d994: mov r1, r4          ; GPIO bit (6) (PLAYBACK button?)
ff82d998: mov r0, r6          ; ON/OFF button?
ff82d99c: str r5, [sp]        ; unused argument
ff82d9a0: str r5, [sp, #4]    ; unused argument
ff82d9a4: bl loc_ff86b2e8    ; set startup bits
ff82d9a8: bl loc_ff86b2e4    ; nullsub
ff82d9ac: mov r0, #1
loc_ff82d9b0:
ff82d9b0: pop {r2, r3, r4, r5, r6, r7, r8, pc}

ff86b2e8: ldr r3, =0x2a04
ff86b2ec: cmp r2, #0
ff86b2f0: mov ip, #0
ff86b2f4: movne r2, #0x800000           ; depends on data TCM check
ff86b2f8: str ip, [r3, #4]
ff86b2fc: strne r2, [r3, #4]
ff86b300: cmp r0, #0
ff86b304: ldrne r0, [r3, #4]
ff86b308: orrne r0, r0, #0x200000       ; set this bit if ON/OFF pressed
ff86b30c: strne r0, [r3, #4]
ff86b310: cmp r1, #0
ff86b314: ldrne r0, [r3, #4]
ff86b318: orrne r0, r0, #0x400000       ; set this bit if PLAYBACK? pressed
ff86b31c: strne r0, [r3, #4]
ff86b320: bx lr

'GPIO + bit' table
ffbc0738: c022f484        (0)
ffbc073c: 00001000
ffbc0740: c022f484        (1)
ffbc0744: 00002000
ffbc0748: c022f484        (2)
ffbc074c: 00004000
ffbc0750: c022f484        (3)
ffbc0754: 00008000
ffbc0758: c022f484        (4)
ffbc075c: 00010000
ffbc0760: c022f484        (5)
ffbc0764: 00020000
ffbc0768: c022f484        (6)
ffbc076c: 00040000


*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #4 on: 08 / April / 2015, 15:55:40 »
Thanks for the detailed explanation! I made until the GPIO table, could not figure the which bits were read, my ARM isn't that good :)

My understanding is that you can only power-on the camera using playback/power, and it knows which button is pressed using that code, booting the camera in the correct mode.
We want to be able to override this by directly replacing the bit value, effectively tricking the camera into thinking it was booted using either power or playback even if it wasn't the case.
Thus, we have no need to know the GPIO table and instead just check the button value ? (in that case, 0xc0220020)
Only the 0x2A04 + 4 and 0x20000/0x40000 are key, the 0xc0220020 can be found in the stubs entries?

*

Offline srsa_4c

  • ******
  • 3654
Re: IXUS160/ELPH160 Porting attempt
« Reply #5 on: 08 / April / 2015, 16:01:28 »
We want to be able to override this by directly replacing the bit value, effectively tricking the camera into thinking it was booted using either power or playback even if it wasn't the case.
Yes.
Quote
Thus, we have no need to know the GPIO table and instead just check the button value ? (in that case, 0xc0220020)
Only the 0x2A04 + 4 and 0x20000/0x40000 are key, the 0xc0220020 can be found in the stubs entries?
Where does 0xc0220020 come from? If it's an alternative address of the button's GPIO, that might be OK, otherwise you can just take the address and the bit from the GPIO table and check that directly.

edit:
You can also check the bits in the source of physw_status, 0xc0220200 (you may have meant this address), use KEY_POWER's bit (it's in stubs_entry.S).
« Last Edit: 08 / April / 2015, 16:10:11 by srsa_4c »

*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #6 on: 08 / April / 2015, 16:10:53 »
It comes from the stubs generated by finsig, and I assumed the MMIO table is usually at 0xc022XXXX
Code: [Select]
//    { 0, KEY_POWER           ,0x00000020 }, // Found @0xffbc0b10, levent 0x100
It's just that I read more times 0xc022 than the ones from the gpio table :)



---

I guessed some values about the focus min/max values, but I really have no way to guess aperture values (unless they're string and I didn't see them), could someone who has the camera check:
- max aperture at min focal length
- max aperture at max focal length
By looking at the firmware, I guessed that min/max focal are 5.0 and 25, please correct me if I'm wrong.


I was looking at the a2500 firmware for 30 mins -_-
« Last Edit: 08 / April / 2015, 16:31:59 by adong »

*

Offline srsa_4c

  • ******
  • 3654
Re: IXUS160/ELPH160 Porting attempt
« Reply #7 on: 08 / April / 2015, 16:15:44 »
I really have no way to guess aperture values (unless they're string and I didn't see them), could someone who has the camera check:
- max aperture at min focal length
- max aperture at max focal length
It's written on the camera's lens.


One more thing:
The guy trying to port the ixus145 reported that the sigfinder's guesses are wrong for several buttons.
« Last Edit: 08 / April / 2015, 16:19:22 by srsa_4c »


*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #8 on: 08 / April / 2015, 16:36:41 »
One more thing:
The guy trying to port the ixus145 reported that the sigfinder's guesses are wrong for several buttons.

Okay, I'll use the GPIO then, thanks :)

*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #9 on: 11 / April / 2015, 12:21:48 »
Can someone with the camera try this firmware ?
thanks :)
« Last Edit: 03 / August / 2015, 03:29:08 by adong »

 

Related Topics