Another thing I don't quite understand: I have some busy loops for the LED flashing, and the one at the very beginning of the boot function runs about 16 times slower than the others.
Some of ASM code in boot.c enables the CPU caches
If you post a snippet of code where the crash happens someone might have an idea.The Ixus95 port is quite immature, so I'd definitely suggest referring to other cams as well.
void boot() { long *canon_data_src = (void*)0xFFBF837C; //From end of first function long *canon_data_dst = (void*)0x1900; //From end of first function long canon_data_len = 0xEBD0 - 0x1900; // data_end - data_start long *canon_bss_start = (void*)0xEBD0; // just after data long canon_bss_len = 0x14FE20 - 0xEBD0; //In loop at end of first function long i; // enable caches and write buffer... this is a carryover from old dryos ports, may not be useful asm volatile ( "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" :::"r0"); for(i=0;i<canon_data_len/4;i++) canon_data_dst[i]=canon_data_src[i]; for(i=0;i<canon_bss_len/4;i++) canon_bss_start[i]=0;// see [url=http://chdk.setepontos.com/index.php/topic,2972.msg30712.html#msg30712]SD990[/url] *(int*)0x1934=(int)taskCreateHook; *(int*)0x1938=(int)taskCreateHook2; //VERIFY_SD780 // IXUS130: see code from FF85F3F0 *(int*)(0x2484)= (*(int*)0xC0220128)&1 ? 0x400000 : 0x200000; // jump to init-sequence that follows the data-copy-routine asm volatile ("B sub_FF810354_my\n");}void __attribute__((naked,noinline)) sub_FF810354_my() { asm volatile ("..." // copied from fw dump" BL sub_FF811198_my\n" );}void __attribute__((naked,noinline)) sub_FF811198_my() { asm volatile ("..."" LDR R0, =new_sa\n" //Replaces original start location 0x14FE20" LDR R0, [R0]\n"" ..." // Storing lots of things on the stack, including:" LDR R1, =sub_FF815E58_my\n" // also tried "LDR R1, =0xFF815E58"// It gets here" MOV R0, SP\n"" MOV R2, #0\n"" BL sub_FF813404\n" // was FF812D68// It doesn't get here" ADD SP, SP, #0x74\n"" LDR PC, [SP],#4\n" );}void __attribute__((naked,noinline)) sub_FF815E58_my() { asm volatile ( // It doesn't get here" ..."" B taskcreate_Startup_my\n" // FF81FAF0 );}
Ah OK that makes sense, I sort of overlooked it because it has a comment saying:// this is a carryover from old dryos ports, may not be useful
Also, I think the loops in the loader also ran at the faster speed, but maybe the caches were enabled there and somehow get disabled again before boot.c.
Code: [Select] *(int*)0x1934=(int)taskCreateHook; *(int*)0x1938=(int)taskCreateHook2; //VERIFY_SD780
*(int*)0x1934=(int)taskCreateHook; *(int*)0x1938=(int)taskCreateHook2; //VERIFY_SD780
" BL sub_FF813404\n" // was FF812D68// It doesn't get here" ADD SP, SP, #0x74\n"" LDR PC, [SP],#4\n"It is the call to sub_FF813404 that fails. It seems to take a function pointer as an argument, I tried passing in the original function from the firmware instead of the new one from boot.c, but it doesn't make any difference - the call never returns, and the function pointer passed in is never called.
" BL sub_FF813404\n" // was FF812D68
This bit of ASM code needs to be correct for your camera as well, BTW.QuoteCode: [Select] *(int*)0x1934=(int)taskCreateHook; *(int*)0x1938=(int)taskCreateHook2; //VERIFY_SD780
Are you doing anything in these hooks ? If so, try commenting those out.
Quote" BL sub_FF813404\n" // was FF812D68// It doesn't get here" ADD SP, SP, #0x74\n"" LDR PC, [SP],#4\n"It is the call to sub_FF813404 that fails. It seems to take a function pointer as an argument, I tried passing in the original function from the firmware instead of the new one from boot.c, but it doesn't make any difference - the call never returns, and the function pointer passed in is never called.I don't think this function would ever be expected to return, look at what would happen if it did... Unfortunately, this doesn't help you narrow down the problem much.
Have you checked the ROMLOG ? See http://chdk.wikia.com/wiki/Canon_Basic#RomLog for a script to dump it. If the camera is hitting an exception or assert, this may give you a clue.
I also noticedCode: [Select]" BL sub_FF813404\n" // was FF812D68If you are going through and "correcting" code from another camera, chances are you've missed an address or code difference somewhere. For the ASM, I'd really suggest starting from scratch.
"bcc sub_FF81013C\n" "ldr r1, =0x14fe20\n" "mov r2, #0\n"// ; 0x0 "cmp r3, r1\n" "strcc r2, [r3], #4\n" "bcc sub_FF810154\n" "b sub_FF810354\n"
EDIT: I just realised that it would return right to the end of the previous function and run off the end. (Does this mean that those last two instructions are not needed, and the BL could just be a B?)
Now I'm trying to start copying the code from the fw dump, but I'm having a bit of trouble since the syntax of my dump is not quite the same as the assembler expects.
I get undefined reference errors to sub_FF81013C and sub_FF810154, but not to sub_FF810354. Do I have to define them somewhere? If so, presumably the third is already defined there, but I can't find it anywhere.
also tried using constants instead (e.g. bcc 0xFF810154), which compiled but generated the wrong addresses in the dump
QuoteNow I'm trying to start copying the code from the fw dump, but I'm having a bit of trouble since the syntax of my dump is not quite the same as the assembler expects.You have to fix it. If you can look at tools/asmify.sh if you are using IDA
These should be automatically created by the build process, look at stubs_auto.S and how the makefile generates it. This is done with sed, so it can get confused...
Right, because B instructions take a signed 24 PC relative bit offset, and just overflow (in the assembler) if you use a larger number. What you want to do roll your own. For a function call it will look likeMOV LR, PCLDR PC, =0x...A straight B is just a LDR PC, =0x...
ff810114: e3a01001 mov r1, #1 ; 0x1ff810118: e59f205c ldr r2, [pc, #92] ; ff81017c: (c0243100) ff81011c: e5812000 str r2, [r1]
I'm using a disassembly generated with the GNU tools. I think I understand most of the differences now. If I have to do much more I might make an asmify script for this.
I don't need this now I've got the sub_xxxx method working, but it's good to know. The more I learn about ARM the more I like it, it's so much nicer than x86...
But how come the MOV instruction gets the right PC value? I would naively expect it to get the address of itself or the LDR instruction, necessitating something like LDR LR, PC, #4.
Code: [Select]ff810114: e3a01001 mov r1, #1 ; 0x1ff810118: e59f205c ldr r2, [pc, #92] ; ff81017c: (c0243100) ff81011c: e5812000 str r2, [r1]If I'm not mistaken, that is writing 0xc0243100 to address 1, which looks the wrong way around to me, since the address is misaligned, but maybe I'm missing something. If this is the problem it would indicate a corrupted dump, maybe I'll try dumping with another method and comparing. Or I can branch to the original in the middle, to narrow down exactly where the problem is coming from.
"cmp r1, r3\n" "ldrcc r2, [r0], #4\n" "strcc r2, [r1], #4\n" "bcc sub_FF81013C\n"
"loc_FF81013C:\n" "cmp r1, r3\n" "ldrcc r2, [r0], #4\n" "strcc r2, [r1], #4\n" "bcc loc_FF81013C\n"
The ARM documentation is pretty good. I suggest getting the ARM Architecture Reference Manual, you have to sign up at the ARM site to download it but it's free.Links can be found at http://chdk.wikia.com/wiki/Developer_Technical_Documents
QuoteBut... I see your problem, or a problem at leastCode: [Select] "cmp r1, r3\n" "ldrcc r2, [r0], #4\n" "strcc r2, [r1], #4\n" "bcc sub_FF81013C\n"This is B not a BL, so you need to use loc_... not sub. sub_ will send you off through stubs_entry.S and into ROM, where in fact you want to jump back a few instructions in a loop:Code: [Select]"loc_FF81013C:\n" "cmp r1, r3\n" "ldrcc r2, [r0], #4\n" "strcc r2, [r1], #4\n" "bcc loc_FF81013C\n"sub_* should only be used when you are jumping into the actual ROM, usually for a BL but also in a few cases where you simply want to continue in ROM without returning to your CHDK code in RAM. loc_* (or really any label you make up) refers to a label within your code.Yes I just noticed that too and fixed it, but it still doesn't work.By jumping to the original firmware form different points, I think I've found where it is failing, but I don't understand why:Code: [Select] "ldr r2, =0xc0242010\n" "ldr r1, [r2]\n" "orr r1, r1, #1\n"// ; 0x1 "str r1, [r2]\n" "B sub_ff810130\n" // works with this "ldr r0, =0xffbf837c\n" "B sub_ff810134\n" // fails with this "ldr r1, =0x1900\n" "ldr r3, =0xebd0\n""loc_FF81013C:\n" "cmp r1, r3\n" "ldrcc r2, [r0], #4\n" "strcc r2, [r1], #4\n" "bcc loc_FF81013C\n"The equivalent in the dump is:Code: [Select]ff810120: e59f2058 ldr r2, [pc, #88] ; ff810180: (c0242010) ff810124: e5921000 ldr r1, [r2]ff810128: e3811001 orr r1, r1, #1 ; 0x1ff81012c: e5821000 str r1, [r2]ff810130: e59f004c ldr r0, [pc, #76] ; ff810184: (ffbf837c) ff810134: e59f104c ldr r1, [pc, #76] ; ff810188: (00001900) ff810138: e59f304c ldr r3, [pc, #76] ; ff81018c: (0000ebd0) ff81013c: e1510003 cmp r1, r3ff810140: 34902004 ldrcc r2, [r0], #4ff810144: 34812004 strcc r2, [r1], #4ff810148: 3afffffb bcc ff81013c <_binary__dump_bin_start+0x13c>...ff810184: ffbf837c undefined instruction 0xffbf837cSo if it executes the "ldr r0, =0xffbf837c" from boot.c it fails, but if it executes it from the original fw it continues. How could it make any difference? Could it be a corrupted dump? Or something to do with endianness (I read that ARM can use either big or little endian)?
But... I see your problem, or a problem at leastCode: [Select] "cmp r1, r3\n" "ldrcc r2, [r0], #4\n" "strcc r2, [r1], #4\n" "bcc sub_FF81013C\n"This is B not a BL, so you need to use loc_... not sub. sub_ will send you off through stubs_entry.S and into ROM, where in fact you want to jump back a few instructions in a loop:Code: [Select]"loc_FF81013C:\n" "cmp r1, r3\n" "ldrcc r2, [r0], #4\n" "strcc r2, [r1], #4\n" "bcc loc_FF81013C\n"sub_* should only be used when you are jumping into the actual ROM, usually for a BL but also in a few cases where you simply want to continue in ROM without returning to your CHDK code in RAM. loc_* (or really any label you make up) refers to a label within your code.
"ldr r2, =0xc0242010\n" "ldr r1, [r2]\n" "orr r1, r1, #1\n"// ; 0x1 "str r1, [r2]\n" "B sub_ff810130\n" // works with this "ldr r0, =0xffbf837c\n" "B sub_ff810134\n" // fails with this "ldr r1, =0x1900\n" "ldr r3, =0xebd0\n""loc_FF81013C:\n" "cmp r1, r3\n" "ldrcc r2, [r0], #4\n" "strcc r2, [r1], #4\n" "bcc loc_FF81013C\n"
ff810120: e59f2058 ldr r2, [pc, #88] ; ff810180: (c0242010) ff810124: e5921000 ldr r1, [r2]ff810128: e3811001 orr r1, r1, #1 ; 0x1ff81012c: e5821000 str r1, [r2]ff810130: e59f004c ldr r0, [pc, #76] ; ff810184: (ffbf837c) ff810134: e59f104c ldr r1, [pc, #76] ; ff810188: (00001900) ff810138: e59f304c ldr r3, [pc, #76] ; ff81018c: (0000ebd0) ff81013c: e1510003 cmp r1, r3ff810140: 34902004 ldrcc r2, [r0], #4ff810144: 34812004 strcc r2, [r1], #4ff810148: 3afffffb bcc ff81013c <_binary__dump_bin_start+0x13c>...ff810184: ffbf837c undefined instruction 0xffbf837c
Started by HarpoMa « 1 2 ... 67 68 » General Discussion and Assistance
Started by AerialPhotos General Help and Assistance on using CHDK stable releases
Started by Eqric CHDK Releases
Started by waterwingz Firmware Dumping
Started by wb0urw Script Writing
