the sx10 porting thread

cbatman

I've been using the 1.02b build and it's working great! I think it's ready to be released (as beta at least).
Thanks to Grin and Nimrod for their work.

nimrod

reyalp
nimrod: don't forget that variable addresses could change too.

I looked for that, but I don't think any of them did. I found that the best way to do this is to dump all the symbols to a .MAP file then diff those text files. I'm not sure if this is 100% reliable, after all, if something wasn't mapped to a symbol by IDA or the IDC scripts then it's not going to be in the MAP file, but trying to diff the entire disassembly text (75M files) doesn't seem to work so well due to the massive filesize.

Let me know if you think diffing the MAP file is good enough. If not I'll have to think of something else. Perhaps diffing as a shortcut just won't work and I'll have to just recheck/recopy everything manually.
I suppose I could also chop the massive disasm text files into different chunks too.

BTW, has anyone tried my CHDK config yet? I'm curious as to whether it works for others and what people think of my OSD layout.

nimrod

Sunflower
Is this a firmware upgrade, or an add-on?

Read the wiki. It loads more like a linux kernel module. If you think of a linux kernel file on disk as "firmware", a kernel module just replaces some kernel functions in the kernel after it's loaded into memory without modifying the kernel on disk. CHDK essentially does the same thing.

reyalp

nimrod
Let me know if you think diffing the MAP file is good enough.

I doubt it. Most of RAM addresses used by CHDK aren't recognized by IDA as variables. The thing to do is either
1) just try it.
2) compare the code where the variable is referenced by the canon firmware.
If you start with the highest value address (or the highest that's easy to fine), and it's the same it's a fair bet the others are all the same too.

From the looks of things, 102b and 101a are identical (unless the stubs_min.s for 102b was just copied and not checked!) If this is true, it's probably reasonable to assume in between versions like 101b are the same as well.

GAJoe

Thanks for the brain work Nimrod and Grin!
I have loaded it and have my RAW working. Also did a quick test on two of my favorite scripts ult_intrvl & lightningb successfully. Love having the battery and memory meters.
You guys are great!
GAJoe

ewavr

reyalp
From the looks of things, 102b and 101a are identical (unless the stubs_min.s for 102b was just copied and not checked!) If this is true, it's probably reasonable to assume in between versions like 101b are the same as well.

It seems that stubs_min.S for 1.02b is just copy of 1.01a. But at least FlashParamsTable address (in ROM) must be different?
p.s. In 1.01a and 1.01b zoom_status address is also different.

redeyes3000

the few options I had the chance to test worked very well but ... the menu seems to disappear sometimes without reason

nimrod

reyalp
From the looks of things, 102b and 101a are identical (unless the stubs_min.s for 102b was just copied and not checked!) If this is true, it's probably reasonable to assume in between versions like 101b are the same as well.

Wait, what?

Just comparing the autogenerated stubs_entry.S files, 101a and 101b are different in many places. 101b and 101c only differ in these functions:

101b:

NSTUB(_log, 0xffb01a10)
NSTUB(_log10, 0xffb0069c)
NSTUB(_pow, 0xffb0080c)
NSTUB(_sqrt, 0xffb0366c)

102b:

NSTUB(_log, 0xffb01a40)
NSTUB(_log10, 0xffb006cc)
NSTUB(_pow, 0xffb0083c)
NSTUB(_sqrt, 0xffb0369c)

That's what lead me to think that 101b and 102b were mostly the same (As someone mentioned, looks like 0x30 bytes were added) but diffing some code in 101b&102b it looks like someone changed a datatype from unsigned to signed in the firmware source because lots of "LDR R0, #0" all over have changed to "LDR R0, #FFFFFFFF" (and #1 to #FFFFFFFE, etc.).

reyalp

nimrod

reyalp
From the looks of things, 102b and 101a are identical (unless the stubs_min.s for 102b was just copied and not checked!) If this is true, it's probably reasonable to assume in between versions like 101b are the same as well.

Wait, what?

I was specifically referring to the variable addresses in stubs_min.s, but from ewavrs post it appears this is an error in the 102b port.

Sunflower

nimrod

Sunflower
Is this a firmware upgrade, or an add-on?

Read the wiki. It loads more like a linux kernel module. If you think of a linux kernel file on disk as "firmware", a kernel module just replaces some kernel functions in the kernel after it's loaded into memory without modifying the kernel on disk. CHDK essentially does the same thing.

I did. And then I read this:

sticher
First of all thanks a lot.
I just bought the SX10 and wasn't expecting to get a CHDK-Build for it so fast!! 😐:

Amazing, guys!!!

For the newbies to install the 1.02B:
Just download the test 1.02B from Grin: http://rapidshare.de/files/47479851/sx10-102b-0.9.8.rar.html
Then get the 1.01A from the Autobuild http://mighty-hoernsche.de/ (I took the 'Complete') extract it
and replace the 'PS.FI2' and 'DISKBOOT.BIN'.
Copy the files to your card (dont'lock it), start the camera with the 'play'-button, press 'MENU', go 'up', run the firmware upgrade and you're done.
(worked for me 😀)

Thanks for clearing it up for me. 😀

nimrod

Sunflower

sticher
Copy the files to your card (dont'lock it), start the camera with the 'play'-button, press 'MENU', go 'up', run the firmware upgrade and you're done.

Thanks for clearing it up for me. 😀

Really it's Canon that's confusing you 😀

The "run the firmware upgrade" menu item was named by Canon assuming that this DISKBOOT.BIN and PS.FI2 stuff would only be used for actually upgrading the firmware, however that doesn't have to be the case. Basically the menu option means something more like "execute code" and the code that's executed doesn't have to actually overwrite the firmware at all. It can do anything such as boot itself as a firmware replacement essentially.

So it works something like:

DISKBOOT.BIN gets copied into RAM and boots in place of the firmware
DISKBOOT.BIN makes lots of function calls into the actual firmware

An upgrade DISKBOOT.BIN from Canon would boot in place of the firmware, then start overwriting the firmware storage with new data, then exit.

nimrod

Ok, here's a drop with a new totally untested 1.01b build that may just crash and die because absolutely nobody has even tried to boot it at this point:

http://drop.io/nimrodfiles

There's also a new 1.02b candidate build at that URL that has the FlashParamsTable definition in stubs_min.S fixed (well, I hope so). [BTW, I just realized that I built these images without the games, so hopefully you won't be too devastated about that.]

The patch applied to 1.02b is very simple. Here's the diff:

5c5
< DEF(FlashParamsTable,0xFFB7455C)
---
> DEF(FlashParamsTable,0xFFB746B4)

This is patched against svn vers 774.
I think that the only things that this misdefinition really breaks are a debug display, and any lua scripts that try to use get_parameter_data().

I think this is all that needs to be updated in stubs_min.S. If not, let me know and give me some hint as to how to update the rest of it since the addresses are so low that they'd have to be offsets from a register or something to make sense as something in the firmware.

reyalp

nimrod
If not, let me know and give me some hint as to how to update the rest of it since the addresses are so low that they'd have to be offsets from a register or something to make sense as something in the firmware.

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.

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.

physw_status and physw_run look right to me (unchanged between 101a and 102b). I also agree with 0xFFB746B4 for FlashParamsTable.

edit:
and so does the stuff up to zoom_status

edit:
zoom_status looks like 0xE3EC
the rest looks OK.

Radix

I tried the 1.01b build but it doesn't seem to be working. The camera just locks when I try to start it. The build didn't include the PS.FI2 file. Is it the same in every build or not necessary? I tried using it without that file and copying it from 1.01a and 1.02b builds but that didn't make a change.

But thanks anyway for working on these builds!

reyalp

Radix
I tried the 1.01b build but it doesn't seem to be working. The camera just locks when I try to start it. The build didn't include the PS.FI2 file. Is it the same in every build or not necessary? I tried using it without that file and copying it from 1.01a and 1.02b builds but that didn't make a change.

FI2 is used for the "firm update" option. DISBOOT.BIN is used for autoboot. Each one contains a complete copy of the CHDK program, in slightly different formats.

I've committed the changes for 102b stubs_min.S, and added it to the top level makefile. It should show up in the autobuild shortly.

nimrod

Radix
I tried the 1.01b build but it doesn't seem to be working. The camera just locks when I try to start it.

Not too surprised. I probably missed some things. I'll take another look at this tomorrow after I'm rested....

Did you try to boot it or did you use the "firm update" thing? I didn't get around to building the FI2 yet. If you loaded some other FI2 from another build, then you probably loaded that other build essentially.

Radix

I tried the both.

GAJoe

Any one able to use the "remote enable" to get the homemade USB remote cable to trigger the shutter?
What voltage battery?
Joe

tomaz.stubelj

I installed it from: http://mighty-hoernsche.de/
sx10-102b-0.9.8-776-full_BETA.zip

For now it looks good. I will test it through weekend. Keep you posted...

TNX! You are great!

the_enyel

Hi there, are any news about different firmwares being ported? i've just seen the 1.02 beta on this forum, but as we bought the camera many months ago, the firmware that we have is 1.00C, i think this is the original one for first series.

Anyone knows about it?

Thx!

« Previous Page Next Page »