Windows GUI for CHDK porting - page 4 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 [4] 5 6 7 8 9 10   Go Down

Windows GUI for CHDK porting

  • 98 Replies
  • 144080 Views
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Windows GUI for CHDK porting tools
« Reply #30 on: 28 / August / 2011, 21:06:54 »
Advertisements
Quote from: andyroo on 28 / August / 2011, 20:45:00
I got a little lost with the instructions about the address.txt file...
Try to think of it this way.  The core of the code in boot.c,  capt_seq.c and movie_rec.c comes from the existing routines in the camera.  If you know where that code comes from in an existing port,  you can make an addresses.txt file that lists where each code seqment starts,  how long it is and what it should be called.   Once you have that,  you can point CHDK-PT at the rom dump from a different camera and it will try to find matches with the code in your reference camera based on the addesses.txt file.

Quote
But then I saw code like ...
Obviously,  if you just reload the same code into the camera as what is already there, then there is no way for CHDK to do anything.  So the reference code from the camera PRIMARY.BIN file needs to be modified a bit to hook in the CHDK part.  What you found is an example of that  i.e. code that is in the CHDK source that is not in the original camera source.

Quote
I assume that if loc_F000358 changes I have some work to do on sub_FF000358_my, but if I just look at all the loc_XXXXXXXX codes and change them to reflect the addresses in the firmware I am porting to, does that make things simpler?
Things designated as loc_ are typically targets of local branches.  You pretty much never need to change those.  Things designated sub_xxxxxxxx__my are where different routines copied from the firmware connect together.  If you don't do that,  then the code will jump back into the Canon code and never return.

Quote
AND, am I making this all harder on myself because I don't understand what addresses and labels to pull out of boot.c and put into addresses.txt?
Probably, but what you need is the address of each routine you find in boot.c - anything that starts with :

 void __attribute__((naked,noinline))

Quote
I looked at the sample addresses.txt file but I couldn't figure out how to make a similar list of addresses and task lengths from the boot.c file I am working with.
Here's an actual addresses.txt file from a real world situation (the G11 in this case)  :
Code: [Select]
boot 0xFF81000C 86
sub_FF810354_my 0xFF810354 27
sub_FF811178_my 0xFF811178 44
sub_FF815E34_my 0xFF815E34 30
taskcreate_Startup_my 0xFF81F868 35
task_Startup_my 0xFF81F804 25
taskcreatePhySw_my 0xff833224 21
init_file_modules_task  0xff898fd8 14   
sub_FF88DFCC_my  0xFF88DFCC 17
sub_FFF86F8AC_my  0xFF86F8AC 54
sub_FF86F4E0_my  0xFF86F4E0 29
sub_FF86F1DC_my  0xFF86F1DC 93
JogDial_task_my  0xFF860554 213

Hope that helps.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline funnel

  • ****
  • 349
Re: Windows GUI for CHDK porting tools
« Reply #31 on: 29 / August / 2011, 02:58:00 »
To just port to a different camera you usually don't need to copy all the code, just correct the wrong sub addresses. Usually in a different version the addresses are just offset at some point. For example in sx220 the difference between 100c -> 101a and 101b, the differences start at an offset ~0xff2e0000. What I do is go into boot.c for example and search for "ff2" the look at the ida dissasebmly if the addresses match and correct them, next I search for "ff3" and "ff4". Correct the addresses in boot.c, capt_seq.c, movie_req.c and stubs_min.h.
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Windows GUI for CHDK porting tools
« Reply #32 on: 29 / August / 2011, 18:07:02 »
Quote from: funnel on 29 / August / 2011, 02:58:00
To just port to a different camera you usually don't need to copy all the code, just correct the wrong sub addresses.
That can work too.  I guess its all a question of what you feel most comfortable doing. 

Going through and manually changing addresses is pretty detailed work - you can't afford to a miss an address or calculate an offset incorrectly.  But when you go that route, you have the CHDK changes already built in.

