chdk in the DIGIC6 world - page 9 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 4 5 6 7 8 [9] 10 11 12 13 14 ... 21   Go Down

chdk in the DIGIC6 world

  • 201 Replies
  • 138076 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: chdk in the DIGIC6 world
« Reply #80 on: 26 / June / 2016, 18:57:07 »
Advertisements
I think I found the API provided by the Zico/Mzrm firmware.
As mentioned previously, the main ARM core uses a messaging-based method to communicate with Zico.
Messages have an ID. This is recognizable on the ARM side code, and, as it turns out, on the Xtensa side too.
The 0xbff0xxxx area is used on both sides for communication. My guess is that the data doesn't necessarily has to fit there, multiple megabytes from RAM are assigned for display related data (which are visible from both cores).

Here is an excerpt from the Xtensa side (sx280) that shows how message IDs are associated with message handler functions.

Code: [Select]
...
80a2c1d0:   movi    a11, 226
80a2c1d3:   bgeu    a11, a3, loc_80a2c23a          ; branch if a3 <= 226
80a2c1d6:   l32i.n  a15, a1, 0
80a2c1d8:   movi.n  a10, 8
80a2c1da:   l32i.n  a11, a7, 0
80a2c1dc:   l32r    a12, 0x80a29400 ; *"ID Error[%d] -- msg:0x%08x"
80a2c1df:   mov.n   a13, a2
80a2c1e1:   mov.n   a14, a3
80a2c1e3:   l32r    a8, 0x80a1d4e8  ; (loc_bff209f0)
80a2c1e6:   callx8  a8
...
loc_80a2c23a
80a2c23a:   l32r    a8, 0x80a29404  ; (0x80a001d0) ; table of msg handler function pointers
80a2c23d:   addx4   a8, a3, a8                     ; calculate offset (a3 = a8 + a3 * 4)
80a2c240:   l32i.n  a8, a8, 0                      ; load function pointer
80a2c242:   callx8  a8                             ; execute it
...
The ID -> name association list is attached to my previous post due to size limitation. I have extracted the function pointers starting from 0x80a001d0, and used a script to extract the debug strings (which appear to be function names) from the disassembly of the 0x80a00000 area.


The 0xbff20000 area is Xtensa code, the 0xbff00000 area has only data. RAM starting at 0xd80000 is used for Xtensa variables. Pointers to 0x41xxxxxx and 0x42xxxxxx addresses can be found in Xtensa-related data, my guess is that those parts of RAM are dedicated to overlay related stuff.

Update disassembler script is attached (it has not become "wiser", but it now has options that can aid disassembly).
The other script can be used to get the names of the message handler functions.
Logged
*

Offline zweistein68

  • *
  • 29
Re: chdk in the DIGIC6 world
« Reply #81 on: 27 / June / 2016, 15:55:32 »
Thanks for the advice.
for G7x: RAM location 0x0000bc24 contains a value greater than two while video recording.
I did not find a location where it is zero when not recording.
 
For a sample rate of one-per-second, are you programming the HP timer directly with that interval or do you use a series of smaller intervals ?
If just a single interval surely that is at or beyond the timer limit and will cause a crash ?


Zweistein
Logged
*

Offline reyalp

  • ******
  • 13947
Re: chdk in the DIGIC6 world
« Reply #82 on: 09 / July / 2016, 22:19:26 »
Quote from: zweistein68 on 27 / June / 2016, 15:55:32
Thanks for the advice.
for G7x: RAM location 0x0000bc24 contains a value greater than two while video recording.
I used 0xbbb4. In my testing, it's 0 when not recording, 1 when recording or "busy" after stopping. See svn 4657-4658.

It seems related to the variable srsa_4c used on sx280, but the code is a bit different.
Logged
Don't forget what the H stands for.
*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: chdk in the DIGIC6 world
« Reply #83 on: 15 / July / 2016, 18:25:03 »
Some findings about display on DIGIC 6:

We've managed to print something on 80D display from bootloader, and also emulated Canon's firmware update messages in QEMU (such as "firmware file not found"). The 80D has the strings mentioned here, such as OpenGL, Marius, Omar and Zico.

The bitmap overlay format - from bootloader - is very similar to the one in DIGIC 4 and 5: 8-bit palette bitmap, 720x480. The older cameras use 4-bit palette bitmap, that's the only significant difference.

So, the DIGIC 6 can display palette-based bitmaps without doing anything about Zico.

Didn't try to display anything from main firmware yet.

QEMU changeset for DIGIC 6 display emulation: https://bitbucket.org/hudson/magic-lantern/commits/35c71dc50ed8
Logged
*

Offline reyalp

  • ******
  • 13947
Re: chdk in the DIGIC6 world
« Reply #84 on: 17 / July / 2016, 02:04:51 »
Quote from: srsa_4c on 26 / June / 2016, 18:57:07
I think I found the API provided by the Zico/Mzrm firmware.
As mentioned previously, the main ARM core uses a messaging-based method to communicate with Zico.
Messages have an ID. This is recognizable on the ARM side code, and, as it turns out, on the Xtensa side too.
This is great work :)

I finally got around to looking at the g7x a bit. Message handler list attached. I'm not sure about the total number of handlers.
It's recognizably similar to sx280, but there's are quite a few differences.

On g7x, the "ID Error[%d] -- msg:0x%08x" is around bff25a3d, not in the 0x80a... code

I've been thinking about using the names from the list to identify the calls on the in the main ARM code disassembly with some combination of finsig / capdis and the message list.

I got an xtensa capable objdump working on mingw, using binutils-2.26 and with minor modification to the script you linked earlier (http://pete.akeo.ie/2011/04/quick-and-dirty-script-to-compile.html) I only had to add zlib to the list of things to build, and remove -j4
Logged
Don't forget what the H stands for.
*

Offline Ant

  • *****
  • 509
Re: chdk in the DIGIC6 world
« Reply #85 on: 22 / July / 2016, 10:30:39 »
Quote from: reyalp on 22 / May / 2016, 15:12:05
The respective Dryshell prompts are Dry[MARIUS]>, Dry[OMAR]> and Dry[ZICO]>, where pre-digic 6 cams just have Dry>

On my EOS M3 I can switch only between Dry[MARIUS] and Dry[OMAR]. You can see their tasks in attachment.
Logged
*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: chdk in the DIGIC6 world
« Reply #86 on: 19 / August / 2016, 06:00:11 »
Quote from: srsa_4c on 29 / August / 2015, 14:33:19
Some information about the ARM core that runs CHDK (sx280).
Cortex-R4, 16k D + 16k I cache, no MMU.
Source.

Small addition to cpuinfo_v7.c (SCTLR, MPIDR, ACTLR, ACTLR2, CPACR).

7D2 results: SCTLR 0x08E5187D, ACTLR 0x00000020, others zero (source).
« Last Edit: 19 / August / 2016, 06:04:47 by a1ex »
Logged
*

Offline reyalp

  • ******
  • 13947
Re: chdk in the DIGIC6 world
« Reply #87 on: 20 / August / 2016, 19:48:23 »
Quote from: a1ex on 19 / August / 2016, 06:00:11
Small addition to cpuinfo_v7.c (SCTLR, MPIDR, ACTLR, ACTLR2, CPACR).

7D2 results: SCTLR 0x08E5187D, ACTLR 0x00000020, others zero (source).
Thanks. I checked this into our trunk, along with decoding for SCTLR (I have trouble keeping track of that many bits :haha)

Updated G7X output attached.
SCTLR 0x48ED187D
ACTLR 0x00000020
Logged
Don't forget what the H stands for.
*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: chdk in the DIGIC6 world
« Reply #88 on: 21 / August / 2016, 14:20:10 »
Quote from: reyalp on 20 / August / 2016, 19:48:23
along with decoding for SCTLR (I have trouble keeping track of that many bits :haha)

Cool, so I just copied it without having to figure out how it works :haha
Logged
*

Offline reyalp

  • ******
  • 13947
Re: chdk in the DIGIC6 world
« Reply #89 on: 12 / November / 2016, 17:04:44 »
I started a wiki page http://chdk.wikia.com/wiki/Digic_6_Porting

There is a lot of useful information scattered over a number of long forum threads, mixed in with a lot of stuff that isn't relevant. My hope is to consolidate more current best practice in one place.

Additions and improvements are welcome.

Edit:
I also started putting category Digic 6 on d6 related pages and ports.
« Last Edit: 12 / November / 2016, 17:08:01 by reyalp »
Logged
Don't forget what the H stands for.
Pages: 1 ... 4 5 6 7 8 [9] 10 11 12 13 14 ... 21   Go Up
« previous next »
 

Related Topics