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

SX60HS Porting

  • 915 Replies
  • 348564 Views
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #40 on: 13 / March / 2016, 16:08:21 »
Advertisements
Thanks for your  responses.  You are correct that my procedure was to modify g7x boot.c (most recently).  Although, I did so while viewing the dissassembly of both g7x/102d and sx60/100f and following along line by line, the procedure is error prone as you say. I'll try to use capdis as suggested to extract the appropriate sections....
thx.
Logged
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #41 on: 15 / March / 2016, 15:18:57 »
Well I've extracted everything using capdis...it wasn't painful at all, this is a nice tool. Thanks for all your suggestions. Occasionally you have to enter the the start address plus one (thumb) for disassembly to be successful.  Updated boot.c, which corrected a few errors and typos.  Now the boot process proceeds into sub_fc05f050_my before having difficulty in stdioSetup

<pre>
"loc_fc05f0b0:\n"
"    mov     r0, r4\n"
"    bl      sub_fc05f288\n"
// led works here
"    cmp     r0, #0\n"
"    bge     loc_fc05f0c0\n"   
"    ldr     r0, =0xfc05f154\n" //  *"stdioSetup
"    bl      sub_fc05f0e4\n"
</pre>
where we have dmSetup, termDriverInit and etc.
bl  sub_fc05f288 appears to fail with a bad return code
since we never branch to loc_fc05f0c0
Forcing the branch by replacing bge with b continues execution,
and if i force one more the same way in the section // stdlibSetup
i get all the way to _CreateTask

Suggestions for debugging this?
Attached is the latest code
Logged
*

Offline reyalp

  • ******
  • 14080
Re: SX60HS Porting
« Reply #42 on: 15 / March / 2016, 16:44:53 »
Quote from: 62ndidiot on 15 / March / 2016, 15:18:57
Well I've extracted everything using capdis...it wasn't painful at all, this is a nice tool. Thanks for all your suggestions. Occasionally you have to enter the the start address plus one (thumb) for disassembly to be successful.
Just be clear:
If you are using an address (rather than a function name from stubs) you always need to make sure the thumb it is set to match the instruction set of the code you are extracting. For digic 6 / thumb2 firmwares, this will almost always be thumb mode, except for some veneers that jump from ROM to RAM or vice versa.
Depending on where you get the address from, it may already have the thumb it set: e.g. LDR pc,=#0xXXXXXXXX. does while a bl  sub_XXXXXXXX in thumb code does not.

Quote
Suggestions for debugging this?
You can check if there is a romlog, using the canon basic romlog script: http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Romlog

This may be a bit early in the boot process for one to be saved, but it doesn't hurt to check.

From a quick look, I don't see anything immediately amiss, but I would strongly recommend starting out with all CHDK tasks disabled. Don't create spytask, or hook init_file_modules_task, or replace kbd_task. For kbd task, you can just call the original. Once you have it booting booting like this, then start implementing the CHDK tasks. The only thing you should have to do is comment out the diskboot loading code (sub_fc05f712), so you don't end up in a boot loop. You may also need to do something with the reboot flag / keyboard startup checks (probably  sub_fc07319c), but on g7x I found this wasn't needed if I set the magic 0x12345678 value in loader, or just held the button down when powering on.

With this setup, the camera should appear to boot normally with a "card locked" message.

It seems like your problem is before any of the CHDK tasks are started, but this can be confusing. Early in the boot process, you can block with an infinite loop that blinks an LED, but once the camera starts multi-tasking this doesn't work.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #43 on: 15 / March / 2016, 18:24:01 »
Thanks....one clarification....
stubs_auto.S contains fc05f288 (for example)
stubs_auto.S:STUB(fc05f288)

This is the current problem in boot.c (discussed above)
Using capdis with a -s fc05f288 doesn't work,  you must use -s fc05f289.
However, using capdis to disassemble from -s 0xfc05f051 produces code with

bge sub_fc05f288 (not 289)

I think 288 is correct but now after reading your comment I have doubts.
I'm showing my lack of real understanding here.  Sorry.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: SX60HS Porting
« Reply #44 on: 15 / March / 2016, 21:17:45 »
Quote from: 62ndidiot on 15 / March / 2016, 18:24:01
Using capdis with a -s fc05f288 doesn't work,  you must use -s fc05f289.
However, using capdis to disassemble from -s 0xfc05f051 produces code with

bge sub_fc05f288 (not 289)

I think 288 is correct but now after reading your comment I have doubts.
I'm showing my lack of real understanding here.  Sorry.
This is correct. This is confusing because there are a couple of things going on.

