supplierdeeply
« previous next »
Pages: 1 ... 10 11 12 13 14 [15] 16   Go Down

chdk in the DIGIC6 world

  • 154 Replies
  • 67400 Views
*

Offline 62ndidiot

  • *****
  • 590
Re: chdk in the DIGIC6 world
« Reply #140 on: 24 / March / 2018, 20:09:51 »
Advertisements
Thanks. I'm out of practice.  Now at the stage of crashing and romlogs.
Trying to find which of 22 branches it takes.  Confining myself to the case of mode dial at video. HD 30 fps.
Logged
*

Offline 62ndidiot

  • *****
  • 590
Re: chdk in the DIGIC6 world
« Reply #141 on: 24 / March / 2018, 22:11:57 »
I think I have a problem.  In the SX60 100f firmware, the capdis disassembly doesn't terminate cleanly ..seems no matter what I do, soon after pressing the video button it crashes
/*************************************************************/
//capdis -f=chdk -s=0xfc1d46db -c=811 -stubs PRIMARY.BIN 0xfc000000

The last line is
"loc_fc1d4f78:\n"
"    add     sp, #0x24\n"
"    pop.w   {r4, r5, r6, r7, r8, sb, sl, fp, pc}\n"

however, there is branch to a location beyond the pop instruction, a little ways before..and that seems just go on and on as far as I can see.  Is there a way around this?   
"    cmp     r5, r1\n"
"    beq    loc_fc1d4f7e\n" // out of range.....
"    add.w   r1, sb, #0x80\n"

Can I just continue in ROM?
"loc_fc1d4f78:\n"
"    add     sp, #0x24\n"
"    pop.w   {r4, r5, r6, r7, r8, sb, sl, fp, pc}\n"
"loc_fc1d4f7e:\n"
"ldr pc, =0xfc1d4f7e\n"
".ltorg\n"

attaching some debug info.
Logged
*

Offline srsa_4c

  • ******
  • 3780
Re: chdk in the DIGIC6 world
« Reply #142 on: 25 / March / 2018, 07:06:24 »
Quote from: 62ndidiot on 24 / March / 2018, 20:09:51
I'm out of practice.
OK, I'll create a 100f movie_rec.c soon.
Logged
*

Offline 62ndidiot

  • *****
  • 590
Re: chdk in the DIGIC6 world
« Reply #143 on: 25 / March / 2018, 10:21:49 »
@srsa_4c I really appreciate your help, but one of the reasons I'm doing this is that "I am out of practice".  I guess I should extend the 811 lines until I can find a suitable place to continue in Rom or return (pop) with no unresolved branching? Worried it will get too big.
That being said I know the frustration of answering and guiding people when you know you could do it yourself  in your sleep so go ahead if you like.  😏
Logged
*

Offline srsa_4c

  • ******
  • 3780
Re: chdk in the DIGIC6 world
« Reply #144 on: 25 / March / 2018, 13:54:25 »
Quote from: 62ndidiot on 25 / March / 2018, 10:21:49
I guess I should extend the 811 lines until I can find a suitable place to continue in Rom or return (pop) with no unresolved branching?
You only need 3 more lines there. The firmware's optimized Thumb2 code tends to jump around more frequently than regular ARM.
BTW, if you do jump back to ROM, don't forget the thumb bit (like in your most recent code excerpt).

In the meantime, I changed the cocoa task related code again - the added assembly parts now use assembler "symbols" instead of having (repeated) addresses everywhere. Will publish the patch shortly. edit: done
« Last Edit: 25 / March / 2018, 14:21:05 by srsa_4c »
Logged
*

Offline 62ndidiot

  • *****
  • 590
Re: chdk in the DIGIC6 world
« Reply #145 on: 25 / March / 2018, 19:13:41 »
Quote
You only need 3 more lines there. The firmware's optimized Thumb2 code tends to jump around more frequently than regular ARM.
thanks, all seems to work now.
Logged
*

Offline srsa_4c

  • ******
  • 3780
Re: chdk in the DIGIC6 world
« Reply #146 on: 26 / March / 2018, 18:55:21 »
Quote from: 62ndidiot on 25 / March / 2018, 19:13:41
thanks, all seems to work now.
It's possible that your cam has a different high limit for bitrate. If the limit is lower than defined in movie_rec.c, attempts to increase bitrate can make the camera crash (first sign is that the recording time indicator remains zero after you start recording - it's best to remove the battery when that happens). The set_quality() function can be modified to make the search for bitrate limit a bit more comfortable.
Logged
*

Offline srsa_4c

  • ******
  • 3780
Re: chdk in the DIGIC6 world
« Reply #147 on: 26 / March / 2018, 18:59:17 »
Now, for something completely different.

I managed to make movie playback/recording work after FI2 boot, on my sx280.

Some background info (using sx280 102b addresses):
The task that inits the audio/video codec core (I'll call it avcore as I'm not sure how Canon calls it) is named TricInitTask. The function that does the initializaton at startup is sub_FC3740D0. What it does is the following:
- registers the core's interrupt handler (in sub_FC3B49C4)
- copies 3 firmware blobs to the core's assigned (uncached) RAM area (that's regular RAM, starts at 0xe00000 on this cam)
- calls a function that reads and writes a few MMIO registers in the 0xd2090000, 0xd20a0000, 0xd20c0000, 0xd20f0000 ranges
- makes sure the blobs reached the RAM
- sets the 0xd2020074 MMIO register to 0x801 (that register reads as zero on a clean boot before this operation)
After this, the core is assumed running its startup sequence.

The task then proceeds waiting for an eventflag (or either of 2 possible flags on later models), for up to 500 msecs (@FC373DD8). If the flag does not get set, it is considered an error: code at 0xFC373DF2 gets executed that leaves the following entries in the optional UART(?) log.
Code: [Select]
ER TYPE0x1000
ER CODE0x2004
The flag is normally set by the interrupt handler @FC3B4954. It is associated with a debug string: SmacIdleCmp. On later cams, the other flag's debug string is SmacLpIdleCmp.

Now, the issue we have on an FI2 boot is that the avcore is already set up and "running". It looks like the firmware does not attempt to disable it prior to setting it up.
On the sx280, the (re-)initialization does not seem to bother it. If I set that eventflag myself, TricInitTask succeeds and audio/video is decoded and encoded properly. (Warning: only set the eventflag if that core is already running. This can be detected by reading the 0xd2020074 MMIO register: it's nonzero when the core is up. Doing the eventflag manipulation is best done in TricInitTask).

So, the sx280 can be made to work with FI2.

Unfortunately, I can't test the method on my other D6 cam (M10), because it does not accept my FI2 files.

Later cameras do more stuff in their avcore initialization routines, I don't know if those affect the success of the method I found.
It would be great if anyone could try this workaround on other models (it involves hooking TricInitTask, plus doing the eventflag manipulation, as described above).
Logged
*

Offline reyalp

  • ******
  • 11706
Re: chdk in the DIGIC6 world
« Reply #148 on: 03 / June / 2018, 21:23:18 »
In trunk 5026 I updated the cpuinfo module with some ML code from @a1ex to output debug related registers. Both sx710 and g7x give the same output. sx710 output attached as a representative example.

I haven't looked at the details, they appear to be described in "ARM® Architecture Reference Manual ARMv7-A and ARMv7-R edition"

Also, comments in the ML source note that the MPU related parts of the cpuinfo code don't work on Digic 7 (presumably since it has an MMU)
Logged
Don't forget what the H stands for.
*

Online Ant

  • ****
  • 401
Re: chdk in the DIGIC6 world
« Reply #149 on: 04 / June / 2018, 11:13:35 »
Quote from: reyalp on 03 / June / 2018, 21:23:18
Both sx710 and g7x give the same output. sx710 output attached as a representative example.

EOS M3 also gives the same output:
https://chdk.setepontos.com/index.php?topic=9217.msg130449#msg130449
But there is no access to memory mapped debug registers.
Maybe this feature wasn't implemented by Canon?
Logged
Pages: 1 ... 10 11 12 13 14 [15] 16   Go Up
« previous next »
 

Related Topics