SX60HS Porting - page 12 - DryOS Development - CHDK Forum
« previous next »
Pages: 1 ... 7 8 9 10 11 [12] 13 14 15 16 17 ... 92   Go Down

SX60HS Porting

  • 915 Replies
  • 372139 Views
*

Offline reyalp

  • ******
  • 14118
Re: SX60HS Porting
« Reply #110 on: 25 / March / 2016, 21:13:09 »
Advertisements
Quote from: 62ndidiot on 25 / March / 2016, 18:50:02
and the disassembly supports sigfinder...I probably had a copy of stubs_min which I should have deleted. I should re-run sigfinder, i just worry it will wipe something and surprise me.
You can comment out the ones you have in your stubs_min

You should not make any changes to stubs_entry.S. The sig finder won't overwrite any of the other sources files (it will overwrite the csv files and physw_bits.txt but you really shouldn't have any reason to change those)

Quote
I am not terribly familiar with SVN...the code management system I use in my work is very very different, I need to gain comfort with it, I will try updating as you say. Hopefully it will not overwrite any local changes in config (like capstone)...first i will back up  :) I definitely hope finsig gets better and better.
Normally, svn won't overwrite you changes when you update. If there are conflicting changes, you might have to do something manually to resolve it. Build configuration (capstone paths etc) should be in localbuildconf.inc, which isn't under version control at all.

All that said, backups are always a Good Thing.

The svn book is available online http://svnbook.red-bean.com/

Quote
Will it be possible to do this purely in perl without capstone in the future I wonder?
In theory I suppose, but I would not want to try to implement something like that in perl.

Quote
reyalp, my first attempt at uart redirect...I output the value of the  active_bitmap_buffer variable in lib.c.  tagged with "lc ai:"  It alternates from 0,1.
I believe VTMLock/VTMUnLock have something to do with canon screen refresh, so that looks promising.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #111 on: 26 / March / 2016, 22:51:40 »
Svn Updated.  Finsig finds a few more, but addresses were already correct.
If I use the displaytype variable to update screen dimensions in Lib.c it is probably wrong: changes -1,0,1 only.  Commented out for now.
Trying to choose where is best to log key presses.
Play button second short press after boot causes reboot.  Play button second short press after half press of shoot enters alt mode. 
File browse crashes camera after bringing up list of files.
Lots to figure out.
Minor detail, how is opening and closing of the foldaway LCD usually treated ? Not that it matters at this stage. :)
Logged
*

Offline reyalp

  • ******
  • 14118
Re: SX60HS Porting
« Reply #112 on: 27 / March / 2016, 00:27:13 »
Quote from: 62ndidiot on 26 / March / 2016, 22:51:40
Trying to choose where is best to log key presses.
What are you trying to log? somewhere in kbd_task would be the obvious place, but you probably don't want to log every iteration. You could log changes pretty easily.
Quote
Play button second short press after boot causes reboot.  Play button second short press after half press of shoot enters alt mode. 
This is very weird. I thought had it mostly working before, if so maybe going back to older code or commenting out recent additions would be helpful.

Incorrect physw_status manipulation or bad assembly code would be my first suspects, but that's just a guess.
Quote
File browse crashes camera after bringing up list of files.
If this crash generates a romlog that might be helpful.

Quote
Minor detail, how is opening and closing of the foldaway LCD usually treated ?
I'm not sure what you mean. There is a CAM_SWIVEL_SCREEN define you can grep for. Also watch out for flashlight mode http://chdk.wikia.com/wiki/CHDK_User_Manual#Flashlight
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #113 on: 28 / March / 2016, 16:20:33 »
I will post the rom log from the crash.
I can do several, perhaps a tutorial on how best to go about it could be developed by doing a few examples. You would need mainbindump as well. I could put romcode.dis and ram code.dis on a google drive.  Of course ram code changes each time I build.
I checked all the keys and their codes. Fixed an error in key mask.