The sub_xxxxxxxx is just a name. We could call it anything, but using the original firmware address is a convention that allows us to generate stubs_auto.S and makes it easier to reference the original disassembly. The STUB macro in includes/stubs_asm.h takes care of setting the thumb bit for thumb2 firmware. Calls to ARM code get the STUB2 macro instead. Arm calls are recognized by BX/BLX instructions, under the assumption that our inline code is thumb mode.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #45 on: 16 / March / 2016, 13:36:56 »
Quote
If you are using an address (rather than a function name from stubs) you always need to make sure the thumb it is set to match the instruction set of the code you are extracting. For digic 6 / thumb2 firmwares, this will almost always be thumb mode, except for some veneers that jump from ROM to RAM or vice versa.
and
Quote
The sub_xxxxxxxx is just a name. We could call it anything, but using the original firmware address is a convention that allows us to generate stubs_auto.S and makes it easier to reference the original disassembly. The STUB macro in includes/stubs_asm.h takes care of setting the thumb bit for thumb2 firmware. Calls to ARM code get the STUB2 macro instead. Arm calls are recognized by BX/BLX instructions, under the assumption that our inline code is thumb mode.
MOST of the branches to sub_xxxxx in boot.c show up in stubs_auto.S as STUB, not STUB2, which would seem to contradict the above? However BLX show up as STUB2 in stubs_auto.S....
Logged
*

Offline reyalp

  • ******
  • 14080
Re: SX60HS Porting
« Reply #46 on: 16 / March / 2016, 16:19:43 »
Quote from: 62ndidiot on 16 / March / 2016, 13:36:56

MOST of the branches to sub_xxxxx in boot.c show up in stubs_auto.S as STUB, not STUB2, which would seem to contradict the above? However BLX show up as STUB2 in stubs_auto.S....
Apologies for the confusion. The first comment was about specifying the start address on the capdis command line. For capdis, you must specify the correct instruction set to get correct disassembly.

What appears in the output of capdis follows the convention expected by the stub_auto system, where function / label names are generated without the thumb bit set, and the instruction set of the stub is inferred from the instruction.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #47 on: 16 / March / 2016, 20:07:54 »
I made it a little farther today.  Got it to execute all the way to
<pre>
//"    blx     sub_fc2cf018\n" // j_CreateTask
    "blx     _CreateTask\n"    // CreateTask
"    movs    r0, #0\n"
"    pop     {r3, pc}\n"
    ".ltorg\n"
</pre>

where it goes off somewhere. I found I was able to create romlog1.txt (see attached zip, which i hope is the result of this).  Also after creating romlog.txt I re-inserted the card in the locked position and a file GK.log got created when i tried another boot...after that i couldn't get anymore romlog creation...not sure if I need to re-write the boot area or not after this, since I am using the same card for everything.

I found that if I comment out the branch to _CreateTask above, and instead
use   blx     sub_fc2cf018\n , then task_Startup_my does execute, and the camera led stays on if I continue to depress the power button, but if I release the LED goes out after a bit of a pause.

I also worked on capt_seq.c for a bit.  it seems that the disassembly for the sx60hs/100f differs a fair bit from that of the g7x using 
Quote
~/chdk/tools$ ./capdis ../../dumps/sx60/sub/100f/PRIMARY.BIN 0xfc000000 -stubs=../platform/sx60hs/sub/100f -s=0xfc15284d  -c=117 -f=chdk   

thanks everyone for your help and I'd appreciate more suggestions. Probably i should comment out capt_seq part in CreateTask_my (again), but I got frustrated. The SX60HS has a high resolution LCD, i'm worried i won't be able to see a thing if i don't set that up properly.  Also what is GK.log?
-af
Logged
*

Offline reyalp

  • ******
  • 14080
Re: SX60HS Porting
« Reply #48 on: 16 / March / 2016, 22:31:46 »
Quote from: 62ndidiot on 16 / March / 2016, 20:07:54
I made it a little farther today.  Got it to execute all the way to
<pre>
//"    blx     sub_fc2cf018\n" // j_CreateTask
    "blx     _CreateTask\n"    // CreateTask
"    movs    r0, #0\n"
"    pop     {r3, pc}\n"
    ".ltorg\n"
</pre>
It should be bl _CreateTask, because it's calling the CHDK stub (which is always thumb), not the original ARM veneer.
Quote
Probably i should comment out capt_seq part in CreateTask_my (again), but I got frustrated. The SX60HS has a high resolution LCD, i'm worried i won't be able to see a thing if i don't set that up properly.
capt seq is only related to image capture, not the display. Display is mostly done in spytask, but you have to find buffer addresses (see platform/g7x/lib.c) before you can display anything.

