G7X II - need help finding led details. - page 2 - General Discussion and Assistance - CHDK Forum

G7X II - need help finding led details.

  • 30 Replies
  • 719 Views
*

Offline srsa_4c

  • ******
  • 3890
Re: G7X II - need help finding led details.
« Reply #10 on: 08 / May / 2019, 19:41:41 »
Advertisements
The store operation to 0xc1001f00 hangs the camera - I can blink the LED before this instruction; but not after.
You can find some clues in ML, qemu branch. contrib/qemu/eos.c for example:
Code: [Select]
    { "Interrupt",    0xC1000000, 0xC100FFFF, eos_handle_intengine_gic, 7 },/* D7 */The source mentions a CortAProgGuide.pdf which can be found on the 'net.
Some other thoughts:
- since the bootloader is DryOS, could it be that both cores are active when the diskboot is started?
- perhaps looking at an updater (from a Canon D7 fw upgrade) could be helpful

*

Offline srsa_4c

  • ******
  • 3890
Re: G7X II - need help finding led details.
« Reply #11 on: 09 / May / 2019, 12:34:26 »
I extracted the g7x2 updater from the official fw update package. It surely uses 2 CPU cores as both CreateTask routines are present in the binary and both are used.
So, I'd look for differences between the main fw startup and the updater's startup, up to the point where the offending function is called. For example, the updater's taskcreate_Startup doesn't call an equivalent of sub_E0020848.
Somewhat related post from the ML forum.

D7 cameras have two CreateTask variants: the one exported as eventproc and the other that (I believe) allows restricting the task to one core. The sigfinder is only aware of the strict version of the latter (CreateTaskStrictly_alt), but fails to identify it on the g7x2.
On g7x2 101a and 101b (identical main fw), the one-core variant of CreateTask is at 0xDFFC95D8, strict version is at 0xDFFCA1EE.

*

Offline philmoz

  • *****
  • 3103
    • Photos
Re: G7X II - need help finding led details.
« Reply #12 on: 09 / May / 2019, 17:17:11 »
Thanks srsa_4c. Plenty to look at; but not going to be easy - a bit beyond my knowledge level right now.


If it would help I can put what I've got into SVN in case someone else can look at it.


EDIT: small progress, I can create a task that blinks the LED; but the CHDK boot code fails somewhere and the Canon GUI never starts.
« Last Edit: 10 / May / 2019, 04:20:05 by philmoz »
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)

*

Offline srsa_4c

  • ******
  • 3890
Re: G7X II - need help finding led details.
« Reply #13 on: 10 / May / 2019, 13:19:04 »
I can put what I've got into SVN in case someone else can look at it.
Sounds good.
Quote
EDIT: small progress, I can create a task that blinks the LED; but the CHDK boot code fails somewhere and the Canon GUI never starts.
I'd probably try the alternative CreateTask for CHDK tasks.
I had to use a workaround in the m10 port, booting failed when SpyTask was started too early. I could never find out the reason, the romlog contained a weird exception.

For those who might be following, I have updated the fi2 decoder source so it now works on 64-bit machines. Link in my previous post.


*

Offline philmoz

  • *****
  • 3103
    • Photos
Re: G7X II - need help finding led details.
« Reply #14 on: 10 / May / 2019, 19:18:24 »
I can put what I've got into SVN in case someone else can look at it.
Sounds good.
Quote
EDIT: small progress, I can create a task that blinks the LED; but the CHDK boot code fails somewhere and the Canon GUI never starts.
I'd probably try the alternative CreateTask for CHDK tasks.
I had to use a workaround in the m10 port, booting failed when SpyTask was started too early. I could never find out the reason, the romlog contained a weird exception.

For those who might be following, I have updated the fi2 decoder source so it now works on 64-bit machines. Link in my previous post.


The alternate CreateTask gives the same result. Taking out the task create just gives me a blank screen, no button response, no shutdown or debug crash :(


I tried putting a call to DebugAssert in the code to see where it gets too. The camera shuts down; but I don't get the assert showing as being in my code.
The ROMLOG output is weird with the PC being in low RAM.


Not sure if this gives any clues. When I look for WdtPU1Check in the code it is created as a task with a whole seperate bunch of routines, a different CreateTask function (0xe120c2e0), etc.
The task address is also in RAM (0x26a45); but the ram content initialisation in the E0020000 startup code does not seem to copy code to this area.



Exception!! Vector 0x04
Occured Time  2019:05:11 08:09:07
Task ID: 4587529
Task name: WdtPU1Check
Exc Registers:
0xFFFFFAC4
0xAAAAA2AA
0x0000000A
0xAAAA2AAA
0x00008001
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x005CF620
0xE04F0DE1
0x0000805C
0xA00000F3
StackDump:
00000250: *** Camera Log Start ***
 
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)

*

Offline srsa_4c

  • ******
  • 3890
Re: G7X II - need help finding led details.
« Reply #15 on: 10 / May / 2019, 19:50:41 »
I tried putting a call to DebugAssert in the code to see where it gets too. The camera shuts down; but I don't get the assert showing as being in my code.
The ROMLOG output is weird with the PC being in low RAM.
That's pretty weird. At this point, I'd dump (all accessible) RAM from Canon Basic and look for clues (where are the stacks, what's in them).
I don't know what uses the code around and above 0xe1000000 (could it be that the D6 secondary ARM core has evolved into another dual-core unit?), but would be good to know what's running when the cam is working.
There is another copy of WdtPU1Check, in the lower part of ROM.

*

Offline srsa_4c

  • ******
  • 3890
Re: G7X II - need help finding led details.
« Reply #16 on: 11 / May / 2019, 05:10:00 »
Now that I see the source, it occurred to me that our diskboot's startup does a lot before starting to execute the platform's boot() function.
To me, the main firmware's start looks like it is expected to be executed by both cores. This check
Code: [Select]
            "    mrc     p15, #0, r5, c0, c0, #5\n"
            "    ands    r0, r5, #0xf\n"
is for determining the current core's ID (0 or 1).
So, any code before OS start should support parallel execution. Minimizing the amount of CHDK stuff at start may help (until we know what's safe and what is not). Perhaps only do the blob copy on one core, somehow (the main fw also restricts that to one core).
edit:
Setting both core's SP to the same (shared) address also seems problematic to me.
edit2:
To find out whether both cores are executing diskboot, you could make separate blinkers (separate LEDs) for each core.
« Last Edit: 11 / May / 2019, 05:31:50 by srsa_4c »

*

Offline philmoz

  • *****
  • 3103
    • Photos
Re: G7X II - need help finding led details.
« Reply #17 on: 11 / May / 2019, 06:10:43 »
Now that I see the source, it occurred to me that our diskboot's startup does a lot before starting to execute the platform's boot() function.
To me, the main firmware's start looks like it is expected to be executed by both cores. This check
Code: [Select]
            "    mrc     p15, #0, r5, c0, c0, #5\n"
            "    ands    r0, r5, #0xf\n"
is for determining the current core's ID (0 or 1).
So, any code before OS start should support parallel execution. Minimizing the amount of CHDK stuff at start may help (until we know what's safe and what is not). Perhaps only do the blob copy on one core, somehow (the main fw also restricts that to one core).
edit:
Setting both core's SP to the same (shared) address also seems problematic to me.
edit2:
To find out whether both cores are executing diskboot, you could make separate blinkers (separate LEDs) for each core.


Whew - that's going to take some time to digest :)


There appears to be another boot block at 0xE1200000.
The code in the firmware update file looks more like this one than the one at 0xE0020000.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)


*

Offline philmoz

  • *****
  • 3103
    • Photos
Re: G7X II - need help finding led details.
« Reply #18 on: 11 / May / 2019, 18:54:13 »
Link to FW dump for G7X II 101a.


I've also included a dump of the first 16MB of RAM in case there are any clues in there.


https://drive.google.com/open?id=14lTK3yQ8Eeo4OljayID2nSHEeMVPeHrm
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)

*

Offline srsa_4c

  • ******
  • 3890
Re: G7X II - need help finding led details.
« Reply #19 on: 18 / May / 2019, 07:39:21 »
There appears to be another boot block at 0xE1200000.
The fw update does contain a ~266kB blob that goes to this address, but I did not disassemble it yet.

Have you tried starting the main firmware without running any CHDK code, like this:

entry.S in loader:
Code: [Select]
.section .entry
// ordinary startup...
.code 16
.align 2
.syntax unified
    mov     r0, 0x300000            // some uninitialized RAM, hopefully retaining content after restart
    ldr     r1, [r0]
    mov     r2, 0xd15c              // marker
    cmp     r2, r1
    beq     already
    str     r2, [r0]
    ldr     r0, =0xe0020001
    bx      r0
already:
    mrc     p15, 0, r0, c0, c0, 5   // read current core id
    ands    r0, r0, #0xf
    b       blink

main.c in loader:
Code: [Select]
void blink(int c)
{
    // GPIO base = 0xD2080000
    // 0xD20801E4   - SD led
    // 0xD20801E8   - AF led

    volatile int* p = (int*)0xD20801E4;
    if (c)
    {
        p = (int*)0xD20801E8;
    }
    *p = 0x24D0002;

    // blinker
    int i;
    while (1)
    {
        *p = 0x24D0002;
        for(i=0;i<10000000;i++) {
            asm volatile(
            "nop\n"
            );
        }
        *p = 0x24C0003;
        for(i=0;i<10000000;i++) {
            asm volatile(
            "nop\n"
            );
        }
    }
}
The marker is for protection against a diskboot boot-loop (address chosen seems uninitialized in RAM-dump, may need to be uncached), both named LEDs should blink if test is successful.

 

Related Topics