Porting chdk to the G9

[jeff666]

So -- putting more of the firmware into CHDK hasn't helped and neither has putting less of it in.  I'm fresh out of ideas.  Anybody out there have a new approach? 

Sorry for replying so late.

Observation:
* you have a program and expect it to behave in a specific way
* this program behaves differently than you expected.
* you (i.e. we) are sure that our little devices do exactly what they're told to do

Conclusion 1: The device executes a program that differs from what you have developed.
Conclusion 2: The program you developed is changed at some point, most probably on the device.

Resolution: Test what the device actually executes and fix your program if necessary.


You may want to use the function WriteSDCard which is used for the udumper, as well. It writes a portion of memory to a specific sector on the SD. WriteSDCard is part of the official firmware. Ask if you have trouble locating it.

Syntax: WriteSDCard(int drive, int startsector, int sectorcount, int memstart);
drive is always 0
startsector is the first sector on the SD that is written
sectorcount is the number of sectors that are written (1sector = 512bytes)
memstart is the first byte of memory that has to be written.

You may have trouble writing the first few bytes of memory. In case your dump doesn't work, try 0x1900 as memory start:

WriteSDCard(0, 1024, 2048, 0x1900);

Writes 1mb (2048 sectors) of memory, starting at 0x1900 to the sd starting at sector 1024.
Make sure your card is empty so you don't overwrite data you still need.

further code example:
typedef int (*f_w)(int, int, int, int); // drive(?), start sector, number of sectors, address
f_w WriteSDCard; // "variable" declaration
WriteSDCard=(f_w)(0xFFxxxxxx); // set function pointer, use firmware-specific address


After you have the memory extracted, load it in IDA as additional file to the firmware. Now you can check if the device executes exactly the same code that you have written.

Cheers.

[bongo_bingo]

hello jeff666,

thanks for the idea, I searching in the forum how to implent. Should it be added to boot.c? how?

jeff666, what do think bout using the s5is code as a template for the g9(as v3rtex suggested)?
I was looking to the s5is boot.c, it implements a complete sub_ff810000, but from my ida's dump ff810000, looks like this:

Code: [Select]

ROM:FF810000 ; Segment type: Pure code
ROM:FF810000                 AREA ROM, CODE, READWRITE, ALIGN=0
ROM:FF810000                 ; ORG 0xFF810000
ROM:FF810000 ; START OF FUNCTION CHUNK FOR sub_FF82C7E4
ROM:FF810000                 CODE32
ROM:FF810000
ROM:FF810000 loc_FF810000                            ; CODE XREF: sub_FF82C7E4+E4j
ROM:FF810000                                         ; DATA XREF: ROM:off_FF823788o ...
ROM:FF810000                 B       loc_FF81000C
ROM:FF810000 ; END OF FUNCTION CHUNK FOR sub_FF82C7E4
ROM:FF810000 ; ---------------------------------------------------------------------------
ROM:FF810004 aGaonisoy       DCB "gaonisoy"
ROM:FF81000C ; ---------------------------------------------------------------------------
ROM:FF81000C ; START OF FUNCTION CHUNK FOR sub_FF82C7E4
ROM:FF81000C
ROM:FF81000C loc_FF81000C                            ; CODE XREF: sub_FF82C7E4:loc_FF810000j
ROM:FF81000C                 LDR     R1, =0xC0410000
ROM:FF810010                 MOV     R0, #0
ROM:FF810014                 STR     R0, [R1]
ROM:FF810018                 MOV     R1, #0x78
ROM:FF81001C                 MCR     p15, 0, R1,c1,c0
ROM:FF810020                 MOV     R1, #0
ROM:FF810024                 MCR     p15, 0, R1,c7,c10, 4
ROM:FF810028                 MCR     p15, 0, R1,c7,c5
ROM:FF81002C                 MCR     p15, 0, R1,c7,c6
ROM:FF810030                 MOV     R0, #0x3D
ROM:FF810034                 MCR     p15, 0, R0,c6,c0
ROM:FF810038                 MOV     R0, #0xC000002F
ROM:FF81003C                 MCR     p15, 0, R0,c6,c1
ROM:FF810040                 MOV     R0, #0x33
ROM:FF810044                 MCR     p15, 0, R0,c6,c2
ROM:FF810048                 LDR     R0, =0x10000033
ROM:FF81004C                 MCR     p15, 0, R0,c6,c3
ROM:FF810050                 MOV     R0, #0x40000017
ROM:FF810054                 MCR     p15, 0, R0,c6,c4
ROM:FF810058                 LDR     R0, =0xFF80002D
ROM:FF81005C                 MCR     p15, 0, R0,c6,c5
ROM:FF810060                 MOV     R0, #0x34
ROM:FF810064                 MCR     p15, 0, R0,c2,c0
ROM:FF810068                 MOV     R0, #0x34
ROM:FF81006C                 MCR     p15, 0, R0,c2,c0, 1
ROM:FF810070                 MOV     R0, #0x34
ROM:FF810074                 MCR     p15, 0, R0,c3,c0
ROM:FF810078                 LDR     R0, =0x3333330
ROM:FF81007C                 MCR     p15, 0, R0,c5,c0, 2
ROM:FF810080                 LDR     R0, =0x3333330
ROM:FF810084                 MCR     p15, 0, R0,c5,c0, 3
ROM:FF810088                 MRC     p15, 0, R0,c1,c0
ROM:FF81008C                 ORR     R0, R0, #0x1000
ROM:FF810090                 ORR     R0, R0, #4
ROM:FF810094                 ORR     R0, R0, #1
ROM:FF810098                 MCR     p15, 0, R0,c1,c0
ROM:FF81009C                 MOV     R1, #0x40000006
ROM:FF8100A0                 MCR     p15, 0, R1,c9,c1
ROM:FF8100A4                 MOV     R1, #6
ROM:FF8100A8                 MCR     p15, 0, R1,c9,c1, 1
ROM:FF8100AC                 MRC     p15, 0, R1,c1,c0
ROM:FF8100B0                 ORR     R1, R1, #0x50000
ROM:FF8100B4                 MCR     p15, 0, R1,c1,c0
ROM:FF8100B8                 LDR     R2, =0xC0200000
ROM:FF8100BC                 MOV     R1, #1
ROM:FF8100C0                 STR     R1, [R2,#0x10C]
ROM:FF8100C4                 MOV     R1, #0xFF
ROM:FF8100C8                 STR     R1, [R2,#0xC]
ROM:FF8100CC                 STR     R1, [R2,#0x1C]
ROM:FF8100D0                 STR     R1, [R2,#0x2C]
ROM:FF8100D4                 STR     R1, [R2,#0x3C]
ROM:FF8100D8                 STR     R1, [R2,#0x4C]
ROM:FF8100DC                 STR     R1, [R2,#0x5C]
ROM:FF8100E0                 STR     R1, [R2,#0x6C]
ROM:FF8100E4                 STR     R1, [R2,#0x7C]
ROM:FF8100E8                 STR     R1, [R2,#0x8C]
ROM:FF8100EC                 STR     R1, [R2,#0x9C]
ROM:FF8100F0                 STR     R1, [R2,#0xAC]
ROM:FF8100F4                 STR     R1, [R2,#0xBC]
ROM:FF8100F8                 STR     R1, [R2,#0xCC]
ROM:FF8100FC                 STR     R1, [R2,#0xDC]
ROM:FF810100                 STR     R1, [R2,#0xEC]
ROM:FF810104                 STR     R1, [R2,#0xFC]
ROM:FF810108                 LDR     R1, =0xC0400008
ROM:FF81010C                 LDR     R2, =0x430005
ROM:FF810110                 STR     R2, [R1]
ROM:FF810114                 MOV     R1, #1
ROM:FF810118                 LDR     R2, =0xC0243100
ROM:FF81011C                 STR     R2, [R1]
ROM:FF810120                 LDR     R2, =0xC0242010
ROM:FF810124                 LDR     R1, [R2]
ROM:FF810128                 ORR     R1, R1, #1
ROM:FF81012C                 STR     R1, [R2]
ROM:FF810130                 LDR     R0, =unk_FFB2E3F4
ROM:FF810134                 LDR     R1, =0x1900
ROM:FF810138                 LDR     R3, =0x140E4
ROM:FF81013C
ROM:FF81013C loc_FF81013C                            ; CODE XREF: sub_FF82C7E4-1C69Cj
ROM:FF81013C                 CMP     R1, R3
ROM:FF810140                 LDRCC   R2, [R0],#4
ROM:FF810144                 STRCC   R2, [R1],#4
ROM:FF810148                 BCC     loc_FF81013C
ROM:FF81014C                 LDR     R1, =0xB0B68
ROM:FF810150                 MOV     R2, #0
ROM:FF810154
ROM:FF810154 loc_FF810154                            ; CODE XREF: sub_FF82C7E4-1C688j
ROM:FF810154                 CMP     R3, R1
ROM:FF810158                 STRCC   R2, [R3],#4
ROM:FF81015C                 BCC     loc_FF810154
ROM:FF810160                 B       loc_FF8101A4
ROM:FF810160 ; END OF FUNCTION CHUNK FOR sub_FF82C7E4


[v3rtex]

Bongo, I am glad you are looking at the source of CHDK for the S5IS.

Now you need the corresponding firmware dump (with the correct version) and decompile it with IDA. Then you'll be able to compare it with the decompiled ASM code of your G9. It will make your life easier to track changes between the port of the S5IS and the G9.

So to answer your previous question, check how the S5IS IDA's dump looks like at ff810000.

I hope it helps 

BTW, I suggested the S5IS, but I guess the source of any ported DryOs camera would help in porting the G9. It would be wise to use the port of a camera with functionalities close to the G9, to keep their decompiled ASM codes as similar as possible. The G9 and the S5IS are indeed quite similar as you can read in this comparison http://www.dpreview.com/reviews/compare_post.asp?method=sidebyside&cameras=canon_g9%2Ccanon_s5is&show=all

[Guido44]

Just a quick note to let you guys know that your efforts are appreciated.

I'm not a programmer, but I frequently check your progress in this thread for the new G9 CHDK.

I need this program for my new photo biz.  Keep at guys/gals!

Thanks again,

dan

[jeff666]

I searching in the forum how to implent. Should it be added to boot.c? how?

Save the memory contents from the last piece of code that you know is executed. If everything looks ok there, your code might be overwritten at a later time.

Example how to refer to a function in the firmware (taken from an early udumper-test):

Code: C

1. typedef int (*f_w)(int, int, int, int);
2.  
3. int main() {
4.     f_w WriteSDCard;
5.     WriteSDCard=(f_w)(0xFFCF51b0); // address from A720
6.     WriteSDCard(0, START_SECTOR, FW_SIZE/512, FW_ADDRESS);
7. }
8.  

jeff666, what do think bout using the s5is code as a template for the g9(as v3rtex suggested)?

I'd prefer the A720, because it's firmware-start differs from the G9 and S5. If you miss an address during the porting process, you will recognize it easily (0xFFC... vs. 0xFF8...). Other than that I can't name a reason to prefer one or the other.

I was looking to the s5is boot.c, it implements a complete sub_ff810000, but from my ida's dump ff810000, looks like this:

The whole first block is completely skipped by CHDK. The main thing that happens here, is duplicating a memory segment of preset values from ROM to RAM. This is rewritten in C. The code I prepared should cover this. ASM code is taken and modified afterwards.

Cheers.

[dlw]

I've been away for a while, and may not have time to play for a few more days -- but:
I followed the S5IS model of replicating the firmware assembly memory move section (Jeff666, I know this should make no difference, but I was grasping at straws . . .).  I also left out the CPU speed-up code so that I would have an exact copy of the firmware inserted into CHDK.  I get a boot loop (just as I should) for as far as I've gotten.  As soon as I can get back to this, I'll move past the call to StartDiskboot (FF82C924) and hope CHDK boots a little bit (without spytask and physw not much should happen) -- unless one of you (bongo-bingo?) gets there first . . .

Jeff666 -- thank you for the advice and the WriteSDCard information.  I can see that it will be most helpful.  I notice that there are some dump functions toward the end of platform/s5is/sub/101a/boot.c.  Would these be useful after a partial CHDK boot?

v3rtex -- I appreciate your interest and suggestions.  I reccomend that you read this thread from the beginning.

PS:  I'd throw $20 US into the pot myself -- I'm still processing the "8 - 12 hours for an experienced developer to port CHDK" estimate from an earlier post.

[jeff666]

thank you for the advice and the WriteSDCard information.  I can see that it will be most helpful.  I notice that there are some dump functions toward the end of platform/s5is/sub/101a/boot.c.  Would these be useful after a partial CHDK boot?

You might have some success with the function I called qDump. I think I used it at some point when I ran into similar problems. If it works, you get a regular file on the card. If it doesn't you'll have to stick to WriteSDCard.

Btw: I just noticed that you can include a declaration for WriteSDCard by utilizing the existing glue-code for firmware functions. Add the pointer to stubs_entry_2.S, add a forward declaration to your c-file (extern long _xxx()) and you're ready to call the function. See the _xxx calls in boot.c

I'm still processing the "8 - 12 hours for an experienced developer to port CHDK" estimate from an earlier post.

For a straight-forward port without any major trouble (i.e. significant changes from earlier cameras) two days with 5-6 hours each are a reasonable amount of time to port about 90-95% of the features. Problem is that most devs have exactly one camera so for every new model we have to find a new developer and teach him how to do a port.

Cheers.

[bongo_bingo]

Hello, been very busy this days.

I think I've found the address of function WriteSDCard, it should be FF928CF4 (g9/100f).
I'm still unable to implement the code in boot.c

cheers

Edit 1:

I've managed to add writesdcard in the last executed sub this way, gcc compiled with no errors

Code: [Select]

void __attribute__((naked,noinline)) sub_FF81517C_my() { //"taskcreate_ClockSave\n"

typedef int (*f_w)(int, int, int, int);
 
int main() {
    f_w WriteSDCard;
    WriteSDCard=(f_w)(0xFF928CF4); // address from A720
    WriteSDCard(0, 1024, 2048, 0x1900);
}



asm volatile (

//ok
 
                 "MOV     R0, #1\n"
                 "MOV     R1, #0x40000000\n"
                 "STMFD   SP!, {R3,LR}\n"
                 "STR     R0, [R1,#0x7C4]\n"
                 "RSB     R1, R1, R0,LSL#22\n"
                 "STR     R0, [R1,#0x30]\n"
                 
//ok

"BL      sub_FF81B7F4\n" // j_IRQdisable
                 "MOV     R2, R0\n"
                 "BL      sub_FF815144\n"
                 "MOV     R0, R2\n"
                 
"BL      sub_FF81B7F8\n" //j_IRQrestore
                 "MOV     R3, #0\n"
                 "STR     R3, [SP,#8-8]\n" //[SP,#8+var_8]:"var_8           = -8\n"
 
//ok
 
"LDR     R3, =0xFF8150CC\n" // task_ClockSave, was adr
                 "MOV     R2, #0x200\n"
                 "MOV     R1, #0x20\n"

//ok
                 
"LDR     R0, =0xFF8152B4\n" // aClocksave, was adr
                 
//ok   

"BL      sub_FF81BAF0\n" // CreateTask


//ok
                 "LDMFD   SP!, {R12,PC}\n"


        );
}; //#fe
it didn't generate any new file on the sd card. What's wrong?

[bongo_bingo]

Hi,
just to experiment I've tryed to load in Ida the compiled diskboot.bin, as additional binary file.
Ida loaded it with no problem.
But: what to do next, how to use this file to help?

[jeff666]

I think I've found the address of function WriteSDCard, it should be FF928CF4 (g9/100f).

That is correct.

it didn't generate any new file on the sd card. What's wrong?

Your assumption that a new file would be created. WriteSDCard writes a sector. Use a diskeditor to access sectors directly. If you have linux you can use dd:

dd if=<dev-to-sd-card> of=<output_filename> bs=512 count=<number of sectors> skip=<startsector>

Btw: are you sure the code you posted did compile?

Cheers.

[bongo_bingo]

hello jeff666,

that code compiles, but I'm unsure if it works.

I'm using Hxd, a free hex/disk editor (from Freeware Programs | mh-nexus ), but I don't know how to analyze the results.

I've uploaded the sd card dump to zshare zSHARE - disco removibile 1.zip

[bongo_bingo]

hi jeff666,

can you help me to implement the writesdcard?

[jeff666]

can you help me to implement the writesdcard?

I should be able to make a suggestion. Post your boot.c. I'll have a look this evening.

Cheers.

[bongo_bingo]

here is my boot.c.

"ok" means that I was able to follow the execution of the code with led debug.

I've added sub_FF81517C_my because gcc aked for it, but it seems after that sub the code doesn't return to chdk.

The results of this code is that the debug led (AF) blinks one time after the g9 is turned on. The led blinks one even if I press the power or the play buttons, the led remains on for the time I hold one of this buttons.

Thanks again for the help jeff666,and sorry for my bad english

[johngalt42]

Wow - you guys have been putting in lots of work! Thanks. I also pledge $20US towards a G9 for an experienced developer if that would speed things up.