Quick question: whenever I connect usb via linux I do not mount the camera's  file system and chdkptp works fine (I think) however the screen goes black and stays black on the camera.  Is that expected? The linux usb layer always registers that the device is present and soon as I plug the usb cable in.  I'm not sure I can prevent that.
Logged
*

Offline reyalp

  • ******
  • 14118
Re: SX60HS Porting
« Reply #114 on: 28 / March / 2016, 16:57:52 »
Quote from: 62ndidiot on 28 / March / 2016, 16:20:33
I will post the rom log from the crash.

I can do several, perhaps a tutorial on how best to go about it could be developed by doing a few examples. You would need mainbindump as well.
I can take a look at them and try to explain what I find, but whether a romlog is useful depends on the particular crash. Aside from main.bin.dump, the .elf files the modules are built from (in the modules/.o2 directory) may be needed if the crash is in a module. To debug module crashes, you also need module logging enabled to know what address the module was loaded at.

Quote
I could put romcode.dis and ram code.dis on a google drive.  Of course ram code changes each time I build.
Anyone with the dump can generate the same disassembly.
If you mean the ramcode.dis created with capdis, this doesn't change (except function names if your function list csv or stubs are updated)

Quote
Quick question: whenever I connect usb via linux I do not mount the camera's  file system and chdkptp works fine (I think) however the screen goes black and stays black on the camera.  Is that expected? The linux usb layer always registers that the device is present and soon as I plug the usb cable in.  I'm not sure I can prevent that.
This is a common problem on linux. It will probably prevent you from switching to shooting mode. It usually happens because some automated udev action accesses the camera. You should be able to prevent it with some modification to udev.rules and/or hwdb, but the details are distro specific and poorly documented. See the "interactions with default software" section on https://www.assembla.com/spaces/chdkptp/wiki/Install and forum threads linked from there
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #115 on: 28 / March / 2016, 18:46:20 »
Here's the log from a crash that occurs when invoking the filebrowser on the camera, it brings up a list of files nicely, and then after a few seconds crashes
Code: [Select]
ASSERT!! DriveLetterManager.c Line 105
Occured Time  2016:03:28 14:38:04
Task ID: 17629225
Task name: SpyTask
SP: 0x00644EFC
StackDump:
0x00000000
0x00000000
0xFC336E88
0x00000069
0x00000000
0x00000000
0x003BFA3C
0x003BA487
0x000001EA
0x00000000
0x00000008
0x0000000B
0xFC336D15
0x00000000
0xFC332777
0x00000000
0x01A09F20
0x003BFA3C
0xFC06910F
0x005782B0
0x01A09F20
0x003BFA3C
0x003BA449
0x005782B0
0x00577905
0x00000004
0x0000015C
0x00000010
0x3A626261
0x00644F78
0x00007F3F
0x696D0041
0x2E6F666E
0x20747874
0x20202020
0x20202020
0x33202006
0x066B372E
0x302E3530
0x36312733
0x3A303020
0x00003633
0x00000000
0x00000000
0x00000001
0x003C57AC
0x003C5724
0x0000061C
0x0000061D
0x19980218
0x19980218
0x19980218
0x003AC55D
0x00000000
0x003C26E8
0x003C68A4
0x003A9DE3
0x00000000
0x003A8D89
0x006230A4
0x0000803C
0x19980218
0x19980218
0x19980218
0x010E1F35
0x19980218
0x19980218
0x19980218
0x19980218
0x00000808
ShootConDump:
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
CameraConDump:
07 0a 02 0f 0f 0f 0f 0f 0f 0f
00023910: UI:DSIC:21,6557600
00023930: UI:Button:0x0000085D:UnpressSetButton
00023930: UI:VTMLock
00023930: UI:VTMUnLock
00024130: UI:LogicalEvent:0x0000301d:adr:0x1,Para:1
00024130: UI:DSIC:21,6557600
00024240: UI:LogicalEvent:0x0000301d:adr:0x2,Para:2
00024240: UI:DSIC:21,6557600
00024350: UI:LogicalEvent:0x0000301d:adr:0x1,Para:1
00024350: UI:DSIC:21,6557600
00024460: UI:LogicalEvent:0x0000301d:adr:0x2,Para:2
00024460: UI:DSIC:21,6557600
00024670: UI:LogicalEvent:0x0000301d:adr:0x1,Para:1
00024670: UI:DSIC:21,6557600
00024780: UI:LogicalEvent:0x0000301d:adr:0x2,Para:2
00024780: UI:DSIC:21,6557600
00025000: UI:LogicalEvent:0x0000301d:adr:0x1,Para:1
00025000: UI:DSIC:21,6557600
00025110: UI:LogicalEvent:0x0000301d:adr:0x2,Para:2
00025110: UI:DSIC:21,6557600
00026210: UI:LogicalEvent:0x0000301d:adr:0x3,Para:3
00026210: UI:DSIC:21,6557600
00028830: UI:LogicalEvent:0x0000301d:adr:0x2,Para:2
00028830: UI:DSIC:21,6557600
00028940: UI:LogicalEvent:0x0000301d:adr:0x3,Para:3
00028940: UI:DSIC:21,6557600
00029110: UI:LogicalEvent:0x0000301d:adr:0x2,Para:2
00029110: UI:DSIC:21,6557600
00030230: UI:LogicalEvent:0x0000301d:adr:0x3,Para:3
00030230: UI:DSIC:21,6557600
00030340: UI:LogicalEvent:0x0000301d:adr:0x2,Para:2
00030340: UI:DSIC:21,6557600
00030470: UI:LogicalEvent:0x0000301d:adr:0x3,Para:3
00030470: UI:DSIC:21,6557600
00030990: UI:LogicalEvent:0x0000301d:adr:0x2,Para:2
00030990: UI:DSIC:21,6557600
00031190: UI:LogicalEvent:0x0000301d:adr:0x3,Para:3
00031190: UI:DSIC:21,6557600
00031300: UI:LogicalEvent:0x0000301d:adr:0x2,Para:2
00031300: UI:DSIC:21,6557600
00033450: kc3: ps0:10077dff  ps1:20c08030 ps2:10000000
00033460: kc: kbs0:10077dff  kbs1:20c08030 kbs2:00000005
00033460: kc3: ps0:10077dff  ps1:20c08030 ps2:10000000
00033460: UI:VTMLock
00033460: UI:VTMUnLock
00033470: kc: kbs0:10077dff  kbs1:20c08030 kbs2:00000005
00033470: kc3: ps0:10077dff  ps1:20c08030 ps2:10000000
00033470: UI:Button:0x0000085C:PressSetButton
00033480: kc: kbs0:10077dff  kbs1:20c08030 kbs2:00000005
00033480: kc3: ps0:10077dff  ps1:20c08030 ps2:10000200
00033490: kc: kbs0:10077dff  kbs1:20c08030 kbs2:00000005
00033490: kc3: ps0:10077dff  ps1:20c08030 ps2:10000200
00033500: kc: kbs0:10077dff  kbs1:20c08030 kbs2:00000005
00033500: kc3: ps0:10077dff  ps1:20c08030 ps2:10000200
00033510: kc: kbs0:10077dff  kbs1:20c08030 kbs2:00000005
00033510: kc3: ps0:10077dff  ps1:20c08030 ps2:10000200
00033510: lc  abb:0
00033520: kc: kbs0:10077dff  kbs1:20c08030 kbs2:00000005
00033520: kc3: ps0:10077dff  ps1:20c08030 ps2:10000200
00033530: kc: kbs0:10077dff  kbs1:20c08030 kbs2:00000005
00033530: kc3: ps0:10077dff  ps1:20c08030 ps2:10000200
00033540: kc: kbs0:10077dff  kbs1:20c08030 kbs2:00000005
00033540: kc3: ps0:10077dff  ps1:20c08030 ps2:10000200
00033550: kc: kbs0:10077dff  kbs1:20c08030 kbs2:00000005
00033550: kc3: ps0:10077dff  ps1:20c08030 ps2:10000200
   
