SX720 Porting thread - page 10 - DryOS Development - CHDK Forum
supplierdeeply

SX720 Porting thread

  • 158 Replies
  • 40978 Views
*

Offline reyalp

  • ******
  • 12168
Re: SX720 Porting thread
« Reply #90 on: 10 / April / 2016, 20:02:50 »
Advertisements
Yeah, but I thought a well known function looks less obscure and the additional clock cycles don't really matter much at this point.
Not worried about the speed, but I checked in the ldrh/strh version for g7x and sx280 since it doesn't depend on memcpy being found. Might not be required for these ports, but it's a better example, and the compiler could change the alignment of the source part.
Don't forget what the H stands for.

*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: SX720 Porting thread
« Reply #91 on: 11 / April / 2016, 02:40:50 »
reyalp yes after that will not boot,  "blo   loc_fc020046"

will Change the close address

srsa_4c, I think then some of my source files will have wrong info with these new buffers


EDIT:  with this it did not crash after boot ( but with the wrong patch after  "    blo     loc_fc02002a\n")

//NHSTUB(Close,0xfc33303e) // SX720
//NHSTUB(close,0xfc33303e) // SX720
//NHSTUB(Close_FW,0xfc33303e) // SX720
« Last Edit: 11 / April / 2016, 07:58:20 by asm1989 »

*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: SX720 Porting thread
« Reply #92 on: 16 / April / 2016, 04:56:07 »

Hi srsa_4c , from the ram and romlog I get is there a way to get from there some of the missing things for SX720


like the focus_len_table for stubs_min


I still have wrong also the lib.c buffers from *hook_raw_image_addr(), and probably the screen info


Boot it working but with the hook in the wrong place


Thanks!

*

Offline srsa_4c

  • ******
  • 4035
Re: SX720 Porting thread
« Reply #93 on: 16 / April / 2016, 09:44:06 »
like the focus_len_table for stubs_min
That is a table containing all possible focal lengths. The table itself is in the "upper half" of the ROM, it can be found by searching for known constants of the lens, such as its shortest focal length (4.3 mm). Values are usually multiplied by 1000, that's 4300=0x10cc on your cam. It seems to start at 0xfdf31670. Its last entry is 0x29FE0 which corresponds to your cam's spec (172 mm).
Quote
and probably the screen info
Buffer addresses are listed here. The overlay buffers (aka bitmap_buffer) can be found at 0xc8b8 (in reverse order, I wonder why...). Did not check active_bitmap_buffer, your guess (from 9th of April, don't have newer source) might be right. The opacity buffers are not listed in RAM as a table, so do what's on existing ports and make an array in lib.c . You'll have to work out the correct order though.
Quote
hook_raw_image_addr()
Be patient and make display and keyboard working first.

Quote
Boot it working but with the hook in the wrong place
Please rephrase this, I did not understand your earlier
Quote
with this it did not crash after boot ( but with the wrong patch after  "    blo     loc_fc02002a\n")
either.

edit:
From the camera manual, you probably won't really need to implement CAM_SUPPORT_BITMAP_RES_CHANGE related stuff as it only outputs TV/HDMI signal in playback mode.
« Last Edit: 16 / April / 2016, 09:52:21 by srsa_4c »


*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: SX720 Porting thread
« Reply #94 on: 16 / April / 2016, 13:31:08 »

thanks srsa_4c, still trying to make something show up, with no luck yet!


I mean that these lines


"ldr     r0, =hook_CreateTask\n"    // dest: Address to patch (hook_ has thumb bit off)
"adr     r1, patch_CreateTask\n"    // src: Patch data
"mov     r2, #8\n" // two words
"bl      _memcpy\n" // shouldn't need to preserve any extra regs, cache func called just below


are after "    blo     loc_fc02002a\n"


and reyalp sugest they should go after  "    blo     loc_fc020046\n" 


But if I put them there the cam wont boot

*

Offline srsa_4c

  • ******
  • 4035
Re: SX720 Porting thread
« Reply #95 on: 16 / April / 2016, 13:43:58 »
I mean that these lines


"ldr     r0, =hook_CreateTask\n"    // dest: Address to patch (hook_ has thumb bit off)
"adr     r1, patch_CreateTask\n"    // src: Patch data
"mov     r2, #8\n" // two words
"bl      _memcpy\n" // shouldn't need to preserve any extra regs, cache func called just below


are after "    blo     loc_fc02002a\n"
That's not good, because the firmware's CreateTask function is located in the 0xbfe10800 area, which is populated in the next loop (the one ending with blo loc_fc020046), so the patch is simply overwritten.
Quote
and reyalp sugest they should go after  "    blo     loc_fc020046\n" 
Definitely.
Quote
But if I put them there the cam wont boot
Please upload the non booting version of boot.c (don't add comments to it because that can be confusing), and the main.bin.dump your get after compilation.
Also note that (in latest trunk) reyalp has switched to a halfword copy loop at that place.

*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: SX720 Porting thread
« Reply #96 on: 17 / April / 2016, 03:26:43 »
Here you have it built with trunk 4591

*

Offline srsa_4c

  • ******
  • 4035
Re: SX720 Porting thread
« Reply #97 on: 17 / April / 2016, 08:11:29 »
Here you have it built with trunk 4591
Thanks.
Looks like patching thumb2 code requires even more attention.

The problem is, patch_CreateTask is assembled as follows:
Code: [Select]
00395650 <patch_CreateTask>:
  395650: f8df f000 ldr.w pc, [pc] ; 395654 <patch_CreateTask+0x4>
  395654: 00395659 .word 0x00395659
Looks innocent. We are copying these 2 words to an address that is not word aligned (0xbfe14a62).
Trouble is, PC-relative load is calculated as follows (excerpt from the ARM architecture ref. manual):

Quote
LDR (literal)
(...)
Encoding T2              ARMv6T2, ARMv7
LDR<c>.W <Rt>,<label>
LDR<c>.W <Rt>,[PC,#-0]
(...)
<label>
The label of the literal data item that is to be loaded into <Rt>. The assembler calculates the required value of the offset from the Align(PC,4) value of this instruction to the label.
(...)
That means, the LDR instruction copied to the unaligned address will load a different value and not what we expect.

Solution: we need to make sure the code we're using executes the same in its intended place.

edit:
I have done some trials.

ASM code:

Code: [Select]
    ".align 2\n"
    "ldr pc, mylabel\n"
    "mylabel:\n"
    ".long 0x12345678\n"

as compiled:

Code: [Select]
  3955f0: f8df f000 ldr.w pc, [pc] ; 3955f4 <mylabel>

003955f4 <mylabel>:
  3955f4: 12345678 .word 0x12345678

unaligned case:

Code: [Select]
    ".align 2\n"
    "nop\n"
    "ldr pc, mylabel\n"
    "mylabel:\n"
    ".long 0x12345678\n"

Code: [Select]
  3955f0: bf00      nop
  3955f2: f8df f002 ldr.w pc, [pc, #2] ; 3955f6 <mylabel>

003955f6 <mylabel>:
  3955f6: 5678      .short 0x5678
  3955f8: 1234      .short 0x1234

edit2:
proposed version attached
« Last Edit: 17 / April / 2016, 09:36:30 by srsa_4c »


*

Offline asm1989

  • *****
  • 527
  • SX720, SX260, SX210 & SX200
Re: SX720 Porting thread
« Reply #98 on: 17 / April / 2016, 09:55:44 »
Great srsa_4c,  :D  now it boots, shows a canon logo with some black vertical lines crossing it , shows no file and shuts down with no chdk info, attached romlog

*

Offline srsa_4c

  • ******
  • 4035
Re: SX720 Porting thread
« Reply #99 on: 17 / April / 2016, 10:07:37 »
Great srsa_4c,  :D  now it boots, shows a canon logo with some black vertical lines crossing it , shows no file and shuts down with no chdk info, attached romlog
Exception in firmware's CtrlSrv task. You have some major memory corruption. Either stack or in RAM elsewhere.
As a start, try commenting out both task replacement blocks (capt_seq and initfilemodules) in CreateTask_my().
If you still have unported/copied parts laying around in code, it's time to review them.

(you don't need to upload those gk.log files, their content is unknown)

 

Related Topics