chdk in the DIGIC6 world - page 8 - General Discussion and Assistance - CHDK Forum  

chdk in the DIGIC6 world

  • 201 Replies
  • 161922 Views
*

Offline reyalp

  • ******
  • 14098
Re: chdk in the DIGIC6 world
« Reply #70 on: 13 / June / 2016, 01:56:58 »
Advertisements
I don't think I see any problems with your version. If you feel like it, you could just check it in.
Checked in, trunk 4642. Built all the affected ports, but haven't tested beyond that.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #71 on: 18 / June / 2016, 20:22:53 »
Some speculation about the 0xe00000 RAM area.

It seems to be shared between *some unknown cpu* and at least one of the ARM cores.

I have reasons to believe that *some unknown cpu* might be an xtensa:
- the 0xe00000 area has those extensa specific error strings (the mzrm area doesn't, despite proven to be xtensa)
- the instruction set is clearly not based on pure or mixed 16 or 32 bit instructions (byte patterns show this)
- there is evidence of word alignment (where needed) and gaps prior to aligned blocks are filled with zero bytes (just like in the mzrm firmware)

The catch is - the instructions are encoded differently. This doesn't seem like 'just some added custom instructions' which is advertised in the xtensa literature, it seems to affect the whole instruction set.

The other xtensa firmware typically has functions which look like:
entry instruction
...
retw instruction, usually retw.n (encoded as 0x1d, 0xf0 bytes)


Return value is passed back in the a2 register, for example:
80a1c1d1:   0c02                    movi.n  a2, 0
80a1c1d3:   1df0                    retw.n

The retw.n instruction is often found at the end of function and it is often followed by padding zero bytes.

Based on this observation, I believe that the core assigned to the 0xe00000 area uses the 0xd1, 0x0f byte sequence as retw.n. I first thought that simply exchanging the nibbles in bytes will decypher the instructions, but this doesn't seem to be the case - it surely doesn't work for 24 bit instructions.
For 16 bit instructions, it may or may not work. For example, following seems reasonable (after nibble swap, address is arbitrary):
   14690:   2c42                    movi.n  a2, 36
   14692:   1df0                    retw.n


Integers found in this area appear to be stored in big endian byte order.

Conclusion:
It appears to me that free (video) bitrate adjustment won't be possible on DIGIC 6, due to reasons described above.
Unless someone manages to decypher the instruction set.


For the sx280, ARM-related stuff seems to begin around 0xe54400 (I would have expected a nice round starting address, but found this instead).

*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #72 on: 19 / June / 2016, 14:41:10 »
Attached is a semi-usable (work-in-progress) disassembler script for xtensa dumps.
It needs GNU 'strings' and an objdump binary that understands xtensa.

It has lots of weaknesses, for example
- the code is horrible
- disassembly can become easily derailed because it does not recognize padding bytes
...

I have also found an alternative (written in Python but also requires objdump) that seems a bit more intelligent when it comes to padding bytes. Unfortunately, it needs a user-supplied list to recognize functions and data.
https://bitbucket.org/foogod/xtobjdis

edit:
attachment removed
« Last Edit: 26 / June / 2016, 18:59:36 by srsa_4c »

Re: chdk in the DIGIC6 world
« Reply #73 on: 22 / June / 2016, 09:13:43 »
Could you give detailed advice as to how a suitable ram location can be found for the G7x including what tool to use and any precautions that need to be taken ?
 
Thanks


*

Offline reyalp

  • ******
  • 14098
Re: chdk in the DIGIC6 world
« Reply #74 on: 22 / June / 2016, 15:52:28 »
Could you give detailed advice as to how a suitable ram location can be found for the G7x including what tool to use and any precautions that need to be taken ?
Suitable RAM location for what?
Don't forget what the H stands for.

Re: chdk in the DIGIC6 world
« Reply #75 on: 22 / June / 2016, 16:41:15 »
movie_status substitute

*

Offline reyalp

  • ******
  • 14098
Re: chdk in the DIGIC6 world
« Reply #76 on: 22 / June / 2016, 17:10:51 »
movie_status substitute
Since srsa_4c has already found one for sx280, I'd suggest finding where it is referenced in the sx280hs disassembly, and looking for the equivalent code in the g7x disassembly.
Don't forget what the H stands for.

Re: chdk in the DIGIC6 world
« Reply #77 on: 23 / June / 2016, 09:13:31 »
Thanks, but as I do not have a suitable disassembler I thought srsa-4c's 'ram snooping' method would be easier.
Could you provide details of that ?
Thanks.


*

Offline reyalp

  • ******
  • 14098
Re: chdk in the DIGIC6 world
« Reply #78 on: 23 / June / 2016, 16:21:08 »
Thanks, but as I do not have a suitable disassembler
FWIW, I used http://chdk.wikia.com/wiki/User:Srsa_4c/GPL:disassemblev7.pl and capdis (in the tools directory) for all of the g7x port. Both are very affordable 8)

I would not recommend attempting to work on a port without a full disassembled dump.

See this thread for information about capdis https://chdk.setepontos.com/index.php?topic=12714.0
and https://chdk.setepontos.com/index.php?topic=12532.msg127059#msg127059 for commands to disassemble a whole dump (g7x addresses are be different)

Quote
I thought srsa-4c's 'ram snooping' method would be easier.
Could you provide details of that ?
Look for a location in memory location that changes from 0 to nonzero when you start recording. Unfortunately, there are a lot of variables that change from 0 to other values frequently.

I'm not sure what techniques srsa uses for this, but you can dump RAM (either in chdk or using chdkptp) and compare the resulting files in a hex editor or other program that allows diffing binaries.

You don't have to dump the whole RAM, for variables the data and bss should be sufficient (0x8000 to 0x36a354 on g7x) You might narrow down likely suspects with some knowledge of where other video related variables appear.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #79 on: 25 / June / 2016, 09:55:48 »
I'm not sure what techniques srsa uses for this, but you can dump RAM
I used the rmem command of chdkptp on the area of interest, and then I made a verification on the candidate variable with this.

Quote
You might narrow down likely suspects with some knowledge of where other video related variables appear.
I used the disassembly of task_MovieRecord. It has a block of variables (likely a struct), the address of which can be worked out by looking at the first few disassembled lines.
Code: [Select]
; task_MovieRecord 0xfc14cd13
fc14cd12: e92d 5fff push.w {r0, r1, r2, r3, r4, r5, r6, r7, r8, sb, sl, fp, ip, lr}
fc14cd16: f8df a050 ldr.w sl, =0x0000bb3c ; [pc, #80] (0xfc14cd68)
fc14cd1a: f04f 0901 mov.w sb, #1
fc14cd1e: f04f 0800 mov.w r8, #0
fc14cd22: f241 3b21 movw fp, #0x1321
fc14cd26: f50a 7696 add.w r6, sl, #0x12c
fc14cd2a: f1a6 0480 sub.w r4, r6, #0x80
fc14cd2e: f5a6 7780 sub.w r7, r6, #0x100
fc14cd32: f5a4 7580 sub.w r5, r4, #0x100
I'd start at 0xbb3c+0x12c-0x80-0x100 and dump ~512 bytes.


edit:
Attachment of the next post is attached here.
« Last Edit: 26 / June / 2016, 18:58:23 by srsa_4c »

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal