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).
