Some propcase investigation - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1] 2   Go Down

Some propcase investigation

  • 10 Replies
  • 9462 Views
*

Offline fudgey

  • *****
  • 1705
  • a570is
Some propcase investigation
« on: 04 / December / 2008, 17:37:33 »
Advertisements
So I was looking around the firmware (a570 100e) and came about some code starting at 0xffe17e64 which is more or less responsible of the JPEG develop process that was quite intelligible in some of what it does with propcases. Namely, it appears to read them using a subroutine at 0xffc0c318 by passing the propcase number in r1, and then it outputs an error string with the name of the propcase if 0xffc0c318 returned 1 in r0.

So, from this I right away got five original Canon names for five propcases:

57 Compression
95 DigitalZoomPos
138 HSCapture
201 NoizeReduction
218 Resolution

Then taking a look at the Wikia page PropertyCase - CHDK Wiki

57      Picture Quality (0,1,2 = Superfine, Fine, Normal)
95   RO   Digital zoom depth (0--6: 0=none, 1--6 are for camera dependent zoom steps, higher number = higher magnification)
218   RW   Picture Size (0,1,2,3,4,6,8 = L,M1,M2,M3,S,Postcard,W)

it looks like we're taking about the same exact numbers. Good. Those two others are previously unknown, especially that NoizeReduction (my SIC, Canon's not so much...) is pretty interesting...

After this I got a stupid idea of going through the firmware to see what other propcases not listed in Wikia are being read by the camera using this same procedure. So here they are, from a570is 100e, a Digic III vxworks camera.

On the left is the propcase number, and after each is a list of addresses of their respective calls to 0xffc0c318 in case someone wants to take a look at one.

For a handful of them, instead of addresses there's a string from a following assert call, which likely correlates with the usage of that propcase.

Some addresses are followed by a strings in paranthesis that appear near the call, which may give some hints about what sort of functionality likes to read that particular propcase.

4 ffc41970
19 ffc418bc
22 ffc4178c
28 ffd418c4(WBShtInf.c) ffd41ce4(WBShtInf.c)
43 ffe310b4(ImageHeader.c) ffeb0640(SsMovieRec.c)
44 ffd368d8 ffd37c80 ffd37d60
51 ffcf3c80
52 ffc42800 ffe30f08 fff29520
54 CenterCxCy.Cx
66 ffc817e0 ffc92c18
67 GetDayLightValueResult
68 fff22578
77 ffd5cfec(MainFlash.c)
80 ffd5cfc4(MainFlash.c)
81 ffd5cf98(MainFlash.c)
82 ffd41940(WBShtInf.c) ffd41d64(WBShtInf.c)
83 ffcf3ca8 ffd41918(WBShtInf.c) ffd41d38(WBShtInf.c)
84 ffd418ec(WBShtInf.c) ffd41d10(WBShtInf.c)
106 ffc4068c
108 ffc4120c
112 ffc41080 ffc5cf84
114 ffd4c10c
116 ffc40e7c
124 GetFlashDurationResult
128 ffc41a38 ffd419ac(WBShtInf.c) ffd41da4(WBShtInf.c)
129 GetFlashLightValueResult
136 ffd419ec(WBShtInf.c) ffd41de0(WBShtInf.c)
138 HSCapture
139 ffc3f278
140 ffc3f2a4
151 ffd4bf78
152 ffc4087c
156 fff27830(MovieRecorder.c)
157 fff27800(MovieRecorder.c)
158 ffc408d4
160 ffc426bc ffc4f108 ffcb7074(PBPlayVolume.c) ffcb74a8
161 ffc426d8 ffc4f124 ffcb74d8
162 ffc4099c
164 ffc42854 ffc4e21c
167 ffc426a0 ffc4f0b8
168 ffc42684 ffc4f09c
174 ffc3c388 ffc3c5c4 ffc40974 ffc42658 ffc4f0d8
192 ffc41134
198 ffc40dec
199 ffc407cc
200 ffc41024
201 NoizeReduction
207 ffd18a30
222 ffc4256c(b)
228 fff27534(MovieRecorder.c)
231 ffd106f8 (related to metering? it's read after 155)
242 ffd419cc(WBShtInf.c) ffd41dc0(WBShtInf.c)
260 ffd1e8e8
261 ffc417d0 ffc418ec
272 fff277b4(MovieRecorder.c)
279 ffc41694 ffc9f3f4 ffca15e8

While at it, I noticed that property 165 (timelapse movie shoot interval) is used (ffc4f0f4) in a570is firmware even though the camera does not have this feature. Maybe it can be done...?

Logged
*

Offline reyalp

  • ******
  • 14126
Re: Some propcase investigation
« Reply #1 on: 04 / December / 2008, 18:51:23 »
Oooh good stuff. Are you using an automated method to find the propcase calls ?
Logged
Don't forget what the H stands for.
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Some propcase investigation
« Reply #2 on: 04 / December / 2008, 19:11:32 »
Quote
Oooh good stuff. Are you using an automated method to find the propcase calls ?

No, it was all manual -- that was the stupidity part of the idea  :haha.

Seriously, 25% through I thought of automation but then I ran into a couple of calls that were calculated and figured automation would have needed to be sort of smart...

Code: [Select]
ffc41680: e3a01f45 mov r1, #276 ; 0x114
ffc4168c: e2811003 add r1, r1, #3 ; 0x3
ffc41694: ebff2b1f bl ffc0c318 <_binary_PRIMARY_BIN_start+0xc318 -217980>

It would also be interesting to do something similar for propcase writes, maybe even more so.
Logged
*

Offline robocat

  • *
  • 33
Re: Some propcase investigation
« Reply #3 on: 04 / December / 2008, 22:40:01 »
Logged
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Some propcase investigation
« Reply #4 on: 05 / December / 2008, 09:44:21 »
nice finding!
maybe we can find out some neat stuff using this method.
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Some propcase investigation
« Reply #5 on: 05 / December / 2008, 12:30:00 »
And of course the 243 calls to GetPropertyCase and 173 calls to SetPropertyCase which get prop number in r0 are insteresting if one is to analyze propcases further.

Logged
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Some propcase investigation
« Reply #6 on: 05 / December / 2008, 12:43:20 »
btw have you tried setting noizereduction?
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Some propcase investigation
« Reply #7 on: 05 / December / 2008, 12:50:03 »
Quote from: PhyrePhoX on 05 / December / 2008, 12:43:20
btw have you tried setting noizereduction?

I tried very briefly, it doesn't stick while idling in normal rec mode if I modify it from a script. But on the other hand why would it, the decision to use noise reduction (both dark frame and high-ISO kinds) is done during half press.

So what should be tried is to override it during the shooting process

half shoot -> shoot state wait -> get_prop, print, set_prop, get_prop, print again -> shoot full

and

half shoot -> shoot state wait -> shoot full -> no sleep or configurable sleep -> get_prop, print, set_prop, get_prop, print again

Using ISO800 and comparing JPEGs of course... As for values, I have no clue, one could study the disassembly to find what values the fw expects :)
Logged
*

Offline reyalp

  • ******
  • 14126
Re: Some propcase investigation
« Reply #8 on: 08 / August / 2010, 05:18:20 »
Bump to and old thread. I've made a tool that can find many of the propcase numbers automatically. It can also be used for other functions that usually take constant values. It's very hacky, not very smart, but the results for GetPropertyCase and SetPropertyCase are quite good.

Usage is
find_calls <dump file> <base address> <address of function> [bitmask of registers r0-r3 of interest]

output is
<address of call> <r0 value> <r1 value> ...

possible values for registers are
"-" the register was not selected on the command line
<hex value> probably, but not 100% certain, the value of the corresponding argument to the function
"U" the register was loaded with an undetermined value, e.g. MOV R0, R8
"?" no value was seen

Example, to find the calls to GetPropertyCase on D10, I do
find_calls PRIMARY.BIN 0xFF810000 0xFF871CCC 5 > getprops.txt

The 5 means I'm interested in R0 (the propcase number) and R2 (the size)

The output looks like
Code: [Select]
0xff8246c4  0x69 - 0x2 -
0xff824758  0x31 - 0x2 -
0xff8252dc  0xda - 0x2 -
0xff825700  0xcf - 0x2 -
0xff825bf8  0xda - 0x2 -
0xff8262bc  ? - 0x2 -

The strategy is to look for B/BL/BLX referring to the desired address, and then work backward for a few instructions (currently 8 ) looking for MOV or LDR that put constant values into the register of interest. It does not deal with adds, which the compiler occasionally generates instead of an LDR. It also won't notice many instructions that could modify the registers, conditional execution etc. It doesn't catch every case, and can make mistakes, but for functions like the propcase functions that mostly use small constant values, it appears to work pretty well.

patch against tools:
http://drop.io/reyalp_chdk/asset/find-calls-work-1-zip
Note this code was hacked together to do this job quickly, it's quite stupid in several ways ;)

example output from d10 and a540
http://drop.io/reyalp_chdk/asset/propcalls-zip
This doesn't cover everywhere the code reads/writes property cases on these cameras, because there are a number of other functions that do roughly the same thing.
Logged
Don't forget what the H stands for.
*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: Some propcase investigation
« Reply #9 on: 31 / October / 2010, 18:03:43 »
I'm researching a bit on propases of the sx210, and get arround a func sub_FFB3986C__PCaseWrapper.c__39, as far as I can see its used by functions related to generating the jpg headers,


Code: [Select]
_sub_FFB3986C__PCaseWrapper.c__39
var_8           = -8
STMFD   SP!, {R3,LR}
                STR     R3, [SP,#8+var_8]
                MOV     R12, R1
                 MOV     R3, R2
               LDMIA   R0, {R0,R1}
                 MOV     R2, R12
               BL      _sub_FF8917C8__PropertyCase.c__580 ; LOCATION: PropertyCase.c:580
                 TST     R0, #1
                LDMNEFD SP!, {R12,LR}
                 MOVNE   R1, #0x27
                ADRNE   R0, aPcasewrapper_c ; "PCaseWrapper.c"
                BNE     DebugAssert
                LDMFD   SP!, {R12,PC}
my guess from the backtrace is that it cuould get names for the exif parameters.  maybe if we can dig into this function we can get easly a list of propcases realted to names

Is there a simply way to get the parameters used by this function, call it from a asm volatile (.... and get the return in c ?
Logged
Pages: [1] 2   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal