IXUS 130 (SD1400 IS) Porting Thread - page 5 - DryOS Development - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 29   Go Down

IXUS 130 (SD1400 IS) Porting Thread

  • 288 Replies
  • 77824 Views
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #40 on: 12 / October / 2010, 13:13:56 »
Advertisements
Quote from: emlyn on 12 / October / 2010, 10:24:35
...
I really don't understand how this can be happening
...
Well, this is becoming almost unbearable... Is your f/w 1.00c, with the dump 20100817-IXUS130-PRIMARY.BIN linked here?

If so, then the relevant disasm looks as follows:
Code: [Select]
FF81012C 00 10 82 E5                 STR     R1, [R2]        ; Store to Memory
FF810130 4C 00 9F E5                 LDR     R0, =0xFFBF8434 ; Load from Memory
FF810134 4C 10 9F E5                 LDR     R1, =0x1900     ; Load from Memory
FF810138 4C 30 9F E5                 LDR     R3, =0xEBD0     ; Load from Memory
FF81013C
FF81013C             loc_FF81013C                            ; CODE XREF: ROM:FF810148
FF81013C 03 00 51 E1                 CMP     R1, R3          ; Set cond. codes on Op1 - Op2
FF810140 04 20 90 34                 LDRCC   R2, [R0],#4     ; Load from Memory
FF810144 04 20 81 34                 STRCC   R2, [R1],#4     ; Store to Memory
FF810148 FB FF FF 3A                 BCC     loc_FF81013C    ; Branch
FF81014C 3C 10 9F E5                 LDR     R1, =0x14FE20   ; Load from Memory
FF810150 00 20 A0 E3                 MOV     R2, #0          ; Rd = Op2
FF810154
FF810154             loc_FF810154                            ; CODE XREF: ROM:FF81015C
FF810154 01 00 53 E1                 CMP     R3, R1          ; Set cond. codes on Op1 - Op2
FF810158 04 20 83 34                 STRCC   R2, [R3],#4     ; Store to Memory
FF81015C FC FF FF 3A                 BCC     loc_FF810154    ; Branch
FF810160 7B 00 00 EA                 B       loc_FF810354    ; Branch
Where do you find "ldr r0, =0xffbf837c"??
Logged
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #41 on: 12 / October / 2010, 17:49:26 »
Quote from: whoever on 12 / October / 2010, 13:13:56
Well, this is becoming almost unbearable... Is your f/w 1.00c, with the dump 20100817-IXUS130-PRIMARY.BIN linked here?
...
Where do you find "ldr r0, =0xffbf837c"??

Hmm this is interesting, that is the right dump, but what I have is:

Code: [Select]
ff81012c:       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, r3
ff810140:       34902004        ldrcc   r2, [r0], #4
ff810144:       34812004        strcc   r2, [r1], #4
ff810148:       3afffffb        bcc     ff81013c
ff81014c:       e59f103c        ldr     r1, [pc, #60]   ; ff810190: (0014fe20)
ff810150:       e3a02000        mov     r2, #0  ; 0x0
ff810154:       e1530001        cmp     r3, r1
ff810158:       34832004        strcc   r2, [r3], #4
ff81015c:       3afffffc        bcc     ff810154
ff810160:       ea00007b        b       ff810354

I've now downloaded the dump again and regenerated the disassembly: it seems somehow I had the wrong dump file. I don't know how that happened, but it explains everything! Thanks for the help.

I'm relieved that problem seems to be solved at last. Hopefully with the correct file things will start going a bit better :-)

EDIT: boot() now works properly, I am going through the rest of boot.c now.

EDIT2: boot.c is getting closer, the spytask crashes, but that's expected as I haven't yet done much with the stubs_entry files (and what I had done was from the wrong dump file...), so the next task is looking up function addresses.
« Last Edit: 14 / October / 2010, 06:31:59 by emlyn »
Logged
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #42 on: 18 / October / 2010, 08:27:21 »
I have now found most of the addresses for the stubs_* files, but the spytask is still crashing (in fact it doesn't really crash, it just switches the camera off).

It happens in core_spytask() -> conf_restore() -> conf_load_defaults() -> conf_change_script_file() -> script_load(conf.script_file, 2):
Code: [Select]
void script_load(const char *fn, int saved_params) {
    ...
    if (state_ubasic_script && state_ubasic_script != ubasic_script_default) {
      free(state_ubasic_script); // <--- this crashes
    }

    state_ubasic_script = ubasic_script_default;
    update_vars = (strcmp(fn, conf.script_file) != 0) || !saved_params || (saved_params == 2);  // update if new file
    if (!fn[0]) { // load internal script
        if (!conf.script_file[0]) { // internal script was used last time
            fd = fopen(SCRIPT_DEFAULT_FILENAME, "rb");
            if (fd) {
                fn = SCRIPT_DEFAULT_FILENAME;
                update_vars = 1;
            }
        }
    } else {
        fd = fopen(fn, "rb"); // <--- this crashes
        return;//***
        if (!fd) {
            conf.script_file[0]=0;
            update_vars = 1;
        }
    }
The call to free (marked with <---) crashes, even though state_ubasic_script should be initialized to NULL, so it shouldn't get called. I checked the addresses for any functions containing 'free' or 'alloc' in the name but couldn't find any obvious errors, so I commented out this line temporarily.
Then the fopen (also marked with <---) crashed, even though that branch of the 'if' should not execute, as fn (=conf.script_file) should be initialised to an empty string.
I wanted to blink out the values of these variables, but the LEDs are not working from within the spytask (I found the crash points by returning early from the function and seeing if the camera crashed). It seems that immediately after msleep is called, the LEDs no longer work:

Code: [Select]
void core_spytask()
{
    int cnt = 1;
    int i=0;

    raw_need_postprocess = 0;

    spytask_can_start=0;

    led_flash(LED_RED, 1); // <--- flashes
    while((i++<400) && !spytask_can_start) msleep(10);
    led_flash(LED_RED, 2); // <--- does not flash

    started();
    msleep(50);
    finished();
    drv_self_unhide();
    ...

The led_flash function takes an LED address and a number, and flashes the LED that number of times, and the LED should also be switched on by started() and off by finished(). I see just one flash (or none if I comment out the first led_flash call), but the execution does continue as I can prevent it crashing by returning early.

I will continue trying to work out what's going on, but if anyone has any ideas I would be happy to hear them.

EDIT: I should add that msleep just calls SleepTask, and I have verified that SleepTask has the correct address.
« Last Edit: 18 / October / 2010, 09:49:15 by emlyn »
Logged
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #43 on: 22 / October / 2010, 10:25:08 »
Just a quick status update:

I still don't understand why the LED is not working in the spytask after the msleep call, but I'll leave that for later.

The problem with the local variables having the wrong value, I thought must be caused by something like stack corruption in a previous function call. So I checked all my function addresses, and fixed a few that were wrong, but it didn't help.
Then I found in conf.c, the lines:
Code: [Select]
   CONF_INFO( 38, conf.reader_file,            CONF_DEF_PTR,   ptr:"A/README.TXT", conf_change_script_file),
...
    CONF_INFO(194, conf.script_file,            CONF_DEF_PTR,   ptr:"", conf_change_script_file),

Where conf_change_script_file is:
Code: [Select]
static void conf_change_script_file() {
  script_load(conf.script_file, 2);
}

I think the first reference to conf_change_script_file is a bug, as it accesses conf.script_file before it has been set by the second one, causing undefined behaviour.
I replaced it with NULL, and now it is crashing in rbf_load_from_8x16 (pasted below for reference), in the first for loop. I commented out the call to free, and then it no longer crashes, but I don't understand why, as I think need_free should be 0 here, so the free shouldn't be called anyway...
Code: [Select]
void rbf_load_from_8x16(unsigned char font[256][16]) {
    int i, c, b;

    rbf_font.charSize  = 16;
    rbf_font.height    = 16;
    rbf_font.maxWidth  = 8;
    rbf_font.charFirst = 0;
    rbf_font.charLast  = 255;

    rbf_font.width = 8 * rbf_font.charSize / rbf_font.height;
    rbf_font.charCount = rbf_font.charLast - rbf_font.charFirst + 1;

    for (i=0; i<256; ++i) {
        rbf_font.wTable[i]=8;
        if (need_free && rbf_font.cTable[i]) {
          free(rbf_font.cTable[i]); // <--- here
        }
        rbf_font.cTable[i]=NULL;
    }
    need_free = 0;
    return; // early return for debugging
    for (i=0; i<256; ++i) {
        rbf_assign_char_8x16(&rbf_font.cTable[i], (char*)font[i], rbf_font.height);
    }
    need_free = 1;
}
« Last Edit: 22 / October / 2010, 10:39:42 by emlyn »
Logged
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #44 on: 24 / October / 2010, 07:32:59 »
I've dumped the romlog, and this is what gets logged when it crashes:

Code: [Select]
Exception!! Vector 0x10
Occured Time  2010:10:24 11:28:59
Task ID: 1441797
Task name:             0
Exc Registers:
0x00000000
0x00000000
0x0000000B
0x0C000046
0x1B2C4610
0x0000F504
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x0033D0A0
0x0033D0A4
0x0033D084
0xFF812CC8
0xFF814178
0x60000013
StackDump:
0x00000000
0x0018AF98
0x19980218
0x001625C4
0x19980218
0x0033D0A4
0x0016913F
0x001625C4
0x00000514
0x000000AA
0x00158317
0x00158499
0x001886F4
0x00000191
0x00158559
0x02FAF080
0x001886F4
0x00161DEC
0x19980218
0x0033D0DC
0x0014FF63
0x0014FF71
0x00332708
0x19980218
0xFF816AEC
0x19980218
0x19980218
0x00000208
00000410: *** Camera Log Start ***
00000470: UI:LogicalEvent:0x5001:adr:0,Para:0
00000500: SS:S-Imag
00000500: UI:ScreenLock
00000500: UI:ScreenUnLock
00000500: UI:LogicalEvent:0x300a:adr:0,Para:0
00000510: UI:HDMIConnectCnt
00000510: UI:PB.Create
00000510: UI:DispSwCon_TurnOnBackLight
00000510: UI:TurnOnBackLight
00000600: UI:LogicalEvent:0x5006:adr:0,Para:0
00000680: UI:LogicalEvent:0x112c:adr:0,Para:0
00000700: UI:ScreenLock
00000700: UI:ScreenUnLock
00000720: UI:PB.CreateE
00000720: UI:AC:StartPB
00000720: UI:DispSwCon_TurnOnDisplayDevice
00000720: UI:AC:EBtn
00000720: UI:PB.Start
00000720: UI:DSIC:47,0
00000720: UI:LogicalEvent:0x3209:adr:0x1,Para:1
00000720: UI:CC_CompFlhJpg
00000730: UI:_CompFlhJpg
00000730: UI:PB.Flash
00000730: UI:ScreenLock
00000730: UI:DSIC:47,0
00000730: UI:ScreenUnLock
00000730: UI:ScreenLock
00000730: UI:DSIC:47,0
00000730: UI:DispSwCon_MuteOffPhysicalScreen
00000730: UI:MuteOffPhysicalScreen
00000740: UI:LogicalEvent:0x3138:adr:0,Para:0
00001090: UI:PB.DrawI
00001090: UI:LogicalEvent:0x320a:adr:0,Para:0
00001110: UI:PB.StartE
00001120: UI:PB.TOTAL
00001120: UI:PB.DPOF
00001310: UI:LogicalEvent:0x3203:adr:0,Para:0
00001310: UI:PB.IHist
00001310: UI:PB.DcdCBR
00001320: UI:PB.RfrsI
00001340: UI:ScreenUnLock
00001340: UI:LogicalEvent:0x3201:adr:0,Para:0
00001340: UI:DispSw: Unlock
00001340: UI:DispSwCon:Unlock
00001340: UI:DispSwCon_TurnOnBackLight
00001340: UI:DispSwCon_MuteOffPhysicalScreen
00001340: UI:MuteOffPhysicalScreen
00001340: UI:AC:EnryPB
00001340: UI:AP:ChkCnctUSB
00001400: UI:LogicalEvent:0x321f:adr:0,Para:0
00001400: UI:PB.CTG
00001400: UI:DSIC:48,0
00003330: UI:ScreenLock
00003330: UI:ScreenUnLock

I'm not sure what the "Exception!! Vector 0x10" means. I assume the 17 values after "Exc Registers" are r0-r15 and maybe the CPSR, in which case the penultimate one is the PC, and the address 0xFF814178 is in the "free" function:
Code: [Select]
loc_ff81415c: ; 14 refs
ff81415c: e92d4070 push {r4, r5, r6, lr}
ff814160: e1b04000 movs r4, r0
ff814164: 08bd8070 popeq {r4, r5, r6, pc}
ff814168: e3a01000 mov r1, #0 ; 0x0
ff81416c: e59f5020 ldr r5, [pc, #32] ; ff814194: (0000f504)
ff814170: e5950024 ldr r0, [r5, #36]
ff814174: ebfffabb bl loc_ff812c68
ff814178: e5140008 ldr r0, [r4, #-8]
ff81417c: e5901000 ldr r1, [r0]
ff814180: e2850000 add r0, r5, #0 ; 0x0
ff814184: eb001378 bl loc_ff818f6c
ff814188: e5950024 ldr r0, [r5, #36]
ff81418c: e8bd4070 pop {r4, r5, r6, lr}
ff814190: eafffaa7 b loc_ff812c34
ff814194: 0000f504 andeq pc, r0, r4, lsl #10

I'm reasonably sure I have the right address for free, it is found by finsig with a 91% match, and comparing with the ixus300 and the sx210is it is virtually identical, and to the ixus95 it is a bit different but looks functionally very similar.

The previous register would then be the LR (0xFF812CC8), which points into the following function:
Code: [Select]
loc_ff812c68: ; 113 refs
ff812c68: e92d4070 push {r4, r5, r6, lr}
ff812c6c: e1a05001 mov r5, r1
ff812c70: e59f1774 ldr r1, [pc, #1908] ; ff8133ec: (00001964)
ff812c74: e5911000 ldr r1, [r1]
ff812c78: e3510000 cmp r1, #0 ; 0x0
ff812c7c: 0a000008 beq loc_ff812ca4
ff812c80: e3550000 cmp r5, #0 ; 0x0
ff812c84: 0a000004 beq loc_ff812c9c
ff812c88: e5951000 ldr r1, [r5]
ff812c8c: e3510000 cmp r1, #0 ; 0x0
ff812c90: 05951004 ldreq r1, [r5, #4]
ff812c94: 03510000 cmpeq r1, #0 ; 0x0
ff812c98: 0a000001 beq loc_ff812ca4
loc_ff812c9c: ; 2 refs
ff812c9c: e3e00000 mvn r0, #0 ; 0x0
ff812ca0: e8bd8070 pop {r4, r5, r6, pc}
loc_ff812ca4: ; 2 refs
ff812ca4: e10f4000 mrs r4, CPSR
ff812ca8: e3841080 orr r1, r4, #128 ; 0x80
ff812cac: e121f001 msr CPSR_c, r1
ff812cb0: eb001095 bl loc_ff816f0c
ff812cb4: e3500000 cmp r0, #0 ; 0x0
ff812cb8: 0121f004 msreq CPSR_c, r4
ff812cbc: 0afffff6 beq loc_ff812c9c
ff812cc0: e1a01005 mov r1, r5
ff812cc4: eb001119 bl loc_ff817130
ff812cc8: e121f004 msr CPSR_c, r4
ff812ccc: e8bd8070 pop {r4, r5, r6, pc}

But I haven't worked out what it does (other than I think disabling and reenabling interrupts in the second part).

Is there more information I can extract from the log? What does the part after "*** Camera Log Start ***" mean?
Logged
*

Online reyalp

  • ******
  • 12111
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #45 on: 24 / October / 2010, 14:53:56 »
If it's in free, it could be freeing garbage.

Exception vector 0x10 is Data Abort, which probably means trying to access a nonsense address (not configured to be readable/writable in the MPU setup, meaning not in the regions set aside for RAM, MMIO or ROM) See "ARM Architecture Reference Manual"

It looks r4 is 0x1B2C4610 so that instruction would be trying to load 0x1B2C4610-8 which looks like an invalid address to me. If you can figure out where that value comes from, it might give you a hint.

Camera log is recent camera activity. Note that it's in chronological order from top to bottom (the numbers are timestamps)

The stack dump may also give you some clues.
Logged
Don't forget what the H stands for.
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #46 on: 24 / October / 2010, 16:25:18 »
Quote from: reyalp on 24 / October / 2010, 14:53:56
If it's in free, it could be freeing garbage.

Exception vector 0x10 is Data Abort, which probably means trying to access a nonsense address (not configured to be readable/writable in the MPU setup, meaning not in the regions set aside for RAM, MMIO or ROM) See "ARM Architecture Reference Manual"

It looks r4 is 0x1B2C4610 so that instruction would be trying to load 0x1B2C4610-8 which looks like an invalid address to me. If you can figure out where that value comes from, it might give you a hint.

Thanks for the hints. There seems to be some sort of memory corruption happening, earlier I was also seeing execution take the "wrong" branch in some conditionals. Maybe it could also explain why the LEDs seem to stop working, but at that point I think the only Canon functions that have been called are CreateTask and SleepTask, and I am pretty sure I have the right addresses for them.
I don't know what all the parameters to CreateTask mean, I just copied them from another camera:
Code: [Select]
_CreateTask("SpyTask", 0x19, 0x2000, core_spytask, 0);
Could any of them cause a problem?
I have also disabled as much code as possible in boot.c to try and track down the problem, so I currently don't load the task hook, and just kept what was needed to start the spytask. It didn't look like any of that was needed to at least get the spytask running without crashing, but maybe I'm wrong?
Logged
*

Online reyalp

  • ******
  • 12111
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #47 on: 24 / October / 2010, 16:37:56 »
Quote from: emlyn on 24 / October / 2010, 16:25:18
Thanks for the hints. There seems to be some sort of memory corruption happening, earlier I was also seeing execution take the "wrong" branch in some conditionals. Maybe it could also explain why the LEDs seem to stop working, but at that point I think the only Canon functions that have been called are CreateTask and SleepTask, and I am pretty sure I have the right addresses for them.
I don't know what all the parameters to CreateTask mean, I just copied them from another camera:
Code: [Select]
_CreateTask("SpyTask", 0x19, 0x2000, core_spytask, 0);
Could any of them cause a problem?
I have also disabled as much code as possible in boot.c to try and track down the problem, so I currently don't load the task hook, and just kept what was needed to start the spytask. It didn't look like any of that was needed to at least get the spytask running without crashing, but maybe I'm wrong?
This shouldn't vary between cameras of the same OS. If they did change in some revision of dryos, you'd be able to see it in the creation of canon tasks. The arguments are something like name, priority, stack size, entry point, not sure what the zero is.

If you somehow didn't get the CHDK bss initialized (platform/<camera>/main.c startup) that would make your globals not actually start zeroed, which would be a problem. Hard to see why you would do that though. It could also happen if you got the size/address wrong, but again I don't see why that would happen unless you've done something very weird.

If you got CHDK loading addresses wrong, or didn't put new_sa in the right place you might get issues like this.

Your camera should be very similar to cameras of the same generation (dryos R43), and most of this stuff is the same on older dryos cameras as well. You shouldn't have to do anything special, or change any core code, just make it do what they do.
Logged
Don't forget what the H stands for.
*

Offline emlyn

  • **
  • 88
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #48 on: 24 / October / 2010, 17:30:22 »
Quote from: reyalp on 24 / October / 2010, 16:37:56
If you somehow didn't get the CHDK bss initialized (platform/<camera>/main.c startup) that would make your globals not actually start zeroed, which would be a problem. Hard to see why you would do that though. It could also happen if you got the size/address wrong, but again I don't see why that would happen unless you've done something very weird.

If you got CHDK loading addresses wrong, or didn't put new_sa in the right place you might get issues like this.

Your camera should be very similar to cameras of the same generation (dryos R43), and most of this stuff is the same on older dryos cameras as well. You shouldn't have to do anything special, or change any core code, just make it do what they do.

Oops, the CHDK bss initialization was commented out, but unfortunately putting it back in didn't change anything. I think I need to go through all the code from the beginning, comparing with another camera of the same generation, there must be something else I've missed.
Logged
*

Online reyalp

  • ******
  • 12111
Re: IXUS 130 (SD1400 IS) Porting Thread
« Reply #49 on: 24 / October / 2010, 18:51:07 »
Note that if you've booted with things broken, you can get a corrupted CCHDK.CFG, which will then cause you to crash all on it's own.

Leaving out the bss initialization will break *lots* of stuff, in ways that match at least some of your symptoms.

It is probably a good idea to step back and go through all the stuff you might have changed while debugging this.
Logged
Don't forget what the H stands for.
Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 29   Go Up
« previous next »
 

Related Topics