EekoAddRawPath

Started by a1ex, September 25, 2014, 04:11:05 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Andy600

Can we assume that DryOS 2.3 is likely in Digic4 cams too because the copyright notice is dated pre-Digic5? Those strings look VERY interesting!  ;D
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

a1ex


500D:   DRYOS version 2.3, release #0023
50D:    DRYOS version 2.3, release #0023
5D2:    DRYOS version 2.3, release #0023
A1100:  DRYOS version 2.3, release #0031
7D:     DRYOS version 2.3, release #0039
550D:   DRYOS version 2.3, release #0043
1100D:  DRYOS version 2.3, release #0047
1200D:  DRYOS version 2.3, release #0047
600D:   DRYOS version 2.3, release #0047
60D:    DRYOS version 2.3, release #0047
5D3:    DRYOS version 2.3, release #0049
650D:   DRYOS version 2.3, release #0049
700D:   DRYOS version 2.3, release #0049
EOSM:   DRYOS version 2.3, release #0049
100D:   DRYOS version 2.3, release #0051
6D:     DRYOS version 2.3, release #0051
70D:    DRYOS version 2.3, release #0051
5D4AE:  DRYOS version 2.3, release #0055
7D2M:   DRYOS version 2.3, release #0055
7D2S:   DRYOS version 2.3, release #0055
EOSM3:  DRYOS version 2.3, release #0055
750D:   DRYOS version 2.3, release #0057
760D:   DRYOS version 2.3, release #0057
1300D:  DRYOS version 2.3, release #0058
5D4:    DRYOS version 2.3, release #0058
80D:    DRYOS version 2.3, release #0058

Eeko:
100D:   DRYOS version 2.3, release #0044
5D3:    DRYOS version 2.3, release #0044
650D:   DRYOS version 2.3, release #0044
6D:     DRYOS version 2.3, release #0044
700D:   DRYOS version 2.3, release #0044
70D:    DRYOS version 2.3, release #0044
EOSM:   DRYOS version 2.3, release #0044

Eeko maybe:
750D:   DRYOS version 2.3, release #0055
760D:   DRYOS version 2.3, release #0055

Levas

That last list of cameras, Eeko: Dryos...looks like digic 5

a1ex

Eeko dumper:

void (*EekoBltDmac_copy)(int zero, uint32_t dst, uint32_t src, uint32_t size, void* cbr, int arg)
    = (void*) 0xFF3B940C;   /* 5D3 1.1.3 */

call("StartupEeko");
void * buf = malloc(0x8000);

dump_seg((void*)0x1E00000, 0x140000, "1E00000.DMP");

EekoBltDmac_copy(0, (uint32_t)buf, 0xD0288000, 0x8000, ret_0, 0);
dump_seg(buf, 0x8000, "D0288000.DMP");

EekoBltDmac_copy(0, (uint32_t)buf, 0xD0280000, 0x8000, ret_0, 0);
dump_seg(buf, 0x8000, "D0280000.DMP");

free(buf);
call("TerminateEeko");

a1ex

Compared dumps before / after / 1 second after starting the Eeko core, 2 attempts:

- 1E00000-1E80000: identical in all 6 attempts
- 1E80000-1EE0000: some differences (data RAM?)
- 1F28C4C int32: changed at every experiment (timer?)
- 1F20C50 int32: before 0, after 0xFF55AA00
- 1F27840-1F28000: before FF, after 0
- D0280000 (mapped to 0x40000000)
  - before:
     - D0280000-D02801BE: identical in both attempts
     - many differences until D0288000 (noise?)
  - after:
     - D0280000-D0280080: small changes
     - D0280080-D0282120: identical (populated during startup)
     - D0282120-D0284000: noise
     - D0284000-D0288000: identical to D028C000-D0290000
- D0288000 (mapped to 0):
  - D0288000-D028EB8C: identical in all 6 attempts
  - D028EB8C-D0290000: noise
  - attempt to dump past D0289000 => camera lockup

tron

Sorry for being half-off topic but what is with 5D4AE vs 5D4 and 7D2S vs 7D2M ?

nikfreak

Just guessing:
AE - Autofocus Engine
S - Slave (CPU)
M - Master (CPU)
[size=8pt]70D.112 & 100D.101[/size]

tron


g3gg0

if someone wants to run own code on EEKO, there is some example:


static void run_test()
{
    uint32_t eeko_ram = 0xD0288000;
    uint32_t eeko_ram_counter = eeko_ram + 0x10;
   
    console_clear();
    console_show();
   
    printf("Init...\n");
    MEM(0xC0223210) = 0x7E;
    MEM(0xC022320C) = 0x06;
   
    /*
      now run this code:
     
        mov r0, 0x10
        mov r1, 0

        @loop:
        add r1, #1        [1 clocks]
        str r1, r0, 0     [1 clocks]
        b @loop           [3 clocks]
       
        -> 5 cpu clocks per loop

    */
    uint32_t clocks = 5;
    memcpy32(eeko_ram, "\x10\x20\x00\x21\x01\x31\x01\x60\xFC\xE7", 10);
   
    printf("Boot...\n");
    MEM(0xC022320C) = 0x07;
   
    printf("Measure...\n");
    uint32_t old_val = 0;
    while(1)
    {
        uint32_t new_val = MEM(eeko_ram_counter);
        uint32_t delta = new_val - old_val;
        uint32_t freq = delta * clocks / 10000;
       
        printf("speed: %d/sec -> %d.%d MHz\n", delta, freq / 100, freq % 100 );
        old_val = new_val;
        msleep(1000);
    }
}


please remind that the code boots in thumb mode.

thinking about how to speed up things using eeko. not that simple because in video mode it is highly used.
probably useful to speed up raw playback, but i'd prefer a engine solution instead of CPU.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

a1ex

I have a feeling Omar (secondary DryOS core from DIGIC 6) might be the equivalent of Eeko on D5.

Why?

- they are initialized in a similar way, from the main core, on request - unlike 7D, where both cores start at power on and they wait for each other
- communication is done using "postman" routines (same name used for Eeko)
- startupPrepareCapture is waiting for it at startup, so it must have some important role in image capture and/or processing
- interrupts used 0xd, 0x2d, 0x4d, 0x6d, 0x1c, 0x3c, 0x5c, 0x7c, 0xcd, 0x9c, 0xbc, 0xdc, 0xfc (exact meaning unknown, but they follow a similar pattern).

80D:

[ROM-DMA0] at OmarI:FE1DA5EC:FE1DA6E9 [0xD6030000] -> 0x10000000: ???
[ROM-DMA1] at OmarI:FE1DA288:FE1DA273 [0xD6030040] <- 0x46FF    : count
[ROM-DMA1] at OmarI:FE1DA292:FE1DA273 [0xD6030044] <- 0xFE88871C: srcAddr
[ROM-DMA1] at OmarI:FE1DA29C:FE1DA273 [0xD6030048] <- 0xDFF00000: dstAddr
[ROM-DMA1] at OmarI:FE1DA2A6:FE1DA273 [0xD603004C] <- 0x30F00   : ???
[ROM-DMA1] at OmarI:FE1DA2B0:FE1DA273 [0xD6030050] <- 0x30F00   : ???
[ROM-DMA1] at OmarI:FE1DA2BA:FE1DA273 [0xD6030054] <- 0x2E8301  : ???
[ROM-DMA1] at OmarI:FE1DA2CC:FE1DA2C5 [0xD6030058] <- 0x11100003: Start DMA


More stuff coming soon.

a1ex

Omar blobs:


5D4 112:
dd if=ROM1.BIN of=00000000.BIN bs=1 skip=$((0x8762B8)) count=$((0x54D8))
dd if=ROM1.BIN of=80000800.BIN bs=1 skip=$((0x87B798)) count=$((0xE9A8))
dd if=ROM1.BIN of=01AC0000.BIN bs=1 skip=$((0x88A148)) count=$((0x98E0))
dd if=ROM1.BIN of=01AE0000.BIN bs=1 skip=$((0x893A30)) count=$((0x2B3460))

5D4 104:
dd if=ROM1.BIN of=00000000.BIN bs=1 skip=$((0x870EB8)) count=$((0x54D8))
dd if=ROM1.BIN of=80000800.BIN bs=1 skip=$((0x876398)) count=$((0xE8A8))
dd if=ROM1.BIN of=01AC0000.BIN bs=1 skip=$((0x884C48)) count=$((0x9878))
dd if=ROM1.BIN of=01AE0000.BIN bs=1 skip=$((0x88E4C8)) count=$((0x2B2460))

80D 102:
dd if=ROM1.BIN of=00000000.BIN bs=1 skip=$((0x888824)) count=$((0x4700))
dd if=ROM1.BIN of=80000800.BIN bs=1 skip=$((0x88CF2C)) count=$((0xE258))
dd if=ROM1.BIN of=01AC0000.BIN bs=1 skip=$((0x89B18C)) count=$((0xADE8))
dd if=ROM1.BIN of=01AE0000.BIN bs=1 skip=$((0x8A5F7C)) count=$((0x2898F0))


Other D6 models:

# this identifies Omar (secondary code) firmware blobs in DIGIC 6 cameras
#
# usage: scan_omar.py ROM1.BIN <srcAddr from OmarInit>
#
# Example for 5D4 112:
# ./run_canon_fw.sh 5D4,firmware="112" -d io |& grep srcAddr -a
# ...
# [XDMAC0] at OmarIni:FE26C802:FE26C7E3 [0xD6030014] <- 0xFE8762B8: srcAddr
#                                                       ^^^^^^^^^^
# python scan_omar.py 5D4/112/ROM1.BIN 0xFE8762B8

import os, sys
from struct import unpack

def getLongLE(d, a):
   return unpack('<L',(d)[a:a+4])[0]

d = open(sys.argv[1]).read()
a = int(sys.argv[2], 16) - 8
off = 0xFE000000

for i in range(4):
    target_addr = getLongLE(d, a - off)
    copied_size = getLongLE(d, a - off + 4)
    source_addr = a + 8
    print "dd if=ROM1.BIN of=%08X.BIN bs=1 skip=$((0x%08X)) count=$((0x%X))" % (target_addr, source_addr - off, copied_size)
    a = source_addr + copied_size