SX720 Porting thread

reyalp

12690

Re: SX720 Porting thread

« Reply #20 on: 27 / March / 2016, 13:34:25 »

Advertisements

Quote from: asm1989 on 27 / March / 2016, 06:54:51

Is it possible to open the .dis file generated with capdis with ida or some visual tool?

It's just a text file. (edit: I use vi, which stands for "visual" so...

)

Quote from: asm1989 on 27 / March / 2016, 11:37:27

regarding the disasm of the RAM with
./capdis.exe ../../dumps/sx720/sub/100e/PRIMARY.BIN 0xfc000000 -stubs=../platform/sx720/sub/100e -s=0x010e1001 -e=0x010fce10 -f=objdump -d-const -d-addr -d-bin > ../../dumps/sx720/sub/100e/RAMCODE1.DIS

I think it is missing some RAM areas , the start and end seems to be right

// RAM code 0x010e1000 - 0x010fce10 copied from 0xfcd3b79c ( 114192 bytes)
// RAM code 0xbfe10800 - 0xbfe1751d copied from 0xfcd575ac ( 27933 bytes)

But dosnt seems to start correctly , the g7x has much more at the begining looking for example for the surrunding areas for CreateBinarySemaphoreStrictly

G7x only has the first RAM area. Later ones like your camera have two. In the newer cameras, a lot of the IPC functions (semaphore, event flag etc) go in the second area 0xb...

There are also veneers between these, which may not be picked up correctly by finsig_thumb2, since it currently only resolves one level.

I disassembled both for sx720 and I don't see any really obvious problems. But I haven't looked at it carefully.

Logged

Don't forget what the H stands for.

asm1989

527
SX720, SX260, SX210 & SX200

Re: SX720 Porting thread

« Reply #21 on: 27 / March / 2016, 13:47:03 »

Thanks reyalp,

No great problems so far, just time to double check, able to find most of them, CreateBinarySemaphoreStrictly is still missing but looking for clues

Any cams with 2 rams ported so far?

Logged

reyalp

12690

Re: SX720 Porting thread

« Reply #22 on: 27 / March / 2016, 14:00:35 »

Quote from: asm1989 on 27 / March / 2016, 13:47:03

Thanks reyalp,

No great problems so far, just time to double check, able to find most of them, CreateBinarySemaphoreStrictly is still missing but looking for clues

Any cams with 2 rams ported so far?

philmoz did some work on g5x, and there is a partial port for EOS M3 https://www.assembla.com/spaces/chdk-m3/subversion/source

From working on the sigfinder, I don't think there's anything special about the two RAM regions from a CHDK POV, just different addresses for some functions.

Quote

No great problems so far, just time to double check, able to find most of them, CreateBinarySemaphoreStrictly is still missing but looking for clues

I see it in the func csv, but "close" has the same address, so it's labeled with that in the disassembly. In this case, close is the one that's wrong. I'll take a look at why close is misidentified later.

Logged

Don't forget what the H stands for.

asm1989

527
SX720, SX260, SX210 & SX200

Re: SX720 Porting thread

« Reply #23 on: 27 / March / 2016, 14:22:22 »

Thanks just finished most of the stubs_entry_2.S , stubs_min.S

If any other is wrong like the close, it should be replaced then in stubs_min.S to avoid using the wrong one?

Also Close_FW was wrong too, the right one is lowecase close

0xfc33303f,Close
0xbfe155f5,close
0xfc33303f,Close_FW

« Last Edit: 27 / March / 2016, 15:14:56 by asm1989 »

Logged

reyalp

12690

Re: SX720 Porting thread

« Reply #24 on: 27 / March / 2016, 15:36:04 »

Quote from: asm1989 on 27 / March / 2016, 14:22:22

If any other is wrong like the close, it should be replaced then in stubs_min.S to avoid using the wrong one?

stubs_entry_2.S

Quote

Also Close_FW was wrong too, the right one is lowecase close

0xfc33303f,Close
0xbfe155f5,close
0xfc33303f,Close_FW

I'm sure the lowercase one is wrong, because it's actually CreateBinarySemaphoreStrictly. You can see this in the disassembly, and the fact that it appears near other *Strict functions in the copied RAM area.

The upper case one should be right, because it comes from an eventproc. lowercase close ends up being wrong because the first call from Close_FW function is CreateBinarySemaphoreStrictly, where the sig finder expects it to be lowercase close.

The disassembly of Close is bad in my ROMCODE.DIS, because it's out of alignment. If you do capdis -s=Close_FW -c=20 you can see the real code.

edit:
Usually, when capdis gets out of alignment, it syncs up pretty fast naturally, but this case there was a long run of code that happens to be valid instructions.

edit 2:
g5x has the same problem. It also looks like TurnOnBackLight is also incorrectly identified on these cameras, because the firmware function is a return 0.

« Last Edit: 27 / March / 2016, 15:53:01 by reyalp »

Logged

Don't forget what the H stands for.

asm1989

527
SX720, SX260, SX210 & SX200

