Magic Lantern Forum

Developing Magic Lantern => Camera-specific Development => Topic started by: feedrail on June 12, 2017, 07:05:50 AM

Title: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: feedrail on June 12, 2017, 07:05:50 AM
Ive used ML on my t2i for years and loved it, now I want to do my part and bring ML to my t7i. Point me in the right direction and a few do's and don't s and I'll do whatever I can. I had some coding years ago vb+, c++, java. I don't know it that will be any use but I'm willing and want to try.

(was: Newbie Here wantingg to help on 800d)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on June 12, 2017, 10:40:26 AM
A few days ago I've tried to find the LED address on a 77D (also digic 7), on IRC, without success. If you want to try the same steps, just get in touch with me.

The good news is that we can run code on the camera. The next step would be to produce some sort of side effects (such as LED blinks, or even variations in power consumption, that can be noticed with a multimeter).

What we know about D7 can be found on the EOS M5 (https://chdk.setepontos.com/index.php?topic=13014.0) thread, but that model runs PowerShot firmware. It's very likely a dual-core Cortex A9, with MMU, and runs Thumb-2 code (therefore, we might have some luck matching code patterns from some D6 models).

Caching issues (not yet solved on D6) are probably similar (that is, once it's solved for one model, it will very likely apply to all others).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: GabrielJLozano on September 08, 2017, 07:59:13 AM
So I tried looking all over the forums and the only information I could find about anyone even remotely talking about working on the t7i is this thread. Is anyone trying to port it at all? I'd love to help as well so long as someone points me in the right direction.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on September 08, 2017, 09:24:38 AM
Read the post above yours.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on September 08, 2017, 09:47:36 AM
Some of the easier things you can do to help, in order of increasing difficulty:

- wait for a firmware update
- open your camera and take high-resolution pictures of the mainboard
- hook a multimeter / Arduino / oscilloscope / whatever to an external power supply (see above)
- find some UART (https://www.magiclantern.fm/forum/index.php?topic=7531) or JTAG (https://nada-labs.net/2014/finding-jtag-on-a-canon-elph100hs-ixus115/) port and attempt to communicate with it
- read the Cortex A9 manuals and the PowerShot ROM dumps (CHDK forum), then suggest things to try running on the camera, in order to get any kind of side effects (LED blinks, display activity, writing to SD, variations in power draw)

If you want to run your own code on the camera, I recommend starting from either recovery or digic6-dumper branches. However, you'll need to sign the code, and the tools for doing that are not public, but I can help with that - just drop me a PM.

Good luck!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: A8M on December 03, 2017, 02:40:09 AM
Okay.  Just got off the phone with Canon.  No good news.  According to their techs, the company has NO PLANS to release a firmware update for this model until 2019!!!  Could be a lie, but if it is, the company's personnel told it.  Sucks to be us I guess as the new kids on the block.

Having said that, is it still possible to go forward and try to figure out a ML for this model?  I'm somewhat skeptical it will happen since the T6i hasn't had any good luck thus far, along with other models that have been out there on the block longer than this one with the newer chipsets.  Al3x has already said he isn't going to invest the time/energy into building newer model MLs from scratch leaving the burden on others, but most of us are just not coders/assemblers/hackers like that.  At most I think you have more script kiddies at the site's disposal than actual hardcore coders that know enough C++, Python, or Linux enough to be viable.  If I had 2 of these I'd be willing to try, but with only one as my daily driver for projects I can't afford a brick tinkering with it.   

I've trolled a little bit in the forums trying to see if there were any people actively figuring this out and so far there hasn't been a lot of discussion threads about the 800D.  But from what I've seen this is all I've been able to answer:
1.  Chipset is Digic7.  Haven't found on the forums yet whether or not there is a specific dumper for this digic, as what digic6 has.
2.  Can't open the camera to take pics of the hardware; don't have the right bits for these screws and that's sad considering I tried 25 different pieces.
3.  Dont have a  multimeter / Arduino / oscilloscope / whatever to hook to an external power supply.
4.  JTAG port can't say yay or nay because of #2. 







Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: TheCallumP on December 29, 2017, 12:52:09 AM
Is there a version of ML that can be used with this camera? I bought this camera for content creation not realising that it doesn't offer a clean HDMI output ('clean' in the respect that it hides all of the on-screen information). I literally have everything set up, but could not for the life of me figure out a way to hide the on-screen information...until I found Magic Lantern. Sadly, I've found that my camera is not supported.

Are there any plans to support this camera, or is there a version that I can use that will work with my 200D? Sorry if either of these are dumb questions, I'm completely new to this and am grasping at straws here.

Many thanks.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on December 29, 2017, 05:28:21 PM
Short A: No.

Long A:
There is no such thing as project management, masterplan, schedule in ML development. If someone takes up the task of porting a cam it's a start. But again: That's not a promise you will see a port going "full ML" at a given time or at all.
At time of writing there are serious efforts to port ML to cams housing Digic 6 processors. But 200D doesn't run on Digic 6 but Digic 7. And porting ML to an unknown processor generation is a very hard task to master.
And dev time is sparce. Devs made it pretty clear they will help in development for new ports but do not have the time to maintain newer cams. Each and every cam needs a maintainer for long time support.


My general advice: If there is no ML port for your cam act like there will be no ML for your cam ever.

Or you have a spare dev at hand: Skilled in embedded devices (preferable ARM architecture), assembler and C programming. And some time to waste.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: TheCallumP on December 29, 2017, 05:52:21 PM
Thank you for taking the time to respond, I appreciate it. Bummer, but totally understandable. 

Are there any alternatives to ML that I may be unaware of? Literally all I'm looking for is a way to turn off the on-screen overlay entirely.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: dfort on December 30, 2017, 01:28:52 AM
This is the least expensive of the Digic 7 DSLR's.

Would asking for a ROM dumper be unreasonable? Maybe Digic 7 code isn't all that different from Digic 6?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on December 30, 2017, 01:37:13 AM
Answered at http://www.magiclantern.fm/forum/index.php?topic=19737.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: deathline on January 16, 2018, 10:38:03 PM
Quote from: a1ex on December 30, 2017, 01:37:13 AM
Answered at http://www.magiclantern.fm/forum/index.php?topic=19737.

Canon released a firmware update for eos 200d but Firload can't decrypt it.Is another solution is avaible?

http://gdlp01.c-wss.com/gds/8/0400003508/01/v101-sl2-200d-x9-win.zip (http://gdlp01.c-wss.com/gds/8/0400003508/01/v101-sl2-200d-x9-win.zip)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on January 20, 2018, 12:27:49 AM
Dual-core Cortex A9 (just like M5). The firmware is still based on the EOS codebase and doesn't look too different from DIGIC 6.

Main firmware: 0xE0040000, starts as Thumb, entry point code different from D6.
Bootloader: no idea how it looks like, we'll need to run some code blindly until we manage to dump its contents.
MPU (http://www.magiclantern.fm/forum/index.php?topic=17596.0) (microcontroller) present (similar to other EOS models, same interrupts as D6, didn't look further).
MMU (memory management unit) present (likely configured in the same way as M5).
All previous Canon models use a MPU - memory protection unit (not to be confused with the microcontroller with the same name). D7 uses a MMU instead.
Interrupt system: same as D6.
Some DryOS tasks are starting with single-core emulation (unlike 7D/7D2), even with this (incomplete) ROM.
The DryOS shell works out of the box!


K417 READY
K417 ICU Firmware Version 1.0.1 ( 5.0.2 )
ICU Release DateTime 2017.09.21 12:53:23

Open Console K417[1]>...

Dry[MusaPUX]> ?
[Kern]
extask  memmap  meminfo  mkcfg  dminfo  exobjinfo  stdlibcfg  efatcfg
sysvers  xd  xm  prio  resume  suspend  release  sem  mutex  event  mq  exit

Dry[MusaPUX]> sysvers
SystemIF 0.88
DRYOS version 2.3, release #0059+p4
MACH 0.83+p1


WLAN led at 0xD2080190: 0x20D0002 (on), 0x20C0003 (off)
Could not find the SD card led yet.

There are many early tests I can run with the above knowledge, on any DIGIC 7 model:
- blink the LED
- identify the SD card LED (we did that on DIGIC 6)
- dump the bootloader using CHDK soundcard method (requires extra hardware)
- attempt to jump to main firmware (assuming it's the same as D6)

Ready to try?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on January 20, 2018, 10:43:18 AM
6D Mark II also has a firmware update available (just noticed it):


K406 READY
K406 ICU Firmware Version 1.0.3 ( 6.4.4 )
ICU Release DateTime 2017.08.28 12:49:25

Dry[MusaPUX]> sysvers
SystemIF 0.88
DRYOS version 2.3, release #0059+p4
MACH 0.83+p1


WLAN led not found (does it have one?)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: grtor on January 24, 2018, 08:01:17 PM
No, the 6dii doesn't have a WLAN led only an SD card led
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on February 25, 2018, 10:52:59 AM
Tried scanning 0xD2080000 - 0xD2081FFC and 0xD2080000 - 0xD20BFFFC on a 77D, with led_on = 0x20D0002 and led_off = 0x20C0003 (based on the above info). No success.

Would be helpful (for all D7 models) if a 200D owner would be willing to run the LED blinking test, since it's the only model with a known LED address.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: deathline on February 26, 2018, 05:01:05 PM
Quote from: a1ex on February 25, 2018, 10:52:59 AM
Tried scanning 0xD2080000 - 0xD2081FFC and 0xD2080000 - 0xD20BFFFC on a 77D, with led_on = 0x20D0002 and led_off = 0x20C0003 (based on the above info). No success.

Would be helpful (for all D7 models) if a 200D owner would be willing to run the LED blinking test, since it's the only model with a known LED address.

Is  this https://www.magiclantern.fm/forum/index.php?topic=2296.0 (https://www.magiclantern.fm/forum/index.php?topic=2296.0) generic one?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on February 26, 2018, 07:02:27 PM
No, it would be a FIR crafted specifically for this camera (I can create one on request).

Source: https://bitbucket.org/hudson/magic-lantern/src/digic6-dumper/src/reboot-dumper.c
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: gunny2k6 on March 08, 2018, 08:27:15 PM
Interesting Topic to read ML is already maybe possible on DIGIC 7... traded my 450D for a 77D and wasnt even thinking of asking about ML running on it at all as the work on the DIGI 6 is still ongoing
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: deathline on April 03, 2018, 03:57:00 PM
Quote from: a1ex on February 26, 2018, 07:02:27 PM
No, it would be a FIR crafted specifically for this camera (I can create one on request).

Source: https://bitbucket.org/hudson/magic-lantern/src/digic6-dumper/src/reboot-dumper.c

Hi alex, you can send me blink test for eos200d, i will try it :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on April 12, 2018, 01:37:27 PM
I have a 6D2, is there anything I could help with without taking the camera apart? :-)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: topit1972 on April 20, 2018, 11:14:44 AM
Wish i had researched my camera, 200D, prior to buying.  This 29min is a real paid as i record and manage a band.  I had a Sony HVR 5ZE Pro cam, but having to use MiniDV tapes was a pain, so thought i'd go digital not knowing the 29min cap!

Pity there isn't a generic one for 200D

Quote from: TheCallumP on December 29, 2017, 12:52:09 AM
Is there a version of ML that can be used with this camera? I bought this camera for content creation not realising that it doesn't offer a clean HDMI output ('clean' in the respect that it hides all of the on-screen information). I literally have everything set up, but could not for the life of me figure out a way to hide the on-screen information...until I found Magic Lantern. Sadly, I've found that my camera is not supported.

Are there any plans to support this camera, or is there a version that I can use that will work with my 200D? Sorry if either of these are dumb questions, I'm completely new to this and am grasping at straws here.

Many thanks.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on April 20, 2018, 12:07:22 PM
200D LED blinking test didn't work, but here's a small detail I've overlooked: bootloader seems to loads external code as Thumb (as opposed to ARM on DIGIC 6 and earlier). [ edit: confirmed, IT WORKS! ]

6D2: not much luck finding the LED address, but found out this (https://www.magiclantern.fm/forum/index.php?topic=21981) instead.

@ all DIGIC 7 EOS owners (800D, 77D, 6D2): let's retry the LED brute-forcing test (PM me if you don't mind running some blind code that pokes some GPIOs hoping to find the right one).

Source code for previous experiments committed to the digic6-dumper (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper) branch.




Next step is to dump the bootloader with one of these methods:
- CHDK soundcard method (http://chdk.wikia.com/wiki/Obtaining_a_firmware_dump#Using_soundcard_input) (phototransistor connected to PC soundcard input)
- a photodiode/phototransistor connected to an Arduino board or similar.

Please PM me once you have the hardware ready.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on April 21, 2018, 12:21:43 PM
77D: LED address identified (https://bitbucket.org/hudson/magic-lantern/commits/8c068b8ff7cf0d0c9d217696dc5520db9bb4b110), thanks @alpha232 8)

Blinking pattern:

(https://a1ex.magiclantern.fm/bleeding-edge/77D/image.png)

Wide black bar = 1, narrow black bar = 0, pattern repeats 3 times. Scan range started at 0xD2080000, 32-bit aligned addresses only => 77D LED address is 0xD2080000 + 0b00001011011 * 4 = 0xD208016C.

Background (https://www.magiclantern.fm/forum/index.php?topic=17848.msg172321#msg172321) info (https://www.magiclantern.fm/forum/index.php?topic=16052.msg168592#msg168592).

Next step: please see previous post.




Edit: the EOS M50 appears to run EOS firmware (https://bitbucket.org/hudson/magic-lantern/commits/f6e763a002080605887dcc4a5c882b626fe97553) (other recent models, i.e. M3, M5, M6, M10 and M100, are based on PowerShot firmware). Looking for a volunteer to try the LED blinking test on this camera, too :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on April 24, 2018, 10:28:49 AM
Portable ROM dumpers (https://www.magiclantern.fm/forum/index.php?topic=16534) ready 8)

77D_DUMP.FIR (https://a1ex.magiclantern.fm/bleeding-edge/77D/77D_DUMP.FIR) (confirmed by alpha232)
200DDUMP.FIR (https://a1ex.magiclantern.fm/bleeding-edge/200D/200DDUMP.FIR) (confirmed by deathline)
6D2_DUMP.FIR (https://a1ex.magiclantern.fm/bleeding-edge/6D2/6D2_DUMP.FIR) (confirmed by DieHertz)
800DDUMP.FIR (https://a1ex.magiclantern.fm/bleeding-edge/800D/800DDUMP.FIR) (confirmed by ids1024)
M50_DUMP.FIR (TODO; please use this one (https://www.magiclantern.fm/forum/index.php?topic=23296.msg209696#msg209696) instead)

Emulation coming soon.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on April 24, 2018, 10:39:33 AM
So I don't need my STM32 Discovery and phototransistors anymore? :-( :-D
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on April 24, 2018, 10:45:12 AM
Hehe... the other testers were quicker :D

Still need that hardware setup for M50. Or maybe for initial debugging, as all these recent cameras are dual-core.

Decoding LED blinks may also be possible with a camera that has automatic LCD brightness (5D3, 5D2, 7D) and already runs ML (I can look into it if needed).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: deathline on April 24, 2018, 04:27:56 PM
Quote from: DieHertz on April 24, 2018, 10:39:33 AM
So I don't need my STM32 Discovery and phototransistors anymore? :-( :-D


Is there any working project file code?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on April 24, 2018, 09:58:21 PM
I have found a 2GiB SD card, formatted it via my 6D2 (low-level format), then dd-ed 256 MB filesystem .img over it, and copied 6D2_DUMP.FIR into SD root.
Then put the SD card into camera, turned it on, screen lit up as usual, I let it sit for a minute and then turned camera off, opened SD card bay and after 10 seconds ejected it.
There are no new files on the SD card following this procedure, did I miss something?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on April 24, 2018, 10:03:05 PM
You have to "load" FIR file using Firmware Update in Canon menu!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on April 24, 2018, 10:05:38 PM

(https://thumb.ibb.co/huLePH/IMG_20180424_230954_HDR.jpg) (https://ibb.co/huLePH)
Oh indeed, I forgot this is the firmware update file format.
Thank you!

Battery taken out, can I put it back now? :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: alpha232 on April 27, 2018, 07:27:42 AM
I'm getting all antsy for something else to test :D

Much thanks to poor a1ex for his tolerating my odd schedule.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on April 28, 2018, 08:03:14 AM
LED number on 6d2 appears to be 0x5b.
Speaker/beeper is a bit weird, the second least significant bit seems to have some echo which makes it hard to distinguish whether it's 1 or 0, there seem to be 3 clicks per just two edges. It's either 0x40, 0x42, or both.
Maybe that explains why there are 3 clicks, rising edges coincide, while falling edges are spread apart as one of them is longer than the other.
https://youtu.be/MFp3pxfomGM

Result:
SD LED: 0xD208016C
Speaker 1: 0xD2080100
Speaker 2: 0xD2080108

P.S. 77D looks similar :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on April 28, 2018, 10:28:42 AM
Let's try to get some CPU info (http://www.magiclantern.fm/forum/index.php?topic=17714.0):

CPUI_6D2.FIR (https://a1ex.magiclantern.fm/bleeding-edge/6D2/CPUI_6D2.FIR)

(other D7 models on request)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on April 28, 2018, 09:18:42 PM
a1ex, here's the CPU info from 6D2.
Maybe it could be easier if it wrote output to SD card, taking these photos was far from easy :-)

(https://thumb.ibb.co/dGc1Tc/IMG_20180428_221221_HDR.jpg) (https://ibb.co/dGc1Tc)

(https://thumb.ibb.co/gBmH1x/IMG_20180428_221224_HDR.jpg) (https://ibb.co/gBmH1x)

(https://thumb.ibb.co/griaoc/IMG_20180428_221228_HDR.jpg) (https://ibb.co/griaoc)

(https://thumb.ibb.co/fqWT8c/IMG_20180428_221110_HDR.jpg) (https://ibb.co/fqWT8c)


I wonder what is the level8 cache it mentions
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on April 30, 2018, 09:51:12 AM
Emulation (https://bitbucket.org/hudson/magic-lantern/commits/a20c79bcfe12867a2d62fc50e2fe628fa16f9200) ready (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-tests/331/console) 8)

(https://a1ex.magiclantern.fm/bleeding-edge/qemu/77D.png)

Please refer to README.rst (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst), HACKING.rst (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst), the sticky tweet (https://twitter.com/autoexec_bin/status/913530810686418944) and the 80D (https://www.magiclantern.fm/forum/index.php?topic=17360.msg194898#msg194898)/750D (https://www.magiclantern.fm/forum/index.php?topic=17627.msg190275#msg190275) threads to get started.


./run_canon_fw.sh 77D -d debugmsg -s -S & arm-none-eabi-gdb -x 77D/debugmsg.gdb

<<<<< Musa(PU0) Boot Ver 0.21 >>>>>
BootLoader
K408 READY
K408 ICU Firmware Version 1.0.2 ( 7.3.6 )
ICU Release DateTime 2017.02.23 14:49:29
...
[SD] Name: QEMU! Size: 247(7bc00)
...
[STARTUP] ERROR WaitPU1 TimeOut
...


Next steps:
- attempt to jump to main firmware (will it work? we've got two CPUs)
- enable the boot flag (might be risky, we will reflash a small part of the ROM)
- port ML startup process (likely similar to 80D)
- run the proof of concept code from 80D thread (logging, photo capture etc)
- figure out how to print things on the screen
- start porting ML!

More about the bootflag:
- recovery branch (https://bitbucket.org/hudson/magic-lantern/branch/recovery) with CONFIG_BOOT_BOOTFLAG=y (https://bitbucket.org/hudson/magic-lantern/commits/2ed80d7cebcf7039652db278b2e4be362f34763d)
- doesn't work yet; stub autodetection routines have to be updated for Thumb (they were written for DIGIC 6 (https://www.magiclantern.fm/forum/index.php?topic=17360.msg189584#msg189584))
- the risk is more about bugs or other unexpected behavior in Canon bootloader (unlikely)
- this will let you compile ML (in these early stages) and run test code on your camera.

Have fun!

P.S. just got a cool feature request - audio output to Bluetooth headphones. Not tempting enough for me to get another camera, but if any of you is willing to look into it, I'll be here to help (at least with the reverse engineering side).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: deathline on May 01, 2018, 03:13:12 PM
Quote from: a1ex on April 30, 2018, 09:51:12 AM
P.S. just got a cool feature request - audio output to Bluetooth headphones. Not tempting enough for me to get another camera, but if any of you is willing to look into it, I'll be here to help (at least with the reverse engineering side).

Are you sure digic7 cameras have  hardware support for Bluetooth 4.0 BR/EDR? 200d canon firmware support only bluetooth low energy and there is no profile for audio headsets.But i've found a low energy supported hid profile gamepad for playing mario :D 
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on May 01, 2018, 09:11:02 PM
Great job Alex, I guess now is the case for us, owners of 6d2 and other DIGIC 7 cameras, to continue the effort :-)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on May 01, 2018, 09:23:27 PM
You still need my help to enable the boot flag, but at least you can now debug your binaries in QEMU.

Good news - we were able to jump to main firmware without any special tricks! (confirmed by both DieHertz and deathline). In reboot-dumper.c from the digic6-dumper branch, run this:


void(*firmware_start)(void) = (void*) 0xE0040001;
firmware_start();

while(1);


That means, one can already start to port the 80D boot process (minimal.c) and debug it in QEMU. Same for the DIGIC 6 boot flag enabling code (recovery branch).

DIGIC 6 cameras require a special trick to jump to main firmware (poking register 0xD20C0084 on single-core D6). This was not needed for DIGIC 7.

Feel free to play around with the virtual machine and report your findings.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on May 01, 2018, 10:23:18 PM
I'm sure we'll need your help for much more than that :-)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on May 03, 2018, 04:19:35 PM
I think it fails earlier, unless "irregular TotalSheets 0" is a known and insignificant error message.
6D2 seems to wait for startup config to finish, last flag `0x40000` isn't cleared for a couple of minutes
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on May 03, 2018, 09:43:44 PM
Is it safe to assume that most of these messages are errors?
(https://thumb.ibb.co/bXJ9PS/Screen_Shot_2018_05_03_at_22_43_16.png) (https://ibb.co/bXJ9PS)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on May 04, 2018, 11:09:24 AM
The TotalSheets and EstimatedSize errors are likely caused by wrong / incomplete MPU messages (these will have to be logged from a real camera); the WaitPU1 error is probably what's blocking right now. It appears to wait at a semaphore.

200D:

startupPrepareCapture -> take_semaphore(PU1Wait_sem, 2000) -> DebugMsg("WaitPU1 TimeOut") if failed.
This semaphore (PU1Wait) is created right after launching TaskMain (E00413E6).
The function that gives this semaphore is E0040220 -> E004053C, referenced at:

  call 0xE0426000(e0040221, 0, 0, 1000)                                          at [init:e00402dd:e004029d]

That's something named init1 / init_task1. It does a bunch of initialization, then calls give_semaphore(PU1Wait_send) at the end.
It also appears to initialize Omar (a small secondary core likely used to offload some image processing tasks).

So, one puzzle is to debug this init_task1 to see where it locks up / why it doesn't finish / whether it's starting at all.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: BHybes on May 04, 2018, 12:40:26 PM
I ran the FIR file as an update on my 800D and only got this from it:
(https://thumb.ibb.co/iHGnDn/20180504_113428.jpg) (https://ibb.co/iHGnDn)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on May 04, 2018, 01:06:08 PM
One of the ROMs is very slow, so it takes a while. Updated the binaries to skip that step.

@ 200D/6D2/77D owners: please check whether the new dumpers are still working (same link, top of the page).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on May 04, 2018, 03:17:21 PM
I'm still figuring my way through radare2, ARM console, and probably something else. Having no IDA complicates it a bit, reading raw undecorated ASM in GDB is too hardcore for now :)
Will try the new dumper tonight
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on May 04, 2018, 06:12:14 PM
Radare2 should be the most promising one; I doubt you'll get anything useful from ARM-console on Thumb.

I find GDB useful not for step-by-step debugging (I find that too slow, and IDA crashes very often, so it doesn't help that much), but with:
- watch *0x1234 (to tell what code writes to that memory address)
- custom logging hooks (to tell when a particular sequence of code executes, and with what arguments / return values / etc)

Most of the time, I use various logging options from qemu -d (many of them are custom logging code, not found in vanilla QEMU), possibly coupled with small GDB scripts (see e.g. generic_log) and grep. The most useful ones: I/O trace with interrupts (-d debugmsg,io,int), call trace (-d calls,tail), RAM trace (-d ram, with variations, or temporary edits to source code to define filters if grep is too slow).

Back to our issue. From what I could tell, the second core (CPU1) gets stuck waiting for interrupt 0xA, early in the boot process; see the EOS M5 notes about GIC.


; 77D
ROM:E0007752  BL      gicc_setup   ; writes to 0xC1000100 and 104
ROM:E0007756  MOV     R0, #0xA
ROM:E000775E  BL      wait_some_interrupt   ; calls WFI in a loop until it gets the expected interrupt


I believe these are meant to generate a software interrupt for CPU1 (77D):

[CPU0] [GICD]   at Startup:E0152F04:E0092855 [0xC1001F00] <- 0x2000A   : ???
[CPU0] [GICD]    at RscMgr:E0152F04:E0092855 [0xC1001F00] <- 0x2000A   : ???
[CPU0] [GICD]    at RscMgr:E0152F04:000350BF [0xC1001F00] <- 0x2000C   : ???


See arm_gic_architecture_specification.pdf, 4.3.15 Software Generated Interrupt Register GICD_SGIR: lowest hex digit is the interrupt ID, and the 0x2 is CPUTargetList (second CPU).

We've got some generic GIC emulation code in QEMU (intc/arm_gic.c); would be great if that can be reused.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: t3r4n on May 04, 2018, 07:03:03 PM
Quote from: DieHertz on May 04, 2018, 03:17:21 PM
I'm still figuring my way through radare2,

well maybe I've got something
try adapting the following to your specific camera layout

# Show comments at right of disassembly if they fit in screen
e asm.cmtright=true

# Shows pseudocode in disassembly. Eg mov eax, str.ok = > eax = str.ok
e asm.pseudo = true
# (Show ESIL instead of mnemonic)
# e asm.esil = true

# Selected: asm.describe (Show opcode description)
e asm.describe = false

#asm.emu (Run ESIL emulation analysis on disasm)
e asm.emu = true

# Solarized theme
eco solarized

# Use UTF-8 to show cool arrows
e scr.utf8 = true
e scr.utf8.curvy=true

# set arch and cpu type
e io.va = true
e asm.arch = arm
e asm.bits = 16
e asm.cpu=cortex
# anal.armthumb (aae computes arm/thumb changes (lot of false positives ahead))
e anal.armthumb=true

# initialize esil vm
#e esil.stack.addr = 0x20000000
#e esil.stack.size = 0x000f0000

e asm.section.sub = true
e io.va=true

#S ${esil.stack.addr} ${esil.stack.addr} ${esil.stack.size} ${esil.stack.size} ram mrwx

#00000000 - 00003FFF: eos.tcm_code
S 0x0000000 0x00000000 0x3fff 0x3fff tcmcode mrwx

#00004000 - 1FFFFFFF: eos.ram
S 0x00004000 0x00004000 0x1FFFBFFF 0x1FFFBFFF  eosram mrw-

#40000000 - 40003FFF: eos.ram_uncached0
S 0x40000000 0x40000000 0x3fff 0x3FFF  eosramuncached0 mrw-

#40004000 - 5FFFFFFF: eos.ram_uncached
S 0x40004000 0x40004000 0x1FFFBFFF 0x1FFFBFFF  eosramuncached mrw-

#80000000 - 8000FFFF: eos.tcm_data
S 0x80000000 0x80000000 0xffff 0xffff tcmram mrw-

#BFE00000 - BFFFFFFF: eos.ram_extra
S 0xBFE00000 0xBFE00000 0x1fffff 0x1fffff  eosramextra mrw-

#C0000000 - DFFFFFFF: eos.iomem
S 0xc0000000 0xc0000000 0x1fffffff 0x1fffffff  eosiomem mrw-


#FC000000 - FDFFFFFF: eos.rom1
#FE000000 - FFFFFFFF: eos.rom1_mirror
S 0xfc000000 0xfc000000 0x1fffffff 0x1fffffff  eosrom1 mr-x
S 0xfe000000 0xfe000000 0x1fffffff 0x1fffffff  eosrom1m mr-x

aa
aaa
aae
e anal.hasnext = true
# e io.sectonly = true
e search.in = io.sections.exec
#aac
dbe 0xFE020000


(taken from https://vimeo.com/211371081 (https://vimeo.com/211371081) and adapted to 750D)
then leave this open in a text editor
start qemu .... -S -s  and  radare with :

r2 -aarm -b16 -d gdb://localhost:1234

paste the commands above into radare (loading as a startup script does not seem to work with gdb option)
hit vv and start debugging.


Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DieHertz on May 04, 2018, 09:06:04 PM
New ROM dumper on 6D2 works as intended, got different hashes, but I suppose it's because of change of settings since last dump?
@t3r4n you should consider moving these into ~/.radare2rc and not fiddle with text files and open editors :-)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: BHybes on May 05, 2018, 10:35:42 AM
800D Rom Dump didn't work, got stuck at ROM0
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on May 05, 2018, 11:06:42 AM
From the post with download links -> click on first link:

Quote from: a1ex on January 25, 2016, 09:29:53 AM
Requirements:
- a very small SD card or filesystem (important!)
- [...]

Formatting a larger card at a much lower capacity (e.g. 256MB) does the trick. For example, you can write the SD image that comes with QEMU (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/sd.img.xz) to your SD or CF card (follow this guide (https://thepihut.com/blogs/raspberry-pi-tutorials/17789160-backing-up-and-restoring-your-raspberry-pis-sd-card)).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: deathline on May 05, 2018, 08:11:24 PM
Quote from: a1ex on May 04, 2018, 01:06:08 PM
One of the ROMs is very slow, so it takes a while. Updated the binaries to skip that step.

@ 200D/6D2/77D owners: please check whether the new dumpers are still working (same link, top of the page).

new dumper starting to work immediately, rom1.bin identically same priveous files, rom0.bin have slightly differences which has been seen all rom0.bin file.It's look like a block shifting flaws causing newlines.And you know where to find ;)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: ids1024 on May 10, 2018, 08:53:02 PM
The 800D ROM dumper seems to work, though it took me a while to figure out how to create a fatfs smaller than the card. "strings ROM0.BIN" and "strings ROM1.BIN" confirm they aren't just non-sense (I'm not sure what else to check).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: overVolt on June 13, 2018, 05:38:31 PM
I have a 77d, some sort of programming skills and I'm ready to help in any way needed (if needed).

I just need to NOT brick my camera because I use it every day for work and have no other camera :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: CanonPrimoz on June 14, 2018, 06:29:51 PM
Hi!
I just got new 6D2 and I'm ready to help... I have some coding skills with C and C++
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Rubsstar on June 27, 2018, 03:30:50 PM
Hi, I want to have magic lantern on my Canon 200D camera. I have already installed this fir document. then he says that I have to put out my battery and restart my camera. if I do that he does nothing... Is that right?

Quote from: a1ex on April 24, 2018, 10:28:49 AM
Portable ROM dumpers (https://www.magiclantern.fm/forum/index.php?topic=16534) ready 8)

77D_DUMP.FIR (https://a1ex.magiclantern.fm/bleeding-edge/77D/77D_DUMP.FIR) (confirmed by alpha232)
200DDUMP.FIR (https://a1ex.magiclantern.fm/bleeding-edge/200D/200DDUMP.FIR) (confirmed by deathline)
6D2_DUMP.FIR (https://a1ex.magiclantern.fm/bleeding-edge/6D2/6D2_DUMP.FIR) (confirmed by DieHertz)
800DDUMP.FIR (https://a1ex.magiclantern.fm/bleeding-edge/800D/800DDUMP.FIR) (confirmed by ids1024)
M50_DUMP.FIR (need a second volunteer who has either another camera to film the display, or a phototransistor connected to soundcard/arduino/whatever)

Emulation coming soon.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kotik on July 12, 2018, 03:41:14 PM
Firmware update 6D200104.FIR is released.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on July 12, 2018, 04:02:55 PM
Previous dumper should work; feel free to double-check the stubs (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/scripts/6D2/debugmsg.gdb).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kotik on July 12, 2018, 05:15:47 PM
Can confirm that 6D2_DUMP.FIR is still working on 6D2 1.0.4.
https://ibb.co/hBUQK8 (https://ibb.co/hBUQK8)

Did 3 runs, MD5 of ROM0 is inconsistent, ROM1 is even.

Did run: ./run_canon_fw.sh 6D2 -d debugmsg
FileMerge detected 69 differences between 6D2.103 and 6D2.104, all memory address related.

Tried: ./run_canon_fw.sh 6D2 -d debugmsg -s -S & arm-none-eabi-gdb -x 6D2/debugmsg.gdb
but the iMac terminal complained: -bash: arm-none-eabi-gdb: command not found.

There seems to be a Homebrew problem not installing arm-none-eabi-gdb.
Found a script to fix that, but that didn't work!

Installed arm-none-eabi-gdb with Homebrew, now I get the following error.

Python Exception <type 'exceptions.ImportError'> No module named gdb:
warning:
Could not load the Python gdb module from `/Users/ibush/bin/arm-none-eabi/share/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.

How can I fix this? Start all over again?   :o
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: mauriciovrc on August 03, 2018, 03:30:15 AM
Hi guys! I'm new with magic lantern and don't understand so much about this. Someone can tell me how I install the firmware in 80OD? I didn't understand if I get ML just installing the firmware availably here.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Audionut on August 03, 2018, 05:38:19 AM
Quote from: mauriciovrc on August 03, 2018, 03:30:15 AM
Someone can tell me how I install the firmware in 80OD?  I didn't understand if I get ML just installing the firmware availably here.

There is no ML currently available for the 800D.  There is a bunch of work that must be completed first before ML is available for the 800D.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Jonn3y on August 08, 2018, 11:24:39 PM
Hey guys,

I have a 77D here and want to help making some progress :)
do you still need some rom-dumps or something else?

Hope i can help a little!


// Jonny
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: morgan20 on August 09, 2018, 07:14:17 AM
Quote from: a1ex on August 08, 2018, 05:55:59 PM
Looks very much like DIGIC 7. Dual core.

Volunteers willing to run untested code are welcome.

Hi there! I own a 6D2. Could you please tell me more about running the untested code? How dangerous is it?

If the code damages the camera, will you help to recover it if it's possible (with another code, for example)?

I'm kinda experienced Linux user and a Java (with a little C) programmer. Sadly, I'm not much into low-level programming.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on August 09, 2018, 09:02:43 AM
For DIGIC 7 models, the next step is porting the 80D startup code (https://www.magiclantern.fm/forum/index.php?topic=19737.msg200895;topicseen#msg200895) (i.e. running user code alongside Canon firmware). I expect this step to be straightforward, so it's left as an exercise to the owners of these cameras. You can debug the startup code in the emulator; once you get it working, just ask me to enable the boot flag so you can test it on the camera.

The previous post was for M50 ( DIGIC 8 ). On this camera, I don't know yet how the bootloader looks like, and the code written for DIGIC 7 didn't work, so I'll probably attempt to dump the ROM directly from main firmware. The tests you'll run are:
- jumping to Canon firmware (expecting to be identical to DIGIC 7, i.e. jumping to 0xE0040000)
- LED blinking (testing the above addresses)
- LED blinking from main firmware (if I'll get this working in QEMU)
- ROM dumping from main firmware (could not test this one in QEMU yet)
- other tests (CPU model, diagnostic logs etc)

After publishing the ROM dumper, I'll update the emulator, attempt to enable the boot flag and get some diagnostic logs. Further progress will require a developer with a camera in their hands and plenty of spare time for experiments. If that describes you, your contribution will be more than welcome. I'll be here to help if you get stuck, but please be aware I'm not interested in maintaining yet another camera port alone.

If the code damages the camera, I'll try to help, but cannot guarantee success.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: morgan20 on August 10, 2018, 06:23:04 AM
Quote from: a1ex on August 09, 2018, 09:02:43 AM
For DIGIC 7 models, the next step is porting the 80D startup code (https://www.magiclantern.fm/forum/index.php?topic=19737.msg200895;topicseen#msg200895) (i.e. running user code alongside Canon firmware). I expect this step to be straightforward, so it's left as an exercise to the owners of these cameras. You can debug the startup code in the emulator; once you get it working, just ask me to enable the boot flag so you can test it on the camera.

Hmm, given that I have no experience in reverse engineering, this one is gonna be tough. I'll see if I can do anything, but the success for me in that task is gonna be almost impossible.
Although, I've read that DIGIC 7 are quite the same as DIGIC 6, just dual core, and this kinda makes me wonder why we can't run the DIGIC 6 code on a single DIGIC 7 core?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on August 10, 2018, 07:27:06 AM
Short answer: because nobody tried yet.

Long answer: generally it won't work out of the box, even on nearly identical generations, because the code is tightly tied to Canon firmware. Being "mostly identical" just means most of the code can be reused (i.e. not rewritten from scratch), but it generally needs some adjustments.

Nearly every minor firmware update has the functions we want to call at different addresses (https://www.magiclantern.fm/forum/index.php?topic=19417.0). At least these will have to be adjusted, but this is generally the easiest step (a bit time-consuming, but can be automated to some extent).

Besides, each camera model has its own quirks; even cameras from the same generation will have differences beyond just different stubs. Some very close models are 650D and 750D, for example, but even there, not everything works just by changing the stub addresses. Other close models are 80D, 750D and 760D - in this case, I'd expect the startup code to work out of the box just by tweaking the addresses, but nobody tried. Beyond startup code, I'd expect 750D and 760D to start diverging from 80D.

Here, DIGIC 7 is definitely not the same DIGIC 6. There is a new processor, a new startup code, two cores that have to run in sync, a new memory layout, a memory mapping unit (previous models only had a memory protection unit) and so on. Overall, they are based on the same EOS codebase we are familiar with, but that doesn't mean the old code will run out of the box.

The similarity I've mentioned was at hardware level, i.e. many peripherals (things other than CPU and RAM) identified on DIGIC 6 could be used to emulate DIGIC 7 firmware either out of the box or with minor adjustments (such as different register addresses).

The screenshots you have seen were created with portable code (the recovery (https://bitbucket.org/hudson/magic-lantern/branch/recovery) branch, which is limited to bootloader experiments). This code attempts to locate firmware functions on the fly, with pattern matching, and can run from DIGIC 2 all the way to DIGIC 7. However, what can be done in a portable way is quite limited and relies on similarity between Canon firmwares. Sooner or later, you will need "if" branches with model-specific or generation-specific code.

The DIGIC 7 cameras appear to be very similar; that is, I'd expect most of the knowledge gained by analyzing one model to apply to all others in this group. DIGIC 8 starts to diverge a bit, but I still believe D7 and D8 are a lot more similar than D6 and D7 (they have the same ROM layout, the same startup code, similar - possibly the same - dual-core configuration and so on). Maybe it's best to move M50 in its own thread, but for now I'm analyzing all these models together.

One significant difference between D7 and D8: the portable code did not quite work out of the box on M50. Expecting the bootloader changes to be minor, but unable to guess them from the firmware update. The portable code ran, to some extent, so we could tell the code is running and we could change the error screen, but could not display any custom things and could not guess the LED address. Figuring things out that way would have been possible, but tedious; luckily, the firmware update came out earlier than expected.

I'm going to implement the startup code for M50, so you can compare it to 80D and see what are the parts that may need tweaking.




Edit: committed startup code for both M50 (https://bitbucket.org/hudson/magic-lantern/commits/4d8840f63b15dde45ba27272530f0e0ab0fe8372) and 200D (https://bitbucket.org/hudson/magic-lantern/commits/89262376d7de0b4828b3cc6fde444c38f5874a34), as it was easier to debug this way. Testers welcome (contact me by PM).

Porting to 6D2, 77D and 800D should now be just a matter of pattern matching (https://www.magiclantern.fm/forum/index.php?topic=12177.0) (in theory).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: morgan20 on August 12, 2018, 05:03:40 AM
This sounds promising! Thanks for the links, I'll be checking this out.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: todd3835 on August 14, 2018, 12:51:44 PM
I have a 77D and would be willing to help test things if needed. I don't know that I have the knowledge to help further than that :(
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: critix on August 19, 2018, 08:06:48 AM
Hi.
I need ROM dump file for 200D and M50.
Thanks.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on August 20, 2018, 09:21:13 PM
Some news:

- after fixing some cache routines (https://bitbucket.org/hudson/magic-lantern/commits/b63d437586cb90dcd440c4ddfef411dcd2f576ec), the startup code was confirmed to work on 200D by two testers (vissie and deathline)
- the same startup code refused to work on M50, although it works in QEMU and the firmwares seem pretty much identical (couldn't figure out why)
- on M50, the two LED addresses mentioned earlier are both valid (green led above LCD and red led used for autofocus - confirmed by DrWeez)

That means:
- I'm ready to enable the boot flag on 200D, so you can run your own code on the camera
- we can get RAM dumps, take pictures and run other simple code sequences
- we might be able to get debug messages (not confirmed yet - confirmed by vissie)
- we might be able to save a 14-bit DNG, just like we did on 80D (https://www.magiclantern.fm/forum/index.php?topic=17360.msg200479#msg200479)
- other DIGIC 7 models can reach the same stage with minimal effort (https://www.magiclantern.fm/forum/index.php?topic=12177.0,); once that is done, I'm ready to enable the boot flag there as well
- for M50, we are going to use the CHDK soundcard method (http://chdk.wikia.com/wiki/Obtaining_a_firmware_dump#Using_soundcard_input) for "blinking" the bootloader out of the camera

That's it for today.




Edit: here's a diagnostic log from 200D, from vissie:

00000000>       init:001b6acf:00:0f: Logging started.
00000000>       init:913:00:05: [MEM] InitializePermanentMemory 0 4636784
000001B0>       init:99103:89:16:
K417 ICU Firmware Version 1.0.1 ( 5.0.2 )
000001D2>       init:99100:89:05:
ICU Release DateTime 2017.09.21 12:53:23
00000329>       init:991503:00:03: [SEQ] CreateSequencer (Startup, Num = 6)
00000372>       init:991699:00:03: [SEQ] NotifyComplete (Cur = 0, #x, Flag = #x)
000009BC>     SFRead:906091:02:05: PROPTUNEAD_CreateFROMPropertyHandleToDRAM Addr:0x416a2c00
00000A36>     SFRead:9497:02:03: PROPCOMBO_LoadProperty(395)
00000A81>    RomRead:9117:02:05: PROPAD_CreateFROMPropertyHandle DRAMAddr 0x421f8400
00005EFD>     SFRead:991699:00:03: [SEQ] NotifyComplete (Cur = 0, #x, Flag = #x)
00009579>    RomRead:991699:00:03: [SEQ] NotifyComplete (Cur = 0, #x, Flag = #x)
000095A8>    Startup:991503:00:05: [SEQ] seqEventDispatch (Startup, 0)
000095C4>    Startup:99115:89:05: startupEntry
0000ABF4>    Startup:9913009:00:03: [PWM] PWM_Initialize
0000AC65>    Startup:92125:00:03: [ADC] InitializePollingADC
0000B211>      init1:9130:d2:03: [FMID]FMID_SYS_Initialize(#x, #x)
0000D3D5>    Startup:921201:00:03: [ ADC ] Calibration Completed, #08x
0000E603>    PropMgr:997595:81:03: PROP_RegisterMultiConvert : 3, 6
0000E629>    PropMgr:997595:81:03: PROP_RegisterMultiConvert : 1, 1
0000E81D>    PropMgr:99339:81:03: @@@JudgeRestoreFlavorPC 1062
0000EB7F>    Startup:001b686f:00:0f: [0] *** mpu_send(06 04 02 00 00 00)                             ; Init group
0000ECF8>    PropMgr:9143:37:03: emSlaveChangeCBR : AUTO_POWEROFF (1)
0000ED2D>    PropMgr:91591:37:03: emSlaveChangeCBR : UILOCK (#x)
0000EF69>    PropMgr:001b68db:00:0f: [0] *** mpu_recv(06 05 01 00 03 00)                             ; PROP_SHOOTING_MODE
0000F013>    PropMgr:9934067:81:03: ChangeAEMode -> 3 @AE_MODE_DIAL
0000F070>    PropMgr:001b686f:00:0f: [1] *** mpu_send(08 06 01 a7 00 01 00 00)                       ; ???
0000F09B>    PropMgr:99601:81:03: Active Adjective & Situation 3->3
0000F0DC>    PropMgr:99753:81:03: ReqChangeCBR : Adjective 0, 0
0000F0F8>    PropMgr:997519:81:03: Not ExecMultiConvert Already None : Adjective 0, 0
0000F130>    PropMgr:997503:81:03: Not ExecMultiConvert : Situation 0
0000F18F>    PropMgr:996375:81:03: !! Convert End !!
0000F1B8>    PropMgr:001b68db:00:0f: [1] *** mpu_recv(06 05 01 99 00 00)                             ; PROP 80040057
0000F234>    PropMgr:001b68db:00:0f: [2] *** mpu_recv(06 05 01 9a 00 00)                             ; PROP 80040058
0000F259>    PropMgr:91005:02:03: DataType = 0x2000000 fModify = TRUE
0000F2DD>    PropMgr:001b68db:00:0f: [3] *** mpu_recv(06 05 01 06 30 00)                             ; PROP_APERTURE
0000F36F>    PropMgr:001b68db:00:0f: [4] *** mpu_recv(06 05 01 3f 00 00)                             ; PROP_FLASH_ENABLE
0000F707>    PropMgr:001b68db:00:0f: [5] *** mpu_recv(06 05 01 99 00 00)                             ; PROP 80040057
0000F755>    PropMgr:9970:81:03: PROP_STROBO_FIRING 0 Last 0
0000F773>    PropMgr:9970:81:03: dwLastStroboFiring = 0  stroboFiring = 0
0000F79E>    PropMgr:001b68db:00:0f: [6] *** mpu_recv(06 05 01 9a 00 00)                             ; PROP 80040058
0000F81A>    PropMgr:001b68db:00:0f: [7] *** mpu_recv(06 05 01 06 30 00)                             ; PROP_APERTURE
0000F8BB>    PropMgr:001b68db:00:0f: [8] *** mpu_recv(06 05 01 3f 00 00)                             ; PROP_FLASH_ENABLE
0000F92C>    PropMgr:993475:81:03: PROP_CHROMATISM 0 (Excluding:0)
0000F956>    PropMgr:001b68db:00:0f: [9] *** mpu_recv(06 05 01 4f 00 00)                             ; PROP_FIXED_MOVIE
0000F9E1>    PropMgr:993475:81:03: PROP_DISTORTION_COMP 0 (Excluding:0)
0000FA5D>    PropMgr:993472:81:03: PROP_LIGHT_FALLOFF_COMP 0 (Excluding:0)
0000FC2B>    PropMgr:9970:81:03: PROP_STROBO_FIRING 0 Last 0
0000FC45>    PropMgr:9970:81:03: dwLastStroboFiring = 0  stroboFiring = 0
0000FC70>    PropMgr:993409:81:03: FixedMovie New 0 Last 0
0000FDA7>    PropMgr:9934373:81:03: PROP_TOUCH_SHUTTER 1
0000FE34>    PropMgr:99343:81:03: PROP_CREATIVE_TOUCH_SHUTTER 1
0000FEB9>    PropMgr:001b686f:00:0f: [2] *** mpu_send(22 20 0e 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; ???
0000FEDB>    PropMgr:9161:d6:03: LvLensDataMasterResultCBR
0000FF2D>    PropMgr:9161:d6:03: PowerZoomAdapterInfoCBR
0000FF79>    PropMgr:9161:d6:03: FactErrLensDataInfoCBR
0001021E>     NFCMgr:902297:3e:03: [BLE] BLEMGR_InitializeParam
000102BF>     NFCMgr:001b686f:00:0f: [3] *** mpu_send(06 05 03 8a 00 00)                             ; ???
0001031A>     NFCMgr:001b686f:00:0f: [4] *** mpu_send(06 04 02 14 00 00)                             ; ???
00010378>     NFCMgr:9200:3e:03:  NFCI2C_SetParam 1 3 0xa8 0x0
000103B2>     NFCMgr:9253:3e:03:  PROP_SPECIAL_OPTION Wlan off (0x0)
00010A77>   PowerMgr:001b68db:00:0f: [10] *** mpu_recv(30 2f 02 0d 00 00 00 00 01 00 00 00 00 00 00 01 00 01 02 00 00 00 00 00 01 01 00 00 00 00 00 00 00 00 00 00 01 00 01 00 0f 00 07 01 00 00 00 00) ; Card group
00010BEE>    PropMgr:910:01:03: DivideMediaEtcInit2Data[24] comID 1 dataID 91 data 0xf00
00010C1B>    PropMgr:910:01:03: DivideMediaEtcInit2Data[25] comID 1 dataID 9c data 0x700
000110F0>   PowerMgr:001b68db:00:0f: [11] *** mpu_recv(5e 5c 02 0f 01 00 00 08 01 01 00 00 00 00 00 00 00 00 00 00 09 c4 00 00 00 0c 00 00 00 00 00 00 00 03 00 00 00 01 00 00 00 00 00 02 03 01 01 00 00 00 00 00 00 00 00 00 03 01 2c 00 00 0b b5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; Movie group
000111A3>    PropMgr:910:01:03: RecMovieParam 0 0 2500 12 0 3 1 0
000112C2>    PropMgr:99346:81:03: @@@ PROP_MOVIE_CFILTER 0
0001190F>   PowerMgr:001b68db:00:0f: [12] *** mpu_recv(48 46 02 10 00 00 00 00 00 00 01 00 00 00 03 03 03 03 00 00 00 00 00 00 00 5c 00 01 ba 50 00 00 00 00 00 01 ff 00 00 02 01 01 00 03 00 01 00 04 00 00 01 05 00 01 01 00 01 00 00 03 03 00 00 00 00 00 00 00 00 00 00 00) ; AF group
00011D83>   PowerMgr:001b68db:00:0f: [13] *** mpu_recv(42 40 02 11 00 01 00 00 00 00 01 00 ff 01 00 00 00 00 00 00 00 ff 01 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 ff 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 00 00) ; AF2 group
00011DF5>    PropMgr:91361:01:03: DivideLensInit2Data[3] comID 1 dataID 4 data 0x0
00011E26>    PropMgr:001b68db:00:0f: [14] *** mpu_recv(06 05 01 b6 01 00)                            ; ???
00011EA5>   PowerMgr:001b68db:00:0f: [15] *** mpu_recv(06 05 01 b5 01 00)                            ; ???
00011F24>   PowerMgr:001b68db:00:0f: [16] *** mpu_recv(06 05 01 98 00 00)                            ; PROP 80040056
00012063>   PowerMgr:001b68db:00:0f: [17] *** mpu_recv(12 10 02 04 0c 00 00 00 00 00 00 43 00 00 00 00 00 00) ; PROP_CFN
00012A01>   PowerMgr:99157:00:03: [STARTUP]startupCompleteCallback 0x2
00012A22>   PowerMgr:991699:00:03: [SEQ] NotifyComplete (Cur = 1, #x, Flag = #x)
00012A9A>   PowerMgr:001b68db:00:0f: [18] *** mpu_recv(94 93 02 0e 03 03 01 00 00 00 00 00 00 00 00 00 14 50 00 00 00 00 87 00 00 01 03 00 00 01 03 00 00 01 00 00 01 00 00 0a 00 70 30 00 00 00 00 00 00 00 00 01 03 00 00 88 48 00 00 80 48 80 48 80 48 88 48 78 48 80 48 78 48 70 00 00 03 03 01 00 00 00 00 02 00) ; Mode group
00012B26>    PropMgr:001b68db:00:0f: [19] *** mpu_recv(06 05 03 37 00 00)                            ; PROP_MIRROR_DOWN_IN_MOVIE_MODE
00012BD6>    PropMgr:001b68db:00:0f: [20] *** mpu_recv(0a 08 03 2f 00 40 00 00 00 00)                ; PROP_SPECIAL_OPTION
00012C4D>    PropMgr:001b68db:00:0f: [21] *** mpu_recv(06 05 03 20 01 00)                            ; PROP_STARTUP_CONDITION
00012C90>    PropMgr:9934067:81:03: ChangeAEMode -> 3 @AE_MODE_DIAL
00012CB3>    PropMgr:996375:81:03: !! Convert End !!
00012CDB>    PropMgr:001b68db:00:0f: [22] *** mpu_recv(06 05 03 76 00 00)                            ; ???
00012E40>    PropMgr:9119:01:03: DivideDataInit2Data[4] comID 1 dataID 4 data 0x0
00012E6C>    PropMgr:9119:01:03: DivideDataInit2Data[8] comID 1 dataID b data 0x0
00012E95>    PropMgr:9119:01:03: DivideDataInit2Data[10] comID 1 dataID e data 0x1450
00012EF5>    PropMgr:9119:01:03: DivideDataInit2Data[22] comID 1 dataID 1f data 0xa
00012F6C>    PropMgr:9970:81:03: PROP_STROBO_FIRING 0 Last 0
00012F88>    PropMgr:9970:81:03: dwLastStroboFiring = 0  stroboFiring = 0
00012FE8>    PropMgr:993475:81:03: PROP_MULTIPLE_EXPOSURE_SETTING 0
0001300E>    PropMgr:993475:81:03: PROP_HDR_SETTING 0
00013046>    PropMgr:9934309:81:03: @@@ PROP_LV_CFILTER 0
0001306F>    PropMgr:993475:81:03: PROP_GIS_SETTING Func 0
0001308B>    PropMgr:9119:01:03: DivideDataInit2Data[50] comID 1 dataID 47 data 0x20a
000130AE>    PropMgr:9119:01:03: DivideDataInit2Data[51] comID 1 dataID 57 data 0x100
000130D7>    PropMgr:993425:81:03: PROP_SHUFFLE_MODE 0x0 ConvertMode 0x0
000130F3>    PropMgr:9119:01:03: DivideDataInit2Data[53] comID 1 dataID 88 data 0x3c
0001315A>    PropMgr:9119:01:03: DivideDataInit2Data[59] comID 1 dataID 9e data 0x40
000131D3>    PropMgr:9123:01:03: Deliv WaitID = 0xd5555555, 0x55bbef(1)
0001325E>    PropMgr:9934141:81:03: StartupCondition : 1, 0
0001337D>    PropMgr:001b68db:00:0f: [23] *** mpu_recv(64 62 02 12 01 25 50 01 eb 00 10 01 2c 91 77 9a ef 08 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 04 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 47 00 00 00 00 00 00 00 10 3e 00 00 00 00 00 00 00 00 00 00) ; Lens group
00013402>    PropMgr:001b68db:00:0f: [24] *** mpu_recv(06 05 03 35 01 00)                            ; PROP_BATTERY_REPORT_COUNTER
00013494>    PropMgr:910:01:03: Complete WaitID = 0xd5555555, 0x55bbef(0)
000134C4>    PropMgr:910007:01:03: SpecialComplete ID = 0xd5555555, 0xd5555555 3011
0001350D>    PropMgr:001b686f:00:0f: [5] *** mpu_send(08 06 00 00 02 0e 00 00)                       ; Complete WaitID = Mode group
00013588>    Startup:991503:00:05: [SEQ] seqEventDispatch (Startup, 1)
000135B6>    Startup:9912:89:05: startupPrepareProperty
00013649>    PropMgr:001b68db:00:0f: [25] *** mpu_recv(1c 1b 03 1d 64 03 00 00 00 00 00 4c 50 2d 45 31 37 00 00 00 00 01 00 24 42 05 d2 00) ; PROP_BATTERY_REPORT
000136D4>    PropMgr:001b68db:00:0f: [26] *** mpu_recv(06 04 03 36 00 00)                            ; PROP_BATTERY_REPORT_FINISHED
00013733>    PropMgr:9915243:88:03: HotPlug TimelapseSetting = 0
00013776>    Startup:001b68db:00:0f: [27] *** mpu_recv(08 07 03 7e ff ff ff 00)                      ; ???
000137BD>    Startup:99607:88:03: # 0 0 1 1 0
000137FE>    PropMgr:001b68db:00:0f: [28] *** mpu_recv(06 05 03 38 93 00)                            ; PROP 80030035
00013872>    Startup:991566:88:03: CreateTask Master End
0001389F>    Startup:001b68db:00:0f: [29] *** mpu_recv(08 06 01 a7 00 01 00 00)                      ; ???
0001395B>    PropMgr:99193:89:03: PROP_GPS_AUTO_TIME_SETTING 0
0001398B>    Startup:99157:00:03: [STARTUP]startupCompleteCallback 0x20000000
000139AE>    Startup:991699:00:03: [SEQ] NotifyComplete (Cur = 2, #x, Flag = #x)
000139C8>    Startup:9915:89:03: startupPrepareProperty : CLASSID_FLAG_PROPAD
000139E4>    Startup:9360:19:03: FM_Initialize (0, 1, 0)
00013A53>    PropMgr:936065:19:03: fmResultCBR (#x)
00013B16>    PropMgr:001b68db:00:0f: [30] *** mpu_recv(08 06 01 a7 00 00 00 00)                      ; ???
00013BE0>    PropMgr:9360:19:03: PROP_HDD_DCIM_PATH (/)
00013CD2>    Startup:9170:1c:03: FC_Initialize [drive:0 1 0][ClassID:28]
00013CEF>    Startup:91799:1c:03: FC_Initialize [86608 655360]
00014190>     RTCMgr:976:00:05: [RTC] SPECIAL_OPTION 0x0, 0x4000
00014241>     RTCMgr:001b686f:00:0f: [6] *** mpu_send(08 07 03 6a 00 02 00 00)                       ; ???
00014296>     RTCMgr:9171:00:05: [RTC] PermitCharge already Permit 0x20
00014306>    Startup:916511:80:03: srmGetShootMemAreaAddress(): Area[4] isn't Exist.
000143A5>    PropMgr:001b686f:00:0f: [7] *** mpu_send(0a 08 03 06 00 00 00 00 00 00)                 ; PROP_AVAIL_SHOT
00014413>    PropMgr:001b686f:00:0f: [8] *** mpu_send(06 04 03 10 00 00)                             ; PROP 80030008
0001454C>    Startup:001b686f:00:0f: [9] *** mpu_send(06 05 03 07 ff 00)                             ; PROP_BURST_COUNT
00014594>    Startup:9162007:80:03: CreatePackHeapObject
000145F0>    Startup:90439:80:03: AllocateMemoryUnit For OnlyMem1
0001460B>    Startup:90439:80:03: AllocateMemoryUnit For OnlyMem1
0001461E>    Startup:90439:80:03: AllocateMemoryUnit For OnlyMem1
00014630>    Startup:90439:80:03: AllocateMemoryUnit For OnlyMem1
00014765>    Startup:99:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[1]
00014793>    Startup:99:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[2]
000147FE>    Startup:916955:80:03: RearrangeMemMgr sub 1 0 0
0001485C>    Startup:9169509:80:03: fDevDone 1, dwLvLock 0
00014877>    Startup:916960:80:03: 0 0 0
00014893>    Startup:916961:80:03: PROP_MEMORY_STATUS(SELF) (10->)13 (OTHER) 0, 5276
000148B3>    Startup:916960:80:05: Deliver PROP_MEMORY_STATUS 19
000148FB>    Startup:9163905:80:03: MemMgr(IMAGE) 0 0
00014915>    Startup:9163905:80:03: MemMgr(IMAGE) 0 0
0001492C>    Startup:9163905:80:03: MemMgr(IMAGE) 0 1
00014941>    Startup:9163905:80:03: MemMgr(IMAGE) 0 0
000149E3>     RscMgr:9957:35:03: this->dwCardStatus[0] = 0x0(474)
00014A10>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00014A29>     RscMgr:916960:80:03: 0 0 0
00014A5C>     RscMgr:9957:35:03: this->dwCardStatus[1] = 0x0(474)
00014A80>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00014A95>     RscMgr:916960:80:03: 0 0 0
00014AC5>     RscMgr:995:35:03: PROP_PC_HDD_STATUS = 0x1
00014B2E>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00014B46>     RscMgr:916960:80:03: 0 0 0
00014B99>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00014BAE>     RscMgr:916960:80:03: 0 0 0
00014BF9>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00014C10>     RscMgr:916960:80:03: 0 0 0
00014CC2>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00014CD9>     RscMgr:916960:80:03: 0 0 0
00014D15>     RscMgr:99223:35:03: PROP_SAVE_MODE = 0x1
00014D66>     RscMgr:9927:35:03: PROP_CARD0_FOLDER_NUMBER
00014DA4>     RscMgr:9927:35:03: PROP_CARD1_FOLDER_NUMBER
00014E46>     RscMgr:995:35:03: PROP_NUMBER_OF_CONTINUOUS_MODE BaseDcfNo 3117
00014E84>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00014E9C>     RscMgr:916960:80:03: 0 0 0
00014ED4>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00014EEA>     RscMgr:916960:80:03: 0 0 0
00014F51>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00014F69>     RscMgr:916960:80:03: 0 0 0
00014F7F>     RscMgr:9931:35:03: PROP_CARD_EXTENSION 0
0001513F>     RscMgr:9977:35:03: PC_CLUSTER_SIZE = 0x10000
00015221>     RscMgr:995:80:03: SetAutoIsoCode 0x83
0001523C>     RscMgr:9963:35:03: ChangeAutoIsoCode Factor:1 AutoIsoCode:131 -> 131
00015288>     RscMgr:995:80:03: SetAutoIsoCode 0x83
0001529E>     RscMgr:9963:35:03: ChangeAutoIsoCode Factor:2 AutoIsoCode:131 -> 131
000152E4>     RscMgr:99:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[3]
00015305>     RscMgr:99:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[4]
00015328>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
0001533F>     RscMgr:916960:80:03: 0 0 0
00015386>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
0001539B>     RscMgr:916960:80:03: 0 0 0
000153F1>     RscMgr:99:35:03: RealClearBusy(0x40000) 0x0->0x0,0x0(0x0)[5]
00015441>     RscMgr:99:35:03: RealClearBusy(0x40000) 0x0->0x0,0x0(0x0)[6]
0001548D>     RscMgr:99:35:03: RealClearBusy(0x40000) 0x0->0x0,0x0(0x0)[7]
000154D7>     RscMgr:99:35:03: RealClearBusy(0x40000) 0x0->0x0,0x0(0x0)[8]
0001550B>     RscMgr:995:80:03: SetAutoIsoCode 0x78
00015521>     RscMgr:9963:35:03: ChangeAutoIsoCode Factor:0 AutoIsoCode:131 -> 120
0001557C>     RscMgr:99:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[9]
00015599>     RscMgr:99:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[10]
000155BC>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
000155E4>     RscMgr:916960:80:03: 0 0 0
00015655>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
0001566F>     RscMgr:916960:80:03: 0 0 0
000156C8>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
000156DF>     RscMgr:916960:80:03: 0 0 0
000157CF>     RscMgr:9911:35:03: RU CLUSTER_SIZE[0] = 0x407BA670
0001582C>     RscMgr:9911:35:03: RU CLUSTER_SIZE[1] = 0x407BA67C
000158F9>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 0, ClassID = 53
00015930>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 11, ClassID = 53
0001594B>   EventMgr:9972:37:03: Already SW1OFF
00015985>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 14, ClassID = 53
000159AF>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 15, ClassID = 53
000159D5>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 4, ClassID = 53
00015B31>    Startup:93650:19:03: FM_RegisterSpaceNotifyCallback
00015B55>    Startup:940111:1a:05: MRK_RegisterSpaceNotifyCallback
00015B72>    Startup:9755:1a:03: RegisterSpaceNotifyCallback : DriveNo = 2
00015B91>    Startup:94933:19:03: voiRegisterSpaceNotifyCallback : DriveNo = 2
00015BAD>    Startup:929099:19:03: [GPS] gpsRegisterSpaceNotifyCallback : DriveNo = 2
00015BD2>    Startup:93267:19:03: RegisterSpaceNotifyCallback : DriveNo = 2
00015C5E>    Startup:913:15:03: @Startup FIO_RegisterSpaceNotifyCallback(1,0xe04d4b0b,0x2) L:1051
00015C8C>    Startup:91703:1c:03: FcmcRegisterSpaceNotifyCallback : DriveNo = 2
00015CA8>    Startup:93650:19:03: FM_RegisterSpaceNotifyCallback
00015D31>    Startup:9124:39:05: InitializeJobClass (ID = 3158, Num = 15)
00015D52>    Startup:9121:39:05: InitializeJobClass 12 206 0 5544
00015DBA>    PropMgr:91:39:03: [BIND] dcsResultCBR (#x)
00015F48>    PropMgr:97:39:03: PROP_GPS_INFORMATION fGPSConnect = 0x0
00015F6B>    PropMgr:909:39:03: MPU 0x0 USB 0x0 WFT 0x0 INNER 0x0
00015F8E>    PropMgr:97:39:03: PROP_MPU_GPS fGPSConnect = 0x0
00015FA6>    PropMgr:909:39:03: MPU 0x0 USB 0x0 WFT 0x0 INNER 0x0
00016022>    PropMgr:91:39:03: @@@setDefaultImgDirection
00016083>    PropMgr:001b68db:00:0f: [31] *** mpu_recv(42 40 02 11 00 01 00 00 00 00 01 00 ff 01 00 00 00 00 00 00 00 ff 01 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 ff 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 00 00) ; AF2 group
000160AC>    PropMgr:91:39:03: @@@setDefaultImgDirection
000160C8>    PropMgr:90:39:03: @@@setDefaultGPSParam
000160E0>    PropMgr:9101:39:03: PROP_GPS_DEVICE_ACTIVE INNER 0x0 fGPSConnect = 0x0
00016104>    PropMgr:925:39:03: PROP_NETWORK_SYSTEM 0x0
0001612E>    PropMgr:001b68db:00:0f: [32] *** mpu_recv(08 06 01 04 00 00 00 00)                      ; PROP_AF_MODE
000161D4>    PropMgr:001b68db:00:0f: [33] *** mpu_recv(08 06 01 a2 00 00 00 00)                      ; ???
0001625B>    PropMgr:001b68db:00:0f: [34] *** mpu_recv(06 05 01 06 30 00)                            ; PROP_APERTURE
00016307>    PropMgr:001b68db:00:0f: [35] *** mpu_recv(06 05 03 23 2c 00)                            ; ???
00016664>    PropMgr:001b68db:00:0f: [36] *** mpu_recv(32 30 03 24 54 41 4d 52 4f 4e 20 31 36 2d 33 30 30 6d 6d 20 46 2f 33 2e 35 2d 36 2e 33 20 44 69 20 49 49 20 56 43 20 50 5a 44 20 42 30 31 36 00 00 00) ; PROP_LENS_NAME
000166EC>    PropMgr:001b68db:00:0f: [37] *** mpu_recv(06 04 03 25 00 00)                            ; ???
00016802>    PropMgr:001b68db:00:0f: [38] *** mpu_recv(06 05 01 99 00 00)                            ; PROP 80040057
00016883>    PropMgr:001b68db:00:0f: [39] *** mpu_recv(06 05 01 9a 00 00)                            ; PROP 80040058
000168D2>    PropMgr:9101:39:03: PROP_BTDEVICE_CONNECT WFT 0x0 fGPSConnect = 0x0
00016914>    PropMgr:001b68db:00:0f: [40] *** mpu_recv(06 05 01 06 30 00)                            ; PROP_APERTURE
000169C6>    PropMgr:001b68db:00:0f: [41] *** mpu_recv(06 05 01 3f 00 00)                            ; PROP_FLASH_ENABLE
00016A03>    PropMgr:91361:01:03: DivideLensInit2Data[3] comID 1 dataID 4 data 0x0
00016B04>    PropMgr:9970:81:03: PROP_STROBO_FIRING 0 Last 0
00016B1F>    PropMgr:9970:81:03: dwLastStroboFiring = 0  stroboFiring = 0
00016B6B>    PropMgr:001b686f:00:0f: [10] *** mpu_send(06 05 01 2e 01 00)                            ; PROP_SAVE_MODE
00016BDE>   EventMgr:99705:37:05: emLockControl (TYPE_JOBSTATE = #x)
00016C36>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00016C4F>     RscMgr:916960:80:03: 0 0 0
00016D17>    PropMgr:001b686f:00:0f: [11] *** mpu_send(0a 08 03 0b 00 00 00 00 00 00)                ; PROP 80030007
00016E49>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 20, ClassID = 57
00016E98>    Startup:917:39:05: InitializeInnerDevelopJobClass (ID = 3158, Num = 16)
00016EBE>    Startup:9163:39:05: InitializeHDRShootJobClass ( Num = 13 )
00016ED9>    Startup:91621:39:05: InitializeHDRSaveAndEndJobClass ( Num = 37 )
00016EF3>    Startup:910:39:05: InitializeGISShootJobClass ( Num = 13 )
00016F0E>    Startup:91197:39:05: InitializeGISSaveAndEndJobClass ( Num = 28, 31 )
00016F46>    Startup:9195:39:03: InitializeShufflehootJobClass (ID = 3158, Num = 15)
00016FA5>    Startup:99661:d9:03: InitializeGUILock (PUB)
00017021>    PropMgr:001b686f:00:0f: [12] *** mpu_send(06 05 03 19 01 00)                            ; PROP_TFT_STATUS
00017047>    PropMgr:9161:d9:03: [GUI] MasterResultCBR
000170A0>    PropMgr:9911235:8a:03: terminateChangeCBR : SHUTDOWN (255)
000170BB>    PropMgr:9911357:00:03: [TERMINATE] SHUTDOWN init comp
000170D8>    PropMgr:99114:8a:03: terminateChangeCBR : AUTO_POWEROFF (1)
000170F9>    PropMgr:9911103:00:03: [TERMINATE] Abort init comp
000171B1>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 0, ClassID = 150
000171E1>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 1, ClassID = 150
0001720A>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 4, ClassID = 150
000172CD>    PropMgr:993:96:03: PROP_SHOOTING_TYPE (#x->#x)
000172EC>    PropMgr:993:96:03: PROP_AF_SHIFT_AFB_INFO (#x 0)
0001745B>    Startup:001b686f:00:0f: [13] *** mpu_send(06 05 01 56 00 00)                            ; ???
0001748F>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 0, ClassID = 225
000174CF>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 11, ClassID = 225
000174F3>   EventMgr:9972:37:03: Already SW1OFF
0001751F>   MainCtrl:996139:94:03: MeteringTimerStart
0001754B>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 7, ClassID = 225
00017574>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 1, ClassID = 225
0001759B>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 4, ClassID = 225
000175C2>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 6, ClassID = 225
000175E7>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 3, ClassID = 225
0001760E>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 2, ClassID = 225
0001763A>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 20, ClassID = 225
0001766E>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 24, ClassID = 130
00017698>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 25, ClassID = 130
000176C5>   EventMgr:001b68db:00:0f: [42] *** mpu_recv(08 06 01 04 00 00 00 00)                      ; PROP_AF_MODE
00017760>    PropMgr:001b68db:00:0f: [43] *** mpu_recv(08 06 01 a2 00 00 00 00)                      ; ???
00017823>   MainCtrl:993069:94:03: PROP_DISPLAY_OFF_SENSOR 1
00017866>   MainCtrl:993069:94:03: PROP_DISPSENSOR_CTRL 1
000178CB>   MainCtrl:99621:94:03: PROP_SHOOTING_TYPE 0
000178E6>   MainCtrl:99605:94:03: set_lv_act2 : 0 -1 1 0
00017920>   MainCtrl:99625:94:03: PROP_GUI_STATE 0
00017950>   MainCtrl:996105:94:03: PROP_LV_ACTION LV_STOP
00017965>   MainCtrl:99619:94:03: judge_lv_disp_busy(mode_change): 0 0 1 1 0
00017999>   MainCtrl:993069:94:03: PROP_LV_DISPBUSY not Busy
000179C7>   MainCtrl:996297:94:03: PROP_LV_LOCK LVLOCK_PERMIT
000179DD>   MainCtrl:99605:94:03: set_lv_act2 : 0 1 1 0
000179F2>   MainCtrl:99619:94:03: judge_lv_disp_busy(mode_change): 0 0 1 1 0
00017A1C>   MainCtrl:993069:94:03: PROP_DISABLE_PLAY_IMAGE Enable Play
00017A53>   MainCtrl:9961:94:03: JobState 0
00017A67>   MainCtrl:9962769:94:03: on_digi_event start
00017A7B>   MainCtrl:99605:94:03: set_lv_act2 : 0 1 1 0
00017A8F>   MainCtrl:99619:94:03: judge_lv_disp_busy(mode_change): 0 0 1 1 0
00017ACD>   MainCtrl:996219:94:03: PROP_AE_MODE m_AeMode=0x03 m_SetTv =0x70 ,m_ModeBulb=0
00017AF8>   MainCtrl:996219:94:03: PROP_SET_TV  m_SetTv =0x70 m_AeMode=0x03 ,m_ModeBulb=0
00017BBA>    PropMgr:001b68db:00:0f: [44] *** mpu_recv(0e 0d 04 30 00 00 00 00 00 00 00 00 00 00)    ; ???
00017BDE>   MainCtrl:993069:94:03: QRTime 2
00017C38>    PropMgr:001b68db:00:0f: [45] *** mpu_recv(06 05 01 48 01 00)                            ; PROP_LIVE_VIEW_MOVIE_SELECT
00017CB0>   MainCtrl:001b68db:00:0f: [46] *** mpu_recv(06 05 01 4b 01 00)                            ; PROP_LIVE_VIEW_VIEWTYPE_SELECT
00017D53>    PropMgr:001b68db:00:0f: [47] *** mpu_recv(06 05 01 49 01 00)                            ; PROP_LIVE_VIEW_AF_SYSTEM
00017D8D>   MainCtrl:993069:94:03: PROP_VARIANGLE_GUICTRL Enable
00017DB3>   MainCtrl:9930669:94:03: PROP_HEADPHONE_VOLUME_VALUE : 0
00017E0B>    PropMgr:001b68db:00:0f: [48] *** mpu_recv(06 05 01 12 00 00)                            ; PROP_WBB_GM
00017E26>   MainCtrl:993069:94:03: PROP_MOVIE_PLAY_VOLUME : 5
00017E65>   MainCtrl:993069:94:16: PROP_LCD_OFFON_BUTTON : 1
00017E9D>   MainCtrl:993069:94:03: PROP_LV_CFILTER 0
00017EC2>   MainCtrl:001b68db:00:0f: [49] *** mpu_recv(06 05 01 13 00 00)                            ; PROP_WBB_BA
00017EE9>   MainCtrl:99605:94:03: set_lv_act2 : 0 1 1 0
00017F2B>   MainCtrl:99619:94:03: judge_lv_disp_busy(mode_change): 0 1 1 1 0
00017FBF>   MainCtrl:996294:94:03: PROP_GUIGROUND_STATE 1
00018018>   MainCtrl:996105:94:03: PROP_LV_ACTION LV_STOP
0001804C>   MainCtrl:001b68db:00:0f: [50] *** mpu_recv(10 0e 01 8f 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP_LV_CFILTER
00018066>   MainCtrl:99619:94:03: judge_lv_disp_busy(mode_change): 0 1 1 1 0
0001814E>    PropMgr:001b68db:00:0f: [51] *** mpu_recv(0e 0c 01 b1 00 00 00 00 00 00 00 00 00 00)    ; ???
000181B8>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
000181E7>     RscMgr:001b68db:00:0f: [52] *** mpu_recv(06 05 01 03 00 00)                            ; PROP_DRIVE_MODE
000181FE>     RscMgr:916960:80:03: 0 0 0
0001827C>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
00018297>     RscMgr:916960:80:03: 0 0 0
00018351>    PropMgr:001b686f:00:0f: [14] *** mpu_send(06 05 04 0e 01 00)                            ; PROP 8002000D
0001838C>    PropMgr:916:01:03: LV_CFilter : kind 0 hv 0
000183AB>    PropMgr:919:01:03: Level 0 0 0 0 0 0 0 0
000183D5>    PropMgr:9934309:81:03: @@@ PROP_LV_CFILTER 0
00018440>   MainCtrl:993069:94:03: PROP_LV_CFILTER 0
0001847B>   MainCtrl:993069:94:03: PROP_LV_DISPBUSY Busy
000184A6>   MainCtrl:993069:94:03: PROP_LV_DISPBUSY Busy
000184CE>   MainCtrl:993069:94:03: PROP_LV_DISPBUSY Busy
000184F0>    PropMgr:9197:01:03: MovieCFilter : kind 0 hv 0
00018507>    PropMgr:919709:01:03: Level 0 0 0 0 0 0
00018526>    PropMgr:99346:81:03: @@@ PROP_MOVIE_CFILTER 0
00018575>   MainCtrl:993069:94:03: PROP_LV_DISPBUSY not Busy
00018617>    PropMgr:913:15:03: @PropMgr FIO_SuspendDelayFlush(0) L:709
00018645>   MainCtrl:996100:94:03: CardCover=0
0001865F>    PropMgr:9161:94:03: regist master CardCover
00018692>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 13, ClassID = 225
000186C0>    Startup:920661:3a:03: TA10_Initialize : Start
00018743>    PropMgr:001b686f:00:0f: [15] *** mpu_send(06 05 03 40 00 00)                            ; PROP 80030040
00018866>    PropMgr:92015:3a:03: ### TA10Setting Clear (OFF->OFF) ###
0001888D>    PropMgr:920139:3a:03: ChangePropCBR ShotsPlan 2 / TotalSheets 2
00018B69>    PropMgr:001b686f:00:0f: [16] *** mpu_send(0c 0b 03 53 02 00 48 81 81 00 00 00)          ; PROP 80030058
00018C03>    Startup:9203:3a:03: TA10_Initialize : End
00018C2D>    Startup:001b686f:00:0f: [17] *** mpu_send(0c 0b 03 53 02 00 48 81 81 00 00 00)          ; PROP 80030058
00018C5B>    Startup:993529:3c:03: HDR_Initialize : Start
00018D5A>    PropMgr:993141:3c:03: ### HDRSetting Clear (OFF->OFF) ###
00018D77>    PropMgr:9931:3c:03: ChangePropCBR HDRFunc 0
00018DCB>    Startup:99710:3c:03: HDRS_Initialize
00018DED>    Startup:9972997:3c:03: CreateStageClass
00018E78>    Startup:997211:3c:03: HDRS_Initialize : End
00018E90>    Startup:993643:3c:03: HDR_Initialize : End
00018EAB>    Startup:99361:3d:03: GIS_Initialize : Start
00018F85>    PropMgr:993241:3d:03: ### GISSetting Clear (OFF->OFF) ###
00018FA1>    PropMgr:99321:3d:03: ChangePropCBR GISFunc 0
00018FF4>    Startup:997471:3d:03: GISS_Initialize
00019017>    Startup:99747:3d:03: CreateStageClass
00019090>    Startup:997497:3d:03: GISS_Initialize : End
000190A8>    Startup:993741:3d:03: GIS_Initialize : End
000190F4>    FileMgr:91:19:03: PROP_CARD1_STATUS = #x
00019147>    FileMgr:913:15:03: @FileMgr FIO_SetCardChangeFlag(0,1) L:1060
0001917B>    FileMgr:9007:19:03: PROP_CARD1_FOLDER_NUMBER = 142
000191A2>    FileMgr:944:19:03: PROP_CARD1_FILE_NUMBER = 0
000191E0>    FileMgr:939:19:03: PROP_CARD2_STATUS = #x
0001921D>    FileMgr:913:15:03: @FileMgr FIO_SetCardChangeFlag(1,1) L:1060
00019242>    FileMgr:940:19:03: PROP_CARD2_FOLDER_NUMBER = 100
0001926D>    FileMgr:9451:19:03: PROP_CARD2_FILE_NUMBER = 3117
000192A1>    FileMgr:953:19:03: PROP_FILE_NUMBERING_MODE = 1, 0
000192C3>    FileMgr:947:19:03: PROP_CARD_EXTENSION = 0
000192EB>    FileMgr:940:19:03: PROP_CURRENT_MEDIA = 2
00019312>    FileMgr:9121:19:03: PROP_USBDEVICE_CONNECT = -1
00019336>    FileMgr:954:19:03: PROP_NUMBER_OF_CONTINUOUS_MODE = 3117
00019369>    FileMgr:001b68db:00:0f: [53] *** mpu_recv(06 05 03 38 93 00)                            ; PROP 80030035
000193A0>    FileMgr:99157:00:03: [STARTUP]startupCompleteCallback 0x10
000193C0>    FileMgr:991699:00:03: [SEQ] NotifyComplete (Cur = 2, #x, Flag = #x)
000193EB>    FileMgr:953:19:03: PROP_DSDEFINE ModelId 5999913
0001941B>    FileMgr:95:19:03: PROP_APPENDMOVINFO Handle 0,205001d
0001943C>    FileMgr:95:19:03: PROP_APPENDMOVINFO VideoSnapMode 4,205001d
00019469>    FileMgr:9603:19:03: PROP_SPECIAL_OPTION = 16384
00019494>    FileMgr:001b68db:00:0f: [54] *** mpu_recv(06 05 04 29 01 00)                            ; ???
000194DA>   MainCtrl:99619:94:03: judge_lv_disp_busy(mode_change): 0 1 1 1 0
0001951A>    FileMgr:9637:19:03: PROP_SCREEN_SAVER = 0
0001953F>    FileMgr:9663:19:03: PROP_CARD1_RU_SIZE -1
0001956C>    FileMgr:001b68db:00:0f: [55] *** mpu_recv(0a 09 01 55 00 00 02 00 00 01)                ; PROP_MULTIPLE_EXPOSURE_SETTING
000195A9>    PropMgr:993475:81:03: PROP_MULTIPLE_EXPOSURE_SETTING 0
000195D0>    PropMgr:9123:01:03: Deliv WaitID = 0xd555558, 0x55bbef(1)
0001963F>     RscMgr:99:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[11]
00019664>     RscMgr:99:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[12]
0001968D>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
000196A7>     RscMgr:916960:80:03: 0 0 0
000196E5>    PropMgr:9123:01:03: Deliv WaitID = 0xd555558, 0x590575(2)
00019716>    PropMgr:9123:01:03: Deliv WaitID = 0xd555558, 0x566a7(3)
0001974F>    PropMgr:9123:01:03: Deliv WaitID = 0xd555558, 0x55b0e7(4)
0001977B>    PropMgr:92015:3a:03: ### TA10Setting Clear (OFF->OFF) ###
00019798>    PropMgr:920139:3a:03: ChangePropCBR ShotsPlan 2 / TotalSheets 2
000197B6>    PropMgr:9123:01:03: Deliv WaitID = 0xd555558, 0x5a07659(5)
000197E1>    PropMgr:9123:01:03: Deliv WaitID = 0xd555558, 0x55b8ff(6)
0001980A>    PropMgr:9123:01:03: Deliv WaitID = 0xd555558, 0x55b9fb(7)
00019838>    PropMgr:910:01:03: Complete WaitID = 0xd555558, 0x55bbef(6)
00019863>    PropMgr:910:01:03: Complete WaitID = 0xd555558, 0x590575(5)
00019890>    PropMgr:910:01:03: Complete WaitID = 0xd555558, 0x566a7(4)
000198B8>    PropMgr:910:01:03: Complete WaitID = 0xd555558, 0x55b0e7(3)
00019924>    PropMgr:910:01:03: Complete WaitID = 0xd555558, 0x5a07659(2)
00019951>    PropMgr:910:01:03: Complete WaitID = 0xd555558, 0x55b8ff(1)
0001997A>    PropMgr:910:01:03: Complete WaitID = 0xd555558, 0x55b9fb(0)
000199B1>    PropMgr:001b686f:00:0f: [18] *** mpu_send(08 06 00 00 01 55 00 00)                      ; Complete WaitID = PROP_MULTIPLE_EXPOSURE_SETTING
00019A67>    PropMgr:001b686f:00:0f: [19] *** mpu_send(0c 0b 03 53 02 00 48 81 81 00 00 00)          ; PROP 80030058
00019AF7>    FileMgr:001b686f:00:0f: [20] *** mpu_send(0c 0b 03 53 02 00 48 81 81 00 00 00)          ; PROP 80030058
00019B26>    FileMgr:9675:19:03: PROP_CARD2_RU_SIZE 524288
00019B64>    FileMgr:907:19:03: fmInitialized
00019BC6>    FileMgr:90607:1c:03: _FC_SetDirSuffix (CANON)
00019BFF>    FileMgr:90:19:03: fmPrepare
00019C4E>    FileMgr:913:15:03: @FileMgr FIO_Init(25,28,0xe069ad83) L:870
00019C73>    FileMgr:92719:13:03: CSMGR_Initialize
00019CF8>    FileMgr:001b68db:00:0f: [56] *** mpu_recv(06 05 01 2e 01 00)                            ; PROP_SAVE_MODE
00019D44>     RscMgr:99223:35:03: PROP_SAVE_MODE = 0x1
0001A181>    FileMgr:001b68db:00:0f: [57] *** mpu_recv(08 06 01 1d 87 87 00 00)                      ; PROP_PICTURE_STYLE
0001A217>    PropMgr:001b68db:00:0f: [58] *** mpu_recv(06 05 01 74 00 00)                            ; PROP_HIGHISO_NOISE_REDUCTION
0001A26C>    FileMgr:929:13:03: InitializeLogicalStorage: LStorageList = NULL
0001A28B>    FileMgr:929:13:03: SocketServiceInstall: SUCCESS
0001A2B3>    FileMgr:001b68db:00:0f: [59] *** mpu_recv(06 05 01 75 00 00)                            ; PROP_HTP
0001A315>    FileMgr:913:15:03: @FileMgr FIO_GetSupportedDriveInfo(0x2233f4) L:1102
0001A346>    FileMgr:93055:18:03: InitializeSDDriver
0001A5D2>    FileMgr:9257:13:03: RegisterClient: handler=#x 1
0001A5F1>    FileMgr:9269:13:03: RegisterClient: SUCCESS
0001A606>    FileMgr:920:13:03: CSMGR_Initialize End
0001A621>    FileMgr:9361:19:03: fmAllocDcfNo(#x)(#x)
0001A66A>     RscMgr:99:35:03: srmAllocDcfNoTable
0001A694>     RscMgr:93613:19:03: fmAllocateDcfNoCompleteCallback(#x,#x)
0001A6DE>    FileMgr:901:19:03: fmAllocDcfNo : DcfNoTable(#x)
0001A722>    FileMgr:913:15:03: @FileMgr FIO_MountDevice(1,0,0) L:901
0001A741>    FileMgr:9267:16:03: [FSUmountDevice] (#x)
0001A756>    FileMgr:921:13:03: MapPhysicToLog: StorageID=1
0001A76A>    FileMgr:9231:13:03: MapPhysicToLog: SUCCESS(#x)
0001A77F>    FileMgr:9205:13:03: CSMGR_MountCard : Message=#x, pLStorage=#x
0001A7B6>     NFCMgr:92537:3e:03:  PROP_SPECIAL_OPTION ->init (0x4000)
0001A9A4>     NFCMgr:9257511:3e:03:  nfcmgrstate_Initialize:NewsDet_R Hi
0001AA60>  CSMgrTask:9265:13:03: CSMgrTask: pMessage=#x, pLStorage=#x
0001AA7B>  CSMgrTask:92621:13:03: MapLogToPhysic: pLStorage=#x
0001AA90>  CSMgrTask:92635:13:03: MapLogToPhysic: SUCCESS(ID=1)
0001AAA7>  CSMgrTask:92621:13:03: MapLogToPhysic: pLStorage=#x
0001AABB>  CSMgrTask:92635:13:03: MapLogToPhysic: SUCCESS(ID=1)
0001AACD>  CSMgrTask:9:18:03: ---- SDEventHandler(ID=1:Event=8) ----
0001AAE9>  CSMgrTask:93063:16:03: Set StgDev:1
0001AB33>  CSMgrTask:997:18:03: SDPowerOn
0001AC21>     NFCMgr:001b68db:00:0f: [60] *** mpu_recv(06 05 01 07 00 01)                            ; PROP_ISO
0001ACB0>    PropMgr:9123:01:03: Deliv WaitID = 0xd555555b, 0x590575(1)
0001ACE4>    PropMgr:9123:01:03: Deliv WaitID = 0xd555555b, 0x566a7(2)
0001AD11>    PropMgr:910:01:03: Complete WaitID = 0xd555555b, 0x590575(1)
0001AD3E>    PropMgr:910:01:03: Complete WaitID = 0xd555555b, 0x566a7(0)
0001AD77>     NFCMgr:001b686f:00:0f: [21] *** mpu_send(08 06 00 00 01 07 00 00)                      ; Complete WaitID = PROP_ISO
0001B30B>   PowerMgr:001b68db:00:0f: [61] *** mpu_recv(0a 08 01 34 00 00 01 03 01 00)                ; PROP_CARD1_IMAGE_QUALITY
0001B38B>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
0001B3A8>     RscMgr:916960:80:03: 0 0 0
0001B3F1>    PropMgr:9123:01:03: Deliv WaitID = 0xd555557, 0x590575(1)
0001B423>    PropMgr:9123:01:03: Deliv WaitID = 0xd555557, 0x566a7(2)
0001B456>    PropMgr:910:01:03: Complete WaitID = 0xd555557, 0x590575(1)
0001B480>    PropMgr:910:01:03: Complete WaitID = 0xd555557, 0x566a7(0)
0001B4BB>   PowerMgr:001b686f:00:0f: [22] *** mpu_send(08 06 00 00 01 34 00 00)                      ; Complete WaitID = PROP_CARD1_IMAGE_QUALITY
0001B6D8>  CSMgrTask:94053:18:03: SD initialize start
0001B776>  CSMgrTask:001b68db:00:0f: [62] *** mpu_recv(0a 08 01 35 00 00 01 03 01 00)                ; PROP_CARD2_IMAGE_QUALITY
0001B7DD>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
0001B7FB>     RscMgr:916960:80:03: 0 0 0
0001B83C>    PropMgr:9123:01:03: Deliv WaitID = 0xd5555570, 0x590575(1)
0001B86C>    PropMgr:9123:01:03: Deliv WaitID = 0xd5555570, 0x566a7(2)
0001B89A>    PropMgr:910:01:03: Complete WaitID = 0xd5555570, 0x590575(1)
0001B8C8>    PropMgr:910:01:03: Complete WaitID = 0xd5555570, 0x566a7(0)
0001B904>  CSMgrTask:001b686f:00:0f: [23] *** mpu_send(08 06 00 00 01 35 00 00)                      ; Complete WaitID = PROP_CARD2_IMAGE_QUALITY
0001BCA4>   PowerMgr:001b68db:00:0f: [63] *** mpu_recv(0a 09 01 70 00 00 00 00 00 01)                ; PROP_HDR_SETTING
0001BCE1>    PropMgr:993475:81:03: PROP_HDR_SETTING 0
0001BD0C>    PropMgr:9123:01:03: Deliv WaitID = 0xd5555599, 0x55bbef(1)
0001BD5C>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
0001BD76>     RscMgr:916960:80:03: 0 0 0
0001BDC2>    PropMgr:9123:01:03: Deliv WaitID = 0xd5555599, 0x590575(2)
0001BDF6>    PropMgr:9123:01:03: Deliv WaitID = 0xd5555599, 0x566a7(3)
0001BE3E>    PropMgr:9123:01:03: Deliv WaitID = 0xd5555599, 0x55b0e7(4)
0001BE71>    PropMgr:9123:01:03: Deliv WaitID = 0xd5555599, 0x5a07659(5)
0001BE9B>    PropMgr:993141:3c:03: ### HDRSetting Clear (OFF->OFF) ###
0001BEB1>    PropMgr:9931:3c:03: ChangePropCBR HDRFunc 0
0001BEC8>    PropMgr:9123:01:03: Deliv WaitID = 0xd5555599, 0x55b8ff(6)
0001BEF9>    PropMgr:9123:01:03: Deliv WaitID = 0xd5555599, 0x55b9fb(7)
0001BF29>    PropMgr:910:01:03: Complete WaitID = 0xd5555599, 0x55bbef(6)
0001BF55>    PropMgr:910:01:03: Complete WaitID = 0xd5555599, 0x590575(5)
0001BF7E>    PropMgr:910:01:03: Complete WaitID = 0xd5555599, 0x566a7(4)
0001BFA5>    PropMgr:910:01:03: Complete WaitID = 0xd5555599, 0x55b0e7(3)
0001BFCC>    PropMgr:910:01:03: Complete WaitID = 0xd5555599, 0x5a07659(2)
0001BFF5>    PropMgr:910:01:03: Complete WaitID = 0xd5555599, 0x55b8ff(1)
0001C01E>    PropMgr:910:01:03: Complete WaitID = 0xd5555599, 0x55b9fb(0)
0001C057>  CSMgrTask:001b686f:00:0f: [24] *** mpu_send(08 06 00 00 01 70 00 00)                      ; Complete WaitID = PROP_HDR_SETTING
0001C21F>   PowerMgr:001b68db:00:0f: [64] *** mpu_recv(0a 08 01 85 00 00 00 01 01 00)                ; PROP_GIS_SETTING
0001C25B>    PropMgr:993475:81:03: PROP_GIS_SETTING Func 0
0001C281>    PropMgr:9123:01:03: Deliv WaitID = 0xd555559, 0x55bbef(1)
0001C2D0>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
0001C2EB>     RscMgr:916960:80:03: 0 0 0
0001C336>    PropMgr:9123:01:03: Deliv WaitID = 0xd555559, 0x590575(2)
0001C364>    PropMgr:9123:01:03: Deliv WaitID = 0xd555559, 0x566a7(3)
0001C39C>    PropMgr:9123:01:03: Deliv WaitID = 0xd555559, 0x55b0e7(4)
0001C3C5>    PropMgr:9123:01:03: Deliv WaitID = 0xd555559, 0x55b8ff(5)
0001C3EB>    PropMgr:993241:3d:03: ### GISSetting Clear (OFF->OFF) ###
0001C400>    PropMgr:99321:3d:03: ChangePropCBR GISFunc 0
0001C419>    PropMgr:9123:01:03: Deliv WaitID = 0xd555559, 0x55b9fb(6)
0001C447>    PropMgr:910:01:03: Complete WaitID = 0xd555559, 0x55bbef(5)
0001C474>    PropMgr:910:01:03: Complete WaitID = 0xd555559, 0x590575(4)
0001C49D>    PropMgr:910:01:03: Complete WaitID = 0xd555559, 0x566a7(3)
0001C4C4>    PropMgr:910:01:03: Complete WaitID = 0xd555559, 0x55b0e7(2)
0001C4EB>    PropMgr:910:01:03: Complete WaitID = 0xd555559, 0x55b8ff(1)
0001C514>    PropMgr:910:01:03: Complete WaitID = 0xd555559, 0x55b9fb(0)
0001C550>  CSMgrTask:001b686f:00:0f: [25] *** mpu_send(08 06 00 00 01 85 00 00)                      ; Complete WaitID = PROP_GIS_SETTING
00028E64>    CE_Main:925273:3e:03:  ce_completion payload=84 num=2
00028F7B>     NFCMgr:92579:3e:03:  nfcmgrstate_Initialize:wtime=0
000292BF>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 0, ClassID = 62
000292F9>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 7, ClassID = 62
00029327>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 11, ClassID = 62
00029344>   EventMgr:9972:37:03: Already SW1OFF
0002936F>     NFCMgr:92579:3e:03:  nfcmgrstate_Initialize End
000293B7>     NFCMgr:925497:3e:03:  PROP_AUTO_POWEROFF 1
000293F2>     NFCMgr:9253:3e:03:  PROP_NFC_APPLI_INFO jp.co.canon.ic.cameraconnect
0002940C>     NFCMgr:925309:3e:03:  PROP_NFC_APPLI_INFO a01
000294E0>     NFCMgr:925377:3e:03:  ChkRWInfo Illegal product type(pdt=dslr)
00029532>     NFCMgr:925321:3e:03:  PROP_DSDEFINE Canon%20EOS%20200D
0002954F>     NFCMgr:9254547:3e:03:  PROP_DSDEFINE 0x32cc
000295D1>     NFCMgr:9253:3e:03:  PropChange:PROP_NETWORK_NICKNAME(Vis_Cam)->(Vis_Cam)
0002960A>     NFCMgr:9254547:3e:03:  PROP_NETWORK_SYSTEM MODE_OFF 0
00029631>     NFCMgr:9254015:3e:03:  PROP_NFC_SETTING enable 1
00029657>     NFCMgr:9254037:3e:03:  PROP_FIXED_MOVIE off 0
0002967C>     NFCMgr:9254067:3e:03:  SHOOTING_TYPE_MOVIE off 0
0002969F>     NFCMgr:925407:3e:03:  PROP_TIMELAPSE_MOVIE_SETTING off 0
000296C5>     NFCMgr:925419:3e:03:  PROP_MULTIPLE_EXPOSURE_SETTING OFF 0
000296E8>     NFCMgr:925413:3e:03:  PROP_VARIANGLEDISPLAY_ONOFF ON 1
0002970B>     NFCMgr:9254509:3e:03:  PROP_VIDEOSNAP_MODE OFF 0
000297E4>     NFCMgr:925452:3e:03:  PROP_ICU_UILock OFF 0x0
0002980C>     NFCMgr:92546:3e:03:  PROP_PHYSICAL_CONNECT disconnect 0
0002982E>     NFCMgr:925351:3e:03:  PROP_STARTUP_CONDITION NOT BLE_LOCKOFF (0x1)
00029886>     NFCMgr:904507:3e:03: [BLE] Initialize : Enter
00029B85>     NFCMgr:9245:3e:03: [BLE] BLESIODRIVER_Initialize END
00029BAC>     NFCMgr:9220:3e:03: [BLE] blesiodriver_SioInitialize END
00029BF9>     NFCMgr:92772:3e:03: [BLE] BLEFirmUp_InitializeTest
00029DC1>     NFCMgr:9069:3e:03: [BLE] PROP_DSDEFINE 0x32cc
00029E38>     NFCMgr:90631:3e:03: [BLE] PROP_NETWORK_NICKNAME Vis_Cam
00029E9D>     NFCMgr:9065:3e:03:  [BLE] PROP_FIXED_MOVIE off 0
00029F01>     NFCMgr:90631:3e:03: [BLE] PROP_VIDEOSNAP_MODE OFF 0
00029F33>     NFCMgr:90659:3e:03: [BLE] PROP_BLE_SETTING OFF(0)
00029F4B>     NFCMgr:9099:3e:03: [BLE] Enter blemgr_SmartphoneGps_CheckState().
00029F63>     NFCMgr:90901:3e:03: [BLE] Enter CheckGpsAndBleState().
00029F9E>     NFCMgr:9099:3e:03: [BLE] Enter blemgr_SmartphoneGps_CheckState().
00029FB4>     NFCMgr:90601:3e:03: [BLE] PROP_BLE_PAIRING_INFO fSet(0 0) 2 2
00029FE7>     NFCMgr:901605:3e:03: [BLE] CheckWiFiConnect Uuid is Null
00029FFC>     NFCMgr:90179:3e:03: [BLE] CheckWiFiConnect FALSE
0002A024>     NFCMgr:906579:3e:03: [BLE] PROP_BLE_REMOTE_RESULT 0
0002A04C>     NFCMgr:9099:3e:03: [BLE] Enter blemgr_SmartphoneGps_CheckState().
0002A061>     NFCMgr:90901:3e:03: [BLE] Enter CheckGpsAndBleState().
0002A08D>     NFCMgr:9099:3e:03: [BLE] Enter blemgr_SmartphoneGps_CheckState().
0002A0A0>     NFCMgr:90901:3e:03: [BLE] Enter CheckGpsAndBleState().
0002A0D9>     NFCMgr:90635:3e:03: [BLE] PROP_PHYSICAL_CONNECT disconnect 0
0002A120>     NFCMgr:906619:3e:03: [BLE] PROP_BATTERY_POWER:not BAT_NONE 2
0002A13F>     NFCMgr:90415:3e:03: [BLE] InitializeChkState
0002A159>     NFCMgr:900609:3e:03: [BLE] SendCamPowerState :0x1
0004552D>     NFCMgr:907:3e:03: [BLE] Enter blemgr_SmartPhoneGps_NopEvent!!!
00045549>     NFCMgr:909:3e:03: [BLE]   Status=0, Event=13
0004556B>     NFCMgr:907:3e:03: [BLE] Enter blemgr_SmartPhoneGps_NopEvent!!!
00045582>     NFCMgr:909:3e:03: [BLE]   Status=0, Event=13
0004559D>     NFCMgr:907:3e:03: [BLE] Enter blemgr_SmartPhoneGps_NopEvent!!!
000455B2>     NFCMgr:909:3e:03: [BLE]   Status=0, Event=13
00045CD2>     NFCMgr:9011:3e:03: [BLE] ProcSpiRecvData Cat = 0x1, cmd = 0x85
00045CFD>     NFCMgr:901:3e:03: [BLE] RecvNtfBleState IDLE(1)
00045D54>     NFCMgr:90077:3e:03: [BLE] SendGetPairingInfo :0x1
000464FF>     NFCMgr:9099:3e:03: [BLE] Enter blemgr_SmartphoneGps_CheckState().
00046F0D>     NFCMgr:9011:3e:03: [BLE] ProcSpiRecvData Cat = 0x2, cmd = 0x86
00046F3C>     NFCMgr:9017:3e:03: [BLE] JudgeBlePairInfo SD Host&BLE:None
00046F55>     NFCMgr:9001:3e:03: [BLE] CheckNextBlePairInfo:SD01->ARC
00046F6A>     NFCMgr:90077:3e:03: [BLE] SendGetPairingInfo :0x2
000480AB>     NFCMgr:9011:3e:03: [BLE] ProcSpiRecvData Cat = 0x2, cmd = 0x86
000480CA>     NFCMgr:9017:3e:03: [BLE] JudgeBlePairInfo ARC Host&BLE:None
000480E0>     NFCMgr:9097:3e:03: [BLE] CheckNextBlePairInfo:ARC->END
00052656>  CSMgrTask:947:18:03: power 18
00052671>  CSMgrTask:9963:18:16: SdSwitchVoltage 1
0005F93E>  CSMgrTask:9401:18:16: SD initialize end speed=2 clock=2 UHS=1
0005F97C>  CSMgrTask:94155:18:16: strength 1111 current 3 mode 2
0005FF38>  CSMgrTask:94315:18:16: Name:       Size: 15271(1dd3800)
0005FF64>  CSMgrTask:949:18:03: pBlkDev=#x
0005FF7A>  CSMgrTask:949:18:03: nBlocks=31275008, blksPerTrack=0, nHeads=0
0006327F>  CSMgrTask:9363:16:05: fsuGetPart: Block(8192, 31266816, 31275008)
00064301>  CSMgrTask:927717:16:16: efat_map_filesys 8192 B: 1
0006482C>  CSMgrTask:913:15:03: @CSMgrTask FIO_GetSupportedDriveInfo(0x22eca8) L:1102
00064885>  CSMgrTask:92029:16:16: AllocateMemoryStrictly For Speed Class!!!
000AC4C5>  CSMgrTask:9205:16:16: Attach SC 1 0 80 10 7632
000AC748>  CSMgrTask:913:15:03: @CSMgrTask FIO_GetProductName(1) L:1075
000AC76D>  CSMgrTask:9304:16:03: Get StgDev:1
000AC78E>  CSMgrTask:936709:19:03: EV_INSERTION_COMPLETE : ID = 1, stat = 8192
000AC7AD>  CSMgrTask:93677:19:03: bWormCard = 0
000AC7C2>  CSMgrTask:9367:19:03: bWriteOnceCard = 0
000AC7ED>    FileMgr:9095:19:03: fmNormalMountCard (ID = 2, Ret = 0)
000AC812>    FileMgr:905:19:03: fmPrepareShooting (Drive = 2)
000AC854>    FileMgr:913:15:03: @FileMgr FIO_GetDriveName(1,0x2233d0) L:883
000AC86F>    FileMgr:9304:16:03: Get StgDev:1
000AC88D>    FileMgr:90601:1c:03: _FC_PrepareCatalog (2, B:)
000AC8DA>    FileMgr:913:15:03: @FileMgr FIO_GetFileInfo(B:/DCIM,0x223240) L:351
000AC9F0>  CSMgrTask:913:15:03: @CSMgrTask FIO_IsExistFile(B:/STGDBG99.TXT) L:1118
000ACFB8>    FileMgr:913:15:03: @FileMgr FIO_GetFileInfo(B:/MISC,0x223240) L:351
000AD730>    FileMgr:913:15:03: @FileMgr FIO_FindFirstEx(B:/DCIM,0x223220) L:787
000AD767>    FileMgr:913:15:03: @FileMgr FIO_Flush(B:/DCIM) L:632
000AD787>    FileMgr:9304:16:03: Get StgDev:1
000AD7C6>    FileMgr:92770:15:03: Flush:B:/DCIM
000AD7F1>    FileMgr:913:15:03: @FileMgr FIO_SetError(0) L:852
000AD8C4>  CSMgrTask:90:18:03: ---- SDEventHandler(ID=1:< B: >) Mounted ----
000ADEE7>    FileMgr:913:15:03: @FileMgr FIO_FindCloseEx(0x979834) L:845
000ADF2C>    FileMgr:913:15:03: @FileMgr FIO_GetError( ) L:858
000ADF6D>    FileMgr:913:15:03: @FileMgr FIO_FindFirstEx(B:/DCIM/100CANON,0x223228) L:787
000ADF97>    FileMgr:913:15:03: @FileMgr FIO_Flush(B:/DCIM/100CANON) L:632
000ADFAF>    FileMgr:9304:16:03: Get StgDev:1
000ADFE1>    FileMgr:92770:15:03: Flush:B:/DCIM/100CANON
000AE009>    FileMgr:913:15:03: @FileMgr FIO_SetError(0) L:852
000AE5B7>    FileMgr:913:15:03: @FileMgr FIO_FindCloseEx(0x979834) L:845
000AE5F4>    FileMgr:913:15:03: @FileMgr FIO_GetError( ) L:858
000AE61C>    FileMgr:9026:19:03: DirNo = 100, FileNo = 0
000AE65C>    FileMgr:913:15:03: @FileMgr FIO_GetCardInfo(B:,0x223400,0x2233ec,0x2233f4,0x2233fc,0x2233e8,1) L:959
000AE6A4>    FileMgr:913:15:03: @FileMgr FIO_GetSupportedDriveInfo(0x22335c) L:1102
000AE6D2>    FileMgr:913:15:03: @FileMgr FIO_GetSCParam(1) L:1202
000AE6FE>    FileMgr:913:15:03: @FileMgr FIO_GetSupportedDriveInfo(0x22335c) L:1102
000AE723>    FileMgr:913:15:03: @FileMgr FIO_GetSCParam(1) L:1202
000AE7B7>    FileMgr:9029:19:03: Cluster = 32768, Total = 488416, Free = 488406 RU = 524288 FreeRU = 30512
000AE7FA>    FileMgr:9537:1c:03: _FC_GetNewDirDcfNo (2, 0, 0, 0)
000AE821>    FileMgr:923:19:03: fmSetInitialCardInfo (Drive = 2, 0)
000AE884>    PropMgr:001b686f:00:0f: [26] *** mpu_send(08 06 01 24 00 01 00 00)                      ; PROP_CARD2_STATUS
000AEA38>    PropMgr:001b686f:00:0f: [27] *** mpu_send(08 06 01 27 00 64 00 00)                      ; PROP_CARD2_FOLDER_NUMBER
000AEA6D>    PropMgr:001b68db:00:0f: [65] *** mpu_recv(08 06 01 24 00 01 00 00)                      ; PROP_CARD2_STATUS
000AEAA5>     RscMgr:9927:35:03: PROP_CARD1_FOLDER_NUMBER
000AEB57>     RscMgr:9957:35:03: this->dwCardStatus[1] = 0x1(474)
000AEB94>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
000AEBAC>     RscMgr:916960:80:03: 0 0 0
000AECDC>     RscMgr:9911:35:03: RU CLUSTER_SIZE[1] = 0x407BA67C
000AED4C>    FileMgr:913:15:03: @FileMgr FIO_GetDriveName(1,0x2233e4) L:883
000AED6C>    FileMgr:9304:16:03: Get StgDev:1
000AED97>    FileMgr:913:15:03: @FileMgr FIO_GetFreeRU(B:,0x2233e0) L:1010
000AEDC1>    FileMgr:913:15:03: @FileMgr FIO_GetSupportedDriveInfo(0x22339c) L:1102
000AEDEC>    FileMgr:913:15:03: @FileMgr FIO_GetSCParam(1) L:1202
000AEE7E>    FileMgr:9535:19:03: fmWrapperRU1 : DriveNo = 2 B: 30512
000AEE9D>    FileMgr:95379:19:03: fmWrapperRU : DriveNo = 2 B: 30512
000AEEB8>    FileMgr:900:19:03: fmSetInitialCardInfo (FreeRU = 30512)
000AEEED>     RscMgr:9929:35:03: Storage Space 488406, FreeRUCount 30512
000AEF94>    FileMgr:90909:19:03: pfNotifyDcfNoCBR(2:100_0000)
000AEFDA>     RscMgr:997:35:03: srmNotifyDcfNo 0x2 100 0 0 1
000AEFFD>     RscMgr:900995:35:03: srmSetDcfNoTableOrDiff 1 100 0 1
000AF017>     RscMgr:90092:35:03: Diff Dcf List
000AF02B>     RscMgr:90094:35:03: Create Diff Dcf ListItem 100
000AF043>     RscMgr:9007:35:03: fTemporary 1 pMaxDcfNoInFolder->fTemporary 1
000AF05A>     RscMgr:900:35:03: Diff Dcf Over Write 100
000AF079>     RscMgr:99953:35:03: ####### [1]DCF No 3117
000AF0E4>     RscMgr:9937:35:03: BURST 28 Enable 1319 Reserve 12107776
000AF10C>     RscMgr:99349:35:03: Burst 28 ENABLE 1319 Reserve 12107776
000AF135>     RscMgr:99:35:03: RealClearBusy(0x2100) 0x0->0x0,0x0(0x0)[13]
000AF157>     RscMgr:99157:00:03: [STARTUP]startupCompleteCallback 0x20000
000AF17A>     RscMgr:991699:00:03: [SEQ] NotifyComplete (Cur = 2, #x, Flag = #x)
000AF1EB>    PropMgr:001b686f:00:0f: [28] *** mpu_send(08 06 01 2a 0c 2d 00 00)                      ; PROP_CARD2_FILE_NUMBER
000AF289>    PropMgr:001b686f:00:0f: [29] *** mpu_send(06 05 03 07 1c 00)                            ; PROP_BURST_COUNT
000AF31E>    FileMgr:001b686f:00:0f: [30] *** mpu_send(0a 08 03 06 00 00 05 27 00 00)                ; PROP_AVAIL_SHOT
000AF343>    FileMgr:99157:00:03: [STARTUP]startupCompleteCallback 0x400000
000AF369>    FileMgr:991699:00:03: [SEQ] NotifyComplete (Cur = 2, #x, Flag = #x)
000AF3C0>    FileMgr:940:19:03: PROP_CARD2_FOLDER_NUMBER = 100
000AF3ED>    FileMgr:939:19:03: PROP_CARD2_STATUS = #x
000AF416>    FileMgr:9675:19:03: PROP_CARD2_RU_SIZE 524288
000AF443>    FileMgr:9451:19:03: PROP_CARD2_FILE_NUMBER = 3117
000AF465>    Startup:991503:00:05: [SEQ] seqEventDispatch (Startup, 2)
000AF47F>    Startup:99196:89:03: startupPrepareCapture
000AF51B>    Startup:91100:b0:05: [MNAV] MEMNAVI_Initialize
000AF6EC>    Startup:911307:b0:05: [MNAV] MEMNAVI_SetMemoryMap: 1
000AF728>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 14, ClassID = 142
000AF75F>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 2, ClassID = 142
000AF789>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 3, ClassID = 142
000AF7B1>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 15, ClassID = 142
000AF7D8>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 5, ClassID = 142
000AF800>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 6, ClassID = 142
000AF826>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 1, ClassID = 142
000AF84D>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 4, ClassID = 142
000AF876>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 8, ClassID = 142
000AF89D>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 9, ClassID = 142
000AF8C3>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 10, ClassID = 142
000AF8EA>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 17, ClassID = 142
000AF90F>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 18, ClassID = 142
000AF934>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 19, ClassID = 142
000AF959>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 21, ClassID = 142
000AF9DD> ShootCaptu:9023:8e:03: scsIgnore
000AFAA0> ShootCaptu:9200:8e:03: IsFactoryMenuMode:0
000AFAD1> ShootCaptu:907:8e:03: scsInit
000AFC63> ShootCaptu:9339:8c:03: InitializeHeadControl
000B01D6>    Startup:99157:00:03: [STARTUP]startupCompleteCallback 0x80000
000B01FF>    Startup:991699:00:03: [SEQ] NotifyComplete (Cur = 3, #x, Flag = #x)
000B0297> ShootCaptu:920:8e:03: Mem1Component Size=#x
000B03B7> ShootCaptu:904:8e:03: DarkCurrentBuffer:#lx, Size:139264
000B0D10> ShootCaptu:99:35:03: RealClearBusy(0x40) 0x0->0x0,0x0(0x0)[14]
000B0D33> ShootCaptu:99157:00:03: [STARTUP]startupCompleteCallback 0x40000
000B0D51> ShootCaptu:991699:00:03: [SEQ] NotifyComplete (Cur = 3, #x, Flag = #x)
000B0E0B> ShootBlack:996201:8f:03: sbsInit
000B0E50> ShootBlack:99623:8f:03: VShadingAddress:#lx, Size:162816
000B0EE3> ShootPreDe:902:90:03: Init
000B0F38>    Panning:947705:dd:03: panInit
000B1124>    Startup:991503:00:05: [SEQ] seqEventDispatch (Startup, 3)
000B1179>    Startup:001b686f:00:0f: [31] *** mpu_send(06 05 03 11 01 00)                            ; PROP_ICU_AUTO_POWEROFF
000B11F5>    PropMgr:001b686f:00:0f: [32] *** mpu_send(06 05 02 0a 00 00)                            ; PROP_PERMIT_ICU_EVENT
000B1218>    PropMgr:993491:81:03: PROP_PERMIT_ICU_EVENT 0x0
000B126A>    PropMgr:9915001:88:03: HDMIDetectISR 0
000B1299>    PropMgr:9915227:88:03: CreateTask Master RealEnd
000B1306>    PropMgr:001b686f:00:0f: [33] *** mpu_send(06 05 03 0d 00 00)                            ; PROP_CARD2_RECORD
000B1344>    Startup:99125:89:05: startupPrepareDevelop
000B1363>    Startup:001b686f:00:0f: [34] *** mpu_send(06 05 03 0c 00 00)                            ; PROP_CARD1_RECORD
000B1385>    Startup:9919:89:03: MovieCFilter 431A0C00 5de9f8 196000
000B1449>    Startup:001b68db:00:0f: [66] *** mpu_recv(06 05 01 2c 02 00)                            ; PROP_CURRENT_MEDIA
000B1613>     RscMgr:001b68db:00:0f: [67] *** mpu_recv(12 11 03 00 62 00 00 31 0f 00 00 00 00 00 00 00 00 00) ; PROP 80030000
000B164B>     RscMgr:9169509:80:03: fDevDone 1, dwLvLock 0
000B167D>     RscMgr:916960:80:03: 0 0 0
000B16BD>     RscMgr:001b68db:00:0f: [68] *** mpu_recv(06 05 03 04 00 00)                            ; PROP_POWER_KIND
000B173C>     RscMgr:001b68db:00:0f: [69] *** mpu_recv(06 05 03 05 02 00)                            ; PROP_POWER_LEVEL
000B1800>     RscMgr:001b68db:00:0f: [70] *** mpu_recv(06 05 03 23 2c 00)                            ; ???
000B1852>     RscMgr:99:35:03: RealClearBusy(0x2100) 0x0->0x0,0x0(0x0)[15]
000B194D>    PropMgr:9925:01:16: M:62 F:0 L:0 P:31 T:F
000B1A2E>    PropMgr:99179:89:05: update coded version.
000B1A58>    PropMgr:991735:89:05: internal version 05:00:02:62:00:00:31:0f:00:00:d0:d0:d0
000B1B81>    PropMgr:001b68db:00:0f: [71] *** mpu_recv(32 30 03 24 54 41 4d 52 4f 4e 20 31 36 2d 33 30 30 6d 6d 20 46 2f 33 2e 35 2d 36 2e 33 20 44 69 20 49 49 20 56 43 20 50 5a 44 20 42 30 31 36 00 00 00) ; PROP_LENS_NAME
000B1C0F>    PropMgr:001b68db:00:0f: [72] *** mpu_recv(06 04 03 25 00 00)                            ; ???
000B1C9F>    Startup:906091:02:05: PROPTUNEAD_CreateFROMPropertyHandleToDRAM Addr:0x42356400
000B1D1B>    Startup:9497:02:03: PROPCOMBO_LoadProperty(395)
000B1DE7>    FileMgr:940:19:03: PROP_CURRENT_MEDIA = 2
000B1F36>     NFCMgr:906619:3e:03: [BLE] PROP_BATTERY_POWER:not BAT_NONE 2
000B213F>   PowerMgr:001b68db:00:0f: [73] *** mpu_recv(32 31 03 15 01 25 50 01 eb 00 10 01 2c 91 77 9a ef 08 ff 00 00 00 00 00 00 00 00 00 00 01 00 00 04 24 00 02 00 00 00 00 00 00 00 00 00 00 00 00 01 00) ; PROP_LENS
000B23AB>    PropMgr:001b68db:00:0f: [74] *** mpu_recv(24 22 03 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP 8003003C
000B243E>    PropMgr:001b68db:00:0f: [75] *** mpu_recv(06 05 03 17 94 00)                            ; PROP_EFIC_TEMP
000B24C3>    PropMgr:001b68db:00:0f: [76] *** mpu_recv(06 05 01 3d 00 00)                            ; PROP_TEMP_STATUS
000B24F1> EFLensComT:923205:d6:03: LensAction_UpdateLensInfo
000B2539> EFLensComT:96411:d6:03: LensExist=1, AberrationVersion=0
000B2567> EFLensComT:92320:d6:03: LensPropSendIdentifyOptLensData2ByLensInfo passed
000B258E> EFLensComT:966:d6:03: LensPropUpdateLensInfo
000B25BC> EFLensComT:001b68db:00:0f: [77] *** mpu_recv(06 05 03 0d 00 00)                            ; PROP_CARD2_RECORD
000B2811>    FileMgr:913:15:03: @FileMgr FIO_SetCardChangeFlag(1,0) L:1060
000B2976>   PowerMgr:001b68db:00:0f: [78] *** mpu_recv(32 31 03 15 01 25 50 01 eb 00 10 01 2c 91 77 9a ef 08 ff 00 00 00 00 00 00 00 00 00 00 01 00 00 04 24 00 02 00 00 00 00 00 00 00 00 00 00 00 00 01 00) ; PROP_LENS
000B2A03> EFLensComT:923205:d6:03: LensAction_UpdateLensInfo
000B2A26> EFLensComT:96411:d6:03: LensExist=1, AberrationVersion=0
000B2A40> EFLensComT:92320:d6:03: LensPropSendIdentifyOptLensData2ByLensInfo passed
000B2A59> EFLensComT:966:d6:03: LensPropUpdateLensInfo
000B2BD7>   PowerMgr:001b68db:00:0f: [79] *** mpu_recv(24 22 03 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP 8003003C
000B2C5E>   PowerMgr:001b68db:00:0f: [0] *** mpu_recv(06 05 03 0c 00 00)                             ; PROP_CARD1_RECORD
000B2CE5>    FileMgr:913:15:03: @FileMgr FIO_SetCardChangeFlag(0,0) L:1060
000BF408> ShootFenci:90635:df:03: Init
000BF4C1> ShootDevel:94305:b1:03: sdsInit
000BF57F>    Startup:947:9a:03: sssCreateStateList Job=#x Yuv=#x
000BF5C8>    Startup:947:9a:03: sssCreateStateList Job=#x Yuv=#x
000BF63F> ShootSsDev:962:9a:03: Init
000BF6EC> DistCorrec:9225:af:03: sdcsInit
000BF881> DistCorrec:93043:af:03: sdcsProperty id:#x
000BF8B7> DistCorrec:93043:af:03: sdcsProperty id:#x
000BF8D9> DistCorrec:93395:af:03: sdcsSetPropLens Data #x #x #x #x #x
000BF8F9> DistCorrec:930:af:03: sdcsPropLensForDistCorrect
000BF91C> DistCorrec:93043:af:03: sdcsProperty id:#x
000BF93B> DistCorrec:93043:af:03: sdcsProperty id:#x
000BF952> DistCorrec:930:af:03: sdcsPropLensForDistCorrect
000BF9F2> DistCorrec:93005:af:03: sdcsPropLensForDistCorrect LensData
000BFC14>    Startup:99354:a6:03: SVS_Activate
000BFC70>   ShootVfx:9403:a6:03: shsInit
000BFCFF>   ShootVfx:94151:a6:03: shpsInit
000BFEA5>   ShootVfx:947093:a6:03: sgsInit PropRet :0
000BFF14>   ShootVfx:944509:a6:03: snpsInit PropRet :0
000BFF54>   ShootVfx:9470:a6:03: sasInit
000BFFCD>   ShootVfx:945031:a6:03: svdsInit
000C00AC>    Startup:9910:a6:03: SVS_Activate Complete
000C01BC>    Startup:901:ff:05: MAC_Initialize (nop)
000C026E>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 16, ClassID = 149
000C02BC>    Startup:9274011:3b:03: INDEV_Initialize
000C0509>    Startup:927511:3b:03: [Trimming]Tbl_Set TblAddr:9592540 Size:42
000C0645> ShootFenci:90609:df:03: Activate
000C0675> ShootFenci:9005:89:03: startupMovieCFilterXDmacCBR
000C0804> ShootFenci:90047:df:03: Property id:#x
000C0838> ShootFenci:90047:df:03: Property id:#x
000C086F> ShootFenci:90047:df:03: Property id:#x
000C0894> ShootFenci:90047:df:03: Property id:#x
000C08CE> ShootPreDe:90449:90:03: spsActivate
000CA085>    Panning:94771:dd:03: [GYRO  :2118078987,1077764206]
000CA0BA>    Panning:947:dd:03: [Offset:14741,-20509]
000CA0D7>    Panning:9479:dd:03: [DIFF  :-32352,-5486]
000D5E54> ShootPreDe:9054:90:03: spsProperty id:#x
000D5E7C> ShootPreDe:9054:90:03: spsProperty id:#x
000D5E96> ShootPreDe:9054:90:03: spsProperty id:#x
000D5EAF> ShootPreDe:9054:90:03: spsProperty id:#x
000D768A> ShootPreDe:9054:90:03: spsProperty id:#x
000D8EA8> ShootPreDe:9054:90:03: spsProperty id:#x
000DA6BC> ShootPreDe:9054:90:03: spsProperty id:#x
000DA6D5> ShootPreDe:9054:90:03: spsProperty id:#x
000DA6EB> ShootPreDe:9054:90:03: spsProperty id:#x
000DA703> ShootPreDe:9054:90:03: spsProperty id:#x
000DA719> ShootPreDe:9054:90:03: spsProperty id:#x
000DA72F> ShootPreDe:9054:90:03: spsProperty id:#x
000DA745> ShootPreDe:9054:90:03: spsProperty id:#x
000DA777> ShootDevel:944931:b1:03: sdsActivate
000DA848> ShootSsDev:965:9a:03: Activate
000DA86E> ShootSsDev:9165:b1:05: [MEM3NAVI]Initialize
000DA96E>      ShtSs:9997:9a:03: fmCreateTaskRawToYuv
000DA97B> ShootSsDev:9701:00:03: ORE_CreateTaskRawToYuvInitializeList(#x)

000DA997> ShootSsDev:999:00:03: InitializeList(#x)
000DA9AB> ShootSsDev:99:00:03: InitializeList(#x)
000DA9F1>    PropMgr:9653:9a:03: ORE create lock handle for yuv path
sssChangeCBR(PROP_DSDEFINE:#x)
000DAA53> DistCorrec:92203:af:03: sdcsActivate
000DAAE9>      ShtSs:9990:9a:03: entry = 9cb1a4 (975620)(3c)
000DAB27>      ShtSs:9911:9a:03: CORE create lock handle for raw path
000DABAC>      ShtSs:99173:9a:03: entry = 9ebf04 (975634)(10)
000DAC27>      ShtSs:99173:9a:03: entry = 9ec1c8 (975674)(17)
000DAC7D>      ShtSs:99173:9a:03: entry = 9ec388 (975634)(10)
000DACD9>      ShtSs:99173:9a:03: entry = 9ec40c (975674)(17)
000DAF79>    Startup:921347:0c:03: [IC] AUD_Initialize[PRI AUD:19,ALV:25]
000DAFB6>    Startup:9209035:0c:03: SoundDev_Initialize(dwPriority=19)
000DAFD5>    Startup:922141:0c:03: [ACTRL] ACTRL_Initialize (12, 19)
000DB039>    Startup:92097:0c:03: SoundDevRegisterNRStartCallback
000DB059>    Startup:90131:0c:03: [TEST]Audio_TestCommand
000DB43B>    Startup:9209075:0c:03: SoundDev_AprocInitialize(dwPriority 1=23,2=25,3=25,IC=0)
000DB45F>    Startup:9210377:0c:03: [APROC] AprocCtrl_Initialize
000DF003> AprocMainT:9210241:0c:03: [APROC] Aproc_PathDoneCBR [0]
000DF056>    Startup:9210409:0c:03: [APROC] AprocCtrlSetLpcParam
000DF074>    Startup:921427:0c:03: AUD_GetLPCParam
000DF091>    Startup:9210345:0c:03: [APROC] AprocCtrlSetLevelMeterMode
000DF0B0>    Startup:921050:0c:03: [APROC] Aproc_RegisterShellCommand [TEST]
000DF0C7>    Startup:921042:0c:03: AprocCtrl_Initialize : END
000DF0DA>    Startup:92090:0c:03: SoundDev_AprocInitialize END
000DF0F2>    Startup:921454:0c:03: [IC] EnableAudioIC[0]
000DF173>    Startup:9322:0c:03: ALV_Initialize (12, 25)
000DF1A1>    Startup:937:0c:03: alvCreateStateObject
000DF201>    PropMgr:9361:0c:03: alvResultCBR : #x
000DF25A>    PropMgr:9329:0c:03: alvChangeAckCBR
000DF26E>    PropMgr:9355:0c:03: alvChangeAckCBR : PROP_MOVIE_PLAY_VOLUME[#x]
000DF286>    PropMgr:935:0c:03: ALV_SetOutputVol
000DF29B>    PropMgr:930921:0c:03: _ALV_SetOutputVol
000DF2D3>    PropMgr:9329:0c:03: alvChangeAckCBR
000DF2E5>    PropMgr:9379:0c:03: alvChangeAckCBR : PROP_MOVIE_SOUND_RECORD[#x]
000DF2FA>    PropMgr:933:0c:03: ALV_SetALCMode
000DF30B>    PropMgr:933:0c:03: _ALV_SetALCMode
000DF33F>    PropMgr:9329:0c:03: alvChangeAckCBR
000DF353>    PropMgr:93:0c:03: alvChangeAckCBR : PROP_MOVIE_REC_VOLUME[#x]
000DF367>    PropMgr:9373:0c:03: ALV_SetInputVol
000DF378>    PropMgr:9373:0c:03: _ALV_SetInputVol
000DF3A5>    PropMgr:9329:0c:03: alvChangeAckCBR
000DF3B5>    PropMgr:9303:0c:03: alvChangeAckCBR : PROP_WIND_CUT(1)
000DF3C9>    PropMgr:937:0c:03: ALV_SetWindCut
000DF40E>    PropMgr:9329:0c:03: alvChangeAckCBR
000DF421>    PropMgr:93:0c:03: alvChangeAckCBR : PROP_ATTENUATOR(0)
000DF436>    PropMgr:9360:0c:03: ALV_SetAttenuator
000DF44A>    PropMgr:93065:0c:03: _ALV_SetAttenuator
000DF46A>    Startup:93161:0c:03: ALV_RegisterShellCommand
000DF4D8>    Startup:91117:0c:03: AudioSE_Initialize
000DF511>    Startup:9116:0c:03: [SE] AudioSE_Initialize (SIZE=0x1700)(ADR=0x405425c0)
000DF539>    Startup:95934:0c:03:  [MUSIC]AUDMUSIC_Initialize
000DF5E5>    Startup:92090:0c:03: SoundDev_PropInitialize
000DF601>    Startup:9221:0c:03: [ACTRL] ACTRL_InitializeProperty
000DF627>    PropMgr:922275:0c:03: actrlResultCBR : #x
000DF65A>    PropMgr:92237:0c:03: actrlChangeAckCBR :Audio Property[5990997]
000DF67B>    PropMgr:922425:0c:03: [ACTRL]  PROP_MIC_PHYSICAL_CONNECT(0)
000DF695>    PropMgr:9213303:0c:03: AUD_SetMICDetect
000DF6BD>  AudioCtrl:9294115:0c:03: [ACTRL] actrlASetConnect(0,0)
000DF724>    PropMgr:92237:0c:03: actrlChangeAckCBR :Audio Property[207001b]
000DF744>    PropMgr:92241:0c:03: [ACTRL]  PROP_AVPORT_SETTING(0)
000DF75A>    PropMgr:92134:0c:03: AUD_CHG_AvHpDetect No Use PROP_AVPORT_SETTING(0)
000DF79C>    PropMgr:92237:0c:03: actrlChangeAckCBR :Audio Property[599099]
000DF7BB>    PropMgr:92271:0c:03: [ACTRL]  PROP_HDMI_PHYSICAL_CONNECT(0)
000DF7D0>    PropMgr:9213475:0c:03: AUD_SetHdmiDetect HDMI(0)
000DF7E5>    PropMgr:920951:0c:03: SoundDevSetSpeaker
000DF811>    PropMgr:92263:0c:03: [ACTRL] _ACTRL_SetAudioParam [1](0,0,0)
000DF83B>  AudioCtrl:92933:0c:03: [ACTRL] actrlASetPlayParam : 1
000DF85D>  AudioCtrl:9595:0c:03:  [MUSIC]AUDMusic_GetUsingFlg(0)
000DF880>    PropMgr:921345:0c:03: [IC] GetAudioEnableHdmiThrough : 0
000DF8B5>    PropMgr:9215557:44:26: NotInit [PropMgr] GpclkCtrl_Off
000DF8DD>    PropMgr:92237:0c:03: actrlChangeAckCBR :Audio Property[5999992]
000DF8F9>    PropMgr:9227:0c:03: [ACTRL]  PROP_BUZZER(5)
000DF91C>  AudioCtrl:929435:0c:03:  [ACTRL] actrlAudioICSerialCommand_Send(5,2)
000DF975>    PropMgr:92237:0c:03: actrlChangeAckCBR :Audio Property[2050031]
000DF993>    PropMgr:92291:0c:03: [ACTRL]  PROP_DUAL_OUTPUT(0)
000DF9AC>    PropMgr:92237:0c:03: actrlChangeAckCBR :Audio Property[599199]
000DF9C9>    PropMgr:922:0c:03: [ACTRL]  PROP_LIVE_VIEW_MOVIE_SELECT(1)
000DF9F0>    PropMgr:92237:0c:03: actrlChangeAckCBR :Audio Property[599299]
000DFA0D>    PropMgr:9220:0c:03: [ACTRL]  PROP_LV_ACTION(1)
000DFA24>    PropMgr:9213523:0c:03: AUD_SetLvAction (VAL:1,MODE:0)
000DFA41>    PropMgr:922365:0c:03: actrlChangeAckCBR :Audio Property[5990999] ParamSize[#x]
000DFA62>    PropMgr:9223:0c:03: [ACTRL]  PROP_LENS(1eb)
000DFA7A>    PropMgr:92135:0c:03: [IC] AUD_SetNoiseChancelLensID[ID:1eb]
000DFA90>    PropMgr:921309:0c:03: [IC] AUD_SetNoiseChancelLensISsw[ID:1]
000DFAB4>    Startup:92090:0c:03: SoundDev_PropInitialize END
000DFAC8>    Startup:921397:0c:03: [IC] Test_AudioCommand
000DFDBB>    Startup:90755:97:03: PackHeap 54a9a4,54a9a4,114560
000DFE19>    Startup:936740:19:03: FM_RegisterMetaCompleteCallBack
000DFE35>    Startup:936740:19:03: FM_RegisterMetaCompleteCallBack
000DFEAA>    PropMgr:001b686f:00:0f: [35] *** mpu_send(08 06 03 18 00 00 00 00)                      ; PROP 8003000F
000DFEE1>    PropMgr:971:39:03: PROP_CONNECT_TARGET fGPSConnect = 0x0
000DFF05>    PropMgr:909:39:03: USB 0x0 MPU 0x0 WFT 0x0 INNER 0x0
000DFF7D>    Startup:001b686f:00:0f: [36] *** mpu_send(08 06 03 1f 00 00 00 00)                      ; PROP 80030019
000DFFCE>    PropMgr:001b686f:00:0f: [37] *** mpu_send(08 06 04 24 00 00 00 00)                      ; ???
000E01EE>    PropMgr:001b686f:00:0f: [38] *** mpu_send(0a 08 01 3b ff ff 00 00 00 00)                ; PROP_USBDEVICE_CONNECT
000E03AC>    Startup:001b686f:00:0f: [39] *** mpu_send(08 07 03 68 00 00 00 00)                      ; ???
000E0413>    PropMgr:001b686f:00:0f: [40] *** mpu_send(06 05 03 69 00 00)                            ; ???
000E04EA>    PropMgr:001b686f:00:0f: [41] *** mpu_send(08 07 03 89 00 00 00 00)                      ; ???
000E051F>    Startup:931:0c:03: ALV_RegisterObserveCBR[0]
000E0758>    PropMgr:001b68db:00:0f: [1] *** mpu_recv(06 05 01 58 00 00)                             ; PROP_VIDEOSNAP_MODE
000E0E0B>    PropMgr:001b68db:00:0f: [2] *** mpu_recv(06 05 01 58 00 00)                             ; PROP_VIDEOSNAP_MODE
000E1566>    PropMgr:001b68db:00:0f: [3] *** mpu_recv(06 05 01 58 00 00)                             ; PROP_VIDEOSNAP_MODE
000E1F09>    Startup:930:97:03: PackHeap 4056ac80,4056ac80,393088
000E25AD>    Startup:907099:97:03: COM_RegisterTransMission 81 0x9372
000E25E1>    Startup:9007:97:03: COM_RegisterConncectModeChange 0x9370
000E26C9>    Startup:921411:34:03:  TOM_Initialize
000E2780>    PropMgr:92147:34:03:  PROP_WFT_IMAGE_TRANS (1)
000E27E0> AudioLevel:932:0c:03: alvChangeOutputVol SetVolume(5)
000E2800> AudioLevel:920921:0c:03: SoundDevSetVolumeOut(Volume=5)
000E2829> AudioLevel:92263:0c:03: [ACTRL] _ACTRL_SetAudioParam [2](5,0,0)
000E2851>  AudioCtrl:92933:0c:03: [ACTRL] actrlASetPlayParam : 2
000E2870>  AudioCtrl:9595:0c:03:  [MUSIC]AUDMusic_GetUsingFlg(0)
000E288A>  AudioCtrl:921373:0c:03: [IC] SetAudioVolumeWithoutSendCommand
000E28C4> AudioLevel:9209273:0c:03: SoundDevSetWindCutMode(Mode=1)
000E28DE> AudioLevel:92263:0c:03: [ACTRL] _ACTRL_SetAudioParam [6](1,0,0)
000E2901>  AudioCtrl:929301:0c:03: [ACTRL] actrlASetRecParam : 6
000E2926> AudioLevel:93109:0c:03: ALC=1,LVOL=47,RVOL=47,WCT=1,ATN=0 /alvChangeWindCut
000E29DB>     ComMgr:904:97:03: PROP_CARD1_STATUS 0
000E29F8>     ComMgr:90903:97:03: comStorageSetStorageID:0,0,0
000E2A15>     ComMgr:9236639:97:03: COMS PROP_CARD1_STATUS 0
000E2A46>     ComMgr:9040:97:03: PROP_CARD2_STATUS 1
000E2A5D>     ComMgr:90903:97:03: comStorageSetStorageID:1,0,0
000E2A73>     ComMgr:9236639:97:03: COMS PROP_CARD2_STATUS 1
000E2A9F>     ComMgr:9042:97:03: PROP_CARD1_EXIST 0
000E2AB4>     ComMgr:90903:97:03: comStorageSetStorageID:0,0,0
000E2ADA>     ComMgr:90445:97:03: PROP_CARD2_EXIST 1
000E2AED>     ComMgr:90903:97:03: comStorageSetStorageID:1,0,1
000E2B39>     ComMgr:90962:97:03: comAudioLevelMeterStartEnd 0 0
000E2B81>     ComMgr:9055:97:03: PROP_CURRENT_MEDIA[2]
000E2DE6>     ComMgr:923646:97:03: PROP_SHOOTING_TYPE 0 0
000E2FF8>     ComMgr:9055:97:03: bodyID_h = #x
000E3013>     ComMgr:9061:97:03: bodyID_l = #x
000E303F>     ComMgr:9093:97:03: String = 023070047059
000E33C8>     ComMgr:905:97:03: COMMUNICATION_MODE_OFF #x #x
000E34C4>     ComMgr:90179:97:03: PROP_MWB[2c]
000E3552>     ComMgr:90607:97:03: R JobState 0x0 0x0 0x20
000E387C>     ComMgr:9072:97:03: CommunicationMode:0
000E3945>     ComMgr:905:97:03: PROP_ADAPTER_DEVICE_ACTIVE: FALSE
000E39DE>     ComMgr:907:97:03: PROP_NETWORK_NICKNAME
000E3A5B>     ComMgr:9097:97:03: LensName:TAMRON 16-300mm F/3.5-6.3 Di II VC PZD B016
000E3A75>     ComMgr:90925:97:03: LensExist 1
000E3B26>     ComMgr:90962:97:03: comAudioLevelMeterStartEnd 0 0
000E3B5B>     ComMgr:9001:26:03: PROP_SCREEN_SAVER
000E3B96>     ComMgr:9093:26:03: PROP_PUSH_TRANSFER 0
000E3C1C>     ComMgr:900:97:03: #LENS_EXCHANGE_HISTORY[3] 0[#x] 1[#x]
000E3C35>     ComMgr:90003:97:03: #LENS_EXCHANGE_HISTORY 2[#x] 3[#x] 4[#x]
000E3CF2>     ComMgr:900565:97:03: comRegisterPhysicalConnect USB 9372 56aa18
000E3D1E>     ComMgr:90053:97:03: comRegisterPhysicalConnect SDIO 9372 56aa18
000E3D44>     ComMgr:90053:97:03: comRegisterPhysicalConnect INNER 9372 56aa18
000E3EEF>     PtpMgr:94011:97:03: ptpChangeConnectMode 0x
000E3F15>     PtpMgr:9167:26:03: OverWrite Operation Function
000E3F2F>     PtpMgr:9167:26:03: OverWrite Operation Function
000E3F46>     PtpMgr:9167:26:03: OverWrite Operation Function
000E3FB3>      TOMgr:9270619:34:03:  tomSetRawJpgMode (Type = #x)
000E4029>     NFCMgr:92541:3e:03:  PROP_NETWORK_INFO 00:00:00:00:00:00:00:00
000E4049>     NFCMgr:92545:3e:03:  PROP_NETWORK_INFO MacAdder is Default or ILLEGAL
000E4175>    Startup:99157:00:03: [STARTUP]startupCompleteCallback 0x100
000E4198>    Startup:991699:00:03: [SEQ] NotifyComplete (Cur = 4, #x, Flag = #x)
000E4550>    Startup:924139:d7:03: InitializeServo
000E468C>    Startup:923075:d7:03: AF_ResetDriveAndSamplingParameter
000E4B35>    PropMgr:001b686f:00:0f: [42] *** mpu_send(06 04 0e 3a 00 00)                            ; ???
000E4BBA>   EventMgr:9977:37:03: emRegisterMulticastCallback : EventID = 20, ClassID = 215
000E4BF7>    Startup:924321:d7:03: AF_StartSampling
000E4CE9>    Startup:906105:22:03: TCM_Initialize
000E4DA1>    PropMgr:906113:22:05: TimeCode DropFrame Mode:1
000E4DE3>    PropMgr:90605:22:03: TimeCode Base:0,0,0,0
000E4E00>    PropMgr:906071:22:03: Set Time:0,0,0
000E4E4A>    Panning:94771:dd:03: [GYRO  :2118078987,1077764206]
000E4E7E>    Panning:947:dd:03: [Offset:14741,-20509]
000E4E9C>    Panning:9479:dd:03: [DIFF  :-32352,-5486]
000E4EC5>    PropMgr:9060:22:03: dwFreeRunModifyingFlags 2
000E4FB4>    PropMgr:9061:22:03: TCPreSet[00:00:00.00]
000E5041>    PropMgr:906113:22:05: TimeCode Mode:1
000E510E> TimeCodeMa:996:22:16: [TCTEST]FreeRunBase RTC:21(h)15(m)17(s)->76517
000E5132> TimeCodeMa:99:22:16: FreeRun/1 [1836408][1836408][1912925][2293214][3825850][4586428]
000E51A3>    PropMgr:906113:22:05: PROP_TIMECODE_HDMI_OUTPUT:0
000E51E1>    PropMgr:906113:22:05: PROP_TIMECODE_HDMI_REC_COMMAND:0
000E51FD>    PropMgr:906167:22:05: PROP_MOVIE_PARAM:0,0
000E522C>    Startup:906277:22:03: TCM_Initialize
000E53AD>    PropMgr:92375:22:16: card 1 0
000E53D8>    PropMgr:92375:22:16: card 2 32768
000E5468>    Startup:91359:22:16: Smac:#x Tric:#x
000E5483>    Startup:91361:22:16: AllocSize:#x S:#x T:#x
000E5672>    Startup:913:15:03: @Startup FIO_GetSupportedDriveInfo(0x205700) L:1102
000E5801>     NFCMgr:9254509:3e:03:  PROP_VIDEOSNAP_MODE OFF 0
000E583C>     NFCMgr:9254509:3e:03:  PROP_VIDEOSNAP_MODE OFF 0
000E5863>     NFCMgr:9254509:3e:03:  PROP_VIDEOSNAP_MODE OFF 0
000E58A7>     NFCMgr:90625:3e:03: [BLE] PROP_NETWORK_STATE Wi-Fi OFF
000E58D6>     NFCMgr:90644:3e:03: [BLE] PROP_NETWORK_INFO 00:00:00:00:
000E58EF>     NFCMgr:906455:3e:03: [BLE] PROP_NETWORK_INFO :00:00:00:00
000E5919>     NFCMgr:9099:3e:03: [BLE] Enter blemgr_SmartphoneGps_CheckState().
000E5931>     NFCMgr:90901:3e:03: [BLE] Enter CheckGpsAndBleState().
000E5964>     NFCMgr:90631:3e:03: [BLE] PROP_VIDEOSNAP_MODE OFF 0
000E597F>     NFCMgr:90631:3e:03: [BLE] PROP_VIDEOSNAP_MODE OFF 0
000E599A>     NFCMgr:90631:3e:03: [BLE] PROP_VIDEOSNAP_MODE OFF 0
000E59C0>     NFCMgr:907:3e:03: [BLE] Enter blemgr_SmartPhoneGps_NopEvent!!!
000E59D6>     NFCMgr:909:3e:03: [BLE]   Status=0, Event=13
000F38C1>       dump:001b6b09:00:0f: Logging finished.
000F38E2>       dump:001b6b17:00:0f: Free memory: 3655028 bytes.


If anyone else with a 200D wants to get a similar log, here's the FIR you should run:

LOG_200D.FIR (https://a1ex.magiclantern.fm/bleeding-edge/200D/LOG_200D.FIR)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: morgan20 on August 26, 2018, 03:24:42 AM
So I was playing around with the 6D2 ROM1 dump and it seem to have failed the disassembly part.
I get a lot of lines like this in the ROM1 disassembly file:
ffffffff ; <UNDEFINED> instruction: 0xffffffff

Somewhere on the forum I read that it might be because the wrong firmware start address that I use with disassemble.pl script. Although I used exactly the same address that was given me by the Firmware Dumper: 0xE0040000. What am I doing wrong?

Another stupid question how can I identify the stub (what it actually does so I put it in stubs.S)?

Note: my dump is of the 1.0.4 firmware version.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: critix on August 26, 2018, 06:26:13 AM
Hi.
Please send to me dump from 6D2 for finding stubs.
Thanks.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on August 26, 2018, 06:29:07 AM
"Somewhere on the forum..."

Quote from: a1ex on July 20, 2017, 08:09:08 AM
- ROM0 start address: 0xE0000000 on [DIGIC 7], 0xF0000000 on [DIGIC 2..5] (data only)

Also the "reference" documentation:
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?#rst-header-initial-firmware-analysis

For Thumb, you will need disassemblev7.pl (http://chdk.wikia.com/wiki/User:Srsa_4c/GPL:disassemblev7.pl). Good news is that DIGIC 7 firmware is mostly Thumb, unlike DIGIC 6 which is a mix of ARM and Thumb. There are still a few ARM veneers around; so far I've only noticed direct jumps to Thumb functions.

Stubs are generally function addresses (where a function starts); the LSB is the Thumb bit. A small part of them are data pointers; these have even values, usually in RAM. Some of the stubs are already defined in */debugmsg.gdb in the QEMU directory. Some of them are even identical between 200D (D7) and M50 (D8), so...

Following a call trace in QEMU is also helpful; that's the method used by find_stubs.sh (https://www.magiclantern.fm/forum/index.php?topic=2864.msg200846#msg200846) (which helps, but only finds a small set of stubs and... doesn't work on Mac).

The autogenerated IDC files (one with -d idc from QEMU and the other from the GDB script saved by find_stubs.sh) are also very helpful.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: edoardoc on September 02, 2018, 12:36:21 PM
Hi! I own a Canon 200D, how can I help the developers? :D
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: edoardoc on September 08, 2018, 11:02:30 AM
I loaded the dump file for the EOS 200D but it get stuck on "- Dumping ROM0..." :

(https://thumb.ibb.co/hsUgh9/IMG_3619.jpg) (https://ibb.co/hsUgh9)


Here's a diagnostic log from my 200D :


00000000>       init:001b6acf:00:0f: Logging started.
00000000>       init:e04bdce7:00:05: [MEM] InitializePermanentMemory 0 4636784
0000013E>       init:e0041327:89:16:
K417 ICU Firmware Version 1.0.1 ( 5.0.2 )
00000163>       init:e0041333:89:05:
ICU Release DateTime 2017.09.21 12:53:23
000002BC>       init:e0048fd7:00:03: [SEQ] CreateSequencer (Startup, Num = 6)
00000306>       init:e00490d1:00:03: [SEQ] NotifyComplete (Cur = 0, 0x2018000, Flag = 0x10000)
00000979>     SFRead:e0139f05:02:05: PROPTUNEAD_CreateFROMPropertyHandleToDRAM Addr:0x416a2c00
000009E9>     SFRead:e01c7b0b:02:03: PROPCOMBO_LoadProperty(395)
00000A38>    RomRead:e04c14af:02:05: PROPAD_CreateFROMPropertyHandle DRAMAddr 0x421f8400
00005EB9>     SFRead:e00490d1:00:03: [SEQ] NotifyComplete (Cur = 0, 0x2008000, Flag = 0x8000)
00009537>    RomRead:e00490d1:00:03: [SEQ] NotifyComplete (Cur = 0, 0x2000000, Flag = 0x2000000)
00009571>    Startup:e0048f6d:00:05: [SEQ] seqEventDispatch (Startup, 0)
0000958B>    Startup:e004148f:89:05: startupEntry
0000ABD0>    Startup:e0046f31:00:03: [PWM] PWM_Initialize
0000AC4F>    Startup:e05452e9:00:03: [ADC] InitializePollingADC
0000B238>      init1:e0246323:d2:03: [FMID]FMID_SYS_Initialize(0x5eeefe00, 0x500000)
0000D3BD>    Startup:e05451f5:00:03: [ ADC ] Calibration Completed, 0x00000000
0000E602>    PropMgr:e00a8c09:81:03: PROP_RegisterMultiConvert : 3, 6
0000E632>    PropMgr:e00a8c09:81:03: PROP_RegisterMultiConvert : 1, 1
0000E82F>    PropMgr:e0066e11:81:03: @@@JudgeRestoreFlavorPC 1062
0000EB92>    Startup:001b686f:00:0f: [0] *** mpu_send(06 04 02 00 00 00)
0000ED0A>    PropMgr:e04e17e7:37:03: emSlaveChangeCBR : AUTO_POWEROFF (1)
0000ED3C>    PropMgr:e04e1805:37:03: emSlaveChangeCBR : UILOCK (0x0)
0000EF65>    PropMgr:001b68db:00:0f: [0] *** mpu_recv(06 05 01 00 00 00)
0000F020>    PropMgr:e006739b:81:03: ChangeAEMode -> 0 @AE_MODE_DIAL
0000F07F>    PropMgr:001b686f:00:0f: [1] *** mpu_send(08 06 01 a7 00 01 00 00)
0000F0A3>    PropMgr:e009134f:81:03: Active Adjective & Situation 0->0
0000F0E5>    PropMgr:e00a8dd7:81:03: ReqChangeCBR : Adjective 0, 0
0000F113>    PropMgr:001b68db:00:0f: [1] *** mpu_recv(06 05 01 99 00 00)
0000F132>    PropMgr:e00a8e41:81:03: Not ExecMultiConvert Already None : Adjective 0, 0
0000F16F>    PropMgr:e00a8ef7:81:03: Not ExecMultiConvert : Situation 0
0000F1B0>    PropMgr:001b68db:00:0f: [2] *** mpu_recv(06 05 01 9a 00 00)
0000F1EF>    PropMgr:e00916a9:81:03: !! Convert End !!
0000F246>    PropMgr:001b68db:00:0f: [3] *** mpu_recv(06 05 01 06 15 00)
0000F294>    PropMgr:e04bf3d9:02:03: DataType = 0x2000000 fModify = TRUE
0000F2F5>    PropMgr:001b68db:00:0f: [4] *** mpu_recv(06 05 01 3f 00 00)
0000F644>    PropMgr:001b68db:00:0f: [5] *** mpu_recv(06 05 01 99 00 00)
0000F6D7>    PropMgr:001b68db:00:0f: [6] *** mpu_recv(06 05 01 9a 00 00)
0000F766>    PropMgr:001b68db:00:0f: [7] *** mpu_recv(06 05 01 06 15 00)
0000F7AF>    PropMgr:e00afc13:81:03: PROP_STROBO_FIRING 0 Last 0
0000F7D2>    PropMgr:e00afc2d:81:03: dwLastStroboFiring = 0  stroboFiring = 0
0000F810>    PropMgr:001b68db:00:0f: [8] *** mpu_recv(06 05 01 3f 00 00)
0000F897>    PropMgr:001b68db:00:0f: [9] *** mpu_recv(06 05 01 4f 00 00)
0000F94C>    PropMgr:e0067a8f:81:03: PROP_CHROMATISM 0 (Excluding:0)
0000F9D9>    PropMgr:e0067a29:81:03: PROP_DISTORTION_COMP 0 (Excluding:0)
0000FA52>    PropMgr:e0067a5f:81:03: PROP_LIGHT_FALLOFF_COMP 1 (Excluding:0)
0000FC1E>    PropMgr:e00afc13:81:03: PROP_STROBO_FIRING 0 Last 0
0000FC39>    PropMgr:e00afc2d:81:03: dwLastStroboFiring = 0  stroboFiring = 0
0000FC66>    PropMgr:e0067321:81:03: FixedMovie New 0 Last 0
0000FD9A>    PropMgr:e00676a7:81:03: PROP_TOUCH_SHUTTER 0
0000FE27>    PropMgr:e00676cf:81:03: PROP_CREATIVE_TOUCH_SHUTTER 0
0000FEB6>    PropMgr:001b686f:00:0f: [2] *** mpu_send(22 20 0e 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
0000FED7>    PropMgr:e041e9b5:d6:03: LvLensDataMasterResultCBR
0000FF2C>    PropMgr:e041e9b5:d6:03: PowerZoomAdapterInfoCBR
0000FF7D>    PropMgr:e041e9b5:d6:03: FactErrLensDataInfoCBR
00010228>     NFCMgr:e03d550b:3e:03: [BLE] BLEMGR_InitializeParam
000102CB>    PropMgr:001b686f:00:0f: [3] *** mpu_send(06 05 03 8a 00 00)
0001033D>    PropMgr:001b686f:00:0f: [4] *** mpu_send(06 04 02 14 00 00)
00010395>     NFCMgr:e05f3be3:3e:03:  NFCI2C_SetParam 1 3 0xa8 0x0
000103CB>     NFCMgr:e0586c13:3e:03:  PROP_SPECIAL_OPTION Wlan off (0x0)
000107C4>   PowerMgr:001b68db:00:0f: [10] *** mpu_recv(30 2f 02 0d 00 00 00 00 01 00 00 00 00 00 00 01 00 01 02 00 00 00 00 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 01 00 0f 00 01 01 01 00 00 00)
00010949>    PropMgr:e041dfc3:01:03: DivideMediaEtcInit2Data[24] comID 1 dataID 91 data 0xf00
00010979>    PropMgr:e041dfc3:01:03: DivideMediaEtcInit2Data[25] comID 1 dataID 9c data 0x100
00010E53>   PowerMgr:001b68db:00:0f: [11] *** mpu_recv(5e 5c 02 0f 02 00 00 08 01 01 00 00 00 00 00 00 00 00 00 00 09 5e 00 00 00 0c 00 00 00 00 00 00 00 03 00 00 00 01 00 00 00 00 00 01 00 01 01 00 00 00 00 00 00 00 00 00 03 01 2c 00 00 0b b5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)
00010F05>    PropMgr:e041cf2f:01:03: RecMovieParam 0 0 2398 12 0 3 1 0
00011022>    PropMgr:e00679df:81:03: @@@ PROP_MOVIE_CFILTER 0
00011335>   PowerMgr:001b68db:00:0f: [12] *** mpu_recv(48 46 02 10 00 00 00 00 00 00 01 01 00 00 03 03 03 03 00 00 00 00 00 00 00 5c 00 01 ba 50 00 00 00 00 00 01 ff 00 00 02 01 01 00 03 00 01 00 04 00 00 01 05 00 01 01 00 01 00 00 03 03 00 00 00 00 00 00 00 00 00 00 00)
00011B29>   PowerMgr:001b68db:00:0f: [13] *** mpu_recv(42 40 02 11 00 01 00 00 00 00 01 00 ff 01 00 00 00 00 00 00 00 ff 01 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 ff 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 15 00 00 00 00 00)
00011B96>    PropMgr:e041e695:01:03: DivideLensInit2Data[3] comID 1 dataID 4 data 0x0
00011BC8>    PropMgr:001b68db:00:0f: [14] *** mpu_recv(06 05 01 b6 01 00)
00011C45>   PowerMgr:001b68db:00:0f: [15] *** mpu_recv(06 05 01 b5 01 00)
00011CD2>   PowerMgr:001b68db:00:0f: [16] *** mpu_recv(06 05 01 98 00 00)
00011E28>   PowerMgr:001b68db:00:0f: [17] *** mpu_recv(12 10 02 04 0c 00 01 01 00 01 00 43 00 00 00 00 00 00)
000127DA>   PowerMgr:e0042c8b:00:03: [STARTUP]startupCompleteCallback 0x2
000127FC>   PowerMgr:e00490d1:00:03: [SEQ] NotifyComplete (Cur = 1, 0x2, Flag = 0x2)
0001287C>   PowerMgr:001b68db:00:0f: [18] *** mpu_recv(94 93 02 0e 00 00 03 01 00 00 00 68 01 00 00 17 14 50 00 00 00 00 81 00 00 01 03 00 00 06 04 00 00 01 00 00 01 00 00 00 00 60 15 00 00 00 00 00 00 00 00 01 03 00 00 90 48 00 00 88 48 80 48 80 48 90 48 88 48 80 48 78 48 70 00 00 00 00 01 00 00 00 00 02 00)
00012910>    PropMgr:001b68db:00:0f: [19] *** mpu_recv(06 05 03 37 00 00)
000129CA>    PropMgr:001b68db:00:0f: [20] *** mpu_recv(0a 08 03 2f 00 40 00 00 00 00)
00012A46>    PropMgr:001b68db:00:0f: [21] *** mpu_recv(06 05 03 20 01 00)
00012A6B>    PropMgr:e006739b:81:03: ChangeAEMode -> 0 @AE_MODE_DIAL
00012A92>    PropMgr:e00916a9:81:03: !! Convert End !!
00012ACE>    PropMgr:001b68db:00:0f: [22] *** mpu_recv(06 05 03 76 00 00)
00012C1D>    PropMgr:e041e141:01:03: DivideDataInit2Data[4] comID 1 dataID 4 data 0x0
00012C4C>    PropMgr:e041e141:01:03: DivideDataInit2Data[8] comID 1 dataID b data 0x0
00012C75>    PropMgr:e041e141:01:03: DivideDataInit2Data[10] comID 1 dataID e data 0x1450
00012CCA>    PropMgr:e041e141:01:03: DivideDataInit2Data[22] comID 1 dataID 1f data 0x0
00012D45>    PropMgr:e00afc13:81:03: PROP_STROBO_FIRING 0 Last 0
00012D64>    PropMgr:e00afc2d:81:03: dwLastStroboFiring = 0  stroboFiring = 0
00012DCA>    PropMgr:e0067ac9:81:03: PROP_MULTIPLE_EXPOSURE_SETTING 0
00012DF4>    PropMgr:e0067ac9:81:03: PROP_HDR_SETTING 0
00012E2C>    PropMgr:e00676f1:81:03: @@@ PROP_LV_CFILTER 0
00012E5A>    PropMgr:e0067ac9:81:03: PROP_GIS_SETTING Func 0
00012E77>    PropMgr:e041e141:01:03: DivideDataInit2Data[50] comID 1 dataID 47 data 0x20a
00012E9A>    PropMgr:e041e141:01:03: DivideDataInit2Data[51] comID 1 dataID 57 data 0x0
00012ED0>    PropMgr:e00675e9:81:03: PROP_SHUFFLE_MODE 0x0 ConvertMode 0x0
00012EEE>    PropMgr:e041e141:01:03: DivideDataInit2Data[53] comID 1 dataID 88 data 0x3c
00012F59>    PropMgr:e041e141:01:03: DivideDataInit2Data[59] comID 1 dataID 9e data 0x40
00012FD0>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000001, 0xE0066E9B(1)
00013059>    PropMgr:e0067475:81:03: StartupCondition : 1, 0
0001313D>    PropMgr:001b68db:00:0f: [23] *** mpu_recv(64 62 02 12 01 26 51 10 32 00 12 00 37 91 57 9a 7e 08 ff 00 00 00 00 00 00 00 3b 59 dc 00 00 00 17 26 00 00 00 3b 59 dc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 00 00 00 00 00 00 10 32 00 00 00 00 00 00 00 00 00 00)
000131C3>    PropMgr:001b68db:00:0f: [24] *** mpu_recv(06 05 03 35 01 00)
00013295>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000001, 0xE0066E9B(0)
000132C8>    PropMgr:e041f33b:01:03: SpecialComplete ID = 0x80000001, 0x80000001 3011
00013312>    PropMgr:001b686f:00:0f: [5] *** mpu_send(08 06 00 00 02 0e 00 00)
00013389>    Startup:e0048f6d:00:05: [SEQ] seqEventDispatch (Startup, 1)
000133B5>    Startup:e0041c5d:89:05: startupPrepareProperty
0001340F>    Startup:001b68db:00:0f: [25] *** mpu_recv(1c 1b 03 1d 64 03 00 00 00 00 00 4c 50 2d 45 31 37 00 00 00 00 01 00 23 7e 02 66 00)
0001349B>    PropMgr:001b68db:00:0f: [26] *** mpu_recv(06 04 03 36 00 00)
0001353A>    PropMgr:001b68db:00:0f: [27] *** mpu_recv(08 07 03 7e ff ff ff 00)
00013567>    PropMgr:e0048577:88:03: HotPlug TimelapseSetting = 0
000135C8>    Startup:001b68db:00:0f: [28] *** mpu_recv(06 05 03 38 9e 00)
000135F9>    Startup:e0093baf:88:03: # 0 0 1 1 0
00013675>    PropMgr:001b68db:00:0f: [29] *** mpu_recv(08 06 01 a7 00 01 00 00)
000136BD>    Startup:e004899f:88:03: CreateTask Master End
00013719>    PropMgr:001b68db:00:0f: [30] *** mpu_recv(08 06 01 a7 00 00 00 00)
0001379E>    PropMgr:e0041c07:89:03: PROP_GPS_AUTO_TIME_SETTING 0
000137E2>    Startup:e0042c8b:00:03: [STARTUP]startupCompleteCallback 0x20000000
00013805>    Startup:e00490d1:00:03: [SEQ] NotifyComplete (Cur = 2, 0x20420010, Flag = 0x20000000)
0001382D>    Startup:e0041c8f:89:03: startupPrepareProperty : CLASSID_FLAG_PROPAD
0001384B>    Startup:e0693cbd:19:03: FM_Initialize (0, 1, 0)
000138BC>    PropMgr:e0693b99:19:03: fmResultCBR (0x860348)
00013A0C>    PropMgr:e0693bbf:19:03: PROP_HDD_DCIM_PATH (/)
00013AE7>    Startup:e04a1fdf:1c:03: FC_Initialize [drive:0 1 0][ClassID:28]
00013B04>    Startup:e04a2011:1c:03: FC_Initialize [86608 655360]
00013FA7>     RTCMgr:e01ca19f:00:05: [RTC] SPECIAL_OPTION 0x0, 0x4000
00014057>     RTCMgr:001b686f:00:0f: [6] *** mpu_send(08 07 03 6a 00 01 00 00)
000140B4>     RTCMgr:e024a1d5:00:05: [RTC] PermitCharge already Permit 0x20
00014127>    Startup:e0498415:80:03: srmGetShootMemAreaAddress(): Area[4] isn't Exist.
000141C4>    PropMgr:001b686f:00:0f: [7] *** mpu_send(0a 08 03 06 00 00 00 00 00 00)
0001421A>    PropMgr:001b686f:00:0f: [8] *** mpu_send(06 04 03 10 00 00)
00014376>    Startup:001b686f:00:0f: [9] *** mpu_send(06 05 03 07 ff 00)
000143C3>    Startup:e0495ffb:80:03: CreatePackHeapObject
0001441B>    Startup:e0376221:80:03: AllocateMemoryUnit For OnlyMem1
00014434>    Startup:e0376221:80:03: AllocateMemoryUnit For OnlyMem1
00014446>    Startup:e0376221:80:03: AllocateMemoryUnit For OnlyMem1
00014458>    Startup:e0376221:80:03: AllocateMemoryUnit For OnlyMem1
00014589>    Startup:e00d2213:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[1]
000145B6>    Startup:e00d2213:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[2]
00014620>    Startup:e049088d:80:03: RearrangeMemMgr sub 1 0 0
0001467F>    Startup:e04908f1:80:03: fDevDone 1, dwLvLock 0
00014699>    Startup:e049093d:80:03: 0 0 0
000146B6>    Startup:e04909b5:80:03: PROP_MEMORY_STATUS(SELF) (10->)13 (OTHER) 0, 5276
000146D3>    Startup:e04909ff:80:05: Deliver PROP_MEMORY_STATUS 19
0001471B>    Startup:e04960f9:80:03: MemMgr(IMAGE) 0 0
00014736>    Startup:e04960f9:80:03: MemMgr(IMAGE) 0 0
0001474E>    Startup:e04960f9:80:03: MemMgr(IMAGE) 0 1
00014762>    Startup:e04960f9:80:03: MemMgr(IMAGE) 0 0
00014806>     RscMgr:e00ce18b:35:03: this->dwCardStatus[0] = 0x0(474)
0001482E>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
00014846>     RscMgr:e049093d:80:03: 0 0 0
0001487A>     RscMgr:e00ce18b:35:03: this->dwCardStatus[1] = 0x0(474)
000148A1>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
000148B9>     RscMgr:e049093d:80:03: 0 0 0
000148EB>     RscMgr:e00ce219:35:03: PROP_PC_HDD_STATUS = 0x1
00014954>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
0001496F>     RscMgr:e049093d:80:03: 0 0 0
000149C3>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
000149DD>     RscMgr:e049093d:80:03: 0 0 0
00014A30>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
00014A49>     RscMgr:e049093d:80:03: 0 0 0
00014AF8>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
00014B14>     RscMgr:e049093d:80:03: 0 0 0
00014B52>     RscMgr:e00ce557:35:03: PROP_SAVE_MODE = 0x1
00014BA8>     RscMgr:e00ce5db:35:03: PROP_CARD0_FOLDER_NUMBER
00014BE8>     RscMgr:e00ce5db:35:03: PROP_CARD1_FOLDER_NUMBER
00014C87>     RscMgr:e00cdeb9:35:03: PROP_NUMBER_OF_CONTINUOUS_MODE BaseDcfNo 2292
00014CC5>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
00014CDD>     RscMgr:e049093d:80:03: 0 0 0
00014D15>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
00014D2C>     RscMgr:e049093d:80:03: 0 0 0
00014D7D>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
00014D94>     RscMgr:e049093d:80:03: 0 0 0
00014DAB>     RscMgr:e00cec65:35:03: PROP_CARD_EXTENSION 0
00014F99>     RscMgr:e00ceadb:35:03: PC_CLUSTER_SIZE = 0x1000
0001507E>     RscMgr:e00cdb83:80:03: SetAutoIsoCode 0x83
0001509C>     RscMgr:e00cdb97:35:03: ChangeAutoIsoCode Factor:1 AutoIsoCode:131 -> 131
000150F8>     RscMgr:e00cdb83:80:03: SetAutoIsoCode 0x83
00015111>     RscMgr:e00cdb97:35:03: ChangeAutoIsoCode Factor:2 AutoIsoCode:131 -> 131
0001516C>     RscMgr:e00d2213:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[3]
00015190>     RscMgr:e00d2213:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[4]
000151B2>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
000151C8>     RscMgr:e049093d:80:03: 0 0 0
00015210>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
00015227>     RscMgr:e049093d:80:03: 0 0 0
00015285>     RscMgr:e00d2213:35:03: RealClearBusy(0x40000) 0x0->0x0,0x0(0x0)[5]
000152D5>     RscMgr:e00d2213:35:03: RealClearBusy(0x40000) 0x0->0x0,0x0(0x0)[6]
00015323>     RscMgr:e00d2213:35:03: RealClearBusy(0x40000) 0x0->0x0,0x0(0x0)[7]
0001536E>     RscMgr:e00d2213:35:03: RealClearBusy(0x40000) 0x0->0x0,0x0(0x0)[8]
000153A7>     RscMgr:e00cdb83:80:03: SetAutoIsoCode 0x88
000153BD>     RscMgr:e00cdb97:35:03: ChangeAutoIsoCode Factor:0 AutoIsoCode:131 -> 136
00015427>     RscMgr:e00d2213:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[9]
00015446>     RscMgr:e00d2213:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[10]
00015467>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
0001547E>     RscMgr:e049093d:80:03: 0 0 0
000154E4>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
000154FB>     RscMgr:e049093d:80:03: 0 0 0
00015553>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
0001556A>     RscMgr:e049093d:80:03: 0 0 0
00015676>     RscMgr:e00ce4c5:35:03: RU CLUSTER_SIZE[0] = 0x407BA6B0
000156D6>     RscMgr:e00ce4c5:35:03: RU CLUSTER_SIZE[1] = 0x407BA6BC
000157A6>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 0, ClassID = 53
000157DE>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 11, ClassID = 53
000157FD>   EventMgr:e00a2b5d:37:03: Already SW1OFF
00015839>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 14, ClassID = 53
00015862>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 15, ClassID = 53
0001588A>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 4, ClassID = 53
00015A19>    Startup:e06983bf:19:03: FM_RegisterSpaceNotifyCallback
00015A40>    Startup:e0713445:1a:05: MRK_RegisterSpaceNotifyCallback
00015A60>    Startup:e02a881d:1a:03: RegisterSpaceNotifyCallback : DriveNo = 2
00015A85>    Startup:e01c7067:19:03: voiRegisterSpaceNotifyCallback : DriveNo = 2
00015AA6>    Startup:e050f011:19:03: [GPS] gpsRegisterSpaceNotifyCallback : DriveNo = 2
00015AC8>    Startup:e065c9af:19:03: RegisterSpaceNotifyCallback : DriveNo = 2
00015B52>    Startup:e04bc1e7:15:03: @Startup FIO_RegisterSpaceNotifyCallback(1,0xe04d4b0b,0x2) L:1051
00015B88>    Startup:e04ea317:1c:03: FcmcRegisterSpaceNotifyCallback : DriveNo = 2
00015BA8>    Startup:e06983bf:19:03: FM_RegisterSpaceNotifyCallback
00015C35>    Startup:e04c2573:39:05: InitializeJobClass (ID = 2015, Num = 15)
00015C57>    Startup:e04c25c5:39:05: InitializeJobClass 12 206 0 5544
00015CBB>    PropMgr:e01b14bd:39:03: [BIND] dcsResultCBR (0x8624f0)
00015DE3>    PropMgr:001b68db:00:0f: [31] *** mpu_recv(42 40 02 11 00 01 00 00 00 00 01 00 ff 01 00 00 00 00 00 00 00 ff 01 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 ff 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 15 00 00 00 00 00)
00015E90>    PropMgr:001b68db:00:0f: [32] *** mpu_recv(08 06 01 04 00 00 00 00)
00015EFD>    PropMgr:e01b1ddb:39:03: PROP_GPS_INFORMATION fGPSConnect = 0x0
00015F1C>    PropMgr:e01b1df1:39:03: MPU 0x0 USB 0x0 WFT 0x0 INNER 0x0
00015F48>    PropMgr:001b68db:00:0f: [33] *** mpu_recv(08 06 01 a2 00 00 00 00)
00015F6A>    PropMgr:e01b1ddb:39:03: PROP_MPU_GPS fGPSConnect = 0x0
00015F84>    PropMgr:e01b1df1:39:03: MPU 0x0 USB 0x0 WFT 0x0 INNER 0x0
00015FC4>    PropMgr:001b68db:00:0f: [34] *** mpu_recv(06 05 01 06 15 00)
00016034>    PropMgr:e01b14cf:39:03: @@@setDefaultImgDirection
00016052>    PropMgr:e01b24f5:39:03: PROP_GPS_DEVICE_ACTIVE INNER 0x0 fGPSConnect = 0x0
0001607E>    PropMgr:001b68db:00:0f: [35] *** mpu_recv(06 05 03 23 1d 00)
000160A3>    PropMgr:e01b2583:39:03: PROP_NETWORK_SYSTEM 0x0
000162C8>    PropMgr:001b68db:00:0f: [36] *** mpu_recv(22 21 03 24 45 46 2d 53 31 38 2d 35 35 6d 6d 20 66 2f 33 2e 35 2d 35 2e 36 20 49 53 20 53 54 4d 00 00)
00016351>    PropMgr:001b68db:00:0f: [37] *** mpu_recv(06 04 03 25 00 00)
0001662F>    PropMgr:001b68db:00:0f: [38] *** mpu_recv(06 05 01 99 00 00)
000166F2>    PropMgr:001b68db:00:0f: [39] *** mpu_recv(06 05 01 9a 00 00)
00016754>    PropMgr:e01b24f5:39:03: PROP_BTDEVICE_CONNECT WFT 0x0 fGPSConnect = 0x0
000167AE>    PropMgr:001b68db:00:0f: [40] *** mpu_recv(06 05 01 06 15 00)
0001685C>    PropMgr:e041e695:01:03: DivideLensInit2Data[3] comID 1 dataID 4 data 0x0
000168BA>    PropMgr:001b68db:00:0f: [41] *** mpu_recv(06 05 01 3f 00 00)
00016990>    PropMgr:e00afc13:81:03: PROP_STROBO_FIRING 0 Last 0
000169AD>    PropMgr:e00afc2d:81:03: dwLastStroboFiring = 0  stroboFiring = 0
000169FB>    Startup:001b686f:00:0f: [10] *** mpu_send(06 05 01 2e 01 00)
00016A6F>   EventMgr:e00a3283:37:05: emLockControl (TYPE_JOBSTATE = 0x0)
00016ACD>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
00016AE9>     RscMgr:e049093d:80:03: 0 0 0
00016B9E>    PropMgr:001b686f:00:0f: [11] *** mpu_send(0a 08 03 0b 00 00 00 00 00 00)
00016CCA>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 20, ClassID = 57
00016D1A>    Startup:e04c2bdb:39:05: InitializeInnerDevelopJobClass (ID = 2015, Num = 16)
00016D3F>    Startup:e04cd927:39:05: InitializeHDRShootJobClass ( Num = 13 )
00016D5B>    Startup:e04cd955:39:05: InitializeHDRSaveAndEndJobClass ( Num = 37 )
00016D76>    Startup:e04ce3e3:39:05: InitializeGISShootJobClass ( Num = 13 )
00016D91>    Startup:e04ce40b:39:05: InitializeGISSaveAndEndJobClass ( Num = 28, 31 )
00016DC7>    Startup:e04c2c09:39:03: InitializeShufflehootJobClass (ID = 2015, Num = 15)
00016E26>    Startup:e00929e5:d9:03: InitializeGUILock (PUB)
00016EA2>    PropMgr:001b686f:00:0f: [12] *** mpu_send(06 05 03 19 01 00)
00016ECC>    PropMgr:e041e9b5:d9:03: [GUI] MasterResultCBR
00016F28>    PropMgr:e0044569:8a:03: terminateChangeCBR : SHUTDOWN (255)
00016F44>    PropMgr:e004468b:00:03: [TERMINATE] SHUTDOWN init comp
00016F62>    PropMgr:e0044723:8a:03: terminateChangeCBR : AUTO_POWEROFF (1)
00016F83>    PropMgr:e00444f7:00:03: [TERMINATE] Abort init comp
00017044>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 0, ClassID = 150
00017077>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 1, ClassID = 150
000170A1>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 4, ClassID = 150
00017164>    PropMgr:e006bbbf:96:03: PROP_SHOOTING_TYPE (0x0->0x0)
00017183>    PropMgr:e006bc1d:96:03: PROP_AF_SHIFT_AFB_INFO (0x0 0)
000172F3>    Startup:001b686f:00:0f: [13] *** mpu_send(06 05 01 56 00 00)
0001732E>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 0, ClassID = 225
0001736D>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 11, ClassID = 225
0001738E>   EventMgr:e00a2b5d:37:03: Already SW1OFF
000173BB>   MainCtrl:e0094603:94:03: MeteringTimerStart
000173E9>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 7, ClassID = 225
00017414>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 1, ClassID = 225
0001743D>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 4, ClassID = 225
00017468>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 6, ClassID = 225
0001748F>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 3, ClassID = 225
000174B7>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 2, ClassID = 225
000174DE>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 20, ClassID = 225
00017507>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 24, ClassID = 130
00017531>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 25, ClassID = 130
00017657>    PropMgr:001b68db:00:0f: [42] *** mpu_recv(08 06 01 04 00 00 00 00)
00017685>   MainCtrl:e006f9d1:94:03: PROP_DISPLAY_OFF_SENSOR 1
000176DB>   MainCtrl:e006f9d1:94:03: PROP_DISPSENSOR_CTRL 1
00017708>   MainCtrl:001b68db:00:0f: [43] *** mpu_recv(08 06 01 a2 00 00 00 00)
0001776E>   MainCtrl:e009514d:94:03: PROP_SHOOTING_TYPE 0
0001778B>   MainCtrl:e0093eb9:94:03: set_lv_act2 : 0 -1 1 0
000177C7>   MainCtrl:e00951c9:94:03: PROP_GUI_STATE 0
000177FD>   MainCtrl:e0094fc9:94:03: PROP_LV_ACTION LV_STOP
00017816>   MainCtrl:e0094cb1:94:03: judge_lv_disp_busy(mode_change): 0 0 1 1 0
0001784B>   MainCtrl:e006f9d1:94:03: PROP_LV_DISPBUSY not Busy
0001787D>   MainCtrl:e009520b:94:03: PROP_LV_LOCK LVLOCK_PERMIT
00017895>   MainCtrl:e0093eb9:94:03: set_lv_act2 : 0 1 1 0
000178AC>   MainCtrl:e0094cb1:94:03: judge_lv_disp_busy(mode_change): 0 0 1 1 0
000178D9>   MainCtrl:e006f9d1:94:03: PROP_DISABLE_PLAY_IMAGE Enable Play
00017917>   MainCtrl:e0094eef:94:03: JobState 0
0001792E>   MainCtrl:e0095a91:94:03: on_digi_event start
00017945>   MainCtrl:e0093eb9:94:03: set_lv_act2 : 0 1 1 0
0001795A>   MainCtrl:e0094cb1:94:03: judge_lv_disp_busy(mode_change): 0 0 1 1 0
00017992>   MainCtrl:e00954b1:94:03: PROP_AE_MODE m_AeMode=0x00 m_SetTv =0x70 ,m_ModeBulb=0
000179B8>   MainCtrl:e00954b1:94:03: PROP_SET_TV  m_SetTv =0x60 m_AeMode=0x00 ,m_ModeBulb=0
00017A64>   MainCtrl:e006f9d1:94:03: QRTime 2
00017B0A>    PropMgr:001b68db:00:0f: [44] *** mpu_recv(0e 0d 04 30 00 00 00 00 00 00 00 00 00 00)
00017B8A>    PropMgr:001b68db:00:0f: [45] *** mpu_recv(06 05 01 48 01 00)
00017BF7>   MainCtrl:e006f9d1:94:03: PROP_VARIANGLE_GUICTRL Enable
00017C22>   MainCtrl:001b68db:00:0f: [46] *** mpu_recv(06 05 01 4b 01 00)
00017C45>   MainCtrl:e006f991:94:03: PROP_HEADPHONE_VOLUME_VALUE : 0
00017C95>   MainCtrl:e006f911:94:03: PROP_MOVIE_PLAY_VOLUME : 5
00017CD2>    PropMgr:001b68db:00:0f: [47] *** mpu_recv(06 05 01 49 02 00)
00017D13>   MainCtrl:e006f9d1:94:16: PROP_LCD_OFFON_BUTTON : 0
00017D50>   MainCtrl:e006f9d1:94:03: PROP_LV_CFILTER 0
00017D7A>   MainCtrl:001b68db:00:0f: [48] *** mpu_recv(06 05 01 12 00 00)
00017DA4>   MainCtrl:e0093eb9:94:03: set_lv_act2 : 0 1 1 0
00017DEE>   MainCtrl:e0094cb1:94:03: judge_lv_disp_busy(mode_change): 0 1 1 1 0
00017E38>    PropMgr:001b68db:00:0f: [49] *** mpu_recv(06 05 01 13 00 00)
00017ECA>   MainCtrl:e009507d:94:03: PROP_GUIGROUND_STATE 1
00017F24>   MainCtrl:e0094fc9:94:03: PROP_LV_ACTION LV_STOP
00017F42>   MainCtrl:e0094cb1:94:03: judge_lv_disp_busy(mode_change): 0 1 1 1 0
00017F78>   MainCtrl:001b68db:00:0f: [50] *** mpu_recv(10 0e 01 8f 00 00 00 00 00 00 00 00 00 00 00 00)
00018075>     RscMgr:001b68db:00:0f: [51] *** mpu_recv(0e 0c 01 b1 00 00 00 00 00 00 00 00 00 00)
000180BE>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
000180DD>     RscMgr:e049093d:80:03: 0 0 0
00018107>     RscMgr:001b68db:00:0f: [52] *** mpu_recv(06 05 01 03 01 00)
0001819A>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
000181B3>     RscMgr:e049093d:80:03: 0 0 0
0001825A>    PropMgr:001b686f:00:0f: [14] *** mpu_send(06 05 04 0e 01 00)
00018294>    PropMgr:e041db9d:01:03: LV_CFilter : kind 0 hv 0
000182B3>    PropMgr:e041dbc1:01:03: Level 0 0 0 0 0 0 0 0
000182DC>    PropMgr:e00676f1:81:03: @@@ PROP_LV_CFILTER 0
0001834C>   MainCtrl:e006f9d1:94:03: PROP_LV_CFILTER 0
0001838B>   MainCtrl:e006f9d1:94:03: PROP_LV_DISPBUSY Busy
000183BC>   MainCtrl:e006f9d1:94:03: PROP_LV_DISPBUSY Busy
000183E8>   MainCtrl:e006f9d1:94:03: PROP_LV_DISPBUSY Busy
0001840C>    PropMgr:e0420ad3:01:03: MovieCFilter : kind 0 hv 0
00018425>    PropMgr:e0420af1:01:03: Level 0 0 0 0 0 0
00018441>    PropMgr:e00679df:81:03: @@@ PROP_MOVIE_CFILTER 0
00018491>   MainCtrl:e006f9d1:94:03: PROP_LV_DISPBUSY not Busy
00018533>    PropMgr:e04bc1e7:15:03: @PropMgr FIO_SuspendDelayFlush(0) L:709
00018562>   MainCtrl:e0094f3d:94:03: CardCover=0
0001857F>    PropMgr:e041e9b5:94:03: regist master CardCover
000185BE>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 13, ClassID = 225
000185F1>    Startup:e05f2995:3a:03: TA10_Initialize : Start
0001867E>    PropMgr:001b686f:00:0f: [15] *** mpu_send(06 05 03 40 00 00)
0001879D>    PropMgr:e05f24c9:3a:03: ### TA10Setting Clear (OFF->OFF) ###
000187C7>    PropMgr:e05f2461:3a:03: ChangePropCBR ShotsPlan 2 / TotalSheets 2
00018AA4>    PropMgr:001b686f:00:0f: [16] *** mpu_send(0c 0b 03 53 02 00 48 81 81 00 00 00)
00018B3B>    Startup:e05f2be7:3a:03: TA10_Initialize : End
00018B66>    Startup:001b686f:00:0f: [17] *** mpu_send(0c 0b 03 53 02 00 48 81 81 00 00 00)
00018B96>    Startup:e006c851:3c:03: HDR_Initialize : Start
00018C9E>    PropMgr:e006c475:3c:03: ### HDRSetting Clear (OFF->OFF) ###
00018CBC>    PropMgr:e006c41f:3c:03: ChangePropCBR HDRFunc 0
00018D13>    Startup:e00a4fdf:3c:03: HDRS_Initialize
00018D36>    Startup:e00a500b:3c:03: CreateStageClass
00018DC1>    Startup:e00a5425:3c:03: HDRS_Initialize : End
00018DD7>    Startup:e006c977:3c:03: HDR_Initialize : End
00018DF2>    Startup:e006d94d:3d:03: GIS_Initialize : Start
00018EC8>    PropMgr:e006d575:3d:03: ### GISSetting Clear (OFF->OFF) ###
00018EE6>    PropMgr:e006d525:3d:03: ChangePropCBR GISFunc 0
00018F3C>    Startup:e00a7ab5:3d:03: GISS_Initialize
00018F5F>    Startup:e00a7adf:3d:03: CreateStageClass
00018FDB>    Startup:e00a7c0b:3d:03: GISS_Initialize : End
00018FF1>    Startup:e006da75:3d:03: GIS_Initialize : End
00019047>    FileMgr:e01c24cd:19:03: PROP_CARD1_STATUS = 0x0
00019099>    FileMgr:e04bc1e7:15:03: @FileMgr FIO_SetCardChangeFlag(0,1) L:1060
000190D4>    FileMgr:e01c23fb:19:03: PROP_CARD1_FOLDER_NUMBER = 142
000190FF>    FileMgr:e01c2773:19:03: PROP_CARD1_FILE_NUMBER = 0
00019139>    FileMgr:e01c26c1:19:03: PROP_CARD2_STATUS = 0x0
00019177>    FileMgr:e04bc1e7:15:03: @FileMgr FIO_SetCardChangeFlag(1,1) L:1060
000191A0>    FileMgr:e01c273d:19:03: PROP_CARD2_FOLDER_NUMBER = 100
000191CA>    FileMgr:e01c2785:19:03: PROP_CARD2_FILE_NUMBER = 2292
000191F9>    FileMgr:e01c2827:19:03: PROP_FILE_NUMBERING_MODE = 1, 0
00019219>    FileMgr:e01c27db:19:03: PROP_CARD_EXTENSION = 0
00019235>    FileMgr:e01c27fd:19:03: PROP_CURRENT_MEDIA = 2
00019250>    FileMgr:e01c2455:19:03: PROP_USBDEVICE_CONNECT = -1
0001926C>    FileMgr:e01c2873:19:03: PROP_NUMBER_OF_CONTINUOUS_MODE = 2292
00019286>    FileMgr:e0042c8b:00:03: [STARTUP]startupCompleteCallback 0x10
000192A1>    FileMgr:e00490d1:00:03: [SEQ] NotifyComplete (Cur = 2, 0x420010, Flag = 0x10)
000192C9>    FileMgr:e01c28c7:19:03: PROP_DSDEFINE ModelId 80000417
000192EF>    FileMgr:e01c28df:19:03: PROP_APPENDMOVINFO Handle 0,205001d
0001930C>    FileMgr:e01c28ef:19:03: PROP_APPENDMOVINFO VideoSnapMode 4,205001d
00019330>    FileMgr:e01c2937:19:03: PROP_SPECIAL_OPTION = 16384
00019350>    FileMgr:e01c296b:19:03: PROP_SCREEN_SAVER = 0
0001936E>    FileMgr:e01c2997:19:03: PROP_CARD1_RU_SIZE -1
00019388>    FileMgr:e01c29a9:19:03: PROP_CARD2_RU_SIZE 524288
000193B4>    FileMgr:e01c3ab3:19:03: fmInitialized
00019407>    FileMgr:e039fd2b:1c:03: _FC_SetDirSuffix (CANON)
00019439>    FileMgr:e01c3bc3:19:03: fmPrepare
00019479>    FileMgr:e04bc1e7:15:03: @FileMgr FIO_Init(25,28,0xe069ad83) L:870
000194A0>    FileMgr:e025ba41:13:03: CSMGR_Initialize
00019898>    FileMgr:e025c0e3:13:03: InitializeLogicalStorage: LStorageList = NULL
000198B1>    FileMgr:e025c10d:13:03: SocketServiceInstall: SUCCESS
00019903>    FileMgr:e04bc1e7:15:03: @FileMgr FIO_GetSupportedDriveInfo(0x2233f4) L:1102
00019933>    FileMgr:e02b6f89:18:03: InitializeSDDriver
00019BB9>    FileMgr:e025b8cb:13:03: RegisterClient: handler=0xe02c1dc1 1
00019BE7>    FileMgr:e025b921:13:03: RegisterClient: SUCCESS
00019BFC>    FileMgr:e025bb33:13:03: CSMGR_Initialize End
00019C17>    FileMgr:e069b4ed:19:03: fmAllocDcfNo(0x4845f8)(0x0)
00019C6B>     RscMgr:e00d1e23:35:03: srmAllocDcfNoTable
00019C95>     RscMgr:e069b4c7:19:03: fmAllocateDcfNoCompleteCallback(0x4169ec00,0x4000)
00019CEF>    FileMgr:e01c3be5:19:03: fmAllocDcfNo : DcfNoTable(0x4169ec00)
00019D47>    FileMgr:e04bc1e7:15:03: @FileMgr FIO_MountDevice(1,0,0) L:901
00019D68>    FileMgr:e015bb9b:16:03: [FSUmountDevice] (0x1)
00019D81>    FileMgr:e025bb4f:13:03: MapPhysicToLog: StorageID=1
00019D96>    FileMgr:e025bb65:13:03: MapPhysicToLog: SUCCESS(0x86b930)
00019DAF>    FileMgr:e025bfd9:13:03: CSMGR_MountCard : Message=0x1fd74, pLStorage=0x86b930
00019DED>     NFCMgr:e0586c2b:3e:03:  PROP_SPECIAL_OPTION ->init (0x4000)
00019FEB>     NFCMgr:e058a845:3e:03:  nfcmgrstate_Initialize:NewsDet_R Hi
0001A0AB>  CSMgrTask:e025b9c9:13:03: CSMgrTask: pMessage=0x1fd74, pLStorage=0x86b930
0001A0D1>  CSMgrTask:e025b955:13:03: MapLogToPhysic: pLStorage=0x86b930
0001A0EA>  CSMgrTask:e025b969:13:03: MapLogToPhysic: SUCCESS(ID=1)
0001A102>  CSMgrTask:e025b955:13:03: MapLogToPhysic: pLStorage=0x86b930
0001A11C>  CSMgrTask:e025b969:13:03: MapLogToPhysic: SUCCESS(ID=1)
0001A12E>  CSMgrTask:e02c1ded:18:03: ---- SDEventHandler(ID=1:Event=8) ----
0001A179>  CSMgrTask:e02b6397:16:03: Set StgDev:1
0001A224>     NFCMgr:001b68db:00:0f: [53] *** mpu_recv(06 05 03 38 9e 00)
0001A335>    CE_Main:001b68db:00:0f: [54] *** mpu_recv(06 05 04 29 01 00)
0001A3D5>   MainCtrl:e0094cb1:94:03: judge_lv_disp_busy(mode_change): 0 1 1 1 0
0001A410>   MainCtrl:001b68db:00:0f: [55] *** mpu_recv(0a 09 01 55 00 00 02 00 00 01)
0001A48F>    PropMgr:e0067ac9:81:03: PROP_MULTIPLE_EXPOSURE_SETTING 0
0001A53A>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000003F, 0xE0066E9B(1)
0001A5C4>     RscMgr:e00d2213:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[11]
0001A646>     RscMgr:e00d2213:35:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)[12]
0001A67B>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
0001A694>     RscMgr:e049093d:80:03: 0 0 0
0001A6E6>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000003F, 0xE04CF021(2)
0001A720>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000003F, 0xE01B152D(3)
0001A75C>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000003F, 0xE006F9E3(4)
0001A788>    PropMgr:e05f24c9:3a:03: ### TA10Setting Clear (OFF->OFF) ###
0001A7AF>    PropMgr:e05f2461:3a:03: ChangePropCBR ShotsPlan 2 / TotalSheets 2
0001A7DB>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000003F, 0xE05F2105(5)
0001A812>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000003F, 0xE006C3AB(6)
0001A84B>    PropMgr:001b68db:00:0f: [56] *** mpu_recv(06 05 01 2e 01 00)
0001A86C>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000003F, 0xE006D4A7(7)
0001A89F>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000003F, 0xE0066E9B(6)
0001A8CE>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000003F, 0xE04CF021(5)
0001A900>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000003F, 0xE01B152D(4)
0001A92D>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000003F, 0xE006F9E3(3)
0001A994>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000003F, 0xE05F2105(2)
0001A9C0>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000003F, 0xE006C3AB(1)
0001AA1B>     RscMgr:e00ce557:35:03: PROP_SAVE_MODE = 0x1
0001AA66>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000003F, 0xE006D4A7(0)
0001AAB3>    PropMgr:001b686f:00:0f: [18] *** mpu_send(08 06 00 00 01 55 00 00)
0001AB71>    PropMgr:001b686f:00:0f: [19] *** mpu_send(0c 0b 03 53 02 00 48 81 81 00 00 00)
0001AC02>    PropMgr:001b686f:00:0f: [20] *** mpu_send(0c 0b 03 53 02 00 48 81 81 00 00 00)
0001AC85>  CSMgrTask:e02b101b:18:03: SDPowerOn
0001AE25>   PowerMgr:001b68db:00:0f: [57] *** mpu_recv(08 06 01 1d 81 81 00 00)
0001AEBF>   PowerMgr:001b68db:00:0f: [58] *** mpu_recv(06 05 01 74 01 00)
0001AF54>   PowerMgr:001b68db:00:0f: [59] *** mpu_recv(06 05 01 75 00 00)
0001B537>  CSMgrTask:e02b7387:18:03: SD initialize start
0001B8FE>   PowerMgr:001b68db:00:0f: [60] *** mpu_recv(06 05 01 07 68 01)
0001B96A>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000007, 0xE04CF021(1)
0001B99E>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000007, 0xE01B152D(2)
0001B9CE>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000007, 0xE04CF021(1)
0001B9FB>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000007, 0xE01B152D(0)
0001BA36>   PowerMgr:001b686f:00:0f: [21] *** mpu_send(08 06 00 00 01 07 00 00)
0001C1E6>   PowerMgr:001b68db:00:0f: [61] *** mpu_recv(0a 08 01 34 00 00 01 03 01 00)
0001C267>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
0001C281>     RscMgr:e049093d:80:03: 0 0 0
0001C2C3>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000002F, 0xE04CF021(1)
0001C2F6>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000002F, 0xE01B152D(2)
0001C329>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000002F, 0xE04CF021(1)
0001C358>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000002F, 0xE01B152D(0)
0001C395>  CSMgrTask:001b686f:00:0f: [22] *** mpu_send(08 06 00 00 01 34 00 00)
0001C659>  CSMgrTask:001b68db:00:0f: [62] *** mpu_recv(0a 08 01 35 00 00 06 04 01 00)
0001C6C5>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000030, 0xE04CF021(1)
0001C6F6>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000030, 0xE01B152D(2)
0001C727>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000030, 0xE04CF021(1)
0001C755>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000030, 0xE01B152D(0)
0001C790>  CSMgrTask:001b686f:00:0f: [23] *** mpu_send(08 06 00 00 01 35 00 00)
0001D74D>   PowerMgr:001b68db:00:0f: [63] *** mpu_recv(0a 09 01 70 00 00 00 00 00 01)
0001D787>    PropMgr:e0067ac9:81:03: PROP_HDR_SETTING 0
0001D7B4>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000045, 0xE0066E9B(1)
0001D805>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
0001D81F>     RscMgr:e049093d:80:03: 0 0 0
0001D857>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000045, 0xE04CF021(2)
0001D88C>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000045, 0xE01B152D(3)
0001D8CF>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000045, 0xE006F9E3(4)
0001D8FF>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000045, 0xE05F2105(5)
0001D925>    PropMgr:e006c475:3c:03: ### HDRSetting Clear (OFF->OFF) ###
0001D93A>    PropMgr:e006c41f:3c:03: ChangePropCBR HDRFunc 0
0001D951>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000045, 0xE006C3AB(6)
0001D97E>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x80000045, 0xE006D4A7(7)
0001D9AD>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000045, 0xE0066E9B(6)
0001D9DC>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000045, 0xE04CF021(5)
0001DA08>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000045, 0xE01B152D(4)
0001DA31>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000045, 0xE006F9E3(3)
0001DA5C>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000045, 0xE05F2105(2)
0001DA85>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000045, 0xE006C3AB(1)
0001DAB0>    PropMgr:e041f1df:01:03: Complete WaitID = 0x80000045, 0xE006D4A7(0)
0001DAEB>   PowerMgr:001b686f:00:0f: [24] *** mpu_send(08 06 00 00 01 70 00 00)
0001DCA7>   PowerMgr:001b68db:00:0f: [64] *** mpu_recv(0a 08 01 85 00 00 00 01 01 00)
0001DCE2>    PropMgr:e0067ac9:81:03: PROP_GIS_SETTING Func 0
0001DD08>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000004E, 0xE0066E9B(1)
0001DD56>     RscMgr:e04908f1:80:03: fDevDone 1, dwLvLock 0
0001DD70>     RscMgr:e049093d:80:03: 0 0 0
0001DDA6>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000004E, 0xE04CF021(2)
0001DDD6>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000004E, 0xE01B152D(3)
0001DE0E>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000004E, 0xE006F9E3(4)
0001DE3C>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000004E, 0xE006C3AB(5)
0001DE64>    PropMgr:e006d575:3d:03: ### GISSetting Clear (OFF->OFF) ###
0001DE79>    PropMgr:e006d525:3d:03: ChangePropCBR GISFunc 0
0001DE8F>    PropMgr:e041c56d:01:03: Deliv WaitID = 0x8000004E, 0xE006D4A7(6)
0001DEBD>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000004E, 0xE0066E9B(5)
0001DEEA>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000004E, 0xE04CF021(4)
0001DF16>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000004E, 0xE01B152D(3)
0001DF42>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000004E, 0xE006F9E3(2)
0001DF6D>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000004E, 0xE006C3AB(1)
0001DF96>    PropMgr:e041f1df:01:03: Complete WaitID = 0x8000004E, 0xE006D4A7(0)
0001DFD2>   PowerMgr:001b686f:00:0f: [25] *** mpu_send(08 06 00 00 01 85 00 00)
00028E68>    CE_Main:e0585a27:3e:03:  ce_completion payload=84 num=2
00028F81>     NFCMgr:e058acc1:3e:03:  nfcmgrstate_Initialize:wtime=0
000292C5>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 0, ClassID = 62
00029300>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 7, ClassID = 62
00029330>   EventMgr:e00a2b2b:37:03: emRegisterMulticastCallback : EventID = 11, ClassID = 62
0002934E>   EventMgr:e00a2b5d:37:03: Already SW1OFF
00029377>     NFCMgr:e058ad21:3e:03:  nfcmgrstate_Initialize End
000293C3>     NFCMgr:e058710b:3e:03:  PROP_AUTO_POWEROFF 1
000293FE>     NFCMgr:e0586ce3:3e:03:  PROP_NFC_APPLI_INFO jp.co.canon.ic.cameraconnect
00029418>     NFCMgr:e0586cf1:3e:03:  PROP_NFC_APPLI_INFO a01
000294ED>     NFCMgr:e0586aa3:3e:03:  ChkRWInfo Illegal product type(pdt=dslr)
0002953C>     NFCMgr:e0586d55:3e:03:  PROP_DSDEFINE Canon%20EOS%20200D
00029557>     NFCMgr:e058787b:3e:03:  PROP_DSDEFINE 0x32cc
000295E1>     NFCMgr:e0586bed:3e:03:  PropChange:PROP_NETWORK_NICKNAME(EOS200D)->(EOS200D)
0002961F>     NFCMgr:e058787b:3e:03:  PROP_NETWORK_SYSTEM MODE_OFF 0
00029649>     NFCMgr:e0587349:3e:03:  PROP_NFC_SETTING enable 1
00029672>     NFCMgr:e058736b:3e:03:  PROP_FIXED_MOVIE off 0
00029699>     NFCMgr:e058739b:3e:03:  SHOOTING_TYPE_MOVIE off 0
000296BF>     NFCMgr:e05873cb:3e:03:  PROP_TIMELAPSE_MOVIE_SETTING off 0
000296E5>     NFCMgr:e058740f:3e:03:  PROP_MULTIPLE_EXPOSURE_SETTING OFF 0
0002970E>     NFCMgr:e0587427:3e:03:  PROP_VARIANGLEDISPLAY_ONOFF ON 1
00029734>     NFCMgr:e0587831:3e:03:  PROP_VIDEOSNAP_MODE OFF 0
00029809>     NFCMgr:e058785f:3e:03:  PROP_ICU_UILock OFF 0x0
00029832>     NFCMgr:e058792d:3e:03:  PROP_PHYSICAL_CONNECT disconnect 0
00029856>     NFCMgr:e0586c85:3e:03:  PROP_STARTUP_CONDITION NOT BLE_LOCKOFF (0x1)
000298AD>     NFCMgr:e03d78fb:3e:03: [BLE] Initialize : Enter
00029BB1>     NFCMgr:e05c17b9:3e:03: [BLE] BLESIODRIVER_Initialize END
00029BD7>     NFCMgr:e05c153d:3e:03: [BLE] blesiodriver_SioInitialize END
00029C21>     NFCMgr:e05aea5f:3e:03: [BLE] BLEFirmUp_InitializeTest
00029DF0>     NFCMgr:e03d9cc1:3e:03: [BLE] PROP_DSDEFINE 0x32cc
00029E69>     NFCMgr:e03d96c5:3e:03: [BLE] PROP_NETWORK_NICKNAME EOS200D
00029ECD>     NFCMgr:e03d9d8d:3e:03:  [BLE] PROP_FIXED_MOVIE off 0
00029F39>     NFCMgr:e03d9e65:3e:03: [BLE] PROP_VIDEOSNAP_MODE OFF 0
00029F72>     NFCMgr:e03d91c1:3e:03: [BLE] PROP_BLE_SETTING SMARTPHONE(1)
00029F8F>     NFCMgr:e03d0d03:3e:03: [BLE] Enter blemgr_SmartphoneGps_CheckState().
00029FA9>     NFCMgr:e03d0c35:3e:03: [BLE] Enter CheckGpsAndBleState().
00029FE6>     NFCMgr:e03d92f5:3e:03: [BLE] PROP_BLE_PAIRING_INFO fSet(1 0) 1 2
0002A01E>     NFCMgr:e03d49e9:3e:03: [BLE] CheckWiFiConnect TRUE
0002A048>     NFCMgr:e03d98a1:3e:03: [BLE] PROP_BLE_REMOTE_RESULT 0
0002A073>     NFCMgr:e03d0d03:3e:03: [BLE] Enter blemgr_SmartphoneGps_CheckState().
0002A087>     NFCMgr:e03d0c35:3e:03: [BLE] Enter CheckGpsAndBleState().
0002A0B3>     NFCMgr:e03d0d03:3e:03: [BLE] Enter blemgr_SmartphoneGps_CheckState().
0002A0C8>     NFCMgr:e03d0c35:3e:03: [BLE] Enter CheckGpsAndBleState().
0002A103>     NFCMgr:e03d968f:3e:03: [BLE] PROP_PHYSICAL_CONNECT disconnect 0
0002A151>     NFCMgr:e03d9941:3e:03: [BLE] PROP_BATTERY_POWER:not BAT_NONE 2
0002A170>     NFCMgr:e03d7e49:3e:03: [BLE] InitializeChkState
0002A18C>     NFCMgr:e03cf9f1:3e:03: [BLE] SendCamPowerState :0x1
000464CD>     NFCMgr:e03db2af:3e:03: [BLE] Enter blemgr_SmartPhoneGps_NopEvent!!!
000464EB>     NFCMgr:e03db2c1:3e:03: [BLE]   Status=0, Event=13
00046510>     NFCMgr:e03db2af:3e:03: [BLE] Enter blemgr_SmartPhoneGps_NopEvent!!!
00046526>     NFCMgr:e03db2c1:3e:03: [BLE]   Status=0, Event=13
00046544>     NFCMgr:e03db2af:3e:03: [BLE] Enter blemgr_SmartPhoneGps_NopEvent!!!
00046557>     NFCMgr:e03db2c1:3e:03: [BLE]   Status=0, Event=13
00046CA4>     NFCMgr:e03d44cf:3e:03: [BLE] ProcSpiRecvData Cat = 0x1, cmd = 0x85
00046CD2>     NFCMgr:e03d1243:3e:03: [BLE] RecvNtfBleState IDLE(1)
00046D29>     NFCMgr:e03cfbab:3e:03: [BLE] SendGetPairingInfo :0x1
000474D7>     NFCMgr:e03d0d03:3e:03: [BLE] Enter blemgr_SmartphoneGps_CheckState().
00047EA1>     NFCMgr:e03d44cf:3e:03: [BLE] ProcSpiRecvData Cat = 0x2, cmd = 0x86
00047ECC>     NFCMgr:e03d214b:3e:03: [BLE] JudgeBlePairInfo SD Host&BLE:Exist
00047EE4>     NFCMgr:e03d1cf5:3e:03: [BLE] CheckNextBlePairInfo:SD01->ARC
00047EFB>     NFCMgr:e03cfbab:3e:03: [BLE] SendGetPairingInfo :0x2
00049077>     NFCMgr:e03d44cf:3e:03: [BLE] ProcSpiRecvData Cat = 0x2, cmd = 0x86
0004909B>     NFCMgr:e03d214b:3e:03: [BLE] JudgeBlePairInfo ARC Host&BLE:None
000490B2>     NFCMgr:e03d1d0b:3e:03: [BLE] CheckNextBlePairInfo:ARC->END
000AF2BB>  CSMgrTask:e02b7b2b:18:03: power 18
000AF2D6>  CSMgrTask:e02b1097:18:16: SdSwitchVoltage 1
000BC4F5>  CSMgrTask:e02b73d5:18:16: SD initialize end speed=2 clock=2 UHS=1
000BC534>  CSMgrTask:e02b7489:18:16: strength 1111 current 3 mode 2
000BCE15>  CSMgrTask:e02b7649:18:16: Name: 58BGO Size: 30543(3ba7800)
000BCE40>  CSMgrTask:e02b710d:18:03: pBlkDev=0x86b95c
000BCE5A>  CSMgrTask:e02b7121:18:03: nBlocks=62552064, blksPerTrack=0, nHeads=0
000BD182>  CSMgrTask:e02b69e7:16:05: fsuGetPart: Block(2, 62552062, 62552064)
000BE20B>  CSMgrTask:e025aa4b:16:16: efat_map_filesys 2 B: 1
000BE68F>  CSMgrTask:e04bc1e7:15:03: @CSMgrTask FIO_GetSupportedDriveInfo(0x22eca8) L:1102
000BE6EE>  CSMgrTask:e025b351:16:16: AllocateMemoryStrictly For Speed Class!!!
000F411F>       dump:001b6b09:00:0f: Logging finished.
000F413C>       dump:001b6b17:00:0f: Free memory: 4168940 bytes.





Now it worked:

(https://thumb.ibb.co/gZwDUp/IMG_3622.jpg) (https://ibb.co/gZwDUp)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on September 08, 2018, 12:21:00 PM
Nice.

The next step is to enable the boot flag (it will toggle a flag in the ROM so the firmware will load and execute code from the SD card). That appears to be a diagnostic feature in Canon's bootloader, present since DIGIC 2 or maybe earlier. It's the first time we are trying this procedure on DIGIC 7; the same code was tested on 5DS first, then on 80D, 750D, 760D, and 7D2 without surprises.

Very old versions of the boot flag enabling code caused some issues in the past (years ago): when they were run from LiveView, the "erase" step of the ROM flashing procedure succeeded, but the "write" step failed; as a result, the entire boot flag area (http://magiclantern.wikia.com/wiki/Bootflags) was set to FFFFFFFF. Luckily, this was still a valid configuration with a ML card inserted, but the camera refused to boot plain Canon firmware and asked for a firmware update. Placing Canon's firmware update on the card fixed the issue.

Now we are running this code directly from bootloader. Source code is on the recovery (https://bitbucket.org/hudson/magic-lantern/branch/recovery) branch (i.e. bootloader experiments, with portable code that runs on all EOS cameras from DIGIC 2 to DIGIC 8 ), compiled from platform/portable.000 with CONFIG_BOOT_BOOTFLAG = y. You may review this code by running it in QEMU if you prefer.

If you (or anyone else) are OK with the risks, just send me a PM and I'll give you the FIR file.

In the emulator, if you run with firmware="boot=1", this option enables the boot flag, so you can see what exactly the firmware does differently. It will check the card contents at every startup, so there might be a small delay after this change. Other than that, with a regular (non-bootable) card is inserted, the camera will run plain Canon firmware.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: edoardoc on September 08, 2018, 01:29:34 PM
In the emulator ( " ./run_canon_fw.sh 60D,firmware="boot=1" " ) I got this:

(https://thumb.ibb.co/fiZZkU/Screen_Shot_2018_09_08_at_13_24_30.png) (https://ibb.co/fiZZkU)

Is it ok?

Before compiling ML ( " make -C ../magic-lantern 60D_install_qemu " )  I got the same screen of ML Rescue that I got directly from my camera.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on September 08, 2018, 04:42:22 PM
The emulation doesn't go very far; it doesn't show the GUI yet. It covers the bootloader, SD card I/O and roughly half of the startup process. At some point it times out waiting for the second CPU, as the communication between them is not well understood.

To try the boot flag enabler:

cd magic-lantern
hg up recovery -C
cd platform/portable.000
make clean && make install_qemu ML_MODULES= CONFIG_BOOT_BOOTFLAG=y # optionally CONFIG_QEMU=y for more debugging info
( cd ../../../qemu-eos && ./run_canon_fw.sh 200D,firmware="boot=1" )


In this simulation, the boot flag would be already enabled, so the above won't show anything interesting (Canon code will attempt to flash the ROM only if the flag is actually changed). You could try to disable the boot flag instead (like this (https://www.magiclantern.fm/forum/index.php?topic=17360.msg204747#msg204747)), as the emulation runs with boot flag enabled. In this case, you will see some low-level activity and the emulator will lock up. That's OK. It will print the address of the function it's going to call from Canon's bootloader, and you can look it up in the disassembly to confirm it's indeed the right one and has the correct syntax ( I already did that, but you should probably not trust me blindly :D ).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: edoardoc on September 08, 2018, 08:03:46 PM
Which file should I edit to make this changes (https://www.magiclantern.fm/forum/index.php?topic=17360.msg204747#msg204747)?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on September 08, 2018, 09:48:32 PM
First two lines from the patch are telling you the file name:

--- a/src/reboot.c
+++ b/src/reboot.c


You should also be on the "recovery" branch.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: edoardoc on September 09, 2018, 12:33:13 PM
Thanks.

I disabled the boot flag from reboot.c and I ran the emulation with firmware="boot=1" , here's the result:

(https://thumb.ibb.co/kuZgZp/Screen_Shot_2018_09_09_at_11_56_16.png) (https://ibb.co/kuZgZp)


Reading reboot.c I noticed that ( line 842 ) :
/* DIGIC 7: the main ROM is at 0xE0000000 and there is another one at 0xF0000000, so it should be OK */

from my screenshot:
ROMBASEADDR: 0xE0040000

Why my ROM starts after the addr in the previous comment?

And... what's the next step? Loading the FIR with the bootflag enabled from a real camera?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on September 09, 2018, 04:33:13 PM
0xE0000000 is the start address of the first ROM chip (we call it ROM0).

0xE0040000 is the address of Canon's main firmware. Below that address, you can find Canon's bootloader (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default#rst-header-overview-of-canon-eos-boot-process); they are both in the same physical ROM chip.

Yes, the next step is running the FIR on real hardware and praying things won't go wrong.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: edoardoc on September 09, 2018, 11:44:19 PM
Quote from: a1ex on September 08, 2018, 12:21:00 PM
Very old versions of the boot flag enabling code caused some issues in the past (years ago): when they were run from LiveView, the "erase" step of the ROM flashing procedure succeeded, but the "write" step failed; as a result, the entire boot flag area (http://magiclantern.wikia.com/wiki/Bootflags) was set to FFFFFFFF. Luckily, this was still a valid configuration with a ML card inserted, but the camera refused to boot plain Canon firmware and asked for a firmware update. Placing Canon's firmware update on the card fixed the issue.

Sorry for the questions but I just want to make sure what I'm doing.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on September 09, 2018, 11:54:09 PM
That's the only surprise we had so far with this procedure, but anecdote != data. Anything can happen.

Expected outcome - see e.g. for 80D (https://www.magiclantern.fm/forum/index.php?topic=17360.msg189646#msg189646).

If you copy both FIR files, Canon's bootloader will just pick one. So, you should copy only one FIR.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: edoardoc on September 11, 2018, 03:07:49 PM
Loading the FIR that enable the bootflag will avoid the warranty?

Can I reset the bootflag in the future?




Inviato dal mio iPhone utilizzando Tapatalk
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: ids1024 on September 16, 2018, 04:29:25 PM
Quote from: edoardoc on September 11, 2018, 03:07:49 PM
Loading the FIR that enable the bootflag will avoid the warranty?

There is an FAQ entry for that: https://wiki.magiclantern.fm/faq#does_it_void_my_warranty

Quote from: edoardoc on September 11, 2018, 03:07:49 PM
Can I reset the bootflag in the future?

Yes.

Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Dennis_K on September 30, 2018, 02:24:06 PM
I own a 77D and I would love to help the development. Is there anything I can do? Unfortunately, I have zero expereience with coding.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on October 01, 2018, 09:07:12 PM
I'm trying to find stubs for 77D, using 200D as a reference.

This is what I have at the moment:

/** Startup **/
NSTUB( ROMBASEADDR, firmware_entry )
NSTUB(0xE00400EC,  cstart)                 /* calls bzero32 and create_init_task(..., init_task, ...) */
NSTUB(0xDF00D285,  bzero32)                /* zeros out a data structure. From sub_E0428334
      LDR             PC, =(loc_DF00D284+1) */

NSTUB(0xDF006515,  create_init_task)       /* low-level DryOS initialization. From sub_E0427890
      LDR             PC, =(sub_DF006514+1) */
NSTUB(0xE0040215,  init_task)              /* USER_MEM size checking, dmSetup, termDriverInit, stdlibSetup etc */
NSTUB(0xe065e278,  dcache_clean)           /* loop with MCR p15 c7,c10,1; DSB */
NSTUB(0xe065e34c,  icache_invalidate)      /* loop with MCR p15 c7,c5,1; c7,c1,6; c7,c1,0; ISB */

/** Tasks **/
NSTUB(0xDF008F7E,  task_create)            /* used to start TaskMain, GuiMainTask etc */
NSTUB(0xDF0087FE,  msleep)                 /* argument is always multiple of 10 */
//NSTUB(    0x????,  current_task)           /* from task_create; pointer to the current task structure */
//NSTUB(    0x????,  current_interrupt)      /* from interrupt handler (VBAR + 0x18); where the interrupt ID is stored */

/** Dumper **/
NSTUB(0xe007fc46,  dump_file)              /* tries to save a file to either "A:/%s" or "B:/%s"; calls FIO_RemoveFile/CreateFile/WriteFile/CloseFile/Flush */

/** Memory info **/
NSTUB(0xe02640b4,  malloc_info)            /* Malloc Information */
NSTUB(0xe026414c,  sysmem_info)            /* System Memory Information */
NSTUB(0xe01eaf80,  memmap_info)            /* Exception vector, DRYOS system memory etc */
NSTUB(0xe0164ca6,  smemShowFix)            /* Common Lower, Common Upper etc */

/** Memory allocation **/
NSTUB(0xDF0079D3,  GetMemoryInformation)   /* called from AllocateMemory */

/** Debug messages **/
NSTUB(0xDF006E6D,  DryosDebugMsg)          /* lots of debug messages; format string is third argument */

/** Eventprocs (call by name) **/
NSTUB(0xe04d8aee,  call)                   /* many functions called by name (lv_start, lv_stop etc) */

/** GUI timers **/
NSTUB(0xe04d499a,  CancelTimer)            /* from error message */
NSTUB(0xe05aad76,  SetHPTimerAfterNow)     /* from error message */
NSTUB(0xe05aadca,  SetHPTimerNextTick)     /* same "worker" function as SetHPTimerAfterNow */
NSTUB(0xe04d48e4,  SetTimerAfter)          /* from error message */

/** Interrupts **/
//NSTUB(    0x????,  pre_isr_hook)
//NSTUB(    0x????,  post_isr_hook)
//NSTUB(   0x?????,  isr_table_handler)
//NSTUB(   0x?????,  isr_table_param)

/** MPU communication **/
NSTUB(0xE01E781F,  mpu_send)                  // "dwSize < TXBD_DATA_SIZE"
NSTUB(0xE058866B,  mpu_recv)                  // passed as last argument by InitializeIntercom and eventually stored into mpu_recv_cbr
NSTUB(    0x7CF4,  mpu_recv_cbr)              // mpu_recv is called indirectly through this function pointer
NSTUB(   0x887D4,  mpu_send_ring_buffer)      // ring buffer used in mpu_send
NSTUB(    0x7CD8,  mpu_send_ring_buffer_tail) // ring buffer index incremented in mpu_send
NSTUB(   0x88694,  mpu_recv_ring_buffer)      // ring buffer used in SIO3_ISR, subroutine that processes two chars at a time
NSTUB(    0x7CD0,  mpu_recv_ring_buffer_tail) // ring buffer index incremented in the above subroutine

/** Misc **/
NSTUB(0xe11f93d4,  vsnprintf)              /* called near dmstart; references "01234567", "0123456789", "0123456789abcdef" and "0123456789ABCDEF"; second arg is size; the one called by DebugMsg only knows %s */

Still missing a couple of references to data structures.
After figuring out it should be able to run the same minimal code as current state of 200D.

If someone want to double check and find the remaining stubs, please write down here your finding.

EDIT: More address found. Still missing last isr related stubs

NSTUB(    0x1020,  current_task)           /* from task_create; pointer to the current task structure */
NSTUB(    0x1008,  current_interrupt)      /* from interrupt handler (VBAR + 0x18); where the interrupt ID is stored */

/** Interrupts **/
//NSTUB(    0x????,  pre_isr_hook)
//NSTUB(    0x????,  post_isr_hook)
NSTUB(   0x6D0C0,  isr_table_handler)
//NSTUB(   0x?????,  isr_table_param)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on October 07, 2018, 11:23:29 AM
does ML even work for 200D?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Mikerofilm on October 07, 2018, 04:45:00 PM
Through rom dumpers are we able to expand the range of the video codec on the 6d mk2?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on October 07, 2018, 06:33:32 PM
Misconception: ROM dumpers read ROM data from cam. That's a very basic step in ML development. Don't hold your breath waiting for ML files loaded from card and ML code running in the cam. Devs just taking the very first steps in a very, very long journey.

Don't know what you expect in "codec range expanding" but you may take a look into what ML enabled cams are actually able to do. You may be disappointed, though.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on October 10, 2018, 06:23:52 PM
What if i want to run some simple code on my 200D? Like a simple calculation and store it in the RAM or some accessible space. What can i do too access the full CPU instructions in assembler? I am not looking for fancy Screen gui's and touch or anything above those categories.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on October 10, 2018, 07:23:07 PM
You can already do that in the emulator - see e.g. reply #83. For example, a simple intervalometer coded in C would be very easy to write.

After enabling the boot flag, you will be able to do the same on real hardware. Proof of concept code was already tested and confirmed to work. I'm looking for a volunteer willing to be the first one who enables the boot flag on DIGIC 7 (see previous page); nobody took the risk yet. The FIR file for enabling the boot flag for 200D is ready, just drop me a PM if (or when) you are prepared to run it.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on October 11, 2018, 09:24:06 AM
I'm ready
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: juarez13 on October 29, 2018, 11:11:35 PM
I didnt undertand how to install the magic lantern on 77d, someone can help?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Jonn3y on October 30, 2018, 06:18:09 PM
Quote from: juarez13 on October 29, 2018, 11:11:35 PM
I didnt undertand how to install the magic lantern on 77d, someone can help?

There is no tested and working ML for 77D yet :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on November 02, 2018, 03:43:50 PM
Hi,

I've dumped the ROMs of my 77D and created a build environment that brings me up to this point:


(https://thumb.ibb.co/k2Qv00/Virtual-Box-Magic-Lantern-Build-Environment-02-11-2018-15-08-34.png) (https://ibb.co/k2Qv00)


I also did the test with changing reboot.c to disable the boot flag. Is the output of this still relevant for anybody?

I have a few questions now:
- I unterstand the next step is to collect the stubs. Is there already a more complete list than aprofiti posted on October 1st?
- Has anybody already done the steps described here? https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default#rst-header-adding-support-for-a-new-camera-model
- In branch "digic6-dumper" I see directory "platform/77D.100". Shouldn't this be "77D.102" since the current firmware version is 1.0.2?
- Is there a repository where people work together on porting to the 77D?

Thanks you so far for the good documentation. I hope I can help to get some steps further to a working port of ML for the 77D.

Cheers,
Christian.

PS: If you are interested on how I created my environment have a look at https://github.com/calle2010/magic-lantern-77d-vagrant. I use Vagrant and VirtualBox hosted on MacOs.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on November 02, 2018, 07:38:20 PM
Quote from: calle2010 on November 02, 2018, 03:43:50 PM
PS: If you are interested on how I created my environment have a look at https://github.com/calle2010/magic-lantern-77d-vagrant. I use Vagrant and VirtualBox hosted on MacOs.

Very nice! Not familiar with vagrant, but if it makes easier to setup a build environment, it might be an interesting option.

I've tried Docker some time ago, but the experience wasn't straightforward. I couldn't install it on my main machine (OpenSUSE Tumbleweed), so I had to try it in a virtual machine.

Moving qemu.monitor into /tmp sounds interesting.

Quote
- I unterstand the next step is to collect the stubs. Is there already a more complete list than aprofiti posted on October 1st?

That's the most complete one. I didn't double-check them yet, only noticed the Thumb bit was not set in most of the stubs (and it should be; refer to 200D for details).

Quote
- Has anybody already done the steps described here? https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default#rst-header-adding-support-for-a-new-camera-model

Emulation is at the same level as 200D and all other DIGIC 7 ports. It gets stuck as soon as the two cores expect to talk to each other.

I hope this experiment (https://bitbucket.org/hudson/magic-lantern/pull-requests/900/mmio-tracing-backend-insanely-powerful) is going to capture the info needed to understand these interactions, but it has to be adapted to the ARMv7 architecture. The two cores are talking via MMIO registers, interrupts, and they both access the same memory (flat mapping, except for a private 4K page for each core, just like EOS M5).

Quote
- In branch "digic6-dumper" I see directory "platform/77D.100". Shouldn't this be "77D.102" since the current firmware version is 1.0.2?

That's right. Initial experiments on 77D were done before Canon published a firmware update.

Quote
- Is there a repository where people work together on porting to the 77D?

The digic6-dumper branch currently covers the DIGIC 6 and newer models, so... that's pretty much it. RE notes and other findings are shared on the forum.

Some bootloader experiments can be found in the "recovery" branch. That's portable code, running on all models since DIGIC 2.

BTW, we could successfully enable the boot flag on 200D; will post the FIR files soon.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on November 03, 2018, 12:22:29 PM
Quote from: a1ex on November 02, 2018, 07:38:20 PM
Very nice! Not familiar with vagrant, but if it makes easier to setup a build environment, it might be an interesting option.

I do only my first steps with Vagrant. I want to automate all the manual steps and setting up the build environment on my MacOS created too much clutter for my taste.

Quote from: a1ex on November 02, 2018, 07:38:20 PMMoving qemu.monitor into /tmp sounds interesting.

This was just the first place that came to my mind. The working directory in this setup is on the VirtualBox filesystem mounted with nodev, so creation of the socket fails with "no permission" error message.

Quote from: a1ex on November 02, 2018, 07:38:20 PM
I didn't double-check them yet, only noticed the Thumb bit was not set in most of the stubs (and it should be; refer to 200D for details).

I will check the 200D code and see if I can find the same stubs for 77D. My assembler experience is very limited, though. Also I do not yet quite understand how to test the stubs without the GUI emulation.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on November 04, 2018, 09:09:10 AM
Quote from: calle2010 on November 03, 2018, 12:22:29 PM
Also I do not yet quite understand how to test the stubs without the GUI emulation.

The emulation goes far enough to start a couple of Canon tasks; it even initializes the virtual SD card and is able to save logs. That's pretty much what can be tested at this stage.

Canon firmware even creates a DCIM directory when started from an empty card. From QEMU test results (https://builds.magiclantern.fm/jenkins/job/QEMU-tests/lastSuccessfulBuild/consoleFull):

Testing file I/O (DCIM directory)...
     [...]
    77D: OK
   200D: OK
    6D2: OK
   800D: OK


Once the startup process works, you'll be able to get logs directly from the camera and start experimenting.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: tekrevz on December 03, 2018, 08:24:27 PM
i have a 6D mark 2 how can I help out??
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on January 08, 2019, 10:58:30 PM
M50 moved over here (https://www.magiclantern.fm/forum/index.php?topic=23296.0), alongside with other DIGIC 8 PowerShots.

Short recap for DIGIC 7:
- source code: digic6-dumper (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper) branch ( actually covering DIGIC 6, 7 and 8 )
- bootloader experiments: recovery (https://bitbucket.org/hudson/magic-lantern/branch/recovery) branch ( portable code, running on DIGIC 2...8 )
- emulation: qemu (https://bitbucket.org/hudson/magic-lantern/branch/qemu) branch (README.rst (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst), HACKING.rst (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst), no GUI yet, but file I/O is working)
- CPU info (https://www.magiclantern.fm/forum/index.php?topic=19737.msg200737#msg200737) (Cortex A9 dual core), MMU configuration (https://chdk.setepontos.com/index.php?topic=13014.msg131205#msg131205) (mostly flat mapping), ROM layout (https://www.magiclantern.fm/forum/index.php?topic=6785.msg187436#msg187436) (32MB at 0xE0000000, 16MB at 0xF0000000)
- see also Initial firmware analysis (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default#rst-header-initial-firmware-analysis) in QEMU docs
- 200D: proof of concept code available; I'm ready to enable the boot flag, too. Or, to capture DNGs from LiveView or other simple tasks.
- 800D, 77D, 6D2: find a couple of stubs (tutorial (https://www.magiclantern.fm/forum/index.php?topic=12177.0)) to run the 200D PoC. Once you do that, I'm ready to enable the boot flag on these models, too.
- image sensor on all these models appears to run at 27 MHz x 12 channels (hypothesis (https://www.magiclantern.fm/forum/index.php?topic=23040.msg208479#msg208479)), i.e. fast enough for 4K video.
- I have no plans to get any of these cameras; it's up to the user community to push the development further.

Have fun!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: DeafEyeJedi on January 09, 2019, 03:21:15 AM
Sounds fabulous in regards to these updates. Thanks for reporting them @a1ex and definitely feels encouraging!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on January 14, 2019, 07:29:58 AM
Quote from: a1ex on January 08, 2019, 10:58:30 PM
M50 moved over here (https://www.magiclantern.fm/forum/index.php?topic=23296.0), alongside with other DIGIC 8 PowerShots.

Short recap for DIGIC 7:
- source code: digic6-dumper (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper) branch ( actually covering DIGIC 6, 7 and 8 )
- bootloader experiments: recovery (https://bitbucket.org/hudson/magic-lantern/branch/recovery) branch ( portable code, running on DIGIC 2...8 )
- emulation: qemu (https://bitbucket.org/hudson/magic-lantern/branch/qemu) branch (README.rst (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst), HACKING.rst (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst), no GUI yet, but file I/O is working)
- CPU info (https://www.magiclantern.fm/forum/index.php?topic=19737.msg200737#msg200737) (Cortex A9 dual core), MMU configuration (https://chdk.setepontos.com/index.php?topic=13014.msg131205#msg131205) (mostly flat mapping), ROM layout (https://www.magiclantern.fm/forum/index.php?topic=6785.msg187436#msg187436) (32MB at 0xE0000000, 16MB at 0xF0000000)
- see also Initial firmware analysis (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default#rst-header-initial-firmware-analysis) in QEMU docs
- 200D: proof of concept code available; I'm ready to enable the boot flag, too. Or, to capture DNGs from LiveView or other simple tasks.
- 800D, 77D, 6D2: find a couple of stubs (tutorial (https://www.magiclantern.fm/forum/index.php?topic=12177.0)) to run the 200D PoC. Once you do that, I'm ready to enable the boot flag on these models, too.
- image sensor on all these models appears to run at 27 MHz x 12 channels (hypothesis (https://www.magiclantern.fm/forum/index.php?topic=23040.msg208479#msg208479)), i.e. fast enough for 4K video.
- I have no plans to get any of these cameras; it's up to the user community to push the development further.

Have fun!
What is the main reason for limited support for the dual core camera's anyways?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Sayfog on January 15, 2019, 05:38:28 AM
Where is the 200D proof of concept code stored? I've got one and want to help develop, I've also got an oscilloscope if stuff needs probing to help out development.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on January 16, 2019, 10:24:08 PM
Quote from: jack001214 on January 14, 2019, 07:29:58 AM
What is the main reason for limited support for the dual core camera's anyways?

For DIGIC 7/8:
- There's very little reason for ML to run on both cores, on these models. They both can access nearly the entire memory space (except for a small private page).
- This does not apply to earlier dual core models. On 7D, ML running only on a single core means reduced functionality (or much harder to implement certain features).
- Emulation-wise, it's important, but one has to understand the low-level interfaces between the two cores. Likely doable with io_trace (https://bitbucket.org/hudson/magic-lantern/pull-requests/900/mmio-tracing-backend-insanely-powerful) (after updating it to run on the newer CPUs).

Quote from: Sayfog on January 15, 2019, 05:38:28 AM
Where is the 200D proof of concept code stored? I've got one and want to help develop, I've also got an oscilloscope if stuff needs probing to help out development.

We've been in touch on IRC. Short summary, for those who didn't follow the conversation:

Where to find stuff: see my recap post above.

Electronics probing: I see very little need for this in order to port ML. I'm pretty sure such low-level investigation is going to reveal very (https://www.magiclantern.fm/forum/index.php?topic=22030) interesting (https://twitter.com/autoexec_bin/status/1067557639134068742) stuff (https://twitter.com/autoexec_bin/status/1080138121432522752) about (https://twitter.com/autoexec_bin/status/1083273099045494784) camera (https://twitter.com/marcan42/status/1046781328148979712) internals (https://www.magiclantern.fm/forum/index.php?topic=21728.msg207376#msg207376), but first we need to get the basics working (i.e. bringing up the ML menu). I won't refuse a few high-res (https://twitter.com/autoexec_bin/status/1014766030714032130) pictures (https://www.magiclantern.fm/forum/index.php?topic=3443.msg17204#msg17204) of the circuit boards, though :D

In other words, an important task is figuring out how to print things on the screen (i.e. a software-only task). Then, there comes the easy stuff - identifying button codes, adapting the display routines for the new image format (likely this (https://www.magiclantern.fm/forum/index.php?topic=17360.msg196110;topicseen#msg196110)), figuring out ARM-Thumb calling quirks, enabling and testing ML features...




CPU info from 200D (same as 6D2 (https://www.magiclantern.fm/forum/index.php?topic=19737.msg200737#msg200737)):


CHDK CPU info for 0x417 200D
------------------------------
ID         0x414FC091
  Revision             0x1 1
  Part                 0xC09 3081
  ARM Arch             0xF 15
  Variant              0x4 4
  Implementor          0x41 65
Cache type 0x83338003
  Icache min words/line 0x3 3 [8]
  (zero)               0x0 0
  L1 Icache policy     0x2 2
  Dcache min words/line 0x3 3 [8]
  Exclusives Reservation Granule 0x3 3 [8]
  Cache Writeback Granule 0x3 3 [8]
  (zero)               0x0 0
  (register format)    0x4 4
TCM type   0x00000000
  (raw value)          0x0 0
MPU type   0x414FC091
  S                    0x1 1
  -                    0x48 72
  Num of MPU regions   0xC0 192
Multiprocessor ID 0x80000000
  (raw value)          0x80000000 -2147483648
Processor feature 0 0x00001231
  ARM inst set         0x1 1
  Thumb inst set       0x3 3
  Jazelle inst set     0x2 2
  ThumbEE inst set     0x1 1
  -                    0x0 0
Processor feature 1 0x00000011
  Programmers' model   0x1 1
  Security extensions  0x1 1
  Microcontr. prog model 0x0 0
  -                    0x0 0
Debug feature 0x00010444
  (raw value)          0x10444 66628
Aux feature 0x00000000
  (raw value)          0x0 0
Mem model feature 0 0x00100103
  VMSA support         0x3 3
  PMSA support         0x0 0
  Cache coherence      0x1 1
  Outer shareable      0x0 0
  TCM support          0x0 0
  Auxiliary registers  0x1 1
  FCSE support         0x0 0
  -                    0x0 0
Mem model feature 1 0x20000000
  L1 Harvard cache VA  0x0 0
  L1 unified cache VA  0x0 0
  L1 Harvard cache s/w 0x0 0
  L1 unified cache s/w 0x0 0
  L1 Harvard cache     0x0 0
  L1 unified cache     0x0 0
  L1 cache test & clean 0x0 0
  Branch predictor     0x2 2
Mem model feature 2 0x01230000
  L1 Harvard fg prefetch 0x0 0
  L1 Harvard bg prefetch 0x0 0
  L1 Harvard range     0x0 0
  Harvard TLB          0x0 0
  Unified TLB          0x3 3
  Mem barrier          0x2 2
  WFI stall            0x1 1
  HW access flag       0x0 0
Mem model feature 3 0x00102111
  Cache maintain MVA   0x1 1
  Cache maintain s/w   0x1 1
  BP maintain          0x1 1
  -                    0x102 258
  Supersection support 0x0 0
ISA feature 0 0x00101111
  Swap instrs          0x1 1
  Bitcount instrs      0x1 1
  Bitfield instrs      0x1 1
  CmpBranch instrs     0x1 1
  Coproc instrs        0x0 0
  Debug instrs         0x1 1
  Divide instrs        0x0 0
  -                    0x0 0
ISA feature 1 0x13112111
  Endian instrs        0x1 1
  Exception instrs     0x1 1
  Exception AR instrs  0x1 1
  Extend instrs        0x2 2
  IfThen instrs        0x1 1
  Immediate instrs     0x1 1
  Interwork instrs     0x3 3
  Jazelle instrs       0x1 1
ISA feature 2 0x21232041
  LoadStore instrs     0x1 1
  Memhint instrs       0x4 4
  MultiAccess Interruptible instructions 0x0 0
  Mult instrs          0x2 2
  MultS instrs         0x3 3
  MultU instrs         0x2 2
  PSR AR instrs        0x1 1
  Reversal instrs      0x2 2
ISA feature 3 0x11112131
  Saturate instrs      0x1 1
  SIMD instrs          0x3 3
  SVC instrs           0x1 1
  SynchPrim instrs     0x2 2
  TabBranch instrs     0x1 1
  ThumbCopy instrs     0x1 1
  TrueNOP instrs       0x1 1
  T2 Exec Env instrs   0x1 1
ISA feature 4 0x00011142
  Unprivileged instrs  0x2 2
  WithShifts instrs    0x4 4
  Writeback instrs     0x1 1
  SMC instrs           0x1 1
  Barrier instrs       0x1 1
  SynchPrim_instrs_frac 0x0 0
  PSR_M instrs         0x0 0
  -                    0x0 0
ISA feature 5 0x00000000
  -                    0x0 0
Cache level ID 0x09200003
  Cache type, level1   0x3 3 [Separate Icache, Dcache]
  Cache type, level2   0x0 0 [no cache]
  Cache type, level3   0x0 0 [no cache]
  Cache type, level4   0x0 0 [no cache]
  Cache type, level5   0x0 0 [no cache]
  Cache type, level6   0x0 0 [no cache]
  Cache type, level7   0x0 0 [no cache]
  Cache type, level8   0x1 1 [Icache only]
  Level of coherency   0x1 1
  Level of unification 0x1 1
  (zero)               0x0 0
Cache size ID reg (data, level0) 0x700FE019
  Line size in words   0x1 1 [8]
  Associativity        0x3 3 [4]
  Number of sets       0x7F 127 [128]
  Write allocation     0x1 1
  Read allocation      0x1 1
  Write back           0x1 1
  Write through        0x0 0
Cache size ID reg (inst, level0) 0x200FE019
  Line size in words   0x1 1 [8]
  Associativity        0x3 3 [4]
  Number of sets       0x7F 127 [128]
  Write allocation     0x0 0
  Read allocation      0x1 1
  Write back           0x0 0
  Write through        0x0 0
SCTLR      0x48C5187D
  MPU Enable           0x1 1
  Strict Align         0x0 0
  L1 DCache Enable     0x1 1
  - (SBO)              0xF 15
  - (SBZ)              0x0 0
  Branch Pred Enable   0x1 1
  L1 ICache Enable     0x1 1
  High Vectors         0x0 0
  Round Robin          0x0 0
  - (SBZ)              0x0 0
  - (SBO)              0x1 1
  MPU background reg   0x0 0
  - (SBO)              0x1 1
  Div0 exception       0x0 0
  - (SBZ)              0x0 0
  FIQ Enable           0x0 0
  - (SBO)              0x3 3
  VIC                  0x0 0
  CPSR E bit           0x0 0
  - (SBZ)              0x0 0
  NMFI                 0x1 1
  TRE                  0x0 0
  AFE                  0x0 0
  Thumb exceptions     0x1 1
  Big endian           0x0 0
ACTLR      0x00000045
  (raw value)          0x45 69
ACTLR2     0x00000201
  (raw value)          0x201 513
CPACR      0xC0000000
  (raw value)          0xC0000000 -1073741824
DBGDIDR    0x35137041
  Revision             0x1 1
  Variant              0x4 4
  - (RAZ)              0x70 112
  Version              0x3 3 [v7 full]
  Context              0x1 1 [2]
  BRP                  0x5 5 [6]
  WRP                  0x3 3 [4]
DBGDRAR    0x00000000
  Valid                0x0 0
  - (UNK)              0x0 0
  Address              0x0 0 [0x00000000]
DBGDSAR    0x00030000
  Valid                0x0 0
  - (UNK)              0x0 0
  Address              0x30 48 [0x00030000]
DBGDSCR    0x03000002
  HALTED               0x0 0
  RESTARTED            0x1 1
  MOE                  0x0 0
  SDABORT_l            0x0 0
  ADABORT_l            0x0 0
  UND_l                0x0 0
  FS                   0x0 0
  DBGack               0x0 0
  INTdis               0x0 0
  UDCCdis              0x0 0
  ITRen                0x0 0
  HDBGen               0x0 0
  MDBGen               0x0 0
  SPIDdis              0x0 0
  SPNIDdis             0x0 0
  NS                   0x0 0
  ADAdiscard           0x0 0
  ExtDCCmode           0x0 0
  - (SBZ)              0x0 0
  InstrCompl_l         0x1 1
  PipeAdv              0x1 1
  TXfull_l             0x0 0
  RXfull_l             0x0 0
  - (SBZ)              0x0 0
  TXfull               0x0 0
  RXfull               0x0 0
  - (SBZ)              0x0 0





Updated ROM dumpers to the latest codebase (no more restrictions on card/filesystem size, it just has to be FAT12/16/32):
Quote from: a1ex on January 16, 2019, 09:06:18 AM
DIGIC 7:  200D (https://a1ex.magiclantern.fm/debug/portable-rom-dumper/new/DUMP200D.FIR)  6D2 (https://a1ex.magiclantern.fm/debug/portable-rom-dumper/new/DUMP_6D2.FIR)  77D (https://a1ex.magiclantern.fm/debug/portable-rom-dumper/new/DUMP_77D.FIR)  800D (https://a1ex.magiclantern.fm/debug/portable-rom-dumper/new/DUMP800D.FIR)

And CPUINFO with log file support (same output expected on all models, but...):
Quote from: a1ex on January 16, 2019, 09:19:19 AM
DIGIC 7:  200D (https://a1ex.magiclantern.fm/debug/portable-cpuinfo/CPUI200D.FIR)  6D2 (https://a1ex.magiclantern.fm/debug/portable-cpuinfo/CPUI_6D2.FIR)  77D (https://a1ex.magiclantern.fm/debug/portable-cpuinfo/CPUI_77D.FIR)  800D (https://a1ex.magiclantern.fm/debug/portable-cpuinfo/CPUI800D.FIR)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on January 17, 2019, 06:07:44 AM
Quotefiguring out how to print things on the screen (i.e. a software-only task)
How were able to achieve that with the ROM dumpers?


Quote- 200D: proof of concept code available;
Is it from the digic6-dumper branch? The same one which you gave me few months back?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Sayfog on January 18, 2019, 12:18:54 PM
Quote from: jack001214 on January 17, 2019, 06:07:44 AM
How were able to achieve that with the ROM dumpers?

Just going to repeat what A1ex said on IRC the other night, that ROM Dumper screen control is done from the bootloader, not the Canon formware. I've only just got my machine setup with Radare2 and a bunch of other tools but could we trace through the memory locations accessed by the rom dumper for the screen into the Canon FW? Unless its currently hanging on some other check and GUI will just fall out when that's figured out.

Edit: word of warning, WSL works great for the development environment, all the tools - not so much.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on January 20, 2019, 11:29:30 AM
I recompiled the digic6 branch and dumped the autoexec.bin on my 200D.
What exactly is the OSD Vram? (On Screen Display?)


These two instructions are being executed together at every 'update'.
002FD1BA>    CtrlSrv:e04a0783:04:03: DISP_SetUpdateOSDVram(0x4169ea00)(0)
002FD2E2>    CtrlSrv:e04afd6f:04:03: refresh x=728 y=442 w=84 h=60


How can i poke this function? i mean what would be minimalist code required to poke a function
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: arvakur on February 06, 2019, 02:53:13 AM
Hi there people, hope you all are doing grate, guys I have lots of questions, I have a T7i with firmware 1.0.1 and I tried to installed it and well, had no success but I want to know and learn more and to be instructed please people can you help me? I loved this ML because Im a cinematographer and worked it with a T5i...  and well I would love this ML to work on my T7I, but can you guys explain me what is all of this? what are the ROM DUMPERS? how does this work? what do they do?  have any of you make it work on a T7i? what do I need to do or to make it work on that camera model?

thanks
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on February 22, 2019, 11:27:02 AM
Quote from: jack001214 on January 20, 2019, 11:29:30 AM
What exactly is the OSD Vram? (On Screen Display?)

Found the answer in 80D logs (https://www.magiclantern.fm/forum/index.php?topic=17360.msg212411#msg212411). It's the bitmap overlay (i.e. Canon menus and other info displayed on top of the LiveView or playback image).

Quote
CtrlSrv:e04a0783:04:03: DISP_SetUpdateOSDVram(0x4169ea00)(0)

That address is a BMP buffer descriptor (its structure appears to match the one from 80D). If you can get a RAM dump, I can decode it and identify the image buffers.

Quote
How can i poke this function? i mean what would be minimalist code required to poke a function

These functions are in ROM, so... this minimalist code might require reprogramming of the MMU. I'll take care of this - it's one of these things that's doable, well covered in ARM manuals, but complex enough to make one's head spinning.

However, assuming the display hardware on DIGIC 7 is like 80D, printing things on the screen should be much easier. If lucky, all you need to print Hello World is to modify the contents of that bitmap buffer (which will have to be identified from a RAM dump, starting from the argument of DISP_SetUpdateOSDVram).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on February 25, 2019, 06:48:28 PM
QuoteIf lucky, all you need to print Hello World is to modify the contents of that bitmap buffer (which will have to be identified from a RAM dump, starting from the argument of DISP_SetUpdateOSDVram).
...
How would i get a RAM dump? if i cant invoke many location's then  how would i go about getting a RAM dump then?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on February 26, 2019, 11:06:39 AM
It's commented out in the source.

Memory map is the same as on M5; here's a slightly revised version, annotated like the one for EOS R (https://www.magiclantern.fm/forum/index.php?topic=22770.msg212090#msg212090):


00001000-00001FFF -> 00000000-00000FFF (-1000) O:NCACH I:WB,WA  P:RW       [ CPU0 only ]
00001000-00001FFF -> 00001000-00001FFF (   +0) O:NCACH I:WB,WA  P:RW       [ CPU1 only ]
00002000-3FFFFFFF -> 00002000-3FFFFFFF (   +0) O:NCACH I:WB,WA  P:RW       [ cacheable RAM - without private areas ]
40000000-BFFFFFFF -> 40000000-BFFFFFFF (   +0) O:NCACH I:NCACH  P:RW       [ uncacheable RAM; todo - what's above 80000000? ]
C0000000-C1FFFFFF -> C0000000-C1FFFFFF (   +0) Device           P:RW XN
C4000000-C4FFFFFF -> C4000000-C4FFFFFF (   +0) Device           P:RW XN
C8000000-CAFFFFFF -> C8000000-CAFFFFFF (   +0) Device           P:RW XN
D0000000-D0FFFFFF -> D0000000-D0FFFFFF (   +0) Device           P:RW XN
D2000000-D2FFFFFF -> D2000000-D2FFFFFF (   +0) Device           P:RW XN
D4000000-D5FFFFFF -> D4000000-D5FFFFFF (   +0) Device           P:RW XN
D8000000-D9FFFFFF -> D8000000-D9FFFFFF (   +0) Device           P:RW XN
DE000000-DEFFFFFF -> DE000000-DEFFFFFF (   +0) Device           P:RW XN
DF000000-DFFFFFFF -> DF000000-DFFFFFFF (   +0) O:NCACH I:WB,WA  P:RW       [ TCM? ]
E0000000-E7FFFFFF -> E0000000-E7FFFFFF (   +0) O:WB,WA I:WB,WA  P:R        [ main ROM ]
E8000000-EFFFFFFF -> E8000000-EFFFFFFF (   +0) Strongly-ordered P:R  XN    [ ? ]
F0000000-F7FFFFFF -> F0000000-F7FFFFFF (   +0) O:WB,WA I:WB,WA  P:R        [ serial flash? much slower than main ROM ]
F8000000-FFFFFFFF -> F8000000-FFFFFFFF (   +0) Strongly-ordered P:R  XN    [ ? ]


The entire RAM is visible as "uncacheable", i.e. from 0x40000000 to 0x7FFFFFFF. Most of that RAM (except for the two 4K pages private for each core) is visible as "cacheable" as well (i.e. after clearing 0x40000000).

There seems to be something above 0x80000000 as well (we've got some trouble on the EOS R while overwriting it by mistake, and found out the 200D is also using that area - it's shared memory for yet another secondary processor), so... let's also dump from 0x40000000 to 0xBFDFFFFF (or even until 0xBFEFFFFF / 0xBFFFFFFF if the hardware doesn't lock up).

RscMgr memory maps here (https://www.magiclantern.fm/forum/index.php?topic=5071.msg212085#msg212085). Surprise - the 800D has no less than 1 GiB of RAM! Compare to 256 MiB on the 700D :)




Yesterday, we made significant progress on IRC, with the help of @names_are_hard. Noticed the digic6-dumper codebase was no longer working on 200D; last time it was confirmed to work was in August 22, 2018 (changeset e21eec1/b2e0efa), so at least we had some reference "last known good" code.

Although @names_are_hard was not familiar with the ARM architecture, we managed to narrow down the issue after "only" 3 hours of pair debugging (as in "pair programming"): him on real hardware and me in QEMU. After all of that, we came up with two tiny changesets (who said the number of lines of code is a good metric?!): 2cd1b5f (https://bitbucket.org/hudson/magic-lantern/commits/2cd1b5f) and bcfa76b (https://bitbucket.org/hudson/magic-lantern/commits/bcfa76b): our DebugMsg, which was overwriting Canon's, and maybe also the interrupt hooks, were running on both CPU cores!

Even though we are running ML on the first core only, to avoid multitasking issues, we've got a problem: since both CPU cores on DIGIC 7/8 are sharing the entire memory (with very few exceptions), when overriding DebugMsg & co. by writing into (shared) RAM, our change took effect on both cores.

This kind of debugging would have been very hard to do with me sending precompiled binaries to a tester (he would have had to report back "it doesn't boot" a few dozen times). Did that on M50 - it took me (together with a tester who couldn't program, but otherwise tested my binaries really quickly) an entire week (https://www.magiclantern.fm/forum/index.php?topic=23296.msg209696#msg209696) for a similar issue.




Enabling the boot flag

The above means I'm now confident the current proof of concept code from the digic6-dumper branch is relatively safe to use on 200D (and other DIGIC 7 models after finding some stubs). That means, if you want to help and you are not afraid of the source code, you may now enable the boot flag on your 200D with:

BOOT200D.FIR (https://a1ex.magiclantern.fm/bleeding-edge/200D/BOOT200D.FIR) (confirmed by both @jack001214 and @names_are_hard).

This will modify your camera.

In theory, the FIR for enabling the boot flag should work on any firmware version. In practice, some cameras may refuse to downgrade (cough 5D3/5D4); should this happen, it's easy to fix.

However, the code from the digic6-dumper branch expects firmware 1.0.1, specifically 1.0.1 / 5.0.2 62(31) as printed by the Portable ROM dumper (https://www.magiclantern.fm/forum/index.php?topic=16534.0); otherwise, it simply won't boot. IIRC this is the latest firmware available from Canon at the time of writing, but we did not double-check this yet.

To disable the boot flag: see these notes (https://www.magiclantern.fm/forum/index.php?topic=17360.msg204717#msg204717).

Warranty

If it breaks, you get to keep both pieces. Sorry.




800D, 77D, 6D2

TBD after you, camera owners, will:
- find the missing stubs (tutorial) (http://www.magiclantern.fm/forum/index.php?topic=12177.0)
- verify them in QEMU (you *will* need it for debugging)
- are ready to run and debug the code on real hardware.




Next steps (200D)

- compile the digic6-dumper branch, changeset bcfa76b (confirmed to work on 200D)
- just committed some code attempting to log debug messages and interrupts from both cores (will it work? I have no idea)
- figure out how to print things on the screen (follow my earlier notes)
- find large chunks of memory that might be unused during boot, i.e. available for logging (CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP (https://www.magiclantern.fm/forum/index.php?topic=17360.msg211065#msg211065))
- get some huge logs with all Canon's debug messages, interrupts etc, fully covering the startup process
- port io_trace on DIGIC 7/8 and log all MMIO activity (doable, but not trivial)
- fix emulation, using the info from the above huge logs
- start porting ML (once you know how to print things on the screen, there's nothing else stopping you to do so).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on February 27, 2019, 09:55:30 AM
Awesome analysis and work through. I will try to find some stuff with my novice skills. Though you can always PM me to test some code  for the 200D.

Cheers!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on March 01, 2019, 05:21:19 PM
So I got bored (again).To counteract that I decided to compile the latest branch and run it on actual EOS200D(it works).
The logs that the program created got me to tinker some memory location on the camera.
The first address I tinkered was the supposed 'gain control' which was noted as DispDCtrl:e055f277:42:03: GAIN R:0x0eb G:0x0ec B:0x100
[0] 1.435252
in the log. I went ahead and set the contents of the area to '0x00'(random int) and surprisingly,the camera booted and the display was working perfectly(unexpected). Right after switching the camera to record, there were two separate 'boxes' created which had the live view shifted few places to one another and settled as soon as the camera was still.
I mean this was not useful too anyone but I was inspired. So yeah.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 02, 2019, 02:08:59 AM
Progress pic 8)

https://imgur.com/a/VUFcvou
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on March 02, 2019, 11:01:00 AM
Quote from: names_are_hard on March 02, 2019, 02:08:59 AM
Progress pic 8)

https://imgur.com/a/VUFcvou
Awesome! Send me the code(if you can)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: edoardoc on March 02, 2019, 02:18:50 PM
Quote from: names_are_hard on March 02, 2019, 02:08:59 AM
Progress pic 8)

https://imgur.com/a/VUFcvou
Amazing! Keep going! :o
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: brollnet on March 06, 2019, 04:47:13 AM
Hello all... I have a 77D and would love to see ML working on it. I'm not code savvy, but I'm willing to help if I can. Tell me what I can do to help...

kev
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on March 06, 2019, 07:43:22 AM
Code savvy is what is needed most now. Among the things you can do without: https://www.magiclantern.fm/forum/index.php?topic=23606 applies to 77D, too. Report back!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 06, 2019, 09:17:07 AM
I've already got a ROM dump from 77D; from the linked thread, I only need a confirmation whether the latest dumper is still working. I don't expect any surprises, as it was confirmed to work on all other D7 models.

For 77D, the next step is to check the stubs from aprofiti (https://www.magiclantern.fm/forum/index.php?topic=19737.msg206736#msg206736) and debug them in QEMU. Difficulty: easy. Expected outcome: current codebase (digic6-dumper branch) should save a log file on the virtual card.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: brollnet on March 08, 2019, 03:50:17 AM
Thanks... As soon as my 77D returns from the shop (focus calibration) I'll try the ROM.

Thanks for all the work you do!

kev
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on March 09, 2019, 01:08:25 PM
Tried to compile digic6-dumper for 77D using the partial Stubs.S, but failed when doing "make zip":

.. other failing modules...

Building module edmac...
Updated HGVERSION
[ README   ]   module_strings.h
[ CC       ]   edmac.o
[ CC       ]   edmac_util.o
[ CC       ]   edmac_test.o
[ CC       ]   md5.o
[ HGDIFF   ]   hgdiff.tmp
[ MODULE   ]   edmac.mo
[ STRIP    ]   edmac.mo
[ OBJCOPY  ]   edmac.mo
[ RM       ]   hgdiff.tmp
[ STRIP    ]   edmac.sym
[ STRIP    ]   edmac.sym
[ RM       ]   localsyms
[ EXPORTS  ]   edmac.sym
000018f0 edmac_format_size
[ DEPENDS  ]   edmac.dep
Not checked (compile ML for these cameras first):
    100D, 1100D, 200D, 500D, 50D, 550D, 5D2, 5D3.113, 5D3.123, 5D4, 5DS, 5DSR, 600D, 60D, 650D, 6D, 6D2, 700D, 760D, 77D, 7D, 7D2, 80D, EOSM, M50, R
make[5]: *** [edmac.dep] Error 1

********************************************************
WARNING: module edmac failed to build, deleting
********************************************************

[ RM       ] edmac.o edmac_util.o edmac_test.o md5.o edmac.mo edmac.sym edmac.dep edmac.zip module_strings.h hgdiff.tmp *.o *.d *.dep *.sym hgstamp
[ MKDIR    ]   ML directory structure...
cp ../modules/*/*.mo /Users/alex/Desktop/pullML/official/platform/77D.100/zip/ML/modules/
cp: ../modules/*/*.mo: No such file or directory
make[2]: *** [install] Error 1
make[1]: *** [CONFIG_MODULES_install] Error 2
make: *** [install] Error 2


Should I compile using minimal build or special commands?

Noticed I got the same for 200D... Already tried to reclone repo to get a fresh copy...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 09, 2019, 01:25:36 PM
It's not going to load any modules at this stage. The early code does not use any data files, other than autoexec.bin, so if plain "make" succeeds, that's pretty much it. For testing, I use:

make install_qemu ML_MODULES=


The "make zip" command expects some modules present; you could create an empty .mo file there to please it, or compile ML from a different camera to create some modules.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on March 09, 2019, 05:03:37 PM
First try using "make install_qemu ML_MODULES=" didn't work; so copied a compiled version of arkanoid.mo (from another camera compiled in the same branch) after the second pass of module compilation, then run "make zip" and got this error:

/Library/Developer/CommandLineTools/usr/bin/make -C ../../minimal/ MODEL=77D FW_VERSION=100
/Library/Developer/CommandLineTools/usr/bin/make -C hello-world/.
[ CC       ]   reboot-dumper.o
[ CC       ]   footer.o
[ LD       ]   autoexec
[ XOR_CHK  ]   ../../build_tools/xor_chk
../../build_tools/xor_chk.c:48:88: warning: format specifies type
      'unsigned long' but the argument has type 'uint64_t' (aka
      'unsigned long long') [-Wformat]
  ...error (expected 0x%lX, got 0x%lX)\n", 0xCCCCCCCCE12FFF13, footer_magic);
                                  ~~~                          ^~~~~~~~~~~~
                                  %llX
1 warning generated.
[ OBJCOPY  ]   autoexec.bin
[ XOR_CHK  ]   autoexec.bin
[ CPP      ]   magiclantern.lds
[ AS       ]   entry.o
[ CC       ]   minimal.o
In file included from minimal.c:5:0:
../../src/dryos.h:37:17: fatal error: gui.h: No such file or directory
compilation terminated.
make[2]: *** [minimal.o] Error 1
make[1]: *** [hello-world/.] Error 2
make: *** [minimal_check] Error 2

retried with "make install_qemu ML_MODULES=" and got no errors.

Unfortunately I still have a problem with qemu I can't solve:

./run_canon_fw.sh 77D, firmware=boot=0

DebugMsg=0xDF006E6C (from GDB script)
qemu-system-arm: -M 77D,: drive with bus=0, unit=0 (index=0) exists

I get that on each try, whether camera model is specified...
I don't know if it screwed after installing/updating packages with brew some days ago, got some errors and had to reinstall some of them.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 09, 2019, 05:23:42 PM
Module error: right, needs to be fixed somehow in the Makefiles.

xor_chk: reproduced on the Mac VM, will fix. No warnings on my main system.

gui.h: just create an empty file for now.

QEMU error: when in doubt, copy the commands from the guide. You've got an extra space that's not present in the READMEs (at least I couldn't find it). I'm hijacking an option from vanilla QEMU, as their command line parser doesn't seem the easiest thing to figure out.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on March 09, 2019, 05:48:09 PM
Quote from: a1ex on March 09, 2019, 05:23:42 PM
QEMU error: when in doubt, copy the commands from the guide. You've got an extra space that's not present in the READMEs (at least I couldn't find it). I'm hijacking an option from vanilla QEMU, as their command line parser doesn't seem the easiest thing to figure out.
Yes, put a space when was't needed. Thank You a1ex.

How is debugging process of stubs in qemu minded?
Do I need to call each stubs by modified test code in minimal-d78.c and check for their behaviour using return value or expected outcome?

Currently I can see in qemu only the blinking red icon on bottom right of the screen, I imagine is led_blink() test.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 09, 2019, 05:58:04 PM
Sounds good; it should also save a log though. Either printf-based debugging (qprintf, compile with CONFIG_QEMU=y), or step by step debugging in gdb, or something like that. Also run with -d debugmsg and possibly other debugging options. No short answer, I'm afraid (I'm currently debugging a quirk in the logging code for about a week and still can't manage to pass the tests).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on March 09, 2019, 06:40:16 PM
I'm not sure it's good... no log is saved to virtual SD.

Led icon is blinking too much fast and by trying to modify the timings (ex. msleep related to off period) in led_blink() doesn't seems to matter.
Screen looks gray like when booted with bootflag disabled, but on top left there is a broken black line.

In console I get no debug messages when bootflag is enabled but this: (compiled with make install_qemu ML_MODULES= from platform/77D)

./run_canon_fw.sh 77D,firmware=boot=1 -d debugmsg

DebugMsg=0xDF006E6C (from GDB script)
00000000 - 3FFFFFFF: eos.ram
40000000 - 7FFFFFFF: eos.ram_uncached
DF000000 - DFFFFFFF: eos.ram_extra
E0000000 - E1FFFFFF: eos.rom0
E2000000 - E3FFFFFF: eos.rom0_mirror
E4000000 - E5FFFFFF: eos.rom0_mirror
E6000000 - E7FFFFFF: eos.rom0_mirror
E8000000 - E9FFFFFF: eos.rom0_mirror
EA000000 - EBFFFFFF: eos.rom0_mirror
EC000000 - EDFFFFFF: eos.rom0_mirror
EE000000 - EFFFFFFF: eos.rom0_mirror
F0000000 - F0FFFFFF: eos.rom1
F1000000 - F1FFFFFF: eos.rom1_mirror
F2000000 - F2FFFFFF: eos.rom1_mirror
F3000000 - F3FFFFFF: eos.rom1_mirror
F4000000 - F4FFFFFF: eos.rom1_mirror
F5000000 - F5FFFFFF: eos.rom1_mirror
F6000000 - F6FFFFFF: eos.rom1_mirror
F7000000 - F7FFFFFF: eos.rom1_mirror
F8000000 - F8FFFFFF: eos.rom1_mirror
F9000000 - F9FFFFFF: eos.rom1_mirror
FA000000 - FAFFFFFF: eos.rom1_mirror
FB000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FCFFFFFF: eos.rom1_mirror
FD000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FEFFFFFF: eos.rom1_mirror
FF000000 - FFFFFFFF: eos.rom1_mirror
BFE00000 - DEFFFFFF: eos.mmio
[EOS] enabling code execution logging.
[EOS] loading './77D/ROM0.BIN' to 0xE0000000-0xE1FFFFFF
[EOS] loading './77D/ROM1.BIN' to 0xF0000000-0xF0FFFFFF
[MPU] FIXME: using generic MPU spells for 77D.
[MPU] FIXME: no MPU button codes for 77D.
Start address: 0xE0000000
Setting BOOTDISK flag to FFFFFFFF
[CPU0] E00075E0: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] E0007606: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xE000001D
[CPU0] E0007632: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x8C50078
[CPU0] E0007628: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU0] E0007632: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU0] E0004AC6: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU0] E0004AC6: MCR p15, ...          : CACHEMAINT x3 (omitted)
[CPU0] E0004AC6: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51878
<<<<< Musa(PU0) Boot Ver 0.21 >>>>>
[CPU0] E0007672: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU1] E00075E0: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000001
[CPU1] E0004BB2: MCR p15, ...          : CACHEMAINT x512 (omitted)
[CPU1] E0007606: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xE000001D
[CPU1] E0007632: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x8C50078
[CPU1] E0007628: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU1] E0007632: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU1] E0004AC6: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU1] E0004AC6: MCR p15, ...          : CACHEMAINT x3 (omitted)
[CPU1] E0004AC6: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51878
[CPU1] E0004AEA: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51878
[CPU1] E0004BA0: MCR p15, ...          : CACHEMAINT x512 (omitted)
[CPU1] E0004AEA: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU1] E0004AFA: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU1] E0004A5A: MCR p15,0,Rd,cr3,cr0,0:       DACR <- 0x55555555
[CPU1] E0004A62: MCR p15,0,Rd,cr2,cr0,0:  TTBR0_EL1 <- 0xE0004880
[CPU1] E0004A66: MCR p15,0,Rd,cr2,cr0,1:  TTBR1_EL1 <- 0xE0000080
[CPU1] E0004A6A: MCR p15,0,Rd,cr13,cr0,1: CONTEXTIDR(S) <- 0x1       
[CPU1] E0004A6E: MCR p15,0,Rd,cr2,cr0,2:      TTBCR <- 0x7       
[CPU1] E0004A76: MCR p15,0,Rd,cr8,cr7,0:    TLBIALL <- 0x0       
[CPU1] E0004A7E: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU1] E0004A7E: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50879
[CPU1] E00076D8: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50879
[CPU1] E00076D8: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU1] E00076D8: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51879
[CPU1] E00076F0: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51879
[CPU1] E00076F0: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C5187D
[CPU1] E00076FC: MRC p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 -> 0x45
[CPU1] E00076FC: MCR p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 <- 0x45       
[CPU1] E00076FC: MRC p15,0,Rd,cr15,cr0,0:  A9_PWRCTL -> 0x0
[CPU1] E00076FC: MCR p15,0,Rd,cr15,cr0,0:  A9_PWRCTL <- 0x1       
[CPU1] E000771C: MRC p15,0,Rd,cr15,cr0,1:    A9_DIAG -> 0x0
[CPU1] E000771C: MCR p15,0,Rd,cr15,cr0,1:    A9_DIAG <- 0x400000   
[CPU1] E0004A1A: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C5187D
[CPU1] E0004A1A: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C5107D
[CPU0] E0004AEA: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51878
[CPU0] E0004AEA: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU0] E0004AFA: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU0] E0004A5A: MCR p15,0,Rd,cr3,cr0,0:       DACR <- 0x55555555
[CPU0] E0004A62: MCR p15,0,Rd,cr2,cr0,0:  TTBR0_EL1 <- 0xE0004800
[CPU0] E0004A66: MCR p15,0,Rd,cr2,cr0,1:  TTBR1_EL1 <- 0xE0000080
[CPU0] E0004A6A: MCR p15,0,Rd,cr13,cr0,1: CONTEXTIDR(S) <- 0x0       
[CPU0] E0004A6E: MCR p15,0,Rd,cr2,cr0,2:      TTBCR <- 0x7       
[CPU0] E0004A76: MCR p15,0,Rd,cr8,cr7,0:    TLBIALL <- 0x0       
[CPU0] E0004A7E: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU0] E0004A7E: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50879
[CPU0] E00076D8: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50879
[CPU0] E00076D8: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU0] E00076D8: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51879
[CPU0] E00076F0: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51879
[CPU0] E00076F0: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C5187D
[CPU0] E00076FC: MRC p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 -> 0x45
[CPU0] E00076FC: MCR p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 <- 0x45       
[CPU0] E00076FC: MRC p15,0,Rd,cr15,cr0,0:  A9_PWRCTL -> 0x0
[CPU0] E00076FC: MCR p15,0,Rd,cr15,cr0,0:  A9_PWRCTL <- 0x1       
[CPU0] E000771C: MRC p15,0,Rd,cr15,cr0,1:    A9_DIAG -> 0x0
[CPU0] E000771C: MCR p15,0,Rd,cr15,cr0,1:    A9_DIAG <- 0x400000   
[CPU0] E0004900: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] E0004940: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xDF000000
Boot[CPU0] 00100752: MCR p15,0,Rd,cr7,cr8,0:        ATS <- 0xC6000000
[CPU0] 0010075A: MRC p15,0,Rd,cr7,cr4,0:        PAR -> 0xB
[CPU0] 00100752: MCR p15,0,Rd,cr7,cr8,0:        ATS <- 0xC2000000
[CPU0] 0010075A: MRC p15,0,Rd,cr7,cr4,0:        PAR -> 0xB
Load
SLOT_A LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0xA0
Now jump to AUTOEXEC.BIN(0x00800000)!!


I should try to put some debug messages (probably qprintf because not sure how to set gdb) to understand what code is executed, but I'm short in time now so will try in next days.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 09, 2019, 06:58:32 PM
If nothing is happening after autoexec.bin... then it's not booting. There should be plenty of debug messages from Canon. Also, delays are emulated fairly well (not exactly real-time, but close). If changing the msleep arguments do not affect the delays you see on the screen, then... you may be running some other code. To make sure you are running the code you are editing, write some nonsense near the msleeps - you should get a compile error. Otherwise, look in the Makefiles.

By default, on 77D, the code on the main repository runs the LED blinking test from reboot-dumper.c. Make sure you have changed that in Makefiles to match 200D.

For early boot debugging, compile with CONFIG_QEMU=y (after make clean) and I'd expect it to print at least something.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on March 11, 2019, 01:27:30 AM
Quote from: a1ex on March 09, 2019, 06:58:32 PM
If nothing is happening after autoexec.bin... then it's not booting. There should be plenty of debug messages from Canon.

By default, on 77D, the code on the main repository runs the LED blinking test from reboot-dumper.c. Make sure you have changed that in Makefiles to match 200D.
Forgot about adapt makefile to this commit (https://bitbucket.org/hudson/magic-lantern/commits/ae6f75a40b5f474b3fcbc5533168663e438748d5?at=digic6-dumper)...

So I started by changing Makefile to this:

# 77D 1.0.2

CANON_NAME_FIR  = 5D300133.FIR
FIRMWARE_ID     = 0x80000408
UPDATE_NAME_FIR = LOG_77D.FIR

# Shrink Canon's malloc heap by changing its end address
#          ("meminfo -m" in drysh)    ("memmap" in drysh)
# Default: 0x000e0fa8 - 0x001f5658, 0x000e0fa0 - 0x001f5928 (total size 0x001146b0 ?)
# Patched: 0x000e0fa8 - 0x001b5658, 0x000e0fa0 - 0x001b5928 ( reserved for ML)
# (TO BE CHECKED)
ROMBASEADDR     = 0xE0040000
RESTARTSTART    = 0x001B5700

# Cortex A9, binaries loaded as Thumb
CFLAG_USER = -mthumb -march=armv7-a -mlong-calls

# these should be removed when porting starts
ML_SRC_PROFILE  = minimal
ML_MINIMAL_OBJ  = minimal-d678.o
ML_SRC_EXTRA_OBJS += log-d678.o stdio.o

# FIXME: should be boot-d6.o
ML_BOOT_OBJ = boot-d78.o

Used qemu and drysh to retrieve values for memory configuration, not sure if reserved space is enough and if rombaseaddr is correct...

At this point to make it compile I had to first find these constants by pattern matching with 200D:

/*
*  77D 1.0.2 consts
*/

#define CARD_LED_ADDRESS            0xD208016C
#define LEDON                       0x20D0002
#define LEDOFF                      0x20C0003

#define HIJACK_FIXBR_DCACHE_CLN_1   0xe0040058   /* first call to dcache_clean, before cstart */
#define HIJACK_FIXBR_ICACHE_INV_1   0xe0040062   /* first call to icache_invalidate, before cstart */
#define HIJACK_FIXBR_DCACHE_CLN_2   0xe0040090   /* second call to dcache_clean, before cstart */
#define HIJACK_FIXBR_ICACHE_INV_2   0xe004009a   /* second call to icache_invalidate, before cstart */
#define HIJACK_INSTR_BL_CSTART      0xe00400b0   /* easier to fix up here */
#define HIJACK_INSTR_HEAP_SIZE      0xe00401c0   /* easier to patch the size; start address is computed */
#define HIJACK_FIXBR_BZERO32        0xe004013a   /* called from cstart */
#define HIJACK_FIXBR_CREATE_ITASK   0xe004019c   /* called from cstart */
#define HIJACK_INSTR_MY_ITASK       0xe00401cc   /* address of init_task passed to create_init_task */


Add more stubs to this list (https://www.magiclantern.fm/forum/index.php?topic=19737.msg206736#msg206736):

NSTUB(0xe0152eb1,  cli_spin_lock)          /* used in AllocateMemory/FreeMemory and others */

// Taken from 200d to make it compile.
NSTUB(    0x4030,  pre_isr_hook)  //Not Good
NSTUB(    0x4034,  post_isr_hook)  //Not Good
NSTUB(   0x6CC14,  isr_table_param)  //Not Good
NSTUB(0xDF007B59, _AllocateMemory)  //Not Good - Maybe 0xDF007E58

Did't figured out yet how to find isr related stubs from interrupt Handler.... Any Hints for me?

Now last thing to figure out was signature of the firmware; started by copying the one from 200D and then changed to this:

#define SIG_200D_101 0xf72c729a // from E0040000
#define SIG_77D_100  0x6dd89c83 // from e0040000

Which come to my surprise from Qemu: (wasn't reaching this point without the faked value)

Boot[CPU0] 00100752: MCR p15,0,Rd,cr7,cr8,0:        ATS <- 0xC6000000
[CPU0] 0010075A: MRC p15,0,Rd,cr7,cr4,0:        PAR -> 0xB
[CPU0] 00100752: MCR p15,0,Rd,cr7,cr8,0:        ATS <- 0xC2000000
[CPU0] 0010075A: MRC p15,0,Rd,cr7,cr4,0:        PAR -> 0xB
Load
SLOT_A LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x6D20
Now jump to AUTOEXEC.BIN(0x00800000)!!
[CPU0] 00800008: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[boot] firmware signature: 0x6dd89c83 (1842912387)
                 expected: 0xf72c729a (-148082022)
            computed from: 0xe0040000 (-536608768)


Which ended in what is like make emulation a step ahead:

./run_canon_fw.sh 77D,firmware=boot=1 -d debugmsg

DebugMsg=0xDF006E6C (from GDB script)
00000000 - 3FFFFFFF: eos.ram
40000000 - 7FFFFFFF: eos.ram_uncached
DF000000 - DFFFFFFF: eos.ram_extra
E0000000 - E1FFFFFF: eos.rom0
E2000000 - E3FFFFFF: eos.rom0_mirror
E4000000 - E5FFFFFF: eos.rom0_mirror
E6000000 - E7FFFFFF: eos.rom0_mirror
E8000000 - E9FFFFFF: eos.rom0_mirror
EA000000 - EBFFFFFF: eos.rom0_mirror
EC000000 - EDFFFFFF: eos.rom0_mirror
EE000000 - EFFFFFFF: eos.rom0_mirror
F0000000 - F0FFFFFF: eos.rom1
F1000000 - F1FFFFFF: eos.rom1_mirror
F2000000 - F2FFFFFF: eos.rom1_mirror
F3000000 - F3FFFFFF: eos.rom1_mirror
F4000000 - F4FFFFFF: eos.rom1_mirror
F5000000 - F5FFFFFF: eos.rom1_mirror
F6000000 - F6FFFFFF: eos.rom1_mirror
F7000000 - F7FFFFFF: eos.rom1_mirror
F8000000 - F8FFFFFF: eos.rom1_mirror
F9000000 - F9FFFFFF: eos.rom1_mirror
FA000000 - FAFFFFFF: eos.rom1_mirror
FB000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FCFFFFFF: eos.rom1_mirror
FD000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FEFFFFFF: eos.rom1_mirror
FF000000 - FFFFFFFF: eos.rom1_mirror
BFE00000 - DEFFFFFF: eos.mmio
[EOS] enabling code execution logging.
[EOS] loading './77D/ROM0.BIN' to 0xE0000000-0xE1FFFFFF
[EOS] loading './77D/ROM1.BIN' to 0xF0000000-0xF0FFFFFF
[MPU] FIXME: using generic MPU spells for 77D.
[MPU] FIXME: no MPU button codes for 77D.
Start address: 0xE0000000
Setting BOOTDISK flag to FFFFFFFF
[CPU0] E00075E0: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] E0007606: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xE000001D
[CPU0] E0007632: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x8C50078
[CPU0] E0007628: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU0] E0007632: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU0] E0004AC6: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU0] E0004AC6: MCR p15, ...          : CACHEMAINT x3 (omitted)
[CPU0] E0004AC6: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51878
<<<<< Musa(PU0) Boot Ver 0.21 >>>>>
[CPU0] E0007672: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU1] E00075E0: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000001
[CPU1] E0004BB2: MCR p15, ...          : CACHEMAINT x512 (omitted)
[CPU1] E0007606: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xE000001D
[CPU1] E0007632: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x8C50078
[CPU1] E0007628: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU1] E0007632: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU1] E0004AC6: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU1] E0004AC6: MCR p15, ...          : CACHEMAINT x3 (omitted)
[CPU1] E0004AC6: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51878
[CPU1] E0004AEA: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51878
[CPU1] E0004BA0: MCR p15, ...          : CACHEMAINT x512 (omitted)
[CPU1] E0004AEA: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU1] E0004AFA: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU1] E0004A5A: MCR p15,0,Rd,cr3,cr0,0:       DACR <- 0x55555555
[CPU1] E0004A62: MCR p15,0,Rd,cr2,cr0,0:  TTBR0_EL1 <- 0xE0004880
[CPU1] E0004A66: MCR p15,0,Rd,cr2,cr0,1:  TTBR1_EL1 <- 0xE0000080
[CPU1] E0004A6A: MCR p15,0,Rd,cr13,cr0,1: CONTEXTIDR(S) <- 0x1       
[CPU1] E0004A6E: MCR p15,0,Rd,cr2,cr0,2:      TTBCR <- 0x7       
[CPU1] E0004A76: MCR p15,0,Rd,cr8,cr7,0:    TLBIALL <- 0x0       
[CPU1] E0004A7E: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU1] E0004A7E: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50879
[CPU1] E00076D8: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50879
[CPU1] E00076D8: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU1] E00076D8: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51879
[CPU1] E00076F0: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51879
[CPU1] E00076F0: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C5187D
[CPU1] E00076FC: MRC p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 -> 0x45
[CPU1] E00076FC: MCR p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 <- 0x45       
[CPU1] E00076FC: MRC p15,0,Rd,cr15,cr0,0:  A9_PWRCTL -> 0x0
[CPU1] E00076FC: MCR p15,0,Rd,cr15,cr0,0:  A9_PWRCTL <- 0x1       
[CPU1] E000771C: MRC p15,0,Rd,cr15,cr0,1:    A9_DIAG -> 0x0
[CPU1] E000771C: MCR p15,0,Rd,cr15,cr0,1:    A9_DIAG <- 0x400000   
[CPU1] E0004A1A: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C5187D
[CPU1] E0004A1A: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C5107D
[CPU0] E0004AEA: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51878
[CPU0] E0004AEA: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU0] E0004AFA: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU0] E0004A5A: MCR p15,0,Rd,cr3,cr0,0:       DACR <- 0x55555555
[CPU0] E0004A62: MCR p15,0,Rd,cr2,cr0,0:  TTBR0_EL1 <- 0xE0004800
[CPU0] E0004A66: MCR p15,0,Rd,cr2,cr0,1:  TTBR1_EL1 <- 0xE0000080
[CPU0] E0004A6A: MCR p15,0,Rd,cr13,cr0,1: CONTEXTIDR(S) <- 0x0       
[CPU0] E0004A6E: MCR p15,0,Rd,cr2,cr0,2:      TTBCR <- 0x7       
[CPU0] E0004A76: MCR p15,0,Rd,cr8,cr7,0:    TLBIALL <- 0x0       
[CPU0] E0004A7E: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU0] E0004A7E: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50879
[CPU0] E00076D8: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50879
[CPU0] E00076D8: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU0] E00076D8: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51879
[CPU0] E00076F0: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51879
[CPU0] E00076F0: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C5187D
[CPU0] E00076FC: MRC p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 -> 0x45
[CPU0] E00076FC: MCR p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 <- 0x45       
[CPU0] E00076FC: MRC p15,0,Rd,cr15,cr0,0:  A9_PWRCTL -> 0x0
[CPU0] E00076FC: MCR p15,0,Rd,cr15,cr0,0:  A9_PWRCTL <- 0x1       
[CPU0] E000771C: MRC p15,0,Rd,cr15,cr0,1:    A9_DIAG -> 0x0
[CPU0] E000771C: MCR p15,0,Rd,cr15,cr0,1:    A9_DIAG <- 0x400000   
[CPU0] E0004900: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] E0004940: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xDF000000
Boot[CPU0] 00100752: MCR p15,0,Rd,cr7,cr8,0:        ATS <- 0xC6000000
[CPU0] 0010075A: MRC p15,0,Rd,cr7,cr4,0:        PAR -> 0xB
[CPU0] 00100752: MCR p15,0,Rd,cr7,cr8,0:        ATS <- 0xC2000000
[CPU0] 0010075A: MRC p15,0,Rd,cr7,cr4,0:        PAR -> 0xB
Load
SLOT_A LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x7120
Now jump to AUTOEXEC.BIN(0x00800000)!!
[CPU0] 00800008: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] 00806A46: MRC p15,1,Rd,cr0,cr0,1:      CLIDR -> 0x9200003
[CPU0] 001008BC: MCR p15, ...          : CACHEMAINT x512 (omitted)
[CPU0] 00806A66: MCR p15,2,Rd,cr0,cr0,0:     CSSELR <- 0x0       
[CPU0] 00806A6A: MRC p15,1,Rd,cr0,cr0,0:     CCSIDR -> 0x700FE019
[boot] copy_and_restart 0x1b5700 (1791744)
[BOOT] reserving memory: 0x40000 (262144)
before: user_mem_size = 0x114988 (1132936)
after: user_mem_size = 0xd4988 (870792)
[BOOT] fixing up branch at 0x1b7ba0 (1801120)  (ROM: 0xe0040058 (-536608680) ) to 0x1b5769 (1791849)
[BOOT] fixing up branch at 0x1b7bd8 (1801176)  (ROM: 0xe0040090 (-536608624) ) to 0x1b5769 (1791849)
[BOOT] fixing up branch at 0x1b7baa (1801130)  (ROM: 0xe0040062 (-536608670) ) to 0x1b5759 (1791833)
[BOOT] fixing up branch at 0x1b7be2 (1801186)  (ROM: 0xe004009a (-536608614) ) to 0x1b5759 (1791833)
[BOOT] fixing up branch at 0x1b7bf8 (1801208)  (ROM: 0xe00400b0 (-536608592) ) to 0x1b7c34 (1801268)
[BOOT] fixing up branch at 0x1b7c82 (1801346)  (ROM: 0xe004013a (-536608454) ) to 0x1b5751 (1791825)
[BOOT] fixing up branch at 0x1b7ce4 (1801444)  (ROM: 0xe004019c (-536608356) ) to 0x1b5749 (1791817)
[BOOT] changing init_task from 0xe0040215 (-536608235) to 0x1b577d (1791869)
[CPU0] 001B5F96: MRC p15,1,Rd,cr0,cr0,1:      CLIDR -> 0x9200003
[CPU0] 00806A20: MCR p15, ...          : CACHEMAINT x514 (omitted)
[CPU0] 001B5FB6: MCR p15,2,Rd,cr0,cr0,0:     CSSELR <- 0x0       
[CPU0] 001B5FBA: MRC p15,1,Rd,cr0,cr0,0:     CCSIDR -> 0x700FE019
[BOOT] jumping to relocated startup code at 0x1b7b49 (1801033)
[CPU0] 001B5F70: MCR p15, ...          : CACHEMAINT x514 (omitted)
[CPU0] 001B7B48: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xE02427A0
[CPU0] 001B7B52: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000

Now it appears to execute in qemu compiling code from minimal-678.c. (put some garbage in led_blink() to see if compilation fail)
But none of the functions contained is executed (put some qprintf to see if they get called).

I still get that black bar on top and still no log saved to sd unfortunately.
Now the red icon is not blinking anymore, but is solid red instead of blinking half of a second... My hope is it get stuck because of the missing stubs

@a1ex can you check if this is good up to this stage by looking at changes and what is printed by Qemu by using qprintf?

Didn't tried to add +1 to the stubs in ARM address to make it THUMB. May this be valid in this case?


EDIT:
Comparing 200D in Qemu I get:
./run_canon_fw.sh 200D,firmware=boot=1 -d debugmsg

DebugMsg=0xDF006E6C (from GDB script)
00000000 - 1FFFFFFF: eos.ram
40000000 - 5FFFFFFF: eos.ram_uncached
DF000000 - DFFFFFFF: eos.ram_extra
E0000000 - E1FFFFFF: eos.rom0
E2000000 - E3FFFFFF: eos.rom0_mirror
E4000000 - E5FFFFFF: eos.rom0_mirror
E6000000 - E7FFFFFF: eos.rom0_mirror
E8000000 - E9FFFFFF: eos.rom0_mirror
EA000000 - EBFFFFFF: eos.rom0_mirror
EC000000 - EDFFFFFF: eos.rom0_mirror
EE000000 - EFFFFFFF: eos.rom0_mirror
F0000000 - F0FFFFFF: eos.rom1
F1000000 - F1FFFFFF: eos.rom1_mirror
F2000000 - F2FFFFFF: eos.rom1_mirror
F3000000 - F3FFFFFF: eos.rom1_mirror
F4000000 - F4FFFFFF: eos.rom1_mirror
F5000000 - F5FFFFFF: eos.rom1_mirror
F6000000 - F6FFFFFF: eos.rom1_mirror
F7000000 - F7FFFFFF: eos.rom1_mirror
F8000000 - F8FFFFFF: eos.rom1_mirror
F9000000 - F9FFFFFF: eos.rom1_mirror
FA000000 - FAFFFFFF: eos.rom1_mirror
FB000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FCFFFFFF: eos.rom1_mirror
FD000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FEFFFFFF: eos.rom1_mirror
FF000000 - FFFFFFFF: eos.rom1_mirror
BFE00000 - DEFFFFFF: eos.mmio
[EOS] enabling code execution logging.
[EOS] loading './200D/ROM0.BIN' to 0xE0000000-0xE1FFFFFF
[EOS] loading './200D/ROM1.BIN' to 0xF0000000-0xF0FFFFFF
[MPU] FIXME: using generic MPU spells for 200D.
[MPU] FIXME: no MPU button codes for 200D.
Start address: 0xE0000000
Setting BOOTDISK flag to FFFFFFFF
[CPU0] E0007618: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] E000763E: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xE000001D
[CPU0] E000766A: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x8C50078
[CPU0] E0007660: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU0] E000766A: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU0] E0004ADA: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU0] E0004ADA: MCR p15, ...          : CACHEMAINT x2 (omitted)
[CPU0] E0004ADA: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51878
<<<<< Musa(PU0) Boot Ver 0.17 (DE) >>>>>
[CPU0] E00076AA: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] E0004AFE: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51878
[CPU0] E0004BC8: MCR p15, ...          : CACHEMAINT x512 (omitted)
[CPU0] E0004AFE: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU0] E0004B0E: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU0] E0004A5A: MCR p15,0,Rd,cr3,cr0,0:       DACR <- 0x55555555
[CPU0] E0004A62: MCR p15,0,Rd,cr2,cr0,0:  TTBR0_EL1 <- 0xE0004800
[CPU0] E0004A66: MCR p15,0,Rd,cr2,cr0,1:  TTBR1_EL1 <- 0xE0000080
[CPU0] E0004A6A: MCR p15,0,Rd,cr13,cr0,1: CONTEXTIDR(S) <- 0x0       
[CPU0] E0004A6E: MCR p15,0,Rd,cr2,cr0,2:      TTBCR <- 0x7       
[CPU0] E0004A76: MCR p15,0,Rd,cr8,cr7,0:    TLBIALL <- 0x0       
[CPU0] E0004A7E: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU0] E0004A7E: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50879
[CPU0] E00076EC: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50879
[CPU0] E00076EC: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU0] E00076EC: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51879
[CPU0] E0007704: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51879
[CPU0] E0007704: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C5187D
[CPU0] E0007710: MRC p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 -> 0x45
[CPU0] E0007710: MCR p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 <- 0x45       
[CPU0] E0007710: MRC p15,0,Rd,cr15,cr0,0:  A9_PWRCTL -> 0x0
[CPU0] E0007710: MCR p15,0,Rd,cr15,cr0,0:  A9_PWRCTL <- 0x1       
[CPU0] E0007730: MRC p15,0,Rd,cr15,cr0,1:    A9_DIAG -> 0x0
[CPU0] E0007730: MCR p15,0,Rd,cr15,cr0,1:    A9_DIAG <- 0x400000   
[CPU0] E0004900: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] E0004940: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xDF000000
Boot[CPU0] 0010074E: MCR p15,0,Rd,cr7,cr8,0:        ATS <- 0xC6000000
[CPU0] 00100756: MRC p15,0,Rd,cr7,cr4,0:        PAR -> 0xB
[CPU0] 0010074E: MCR p15,0,Rd,cr7,cr8,0:        ATS <- 0xC2000000
[CPU0] 00100756: MRC p15,0,Rd,cr7,cr4,0:        PAR -> 0xB
Load
SLOT_A LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x5400
Now jump to AUTOEXEC.BIN(0x00800000)!!
[CPU0] 00800008: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] 00804D16: MRC p15,1,Rd,cr0,cr0,1:      CLIDR -> 0x9200003
[CPU0] 001008D4: MCR p15, ...          : CACHEMAINT x512 (omitted)
[CPU0] 00804D36: MCR p15,2,Rd,cr0,cr0,0:     CSSELR <- 0x0       
[CPU0] 00804D3A: MRC p15,1,Rd,cr0,cr0,0:     CCSIDR -> 0x700FE019
[boot] copy_and_restart 0x1b6300 (1794816)
[BOOT] reserving memory: 0x40000 (262144)
before: user_mem_size = 0x114988 (1132936)
after: user_mem_size = 0xd4988 (870792)
[BOOT] fixing up branch at 0x1b87b0 (1804208)  (ROM: 0xe0040068 (-536608664) ) to 0x1b6369 (1794921)
[BOOT] fixing up branch at 0x1b87e8 (1804264)  (ROM: 0xe00400a0 (-536608608) ) to 0x1b6369 (1794921)
[BOOT] fixing up branch at 0x1b87ba (1804218)  (ROM: 0xe0040072 (-536608654) ) to 0x1b6359 (1794905)
[BOOT] fixing up branch at 0x1b87f2 (1804274)  (ROM: 0xe00400aa (-536608598) ) to 0x1b6359 (1794905)
[BOOT] fixing up branch at 0x1b8808 (1804296)  (ROM: 0xe00400c0 (-536608576) ) to 0x1b8845 (1804357)
[BOOT] fixing up branch at 0x1b8892 (1804434)  (ROM: 0xe004014a (-536608438) ) to 0x1b6351 (1794897)
[BOOT] fixing up branch at 0x1b88f4 (1804532)  (ROM: 0xe00401ac (-536608340) ) to 0x1b6349 (1794889)
[BOOT] changing init_task from 0xe0040225 (-536608219) to 0x1b637d (1794941)
[CPU0] 001B6B96: MRC p15,1,Rd,cr0,cr0,1:      CLIDR -> 0x9200003
[CPU0] 00804CF0: MCR p15, ...          : CACHEMAINT x514 (omitted)
[CPU0] 001B6BB6: MCR p15,2,Rd,cr0,cr0,0:     CSSELR <- 0x0       
[CPU0] 001B6BBA: MRC p15,1,Rd,cr0,cr0,0:     CCSIDR -> 0x700FE019
[BOOT] jumping to relocated startup code at 0x1b8749 (1804105)
[CPU0] 001B6B70: MCR p15, ...          : CACHEMAINT x514 (omitted)
[CPU0] 001B8748: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xE021CB60
[CPU0] 001B8752: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU1] E0007618: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000001
[CPU1] E000763E: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xE000001D
[CPU1] E000766A: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x8C50078
[CPU1] E0007660: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU1] E000766A: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU1] E0004ADA: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU1] E0004ADA: MCR p15, ...          : CACHEMAINT x2 (omitted)
[CPU1] E0004ADA: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51878
[CPU1] E0004AFE: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51878
[CPU1] E0004BB8: MCR p15, ...          : CACHEMAINT x512 (omitted)
[CPU1] E0004AFE: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU1] E0004B0E: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU1] E0004A5A: MCR p15,0,Rd,cr3,cr0,0:       DACR <- 0x55555555
[CPU1] E0004A62: MCR p15,0,Rd,cr2,cr0,0:  TTBR0_EL1 <- 0xE0004880
[CPU1] E0004A66: MCR p15,0,Rd,cr2,cr0,1:  TTBR1_EL1 <- 0xE0000080
[CPU1] E0004A6A: MCR p15,0,Rd,cr13,cr0,1: CONTEXTIDR(S) <- 0x1       
[CPU1] E0004A6E: MCR p15,0,Rd,cr2,cr0,2:      TTBCR <- 0x7       
[CPU1] E0004A76: MCR p15,0,Rd,cr8,cr7,0:    TLBIALL <- 0x0       
[CPU1] E0004A7E: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU1] E0004A7E: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50879
[CPU1] E00076EC: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50879
[CPU1] E00076EC: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU1] E00076EC: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51879
[CPU1] E0007704: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C51879
[CPU1] E0007704: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C5187D
[CPU1] E0007710: MRC p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 -> 0x45
[CPU1] E0007710: MCR p15,0,Rd,cr1,cr0,1:  ACTLR_EL1 <- 0x45       
[CPU1] E0007710: MRC p15,0,Rd,cr15,cr0,0:  A9_PWRCTL -> 0x0
[CPU1] E0007710: MCR p15,0,Rd,cr15,cr0,0:  A9_PWRCTL <- 0x1       
[CPU1] E0007730: MRC p15,0,Rd,cr15,cr0,1:    A9_DIAG -> 0x0
[CPU1] E0007730: MCR p15,0,Rd,cr15,cr0,1:    A9_DIAG <- 0x400000   
[CPU1] E0004A1A: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C5187D
[CPU1] E0004A1A: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C5107D
[CPU0] 001B8844: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] E06BE23C: MCR p15, ...          : CACHEMAINT x8845 (omitted)
[CPU0] E04B43BE: MCR p15,0,Rd,cr7,cr8,0:        ATS <- 0xC6000000
[CPU0] E04B43C6: MRC p15,0,Rd,cr7,cr4,0:        PAR -> 0xB
[CPU0] E04B43BE: MCR p15,0,Rd,cr7,cr8,0:        ATS <- 0xC2000000
[CPU0] E04B43C6: MRC p15,0,Rd,cr7,cr4,0:        PAR -> 0xB
[BOOT] autoexec.bin loaded at 1B6300 - 1B9A80.
[BOOT] calling pre_init_task 1B6B19...
[DBG] boot_pre_init_task()
[BOOT] reserved 262144 bytes for ML (used 14208)
[BOOT] starting init_task 200BBC...
K417 READY
[CPU0] [        init:e04bdce7 ] (00:05) [MEM] InitializePermanentMemory 0 4636784
[CPU0] [        init:e01b3235 ] (00:01) [HPC] InitializeHPCopy( 0 )
[CPU0] [        init:e01b3235 ] (00:01) [HPC] InitializeHPCopy( 1 )
[CPU0] [        init:e0584607 ] (00:01) [PM] Disable (ID = 137, cnt = 1/1)
[CPU0] [        init:e0041327 ] (89:16)
                                        K417 ICU Firmware Version 1.0.1 ( 5.0.2 )
[CPU0] [        init:e0041333 ] (89:05)
                                        ICU Release DateTime 2017.09.21 12:53:23
[CPU0] [        init:e04c0ec5 ] (02:01) PROPAD_Initialize CreateBinarySemaphore = 0x4e003a
[CPU0] [        init:e04c0f75 ] (02:01) PROPAD_RegisterOmarSysBlockCBR 0xe00406eb 0xe00406b1
[CPU0] [        init:e0139d3f ] (02:01) PROPTUNEAD_RegisterOmarSysBlockCBR 0xe00406eb 0xe00406b1
[CPU0] [        init:e0048fd7 ] (00:03) [SEQ] CreateSequencer (Startup, Num = 6)
[CPU0] [        init:e004909b ] (00:02) [SEQ] NotifyComplete (Startup, Flag = 0x10000)
[CPU0] [        init:e00490d1 ] (00:03) [SEQ] NotifyComplete (Cur = 0, 0x2018000, Flag = 0x10000)
[BOOT] calling post_init_task 1B6B21...
Free memory: 5B1B44
Logging buffer: 7BA4C4 - 9BA4C3
Free memory: 3B1B34
Replacing DF006E6C DebugMsg with 1B854D...
[CPU0] 001B6B96: MRC p15,1,Rd,cr0,cr0,1:      CLIDR -> 0x9200003
[CPU0] E06BE168: MCR p15, ...          : CACHEMAINT x1680 (omitted)
[CPU0] 001B6B96: MCR p15,2,Rd,cr0,cr0,0:     CSSELR <- 0x0       
[CPU0] 001B6BBA: MRC p15,1,Rd,cr0,cr0,0:     CCSIDR -> 0x700FE019
[CPU0] 001B6B96: MRC p15,1,Rd,cr0,cr0,1:      CLIDR -> 0x9200003
[CPU0] 001B6B70: MCR p15, ...          : CACHEMAINT x514 (omitted)
[CPU0] 001B6B96: MCR p15,2,Rd,cr0,cr0,0:     CSSELR <- 0x0       
[CPU0] 001B6BBA: MRC p15,1,Rd,cr0,cr0,0:     CCSIDR -> 0x700FE019
[CPU0] [        init:001b6b23 ] (00:0f) Logging started.
[CPU0] 001B858C: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[DBG] boot_post_init_task()
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dc0000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dc0004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dc2000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dc2004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dc4000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dc4004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dc6000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dc6004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dc8000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dc8004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dca000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dca004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dcc000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dcc004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dce000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dce004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dd0000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dd0004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dd2000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dd2004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dd4000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dd4004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dd6000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dd6004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dd8000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dd8004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dda000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dda004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1ddc000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1ddc004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dde000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dde004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1de0000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1de0004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1de2000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1de2004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1de4000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1de4004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1de6000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1de6004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1de8000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1de8004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dea000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dea004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dec000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dec004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dee000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dee004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1df0000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1df0004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1df2000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1df2004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1df4000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1df4004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1df6000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1df6004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1df8000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1df8004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dfa000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dfa004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dfc000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dfc004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1dfe000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1dfe004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b90 0xe1de0004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e01b32b5 ] (00:01) [HPC] HPCopy() use ch0 !
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[XDMAC0] Copy [0xE1DE0000] -> [0x409BA540], length [0x00001604], flags [0x00000005]
[XDMAC0] OK
[CPU0] [     RomRead:001b6d9b ] (00:0f) >>> INT-11Eh  E013A8F5(11E)
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] 001B6D9E: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:001b6e67 ] (00:0f) <<< INT-11Eh
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b30 0xe1de2000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b34 0xe1de2004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c14af ] (02:05) PROPAD_CreateFROMPropertyHandle DRAMAddr 0x421f8400
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b18 0xe1980000 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b1c 0xe1980004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e04c1fe1 ] (02:01) ReadUncacheFromData 0x205b78 0xe1980004 0x4
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [     RomRead:e01b32b5 ] (00:01) [HPC] HPCopy() use ch0 !
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[XDMAC0] Copy [0xE1980000] -> [0x421F8400], length [0x00155BB8], flags [0x00000005]
[XDMAC0] OK
[CPU0] [      SFRead:e0139f05 ] (02:05) PROPTUNEAD_CreateFROMPropertyHandleToDRAM Addr:0x416a2c00
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [      SFRead:e01c7b0b ] (02:03) PROPCOMBO_LoadProperty(395)
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [      SFRead:e01b32b5 ] (00:01) [HPC] HPCopy() use ch1 !
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[XDMAC1] Copy [0xF0890000] -> [0x416A2C00], length [0x000FCBD8], flags [0x00000005]
[XDMAC1] OK
[CPU0] [      DbgMgr:e0584607 ] (00:01) [PM] Disable (ID = 10, cnt = 1/2)
[CPU0] 001B8578: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
     0:4294964.223 [STARTUP]
K417 ICU Firmware Version 1.0.1 ( 5.0.2 )

So, it should switch from cpu0 to cpu1 but it freezes. What can cause the boot process to hang up? Some wrong constants?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 12, 2019, 02:16:48 AM
I followed the work from aprofiti and fixed the thumb bits in stubs.S.

I basically see the same results, including the strange broken line in the emulator. But the red light is on after boot for about a second and then turns off.

Unfortunately I get no log file on sd.img, neither with reboot-dumper nor with the changed makefile for minimal-d678.

Running the minimal-d678 in Qemu with "-d debugmsg,int,io" I get a lot of messages like this:

Quote[CPU0] [      RscMgr:001b61ff ] (00:0f) >>> INT-01Bh dryos_timer 54535F4D(5F545241)
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[HPTimer] Firing HPTimer #13
[EOS] trigger int 0x28
[CPU0] 001B6202: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [GICC]    at RscMgr:E029D558:001B6203 [0xC1000110] <- 0x20      : ???
E04D45A4: Taking exception 5 [IRQ]
[CPU0] [GICC]    at RscMgr:E029D4D4:E0242919 [0xC100010C] -> 0x20      : GICC_IAR
[CPU0] [INT]     at RscMgr:E029D4FA:E0242919 [0xD4011000] -> 0x28      : Requested int reason a0 (INT 28h)
[CPU0] [      RscMgr:001b61ff ] (00:0f) >>> INT-028h HPTimer 0(696C4370)
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] 001B6202: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [GICC]    at RscMgr:E029D558:001B6203 [0xC1000110] <- 0x20      : ???
[CPU0] [HPTimer] at RscMgr:E02B80CA:E05AA835 [0xC0243300] -> 0x40000   : Which timer(s) triggered
[CPU0] [HPTimer] at RscMgr:E02B8070:E05AA901 [0xC02432D4] <- 0x0       : HPTimer #13: reset trigger?
[CPU0] [HPTimer] at RscMgr:E02B8074:E05AA901 [0xC02432D4] -> 0x0       : HPTimer #13: ???
[CPU0] [HPTimer] at RscMgr:E02B80CA:E05AA99B [0xC0243300] -> 0x0       : Which timer(s) triggered
[CPU0] [      RscMgr:001b62cb ] (00:0f) <<< INT-028h HPTimer
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [INT]     at RscMgr:E029D5A2:001B62CF [0xD4011010] <- 0x28      : Enabled interrupt 28h
[CPU0] [      RscMgr:001b62cb ] (00:0f) <<< INT-01Bh dryos_timer
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
000350FC: Taking exception 5 [IRQ]
[CPU0] [GICC]    at RscMgr:E029D4D4:E02428C9 [0xC100010C] -> 0x20      : GICC_IAR
[CPU0] [      RscMgr:001b61ff ] (00:0f) >>> INT-01Bh dryos_timer 54535F4D(5F545241)
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] 001B6202: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [GICC]    at RscMgr:E029D558:001B6203 [0xC1000110] <- 0x20      : ???
[CPU0] [      RscMgr:001b62cb ] (00:0f) <<< INT-01Bh dryos_timer
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
000350F6: Taking exception 5 [IRQ]
[CPU0] [GICC]    at RscMgr:E029D4D4:E02428C9 [0xC100010C] -> 0x20      : GICC_IAR
[CPU0] [      RscMgr:001b61ff ] (00:0f) >>> INT-01Bh dryos_timer 54535F4D(5F545241)
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] 001B6202: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [GICC]    at RscMgr:E029D558:001B6203 [0xC1000110] <- 0x20      : ???
[CPU0] [      RscMgr:001b62cb ] (00:0f) <<< INT-01Bh dryos_timer
[CPU0] 001B7958: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000

This is what the serial console shows:

(https://i.ibb.co/LNM3zmV/Bildschirmfoto-2019-03-12-um-02-08-39.png) (https://ibb.co/LNM3zmV)

free image upload (https://de.imgbb.com/)


Not sure if this is normal or what to do next. I can't compare with another camera since I don't have other ROM dumps available.

Between all the messages above there are some more interesting logs for MPU as well:

Quote
[MPU] FIXME: using generic MPU spells for 77D.
[MPU] FIXME: no MPU button codes for 77D.
[MPU] Received: 06 04 02 00 00 00  (Init - spell #1)
[MPU] Sending : 2c 2a 02 00 03 03 03 04 03 00 00 48 00 00 00 14 50 00 00 00 00 81 06 00 00 04 06 00 00 04 06 00 00 04 01 01 00 00 00 00 4d 4b 01 00  (Init group)
[MPU] Sending : 06 05 01 21 01 00  (PROP_CARD2_EXISTS)
[MPU] Received: 22 20 0e 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  (unknown - unnamed)
[MPU] Received: 08 06 01 a7 00 01 00 00  (unknown - unnamed)
[MPU] Received: 08 06 00 00 02 00 00 00  (unknown - Complete WaitID)
[MPU] Received: 0a 08 03 06 00 00 00 00 00 00  (unknown - PROP_AVAIL_SHOT)
[MPU] Received: 06 04 03 10 00 00  (unknown - PROP 80030008)
[MPU] Received: 06 05 03 07 ff 00  (unknown - PROP_BURST_COUNT)
[MPU] Received: 06 05 01 2e 01 00  (unknown - PROP_SAVE_MODE)
[MPU] Received: 0a 08 03 0b 00 00 00 00 00 00  (unknown - PROP 80030007)
[MPU] Received: 06 05 03 19 01 00  (PROP_TFT_STATUS - spell #11)
[MPU] Received: 06 05 01 56 00 00  (unknown - unnamed)
[MPU] Received: 06 05 04 0e 01 00  (unknown - PROP 8002000D)
[MPU] Received: 06 05 03 40 00 00  (unknown - PROP 80030040)
[MPU] Received: 0a 09 01 55 00 00 02 00 01 00  (unknown - PROP_MULTIPLE_EXPOSURE_SETTING)
[MPU] Received: 0c 0b 03 53 02 00 48 81 81 00 00 00  (unknown - PROP 80030058)
[MPU] Received: 0c 0b 03 53 02 00 48 81 81 00 00 00  (unknown - PROP 80030058)
[MPU] Received: 06 05 03 8a 00 00  (unknown - unnamed)
[MPU] Received: 06 04 02 14 00 00  (unknown - unnamed)
[MPU] Received: 08 06 01 24 00 01 00 00  (PROP_CARD2_STATUS - spell #7)
[MPU] Sending : 08 06 01 24 00 01 00 00  (PROP_CARD2_STATUS)
[MPU] Received: 08 06 01 27 00 64 00 00  (unknown - PROP_CARD2_FOLDER_NUMBER)
[MPU] Received: 08 06 01 2a 04 e6 00 00  (unknown - PROP_CARD2_FILE_NUMBER)
[MPU] Received: 08 06 03 03 65 01 00 00  (unknown - unnamed)
[MPU] Received: 08 07 03 6a 00 02 00 00  (unknown - unnamed)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 13, 2019, 12:53:52 AM
I made some progress. I changed the create_task stub to

QuoteNSTUB(0xDF008CD3,  task_create)            /* used to start TaskMain, GuiMainTask etc */

Now the assertion message in serial console "SystemIF:KerTask.c, Task = init, Line 684" is gone.

Also I got a DEBUGMSG.LOG on the sd.img: https://gist.github.com/calle2010/f6a90f9973cf7d5e191190b45ab3f430

I have not verified all the other stubs yet.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on March 13, 2019, 01:57:03 AM
Quote from: calle2010 on March 13, 2019, 12:53:52 AM
I made some progress.

Now the assertion message in serial console "SystemIF:KerTask.c, Task = init, Line 684" is gone.

Also I got a DEBUGMSG.LOG on the sd.img: https://gist.github.com/calle2010/f6a90f9973cf7d5e191190b45ab3f430

I have not verified all the other stubs yet.
Good work calle2010!

I can't get it to boot main firmware as you got previously... my console is like you up to AUTOEXEC.bin message.

I tried to see what was getting with "-d debugmsg,int,io" but nothing special appened apart a "taking exception 2 [SVC]" message.

./run_canon_fw.sh 77D,firmware=boot=1 -d debugmsg,int,io

DebugMsg=0xDF006E6C (from GDB script)
00000000 - 3FFFFFFF: eos.ram
40000000 - 7FFFFFFF: eos.ram_uncached
DF000000 - DFFFFFFF: eos.ram_extra
E0000000 - E1FFFFFF: eos.rom0
E2000000 - E3FFFFFF: eos.rom0_mirror
E4000000 - E5FFFFFF: eos.rom0_mirror
E6000000 - E7FFFFFF: eos.rom0_mirror
E8000000 - E9FFFFFF: eos.rom0_mirror
EA000000 - EBFFFFFF: eos.rom0_mirror
EC000000 - EDFFFFFF: eos.rom0_mirror
EE000000 - EFFFFFFF: eos.rom0_mirror
F0000000 - F0FFFFFF: eos.rom1
F1000000 - F1FFFFFF: eos.rom1_mirror
F2000000 - F2FFFFFF: eos.rom1_mirror
F3000000 - F3FFFFFF: eos.rom1_mirror
F4000000 - F4FFFFFF: eos.rom1_mirror
F5000000 - F5FFFFFF: eos.rom1_mirror
F6000000 - F6FFFFFF: eos.rom1_mirror
F7000000 - F7FFFFFF: eos.rom1_mirror
F8000000 - F8FFFFFF: eos.rom1_mirror
F9000000 - F9FFFFFF: eos.rom1_mirror
FA000000 - FAFFFFFF: eos.rom1_mirror
FB000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FCFFFFFF: eos.rom1_mirror
FD000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FEFFFFFF: eos.rom1_mirror
FF000000 - FFFFFFFF: eos.rom1_mirror
BFE00000 - DEFFFFFF: eos.mmio
[EOS] enabling code execution logging.
[EOS] enabling singlestep.
[EOS] loading './77D/ROM0.BIN' to 0xE0000000-0xE1FFFFFF
[EOS] loading './77D/ROM1.BIN' to 0xF0000000-0xF0FFFFFF
[MPU] FIXME: using generic MPU spells for 77D.
[MPU] FIXME: no MPU button codes for 77D.
Start address: 0xE0000000
Setting BOOTDISK flag to FFFFFFFF
[CPU0] E00075E0: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [DIGIC6]       at 0xE00075F8:00000000 [0xDE000008] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE00075FA:00000000 [0xDE000000] -> 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0007600:00000000 [0xDE000000] <- 0x40      : ???
[CPU0] E0007624: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xE000001D
[CPU0] E0007632: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x8C50078
[CPU0] E0007628: MCR p15, ...          : CACHEMAINT x1 (omitted)
[CPU0] E0007656: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C50878
[CPU0] E0004AC6: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x48C50878
[CPU0] E0004AD2: MCR p15, ...          : CACHEMAINT x3 (omitted)
[CPU0] E0004AD6: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x48C51878
[CPU0] [DIGIC6]       at 0xE0004DCA:E0004E9B [0xD209F208] <- 0x5930    : ???
[CPU0] [DIGIC6]       at 0xE0004DDA:E0004E9B [0xD209F208] <- 0x5932    : ???
[CPU0] [DIGIC6]       at 0xE0004DE2:E0004E9B [0xD209F200] <- 0x6320    : ???
[CPU0] [DIGIC6]       at 0xE0004DF2:E0004E9B [0xD209F200] <- 0x6322    : ???
[CPU0] [DIGIC6]       at 0xE0004DF8:E0004E9B [0xD209F204] <- 0x73F10   : ???
[CPU0] [DIGIC6]       at 0xE0004DFE:E0004E9B [0xD209F204] <- 0x33F10   : ???
[CPU0] [DIGIC6]       at 0xE0004E0C:E0004E9B [0xD209F204] <- 0x13F10   : ???
[CPU0] [DIGIC6]       at 0xE0004E14:E0004E9B [0xD209F204] <- 0x3F10    : ???
[CPU0] [DIGIC6]       at 0xE0004E26:E0004E9B [0xD209F204] <- 0x3F12    : ???
[CPU0] [DIGIC6]       at 0xE0004E2E:E0004E9B [0xD2090040] <- 0x3       : ???
[CPU0] [DIGIC6]       at 0xE0004E36:E0004E9B [0xD209F218] <- 0x4010    : ???
[CPU0] [DIGIC6]       at 0xE0004E4E:E0004E9B [0xD209F218] <- 0x4012    : ???
[CPU0] [DIGIC6]       at 0xDF02000A:E0004EB5 [0xD208005C] <- 0x800040  : ???
[CPU0] [DIGIC6]       at 0xDF020012:E0004EB5 [0xDE000014] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0xDF020016:E0004EB5 [0xDE000010] <- 0x9F      : ???
[CPU0] [DIGIC6]       at 0xDF020018:E0004EB5 [0xDE000010] -> 0x0       : ???
[CPU0] [DIGIC6]       at 0xDF02001C:E0004EB5 [0xDE000010] -> 0x0       : ???
[CPU0] [DIGIC6]       at 0xDF02001E:E0004EB5 [0xDE000010] -> 0x0       : ???
[CPU0] [DIGIC6]       at 0xDF020024:E0004EB5 [0xDE000014] <- 0x1       : ???
[CPU0] [ROMID]        at 0xDF020028:E0004EB5 [0xBFE01FD0] <- 0x0       : SROM ID
[CPU0] [ROMID]        at 0xDF02002C:E0004EB5 [0xBFE01FD2] <- 0x0       : SROM ID
[CPU0] [ROMID]        at 0xDF020030:E0004EB5 [0xBFE01FD4] <- 0x0       : SROM ID
[CPU0] [DIGIC6]       at 0xE0005E14:E0004EBB [0xD2090008] <- 0x430C04  : CLOCK_ENABLE
[CPU0] [DIGIC6]       at 0xE0005E1C:E0004EBB [0xD209002C] <- 0x1000    : ???
[CPU0] [DIGIC6]       at 0xE0005E24:E0004EBB [0xD20900D0] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0xE0005E2A:E0004EBB [0xD209B050] <- 0x98000021: ???
[CPU0] [DIGIC6]       at 0xE0005E32:E0004EBB [0xD209B070] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E3A:E0004EBB [0xD209B080] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E42:E0004EBB [0xD209B100] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E4A:E0004EBB [0xD209B110] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E52:E0004EBB [0xD209B220] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E5A:E0004EBB [0xD209B2D0] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E62:E0004EBB [0xD209B520] <- 0x16000000: ???
[CPU0] [DIGIC6]       at 0xE0005E6A:E0004EBB [0xD209B550] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E72:E0004EBB [0xD209B560] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E7A:E0004EBB [0xD209B590] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E82:E0004EBB [0xD209B600] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E8A:E0004EBB [0xD209B610] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0005E92:E0004EBB [0xD209B620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0xE0004EC0:E0004EBB [0xD2040128] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0xE0004EC8:E0004EBB [0xD204012C] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0xE0004ED0:E0004EBB [0xD2040130] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0xE0004ED8:E0004EBB [0xD2040134] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0xE0004EE0:E0004EBB [0xD2040138] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0xE0004EE8:E0004EBB [0xD204013C] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0xE0004EF0:E0004EBB [0xD2040140] <- 0x80000000: ???

...

[CPU0] [SDIO]         at 0x00106D06:00106B71 [0xC805000C] <- 0x11      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:00106B71 [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00106D00:00106B81 [0xC8050024] <- 0x4000    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:00106B81 [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106D04:00106B81 [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:00106B81 [0xC805000C] <- 0x11      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:00106B81 [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107852:00106B91 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x00107854:00106B91 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:00107873 [0xC8050024] <- 0x4800    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:00107873 [0xC8050020] <- 0x1AA01   : cmd_lo
[CPU0] [SDIO]         at 0x00106D04:00107873 [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:00107873 [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:00107873 [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x0010754C:00106D59 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00106D59 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x7700    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x12000   : Response[0]
[CPU0] [SDIO]         at 0x001076AA:00106D79 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x001076AC:00106D79 [0xC805002C] <- 0x80000000: response setup?
[CPU0] [SDIO]         at 0x00106D00:001076CB [0xC8050024] <- 0x6940    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:001076CB [0xC8050020] <- 0x10000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:001076CB [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:001076CB [0xC805000C] <- 0x2       : Command flags?
[CPU0] [SDIO]         at 0x00106D08:001076CB [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x001076D0:001076CB [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x001076D2:001076CB [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x001076D4:001076CB [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x001076D6:001076CB [0xC8050038] -> 0x80      : Response[1]
[CPU0] [SDIO]         at 0x001076D8:001076CB [0xC8050034] -> 0xFFFF0000: Response[0]
[CPU0] [SDIO]         at 0x001075DC:00106BB7 [0xC8050028] <- 0x88      : Response size (bits)
[CPU0] [SDIO]         at 0x001075DE:00106BB7 [0xC805002C] <- 0x7F08    : response setup?
[CPU0] [SDIO]         at 0x00106D00:001075FD [0xC8050024] <- 0x4200    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:001075FD [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106D04:001075FD [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:001075FD [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:001075FD [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107602:001075FD [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107604:001075FD [0xC8050040] -> 0xAA585951: Response[3]
[CPU0] [SDIO]         at 0x00107606:001075FD [0xC805003C] -> 0x454D5521: Response[2]
[CPU0] [SDIO]         at 0x00107608:001075FD [0xC8050038] -> 0x1DEADBE : Response[1]
[CPU0] [SDIO]         at 0x0010760A:001075FD [0xC8050034] -> 0xEF006219: Response[0]
[CPU0] [SDIO]         at 0x001077C2:00106BCF [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x001077C4:00106BCF [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:001077E3 [0xC8050024] <- 0x4300    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:001077E3 [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106D04:001077E3 [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:001077E3 [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:001077E3 [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x001077E8:001077E3 [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x001077EA:001077E3 [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x001077EC:001077E3 [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x001077EE:001077E3 [0xC8050038] -> 0x45      : Response[1]
[CPU0] [SDIO]         at 0x001077F0:001077E3 [0xC8050034] -> 0x67050000: Response[0]
[CPU0] [SDIO]         at 0x001075DC:00106E4B [0xC8050028] <- 0x88      : Response size (bits)
[CPU0] [SDIO]         at 0x001075DE:00106E4B [0xC805002C] <- 0x7F08    : response setup?
[CPU0] [SDIO]         at 0x00106D00:001075FD [0xC8050024] <- 0x4945    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:001075FD [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:001075FD [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:001075FD [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:001075FD [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107602:001075FD [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107604:001075FD [0xC8050040] -> 0x26005A  : Response[3]
[CPU0] [SDIO]         at 0x00107606:001075FD [0xC805003C] -> 0x5F59E0F7: Response[2]
[CPU0] [SDIO]         at 0x00107608:001075FD [0xC8050038] -> 0x7FFFDFFF: Response[1]
[CPU0] [SDIO]         at 0x0010760A:001075FD [0xC8050034] -> 0x92600047: Response[0]
[CPU0] [SDIO]         at 0x0010754C:00106BED [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00106BED [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4745    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x70000   : Response[0]
[CPU0] [SDIO]         at 0x0010754C:00106BFD [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00106BFD [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x7745    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x92000   : Response[0]
[CPU0] [SDIO]         at 0x0010754C:00106C0D [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00106C0D [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x6A45    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x92000   : Response[0]
[CPU0] [SDIO]         at 0x0010754C:00106E69 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00106E69 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x7745    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x92000   : Response[0]
[CPU0] [SDIO]         at 0x00106E82:00106E69 [0xC8050010] <- 0x0       : Status
[CPU0] [SDIO]         at 0x00106E84:00106E69 [0xC805007C] <- 0x1       : transfer block count
[CPU0] [SDIO]         at 0x00106E86:00106E69 [0xC8050068] <- 0x40      : read block size
[CPU0] [SDIO]         at 0x001074EA:00106E8D [0xC8050088] <- 0x30      : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x001074B8:001074FB [0xD209063C] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074C0:001074FB [0xD2090614] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074D0:001074FB [0xD2090610] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0x001074D8:001074FB [0xD2090608] <- 0x0       : ???
[CPU0] [SDIO]         at 0x00107508:001074FB [0xC8050088] <- 0x0       : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x0010742A:00107511 [0xD209F100] <- 0xA       : ???
[CPU0] [DIGIC6]       at 0x00107430:00107511 [0xD2090600] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107438:00107511 [0xD2090618] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010743E:00107511 [0xD209061C] <- 0x1D000901: ???
[CPU0] [DIGIC6]       at 0x00107446:00107511 [0xD2090620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010744E:00107511 [0xD209062C] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x00107456:00107511 [0xD2090630] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x0010745E:00107511 [0xD2090624] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x00107466:00107511 [0xD2090628] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010746E:00107511 [0xD2090638] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x00107476:00107511 [0xD2090604] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010747E:00107511 [0xD209060C] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010748E:00107511 [0xD2090608] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107496:00107511 [0xD2090610] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010749E:00107511 [0xD2090614] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x001074A6:00107511 [0xD209063C] <- 0x1       : ???
[CPU0] [SDIO]         at 0x00106F48:00106E99 [0xC8050024] <- 0x4D00    : cmd_hi
[CPU0] [SDIO]         at 0x00106F4A:00106E99 [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106F4C:00106E99 [0xC8050010] <- 0x0       : Status
[CPU0] [SDIO]         at 0x00106F4E:00106E99 [0xC805000C] <- 0x14      : Command flags?
[CPU0] [SDIO]         at 0x00106EA4:00106E99 [0xC8050010] -> 0x200001  : Status
[CPU0] [SDIO]         at 0x00106EB4:00106E99 [0xC8050010] <- 0xFFDFFFFE: Status
[CPU0] [SDIO]         at 0x00106EBA:00106E99 [0xC8050010] -> 0x0       : Status
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EBA:00106E99 [0xC8050010] -> 0x0       : Status
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EBA:00106E99 [0xC8050010] -> 0x0       : Status
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EBA:00106E99 [0xC8050010] -> 0x0       : Status
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106EE2:00106E99 [0xC805006C] -> 0x0       : FIFO data
[CPU0] [SDIO]         at 0x00106EEC:00106E99 [0xC8050010] -> 0x200001  : Status
[CPU0] [SDIO]         at 0x00106EF4:00106E99 [0xC8050084] -> 0x0       : SDREP: Status register/error codes
[CPU0] [SDIO]         at 0x00106C42:00106C11 [0xC8050064] <- 0x61000A  : bus width
[CPU0] [SDIO]         at 0x00106C46:00106C11 [0xC8050058] <- 0x41000A  : bus width
[CPU0] [DIGIC6]       at 0x001074B8:00106C4D [0xD209063C] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074C0:00106C4D [0xD2090614] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074D0:00106C4D [0xD2090610] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0x001074D8:00106C4D [0xD2090608] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010742A:00106C51 [0xD209F100] <- 0xA       : ???
[CPU0] [DIGIC6]       at 0x00107430:00106C51 [0xD2090600] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107438:00106C51 [0xD2090618] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010743E:00106C51 [0xD209061C] <- 0x1D000901: ???
[CPU0] [DIGIC6]       at 0x00107446:00106C51 [0xD2090620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010744E:00106C51 [0xD209062C] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x00107456:00106C51 [0xD2090630] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x0010745E:00106C51 [0xD2090624] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x00107466:00106C51 [0xD2090628] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010746E:00106C51 [0xD2090638] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x00107476:00106C51 [0xD2090604] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010747E:00106C51 [0xD209060C] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010748E:00106C51 [0xD2090608] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107496:00106C51 [0xD2090610] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010749E:00106C51 [0xD2090614] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x001074A6:00106C51 [0xD209063C] <- 0x1       : ???
[CPU0] [SDIO]         at 0x00106C58:00106C51 [0xC8050058] -> 0x0       : bus width
[CPU0] [SDIO]         at 0x00106C62:00106C51 [0xC8050058] <- 0x1       : bus width
[CPU0] [SDIO]         at 0x00106C66:00106C51 [0xC8050064] -> 0x0       : bus width
[CPU0] [SDIO]         at 0x00106C70:00106C51 [0xC8050064] <- 0x1       : bus width
[CPU0] [SDIO]         at 0x0010754C:00106C87 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00106C87 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x7745    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x92000   : Response[0]
[CPU0] [SDIO]         at 0x0010754C:00106C97 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00106C97 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4600    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x201     : cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x92000   : Response[0]
[CPU0] [SDIO]         at 0x00106FB0:00105C5F [0xC8050010] <- 0x0       : Status
[CPU0] [SDIO]         at 0x00106FB6:00105C5F [0xC8050068] <- 0x200     : read block size
[CPU0] [SDIO]         at 0x00106FBC:00105C5F [0xC805007C] <- 0x1       : transfer block count
[CPU0] [SDIO]         at 0x001074EA:00106FC3 [0xC8050088] <- 0x30      : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x001074B8:001074FB [0xD209063C] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074C0:001074FB [0xD2090614] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074D0:001074FB [0xD2090610] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0x001074D8:001074FB [0xD2090608] <- 0x0       : ???
[CPU0] [SDIO]         at 0x00107508:001074FB [0xC8050088] <- 0x0       : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x0010742A:00107511 [0xD209F100] <- 0xA       : ???
[CPU0] [DIGIC6]       at 0x00107430:00107511 [0xD2090600] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107438:00107511 [0xD2090618] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010743E:00107511 [0xD209061C] <- 0x1D000901: ???
[CPU0] [DIGIC6]       at 0x00107446:00107511 [0xD2090620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010744E:00107511 [0xD209062C] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x00107456:00107511 [0xD2090630] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x0010745E:00107511 [0xD2090624] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x00107466:00107511 [0xD2090628] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010746E:00107511 [0xD2090638] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x00107476:00107511 [0xD2090604] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010747E:00107511 [0xD209060C] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010748E:00107511 [0xD2090608] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107496:00107511 [0xD2090610] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010749E:00107511 [0xD2090614] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x001074A6:00107511 [0xD209063C] <- 0x1       : ???
[CPU0] [SDIO]         at 0x00106FC8:00106FC3 [0xC8050008] <- 0xF1      : DMA
[CPU0] [SDDMA]        at 0x00106FD0:00106FC3 [0xC8020000] <- 0x44000000: Transfer memory address
[CPU0] [SDDMA]        at 0x00106FE0:00106FC3 [0xC8020004] <- 0x200     : Transfer byte count
[CPU0] [SDDMA]        at 0x00106FE6:00106FC3 [0xC8020018] <- 0x0       : ???
[CPU0] [SDDMA]        at 0x00106FEC:00106FC3 [0xC8020010] <- 0x39      : Command/Status?
[CPU0] [SDIO]         at 0x00106F48:00106FFF [0xC8050024] <- 0x5100    : cmd_hi
[CPU0] [SDIO]         at 0x00106F4A:00106FFF [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106F4C:00106FFF [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[EOS] trigger int 0xBE (delayed!)
[CPU0] [SDIO]         at 0x00106F4E:00106FFF [0xC805000C] <- 0x14      : Command flags?
[CPU0] [SDDMA]        at 0x0010700C:00106FFF [0xC8020010] -> 0x0       : Command/Status?
[CPU0] [SDIO]         at 0x00107016:00106FFF [0xC8050010] -> 0x200001  : Status
[CPU0] [SDIO]         at 0x00107024:00106FFF [0xC8050008] <- 0x0       : DMA
[CPU0] [SDIO]         at 0x00107032:00106FFF [0xC8050080] -> 0x1       : transferred blocks
[CPU0] [SDIO]         at 0x0010754C:00107071 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107071 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4D45    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x90000   : Response[0]
[CPU0] [SDIO]         at 0x00106FB0:00105C5F [0xC8050010] <- 0x0       : Status
[CPU0] [SDIO]         at 0x00106FB6:00105C5F [0xC8050068] <- 0x200     : read block size
[CPU0] [SDIO]         at 0x00106FBC:00105C5F [0xC805007C] <- 0x1       : transfer block count
[CPU0] [SDIO]         at 0x001074EA:00106FC3 [0xC8050088] <- 0x30      : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x001074B8:001074FB [0xD209063C] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074C0:001074FB [0xD2090614] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074D0:001074FB [0xD2090610] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0x001074D8:001074FB [0xD2090608] <- 0x0       : ???
[CPU0] [SDIO]         at 0x00107508:001074FB [0xC8050088] <- 0x0       : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x0010742A:00107511 [0xD209F100] <- 0xA       : ???
[CPU0] [DIGIC6]       at 0x00107430:00107511 [0xD2090600] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107438:00107511 [0xD2090618] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010743E:00107511 [0xD209061C] <- 0x1D000901: ???
[CPU0] [DIGIC6]       at 0x00107446:00107511 [0xD2090620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010744E:00107511 [0xD209062C] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x00107456:00107511 [0xD2090630] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x0010745E:00107511 [0xD2090624] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x00107466:00107511 [0xD2090628] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010746E:00107511 [0xD2090638] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x00107476:00107511 [0xD2090604] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010747E:00107511 [0xD209060C] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010748E:00107511 [0xD2090608] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107496:00107511 [0xD2090610] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010749E:00107511 [0xD2090614] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x001074A6:00107511 [0xD209063C] <- 0x1       : ???
[CPU0] [SDIO]         at 0x00106FC8:00106FC3 [0xC8050008] <- 0xF1      : DMA
[CPU0] [SDDMA]        at 0x00106FD0:00106FC3 [0xC8020000] <- 0x44000000: Transfer memory address
[CPU0] [SDDMA]        at 0x00106FE0:00106FC3 [0xC8020004] <- 0x200     : Transfer byte count
[CPU0] [SDDMA]        at 0x00106FE6:00106FC3 [0xC8020018] <- 0x0       : ???
[CPU0] [SDDMA]        at 0x00106FEC:00106FC3 [0xC8020010] <- 0x39      : Command/Status?
[CPU0] [SDIO]         at 0x00106F48:00106FFF [0xC8050024] <- 0x5100    : cmd_hi
[CPU0] [SDIO]         at 0x00106F4A:00106FFF [0xC8050020] <- 0xC60001  : cmd_lo
[CPU0] [SDIO]         at 0x00106F4C:00106FFF [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[EOS] trigger int 0xBE (delayed!)
[CPU0] [SDIO]         at 0x00106F4E:00106FFF [0xC805000C] <- 0x14      : Command flags?
[CPU0] [SDDMA]        at 0x0010700C:00106FFF [0xC8020010] -> 0x0       : Command/Status?
[CPU0] [SDIO]         at 0x00107016:00106FFF [0xC8050010] -> 0x200001  : Status
[CPU0] [SDIO]         at 0x00107024:00106FFF [0xC8050008] <- 0x0       : DMA
[CPU0] [SDIO]         at 0x00107032:00106FFF [0xC8050080] -> 0x1       : transferred blocks
[CPU0] [SDIO]         at 0x0010754C:00107071 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107071 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4D45    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x90000   : Response[0]
SLOT_A LOAD OK.
[CPU0] [GPIO]         at 0x00101774:00101A57 [0xD208016C] <- 0xD0002   : Card LED
Open file for read : AUTOEXEC.BIN
[CPU0] [SDIO]         at 0x00106FB0:00105C5F [0xC8050010] <- 0x0       : Status
[CPU0] [SDIO]         at 0x00106FB6:00105C5F [0xC8050068] <- 0x200     : read block size
[CPU0] [SDIO]         at 0x00106FBC:00105C5F [0xC805007C] <- 0x1       : transfer block count
[CPU0] [SDIO]         at 0x001074EA:00106FC3 [0xC8050088] <- 0x30      : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x001074B8:001074FB [0xD209063C] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074C0:001074FB [0xD2090614] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074D0:001074FB [0xD2090610] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0x001074D8:001074FB [0xD2090608] <- 0x0       : ???
[CPU0] [SDIO]         at 0x00107508:001074FB [0xC8050088] <- 0x0       : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x0010742A:00107511 [0xD209F100] <- 0xA       : ???
[CPU0] [DIGIC6]       at 0x00107430:00107511 [0xD2090600] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107438:00107511 [0xD2090618] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010743E:00107511 [0xD209061C] <- 0x1D000901: ???
[CPU0] [DIGIC6]       at 0x00107446:00107511 [0xD2090620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010744E:00107511 [0xD209062C] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x00107456:00107511 [0xD2090630] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x0010745E:00107511 [0xD2090624] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x00107466:00107511 [0xD2090628] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010746E:00107511 [0xD2090638] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x00107476:00107511 [0xD2090604] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010747E:00107511 [0xD209060C] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010748E:00107511 [0xD2090608] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107496:00107511 [0xD2090610] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010749E:00107511 [0xD2090614] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x001074A6:00107511 [0xD209063C] <- 0x1       : ???
[CPU0] [SDIO]         at 0x00106FC8:00106FC3 [0xC8050008] <- 0xF1      : DMA
[CPU0] [SDDMA]        at 0x00106FD0:00106FC3 [0xC8020000] <- 0x44000000: Transfer memory address
[CPU0] [SDDMA]        at 0x00106FE0:00106FC3 [0xC8020004] <- 0x200     : Transfer byte count
[CPU0] [SDDMA]        at 0x00106FE6:00106FC3 [0xC8020018] <- 0x0       : ???
[CPU0] [SDDMA]        at 0x00106FEC:00106FC3 [0xC8020010] <- 0x39      : Command/Status?
[CPU0] [SDIO]         at 0x00106F48:00106FFF [0xC8050024] <- 0x5100    : cmd_hi
[CPU0] [SDIO]         at 0x00106F4A:00106FFF [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106F4C:00106FFF [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[EOS] trigger int 0xBE (delayed!)
[CPU0] [SDIO]         at 0x00106F4E:00106FFF [0xC805000C] <- 0x14      : Command flags?
[CPU0] [SDDMA]        at 0x0010700C:00106FFF [0xC8020010] -> 0x0       : Command/Status?
[CPU0] [SDIO]         at 0x00107016:00106FFF [0xC8050010] -> 0x200001  : Status
[CPU0] [SDIO]         at 0x00107024:00106FFF [0xC8050008] <- 0x0       : DMA
[CPU0] [SDIO]         at 0x00107032:00106FFF [0xC8050080] -> 0x1       : transferred blocks
[CPU0] [SDIO]         at 0x0010754C:00107071 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107071 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4D45    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x90000   : Response[0]
[CPU0] [SDIO]         at 0x00106FB0:00105C5F [0xC8050010] <- 0x0       : Status
[CPU0] [SDIO]         at 0x00106FB6:00105C5F [0xC8050068] <- 0x200     : read block size
[CPU0] [SDIO]         at 0x00106FBC:00105C5F [0xC805007C] <- 0x1       : transfer block count
[CPU0] [SDIO]         at 0x001074EA:00106FC3 [0xC8050088] <- 0x30      : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x001074B8:001074FB [0xD209063C] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074C0:001074FB [0xD2090614] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074D0:001074FB [0xD2090610] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0x001074D8:001074FB [0xD2090608] <- 0x0       : ???
[CPU0] [SDIO]         at 0x00107508:001074FB [0xC8050088] <- 0x0       : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x0010742A:00107511 [0xD209F100] <- 0xA       : ???
[CPU0] [DIGIC6]       at 0x00107430:00107511 [0xD2090600] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107438:00107511 [0xD2090618] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010743E:00107511 [0xD209061C] <- 0x1D000901: ???
[CPU0] [DIGIC6]       at 0x00107446:00107511 [0xD2090620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010744E:00107511 [0xD209062C] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x00107456:00107511 [0xD2090630] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x0010745E:00107511 [0xD2090624] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x00107466:00107511 [0xD2090628] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010746E:00107511 [0xD2090638] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x00107476:00107511 [0xD2090604] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010747E:00107511 [0xD209060C] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010748E:00107511 [0xD2090608] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107496:00107511 [0xD2090610] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010749E:00107511 [0xD2090614] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x001074A6:00107511 [0xD209063C] <- 0x1       : ???
[CPU0] [SDIO]         at 0x00106FC8:00106FC3 [0xC8050008] <- 0xF1      : DMA
[CPU0] [SDDMA]        at 0x00106FD0:00106FC3 [0xC8020000] <- 0x44000000: Transfer memory address
[CPU0] [SDDMA]        at 0x00106FE0:00106FC3 [0xC8020004] <- 0x200     : Transfer byte count
[CPU0] [SDDMA]        at 0x00106FE6:00106FC3 [0xC8020018] <- 0x0       : ???
[CPU0] [SDDMA]        at 0x00106FEC:00106FC3 [0xC8020010] <- 0x39      : Command/Status?
[CPU0] [SDIO]         at 0x00106F48:00106FFF [0xC8050024] <- 0x5100    : cmd_hi
[CPU0] [SDIO]         at 0x00106F4A:00106FFF [0xC8050020] <- 0xC60001  : cmd_lo
[CPU0] [SDIO]         at 0x00106F4C:00106FFF [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[EOS] trigger int 0xBE (delayed!)
[CPU0] [SDIO]         at 0x00106F4E:00106FFF [0xC805000C] <- 0x14      : Command flags?
[CPU0] [SDDMA]        at 0x0010700C:00106FFF [0xC8020010] -> 0x0       : Command/Status?
[CPU0] [SDIO]         at 0x00107016:00106FFF [0xC8050010] -> 0x200001  : Status
[CPU0] [SDIO]         at 0x00107024:00106FFF [0xC8050008] <- 0x0       : DMA
[CPU0] [SDIO]         at 0x00107032:00106FFF [0xC8050080] -> 0x1       : transferred blocks
[CPU0] [SDIO]         at 0x0010754C:00107071 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107071 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4D45    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x90000   : Response[0]
[CPU0] [SDIO]         at 0x00106FB0:00105C5F [0xC8050010] <- 0x0       : Status
[CPU0] [SDIO]         at 0x00106FB6:00105C5F [0xC8050068] <- 0x200     : read block size
[CPU0] [SDIO]         at 0x00106FBC:00105C5F [0xC805007C] <- 0x3E      : transfer block count
[CPU0] [SDIO]         at 0x001074EA:00106FC3 [0xC8050088] <- 0x30      : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x001074B8:001074FB [0xD209063C] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074C0:001074FB [0xD2090614] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074D0:001074FB [0xD2090610] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0x001074D8:001074FB [0xD2090608] <- 0x0       : ???
[CPU0] [SDIO]         at 0x00107508:001074FB [0xC8050088] <- 0x0       : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x0010742A:00107511 [0xD209F100] <- 0xA       : ???
[CPU0] [DIGIC6]       at 0x00107430:00107511 [0xD2090600] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107438:00107511 [0xD2090618] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010743E:00107511 [0xD209061C] <- 0x1D000901: ???
[CPU0] [DIGIC6]       at 0x00107446:00107511 [0xD2090620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010744E:00107511 [0xD209062C] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x00107456:00107511 [0xD2090630] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x0010745E:00107511 [0xD2090624] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x00107466:00107511 [0xD2090628] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010746E:00107511 [0xD2090638] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x00107476:00107511 [0xD2090604] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010747E:00107511 [0xD209060C] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010748E:00107511 [0xD2090608] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107496:00107511 [0xD2090610] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010749E:00107511 [0xD2090614] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x001074A6:00107511 [0xD209063C] <- 0x1       : ???
[CPU0] [SDIO]         at 0x00106FC8:00106FC3 [0xC8050008] <- 0xF1      : DMA
[CPU0] [SDDMA]        at 0x00106FD0:00106FC3 [0xC8020000] <- 0x46001E00: Transfer memory address
[CPU0] [SDDMA]        at 0x00106FE0:00106FC3 [0xC8020004] <- 0x7C00    : Transfer byte count
[CPU0] [SDDMA]        at 0x00106FE6:00106FC3 [0xC8020018] <- 0x0       : ???
[CPU0] [SDDMA]        at 0x00106FEC:00106FC3 [0xC8020010] <- 0x39      : Command/Status?
[CPU0] [SDIO]         at 0x00106F48:0010700B [0xC8050024] <- 0x5200    : cmd_hi
[CPU0] [SDIO]         at 0x00106F4A:0010700B [0xC8050020] <- 0xC80001  : cmd_lo
[CPU0] [SDIO]         at 0x00106F4C:0010700B [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[EOS] trigger int 0xBE (delayed!)
[CPU0] [SDIO]         at 0x00106F4E:0010700B [0xC805000C] <- 0x14      : Command flags?
[CPU0] [SDDMA]        at 0x0010700C:0010700B [0xC8020010] -> 0x0       : Command/Status?
[CPU0] [SDIO]         at 0x00107016:0010700B [0xC8050010] -> 0x200001  : Status
[CPU0] [SDIO]         at 0x00107024:0010700B [0xC8050008] <- 0x0       : DMA
[CPU0] [SDIO]         at 0x00107032:0010700B [0xC8050080] -> 0x3E      : transferred blocks
[CPU0] [SDIO]         at 0x0010754C:00107061 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107061 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4C00    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0xB0000   : Response[0]
[CPU0] [SDIO]         at 0x0010754C:00107071 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107071 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4D45    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x90000   : Response[0]
[CPU0] [SDIO]         at 0x00106FB0:00105C5F [0xC8050010] <- 0x0       : Status
[CPU0] [SDIO]         at 0x00106FB6:00105C5F [0xC8050068] <- 0x200     : read block size
[CPU0] [SDIO]         at 0x00106FBC:00105C5F [0xC805007C] <- 0x20      : transfer block count
[CPU0] [SDIO]         at 0x001074EA:00106FC3 [0xC8050088] <- 0x30      : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x001074B8:001074FB [0xD209063C] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074C0:001074FB [0xD2090614] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074D0:001074FB [0xD2090610] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0x001074D8:001074FB [0xD2090608] <- 0x0       : ???
[CPU0] [SDIO]         at 0x00107508:001074FB [0xC8050088] <- 0x0       : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x0010742A:00107511 [0xD209F100] <- 0xA       : ???
[CPU0] [DIGIC6]       at 0x00107430:00107511 [0xD2090600] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107438:00107511 [0xD2090618] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010743E:00107511 [0xD209061C] <- 0x1D000901: ???
[CPU0] [DIGIC6]       at 0x00107446:00107511 [0xD2090620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010744E:00107511 [0xD209062C] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x00107456:00107511 [0xD2090630] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x0010745E:00107511 [0xD2090624] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x00107466:00107511 [0xD2090628] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010746E:00107511 [0xD2090638] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x00107476:00107511 [0xD2090604] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010747E:00107511 [0xD209060C] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010748E:00107511 [0xD2090608] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107496:00107511 [0xD2090610] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010749E:00107511 [0xD2090614] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x001074A6:00107511 [0xD209063C] <- 0x1       : ???
[CPU0] [SDIO]         at 0x00106FC8:00106FC3 [0xC8050008] <- 0xF1      : DMA
[CPU0] [SDDMA]        at 0x00106FD0:00106FC3 [0xC8020000] <- 0x48001E00: Transfer memory address
[CPU0] [SDDMA]        at 0x00106FE0:00106FC3 [0xC8020004] <- 0x4000    : Transfer byte count
[CPU0] [SDDMA]        at 0x00106FE6:00106FC3 [0xC8020018] <- 0x0       : ???
[CPU0] [SDDMA]        at 0x00106FEC:00106FC3 [0xC8020010] <- 0x39      : Command/Status?
[CPU0] [SDIO]         at 0x00106F48:0010700B [0xC8050024] <- 0x5200    : cmd_hi
[CPU0] [SDIO]         at 0x00106F4A:0010700B [0xC8050020] <- 0x1C00001 : cmd_lo
[CPU0] [SDIO]         at 0x00106F4C:0010700B [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[EOS] trigger int 0xBE (delayed!)
[CPU0] [SDIO]         at 0x00106F4E:0010700B [0xC805000C] <- 0x14      : Command flags?
[CPU0] [SDDMA]        at 0x0010700C:0010700B [0xC8020010] -> 0x0       : Command/Status?
[CPU0] [SDIO]         at 0x00107016:0010700B [0xC8050010] -> 0x200001  : Status
[CPU0] [SDIO]         at 0x00107024:0010700B [0xC8050008] <- 0x0       : DMA
[CPU0] [SDIO]         at 0x00107032:0010700B [0xC8050080] -> 0x20      : transferred blocks
[CPU0] [SDIO]         at 0x0010754C:00107061 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107061 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4C00    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0xB0000   : Response[0]
[CPU0] [SDIO]         at 0x0010754C:00107071 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107071 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4D45    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x90000   : Response[0]
File size : 0x71A0
[CPU0] [SDIO]         at 0x00106FB0:00105C5F [0xC8050010] <- 0x0       : Status
[CPU0] [SDIO]         at 0x00106FB6:00105C5F [0xC8050068] <- 0x200     : read block size
[CPU0] [SDIO]         at 0x00106FBC:00105C5F [0xC805007C] <- 0x20      : transfer block count
[CPU0] [SDIO]         at 0x001074EA:00106FC3 [0xC8050088] <- 0x30      : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x001074B8:001074FB [0xD209063C] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074C0:001074FB [0xD2090614] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074D0:001074FB [0xD2090610] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0x001074D8:001074FB [0xD2090608] <- 0x0       : ???
[CPU0] [SDIO]         at 0x00107508:001074FB [0xC8050088] <- 0x0       : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x0010742A:00107511 [0xD209F100] <- 0xA       : ???
[CPU0] [DIGIC6]       at 0x00107430:00107511 [0xD2090600] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107438:00107511 [0xD2090618] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010743E:00107511 [0xD209061C] <- 0x1D000901: ???
[CPU0] [DIGIC6]       at 0x00107446:00107511 [0xD2090620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010744E:00107511 [0xD209062C] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x00107456:00107511 [0xD2090630] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x0010745E:00107511 [0xD2090624] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x00107466:00107511 [0xD2090628] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010746E:00107511 [0xD2090638] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x00107476:00107511 [0xD2090604] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010747E:00107511 [0xD209060C] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010748E:00107511 [0xD2090608] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107496:00107511 [0xD2090610] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010749E:00107511 [0xD2090614] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x001074A6:00107511 [0xD209063C] <- 0x1       : ???
[CPU0] [SDIO]         at 0x00106FC8:00106FC3 [0xC8050008] <- 0xF1      : DMA
[CPU0] [SDDMA]        at 0x00106FD0:00106FC3 [0xC8020000] <- 0x44001800: Transfer memory address
[CPU0] [SDDMA]        at 0x00106FE0:00106FC3 [0xC8020004] <- 0x4000    : Transfer byte count
[CPU0] [SDDMA]        at 0x00106FE6:00106FC3 [0xC8020018] <- 0x0       : ???
[CPU0] [SDDMA]        at 0x00106FEC:00106FC3 [0xC8020010] <- 0x39      : Command/Status?
[CPU0] [SDIO]         at 0x00106F48:0010700B [0xC8050024] <- 0x5200    : cmd_hi
[CPU0] [SDIO]         at 0x00106F4A:0010700B [0xC8050020] <- 0x23800001: cmd_lo
[CPU0] [SDIO]         at 0x00106F4C:0010700B [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[EOS] trigger int 0xBE (delayed!)
[CPU0] [SDIO]         at 0x00106F4E:0010700B [0xC805000C] <- 0x14      : Command flags?
[CPU0] [SDDMA]        at 0x0010700C:0010700B [0xC8020010] -> 0x0       : Command/Status?
[CPU0] [SDIO]         at 0x00107016:0010700B [0xC8050010] -> 0x200001  : Status
[CPU0] [SDIO]         at 0x00107024:0010700B [0xC8050008] <- 0x0       : DMA
[CPU0] [SDIO]         at 0x00107032:0010700B [0xC8050080] -> 0x20      : transferred blocks
[CPU0] [SDIO]         at 0x0010754C:00107061 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107061 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4C00    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0xB0000   : Response[0]
[CPU0] [SDIO]         at 0x0010754C:00107071 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107071 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4D45    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x90000   : Response[0]
[CPU0] [SDIO]         at 0x00106FB0:00105C5F [0xC8050010] <- 0x0       : Status
[CPU0] [SDIO]         at 0x00106FB6:00105C5F [0xC8050068] <- 0x200     : read block size
[CPU0] [SDIO]         at 0x00106FBC:00105C5F [0xC805007C] <- 0x20      : transfer block count
[CPU0] [SDIO]         at 0x001074EA:00106FC3 [0xC8050088] <- 0x30      : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x001074B8:001074FB [0xD209063C] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074C0:001074FB [0xD2090614] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x001074D0:001074FB [0xD2090610] <- 0x80000000: ???
[CPU0] [DIGIC6]       at 0x001074D8:001074FB [0xD2090608] <- 0x0       : ???
[CPU0] [SDIO]         at 0x00107508:001074FB [0xC8050088] <- 0x0       : SDBUFCTR: Set to 0x03 before reading
[CPU0] [DIGIC6]       at 0x0010742A:00107511 [0xD209F100] <- 0xA       : ???
[CPU0] [DIGIC6]       at 0x00107430:00107511 [0xD2090600] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107438:00107511 [0xD2090618] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010743E:00107511 [0xD209061C] <- 0x1D000901: ???
[CPU0] [DIGIC6]       at 0x00107446:00107511 [0xD2090620] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010744E:00107511 [0xD209062C] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x00107456:00107511 [0xD2090630] <- 0x807     : ???
[CPU0] [DIGIC6]       at 0x0010745E:00107511 [0xD2090624] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x00107466:00107511 [0xD2090628] <- 0xF       : ???
[CPU0] [DIGIC6]       at 0x0010746E:00107511 [0xD2090638] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x00107476:00107511 [0xD2090604] <- 0x0       : ???
[CPU0] [DIGIC6]       at 0x0010747E:00107511 [0xD209060C] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010748E:00107511 [0xD2090608] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x00107496:00107511 [0xD2090610] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x0010749E:00107511 [0xD2090614] <- 0x1       : ???
[CPU0] [DIGIC6]       at 0x001074A6:00107511 [0xD209063C] <- 0x1       : ???
[CPU0] [SDIO]         at 0x00106FC8:00106FC3 [0xC8050008] <- 0xF1      : DMA
[CPU0] [SDDMA]        at 0x00106FD0:00106FC3 [0xC8020000] <- 0x44001800: Transfer memory address
[CPU0] [SDDMA]        at 0x00106FE0:00106FC3 [0xC8020004] <- 0x4000    : Transfer byte count
[CPU0] [SDDMA]        at 0x00106FE6:00106FC3 [0xC8020018] <- 0x0       : ???
[CPU0] [SDDMA]        at 0x00106FEC:00106FC3 [0xC8020010] <- 0x39      : Command/Status?
[CPU0] [SDIO]         at 0x00106F48:0010700B [0xC8050024] <- 0x5200    : cmd_hi
[CPU0] [SDIO]         at 0x00106F4A:0010700B [0xC8050020] <- 0x23C00001: cmd_lo
[CPU0] [SDIO]         at 0x00106F4C:0010700B [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[EOS] trigger int 0xBE (delayed!)
[CPU0] [SDIO]         at 0x00106F4E:0010700B [0xC805000C] <- 0x14      : Command flags?
[CPU0] [SDDMA]        at 0x0010700C:0010700B [0xC8020010] -> 0x0       : Command/Status?
[CPU0] [SDIO]         at 0x00107016:0010700B [0xC8050010] -> 0x200001  : Status
[CPU0] [SDIO]         at 0x00107024:0010700B [0xC8050008] <- 0x0       : DMA
[CPU0] [SDIO]         at 0x00107032:0010700B [0xC8050080] -> 0x20      : transferred blocks
[CPU0] [SDIO]         at 0x0010754C:00107061 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107061 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4C00    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x1       : cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0xB0000   : Response[0]
[CPU0] [SDIO]         at 0x0010754C:00107071 [0xC8050028] <- 0x30      : Response size (bits)
[CPU0] [SDIO]         at 0x0010754E:00107071 [0xC805002C] <- 0x2701    : response setup?
[CPU0] [SDIO]         at 0x00106D00:0010756D [0xC8050024] <- 0x4D45    : cmd_hi
[CPU0] [SDIO]         at 0x00106D02:0010756D [0xC8050020] <- 0x67000001: cmd_lo
[CPU0] [SDIO]         at 0x00106D04:0010756D [0xC8050010] <- 0x0       : Status
[EOS] trigger int 0xEE (delayed!)
[CPU0] [SDIO]         at 0x00106D06:0010756D [0xC805000C] <- 0x12      : Command flags?
[CPU0] [SDIO]         at 0x00106D08:0010756D [0xC8050010] -> 0x1       : Status
[CPU0] [SDIO]         at 0x00107572:0010756D [0xC8050044] -> 0x0       : ???
[CPU0] [SDIO]         at 0x00107574:0010756D [0xC8050040] -> 0x0       : Response[3]
[CPU0] [SDIO]         at 0x00107576:0010756D [0xC805003C] -> 0x0       : Response[2]
[CPU0] [SDIO]         at 0x00107578:0010756D [0xC8050038] -> 0x0       : Response[1]
[CPU0] [SDIO]         at 0x0010757A:0010756D [0xC8050034] -> 0x90000   : Response[0]
[CPU0] [GPIO]         at 0x00101782:00104E95 [0xD208016C] <- 0xC0003   : Card LED
[CPU0] [DIGIC6]       at 0x0010162C:00101955 [0xD2080114] <- 0x4C0083  : ???
[CPU0] [DIGIC6]       at 0x00101630:00101955 [0xD2080118] <- 0x4C0083  : ???
[CPU0] [DIGIC6]       at 0x00101634:00101955 [0xD208011C] <- 0x4C0083  : ???
[CPU0] [DIGIC6]       at 0x00101638:00101955 [0xD2080120] <- 0x4C0083  : ???
[CPU0] [DIGIC6]       at 0x0010163C:00101955 [0xD2080124] <- 0x4C0083  : ???
[CPU0] [DIGIC6]       at 0x00101640:00101955 [0xD2080128] <- 0x4C0083  : ???
[CPU0] [DIGIC6]       at 0x00101646:00101955 [0xD208015C] <- 0xC0003   : ???
Now jump to AUTOEXEC.BIN(0x00800000)!!
[CPU0] 00800008: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
[CPU0] [GPIO]         at 0x008065EE:008064BB [0xD208016C] <- 0x20D0002 : Card LED
[CPU0] 00806ABE: MRC p15,1,Rd,cr0,cr0,1:      CLIDR -> 0x9200003
[CPU0] 001008C0: MCR p15, ...          : CACHEMAINT x512 (omitted)
[CPU0] 00806AD6: MCR p15,2,Rd,cr0,cr0,0:     CSSELR <- 0x0       
[CPU0] 00806ADA: MRC p15,1,Rd,cr0,cr0,0:     CCSIDR -> 0x700FE019
[CPU0] [*unk*]        at 0x00806B46:00000005 [0xC1100730] <- 0x0       : ???
[boot] copy_and_restart 0x1b5700 (1791744)
[BOOT] reserving memory: 0x40000 (262144)
before: user_mem_size = 0x114988 (1132936)
after: user_mem_size = 0xd4988 (870792)
[BOOT] fixing up branch at 0x1b7ba0 (1801120)  (ROM: 0xe0040058 (-536608680) ) to 0x1b5769 (1791849)
[BOOT] fixing up branch at 0x1b7bd8 (1801176)  (ROM: 0xe0040090 (-536608624) ) to 0x1b5769 (1791849)
[BOOT] fixing up branch at 0x1b7baa (1801130)  (ROM: 0xe0040062 (-536608670) ) to 0x1b5759 (1791833)
[BOOT] fixing up branch at 0x1b7be2 (1801186)  (ROM: 0xe004009a (-536608614) ) to 0x1b5759 (1791833)
[BOOT] fixing up branch at 0x1b7bf8 (1801208)  (ROM: 0xe00400b0 (-536608592) ) to 0x1b7c34 (1801268)
[BOOT] fixing up branch at 0x1b7c82 (1801346)  (ROM: 0xe004013a (-536608454) ) to 0x1b5751 (1791825)
[BOOT] fixing up branch at 0x1b7ce4 (1801444)  (ROM: 0xe004019c (-536608356) ) to 0x1b5749 (1791817)
[BOOT] changing init_task from 0xe0040215 (-536608235) to 0x1b577d (1791869)
[CPU0] 001B5F9E: MRC p15,1,Rd,cr0,cr0,1:      CLIDR -> 0x9200003
[CPU0] 00806A98: MCR p15, ...          : CACHEMAINT x514 (omitted)
[CPU0] 001B5FB6: MCR p15,2,Rd,cr0,cr0,0:     CSSELR <- 0x0       
[CPU0] 001B5FBA: MRC p15,1,Rd,cr0,cr0,0:     CCSIDR -> 0x700FE019
[CPU0] [*unk*]        at 0x001B6026:00000005 [0xC1100730] <- 0x0       : ???
[BOOT] jumping to relocated startup code at 0x1b7b49 (1801033)
[CPU0] 001B5F78: MCR p15, ...          : CACHEMAINT x514 (omitted)
[CPU0] 001B7B4A: MCR p15,0,Rd,cr12,cr0,0:       VBAR <- 0xE02427A0
[CPU0] 001B7B5C: MRC p15,0,Rd,cr0,cr0,5:      MPIDR -> 0x80000000
E065E27C: Taking exception 2 [SVC]


Did you only changed stubs values by adding +1 to the address?

I have some warnings while compiling, can you check if you get the same?

../../src/minimal-d678.c: In function 'FIO_WriteFile':
../../src/minimal-d678.c:140:1: warning: control reaches end of non-void function [-Wreturn-type]
int FIO_WriteFile( FILE* stream, const void* ptr, size_t count ) { };
^
[ CC       ]   cache.o
[ CC       ]   font_direct.o
[ AS       ]   ../../platform/77D.100/stubs.o
[ CC       ]   log-d678.o
../../src/log-d678.c: In function 'my_DebugMsg':
../../src/log-d678.c:64:23: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
     char* task_name = get_current_task_name();
                       ^
...

[ XOR_CHK  ]   ../../build_tools/xor_chk
../../build_tools/xor_chk.c:48:88: warning: format specifies type
      'unsigned long' but the argument has type 'uint64_t' (aka
      'unsigned long long') [-Wformat]
  ...error (expected 0x%lX, got 0x%lX)\n", 0xCCCCCCCCE12FFF13, footer_magic);
                                  ~~~                          ^~~~~~~~~~~~
                                  %llX


I need to try using linux to see if this is the problem to me.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 13, 2019, 07:05:23 AM
Mostly I added 1 for the function calls. I will clean up a bit and then create a fork on Bitbucket with the update. It may take some days but I hope to get it done on the weekend.

I use Ubuntu bionic64 in MacOS through VirtualBox and Vagrant. Basically Vagrant allows you to discard and create the dev environment anytime. All files will be mirrored to the MacOS host.
Have a look here https://github.com/calle2010/magic-lantern-77d-vagrant

But I don't think the issues are caused by MacOS. Your output is very similar to mine.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 13, 2019, 11:56:48 PM
Quote from: a1ex on May 04, 2018, 11:09:24 AM
The TotalSheets and EstimatedSize errors are likely caused by wrong / incomplete MPU messages (these will have to be logged from a real camera);

I spent the evening trying to find the cause for the ASSERT EstimatedSize.c Task = RscMgr Line=1483 error.
Finally I figured out that a wrong value is passed from GetEstimatedSizeOfMovie or similar and when I wanted to use gdb to put a breakpoint I found that Alex did this already, including the workaround, in a20c79b (https://bitbucket.org/hudson/magic-lantern/commits/a20c79bcfe12867a2d62fc50e2fe628fa16f9200#chg-contrib/qemu/scripts/77D/debugmsg.gdb).

So that means this assertion doesn't happen anymore when running with GDB debugmsg.gdb.
At least I learned a lot so far.

Next is an exception:

< Error Exception>
CORE        : 0
TYPE        : 16
ISR         : 0
TASK IDSR   : 11534368
TASK Name   : ShootCapture
R 0         : e018a2cd
R 1         : 0
R 2         : 0
R 3         : 1
R 4         : a1bb0
R 5         : 0
R 6         : 10000
R 7         : e0042c9f
R 8         : 40b65600
R 9         : 19980218
R10         : 19980218
R11         : 19980218
R12         : 48
R13         : 1ffebc
R14         : e018a315
PC          : e04108b2
CPSR        : 73


The code at this PC is
e04108b2:       f845 0022       str.w   r0, [r5, r2, lsl #2]
If I understand it right, it tries to store the value in r0 to the address r5+r2, which happens to be 0.

Is this also a known problem and perhaps solved already?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 14, 2019, 10:02:26 AM
It is a known problem, but not solved yet. On 80D, I've got similar issues after skipping Omar initialization. On DIGIC 7, I'm currently emulating only the main CPU core, and the early startup for the other. Previously, I had unsuccessful attempts at guessing the interrupts used by the two cores, but nothing worth showing.

Recently we've got detailed logs from 200D, that I can use to fix the emulation, but didn't look into them yet. The cleanest one seems to be this: DEBUGMSG-mpu-int.LOG (https://a1ex.magiclantern.fm/bleeding-edge/200D/DEBUGMSG-mpu-int.LOG)

For porting ML, full emulation is not strictly required; after checking the stubs (just in case) I'll publish the FIR for enabling the boot flag, so you'll be able to debug directly on the camera.

You may also want to join the IRC channel, as @names_are_hard and others are active there.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 14, 2019, 12:59:05 PM
What I don't understand: Why can't GDB read the memory at addresses 0x000-0xFFF? Initially that works, but when I set a breakpoint later in the boot process, e. g. at 0xe04108b2, GDB says it can't access these addresses. Does it have to do with the MMU? I think I read elsewhere in the forum that this address range is separate for the two processors?

I think I understand now:
#112 (https://www.magiclantern.fm/forum/index.php?topic=19737.msg212603#msg212603) and #43 from EOS R/RP (https://www.magiclantern.fm/forum/index.php?topic=22770.msg212090#msg212090): This area is unavailable, perhaps to catch null pointer exceptions, if I understand correctly.

I wanted to look at the interrupt vector table as you did in the M2 porting tutorial. But I never see anything valid there.

Alex, thank you for all the information, I find a new piece everyday. But I think I'm stuck here. May try to use IRC when I have the time, never used that before. :-)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 14, 2019, 11:18:06 PM
Here is the stubs.S I am working with right now: https://bitbucket.org/calle2010/magic-lantern/src/f387fc148a1c4c5e4c1517a42226bcc0c17ded9f/platform/77D.102/stubs.S

Alex, if you could have a look and verify? I am not very confident...

I run the Canon firmware with

Quote./run_canon_fw.sh 77D,firmware="boot=0" -d callstack -s -S  & gdb-multiarch -x 77D/debugmsg.gdb

It is possible to open the drysh console. Memory information:

Open Console K408[1]>...

K408[1]>dryshDry[MusaPUX]> Dry[MusaPUX]> meminfo -m
Malloc Information (onetime type)
  Start Address       = 0x000e0fa8
  End Address         = 0x001f5658
  Total Size          = 0x001146b0 (  1132208)
  Allocated Size      = 0x00007608 (    30216)
  Allocated Peak      = 0x00007608 (    30216)
  Allocated Count     = 0x00000050 (       80)
  Free Size           = 0x0010d0a8 (  1101992)
  Free Block Max Size = 0x0010d0a8 (  1101992)
  Free Block Count    = 0x00000001 (        1)
Dry[MusaPUX]> memmap
e02427a0 : Exception vector
000e0fa0 : Heap start
           0x00114988(1132936)
001f5928 : Heap end
001f5928 : DRYOS system object
           0x00009478(38008)
001feda0 : DRYOS system memory
           0x000e2200(926208)
000e07a0 : Error exception stack start (PU0)
           0x00000400(1024)
000e0ba0 : Error exception stack end (PU0)
000e0ba0 : Error exception stack start (PU1)
           0x00000400(1024)
000e0fa0 : Error exception stack end (PU1)
df000000 : IRQ exception stack start (PU0)
           0x00001000(4096)
df001000 : IRQ exception stack end (PU0)
df001000 : IRQ exception stack start (PU1)
           0x00001000(4096)
df002000 : IRQ exception stack end (PU1)


Tasks:

Dry[MusaPUX]> extask
Name            ID   State Pri         Wait(ID)      Stack  % StackTop StackEnd       SP Bound(ID)
init1      000d0004   READY   0         -------   0008/1000 00 001fffc8 00200fc8 00200fc8    BND(1)
DbgMgr     00260006   READY  13         -------   02a0/1000 16 002013d8 002023d8 002022f0    BND(1)
EventMgr   0038000d    WAIT  14  RCVMQ(00370005)  01a8/1000 10 00207408 00208408 00208340    BND(0)
RTCMgr     004e0011    WAIT  14  RCVMQ(004d000c)  0330/0400 79 00209418 00209818 00209750    BND(0)
ShootCaptu 00af001f SUSPEND  14         -------   01f0/1000 12 00215c88 00216c88 000e0b28    BND(0)
EFLensComT 0040000e    WAIT  16  RCVMQ(003e0008)  00b8/0400 17 00204be8 00204fe8 00204f60    BND(0)
MainCtrl   00840017    WAIT  16  RCVMQ(00830013)  0190/1000 09 0020e848 0020f848 0020f7c0    BND(0)
RscMgr     005e0014    WAIT  18  RCVMQ(005d000e)  03f0/1000 24 0020b830 0020c830 0020c768    BND(0)
Panning    00c40022    WAIT  18  RCVMQ(00c3001f)  0170/0c00 11 0021cca0 0021d8a0 0021d7d8    BND(0)
PropMgr    0032000b    WAIT  20  RCVMQ(00310003)  0428/1000 25 001fefc0 001fffc0 001ffef8    BND(0)
MainSubTas 0043000f    WAIT  20  RCVMQ(00410009)  00b0/0400 17 00204ff0 002053f0 00205370    BND(0)
FileCache  005b0013    WAIT  20  RCVMQ(005a000d)  00f8/1000 06 0020a828 0020b828 0020b760    BND(0)
ShootBlack 00bd0020    WAIT  21  RCVMQ(00bc001d)  0138/2000 03 00216c90 00218c90 00218bc8    BND(0)
ShootPreDe 00c10021    WAIT  22  RCVMQ(00c0001e)  00f8/4000 01 00218c98 0021cc98 0021cbd0    BND(0)
GuiLockTas 007e0015    WAIT  23  RCVMQ(007d0011)  00b0/1000 04 0020c838 0020d838 0020d7b8    BND(0)
EvShel     00c60023 RUNNING  24         -------   0358/8000 02 0021d8a8 002258a8 --------    BND(0)
ConsoleSvr 00ce0025    WAIT  24  RCVMQ(00c90020)  01f8/0800 24 002260b8 002268b8 00226820    BND(0)
Startup    002a0007    WAIT  25  RCVMQ(00290002)  0398/2800 08 002023e0 00204be0 00204b50    BND(0)
FileMgr    00470010    WAIT  25  RCVMQ(0046000b)  0820/1000 50 00208410 00209410 00209348    BND(0)
Fstorage   00820016    WAIT  25  RCVMQ(00810012)  00f8/1000 06 0020d840 0020e840 0020e778    BND(0)
Ta10Mgr    00880019    WAIT  25  RCVMQ(00870014)  00f8/1000 06 0020fc58 00210c58 00210b90    BND(0)
HDRMgr     008b001a    WAIT  25  RCVMQ(008a0015)  00f8/1000 06 00210c60 00211c60 00211b98    BND(0)
HDRStage   008d001b    WAIT  25  RCVMQ(008c0016)  00f8/1000 06 00211c68 00212c68 00212ba0    BND(0)
GISMgr     0091001c    WAIT  25  RCVMQ(00900017)  00f8/1000 06 00212c70 00213c70 00213ba8    BND(0)
GISStage   0093001d    WAIT  25  RCVMQ(00920018)  00f8/1000 06 00213c78 00214c78 00214bb0    BND(0)
LowConsole 00cd0024 SUSPEND  25         -------   00d0/0800 10 002258b0 002260b0 00226040    BND(0)
NFCMgr     0035000c    WAIT  26  RCVMQ(00340004)  01e8/1000 11 00206400 00207400 00207338    BND(0)
DOSDriver  00590012    WAIT  26  EVENT(0058000c)  00d8/1000 05 00209820 0020a820 0020a778    BND(0)
AEmodeJudg 00860018    WAIT  26    SEM(0085004d)  0088/0400 13 0020f850 0020fc50 0020fc00    BND(0)
CSMgrTask  0099001e    WAIT  28  RCVMQ(00970019)  0530/1000 32 00214c80 00215c80 00215bd8    BND(0)
PowerMgr   00240005   READY  32         -------   0080/0400 12 00200fd0 002013d0 002013b8    BND(0)
idle       00010001   READY  33         -------   0060/0100 37 001fedb0 001feeb0 001fee80    BND(0)
idle       00020002   READY  33         -------   0008/0100 03 001feeb8 001fefb8 001fefb8    BND(1)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 15, 2019, 08:32:07 AM
Quote from: calle2010 on March 14, 2019, 11:18:06 PM
Alex, if you could have a look and verify?

Done, mostly good. Even the interrupt logging stubs (pre/post_isr_log) happened to be correct, i.e. the same as 200D.

Would be nice to have minimal-d78 working as well; this one uses regular file I/O functions (rather than dump_file) and needs some more memory allocation functions.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 15, 2019, 01:30:44 PM
Thank you! I worked on your comments and I think I found the memory stubs.
Next I would work on the File I/O stubs.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on March 15, 2019, 01:45:05 PM
Try these one:

/** File I/O **/
NSTUB(0xe04d714d, _FIO_OpenFile)
NSTUB(0xe04d71b7, _FIO_CreateFile)
NSTUB(0xe04d7271, _FIO_ReadFile)
NSTUB(0xe04d7389, _FIO_WriteFile)
NSTUB(0xe04d7317,  FIO_SeekSkipFile)
NSTUB(0xe04d7389,  FIO_CloseFile)
NSTUB(0xe04d7cb1, _FIO_CreateDirectory)
NSTUB(0xe04d7fc1, _FIO_FindFirstEx)
NSTUB(0xe04d804f,  FIO_FindNextEx)
NSTUB(0xe04d80bb,  FIO_FindClose)
NSTUB(0xe04d74a7, _FIO_GetFileSize)
NSTUB(0xe04d7225, _FIO_RemoveFile)
NSTUB(0xe04d7b2b, _FIO_RenameFile)
NSTUB(0xe04d7dd5,  FIO_Flush)               // to be called after FIO_CloseFile?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 16, 2019, 01:32:00 PM
Many thanks, aprofiti. I double checked the stubs and found two that I had to change:

NSTUB(0xe04d7317, _FIO_WriteFile) //!
NSTUB(0xe04d8895,  FIO_SeekSkipFile) //!


Your FIO_SeekSkipFile stub I think referred to _FIO_WriteFile.
_FIO_WriteFile was the same as _FIO_CloseFile. (copy&paste error?)

All the stubs you posted have a difference of 0x1AF60 to the 200D. So I did the same for _FIO_SeekSkipFile. I could match it with some error messages, but it looks very different from all the other FIO functions. Especially I couldn't find it calling the function at 0xe04d70e8, which seems to be a kind of debug function for the FIO functions.

Also I'm not so sure about these three:
NSTUB(0xe04d80db, _FIO_FindFirstEx) /* 0xe04d7fc1 is FIO_FindFirst */
NSTUB(0xe04d8173,  FIO_FindNextEx) /* 0xe04d804f is FIO_FindNext */
NSTUB(0xe04d80bb,  FIO_FindClose) /* 0xe04d81de is FIO_FincCloseEx(!) */


FindFirst/FindNext/FindClose seem to come in two flavors: With or without "Ex".
The difference seems to be that FindFirstEx does a FIO_Flush before it does whatever it does.
I think FindNext/FindNextEx and FindClose/FindCloseEx are functionally identical.

I changed the stubs to match the names, but I am not sure if this is correct.
If correct, than perhaps the same change applies to the 200D as well? Because these would not match with the same address offset of 0x1AF60 to the 200D.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on March 16, 2019, 04:12:51 PM
Quote from: calle2010 on March 16, 2019, 01:32:00 PM
FindFirst/FindNext/FindClose seem to come in two flavors: With or without "Ex".
The difference seems to be that FindFirstEx does a FIO_Flush before it does whatever it does.
I think FindNext/FindNextEx and FindClose/FindCloseEx are functionally identical.
Noticed that 2-3 stubs where having some sort of mirror, same code at another offset. Was the same with 200D, where the ones with lower address where used.

Quote from: calle2010 on March 16, 2019, 01:32:00 PM
Your FIO_SeekSkipFile stub I think referred to _FIO_WriteFile.
_FIO_WriteFile was the same as _FIO_CloseFile. (copy&paste error?)
I mixed one time so maybe I missed these when redoing.
Can't check right now...

Offset of FIO stubs should be right, but I may expect some slightly change in code which can broke it, it need to be rechecked.

It's missing uart_printf stub, 200d doesn't use it and I don't have R or M50 rom to check for; maybe can be found using GDB and some breakpoint, message printed can be easily found as string when looking at the disassembly.

Should be possible to temporarily change the code to use something else, to make it compile and experiment with marking unused memory.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 16, 2019, 08:10:30 PM
I'm experimenting with minimal-d78.c.

dump_task is started, I can blink the LED in different ways, qprint messages are printed.

But I can't get anything saved to the SD image. Neither dumpf, nor backup_region or dump_file is doing anything.

Also when I start the firmware with boot=0 and type dumpf in the event shell nothing is written to the SD card.

I couldn't find uart_printf stub so far, only many low-level UART related functions to write a byte or a string. Nothing that takes a format.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on March 16, 2019, 09:24:00 PM
I can confirm that I copy pasted wrong and lost some values, writeFile/seeSkipFile and closeFile were found like your post.

If I try to use "dump" with bootflag disable, I get this:

K408[1]>dumpf
dumpf returned 0(0x0)
K408[1]>[DM] ERROR : FIO_FindFirstEx fail
ASSERT : ./FileIO/FileIO.c, Task = DbgMgr, Line 86


I have also this error with and without bootflag enabled:

   228:4294889.983 [TA10] ERROR Irregular TotalSheets 0 !!

But I imagine there is something wrong on my side... because none of the debug message from qprintf are printed and led doesn't look like is blinking...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 17, 2019, 04:13:42 PM
Screenshot of the "broken line". Already visible with a break-point at 0x00800000, so after AUTOEXEC.BIN is loaded but before it is relocated.

(https://i.ibb.co/HnPZntY/broken-line.png) (https://ibb.co/HnPZntY)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on March 18, 2019, 04:59:15 PM
@calle2010 Did you already read a1ex's comments about isr (https://bitbucket.org/calle2010/magic-lantern/commits/e25589c06564b665fe1c17f9e3b30a5c1a0b0036#comment-7273500) and memory (https://bitbucket.org/calle2010/magic-lantern/commits/e25589c06564b665fe1c17f9e3b30a5c1a0b0036#comment-7273510) stubs on bitbucket?

I can see you didn't updated your repository with the changes
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 20, 2019, 11:37:56 PM
It's updated in commit 0264f84 (https://bitbucket.org/calle2010/magic-lantern/commits/0264f845c9b86e43c4b6b9f017625b3aabdaffcc). I hadn't time to replicate any of these tests yet that Alex did with File I/O.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 21, 2019, 12:26:57 AM
Quote from: calle2010 on March 17, 2019, 04:13:42 PM
Screenshot of the "broken line". Already visible with a break-point at 0x00800000, so after AUTOEXEC.BIN is loaded but before it is relocated.

I'm pretty sure now this is the AUTOEXEC.BIN which is loaded by the boot loader. After the function at 0x00104DA4, which I believe does the loading, the line appears.

Since Canon boot loader code is doing this it should be fine. I guess Qemu just happens to pick this RAM area as a screen buffer because it is not adapted to the 77D yet?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 25, 2019, 11:32:25 PM
Some progress:
- verified and committed the 77D stubs from @aprofiti and @calle2010; nice job!
- DISP_SetUpdateOSDVram (suggested by @jack001214) was, indeed, the keyword for figuring out the display buffer address on all DIGIC 6/7/8 models
- committed the Hello World (https://bitbucket.org/hudson/magic-lantern/commits/e34a3af91d9276e600a1c231906c34b553026e89) code from @names_are_hard (200D) and @chris_overseas (5D4) and cleaned it up a bit (hopefully still working)
- some definitions (https://bitbucket.org/hudson/magic-lantern/commits/1e8f3b358a3208cb71a01bf09faa2d9c6452c429) useful for porting
- dedicated stub macros (https://bitbucket.org/hudson/magic-lantern/commits/6aff5f72ba485652bfd902de0fb1b6fe3480ff0d) for ARM/Thumb code and also for data (less error-prone)
- various other code cleanups (and some robots programmed to perform them)

To compile the minimal Hello World code (expected to work on DIGIC 4/5/6/7/8, most models):

hg up digic6-dumper -C
cd minimal/hello-world
make MODEL=77D clean
make MODEL=77D install  # or install_qemu, but won't work out of the box





77D FIR for enabling the boot flag: BOOT_77D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/77D/BOOT_77D.FIR) (edit: confirmed by calle2010)

This will modify your camera (details (https://www.magiclantern.fm/forum/index.php?topic=19737.msg212603;topicseen#msg212603))

Have fun!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on March 26, 2019, 06:18:57 AM
Great News! Future seems bright for these camera's!

Also, (if you dont mind) can you briefly explain the process which took place too find this address when the memory region is  not 'cache-able'?
Thanks,
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 26, 2019, 10:58:40 PM
Quote from: jack001214 on March 26, 2019, 06:18:57 AM
Also, (if you dont mind) can you briefly explain the process which took place too find this address when the memory region is  not 'cache-able'?

Not sure I understand the question. Generally, an address below 0x40000000 is cacheable (i.e. any access to that memory goes through the CPU cache). An address above 0x40000000 (until 0xC0000000, but that limit is only reached on the EOS R for now) is uncacheable, i.e. memory access is done bypassing the CPU cache, i.e. reading/writing directly into physical memory.

Memory address 0x01234567 and 0x41234567 refer to the same physical address; the former is cacheable, the latter is not.

Regarding the display buffers - the code after DISP_SetUpdateOSDVram flips between two image buffers (given as pointers to MARV structures, documented earlier on the 80D thread (https://www.magiclantern.fm/forum/index.php?topic=17360.msg212411#msg212411)). There is a data structure with 3 pointers:

struct bmp_vram_info
{
    struct MARV * vram1;        /* one of the two bitmap buffers - statically allocated? */
    struct MARV * vram2;        /* the other bitmap buffer */
    struct MARV * back_vram;    /* we need to write to the other one */
};


The first two fields are constant (confirmed from various RAM dumps), and the third one points to one of the first two. In the code that follows the OSDVram message, the third pointer is flipped after configuring the hardware registers. That means, it doesn't point to the currently displayed buffer, but to the "back" one, for some reason. This code pattern was present on all DIGIC 6/7/8 models I've checked.

Basically, this pseudocode:

DebugMsg(4, 3, "DISP_SetUpdateOSDVram(%#x)(%d)", MEM(0x1238), ...)
DISP_SetUpdateOSDVram(...)
if MEM(0x1238) == MEM(0x1230):      # third field same as first one?
    MEM(0x1238) = MEM(0x1234)       # yes, switch to the second one
else:
    MEM(0x1238) = MEM(0x1230)       # no, switch to the first one


So, the bmp_vram_info would be 0x1230 in this hypothetical case.

In ASM:

  LDR   R3, [R5,#0x1C]      ; VRAM pointer (to be printed - first arg after the format string)
  ...
  BLX   DebugMsg            ; DISP_SetUpdateOSDVram(...)
  BL    DISP_SetUpdateOSDVram
  LDR   R1, [R5,#0x1C]      ; VRAM pointer
  LDR   R0, [R5,#0x14]      ; VRAM1
  CMP   R1, R0              ; is it pointing to VRAM1?
  BNE   store               ; no, flip to VRAM1
  LDR   R0, [R5,#0x18]      ; yes, flip to VRAM2
store:
  STR   R0, [R5,#0x1C]      ; store the new VRAM pointer


Notice Canon's data structure is a bit larger than the 3 fields I've declared; didn't check the other fields yet, but they might be useful. The number of fields before these 3 VRAM pointers is model-specific, but I'm trying to write generic (portable) code whenever possible.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 27, 2019, 12:08:25 AM
Quote from: a1ex on March 25, 2019, 11:32:25 PM
77D FIR for enabling the boot flag: BOOT_77D.FIR

I have loaded BOOT_77D.FIR on an SD card formatted in camera, executed the firmware update process and ... it worked!  ;)


(https://i.ibb.co/sjNt8jt/fullsizeoutput-7768.jpg) (https://ibb.co/sjNt8jt)


I could compile minimal-d78.c for 77D.102 from commit 537045b7424c and the AUTOEXEC.BIN worked on the camera.

I've got another dump of my ROMs and this output, which must come from call("dumpf"):
https://bitbucket.org/snippets/calle2010/Ke4GB8#file-LOG000.LOG
Camera continued to work while the dumps were made and afterwards...

@Alex: You mentioned that you have a fix for struct fio_file. Are you going to commit this, too?

I guess the next step for 77D is to capture the log files and then try to get Hello, world running?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 27, 2019, 11:11:12 AM
Quote
I guess the next step for 77D is to capture the log files and then try to get Hello, world running?

Hello World is expected to run out of the box, without any tweaking (well, unless I've mistyped the stub).

Quote from: calle2010 on March 27, 2019, 12:08:25 AM
@Alex: You mentioned that you have a fix for struct fio_file. Are you going to commit this, too?

Done. (https://bitbucket.org/hudson/magic-lantern/commits/6efd9eb6a2b1cf21e204a98e41c8228af4b7fa5b)

I must be doing something wrong in my workflow:

- figuring out the changes to struct fio_file (by trial and error, printf-based debugging): about 15-30 minutes
- writing some reasonably clean test code to cover these changes, and manually testing it on 5 models in QEMU: about 1 hour
- including it in the QEMU test suite and making sure it passes on all other EOS models: a couple of days...

And after all that, it still doesn't pass the tests every single time I run the suite, but that's caused by imperfect emulation (some nondeterministic issue emulating the SD card on all DIGIC 7 models).

And I'm still wondering whether the tests will pass on the build server (watch it live (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-tests/362/consoleFull), it will take an hour or so to run all the tests; the newly added test for FindFirst/FindNext/FindClose takes 4 minutes on my local machine).

Maybe I'm misunderstanding what TDD is all about ???
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 27, 2019, 07:17:16 PM
Thank you, Alex!

Quote from: a1ex on March 27, 2019, 11:11:12 AM
Maybe I'm misunderstanding what TDD is all about ???

I was told in the last millenium that testing takes 10 times longer than development. I guess this hasn't changed. Only that you now can make a machine doing it over and over again, saving us from all the headaches!  :)

I haven't even started to dive into the testing machinery that you built...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 27, 2019, 08:02:53 PM
Right. And programming that machine takes 10 times longer than actual feature development.

It's still way faster than asking users to test every single "nitpick" change - see e.g. all these backend refactors made to have a sane Lua API. On some models, the feedback is immediate, i.e. in hours or the next day. On others... I get feedback after several months, and that's when I discover that basic stuff - such as mere ML menu navigation - is broken (but working in QEMU because of an incorrect assumption of mine). And that's just because of my desire to include in mainline only what's known to work on all models, without breaking existing features.

Wish I could fully test the entire ML feature set in QEMU at the press of a button (https://www.magiclantern.fm/forum/index.php?topic=23606.msg213030#msg213030), even if it takes a day or two (as it will be done by a robot). Currently, the tests running on the build server are covering only some basic things - whether it boots, whether one can browse the menus and other similar nitpicks.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on March 28, 2019, 09:24:44 AM
QuoteNotice Canon's data structure is a bit larger than the 3 fields I've declared;
Yes i found my self nitpicking each log and found the same result against the ram dump.

QuoteThat means, it doesn't point to the currently displayed buffer, but to the "back" one, for some reason. This code pattern was present on all DIGIC 6/7/8 models I've checked.
Ah! So now i see, when i was changing that region it affected a 'part' of the display which was probably the live view from the camera.

Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 29, 2019, 09:24:09 AM
I played with CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP.

With commit 6a3ca36c (https://bitbucket.org/calle2010/magic-lantern/commits/6a3ca36c074a52bf6785548c6939685d3063477d) I get a very clean DEBUGMSG.LOG with only "used/maybe unused" log entries.

I tried it two times. Then I found two memory areas with 6MB each consistently mark as "maybe unused".
Main difference between the two tries was that in the menu I clicked an item to setup a photobook. It seemed to read the pictures on the card (nearly 100 from previous experiments), so this try showed many more memory areas as used.

I'm a bit disappointed that I couldn't find a larger chunk of memory. I think logging will be very limited with only 6MB.

My procedure for the experiment:

Steps:
- put the card with autoexec.bin and close the card door
- wait for the LED to go dark
- start camera in M or P mode, High Speed Shutter enabled
- startup will take a couple of seconds
- wait for three seconds (LED blinks)

Do all of this within 50 seconds:
- open menu and do two or three steps
- take one picture in photo mode
- take one picture in LV mode
- take some seconds of video (in my case 8s video snapshot function since I don't use any other video function)
- go to image playback mode, zoom into one of the photos
- take pictures until buffer is full

- Important: Wait until LED blinks 3/4 times and all pictures are written to the card (may overlap)

Only until LED is dark for a minute:
- Switch off camera
- wait five seconds
- open card door
- wait five seconds
- take card, get DEBUGMSG.LOG

These are the two areas. All others are smaller:

5A400000-5A4FFFFF: maybe unused
5A500000-5A5FFFFF: maybe unused
5A600000-5A6FFFFF: maybe unused
5A700000-5A7FFFFF: maybe unused
5A800000-5A8FFFFF: maybe unused
5A900000-5A9FFFFF: maybe unused

69600000-696FFFFF: maybe unused
69700000-697FFFFF: maybe unused
69800000-698FFFFF: maybe unused
69900000-699FFFFF: maybe unused
69A00000-69AFFFFF: maybe unused
69B00000-69BFFFFF: maybe unused
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on March 29, 2019, 09:31:26 AM
Quote from: calle2010 on March 29, 2019, 09:24:09 AM
- take pictures until buffer is full

Assuming you are not going to log a full burst, you can skip this, for these reasons:
- a full burst will allocate as much memory as it can
- these hardcoded addresses are not used in "production" code, only for initial logging experiments
- you are not going to log a full burst anyway
- memory used for image processing is well away from DryOS internal data structures (so, no bad outcome expected, should we happen to overwrite this)

Taking 2-3 pictures in a row should be OK, just in case, but a full burst is probably overkill.

Also, once the firmware is started, one can use the "exmem" allocators to get large chunks of memory, so this trick is pretty much for startup logging only.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 29, 2019, 10:43:05 AM
Ol, Alex.  I will try again and not use the photobook function either
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: chris_overseas on March 29, 2019, 12:10:30 PM
Quote from: calle2010 on March 29, 2019, 09:24:09 AM
I'm a bit disappointed that I couldn't find a larger chunk of memory. I think logging will be very limited with only 6MB.

Don't be too disappointed by this, I had the same problem with the 5D4. I created a workaround using a ring buffer that gets periodically flushed and hence allows continuous logging. With this I managed to get 45MB+ log files with 8MB of buffer.

It is still a bit experimental and not yet merged into the ML repo, but if you're willing to get your hands dirty with the code you can try merging in the relevant parts from my repo. The initial commit was this one (https://bitbucket.org/chris_miller/ml-fork/commits/9911cb78cd873a696e585c07057bc539279bde09?at=5d4-112) but there were a few (https://bitbucket.org/chris_miller/ml-fork/commits/90dfca375a790a0403bdb8b937f5c255ce3932f5?at=5d4-112) more improvements (https://bitbucket.org/chris_miller/ml-fork/commits/f395aed2eb291fb1026f1422fef33449767109f4?at=5d4-112) and fixes (https://bitbucket.org/chris_miller/ml-fork/commits/36285f5206a2ed008cd018ec51d5a8bd079c126c?at=5d4-112) added later, so you'll probably want to cherry pick those bits too if you want to give it a try. Note also that it was only hacked together for the 5D4, but should be trivial enough to use on other cameras.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on March 29, 2019, 01:24:55 PM
Sounds great, Chris! If there is a need I will try it.

I found one area with 14MB which seems to be pretty stable, even with burst pictures, and three more areas with more than 40MB which should be good for lighter workloads.


/* area at 43700000 doesn't seem to be overwritten by burst pictures */
buf = (void *) 0x43700000           /* 43700000-444FFFFF = 14MB, 4BA00000 - 4E2FFFFF = 41MB, 4E400000 - 50DFFFFF = 42MB, 72A00000 - 753FFFFF = 42MB */
buf_size = 14 * 1024*1024;


I wonder if it is better to use the uncacheable address space, as defined for the 80D? Cause the log is likely to be written from both CPUs.
Still confused by what is cacheable and what not.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: buro341 on April 01, 2019, 06:00:25 PM
Just got the 77d. 
Very glad to see people working to get ML working on this camera! :o :o :o

thnx!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on April 01, 2019, 10:38:51 PM
hello-world on 77D:


(https://i.ibb.co/JmdCWbT/77-D-hello-world-movie.jpg) (https://ibb.co/JmdCWbT)

(https://i.ibb.co/vHfMHFZ/77-D-hello-world-photo.jpg) (https://ibb.co/vHfMHFZ)


In liveview mode and while recording a movie it blinks once per second. During menu display it gets wiped as soon as a new screen is shown. I think this is expected. Also at shutdown it overlays the sensor clean animation, blinking.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: buro341 on April 01, 2019, 10:48:00 PM
and hello world shows that with altering some code, ML will work on 77d?
anyways, I love that people are working on the 77D, it really needs ML to produce great video imo.

Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on April 01, 2019, 11:12:00 PM
From what I understand this shows that we can run code on the camera next to Canon's firmware and some people much smarter than I have figured out how to modify the screen buffer.

If you need ML to produce great video then you should not hold your breadth while waiting for it...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on April 02, 2019, 12:53:02 AM
Good! Giving m50 able to navigate menu, should be only a matter of time before it can also be archived on d7 cameras.
Archiving MMIO logs could also help to enhance emulation in the future.

I don't have a 77d, so my help likely end here; nevertheless the development is already in good hands.

P.S: Looks like only 6D2 and 800D are missing the party... a1ex, any roms dump available? :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on April 02, 2019, 03:33:38 AM
Quote from: Jakesmjf on April 01, 2019, 11:05:37 PM
Hey guys! I recently bought a 200D and am quite stoked at the development on this forum! Would just like to know if there is anything I could do to help?

What kind of programming experience do you have?  I have a 200D and am slowing porting magiclantern.  There is not enough done yet to safely try running magiclantern, but if you are happy with C, ARM assembly, or reverse engineering, there's lots you could help with.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on April 02, 2019, 03:45:40 PM
QuoteI have a 200D and am slowing porting magiclantern
How far did you get? I mean i am goofing around with my 200D too with the RAM dumps etc .If there was a list or some updates i'd follow it.

Also, any decoded buttons 'codes' are found yet?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on April 02, 2019, 05:20:19 PM
Would be great if we could share progress here in the forum and also have the links to our repositories.

Mine is: https://bitbucket.org/calle2010/magic-lantern-77d/commits/all (updated)
I will share whatever is halfway working for me.

I know this one with WIP for 200D: https://bitbucket.org/stephen-e/ml_200d/commits/all

Finally it probably would be good to have pull requests for Alex for any substantial progress.

I'm not very fond of IRC, especially because I think a lot of communication is lost when one is offline. No idea how to stay online for 24h. Is anybody interested in using Slack or similar for chatting? At least for the DIGIC 7 stuff, not as a replacement for IRC.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: chris_overseas on April 02, 2019, 06:30:00 PM
My 5D4 work-in-progress repo is here: https://bitbucket.org/chris_miller/ml-fork/commits/all

It's digic 6+ of course but has some similar challenges to the ones faced with digic 7 so may well still be helpful.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on April 02, 2019, 10:28:58 PM
This is a useful starting place:
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default#rst-header-adding-support-for-a-new-camera-model

The Finding Stubs tutorial is also handy:
https://www.magiclantern.fm/forum/index.php?topic=12177.0

IRC is a good place to ask "how do I find out about X?".

The stephen-e repo is mine, I am working on stub hunting currently.  There's about 80 stubs I haven't tried to locate yet, when I've taken a first pass through that I'll need to ask more questions.  If anyone with a 200D finds stubs further down in stubs.S them my "UNSURE or untested" section, let me know and I can add them.  Currently I have the hack hello world working, and the official CONFIG_HELLO_WORLD Magiclantern *building*, but it won't run; it will need some of the stubs that I haven't yet found.  I guess it might take 40 hours to try and find the 80 I know are currently wrong.  Then maybe another 40 to find the ones that are hard to find?  Then I don't know what is next; I guess maybe correcting the ML source code for assumptions it makes that aren't true for Digic 7.  I have noticed that some functions seem to have a changed number of parameters, perhaps that will become important.

If you can't afford IDA Pro + decompiler (about $4000), then I highly recommend Ghidra.  It's free, and has very similar features.  If you've not used something like that before I can get you started.  This lets you better compare a known good camera with a new camera, so you can find the equivalent functions in the new version.

You can stay logged into IRC permanently by using an IRC Proxy / Bouncer, then your IRC client connects to that.  ZNC looks alive, I've not tried it.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on April 03, 2019, 07:22:48 AM
That's a very good summary. I decided to give up on improving the emulation for now. This task is beyond my knowledge and I think I make no progress:
I tried to create 77D MPU spells but ailed because many important spells are not in the log from my camera and I don't know why.
I tried to analyze and debug the WaitPU1 issue but do not understand enough of DryOS semaphores, sequencers and other things to make any sense of it. I believe this blocks the firmware startup sequence
I have no clue how to fix QEMU for the new display GPU. I thought about having a breakpoint, dumping the VRAM every second to a file and convert and display outside of QEMU...  but as long as the emulation is stuck it doesn't make much sense.

So I think I will follow your path, trying to find the relevant stubs for ML Hello World. As the two models are very similar we should be able to benefit from each other.

I use Ghidra, too.  I wrote a small Getting Started for the 77D ROMs. It should be nearly identical for the other Digic 7 cameras: https://github.com/calle2010/magic-lantern-77d-vagrant/blob/master/ghidra.md
Im happy for feedback and tips since this is the first time I use a tool like this.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on April 03, 2019, 11:25:41 PM
It's a nice Ghidra guide, I like it!  I made some changes but git push gave me a 403, so I guess I can't submit a pull request?  I'm not very good with git, maybe it's something else.  I put my edits here: https://pastebin.com/vP5TNPt1

There are two things that I think will make your life much easier - I think you have the "language" wrong, and should be using ARM Cortex 32 little endian, not ARM v7. Second, you shouldn't load each ROM as a file in your Ghidra project (I made this mistake too).  This makes each file separate and disassembly can't see stuff in the other files, so you will get lots of broken refs.  Instead, load the main ROM, then use File -> Add To Program.  This puts all the files in the same address space and disassembly works much better.

Third...  I should really write a Ghidra script that reads stubs.S and disassembles and labels every code address.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on April 04, 2019, 12:49:18 AM
Quote from: names_are_hard on April 03, 2019, 11:25:41 PM
I made some changes but git push gave me a 403, so I guess I can't submit a pull request?

You could create a PR from your own fork. But you can't directly push to another repository if permissions haven't been setup.

Thank you very much for the edits. I took them over manually. What started as my personal notes for the 77D may turn into a ML Ghidra guide.  :)

QuoteI think you have the "language" wrong, and should be using ARM Cortex 32 little endian, not ARM v7.

I will check this. I though ARM v7 architecture is correct for the Cortex A9 processor? Actually I'm a bit confused by the choices in Ghidra...

QuoteSecond, you shouldn't load each ROM as a file in your Ghidra project (I made this mistake too).  This makes each file separate and disassembly can't see stuff in the other files, so you will get lots of broken refs.  Instead, load the main ROM, then use File -> Add To Program.  This puts all the files in the same address space and disassembly works much better.

Actually this is what I do, but my language was not clear enough.

Quote
Third...  I should really write a Ghidra script that reads stubs.S and disassembles and labels every code address.

...and also for named_functions.idc :-)

Btw: I use F12 always instead of D since the thumb flag is not persisted. In the next session "D" may try to analyze ARM instead of Thumb again. Nearly all code of the 77D seems to be Thumb.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on April 04, 2019, 03:33:31 AM
Quote from: calle2010 on April 04, 2019, 12:49:18 AM
You could create a PR from your own fork. But you can't directly push to another repository if permissions haven't been setup.
Okay, makes sense, thanks.

Quote
I will check this. I though ARM v7 architecture is correct for the Cortex A9 processor? Actually I'm a bit confused by the choices in Ghidra...
Earlier in this thread Alex says it's Cortex.  I may be wrong that it makes a difference, I thought that all Cortex were v7 but not all v7 were Cortex, but now I'm not sure.  I looked at the Ghidra definitions in Ghidra/Processors/ARM/data/languages and it seems they're treated very similarly.  I think Cortex might default to Thumb, where v7 doesn't.  Might explain why D works fine for me most of the time?

Quote
...and also for named_functions.idc :-)
Yes, similar thing, should be easy.  Although named_functions doesn't find much for me.  I guess because emulation is quite limited so far.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on April 04, 2019, 08:22:21 AM
Found stubs for 800D 1.0.1 (https://bitbucket.org/aprofiti/magic-lantern/commits/4cb18d3a18bf0b52f3b6f1b40cfaedea45769ff1) and 6D2 1.0.3  (https://bitbucket.org/aprofiti/magic-lantern/commits/b9c48404f066ee14097905e1eec1308ddd797882)6D2 1.0.4 (https://bitbucket.org/aprofiti/magic-lantern/commits/d9d813cf507eb4f4858336c2f422331da4fce5db); now they have possibility to join the party :)

You should be able to save a log from startup as the other d7 cameras (please test and report).
Next step will be to find bmp_vram_info for hello world code, then start to port ML.

Is there someone who has these cameras and is willing to try bootflag enabler?

edit: Updated 6D2 stubs list to 1.0.4
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: totalmichel on April 04, 2019, 11:37:44 AM
Quote from: aprofiti on April 04, 2019, 08:22:21 AM
Found stubs for 800D 1.0.1 (https://bitbucket.org/aprofiti/magic-lantern/commits/4cb18d3a18bf0b52f3b6f1b40cfaedea45769ff1) and 6D2 1.0.3 (https://bitbucket.org/aprofiti/magic-lantern/commits/b9c48404f066ee14097905e1eec1308ddd797882); now they have possibility to join the party :)

You should be able to save a log from startup as the other d7 cameras (please test and report).
Next step will be to find bmp_vram_info for hello world code, then start to port ML.

Is there someone who has these cameras and is willing to try bootflag enabler?

i have an 6D2 but it has the latest firmware 1.0.4
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on April 04, 2019, 01:30:57 PM
You can try the FIR version (https://www.magiclantern.fm/forum/index.php?topic=19737.msg200460#msg200460) of the rom dumper and ask a1ex for bootflag enabler (after that It is possibile to run custom binary on camera).

Then share the dump (send a PM) so we can work on an updated version (time consuming but it should be worth if there is collaboration) for 1.0.4.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: totalmichel on April 05, 2019, 06:18:38 PM
a1ex can you send me the bootflag enabler for 6D2?

just finished sending the 1.0.4 dump to aprofiti
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: buro341 on April 11, 2019, 08:36:37 PM
just a supporter here, how are things going guys?  :D
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on April 11, 2019, 08:45:16 PM
There is the expected slow progress.  It will likely be several months minimum before anything major happens.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Nicolas Apud on April 12, 2019, 12:54:38 AM

Hi, I have a 6D2  and I would like to help
[email protected]
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: buro341 on April 15, 2019, 05:28:55 PM
Thnx for the info. I really don't like ipb for the 77d  :'(
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: tekrevz on April 16, 2019, 03:12:30 AM
I know this is a naive question. But how quickly /easy would a change to bitrate of the 6dm2 video be. Could you theoretically go into the code and just change the number?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: scrax on April 16, 2019, 01:02:39 PM
Quote from: tekrevz on April 16, 2019, 03:12:30 AM
I know this is a naive question. But how quickly /easy would a change to bitrate of the 6dm2 video be. Could you theoretically go into the code and just change the number?
ML don't changes any code in canon firmware, so for any function ML need to be ported for the cam at first, before doing anything
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on April 23, 2019, 10:54:54 PM
I'm having problems finding stubs for 200D.  I have almost all of them found (can probably mock out the rest for now), except the EDMAC family, which look quite important.  Does anybody on a Digic 7 cam have any found?  It looks to me that something important changed.  There are very few EDMAC related strings on 200D.  Case insensitive grep for edmac gives me 138 unique strings on 50D, 12 on 200D.

The only one that looks like a function name is WriteEDmacCompleteCBR, but that's not in stubs for other cams and hasn't been a good enough clue for me so far to locate the rest.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on April 25, 2019, 12:16:49 AM
Possibly related, 200D has PCIe related strings, including:

WriteDMAPCIeCom
WriteDMAPCIeCom
ReadDMAPCIeCom
ReadDMAPCIeCom
CompletePCIe_DMA
CompletePCIe_DMA

There are also xdmac strings, not very many, some are close to some PCIe strings.  I'm not convinced there's a link to edmac, but I'll explore further.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: calle2010 on April 25, 2019, 07:50:35 PM
Quote from: names_are_hard on April 25, 2019, 12:16:49 AM
There are also xdmac strings, not very many, some are close to some PCIe strings.  I'm not convinced there's a link to edmac, but I'll explore further.

Thank you for sharing the information. Currently I have very little time to spend on ML. I think in May I would try to catch up with the 77D stubs based on yours and also try to understand the EDMAC.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on April 29, 2019, 12:06:19 AM
Also perhaps noteworthy, a family of new "lime" strings, eg:

LimeXdmac/XdmacApi.c
LimeSdIo/SdWlanIf/SdWlanIf.c
[NWCOM] Lime WorkLoad DMA
LimeSdIo/SdWlanIf/SdWlanIf.c
platform/lime/sd_wif11n.c

Many, though not all, seem to be wifi related - 200D does have wifi.  So perhaps this is a dma controller for that only, and doesn't replace Edmac?  Or perhaps Canon consolidated all DMA with a new controller.
I found this Fujitsu link which might be relevant, but could just be a naming coincidence:
https://www.fujitsu.com/us/products/devices/semiconductor/gdc/doc/an-dma.html
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on April 29, 2019, 09:00:21 AM
As for lime strings, from EOS R:

"NetDomain::LimeKick.c":
"LimeInit":
"Error : bad parameter(LimeClock).":
"Inport(CCLIME_TIC_WDLPS_ADDR) == val":
"Inport(CCLIME_TIC_WDLP_EN_ADDR) == val":

"LimeSdIo/SdDom/SdClk.c":
"LimeSdIo/SdDom/SdCmd.c":
"LimeSdIo/SdDom/SdCommon.c":
"LimeSdIo/SdDom/SdCon.c":
"LimeSdIo/SdDom/SdDebug.c":
"LimeSdIo/SdDom/SdDma.c":
"LimeSdIo/SdDom/SdDom.c":
"LimeSdIo/SdDom/SdIo.c":
"LimeSdIo/SdDom/SdLog.c":
"LimeSdIo/SdDom/SdReg.c":
"LimeSdIo/SdDom/SdResource.c":
"LimeSdIo/SdWlanIf/SdWlanIf.c":
"LimeSdIo/SdWlanIf/SdWlanIfConfig.c":
"LimeXdmac/XdmacApi.c":
"LimeXdmac/XdmacDrv.c":
"LimeIntc.c":
"LimeKick.c":
"CclimeSdIo/TsumSd/SdCmd.c":
"CclimeSdIo/TsumSd/SdCon.c":
"CclimeSdIo/TsumSd/SdDma.c":
"CclimeSdIo/TsumSd/SdIo.c":
"CclimeSdIo/SdWlanIf/SdWlanIf.c":

"[NWCOM] Lime Load Complete For XDmac(Ch=%d)":
"[NWCOM] Lime Load Complete For CPU":
"[NWCOM] LimePanic":
"[NWCOM] LimeExcept":
"[NWCOM] LimeAssert":
"[NWCOM] Lime WorkLoad CPU":
"[NWCOM] Lime WorkLoad (DMA)->CPU":
"[NWCOM] Lime Init":
"[NWCOM] Lime Uninit":

and more. So seems to be related to WiFi / SDIO is used for WiFi card internally (that's interesting)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on April 29, 2019, 09:33:03 PM
Thanks for the comparison.  How many edmac strings do you have?  EOS R is Digic 8, it would be interesting if it still had the 100s that old cameras have.  My guess is it'll have 10s like 200D.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on April 29, 2019, 09:45:32 PM
kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i edmac | wc -l
121
kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i pcie | wc -l
70

:)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: josecarlosss on May 04, 2019, 02:41:40 AM
Hi guys, i am an owner of a Canon 77D, and i was wondering  how can i help to make the magic lantern useable for 77D.

Is there any news about the built for 77D?

Best regards
Stelios
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on May 04, 2019, 02:49:20 AM
Quote from: josecarlosss on May 04, 2019, 02:41:40 AM
Hi guys, i am an owner of a Canon 77D, and i was wondering  how can i help to make the magic lantern useable for 77D.

Build a development environment, startup QEMU, dump ROM files and make your first steps inside the emulator.
Tutorials how to make QEMU run are available.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on May 05, 2019, 02:22:43 AM
Quote from: kitor on April 29, 2019, 09:45:32 PM
kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i edmac | wc -l
121
kitor@kitor-pc:eosr-120$ cat ROM0.BIN.strings | grep -i pcie | wc -l
70

:)

So it seems Digic 7 is the strange one! I have found some DMA related code now, "DmacCh" was a useful string. I can see some possible init code around 0xe007e02c.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on May 05, 2019, 10:37:37 AM
Quote from: Walter Schulz on May 04, 2019, 02:49:20 AM
Build a development environment, startup QEMU, dump ROM files and make your first steps inside the emulator.
Tutorials how to make QEMU run are available.

Walter, I see a similar post from time to time.
Unfortunately (from few years experience working with developers (!, so people who should know the drill) in quite large project), I don't think people who ask those questions does understand problem at all.

For average person installing software on new PC is like... download it and install. They think that the problem is that with their new camera no one yet tried to download and install ML and provide feedback that it works (yup, I'm oversimplifying, but again, experience tells me to expect low unless proven wrong).

We know that ML code doesn't grow on trees. (https://www.magiclantern.fm/forum/index.php?topic=17695.msg207023#msg207023) (great quote btw!). But this means nothing even for pro photo/videographers who used ML for living, if they don't have any computer engineering background.

IMO, the real answer should be like:

Quote from: kitor's alter egoUnless you know or want to learn how (https://www.magiclantern.fm/forum/index.php?topic=15895.msg185103#msg185103) to (https://www.magiclantern.fm/forum/index.php?topic=19417.0) do (https://www.magiclantern.fm/forum/index.php?topic=12657.0) any (https://www.magiclantern.fm/forum/index.php?topic=22770.msg211977#msg211977) of (https://www.magiclantern.fm/forum/index.php?topic=2864.msg204397#msg204397) this (https://www.magiclantern.fm/forum/index.php?topic=9625.0), wait patiently for news containing download links, or grab a camera that is supported now (https://builds.magiclantern.fm/).

Sorry for OT, but something tells me this post may be much better answer for all people asking.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: totalmichel on May 14, 2019, 01:42:04 PM
Im willing to test the bootloader enabler on my spare 6D2 and also run any test
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: totalmichel on June 14, 2019, 06:37:14 PM
maybe its a dumb question
the 6d2 was a mov 4k codec available for timelapse mode
is there any way to activate it for regular movie without the need to fully develop magic lantern for it? maybe some special code that if the cam turns on on movie mode enables it?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 14, 2019, 10:07:43 PM
Very unlikely. Magic Lantern is the "special code" that allows changing how the cam behaves.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: totalmichel on June 14, 2019, 10:19:15 PM
Quote from: names_are_hard on June 14, 2019, 10:07:43 PM
Very unlikely. Magic Lantern is the "special code" that allows changing how the cam behaves.

I dont know much about assembly , but from what i got from the code exemples ML peeks and pokes memory adress to change settings, we already know that 6D2 can run custom codes. so what is necessary is to know where to poke the memory adress to change the codec.
i know how to program c# (not very useful to ml porting), so i'm investigating about arm assembly, and trying to learn basic stuff (as difficult as it may be), i also know that theres a way to log what the camera memory does while using different stuff (its used to find free memory spaces)

what i need to know is theres any way to find where to poke? and any way to make it run on power on? (even if necessary an custom card for it)

i know that is not ML porting, but it could be a temporary patch to enable the native 4k codec
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 14, 2019, 11:14:51 PM
As I understand it, a lot of the difficulty is in getting ML to stay memory resident through the boot process.  There is also a great deal of complexity dealing with an interrupt driven real-time OS with multiple processors.  What you're asking would need all of that stuff.  And at that point the hard parts of porting ML are done, so you may as well use ML and get the rest for free.

In any case, this is getting quite off-topic for this thread - really you are asking "is there a way to do just one thing on any Canon cam, I don't want all of ML". 
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: totalmichel on June 15, 2019, 12:26:38 PM
Quote from: names_are_hard on June 14, 2019, 11:14:51 PM
As I understand it, a lot of the difficulty is in getting ML to stay memory resident through the boot process.  There is also a great deal of complexity dealing with an interrupt driven real-time OS with multiple processors.  What you're asking would need all of that stuff.  And at that point the hard parts of porting ML are done, so you may as well use ML and get the rest for free.

In any case, this is getting quite off-topic for this thread - really you are asking "is there a way to do just one thing on any Canon cam, I don't want all of ML".

im not asking to be developed for me, im asking the more seasoned devs if theres any way i can try to develop that, or if is just impossible.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 15, 2019, 04:15:18 PM
Ah, I see, I hadn't understood that absolute possibility was what you were concerned with.  It would certainly be *possible* to do what you're asking.  It would probably be easier to port ML, then add the feature you want, than develop the feature you want from scratch.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: TolisK on June 21, 2019, 08:16:16 PM
Hi is there a final version of magic lantern for 6DII?

I' tried runnig dumb autoexec with no results.

Any help?
THank you in advance
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 22, 2019, 06:17:18 AM
If there was any news about 6D2 it would probably be in this thread.  I'm not even sure anyone is working on a 6D2 port.  Certainly there is not a final version.  Sorry to disappoint!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on June 22, 2019, 11:39:01 AM
I have been looking through several ram dumps of 200D and i was wondering where is the output of the raw DryOS debug messages and for that i need the following question to be answered.(I'd really appreciate it) 

Where is the debug port for the 200D?
can the WIFI or NFC interface be used to send logs to the host (or any suitable interface for logs) ?


I have not been actively working on magic lantern either as i do not know what i am looking at.i just end up brut-forcing stuff which i know is not going to get me anywhere 
Thank you,
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on June 22, 2019, 03:13:36 PM
By looking at the board photo from Aliexpress, it's the same style connector as on EOS R / RP, located under thumb rubber, near USB connector.
Just educated guess.

As connector is visually the same, pinout for R is here:
https://www.magiclantern.fm/forum/index.php?topic=7531.msg212071#msg212071

If that checks out - FPC that goes into it is less than usuall 0.5mm pitch.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on June 22, 2019, 05:26:20 PM
QuoteBy looking at the board photo from Aliexpress, it's the same style connector as on EOS R / RP, located under thumb rubber, near USB connector.
Just educated guess.
It's exactly the same but the pins could be different.Now its time to dissect a old video player and hopefully find the right FPC cable

(https://i.postimg.cc/j2KcZN0M/IMG-20190622-202111.jpg)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 22, 2019, 05:59:40 PM
Fun to see a debug port!  I am still working on 200D but it's very slow, I keep getting stuck with invisible bugs.  I can build a CONFIG_HELLO_WORLD autoexec but it doesn't boot and I can't even find a place to LED blink to diagnose, QEMU or real cam (I guess it crashes very early).  The same source, built for 50D, does boot in QEMU, so I'm hoping this means my build is okay, but my stubs or similar (register constants? MPU stuff?) are wrong.

Debug port could be very helpful.  I'd join you but my electronics stuff is in a shipping contiainer 1000 km away.

Currently I'm working on making gdb go further with 200D, I have some limited progress and I'm improving my gdb scripting.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on June 22, 2019, 06:00:30 PM
So at least location is right. As for this FPC pitch - I doubt you will find one, I measured it to be probably 0.4mm (maybe 0,35mm - hard to measure without desoldering connector), found just a single china source for matching parts...  :(
I don't think they are using different pinouts, as connector is already exotic (it's impossible to use standard 0.5mm cable as it will short pins to ground). But if you find anything (or want to disassemble camera - on R there are testpads near connector that I used for all of my work), please update thread I linked before with your findings  :)

@names_are_hard - debug connector is very useful. In R stubs you can find one for uart_printf, that was the only way I was able to debug R before I found out my RAM dump was wrong and I had 1-byte offset framebuffer location :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on June 22, 2019, 06:53:24 PM
@kitor How did you measure the pitch of the FPC connector with that small size?

P.S there is a very slim chance of me opening up the camera and probing points as my parents will most likely evaporate me from existence if they found out.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 22, 2019, 07:50:35 PM
Very interesting, mine isn't FPC.  Jack's has a K2 label, I have K1 - and inside 3 exposed pads.  Serial port without ground?

(https://i.postimg.cc/DwpbnQX4/200d-k1-port.png)
(my only nice macro lens is on the 200D...)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on June 22, 2019, 08:10:35 PM
Quote from: jack001214 on June 22, 2019, 06:53:24 PM
@kitor How did you measure the pitch of the FPC connector with that small size?

Caliper (https://en.wikipedia.org/wiki/Calipers)  ;)

QuoteP.S there is a very slim chance of me opening up the camera and probing points as my parents will most likely evaporate me from existence if they found out.
And I disassembled mine. Still over a year to end loan payments, but that's the things you do for Science! ;)

QuoteVery interesting, mine isn't FPC.  Jack's has a K2 label, I have K1 - and inside 3 exposed pads.  Serial port without ground?
Took me a moment to realize "K1" and "K2" is molded into case. I don't believe it's related to what's inside. More likely different factory code or something.

Side note: While RP on promo video had both debug connectors soldered (like my retail R does, 2nd we guess to be jtag), on photos from retail ones this 2nd connector is missing (pads only).
If those 3 pins are serial, then my bet is rx/tx/gnd, but IIRC all known cameras exposes both CPU and MPU serial ports, so this would be werid.

Since quality of picture is as visible, I see like three pads with solder on them just above those three, and something possibly hidden under sticker... like if connector just isn't soldered in.
That would fit as connector is 8 pin, soldered 4 pins on each side of connector.
I can't find any high res photo of the board to confirm those suspicions. Look at 2nd photo here: Aliexpress (https://www.aliexpress.com/item/New-main-circuit-Board-mother-board-PCB-repair-parts-for-Canon-EOS-200D-SLR/32917863882.html) - that's best I found.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 22, 2019, 08:34:15 PM
Comparing the aliexpress pic, yes, it does look like the connector is missing, nice find, thanks.  The sticker thing is the silver braided cushion you can see in aliexpress pic.  There are four soldered pins hidden by case (these are ones visible in aliexpress), I think only 3 on the other side.  The 3 and 4 are not aligned but do look the same pitch.

If the three gold pads don't act as test pads for Vcc/GND, Rx, Tx it's going to suck to connect to.  I won't have access to tools until next month anyway.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on June 22, 2019, 08:40:01 PM
Quote from: jack001214 on June 22, 2019, 06:53:24 PM
P.S there is a very slim chance of me opening up the camera and probing points as my parents will most likely evaporate me from existence if they found out.

Don't worry - the UART port is not going to provide much info on top of what you already get from logs saved to the SD card. It's actually the opposite - our logs (i.e. those saved to SD) actually provide a bunch of context info, timestamps, program location and so on, besides the actual messages.

I've also found real-time logging via UART problematic while troubleshooting bricked cameras - it's just too slow to print all Canon's messages in real-time. No wonder they are printing only a tiny subset, and even that happens in a background task.

On EOS R, the UART port was the only way to get in. That's why it was very useful there, but - in my opinion - it's not necessary for ML development or reverse engineering on earlier models (including all DIGIC 6/7, and also the DIGIC 8 "PowerShot" hybrids).

That port is, however, very useful to troubleshoot a camera that doesn't boot (read: a defective camera). It could also also help with debugging early startup code, but that part was already done. Besides, for early startup code, I believe debugging is much easier in QEMU (even with the current limitations). Even if you don't get a display, you do have a way to run the program step by step, to trace calls to arbitrary functions and other stuff like that.

If you just want to read the UART messages, connect the ground to the hot shoe (it worked for me on 5D3), and hold a needle onto the test pin (TX on the camera board, RX on the dongle). That should do the trick, without a FPC.

Quotecan the WIFI or NFC interface be used to send logs to the host (or any suitable interface for logs) ?

Yes, but currently the only notes on the Wi-Fi interface are these (http://magiclantern.wikia.com/wiki/6D/Networking) (for the old 6D). One could certainly attempt to find the stubs and try that proof of concept code.

An easier way (read: without requiring additional reverse engineering) is to use a Wi-Fi SD card (https://www.magiclantern.fm/forum/index.php?topic=17041.0). You don't need a Wi-Fi camera for that.




QuoteAs I understand it, a lot of the difficulty is in getting ML to stay memory resident through the boot process.

Actually this step wasn't *that* hard, and is already solved for all DIGIC 6/7/8 models :)

The minimal "Hello World" code runs on top of that.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on June 22, 2019, 10:43:18 PM
QuoteYes, but currently the only notes on the Wi-Fi interface are these (for the old 6D). One could certainly attempt to find the stubs and try that proof of concept code.
My new task.

QuoteI've also found real-time logging via UART problematic while troubleshooting bricked cameras - it's just too slow to print all Canon's messages in real-time. No wonder they are printing only a tiny subset, and even that happens in a background task.
Bummer! Well that saved saved me from evaporating.  :D

QuoteVery interesting, mine isn't FPC.  Jack's has a K2 label, I have K1 - and inside 3 exposed pads.  Serial port without ground?
I think that could be a newer revision.
maybe to keep us out?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 23, 2019, 09:31:05 PM
Probably not to keep us out :)  Really Canon are remarkably friendly for reverse engineering.  There are many standard anti-reversing measures they could take that they choose not to.

In other news, I have found a large mistake I had made porting to 200D!  I've found a major cause for CONFIG_HELLO_WORLD ML not booting, even though digic6-dumper would boot.  I had forgotten / not noticed that the dual-cpu code for avoiding race conditions was only in digic6 branch.  So, I've been porting that code into unified for 200D.  I've *almost* got it building, but it's failing at link time:

Quotearm-none-eabi-ld: patch.o: in function `_patch_sync_caches':
patch.c:(.text+0xf4c): undefined reference to `_flush_i_cache'

I'm not sure but I think this code is broken on digic6, too, but digic6 is so stripped down that it doesn't build patch.c.

My changes are here if anyone would like to explain why I'm being stupid :)
https://bitbucket.org/stephen-e/ml_200d/commits/7ac5c6f5acc78be7df87e853235d52c2d826fa00
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 24, 2019, 07:58:12 AM
More progress.  Couldn't work out why the symbol isn't visible to the linker, so I faked that out.  Some gdb work later and I realised I hadn't defined SIG_START so it was picking up a default.  It now passes FW checksum code.  Crashes very early, but, it now gets far enough to show a stuck LED in real cam - before it was failing too early even for that.  I can now crash ML, not just digic6-dumper  :D

I guess now I'll be spending lots of time in gdb.  If only it didn't have the worst UI of any debugger I've ever used.  Oh well, I do keep telling myself it's a useful tool to learn.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: totalmichel on June 24, 2019, 10:56:46 PM
Quote from: names_are_hard on June 24, 2019, 07:58:12 AM
More progress.  Couldn't work out why the symbol isn't visible to the linker, so I faked that out.  Some gdb work later and I realised I hadn't defined SIG_START so it was picking up a default.  It now passes FW checksum code.  Crashes very early, but, it now gets far enough to show a stuck LED in real cam - before it was failing too early even for that.  I can now crash ML, not just digic6-dumper  :D

I guess now I'll be spending lots of time in gdb.  If only it didn't have the worst UI of any debugger I've ever used.  Oh well, I do keep telling myself it's a useful tool to learn.

very nice, thumbs up
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 30, 2019, 05:19:20 PM
Some progress and an unexpected problem - QEMU now gets further than real hardware.  I'm comparing a CONFIG_HELLO_WORLD build from my patched unified branch against a digic6-dumper build.  I'll call these ML200 and D6.  Here's the 200D code:
https://bitbucket.org/stephen-e/ml_200d/commits/f3d7f1c6face84e4d4f7d01125ded4e56b939144

Debugging via LED blinking, ML200 on real HW is locking up when cstart() tries to transfer control to copy_and_restart().  In QEMU this call works okay!  D6 transfers control okay on QEMU and HW.  I don't know what might cause this, and I'm unsure how to debug it - can anyone help?  Perhaps something to do with the larger size of ML200 vs D6?  Here's the build output for that:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000100 0x001b6300 0x001b6300 0x33ef4 0x3e8fc RWE 0x100  (ML200)
  LOAD           0x000060 0x001b6300 0x001b6300 0x01b4c 0x02ea8 RWE 0x10  (D6)

Looks boring to me.  Any ideas on how to debug appreciated.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 03, 2019, 03:29:22 AM
Significant progress: now gets as far as my_init_task()!  This is nice, many more functions are available, logging to disk should be possible. My previous problem was defining a static function with the same name in boot-hack.c and reboot.c.  Ordinarily that wouldn't be a problem, static, so only visible within that file == no name conflict.  But here we copy raw mem from boot-hack object file while in reboot code - the compiler can't save me from that conflict.  So, don't do that.  Don't know why it doesn't break in Qemu.

It's currently failing the ml_used_mem > ml_reserved_mem check and therefore LED blinking forever.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 04, 2019, 03:35:36 AM
Can now boot a fair way, it returns from Canon's init task, power on switch works, buttons are responsive (they all make it crash, that's a response).  No back screen and cam generally errors out quite quickly (with Err in viewfinder).  The good news: I can log to DEBUGMSG.LOG and see asserts so I have good hints on how to proceed.

The code is kind of ugly, in particular I'm not sure the changes in qemu-util.c and .h should go into unified.  I don't recommend running this one, but here it is:
https://bitbucket.org/stephen-e/ml_200d/commits/57efead89219199cfaab686d72b0fb532d5afe2e
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on July 04, 2019, 08:05:39 PM
Impressive! Keep it up! I do not have  knowledge on disassembly and reverse engineering and i wish i could help.
Don't stop keep on going(you know i might own a 200D).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 05, 2019, 04:26:11 AM
It can boot to Canon menus now, but often hangs afterwards.  One definite problem is initialising fonts; 200D (and other digic7 I think? Can't find this on the forum, maybe it was IRC) uses Opentype, not bitmap.  This makes our init error (it's not possible to give a valid address for BFNT_CHAR_CODES to bfnt_ok()).  Digic6-dumper uses some fixed bitmap font I believe, I'll port that next as the easiest option.

At some point I suppose we want an opentype renderer, or some one time step to convert those to bitmap, dump to ML dir, and ML init could load them to mem.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 07, 2019, 08:17:02 PM
Reliable booting to Canon menus.  Okay-for-now workaround for the font problem (conditionally skip the Canon font initialisation and only use the RBF fonts on the card).  Means you can't do early logging to the display, but I've changed the logging to disk code so it makes sequential numbered DBG00000.LOG files.

@kitor pointed me at some vram changes in DIGIC7 that were very useful - hello_world() now prints to display...  but the output is junk.  Need to change some consts to get the offset into display right (maybe just BMP_VRAM_START) and do colour correction since DIGIC7 uses YUV display.  Then see why the font output is garbled.

Anyone know if the RBF font routines require valid Canon bitmap fonts?  I'd guess not, looks like we use Canon fonts as fallback, but I don't really know.

I think this commit is mildly broken and needs an msleep(2000) ish before log_finish() in boot-hack.c (or the menus won't load before hello_world() starts and blocks; this means back screen won't display).  Too lazy to retest and push, local build works, I'll push something else soon enough:
https://bitbucket.org/stephen-e/ml_200d/commits/2fffa3bbda8980fdc3ce1c3fe1a8323ddaee45f4
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on July 08, 2019, 08:30:51 AM
Won't bmp_putpixel_fast from bmp.h be a problem here? It's used by font_draw_char from frb_font.c:


inline void bmp_putpixel_fast(uint8_t * const bvram, int x, int y, uint8_t color)
{
    /* vxvorks skipped */
    bvram[x + y * BMPPITCH] = color;
    /* 500d skipped ;) */
}


It's definitely not YUV-aware.

What about replacing it with code based on disp_set_pixel from minimal.c in digic6-dumper?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 09, 2019, 02:18:30 AM
Yes, bmp_putpixel_fast() is part of the problem.  disp_set_pixel() also wants fixing in unified, which isn't as simple as I expected, a bunch of symbols are in different places in unified vs digic6-dumper.

I haven't looked much at how bmp_putpixel_fast() is using its colour param.  It's an enum (eg, COLOR_GREEN1 in bmp.h), but seems to get written direct to vram, so I'm missing something.  Not immediately obvious how to map to YUV (maybe it's not needed, map the YUV to the color params first?).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on July 09, 2019, 08:34:29 AM
I see some discussion about YUV stuff on chdk forum -> https://chdk.setepontos.com/index.php?topic=11316.120

As for "simply replacing" - from what I understand now, YUV buffers have also alpha channel, so replacing rgb values with yuv ones will produce werid results (mentioned in chdk thread too). And Canon seemed to change this twice - once to UYVY + separate opacity data that's in 200D (according to comments in minimal.c - and by "adapted from names_are_hard" i believe you are aware of that ;) ) and then to UYVYAA (5D4, M50, R...)

For now I would just replace bmp_putpixel_fast with implementation based on CONFIG_DIGIC_678 part of disp_set_pixel in digic6-dumper/minimal/hello-world/minimal.c, completly ignoring bvram and converting 8 bit input into 32 by some bitwise operations (?, i was never good at optimizing low-level stuff) since now it's hardcoded to white. This surely will be order of magnitude slower, but if that takes us into ML menu, i guess that's good idea to fix/optimize it after we know that we can do GUI stuff.

As for
Quotedisp_set_pixel() also wants fixing in unified, which isn't as simple as I expected, a bunch of symbols are in different places in unified vs digic6-dumper.

I thought that this is used only from BL context, so not required at this stage:
grep -irw disp_set_pixel ./
./src/font_direct.c:    disp_set_pixel(x, y, c);
./src/disp_direct.c:void disp_set_pixel(uint32_t x, uint32_t y, uint32_t color)
./src/minimal.c:void disp_set_pixel(int x, int y, int c)
./src/disp_direct.h:void disp_set_pixel(uint32_t x, uint32_t y, uint32_t color);
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on July 09, 2019, 08:44:03 AM
Quote from: names_are_hard on July 09, 2019, 02:18:30 AMa bunch of symbols are in different places in unified vs digic6-dumper.

Yeah, that's because I did some changes in digic6-dumper in order to accommodate DIGIC 6/7/8 models, in particular, the refactoring to allow different boot methods, or the one to allow different kind of stubs (https://bitbucket.org/hudson/magic-lantern/commits/6aff5f72ba485652bfd902de0fb1b6fe3480ff0d?at=digic6-dumper) (such as ARM or Thumb code). Indeed, that branch went a little beyond "just" a simple dumper stage.

The digic6-dumper branch also contains a couple of experimental backends, that are not yet in unified:
- qemu (pretty much ready for merging (https://www.magiclantern.fm/forum/index.php?topic=2864.msg214887#msg214887) if you ask me)
- new-dryos-task-hooks (also pretty much ready (https://bitbucket.org/hudson/magic-lantern/pull-requests/672/dryos-task-hooks-for-newer-cameras-6d-70d/diff), depends on qemu, but there may be surprises (https://www.magiclantern.fm/forum/index.php?topic=15088.msg191948#msg191948))
- lua_fix (needs testing on currently supported cameras (https://www.magiclantern.fm/forum/index.php?topic=14828.msg194706#msg194706); depends on qemu, new-dryos-task-hooks, 100D and some others; basically good, but many model-specific changes to review; currently broken on at least 5D2 and 500D)
- patchmgr (breaks 7D, may break some reworked features, needs cleanup, no dependencies (https://bitbucket.org/hudson/magic-lantern/pull-requests/687/patch-manager))

So, I'd say the logical path to include DIGIC 6/7/8 into unified would be to merge the above branches (and their dependencies) first. There's also calle2010's task rework (https://bitbucket.org/hudson/magic-lantern/pull-requests/958/replace-is_taskid_valid-with-direct-access/diff) that needs to be included, as it should be applied to all DIGIC 4/5/6/7/8 models. Unfortunately, a straw broke the camel's back (https://www.magiclantern.fm/forum/index.php?topic=23927.0), so... I'm very sorry these things are not done yet :(

In any case, I see your efforts as major progress - sometimes, reinventing the wheel (https://blog.codinghorror.com/dont-reinvent-the-wheel-unless-you-plan-on-learning-more-about-wheels/) can be very helpful to understand how things work.

Quote from: names_are_hard on July 04, 2019, 03:35:36 AMThe code is kind of ugly [...]

That's also my issue - I can easily bang out code that does the job, but turning it into something clean and maintainable, with comments and without breaking existing stuff, and with readable history... requires a lot of extra effort from my side. Maybe it's worth it in the long run, I don't know. I don't have any experience with maintaining large codebases, besides ML.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 10, 2019, 02:27:55 AM
kitor: I don't think bmp_putpixel_fast() is called with rgb values at all.  Look at the values when it's called, and the constants in bmp.h, eg, COLOR_WHITE is 1, COLOR_BLACK is 2.  Indexed colour maybe.  I need to understand this better before I can change it.  Probably won't have much time to work on it before the weekend.

I don't know what disp_set_pixel() is used for, but it's the easier thing to port, so I may as well do both.  I guess this is quite a long way from a menu :)  This is a CONFIG_HELLO_WORLD build, it bails out very early.  Still, having fonts will make debugging much faster.

Alex: sadly I have taken a horrible mix of your changes as I've noticed them or found them useful!  All the ugliness in my branch is my fault.  Your suggestion on merging the various branches makes sense to me, but I really struggled with hg.  I lost changes multiple times.  That's why I moved the whole thing to git, but that makes clean merges harder.  Again, my fault.  If it ever gets nice enough to merge back into real unified I'll make an hg repo.  And if I get up to say, menus, I'll be able to notice if I broke something trying to merge in other things to my code.  Currently it's all broken, can't tell if I did a bad merge ;)

There's no need to apologise for not having magically created enough hours to do my work for me!  It's nobodies work really, we're all volunteers, mostly because we want cool toys for our own cameras I guess.  Besides, I wouldn't have started working on this if I didn't enjoy these low-level puzzles.  And yes, definitely learning more doing things the hard way, which is fine by me.

I don't have a reliable opinion on the shape of the code yet.  I can't tell which parts are actually ugly, and what is simply my confusion.  Probably mostly the latter!  Generally I'd say make it work first, then make it reliable, then, maybe, pretty.  I've reviewed millions of lines of C and seen much, much worse (in commercial products...).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on July 10, 2019, 08:18:40 AM
Quote from: names_are_hard on July 10, 2019, 02:27:55 AM
kitor: I don't think bmp_putpixel_fast() is called with rgb values at all.  Look at the values when it's called, and the constants in bmp.h, eg, COLOR_WHITE is 1, COLOR_BLACK is 2.  Indexed colour maybe.  I need to understand this better before I can change it.  Probably won't have much time to work on it before the weekend.

You are right! I looked at uint_8t, saw color definitions and just assumed it without looking at the numbers. Lesson learned once again: don't assume things  :)
https://magiclantern.fandom.com/wiki/VRAM/BMP
https://chdk.fandom.com/wiki/Frame_buffers -> "Bitmap (or Overlay)"
https://chdk.fandom.com/wiki/Palette
Indeed that's an indexed palette, i guess that it was more consistent between EOS cameras than on PowerShot models, but this apply:
#define COLOR_TRANSPARENT_GRAY  0x14 // not portable, old cameras show it as magenta

Since CHDK is running on D6+ cameras, I checked their code (on dev trunk) and while their functions have a bit different definitions, core/gui_draw.c seems to have all the magic implemented that needs to be ported here.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: esinem on July 10, 2019, 05:38:52 PM
As a non-techie user, I assume this geek talk means an 800D/T7i version is on the way? Does anyone have any idea when a download is likely to become available for your average idiot like me? :-)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on July 10, 2019, 05:47:31 PM
Answered in
Top of page -> User Guide -> FAQ -> Troll Questions
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: totalmichel on July 11, 2019, 01:02:08 AM
Quote from: Walter Schulz on July 10, 2019, 05:47:31 PM
Answered in
Top of page -> User Guide -> FAQ -> Troll Questions

👏👏👏
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 11, 2019, 03:03:58 AM
@kitor - those CHDK links were very helpful, thank you!  It *used* to be indexed, but now it's not.  That's good, I can ignore the indexed code and simply replace it (ifdef for > Digic 5).

@esinem - I don't know that anyone is working on an 800D port.  It will still be several months, minimum, before I have 200D working.  Each camera needs individual work.  Porting between the various Digic7 cams should be easier, so if 200D gets usable, progress on the others may speed up.  Or I may get bored, or get stuck, and stop and it'll never get done.  Who can say? :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: totalmichel on July 12, 2019, 11:14:25 AM
Quote from: names_are_hard on July 11, 2019, 03:03:58 AM
@kitor - those CHDK links were very helpful, thank you!  It *used* to be indexed, but now it's not.  That's good, I can ignore the indexed code and simply replace it (ifdef for > Digic 5).

@esinem - I don't know that anyone is working on an 800D port.  It will still be several months, minimum, before I have 200D working.  Each camera needs individual work.  Porting between the various Digic7 cams should be easier, so if 200D gets usable, progress on the others may speed up.  Or I may get bored, or get stuck, and stop and it'll never get done.  Who can say? :)


Dont give up 🙂 (on a more serius tone, good job, im a programer, i know the struggle)
I'm waiting for you to complete the 200D to  *try* adapting it to the 6D2 😝
But im nowhere good enough to figure out the things you're doing.
Maybe it will work, or maybe ill brick my camera, who knows...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 13, 2019, 03:47:51 AM
Learning other people's code is hard :)

If you want a probably-low-risk task for porting to 6D2, this commit would be good:
https://bitbucket.org/stephen-e/ml_200d/commits/2fffa3bbda8980fdc3ce1c3fe1a8323ddaee45f4
You would need to find the right values for stubs.S and consts.h (Ghidra, or IDA Pro), if you get enough of them right it will let your cam boot while also loading a small amount of ML code (and let you blink the LED for debugging, search for info_led_blink).  I would recommend getting Alex's digic6-dumper branch working first, if you haven't done that already.

If you want a probably-considered-easy task which is completely safe and will help (force...) you to learn the code, you could get this commit building:
https://bitbucket.org/stephen-e/ml_200d/commits/6ce440ec21564070cdddc7783d50c254aca39093

I'm stuck on that.  You don't need to run any code, only fix the makefiles (or headers?  includes?) so platform/200D.101 will build.  That work is needed to make the bootloader able to display things.  I'm giving up on it for now, it's not very important, the bootloader already finishes.  I'm moving to bmp_putpixel_fast(), if I can get that working I can use output on the display for debugging.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 14, 2019, 05:51:24 AM
It's (more) alive! This is quite nice, it proves I don't need to get opentype working to get a usable interface.  Haven't tried to track down the green bars yet, I guess I left some weird debug code in.

(https://i.imgur.com/TDzPKkd.jpg)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: nikfreak on July 14, 2019, 07:14:56 AM
congrats! Keep up your good work.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on July 14, 2019, 08:10:35 AM
Now that's what i call progress!
Need to find some time and finally dig into your repository.

Inb4 "so when download be available?" -> answer from a few posts ago apply exactly the same now.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 15, 2019, 05:15:10 AM
I hope this should mean it's fairly easy to get CONFIG_HELLO_WORLD building on other Digic 7 cams!  Let me know your progress!

I fixed the green bars, it was a stupid ifdef mistake.  Next up, I have found that disabling CONFIG_HELLO_WORLD and enabling CONFIG_EARLY_PORT is broken, it doesn't compile.  Even doing the obvious fix (a required function definition was ifdef'd out) the cam doesn't boot as far.  Don't know what's going on there, haven't investigated.  I have CONFIG_PROP_REQUEST_CHANGE *disabled* so I decided to try without CONFIG_EARLY_PORT, and this is better - obviously doesn't really work but further than a CONFIG_HELLO_WORLD build.  It's currently failing in call_init_funcs().  I can see which function is crashing via debug logs.

VERY IMPORTANT: if you are trying this, ensure CONFIG_PROP_REQUEST_CHANGE is not defined.  This would be controlled in platform/200D.101/internals.h or equivalent.  Trying to write to properties is risky, can brick cam.

In unrelated news I decided to actually use my cam today and got this lucky shot: https://imgur.com/a/zltkJjv
They're skittish critters, I am learning how to sneak up on them.  Tamron 60mm F/2 macro.  Can't post in Share Photos, it's not using ML ;)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: OlRivrRat on July 15, 2019, 04:52:19 PM
                 @ N_A_H

        Nice Shot ~ 1 thing I've noticed about Dragon Flies is that they are very repetitive creatures,

so if @1st They get away just be patient & They soon, most likely, will return ~
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 19, 2019, 03:59:53 AM
Yes, you're right, they often land back on the same leaf, facing the same direction.  Funny little guys :)

Re 200D porting, I have made some more progress.  I had to fake out one of the funcs that call_init_funcs() wants to setup, a zebra func.  That was giving me weird hangs, at a short but not consistent time afterwards.  With that disabled, it gets far enough to reach ml_started = 1, in my_big_init_task().  So, ML is officially ported? ;)

ML is getting far enough that it prints a warning: "Camera was not shutdown cleanly.  Skipping module loading" - pretty good.  I'm not sure how to proceed now, what's the best way?  The Canon UI is unresponsive, often the camera locks up.  Sometimes it doesn't and half press will give you exposure info.  Sometimes the off switch does a clean shutdown, generally not.  I'm sure some of my consts and stubs will be wrong.

I have a decent log covering up to ml_started = 1:
https://drive.google.com/open?id=1QXRSHMbn1SFUs41wGDFhoZBVbcKEp3U9

Any ideas?  I have a lot of things I can try, I'm wondering if there is an obvious route for someone with experience.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: nikfreak on July 19, 2019, 12:25:01 PM
Quote from: names_are_hard on July 19, 2019, 03:59:53 AM
... I'm sure some of my consts and stubs will be wrong.

...

Any ideas?  I have a lot of things I can try, I'm wondering if there is an obvious route for someone with experience.

Not really followed your post history but it sounds like you should focus on consts / stubs fixing first. Running the stubtest would be a good way but it shouldn't work atm. For me it was rather easy to do consts / stubs "matching" when porting Digic 5 by comparing ROM dumps with same generaton cameras. Drop me a PM if you don't already have some digic5 dumps to compare. I can't tell if it could help with digic 6+. Your situation is rather a difficult one as you got no fully working D6+ port available to do the stubs / consts matching.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on July 19, 2019, 03:59:38 PM
What do you get if you try "unified" helloworld with digic6 branch?
Maybe there are some changes from a1ex useful to make it stable enough.

Quote from: names_are_hard on July 19, 2019, 03:59:53 AM
The Canon UI is unresponsive, often the camera locks up.  Sometimes it doesn't and half press will give you exposure info.  Sometimes the off switch does a clean shutdown, generally not.
I had experience of GUI lockup when updating 5DC port to more recent codebase; If I was quick enough I could as example enter the canon menu before ml override the task responsabile for buttons handling.

Don't remember exactly how I solved but probably was some missing initializzation in the custom ml_init for vxworks cameras. I had to doublecheck with the "unified" code to notice what was missing to load gui.

Also was missing initializzation of memory allocator...

Quote from: names_are_hard on July 19, 2019, 03:59:53 AM
ML is getting far enough that it prints a warning: "Camera was not shutdown cleanly. Skipping module loading" - pretty good.
Maybe here it is hanging on the first startup of Ml (after copy files to card, wiping previous settings) locking the camera and skipping module initializzation on the next round because of the undeleted module lock file in the card...

On vxworks it try to scan the directory to list all modules but doesn't iterate thought, so  camera appears as freezed...

Try to notice what is happening with fresh a install and see if the lock file is still present after shutdown.
If you want to disable modules, just comment module_task creation in ml_big_init
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 20, 2019, 12:37:43 AM
Quoteit sounds like you should focus on consts / stubs fixing first
I'd like to fix them, do you know how I'd find which ones are broken?  Qemu for Digic7 doesn't get very far.  Is there some pattern to look for in debug logs from real cam that shows it's a stubs / consts problem?  I think 90%+ will be right for stubs, maybe 80% for consts.  I've got some other roms to work from and it's surprising how close the code is even for old cams.

QuoteWhat do you get if you try "unified" helloworld with digic6 branch?
If I'm understanding you right, I've sort of done this.  digic6-dumper runs fine, but it doesn't have much functionality.  I've ported the parts that looked relevant into unified branch, fixed some stuff and can now run a full build of ML far enough to get to the point described above.  CONFIG_HELLO_WORLD on unified branch is stable (but again, isn't running much code).

QuoteIf I was quick enough I could as example enter the canon menu before ml override the task responsabile for buttons handling
This may be the problem!  I am pretty sure I don't have any button consts found, so could it simply be ML is hijacking all the button handlers and breaking them?  That would be good news.

Quotebecause of the undeleted module lock file in the card
I can check this too, thanks.  Should be easy to disable the module loading for now, I can't imagine it works yet.

Thanks both for the help!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 20, 2019, 06:18:16 PM
Found a nice missing piece, I had incorrect DRYOS_ASSERT_HANDLER in consts.h, so I wasn't generating CRASH00.LOG.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: nikfreak on July 21, 2019, 08:47:04 AM
Nice one. Now you just may also use several lines of bmp_printf (e.g test1, test2, test3, test4...) to write some text onto the screen and use this approch to locate code which causes trouble. Afterwards it's easy to see which stubs / consts are used around / within that code. You then either uncomment that code and see where code execution reaches (next bmp_printf) or better fix the stubs / consts first. I used this approach a lot and even still do in vb6 when i get stuck in one of my private projects

Next, enable features one by one and use same approach...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 21, 2019, 06:48:14 PM
debug printfs - shameful, but we all use them (entirely excusable here, where you don't have a debugger!).  I've added a convenience printf that works like this:
bmp_printf_auto("some string with data: %d", 6")
It has static x and y which it increments for you.  Nice for lazily printing things in order.

The fixed assert handler has made it much more stable.  Lockups are rare.

This is probably too hopeful, but I wonder if the main thing stopping me getting into ML menus is I haven't defined the button to trigger it?  I think this is supposed to be the delete / bin / trash button, but I don't know where to find it in consts / stubs / code.  What's the name used?  Or, more generallly, what's the path that leads to ML menus, so I can debug it?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: MrDerrick on July 25, 2019, 04:07:33 AM
Hi, i have an 800d, I can help you in any way?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 25, 2019, 01:13:46 PM
Digic7 are in very early stages.  Do you have experience with C or disassembly, or have the time to learn?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: nikfreak on July 26, 2019, 01:36:31 PM
Quote from: names_are_hard on July 21, 2019, 06:48:14 PM

This is probably too hopeful, but I wonder if the main thing stopping me getting into ML menus is I haven't defined the button to trigger it?  I think this is supposed to be the delete / bin / trash button, but I don't know where to find it in consts / stubs / code.  What's the name used?  Or, more generallly, what's the path that leads to ML menus, so I can debug it?

Check platform dir and gui.h in it.
Might be a good idea to copy and use that from my 100d port. You can also grep source code for 100D
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 30, 2019, 03:59:51 AM
Ah, I'd forgotten about gui.h, thank you.  I took a look at it, and I can see it's associated with button codes in gui_massive_event_loop, but comparing between 50D and 200D is difficult.  I think Ghidra has decompiled them in different ways, one part that I'd expect to be a switch is a messy if/else nest.  I think I will have to come back to this part.

Other problems I have: this crash log:
Quote
ASSERT: 0
at TouchUtility.c:132, task DispDCtrl
lv:0 mode:0

DispDCtrl stack: 28d100 [28d218-28c218]
0xUNKNOWN  @ 1b67db:28d100

Which I think is related to these debug messages:
Quote
19.697151   DispVCtrl:e054852d:42:02: GiveSemaphore : StateChangeWaitCBR 56
19.697188   DispDCtrl:e04e2e51:45:03: TCH_ProhibitTouch
19.697216   DispDCtrl:e055a3bb:45:03: JDI_LAM_ProhibitTouch
19.697245   DispDCtrl:e059bec3:45:06: TryPost Cannot be Done!!! 3   <--- I think this is strongly related to the assert

I can locate the function that triggers those messages but it's not obvious how I fix the crash.  I also don't know if I need to - the camera remains responsive.  Perhaps this is not a high priority?  Anyone know a general pattern for dealing with these kinds of logs?  To debug this further I think I would write a dynamic patching util to dump register contents and stacktrace when a given address was hit, which would be fun but likely slow to get working reliably (if it was x86 asm it would be easy :P).

I also find that any attempt to vsnprintf() with %s in the format string has a high chance of causing a very fast crash, fast enough that it stops the string being displayed.  But, it's not a guarantee, just very likely.  Sometimes you get part of the string displayed before locking up.  I don't understand this fully and can't explain it.  It evens occurs with local static strings as the arg.  There is nothing in crash logs when this happens.  I'm mostly mentioning this in case it confuses other Digic7 porters, but if this makes sense to anybody, please let me know.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: nikfreak on July 30, 2019, 06:37:14 AM
I would just try to disable touch in canon menu until you find the root cause (stub / const). It's at least possible on 100d. Do you have a pull request available? It might help others to chime in
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on July 30, 2019, 08:16:35 AM
Quote from: nikfreak on July 30, 2019, 06:37:14 AM
Do you have a pull request available? It might help others to chime in

https://bitbucket.org/stephen-e/ml_200d/
I don't think that this will be ready for PR anytime soon  :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on July 30, 2019, 03:01:57 PM
Disabling touch in the menus was a good idea I hadn't thought of, thanks.  It didn't help, still get the same crash.  I note that the debug messages look related to disabling touch, and the camera will crash if I halfshutter - perhaps it always tries to disable the touchscreen when the display is off?  It does give me the crash log if I insert card, turn on cam, do nothing, turn off cam - but that leads to a display off too.  It's a pattern worth investigating.

I'm happy to look at PRs, but they'd be Git ones, not HG.  Unless Kitor was simply saying my code is too painful to work with :)  I'll also throw stuff over the fence into HG land if people want me to (but I don't want to use it all the time).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on July 31, 2019, 09:55:26 PM
I thought about PR into unified which this is based on ;)
Obviously taking this as a new branch in ML repo is different story - and may encourage others to give it a try.

I really need to find some time and dig for stubs on R to try this. I hope for next month - depends mostly on how long will take me to migrate all stuff from server running in my closet to full-blown rack setup in my parents house ("just IT things")  :)
You know that you work on too many items at once when you have multiple kanban boards just for your own projects...
/ot
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: mylandscapeshots on August 29, 2019, 02:37:44 PM
Long time listener, first time caller.

Here's yet another "I have a 6D2 but have very little programming experience, what low-risk tasks can I do?" type of post. Is there anything I CAN do or just sit back until further instructions?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on September 01, 2019, 08:30:03 PM
A quick update: I am not dead, was just too busy with other stuff (including Blackhat / DEFCON, which was pretty cool).

I am feeling kind of stuck though, I don't know how to proceed with the assert from a few messages back.  If anyone could help diagnose or suggest changes / tests, please do.  Best guess I've come up with is blanking the back screen triggers Canon to disable the touchscreen, and disabling the touchscreen triggers a crash (but why?).  I haven't thought of an easy test for this theory.

For now I am doing a second pass over all the stubs I've found, and sorting them into high / middling / low confidence findings.  If anyone would like to help there, you could do that without running code.  In particular, looking at low confidence stubs and either finding better choices, or explaining why I'm right on the one I've found, so confidence is improved:
https://bitbucket.org/stephen-e/ml_200d/src/dev/platform/200D.101/stubs.S
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Jamh on September 08, 2019, 02:13:21 PM
Hey guys, What's up?
I have a Rebel T7I/800d and wanna help

  Magic Lantern Rescue
----------------------------
- Model ID: 0x405 800D
- Camera: Canon EOS Rebel T7i / Kiss X9i
- Firmware version: 1.0.1 / 7.3.5 6D(33)
- IMG naming: 100CANON/IMG_0357.JPG
- User PS: CineStyle Jamh Natural Flat Colors
- Boot flags: FIR=0 BOOT=0 RAM=-1 UPD=-1
- ROMBASEADDR: 0xE0040000
- boot_read/write_sector 106f45 107041
- 1018CB Card init => 2
- Dumping ROM0... 100%
- MD5: 7dd1e3b8c10211f086859effdb98b67f
- Dumping ROM1... 100%
- MD5: 5a9cf31fdd9789b1e27ace2a4a6b3ad2
- No serial flash.
- Saving RESCUE.LOG ...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on October 01, 2019, 04:08:03 AM
Hi Jamh - what kind of experience do you have?  The Digic 7 cams are in quite early stages.  ARM assembly, C and embedded systems experience would all be useful skills (or the time and inclination to learn them!).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Jamh on October 06, 2019, 06:27:14 PM
Hi, names_are_hard

Actually I'm not a programmer or an assembly expert
but I'm just started learning Python3 language + Arduino applications
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on October 09, 2019, 05:41:03 AM
Cool - Python is a really useful and clean language to learn.  You can program Arduino in assembly and you might want to learn after a while - I read you can get significantly faster or smaller code than AVR compilers generate.  For tiny CPUs it can be important :)

For now I don't think there is much you'll be able to help with porting to 800D.  But the code is freely available if you'd like to learn from it!  Get comfortable with C and AVR assembly and you could even try to work on a port.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: lacek on October 31, 2019, 04:43:54 PM
Quote from: names_are_hard on October 01, 2019, 04:08:03 AM
Hi Jamh - what kind of experience do you have?  The Digic 7 cams are in quite early stages.  ARM assembly, C and embedded systems experience would all be useful skills (or the time and inclination to learn them!).

Hi, I have 6d2, I have C/c++ experience (I code lots of numerics code) and some experience with "why this bloody hell does not link", but formally I'm not a programmer. I have some ASM experience, but I am "rusty" (last ASM code I wrote was 16bit code for Pentium 200 MMX and it was running in DOS...), though I guess this is not a problem, though it was of course single core unlike the digic 7? I have experience with embedded system, but very high-level (iOS apps development) and very low level (soldering mobile phones under the microsope), the mid levels (such as coding microcontrollers) is what I do not have. I work on Linux @home and @work.

And I have some time and lots of inclination to learn.

My motivation is to speed up having clean HDMI output on 6d2, and more importantly actually I am looking for new challenges - things like low-level take on embedded systems is something I always wanted to work on, but never dared to try....

How can I help? I guess the question  I want to ask is what is the next thing to do on 6d2. I have read though this thread -  it seems to me it is  "getting stubs" (is it right?) If yes, should I start with "getting stubs" tutorial and references therein? Is there a place where I can ask newbie questions?

I also read about the IRC channel where people communicate. Is it the same IRC (chat software) that was popular in early 90s?  If yes, what is the server?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on November 03, 2019, 01:01:18 AM
STRG-f
Then type
irc

Welcome! And SCNR!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on November 03, 2019, 01:13:55 AM
Hi Lacek!

Stubs you can do first, you can also get a build environment working - both can be done at the same time.  You should be able to run the digic6-dumper branch:
https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper

That should run on your cam...  but it doesn't do very much.  It's still useful, gives some logs, and should prove you have a correct build env.  Unfortunately, the digic6-dumper code hasn't been officially merged back into the mainline "unified" branch.  I have made some progress with that, here:
https://bitbucket.org/stephen-e/ml_200d

That code acts a lot more like full Magiclantern, but it crashes quite early on and I'm a bit stuck diagnosing the cause.  Also I have only tried to make it work on 200D, but if you look at the diffs you might find it helpful.

You will probably find my stubs useful, the 6d2 is probably fairly similar.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on November 03, 2019, 01:27:35 AM
Found stubs for 6d2 1.0.4 some times ago (https://www.magiclantern.fm/forum/index.php?topic=19737.msg214546#msg214546).

They need to be double checked by a1ex before
a bootflag enabler will be released to public, then hello world should be straightforward.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: lacek on November 03, 2019, 10:36:05 AM
Quote from: aprofiti on November 03, 2019, 01:27:35 AM
Found stubs for 6d2 1.0.4 some times ago (https://www.magiclantern.fm/forum/index.php?topic=19737.msg214546#msg214546).

They need to be double checked by a1ex before
a bootflag enabler will be released to public, then hello world should be straightforward.

Ok I see three things:
1) the stubs I have found so far (that Memory functions, but they are easy, still curious how did you identify that "create" function) are not be really useful, as I have 1.0.2 firmware
2) the stubs I have found so far are not really useful, as you have all of them as well
3) looking for stubs seemed much easier than debugging the code...

I will start by looking at the stubs you have found, after I update the camera...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: lacek on November 03, 2019, 11:12:47 AM
Quote from: aprofiti on November 03, 2019, 01:27:35 AM
Found stubs for 6d2 1.0.4 some times ago (https://www.magiclantern.fm/forum/index.php?topic=19737.msg214546#msg214546).

They need to be double checked by a1ex before
a bootflag enabler will be released to public, then hello world should be straightforward.

Actually I have three more questions:

1) I was following the "stubs tutorial". The Memory stubs I have identified were of the type : if(func()!=0) { "func() failed" } - the latter type discussed in the "stubs tutorial".  There are other types mentioned, for example "label followed by push command".   Do you write own, custom scripts that parse entire disassembly file and look for the occurrence of a label in line N and push command in line N+1 or are there some established scripts that help with stub searching?

2) I assume that stub searching is easier if you have an older camera with stubs identified: I assume that large % the low-level API stays unchanged from version to version, and one could look e.g for a similar sequence of commands or sth like that.  Am I making sense here?

3) the stubs.S files for other cameras have around 50-100 stubs that are identified. I am surprised that this number is actually so low. There way more functions mentioned in the string files for the ROM i downloaded. The ML code is not able to operate merely on these 50-100 functions right? How is that so?  does this: "THUMB_FN(0xE04E706A,  call)                          /* many functions called by name (lv_start, lv_stop etc) */" open the door to call everything else?



Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: aprofiti on November 03, 2019, 09:56:34 PM
Quote from: lacek on November 03, 2019, 11:12:47 AM
1) I was following the "stubs tutorial"...
....
Do you write own, custom scripts that parse entire disassembly file and look for the occurrence of a label in line N and push command in line N+1 or are there some established scripts that help with stub searching?
Most of the time looking for strings is a good way to have a looks in the right direction (or code segment), usually can be done by searching inside decompiled files if using dissasemble.pl script or by looking for xrefs in IDA.

check-stubs.py (https://bitbucket.org/hudson/magic-lantern/src/unified/contrib/stub-checker/check-stubs.py) can also be useful when porting firmware update (https://www.magiclantern.fm/forum/index.php?topic=19417.msg183571#msg183571).

Quote from: lacek on November 03, 2019, 10:36:05 AM
that Memory functions, but they are easy, still curious how did you identify that "create" function
Also using QEMU for some tricks (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst#rst-header-initial-firmware-analysis) (.idc file of function called during emulation and code blocks copied from ROM to RAM), helped me a lot to have more functions marked inside the disassembly or to retrieve the RAM address instead of the ROM address for a specific stub.

IDA will replace and display calls to RAM version of functions automatically if code segments are loaded into the project; the exact function can be found inside the disassembly without using them, but having RAM address instead come in handy when we need to easly patch them.

Quote from: lacek on November 03, 2019, 11:12:47 AM
2) I assume that stub searching is easier if you have an older camera with stubs identified: I assume that large % the low-level API stays unchanged from version to version, and one could look e.g for a similar sequence of commands or sth like that.  Am I making sense here?
Definitely useful to have a reference camera which use same DIGIC generation, it makes looking for stubs much easier because much of the code is shared and usually unchanged between them.

But because most of the code is shared or evolved during years, also comparing disassembly from older cameras can reveal the same or similar code structure to compare with: If I remember correctly I also double checked using a disassembly from 50D (Digic IV) when working on 77D and others (Digic VII).

Unfortunately comparing too much older cameras with a more recent one, ie. 5DC with 50D or even 40D (only 1 generation newer) won't help much... while disassembling 5DC, a lot of stubs looks like 50% smaller or completely different from newer cameras... also error messages (ie. looking for error code pattern from "finding stubs") looks like are handled in a different way, a lot of strings missing... making things harder...

Quote from: lacek on November 03, 2019, 11:12:47 AM
3) the stubs.S files for other cameras have around 50-100 stubs that are identified. I am surprised that this number is actually so low. There way more functions mentioned in the string files for the ROM i downloaded.
Some older camera have unused stubs which were commented because they were replaced by standard library instead of canon's version, or because some stubs required by some specific feature are not necessary anymore due to some refactor of ML code.

Obviously having lesser stubs to find makes porting much easier for us.

Quote from: lacek on November 03, 2019, 11:12:47 AM
The ML code is not able to operate merely on these 50-100 functions right? How is that so?  does this: "THUMB_FN(0xE04E706A,  call)                          /* many functions called by name (lv_start, lv_stop etc) */" open the door to call everything else?
A much better answer to last question need to be provided by main devs or someone which saw how ML code evolved during years.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: lacek on November 05, 2019, 09:11:40 AM
Thank you for very insightful reply. I will analyze it thoroughly.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Argiziont on November 16, 2019, 10:11:58 PM
Ok, i have 200d and i am close to programming (sort of)
I read some posts on this forum.
I read and practiced on python neural network (for those who know 'theano','openCV',' tensorflow') And for a now learning C/C++ inThe University. So i thought i could help us to faster release 200d firmware. But when i tried to set up Ubuntu then qemu and ML on it i faced with huge amount of problems, i said ok and launched my second OS Xubuntu and thied here but i still could not to run this F qemu canon firmware I thied again and again and killed about 20 hours.
I think it's too complicated. Now i really appriciate your work guys, it's really tough job.
Sory for terrible and aughfull english, I'm live in Ukraine and we have bad english education, but i do my best.
Thank you in advance for your future works.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: hkisgg on November 23, 2019, 06:02:25 PM
Hello, I'm an owner of 77D and I didn't know anything about ML until I bought Canon 77D. I have been looking into posts on the development of Digic 7 especially 77D. After reading every post carefully I understood and installed a virtual machine with ubuntu, magic lantern and qemu, while writing this message, I have kept the battery of 77D for charging and will get rom files. I have done a few c programs and but I'm not a science background student. I have seen posts on finding stubs. I need help with that if you kindly show me how to get stubs file(s) and 1 example of finding stubs(if there are threads or posts). I can help with the development of ML for Canon 77D. (Totally noob, I'm sorry if anything wrong)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: EKchan on December 03, 2019, 02:45:55 PM
Hey guys, i have canon 800D and  wanna help
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on December 14, 2019, 02:51:11 AM
Hello and welcome!
Quote from: hkisgg on November 23, 2019, 06:02:25 PM
I have seen posts on finding stubs. I need help with that if you kindly show me how to get stubs file(s) and 1 example of finding stubs(if there are threads or posts). I can help with the development of ML for Canon 77D. (Totally noob, I'm sorry if anything wrong)
Here's a good start on stub hunting:
https://www.magiclantern.fm/forum/index.php?topic=12177.0

If you don't have IDA, you can use Ghidra.  Calle2010 was working on a 77D and has a repo with instructions for getting started with Ghidra, as well as a repo for his 77D porting work (which has some stubs found):
https://github.com/calle2010/magic-lantern-77d-vagrant/blob/master/ghidra.md
https://bitbucket.org/calle2010/magic-lantern-77d/commits/all

EKchan - what experience do you have with C, assembly, or reverse engineering?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on December 14, 2019, 05:36:34 AM
I have made useful debugging progress.  Something is flakey with task code, which can cause weird behaviour / crashes at unpredictable times after doing the task.  This was very hard to understand due to the delayed effect.

I think it's probably related to the significant rework Calle2010 did around tasks.  I'd seen that before and forgotten about it.  I can't find a long explanation for why he did that.  To do with task_create not returning a pointer, it reads like, but beyond that I don't know.
https://bitbucket.org/hudson/magic-lantern/pull-requests/958/replace-is_taskid_valid-with-direct-access/diff

So, next up is understanding that change and porting to mine.  For now I've disabled all tasks in my_big_init_task(), which gets me further in my memory hooking job, but disabling the tasks means I don't get crash logs...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on December 14, 2019, 07:40:34 AM
Yes, these task updates should be applied to all DryOS models (including the old ones). In particular, they will be very useful for DIGIC 4+, as this part of Canon code is shared with (or backported from?) DIGIC 6/7/8.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on December 15, 2019, 09:08:08 AM
Merged them, with some tweaks.  Doesn't seem to be the cause of the prior bug.  Still useful later I imagine.  It does seem to have exposed another bug, but it's so strange I'm not sure.  Maybe something generally related to memory pressure, or bad memory layout?

In vram.c, vram_update_luts(), which gets called indirectly from call_init_funcs(), there's a loop that initialises a cache of screen coordinates:

Quote
    int y_times_BMPPITCH_cache[BMP_H_PLUS - BMP_H_MINUS];
[...]
    for (int y = BMP_H_PLUS - 1; y < BMP_H_PLUS; y++)
    {
        //~ bm2hd_r_cache[y - BMP_H_MINUS] = BM2HD_Ru(y);
        y_times_BMPPITCH_cache[y - BMP_H_MINUS] = y * BMPPITCH;
    }

This crashes.  If I restrict the range of the writes, it doesn't (not sure what the minimum restriction is).  It doesn't look like it can write outside the array to me, which would be the obvious cause.  It's an immediate crash, no crash log and the cam is unresponsive, have to pull battery.

Am I missing something?  Memory alignment (I'd expect y_times_BMPPITCH_cache to be int aligned and for that to be okay)?  Could sizeof(int) be 2 due to Thumb and this does something weird (y * BMPPITCH would overflow)?  I tried increasing ml_reserved_mem by far more than the size of y_times_BMPPITCH_cache and that didn't make a difference.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: hkisgg on December 20, 2019, 05:31:00 PM
Quote from: names_are_hard on December 14, 2019, 02:51:11 AM
Hello and welcome!Here's a good start on stub hunting:
https://www.magiclantern.fm/forum/index.php?topic=12177.0

Ok sir, I will start with this thread and I was busy with shooting for a short film lately sorry for the late reply.

Quote from: names_are_hard on December 14, 2019, 02:51:11 AM
If you don't have IDA, you can use Ghidra.  Calle2010 was working on a 77D and has a repo with instructions for getting started with Ghidra, as well as a repo for his 77D porting work (which has some stubs found):
I just started using Qemu. I'm learning to use it. I guess I can jump to Ghidra to start learning and working on it. Is it ok if I PM you if I'm stuck anywhere in this process?   
Thank you for your kind reply.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: dedmen on December 22, 2019, 06:26:37 AM
Hi! I'm the new guy.
I wanted to use my 200D as a webcam, but the resolution it sends in live view feels too low so I thought I'll just hack the firmware.
I dumped the rom, decompiled most of it in IDA, and made myself a autoexec build of magic lantern from stephen's bitbucket repo.

Now theres the question, how I can set the boot flag to let it execute my autoexec, the 200d firmware dumper sadly is compiled without the bootflag set enabled, and the FIR compile tools are not available.
I already found the FIR crypto code, but I don't really want to go to the effort to reverse it.

Is there a easy-ish way to simply enable the bootflag?
I assume simply running ML build for another camera won't work.

I found the FROMUTILITY MENU which apparently can set bootflag, but I'm not sure how to activate that.
I assume its USB serial stuff, but that seems like too much effort, I don't really want to figure out their whole support, debug access stuff.
I know which flags I need to set on which address to enable the command mode... mh maybe I'll figure out their whole debug stuff afterall..
Yeah its UART, I don't want to rip off the rubber to get to it, finding some software vuln to get in seems easier.

(in case its not obvious, I'm actually constantly pausing while writing this post, while i continue reversing stuff, in case it sounds a bit chaotic.)

Okey already found a stack buffer overflow in PTP, I can probably just use that to get code execution and set the bootflag myself.
Or I can just run the "run autoexec.bin" function directly from there, ignoring the bootflag check...

I'll probably invest more time into helping getting ML running on the 200D, but I have two weeks of vacation coming up, and am currently quite busy so.. no promises.
I will most likely not even finish this stuff before I leave.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on December 23, 2019, 01:34:20 PM
@hkisgg - feel free to PM me with questions.

@dedmen - you can enable the bootflag with the special firmware update Alex posted earlier in this thread:
https://www.magiclantern.fm/forum/index.php?topic=19737.msg212603#msg212603

It's a flash update, so it's persistent, but it just enables the flag.  You'll also need to set your card bootable.  Be aware that if you put in a bootable card without autoexec.bin it hangs the camera.  Non-bootables are fine.

I'm currently working on some major changes to my repo, I think I was working with an older version of Unified branch (I probably messed up some hg command).  Working through a 30k line patch file seeing what's sensible to merge in :(  So, don't trust my repo to be from a sensible base.  Welcome aboard and good luck!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Akaei on December 26, 2019, 08:32:55 PM
I recently bought a T7i/800D.  It's my first decent camera since my AE1 back in the 80s.  I didn't realize until way too late about the file size restriction which limits maximum video duration/quality.   I just wanted to chime in with my appreciate that someone is working on Magic Lantern solutions for the T7i.  I'm looking forward to it.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on December 27, 2019, 03:37:44 PM
File size restriction on 800D? AFAIK the only restriction is 29:59 recording duration. See manual page 277.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on December 29, 2019, 11:09:58 AM
Maybe he formatted card to FAT32.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on December 29, 2019, 11:19:41 AM
Which will generate chunk files < 4 GB but doesn't affect recording duration.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: dedmen on January 04, 2020, 04:52:11 AM
Quoteyou can enable the bootflag with the special firmware update
wow, now I feel great for spending like.. 12 hours overnight on working on my exploit. :D

QuoteI think I was working with an older version of Unified branch
Yeah, I would also appreciate updating qemu with the one from main qemu branch, gave me quite a headache to get running.

Is there a more direct communication channel? Like Discord/Slack or smth? Not sure about what specific things I could be working on.
Yeah need to verify stubs, but not sure which from the stubs file are missing and required, and which need verification.
And as this is the first version I'm working on, I don't have references to older version patterns to compare.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 04, 2020, 06:45:48 PM
Quote from: dedmen on January 04, 2020, 04:52:11 AM
wow, now I feel great for spending like.. 12 hours overnight on working on my exploit. :D
Pff, just read every page on every forum post before you start ...  ::)

Quote
Yeah, I would also appreciate updating qemu with the one from main qemu branch, gave me quite a headache to get running.
Done 27k lines of merge, 3k left.  Should finish this weekend.  Then I "just" need to fix the things I inevitably broke.

Quote
Is there a more direct communication channel? Like Discord/Slack or smth?
The main devs (not me) use IRC.  They're not always online but will get back to any questions you have.  I tried using it for a while but I don't have a 24/7 computer to keep IRC active, and IRC servers have no chat history, so it was very frustrating.
If you start a Discord for 200D discussions I'd join it.

Quote
Not sure about what specific things I could be working on.
My repo works well enough on 200D to allow you to run arbitrary code (you can print to screen and log stuff to files so it's pretty useful), but it crashes part way through ML initialisation for reasons I don't yet understand.  This commit is probably good: https://bitbucket.org/stephen-e/ml_200d/commits/74004ec2c30c8b7253dfb50c598c81333aca8b63
Take a look at src/boot-hack.c, my_big_init_task().  The info_led_blink() lines should let you find when it currently crashes.  I tend to put "SJE" near code where I've made significant (probably hacky) changes.  You should get detailed logs on the cam, sometimes you even get a crash log, depends how broken that exact commit is (didn't check it was a good one, just guessing).
Trying to diagnose the crash would be most helpful to me.  I've asked around and nobody here seems to know what it might be.  So maybe it's hard, or maybe nobody noticed my questions.  The crash log gives line of code (in Canon's source, that we don't have), it's pretty easy from strings to work out where this is in the ROM.  I was working on doing some jump hooks around that location so I can see why it's failing an assert (multiple possible causes).  My jump hooks fail for unknown reasons (alignment?  Bad thumb mode?  page permissions?  There's no log).  That's on hold until I bring my repo up to a more modern version (because...  **** Mercurial's stupid branch model).

Quote
Yeah need to verify stubs, but not sure which from the stubs file are missing and required, and which need verification.
And as this is the first version I'm working on, I don't have references to older version patterns to compare.
The stubs in my repo are at least mostly good.  ML boots and gets a fair way through initialisation.  If you look in my platform/200D/stubs.S you'll see I've divided the stubs into sections based on my confidence that I've found the right function.  Some I am not confident on at all (but does the code currently go far enough that it matters?  Unknown).  So you could work on those if you wanted.  Probably a good way to get familiar with the ROM code.
If you DM me I can send you my Ghidra project.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Kestis on January 05, 2020, 03:32:29 PM
I'd like to shoot better quality video with my 800D. Maybe I could help somehow to make it happen sooner?
I have some experience writing C code on hobby basis for Arduino and AVR microcontrollers.

By the way. How much progress has been made with Digic 7 development?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: srsa on January 05, 2020, 03:55:30 PM
Assuming these questions are still unanswered, I'll try to answer some of them.
Quote from: names_are_hard on December 15, 2019, 09:08:08 AM
In vram.c, vram_update_luts(), which gets called indirectly from call_init_funcs(), there's a loop that initialises a cache of screen coordinates:
A disassembled version of the compiled code could give more hints. The reason of crash is not necessarily related to that piece of code, it could be that RAM gets corrupted somewhere (stack, heap, ML code/data).
QuoteMemory alignment
Should not be a problem from C (unless you try hard) and this core seems to cope with unaligned words anyway.
QuoteCould sizeof(int) be 2 due to Thumb
No. It's 32 bits, regardless of ARM/Thumb.

QuoteI was working on doing some jump hooks around that location
Is that platform/200D.101/jump_hooks.c (https://bitbucket.org/stephen-e/ml_200d/src/master/platform/200D.101/jump_hooks.c)?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on January 06, 2020, 10:53:35 PM
Quote from: Kestis on January 05, 2020, 03:32:29 PM
Maybe I could help somehow to make it happen sooner?
Welcome!
https://builds.magiclantern.fm/#not-listed
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 17, 2020, 03:10:32 AM
@Kestis - you could probably help!  On 200D I can run arbitrary code, but it tends to crash.  Probably true for the other Digic 7.  Need to debug why.  You can print to the cam screen and log to the card to find out.  If you want to help out, get digic6-dumper branch working on your cam, then see if you can find enough stubs so my repo works on 800D.  That's not enough description so let me know if you want any help :)

@srsa - good idea about disassembling, stupidly I had done this in other areas but not for the code I was seeing the problem in!  Good to confirm mem align and thumb int size.  Yes, jump_hooks.c.  That will probably be changing soon, have done a lot of work updating the base branch I'm working from.

Progress report: merged a bunch of code from a branch Danne is working on.  I didn't realise, but the main Unified is about 2 or 3 years old, so I was missing a lot of stuff.  During the merge I realised I need to find a stub for task_trampoline (wasn't needed in the old Unified I was working from).  That has a reasonable chance to be related to where I'm seeing the crash.  Merge is complete but build is broken as now it depends on that stub.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: nikfreak on January 17, 2020, 07:54:49 AM
That progress report sounds good.

Quote from: names_are_hard on January 17, 2020, 03:10:32 AM
That has a reasonable chance to be related to where I'm seeing the crash.  Merge is complete but build is broken as now it depends on that stub.

+1. Don't give up.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on January 17, 2020, 07:57:57 AM
Quote from: names_are_hard on January 17, 2020, 03:10:32 AM
Progress report: merged a bunch of code from a branch Danne is working on.  I didn't realise, but the main Unified is about 2 or 3 years old, so I was missing a lot of stuff.

For what to merge, please re-read reply #230 (https://www.magiclantern.fm/forum/index.php?topic=19737.msg218437#msg218437). It's probably best to start directly from digic6-dumper; at least, the code restructuring to allow booting on different digic generations, and also the new stub formats, are changes I consider useful for all new ports. That branch is also up to date with most other backend changes, that you also want.

The crop_rec_4k branch contains some highly experimental changes that break the compatibility with many cameras. It's also behind in other backend areas. So, while it's probably the most tempting one for users, and actively worked on by non-core developers, it's probably not the best choice for a new port, if you ask me.

Danne's branches are even more experimental, and they contain mostly unreviewed code. I haven't played with it yet, but I highly doubt I'll include these changes verbatim into the main codebase. See also this (https://www.magiclantern.fm/forum/index.php?topic=23041.msg224332#msg224332).

Unless you are betting on me completely retiring from the project - in that case, feel free to ignore my advice. That's probably a sensible thing to do, as I couldn't (yet) find a job that pays the bills, while also leaving me with some time for hobbies. I'm still wondering what you might be doing for close to $20k a month (https://www.magiclantern.fm/forum/index.php?topic=24339.msg218970#msg218970) - I could work for 2 months per year, with a job like that ;)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 17, 2020, 03:38:03 PM
Thanks!

Nik, the build is only a tiny bit broken, the merge was *much* more painful.

Alex, yes, I recall #230 :)  I have some of that done.  But I only just realised the names are branch names in Hudson repo!  qemu, new-dryos-task-hooks, lua_fix and patchmgr are all branches that should be merged into unified?  I have taken most of the code around tasks, patch stuff and qemu I think, but not cleanly from those branches (didn't understand hg or ML codebase well enough, could probably do it now).  And I improved the tasks stuff, it was overcomplicated I think, the task struct on Digic 7 just needed two fields added then everything lined up nicely.

I had no way of *testing* these changes as the only cam I had was 200D, so I didn't make PRs.  Now I have an M2, which runs ML fine (but not Unified I think, that doesn't support M2).  If I can get those branches merged and it runs on M2, is that an okay level of testing for PRs to be worthwhile?  I assumed that the goal of Unified is one branch that runs on all supported cameras, with as many working features possible per cam, conditionally included?  Is that correct?  That would make the most sense to me and was what I was working towards (with a focus on 200D for a challenge).  I dislike how splintered cam support is - it makes finding the "right" build a challenge for new people and generates much extra effort in support questions.  Why not one branch that builds for any camera that we know works?

They don't pay me 20k a month, but if I was going to quit my job to be an ML dev full time I would want a pay rise for the extra risk :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Danne on January 17, 2020, 03:56:13 PM
@names_are_hard
Working for eosm2? To what extent? freezefree recordings around raw? Any build, code you could share? Got my eosm2 collecting dust over here  :-*
@a1ex, please do not retire :(. Are we out of options really?

Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 17, 2020, 04:05:31 PM
M2: it runs, has menus you can navigate and you can take pictures.  Beyond that, I haven't tested.  When I say working I mostly mean "not crashing".  This at least lets me test if I totally broke builds for another cam when trying to get 200D working.  Or when trying to merge branches, now I know I can be useful doing that, maybe!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Danne on January 17, 2020, 04:06:45 PM
Well, that's a very good start.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: nikfreak on January 17, 2020, 06:03:51 PM
Just checked #230 and from my experiences I can tell you that each and every instruction @a1ex provided me was as precise as possible. That said, I sometimes needed to read it twice or thrice until I was able to follow it.

Quote from: names_are_hard on January 17, 2020, 03:38:03 PM
Thanks!

Nik, the build is only a tiny bit broken, the merge was *much* more painful.

Alex, yes, I recall #230 :)  I have some of that done.  But I only just realised the names are branch names in Hudson repo!  qemu, new-dryos-task-hooks, lua_fix and patchmgr are all branches that should be merged into unified? 


Yes, I know that pain, drove me crazy handling "unsupported" branches.  As you realised there are lots of branches that should be merged into unified. Becoming familar with them requires you to compile and try out on your cam. You'l need some time but I can just confirm what @a1ex said in #230. You already did some major progress IMO. Please continue.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Monet.C on January 23, 2020, 06:02:24 AM
Got my SL2 on the way, would be happy to help out with testing. Read most of the treads, I have some first year programming knowledge (C, C++, JS) but it doesn't go further than that. Would be happy to help where it is possible :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: LeptoN on January 24, 2020, 07:12:55 PM
Another I want to help message.

I'm a software developer still in my senior year of college. I have experience with C, C++, 32 bit ARM assembly, and some reverse engineering (game hacking). I had an internship working with embedded systems helping developing firmware for a vehicle infotainment system.

I'd like to help speed up development for the 6D II but I'm not sure what is done, what needs work, and where I should start. I would like some advice.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 24, 2020, 08:11:50 PM
Hi!  No testing required yet, it's not got as far as menus.  Or working buttons.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: LeptoN on January 24, 2020, 08:53:44 PM
How can I help?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 25, 2020, 12:18:37 AM
@LeptoN - was replying to Monet with the previous post, yours wasn't up at the time I started writing!  Your skillset suggests you could help a lot, if you're patient!

6D2 is Digic 7, like 200D.  That should mean you can run arbitrary code, including flashing LEDs and drawing to the screen.  However, it doesn't run full ML yet.  I'm (slowly) working on 200D, where I can build full ML, load it, and it crashes after some early init code.  I think some problem to do with tasks, but so far I've been unable to diagnose it.  For some crashes it will log stack traces to disk, but not this one.

The outline of what to do is this:
- make your cam bootable using special firmware update earlier in this thread
- get ML building (to test you have correct toolchain etc)
- dump firmware from your cam using digic6-dumper
- find required stubs and consts to get full ML building
- build, it will crash, diagnose why, fix, repeat (this is where I am on 200D)

To get started, I would recommend this branch, digic6-dumper, it's easier to build than ML:
https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper

You'll need to get that building - Linux is probably easiest but I know people can build on Mac and WSL as well.  You need an arm toolchain, obviously.  I build by cd'ing to platform/200D then "make zip".  This will fail if you have python3 first in your path.  If you think it's time for python2 to die, I can point you at the changes required for python3 to work.  Otherwise, just make sure "python" means "python2" on your system.

You'll need to get booting enabled on your cam.  This is a small, persistent change to firmware (a bit flip in flash, I think) that instructs the cam to try and do a firmware upgrade if a .FIR file run code from an autoexec.bin file if found on the card.  This is a one-off task, find the magic firmware for 6D2, somewhere earlier in this thread I expect.  ML hijacks the firmware update process to inject into the running OS - but note that no persistent changes are made; there's no firmware update, it's just how code gets injected into ram.

Build digic6-dumper for your cam.  See if it works.  If so, congratulations!  You can run arbitrary code on your cam!  Now it gets harder.  Digic6-dumper is very bare bones.  I think Alex found a minimum set of stubs and consts (more on those later) to get it working on most Digic 6/7/8 cams, but there's not enough to succeed loading full ML.

In order to hook the right functions, ML needs to know the fixed addresses where they are in ram.  ML calls these "stubs", they're in platform/XXX/stubs.S.  There are some scripts that try to guess these from a similar firmware, but I don't know how well these work since we don't have a working >= Digic 6 cam to base it on.  In any case, the scripts aren't perfect, so you'll want something like Ghidra or IDA Pro for finding the stubs for your cam from a firmware dump.  Digic6-dumper should have dropped that on the card for you.  You also want to find some consts, to put in consts.h.  For both these tasks it helps enormously if you a firmware dump from another model where the stubs are known.  The code is surprisingly similar between models.

After you have what you think is a good set of stubs and consts you can try and build full ML.  If you can't find some, you can ignore them, probably, and see what works and what is broken.  For some stuff it won't compile and you may have to fake stuff out, for other stuff you can use obviously bad values if it compiles, but you'll have to go back and fix it later.  You will also want to set some #defines so that ML doesn't try and dangerous code - this is important!  I can't remember the define right now but it stops ML attempting dangerous writes (they're fine if we understand a given model, but here we don't, so...).

Here's the line in internals.h that prevents some ways of breaking your cam.  You want it commented out as shown:

/** Properties are persistent (saved in NVRAM) => a mistake can cause permanent damage. Undefine this for new ports. */
//#define CONFIG_PROP_REQUEST_CHANGE


My repo here is probably the furthest along, but it's far from working:
https://bitbucket.org/stephen-e/ml_200d/src/master/

I've tried to #ifdef stuff in a way that it might work on all Digic 6/7/8 cams, but I only have a 200D to test on.  You can probably get some use out of reading my stubs.S as I comment my reasoning on how I found them.  Firmware between 6D2 and 200D may be similar.

Good luck, and do please let me know if you'd like help with any of those stages.  I think I'm the only person working on a Digic 6/7/8 port at the moment.  Ilia is considering starting on the 5Ds.  It would be nice to have people to share problems with!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: ArcziPL on January 25, 2020, 05:13:13 PM
Very well written introduction. I'd only like to correct this detail:

Quote from: names_are_hard on January 25, 2020, 12:18:37 AM
You'll need to get booting enabled on your cam.  This is a small, persistent change to firmware (a bit flip in flash, I think) that instructs the cam to try and do a firmware upgrade if a .FIR file is found on the card.  This is a one-off task, find the magic firmware for 6D2, somewhere earlier in this thread I expect.  ML hijacks the firmware update process to inject into the running OS - but note that no persistent changes are made; there's no firmware update, it's just how code gets injected into ram.
It's slightly different. ML hijacks the firmware update process only in two cases:
1) ML "installator" to enable the boot flag
2) portable ROM dumper runs fully in this mode

Activated boot flag instructs the cam to look for autoexec.bin on a memory card at every boot and, if found, execute it.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on January 25, 2020, 06:12:28 PM
And here is the boot process in all its glory:
https://www.magiclantern.fm/forum/index.php?topic=23641.msg213338#msg213338
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on January 29, 2020, 05:13:43 PM
IRC is a hassle. Can the smaller discussion be on discord or some sort?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 29, 2020, 07:16:58 PM
IRC is indeed a hassle.  The lack of chat history is very annoying.  No reason Discord couldn't be used, if you can convince people to use it.

What kind of discussion were you hoping would happen?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on January 29, 2020, 07:26:16 PM
Minor thing about the ROM's and the layout of the canon's firmware and such.. planned stuff and more..
Quoteif you can convince people to use it
Ill just say use the web version... simple as pie
In-fact when the chat 'session' gets old one can just search the whole conversation without the need to ask again here....
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 29, 2020, 07:37:16 PM
I admire your optimism and hope it is as simple as you think :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on January 29, 2020, 07:43:47 PM
its about time...
dm me on discord..
https://discord.gg/yBurP7a (discord server invite link.)
The server is pretty much built up and awaiting for users. Hopefully it shouldn't be that difficult
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on February 17, 2020, 08:37:40 PM
Massive merge to a more modern code base didn't work.  It builds, but crashes with no feedback, very early, cam unresponsive.  I'm not very surprised, it was too much to merge in one go.  Still, I learnt a bunch about how the code is organised in doing it.

I think my next steps are to try porting the task code specifically (ideally, as a proper merge, if I can find where this more modern code came from) and to see if it's practical to port the tasks code into digic6-dumper, so I'm experimenting with tasks in a less complex environment.  I'm fairly sure now that tasks are more complex on Digic 7 than single-core cams.  My guess is that each CPU has a separate task queue, held in the per CPU region (0x0000-0xfff for one core, 0x1000-0x1fff the other), with coordination happening in the 0x4000 region.  I also need to dig into the existing code to see if it makes assumptions that would break under that system.  Oh and @jack001214 found task_dispatch_hook for 200D, so he's officially a stub-hunter now!

Separately I may try to merge together the known-important parts in Unified, but outside of Mercurial, and adapt for >= Digic 6.  There's been no official word on what's happening with the Mercurial repo, nobody uses Mercurial anymore, so I may as well merge stuff myself in Git.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: pgathana on March 22, 2020, 03:54:16 PM
Hello, I have the 200D. I have no idea about code. Is there any way to help?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on April 01, 2020, 06:33:46 PM
Yes, learn to code.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: pgathana on April 02, 2020, 07:13:23 PM
Great idea..! I haven't thought about it...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on April 02, 2020, 08:46:54 PM
Canon 200D was introduced about 3 years ago. If you - or anyone else - would have started learning to code back then (instead of waiting for something dev team was adamant about not being able to deliver because of lack of time and dev team constantly asking for additional support by anyone willing to start into coding) I think following calculation might be valid: Give 20 minutes a day to coding -> 3 x 365 x 0.33h = 365 hours. Assuming 39h per week for full time employees -> More than 9 weeks. This compares well to the time a student in STEM is given to work on a project from scratch to presentation.
Start now and give us a presentation in 2023, please.
Title: I want to help, but I don't understand anything...
Post by: Isaac Martínez on April 06, 2020, 12:55:22 PM
Hi, I have a t7i, and I want to help. Anyone can guide me or give me some tutorials for start?
Thanks, and sorry for my english...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on April 06, 2020, 02:16:40 PM
Describe your skills and experiences. Good starting point for coders is making QEMU run. See autoexec_bin Twitter account -> Sticky tweet.
If you don't have any codings skills you might want to learn C programming language first. There are a few web-based online courses.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Isaac Martínez on April 06, 2020, 05:06:04 PM
I know how to program a little... But, what do I need to do to get started? Is anyone trying to get the magic lantern on the 800D? How can I contact them?
I have an arduino board and a Canon 800D. What can I do for progress?
Sorry for my engilsh.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: turtius on April 14, 2020, 10:47:00 AM
Well perhaps try loading the ROM dumps into ghidra or ida and compare them with a port which has a port running. Currently i attempted to compare the 50D with 200D (as instructed by @names_are_hard) and found that the dumps are very similar.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Isaac Martínez on April 20, 2020, 05:25:56 PM
Okay, so first I need to install Ghidra, and second, where can I find the different ports and ROM dumps? The 800D's ROM dumper listed here is correct? https://www.magiclantern.fm/forum/index.php?topic=16534.0
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Isaac Martínez on May 19, 2020, 03:59:58 PM
Hi?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on May 19, 2020, 04:04:30 PM
Have you succeeded in loading ROM dumps into Ghidra?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: mfurseman on July 31, 2020, 11:00:12 AM
Hi, This is my first post on the forum so please keep me inline with the etiquette!

I own a 6DII and find the limitations imposed by Canons software interface quite frustrating, in particular the lack of techniques for manual focus. I am terrified about bricking my new shiny Camera but would like to assist in the development of ML for this platform. I work as a professional software and controls engineer in scientific research, I've got a good knowledge of Python, C, C++ and software engineering practice in general, but only a paltry knowledge of disassembly and nothing but a desire to learn ARM assembly.

I wonder if anyone knows what the cheapest DIGIC 7 camera is so I can try and source a used / broken one for testing without risk. The best description I've found for getting started on porting is in this thread, if there are any better resources could someone point me to them?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on August 16, 2020, 10:19:43 PM
Lookup sticky tweet @autoexec_bin
Portable ROM Dumper thread (https://www.magiclantern.fm/forum/index.php?topic=16534.0)
TImeline Canon DIgital EOS Cameras (https://en.wikipedia.org/wiki/Template:Canon_EOS_digital_cameras)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Isaac Martínez on August 31, 2020, 04:39:30 PM
Hii!
I have alredy loaded 800D, 50D & 200D dumpers into Ghidra.
What I need to do now?
Best regards,
Isaac Martínez
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on August 31, 2020, 05:17:35 PM
@mfurseman - 200D is fairly cheap.  I'm biased because I have one and I have a (very) partial port.  It's the port that's the furthest done so far.

@Isaac - first, read this entire thread.  There is useful information about how to work on ML ports, as well as specific information about 200D, and later on some posts from me about current problems.

Ghidra helps you understand how the ROM code works.  Qemu can run the code.  But, Qemu does not fully understand how to emulate Digic 7, it only partly understands.  So, one task you could try would be improving emulation in Qemu so that it can get further when running the 200D ROM.  50D ROM emulates very well so that might help as a comparison.

Another task would be to check and improve the found stubs for 200D.

Another would be running my 200D repo code on your cam and trying to diagnose why it crashes.  This is the highest risk task as it involves running known bad code on a real cam.  If your camera breaks, it is your fault.  All I can say is that it hasn't broken my 200D so far.

You can join the unofficial Discord to ask questions if you'd like.  Asking here is also fine.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Isaac Martínez on September 03, 2020, 02:41:34 PM
Ok, I don't know much about code, so I'll first help run some known bad code on my 800D and in the meantime, I'd like you to pass me some tutorials so I can help with the programming part.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Isaac Martínez on September 03, 2020, 02:42:24 PM
Quote from: Isaac Martínez on September 03, 2020, 02:41:34 PM
Ok, I don't know much about code, so I'll first help run some known bad code on my 800D and in the meantime, I'd like you to pass me some tutorials so I can help with the programming part.
Sorry for my english
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on September 03, 2020, 03:16:40 PM
If you don't have any programming experience, the goods news is, you can learn for free.  The bad news is, it will likely take several months at least.  I hear CS50 from Harvard is a good free course that covers C.  I learnt a long time ago so I don't have any experience with modern tutorials.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on September 03, 2020, 03:27:00 PM
Isaac, it is as names_are_hard said: It will take a long time until your efforts will result in useable code for a cam. If you are unable to put several hundred hours of work into it you won't succeed (IMO). And everyone will understand if you don't want to take that path!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Isaac Martínez on September 04, 2020, 08:03:25 PM
Well, I have a lot of free time and I could invest it in that
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Nicolas Apud on September 13, 2020, 09:17:34 AM
(https://i.ibb.co/ryKTbCS/Whats-App-Image-2020-09-13-at-4-14-03-AM.jpg) (https://ibb.co/ryKTbCS)

and then what?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Nicolas Apud on September 13, 2020, 09:19:08 AM
(https://i.ibb.co/ryKTbCS/Whats-App-Image-2020-09-13-at-4-14-03-AM.jpg) (https://ibb.co/ryKTbCS)


and then what?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on September 13, 2020, 09:55:09 AM
Upload dumped ROM files somewhere (hidden to public), PN link to srsa and a1ex.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on October 13, 2020, 03:36:56 AM
I think I have found something significant for DIGIC 7 (and probably 8, 10, maybe 6).  The task struct now has a field that determines which CPU the task is scheduled for.

The old struct looks like this for Digic < 7 (only the end shown):

        uint8_t         yieldRequest;   // 0x47, 1
        uint8_t             unknown_0c; // 0x48, 1
        uint8_t         sleepReason;    // 0x49, 1
        uint8_t             unknown_0d; // 0x4a, 1
        uint8_t             unknown_0e; // 0x4b, 1
        struct context *context;        // 0x4c, 4


For 200D (probably all D7), I think it looks like this:

        uint8_t         yieldRequest;   // 0x4b, 1
        uint8_t             unknown_0c; // 0x4c, 1
        uint8_t         sleepReason;    // 0x4d, 1
        uint8_t             unknown_0d; // 0x4e, 1
        uint8_t             unknown_0e; // 0x4f, 1
        uint8_t         cpu; // 0x50, 1
        uint8_t             unknown_10; // 0x51, 1
        uint8_t             unknown_11; // 0x52, 1
        uint8_t             unknown_12; // 0x53, 1
        struct context *context;        // 0x54, 4
        uint32_t            unknown_13; // 0x58, 4


Trying to update Qemu for 200D, it was failing to reach code that would initialise needed structures in memory.  A task was getting scheduled to do the init, but never running.  It was being scheduled for cpu1, which we disable in Qemu early on.

Forcing cpu = 0 for all tasks, I see the "init1" task running and the structures getting at least partially populated.  Unfortunately it triggers an exception, but before it would never run at all.  It looks to me that there are two init routines, designed to run in parallel (presumably no dependencies?).  See 0xe0040224 and 0xe0040220.  The former is "init", the latter "init1".

Beyond helping with qemu, this may allow ML to choose which cpu tasks run on - and that could mean we can run things twice as fast, if we're cpu bound.  Are we cpu bound for recording video, for example?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: sm105 on October 13, 2020, 06:12:04 AM
Very exciting! I'm no expert, but since these DIGIC 7 cameras all have UHS-I controllers (I think?), then the bottleneck will probably be write speed. However, this could be quite a valuable finding when it comes to cameras that support UHS-II.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on October 13, 2020, 05:30:40 PM
Minor update, another field probably identified, better names chosen:

        uint8_t         yieldRequest;   // 0x4b, 1
        uint8_t             unknown_0c; // 0x4c, 1
        uint8_t         sleepReason;    // 0x4d, 1
        uint8_t             unknown_0d; // 0x4e, 1
        uint8_t             unknown_0e; // 0x4f, 1
        uint8_t         cpu_requested; // 0x50, 1 : 0, 1, ff,  ff means "any cpu"
        uint8_t         cpu_assigned; // 0x51, 1 : 0, 1, ff, ff means "not yet assigned"
        uint8_t             unknown_11; // 0x52, 1
        uint8_t             unknown_12; // 0x53, 1
        struct context *context;        // 0x54, 4
        uint32_t            unknown_13; // 0x58, 4
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: srsa on October 13, 2020, 07:51:36 PM
Quote from: names_are_hard on October 13, 2020, 03:36:56 AM
Are we cpu bound for recording video?
I'm not in the position to answer that, but I can say that the ARM core of DIGIC 6 is clocked faster than previous DIGICs and the primary ARM cores of DIGIC 7 are clocked 4x the clock of DIGIC 6. In my cameras - DSLRs might differ, I don't know.
Quotethis may allow ML to choose which cpu tasks run on
FWIW, there are versions of CreateTask that allow specifying the CPU core to run on.
In the M50 firmware (I don't have a D7 DSLR dump), the init1 task is created with the low level version of that function. If you trace that back in disassembly, one of its callers is a function with SystemIF::KerTask.c asserts - that one is the "normal" CreateTask_on_core. CreateTask_on_core also has a "strict" version (recognizable by the SystemIF::KerMisc.c assert). The name "CreateTask_on_core" is not the function's real name, just something I came up with.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on October 13, 2020, 08:16:07 PM
I thought that might be the case. The "normal" CreateTask (task_create in ML land) doesn't have a CPU argument and looks to copy the CPU index from current_task, so it will always schedule on the same CPU as the running task.

Do you know if existing code ever uses 0xff for cpu_requested?  I'm wondering if/when Canon would want tasks to be scheduled opportunistically on either CPU.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: srsa on October 13, 2020, 10:53:38 PM
Quote from: names_are_hard on October 13, 2020, 08:16:07 PM
Do you know if existing code ever uses 0xff for cpu_requested?  I'm wondering if/when Canon would want tasks to be scheduled opportunistically on either CPU.
"CreateTask_on_core" asserts if the core parameter is not 0 or 1. If what you're saying about task_create is true then I guess this DryOS configuration does not support that.
FWIW, I've encountered the following DryOS version string in a printer's firmware:
DRYOS version 2.3, release #0049+SMP
If the SMP is that SMP (https://en.wikipedia.org/wiki/Symmetric_multiprocessing), that might suggest that the DryOS instances in our cameras are not configured to be symmetric, but the OS itself supports that config.
The ARM cores are set to run in SMP mode (ACTLR (https://developer.arm.com/documentation/ddi0388/i/system-control/register-descriptions/auxiliary-control-register) register SMP bit is 1).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on October 14, 2020, 12:37:56 AM
Interesting.  The task consumer function on 200D will assign tasks that have that field set to 0xff.  Either CPU will take them.  It's an explicit check "if -1, assign task to this CPU", so it must be deliberate.  I haven't logged any tasks being created that match.

Curious about SMP.  200D says 2.3, release #0059 - a later release but not listed as SMP, yet the hardware is.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: T7i owner on October 15, 2020, 06:35:56 AM
It's so awesome to see progress on this port!
I'm a Rebel T7i owner and am willing to do testing wherever is needed.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: T7i owner on October 27, 2020, 05:05:05 AM
@names_are_hard
Can I be of help?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on October 27, 2020, 01:23:19 PM
There's no testing required if that's what you're thinking.  Have you got any experience with C or ARM assembly?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Abdul Samad on October 27, 2020, 06:15:29 PM
Is ML availabel for Canon 200D \ SL2 ?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on October 28, 2020, 11:58:12 AM
@Abdul - no.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: T7i owner on October 30, 2020, 07:51:06 PM
Quote from: names_are_hard on October 27, 2020, 01:23:19 PM
There's no testing required if that's what you're thinking.  Have you got any experience with C or ARM assembly?
Not really. But I'll be glad to help maybe even try learning.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on October 30, 2020, 08:40:53 PM
C is a fairly small language, so it doesn't take much time to learn; probably a few months.  Feel to give it a go!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on December 17, 2020, 01:21:44 AM
Thought I'd do a not very exciting update, so people know I haven't given up :)  I am mostly on the Discord these days, but will summarise things every so often:

- I took a step back and got a lot more familiar with the ML codebase
- I've merged a few ML branches in my git repo, meaning I don't need to keep switching branches to keep things in sync
- I updated Qemu to 4.2 (still some problems, but easier to build than old Qemu, and better in some ways)
- it is now easier to run stable test code on 200D
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: a1ex on December 17, 2020, 07:19:21 AM
Quote from: names_are_hard on December 17, 2020, 01:21:44 AM
- I took a step back and got a lot more familiar with the ML codebase

This is actually the step I'm most excited about :)

Yes, being able to discuss the low-level details to somebody who actually knows what they are talking about, makes a huge difference for me.

Quote
- I updated Qemu to 4.2 (still some problems, but easier to build than old Qemu, and better in some ways)

This one is also a significant update, as QEMU will be an essential piece of puzzle in supporting recent models (read: DIGIC 4+/6/7/8/X). There are significant - likely massive - amounts of low-level work ahead, but, without the ability to run automated tests for every single supported camera model (whether in emulator or... somehow on real hardware), I don't see any other reasonable way to support ML on all of these new models.

The development kit (https://www.magiclantern.fm/forum/index.php?topic=7531.msg232902#msg232902) from @coon will be another essential piece of puzzle - besides exploring camera (https://www.magiclantern.fm/forum/index.php?topic=25662.0) internals (https://www.magiclantern.fm/forum/index.php?topic=25661.0), it will allow debugging ML in real-time while running on real hardware, i.e. exactly where names_are_hard stumbled at his previous attempt. And I'm sure we'll find plenty other good uses for it in the near future.

Chapeau 8)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on December 18, 2020, 04:20:46 AM
Hah, I'm glad someone likes it :)  Maybe we should have a planning session soon, with the other active people.

Full agreement around automated testing.  The more complex the problem, the more important reducing human testing is.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Danne on December 18, 2020, 11:34:12 AM
Lowlevel work. I personally would donate to see work expansion here. Deepest respect.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: nikfreak on December 18, 2020, 12:55:40 PM
Time to set some member states to "Developer"
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Maix on January 06, 2021, 03:59:52 AM
Hows the development going?? (why'd you delete this before admin?)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Audionut on January 06, 2021, 04:34:33 AM
Because your post is a troll question.
https://wiki.magiclantern.fm/faq#any_progress_on_xyz
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 14, 2021, 11:31:03 PM
Diagnostics will now be easier:

Debug contacts, biro for scale:
(https://i.imgur.com/yisOKfB.jpg)

Post surgery (waiting on nicer connectors but I got impatient, this ugly way will do for now):
(https://i.imgur.com/oNND8nm.jpeg)

I only tore off one pad.  Your sacrifice will not be forgotten, pad number 5.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: wlfbbz on January 16, 2021, 02:00:04 AM
You are doing important work!! names_are_hard
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on February 24, 2021, 01:23:20 AM
Did this a while back but forgot to update:

Tiny wires:
(https://i.imgur.com/RVkfKOA.jpg)

Bonus serial ports:
(https://i.imgur.com/QZacvqB.jpg)

Debugging in action:
(https://i.imgur.com/QgFIzUl.jpg)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on February 24, 2021, 01:28:01 AM
After a few failed attempts, I have worked out the magic required to get a CONFIG_HELLO_WORLD build working in platform dir.  There's the minor bug that it stops the screen turning on, but you can't get everything right first time.  The code is running to hello_world(), LED blinks prove it.

This is a major step, I think it's the first public build for Digic >= 7 that is using the real build system.  Still many steps to go.

Current WIP is here:

https://github.com/reticulatedpines/magiclantern_simplified/tree/200d_hello_world_fix
(https://github.com/reticulatedpines/magiclantern_simplified/tree/200d_hello_world_fix)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on February 26, 2021, 01:21:37 AM
Blank screen bug is fixed by a short sleep to, presumably, let the display get initialised.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 01, 2021, 08:27:25 AM
Improved CONFIG_HELLO_WORLD platform/200D build:

(https://i.imgur.com/Jqh5bVl.jpg)

uart_printf() works too, between that and onscreen debugging, it should be easier than before to work out what that annoying TouchUtility error is.

Not recommended unless you know what you're doing, but the code is here: https://github.com/reticulatedpines/magiclantern_simplified/commit/051714b613644a6f0d04f0618049d41b2a2318b1

It should be fairly easy to adapt to other DIGIC 6, 7 and 8 cams.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: coco_goat on March 03, 2021, 10:01:09 PM
Quote from: names_are_hard on March 01, 2021, 08:27:25 AM
Improved CONFIG_HELLO_WORLD platform/200D build:

Yay, thank you for your work, names_are_hard! I'm trying to run this on my 200D, no luck so far.

- I've downloaded BOOT200D.FIR from this post https://www.magiclantern.fm/forum/index.php?topic=19737.msg212603#msg212603
- Enabled boot flag (I guess. "BOOT=-1" is okay?)

(https://junk.serverundermybed.com/s/QXReEe4AW47cF2y/preview)

- Made my card bootable

(https://junk.serverundermybed.com/s/n2ZA86wN4Q2FsQd/preview)

- Compiled autoexec.bin


> .../magiclantern_simplified/platform/200D.101/git rev-parse --short HEAD
051714b61

> .../magiclantern_simplified/platform/200D.101/make
Using ~/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc (preferred).
[ VERSION  ]   ../../platform/200D.101/version.bin
......... strip .........
[ LD       ]   magiclantern
[ OBJCOPY  ]   magiclantern.bin
[ STAT     ]   magiclantern.bin
magiclantern.bin: 210700 bytes
[ CC       ]   reboot.o
[ CC       ]   disp_direct.o
[ CC       ]   font_direct.o
[ CC       ]   footer.o
[ LD       ]   autoexec
[ XOR_CHK  ]   ../../build_tools/xor_chk
[ OBJCOPY  ]   autoexec.bin
[ XOR_CHK  ]   autoexec.bin

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000100 0x001b6300 0x001b6300 0x3370c 0x3f5fc RWE 0x100

Tip: to compile faster, try one of these:
    make -j4
    export MAKEFLAGS='-j4'

[ SYMBOLS  ]   magiclantern.sym
[ CP       ]   200D_101.sym


- Dropped autoexec.bin on my card (just autoexec.bin, without ML directory)

... and my camera freezes right after boot.
I see "sensor cleaning" animation and that's all, it does not respond to keys, or, at best, reboots.
What I'm doing wrong? If I'm doing everything right, could you please share your autoexec.bin? Or maybe I can somehow dump some logs to card?

UPD: It actually works. ML directory was mandatory :D

(https://junk.serverundermybed.com/s/dzooFQ3tP2rHzTo/preview)

And even ML itself is kinda trying to work, hehe, throws some asserts:

(https://junk.serverundermybed.com/s/q7aYwQ4XDDH3KRq/preview)

ML ASSERT:
0
at ../../src/bmp.c:69 (BMP_VRAM_START), task console_task
lv:0 mode:0

console_task stack: 2c3580 [2c36d0-2c26d0]
0xUNKNOWN  @ 1b6b7b:2c3580

Magic Lantern version : Nightly.2021Mar03.200D101
Mercurial changeset   : NO_HG
Built on 2021-03-03 21:43:07 UTC by username@tp.
Free Memory  : 0K + 2759K


ML ASSERT:
0
at ../../src/bmp.c:69 (BMP_VRAM_START), task notifybox_task
lv:0 mode:0

notifybox_task stack: 2ad448 [2ad690-2ac690]
0xUNKNOWN  @ 1b6b7b:2ad448

Magic Lantern version : Nightly.2021Mar03.200D101
Mercurial changeset   : NO_HG
Built on 2021-03-03 21:43:07 UTC by username@tp.
Free Memory  : 0K + 2760K
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: c_joerg on March 04, 2021, 10:47:44 AM
I see exFAT in EOScard. Does exFAT work?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 04, 2021, 02:50:17 PM
@coco_goat - welcome aboard, glad you got it working!  I will warn you, it's almost entirely untested.  Chances of it breaking something are much higher than real ML.  It looks like you tried to do a non-CONFIG_HELLO_WORLD build.  That's especially untested and increases risk as it will try to use more functionality.  People willing to work with the code and try and understand what's going on are definitely welcome though!

Consider joining the Discord, you can get quicker feedback there and I don't post everything to the forums, only the stuff that's more generally interesting.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: T7i owner on March 04, 2021, 11:46:03 PM
Quote from: names_are_hard on March 04, 2021, 02:50:17 PM
Consider joining the Discord, you can get quicker feedback there and I don't post everything to the forums, only the stuff that's more generally interesting.
Anyway I can join the discord?

I would love to test stuff out, meanwhile I'll still work on my C learning skills ;)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 05, 2021, 01:49:41 AM
Scroll up, hit the Discord link.  It's not at a stage where things really need testing, and I don't recommend anyone run the code in my repo without understanding it first.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: coco_goat on March 05, 2021, 04:58:44 PM
Quote from: names_are_hard on March 04, 2021, 02:50:17 PM
@coco_goat - welcome aboard, glad you got it working!  I will warn you, it's almost entirely untested.  Chances of it breaking something are much higher than real ML.  It looks like you tried to do a non-CONFIG_HELLO_WORLD build.  That's especially untested and increases risk as it will try to use more functionality.  People willing to work with the code and try and understand what's going on are definitely welcome though!

Consider joining the Discord, you can get quicker feedback there and I don't post everything to the forums, only the stuff that's more generally interesting.

Thanks, I'll visit you someday :) I had some experience in reversing x86 code with OllyDdg and tried to dig a bit 200D firmware in IDA/Ghidra, but it looks quite hazy so far. Toolchain itself is very inconvenient, e.g. I have no idea how to quickly load 200 ROM fragments produced by romcpy.sh to different addresses, what's preventing running 200D FW in QEMU, what are that gdb patches (and how to use gdb at all, lol), how ML bootstraps itself, like where does control go after after my_big_init_task... etc. But at least it's now builds!

--

BTW have you guys seen this? https://github.com/turtiustrek/magiclantern_simplified
Someone ported avrcraft to 200D! (it's Minecraft server, not client)

Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on March 05, 2021, 08:30:10 PM
Yes, we've seen this. Turtius is quite active in ML Discord ...
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 05, 2021, 08:52:31 PM
I'd say the toolchain is not truly inconvenient, it's more that the problem is hard - and the toolchain isn't documented as well as it could be.  Once you've worked out how to use it, it's good for the normal problems we're trying to solve.

QuoteI have no idea how to quickly load 200 ROM fragments produced by romcpy.sh to different addresses
I used dd to put romcpy output that had similar addresses into one file, then mapped those few combined files into memory space for my 200D project.  One way to do that last part in Ghidra is the Display Memory Map icon.

Quotewhat's preventing running 200D FW in QEMU
Not quite clear what you mean here, it does run.  It doesn't emulate fully (or even very far).  And of course, improving Qemu emulation is a much needed task; there are always camera specific behaviours that need to be understood so Qemu can be made to handle them.

Quotehow ML bootstraps itself, like where does control go after after my_big_init_task
https://a1ex.magiclantern.fm/bleeding-edge/ml-startup.png
By a1ex, from this thread:
https://www.magiclantern.fm/forum/index.php?topic=23641.0

Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: fgervais on March 07, 2021, 04:20:39 PM
I'm trying to estimate my chances of making the 800d port on my side before I buy the unit.

Not sure how you guys normally exchange files but I'm leaving a dropbox file request link here in case somebody could drop the 800d ROM:

https://www.dropbox.com/request/lNqRrP4SW4a10SUflsGQ
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 07, 2021, 06:29:26 PM
What background do you have in reverse engineering / embedded development / C / ARM asm?  If you're strong in any one of those, your chances of eventually completing a port are high, if you are persistent.  But I would expect it to take months / years.

If you want to use ML, get a cam that's supported.  If you want to port ML, that's great!  We will help you learn what you need to get started.  Expect it to take a long time.  Most people that start, give up.

Porting becomes significantly easier if there is a supported cam for the same generation of Digic.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: fgervais on March 07, 2021, 10:38:12 PM
Yes on the technical side of things I'm fine. I can definitely do the port if my life would depend on it ;) but I'd like to start looking at the firmware and see if this would fit in one of my free time slice.

If you want to know more about me out of curiosity, this page pretty much sums it up:

https://fgervais.github.io/
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 08, 2021, 05:05:56 AM
Cool, you'd probably enjoy it.  We have a few active devs at the moment, we're okay on the reversing side and general HW understanding, but not skilled at ARM internals.  A1ex has good ARM knowledge but, currently not enough time.

Let me give you a quick summary of some random points:
- Can run arbitrary code, from C, on real cams (this should include 800D).  This can be triggered interactively when Canon code (DryOS) is running.
- Can emulate cams to varying degrees in a custom version of Qemu.  Old cams have full GUI menus and can even simulate taking pictures, etc.  New cams (including 800D) don't emulate that far but can do early init before getting stuck.  Not crashed: they go to an idle state, waiting for tasks from a queue that is empty.  Somewhat earlier I see Canon code checking a struct in mem that is not initialised.  On real hardware it is, so whatever inits that is a missing piece, though perhaps not the direct cause.
- With a little work for the physical connection, you should be able to get UART access to the cam, includes an interactive shell.  There are different shells for different processors.
- ROMs are quite friendly to work with, no obfuscation and they contain many debug strings, including an assert function
- Overall structure of Canon OS, DryOS, is fairly well understood.  RTOS, task based via a queue, interrupts.  Some of the messaging protocols between peripherals are understood.
- ML abstracts camera internals to some degree.  There is good support for a range of Digic 4 and 5 cameras.  800D is Digic 7, getting ML working on Digic 7 is mostly working out how 7 has diverged from 4&5 and updating ML to support this.  Structures used by Canon APIs may have new fields, HW abstraction in ML may need updating for new co-processors, etc.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: fgervais on March 08, 2021, 01:53:19 PM
Nice I'll have a look, thank you
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 15, 2021, 09:07:41 AM
Good progess over the weekend.  The horrible task bugs were defeated.  Stable ML code up to GUI.  Button handling works.  Menus don't, but drawing does.  Getting there.

[gifv]https://i.imgur.com/ANitaWm.mp4[/gifv]
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 29, 2021, 02:13:37 AM
Don't get excited, it's just the menus, nothing works...  but:

[gifv]https://i.imgur.com/UP8gqR0.mp4[/gifv]


Teamwork with Kitor, thanks!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Raging Ocelot on April 01, 2021, 01:08:32 PM
This makes me happy. I have a T7i upgraded from a T3i and I can't wait for a magic lantern upload for my T7i.. Thank you so much for your work.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Ondre on April 02, 2021, 08:47:43 PM
Maybe I can make a donation to support the developer?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on April 06, 2021, 12:38:32 PM
Bitcoin only, ATM. And you can only donate to the project but not to a particular port or dev.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Straight_Shooter on May 19, 2021, 02:56:12 PM
It would be great if one could donate to this project via PayPal. I know I would give a couple bucks to it for sure.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on May 21, 2021, 02:00:23 PM
Have an HDMI capture progress report from 200D.  Minor edits to skip boring pauses:

[gifv]https://i.imgur.com/hBmJDKN.mp4[/gifv]
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on May 22, 2021, 05:33:09 PM
Quite hard bug diagnosed and provisionally fixed in module relocation.  Took me a few weeks to understand.  This is very significant, it removes a large number of very hard to understand crashes from modules, and exposes other, easier to debug problems.

Module loading in ML works by building ELF objects, which are copied to card, and then ML uses libtcc to load these into mem.  The loading process has a relocation step.  There were (probably) two problems here.  The more important, libtcc has I think a bug when it checks to see if the relocation is too far.  Since modules are built as ARM, not Thumb, the default approach means the target of calls / jumps can only be +-32MB from the call site; ARM encodes the address in 24 bits.

For at least Digic 7 cams, offsets can be outside this range, they're typically in 0xe000.0000 or 0xdf00.0000 areas.  Older cams are in 0xff80.0000 or thereabouts, so you can underflow and be within 32MB.  Libtcc tries to check if the target is outside this range but the error condition doesn't trigger.  This was causing tccelf.c, relocate_sections() to fixup the modules with inappropriate relocations.  And that meant calls from within module code would go to *completely unrelated* offsets, with unpredictable and very hard to diagnose crashes.

As far as I can see, the fact that older cams happen to allow modules to successfully relocate was always luck.  If heap allocs had occured from a different region, or if stub addresses hadn't happened to be "near" to heap addresses via wraparound, it would never have worked.

My provisional fix is to build modules with -mlong-calls.  This changes the asm output so the form is "blx r3" style, which allows full 32-bit offsets.  This incurs a minor space and perf cost, and is currently untested on old cams.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on May 22, 2021, 09:44:01 PM
Quoteand is currently untested on old cams.

Not true anymore, verified on 50D to work as intended ;)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: heder on May 23, 2021, 10:16:32 AM
"+/-32 MB near jump issue" : This is (I guess) the problem that all new cameras will face. It's also on the 1300D. On 1300D you can not hijack any calls as the addresses (csanon firmware) are further away than +/-32MB from the magic lantern firmware. I recreated a patch function that instead of using a single near jump, uses a near jump that jumps into a long call jump. Maybe this problem is also present on DIGIC7? ... if so a *temporary* solution is present in the 1300D thread.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on May 23, 2021, 03:03:51 PM
For the module context, since we control the source and are compiling it, I think using -mlong-calls is an appropriate fix.  For patching at runtime, that won't work and you might need to do what you're describing.  I guess that's the context you need to work in, so you can't use -mlong-calls?  Do modules work on 1300D?  If DryOS code is far from heap alloc region, I think they won't, and I also think that my fix will work for you.

I'd like someone with better experience with ARM to confirm -mlong-calls makes sense for where I'm using it - any volunteers?

I'm not doing any runtime patches yet on 200D, they haven't been needed.  I'm assuming I'll use MMU remapping when it gets to that (or, if I'm lucky, overwriting a thunked function, the 200D has *some* code in RWX pages).
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: heder on May 23, 2021, 09:13:09 PM
Quote from: names_are_hard on May 23, 2021, 03:03:51 PM
For the module context, since we control the source and are compiling it, I think using -mlong-calls is an appropriate fix.  For patching at runtime, that won't work and you might need to do what you're describing.  I guess that's the context you need to work in, so you can't use -mlong-calls?  Do modules work on 1300D?  If DryOS code is far from heap alloc region, I think they won't, and I also think that my fix will work for you.

I'd like someone with better experience with ARM to confirm -mlong-calls makes sense for where I'm using it - any volunteers?

I'm not doing any runtime patches yet on 200D, they haven't been needed.  I'm assuming I'll use MMU remapping when it gets to that (or, if I'm lucky, overwriting a thunked function, the 200D has *some* code in RWX pages).

I think the -mlong-calls trick is the way to go, the optimization gained by using relative jumps is ussless.

I dont know if modules are running on the 1300D, I just worked out a solution for hijacking firmware functions, where you patch a single instruction, and you're right about that the heap alloc region need to be close, aka within +/-32MB from canon firmware (99%). 

I'll ask citrix to read this thread
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on May 23, 2021, 11:15:19 PM
I'm not sure.  Relative calls are 1 instruction, 4 bytes and no memory access. Long calls are 2 instructions, 8 + 4 bytes including an addition d-cache read.  It's easy to imagine situations where it would be significant, but I don't know if we hit them.  Not enough runs on 200D for me to try profiling it, and I can't use relative calls for modules so I can't do a comparison easily.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kadushkin90 on May 25, 2021, 03:31:24 PM
Hello, I don't understand anything about programming, but I do have a 6D mark II camera available. Is there anything I can do to help you?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on May 25, 2021, 03:58:29 PM
I don't think so. ATM programmers need physical access to a camera.
One thing you are able to do now but it won't accelerate porting ML to 6D2: Looking for UART connectors (https://www.magiclantern.fm/forum/index.php?topic=7531.msg235152#msg235152).

EDIT: Not needed anymore. Watched a disassembly video. I'm sure UART is located right from rear dial and there is a rectangular hole to access it.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on May 25, 2021, 05:32:46 PM
Beep boop.  200D has a game.

[gifv]https://i.imgur.com/FrzpFvk.mp4[/gifv]

One day, font addr will be good.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 14, 2021, 06:08:44 AM
Made some improvements to memory management routines, and fixed some ML assumptions that were not true for newer Digic:
https://github.com/reticulatedpines/magiclantern_simplified/tree/feature_show_free_mem

This means there's now a useful display of memory info for 200D.  Should be not hard to extend to other semi-supported Digic 6, 7, 8 cams:

[gifv]https://i.imgur.com/PAcDmMF.mp4[/gifv]
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on August 06, 2021, 05:14:45 PM
Progress continues.  Free Mem work uncovered some complicated problems with SRM allocator that took a while to get tamed (Kitor helped a lot here, thanks!).  For now, we have disabled this allocator on D678 (couldn't get free() to work correctly, which causes crashes due to SRM being a LIFO allocator).

Due to bumping up against the ML reserved memory limit, I worked out how to steal more memory from DryOS in early init.  ASCII art summary here: https://github.com/reticulatedpines/magiclantern_simplified/commit/a0bc8f60af48ff48e448632e55507c47445d2246
This works well on the cameras we've tested on (200D, R, RP, M50 I think, maybe not all of these).  We have enough memory now that we can have multiple features enabled, plus I made it simpler to adjust how much is being stolen.  But a downside is that it requires changes to stubs.S for other D678 cams in order to build.  That means I have to do some reversing work on every other D678 cam, or split the cams so some use the old system.  I'd like to avoid the latter option as the solution should be general, and splitting would make the code quite a lot more ugly.

Separately, I got task info working.  This required tracking down some changes to task related structs (task_attr_str).  And fixing a bunch of null pointer derefs in ML code!  Digic 4 and 5 cams don't crash on null pointer derefs, but D678 ones do, due to MMU settings...  I'm sure there's lots more of that fun to discover.

Next up is finding something acceptable to do with new memory stealing on the other D678 cams, then getting Qemu regression testing working locally, so I can have some confidence that changes to support new cams hasn't broken old cams.  I think it's likely this will expose some problems, my repo is a poorly tested merge of several important upstream branches, these will then need fixing.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: OverrRyde on October 13, 2021, 09:59:53 PM
Thank you very much for the updates! Created and account to keep track.

Has there been any progress since the last update? All i really want is clean HDMI! LOL

thank you again!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Brakeless on November 03, 2021, 11:43:21 AM
Thanks guys. I'm not a develop, but I have now 6D2 and after 2 weeks I will return my EOS R. I can run your works if it helps you...? I just try to help. Hello from Russia ❤️
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on November 04, 2021, 05:54:14 AM
Thanks for the offer.  We have an active dev with EOS R, but there is nothing that needs testing.  6D2 doesn't have a dev working on it, so, again, nothing to test.  Later on you could maybe help porting by doing tests on 6D2, but I think all devs are busy enough for now that they won't have time for that.  I'll let you know if I'm wrong!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on November 15, 2021, 05:12:28 AM
All D678 cams can now use the same improved mem stealing logic.  This means one less file to maintain, plus more memory for ML.  This was fairly complicated work and I had to update every cam after confirming stuff in roms.  Kitor had a nice idea on how to simplify one part of this process that reduces what you need to find on new ports, as well as letting me make the code cleaner.

Implemented a mechanism for allowing limited PROP_REQUEST_CHANGE so we can safely experiment without enabling all props.

A bunch of small improvements to the build system to remove some annoyances, and a major fix that removes a significant race condition with parallel builds.  The "minimal" subdir builds were clobbering files during build, causing "make zip" builds to fail randomly.  Was quite annoying to track down.

Found initial stubs for 6D2 builds, should be easy now to get what we have running on that cam.

Generally, a lot of boring but useful work that is applicable to all D678 cams, not just Digic 7.  There's some small bonuses as well, you can check the repo if you want to find them.

Special thanks to kitor and coon who have been quite active lately doing a lot of good work, checking my stuff, talking ideas over, as well as doing their own work and merging in.  I'll let them talk about their own parts!  Between us we're doing well keeping all the things we add working across D678.

We even have a few possible new devs in Discord, who will hopefully stick around!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Thelgord on February 06, 2022, 03:20:25 PM
"Found initial stubs for 6D2 builds, should be easy now to get what we have running on that cam."

Thank you! Just found this thread and I am excited that my camera is being worked on :) If you need a tester for the 6D2 just hit me up :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: shankar101 on April 30, 2022, 09:55:17 AM
Hi where did the development reach?? I believe 200d is going to be way better than  eos m for raw.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on April 30, 2022, 10:03:19 AM
Unfortunately your beliefs have no backup in any measurable data. We are not even close to any raw capabilities on Digic6+ models, do not expect anything in literally years from now unless a miracle happens.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: zvonkok on June 17, 2022, 11:55:53 AM
What is the status of 6D2? I have a background in embedded development and would like to help. I am mostly interested in having a clean HDMI on my 6d2. Thanks.
Asking to not duplicate work.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on June 26, 2022, 06:18:47 AM
Using MMU patches, I hooked mpu_send() and mpu_recv().  This allowed me to obtain a nice clean log of early MPU messages from 200D.  The same technique will be easy to adapt to all other D7, D8, DX cams.

This should greatly help in improving emulation.  So far I've only logged the very early messages, but in theory this can also log MPU traffic while the camera is exercised, to see how different camera functions work.  Note that the messages as seen by these functions are missing a container layer, so e.g. these two lines (one from my code, one from Qemu logging) are the equivalent message:

mpu_send: 06 01 27 00 64 00
[MPU] Received: 08 06 01 24 00 01 00 00  (PROP_CARD2_STATUS - spell #7)

Adding this extra layer for Qemu use looks easy.

The build is from this commit: https://github.com/reticulatedpines/magiclantern_simplified/commit/4d037140ad1c3ea72c16d508de65ddcc13f98a8d

Log (after slight manual cleanup, UART log lines get interlaced sometimes): https://pastebin.com/VmRdvQ9E
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on August 15, 2022, 05:33:00 AM
Dual ISO now works on 200D.  So that's nice.  Process is similar to other cams, but the data format for ADTG / CMOS registers appears different, here are some examples:


0b400000 // ISO 100
0b444440 // 1600
0b440400 // Dual ISO, 100/1600
0b455550 // 3200
0b466660 // 6400
0b466660 // 12800, so presumably this is boosted further elsewhere and is non-native ISO


I'm currently assuming this means the data is now 16 bit, and b4 is the register index.  The lower and upper 4 bits are used by some commands.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Danne on August 15, 2022, 08:13:03 AM
 :o
Nice work!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on November 24, 2022, 05:52:13 PM
Some more understanding of the task scheduler.  I'm now confident that on 200d, e021cc4c is irq_handler(), it runs whenever an irq is triggered, due to VBAR setup in early code, see the table of handlers at e021cb60, associated with VBAR setup at e0040002:

coprocessor_moveto(0xf,0,0,&LAB_e021cb60,in_cr12,in_cr0);


See ARM manual, B4.1.156 for that mcr usage.  Also see FUN_e01caa88(&LAB_e021cb60,"Exception vector") for finding VBAR address.

As part of irq_handler(), we have:

  if (bVar5) {
    handle_interrupt();
    DAT_0000100c = DAT_0000100c + -1;
    return *puVar6;
  }
  handle_interrupt();
  thunk_FUN_df003028();
  change_running_task_maybe(&PTR_0000101c,&PTR_00001020);


This means that in most cases, handling an IRQ triggers assessing whether the task should change.  Which means the irq_handler is in essence the scheduler.  I assume there's a timer that triggers a periodic irq so it can't stall if the rest of the system is idle
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: GabrielJLozano on December 08, 2022, 05:11:20 PM
Still following this. Every year I hope that it will be here by Christmas but greatness takes time I guess.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Atarugolan on January 06, 2023, 01:55:31 PM
Hi All, sorry if I ask, I used the Magic Lantern in my old 1100D, fantastic ovbiusly, but I see nobody do anything for the 6D2, anybody ha doing something?

Thanks
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on January 06, 2023, 04:29:30 PM
Nobody working on it.
Last talk with dev-to-be on Discord was November, 2021.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Atarugolan on January 07, 2023, 07:19:52 PM
Any chance to ask developer to do something? :D
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on January 07, 2023, 07:40:02 PM
Quote from: Atarugolan on January 07, 2023, 07:19:52 PM
Any chance to ask developer to do something? :D

Sure. Please repeat:

"Are we there yet, developers?"
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 07, 2023, 08:36:33 PM
I'm the most active (only?) dev for Digic 7 cams, and I don't have a 6D2.  I did a blind port, but don't have a way to test it.  It has no features.

There won't be any progress on 6D2 until we get a dev that wants to work on it, or I get a 6D2 and a lot more spare time.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Bruno Italiano on January 07, 2023, 11:02:25 PM
Don't worry and You don't have to get in any stress. I love my 5d3 the most anyway.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on April 04, 2023, 05:17:28 AM
As seen elsewhere, I now have good control over Wifi on 200D.  The code should be easily portable to other Digic 7 (and very likely 8, X): https://www.magiclantern.fm/forum/index.php?topic=26850.msg242999#msg242999

Further to that, I've confirmed that the 200D forces the Wifi into a low-power mode.  But this can be overriden using an MMU patch.  Also confirmed, 200D supports 802.11n, 2.4GHz only.  No sign of 802.11ac but n is okay!

Combining both of those, I have boosted bandwidth to about 3.8MB/s.  That's around 3s to upload a full res JPG - pretty useful!  It's very range dependent to the AP so I suspect the cam has a crappy antenna / transmit power.  I'm in a pretty noisy wifi environment so higher may be achievable.

e071f174 on 200D 1.0.1 is something like get_wifi_power_settings(int *chip_index, int *is_low_power).  This always sets chip_index to 1 and is_low_power to 1.  Setting is_low_power to 0 gives MOAR POWER, and presumably less battery life.  I would expect this tweak to make all Canon wifi functions faster, not just ML stuff.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: kitor on May 21, 2023, 03:45:18 PM
(https://kitor.pl/eos/img/77d_th.jpg) (https://kitor.pl/eos/img/77d.jpg)

77D.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 29, 2024, 06:25:35 PM
As noted here, I have some useful edmac / raw progress on 200D: https://www.magiclantern.fm/forum/index.php?topic=13746.msg245918#msg245918

I've now got mlv_lite meeting all deps for 200D (this doesn't mean much, just that all required symbols are exported - some of these I am faking for now).  Trying to run it causes problems, multiple in fact.  I've fixed some serious bugs in the module, and surrounding code (that in theory affect all cams, but may not be possible to hit in practice).  We have very bad discipline around checking for null pointers before use, which on D7 and up causes an exception, whereas D456 you can get away with it.  Canon code has also been changed due to this, they have added many more checks :D  One of the problems is the FIO_* functions often take char *filename, and Canon code checks this now, and asserts.  ML can sometimes pass in null pointers.

One oddity is worth noting.  Some MMIO addresses have changed from Digic 5, we've known this for a while.  For D5 0xc0f06014 is FPS_REGISTER_B (which is hard-coded into the source, a painful decision that I must fix).  On 7D2, this has moved to 0xd0006014.  But on 200D, while the *value* 0xd0006014 is used, it's not used as an address.  Instead, there's an array of (addr, val) pairs, 0xd0006014 is one of the addresses, and the code has some utility functions to search the array, and either update the val from a global (obtained via a function I am calling get_fps_register_b_val()), or return the val.  See e.g. e032b54a().

It's quite weird.  I suppose it might be a more space efficient way to do shamem_read(), if the region was sparsely populated?  This complicates things in at least two ways: there's no fixed offset for FPS_REGISTER_B, I may have to refactor all accesses into a function call.  Second, on 200D we can't assume 0xd00X_YYYY constants are MMIO access, which may break many assumptions in ML code.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on January 29, 2024, 11:45:10 PM
This is related to engio_write()!  I didn't recognise the code because we've never found that function for digic 7.  I might be misinterpreting whether it's writing into the array, or writing through pointers stored in the array - the (addr, val) pairs are very similar to engio_write() buffers used on 5D3 (and I assume, other cams).  I need to look at this in more depth.

_engio_write() itself is probably at e050d6dc.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: magiclantern.oimu5 on March 07, 2024, 08:43:29 PM
Hey there, I have a 6D2 and some time and will to work on it. Anything I can test?

Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on March 07, 2024, 09:06:31 PM
Quote from: magiclantern.oimu5 on March 07, 2024, 08:43:29 PMand will to work on it.

Please specify what you mean by that. Programming?
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: magiclantern.oimu5 on March 08, 2024, 07:03:46 PM
Yes, programming, reverse engineering, I have a background in embedded, firmware, virtualization development.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: Walter Schulz on March 08, 2024, 07:11:01 PM
Welcome to our discord, then.
ML devs meet and discuss stuff there: https://discord.gg/uaY8akC
-> Dev stuff ->
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 08, 2024, 08:24:02 PM
Quote from: magiclantern.oimu5 on March 08, 2024, 07:03:46 PMYes, programming, reverse engineering, I have a background in embedded, firmware, virtualization development.

Good timing, we have someone who is currently updating the partially-supported ROM version from 1.0.5 to 1.1.1.  I am checking the changes currently.

I think it's likely that 6D2 can quickly be brought up to the same level of support as 200D, it's the same digic gen.  That would mean getting raw video on 6D2 is quite plausible.  On 200D, dual ISO works, too, as well as network support.

Discord is probably the easiest way to get you quickly setup.  But I'm happy to help here.  You will want this repo: https://github.com/reticulatedpines/magiclantern_simplified/commits

It should build easily on modern linux, I use Debian Testing.  We don't have a good checker for pre-reqs, missing rst2html is a common problem, for that you want python3-docutils.

Currently, it's fw 1.0.5.  1.1.1 is the new target, I expect my checks will be completed and 1.1.1 support merged within a week.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: magiclantern.oimu5 on March 12, 2024, 07:44:35 AM
I have a crossdev environment setup and trying to build the code for 6D2.105.
Reading up all the docs that are available from the posted repository.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 12, 2024, 03:46:15 PM
Great, let me know if you have any problems.  The docs are very incomplete.  The docs generally for ML are quite awkward, sadly.  They're split over many different sources, quality varies.  Finding what you need is often difficult.

Hence why I'm trying to make a coherent dev guide, but I'm expecting this to take a long time.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 15, 2024, 03:10:38 PM
6D2 1.1.1 now has limited support.  Our one dev / tester (unsure if they have an account here, CrypticKlippo on Discord), suggests it's stable.  It's the standard "has ML GUI, has no features" early build.  A good place to work from to add things.

https://github.com/reticulatedpines/magiclantern_simplified/commit/d16c293288737193bc785f09e8f8cd86a888feb6
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: SebastianC on March 21, 2024, 02:41:23 PM
Quote from: names_are_hard on March 15, 2024, 03:10:38 PM6D2 1.1.1 now has limited support.  Our one dev / tester (unsure if they have an account here, CrypticKlippo on Discord), suggests it's stable.  It's the standard "has ML GUI, has no features" early build.  A good place to work from to add things.

https://github.com/reticulatedpines/magiclantern_simplified/commit/d16c293288737193bc785f09e8f8cd86a888feb6


Hi Names:

I would like ask how to do this, I am only know how to setting other ML file in SD card.Is it load in SD&CF card or other way? Thank you!
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 21, 2024, 03:31:37 PM
Do you mean add features to the build?  You'll need to know C, and have time to learn the code, and Ghidra, to understand the rom.  What do you know so far?

The 6D2 does not have a CF slot.
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: SebastianC on March 21, 2024, 11:05:56 PM
Quote from: names_are_hard on March 21, 2024, 03:31:37 PMDo you mean add features to the build?  You'll need to know C, and have time to learn the code, and Ghidra, to understand the rom.  What do you know so far?

The 6D2 does not have a CF slot.

You are right. I thought I can not do any coding:)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 22, 2024, 12:42:46 AM
Sorry, it's not that easy :)
Title: Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
Post by: names_are_hard on March 27, 2024, 08:18:19 PM
Found a quite interesting shell command, EngMirrorDump.  This takes an integer, and returns info on a shamem region.  This includes the name of the subsystem (engine), and address offset in shamem.  It also dumps content to card.  Results from 200D.  The full list is long, but these at least are interesting and show it's useful to us:

EngMirrorDump 3   (CHANNEL) Addr:4000,Size:1000,Flag:0
EngMirrorDump 29  (CHANNEL) Addr:26000,Size:1000,Flag:0
EngMirrorDump 37  (CHANNEL) Addr:30000,Size:1000,Flag:0
EngMirrorDump 65  (CHANNEL) Addr:57000,Size:1000,Flag:0
EngMirrorDump 66  (CHANNEL) Addr:58000,Size:1000,Flag:0

These are the EDMAC channel ranges.

Full list:
EngMirrorDump 0   (PWRCNT/SETTER) Addr:1000,Size:1000,Flag:0
EngMirrorDump 1   (KAISER) Addr:2000,Size:1000,Flag:0
EngMirrorDump 2   (SHAREMEM) Addr:3000,Size:1000,Flag:0
EngMirrorDump 3   (CHANNEL) Addr:4000,Size:1000,Flag:0
EngMirrorDump 4   (CHNSW) Addr:5000,Size:1000,Flag:0
EngMirrorDump 5   (HEAD) Addr:6000,Size:1000,Flag:0
EngMirrorDump 6   (HEAD) Addr:7000,Size:1000,Flag:0
EngMirrorDump 7   (PEPPER) Addr:8000,Size:1000,Flag:0
EngMirrorDump 8   (FAUST) Addr:9000,Size:1000,Flag:0
EngMirrorDump 9   (WOMBAT) Addr:a000,Size:1000,Flag:0
EngMirrorDump 10  (WOMBAT) Addr:b000,Size:1000,Flag:0
EngMirrorDump 11  (WOMBAT) Addr:c000,Size:1000,Flag:0
EngMirrorDump 12  (AFFINE) Addr:10000,Size:1000,Flag:0
EngMirrorDump 13  (FIXER) Addr:11000,Size:1000,Flag:0
EngMirrorDump 14  (TAIWAN) Addr:12000,Size:1000,Flag:0
EngMirrorDump 15  (RABBIT) Addr:13000,Size:1000,Flag:0
EngMirrorDump 16  (POSTER/SARIDON) Addr:15000,Size:1000,Flag:0
EngMirrorDump 17  (HISTORY) Addr:16000,Size:1000,Flag:0
EngMirrorDump 18  (PCFG) Addr:18000,Size:1000,Flag:0
EngMirrorDump 19  (WOMBAT) Addr:19000,Size:1000,Flag:0
EngMirrorDump 20  (LUCKY) Addr:1a000,Size:1000,Flag:0
EngMirrorDump 21  (DANCING) Addr:1b000,Size:1000,Flag:0
EngMirrorDump 22  (DANCING) Addr:1c000,Size:1000,Flag:0
EngMirrorDump 23  (PONY) Addr:1d000,Size:1000,Flag:0
EngMirrorDump 24  (LOTUS) Addr:1e000,Size:1000,Flag:0
EngMirrorDump 25  (LUCKY) Addr:20000,Size:1000,Flag:0
EngMirrorDump 26  (LUCKY) Addr:22000,Size:1000,Flag:0
EngMirrorDump 27  (CPUIF) Addr:24000,Size:1000,Flag:0
EngMirrorDump 28  (LUCKY) Addr:25000,Size:1000,Flag:0
EngMirrorDump 29  (CHANNEL) Addr:26000,Size:1000,Flag:0
EngMirrorDump 30  (DISTER) Addr:28000,Size:1000,Flag:0
EngMirrorDump 31  (SARIDON2) Addr:29000,Size:1000,Flag:0
EngMirrorDump 32  (QUARK) Addr:2a000,Size:1000,Flag:0
EngMirrorDump 33  (SUMMA) Addr:2b000,Size:1000,Flag:0
EngMirrorDump 34  (SMAP) Addr:2d000,Size:1000,Flag:0
EngMirrorDump 35  (OHYEAR) Addr:2e000,Size:1000,Flag:0
EngMirrorDump 36  (MICROU) Addr:2f000,Size:1000,Flag:0
EngMirrorDump 37  (CHANNEL) Addr:30000,Size:1000,Flag:0
EngMirrorDump 38  (MOSSY) Addr:34000,Size:1000,Flag:0
EngMirrorDump 39  (PEPPER) Addr:37000,Size:1000,Flag:0
EngMirrorDump 40  (SHREK) Addr:38000,Size:1000,Flag:0
EngMirrorDump 41  (SUSAN_A) Addr:39000,Size:1000,Flag:0
EngMirrorDump 42  (SUSAN_B) Addr:3a000,Size:1000,Flag:0
EngMirrorDump 43  (LUCKY) Addr:3c000,Size:1000,Flag:0
EngMirrorDump 44  (LUCKY) Addr:3e000,Size:1000,Flag:0
EngMirrorDump 45  (LUCKY) Addr:40000,Size:1000,Flag:0
EngMirrorDump 46  (LTKIDS) Addr:42000,Size:1000,Flag:0
EngMirrorDump 47  (SUSAN_A) Addr:43000,Size:1000,Flag:0
EngMirrorDump 48  (PEPPER) Addr:45000,Size:1000,Flag:0
EngMirrorDump 49  (BAUST) Addr:46000,Size:1000,Flag:0
EngMirrorDump 50  (HAIZEN) Addr:47000,Size:1000,Flag:0
EngMirrorDump 51  (HISTORY2) Addr:48000,Size:1000,Flag:0
EngMirrorDump 52  (HISTORY2) Addr:49000,Size:1000,Flag:0
EngMirrorDump 53  (HISTORY2) Addr:4a000,Size:1000,Flag:0
EngMirrorDump 54  (HISTORY2) Addr:4b000,Size:1000,Flag:0
EngMirrorDump 55  (CUMULO) Addr:4c000,Size:1000,Flag:0
EngMirrorDump 56  (CAPTAIN) Addr:4d000,Size:1000,Flag:0
EngMirrorDump 57  (CDM) Addr:4e000,Size:1000,Flag:0
EngMirrorDump 58  (WEAVER) Addr:4f000,Size:1000,Flag:0
EngMirrorDump 59  (WEAVER) Addr:50000,Size:1000,Flag:0
EngMirrorDump 60  (VERSARCH) Addr:51000,Size:1000,Flag:0
EngMirrorDump 61  (OPTIMUS) Addr:52000,Size:1000,Flag:0
EngMirrorDump 62  (ELISION) Addr:53000,Size:1000,Flag:0
EngMirrorDump 63  (COMPASS) Addr:54000,Size:1000,Flag:0
EngMirrorDump 64  (PURE) Addr:55000,Size:1000,Flag:0
EngMirrorDump 65  (CHANNEL) Addr:57000,Size:1000,Flag:0
EngMirrorDump 66  (CHANNEL) Addr:58000,Size:1000,Flag:0
EngMirrorDump 67  (ECHIZEN) Addr:59000,Size:1000,Flag:0
EngMirrorDump 68  (ECHIZEN) Addr:5a000,Size:1000,Flag:0
EngMirrorDump 69  (ECHIZEN) Addr:5b000,Size:1000,Flag:0
EngMirrorDump 70  (ECHIGO) Addr:5c000,Size:1000,Flag:0
EngMirrorDump 71  (ECHIGO) Addr:5d000,Size:1000,Flag:0
EngMirrorDump 72  (ECHIGO) Addr:5e000,Size:1000,Flag:0
EngMirrorDump 73  (POSTER) Addr:5f000,Size:1000,Flag:0
EngMirrorDump 74  (BIZEN) Addr:60000,Size:1000,Flag:0
EngMirrorDump 75  (BIZEN) Addr:61000,Size:1000,Flag:0
EngMirrorDump 76  (BIZEN) Addr:62000,Size:1000,Flag:0
EngMirrorDump 77  (BINGO) Addr:63000,Size:1000,Flag:0
EngMirrorDump 78  (BINGO) Addr:64000,Size:1000,Flag:0
EngMirrorDump 79  (BINGO) Addr:65000,Size:1000,Flag:0
EngMirrorDump 80  (COBALT) Addr:66000,Size:1000,Flag:0
EngMirrorDump 81  (COBALT_2) Addr:67000,Size:1000,Flag:0
EngMirrorDump 82  (CUMULO_2) Addr:68000,Size:1000,Flag:0
EngMirrorDump 83  (DAFIGARO) Addr:69000,Size:1000,Flag:0
EngMirrorDump 84  (ELISION_2) Addr:6a000,Size:1000,Flag:0
EngMirrorDump 85  (LUCKY) Addr:6b000,Size:1000,Flag:0
EngMirrorDump 86  (LUCKY) Addr:6c000,Size:1000,Flag:0
EngMirrorDump 87  (PEPPER) Addr:6d000,Size:1000,Flag:0
EngMirrorDump 88  (SADIRS) Addr:6e000,Size:1000,Flag:0
EngMirrorDump 89  (SIBORE) Addr:6f000,Size:1000,Flag:0
EngMirrorDump 90  (POSTER) Addr:70000,Size:1000,Flag:0
EngMirrorDump 91  (XRESON) Addr:71000,Size:1000,Flag:0
EngMirrorDump 92  (OPTIMUS_2) Addr:72000,Size:1000,Flag:0
EngMirrorDump 93  (SUB_CTL_A_0) Addr:73000,Size:1000,Flag:0
EngMirrorDump 94  (SUB_CTL_A_1) Addr:74000,Size:1000,Flag:0
EngMirrorDump 95  (SUB_CTL_A_2) Addr:75000,Size:1000,Flag:0
EngMirrorDump 96  (SUB_CTL_B_12) Addr:76000,Size:1000,Flag:0
EngMirrorDump 97  (SUB_CTL_B_3) Addr:77000,Size:1000,Flag:0
EngMirrorDump 98  (SUB_CTL_C) Addr:78000,Size:1000,Flag:0
EngMirrorDump 99  (SUB_CTL_D_13) Addr:79000,Size:1000,Flag:0
EngMirrorDump 100 (SUB_CTL_D_2) Addr:7a000,Size:1000,Flag:0
EngMirrorDump 100 (SUB_CTL_D_2) Addr:7a000,Size:1000,Flag:0
EngMirrorDump 101 (SUB_CTL_D_4) Addr:7b000,Size:1000,Flag:0
EngMirrorDump 102 (SUB_CTL_E_1) Addr:7c000,Size:1000,Flag:0
EngMirrorDump 103 (SUB_CTL_E_2) Addr:7d000,Size:1000,Flag:0
EngMirrorDump 104 (SUB_CTL_F) Addr:7e000,Size:1000,Flag:0
EngMirrorDump 105 (SUB_CTL_G) Addr:7f000,Size:1000,Flag:0
EngMirrorDump 106 (SUB_CTL_H) Addr:80000,Size:1000,Flag:0
EngMirrorDump 107 (SUB_CTL_K) Addr:81000,Size:1000,Flag:0
EngMirrorDump 108 (SUB_CTL_M) Addr:82000,Size:1000,Flag:0
EngMirrorDump 109 (ELISION_MULTI) Addr:83000,Size:1000,Flag:0
EngMirrorDump 110 (CUMULO_MULTI) Addr:84000,Size:1000,Flag:0
EngMirrorDump 111 (OPTIMUS_MULTI) Addr:85000,Size:1000,Flag:0
EngMirrorDump 112 (COBALT_MULTI) Addr:86000,Size:1000,Flag:0
EngMirrorDump 113 (ECHIZEN2_MULTI) Addr:87000,Size:1000,Flag:0
EngMirrorDump 114 (ECHIZEN3_MULTI) Addr:88000,Size:1000,Flag:0
EngMirrorDump 115 (ECHIGO2_MULTI) Addr:89000,Size:1000,Flag:0
EngMirrorDump 116 (ECHIGO3_MULTI) Addr:8a000,Size:1000,Flag:0
EngMirrorDump 116 (ECHIGO3_MULTI) Addr:8a000,Size:1000,Flag:0
EngMirrorDump 117 (LUCKY1_MULTI) Addr:8b000,Size:1000,Flag:0
EngMirrorDump 118 (LUCKY2_MULTI) Addr:8c000,Size:1000,Flag:0
EngMirrorDump 119 (LUCKY3_MULTI) Addr:8d000,Size:1000,Flag:0

If you know the name of an Engine, and want to monitor MMIO usage, this lets you find where it occurs.