I would (again) highly recommend getting the camera to boot cleanly with no hooked tasks before you enable anything else. Before you have display drawing, you can output using the LED, or UART redirection logging (see http://chdk.wikia.com/wiki/Debugging#Logging_camera_console_output)

GK log is saved when you get a romlog. I believe it is related to the display system, but it's new on digic 6 and we don't know the details yet.

capt_seq is one of the more difficult things to implement. You may find that sx60 is more similar to sx280hs than g7x. You may also find it useful to refer to non-digic 6 cameras. Although the instructions set is different, it is still possible to recognize equivalent code.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 596
Re: SX60HS Porting
« Reply #49 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)
I'm not completely sure I understand the UART redirect stuff.  I've created a file uart.req with the bytes in it....

~/chdk$ od -h uart.req
0000000 2177 82ce
0000004

I don't understand what else i need to do to set up the redirection....
<pre>
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
StackDump:
0x00000120
0x000001E5
0x00000119
0x000000EB
0x0000009A
0x003AA2E5
0x00000000
0x000000EB
0x00000000
0x00000000
0x000000E8
0x00009A9A
0x00000120
0x000001E5
0xFFFFFF00
0x00000000
0x000000EB
0x000000D4
0x003C2318
0x003C5284
0x00009A3F
0x19980218
0x19980218
0x003AB995
0x00009A9A
0x00000048
0x0000003C
0x00000000
0x7F9A99FF
0x3F005A17
0x00000053
0x003C5284
0x003C2198
0x00000004
0x003C6374
0x00000005
0x19980218
0x19980218
0x19980218
0x003ABE5F
0x003C5284
0x00000001
0x003C5284
0x003AC4B1
0x00000000
0x003C2198
0x003C51FC
0x003A9D15
0x00000000
0x003A8D51
0x006230A4
0x0000803C
0x19980218
0x19980218
0x19980218
0x010E1F35
0x19980218
0x19980218
0x19980218
0x19980218
0x00000808
00000080: *** Camera Log Start ***
00000090: UI:LogicalEvent:0x00005001:adr:0,Para:0
00000100: SS:S-Imag
00000100: SS:SoundComp
00000170: UI:Initialized WindowSystem.
00000170: UI:VTMLock
00000180: UI:VTMUnLock
00000190: UI:LogicalEvent:0x0000300a:adr:0,Para:0
00000190: UI:HDMIConnectCnt
00000190: UI:PB.Create
00000190: UI:VTMLock
00000190: UI:DispSwCon_TurnOnBackLight
00000190: UI:TurnOnBackLight
00000190: UI:VTMReduuce
00000200: UI:MuteOffPhysicalScreen
00000200: UI:LogicalEvent:0x00003139:adr:0,Para:0
00000210: UI:PB.CreateE
00000210: UI:VTM SW
00000210: UI:VTMUnLock
00000310: UI:LogicalEvent:0x000011ed:adr:0,Para:0
00000580: UI:LogicalEvent:0x00005006:adr:0,Para:0
00000580: UI:AC:StartPB[0]
00000580: UI:DispSwCon_TurnOnDisplayDevice
00000580: UI:AC:EBtn
00000580: UI:PB.Start
00000580: UI:VTMLock
00000580: UI:LogicalEvent:0x00003201:adr:0,Para:0
00000580: UI:DSIC:47,0
00000600: UI:CC_CompFlhJpg
00000600: UI:_CompFlhJpg
00000600: UI:PB.Flash
00000600: UI:PB.GRInitFileStore
00000600: UI:PB.S_Meta
00000610: UI:DSIC:47,0
00000610: UI:LogicalEvent:0x0000301d:adr:0xb,Para:11
00000610: UI:VTMUnLock
00000610: UI:LogicalEvent:0x0000320b:adr:0,Para:0
00000610: UI:PB.StartE
00000610: UI:DCIC:1,0
00000610: UI:AC:EnryPB
00000610: UI:DCIC:1,0
00000610: UI:AP:ChkCnctUSB
00000610: UI:DSIC:21,6557600
00000610: UI:PB.DPOF
00000620: UI:LogicalEvent:0x00003221:adr:0x1b008a0,Para:28313760
00000620: UI:PB.MAX_ID
00000620: UI:PB.FoundMaxIDF
00000620: UI:PB.RefPB
00000620: UI:VTMLock
00000620: UI:PB.SPC_SFirstCameraObject
00000620: UI:DSIC:47,0
00000650: UI:IPS.ReadI
00000820: UI:Err:0
00000820: UI:IPS.DrawI
00000980: UI:IPS.DComp:0
00000980: UI:LogicalEvent:0x00003204:adr:0,Para:0
00000980: UI:PB.ADrawImage
00000980: UI:PB.DComplete_S
00000990: UI:PB.RfrsI
00000990: UI:PB.F_Dec_S
00000990: UI:PB.GRInitFileStore
00001000: UI:LogicalEvent:0x00003202:adr:0,Para:0
00001000: UI:PB.F_Dec_E
00001000: UI:PB.DCompleteRefresh
00001050: UI:VTMUnLock
00001050: UI:SetSyncroDisplayDeviceController
00001070: UI:PB.DComplete_E
00001070: UI:DispSw: Unlock
00001070: UI:DispSwCon:Unlock
00001070: UI:_ChangeDisplayOut
00001070: UI:DSIC:e4,0
00001070: UI:DispSwCon_TurnOnBackLight
00001070: UI:DispSwCon_MuteOffPhysicalScreen
00001070: UI:Window MuteOff
00001070: UI:MuteOffPhysicalScreen
00001330: UI:LogicalEvent:0x00003220:adr:0,Para:0
00001330: UI:PB.CTG
00001330: UI:PB.Check_S
00001330: UI:VTMLock
00001390: UI:VTMUnLock
00001400: UI:DSIC:48,0
00001400: UI:PB.Check_E
00003010: UI:VTMLock
00003010: UI:VTMUnLock
 </pre>
Logged
Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 92   Go Up
« previous next »
 

Related Topics