SX60HS Porting - page 6 - DryOS Development - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 92   Go Down

SX60HS Porting

  • 915 Replies
  • 347892 Views
*

Offline reyalp

  • ******
  • 14079
Re: SX60HS Porting
« Reply #50 on: 19 / March / 2016, 18:22:50 »
Advertisements
Quote from: 62ndidiot on 19 / March / 2016, 18:06:42
Now able to boot to screen saying memory card locked, where it remains indefinitely.
If I uncomment CreateTask_spytask in task_Startup_my, it boots the same but after a few seconds crashes....romlog.txt attached (as well as current source snap)
Good progress!
Quote
I'm not completely sure I understand the UART redirect stuff.  I've created a file uart.req with the bytes in it....
You need to call the eventprocs to start UART redirection. You can see the lua module CHDK/LUALIB/GEN/uartr.lua for examples (or just use the Lua module, once you've got a bit further). But if you are crashing, you probably don't need this.

Quote
Exception!! Vector 0x10
Occured Time  2016:03:19 13:51:51
Task ID: 17629225
Task name: SpyTask
Exc Registers:
0x000328D9
0xFFFFFF40
0x000000FF
0xD5D5D5D5
0x000000FB
0x000000ED
0x000328CB
0x000001E0
0x0000009A
0x00000001
0x19980218
0x19980218
0x0001946C
0x00644F20
0x003AA117
0x003AA116
0x60000073
This is an invalid memory access in spytask, probably due to some function or address being wrong. The registers are (R0-R5, + status register) so
0x003AA116 is the PC where the exception occurred. In your case this looks like a CHDK code address, so you can look at platform/sx60/sub/100f/main.bin.dump to see what code is at that address.

To debug crashes, you can also use LogCameraEvent. Stuff logged with this will appear in the Camera Log section of the ROMLOG if it happens close to the crash. To call from thumb code, you need a wrapper, I suggest using _LogCameraEvent as the printf function in generic/wrappers.c dbg_printf. Use it instead of _LogPrintf in the commented example, and enable DEBUG_LOGGING in include/platform.h

Note that for spytask to work, you need to have most of the bitmap display stuff setup, or at least to have arranged thing so it doesn't trash random memory.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #51 on: 19 / March / 2016, 20:01:56 »
ok, I'm impatient....the address  of _LogCameraEvent is in stubs_entry.S, but I can't seem to get the build to link it...always unresolved in generic/wrappers.c
Logged
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #52 on: 19 / March / 2016, 20:17:35 »
Nevermind, my bad...not in stubs_entry.S
Logged
*

Offline reyalp

  • ******
  • 14079
Re: SX60HS Porting
« Reply #53 on: 19 / March / 2016, 20:26:44 »
Quote from: 62ndidiot on 19 / March / 2016, 20:17:35
Nevermind, my bad...not in stubs_entry.S
Right, it's found by the sig finder but only added to func*.csv because it's not normally used. You can add functions like this to stubs_entry_2.S
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #54 on: 19 / March / 2016, 20:54:33 »
Yes,  I did that.  It feels like memory getting trashed since the exact point of the exception seems to vary a bit...although in the dump it is draw_test_guard

003a9f84 <draw_test_guard>:
  3a9f84:       4b05            ldr     r3, [pc, #20]   ; (3a9f9c <draw_test_guard+0x18>)
  3a9f86:       681a            ldr     r2, [r3, #0]
  3a9f88:       4b05            ldr     r3, [pc, #20]   ; (3a9fa0 <draw_test_guard+0x1c>)
  3a9f8a:       f853 3022       ldr.w   r3, [r3, r2, lsl #2]
  3a9f8e:       7818            ldrb    r0, [r3, #0]
  3a9f90:       f1b0 0342       subs.w  r3, r0, #66     ; 0x42
  3a9f94:       4258            negs    r0, r3

Now I need a little guidance on how to proceed.
Should I now be looking at platform/sx60hs/lib.c for problems? or ?
It seems to me, I could have dimensions/camera characteristics wrong,  that would trash memory.  I suppose something could easily be wrong in stubs_entry_2.S and also possibly in stubs_entry.S. What should I ensure is shutoff, and what should i turn on  bit by bit to trace this?
I've attached two different crash logs, and the dump.
Logged
*

Offline reyalp

  • ******
  • 14079
Re: SX60HS Porting
« Reply #55 on: 19 / March / 2016, 22:23:12 »
Quote from: 62ndidiot on 19 / March / 2016, 20:54:33
It feels like memory getting trashed since the exact point of the exception seems to vary a bit...although in the dump it is draw_test_guard
From romlog3, PC is 3A9F8E

  3a9f8e:   7818         ldrb   r0, [r3, #0]

R3 is 0xEFEFEFEF which definitely isn't valid.

This corresponds to

    if (opacity_buffer[active_bitmap_buffer][0] != 0x42) return 0;

Meaning opacity_buffer and/or active_bitmap_buffer is incorrect. If you haven't found the active_bitmap_buffer variable, but have found at least one of the buffers, you fake them in your lib.c, like

char *opacity_buffer[2] = {(char*)0xDEADBEEF, (void*)0xDEADBEEF};
int active_bitmap_buffer=0;

and don't define anything in for them in stubs_min.S

You will only get the right buffer half the time, but it should be enough to see something.

If you haven't found the buffers at all, you need to start with that.

edit:
If you want more real-time help, I'm often in the #chdk IRC channel on freenode, usually on weekends and evenings (US/Pacific)

edit 2:
I think the opacity buffer addresses are the same as g7x, based on code around fc0f8736 (= g7x fc0f7b52)

Not sure about active_bitmap_buffer, I seem to have taken very poor notes on how I got that value for g7x, but for now you can just define your own variable and leave it set to 0.

« Last Edit: 19 / March / 2016, 23:28:25 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #56 on: 20 / March / 2016, 13:52:22 »
A little more progress, no crash now,  opacity buffer checks out the same as g7x, based on code near loc-fc0f8736 (100f).. setting int active_bitmap_buffer =0 in lib.c, as suggested and deleting from stubs_min.S.
it powers up, after about 7 seconds, the LCD screen blinks once, and then it stays on.

from stubs_min.S:
DEF(bitmap_buffer, 0xc1cc) // look at 0xfc33701a & compare to g7x
//DEF(active_bitmap_buffer, 0xc1c4) // subtract 8

with setting active_bitmap_buffer 0xc1c4 (which I think should be correct) it crashes at the 7 second mark.

in your comment:
Quote
From romlog3, PC is 3A9F8E

  3a9f8e:   7818         ldrb   r0, [r3, #0]

R3 is 0xEFEFEFEF which definitely isn't valid.

This corresponds to

    if (opacity_buffer[active_bitmap_buffer][0] != 0x42) return 0;

I confess to not understanding how you narrowed it down to code referring to the opacity_buffer
Logged
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #57 on: 20 / March / 2016, 15:02:02 »
Interestingly, the momentary blink, is a "busy" image. It doesn't crash. If i move  the int active_bitmap_buffer = 0 to stubs_min.S using FAKEDEF, it crashes.
Logged
*

Offline reyalp

  • ******
  • 14079
Re: SX60HS Porting
« Reply #58 on: 20 / March / 2016, 15:19:46 »
Quote from: 62ndidiot on 20 / March / 2016, 13:52:22
with setting active_bitmap_buffer 0xc1c4 (which I think should be correct) it crashes at the 7 second mark.
This probably means it's still wrong. The correct active_bitmap_buffer variable will toggle between 0 and 1 when the screen updates. Anything that has different values isn't the correct variable.

I'm not clear if you are getting anything CHDK related on the display when active_bitmap_buffer is forced to zero? If the other stuff is right, you should see something, but it will not refresh correctly. Doing things that update the canon display cause the buffers to swap.

Since you have spytask running (with the faked active_bitmap_buffer) the ptp task should also be started now, so you may be able to use chdkptp rmem command to peek at memory. (see http://chdk.wikia.com/wiki/PTP_Extension and https://www.assembla.com/spaces/chdkptp/wiki)

To get most other ptp commands working, you need kdb_task running as well. I recommend getting ptp working early, since it's helpful for debugging and lets you install new builds without swapping the card.


Quote
I confess to not understanding how you narrowed it down to code referring to the opacity_buffer
First, I just searched for the PC address in the dump. This gives

003a9f84 <draw_test_guard>:
  3a9f84:   4b05         ldr   r3, [pc, #20]   ; (3a9f9c <draw_test_guard+0x18>)
  3a9f86:   681a         ldr   r2, [r3, #0]
  3a9f88:   4b05         ldr   r3, [pc, #20]   ; (3a9fa0 <draw_test_guard+0x1c>)
  3a9f8a:   f853 3022    ldr.w   r3, [r3, r2, lsl #2]
  3a9f8e:   7818         ldrb   r0, [r3, #0]
  3a9f90:   f1b0 0342    subs.w   r3, r0, #66   ; 0x42
  3a9f94:   4258         negs   r0, r3
  3a9f96:   4158         adcs   r0, r3
  3a9f98:   4770         bx   lr

The exception is at 3a9f8e. Since this is the last memory access in the function, and is a single byte load (ldrb), it must correspond to the outermost memory access in the expression. So the value in R3 when the ldrb happens is opacity_buffer + active_bitmap_buffer*sizeof(pointer). Since opacity buffer is defined by you and looks correct, this implies that active_bitmap_buffer out of bounds.

Quote
Interestingly, the momentary blink, is a "busy" image. It doesn't crash. If i move  the int active_bitmap_buffer = 0 to stubs_min.S using FAKEDEF, it crashes.
Are you using FAKEDEF(active_bitmap_buffer,0) ? If so this is incorrect, the second value is the size to reserve, not the initial value. I had this wrong in early versions of the g7x code.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #59 on: 20 / March / 2016, 16:34:53 »
No I do not see any chdk related screen items, except perhaps the momentary busy. I will devote some more time to determining the stub for active_bitmap_buffer.I'll check some other camera implementations like the sx280 and maybe even the sx50. I checked and i had it wrong still...
s/b 0xc1fc I think...more testing required.

Now I see in the init_file_modules_task the line
"    BL      core_spytask_can_start\n" // + CHDK: Set "it's-safe-to-start" flag for spytask
I am not yet loading this module in CreateTask_my, so perhaps spytask cannot yet run? Perhaps I should uncomment this part in CreateTAsk_my.
« Last Edit: 20 / March / 2016, 16:47:44 by 62ndidiot »
Logged
Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 92   Go Up
« previous next »
 

Related Topics