afry@ubuntustudio:~/chdk$
Logged
*

Offline reyalp

  • ******
  • 14118
Re: SX60HS Porting
« Reply #116 on: 29 / March / 2016, 02:36:38 »
Quote from: 62ndidiot on 28 / March / 2016, 18:46:20
Here's the log from a crash that occurs when invoking the filebrowser on the camera, it brings up a list of files nicely, and then after a few seconds crashes
Basics: This is an assert in Canon code (their DriveLetterManager.c Line 105) from a call in CHDK code (SpyTask)

Since it's an assert, we only get a stack trace and camera log output, not registers.

We could find the relevant part of the canon code by searching for the string until we find the corresponding DebugAssert call. However, it will be near the top of the stack trace too.

On the stack, return addresses will point after the call and if the code was thumb (almost always true on digic 6) will have the thumb bit set.

Your main.bin.dump has a start address of 0x3a8bb0, and a data address of 0x3baca8, so we know anything in between is probably CHDK core code. Values a bit higher will be CHDK core data.

The first thing that looks like a ROM code address (thumb bit set) is 0xfc336d15. Searching romcode.dis gives us

Code: [Select]
fc336d0a: 2269      movs r2, #0x69
fc336d0c: 2000      movs r0, #0
fc336d0e: a15e      add r1, pc, #376 ; 0xfc336e88: (76697244) *"DriveLetterManager.c"
fc336d10: f798 eb7a blx sub_fc2cf408 ; j_DebugAssert
fc336d14: 2000      movs r0, #0
It's not immediately obvious to me what this function does or what the assert is checking, so I check the next thing that looks like a return address: fc332776
Code: [Select]
loc_fc33276c:
fc33276c: b570      push {r4, r5, r6, lr}
fc33276e: 4605      mov r5, r0
fc332770: 7800      ldrb r0, [r0]
fc332772: f004 fab5 bl sub_fc336ce0
fc332776: 4604      mov r4, r0
fc336ce0 is the function with the assert.

Moving on
Code: [Select]
loc_fc069106:
fc069106: b570      push {r4, r5, r6, lr}
fc069108: 4604      mov r4, r0
fc06910a: f2c9 fb2f bl sub_fc33276c
fc06910e: 0006      movs r6, r0
The next thing that looks like code on the stack is a CHDK address 0x003ba449

Code: [Select]
003ba440 <GetTotalCardSpaceKb>:
  3ba440: b510      push {r4, lr}
  3ba442: 2000      movs r0, #0
  3ba444: f7ef fb1c bl 3a9a80 <_GetDrive_TotalClusters>
  3ba448: 4604      mov r4, r0
In stubs_entry_2.S,
NHSTUB(GetDrive_TotalClusters               ,0xFC069107)

So, for whatever reason, the function we called GetDrive_TotalClusters crashed.
Some possible reasons:
1) This isn't actually GetDrive_TotalClusters, and expects to be called with some completely different arguments or under some different conditions
2) It is GetDrive_TotalClusters, but the number or meaning of the arguments has changed
3) We've trashed something somewhere else that made it fail
4) ... ???

#1 we can check by comparing to known good functions.
Code: [Select]
$ ./discam.sh g7x 100d -s=GetDrive_TotalClusters -c=13
; GetDrive_TotalClusters 0xfc357bd7
    push    {r4, lr}
    movs    r4, r0
    beq     loc_fc357bea
    movw    r2, #0xbca
    subw    r1, pc, #0x78c ;  *"Mounter.c"
    movs    r0, #0
    blx     sub_fc2ef9e4 ; j_DebugAssert