Re: SX720 Porting thread

« Reply #25 on: 27 / March / 2016, 16:27:37 »

Yes replaced them at stubs_entry_2 with
NHSTUB(CreateBinarySemaphoreStrictly,0xfc33303e)
NHSTUB(Close,0xbfe155f5)
NHSTUB(Close_FW,0xbfe155f5)

Logged

reyalp

12690

Re: SX720 Porting thread

« Reply #26 on: 27 / March / 2016, 16:40:28 »

Quote from: asm1989 on 27 / March / 2016, 16:27:37

Yes replaced them at stubs_entry_2 with
NHSTUB(CreateBinarySemaphoreStrictly,0xfc33303e)
NHSTUB(Close,0xbfe155f5)
NHSTUB(Close_FW,0xbfe155f5)

This incorrect. As I said a couple of times, 0xbfe155f5 is CreateBinarySemaphoreStrictly. I'm very sure of this, it calls CreateBinarySemaphore and assert. Close/Close_FW is 0xfc33303e It's an eventproc so very unlikely to be wrong, and manual inspection shows the registration call is correct.

You do not need to override functions like Close_FW that only appear in the stubs csv, although it may improve capdis output.

edit:
The one that is wrong is lowercase close. Finding the right one requires analysis of the Close function.

edit 2:
I fixed the matching for lowercase close. It's the function called that isn't semaphore related, ~~so I think it's right, but the behavior might have changed from earlier versions.~~

edit 3:
Actually, it isn't (although it might work) because canon added another layer to the eventproc calls: https://chdk.setepontos.com/index.php?topic=12516.msg127454#msg127454

« Last Edit: 27 / March / 2016, 21:23:11 by reyalp »

Logged

Don't forget what the H stands for.

asm1989

527
SX720, SX260, SX210 & SX200

Re: SX720 Porting thread

« Reply #27 on: 28 / March / 2016, 02:30:37 »

Thanks reyalp, will switch to

NHSTUB(CreateBinarySemaphoreStrictly,0xbfe155f5)
NHSTUB(close,0xfc33303e)
NHSTUB(Close,0xfc33303e)
NHSTUB(Close_FW,0xfc33303e)

Once I have a working vers will try out

Logged

asm1989

527
SX720, SX260, SX210 & SX200

Re: SX720 Porting thread

« Reply #28 on: 28 / March / 2016, 10:48:38 »

Almost have a ready to compile version, based fully on gx7 , some questions:

How do I find LED_PR for lib.c ? need to poke with canonbasic or there is another way?

FI2KEY & FI2IV & dancing bits will be needed to any guess on the firmware location?

Also is possible with capdis to look for at the end of rom for levent tables for example?

EDIT: Also not sure about the validity of (0x4ffc)=0x12345678; from g7x since it does not not appear in sx720 fw

EDIT2: Also loader\generic\compat_table.h > needs to be added something or not ?

Thanks

« Last Edit: 28 / March / 2016, 13:26:58 by asm1989 »

Logged

reyalp

12690

Re: SX720 Porting thread

« Reply #29 on: 28 / March / 2016, 13:26:44 »

Quote from: asm1989 on 28 / March / 2016, 10:48:38

Almost have a ready to compile version, based fully on gx7 , some questions:

How do I find LED_PR for lib.c ? need to poke with canonbasic or there is another way?

I would try the same address as g7x first, AFAIK all the d6 cameras known so far have used the same address. You can either use canon basic or blinking in loader. When I'm working on a port, I usually start with an infinite loop trying to blink an LED in loader.

Quote

FI2KEY & FI2IV & dancing bits will be needed to any guess on the firmware location?

The FI2 key address should be loaded by code at the start of ROM (in the romstarter code, not the main ROM)

Code: [Select]

$ ./discam.sh sx720hs 100e -s=0xfc000001 -c=10
    cmp     r0, r3
; fc00
    mov     ip, r0
; fc00
    movw    r0, #0x3fcc
    movt    r0, #0xfc00
    bx      lr

= 0xfc003fcc
The IV is probably the same as all the previous cameras, you can check if it is present by searching in a hex editor.

The dancing bits should be referenced by diskboot loading code, similar to earlier generation cams.

Quote

Also is possible with capdis to look for at the end of rom for levent tables for example?

I'm not sure what you mean. capdis only does disassembly. finsig_thumb2 should find the levent table.

Quote

EDIT: Also not sure about the validity of (0x4ffc)=0x12345678; from g7x since it does not not appear in sx720 fw

Look at the startup code equivalent to g7x

Code: [Select]

"    bl      sub_fc0781f4\n" // power-on mode handling & startupchecks here, no override needed with 0x12345678 set

In g7x, this calls the function sub_fc0bda32 which checks for the 0x12345678 value. If the equivalent exists on your cam, I would guess it's the same. Note on G7x without this code, diskboot would start OK if I held the button down. Just clicking boots and immediately shuts down, due to checks in the firmware finding no buttons pressed and the flag not set.

Logged

Don't forget what the H stands for.