IXUS210 (SD3500) porting thread - page 2 - DryOS Development - CHDK Forum

IXUS210 (SD3500) porting thread

  • 21 Replies
  • 8981 Views
Re: IXUS210 (SD3500) porting thread
« Reply #10 on: 30 / December / 2020, 17:04:49 »
Advertisements
I have some C skills and a PowerShot SD3500 IS with firmware version 1.00f, so I should be able to assist with development and testing.  Here is a firmware dump: https://www36.zippyshare.com/d/yjli598E/34137/PRIMARY.BIN.
Also, note that despite what the wiki page on this camera says, you can use VERS.REQ: move the zoom lever to the zoom out position, start the camera in playback mode, release the lever and press it again.
How exactly do you extract LED addresses?

*

Online reyalp

  • ******
  • 13110
Re: IXUS210 (SD3500) porting thread
« Reply #11 on: 30 / December / 2020, 17:35:42 »
I have some C skills and a PowerShot SD3500 IS with firmware version 1.00f, so I should be able to assist with development and testing.  Here is a firmware dump: https://www36.zippyshare.com/d/yjli598E/34137/PRIMARY.BIN.
Also, note that despite what the wiki page on this camera says, you can use VERS.REQ: move the zoom lever to the zoom out position, start the camera in playback mode, release the lever and press it again.
Interesting, I don't recall seeing that combo before.
Quote
How exactly do you extract LED addresses?
You can run the sig finder: Set up a minimal platform / sub tree (see https://chdk.fandom.com/wiki/Firmware_analysis_with_Ghidra#Preparing_CHDK_stubs_files) and make rebuild-stubs.  It will be the first step to porting anyway. Unless you already have another reverse engineering tool you're proficient with, I'd highly recommend following the rest of the that page too.

Alternately, there's a very good chance your camera uses the same addresses that others released around the same time to do. See https://chdk.fandom.com/wiki/P-ID_(Table) to find them, you'll want to use some for porting references anyway.
Don't forget what the H stands for.

Re: IXUS210 (SD3500) porting thread
« Reply #12 on: 31 / December / 2020, 19:11:02 »
I have some C skills and a PowerShot SD3500 IS with firmware version 1.00f, so I should be able to assist with development and testing.  Here is a firmware dump: https://www36.zippyshare.com/d/yjli598E/34137/PRIMARY.BIN.
Also, note that despite what the wiki page on this camera says, you can use VERS.REQ: move the zoom lever to the zoom out position, start the camera in playback mode, release the lever and press it again.
Interesting, I don't recall seeing that combo before.
Quote
How exactly do you extract LED addresses?
You can run the sig finder: Set up a minimal platform / sub tree (see https://chdk.fandom.com/wiki/Firmware_analysis_with_Ghidra#Preparing_CHDK_stubs_files) and make rebuild-stubs.  It will be the first step to porting anyway. Unless you already have another reverse engineering tool you're proficient with, I'd highly recommend following the rest of the that page too.

Alternately, there's a very good chance your camera uses the same addresses that others released around the same time to do. See https://chdk.fandom.com/wiki/P-ID_(Table) to find them, you'll want to use some for porting references anyway.
I successfully decompiled the firmware and generated the stubs files (attached).  How do you extract the LED and button addresses from the raw firmware?
« Last Edit: 31 / December / 2020, 19:12:57 by RegisteredUser »

*

Online reyalp

  • ******
  • 13110
Re: IXUS210 (SD3500) porting thread
« Reply #13 on: 31 / December / 2020, 19:50:05 »
I successfully decompiled the firmware and generated the stubs files (attached).  How do you extract the LED and button addresses from the raw firmware?
They are found by finsig_dryos.c

Generally, finsig matches lare coded based on taking something that's already known in one port from experiment or reverse engineering, and then identifying sequences of instructions that lead to the same values in other, similar firmware.

This is also how most of the manual porting is done, and also similar to how Ghidra "version tracking" works https://chdk.fandom.com/wiki/Ghidra_Version_Tracking_workflow_for_porting
Don't forget what the H stands for.


Re: IXUS210 (SD3500) porting thread
« Reply #14 on: 02 / January / 2021, 14:52:30 »
I successfully decompiled the firmware and generated the stubs files (attached).  How do you extract the LED and button addresses from the raw firmware?
They are found by finsig_dryos.c

Generally, finsig matches lare coded based on taking something that's already known in one port from experiment or reverse engineering, and then identifying sequences of instructions that lead to the same values in other, similar firmware.

This is also how most of the manual porting is done, and also similar to how Ghidra "version tracking" works https://chdk.fandom.com/wiki/Ghidra_Version_Tracking_workflow_for_porting
Using the method here: https://chdk.setepontos.com/index.php?topic=9005.msg93932#msg93932, I managed to extract the LED addresses:
Code: [Select]
Poke8(0xC0220130, 0x46) ' turns the green LED on
Poke8(0xC0223030, 0x46) ' turns the orange LED on
Poke8(0xC0220130, 0x44) ' turns the green LED off
Poke8(0xC0223030, 0x44) ' turns the orange LED off
Should this port be based on the SX210, since it is the camera released after the SD3500 IS and has a CHDK port?

*

Online reyalp

  • ******
  • 13110
Re: IXUS210 (SD3500) porting thread
« Reply #15 on: 02 / January / 2021, 16:06:07 »
Code: [Select]
Poke8(0xC0220130, 0x46) ' turns the green LED on
Poke8(0xC0223030, 0x46) ' turns the orange LED on
Poke8(0xC0220130, 0x44) ' turns the green LED off
Poke8(0xC0223030, 0x44) ' turns the orange LED off
Oh sorry, misunderstood your last question. Those MMIO addresses are actually listed in the stubs_entry.S you posted (under LED table), I though you were asking how they got there  :-[

Quote
Should this port be based on the SX210, since it is the camera released after the SD3500 IS and has a CHDK port?
I'd suggest the ixus105 or ixus130, since they are the same dryos rev and in the "ixus" series.

Your camera appears to be touchscreen without enough buttons for normal CHDK UI, so you will also want to look at the ports with CAM_TOUCHSCREEN_UI (ixus240, ixus310, and N/N fb). My recommendation would be ixus310, IIRC that was the original touchscreen implementation by philmoz.

Don't forget what the H stands for.

Re: IXUS210 (SD3500) porting thread
« Reply #16 on: 03 / January / 2021, 17:51:19 »
Code: [Select]
Poke8(0xC0220130, 0x46) ' turns the green LED on
Poke8(0xC0223030, 0x46) ' turns the orange LED on
Poke8(0xC0220130, 0x44) ' turns the green LED off
Poke8(0xC0223030, 0x44) ' turns the orange LED off
Oh sorry, misunderstood your last question. Those MMIO addresses are actually listed in the stubs_entry.S you posted (under LED table), I though you were asking how they got there  :-[
Ah.  I thought that it was telling me how to find them and was totally confused.  Thanks anyway...
Quote
Should this port be based on the SX210, since it is the camera released after the SD3500 IS and has a CHDK port?
I'd suggest the ixus105 or ixus130, since they are the same dryos rev and in the "ixus" series.

Your camera appears to be touchscreen without enough buttons for normal CHDK UI, so you will also want to look at the ports with CAM_TOUCHSCREEN_UI (ixus240, ixus310, and N/N fb). My recommendation would be ixus310, IIRC that was the original touchscreen implementation by philmoz.
Yes, it only has playback (alt), on/off (not usable anyway), shutter and zoom unless the video/picture/auto slider counts.  I've now copied the ixus310 files and made minimal modifications such as adding the keymap values (see attachment).  Am I now supposed to reverse-engineer the firmware?

*

Online reyalp

  • ******
  • 13110
Re: IXUS210 (SD3500) porting thread
« Reply #17 on: 03 / January / 2021, 21:19:36 »
Am I now supposed to reverse-engineer the firmware?
Yes ;)

More specifically, you need to
1) Make all the stuff in stubs_entry_2.S and stubs_min.S, makefile.inc files correct for your camera
2) Generate the assembly in boot.c, capt_seq.c etc from your camera, with the various hooks and modifications in the appropriate places
3) Update platform_camera.h to reflect your camera
4) Update the other platform files like kdb.c, shooting.c, lib.c and so on.

#1 involves actual reverse engineering. What ever isn't found automatically, you need to find by analysis. I highly recommend Ghidra with the versioning tool.
#2 is mostly done with code-gen. Update the code_gen.txt to produce boot.c etc with the modifications at the equivalent points in your firmware. Some documentation can be found at the start of tools/code_gen.c. Referring to the disassembly in Ghidra and other ports files can be helpful.
#3 and #4 come from various places: Reverse engineering, testing, reading specs...

Note these aren't really done sequentially in the order above. Instead, you want to get enough correct in each part to have a minimally working build, and then incrementally add stuff to get more features working.

You can dummy things out to make it compile (i.e. using NULL_SUB in stubs_entry_2, or FAKEDEF, or just being sure that some thing copied form another port isn't actually going to be called), but you should try to keep track of which things you've actually done, so at the and you can go through and know that you've made a conscious decision about each item. You'll need to do a fair bit of grepping and wandering through the code to figure out which parts are safe to do when.

So step one is to get a build that boots and blinks an LED.  This means setting up the loader directory (which should be mostly copy/paste). You can make an infinite loop that blinks an LED there to make sure you file is running. You don't have to worry if the rest of the code is right, because execution will never get there.

Next step is to set up platform/boot.c, so you can boot through the CHDK process without starting any CHDK tasks. This means you implement boot(), and the following functions up to where diskboot.bin is started (you need to comment it out to prevent a boot loop), but don't implement the task hooks or try to start CHDK tasks. You can start a simple task that blinks LEDs in a loop.

Once that's working, you'll want to implement kbd_task and spytask, so you have input and display capability and chdkptp for testing and upload. This mostly involves kbd.c, lib.c and platform_camera.h

Once those are working, you can do capt_seq.c to get the shooting functionality, which will give you a minimally useful port. After that you can stuff like filewrite and movierec.

FWIW, if you want some more real time advice I'm often in the IRC channel #chdk on freenode.

Quote
I've now copied the ixus310 files
Note the 310 is somewhat newer than your camera. You'll definitely want it as a reference for the touch screen stuff, but cams like the ixus105 and ixus130 will likely be a closer comparison for general reverse engineering. It's often helpful to refer to several cams in any case.
Don't forget what the H stands for.


Re: IXUS210 (SD3500) porting thread
« Reply #18 on: 06 / January / 2021, 16:34:39 »
After 3 days, I've managed to make some headway:
#1 involves actual reverse engineering. What ever isn't found automatically, you need to find by analysis. I highly recommend Ghidra with the versioning tool.
I've compared it to the PowerShot 3500IS per your suggestion, now I have the matches but can't figure out how to show only the non-matches.
#2 is mostly done with code-gen. Update the code_gen.txt to produce boot.c etc with the modifications at the equivalent points in your firmware. Some documentation can be found at the start of tools/code_gen.c. Referring to the disassembly in Ghidra and other ports files can be helpful.
How do you find the bootloader's address?
#3 and #4 come from various places: Reverse engineering, testing, reading specs...
I got the ISO values and some properties for platform_camera.h.
You can dummy things out to make it compile (i.e. using NULL_SUB in stubs_entry_2, or FAKEDEF, or just being sure that some thing copied form another port isn't actually going to be called), but you should try to keep track of which things you've actually done, so at the and you can go through and know that you've made a conscious decision about each item. You'll need to do a fair bit of grepping and wandering through the code to figure out which parts are safe to do when.
When you say "safe", do you mean that the worst that can happen is messing up the camera's settings or do you mean that you can overwrite the firmware or poke8 to random places if you're not careful?
Sorry if I need a lot of guidance on this, I'm new to porting and decompiling firmware.

*

Online reyalp

  • ******
  • 13110
Re: IXUS210 (SD3500) porting thread
« Reply #19 on: 06 / January / 2021, 19:32:55 »
I've compared it to the PowerShot 3500IS per your suggestion,
Your camera is the SD3500, which are you comparing it to?
Quote
now I have the matches but can't figure out how to show only the non-matches.
In the ghidra version tool?
I would approach this by working through the things that need to be found:
Everything in stubs_min.S, stubs_entry_2.s, and any errors regarding not found items in stubs_entry.S.

So if you're looking for say, focus_busy, you can search for it in the existing port, and then see if there's a match for your port.

Note that when you build stubs_entry.S for this, you should comment out everything in stubs_min.S and stubs_entry_2 because those were manually defined for some other camera. You will likely then get errors about things that weren't found.

Since you are working on a quite old model, the sig finder matches should be pretty good, it's possible there's nothing you immediately need to find.


Quote
How do you find the bootloader's address?
You mean the start of the main firmware that gets copied in boot.c? That will be ff810000 on your cam. You can recognize it on these cams by the string "gaonisoy" appearing immediately after the first jump instruction.

Quote
When you say "safe", do you mean that the worst that can happen is messing up the camera's settings or do you mean that you can overwrite the firmware or poke8 to random places if you're not careful?
Sorry if I need a lot of guidance on this, I'm new to porting and decompiling firmware.
I mean things where being wrong won't crash the camera, because it's hard to make progress on your port if it always crashes. If you start from a copy of another port, all the addresses and inline asm you haven't fixed up will be completely wrong, and attempting to use them (call a function or access a variable) will likely crash or cause other misbehavior.

So if you want to have want to have the cam boot, you need be sure it doesn't try to access something that you haven't updated. For a more concrete example, if you hadn't found one of the zoom related functions, you'd probably be fine to boot the camera, but if you dindn't have malloc, you'd be in trouble. If you aren't sure about something, you can search the source to see how it's used.

Permanent damage is extremely rare (there's only a handful of suspected cases in the entire history of CHDK), although there's no guarantee. It's normal to crash cameras many times in the process of making a port.
Don't forget what the H stands for.

 

Related Topics