loc_fc357bea:
    ldr     r1, =0x0003d908
    add.w   r0, r4, r4, lsl #4
    adds    r1, #0x80
    add.w   r0, r1, r0, lsl #2
    ldr     r0, [r0, #0x34]
    pop     {r4, pc}

Code: [Select]
$ ./discam.sh sx60hs 100f -s=GetDrive_TotalClusters -c=13
; GetDrive_TotalClusters 0xfc069107
    push    {r4, r5, r6, lr}
    mov     r4, r0
    bl      sub_fc33276c
    movs    r6, r0
    beq     loc_fc06911c
    movs    r2, #0xd5
    movs    r0, #0
    adr     r1, #0xe4 ;  *"AvailClusters.c"
    blx     sub_fc2cf408 ; j_DebugAssert
loc_fc06911c:
    movs    r5, #0
    b       loc_fc069128
    cmp     r1, #0x2f
    bne     loc_fc069126
This does not actually look very similar. Since both cameras are the same dryos version, it probably should be.

In G7x, GetDrive_TotalClusters is the function immediately before GetDrive_FreeClusters, and these are around fc35xxxx rather than fc069xxxx

On sx60hs, GetDrive_FreeClusters is at  fc33250e, so if it's similar to g7x, GetDrive_TotalClusters should be fc3324ea. Checking the disassembly:
Code: [Select]
$ ./discam.sh sx60hs 100f -s=0xfc3324eb -c=13
    push    {r4, lr}
    movs    r4, r0
    beq     loc_fc3324fe
    movw    r2, #0xbca
    subw    r1, pc, #0x78c ;  *"Mounter.c"
    movs    r0, #0
    blx     sub_fc2cf408 ; j_DebugAssert
loc_fc3324fe:
    ldr     r1, =0x0003a3c0
    add.w   r0, r4, r4, lsl #4
    adds    r1, #0x80
    add.w   r0, r1, r0, lsl #2
    ldr     r0, [r0, #0x34]
    pop     {r4, pc}
A perfect match for the g7x code, with only addresses differing.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #117 on: 29 / March / 2016, 20:53:56 »
Thank you reyalp! for the very clear and concise tutorial on how to track down a mistake/bug from an ASSERT dump. This will be very useful as I proceed. Yes the address was wrong from even before I used capdis (changing it fixed this problem). I wonder why the sigfinder did not find this code since it is so similar to the g7x? I should probably go thru stubs_entry_2.S and compare each entry to yours in g7x side by side.
Logged
*

Offline reyalp

  • ******
  • 14118
Re: SX60HS Porting
« Reply #118 on: 29 / March / 2016, 22:21:00 »
Quote from: 62ndidiot on 29 / March / 2016, 20:53:56
I wonder why the sigfinder did not find this code since it is so similar to the g7x?
Because I haven't added a rule for it. Currently, finsig_thumb2 work by finding a known reference point (a string, or an already known function) and trying to match some expected sequence of disassembly to find the desired function. Initial "known" functions come from scanning the whole firmware for eventproc registration and task creation.

GetDrive_TotalClusters isn't obviously referenced in the canon firmware, so the above strategy doesn't work. The sig finder doesn't currently have a way to specify "the function before known function X in ROM". This could be implemented but thumb2 variable instruction size makes it somewhat tricky and it's a pretty weak identification without comparing the code.
Quote
I should probably go thru stubs_entry_2.S and compare each entry to yours in g7x side by side.
For sigfinder development, I use a shell script that takes a function name and length and calls capdis with this as the -s= and -c= arguments for each firmware. You could do something similar with just two cameras  to quickly compare functions.

I have thought about ways to automate this kind of comparison, but haven't gotten to yet.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #119 on: 30 / March / 2016, 10:45:33 »
There's a small problem in the menu system that I suspect someone will immediately know the solution too or at least what to check.  When I bring up an information screen that only has an ok button, like say cpuinfo for example, the screen displays and then almost instantly disappears as if I already pressed the "ok" which I believe is the function/set center button. 

One additional question:
On the sx60 there are dual purpose buttons, like Display/Down. These appear to have independent defs in chdk, how should I define them?
Also several others that have special uses, which I'll detail separately later. 
Logged
Pages: 1 ... 7 8 9 10 11 [12] 13 14 15 16 17 ... 92   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal