the sx10 porting thread - page 41 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 36 37 38 39 40 [41] 42 43 44 45 46 ... 62   Go Down

the sx10 porting thread

  • 613 Replies
  • 305307 Views
*

Offline beez

  • *
  • 5
Re: the sx10 porting thread
« Reply #400 on: 24 / June / 2009, 03:14:10 »
Advertisements
Tested the RAW:

Looks good and the DNG files are opening with no problem in Photoshop CS4

Regards,
Logged
*

Offline vijay

  • *
  • 1
Re: the sx10 porting thread
« Reply #401 on: 24 / June / 2009, 03:39:58 »
Thanks nimrod and everyone else who have been helping out porting the SX10 firmwares. I have a 1.01B version for which i have been following this thread for long. Yesterday i installed the release nimrod posted and it worked well!! Thanks again for the awesome job.

I did checked the following
1. RAW (works with DNG; PS and Picasa were able to open the files)
2. Motion detection
3. Interval shots
4. Histogram
5. OSD layouts
6. Using different fonts

all worked like charm, no hangs and crashes.
I will keep on testing more feature in coming days and keep posted if i find anything.

Thanks a ton again!!  8)
« Last Edit: 24 / June / 2009, 03:41:54 by vijay »
Logged
*

Offline ChrisD

  • *
  • 4
Re: the sx10 porting thread
« Reply #402 on: 24 / June / 2009, 08:35:16 »
Thanks to Nimrod and others on this forum I have managed to get CHDK 101b firmware version for the sx10 up and running on my camera. I mainly wanted it for RAW and am amazed at the increased detail recoverable from overblown highlights. Using CS4 Camera Raw to recover and adjust the exposure on a RAW compared to a JPEG image, much more detail is recoverable in the clouds of the RAW version of the test image compared to the JPEG version.
Logged
*

Offline swordfish

  • *
  • 16
Re: the sx10 porting thread
« Reply #403 on: 24 / June / 2009, 20:25:00 »
Quick update for Firmware version 1.01B tests

- Zebra mode worked
- ISO overrride worked
- Aperture Overrride worked
- Ultra slow Shutter Override worked

Have'nt got the time (daytime!) to test the Ultra fast Shutter stuff. ;)

Cheers,
Swordfish



Logged
*

Offline nimrod

  • *
  • 33
Re: the sx10 porting thread
« Reply #404 on: 24 / June / 2009, 23:59:11 »
Quote from: reyalp on 12 / June / 2009, 01:23:07
No, they are global variables in RAM. If you look at the boot process, it copies initialized globals starting at 0x1900, followed by the firmware BSS. If canon added a global variable between different firmware versions, the addresses will change.

I'll have to go look at the boot process in detail for educational purposes. If nothing else it will help me learn to read the ARM instructions faster.


Quote
To find them, you need to find the ROM code where they are referenced. Sometimes you can just search for the value (as a sequence of bytes) in an existing port, find references to that, and then find the corresponding code in your new port. In other cases the address we use is actually a member of a structure (or array) and so the address only referenced as some other pointer plus a constant in the canon code. Some of the ports have comments on how the various addresses are found. I tried to do this for everything I found in the SD990 port.

Ok, so I'm working on the stubs_min.S for the 1.01b port now. My guess is that not much has changed because so far nobody has found anything horribly broken (from what it sounds like) and I didn't change anything in that file, but I want to understand this anyway so....

Looking at, for example, from the 1.02b port:

DEF(zoom_busy, 0x90E4 + 0x1C)

Based on the way that's written, it sounds like a struct. So I search for 0x90e4 in the 102b code and the most applicable hit looks like:

Code: [Select]
ROM:FF9409B4 zoomStructLoc   DCD 0x90E4              ; DATA XREF: sub_FF94078C+4r
ROM:FF9409B4                                         ; ROM:FF940828r ...

(I then gave it that name.) So then I look for xrefs to this and find a bunch of stuff.

All the xrefs look pretty much the same. They're all "LDR R4, =0x90E4" etc. Looks like the usual setup for load register from indexed addressing mode stuff. So I'll just pick one.... The first thing (address wise) using this in 1.02b looks like:

Code: [Select]
ROM:FF94078C sub_FF94078C                            ; CODE XREF: taskcreate_FirmTransferWaitTask+64p
ROM:FF94078C                 STMFD   SP!, {R4,LR}
ROM:FF940790                 LDR     R4, =0x90E4
ROM:FF940794                 LDR     R0, [R4,#4]
ROM:FF940798                 CMP     R0, #0
ROM:FF94079C                 LDMNEFD SP!, {R4,PC}
ROM:FF9407A0                 BL      sub_FF941600
ROM:FF9407A4                 MOV     R1, #1
ROM:FF9407A8                 MOV     R0, #0
...
ROM:FF9407C4                 MOV     R0, #0
ROM:FF9407C8                 STR     R0, [R4,#0x1C]
ROM:FF9407CC                 STR     R0, [R4,#0x14]
ROM:FF9407D0                 STR     R0, [R4,#0x18]
ROM:FF9407D4                 ADR     R0, aZoomlens   ; "ZoomLens"
...

So I try to pick some stuff such as 0x...0794 - 0x...079f = 04 00 94 E5  00 00 50 E3 10 80 BD 18 which probably won't change unless maybe the compiler decides to use different registers or something, then search for that in 101b:

Well, that sequence looks pretty damn common which I shouldn't be too horribly surprised about I guess. I get about 20 hits or something. It looks like one distinguishing feature of this sub is that it references a string that looks like "ZoomLens", so I click through the hits until I find what looks like the same thing in 101b:

Code: [Select]
ROM:FF94078C sub_FF94078C                            ; CODE XREF: taskcreate_FirmTransferWaitTask+64p
ROM:FF94078C                 STMFD   SP!, {R4,LR}
ROM:FF940790                 LDR     R4, =0x90E4
ROM:FF940794                 LDR     R0, [R4,#4]
ROM:FF940798                 CMP     R0, #0
ROM:FF94079C                 LDMNEFD SP!, {R4,PC}
ROM:FF9407A0                 BL      sub_FF941600
ROM:FF9407A4                 MOV     R1, #1
ROM:FF9407A8                 MOV     R0, #0
ROM:FF9407AC                 BL      sub_FF827D8C
ROM:FF9407B0                 STR     R0, [R4,#0x40]
...
ROM:FF9407C4                 MOV     R0, #0
ROM:FF9407C8                 STR     R0, [R4,#0x1C]
...
ROM:FF9407D4                 ADR     R0, aZoomlens   ; "ZoomLens"

Which just happens to be exactly the same (which I really already knew because I diffed the disasm and knew that anything before 0xFFA9xxxx or so hadn't significantly changed).

So if the 0x90E4 had changed I should see something like "LDR R4, =0x90F0", and if the 0x1c had changed then I'm not sure how I'd know from this function because it looks like it's just initializing these struct members with 0's. So to check the index into the struct I suppose I'd need to find something that makes a more meaningful reference to that member.

Looking through the xref'd code for that, I see a bunch of things storing #1 or #0 in 0x1c, loading 0x1c, CMPing it with #0 and running conditional instructions, asserting if it's not 0 in certain places, etc. That seems to make sense for something that's supposed to be "zoom_busy" because it's getting 1 or 0 stored in it, and getting compared against 0 a lot which means it's being used as a boolean. GiveSemaphore is also getting called....  Anyway, basically seems to make sense though I'm not sure exactly how it was originally found.

So anyway, am I essentially going about this the right way?
Logged
*

Offline reyalp

  • ******
  • 13878
Re: the sx10 porting thread
« Reply #405 on: 25 / June / 2009, 00:29:51 »
Quote
Based on the way that's written, it sounds like a struct. So I search for 0x90e4 in the 102b code and the most applicable hit looks like
Right, it's written like that because 0x90E4 is the constant you can find in the dump. If we just used the final address (0x9100) it would be much harder to figure out where it came from. Some ports are like this, and they are a pain to work on ;)

I try to also identify where the address is used, e.g. (from sd990)
Code: [Select]
DEF(zoom_busy, 0x8A1c)  // 0x8A08 + 0x14, found in sub_FF93368 search on "ZoomLens" OK
So you have the base address, a code address where the specific value is used, a string that was found somewhere near that, and finally OK, meaning that I've verified it somehow (usually by watching it with "misc debug vals").
Quote
So anyway, am I essentially going about this the right way?
Yup. Basically
1) find an identifiable segment of code using the thing you are looking for in a known dump.
2) find the corresponding code in the dump that you are trying to port.

If the dumps are very similar, you can just take the code address you find in 1) and use g in ida to jump to that address in the other dump. If what you see there is identical, you're done. Even if the whole function has moved a small amount, you may find it pretty quickly.
Logged
Don't forget what the H stands for.
*

Offline nimrod

  • *
  • 33
Re: the sx10 porting thread
« Reply #406 on: 25 / June / 2009, 01:09:29 »
Quote from: reyalp on 25 / June / 2009, 00:29:51
...meaning that I've verified it somehow (usually by watching it with "misc debug vals").

I seem to have left my camera in the car or something and I'm too lazy to go get it, but I'm guessing that what you're talking about is in the Debug menu in the standard build, and you're probably not talking about the memory browser.


For everyone:

So we have 1.01a, 1.01b, and 1.02b covered now.... I haven't heard too many people clamoring for 1.00c just yet. I'm willing to work on it, but I need at least one person to test builds (or to send me a 1.00c camera) and more than one to convince me it's worth the effort :)

Also, just out of curiosity, where are people getting 1.00c cameras? I just bought one and it was 1.02b. I get the feeling that what you end up with mostly depends on when you buy the thing, but does it also depend on where? (In this I'm assuming "you" are buying a recently manufactured new camera and not "old new stock" from early last year or whatever.)
Logged
*

Offline reyalp

  • ******
  • 13878
Re: the sx10 porting thread
« Reply #407 on: 25 / June / 2009, 02:02:54 »
Quote from: nimrod on 25 / June / 2009, 01:09:29
I seem to have left my camera in the car or something and I'm too lazy to go get it, but I'm guessing that what you're talking about is in the Debug menu in the standard build, and you're probably not talking about the memory browser.
See gui_draw_debug_vals_osd() in gui.c

Quote
So we have 1.01a, 1.01b, and 1.02b covered now.... I haven't heard too many people clamoring for 1.00c just yet.
103a has been requested a few times.
Logged
Don't forget what the H stands for.
*

Offline martinhamersky

  • *
  • 10
Re: the sx10 porting thread
« Reply #408 on: 25 / June / 2009, 05:01:13 »
Logged
*

Offline nimrod

  • *
  • 33
Re: the sx10 porting thread
« Reply #409 on: 25 / June / 2009, 09:19:46 »
I thought someone said that 1.03a was bit-for-bit the same as 1.02b or something?

Anyway, do we have anyone to do testing for 1.03a?
Logged
Pages: 1 ... 36 37 38 39 40 [41] 42 43 44 45 46 ... 62   Go Up
« previous next »
 

Related Topics