Using CHDK-PT, you get a clean version of the exact code from your firmware release.  But then you have to cut & paste the CHDK changes into that file.

Personally,  I like using the CHDK-PT method,  and I have used both.  But then,  I guess I might be accused of being a little biased.

 



Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline andyroo

  • **
  • 67
Re: Windows GUI for CHDK porting tools
« Reply #33 on: 29 / August / 2011, 21:10:31 »
I think I am getting a clearer picture. If I understand waterwingz correctly, then, by identifying where each code segment starts, I can skip the part of making sure I change every address correctly by hand - including changing lengths of any code segments where the length changes.

I might actually be able to get the hang of this...
Logged
A720 1.00c | D10 1.00b |SX220 1.01a | SX230 ? | SX30 1.00p CHDK ver. 1.1.0-r1727
*

Offline andyroo

  • **
  • 67
Re: Windows GUI for CHDK porting tools
« Reply #34 on: 29 / August / 2011, 22:04:45 »
So when I am counting a length for a routine to put in the address.txt file, do I just count how many lines/ASM commands there are?

For example, if void __attribute__((naked,noinline)) boot() was
Code: [Select]
"loc_FF00000C:\n"
                "LDR     R1, =0xC0410000\n"
                "MOV     R0, #0\n"
                "STR     R0, [R1]\n"
                "MOV     R1, #0x78\n"
                "MCR     p15, 0, R1,c1,c0\n"
                "MOV     R1, #0\n"
                "MCR     p15, 0, R1,c7,c10, 4\n"
                "MCR     p15, 0, R1,c7,c5\n"
"loc_FF00002C:\n"
                "MCR     p15, 0, R1,c7,c6\n"
                "MOV     R0, #0x3D\n"
                "MCR     p15, 0, R0,c6,c0\n"
                "MOV     R0, #0xC000002F\n"
                "MCR     p15, 0, R0,c6,c1\n"
                "MOV     R0, #0x35\n"
                "MCR     p15, 0, R0,c6,c2\n"
                "MOV     R0, #0x40000035\n"
                "MCR     p15, 0, R0,c6,c3\n"
                "MOV     R0, #0x80000017\n"
                "MCR     p15, 0, R0,c6,c4\n"
                "LDR     R0, =0xFF80002F\n"
                "MCR     p15, 0, R0,c6,c5\n"
                "MOV     R0, #0x34\n"
                "MCR     p15, 0, R0,c2,c0\n"
                "MOV     R0, #0x34\n"
                "MCR     p15, 0, R0,c2,c0, 1\n"
                "MOV     R0, #0x34\n"
                "MCR     p15, 0, R0,c3,c0\n"
                "LDR     R0, =0x3333330\n"
                "MCR     p15, 0, R0,c5,c0, 2\n"
                "LDR     R0, =0x3333330\n"
                "MCR     p15, 0, R0,c5,c0, 3\n"
                "MRC     p15, 0, R0,c1,c0\n"
                "ORR     R0, R0, #0x1000\n"
                "ORR     R0, R0, #4\n"
                "ORR     R0, R0, #1\n"
                "MCR     p15, 0, R0,c1,c0\n"
                "MOV     R1, #0x80000006\n"
                "MCR     p15, 0, R1,c9,c1\n"
                "MOV     R1, #6\n"
                "MCR     p15, 0, R1,c9,c1, 1\n"
                "MRC     p15, 0, R1,c1,c0\n"
                "ORR     R1, R1, #0x50000\n"
                "MCR     p15, 0, R1,c1,c0\n"
                "LDR     R2, =0xC0200000\n"
                "MOV     R1, #1\n"
                "STR     R1, [R2,#0x10C]\n"
                "MOV     R1, #0xFF\n"
                "STR     R1, [R2,#0xC]\n"
                "STR     R1, [R2,#0x1C]\n"
                "STR     R1, [R2,#0x2C]\n"
                "STR     R1, [R2,#0x3C]\n"
                "STR     R1, [R2,#0x4C]\n"
                "STR     R1, [R2,#0x5C]\n"
                "STR     R1, [R2,#0x6C]\n"
                "STR     R1, [R2,#0x7C]\n"
                "STR     R1, [R2,#0x8C]\n"
                "STR     R1, [R2,#0x9C]\n"
                "STR     R1, [R2,#0xAC]\n"
                "STR     R1, [R2,#0xBC]\n"
                "STR     R1, [R2,#0xCC]\n"
                "STR     R1, [R2,#0xDC]\n"
                "STR     R1, [R2,#0xEC]\n"
                "STR     R1, [R2,#0xFC]\n"
                "LDR     R1, =0xC0400008\n"
                "LDR     R2, =0x430005\n"
                "STR     R2, [R1]\n"
                "MOV     R1, #1\n"
                "LDR     R2, =0xC0243100\n"
                "STR     R2, [R1]\n"
                "LDR     R2, =0xC0242010\n"
                "LDR     R1, [R2]\n"
                "ORR     R1, R1, #1\n"
                "STR     R1, [R2]\n"
                "LDR     R0, =0xFF4B4DFC\n"
                "LDR     R1, =0x1900\n"
                "LDR     R3, =0x11C18\n"
"loc_FF00013C:\n"
                "CMP     R1, R3\n"
                "LDRCC   R2, [R0],#4\n"
                "STRCC   R2, [R1],#4\n"
                "BCC     loc_FF00013C\n"
                "LDR     R1, =0x18A7FC\n"
                "MOV     R2, #0\n"
"loc_FF000154:\n"
                "CMP     R3, R1\n"
                "STRCC   R2, [R3],#4\n"
                "BCC     loc_FF000154\n"
                "B       sub_FF000358_my\n" (90 lines)
my address entry for boot would be "boot 0xFF00000C 90"

yes?
Logged
A720 1.00c | D10 1.00b |SX220 1.01a | SX230 ? | SX30 1.00p CHDK ver. 1.1.0-r1727
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Windows GUI for CHDK porting tools
« Reply #35 on: 29 / August / 2011, 22:21:22 »
Quote from: andyroo on 29 / August / 2011, 21:10:31
I think I am getting a clearer picture. If I understand waterwingz correctly, then, by identifying where each code segment starts, I can skip the part of making sure I change every address correctly by hand - including changing lengths of any code segments where the length changes.
Yup - that's the beauty of CHDK-PT - its done for you.  You just have to make sure CHDK-PT converts enough code so that the routines in your new port end at the same point as the routines in your old port ( usually with a B or LDMFD instruction.)
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Windows GUI for CHDK porting tools
« Reply #36 on: 29 / August / 2011, 22:25:23 »
Quote from: andyroo on 29 / August / 2011, 22:04:45
So when I am counting a length for a routine to put in the address.txt file, do I just count how many lines/ASM commands there are?
Yes.  But you really should check that the code created by CHDK-PT starts and ends with the same instructions as the code in the boot.c, capt_seq.c and movie_req.c in your reference port.   

P.S.  you can also used CHDK-PT to convert the stubs_entry_2.S file from your reference port to your new port.   That leaves you stubs_min.S to do by hand - although the stub_entry.S file created by the new sig finder will give you a really big head start there !

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline andyroo

  • **
  • 67
Re: Windows GUI for CHDK porting tools
« Reply #37 on: 30 / August / 2011, 00:36:12 »
Quote from: waterwingz on 29 / August / 2011, 22:25:23
Yes.  But you really should check that the code created by CHDK-PT starts and ends with the same instructions as the code in the boot.c, capt_seq.c and movie_req.c in your reference port.

I got as far as taskcreatePhySw_my in my address.txt file, but then I couldn't figure out how long to make the address.txt entry (or why the codes were different at the end). The code in boot.c looks like this:

Code: [Select]
void __attribute__((naked,noinline)) taskcreatePhySw_my() {

asm volatile (

                "STMFD   SP!, {R3-R5,LR}\n"
                "LDR     R4, =0x1C44\n"
                "LDR     R0, [R4,#4]\n"
                "CMP     R0, #0\n"
                "BNE     sub_FF024908\n"
                "MOV     R3, #0\n"
                "STR     R3, [SP]\n"
                "LDR     R3, =mykbd_task\n"
                "MOV     R2, #0x2000\n"
"B sub_FF0248F8\n"
);
}
And the code from the primary.bin file looks like this
Code: [Select]
"loc_FF0248D4:\n"
" STMFD SP!, {R3-R5,LR} \n"               
" LDR R4, =0x1C44 \n"                     
" LDR R0, [R4, #4] \n"                     
" CMP R0, #0 \n"                           
" BNE loc_FF024908 \n"                     
" MOV R3, #0 \n"                           
" STR R3, [SP] \n"                         
" LDR R3, =0xFF0248A0 \n"                 
" MOV R2, #0x800 \n"                       
" MOV R1, #0x17 \n"                       
" LDR R0, =0xFF024B54 \n"                 
" BL loc_FF02B9B4 \n"                     
" STR R0, [R4, #4] \n"                     
"loc_FF024908:\n"
          .
          .
          .
so I don't know what to do. It looks like the CHDK is doing its magic after the STR line, but then will CHDK-PT adjust sub_FF0248F8 if it needs to be adjusted? I don't understand.

Oh, incidentally I just figured out that I don't count the "loc_xxxxxxxx:\n line in my line count - but is the address.txt file just so I get enough code converted? In other words, is it ok to have a few lines too long a length?

And thank you for your help. without your pointers I would have been stuck long ago.
Logged
A720 1.00c | D10 1.00b |SX220 1.01a | SX230 ? | SX30 1.00p CHDK ver. 1.1.0-r1727
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Windows GUI for CHDK porting tools
« Reply #38 on: 30 / August / 2011, 00:42:13 »
Quote from: andyroo on 30 / August / 2011, 00:36:12
Code: [Select]
void __attribute__((naked,noinline)) taskcreatePhySw_my() {

asm volatile (

                "STMFD   SP!, {R3-R5,LR}\n"
                "LDR     R4, =0x1C44\n"
                "LDR     R0, [R4,#4]\n"
                "CMP     R0, #0\n"
                "BNE     sub_FF024908\n"
                "MOV     R3, #0\n"
                "STR     R3, [SP]\n"
                "LDR     R3, =mykbd_task\n"
                "MOV     R2, #0x2000\n"
"B sub_FF0248F8\n"
);
}
And the code from the primary.bin file looks like this
Code: [Select]
"loc_FF0248D4:\n"
" STMFD SP!, {R3-R5,LR} \n"               
" LDR R4, =0x1C44 \n"                     
" LDR R0, [R4, #4] \n"                     
" CMP R0, #0 \n"                           
" BNE loc_FF024908 \n"                     
" MOV R3, #0 \n"                           
" STR R3, [SP] \n"                         
" LDR R3, =0xFF0248A0 \n"                 
" MOV R2, #0x800 \n"                       
" MOV R1, #0x17 \n"                       
" LDR R0, =0xFF024B54 \n"                 
" BL loc_FF02B9B4 \n"                     
" STR R0, [R4, #4] \n"                     
"loc_FF024908:\n"
          .
          .
          .
so I don't know what to do. It looks like the CHDK is doing its magic after the STR line, but then will CHDK-PT adjust sub_FF0248F8 if it needs to be adjusted? I don't understand.

The "B   sub_FF0248F8" instruction is jumping back into the firmware code to finish execution. In this case it will be jumping to the "   MOV   R1, #0x17" instruction.

This is done in cases where the CHDK mods are finished, to save space in the CHDK compiled code.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline c10ud

  • ***
  • 245
Re: Windows GUI for CHDK porting tools
« Reply #39 on: 02 / September / 2011, 05:41:35 »
hey, i wanted to try your tool but the link seems to be dead, do you mind reuploading?

thanks in advance
Logged
Pages: 1 2 3 [4] 5 6 7 8 9 10   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal