Magic Lantern Forum

Magic Lantern Releases => Camera-specific discussion => Topic started by: Palpatine on September 22, 2015, 02:48:23 PM

Title: ML on EOS-M2
Post by: Palpatine on September 22, 2015, 02:48:23 PM
It's my first post so... hello guys! :)

Have anyone tried to install ML on EOS-M2?

I'm looking for a low weight camera because I want to use it with a hexacopter. EOS-M2 is surprisingly cheap on ebay and I think it has a proper quality for tasks that I'm going to do. It would be also nice to run ML on it. I know it was released only for Asian market so it's not popular, but maybe someone can assure me that it's possible to run ML without problems.

I'll be thankful for all opinions and advices :)
Title: Re: ML on EOS-M2
Post by: Walter Schulz on September 22, 2015, 05:31:23 PM
Each ML port is pretty much hardcoded for a cam and a specific firmware version. Porting ML takes a skilled programmer fluently speaking ARM processor (="maintainer") and several hundred hours of work. And at time of writing there is a lack of maintainers resulting in orphaned/blindly maintained ports.
A spare developer would come handy ...
Title: Re: ML on EOS-M2
Post by: neoplanta on September 24, 2015, 12:54:40 AM
I was asking the same on the other topic. It would be nice if someone is considering to do this to tell us :) I did not even look when I was buying eos m 2 about this, I asumed that it was the same ML for both 1 and 2.
Title: Re: ML on EOS-M2
Post by: dfort on September 24, 2015, 06:02:57 AM
I just checked up on prices and yes the M2 is priced very low but the M1 is even lower and there is a Magic Lantern port for it. According to a former M2 owner, now an M3 owner:

Dumb question, what's necessary to customize the video bitrate on the firmware? Not a programmer, but I can script.

The EOS M2 had 50mb which produced beautiful 1080P video and no audio compression which resulted in great fidelity; vs the low bit H264 and AAC that Canon throws on the EOS M3 to neuter it so it doesn't compete with pro offerings since the autofocus and software IS is good on the M3/new APS-C's. I almost want to buy another M2 (sold it once I bought the M3) since it did such a good job with video.

So if you have an M2 you might consider holding on to it even without a ML port.

The Canon EOS M3 (http://www.magiclantern.fm/forum/index.php?topic=14990.0) discussion is hinting on some serious interest in porting ML but there is no indication whether or not it has gotten off the ground yet. Though it does look like the CHDK (http://chdk.wikia.com/wiki/CHDK) project has something working with the M3 (http://chdk.wikia.com/wiki/M3). Sorry, nothing that I could find for the M2.
Title: Re: ML on EOS-M2
Post by: godashram on October 14, 2015, 01:44:25 AM
doesn't help that not a single update has been released for the M2...

My M2 would like some love as well...but coding is not my specialty :( much less figuring out if it'll run ML like the Eos M or CHDK like the M3
Title: Re: ML on EOS-M2
Post by: a1ex on October 14, 2015, 12:40:42 PM
On ExifTool website there is a hint that EOS M2 is still based on DSLR firmware (unlike M3, which is based on PowerShot firmware).

http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Canon.html

So, if anyone is tempted to port ML on it, I can prepare a dumper.
Title: Re: ML on EOS-M2
Post by: neoplanta on October 14, 2015, 05:16:14 PM
It would be great if somone would do this. I know this is a dumb question, but I am pretty much idiot when it comes to coding, is it posible to install eos m 1 firmware to eos m 2, or just make focus peaking option somehow on eos m 2?
Title: Re: ML on EOS-M2
Post by: godashram on October 14, 2015, 05:57:41 PM
A1ex, you prep a dumper, i'll dump mine as soon as it's up (well, after driving home to grab the M2)

granted, the most I could do after that is try out builds, my code-fu is non-existent :(
Title: Re: ML on EOS-M2
Post by: a1ex on October 14, 2015, 06:31:15 PM
Alright, here you go:

- the portable display test: hello-M2.fir (http://a1ex.magiclantern.fm/debug/portable-hello-world/EOSM2/hello-M2.fir)

- the ROM dumper: dumperM2.fir (http://a1ex.magiclantern.fm/bleeding-edge/blind-dumper/dumperM2.fir)

It dumps 32 MB from 0xF7000000, which covers both ROM0 and ROM1 - that's what you need to run ML in QEMU. For analyzing the code, you can load ROM1 (the second half of that file) at 0xFF000000.

Usage: run firmware update, then go to play mode (make sure you have an image there), then look on your card. Keep the dump for yourself, do not publish it online.

edit: dumper confirmed working by @godashram :)
Title: Re: ML on EOS-M2
Post by: Licaon_Kter on October 15, 2015, 10:44:10 AM
Interesting.
Title: Re: ML on EOS-M2
Post by: vyskocil on October 15, 2015, 01:26:51 PM
Great, new gears ! Is it possible to have the same for the 7D mkII to start looking at a port ? Perhaps the dumper is not needed as we already have a fir upgrade available but then could you point out the steps to lookup the keys and decrypt the firmware ?
Thanks in advance!
Title: Re: ML on EOS-M2
Post by: godashram on October 15, 2015, 07:19:50 PM
wouldn't it make more sense to start a new thread for the 7D MKII instead of posting the question here??
Title: Re: ML on EOS-M2
Post by: glassescreditsroll on October 19, 2015, 09:15:54 AM
does this mean we could start  porting ml to eos m2?
Title: Re: ML on EOS-M2
Post by: godashram on October 20, 2015, 12:57:29 AM
I hope it does.... I've heard nothing since giving A1ex the M2 dump. Guess the biggest issue would be finding someone to actively work on an M2 build?
Title: Re: ML on EOS-M2
Post by: a1ex on November 01, 2015, 07:08:36 PM
does this mean we could start porting ml to eos m2?

Correct. The M2 looks very similar to the original M, so I don't expect any real difficulties here.

Guess the biggest issue would be finding someone to actively work on an M2 build?

Correct.
Title: Re: ML on EOS-M2
Post by: glassescreditsroll on November 06, 2015, 04:50:30 AM
So what needs to be done now? I have an eos m2 and would love to be able to use ML on it I'll do anything I can to help
Title: Re: ML on EOS-M2
Post by: Audionut on November 06, 2015, 06:08:50 AM
Guess the biggest issue would be finding someone to actively work on an M2 build?

Correct.

Current developers are happy to help.  But there needs to be someone else to take on the bulk of the development work.
Title: Re: ML on EOS-M2
Post by: godashram on November 10, 2015, 05:42:11 PM
Current developers are happy to help.  But there needs to be someone else to take on the bulk of the development work.

and that is where the issue is.... I don't have the patience for development, and well, not many M2's seem to be in the hands of people that would care (my opinion).

to be honest, I'd be happy with just the continuous recording feature :)
Title: Re: ML on EOS-M2
Post by: neoplanta on November 10, 2015, 06:39:44 PM
And I would be happy only with focus peaking option  :D It is too bad that m2 is not wide spread as other cameras, and it is waste that there are people who are willing to help, but unfortunetly there are not many people who know coding to take the bulk of the development work.
Title: Re: ML on EOS-M2
Post by: godashram on November 10, 2015, 10:20:08 PM
well, it's lack of availability outside of Japan and China and the eos m fire sales didn't help the m2 in any way at all.
Title: Re: ML on EOS-M2
Post by: GenMeiHikaru on December 16, 2015, 04:26:22 PM
Just bought a EOS M2 kit (+ a EF-M 22mm and a 18-55mm) with a kinda low price in Japan, just about $285. Seems like the only thing missing is ML firmware, coding is also a no-go for me but I'll be glad to be of any help. Thanks...!
Title: Re: ML on EOS-M2
Post by: neoplanta on December 16, 2015, 06:57:43 PM
Wow, thats prety cheap. I bought mine for about 280 dolars, without lens.
Title: Re: ML on EOS-M2
Post by: godashram on December 16, 2015, 07:32:08 PM
WOW, for $285 with 2 lenses is NUTS! it's a great camera... but hunting down someone to work on it isn't easy :(
Title: Re: ML on EOS-M2
Post by: GenMeiHikaru on December 17, 2015, 03:25:31 PM
Surprisingly it's not just the lens, the EF-EOS M -> EF-S adapter and a 90EX flash are also included in the package.
If u guys still want the link, it's here
http://www.amazon.co.jp/gp/product/B00H2ABRKS/ref=gbps_img_s-3_0229_0fa1bf1e?smid=AN1VRQENFRJN5&pf_rd_p=264150229&pf_rd_s=slot-3&pf_rd_t=701&pf_rd_i=gb_main&pf_rd_m=AN1VRQENFRJN5&pf_rd_r=1F660AF0S908GYXQ8A9F
It's Amazon for Japan so i'm not sure if it's available for shipment outside of Japan though... I bought it with a Lightning Deal (¥34800~$285), but without the deal it's ¥40498(~$330), still very affordable (I think)...
Edit: on sale again...
Title: Re: ML on EOS-M2
Post by: godashram on December 18, 2015, 02:22:18 AM
fulfilled by amazon.... so maybe...
Title: Re: ML on EOS-M2
Post by: jonkjon on December 18, 2015, 04:49:45 PM
Is this something that needs to be built from scratch or is there something to build from? I have some c experience (mostly windoze) and i'd be willing to take a look. I have perused the getting started stuff but it pretty much just shows how to setup a compiler etc. I haven't looked at the source code at all.

--Jon
Title: Re: ML on EOS-M2
Post by: godashram on December 18, 2015, 05:55:28 PM
the m2 was dumped (a1ex has the dump I made)

from there, i guess it would be a port of the existing build, beyond that, no clue.
Title: Re: ML on EOS-M2
Post by: Walter Schulz on December 18, 2015, 06:37:09 PM
What you are looking for is a maintainer. Someone knowing C, assembler programming embedded devices (preferable ARM architecture) and willing and able to spend several hundred hours of his/her time in porting ML to M2. And don't expect any of the devs asking for that additional workload. They will support this maintainer-to-be, of course.
Title: Re: ML on EOS-M2
Post by: bender on March 06, 2016, 10:16:17 AM
any updates for the M2?  :)
Title: Re: ML on EOS-M2
Post by: brocolimayo on March 15, 2016, 08:10:19 PM
same question :) my programming skills are almost zero, but I'd love to help, I own a m2 too, and would be wonderful to have ml on it :)
Title: Re: ML on EOS-M2
Post by: godashram on March 16, 2016, 06:54:44 AM
nope, as far as I know, there isn't anyone willing to work on it.
Title: Re: ML on EOS-M2
Post by: Skylin3 on March 16, 2017, 11:31:14 PM
Bump. Is there any progress with m2? I can help with testing ML, I have m2.
Title: Re: ML on EOS-M2
Post by: dfort on May 24, 2017, 05:50:16 AM
Got one.

(https://c1.staticflickr.com/5/4227/34014053584_75ea69bf64_z.jpg)

Not sure if I'm ready for this but I was going to quietly work on Magic Lantern for the EOSM2. Seems like this one should be one of the "easier" ports.

Then I thought, that's no way to work on an open source project, let's get this out there in the open. My first stumbling block is setting the boot flag on the camera. How to do this without bricking the camera? Tried searching for the answer and it looks like there is already a working .FIR file for this camera -- so how can I get my hands on it?
Title: Re: ML on EOS-M2
Post by: a1ex on May 24, 2017, 09:43:20 AM
Seems like this one should be one of the "easier" ports.

Definitely, as it's plain DIGIC 5 (unlike 1300D, which looks like a mix between D4, 5 and 6).

The boot flag is "traditionally" enabled after getting the Hello World working. There are two flavors: the minimal target (which requires a tiny set of stubs and only compiles a few small files) and the regular one (CONFIG_HELLO_WORLD in the full source code, which also requires file I/O for loading fonts, and a bunch of other initializations). Once the second version is working, CONFIG_DUMPER_BOOTFLAG will be straightforward to compile and run. The "user-friendly" installer comes a bit later, as it requires some more stubs.

The boot flag can be also enabled earlier, from the bootloader context; we did that on the DIGIC 2 and 3 models, blindly (without having the display available for debugging or user feedback). Now that we have display access from bootloader, that's a valid option as well (though I wasn't comfortable doing this step on 7D Mark II).

Until enabling the boot flag, you'll need my assistance to run a binary on the camera. You can run them in QEMU though, by setting "boot=1" though.

Will explain how to get the Hello World on models that don't boot to Canon GUI on the 1300D thread, as it was covered on IRC a few days ago.
Title: Re: ML on EOS-M2
Post by: a1ex on May 24, 2017, 12:17:11 PM
I'll start with a walkthrough using latest QEMU and IDA. First step is to assume it's very similar to EOSM, so after installing QEMU (http://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-tests/lastSuccessfulBuild/console), head over to qemu/qemu-2.5.0/hw/eos/model_list.c and copy the basic entries from the section for EOSM:

Code: [Select]
    {
        .name                   = "EOSM2",
        .digic_version          = 5,
     }

The others are likely model-specific, so let's not assume too much from the beginning. Let's try:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0"
...
FFFF3F50: MCR p15,0,Rd,cr6,cr0,0:  946_PRBS0 <- 0x3F       (00000000 - FFFFFFFF, 0x100000000)
FFFF3F58: MCR p15,0,Rd,cr6,cr1,0:  946_PRBS1 <- 0x3D       (00000000 - 7FFFFFFF, 0x80000000)
FFFF3F60: MCR p15,0,Rd,cr6,cr2,0:  946_PRBS2 <- 0xE0000039 (E0000000 - FFFFFFFF, 0x20000000)
FFFF3F68: MCR p15,0,Rd,cr6,cr3,0:  946_PRBS3 <- 0xC0000039 (C0000000 - DFFFFFFF, 0x20000000)
FFFF3F70: MCR p15,0,Rd,cr6,cr4,0:  946_PRBS4 <- 0xFF00002F (FF000000 - FFFFFFFF, 0x1000000)
FFFF3F78: MCR p15,0,Rd,cr6,cr5,0:  946_PRBS5 <- 0x37       (00000000 - 0FFFFFFF, 0x10000000)
FFFF3F80: MCR p15,0,Rd,cr6,cr6,0:  946_PRBS6 <- 0xF700002F (F7000000 - F7FFFFFF, 0x1000000)
...
K355 READY
128K Sector FROM From BL 0xffff
[SF] InstallSerialFlash 6 0xc022c0d4 0x0 0x1000000 1
...
K355 ICU Firmware Version 1.0.2 ( 6.0.5 )

OK, so we've got a rough idea about its memory map (same as other DIGIC 4 and 5 models). We also noticed it has a serial flash of size 0x1000000. This is similar to 100D (lookup serial_flash_size in model_list.c), so it may be a good idea to reuse the serial flash data from this model:
Code: [Select]
        .serial_flash_size      = 0x1000000,

Unfortunately, this step doesn't change anything in the emulation. Let's look at the next messages:
Code: [Select]
...
    10:    46.336 [PROPAD] ERROR Not Exist Valid ComboPackages!! 0x10000
...
    14:    56.576 [STARTUP] InitializeIntercom
...
    42:   722.688 ERROR [DL] ########## DL ERROR!!!!! ###########

- Many errors regarding missing properties. These are either stored in ROM, or in the serial flash, or they come from the MPU. The ones from ROM should not pose any problems, since we have the complete ROM. For the others, we did not see any sign of activity, so we have to dig in to find out whether anything is different (usually these communication channels may use different registers, depending on model, but overall the communication protocol is the same).

- DL ERROR: if you look in EOSM/debugmsg.gdb, you'll find a way to get past this message (by skipping the initialization of "DL", whatever that is).

- The debug messages are not very informative. To get more insights, find out a few essential functions (such as task_create and DebugMsg) and place them in EOSM2/debugmsg.gdb (look at other models for how the declarations should look like).

OK, so at this point we have to disassemble the firmware. If you use IDA, the initial steps would be:
- load ROM1.BIN
- select ARM processor, architecture ARMv5TEJ (we have ARMv5TE on all models from DIGIC 2 to DIGIC 5)
- uncheck 'Delete instructions with no xrefs' (we have plenty of those)
- uncheck 'Perform no-return analysis' (IDA usually gets it wrong)
- RAM section: 0, size 0x100000 (we can always add more later)
- ROM start address: 0xFF000000
- ROM size: 0xFFFFFC (off-by-one bug in IDA; I have an older version, so YMMV)
- File load address / size: same as ROM.

Now that our binary is loaded, go to 0xFFFF0000 and press "c" to mark this as code. This is the bootloader start address (aka HIVECS in ARM documentation). Next step is to find where the main firmware starts (where the code path leaves the bootloader). It's easy to assume similarity with other models, but let's try to find it from scratch (just to show off the latest QEMU tool):

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d calls
...
call 0xFFFF0FCC(0, ffffdfff, 2000, ffff0b20)                                     at [ffff09c8:0]
 call 0x100000(0, 11836c, 11836c, 100000)                                        at [ffff1010:ffff09cc]
...

OK, so the bootloader runs from RAM.

Where does the bootloader end? When it stops executing from its address range (near 0xFFFF0000 or 0x100000):

Code: [Select]
  return 0 to 0x10013C                                                           at [1022f4:ffff1014]
 return 1 to 0xFFFF1014                                                          at [1000bc:ffff09cc]
return 0 to 0xFFFF09CC                                                           at [ffff101c:0]
Warning: R10 not restored (0xa -> 0x1)                                           at [ffff101c:ffff09cc]
PC jump? 0xF80C0000 lr=ffff09cc                                                  at [ffff0a04:ffff09cc]
0xffff0a04:  e1a0f000      mov pc, r0
PC jump? 0xFF0C000C lr=ffff09cc                                                  at [f80c0000:ffff09cc]
0xf80c0000:  e59ff0c4      ldr pc, [pc, #196] ; 0xfffffffff80c00cc

Ta-da! Same as other DIGIC 5 models: ROM1 startup code is at 0xF80C0000, but code from main firmware expects to run from a mirror copy (details) (https://www.magiclantern.fm/forum/index.php?topic=6785.msg58899#msg58899). So, our ROMBASEADDR is 0xFF0C0000.

Let's go there in IDA and mark this section as code. At this point, IDA already recognized a few functions, but let's get some more from the QEMU execution trace:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d idc
...
EOSM2.idc saved.

Now load this IDC script into IDA, or convert it for your favorite disassembler, and start looking at the functions called during the execution in QEMU:
Code: [Select]
PC jump? 0xFF0C000C lr=ffff09cc                                                  at [f80c0000:ffff09cc]
...
call 0xFF0C1BD4(1000, 698, eeeeeeee, 1000)                                       at [ff0c0dbc:0]
 call 0x866B4(f88, 74, eeeeeeee, 1000)                                           at [ff0c1be4:ff0c0dc0]
 return ffc to 0xFF0C1BE8                                                        at [866f4:ff0c0dc0]
 call 0x3168(f88, ff0c57a4, 0, 0)                                                at [ff0c1c80:ff0c0dc0]
...

0xFF0C1BD4 is cstart, 0x866B4 is bzero32, 0x3168 must be create_init_task and 0xFF0C57A4 must be init_task. Some of these functions are called from RAM, so we'll have to identify where its contents come from (what is copied where). TODO.

Next step, for the emulation, would be to find the MPU registers (near InitializeIntercom), mpu_send/mpu_recv stubs may also help, and we also need to check the serial flash communication.

For executing user code on the camera, next step would be to reserve memory for our application. This is usually done by shrinking the "malloc" buffer. Take a look at boot-hack.c from the "qemu" branch (as it's a bit more verbose and better explained). These debug messages can be seen on the QEMU-boot-check (http://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-boot-check/) page.

To be continued.
Title: Re: ML on EOS-M2
Post by: dfort on May 24, 2017, 06:19:03 PM
Wow.

Let's take half a step back before embarking on this journey. When I posted my intent to attempt this port I skipped one important step before asking for a firmware dumper--check to see if there is already one available. The list of available ROM dumpers are listed at the bottom of the Magic Lantern Nightly Builds (https://builds.magiclantern.fm/) page. The one for the EOSM2 point to a post on this topic (http://www.magiclantern.fm/forum/index.php?topic=15895.msg155455#msg155455) with the links to download the dumpers.

It appears that the EOSM2 ROM was first dumped about 1.5 years ago. I'm assuming that it was the original firmware version. The camera I got has 1.0.2 installed and 1.0.3 is available. My question is, should I try to make a dump of 1.0.2 before updating the firmware or does it matter? Maybe the dumpers won't work with 1.0.3? Maybe we should archive a 1.0.2 dump before starting? The 1.0.3 firmware update is a minor fix that Canon released for most of their cameras to deal with this issue:
Quote
Corrects a phenomenon in which when using the camera with the EF-S 18-135mm f/3.5-5.6 IS USM or EF 70-300mm f/4-5.6 IS II USM lens, even if lens aberration correction is set to "Enable", correction will not be applied.

[EDIT]

hello-M2.fir (http://a1ex.magiclantern.fm/debug/portable-hello-world/EOSM2/hello-M2.fir) running on EOSM.102
(https://c1.staticflickr.com/5/4200/34481675560_77a17b04d7_z.jpg)

However, dumperM2.fir (http://a1ex.magiclantern.fm/bleeding-edge/blind-dumper/dumperM2.fir) doesn't dump the ROM. I tried various cards including an old 2GB card that has worked on all the other ROM dumps I made.
Title: Re: ML on EOS-M2
Post by: a1ex on May 24, 2017, 09:23:14 PM
The dumper linked above runs on the main firmware (in contrast with the portable ROM dumper, which runs from bootloader), so it has no issues with card sizes, but it's limited to DIGIC 4 and 5 models. Does it help if you follow the instructions in the linked post? (it's different from the portable dumper you are used to)

You can start from the latest firmware.
Title: Re: ML on EOS-M2
Post by: dfort on May 24, 2017, 10:40:55 PM
Does it help if you follow the instructions in the linked post?

Doh!

The single file dump is named "(NULL)" on the sd card and it is 33.6 MB. I also updated the firmware to 1.0.3 though I also dumped 1.0.2 just to have it.

Did the change to model_list.c and tried running qemu but it stopped on:
Code: [Select]
eos_load_image: file not found './EOSM2/ROM0.BIN'
./run_canon_fw.sh: line 35: 16058 Abort trap: 6           $QEMU_PATH/arm-softmmu/qemu-system-arm -drive if=sd,format=raw,file=sd.img -drive if=ide,format=raw,file=cf.img -M $*

So I renamed (NULL) to ROM0.BIN then it stopped on "file not found './EOSM2/ROM1.BIN'" but since the dumper only creates the one file I'm afraid I hit another wall.

It dumps 32 MB from 0xF7000000, which covers both ROM0 and ROM1 - that's what you need to run ML in QEMU. For analyzing the code, you can load ROM1 (the second half of that file) at 0xFF000000.

I'm searching how to run ML in QEMU with a single file dump but so far I can't find an answer.

Title: Re: ML on EOS-M2
Post by: a1ex on May 24, 2017, 11:15:20 PM
Split it in two halves: first ROM0, second ROM1.

Back then, it was much easier to patch Canon code to dump everything in one file, so it covers both ROMs. For this reason, older QEMU versions used to require the ROMs to be joined like this (but it was changed to allow using the backup ROM copies already saved by ML on the cards under ML/LOGS, and to allow more unusual ROM configurations).
Title: Re: ML on EOS-M2
Post by: dfort on May 25, 2017, 01:23:00 AM
Making some progress. Mac uses the BSD version of split which doesn't have the -n option but I was able to split the dump in two like this:
Code: [Select]
split -b 16800000 "(NULL)" ROM
That gave me two files, ROMaa and ROMab which I renamed ROM0.BIN and ROM1.BIN and placed in ~/qemu/EOSM2 then ran:
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0"
./run_canon_fw.sh: line 10: losetup: command not found
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when]
[--context[=num]] [--directories=action] [--label] [--line-buffered]
[--null] [pattern] [file ...]
./run_canon_fw.sh: line 10: losetup: command not found
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when]
[--context[=num]] [--directories=action] [--label] [--line-buffered]
[--null] [pattern] [file ...]
CHK version_gen.h
Lockdown read 0
Lockdown read 0
Lockdown read 1
Lockdown read 1
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 1FFFFFFF: eos.ram
40001000 - 5FFFFFFF: eos.ram_uncached
F0000000 - F0FFFFFF: eos.rom0
F1000000 - F1FFFFFF: eos.rom0_mirror
F2000000 - F2FFFFFF: eos.rom0_mirror
F3000000 - F3FFFFFF: eos.rom0_mirror
F4000000 - F4FFFFFF: eos.rom0_mirror
F5000000 - F5FFFFFF: eos.rom0_mirror
F6000000 - F6FFFFFF: eos.rom0_mirror
F7000000 - F7FFFFFF: eos.rom0_mirror
F8000000 - F8FFFFFF: eos.rom1
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
C0000000 - DFFFFFFF: eos.iomem
[EOS] loading './EOSM2/ROM0.BIN' to 0xF0000000-0xF0FFFFFF
[EOS] loading './EOSM2/ROM1.BIN' to 0xF8000000-0xF8FFA6FF
[MPU] FIXME: no MPU spells for EOSM2.
[MPU] FIXME: no MPU button codes for EOSM2.
Setting BOOTDISK flag to 0

It looks like this:

(https://c1.staticflickr.com/5/4221/34833502446_a6c5cf5e35_z.jpg)

QEMU didn't crash but it also isn't displaying the output from the minimal qemu autoexec.bin.
Title: Re: ML on EOS-M2
Post by: dfort on May 25, 2017, 05:02:25 AM
Took some more baby steps. First a fall.
OK, so we've got a rough idea about its memory map (same as other DIGIC 4 models). We also noticed it has a serial flash of size 0x1000000. This is similar to 100D (lookup serial_flash_size in model_list.c), so it may be a good idea to reuse the serial flash data from this model:
Code: [Select]
        .serial_flash_size      = 0x1000000,

All that did was to consistently give me this error when running QEMU:

Code: [Select]
[EOS] loading './EOSM2/ROM0.BIN' to 0xF0000000-0xF0FFFFFF
[EOS] loading './EOSM2/ROM1.BIN' to 0xF8000000-0xF8FFA6FF
Could not open ./EOSM2/SFDATA.BIN

I don't have IDA but I do have ARM-console (http://magiclantern.wikia.com/wiki/GPL_Tools/ARM_console) and the good old reliable disassemble.pl from the finding stubs tutorial (http://www.magiclantern.fm/forum/index.php?topic=12177.msg117735#msg117735). So I took another baby step and tried to disassembly the ROM1.BIN that was split off the single file dumperM2.fir dump. I ran the usual "perl disassemble.pl 0xFF000000 ROM1.BIN" but something looked wrong.

Code: [Select]
ff0ba700: e59ff0c4 ldr pc, [pc, #196] ; ff0ba7cc: (ff0c000c)
"gaonisoy":

All indications are that it should be more like the EOSM and 700D and start on 0xFF0C0000 so I did a second disassemble, "perl disassemble.pl 0xFF005900 ROM1.BIN"

Code: [Select]
ff0c0000: e59ff0c4 ldr pc, [pc, #196] ; ff0c00cc: (ff0c000c)
"gaonisoy":

Now it "looks" right. Well, "looks" is mostly what I'm going on right now. I don't really know what I'm doing. That weird offset might be a result of splitting the dump in two? The EOSM2 "looks" like a combination of the EOSM, 100D with wifi features added on. This means that I should be able to find some stubs using the pattern matching method I used for the minor firmware updates. Of course porting a new camera is certainly not a minor undertaking!

I want to continue getting QEMU working properly on the Mac and figure things out the "right" way but now that I've got a disassembly at least I'm on familiar territory so do you think I'm at the stage where I can start hunting down some stubs?
Title: Re: ML on EOS-M2
Post by: a1ex on May 25, 2017, 08:40:40 AM
You need two *equal* halves, without any approximation.

(edit: updated QEMU to give better warnings in this case)

SFDUMP.BIN can probably be used from 700D or EOSM as well, but these cameras have a smaller size. Padding it with zeros may or may not work. How to get it? It's covered in QEMU's install script.
Title: Re: ML on EOS-M2
Post by: dfort on May 26, 2017, 08:36:33 AM
You need two *equal* halves, without any approximation.

(edit: updated QEMU to give better warnings in this case)

Yeah, that seems to be a problem. "split -b 16800000 "(NULL)" ROM" produced two files that aren't exactly equal. I'll keep up with the QEMU branch commits on this project.

Code: [Select]
-rw-r--r--   1 rosiefort  staff  16800000 May 24 15:15 ROM0.BIN
-rw-r--r--   1 rosiefort  staff  16754432 May 24 15:15 ROM1.BIN

[EDIT] Looks like the lesson learned here is not to trust the finder because it rounds KB to MB.

(https://c1.staticflickr.com/5/4248/34063971594_70bf4993c9.jpg)

I might be able to get SFDUMP.BIN from a 100D.
Title: Re: ML on EOS-M2
Post by: dfort on May 26, 2017, 07:09:10 PM
The equal split did the trick. Now I'm seeing the messages a1ex posted back on Reply #34 (http://www.magiclantern.fm/forum/index.php?topic=15895.msg185103#msg185103). Also made a new disassembly and it looks good so I'll start hunting for stubs.

To be continued.

Looking forward to it!
Title: Re: ML on EOS-M2
Post by: a1ex on May 26, 2017, 11:09:39 PM
Alright, so let's start from where we've left off.

0xFF0C1BD4 is cstart, 0x866B4 is bzero32, 0x3168 must be create_init_task and 0xFF0C57A4 must be init_task. Some of these functions are called from RAM, so we'll have to identify where its contents come from (what is copied where). TODO.

Since the ROMs are placed at some high address (after 0xF0000000), and we've noticed some functions called outside this range, a good guess would be that some of the functions may be copied from ROM to RAM during startup. Let's examine the memory access patterns. We are interested in some code that reads from ROM and writes to RAM. If you have no trouble following the assembly code for the startup sequence, you'll spot this piece of code right away. Otherwise, let's ask for some help from QEMU:

Running QEMU with -d help gives, among many other options:
Code: [Select]
ram        EOS: log all RAM reads and writes
rom        EOS: log all ROM reads and writes
ramr       EOS: log all RAM reads
romr       EOS: log all ROM reads
ramw       EOS: log all RAM writes
romw       EOS: log all ROM writes

We could try romr,ramw (or rom,ram if you don't mind a little more verbosity):
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d romr,ramw

The log is huge, but if you scroll around, there are some large blocks that look similar. Some of them are clearly a copying operation (read some value from ROM, write it to RAM). One of these covers the functions we are interested in:
Code: [Select]
[rom1]     at 0xFF0C000C:FFFF09CC [0xFFD1F02C] -> 0xE92D4010
[ram]      at 0xFF0C000C:FFFF09CC [0x00001900] <- 0xE92D4010: was 0x0;
[rom1]     at 0xFF0C00A4:FFFF09CC [0xFFD1F030] -> 0xE1A04001
[ram]      at 0xFF0C00A4:FFFF09CC [0x00001904] <- 0xE1A04001: was 0x0;
[rom1]     at 0xFF0C00A4:FFFF09CC [0xFFD1F034] -> 0xE59F1040
...
[rom1]     at 0xFF0C00A4:FFFF09CC [0xFFDD60C8] -> 0xFFD1EFFC
[ram]      at 0xFF0C00A4:FFFF09CC [0x000B899C] <- 0xFFD1EFFC: was 0x0;

In other words, a memory block from 0xFFD1F02C to 0xFFDD60C8 (actually 0xFFDD60CB, since we are looking at 32-bit operations) is copied to 0x1900 - 0xB899F. The size of the copied block is 0xb70a0 bytes. To extract this block, grab the terminal and run this under a Bash prompt:

Code: [Select]
dd if=ROM1.BIN of=1900.BIN bs=1 skip=$((0xD1F02C)) count=$((0xB70A0))

(please note the above numbers are only valid for firmware 1.0.2)

Now you can disassemble this file starting from 0x1900. In IDA, load this file as Additional binary file. If you use ARM-console, this should auto-detect the above copying operation (so you can simply start browsing the functions copied into RAM).

There are other similar blocks copied into RAM (newer DIGIC 6 and 7 models have plenty of those), and finding them manually can become tedious, so it's a good candidate for automation.

One of these blocks is the interrupt handler routine. On ARM, hardware interrupts are executed from address 0x18 (see e.g. ARM ARM - A2.6 - Exceptions (https://www.scss.tcd.ie/~waldroj/3d1/arm_arm.pdf#G6.1052026) or these slides (http://osnet.cs.nchu.edu.tw/powpoint/Embedded94_1/Chapter%207%20ARM%20Exceptions.pdf)). That means, we should expect to find some code that writes something to address 0x18 (that can be anywhere in the boot process before enabling interrupts), and on EOS firmwares, at this address you'll find a jump to 0x4B0 on many models, or something close on others. Let's examine it in GDB:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S & arm-none-eabi-gdb -x debug-logging.gdb
(note: we will need to create a GDB file for EOS M2, named EOSM2/debugmsg.gdb to match other models, but since we don't have one yet, we can just use the generic version - which we are going to include in the platform-specific file later)

Let it run for a while (continue), then hit CTRL-C and examine the exception vector (located at address 0):

Code: [Select]
(gdb) disas 0,0x40
Dump of assembler code from 0x0 to 0x40:
   0x00000000: nop ; (mov r0, r0)
   0x00000004: ldr pc, [pc, #20] ; 0x20
   0x00000008: ldr pc, [pc, #20] ; 0x24
   0x0000000c: ldr pc, [pc, #20] ; 0x28
   0x00000010: ldr pc, [pc, #20] ; 0x2c
   0x00000014: nop ; (mov r0, r0)
   0x00000018: ldr pc, [pc, #16] ; 0x30
   0x0000001c: ldr pc, [pc, #16] ; 0x34
   0x00000020: ; <UNDEFINED> instruction: 0xff0c0fec
   0x00000024: ; <UNDEFINED> instruction: 0xff0c105c
   0x00000028: ; <UNDEFINED> instruction: 0xff0c1000
   0x0000002c: ; <UNDEFINED> instruction: 0xff0c1018
   0x00000030: ; <UNDEFINED> instruction: 0x000004b0
   0x00000034: ; <UNDEFINED> instruction: 0xff0c1060
   0x00000038: ; <UNDEFINED> instruction: 0xffff0b08
   0x0000003c: ; <UNDEFINED> instruction: 0xffff0b20

That means, once a hardware interrupt happens (in other words, some device wants to tell the main CPU that it needs attention), the program counter will jump to 0x18, and there it will find a LDR PC, =0x4B0. That's where Canon's interrupt handler is located. Let's find its contents:

- Method 1: scan the memory access log for a copy operation that covers 0x4B0 and above. Easy to find.

- Method 2: disassemble it directly from GDB. How much? 0x1900 - 0x4B0 would be the upper limit (since we already know what's at 0x1900). The interrupt handler is much smaller than that - 512 bytes are more than enough:
Code: [Select]
disas 0x4B0,0x6B0

Method 3: dump the memory from gdb:
Code: [Select]
(gdb) dump memory 4B0.BIN 0x4B0 0x6B0

Method 4: dump the memory from QEMU monitor (https://qemu.weilnetz.de/doc/qemu-doc.html#pcsys_005fmonitor):
Code: [Select]
(qemu) memsave 0x4B0 0x200 4B0.BIN

For the debugmsg.gdb file, we'll need some basic stubs: DebugMsg and task_create (easy to find - one is used for most debug messages, the other can be easily identified from things that look like task names) and two addresses: CURRENT_TASK and CURRENT_ISR (interrupt service routine). We can find the latter in the interrupt handler - quote from debugmsg.gdb:
Quote
# CURRENT_ISR:
#   From interrupt handler (PC=0x18), find an expression that evaluates to
#   the current interrupt ID if any is running, or 0 if a normal task is running.
#   - on DIGIC 4/5, interrupt ID is MEM(0xC0201004) >> 2
#   - on DIGIC 6,   interrupt ID is MEM(0xD4011000)

If you can find that by examining disassembled code, great. If not, QEMU to the rescue:
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d io,int,nochain -singlestep
...
Taking exception 5 [IRQ]
[INT]      at 0x00000510:0000050C [0xC0201004] -> 0x28      : Requested int reason 28 (INT 0Ah)
[INT]      at 0x00000594:00000568 [0xC0201010] <- 0xA       : Enabled interrupt 0Ah

(note: -d nochain -singlestep gives more precise locations in I/O logs - otherwise, QEMU groups the ARM instructions in blocks for faster execution, so the reported location will be approximate)

OK, so the register we are looking for is read at 0x510. Let's disassemble with GDB:
Code: [Select]
(gdb) disas 0x4B0,0x6B0
...
   0x0000050c: ldr r0, [pc, #368] ; 0x684
   0x00000510: ldr r4, [r0]
   0x00000514: str r4, [pc, #304] ; 0x64c
...
(gdb) x 0x684
0x684: 0xc0201004
(gdb) x 0x64c
0x64c: 0x00000028
(gdb) print 0x28>>2
$1 = 0xa

The register we are looking for is loaded in R0, then the interrupt handler reads from this register (result in R4) and stores its value at 0x64C. If you check the memory contents at this address, you'll find 0x28. The interrupt ID would be 0x28 >> 2 = 0x0A, which is DryOS timer interrupt (which fires every 10ms and is used for the task switch - see e.g. FreeRTOS Tick (http://www.learnitmakeit.com/freertos-tick/) for some background info).

Note: ARM has a generic hardware interrupt (PC jumping at 0x18), but in an embedded system we usually have more devices that can trigger an interrupt. To tell which device needs attention, it's helpful to identify these devices somehow - and an interrupt ID is used for that. On EOS, there is a custom interrupt controller, and on DIGIC 4 and 5 models, the register used for identifying the interrupt ID is 0xC0201004. The interrupt ID is hardwired to the device that triggers it (for example, SIO3 and MREQ, which are used for MPU communication, always use interrupts 0x36 and 0x50). This mapping can change across models, but usually it's consistent (at least within the same generation of models). Probably g3gg0 can explain these concepts a bit better, as he identified all this stuff a few years ago (http://www.magiclantern.fm/forum/index.php?topic=2882.0), when I was mostly clueless about how these things work.

OK, so the memory contents at 0x64C can tell us about the interrupt currently handled. There's a problem - this address is not cleared when the interrupt handler is done, so, just by looking at it, we can't tell whether the code is servicing an interrupt or running a regular task. We'll need to look at some other address - and in many cases the previous address is a good candidate:
Code: [Select]
   0x000004d4: ldr r1, [pc, #364] ; 0x648
   0x000004d8: cmp r1, #0
   0x000004dc: add r1, r1, #1
   0x000004e0: str r1, [pc, #352] ; 0x648
   ...
   0x00000598: ldr r1, [pc, #168] ; 0x648
   0x0000059c: sub r1, r1, #1
   0x000005a0: str r1, [pc, #160] ; 0x648

This 0x648 looks like a counter that tells how many nested interrupts we are handling (yes, they can be nested - unfortunately, as this makes it a lot harder to understand, debug, emulate and so on). Let's confirm its functionality with RAM tracing:
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d io,int,ram,nochain -singlestep
...
[tcm_code] at 0x000004D4:19980218 [0x00000648] -> 0x0       
[tcm_code] at 0x000004E0:19980218 [0x00000648] <- 0x1       : was 0x0;
...
[tcm_code] at 0x0000050C:0000050C [0x00000684] -> 0xC0201004
[INT]      at 0x00000510:0000050C [0xC0201004] -> 0x28      : Requested int reason 28 (INT 0Ah)
[tcm_code] at 0x00000514:0000050C [0x0000064C] <- 0x28      : was 0x0;
...
[INT]      at 0x00000594:00000568 [0xC0201010] <- 0xA       : Enabled interrupt 0Ah
[tcm_code] at 0x00000598:00000568 [0x00000648] -> 0x1       
[tcm_code] at 0x000005A0:00000568 [0x00000648] <- 0x0       : was 0x1;

Looks right!

Note: "Enabled interrupt 0Ah" means the interrupt routine finished handling it, so the same interrupt can be triggered again from now on (you can't have the same interrupt nested with itself). The same register configuration happens when an interrupt is enabled for the first time, and that's why the message reads "enabled interrupt". Might be a bit confusing at first sight.

Now that we know what 0x648 does, let's use it as boolean (0 = regular task, nonzero = handling some interrupt):
Code: [Select]
macro define CURRENT_ISR  (*(int*)0x648 ? (*(int*)0x64C) >> 2 : 0)

Next is CURRENT_TASK. One way to find that is by pattern matching in task_create and its subroutines.

I'll try an alternate method, based on one of the recent addition to QEMU: the ability to track function calls and returns. From the ARM calling convention (AAPCS (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf), or the summary from wikipedia (https://en.wikipedia.org/wiki/Calling_convention#ARM_.28A32.29)), you'll notice that registers R4-R11 are supposed to be unchanged after a function call. When tracking function calls, the logging code checks this assumption as well, and will print lots of warnings if a task switch happens without the logger knowing about it. Let's use these warnings to narrow down the location where DryOS switches between tasks:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d callstack,ramw

The log is huge, but we are going to look for some warnings about registers (run with only -d callstack to see them without the clutter from RAM writes). These warnings are likely caused by some memory writes performed just before the warnings. We are looking for some invariant address (one that doesn't change with the warnings):
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d callstack,ramw |& grep -B 20 "not restored"
...
[ram]      at 0x000019D8:0000E24C [0x0018F8FC] <- 0xE24C    : was 0xE24C;
[ram]      at 0x00001A04:0000E24C [0x0008FBCC] <- 0x17EED4  : was 0x17EF28;
[ram]      at 0xFF0C1064:0000E24C [0x0018F8FC] <- 0xE24C    : was 0xE24C;
...
[ram]      at 0xFF0C1074:0000E24C [0x0018F8C0] <- 0x60000093: was 0x19980218;
[ram]      at 0xFF0C1078:0000E24C [0x0017EF78] <- 0x18F8C0  : was 0x18F8D0;
Warning: R4 not restored (0x17ef28 -> 0x17eed4)                                  at [ff0c1088:e24c]
...
[ram]      at 0x000019D8:0000E24C [0x0018E9A4] <- 0xE24C    : was 0xE24C;
[ram]      at 0x00001A04:0000E24C [0x0008FBCC] <- 0x17EF28  : was 0x17EED4;
[ram]      at 0xFF0C1064:0000E24C [0x0018E9A4] <- 0xE24C    : was 0xE24C;
...
[ram]      at 0xFF0C1074:0000E24C [0x0018E968] <- 0x60000093: was 0x18E9FC;
[ram]      at 0xFF0C1078:0000E24C [0x0017EF24] <- 0x18E968  : was 0x18E970;
Warning: R4 not restored (0x17eed4 -> 0x17ef28)                                  at [ff0c1088:e24c]

Most of these addresses are different for each warning message, except one. Let's try it. Find task_create and DebugMsg (easy) and add everything to EOSM2/debugmsg.gdb (look at other cameras for a template):
Code: [Select]
# ./run_canon_fw.sh EOSM2 -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb

source -v debug-logging.gdb

macro define CURRENT_TASK 0x8FBCC
macro define CURRENT_ISR  (*(int*)0x648 ? (*(int*)0x64C) >> 2 : 0)

b *0x4398
DebugMsg_log

b *0x7360
task_create_log

Code: [Select]
./run_canon_fw.sh EOSM2 -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
...
[      init:ff352264 ] task_create(PowerMgr, prio=20, stack=400, entry=ff352088, arg=0)
[      init:ff1470d4 ] (00:01) [PM] DisablePowerSave (Counter = 1)
[      init:0003671c ] task_create(DbgMgr, prio=1f, stack=0, entry=36628, arg=46e584)
[      init:ff0c3334 ] (8b:16)
K355 ICU Firmware Version 1.0.2 ( 6.0.5 )
[      init:ff0c3348 ] (8b:05)
ICU Release DateTime 2013.12.02 09:28:54
[      init:ff0f5ea0 ] (00:03) [SEQ] CreateSequencer (Startup, Num = 6)
[      init:ff0f5f28 ] task_create(Startup, prio=19, stack=2800, entry=ff0f5d6c, arg=46e880)
[      init:ff0f60f4 ] (00:02) [SEQ] NotifyComplete (Startup, Flag = 0x10000)
[      init:ff0f6158 ] (00:03) [SEQ] NotifyComplete (Cur = 0, 0x10000, Flag = 0x10000)
[      init:ff0c33d4 ] task_create(TaskMain, prio=1d, stack=0, entry=ff0c28d8, arg=0)
[   Startup:ff0f5db4 ] (00:05) [SEQ] seqEventDispatch (Startup, 0)
[   Startup:ff0c373c ] (8b:05) startupEntry
[   Startup:ff0c375c ] task_create(Startup2, prio=11, stack=400, entry=ff0c3604, arg=0)
[  Startup2:ff1310c4 ] (02:16) PROPAD_CreateFROMPropertyHandle DRAMAddr 0x416d5b00
[  Startup2:ff14a204 ] (00:01) [SF] IsAddressSerialFlash 0x2d0000
...

We now have task information and debug messages!

To make this information available in QEMU (not just in GDB), add this to model_list.c under the EOSM2 section:
Code: [Select]
        .current_task_addr      = 0x8FBCC,

That's it for today.
Title: Re: ML on EOS-M2
Post by: a1ex on May 28, 2017, 03:13:05 PM
There are other similar blocks copied into RAM (newer DIGIC 6 and 7 models have plenty of those), and finding them manually can become tedious, so it's a good candidate for automation.

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d romcpy |& grep ROMCPY
[ROMCPY] 0xFFFF0000 -> 0x0        size 0x40       at 0xFFFF0980
[ROMCPY] 0xFFFE0000 -> 0x100000   size 0xFF2C     at 0xFFFF0FCC
[ROMCPY] 0xFFD1F02C -> 0x1900     size 0xB70A0    at 0xFF0C000C
[ROMCPY] 0xFF0C0E04 -> 0x4B0      size 0x1E8      at 0xFF0C0D70
[ROMCPY] 0xFFA12904 -> 0x4E0E98   size 0xC7C      at 0x8645C   

This should work on all models from DIGIC 2 to DIGIC 7 (both EOS and PowerShot).

We now have task information and debug messages!

... and also an option to show all context switches:
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d tasks
...
Task switch to idle:ff0c108c                                                     at [idle:1db8:ff0c1c84]
Task switch to init:ff0c1064                                                     at [init:1a18:c73c]
K355 READY
128K Sector FROM From BL 0xffff
...
SerialFlash Initialize
Task switch to Startup:ff0c108c                                                  at [Startup:1db8:c9e0]
Task switch to Startup2:ff0c1064                                                 at [Startup2:1a18:228c]
...
Task switch to DbgMgr:ff0c1064                                                   at [DbgMgr:1a18:e24c]
     4:    54.784 [PROPAD] PROPAD_CreateFROMPropertyHandle DRAMAddr 0x416d5b00
Task switch to Startup:ff0c1064                                                  at [Startup:1a18:2e40]
[RTC] !! RTC_TIME_CORRECT_CHANGE!  0x0 ---> 0x9a
[RTC] !! RTC UNDER MIN_YEAR !!
Task switch to PropMgr:ff0c1064                                                  at [PropMgr:1a18:da2c]
...

8)
Title: Re: ML on EOS-M2
Post by: DeafEyeJedi on May 28, 2017, 05:58:31 PM
All of this is smoking hot guys and have been on the outlook for a used M2 body just because I would like to join the foam party!
Title: Re: ML on EOS-M2
Post by: a1ex on May 29, 2017, 11:47:06 AM
The nice part is that all other models can follow (more or less) the same procedure. Credits go to dfort for getting the tutorials ball rolling (https://www.magiclantern.fm/forum/index.php?topic=19417.0) - that's the reason I've picked this model for a walkthrough.

In other words, owners of other models will no longer have excuses for not knowing how to port ML to their camera :D

Anyway, let's continue figuring out the emulation.

Code: [Select]
        .serial_flash_size      = 0x1000000,

Unfortunately, this step doesn't change anything in the emulation.

Oops, I was wrong here. To quote Ange Albertini - https://twitter.com/angealbertini/status/773650987839926272
Quote
Reverse engineering tip: it's perfectly fine to
- have no idea what to do next
- have made wrong assumptions
- take 'too long'

Here's the detail I've missed the first time:
Code: [Select]
SerialFlash Initialize
[EEPROM-DMA]! [0x2D0000] -> [0x416D5B00] (0x1DC400 bytes)

Also, error messages like this will disappear after declaring .serial_flash_size:
Code: [Select]
     6:    16.640 [PROPAD] ERROR Not Exist Valid ComboPackages!! 0x2D0000

That's good - it probably means we have nothing else to fix regarding serial flash. Running with -d sflash shows plenty of serial flash activity (but I swear I did ran this command back then and noticed none of it...)

Let's move on to the next item - MPU messages. You can find the registers used for these in InitializeIntercom (surrounded in the disassembly by "InitializeIntercom" ... "InitializeIntercom End(%#x)"). The function call between these two strings is:
Code: [Select]
ROM:FF0C3A9C                 LDR     R2, =0xC020302C
ROM:FF0C3AA0                 LDR     R0, =0xC022006C
ROM:FF0C3AA4                 MOV     R1, #0x50 ; 'P'
ROM:FF0C3AA8                 BL      sub_3AD0

Looking up these registers, you'll find the former on the section with DIGIC 5 defaults (so nothing to change about it), and the latter on the EOSM, 100D and some other models. Let's copy it:
Code: [Select]
        .mpu_request_register   = 0xC022006C,
        .mpu_status_register    = 0xC022006C,

Side note: we were very lucky, as EOS M2 is very similar to 100D and other models from the same generation. 1300D was a lot more different (used registers different from all other models, different registers for request and status - unlike all other models - and also different values for driving these GPIOs). Refer to this commit (https://bitbucket.org/hudson/magic-lantern/commits/f6951853578016789becca598345dbb6ed29c833) for the gory details - generally you'll find this kind of changes with cameras from different generations. I expect this kind of changes on DIGIC 6 models - didn't look into this part yet because 1) mixed ARM/Thumb code is a lot harder to reverse engineer (at least with the tools I know) and 2) I don't have any MPU communication logs from a DIGIC 6 models (it might work with replaying one from a recent DIGIC 5, no idea).

Still, after enabling the MPU registers, there's very little MPU activity:
Code: [Select]
[MPU] Received: 06 04 02 00 00 00  (unknown spell)
[MPU] Received: 0a 08 03 57 10 2f 00 01 00 00  (unknown spell)
[MPU] Received: 08 07 03 6a 01 08 00 00  (unknown spell)

And these warnings:
Code: [Select]
[MPU] FIXME: no MPU spells for EOSM2.
[MPU] FIXME: no MPU button codes for EOSM2.

Let's try our luck by assuming the MPU communication is similar to 100D. That model already boots Canon GUI, so it looks like a perfect match. Lookup this message in the source code to see what file you should edit next:
Code: [Select]
grep -nr "no MPU spells" qemu-2.5.0/
qemu-2.5.0/hw/eos/mpu.c:742:        MPU_EPRINTF("FIXME: no MPU spells for %s.\n", s->model->name);

So we have to edit mpu.c (near line 742). Open it and notice this similarity trick worked on a few other models (such as 1200D or 1100D). Add an entry for EOS M2, using the 100D as model (look for MPU_SPELL_SET_OTHER_CAM).

Looks like it's working! There's a lot of MPU activity now.

Still, the screen is filled with DL messages. Let's look it up in other models - it's already patched on EOS M:
Code: [Select]
EOSM/debugmsg.gdb:17:# patch DL to avoid DL ERROR messages
EOSM/debugmsg.gdb-18-set *(int*)0xFF1BE4AC = 0xe3a00015

Looks like it might be exactly what we need.

Wait a minute - what's up with these black magic values? The first one is a ROM address (obvious if you managed to follow the walkthrough until here), but what about the second one?

The code near that address, on EOS M, looks like this:
Code: [Select]
ROM:FF1BE4AC                 BL      sub_FF1BDFD4
ROM:FF1BE4B0                 CMP     R0, #0x15

In other words, it calls a function and checks whether it returns 0x15. Therefore, 0xe3a00015 must be some ARM instruction. You could throw it at a disassembler (tip: there's even an online disassembler on Twitter (http://www.capstone-engine.org/bot.html) :) ) or you could find a similar pattern in arm-mcr.h. Whatever method you choose, you'll find out it's MOV R0, #0x15.

Use your pattern matching skills to find the same piece of code on EOS M2 (nearby string: "IsPossibleActiveSweep OVERRUN") and add the patch to EOSM2/debugmsg.gdb.

Run the EOSM2 firmware under GDB and notice it now gets stuck at localI2C_Write. Look it up in the GDB scripts and notice the same thing was (again) patched on EOSM.

Code: [Select]
EOSM/debugmsg.gdb:20:# patch localI2C_Write to always return 1 (success)
EOSM/debugmsg.gdb-21-set *(int*)0xFF3460C4 = 0xe3a00001
EOSM/debugmsg.gdb-22-set *(int*)0xFF3460C8 = 0xe12fff1e

You may ask: why there are no comments for these black magic values?
1) the ROM addresses have a comment (the name of the function they are referring to).
2) these ARM instructions are obvious to me (how else you could write "return 1" in ARM assembler?)
3) the comment does describe what the patch is doing, what function is patched, what's the meaning of the returned value... what else should I include?

OK, find this one for EOSM2 (easy) and run it again under gdb.

Emulation goes a bit further, and you can spot this message on the last few lines:
Code: [Select]
    61:   203.008 [STARTUP] ERROR SerialFlash Version!! Firm : 6.0.3 SF : 4.2.1

Look up the string in the disassembly, and also the code that references it:
Code: [Select]
ROM:FF0C4270                 MOV     R2, #5
ROM:FF0C4274                 ADD     R1, SP, #0x30
ROM:FF0C4278                 ADR     R0, a6_0_3      ; "6.0.3"
ROM:FF0C427C                 BL      sub_FF0C8F40
ROM:FF0C4280                 CMP     R0, #0
ROM:FF0C4284                 BEQ     loc_FF0C42A4

ROM:FF0C4290                 ADR     R3, a6_0_3      ; "6.0.3"
ROM:FF0C4294                 ADR     R2, aErrorSerialfla ; "ERROR SerialFlash Version!! Firm : %s S"...
ROM:FF0C42A0                 BL      DebugMsg
ROM:FF0C42A4
ROM:FF0C42A4 loc_FF0C42A4               

So, to avoid this message, we need sub_FF0C8F40 to return 0. Looking at its arguments, it compares "6.0.3" to something else (something from the stack, likely a local variable), and there's a third argument set to 5. Looking at its code, it appears to do something similar to strncpy. Let's try to bypass this function call and let the caller code behave as if sub_FF0C8F40 would return 0:
Code: [Select]
# skip SerialFlash version check
set *(int*)0xFF0C427C = 0xe3a00000

We have just replaced the BL sub_FF0C8F40 call with MOV R0, #0.

The emulation goes a lot further now, it initializes RscMgr, FileMgr, PropMgr, starts a bunch of tasks and... gets stuck in an infinite loop at:
Code: [Select]
[   Startup:ff0c5138 ] (8b:03) Wait LeoLens Complete

Look up the string in the disassembly, and notice the decision for exiting this loop is made here:
Code: [Select]
ROM:FF0C512C loc_FF0C512C                            ; CODE XREF: sub_FF0C4E80+2CCj
ROM:FF0C512C                 ADR     R2, aWaitLeolensCom ; "Wait LeoLens Complete"
...
ROM:FF0C5144                 LDR     R0, [R4,#0x28]
ROM:FF0C5148                 CMP     R0, #0
ROM:FF0C514C                 BEQ     loc_FF0C512C
...

So, we need R0 to be nonzero in order to avoid the branch that prints "Wait LeoLens Complete". The memory address where R0 is loaded from is R4 + 0x28. What the contents of R4 is supposed to be, is not clear from the disassembly. Hit CTRL-C in gdb and set a breakpoint at FF0C5148 to find out:
Code: [Select]
(gdb) b *0xFF0C5148
Breakpoint 3 at 0xff0c5148
(gdb) c
Continuing.

Shortly, gdb prompts us again, this time with the program stopped exactly where the loop condition is checked. Examine the registers:
Code: [Select]
Breakpoint 3, 0xff0c5148 in ?? ()
(gdb) info registers
r0             0x0 0x0
r4             0x8fad4 0x8fad4

So, the memory address the program expects to become nonzero is 0x8fad4+0x28 = 0x8fafc. Look up what other code uses this address (references to either 0x8fad4 - the main data structure - or 0x8fafc - the address of the structure field expected to be updated) and you'll find out this tiny function:
Code: [Select]
ROM:FF0C35F4                 LDR     R1, =dword_8FAD4
ROM:FF0C35F8                 MOV     R0, #1
ROM:FF0C35FC                 STR     R0, [R1,#(dword_8FAFC - 0x8FAD4)]
ROM:FF0C3600                 BX      LR

OK, so the value at this memory address is expected to become 1 at some point.

Who calls this function? Look it up (references to FF0C35F4) and you'll find this snippet:
Code: [Select]
ROM:FF0C3B30                 LDR     R0, =loc_FF0C35F4
ROM:FF0C3B34                 MOV     R1, #0
ROM:FF0C3B38                 BL      sub_FF0F7B18
...
ROM:FF0C3B44                 ADRNE   R2, aInitializeprop ; "InitializePropertySatellite (%#x)"

It must be a tiny function passed as pointer to another function (which is why it wasn't recognized as function by IDA - it's not called directly). When it's supposed to be called? No idea, probably from a missing property that's not present in the serial flash dump we took from 100D. Just a guess.

The property code is usually quite complex - in this case it's a lot easier to just patch the affected loop and hope it will work. If the value would have been clearly retrieved from some MMIO register, or set by some interrupt handler, it would probably have been better to emulate that register or that interrupt (because, on the way to that function expected to be called, the code may do a bunch of other initializations, side effects and whatnot).

In this case, let's just patch the value in gdb and see how it goes:
Code: [Select]
(gdb) set *(int*)($r4 + 0x28) = 1
(gdb) c
Continuing.
[   Startup:ff0c5138 ] (8b:03) Wait LeoLens Complete

Breakpoint 3, 0xff0c5148 in ?? ()
(gdb) c
Continuing.
[   Startup:ff0e29a8 ] (30:03) MOVW_Initialize
[   Startup:0003671c ] task_create(MovWriter, prio=15, stack=2000, entry=36628, arg=67262c)
[   Startup:ff0e6f34 ] (2f:03) MVR_Initialize
[   Startup:0003671c ] task_create(MovieRecorder, prio=11, stack=2000, entry=36628, arg=672d4c)

Looks like the emulation went past that point. Let's add our trick to the gdb script:
Code: [Select]
# break infinite loop at Wait LeoLens Complete
b *0xFF0C5148
commands
  printf "Patching LeoLens (infinite loop)\n"
  set *(int*)($r4 + 0x28) = 1
  c
end

The emulation goes further, mounts the SD card (CSMgrTask), starts even more tasks, and appears to be stuck at:
Code: [Select]
   167:   851.456 [TCH]Touch IC Ver : 0x0000

At this point, seeing there's no progress after 10 seconds or so, you'll be tempted to hit CTRL-C. Or you can forget the emulation window open (e.g. for posting gibberish like this on the forum), and when you hit ALT+TAB you notice this:
Code: [Select]
  1383: 57907.968 WARN [I2C] localI2C_Read : 378 (Task : CEC)
  1384: 57927.680 WARN [I2C] localI2C_Read : 378 (Task : CEC)
  1385: 57947.392 WARN [I2C] localI2C_Read : 378 (Task : CEC)
  1386: 57966.592 WARN [I2C] localI2C_Read : 378 (Task : CEC)

(http://a1ex.magiclantern.fm/bleeding-edge/qemu/M2-gui.png)

Wait, what?

Trying to navigate this menu gives no reaction. We forgot to address this warning (at the beginning of the emulation log):
Code: [Select]
[MPU] FIXME: no MPU button codes for EOSM2.

Use the button codes from 100D and - to quote kichetof - take a beer and enjoy it!

(http://a1ex.magiclantern.fm/bleeding-edge/qemu/M2-qemu.gif)

Tip: comment out DebugMsg calls from the GDB script for a much faster boot.

Exercises:
- (easy) patch the loop that times out (probably when initializing the touch IC) and the localI2C_Read loop;
- (easy) print Hello World with the minimal ML target;
- (moderate) print Hello World with the regular ML source code;
- (moderate) implement touch screen emulation;
- (moderate) bring ML menu in QEMU;
- (harder) full ML port, with most features working;
- (extreme) LiveView emulation.
Title: Re: ML on EOS-M2
Post by: yazcui on May 29, 2017, 07:12:06 PM
M2 owner here. All this jargon is way over my head, but I'm thrilled to learn that ML may be available for the M2 soon. Thanks for your efforts!
Title: Re: ML on EOS-M2
Post by: dfort on June 03, 2017, 07:02:50 AM
I'm trying to follow using the tools I've got available to me. QEMU on a Mac (seems to be working), ARM-console on Mac (sort of half-way works), good ol' disassemble.pl and a fine arts degree (?).

I'm on firmware version 1.0.3 so my numbers don't quite match up to the 1.0.2 dump a1ex is using.

...One of these covers the functions we are interested in:
Code: [Select]
[rom1]     at 0xFF0C000C:FFFF09CC [0xFFD1F02C] -> 0xE92D4010
[ram]      at 0xFF0C000C:FFFF09CC [0x00001900] <- 0xE92D4010: was 0x0;
[rom1]     at 0xFF0C00A4:FFFF09CC [0xFFD1F030] -> 0xE1A04001
[ram]      at 0xFF0C00A4:FFFF09CC [0x00001904] <- 0xE1A04001: was 0x0;
[rom1]     at 0xFF0C00A4:FFFF09CC [0xFFD1F034] -> 0xE59F1040
...
[rom1]     at 0xFF0C00A4:FFFF09CC [0xFFDD60C8] -> 0xFFD1EFFC
[ram]      at 0xFF0C00A4:FFFF09CC [0x000B899C] <- 0xFFD1EFFC: was 0x0;

In other words, a memory block from 0xFFD1F02C to 0xFFDD60C8 (actually 0xFFDD60CB, since we are looking at 32-bit operations) is copied to 0x1900 - 0xB899F. The size of the copied block is 0xb70a0 bytes. To extract this block, grab the terminal and run this under a Bash prompt:

Code: [Select]
dd if=ROM1.BIN of=1900.BIN bs=1 skip=$((0xD1F02C)) count=$((0xB70A0))

(please note the above numbers are only valid for firmware 1.0.2)

Now you can disassemble this file starting from 0x1900. In IDA, load this file as Additional binary file. If you use ARM-console, this should auto-detect the above copying operation (so you can simply start browsing the functions copied into RAM).

This is the same bit in 1.0.3:

Code: [Select]
[rom1]     at 0xFF0C000C:FFFF09CC [0xFFD1F0E4] -> 0xE92D4010
[ram]      at 0xFF0C000C:FFFF09CC [0x00001900] <- 0xE92D4010: was 0x0;
[rom1]     at 0xFF0C00A4:FFFF09CC [0xFFD1F0E8] -> 0xE1A04001
[ram]      at 0xFF0C00A4:FFFF09CC [0x00001904] <- 0xE1A04001: was 0x0;
[rom1]     at 0xFF0C00A4:FFFF09CC [0xFFD1F0EC] -> 0xE59F1040
...
[rom1]     at 0xFF0C00A4:FFFF09CC [0xFFDD6180] -> 0xFFD1F0B4
[ram]      at 0xFF0C00A4:FFFF09CC [0x000B899C] <- 0xFFD1F0B4: was 0x0;

I see a memory block from 0xFFD1F0E4 to 0xFFDD6180. I'm not sure how you came up with 0xFFDD60CB from 0xFFDD60C8 to make it conform to a 32-bit operation. I tried looking it up but don't quite get it.

Moving on, 0xFFDD6180 - 0xFFD1F0E4 = 0xB709C. It starts at 0x1900 and we need to calculate the end (0x1900 + 0xB709C = 0xB899C) so it is copied to 0x1900 - 0xB899C. The size of the copied block is 0xB709F but it needs to be rounded up to be evenly divisible by 32 (0x20) right? So if I followed the lesson plan properly it is also 0xB70A0 just like the 1.0.2 firmware.

Code: [Select]
dd if=ROM1.BIN of=EOSM2.103.0x1900.BIN bs=1 skip=$((0xD1F0E4)) count=$((0xB70A0))
That's the name I used for ARM-console to auto-detect. I also did a "perl disassemble.pl 0x1900 EOSM2.103.0x1900.BIN" in order to get a "second opinion" and both methods seem to be in agreement.

[EDIT] Set up a branch to start the port (https://bitbucket.org/daniel_fort/magic-lantern/branch/EOSM2.103_wip). First step was just to create an EOSM.202 build but call it EOSM2.103.
Title: Re: ML on EOS-M2
Post by: a1ex on June 03, 2017, 08:44:44 AM
I'm not sure how you came up with 0xFFDD60CB from 0xFFDD60C8 to make it conform to a 32-bit operation. I tried looking it up but don't quite get it.

A 32-bit read from 0xFFDD60C8 actually means 4 bytes from that address: 0xFFDD60C8, 0xFFDD60C9, 0xFFDD60CA, 0xFFDD60CB.

Quote
The size of the copied block is 0xB709F but it needs to be rounded up to be evenly divisible by 32 (0x20) right? So if I followed the lesson plan properly it is also 0xB70A0 just like the 1.0.2 firmware.

Nothing is rounded up; this is the exact size. Copying 4 bytes at a time cannot give you an odd number of bytes ;)
Title: Re: ML on EOS-M2
Post by: dfort on June 05, 2017, 03:45:14 PM
Alright, so let's start from where we've left off.

I'm going through this slowly and trying to make sure my results are matching up. Some things aren't quite the same which is to be expected because I'm using a different firmware version (1.0.3) and another reason may be because I'm QEMU on a Mac which might not be set up quite right just yet.

For the debugmsg.gdb file, we'll need some basic stubs: DebugMsg and task_create (easy to find - one is used for most debug messages, the other can be easily identified from things that look like task names) and two addresses: CURRENT_TASK and CURRENT_ISR (interrupt service routine). We can find the latter in the interrupt handler - quote from debugmsg.gdb:
If you can find that by examining disassembled code, great. If not, QEMU to the rescue:
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d io,int,nochain -singlestep
...
Taking exception 5 [IRQ]
[INT]      at 0x00000510:0000050C [0xC0201004] -> 0x28      : Requested int reason 28 (INT 0Ah)
[INT]      at 0x00000594:00000568 [0xC0201010] <- 0xA       : Enabled interrupt 0Ah

(note: -d nochain -singlestep gives more precise locations in I/O logs - otherwise, QEMU groups the ARM instructions in blocks for faster execution, so the reported location will be approximate)

First of all I went through the disassembly and as best as I can determine the stubs that we're using haven't changed between the firmware versions. Great! However, I am seeing different results.
Code: [Select]
(gdb) disas 0x4B0,0x6B0[EOS] trigger int 0x0A (delayed)
Taking exception 5 [IRQ]
[INT]      at 0x00000510:0000050C [0xC0201004] -> 0x28      : Requested int reason 28 (INT 0Ah)
[TIMER]    at 0xFF350400:000072A4 [0xC0242014] -> 0x6E900   : DIGIC clock
[INT]      at 0x00000594:FF0C1578 [0xC0201010] <- 0xA       : Enabled interrupt 0Ah

The clock is running continuously so I suppose that can be disregarded but the difference between 0x00000568 and 0xFF0C1578 isn't exactly "approximate."

OK, so the register we are looking for is read at 0x510. Let's disassemble with GDB:
Code: [Select]
(gdb) disas 0x4B0,0x6B0
...
   0x0000050c: ldr r0, [pc, #368] ; 0x684
   0x00000510: ldr r4, [r0]
   0x00000514: str r4, [pc, #304] ; 0x64c
...
(gdb) x 0x684
0x684: 0xc0201004
(gdb) x 0x64c
0x64c: 0x00000028
(gdb) print 0x28>>2
$1 = 0xa

Hit a wall here because I'm not seeing anything at all like that.

I've been updating the EOSM2 preliminary setup (https://bitbucket.org/hudson/magic-lantern/pull-requests/835/eosm2-preliminary-setup/diff) pull request as I work my way through this.
Title: Re: ML on EOS-M2
Post by: a1ex on June 05, 2017, 05:06:05 PM
You need to type the gdb commands at the gdb prompt. You'll need to start qemu like this:
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb

Of course, you can mix gdb with other options freely. In the above invocation, gdb will be the foreground process (the one you interact with on the console); if you swap their order, QEMU will be the foreground process (which doesn't do anything interesting by default, unless you redirect its monitor to console, with -monitor stdio).

The DIGIC clock line appeared after me fine-tuning the verbosity (so it's OK). Interrupts are not deterministic (since they use the host's wall clock as a reference, so the results depend a lot on the emulation speed, and you will not get the same code sequence on two different runs. The same happens on real hardware (run the startup-log twice and compare the logs).

Besides, the execution trace within a timer interrupt also depend on whatever DryOS decides to do in that interrupt (such as switching tasks or running some timer event). To see this particular case more clearly, try:
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d io,int,nochain -singlestep |& grep "Enabled interrupt 0Ah"
Title: Re: ML on EOS-M2
Post by: dfort on June 07, 2017, 08:54:50 PM
Hope I'm not wearing out my QEMU welcome -- still stuck here:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S & arm-none-eabi-gdb -x debug-logging.gdb
(note: we will need to create a GDB file for EOS M2, named EOSM2/debugmsg.gdb to match other models, but since we don't have one yet, we can just use the generic version - which we are going to include in the platform-specific file later)

Let it run for a while (continue), then hit CTRL-C and examine the exception vector (located at address 0):

Code: [Select]
(gdb) disas 0,0x40
Dump of assembler code from 0x0 to 0x40:
   0x00000000: nop ; (mov r0, r0)
   0x00000004: ldr pc, [pc, #20] ; 0x20
   0x00000008: ldr pc, [pc, #20] ; 0x24
...

The line in red is what is tripping me up, specifically the (continue). How am I supposed to do that?

Code: [Select]
[EOS] loading './EOSM2/ROM0.BIN' to 0xF0000000-0xF0FFFFFF
[EOS] loading './EOSM2/ROM1.BIN' to 0xF8000000-0xF8FFFFFF
[EOS] loading './EOSM2/SFDATA.BIN' as serial flash, size=0x1000000
[MPU] FIXME: no MPU spells for EOSM2.
[MPU] FIXME: no MPU button codes for EOSM2.
Setting BOOTDISK flag to 0
continue
-bash: continue: only meaningful in a `for', `while', or `until' loop

So that's not right. QEMU on Mac has a "Machine" menu item where you can "Pause" and "Resume" and that shows some more action in the terminal but CTRL-C always gets me back to the bash prompt--shouldn't I be getting the (gdb) prompt? Launching gdb and continuing your instructions always results in:

Code: [Select]
(gdb) disas 0,0x40
Dump of assembler code from 0x0 to 0x40:
   0x00000000: Cannot access memory at address 0x0

This might be a Macintosh issue but more likely a problem with a clueless user.
Title: Re: ML on EOS-M2
Post by: a1ex on June 07, 2017, 09:05:23 PM
After typing that long command, I get the (gdb) prompt. Type "continue" there.

Selecting "Pause" from QEMU menu also gets me to the (gdb) prompt.
Title: Re: ML on EOS-M2
Post by: dfort on June 08, 2017, 12:57:32 AM
I don't get that at all, that long command launches QEMU. I do see an error message flash by but terminal isn't show the full history. I redirected the error messages like this
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S & arm-none-eabi-gdb -x debug-logging.gdb 2> error.txt
and found this:
Code: [Select]
-bash: arm-none-eabi-gdb: command not found
Seems like I've got a configuration issue. It appears to be in the right place.
Code: [Select]
/Users/rosiefort/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gdb
Title: Re: ML on EOS-M2
Post by: dfort on June 08, 2017, 08:29:47 AM
If I make that long command even longer, it works:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S & ~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gdb -x debug-logging.gdb
Is there supposed to be a symlink in ~/qemu for arm-none-eabi-gdb?
Title: Re: ML on EOS-M2
Post by: a1ex on June 08, 2017, 10:30:49 AM
This may help: https://unix.stackexchange.com/questions/183295/adding-programs-to-path
Title: Re: ML on EOS-M2
Post by: vagaboundedu on June 14, 2017, 02:18:37 AM
Just wanted you all to know that I created an account on this site specifically to say I'm really looking forward to being able to install ML on my M2! Can't wait! Thank you so much for all your work.
Title: Re: ML on EOS-M2
Post by: dfort on June 18, 2017, 11:49:29 PM
Thought I'd make a little noise on this topic just to let people know that I'm still working my way through this albeit at a very slow pace.

QEMU is under active development so before posting anything I pull in the latest commits and merge my EOSM2 and Mac specific build tweaks.

Ok, so here's where I left off:

Alright, so let's start from where we've left off.
...
This 0x648 looks like a counter that tells how many nested interrupts we are handling (yes, they can be nested - unfortunately, as this makes it a lot harder to understand, debug, emulate and so on). Let's confirm its functionality with RAM tracing:
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d io,int,ram,nochain -singlestep
...
[tcm_code] at 0x000004D4:19980218 [0x00000648] -> 0x0       
[tcm_code] at 0x000004E0:19980218 [0x00000648] <- 0x1       : was 0x0;
...
[tcm_code] at 0x0000050C:0000050C [0x00000684] -> 0xC0201004
[INT]      at 0x00000510:0000050C [0xC0201004] -> 0x28      : Requested int reason 28 (INT 0Ah)
[tcm_code] at 0x00000514:0000050C [0x0000064C] <- 0x28      : was 0x0;
...
[INT]      at 0x00000594:00000568 [0xC0201010] <- 0xA       : Enabled interrupt 0Ah
[tcm_code] at 0x00000598:00000568 [0x00000648] -> 0x1       
[tcm_code] at 0x000005A0:00000568 [0x00000648] <- 0x0       : was 0x1;

Looks right!

I'm seeing pretty much the same only with some additional information probably as a result of some of the enhancements a1ex has been adding to QEMU.

Code: [Select]
...
[tcm_code] at TaskM:000004D4:19980218 [0x00000648] -> 0x0       
[tcm_code] at TaskM:000004E0:19980218 [0x00000648] <- 0x1       : was 0x0;
...
[tcm_code]  at init:0000050C:0000050C [0x00000684] -> 0xC0201004
[INT]       at init:00000510:0000050C [0xC0201004] -> 0x28      : Requested int reason 28 (INT 0Ah)
[tcm_code]  at init:00000514:0000050C [0x0000064C] <- 0x28      : was 0x0;
...
[INT]       at init:00000594:00000568 [0xC0201010] <- 0xA       : Enabled interrupt 0Ah
[tcm_code]  at init:00000598:00000568 [0x00000648] -> 0x1       
[tcm_code]  at init:000005A0:00000568 [0x00000648] <- 0x0       : was 0x1;

In some cases I'm getting errors that shouldn't be happening. For example:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d callstack,ramw |& grep -B 20 "not restored"
-bash: syntax error near unexpected token `&'

The '|&' shorthand was added to bash 4 as an abbreviation for '2>&1 |' and I'm running this version of bash:

Code: [Select]
GNU bash, version 4.4.12(1)-release (x86_64-apple-darwin16.3.0)
Go figure -- must be a Mac thing. Changing '|&' to '2>&1 |' still didn't give me the same results a1ex posted.

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d callstack,ramw 2>&1 | grep -B 20 "not restored"
[tcm_data] at 0x0010DA10:00000040 [0x40000F60] <- 0x4       : was 0x4C;
[tcm_data] at 0x0010DA10:00000040 [0x40000F64] <- 0x20      : was 0x4C;
[tcm_data] at 0x0010DA10:00000040 [0x40000F68] <- 0x8       : was 0x4C;
[tcm_data] at 0x0010DA10:00000040 [0x40000F6C] <- 0x40      : was 0x1F;
[tcm_data] at 0x0010DA08:00000100 [0x40000F70] <- 0x10      : was 0x4C;
[tcm_data] at 0x0010DA08:00000100 [0x40000F74] <- 0x80      : was 0x4C;
[tcm_data] at 0x0010DA08:00000100 [0x40000F78] <- 0x20      : was 0x40;
[tcm_data] at 0x0010DA08:00000100 [0x40000F7C] <- 0x100     : was 0x40;
[tcm_data] at 0x0010DA10:00000C00 [0x40000F80] <- 0x40      : was 0x1F;
[tcm_data] at 0x0010DA10:00000C00 [0x40000F84] <- 0x200     : was 0x1;
[tcm_data] at 0x0010DA10:00000C00 [0x40000F88] <- 0x80      : was 0x0;
[tcm_data] at 0x0010DA10:00000C00 [0x40000F8C] <- 0xC00     : was 0x0;
[tcm_data] at 0x0010DA2C:00000C00 [0x40000F90] <- 0xFF      : was 0x7;
[tcm_data] at 0x0010DA2C:00000C00 [0x40000F94] <- 0xFFF     : was 0x1;
[tcm_data] at 0x0010329C:001000C8 [0x40000F9C] <- 0x1       : was 0x0;
[tcm_data] at 0x0010329C:001000C8 [0x40000FA0] <- 0x1000C8  : was 0x10007C;
[tcm_data] at 0x0010329C:001000F8 [0x40000F9C] <- 0x1       : was 0x1;
[tcm_data] at 0x0010329C:001000F8 [0x40000FA0] <- 0x1000F8  : was 0x1000C8;
[tcm_data] at 0x001022C0:0010013C [0x40000F9C] <- 0x1       : was 0x1;
[tcm_data] at 0x001022C0:0010013C [0x40000FA0] <- 0x10013C  : was 0x1000F8;
Warning: R10 not restored (0xa -> 0x1)                                           at [ffff101c:ffff09cc]

Moving on or I'll never get through this. Here we can finally see some indication of the different firmware versions that we're looking at, a1ex on EOSM2 1.0.2 while I'm on 1.0.3.


Code: [Select]
./run_canon_fw.sh EOSM2 -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
...
[      init:ff352264 ] task_create(PowerMgr, prio=20, stack=400, entry=ff352088, arg=0)
[      init:ff1470d4 ] (00:01) [PM] DisablePowerSave (Counter = 1)
[      init:0003671c ] task_create(DbgMgr, prio=1f, stack=0, entry=36628, arg=46e584)
[      init:ff0c3334 ] (8b:16)
K355 ICU Firmware Version 1.0.2 ( 6.0.5 )
[      init:ff0c3348 ] (8b:05)
ICU Release DateTime 2013.12.02 09:28:54
[      init:ff0f5ea0 ] (00:03) [SEQ] CreateSequencer (Startup, Num = 6)
[      init:ff0f5f28 ] task_create(Startup, prio=19, stack=2800, entry=ff0f5d6c, arg=46e880)
[      init:ff0f60f4 ] (00:02) [SEQ] NotifyComplete (Startup, Flag = 0x10000)
[      init:ff0f6158 ] (00:03) [SEQ] NotifyComplete (Cur = 0, 0x10000, Flag = 0x10000)
[      init:ff0c33d4 ] task_create(TaskMain, prio=1d, stack=0, entry=ff0c28d8, arg=0)
[   Startup:ff0f5db4 ] (00:05) [SEQ] seqEventDispatch (Startup, 0)
[   Startup:ff0c373c ] (8b:05) startupEntry
[   Startup:ff0c375c ] task_create(Startup2, prio=11, stack=400, entry=ff0c3604, arg=0)
[  Startup2:ff1310c4 ] (02:16) PROPAD_CreateFROMPropertyHandle DRAMAddr 0x416d5b00
[  Startup2:ff14a204 ] (00:01) [SF] IsAddressSerialFlash 0x2d0000
...

And my results running that same command.

Code: [Select]
./run_canon_fw.sh EOSM2 -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
...
[      init:ff352260 ] task_create(PowerMgr, prio=20, stack=400, entry=ff352084, arg=0)
[      init:ff1470d0 ] (00:01) [PM] DisablePowerSave (Counter = 1)
[      init:0003671c ] task_create(DbgMgr, prio=1f, stack=0, entry=36628, arg=46e584)
[      init:ff0c3334 ] (8b:16)
K355 ICU Firmware Version 1.0.3 ( 6.0.6 )
[      init:ff0c3348 ] (8b:05)
ICU Release DateTime 2016.08.09 13:28:42
[      init:ff0f5e9c ] (00:03) [SEQ] CreateSequencer (Startup, Num = 6)
[      init:ff0f5f24 ] task_create(Startup, prio=19, stack=2800, entry=ff0f5d68, arg=46e880)
[      init:ff0f60f0 ] (00:02) [SEQ] NotifyComplete (Startup, Flag = 0x10000)
[      init:ff0f6154 ] (00:03) [SEQ] NotifyComplete (Cur = 0, 0x10000, Flag = 0x10000)
[      init:ff0c33d4 ] task_create(TaskMain, prio=1d, stack=0, entry=ff0c28d8, arg=0)
[   Startup:ff0f5db0 ] (00:05) [SEQ] seqEventDispatch (Startup, 0)
[   Startup:ff0c373c ] (8b:05) startupEntry
[   Startup:ff0c375c ] task_create(Startup2, prio=11, stack=400, entry=ff0c3604, arg=0)
[  Startup2:ff1310c0 ] (02:16) PROPAD_CreateFROMPropertyHandle DRAMAddr 0x416d5b00
[  Startup2:ff14a200 ] (00:01) [SF] IsAddressSerialFlash 0x2d0000
...

Crawling along to a1ex's next post I ran into the '|&' issue again.

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d romcpy |& grep ROMCPY
[ROMCPY] 0xFFFF0000 -> 0x0        size 0x40       at 0xFFFF0980
[ROMCPY] 0xFFFE0000 -> 0x100000   size 0xFF2C     at 0xFFFF0FCC
[ROMCPY] 0xFFD1F02C -> 0x1900     size 0xB70A0    at 0xFF0C000C
[ROMCPY] 0xFF0C0E04 -> 0x4B0      size 0x1E8      at 0xFF0C0D70
[ROMCPY] 0xFFA12904 -> 0x4E0E98   size 0xC7C      at 0x8645C   

Only this time substituting '2>&1 |' worked, sort of. Seems it ended a little earlier.

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d romcpy 2>&1 | grep ROMCPY
[ROMCPY] 0xFFFF0000 -> 0x0        size 0x40       at 0xFFFF0980
[ROMCPY] 0xFFFE0000 -> 0x100000   size 0xFF2C     at 0xFFFF0FCC
[ROMCPY] 0xFFD1F0E4 -> 0x1900     size 0xB70A0    at 0xFF0C000C
[ROMCPY] 0xFF0C0E04 -> 0x4B0      size 0x1E8      at 0xFF0C0D70
Binary file (standard input) matches
Title: Re: ML on EOS-M2
Post by: a1ex on June 19, 2017, 12:10:34 AM
Quote
Changing '|&' to '2>&1 |' still didn't give me the same results a1ex posted.

These warnings should only appear if .current_task_addr is not defined. There are lots of them, on all models.

Quote
Binary file (standard input) matches

Maybe grep gets confused by ANSI color codes. Adding ansi2txt to the pipeline, or using grep --text, may help.
Title: Re: ML on EOS-M2
Post by: dfort on June 19, 2017, 02:05:14 AM
As I suspected the bash issue was a Mac thing.

Code: [Select]
echo $BASH_VERSION
3.2.57(1)-release

Hold on there, what happened to bash 4 that we installed via Homebrew a while back? That works with the shell scrips but the default shell was still the old BSD version. To make GNU bash the default needs an adjustment of the terminal preferences.

(https://c1.staticflickr.com/5/4228/35392882555_3285a9895b_z.jpg)

The default login was still going to /bin/bash but the new shell is in /usr/local/bin. I've got "Shell opens with: Default login shell" picked and it is now going to the new bash.

Code: [Select]
echo $BASH_VERSION
4.4.12(1)-release

And of course the '|&' shortcut is now working.

I also got the full gcc-arm-none-eabi toolset working by doing a:

Code: [Select]
ln -s ~/gcc-arm-none-eabi-4_8-2013q4/bin/* /usr/local/bin/
Lots of gotchas running QEMU on the Mac. Someday I should put them all together into a tutorial.


Title: Re: ML on EOS-M2
Post by: vagaboundedu on June 19, 2017, 03:00:19 AM
Been checking back everyday and was excited to see the updates today. Thanks so much for your continued work on this!
Title: Re: ML on EOS-M2
Post by: dfort on June 19, 2017, 06:52:38 AM
I was getting excited because I was on the post where QEMU was showing the camera's UI but I got nothing yet -- probably because I neglected to understand this part:

Anyway, let's continue figuring out the emulation.
Code: [Select]
        .serial_flash_size      = 0x1000000,Oops, I was wrong here.

I wasn't really sure what to do here. We are using the SFDATA.BIN from a 100D and added ".serial_flash_size      = 0x1000000," to the new EOSM2 section in "qemu/qemu-2.5.0/hw/eos/model_list.c" -- right? So maybe this isn't right and I need to change the size to something else? Do I also need to somehow "fix" the SFDATA.BIN?

Taking a hint I did a QEMU run with "-d sflash" like this:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d sflash
...
K355 READY
128K Sector FROM From BL 0xffff
[SF] InstallSerialFlash 6 0xc022c0d4 0x0 0x1000000 1

[SF] Bufcon Base 0xc022c0d4
[EEPROM] CS = 1
SerialFlash Initialize
[EEPROM] CS = 0
[EEPROM] Verbose: Got READ (03h)
[EEPROM] Verbose: address is now: 0x2D0000
...
     0:     3.072 [STARTUP]
K355 ICU Firmware Version 1.0.3 ( 6.0.6 )
     4:     3.328 [PROPAD] PROPAD_CreateFROMPropertyHandle DRAMAddr 0x416d5b00
     5:     3.840 [PROPAD] SerialFlash Packages!! 0x2d0000
[SFIO] sfio_trigger_int_DMA
[SFIO] eos_handle_sfio (copying now)
[EEPROM-DMA]! [0x2D0000] -> [0x416D5B00] (0x1DC400 bytes)
...
     6:     9.216 [PROPAD] SerialFlash Packages!! 0x7
     7:     9.216 [PROPAD] PROPAD_CreateFROMPropertyHandle DRAMAddr 0x41435b00
     8:     9.728 [PROPAD] SerialFlash Packages!! 0x10000
[SFIO] sfio_trigger_int_DMA
[SFIO] eos_handle_sfio (copying now)

At first I skipped over this and continued to set up QEMU for the EOSM2 but when it didn't work out as I hoped I returned to the part I didn't quite understand. I also committed the changes I made to my QEMU EOSM2 pull request (https://bitbucket.org/hudson/magic-lantern/pull-requests/835/qemu-eosm2-preliminary-setup/diff) even though it isn't working yet. Maybe someone could check if I'm on the right track?  ;D

I also committed some more changes to the build tweaks (https://bitbucket.org/hudson/magic-lantern/pull-requests/836/qemu-build-tweaks-2/diff) I've been doing to get QEMU on Mac running a little smoother.
Title: Re: ML on EOS-M2
Post by: a1ex on June 19, 2017, 09:43:34 AM
The serial flash activity looks alright. The issue is at MPU messages.

Simply adding files to the repository will not change anything - they must be included somehow in the build process. For example, if it's a .c file, generally you'll need to include the corresponding object file into the executable (example (https://bitbucket.org/hudson/magic-lantern/commits/a23f3fe2b470a2b5a155f87d18354bafd29263f6#chg-contrib/qemu/eos/Makefile.objs)). If it's a .h file, you'll need to #include it somewhere. And once you have done that, you usually have to reference the new stuff somehow (call some functions or use some data structures from the new files), unless these files are used to replace or override some older definitions. That's generally how it works in a C program.

QEMU does something interesting here - any function or variable must be used somehow (unless it's a global API - in this case it requires a prototype - or an inline function), otherwise you get a compile error. So, if you define button_codes_EOSM2[], but you don't reference it from anywhere, you should get this:
Code: [Select]
error: ‘button_codes_EOSM2’ defined but not used [-Werror=unused-variable]
 static int button_codes_EOSM2[] = {
            ^

In this case, you don't even have to create new files or new definitions. Simply look in mpu.c to see how it's done on other models.
Title: Re: ML on EOS-M2
Post by: dfort on June 19, 2017, 04:17:45 PM
Simply look in mpu.c to see how it's done on other models.

I actually did that but forgot to commit mpu.c. Fixed that on the pull request (https://bitbucket.org/hudson/magic-lantern/pull-requests/835/qemu-eosm2-preliminary-setup/diff#chg-contrib/qemu/eos/mpu.c). I'm juggling three branches, the Mac specific build tweaks, the EOSM2 setup and a working branch where these two branches are merged. I'm also merging in changes from the main qemu branch to keep everything up to date. When I want to save a change I made in the working branch I commit the change in either build tweaks or EOSM2 so the pull requests get updated then merge back into the working branch, rinse and repeat.

Whatever problem I'm experiencing probably isn't because I'm on a Mac because QEMU seems to be running properly. I saved the terminal outputs for a fresh QEMU build and run in PASTEBIN in order to take a closer look at the warnings and error messages.

install.sh (https://pastebin.com/C9TMEPJU)
configure_eos.sh (https://pastebin.com/sAfzVrQU)
make -j8 (https://pastebin.com/3ybMCSzY)
run_canon_fw.sh EOSM2 (https://pastebin.com/rMGV4mVK) (The terminal buffer resets so some of the history is lost. Don't know if I'm using the right terminology--no pun intended.)

I would think that running "run_canon_fw.sh EOSM2" would show the minimal autoexc.bin output like on the EOSM but maybe not? I've been able to follow most of the walk through except for the part where QEMU displays the camera's UI. If I can get past that hump I would think that the next step would be to compile a "hello world" autoexec.bin to run in QEMU then figure out how to turn on the camera boot flag to run "hello world" in the camera--or not, I may be jumping an important step here.

Title: Re: ML on EOS-M2
Post by: a1ex on June 19, 2017, 05:11:16 PM
All OK so far - just keep following the walkthrough.

The terminal reset is intended, as it allows you to scroll to the beginning of the log. Would be nice to print the command line after clearing the screen.
Title: Re: ML on EOS-M2
Post by: dfort on June 20, 2017, 01:52:04 AM
Seems oh so close.

EOSM2/debugmsg.gdb
Code: [Select]
# patch localI2C_Write to always return 1 (success)
set *(int*)0xFF356DE0 = 0xe3a00001
set *(int*)0xFF356DE8 = 0xe12fff1e

Not 0xe12fff1e, right? Having a tough time with these black magic numbers. I can sort of see how 0xe3a00001 returns 1 but nothing jumps out at me on that second value.
Title: Re: ML on EOS-M2
Post by: dfort on June 20, 2017, 07:43:49 AM
Thanks for the hints a1ex. Fortunately I saved a dump of the old 1.0.2 firmware so I could check my addresses against yours. I was close which would have counted for something in horseshoes but not here. Haven't managed to find my way around the menus but I did change the time date and place to document this historic event.  8)

(https://c1.staticflickr.com/5/4199/34577687884_5333a32e27_z.jpg)

Title: Re: ML on EOS-M2
Post by: dfort on June 20, 2017, 03:49:55 PM
Ok, so I got menus:

(https://c1.staticflickr.com/5/4205/35295962291_bc58d17aec_z.jpg)

Should the next goal be to boot into ML like the EOSM?

(https://c1.staticflickr.com/5/4270/35038642510_b6d8767934_z.jpg)

Quote
Exercises:
- (easy) patch the loop that times out (probably when initializing the touch IC) and the localI2C_Read loop;
- (easy) print Hello World with the minimal ML target;
- (moderate) print Hello World with the regular ML source code;
- (moderate) implement touch screen emulation;
- (moderate) bring ML menu in QEMU;
- (harder) full ML port, with most features working;
- (extreme) LiveView emulation.
Title: Re: ML on EOS-M2
Post by: a1ex on June 20, 2017, 04:25:13 PM
The second screen should be as easy as specifying "boot=1".

Reason: the ROM dumped from EOS M2 does not have the boot flag enabled, while the ROM dumped from EOS M probably has it.

At this point, we have everything we need to port ML and debug it in the emulator. At least, things like Hello World or ML menu navigation will work without requiring additional changes to QEMU.
Title: Re: ML on EOS-M2
Post by: dfort on June 21, 2017, 06:49:39 AM
The second screen should be as easy as specifying "boot=1".

Yes indeed. Strange thing is that this is an EOSM2 running firmware version 1.0.3 but it is showing unknown with 1.0.2.

(https://c1.staticflickr.com/5/4256/35052267590_bee58b9b8b_z.jpg)

Working on a virtual camera. This will be interesting.
Title: Re: ML on EOS-M2
Post by: a1ex on June 21, 2017, 10:06:33 AM
That comes from the way properties are stored in memory: there are many setting blocks, and only one of them is active. The property parser (https://bitbucket.org/hudson/magic-lantern/src/recovery/src/prop_diag.c) from the recovery branch is was not very smart (it doesn't look at whether a block is active or not - it just parses everything). So, it takes the values from the last block in memory that has them (not necessarily the active one).

It probably takes a couple of restarts after the firmware upgrade to replace all the old blocks with 1.0.3.

Updated prop_diag to only parse the active blocks (recovery branch). You can build the display test from that branch, from platform/portable.000 (comment out the ROM dumping routine and cache disabling tricks and that's the plain display test).

Tip: compiling the same branch from some camera directory will give additional capabilities (such as LED blinking), but the binary will no longer be portable.
Title: Re: ML on EOS-M2
Post by: dfort on June 21, 2017, 04:05:07 PM
Updated prop_diag to only parse the active blocks (recovery branch). You can build the display test from that branch, from platform/portable.000...

Looks good with the latest recovery autoexec.bin.

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=1"(https://c1.staticflickr.com/5/4232/35278925112_5a8d253997.jpg)

It also created a fresh ROM dump in QEMU:
(https://c1.staticflickr.com/5/4245/35058581330_6599c62ee0.jpg)

However, the MD5 values from the "original" ROM1 and the new QEMU dump don't match. Is this expected?

Code: [Select]
MD5 (/Users/rosiefort/qemu/EOSM2/ROM0.BIN) = f1712be00d98f8cea522f32da216cf96
MD5        (/Volumes/EOS_DIGITAL/ROM0.BIN) = f1712be00d98f8cea522f32da216cf96

MD5 (/Users/rosiefort/qemu/EOSM2/ROM1.BIN) = 3788c332c4a8b2a6b3f521cc92c508ce
MD5        (/Volumes/EOS_DIGITAL/ROM1.BIN) = 5a78ec64480d11275dd064da2cedd136
Title: Re: ML on EOS-M2
Post by: vagaboundedu on June 21, 2017, 07:47:08 PM
Wow--big progress! Did you already try it on your M2?
Title: Re: ML on EOS-M2
Post by: a1ex on June 21, 2017, 09:35:37 PM
However, the MD5 values from the "original" ROM1 and the new QEMU dump don't match. Is this expected?

"boot=1" works by patching the ROM. If you do the same change in a hex editor, you'll get the second MD5.
Title: Re: ML on EOS-M2
Post by: dfort on June 24, 2017, 03:43:22 AM
Wow--big progress! Did you already try it on your M2?

Not yet. Still in QEMU. Trying to run Hello World but my MacBook doesn't look like an EOSM2:

(https://c1.staticflickr.com/5/4217/35455229096_54c5570334.jpg)

I found everything in stubs.S but then I started going through consts.h and yikes! Looks like finding stubs was the easy part. I did read the part about firmware signature failing in QEMU so I made a new branch, merged QEMU and EOSM2 but found out that if there is no value for "#define SIG_EOSM2_103" then I get a blank QEMU screen. Is this a Catch-22?

Oh well, at least I've got a good stubs.S file -- uh, I think.
Title: Re: ML on EOS-M2
Post by: a1ex on June 24, 2017, 10:17:13 AM
Time to learn some debugging tricks :)

Look at recent QEMU updates - one of them is compiling ML with debug information (http://www.magiclantern.fm/forum/index.php?topic=2864.msg185649#msg185649). So far I have only used it for translating code addresses from ML code into source code lines (addr2line). Let's see if we can enable source code debugging in GDB, so we can run the code step by step, as we would with a PC program.

Notes:
- This is the first time I'm trying this trick. I have used source code debugging in IDA + QEMU before, but that was based on decompiled code (and the free version can't do debugging if I'm not mistaken). Here I want to run ML step by step, on the original source code.
- I want the QEMU updates in the mainline, as there are some APIs for debugging ML as well (there's a PR open), which means you can merge "qemu" in your EOSM2 branch. Or, simply experiment there, and once the debugging session is over, move the changes to the "clean" branch (this is what I usually do if I need the dm-spy-experiments branch).

Enough chit-chat, let's try it:
Code: [Select]
# from ML directory
hg update qemu -C
cd platform/EOSM2.103
make clean; make
# mount the SD image
make install

Next, we have to set up a breakpoint in our code (autoexec.bin); we can do that from debugmsg.gdb.

Without debugging symbols, we would do it like this and debug the assembly code (which is not very easy):
Code: [Select]
# breakpoint on autoexec.bin
b *0x800000

To use debugging symbols in gdb, we'll have to use symbol-file (to load the symbols from an elf file). The .o files that appear when compiling ML are elf files. Also, the files without extension, "autoexec" and "magiclantern", are elf files. The first one refers to reboot.c (look it up in Makefile.src) and gets loaded where Canon's bootloader loads autoexec.bin (at AUTOEXEC_BASE = 0x800000), while the second refers to the regular ML code (starting in boot-hack.c), that gets loaded into its final location (RESTARTSTART).

Why all this trouble? Because our binary can't stay at 0x800000. How comes? Well, autoexec.bin (which is a file loaded in Canon code, probably for debugging or development purposes) wasn't meant (read: designed by Canon) to be a program to run alongside Canon's main firmware; therefore DryOS is free to use the addresses near 0x800000 (where we are loaded). So, we have to move somewhere else. More on that later.

Back to our debugging session: the issue is in reboot.c (that's where this message is printed from), so we are going to run "autoexec.bin" as a plain binary (machine code), and use "autoexec" (elf) for the debugging symbols. Add this to debugmsg.gdb:

Code: [Select]
# breakpoint on autoexec.bin (cstart)
symbol-file ../magic-lantern/platform/EOSM2.103/autoexec
b cstart

You can keep both breakpoints, as there are some other things that execute before cstart (such as checking the integrity of the binary file, to avoid executing random code when loading from a corrupted filesystem). Without further ado, let's dive in:

Code: [Select]
# from QEMU directory (assuming default paths and bash)
. ./export_ml_syms.sh EOSM2.103
./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb

We'll hit the first breakpoint first:
Code: [Select]
Now jump to AUTOEXEC.BIN!!
...
Breakpoint 3, 0x00800000 in _start ()
=> 0x00800000 <_start+0>: 0c 40 8f e2 add r4, pc, #12

Type "continue" ("c") to reach cstart:
Code: [Select]
Breakpoint 4, cstart () at ../../src/reboot.c:215
215     int s = compute_signature((int*)SIG_START, SIG_LEN);

Type "layout src". Now you are debugging on the original source code.

Tip: you can set breakpoints like this:
Code: [Select]
b reboot.c:216
Refer to GDB manual for the stepping commands (https://sourceware.org/gdb/onlinedocs/gdb/Continuing-and-Stepping.html), or use a GDB GUI.

Let's try nemiver:
Code: [Select]
. ./export_ml_syms.sh EOSM2.103
./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S & nemiver --gdb-binary=$(which arm-none-eabi-gdb) --remote="localhost:1234" ../magic-lantern/platform/EOSM2.103/autoexec

(http://a1ex.magiclantern.fm/bleeding-edge/qemu/gdb/nemiver.png)

For some reason, I'm unable to step. Too bad, as it seems to be working for these (https://www.jann.cc/2012/04/14/using_nemiver_for_remote_debugging_on_arm_microcontrollers.html) guys (https://github.com/ajhc/demo-cortex-m3/blob/master/stm32f0-discovery/extra/debug_nemiver.sh). Maybe someone else can figure it out?

Let's try gdbgui (https://github.com/cs01/gdbgui):
Code: [Select]
. ./export_ml_syms.sh EOSM2.103
./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S & gdbgui -g "arm-none-eabi-gdb"

Make sure you view its GUI with Google Chrome and enter this at the gdb prompt:
Code: [Select]
source EOSM2/debugmsg.gdb

(http://a1ex.magiclantern.fm/bleeding-edge/qemu/gdb/gdbgui.png)

This one appears to work a little better, you can run the program step by step using the GUI, but still gives a bunch of errors. Go figure.

cgdb is a terminal-based GUI, but doesn't like QEMU printing debug messages on the same window. Fortunately, nkls provided a script to split the terminal window in two - splitgdb.sh. Replace its contents with something like this:
Code: [Select]
#!/usr/bin/env bash

. ./export_ml_syms.sh $1.$2
tmux new-session -d "./run_canon_fw.sh $1,firmware='boot=1' -s -S"
tmux split-window -h "cgdb -d arm-none-eabi-gdb -x $1/debugmsg.gdb"
tmux attach-session -d

Code: [Select]
./splitgdb.sh EOSM2 103

(http://a1ex.magiclantern.fm/bleeding-edge/qemu/gdb/cgdb.png)


The user interface seems to be very rough though, and it doesn't like our colored debug messages either...

Let's try the "classic" ddd:
Code: [Select]
. ./export_ml_syms.sh EOSM2.103
./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S & ddd --debugger "arm-none-eabi-gdb -x EOSM2/debugmsg.gdb"

This works. The interface is not pretty, but at least it works.

(I've ran EOSM ML on EOSM2 ROM, in case you are wondering)

(http://a1ex.magiclantern.fm/bleeding-edge/qemu/gdb/ddd.png)

Other suggestions?
Title: Re: ML on EOS-M2
Post by: dfort on June 25, 2017, 08:43:42 AM
Code: [Select]
# from ML directory
hg update qemu -C
cd platform/EOSM2.103

Oh I wish. For now I'm having to merge EOSM2.103_wip, qemu-EOSM2-wip_1, qemu-build-tweaks-2 and of course qemu into a qemu-wip branch in order to get all of the pieces working with EOSM2 on a Mac. I'm keeping these separate branches to keep a couple of my pull requests in order. The build tweaks for the Mac (https://bitbucket.org/hudson/magic-lantern/pull-requests/836/qemu-build-tweaks-2/diff) are working nicely as is the EOSM2 QEMU setup (https://bitbucket.org/hudson/magic-lantern/pull-requests/835/qemu-eosm2-preliminary-setup/diff). It will be a happy day for me when these get merged into the qemu branch.  :D

Code: [Select]
Now jump to AUTOEXEC.BIN!!
...
Breakpoint 3, 0x00800000 in _start ()
=> 0x00800000 <_start+0>: 0c 40 8f e2 add r4, pc, #12

Type "continue" ("c") to reach cstart:
Code: [Select]
Breakpoint 4, cstart () at ../../src/reboot.c:215
215     int s = compute_signature((int*)SIG_START, SIG_LEN);

I'm seeing something slightly different probably because I'm working on a different autoexec.bin.

Code: [Select]
Breakpoint 1 at 0x4398
Breakpoint 2 at 0x7360
Breakpoint 3 at 0xff0c5144
Breakpoint 4 at 0x800000
Breakpoint 5 at 0x8646ec: file ../../src/fw-signature.h, line 47.
(gdb) c
Continuing.
...
Now jump to AUTOEXEC.BIN!!
0010E5F4: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
0010E5F4: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D

Breakpoint 4, 0x00800000 in _start ()
(gdb) c
Continuing.

Breakpoint 5, cstart () at ../../src/reboot.c:215
215     int s = compute_signature((int*)SIG_START, SIG_LEN);
(gdb)


Type "layout src". Now you are debugging on the original source code.

Nice! Got the breakpoints tip working too.

(https://c1.staticflickr.com/5/4261/35478510606_404f5f365b_z.jpg)

Let's try nemiver:

Spent too many hours trying to get nemiver working on Mac (building from the source code) but never succeeded.

Moving on to gdbgui. It this one is coded in python and is easy to install on Mac:

Code: [Select]
pip install gdbgui --upgrade
Yeah, easy but it took me a while because the instructions on the project page didn't work for me. Maybe because I'm using the Homebrew python that doesn't need root access to install packages? So if you're on a Mac and followed my ML tutorial (http://www.magiclantern.fm/forum/index.php?topic=16012.0), don't do this:

Code: [Select]
sudo pip install gdbgui --upgrade --user
Now we're on the same page--sort of.

(https://c1.staticflickr.com/5/4254/35387409601_e32971dffb_z.jpg) (https://flic.kr/p/VV4HZK)

It is getting late so I'll skip to ddd:

Code: [Select]
brew tap homebrew/core
brew install ddd

And...
Code: [Select]
Setting BOOTDISK flag to FFFFFFFF
Error: Unresolved inheritance operation

Xt error (Unresolved inheritance operation).

Oops!  You have found a bug in DDD.

If you can reproduce this bug, please send a bug report
to <[email protected]>, giving a subject like

    DDD 3.3.12 (i386-apple-darwin16.3.0) gets Xt error

To enable us to fix the bug, you should include the following information:
* What you were doing to get this message.  Report all the facts.
* The contents of the `~/.ddd/log' file as generated by this session.
Please read also the section "Reporting Bugs" in the DDD manual.

We thank you for your support.

ddd: Cannot save options
[1]   Done                    ./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S

Ugh!

I'll try cgdb tomorrow.
Title: Re: ML on EOS-M2
Post by: dfort on June 25, 2017, 04:46:14 PM
Ok--trying out cgdb. The splitgdb.sh script uses tmux which I already had on my system, don't when I installed it but it is also available from brew as is cgdb:
 
Code: [Select]
brew install cgdb
Wow, this is one is impressive when run in full screen mode.

(https://c1.staticflickr.com/5/4278/35394128311_e41eeddb26_z.jpg) (https://flic.kr/p/VVEaez)

A couple of questions:

Code: [Select]
│Breakpoint 2 at 0x7360     
│Breakpoint 3 at 0xff0c5144 
│Breakpoint 4 at 0x800000   
│Breakpoint 5 at 0x8646ec: file ../../src/fw-signature.h, line 47. 
│(gdb) c                     
│Continuing.                 

│Breakpoint 4, 0x00800000 in _start ()                   
│(gdb) c                     
│Continuing.                 

│Breakpoint 5, cstart () at ../../src/reboot.c:215       
│(gdb) print s               
│$1 = 0xceeeeeec             
│(gdb) print _signature     
│$2 = 0x2d7c6dcf             
│(gdb)   

[EDIT] Never mind, it is showing the EOSM_202 signature I'm using as a temp. Still find myself in a Catch 22 and can't get "hello world" working much less find the firmware signature. That has to be done in camera, right?

Code: [Select]
│Breakpoint 5, cstart () at ../../src/reboot.c:211         
│(gdb) print s               
│No symbol "s" in current context.                         
│(gdb) print _signature       
│No symbol "_signature" in current context.                 
│(gdb)

Continuing from there:

Code: [Select]
DRYOS PANIC: Module Code = 1, Panic Code = 2
Catch 22 -- Need to run "hello world" to get the firmware signature but QEMU doesn't run "hello world" because it can't get the firmware signature. If we could get the firmware signature maybe "hello world" will run on QEMU but then, what's the point?

Is it too early to turn on the camera bootflag? (Not that I have a clue how to do that.)
Title: Re: ML on EOS-M2
Post by: a1ex on June 25, 2017, 05:16:06 PM
Why isn't this version of splitgdb.sh by nkls in the qemu branch?

The version from nkls is there (https://bitbucket.org/hudson/magic-lantern/src/9912f99c674c81c89ee77e81704439c304d753e1/contrib/qemu/scripts/splitgdb.sh?at=qemu&fileviewer=file-view-default). What I wrote above was something I came up with at the time of writing; I didn't use this approach before.

Would be nice to improve it to accept any number of command-line options (and pass all of them to QEMU).

Quote
Is the firmware signature it displayed to be trusted?

Yes, but only after compute_signature() returns. Not before.

The value from my screenshots should be valid, although I have not set up an EOSM2 platform directory yet (so it's untested).

Quote
Oops!  You have found a bug in DDD.

That's too bad - a very powerful piece of software apparently unmaintained for about 8 years...

Quote
DRYOS PANIC: Module Code = 1, Panic Code = 2

That's a good sign - this message can only appear from the main firmware, so we are no longer in bootloader context. Still, probably something went wrong when patching the startup process.

Time to debug what happens between loading autoexec.bin and this message. Some useful tools:
Code: [Select]
-d calls or callstack
-d ramw (RAM writes)
-d autoexec (to avoid verbose messages from the bootloader)

For example, -d autoexec,ramw,calls,io,v should give some very good insights into how the startup code is patched, and why it doesn't work. The log will be huge though, and it will miss the call to copy_and_restart from boot-hack.c (because it's not actually a call, but a direct jump), but will catch the next call (from copy_and_restart to reloc_entry), which looks like this (500D, since that's the binary I happened to have on the virtual card):

Code: [Select]
       (big bunch of zeroing out some RAM - zero_bss)
       (big bunch of copying from ROM to RAM - blob_memcpy)
       [ram] at 0x0004D4D4:000B8818 [0x000BB300] <- 0xE12FFF1E: was 0xEBFFF769;
       [ram] at 0x0004D4DC:000B8818 [0x000B9154] <- 0xCB400   : was 0x4C5C4;
       [ram] at 0x0004D4E4:000B8818 [0x000B8704] <- 0x7E400   : was 0x0;
       [ram] at 0x0004D4FC:000B8818 [0x000B90BC] <- 0xEBCCCAFD: was 0xEB0F6D03;
       [ram] at 0x0004D514:000B8818 [0x000B9144] <- 0xEBBD78E5: was 0xEB001AEB;
       [ram] at 0x0004D51C:000B8818 [0x000B9160] <- 0x4D010   : was 0xFF011DBC;
       call 0xB8824(0, c00003e0, 400, b8824)                                     at [4d560:86ba30] (copy_and_restart)
        [FlashIF] at 0x000B882C:0004D564 [0xC0000010] <- 0xD9C5D9C5: 'Write enable' enabled
        [*unk*] at 0x000B8838:0004D564 [0xC020010C] <- 0x1       : ???
        ...
        (more startup activity follows)

Right before this call, you'll see the patching process (those "hijack" macros - where they go). I can use this log to check if that went well.

Tip: in the qemu branch, in boot-hack.c (but not in minimal.c), there are some startup messages (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-boot-check/QEMU_boot_check_logs/) (qprint*). These are useful - to see them on the QEMU console, compile with CONFIG_QEMU=y from the regular target (not minimal). Binaries compiled in this way will not run on the camera. More about this on the 1300D thread (http://www.magiclantern.fm/forum/index.php?topic=17969.msg185641#msg185641).
Title: Re: ML on EOS-M2
Post by: dfort on June 25, 2017, 05:30:03 PM
The version from nkls is there (https://bitbucket.org/hudson/magic-lantern/src/9912f99c674c81c89ee77e81704439c304d753e1/contrib/qemu/scripts/splitgdb.sh?at=qemu&fileviewer=file-view-default). What I wrote above was something I came up with at the time of writing; I didn't use this approach before.

Would be nice to improve it to accept any number of command-line options (and pass all of them to QEMU).

Yes, but your latest version of splitgdb.sh seems to be working more better.  :D

...I have not set up an EOSM2 platform directory yet (so it's untested).

I have. It obviously isn't finished but it compiles.

https://bitbucket.org/daniel_fort/magic-lantern/branch/EOSM2.103_wip
Title: Re: ML on EOS-M2
Post by: dfort on June 26, 2017, 07:55:05 AM
I'm still inching my way through consts.h and hit another speed bump. Got to YUV422_LV_BUFFER_1,2,3 and looked up the link to the wiki that's in the source code:

Quote
// http://magiclantern.wikia.com/wiki/VRAM_ADDR_from_code
// stateobj_disp[1]

Not sure what stateobj_disp[1] referrers to but determined that the wiki page wants me to run this code on the EOSM2.103:

Code: [Select]
int i;
unsigned int *bmp_ram_addr = bmp_vram_info;
for (i=0; i<2; i++)
  DebugMsg( DM_MAGIC, 3, "bmp_vram[]=0x%08x, 0x%08x, 0x%08x",
    bmp_ram_addr[3*i+0],  bmp_ram_addr[3*i+1], bmp_ram_addr[3*i+2] );
unsigned int *vram_info_addr = vram_info;
for (i=0; i<3; i++)
  DebugMsg( DM_MAGIC, 3, "vram_info[]=0x%08x, w=%4d, h=%4d, p=%4d, n=%4d",
      vram_info_addr[5*i+0],  vram_info_addr[5*i+1],
      vram_info_addr[5*i+2], vram_info_addr[5*i+3], vram_info_addr[5*i+4] );
unsigned int *stateobj_disp = 0x90494+0x128; // see ff137acc SetBitmapVramAddress
DebugMsg( DM_MAGIC, 3, "stateobj_disp+0xb0[]=0x%08x,0x%08x,0x%08x,",
  stateobj_disp[0], stateobj_disp[1], stateobj_disp[2]);

I was able to figure out the changes to the code but not sure where to run it--probably in "Don't click me?" (run_test in src/debug.c) However, that seems to be something that needs to be run in the camera, or can it be done in QEMU? Also not having much luck getting the firmware signature in QEMU, seems like I'm at the point of being able to run "Hello world" on the camera but can't seem to be able to get it working in QEMU. (I also tend to use "seem" way too much.)

The unexpected  benefactor of this port is the original EOSM as I keep finding blips in the code (http://www.magiclantern.fm/forum/index.php?topic=9741.msg186289#msg186289) for that platform.
Title: Re: ML on EOS-M2
Post by: a1ex on June 26, 2017, 11:00:55 AM
60D in QEMU (from don't click me):

Code: [Select]
. ./export_ml_syms.sh 60D.111 # needed for DebugMsg
./run_canon_fw.sh 60D,firmware="boot=1" -d debugmsg
...
[    run_test:1fe0bc9c ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000000, 0x03f87100
[    run_test:1fe0bcc0 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000000, 0x03f87100
[    run_test:1fe0bce8 ] (32:03) stateobj_disp+0xbc[]=0x43f80008,0x5c307800,0x40a8e470,

From real camera (the easiest way was to use printf):
Code: [Select]
# 60D 1.1.1, 0x2458+0xBC
bmp_vram[]=0xc0f140d0, 0x00000000, 0x03f87100
bmp_vram[]=0xc0f140d4, 0x00000000, 0x03f87100
stateobj_disp+0xbc[]=0x43f80008,0x41b07800,0x48a902c4

In both cases, stateobj_disp[1] shows a valid address for the image buffer. It's not always the same; on this model there are 3 possible addresses; they are not fixed (as we thought in early days) but allocated dynamically. In many cases (but not always), this dynamic allocation gives the same results every time, so hardcoding the image buffer addresses usually works. This area really needs some cleanup (wip here (https://bitbucket.org/hudson/magic-lantern/branch/yuv_buffers)).

However, D5 models don't seem to work that well in QEMU:

Code: [Select]
# 5D3 1.1.3, 0x246A4+0x118, regular photo mode
[    run_test:000753ec ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000000, 0x00dc3100
[    run_test:00075410 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000000, 0x00dc3100
[    run_test:00075438 ] (32:03) stateobj_disp+0x118[]=0x40dbc008,0x00000000,0x40881520,

# 5D3 1.1.3, 0x246A4+0x118, playback mode (not exactly working well in QEMU)
[    run_test:000753ec ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000000, 0x00d43100
[    run_test:00075410 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000000, 0x00d43100
[    run_test:00075438 ] (32:03) stateobj_disp+0x118[]=0x00000000,0x40881414,0x00000000,

# 700D 1.1.4, 0x23C20+0x118 (in QEMU it starts in movie mode and asks for a lens)
[     ml_init:0007f1d0 ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000000, 0x01307100
[     ml_init:0007f1f4 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000000, 0x01307100
[     ml_init:0007f21c ] (32:03) stateobj_disp+0x118[]=0x41300008,0x00000000,0x4092e400,

# 700D 1.1.4, 0x23C20+0x118, playback mode
[     ml_init:0007f1ec ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000000, 0x01387100
[     ml_init:0007f210 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000000, 0x01387100
[     ml_init:0007f238 ] (32:03) stateobj_disp+0x118[]=0x41380008,0x00000000,0x4092e3a8

# EOSM 2.0.2, 0x3E650+0x114 (no GUI in QEMU)
[     ml_init:0009e70c ] (32:03) bmp_vram[]=0xc0f140d0, 0x00000001, 0x01387100
[     ml_init:0009e730 ] (32:03) bmp_vram[]=0xc0f140d4, 0x00000001, 0x01387100
[     ml_init:0009e758 ] (32:03) stateobj_disp+0x114[]=0x41380008,0x00000000,0x00000000,

In 5D3 1.1.3 playback, there is some nonzero value, but I don't recognize it as a display buffer address (it might be correct), while on 700D and EOSM I've only got 0 in QEMU. Probably that's the current state of the emulation.

In any case, this test does not reveal any new addresses, so you don't really need to run it; matching the stub with other models should be enough.
Title: Re: ML on EOS-M2
Post by: dfort on June 27, 2017, 11:31:31 PM
In any case, this test does not reveal any new addresses, so you don't really need to run it; matching the stub with other models should be enough.

This is proving to be a devilishly difficult stub to ferret out of the disassembly. I found only one match in one of my EOSM.202 disassemblies:

Code: [Select]
"[LVEVF] evVdInterrupt LastRamClear Start!![4f1d7800]":
That matches the first of the three buffers I'm searching for:

Code: [Select]
#define YUV422_LV_BUFFER_1 0x4F1D7800
#define YUV422_LV_BUFFER_2 0x4F5E7800
#define YUV422_LV_BUFFER_3 0x4F9F7800

Though it is sort of a dead end because all the other models, including the EOSM2 shows this:

Code: [Select]
"evVdInterrupt LastRamClear Start!![%lx]":
There's a lot of "0x40000000" all over the disassemblies and maybe that's a clue?

I'm probably on the wrong path but I searched through the forum and wiki and came up empty handed. Also don't know if I should be pressing forward finding stubs or if I should try to get "Hello world" working in QEMU in order to find the firmware signature.

In any case, I'll keep searching.
Title: Re: ML on EOS-M2
Post by: a1ex on June 28, 2017, 12:16:01 AM
Couldn't find it from LastRamClear Start, but this (http://www.magiclantern.fm/forum/index.php?topic=9741.msg186291#msg186291) does apply to both M and M2.
Title: Re: ML on EOS-M2
Post by: dfort on June 28, 2017, 05:23:37 AM
I can see the hint near ImageEffect that shows the values for YUV422_LV_BUFFER_DISPLAY_ADDR but I'm still clueless where to find YUV422_LV_BUFFER_1,2,3.

I'll keep going and get back to this later, maybe it will become obvious the second time around.
Title: Re: ML on EOS-M2
Post by: a1ex on June 28, 2017, 08:26:05 AM
Ah, right. I've found one in QEMU - 0x4f3d7800. You could use that value for all of them, as a workaround.

I've found it by pressing P to go to play mode, then printing the contents of 0x90494+0x12C in gdb. I was lucky, as this didn't work on the other D5 models I've tried before (double-checked today, still no luck there).

I've deleted the YUV422_(LV|HD)* constants locally, but there are some bits of code that had to be updated (on the yuv_buffers branch mentioned before, merged with new-lv-buffer-detection - which attempts to autodetect these addresses at runtime, rather than using hardcoded values). Unfortunately, the current state is "compiles, but doesn't work" (after more than half a day of fiddling with it), and I doubt I'll be able to fix it today.
Title: Re: ML on EOS-M2
Post by: dfort on June 30, 2017, 04:50:13 PM
Progressing slowly.

Some of the stubs and constants have hints that include which two numbers to add together to get the value we're looking for. This helps when stub hunting by pattern matching.

For example, in consts.h I think I may have found these for the EOSM2.103:

Code: [Select]
#define CURRENT_GUI_MODE (*(int*)0x928BC) // in SetGUIRequestMode
#define ISO_ADJUSTMENT_ACTIVE ((*(int*)0x96388) == 0xF) // dec ptpNotifyOlcInfoChanged and look for: if arg1 == 1: MEM(0x79B8) = *(arg2)

But it is easier to check against the disassembly if we write them out like this:

Code: [Select]
#define CURRENT_GUI_MODE (*(int*)(0x92860+0x5C)) // in SetGUIRequestMode
#define ISO_ADJUSTMENT_ACTIVE ((*(int*)(0x96338+0x50)) == 0xF) // dec ptpNotifyOlcInfoChanged and look for: if arg1 == 1: MEM(0x79B8) = *(arg2)

I'm not sure if ISO_ADJUSTMENT_ACTIVE is valid on the EOSM2 because it is missing on the EOSM. From what I can figure out the EOSM should be this:

Code: [Select]
#define ISO_ADJUSTMENT_ACTIVE ((*(int*)(0x4BE28+0x44)) == 0xF) // dec ptpNotifyOlcInfoChanged and look for: if arg1 == 1: MEM(0x79B8) = *(arg2)

On the 100D it is commented out:

Code: [Select]
// #define ISO_ADJUSTMENT_ACTIVE ((*(int*)(0x6B930)) == 0xF)       // dec ptpNotifyOlcInfoChanged and look for: if arg1 == 1: MEM(0x79B8) = *(arg2)
but maybe the problem is because it is the wrong value? Shouldn't it be 0x6B860 instead of 0x6B930? Easier to check the disassembly if it is written like this:

Code: [Select]
#define ISO_ADJUSTMENT_ACTIVE ((*(int*)(0x6B810+0x50)) == 0xF)       // dec ptpNotifyOlcInfoChanged and look for: if arg1 == 1: MEM(0x79B8) = *(arg2)
I'm not sure how to "look for: if arg1 == 1: MEM(0x79B8) = *(arg2)" or if I'm even on the right track here but this does fit into a pattern using the values from the 5D3.113 and 700D.114.
Title: Re: ML on EOS-M2
Post by: nikfreak on June 30, 2017, 05:12:04 PM
For firmware 1.01 on 100D it's like you found out:

Code: [Select]
#define ISO_ADJUSTMENT_ACTIVE ((*(int*)(0x6B810+0x50)) == 0xF)
I am unsure myself why it's commented out but the "wrong" value was correct one of the older A/B/C revision on 1.00 firmware. I was mainly doing copy&paste for the revisions as well while upgrading support for fw 1.01. Anyways thx for pointing it out as it has tbd for 70D too (942C0+50).

Quote
// dec ptpNotifyOlcInfoChanged and look for: if arg1 == 1: MEM(0x79B8) = *(arg2)

that's also copy&paste from one of the older supported cams.
Title: Re: ML on EOS-M2
Post by: dfort on July 01, 2017, 07:25:35 PM
I don't want to come off like a little kid asking "why" all the time but as I'm working my way through consts.h some things pique my curiosity.

MOV_RES_AND_FPS_COMBINATIONS

Found this constant used in bitrate.c:
Code: [Select]
    for (i = 0; i < MOV_RES_AND_FPS_COMBINATIONS; i++) // 7 combinations of resolution / fps

Makes sense because these are all the possible settings I could come up with:

1-192024NTSC/PAL
2-192025PAL
3-192030NTSC
4-128050PAL
5-128060NTSC
5-64025PAL
7-64030NTSC

However, this is what is in consts.h:

5D3.113
Code: [Select]
#define MOV_RES_AND_FPS_COMBINATIONS 5 // 3 fullhd, 2 hd, not changing the two VGA modes; worth trying with 9

100D.101
Code: [Select]
#define MOV_RES_AND_FPS_COMBINATIONS 4 // 2FHD, 1HD, 1VGA

700D.114, EOSM.202
Code: [Select]
#define MOV_RES_AND_FPS_COMBINATIONS 9
Ok--so on the 5D3 we aren't messing around with the VGA modes but the 100D should have the same combinations as the other cameras and how do you come up with 9 combinations? 1920/24 is available in both NTSC and PAL so that might give you 8 but where's the final combination?

HALFSHUTTER_PRESSED

The hint is to look for string "[MC] permit LV instant", it's the struct referenced in this function. I can find "[MC] permit LV instant" in the disassemblies of all the cameras except the EOSM2. There is a function named "LvPermit(DelivLvLock)" that might be what replaced it but I can't be sure. How to figure this out? Is it possible to do a half-shutter press in QEMU?

[EDIT] Off topic but on the 700D:

Code: [Select]
#define AE_STATE (*(int8_t*)(0x366B8 + 0x1C))
#define AE_VALUE (*(int8_t*)(0x366B8 + 0x1D))

Shouldn't it be?

Code: [Select]
#define AE_STATE (*(int8_t*)(0x366B4 + 0x1C))
#define AE_VALUE (*(int8_t*)(0x366B4 + 0x1D))

I've got a 700D but not sure how to check this.
Title: Re: ML on EOS-M2
Post by: nikfreak on July 01, 2017, 08:16:47 PM
100D is crippled by Canon. It really only has 4 movie modes to select in Canon menu and this camera even profits from the bitrate modifications as it has no ALL-I option by default  :P 700D should have same amount of movie modes as 650D.

Take this for 700D.114:
Code: [Select]
#define AE_STATE (*(int8_t*)(0x367B4 + 0x1C))
#define AE_VALUE (*(int8_t*)(0x367B4 + 0x1D))
...


#define HALFSHUTTER_PRESSED (*(int*)0x24884) is ok [0x2486C+0x18].
Title: Re: ML on EOS-M2
Post by: a1ex on July 01, 2017, 08:34:21 PM
MVR: see platform/include/mvr.h - some of them are commented. Basically, look up these functions in the firmware and map (or verify) the offsets in the mvr_config structure.

On recent models, there are some gaps (2 positions) between 720p and VGA modes. Not sure what's up with them and whether they are used or not (I'll find out in QEMU, if I'll ever manage to emulate LiveView and video recording - light years from current state). I tend to say we should update all of them to 5, to be on the safe side (so bitrate adjustment won't overwrite memory locations we are unsure about), even if that will leave the VGA modes uncovered.

That 4 on 100D is probably a mistake (thanks for pointing out, as I didn't notice it when looking at the PR). I bet bitrate control doesn't work in 50p mode, but works on 60 (or maybe the other way).

[MC] permit LV instant - all D4 and D5 models have it.

Half-shutter support in QEMU is very incomplete (https://bitbucket.org/hudson/magic-lantern/commits/a55cd409ee1e5374c116ca9305dd1402fc530625).

The AE_VALUEs are for the autoexpo module. Not sure how to use it, couldn't figure it out...
Title: Re: ML on EOS-M2
Post by: JohanJ on July 01, 2017, 08:38:32 PM
100D is crippled by Canon. It really only has 4 movie modes to select in Canon menu

In fact all 7 modes are available also from canon menu, just that only the ones fitting to the chosen video mode (PAL/NTSC) are shown.

[EDIT] On 60D there are 2 additional VGA modes Crop 640x480 NTSC and Crop 640x480 PAL. So here you get in  total 9. Just an idea (even though it is another cam generation)
Title: Re: ML on EOS-M2
Post by: dfort on July 01, 2017, 11:55:24 PM
On 60D there are 2 additional VGA modes Crop 640x480 NTSC and Crop 640x480 PAL. So here you get in  total 9. Just an idea (even though it is another cam generation)

Right, and with FEATURE_CROP_MODE_HACK it adds crop modes to 1920/24 and 25 so that does get 9 possible MOV_RES_AND_FPS_COMBINATIONS. However, it looks like maybe it should be changed to 5 for the reasons that a1ex noted. I'll leave it at 9 on the EOSM2 for now and follow along with any changes to the other cameras.

...
Take this for 700D.114:
...
#define HALFSHUTTER_PRESSED (*(int*)0x24884) is ok [0x2486C+0x18].

That's a clue that got me closer.
5D3[0x251C4+0x10]
100D[0x6674C+0x18]
700D[0x2486C+0x18]
EOSM[0x3F204+0x20]
EOSM2[0x910A8+0x??]

[MC] permit LV instant - all D4 and D5 models have it.

Pretty sure that on the EOSM2 disassembly it shows up as - judge_permit_lv.

Take this for 700D.114:
Code: [Select]
#define AE_STATE (*(int8_t*)(0x367B4 + 0x1C))
#define AE_VALUE (*(int8_t*)(0x367B4 + 0x1D))
...


That's right--my bad.

The AE_VALUEs are for the autoexpo module. Not sure how to use it, couldn't figure it out...

Hokey Smoke!

autoexpo.mo on 700D
(https://farm5.staticflickr.com/4211/35488279622_e6fc748a5a.jpg)

Don't want to get into this right now but maybe this is something that should be looked into:
Issue #2643 Cannot get module autoexpo to work on EOS 700d (https://bitbucket.org/hudson/magic-lantern/issues/2643/cannot-get-module-autoexpo-to-work-on-eos)

[EDIT] Issue with autoexpo.mo on 700D mentioned here:

Hello,

I have download this module for the 700D and it doesn't work.

Then I will instal cygwin and check out the code source and after read this post, see by debug that the AE_STATE is never set (always 0).
So I change the consts.h file for the 700D platform in replacement of the constants AE_STATE ans VALUE as written somewhere in a topic page after having check in hexa code. It will be then the following :

#define EXPO_COMP (*(int16_t*)(0x367B4+0x1C))
#define AE_VALUE (EXPO_COMP-1) * 8 / 2048
#define AE_STATE (*(int8_t*)(0x367B4+0x1C))

It works (I check by printing the values of ae, iso, and so on).

I can check in if you want.

Just a question, what it is the use of AE_STATE ?

Xav
Title: Re: ML on EOS-M2
Post by: Licaon_Kter on July 02, 2017, 12:22:36 AM
But you can't use autoexpo.mo anyway on M/M2 because you don't have (one) more hardware buttons, right?
Title: Re: ML on EOS-M2
Post by: dfort on July 02, 2017, 01:49:25 AM
Which buttons are missing?

autoexpo.mo appears to be working on the EOSM though I have no idea how to work it.

There are lots of reports of it not working on the 700D and it looks like there is a solution to that.
Title: Re: ML on EOS-M2
Post by: a1ex on July 02, 2017, 08:39:12 AM
Quote
Pretty sure that on the EOSM2 disassembly it shows up as - judge_permit_lv.

Right - it does the same thing.

Pressing half-shutter in QEMU gives plenty of info regarding this event (enough to identify this address, but not enough to change things on the user interface or pass the API tests):
Code: [Select]
Key event: 2a -> 0e0e002d
[MPU] Sending : 06 05 06 26 01 00
[    PowerMgr:ff1470d4 ] (00:01) <0 0 0 0 0 0 7> [PM] DisablePowerSave (Counter = 2)
[    PowerMgr:ff147144 ] (00:01) <0 0 0 0 0 0 7> [PM] EnablePowerSave (Counter = 1)
[    MainCtrl:ff0d01c0 ] (9c:01) <0 0 0 0 0 0 7> ID:26(30)
[    MainCtrl:ff0cd8ac ] (89:03) <0 0 0 0 0 0 7> bindReceiveSwitch (38, 1)
[    MainCtrl:ff0cdd88 ] (89:03) <0 0 0 0 0 0 7> COM_SW_SOMETHING
[    MainCtrl:ff0d8ba0 ] (85:03) <0 0 0 0 0 0 7> GUI_Control:84 0x0
[ GuiMainTask:ff0d8f54 ] (84:01) <0 0 0 0 0 0 7> GUI_CONTROL:84
[MPU] Sending : 06 04 05 00 00 00
[ GuiMainTask:ff1470d4 ] (00:01) <0 0 0 0 0 0 7> [PM] DisablePowerSave (Counter = 2)
[ GuiMainTask:ff147144 ] (00:01) <0 0 0 0 0 0 7> [PM] EnablePowerSave (Counter = 1)
[ GuiMainTask:ff1c0728 ] (84:03) <0 0 0 0 0 0 7> GUICMD_PRESS_BUTTON_SOMETHING(0x0)
[    EventMgr:ff224a04 ] (8d:01) <0 0 0 0 0 0 7> emDeliverMulticastEvent : SW1ON
[    MainCtrl:ff0d01c0 ] (9c:01) <0 0 0 0 0 0 7> ID:0(31)
[    MainCtrl:ff154660 ] (9c:03) <0 0 0 0 0 0 7> MeteringStart
[    MainCtrl:ff3da3b0 ] (c0:03) <1 0 0 0 0 0 7> MainCtrl GuiCancelMoviePlay(4151)
[    MainCtrl:ff3e3814 ] (c0:02) <1 0 0 0 0 0 7> [G_P]PC:0xff3e3804 LR:0xff154718 SP:0x197f38
[    MainCtrl:ff0dffe4 ] (2c:03) <1 0 0 0 0 0 7> MVP_CancelMoviePlay
[    MainCtrl:ff0d8ba0 ] (85:03) <1 0 0 0 0 0 7> GUI_Control:80 0x0
[    MainCtrl:ff1549a4 ] (89:03) <1 0 0 0 0 0 7> EVENTID_METERING_START
[      RscMgr:ff0e87dc ] (80:02) <1 0 0 0 0 0 7> srmEventDispatch: Current = 0, dwEventID = 12, dwParam = -442503148 S
[      RscMgr:ff0e89e4 ] (80:02) <1 0 0 0 0 0 7> srmEventDispatch: Current = 0, dwEventID = 12, dwParam = -442503148 E
[ GuiMainTask:ff1c1880 ] (84:01) <1 0 0 0 0 0 7> gui control end
[ GuiMainTask:ff1c18a0 ] (84:01) <1 0 0 0 0 0 7> 0msec = 47810 - 47810
[ GuiMainTask:ff1c18bc ] (84:01) <1 0 0 0 0 0 7> 3584msec = 776448 - 780032
[ GuiMainTask:ff0d8f54 ] (84:01) <1 0 0 0 0 0 7> GUI_CONTROL:80
[ GuiMainTask:ff1c1880 ] (84:01) <1 0 0 0 0 0 7> gui control end
[ GuiMainTask:ff1c18a0 ] (84:01) <1 0 0 0 0 0 7> 0msec = 47810 - 47810
[ GuiMainTask:ff1c18bc ] (84:01) <1 0 0 0 0 0 7> 0msec = 780544 - 780544
[     CtrlSrv:ff3ab264 ] (83:03) <1 0 0 0 0 0 7> IDLEHandler PRESS_SW1_BUTTON
[    Fstorage:ff1c8fac ] (9e:03) <1 0 0 0 0 0 7> fssSW1On

[         CEC:ff347750 ] (c2:01) <1 0 0 0 0 0 7> cecCompleteStart Start
[         CEC:ff357118 ] (00:26) <1 0 0 0 0 0 7> [I2C] localI2C_Read : 378 (Task : CEC)
   980: 47851.520 WARN [I2C] localI2C_Read : 378 (Task : CEC)
[         CEC:ff347750 ] (c2:01) <1 0 0 0 0 0 7> cecCompleteStart Start
[         CEC:ff357118 ] (00:26) <1 0 0 0 0 0 7> [I2C] localI2C_Read : 378 (Task : CEC)
   981: 47868.416 WARN [I2C] localI2C_Read : 378 (Task : CEC)
[         CEC:ff347750 ] (c2:01) <1 0 0 0 0 0 7> cecCompleteStart Start
[         CEC:ff357118 ] (00:26) <1 0 0 0 0 0 7> [I2C] localI2C_Read : 378 (Task : CEC)
   982: 47888.640 WARN [I2C] localI2C_Read : 378 (Task : CEC)

Key event: aa -> 0e0e002e
[MPU] Sending : 06 04 05 0b 00 00
[    PowerMgr:ff1470d4 ] (00:01) <1 0 0 0 0 0 7> [PM] DisablePowerSave (Counter = 2)
[    PowerMgr:ff147144 ] (00:01) <1 0 0 0 0 0 7> [PM] EnablePowerSave (Counter = 1)
[    EventMgr:ff224b7c ] (8d:01) <1 0 0 0 0 0 7> emDeliverMulticastEvent : SW1OFF
[    MainCtrl:ff0d01c0 ] (9c:01) <1 0 0 0 0 0 7> ID:B(32)
[    MainCtrl:ff154748 ] (9c:03) <1 0 0 0 0 0 7> MeteringTimerStart
[    MainCtrl:ff0d8ba0 ] (85:03) <0 0 0 0 0 0 7> GUI_Control:81 0x0
[    MainCtrl:ff1549a4 ] (89:03) <0 0 0 0 0 0 7> EVENTID_METERING_TIMER_START
[      RscMgr:ff0e87dc ] (80:02) <0 0 0 0 0 0 7> srmEventDispatch: Current = 0, dwEventID = 13, dwParam = -442503148 S
[      RscMgr:ff0e89e4 ] (80:02) <0 0 0 0 0 0 7> srmEventDispatch: Current = 0, dwEventID = 13, dwParam = -442503148 E
[ GuiMainTask:ff0d8f54 ] (84:01) <0 0 0 0 0 0 7> GUI_CONTROL:81
[ GuiMainTask:ff1c1880 ] (84:01) <0 0 0 0 0 0 7> gui control end
[ GuiMainTask:ff1c18a0 ] (84:01) <0 0 0 0 0 0 7> 0msec = 47880 - 47880
[ GuiMainTask:ff1c18bc ] (84:01) <0 0 0 0 0 0 7> 0msec = 844032 - 844032
[     CtrlSrv:ff3ab2f4 ] (83:03) <0 0 0 0 0 0 7> IDLEHandler UNPRESS_SW1_BUTTON
[         CEC:ff347750 ] (c2:01) <0 0 0 0 0 0 7> cecCompleteStart Start
[         CEC:ff357118 ] (00:26) <0 0 0 0 0 0 7> [I2C] localI2C_Read : 378 (Task : CEC)

The additional values are the ones found in that function:
Code: [Select]
    APPEND("(%02x:%02x) <%x %x %x %x %x %x %x> ", r0, r1, MEM(0x910C8), MEM(0x910CC), MEM(0x910D4), MEM(0x910F8), MEM(0x910FC), MEM(0x91100), MEM(0x91178));
Code: [Select]
static uint32_t MEM(uint32_t addr)
{
    uint32_t buf;
    cpu_physical_memory_read(addr, &buf, sizeof(buf));
    return buf;
}

Therefore, the first one is what we are looking for (the one compared to 1 in the code).

This gives another hint to find half-shutter state: MeteringStart and MeteringTimerStart. I knew it was related to EVENTID_METERING_START / EVENTID_METERING_TIMER_START, but I didn't know where exactly it was set - this one was found with the mem_spy tool (now a module), that monitors memory addresses to find "interesting" changes.

To quote g3gg0:

... would have saved a lot of work if we had that earlier :D

P.S. Here's an easy coding task - print the name of the buttons in the logs.
Title: Re: ML on EOS-M2
Post by: Licaon_Kter on July 02, 2017, 06:40:16 PM
Which buttons are missing?

autoexpo.mo appears to be working on the EOSM though I have no idea how to work it.
Looks ok now though, you can change lower limits with left-right and upper values with rotating wheel, strange that (IIRC) this was not possible in the past, albeit the sourcode was not modified since forever.  :-\ ::) :o
Title: Re: ML on EOS-M2
Post by: dfort on July 03, 2017, 06:49:25 PM
Oh where oh where has my little fonts gone?

Been here before (http://www.magiclantern.fm/forum/index.php?topic=18957.0) and thought I had my head wrapped around the solution but probably not so let's start from scratch.

There is a block of font addresses in consts.h. Let's look at what you would think would be the closest cousin to the EOSM2 -- the EOSM:

Code: [Select]
// http://magiclantern.wikia.com/wiki/Fonts
#define BFNT_CHAR_CODES    0xffcb9c04
#define BFNT_BITMAP_OFFSET 0xffcbcb88
#define BFNT_BITMAP_DATA   0xffcbfb0c

The base address of DIGIC 5 cameras like the EOSM2 (and EOSM, 700D, 100D, etc.) is 0xFF0C0000 and addresses greater than the base address should show up in the ROM1.BIN disassembly. In fact it is quite easy to find where the fonts are in the disassembly because of strings like "HCanonGothic" and "CanonMonospace".

However, here is where the EOSM2 differs from its closest cousins. The fonts are located in ROM0.BIN like the 5D3.

If you follow the wikia link it will eventually lead you to a python script named find_fnt.py. A copy of that script is also located in magic-lantern/contrib/indy/. What it can do is display the font information buried in ROM0.BIN. The script was written back in the day when DIGIC 4 cameras were the norm so it assumes the base address is 0xFF010000 but it can accept a different address via a command line argument. Let's try it out on the EOSM2.

python find_fnt.py ROM0.BIN ff0c0000
Code: [Select]
Find bitmap fonts in Canon DSLR firmwares
Arm.Indy. based on work by Pel, Trammel Hudson and A1ex

0xff1e4838: FNT
0xff1e483c: (+0x04) 0xffd8
0xff1e483e: (+0x06) font_width = 40
0xff1e4840: (+0x08) charmap_offset = 0x24
0xff1e4844: (+0x0c) charmap_size = 0x31b4
0xff1e4848: (+0x10) bitmap_size = 0x8ab3e
0xff1e484c: (+0x14) font name = 'HCanonGothic///'
0xff1e485c: (+0x24) char_codes[]. 3181 chars
0xff1e7a10: (+0x31d8) offsets[]. Last offset value = 0x8ab08
0xff1eabc4: (+0x638c) bitmaps[]
  0xff2756cc: (+0x90e94) last bitmap
  +0x00: bitmap width = 28
  +0x02: bitmap height = 28
  +0x04: char width = 36
  +0x06: X offset = 4
  +0x08: Y offset = 16
    bitmap size = 0x70

0xff275704: FNT
0xff275708: (+0x04) 0xffd8
0xff27570a: (+0x06) font_width = 40
0xff27570c: (+0x08) charmap_offset = 0x24
0xff275710: (+0x0c) charmap_size = 0x188
0xff275714: (+0x10) bitmap_size = 0x31c4
0xff275718: (+0x14) font name = 'CanonMonospace'
0xff275728: (+0x24) char_codes[]. 98 chars
0xff2758b0: (+0x1ac) offsets[]. Last offset value = 0x3142
0xff275a38: (+0x334) bitmaps[]
  0xff278b7a: (+0x3476) last bitmap
  +0x00: bitmap width = 22
  +0x02: bitmap height = 22
  +0x04: char width = 22
  +0x06: X offset = 0
  +0x08: Y offset = 0
    bitmap size = 0x42

Now the EOSM2 is showing that it is also different from the 5D3 because the 5D3 shows each block twice at different addresses which allows you to easily figure out the ROM0 size.

Last time I searched for fonts was on the 5D3.134 firmware update (http://www.magiclantern.fm/forum/index.php?topic=18966.0) and I didn't have QEMU working but now that I do I can check out the ROM layout (http://www.magiclantern.fm/forum/index.php?topic=6785.msg58899#msg58899):

EOSM2
Code: [Select]
F0000000 - F0FFFFFF: eos.rom0
F1000000 - F1FFFFFF: eos.rom0_mirror
F2000000 - F2FFFFFF: eos.rom0_mirror
F3000000 - F3FFFFFF: eos.rom0_mirror
F4000000 - F4FFFFFF: eos.rom0_mirror
F5000000 - F5FFFFFF: eos.rom0_mirror
F6000000 - F6FFFFFF: eos.rom0_mirror
F7000000 - F7FFFFFF: eos.rom0_mirror
F8000000 - F8FFFFFF: eos.rom1
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

So that means instead of using an address that starts at 0xFF we need to use 0xF[0-7] for ROM0 addresses. The 5D3 uses 0xF7 so let's use that for the EOSM2:

EOSM2
Code: [Select]
// http://magiclantern.wikia.com/wiki/Fonts
#define BFNT_CHAR_CODES    0xf71e485c
#define BFNT_BITMAP_OFFSET 0xf71e7a10
#define BFNT_BITMAP_DATA   0xf71eabc4

Oops--there is something wrong here. How do I know? Because on the 5D3 find_fnt.py shows this:

python find_fnt.py ROM0.BIN ff0c0000
Code: [Select]
0xff423a50: (+0x24) char_codes[]. 3165 chars
And the addressed used in consts.h is:
Code: [Select]
#define BFNT_CHAR_CODES    0xF7363A50
Revisiting the last time I ventured into the font rabbit hole:

Therefore, 0xF[0-7][3B]63A50 should all be valid choices for BFNT_CHAR_CODES.

[3B]?

So confused -- why doesn't find_fnt.py just spit out the right numbers?
Title: Re: ML on EOS-M2
Post by: a1ex on July 03, 2017, 07:24:38 PM
So confused -- why doesn't find_fnt.py just spit out the right numbers?

It does - try this:
Code: [Select]
python find_fnt.py ROM0.BIN 0xF0000000
Title: Re: ML on EOS-M2
Post by: dfort on July 03, 2017, 09:12:39 PM
python find_fnt.py ROM0.BIN 0xF0000000
Code: [Select]
Find bitmap fonts in Canon DSLR firmwares
Arm.Indy. based on work by Pel, Trammel Hudson and A1ex

0xf0124838: FNT
0xf012483c: (+0x04) 0xffd8
0xf012483e: (+0x06) font_width = 40
0xf0124840: (+0x08) charmap_offset = 0x24
0xf0124844: (+0x0c) charmap_size = 0x31b4
0xf0124848: (+0x10) bitmap_size = 0x8ab3e
0xf012484c: (+0x14) font name = 'HCanonGothic///'
0xf012485c: (+0x24) char_codes[]. 3181 chars
0xf0127a10: (+0x31d8) offsets[]. Last offset value = 0x8ab08
0xf012abc4: (+0x638c) bitmaps[]
  0xf01b56cc: (+0x90e94) last bitmap
  +0x00: bitmap width = 28
  +0x02: bitmap height = 28
  +0x04: char width = 36
  +0x06: X offset = 4
  +0x08: Y offset = 16
    bitmap size = 0x70

0xf01b5704: FNT
0xf01b5708: (+0x04) 0xffd8
0xf01b570a: (+0x06) font_width = 40
0xf01b570c: (+0x08) charmap_offset = 0x24
0xf01b5710: (+0x0c) charmap_size = 0x188
0xf01b5714: (+0x10) bitmap_size = 0x31c4
0xf01b5718: (+0x14) font name = 'CanonMonospace'
0xf01b5728: (+0x24) char_codes[]. 98 chars
0xf01b58b0: (+0x1ac) offsets[]. Last offset value = 0x3142
0xf01b5a38: (+0x334) bitmaps[]
  0xf01b8b7a: (+0x3476) last bitmap
  +0x00: bitmap width = 22
  +0x02: bitmap height = 22
  +0x04: char width = 22
  +0x06: X offset = 0
  +0x08: Y offset = 0
    bitmap size = 0x42

So this should work?

Code: [Select]
// http://magiclantern.wikia.com/wiki/Fonts
#define BFNT_CHAR_CODES    0xf012485c
#define BFNT_BITMAP_OFFSET 0xf0127a10
#define BFNT_BITMAP_DATA   0xf012abc4

In addition 0xF[0-7] can be used so 0xf712485c, etc. will make it look more like the 5D3 and 5D2 addresses used in consts.h.

Wow, talk about overcomplicating things. So I guess my mistake was using the wrong base address--but isn't the base address for the EOSM2 0xFF0C0000?

Just for fun (yeah, this is fun) I tried a DIGIC 4 camera that has the fonts in ROM0 -- the 5D2. We want to get to this:

Code: [Select]
#define BFNT_CHAR_CODES    0xf7c5E9C0
Running "python find_fnt.py ROM0.BIN" returns 0xff06e9c0 which wouldn't work but "python find_fnt.py ROM0.BIN 0xF0c00000" returns 0xf0c5e9c0 which is equivalent to 0xf7c5E9C0. (There's mixed upper/lower case in the 5D2 code but that shouldn't matter.)

So what's up with this?

Code: [Select]
if (len(sys.argv)>2):
  base = int(sys.argv[2], 16)
else:
  base = 0xff010000

I thought that was supposed to work with DIGIC 4 cameras.

P.S. Here's an easy coding task - print the name of the buttons in the logs.

You mean in the mem_spy module interpret the button codes to print out the names of the buttons?
Title: Re: ML on EOS-M2
Post by: a1ex on July 03, 2017, 09:50:39 PM
... that script assumes the ROM dump loads at 0xff010000 (this was the main firmware start address for DIGIC 4 models, so in the early days, ROM files were saved from that address)

Meaning: the script expects the address where the ROM file was dumped from; it doesn't care where the main firmware starts inside that ROM.

Quote
You mean in the mem_spy module interpret the button codes to print out the names of the buttons?

No, that's complicated. What I meant was about QEMU logs (the user interface side) - instead of "Key event: 2a -> 0e0e002d", print something human-readable.

Mapping button codes to names is doable as well; it's done in ARM-console to some extent (bgmt command), but should probably be rewritten with unicorn (http://www.unicorn-engine.org) instead (similar to extract_button_codes.py). That requires some low-level knowledge though.
Title: Re: ML on EOS-M2
Post by: dfort on July 03, 2017, 10:36:36 PM
Got it...I think.

boot-hack.c
Code: [Select]
static void backup_rom_task()
{
    backup_region("ML/LOGS/ROM1.BIN", 0xF8000000, 0x01000000);
    backup_region("ML/LOGS/ROM0.BIN", 0xF0000000, 0x01000000);
}

Shouldn't all of the new ROM dumps be saved at these addresses? If that's the case find_fnt.py should probably be updated to:

Code: [Select]
if (len(sys.argv)>2):
  base = int(sys.argv[2], 16)
else:
  base = 0xf0000000

I suppose that the ROM dumpers also use these addresses?

In any case...moving on.

...QEMU logs...instead of "Key event: 2a -> 0e0e002d", print something human-readable.

You mean like "Key event: 2a -> 0e0e002d (half-shutter press)", "Key event: aa -> 0e0e002e (half-shutter release)" or unpress -- if I got that right.
Title: Re: ML on EOS-M2
Post by: dfort on July 04, 2017, 08:20:31 PM
Finished all I could on stubs.S and consts.h. If anyone wants to follow along I'm working on a work-in-progress branch (https://bitbucket.org/daniel_fort/magic-lantern/branch/EOSM2.103_wip) which is sort of a scratch pad to take notes as I go along. Before making the pull request (provided I can get that far) I'll make a new branch so the pull request will be as clean as possible.

Following some of the hints and references in the code led me to some helpful scripts like find_fnt.py that could use some updating to make it easier on the next guy that uses it.

https://bitbucket.org/hudson/magic-lantern/pull-requests/844/find_fntpy-update/diff

Another interesting script is in magic-lantern/modules/adtg_log and is called parse_bin.py. I'm not sure how to use it (no documentation I could find)

[EDIT] Well I did find this:

the bin can be parsed with the python script in the module directory ;)

In any case, running this:

Code: [Select]
python parse_bin.py -f ROM1.BIN
created a large amount of information. I was looking for FRAME_SHUTTER_BLANKING_ZOOM and FRAME_SHUTTER_BLANKING_NOZOOM which required looking up some ADTG registers. I used the adtg_gui before but never figured out adtg_log. In any case, there was this discussion (http://www.magiclantern.fm/forum/index.php?topic=6751.msg69043#msg69043) on the forum which looked promising but I never could find what I was looking for using parse_bin.py.

[EDIT] To be more specific, I was trying to find this:

Code: [Select]
#define FRAME_SHUTTER_BLANKING_ZOOM   (*(uint16_t*)0x40481B20) // ADTG register 805f
#define FRAME_SHUTTER_BLANKING_NOZOOM (*(uint16_t*)0x40481B24) // ADTG register 8061

There are a few more addresses to look up then time to get back to QEMU to try and get "Hello world" working and hopefully find the firmware signature.
Title: Re: ML on EOS-M2
Post by: dfort on July 06, 2017, 02:29:32 AM
Thought I'd try something easy:

Exercises:
- (easy) patch the loop that times out (probably when initializing the touch IC) and the localI2C_Read loop;
- (easy) print Hello World with the minimal ML target;
- (moderate) print Hello World with the regular ML source code;
- (moderate) implement touch screen emulation;
- (moderate) bring ML menu in QEMU;
- (harder) full ML port, with most features working;
- (extreme) LiveView emulation.

So I went into magic-lantern/minimal/qemu-frsp and tried this:

Code: [Select]
MODEL=EOSM2 make
...
[ LD       ]   magiclantern
stdio.o: In function `my_fprintf':
/Users/rosiefort/magic-lantern/minimal/qemu-frsp/../../src/stdio.c:32: undefined reference to `FIO_WriteFile'
make: *** [magiclantern] Error 1

Am I missing something in EOSM2? Maybe but I can't build any model. Next I went into magic-lantern/minimal/qemu-hptimer and:

Code: [Select]
MODEL=EOSM2 make
...
magiclantern.bin: 3052 bytes
[ CC       ]   reboot.o
[ CC       ]   disp_direct.o
[ CC       ]   footer.o
[ LD       ]   autoexec
[ OBJCOPY  ]   autoexec.bin
[ XOR_CHK  ]   autoexec.bin

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000060 0x0009e1e0 0x0009e1e0 0x00bec 0x10c20 RWE 0x10

Yay!

Running autoexec.bin in QEMU:

(https://farm5.staticflickr.com/4290/35615450431_8154d034a4.jpg)

Boo!

Is this because I haven't gotten the firmware signature yet? Keep thinking that maybe that is the next challenge.

[EDIT] Doh! Figured out why that message is coming up--I was using the EOSM.202 firmware signature as a filler for the still undiscovered EOSM2.103 firmware signature. Commenting out the firmware signature and the minimal autoexec.bin will just hang. So I'm back in that Catch 22 situation. I did try some of the debugging tricks with a regular ML Hello World build but that's a moderately difficult exercise to complete.

Here is how that went:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S -d autoexec,ramw,calls,io,v & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb

Lockdown read 0
Lockdown read 0
Lockdown read 1
Lockdown read 1
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 1FFFFFFF: eos.ram
40001000 - 5FFFFFFF: eos.ram_uncached
F0000000 - F0FFFFFF: eos.rom0
F1000000 - F1FFFFFF: eos.rom0_mirror
F2000000 - F2FFFFFF: eos.rom0_mirror
F3000000 - F3FFFFFF: eos.rom0_mirror
F4000000 - F4FFFFFF: eos.rom0_mirror
F5000000 - F5FFFFFF: eos.rom0_mirror
F6000000 - F6FFFFFF: eos.rom0_mirror
F7000000 - F7FFFFFF: eos.rom0_mirror
F8000000 - F8FFFFFF: eos.rom1
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
C0000000 - DFFFFFFF: eos.iomem
[EOS] enabling code execution logging.
[EOS] enabling memory access logging.
[EOS] enabling singlestep.
[EOS] disabling verbose logging until autoexec.bin starts...
[EOS] loading './EOSM2/ROM0.BIN' to 0xF0000000-0xF0FFFFFF
[EOS] loading './EOSM2/ROM1.BIN' to 0xF8000000-0xF8FFFFFF
[EOS] loading './EOSM2/SFDATA.BIN' as serial flash, size=0x1000000
[MPU] warning: non-empty spell #31 (08 06 03 1f) has duplicate(s): #40
[MPU] warning: non-empty spell #41 (0a 08 01 3b) has duplicate(s): #37 #38
[MPU] warning: non-empty spell #45 (26 24 01 4e) has duplicate(s): #46

[MPU] Available keys:
- Arrow keys   : Navigation
- [ and ]      : Main dial (top scrollwheel)
- SPACE        : SET
- DELETE       : guess
- M            : MENU
- P            : PLAY
- I            : INFO/DISP
- Q            : guess
- L            : LiveView
- Shift        : Half-shutter
- B            : Open battery cover
- F1           : show this help

Setting BOOTDISK flag to FFFFFFFF
0xffff0000 in ?? ()
+macro define CURRENT_TASK   ((int)0xFFFFFFFF)
+macro define CURRENT_ISR    ((int)0xFFFFFFFF)
+macro define RTC_VALID_FLAG ((int)0xFFFFFFFF)
+macro define NUM_CORES      1
+macro define PRINT_CALLSTACK 0
+set pagination off
+set output-radix 16
+define hook-quit
+define KRED
+define KCYN
+define KBLU
+define KGRN
+define KYLW
+define KRESET
+macro define CURRENT_TASK_NAME (((int*)CURRENT_TASK)[0] ? ((char***)CURRENT_TASK)[0][9] : CURRENT_TASK)
+define print_callstack
+define print_current_location
+define print_current_location_with_callstack
+define print_formatted_string
+define DebugMsg_log
+define DebugMsg1_log
+define printf_log
+define task_create_log
+define task_switch_log
+define msleep_log
+define assert_log
+define assert0_log
+define create_semaphore_log
+define delete_semaphore_log
+define print_sem_name
+define take_semaphore_log
+define give_semaphore_log
+define create_msg_queue_log
+define print_mq_name
+define post_msg_queue_log
+define try_receive_msg_queue_log
+define receive_msg_queue_log
+define register_interrupt_log
+define register_func_log
+define mpu_decode
+define mpu_send_log
+define mpu_recv_log
+define try_expand_ram_struct
+define try_post_event_log
+define delayed_call_print_name
+define delayed_call_log
+define SetTimerAfter_log
+define SetHPTimerAfterNow_log
+define SetHPTimerNextTick_log
+define CancelTimer_log
+define engine_resource_description
+define engine_resources_list
+define CreateResLockEntry_log
+define LockEngineResources_log
+define AsyncLockEngineResources_log
+define UnLockEngineResources_log
+define StartEDmac_log
+define SetEDmac_log
+define print_date_time
+define set_date_time
+define load_default_date_time_log
+define log_result
Breakpoint 1 at 0x4398
Breakpoint 2 at 0x7360
Breakpoint 3 at 0xff0c5144
FFFF096C: MCR p15,0,Rd,cr9,cr1,0: XSCALE_LOCK_ICACHE_LINE <- 0x40000006 (40000000 - 40000FFF, 0x1000)
FFFF0970: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x2078
FFFF0978: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x12078   
FFFF3F54: MCR p15,0,Rd,cr6,cr0,0:  946_PRBS0 <- 0x3F       (00000000 - FFFFFFFF, 0x100000000)
FFFF3F5C: MCR p15,0,Rd,cr6,cr1,0:  946_PRBS1 <- 0x3D       (00000000 - 7FFFFFFF, 0x80000000)
FFFF3F64: MCR p15,0,Rd,cr6,cr2,0:  946_PRBS2 <- 0xE0000039 (E0000000 - FFFFFFFF, 0x20000000)
FFFF3F6C: MCR p15,0,Rd,cr6,cr3,0:  946_PRBS3 <- 0xC0000039 (C0000000 - DFFFFFFF, 0x20000000)
FFFF3F74: MCR p15,0,Rd,cr6,cr4,0:  946_PRBS4 <- 0xFF00002F (FF000000 - FFFFFFFF, 0x1000000)
FFFF3F7C: MCR p15,0,Rd,cr6,cr5,0:  946_PRBS5 <- 0x37       (00000000 - 0FFFFFFF, 0x10000000)
FFFF3F84: MCR p15,0,Rd,cr6,cr6,0:  946_PRBS6 <- 0xF700002F (F7000000 - F7FFFFFF, 0x1000000)
FFFF3F8C: MCR p15,0,Rd,cr2,cr0,0: DCACHE_CFG <- 0x70       
FFFF3F90: MCR p15,0,Rd,cr3,cr0,0:       DACR <- 0x70       
FFFF3F94: MCR p15,0,Rd,cr2,cr0,1: ICACHE_CFG <- 0x70       
FFFF3F9C: MCR p15,0,Rd,cr5,cr0,0:    DATA_AP <- 0x3FFF     
FFFF3FA0: MCR p15,0,Rd,cr5,cr0,1:    INSN_AP <- 0x3FFF     
FFFF3FA4: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x12078
FFFF3FC8: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC001307D
FFFF0984: MCR p15,0,Rd,cr9,cr1,1: XSCALE_UNLOCK_ICACHE <- 0x6        (00000000 - 00000FFF, 0x1000)
FFFF0988: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC001307D
FFFF0990: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005307D
FFFF09B8: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005307D
FFFF09C0: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D
SD: CMD12 in a wrong state
[SDIO] Error
SD: CMD12 in a wrong state
[SDIO] Error
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
SD: CMD12 in a wrong state
[SDIO] Error
SD: CMD12 in a wrong state
[SDIO] Error
File size : 0x671C0
Now jump to AUTOEXEC.BIN!!
0010E5F8: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
0010E600: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D
[EOS] enabling verbose logging for autoexec.bin...
      PC jump? 0x800000 lr=10e65c                                                at [10e674:10e65c]
      0x0010e674:  e1a0f001      mov pc, r1
[EOS] enabling verbose logging for autoexec.bin...
[BOOT] changing user_mem_start from 0x17ec74 (1567860) to 0x117940 (1145152)
[BOOT] changing init_task from 0xff0c57a0 (-15968352) to 0x9e1f0 (647664)
DRYOS PANIC: Module Code = 1, Panic Code = 2
^C
Program received signal SIGINT, Interrupt.
0xff0c19f4 in ?? ()
(gdb)
Title: Re: ML on EOS-M2
Post by: a1ex on July 06, 2017, 05:24:47 PM
Took a closer look at the firmware signature - it's affected by our QEMU patches. So, to find it, either debug it without enabling other ROM patches (those with SET), or find it out outside GDB (e.g. print it on the screen), or just keep it commented out.

Next:
Code: [Select]
[BOOT] changing user_mem_start from 0x17ec74 (1567860) to 0x117940 (1145152)

This one looks fishy to me. Why? Because we "push" this address to the right in order to make room from our application. Let's take a look at the memory map (printed by 0xFF0C6E70).

Start the firmware under GDB, then, once it's running, hit CTRL-C and call this function. The simplest (and most hackish) way to do this, without loading guest code (autoexec.bin), is:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S -d debugmsg & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
(wait until it boots)
CTRL-C
set $pc = 0xFF0C6E70
continue

This will break the execution flow (after returning from that function, there will be dragons), but at least we'll get what we are looking for. The function probably has no arguments (R0 and R1 are first written, and then read), therefore simply jumping to it should be fine.

Result:
Code: [Select]
...
sys_mem_start   0x0018ac00
sys_mem_max        1179648
user_mem_start  0x00100d80
user_mem_max        515828
...

Here, user_mem is malloc, sys_mem is AllocateMemory the place where DryOS allocats stack space for its tasks.

That means, user_mem_start is not 0x17EC74, but 0x100d80. You'll find that in cstart as well. Set RESTARTSTART to that, or a little bit higher - e.g. 0x100E00). Now, the boot process will "push" user_mem_start to start right where our code ends.

BTW - most models have "RESTARTSTART is selected to be just above the end of the bss". Coincidentally or not, Canon's BSS (the end of what they zero out before cstart) is also 0x100D80; however, it is my understanding that we are not modifying Canon's BSS, but user_mem_start (therefore shrinking their malloc memory pool).

Hence, the 7D2 has an updated comment:
Code: [Select]
# DryOS memory map
# RESTARTSTART is selected to be at user_mem_start
# (aka heap start / DRY_HEAP_START / malloc memory pool)
#
RESTARTSTART  = 0x001CC400

There, Canon's BSS ends at 0x745E8, so the previous comments about BSS were incorrect. Time to fix them.

Having fixed RESTARTSTART and the (misnamed) HIJACK_INSTR_BSS_END, let's check the memory map again, this time loading some minimal ML:

Code: [Select]
sys_mem_start   0x0018ac00
sys_mem_max        1179648
user_mem_start  0x00104580
user_mem_max        501492

Notice the user_mem (malloc) pool is now smaller and shifted to the right. The size needed by our binary (MemSiz when compiling) is 0x03780 (ymmv), so it appears to match.

How much free space do we have? The 7D2 source contains 3 important hints: malloc_info, sysmem_info and smemShowFix (all easily found in the firmware). Let's call the first one (from GDB, to avoid recompiling):

Without ML:
Code: [Select]
Malloc Information (onetime type)
  Start Address       = 0x00100d88
  End Address         = 0x0017ea60
  Total Size          = 0x0007dcd8 (   515288)
  Allocated Size      = 0x00015ab0 (    88752)
  Allocated Peak      = 0x00015ab0 (    88752)
  Allocated Count     = 0x0000005a (       90)
  Free Size           = 0x00068228 (   426536)
  Free Block Max Size = 0x000681f0 (   426480)
  Free Block Count    = 0x00000002 (        2)

With minimal ML:
Code: [Select]
Malloc Information (onetime type)
  Start Address       = 0x00104588
  End Address         = 0x0017ea60
  Total Size          = 0x0007a4d8 (   500952)
  Allocated Size      = 0x00015ab0 (    88752)
  Allocated Peak      = 0x00015ab0 (    88752)
  Allocated Count     = 0x0000005a (       90)
  Free Size           = 0x00064a28 (   412200)
  Free Block Max Size = 0x000649f0 (   412144)
  Free Block Count    = 0x00000002 (        2)


OK, so we don't have enough space to load the entire ML (maybe only if you compile it without any features). We'll have move somewhere else.

This was the "classic" boot process, originally used by 5D2. Not all models have enough free space here to accommodate the full autoexec.bin.

One option is to try the AllocateMemory (like 550D or 1100D), and another is to hunt for possibly unused memory areas (smemShowFix - FF222B68) - see http://www.magiclantern.fm/forum/index.php?topic=5071.0.

Note: I wouldn't call random stuff on a real camera without triple-checking the stub, the number of arguments, any prerequisites that might be and so on. Here we are on a virtual machine, so there's nothing to break - feel free to experiment away.
Title: Re: ML on EOS-M2
Post by: dfort on July 07, 2017, 05:18:22 PM
(after returning from that function, there will be dragons)

I've been meticulously going through all your notes and when I don't understand something I look it up. If this is a reference to the John Ringo book:

Quote
The world is a paradise-and then, in a moment, it ends.

Yep, that's pretty much what happened.

All that debugging you did was due to a very basic mistake on my part. I started out by copying over all the EOSM.202 settings and then went through every line and changed the values to what I could find in the EOSM2.103 disassembly. Well, almost every line. Somehow I skipped over Makefile.platform.default. Oops. The hints were there and I might have been able to figure it out, except for the "a little bit higher" part. From my understanding of your last post:

magic-lantern/platform/EOSM2.103/Makefile.platform.default
Code: [Select]
#Makefile.setup.platform for EOS M2

ifeq ($(FW_VERSION),103)
CANON_NAME_FIR=EOSM2103.FIR

ROMBASEADDR = 0xFF0C0000

# DryOS memory map
# RESTARTSTART is selected to be at user_mem_start
# (aka heap start / DRY_HEAP_START / malloc memory pool)
# (actually 0x00100d80 but make it a little bit higher)
#
RESTARTSTART = 0x100E00
endif

Having fixed RESTARTSTART and the (misnamed) HIJACK_INSTR_BSS_END...

Not sure about the HIJACK_INSTR_BSS_END fix. There is a comment that should be changed:

magic-lantern/platform/EOSM2.103/consts.h
Code: [Select]
#define HIJACK_INSTR_BSS_END 0xFF0C1C94  //BSS_END is 0x17EC74
in order to match the disassembly:
Code: [Select]
; ff0c1c90: (00100d80)
; ff0c1c94: (0017ec74)

...let's check the memory map again, this time loading some minimal ML:

The hackish way to do this doesn't work when loading the QEMU minimal autoexec.bin so this probably requires doing it via debugmsg.gbd, right? Uh, how?

Speaking of debugmsg.gbd - looking at other similar cameras (EOSM and 700D), shouldn't this work on the EOSM2?

Code: [Select]
b *0x1900
assert_log

That might be useful.

The 7D2 source contains 3 important hints: malloc_info, sysmem_info and smemShowFix (all easily found in the firmware).

The closest I could find in the EOSM2 source is: "Malloc Information (%s type)", "ShowWinsysMemory" and "..smemShowFix"

Let's call the first one (from GDB, to avoid recompiling):

I'm lost. How did you do that?

Ok--getting back to the "easy" stuff:

Exercises:
- (easy) patch the loop that times out (probably when initializing the touch IC) and the localI2C_Read loop;
- (easy) print Hello World with the minimal ML target;

The loop that times out is annoying.

Code: [Select]
...
[  TouchMgr:ff346008 ] (c1:16) Touch IC Ver : 0x0000
   154:   993.280 [TCH]Touch IC Ver : 0x0000
[  TouchMgr:ff345160 ] (c1:03) ExecuteSIO32 err
...
[  TouchMgr:ff344f58 ] (c1:03) ExecuteSIO8 err
...
[  TouchMgr:ff34602c ] (c1:06)  TouchPanelIC Ack Error
[   Startup:0003671c ] task_create(DisplayMgr, prio=12, stack=0, entry=36628, arg=8ce0e8)

Am I on the right track here?

Code: [Select]
# patch TouchMgr to avoid err messages and loop timeout
# ExecuteSIO8
set *(int*)0xff344f?? = 0xe???????
# ExecuteSIO32
set *(int*)0xff3451?? = 0xe???????

I'm still at a loss at how to print Hello World with the minimal ML target. For now I've got the firmware signature commented out. However, it seems that you keep hinting that it can be found with QEMU.

Took a closer look at the firmware signature - it's affected by our QEMU patches. So, to find it, either debug it without enabling other ROM patches (those with SET), or find it out outside GDB (e.g. print it on the screen), or just keep it commented out.

The code to find it doesn't seem too complex:

Code: [Select]
static int compute_signature(int* start, int num)
{
    int c = 0;
    int* p;
    for (p = start; p < start + num; p++)
    {
        c += *p;
    }
    return c;
}

start = SIG_START which on Digic V cameras like the EOSM2 is 0xFF0C0000
num = 0x10000

So shouldn't it be possible to write a rather simple script to find the firmware signature from ROM1.BIN or would that be short circuiting the porting process?
Title: Re: ML on EOS-M2
Post by: a1ex on July 07, 2017, 06:36:17 PM
Quote
The world is a paradise-and then, in a moment, it ends.

What happens here is because of how function calls are done on ARM processors. When a BL executes, the next address (where the code should return after the function ends) is placed into LR, then PC is updated to the first address of the called function.

What we did in GDB was to interrupt the firmware somewhere (we don't know where) and change the PC to some function (that takes no arguments). That function will run just fine (we can use its results), but it won't know where to return - and that's where the dragon appears.

In QEMU it's fine - it will just return somewhere. It may lock up, it may go back to the caller function without finishing the function we interrupted... or it may somehow jump to EraseSectorOfRom or other similar address. That's why you must never try this on the real firmware.

Quote
...let's check the memory map again, this time loading some minimal ML:
...
The hackish way to do this doesn't work when loading the QEMU minimal autoexec.bin so this probably requires doing it via debugmsg.gbd, right? Uh, how?

First you need to compile ML from some minimal target (you already did). Then place it on the card image, then start it with boot=1.

To call the function, you may now use either GDB (ctrl-c + jumping to the function), or insert a call to that function somewhere in the minimal ML. The second method will not break the execution flow, as the function will know where to return.

Quote
The closest I could find in the EOSM2 source is: "Malloc Information (%s type)", "ShowWinsysMemory" and "..smemShowFix"

Yes, these are. For example, malloc_info is FF0C750C (the function that references the first string). It takes no arguments, so you can just jump to it.

Quote
shouldn't this work on the EOSM2?
Code: [Select]
b *0x1900
assert_log

It does. Not all models have assert at 0x1900 (1300D doesn't).

Quote
So shouldn't it be possible to write a rather simple script to find the firmware signature from ROM1.BIN or would that be short circuiting the porting process?

It is. But once you patch something via GDB (such as "set *(int*)0xFF356E28 = 0xe3a00001"), the value will change.

Quote
I'm still at a loss at how to print Hello World with the minimal ML target.

Look in src/minimal.c.
Title: Re: ML on EOS-M2
Post by: dfort on July 08, 2017, 03:04:49 AM
Exercises:
- (easy) patch the loop that times out (probably when initializing the touch IC) and the localI2C_Read loop;

One small step for a1ex, one giant leap for dfort:

Code: [Select]
# patch TouchMgr to avoid loop timeout
# ExecuteSIO8
set *(int*)0xFF344F40 = 0xe1a0000b
# ExecuteSIO32
set *(int*)0xFF345148 = 0xe1a0000b

At least it doesn't slow down to a crawl when it hits the TouchMgr section.

Not sure what the issue is with the localI2C_Read loop. I'm not noticing any slowdown or delays though this is printed in red to the console:

Code: [Select]
   154:   824.832 [TCH]ERROR  TouchPanelIC Ack Error
   155:   760.576 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   156:   760.832 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   157:   761.088 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   158:   761.344 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   159:   761.600 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   160:   761.856 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   161:   761.856 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   162:   762.112 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   163:   762.368 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   164:   833.536 [IMPP] H264E InitializeH264EncodeFor1080pDZoom
   165:   833.536 [IMPP] H264E InitializeH264EncodeFor1080p25fpsDZoom
   172:   836.608 [STARTUP] startupInitializeComplete
   173:   841.216 [MR] mvrChangeAckCBR : Video - Mode=0, Type=2, Rate=30, GOP=15
   174:   850.176 [MR] mvrChangeAckCBR : Video - Mode=0, Type=2, Rate=30, GOP=15
   180:   863.232 [CEC]CEC OFF
   182:   882.176 [RTC] !! RTC CHECK ERROR !!

Also had a breakthrough on making a minimal ML. I simply copied what was done in magic-lantern/minimal/600D.102 (and other cameras). Continuing from where I got lost last time:

Code: [Select]
^C
Program received signal SIGINT, Interrupt.
0xff352318 in ?? ()
(gdb) set $pc = 0xFF0C6E70
(gdb) continue
Continuing.
...
sys_mem_start   0x0018ac00
sys_mem_max        1179648
user_mem_start  0x00100d80
user_mem_max         14336
...

With that same minimal ML:

Code: [Select]
^C
Program received signal SIGINT, Interrupt.
0xff352318 in ?? ()
(gdb) set $pc = 0xFF0C750C
(gdb) continue
Continuing.
Malloc Information (onetime type)
  Start Address       = 0x00100d88
  End Address         = 0x00104370
  Total Size          = 0x000035e8 (    13800)
  Allocated Size      = 0x000025c0 (     9664)
  Allocated Peak      = 0x000025c0 (     9664)
  Allocated Count     = 0x00000011 (       17)
  Free Size           = 0x00001028 (     4136)
  Free Block Max Size = 0x00001028 (     4136)
  Free Block Count    = 0x00000001 (        1)

To be continued (still no Hello World) but first - to quote kichetof - take a beer and enjoy it!
Title: Re: ML on EOS-M2
Post by: a1ex on July 08, 2017, 07:32:58 AM
At least it doesn't slow down to a crawl when it hits the TouchMgr section.

... it no longer boots the GUI ...
Title: Re: ML on EOS-M2
Post by: dfort on July 08, 2017, 09:03:31 AM
... it no longer boots the GUI ...

That's strange -- I can see the GUI here. You are talking about the Canon menus, right? I still don't have a minimal ML that displays "Hello World" much less any ML GUI with or without that TouchMgr "fix."

This is the entire debugmsg.gdb:

Code: [Select]
# ./run_canon_fw.sh EOSM2 -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb

source -v debug-logging.gdb

macro define CURRENT_TASK 0x8FBCC
macro define CURRENT_ISR  (*(int*)0x648 ? (*(int*)0x64C) >> 2 : 0)

b *0x4398
DebugMsg_log

b *0x1900
assert_log

b *0x7360
task_create_log

# patch DL to avoid DL ERROR messages
set *(int*)0xFF156348 = 0xe3a00015

# patch localI2C_Write to always return 1 (success)
set *(int*)0xFF356E24 = 0xe3a00001
set *(int*)0xFF356E28 = 0xe12fff1e

# patch TouchMgr to avoid loop timeout
# ExecuteSIO8
set *(int*)0xFF344F40 = 0xe1a0000b
# ExecuteSIO32
set *(int*)0xFF345148 = 0xe1a0000b

# skip SerialFlash version check
set *(int*)0xFF0C4278 = 0xe3a00000

# break infinite loop at Wait LeoLens Complete
b *0xFF0C5144
commands
  printf "Patching LeoLens (infinite loop)\n"
  set *(int*)($r4 + 0x28) = 1
  c
end

continue

Think I found ShowWinsysMemory

No ML:
Code: [Select]
   185:  2214.144 [WINSYS] allocated=44140 max_region=412876

Minimal ML:
Code: [Select]
[  PowerMgr:ff13432c ] (04:16) allocated=0 max_region=1066808

Couldn't find smemShowFix ("..smemShowFix") but this looks interesting:

No ML:
Code: [Select]
(gdb) set $pc = 0xff133b80
(gdb) c
Continuing.
[SVG] Free/Total:3229904/8118272
[SVG] SVG Alloc:0
[SVG] Max Region:2763608
[SVG] number of allocated block:4863
[SVG] dslr_malloc ResetAllocatePointer!!!!!!
[SVG] Memory Allocation Error at :429392408
[SVG] svg_malloc(size:0, pFileName, lineNo)
MaxRegion = 2763608
[SVG] Free/Total:3229904/8118272
[SVG] Max Region:2763608
[SVG] number of allocated block:4863

Minimal ML:
Code: [Select]
[SVG] Free/Total:6431420/8118272
[SVG] SVG Alloc:0
[SVG] Max Region:6427636
[SVG] number of allocated block:1537
[SVG] dslr_malloc ResetAllocatePointer!!!!!!
[SVG] Memory Allocation Error at :429392408
[SVG] svg_malloc(size:0, pFileName, lineNo)
MaxRegion = 6427636
[SVG] Free/Total:6431420/8118272
[SVG] Max Region:6427636
[SVG] number of allocated block:1537
Title: Re: ML on EOS-M2
Post by: a1ex on July 08, 2017, 09:38:43 AM
Hm, it's working now. Previously it got stuck in a loop and stayed like that for some 15 minutes...

Tip: comment out DebugMsg_log and replace it with -d debugmsg (much faster (http://www.magiclantern.fm/forum/index.php?topic=2864.msg185769#msg185769))
Title: Re: ML on EOS-M2
Post by: dfort on July 08, 2017, 06:02:29 PM
Yes, much faster.

Am I doing it right?

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S -d debugmsg & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
Following your link (http://www.magiclantern.fm/forum/index.php?topic=2864.msg185769#msg185769) shows this neat trick:

Code: [Select]
env QEMU_EOS_DEBUGMSG=0x5b90 ./run_canon_fw.sh 5D3,firmware="boot=0" -d debugmsg,callstack,v
but that 0x5b90 address is specific to the 5D3, right?

Booting into the Canon menus "boot=0" seems pretty solid though there are some error messages logged. Making the minimal autoexec.bin to print "Hello World" is another story. I thought I'd try it with the 5D3.113 but--

Code: [Select]
cd minimal/5D3.113/
RosieFoComputer:5D3.113 rosiefort$ make
../../platform/Makefile.platform.base:46: *** ROMBASEADDR is not defined.  Stop.

What the?
Title: Re: ML on EOS-M2
Post by: a1ex on July 08, 2017, 09:10:41 PM
Yep, looks fine. Of course, each model has a different DebugMsg address; will try to automate it.

5D3 has 2 firmware versions, so the build system doesn't know which one to pick. Adding FW_VERSION=113 fixes it.

This was probably broken when merging 5D3 1.2.3 (and since the minimal target is neither widely used, nor covered by self-tests, it wasn't noticed).

Back to the topic - I've got minimal hello world working on M2 after fixing RESTARTSTART and related consts as discussed above, then compiling your source. That was before the timeout patches, but it's still working afterwards.
Title: Re: ML on EOS-M2
Post by: dfort on July 09, 2017, 06:35:35 AM
I've got minimal hello world working on M2...

Nice!

I've got a minimal "Hello World" working on a real 5D3.113 but not on QEMU. Wanna trade?   :D

The 5D3.113 minimal ML was built in the minimal/5D3.113 directory and the firmware signature was commented out so it should work like an early port. This is what it looks like on the camera. (Thanks for the FW_VERSION=113 tip):

(https://farm5.staticflickr.com/4242/34997476353_d772eee7b8.jpg)

That same minimal ML on QEMU:

(https://farm5.staticflickr.com/4241/35675527851_d6cd354971_z.jpg) (https://flic.kr/p/WmwpvM)

The point of this exercise was to see if the problem is with the minimal ML or the QEMU setup or maybe both. Looks like that at least for the 5D3 it is QEMU. That is if my theory holds up which is that the same minimal ML autoexec.bin should be able to run on both the camera and QEMU. This is also assuming that ML on 5D3.113 in QEMU is working.

Note that I also tried the qemu-hptimer version with this result: (Note the "Hello from task init" that wasn't on the previous test.)

Code: [Select]
File size : 0x1940
Now jump to AUTOEXEC.BIN!!
0010DCCC: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
0010DCCC: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D
Hello from task init
K285 READY
[      init:ff3014ac ] create_semaphore('EventProcedure', 1)
Temporary breakpoint 10 at 0xff3014b0

Program received signal SIGTRAP, Trace/breakpoint trap.
0xff3014b0 in ?? ()
(gdb)

qemu-frsp isn't compiling over here.
Title: Re: ML on EOS-M2
Post by: a1ex on July 09, 2017, 09:10:21 AM
For 5D3, try running it with "patches.gdb" instead - that's the only one where I've tried the GUI.

The "Hello world" works without GDB script at all, although that way I get blank screen and no menus (not sure why).
Title: Re: ML on EOS-M2
Post by: dfort on July 09, 2017, 06:38:58 PM
What finally worked with the 5D3.113 for me was simply:

Code: [Select]
./run_canon_fw.sh 5D3,firmware="boot=1"
(https://farm5.staticflickr.com/4265/35008319273_51ebe033b3_z.jpg) (https://flic.kr/p/VkyMDB)

That is working with and without the "#define SIG_5D3_113  0x2e2f65f5" in fw-signature.h so in theory this should also work with the EOSM2 minimal ML, right?

Here is the output (https://pastebin.com/AdwsiYM6) from ./run_canon_fw.sh EOSM2,firmware="boot=1"
Title: Re: ML on EOS-M2
Post by: a1ex on July 09, 2017, 07:54:37 PM
Some models are able to boot the GUI without any GDB patches (e.g. 60D, 500D). They will show the date/time dialog, but you can close it cleanly - then you get the usual Canon GUI. If you patch date/time, it boots directly to the GUI. The patches.gdb are there, but they are no longer necessary (they used to be before figuring out menu navigation).

Other models (700D, EOSM2) require some sort of patching. They won't boot the GUI without these patches.

5D3 is in-between. Without any patches, it shows a blank screen (no menus), but other than that, it appears to boot almost completely. For example, it initializes the bitmap VRAM - that's why you were able to print Hello World. Patching date/time is enough to enable the GUI, menu navigation and info screens (which is a mystery to me - why is the behavior different from e.g. 60D?)
Title: Re: ML on EOS-M2
Post by: dfort on July 10, 2017, 03:16:27 AM
So I created and ran minimal ML versions for the EOSM and 700D. No GUI so I was messing around trying to find patches but then realized--if it doesn't initializes the bitmap VRAM then "Hello World" will never print, will it?

Maybe I already have a working EOSM2 minimal ML and don't know it?

That long printout I posted on pastebin (https://pastebin.com/AdwsiYM6) might be the print to screen code or maybe calculating the firmware signature? It ends with:

Code: [Select]
[DM] FROM Write Complete!!!
That doesn't look like an error message and the navigation keys seem to be working--so is that it?

I built in the minimal directory and from the platform/EOSM.103 directory with the firmware signature commented out and CONFIG_HELLO_WORLD defined -- both worked. I keep thinking that the next step is to get the firmware signature. Looks like we pretty much there on June 25 but then:

Took a closer look at the firmware signature - it's affected by our QEMU patches. So, to find it, either debug it without enabling other ROM patches (those with SET), or find it out outside GDB (e.g. print it on the screen), or just keep it commented out.

I kept it commented out but it looks like it is time to figure it out in order to get to the next step.

Exercises:
- (easy) patch the loop that times out (probably when initializing the touch IC) and the localI2C_Read loop; Check?
- (easy) print Hello World with the minimal ML target; Maybe check this off too?
- (moderate) print Hello World with the regular ML source code; Next exercise?
- (moderate) implement touch screen emulation;
- (moderate) bring ML menu in QEMU;
- (harder) full ML port, with most features working;
- (extreme) LiveView emulation.

Then there is this:

OK, so we don't have enough space to load the entire ML (maybe only if you compile it without any features). We'll have move somewhere else.
...
Note: I wouldn't call random stuff on a real camera without triple-checking the stub, the number of arguments, any prerequisites that might be and so on. Here we are on a virtual machine, so there's nothing to break - feel free to experiment away.

So at what point can we run a minimal ML on the camera?

(https://farm5.staticflickr.com/4239/35825884435_1a61ce1843_o.jpg)
Title: Re: ML on EOS-M2
Post by: a1ex on July 10, 2017, 09:26:03 AM
Quote
[DM] FROM Write Complete!!!

This message usually follows some sort of error (assert). The log has many DL messages, which means it was not run under GDB.

Quote
Maybe I already have a working EOSM2 minimal ML and don't know it?

Very likely :D

Quote
CONFIG_HELLO_WORLD

That won't work, since it will compile with the full feature set (thus reserving as much RAM as a full binary would). However, the minimal hello world requires very little RAM, so it should work (under GDB, with firmware signature commented out).
Title: Re: ML on EOS-M2
Post by: dfort on July 10, 2017, 05:08:03 PM
...the minimal hello world requires very little RAM, so it should work (under GDB, with firmware signature commented out).

Ok then, it's working. At least QEMU buttons seem to be working--no GUI.

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S -d debugmsg & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb > log_file.txt 2> err_file.txt

Empty error file. That's a good thing, right? However, the log file shows that maybe things ended badly:

Code: [Select]

This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".

Breakpoint 1 at 0x408660d4: file ../../src/reboot.c, line 211.
Breakpoint 2 at 0x1900
Breakpoint 3 at 0x7360
Breakpoint 4 at 0xff0c5144
[      init:ff352260 ] task_create(PowerMgr, prio=20, stack=400, entry=ff352084, arg=0)
[      init:0003671c ] task_create(DbgMgr, prio=1f, stack=0, entry=36628, arg=46e584)
[      init:ff0f5f24 ] task_create(Startup, prio=19, stack=2800, entry=ff0f5d68, arg=46e880)
[      init:ff0c33d4 ] task_create(TaskMain, prio=1d, stack=0, entry=ff0c28d8, arg=0)
[   Startup:ff0c375c ] task_create(Startup2, prio=11, stack=400, entry=ff0c3604, arg=0)
[   Startup:0003671c ] task_create(PropMgr, prio=14, stack=0, entry=36628, arg=4d7ca8)
[   Startup:ff0d261c ] task_create(DL, prio=f, stack=400, entry=ff0d23fc, arg=0)
[   Startup:0003671c ] task_create(EventMgr, prio=f, stack=0, entry=36628, arg=4e3898)
[   Startup:0003671c ] task_create(FileCache, prio=14, stack=0, entry=36628, arg=603d08)
[   Startup:0003671c ] task_create(RscMgr, prio=12, stack=0, entry=36628, arg=604110)
[   Startup:ff129dbc ] [ASSERT] this at ./FileMgr/FileMgr.c:2279, ff129dc0

Looks like it stopped on "FM_RegisterSpaceNotifyCallback" -- more patching to do?

Title: Re: ML on EOS-M2
Post by: dfort on July 10, 2017, 09:17:47 PM
Looks to me like something is going on in the GUI code. Does [DM] stand for Display Manager?

Tried to figure out what was going on here:

Code: [Select]
FF0C11BC: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
FF0C11BC: MCR p15, ...          : CACHEMAINT x2456 (omitted)
FF0C11BC: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC0051079
FF0C11F0: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC0051079
FF0C11DC: MCR p15, ...          : CACHEMAINT x1 (omitted)
FF0C11F0: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC0050079
FF0C113C: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC0050079
...
FF0C1194: MCR p15, ...          : CACHEMAINT x257 (omitted)
FF0C1194: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC0051079
FF0C11F0: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC0051079
FF0C1180: MCR p15, ...          : CACHEMAINT x1 (omitted)
FF0C11F0: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC0050079
FF0C113C: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC0050079
FF0C1120: MCR p15, ...          : CACHEMAINT x1 (omitted)
FF0C113C: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005007D
FF0C1168: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005007D
FF0C1120: MCR p15, ...          : CACHEMAINT x1 (omitted)
FF0C1168: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D


[DM] FROM Write Complete!!!

Checked stubs.S and it seems to me that these might GUI calls so I doubled checked all the GUI stubs and they look right.

This message usually follows some sort of error (assert). The log has many DL messages, which means it was not run under GDB.

Looks like this might be the assert:

Code: [Select]
[   Startup:ff129dbc ] [ASSERT] this at ./FileMgr/FileMgr.c:2279, ff129dc0
Here is a log with GDB. (https://pastebin.com/YnvhMATs)

I was trying to find a patch to get around this and came up with something rather interesting.

Code: [Select]
# FM_RegisterSpaceNotifyCallback
set *(int*)0xff129d94 = 0xe3a00001

What this does is to create the same issue when running EOSM2,firmware="boot=0" as it does with "boot=1" without this "patch". In other words, I was able to break it in the same way as the minimal ML. Running "boot=0" without the "patch" will boot all the way to the Canon GUI.

Feel like a kid sticking a fork into an electrical outlet to see what happens. As much as I'd like to see something running on the camera I'm glad we've got QEMU to work out these issues.
Title: Re: ML on EOS-M2
Post by: dfort on July 11, 2017, 06:45:41 AM
Did a little more QEMU'ing with the 550D. Why? Because it seems to be the best supported in QEMU and this:

OK, so we don't have enough space to load the entire ML (maybe only if you compile it without any features). We'll have move somewhere else.
...
One option is to try the AllocateMemory (like 550D or 1100D)...

So the minimal ML looks like this: [Edit] Check out that little dot in the lower right corner--I think it represents the camera's LED because it flashes on and off just like on the camera.

(https://farm5.staticflickr.com/4206/35681451342_8d6163ba37.jpg)

That "Hello World" in the retro graphical font shows up everywhere reminding you that ML is running. Kind of cool and annoying at the same time. Ok, we aren't going to do anything with a minimal ML so how about the full ML only without a firmware signature defined and "Hello World" configured?

(https://farm5.staticflickr.com/4264/35462590070_b8737a2014.jpg)

What is cool about this is that the 550D dump that I'm using doesn't have the boot flag enabled so it is pretty much like the EOSM2 ROMs that I'm using. Is is displaying the correct firmware signature--nice! That's what I thought we were going for with these QEMU exercises.

By the way, these were run with a simple:

Code: [Select]
./run_canon_fw.sh 550D,firmware="boot=1"
Ok so how about setting up AllocateMemory on the EOSM2?

I'm pretty sure that these are correct:

~/magic-lantern/platform/EOSM2.103/consts.h
Code: [Select]
// Used in boot-hack.c with CONFIG_ALLOCATE_MEMORY_POOL
#define ROM_ITASK_START 0xff0c57a0
#define ROM_ITASK_END  0xffc45984 // kinda iffy
#define ROM_CREATETASK_MAIN_START 0xff0c3064
#define ROM_CREATETASK_MAIN_END 0xff0c33dc
#define ROM_ALLOCMEM_END 0xff0c3074 // kinda iffy
#define ROM_ALLOCMEM_INIT 0xff0c307c // kinda iffy
#define ROM_B_CREATETASK_MAIN 0xff0c5814

Then this needs to be turned on:

~/magic-lantern/platform/EOSM2.103/internals.h
Code: [Select]
/** This camera loads ML into the AllocateMemory pool **/
#define CONFIG_ALLOCATE_MEMORY_POOL

Now there's some other adjustments that need to be made like maybe:

now you have to patch the DATA for the LDR. this is the address where the LDR     R3, =0x1F300000 gets the 1F3000000 from.
should be right below the function.
> #define RSCMGR_MEMORY_PATCH_END          0xF80.....   (yes, 0xF800!!! also on your cameras)

interesting that the 650D has 0x1F2C4000 bytes only.... hmm

after you defined that struct, make sure you set RESTARTSTART to 0x1FE00100  (original value minus 2MiB)

Ok--gotta ask a noob question, what is 2MiB? I looked it up but am not sure I'm getting it. Is it 0x800?

Anyway, I don't quite have all the pieces yet because it doesn't build:

Code: [Select]
...
[ LD       ]   magiclantern
boot-hack.o: In function `init_task_patched':
/Users/rosiefort/magic-lantern/platform/EOSM2.103/../../src/boot-hack.c:642: undefined reference to `reloc'
/Users/rosiefort/magic-lantern/platform/EOSM2.103/../../src/boot-hack.c:650: undefined reference to `reloc'
make: *** [magiclantern] Error 1

So reading further along that topic I ran into this:

EOS M2, QEMU:

(https://a1ex.magiclantern.fm/bleeding-edge/RscMgr/EOSM2.png)

Code: [Select]
  1062: 48619.520 [RSC] --- Common Top ----
  1063: 48619.520 [RSC] [TOP1]                  0x40C2A000
  1064: 48619.776 [RSC] REPLACE_IMAGE_VRAM      0x40C2A000 0x00032000 204800
  1065: 48623.104 [RSC] SSS_DEVELOP_WORK        0x40C5C000 0x00038000 229376
  1066: 48626.432 [RSC] SDS_DEVELOP_WORK        0x40C94000 0x00038000 229376
  1067: 48629.760 [RSC] DARKCUR_COMP_WORK       0x40CCC000 0x00020000 131072
  1069: 48637.440 [RSC] FENCING_WORK            0x40CEC000 0x00010000 65536
  1070: 48640.768 [RSC] DCFNO                   0x40CFC000 0x00004000 16384
  1071: 48644.096 [RSC] LVMARGE_P_DEF_DATA_1    0x40D00000 0x0000A000 40960
  1072: 48647.424 [RSC] LVMARGE_P_DEF_DATA_2    0x40D0A000 0x0000A000 40960
  1074: 48654.848 [RSC] LVMARGE_P_DEF_DATA_3    0x41FF0000 0x0000A000 40960
  1075: 48657.920 [RSC] LVMARGE_P_DEF_DATA_ZOOM 0x40D14000 0x0000C000 49152
  1076: 48661.504 [RSC] FILE_HEADER             0x40D20000 0x00240000 2359296
  1077: 48664.320 [RSC] SAF WORK                0x40FA0000 0x00200000 2097152
  1078: 48667.136 [RSC] BMPVRAM1                0x411A0000 0x00080000 524288
  1080: 48676.864 [RSC] BMPVRAM2                0x41220000 0x00080000 524288
  1081: 48680.704 [RSC] ENGINE_MIRROR           0x412A0000 0x00044000 278528
  1082: 48688.640 [RSC] VSHADING_COMP_WORK      0x412E4000 0x000DC000 901120
  1084: 48692.992 [RSC] STILL SCAR              0x413C0000 0x00075B00 482048
  1085: 48692.992 [RSC] TUNEDATA                0x41435B00 0x00140000 1310720
  1086: 48692.992 [RSC] TUNEDATA2               0x41575B00 0x00160000 1441792
  1087: 48693.504 [RSC] FIXDATA                 0x416D5B00 0x0021E500 2221312
  1088: 48693.504 [RSC] LVMARGE_P_DEF_DATA_CROP 0x418F4000 0x0000C000 49152
  1089: 48693.760 [RSC] WIRELESS_WORK2          0x41900000 0x00300000 3145728
  1090: 48699.648 [RSC] WIRELESS_WORK1   *      0x41C00000 0x00200000 2097152
  1091: 48702.464 [RSC] ADAPTER_TRANSFER *      0x0 0x00000000 0
  1092: 48702.464 [RSC] EEKO                    0x41E00000 0x001E0000 1966080
  1093: 48702.720 [RSC] SHOOTING_CREATIVEFILTER 0x41FE0000 0x00010000 65536
  1094: 48704.512 [RSC] EXMEM3_AREA_4           0x0 0x00000000 0
  1095: 48706.304 [RSC] --- Usually Mode ----
  1096: 48708.352 [RSC] MEMORY_MGR              0x42000000 0x04000000 67108864
  1098: 48715.520 [RSC] ONLY MEM1 1             0x46000000 0x02000000 33554432
  1099: 48717.568 [RSC] ONLY MEM1 2             0x48000000 0x02000000 33554432
  1100: 48721.152 [RSC] IMGPLAY_WORK            0x4A000000 0x00A00000 10485760
  1101: 48724.736 [RSC] IMGPLAY_WORK2           0x4AA00000 0x00400000 4194304
  1102: 48727.808 [RSC] SS_DEVELOP1             0x4A000000 0x00E00000 14680064
  1104: 48734.976 [RSC] EXMEM3_AREA_2           0x4AE00000 0x000EA000 958464
  1105: 48738.816 [RSC] AVERAGE_WORK_TOP        0x4AEEA000 0x01116000 17915904
  1106: 48742.144 [RSC] AVERAGE_WORK_BOTTOM     0x4C000000 0x01116000 17915904
  1107: 48745.472 [RSC] SS_DEVELOP_OTHER_WORK   0x4D116000 0x00400000 4194304
  1109: 48752.384 [RSC] SLIDE_SHOW_WORK         0x4D516000 0x00800000 8388608
  1110: 48753.920 [RSC] CAPTURE_WORK1           0x4D600000 0x00240000 2359296
  1111: 48760.576 [RSC] EXMEM3_AREA_1           0x4DD16000 0x016BA000 23830528
  1112: 48764.416 [RSC] IMGVRAM1                0x4F3D0000 0x00410000 4259840
  1113: 48764.928 [RSC] IMGVRAM2                0x4F7E0000 0x00410000 4259840
  1114: 48765.184 [RSC] IMGVRAM3                0x4FBF0000 0x00410000 4259840
  1116: 48771.584 [RSC] ---   GIS Mode   ----
  1117: 48772.352 [RSC] TEMPMEM1                0x48000000 0x02000000 33554432
  1118: 48775.680 [RSC] WORK                    0x4A000000 0x08600000 140509184
  1119: 48775.680 [RSC] IMGPLAY_WORK            0x4A000000 0x00A00000 10485760
  1120: 48775.680 [RSC] IMGPLAY_WORK2           0x4AA00000 0x00400000 4194304
  1121: 48779.520 [RSC] MOVIE_REC_WORK          0x4AE00000 0x00FA0000 16384000
  1122: 48779.520 [RSC] MOVIE_PLAY_WORK         0x4BE00000 0x00E00000 14680064
  1123: 48782.848 [RSC] SLIDE_SHOW_WORK         0x4D516000 0x00800000 8388608
  1124: 48787.200 [RSC] MOVIE_STREAM            0x4DD16000 0x01400000 20971520
  1126: 48790.528 [RSC] IMGVRAM1                0x4F3D0000 0x00410000 4259840
  1127: 48796.160 [RSC] IMGVRAM2                0x4F7E0000 0x00410000 4259840
  1128: 48796.160 [RSC] IMGVRAM3                0x4FBF0000 0x00410000 4259840
  1129: 48797.696 [RSC] EXMEM3_1_AREA           0x42000000 0x06000000 100663296
  1130: 48800.256 [RSC] EXMEM3_2_AREA           0x4CC40000 0x004D6000 5070848
  1131: 48802.304 [RSC] ---   HDR Mode   ----
  1133: 48806.912 [RSC] TEMPMEM1                0x48000000 0x02000000 33554432
  1134: 48808.192 [RSC] WORK                    0x4800000 0x0A600000 174063616
  1135: 48813.312 [RSC] IMGPLAY_WORK            0x4A000000 0x00A00000 10485760
  1136: 48815.360 [RSC] IMGPLAY_WORK2           0x4AA00000 0x00400000 4194304
  1137: 48815.360 [RSC] MOVIE_REC_WORK          0x4AE00000 0x00FA0000 16384000
  1138: 48815.360 [RSC] MOVIE_PLAY_WORK         0x4BE00000 0x00E00000 14680064
  1139: 48815.872 [RSC] SLIDE_SHOW_WORK         0x4D516000 0x00800000 8388608
  1140: 48816.896 [RSC] MOVIE_STREAM            0x4DD16000 0x01400000 20971520
  1141: 48817.920 [RSC] IMGVRAM1                0x4F3D0000 0x00410000 4259840
  1142: 48817.920 [RSC] IMGVRAM2                0x4F7E0000 0x00410000 4259840
  1143: 48817.920 [RSC] IMGVRAM3                0x4FBF0000 0x00410000 4259840
  1144: 48820.224 [RSC] EXMEM3_1_AREA           0x42000000 0x06000000 100663296
  1145: 48823.808 [RSC] EXMEM3_2_AREA           0x4CC40000 0x004D6000 5070848
  1146: 48824.320 [RSC] ---    NR Mode   ----
  1148: 48829.952 [RSC] NR_MEMORY_MGR           0x42000000 0x08000000 134217728
  1149: 48833.024 [RSC] COMPOSITION_WORK_TOP    0x0 0x00000000 0
  1150: 48836.096 [RSC] COMPOSITION_WORK_BOTTOM 0x0 0x00000000 0
  1151: 48839.424 [RSC] ---    DP Mode   ----
  1152: 48841.216 [RSC] DP_SINGLE               0x42000000 0x05E00000 98566144
  1153: 48841.216 [RSC] DP_MULTI                0x47E00000 0x04D94000 81346560
  1154: 48843.520 [RSC] DP_CAPTURE_WORK1        0x4CB94000 0x00040000 262144
  1155: 48844.288 [RSC] DP_AVERAGE_TOP          0x4DBD4000 0x01116000 17915904
  1157: 48848.128 [RSC] DP_AVERAGE_BOTTOM       0x4ECEA000 0x01116000 17915904
  1158: 48849.408 [RSC] --- Indev Mode ----
  1159: 48851.200 [RSC] [INDVMGR]               0x0
  1160: 48852.480 [RSC] YUV                     0x4AEEA000 0x0222C000 35831808
  1161: 48852.480 [RSC] YUV_OUT                 0x42000000 0x0222C000 35831808
  1162: 48853.760 [RSC] INDV_WORK               0x0 0x00000000 0

256MB. Note the WORK region has invalid size (it would overflow), so I've patched it to get a proper graph.

No unused areas for us.

No unused areas for us?

Oh please say it ain't so!
Title: Re: ML on EOS-M2
Post by: dmilligan on July 12, 2017, 01:49:44 AM
https://en.wikipedia.org/wiki/Mebibyte
Title: Re: ML on EOS-M2
Post by: dfort on July 13, 2017, 03:06:04 AM
Thanks!

So -- 1 MiB = 220 bytes = 1024 kibibytes = 1048576bytes = 0x100000

~/magic-lantern/platform/EOSM2.103/Makefile.platform.default
Code: [Select]
# DryOS memory map
# RESTARTSTART is selected to be at user_mem_start
# (aka heap start / DRY_HEAP_START / malloc memory pool)
# (actually 0x00100d80 but make it a little bit higher)
#
RESTARTSTART = 0x100E00

RESTARTSTART   = (0x100E00 - 0x200000) = -0xF200

Uh oh.

I may have found the stubs needed for CONFIG_ALLOCATE_MEMORY_POOL. Got it to compile. Might be useful if we ever find some free memory.

Still don't think I've got minimal ML working. Shouldn't it boot all the way to the Canon GUI? Maybe this camera doesn't have enough memory even for a minimal ML?

Thought I'd take a baby step and try to get the Model ID working in the recovery branch. We know there's enough memory for that:

(https://farm5.staticflickr.com/4288/35756843091_b634e90675.jpg)

Yay!

The Camera model isn't working but it isn't working for the EOSM, 100D or 700D either. Haven't been able to figure out why.
Title: Re: ML on EOS-M2
Post by: a1ex on July 13, 2017, 12:26:27 PM
https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-EOSM2/ - compiled from dfort's repo.

(https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-EOSM2/13/artifact/qemu/EOSM2.png)

Build log (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-EOSM2/13/consoleFull)

Will explain CONFIG_ALLOCATE_MEMORY_POOL later.
Title: Re: ML on EOS-M2
Post by: dfort on July 13, 2017, 02:08:59 PM
From your console output (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-EOSM2/13/consoleFull):

Code: [Select]
sed -i 's/0xFF0C1C94/0xFF0C1C90/' platform/EOSM2.103/consts.h

I was that close?

[EDIT] Minimal ML working perfectly over here now. Well, it needs the debugmsg.gdb file while the 550D doesn't but that's a QEMU mystery.

Title: Re: ML on EOS-M2
Post by: dfort on July 16, 2017, 01:32:15 AM
Will explain CONFIG_ALLOCATE_MEMORY_POOL later.

Turned it on:

internals.h
Code: [Select]
/** This camera loads ML into the AllocateMemory pool **/
#define CONFIG_ALLOCATE_MEMORY_POOL

and set up a special case for the EOSM2

boot-hack.c
Code: [Select]
    #if defined(CONFIG_550D)
    // change end limit to 0xc60000 => reserve 640K for ML
    *addr_AllocMem_end = MOV_R1_0xC60000_INSTR;
    ml_reserved_mem = 640 * 1024;
   
    #elif defined(CONFIG_EOSM2) // experimenting - Hello World autoexec.bin is 425K
    *addr_AllocMem_end = MOV_R1_0xC80000_INSTR;
    ml_reserved_mem = 512 * 1024;
   
    #else
    // change end limit to 0xc80000 => reserve 512K for ML
    *addr_AllocMem_end = MOV_R1_0xC80000_INSTR;
    ml_reserved_mem = 512 * 1024;
    #endif

Of course like everything I try this doesn't work right away.

However, according to this post (http://www.magiclantern.fm/forum/index.php?topic=5071.msg186874#msg186874) from the "placing ML into shoot memory" topic the EOSM2 only has 256MB, same with the 1300D, so does this mean trying to get ML running on these cameras is a lost cause or should we keep trying to shoehorn it in somehow?
Title: Re: ML on EOS-M2
Post by: dfort on July 16, 2017, 04:42:15 AM
Made a test pull request against unified from my repository (kept in sync with the master unified branch) just to see what has changed and make it easy to find what is still left to do.

https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/4/eosm2103-wip/diff
Title: Re: ML on EOS-M2
Post by: a1ex on July 16, 2017, 10:06:22 AM
However, according to this post (http://www.magiclantern.fm/forum/index.php?topic=5071.msg186874#msg186874) from the "placing ML into shoot memory" topic the EOSM2 only has 256MB, same with the 1300D, so does this mean trying to get ML running on these cameras is a lost cause [...] ?

How much memory do your other cameras have?

How much memory does the 1100D have?
Title: Re: ML on EOS-M2
Post by: dfort on July 16, 2017, 08:02:45 PM
How much memory does the 1100D have?

According to the "placing ML into shoot memory" topic it has only 128MB (http://www.magiclantern.fm/forum/index.php?topic=5071.msg166993#msg166993) and of course it can run ML. So I started thinking, how did you do that trick? That is when I realized that I was in the Twilight Zone--in other words I was lost in another dimension, obsessing over shot memory and ignoring other options.

One option is to try the AllocateMemory (like 550D or 1100D), and another is to hunt for possibly unused memory areas (smemShowFix - FF222B68) - see http://www.magiclantern.fm/forum/index.php?topic=5071.0.

That lead me down a path where I was able to track down some more stubs that might be useful to experiment with the AllocateMemoryResource method used on the 60D and 7D:

Code: [Select]
/* here we are patching RscMgr/SRM initialisation to use less memory */
// used on 7D and 60D - found values for EOSM2 but haven't figured out how to implement it yet
// #define HIJACK_CACHE_HACK
// #define RSCMGR_MEMORY_PATCH_END          0xff0c4a8c
// #define HIJACK_CACHE_HACK_INITTASK_ADDR  0xff0c1c98

Of course this isn't working (not enough shot memory?) and am back to pondering over these options:

in canon's firmware we have three options how to allocate memory and where to place data.

1) malloc
2) AllocateMemory (MemoryManager)
3) AllocateMemoryResource (RscMgr, Srm)

By the way, I like looking at graphs better than lists of hexadecimal numbers and the graphs on the placing ML into shoot memory (http://www.magiclantern.fm/forum/index.php?topic=5071.0) topic have disappeared when using the Chrome browser. Looking into the issue it seems that Google has been implementing stricter rules that is affecting the link to your graph: https://a1ex.magiclantern.fm/bleeding-edge/RscMgr/EOSM2.png

(https://farm5.staticflickr.com/4298/35920873166_b2b57e31eb.jpg)

That graph is helpful so if you don't mind I uploaded it to Flickr in case that is happening with others who are following this topic.

(https://farm5.staticflickr.com/4323/35122119534_84ba616817_z.jpg) (https://flic.kr/p/VvC3v5)EOSM2 (https://flic.kr/p/VvC3v5) by Daniel Fort (https://www.flickr.com/photos/dan_fort/), on Flickr

Ok--so what are we looking at here? Is that two ways of looking at the same thing? Before and after memory allocation? Something there must have caused your to come up with this:

...I'm thinking to move autoexec.bin to AllocateMemory, and use the 7MB block as general-purpose memory for ML, using some custom allocator (maybe Canon's).

It hasn't sunk into my thick skull yet and I found myself in another Catch 22 situation. In order to create the data needed for these graphs the instructions (http://www.magiclantern.fm/forum/index.php?topic=5071.msg166799#msg166799) are to:

- compile the dm-spy-experiments branch, with CONFIG_DEBUG_INTERCEPT=y in Makefile.user
- put this in don't click me...

(For the EOSM2)
Code: [Select]
    void debug_intercept();
    debug_intercept();
    void (*smemShowFix)(void) = 0xff222b6c;
    smemShowFix();
    debug_intercept();

There are also some stubs to look for so I followed the excellent example by @josepvm and translated it to the EOSM2

Code: [Select]
/** Low-level allocators */

NSTUB(0x79fc, init_memory_pool) 
NSTUB(0x8080, allocate_memory_from_pool)
NSTUB(0x83ec, free_memory_to_pool)
NSTUB(0x7ea0, get_max_region_of_pool)

Now how did you run that? I've got a feeling you're 10 steps ahead of me and already have a full ML for the EOSM2 working in QEMU--or you have an EOSM2 running ML and are keeping it a secret.
Title: Re: ML on EOS-M2
Post by: a1ex on July 17, 2017, 12:39:54 AM
Now how did you run that?

As simple as... (http://www.magiclantern.fm/forum/index.php?topic=15895.msg186872#msg186872)

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d debugmsg -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
...
CTRL-C
(gdb) set $pc = 0xff222b64
(gdb) continue

Quote
Is that two ways of looking at the same thing?
Yes.

Quote
Before and after memory allocation?
No.

Quote
Ok--so what are we looking at here?

Besides standard C malloc (aka user_mem in DryOS), and a similar allocator named AllocateMemory (sys_mem - nope, that's a third one), which both live in a tiny space of about 12MB (the gray bar at the left - 13MB on most models), for the memory-hungry stuff, Canon code uses a bunch of hardcoded regions (which may change according to operating modes). The graph shows these regions (top: scaled to show their real size, bottom: scaled so you can read the text).

Some of these regions are managed by allocators (shoot_malloc, srm_malloc), but it's not very clear which and when. It's one thing in photo mode and another in LiveView. Consider modes like video recording, raw developing, direct print (anyone uses it?) or wifi operation, and it starts to get really complicated. The safest way is to rely on these allocators when a large amount of memory is needed, and free it as soon as you no longer need it (otherwise you may not be able to change between some of the above modes). That's why the memory backend avoids shoot/srm allocators until it has no other choice. That's also the explanation for the second way to trigger ERR70 described in the stack trace PR (https://bitbucket.org/hudson/magic-lantern/pull-requests/849/stack-trace-aka-backtrace-in-crash-logs/diff).

In some cases, there are memory areas that are never used by Canon code (they are marked as full-height gray bars). We can double-check whether these are really unused (by making sure nobody writes to them while operating the camera in all possible modes we can think of), and if they are really free, we can take them. Caveat: they might be using stuff that's not listed in this log (as parts of that log are also hardcoded, so there's nothing to make sure what's in the log actually matches reality - they could have printed any numbers). On 60D, a region identified as free in this graph was later found to be actually used by Canon code (see the RscMgr PR, where we ran into trouble because of that). So, take this graph with a grain of salt.

For ML, we only need about 512K to load autoexec.bin (compare that to 128MB or even 64 for the 1000D). The other stuff (modules, work memory, whatever) are allocated dynamically, which is less troublesome, as the memory backend figures out which allocators to use, and lets you configure additional ones. But the initial code (autoexec.bin) has to be loaded statically, at some predefined address (unless you relocate it).

Of course, we can move everything to modules and end up with a very small static binary. It's a little more difficult than copy/paste though. Or you can try to compile as Thumb (good luck figuring it out).

Or, we can disable some features. You can even comment out features.h, CONFIG_RAW_* and fix up whatever gives compilation errors - that way, you'll get just the menu with a few debug items inside. It's best to do that anyway, and enable features one by one - otherwise you may end up with lots of possibly broken features (as it's really hard to test every single thing - I used to do that manually years ago), and if it's not something really widely used, you get a bug report after some months or years (even if the feature is not working at all).

Exercise: draw a similar memory map for DryOS (the first ~13 MB), based on the info from this post (http://www.magiclantern.fm/forum/index.php?topic=15895.msg186872#msg186872). Find out where the minimal ML is loaded (draw the map before and after). Find out the memory pool used by AllocateMemory. Find out where it's initialized (hint: check QEMU source). Patch it.

After finishing this, you will have both the Hello World working and a very good understanding of how the memory is organized.
Title: Re: ML on EOS-M2
Post by: dfort on July 17, 2017, 05:35:44 PM
Excellent! Here are some highlights of the output--totaling over 3625 lines!

Code: [Select]
^C
Program received signal SIGINT, Interrupt.
0xff352318 in ?? ()
(gdb) set $pc = 0xff222b6c
(gdb) continue
Continuing.
[    PowerMgr:ff222b78 ] (80:16)
   185:  3179.520 [RSC]
[    PowerMgr:ff222b94 ] (80:16) --- Common Top ----
   186:  3179.520 [RSC] --- Common Top ----
[    PowerMgr:ff222bb0 ] (80:16) [TOP1]                  0x40C2A000
   187:  3179.776 [RSC] [TOP1]                  0x40C2A000
[    PowerMgr:ff222bd4 ] (80:16) REPLACE_IMAGE_VRAM      0x40C2A000 0x00032000 204800
   188:  3179.776 [RSC] REPLACE_IMAGE_VRAM      0x40C2A000 0x00032000 204800
[    PowerMgr:ff222bfc ] (80:16) SSS_DEVELOP_WORK        0x40C5C000 0x00038000 229376
   189:  3180.032 [RSC] SSS_DEVELOP_WORK        0x40C5C000 0x00038000 229376
...
[    PowerMgr:ff223f78 ] (80:16) INDV_WORK               0x0 0x00000000 0
   274:  3187.712 [RSC] INDV_WORK               0x0 0x00000000 0
[    PowerMgr:ff0c2994 ] (8b:16) ###exceptionhandlercbr 0xda2c 0
   275:  3187.712 [STARTUP] ###exceptionhandlercbr 0xda2c 0
< Error Exception>
TYPE        : 4
ISR         : 0
TASK IDSR   : 1835011
TASK Name   : PowerMgr
R 0         : 0
R 1         : 19980218
R 2         : 0
R 3         : 0
R 4         : 19980218
R 5         : 19980218
R 6         : 19980218
R 7         : 19980218
R 8         : 19980218
R 9         : ca18
R10         : 19980218
R11         : 19980218
R12         : 1008
R13         : b89a0
R14         : da2c
PC          : da2c
CPSR        : 600000d3
[    PowerMgr:ff0c2ac4 ] (8b:16) #####exceptionhandlercbr 0xda2c
   276:  3188.480 [STARTUP] #####exceptionhandlercbr 0xda2c
[    PowerMgr:ff0c2ad4 ] (8b:03) < Error Exception>         
[    PowerMgr:ff0c2ae8 ] (8b:03) TYPE        : 4         
[    PowerMgr:ff0c2afc ] (8b:03) ISR         : 0         
[    PowerMgr:ff0c2b10 ] (8b:03) TASK IDSR   : 1835011       
[    PowerMgr:ff0c2b24 ] (8b:03) TASK Name   : PowerMgr     
[    PowerMgr:ff0c2b38 ] (8b:03) R 0         : 0       
[    PowerMgr:ff0c2b4c ] (8b:03) R 1         : 19980218   
[    PowerMgr:ff0c2b60 ] (8b:03) R 2         : 0     
[    PowerMgr:ff0c2b74 ] (8b:03) R 3         : 0       
[    PowerMgr:ff0c2b88 ] (8b:03) R 4         : 19980218       
[    PowerMgr:ff0c2b9c ] (8b:03) R 5         : 19980218
[    PowerMgr:ff0c2bb0 ] (8b:03) R 6         : 19980218       
[    PowerMgr:ff0c2bc4 ] (8b:03) R 7         : 19980218         
[    PowerMgr:ff0c2bd8 ] (8b:03) R 8         : 19980218         
[    PowerMgr:ff0c2bec ] (8b:03) R 9         : ca18         
[    PowerMgr:ff0c2c00 ] (8b:03) R10         : 19980218
[    PowerMgr:ff0c2c14 ] (8b:03) R11         : 19980218       
[    PowerMgr:ff0c2c28 ] (8b:03) R12         : 1008         
[    PowerMgr:ff0c2c3c ] (8b:03) R13         : b89a0         
[    PowerMgr:ff0c2e7c ] (8b:03) R14         : da2c           
[    PowerMgr:ff0c2e90 ] (8b:03) PC          : da2c             
[    PowerMgr:ff0c2ea4 ] (8b:03) CPSR        : 600000d3               
[    PowerMgr:ff0c2ee8 ] (8b:16) Exception : Time 2000/1/1 0:0:3
   277:  3188.736 [STARTUP] Exception : Time 2000/1/1 0:0:3
[      DbgMgr:ff1470d0 ] (00:01) [PM] DisablePowerSave (Counter = 2)
FF0C11BC: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
FF0C11BC: MCR p15, ...          : CACHEMAINT x11722 (omitted)
FF0C11BC: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC0051079
FF0C11F0: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC0051079
...
FF0C1120: MCR p15, ...          : CACHEMAINT x1 (omitted)
FF0C113C: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005007D
FF0C1168: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005007D
FF0C1120: MCR p15, ...          : CACHEMAINT x1 (omitted)
FF0C1168: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D


[DM] FROM Write Complete!!!
[      DbgMgr:ff147140 ] (00:01) [PM] EnablePowerSave (Counter = 1)



And trimming it down to just what we're interested in:

Code: [Select]
   186:  3179.520 [RSC] --- Common Top ----
   187:  3179.776 [RSC] [TOP1]                  0x40C2A000
   188:  3179.776 [RSC] REPLACE_IMAGE_VRAM      0x40C2A000 0x00032000 204800
   189:  3180.032 [RSC] SSS_DEVELOP_WORK        0x40C5C000 0x00038000 229376
   190:  3180.032 [RSC] SDS_DEVELOP_WORK        0x40C94000 0x00038000 229376
   191:  3180.032 [RSC] DARKCUR_COMP_WORK       0x40CCC000 0x00020000 131072
   192:  3180.288 [RSC] FENCING_WORK            0x40CEC000 0x00010000 65536
   193:  3180.288 [RSC] DCFNO                   0x40CFC000 0x00004000 16384
   194:  3180.544 [RSC] LVMARGE_P_DEF_DATA_1    0x40D00000 0x0000A000 40960
   195:  3180.544 [RSC] LVMARGE_P_DEF_DATA_2    0x40D0A000 0x0000A000 40960
   196:  3180.800 [RSC] LVMARGE_P_DEF_DATA_3    0x41FF0000 0x0000A000 40960
   197:  3180.800 [RSC] LVMARGE_P_DEF_DATA_ZOOM 0x40D14000 0x0000C000 49152
   198:  3180.800 [RSC] FILE_HEADER             0x40D20000 0x00240000 2359296
   199:  3181.056 [RSC] SAF WORK                0x40FA0000 0x00200000 2097152
   200:  3181.056 [RSC] BMPVRAM1                0x411A0000 0x00080000 524288
   201:  3181.056 [RSC] BMPVRAM2                0x41220000 0x00080000 524288
   202:  3181.312 [RSC] ENGINE_MIRROR           0x412A0000 0x00044000 278528
   203:  3181.568 [RSC] VSHADING_COMP_WORK      0x412E4000 0x000DC000 901120
   204:  3181.568 [RSC] STILL SCAR              0x413C0000 0x00075B00 482048
   205:  3181.568 [RSC] TUNEDATA                0x41435B00 0x00140000 1310720
   206:  3181.824 [RSC] TUNEDATA2               0x41575B00 0x00160000 1441792
   207:  3181.824 [RSC] FIXDATA                 0x416D5B00 0x0021E500 2221312
   208:  3181.824 [RSC] LVMARGE_P_DEF_DATA_CROP 0x418F4000 0x0000C000 49152
   209:  3182.080 [RSC] WIRELESS_WORK2          0x41900000 0x00300000 3145728
   210:  3182.080 [RSC] WIRELESS_WORK1   *      0x41C00000 0x00200000 2097152
   211:  3182.080 [RSC] ADAPTER_TRANSFER *      0x0 0x00000000 0
   212:  3182.336 [RSC] EEKO                    0x41E00000 0x001E0000 1966080
   213:  3182.336 [RSC] SHOOTING_CREATIVEFILTER 0x41FE0000 0x00010000 65536
   214:  3182.336 [RSC] EXMEM3_AREA_4           0x0 0x00000000 0
   215:  3182.592 [RSC] --- Usually Mode ----
   216:  3182.592 [RSC] MEMORY_MGR              0x42000000 0x04000000 67108864
   217:  3182.592 [RSC] ONLY MEM1 1             0x46000000 0x02000000 33554432
   218:  3182.848 [RSC] ONLY MEM1 2             0x48000000 0x02000000 33554432
   219:  3182.848 [RSC] IMGPLAY_WORK            0x4A000000 0x00A00000 10485760
   220:  3182.848 [RSC] IMGPLAY_WORK2           0x4AA00000 0x00400000 4194304
   221:  3183.104 [RSC] SS_DEVELOP1             0x4A000000 0x00E00000 14680064
   222:  3183.104 [RSC] EXMEM3_AREA_2           0x4AE00000 0x000EA000 958464
   223:  3183.104 [RSC] AVERAGE_WORK_TOP        0x4AEEA000 0x01116000 17915904
   224:  3183.360 [RSC] AVERAGE_WORK_BOTTOM     0x4C000000 0x01116000 17915904
   225:  3183.360 [RSC] SS_DEVELOP_OTHER_WORK   0x4D116000 0x00400000 4194304
   226:  3183.360 [RSC] SLIDE_SHOW_WORK         0x4D516000 0x00800000 8388608
   227:  3183.616 [RSC] CAPTURE_WORK1           0x4D600000 0x00240000 2359296
   228:  3183.616 [RSC] EXMEM3_AREA_1           0x4DD16000 0x016BA000 23830528
   229:  3183.872 [RSC] IMGVRAM1                0x4F3D0000 0x00410000 4259840
   230:  3183.872 [RSC] IMGVRAM2                0x4F7E0000 0x00410000 4259840
   231:  3183.872 [RSC] IMGVRAM3                0x4FBF0000 0x00410000 4259840
   232:  3183.872 [RSC] ---   GIS Mode   ----
   233:  3184.128 [RSC] TEMPMEM1                0x48000000 0x02000000 33554432
   234:  3184.128 [RSC] WORK                    0x4A000000 0x08600000 140509184
   235:  3184.128 [RSC] IMGPLAY_WORK            0x4A000000 0x00A00000 10485760
   236:  3184.384 [RSC] IMGPLAY_WORK2           0x4AA00000 0x00400000 4194304
   237:  3184.384 [RSC] MOVIE_REC_WORK          0x4AE00000 0x00FA0000 16384000
   238:  3184.384 [RSC] MOVIE_PLAY_WORK         0x4BE00000 0x00E00000 14680064
   239:  3184.640 [RSC] SLIDE_SHOW_WORK         0x4D516000 0x00800000 8388608
   240:  3184.640 [RSC] MOVIE_STREAM            0x4DD16000 0x01400000 20971520
   241:  3184.640 [RSC] IMGVRAM1                0x4F3D0000 0x00410000 4259840
   242:  3184.896 [RSC] IMGVRAM2                0x4F7E0000 0x00410000 4259840
   243:  3184.896 [RSC] IMGVRAM3                0x4FBF0000 0x00410000 4259840
   244:  3185.152 [RSC] EXMEM3_1_AREA           0x42000000 0x06000000 100663296
   245:  3185.152 [RSC] EXMEM3_2_AREA           0x4CC40000 0x004D6000 5070848
   246:  3185.152 [RSC] ---   HDR Mode   ----
   247:  3185.152 [RSC] TEMPMEM1                0x48000000 0x02000000 33554432
   248:  3185.408 [RSC] WORK                    0x4800000 0x0A600000 174063616
   249:  3185.408 [RSC] IMGPLAY_WORK            0x4A000000 0x00A00000 10485760
   250:  3185.408 [RSC] IMGPLAY_WORK2           0x4AA00000 0x00400000 4194304
   251:  3185.664 [RSC] MOVIE_REC_WORK          0x4AE00000 0x00FA0000 16384000
   252:  3185.664 [RSC] MOVIE_PLAY_WORK         0x4BE00000 0x00E00000 14680064
   253:  3185.664 [RSC] SLIDE_SHOW_WORK         0x4D516000 0x00800000 8388608
   254:  3185.920 [RSC] MOVIE_STREAM            0x4DD16000 0x01400000 20971520
   255:  3185.920 [RSC] IMGVRAM1                0x4F3D0000 0x00410000 4259840
   256:  3185.920 [RSC] IMGVRAM2                0x4F7E0000 0x00410000 4259840
   257:  3186.176 [RSC] IMGVRAM3                0x4FBF0000 0x00410000 4259840
   258:  3186.176 [RSC] EXMEM3_1_AREA           0x42000000 0x06000000 100663296
   259:  3186.176 [RSC] EXMEM3_2_AREA           0x4CC40000 0x004D6000 5070848
   260:  3186.432 [RSC] ---    NR Mode   ----
   261:  3186.688 [RSC] NR_MEMORY_MGR           0x42000000 0x08000000 134217728
   262:  3186.688 [RSC] COMPOSITION_WORK_TOP    0x0 0x00000000 0
   263:  3186.688 [RSC] COMPOSITION_WORK_BOTTOM 0x0 0x00000000 0
   264:  3186.688 [RSC] ---    DP Mode   ----
   265:  3186.944 [RSC] DP_SINGLE               0x42000000 0x05E00000 98566144
   266:  3186.944 [RSC] DP_MULTI                0x47E00000 0x04D94000 81346560
   267:  3186.944 [RSC] DP_CAPTURE_WORK1        0x4CB94000 0x00040000 262144
   268:  3187.200 [RSC] DP_AVERAGE_TOP          0x4DBD4000 0x01116000 17915904
   269:  3187.200 [RSC] DP_AVERAGE_BOTTOM       0x4ECEA000 0x01116000 17915904
   270:  3187.200 [RSC] --- Indev Mode ----
   271:  3187.456 [RSC] [INDVMGR]               0x0
   272:  3187.456 [RSC] YUV                     0x4AEEA000 0x0222C000 35831808
   273:  3187.456 [RSC] YUV_OUT                 0x42000000 0x0222C000 35831808
   274:  3187.712 [RSC] INDV_WORK               0x0 0x00000000 0

It is also interesting to look at an alternate version and follow along in the disassembly:

Code: [Select]
[    PowerMgr:ff223a54 ] (80:16) ---   HDR Mode   ----
[    PowerMgr:ff223a74 ] (80:16) TEMPMEM1                0x48000000 0x02000000 33554432
[    PowerMgr:ff223a94 ] (80:16) WORK                    0x4800000 0x0A600000 174063616
[    PowerMgr:ff223ab4 ] (80:16) IMGPLAY_WORK            0x4A000000 0x00A00000 10485760
[    PowerMgr:ff223ad4 ] (80:16) IMGPLAY_WORK2           0x4AA00000 0x00400000 4194304
[    PowerMgr:ff223af4 ] (80:16) MOVIE_REC_WORK          0x4AE00000 0x00FA0000 16384000
[    PowerMgr:ff223b14 ] (80:16) MOVIE_PLAY_WORK         0x4BE00000 0x00E00000 14680064
[    PowerMgr:ff223b34 ] (80:16) SLIDE_SHOW_WORK         0x4D516000 0x00800000 8388608
[    PowerMgr:ff223b54 ] (80:16) MOVIE_STREAM            0x4DD16000 0x01400000 20971520
[    PowerMgr:ff223b74 ] (80:16) IMGVRAM1                0x4F3D0000 0x00410000 4259840
[    PowerMgr:ff223d90 ] (80:16) IMGVRAM2                0x4F7E0000 0x00410000 4259840
[    PowerMgr:ff223db0 ] (80:16) IMGVRAM3                0x4FBF0000 0x00410000 4259840
[    PowerMgr:ff223dd0 ] (80:16) EXMEM3_1_AREA           0x42000000 0x06000000 100663296
[    PowerMgr:ff223dec ] (80:16) EXMEM3_2_AREA           0x4CC40000 0x004D6000 5070848

BTW--interesting side trip into the Thumb (https://en.wikipedia.org/wiki/ARM_architecture#Thumb) instruction set. Looks like it is possible to mix it with standard ARM instructions (http://www.simplemachines.it/doc/ARM_COMBO_ap01.html).

Ok--back to work:

Exercise: draw a similar memory map for DryOS (the first ~13 MB), based on the info from this post (http://www.magiclantern.fm/forum/index.php?topic=15895.msg186872#msg186872). Find out where the minimal ML is loaded (draw the map before and after). Find out the memory pool used by AllocateMemory. Find out where it's initialized (hint: check QEMU source). Patch it.
Title: Re: ML on EOS-M2
Post by: a1ex on July 17, 2017, 06:15:22 PM
You may wonder - why are all these messages doubled?
Code: [Select]
[    PowerMgr:ff222b94 ] (80:16) --- Common Top ----
   186:  3179.520 [RSC] --- Common Top ----

The first format is written by "-d debugmsg" (we are printing the arguments to DebugMsg and some context - task and address where it was called from).

The second format is written to UART (possibly one of these pins (https://www.magiclantern.fm/forum/index.php?topic=7531)) by Canon code - they do that for important messages (whatever that means - we don't know much about it (http://magiclantern.wikia.com/wiki/Debugging_Magic_Lantern#DebugMsg_and_DEBUG.28.29_macro)).

You can redirect the UART messages to a file (e.g. "-serial file:uart.log"). The bootloader menu (printed e.g. if you start from a bootable card without autoexec.bin present) also goes to the serial port - you can interact with it from the console if you use "-serial stdio". These are standard QEMU options - you can use them on any other guest OS that uses a serial port.

TODO: the serial console is also usable while running the firmware (and you can call these info functions from there - example (https://nada-labs.net/2014/finding-jtag-on-a-canon-elph100hs-ixus115/)). The emulation is probably missing an interrupt or some status bits on the UART in order to accept incoming characters.
Title: Re: ML on EOS-M2
Post by: dfort on July 22, 2017, 12:59:44 AM
I've amassed a boat load of data but have no idea how to draw a graph that makes any sense of it.

Feels like this is very close. Here are some highlights of where things are at (using HIJACK_CACHE_HACK):

Code: [Select]
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
...
File size : 0x67A00
Now jump to AUTOEXEC.BIN!!
0010E5F4: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
0010E5F4: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D
[BOOT] patching init_task from 0xff0c57a0 (-15968352)
[BOOT] autoexec.bin loaded at 100E00 - 178140.

Great -- autoexec.bin is loaded, next surprise is that the Canon GUI comes up in the QEMU window.

Code: [Select]
[     FileMgr:ff304f9c ] (24:02) PROP_TFT_STATUS = 0
[     FileMgr:ff304fb4 ] (24:03) LED Permit
[MPU] Received: 06 05 03 19 00 00  (spell #52)
[    PowerMgr:ff13826c ] (82:01) VdInterruptHandler bmp=ff136384 img=0 localWaitBmpCBR=ff136384
[    PowerMgr:ff136398 ] (82:01) WaitBmpCBR(local) pParam=0
[  DisplayMgr:ff13a118 ] (82:03) MuteOffDisplay finish Type=0
[  DisplayMgr:ff1790cc ] (9a:02) fTunOnDisp = On

Then it gets ugly:

Code: [Select]
[      init:0010137c ] task_create(ml_init, prio=1e, stack=4000, entry=101510, arg=0)
[     ml_init:ff696760 ] (23:01) sdReadBlk: st=73344, num=32, buf=0x4035e000
[     ml_init:ff6951bc ] (23:01) sdDMAReadBlk: st=73344, num=32
qemu: fatal: Trying to execute code outside RAM or ROM at 0x20000000

R00=ffffffff R01=00987c0a R02=001f3912 R03=00000000
R04=19980030 R05=00000000 R06=596f0ae0 R07=19980218
R08=1998002e R09=19980218 R10=19980218 R11=19980218
R12=00000007 R13=001f3918 R14=00101cc0 R15=20000000
PSR=60000013 -ZC- A svc32
FPSCR: 00000000
qemu: fatal: Trying to execute code outside RAM or ROM at 0x20000000

Here's the full console output: https://pastebin.com/5P45Ujtz

Homework assignment --> F-incomplete (graph missing, Hello World not working)

(gdb) set $pc = 0xFF0C6E70
Code: [Select]
# No ML
sys_mem_start   0x0018ac00
sys_mem_max        1179648
user_mem_start  0x00100d80
user_mem_max        515828

# Minimal ML
sys_mem_start   0x0018ac00
sys_mem_max        1179648
user_mem_start  0x00104580
user_mem_max        501492

# Current almost working full ML Hello World
sys_mem_start   0x0018ac00
sys_mem_max        1179648
user_mem_start  0x00100d80
user_mem_max        515828

(gdb) set $pc = 0xff0c750c
Code: [Select]
# No ML
Malloc Information (onetime type)
  Start Address       = 0x00100d88
  End Address         = 0x0017ea60
  Total Size          = 0x0007dcd8 (   515288)
  Allocated Size      = 0x00015ab0 (    88752)
  Allocated Peak      = 0x00015ab0 (    88752)
  Allocated Count     = 0x0000005a (       90)
  Free Size           = 0x00068228 (   426536)
  Free Block Max Size = 0x000681f0 (   426480)
  Free Block Count    = 0x00000002 (        2)

# Minimal ML
Malloc Information (onetime type)
  Start Address       = 0x00104588
  End Address         = 0x0017ea60
  Total Size          = 0x0007a4d8 (   500952)
  Allocated Size      = 0x00015ab0 (    88752)
  Allocated Peak      = 0x00015ab0 (    88752)
  Allocated Count     = 0x0000005a (       90)
  Free Size           = 0x00064a28 (   412200)
  Free Block Max Size = 0x000649f0 (   412144)
  Free Block Count    = 0x00000002 (        2)

# Current almost working full ML Hello World
Malloc Information (onetime type)
  Start Address       = 0x00100d88
  End Address         = 0x0017ea60
  Total Size          = 0x0007dcd8 (   515288)
  Allocated Size      = 0x00015ab0 (    88752)
  Allocated Peak      = 0x00015ab0 (    88752)
  Allocated Count     = 0x0000005a (       90)
  Free Size           = 0x00068228 (   426536)
  Free Block Max Size = 0x000681f0 (   426480)
  Free Block Count    = 0x00000002 (        2)

(gdb) set $pc = 0xff134304
Code: [Select]
# No ML
   189:  1284.352 [WINSYS] allocated=44140 max_region=412876

# Minimal ML
   185:  1840.896 [WINSYS] allocated=44140 max_region=412876

# Current almost working full ML Hello World
   185:  1042.176 [WINSYS] allocated=44140 max_region=412876

# No change in the above but when experimenting with CONFIG_ALLOCATE_MEMORY_POOL this came up:
[    PowerMgr:ff13432c ] (04:16) allocated=0 max_region=1568300

(gdb) set $pc = 0xff1343f4
Code: [Select]
# No ML
[    PowerMgr:ff134450 ] (04:02) current=44140 max_reg=412876 allocate_size=0
   185:  1667.328 [MEM] NG AllocateMemory 0
   186:  1667.584 [MEM] Total = 0x7be000, Free = 0x3148b8, MaxReg = 0x2a320c
   187:  1667.840 [MEM] Num Alloc = 4864, Num Free = 460

# Minimal ML
[    PowerMgr:ff134450 ] (04:02) current=44140 max_reg=412876 allocate_size=0
   185:  2236.928 [MEM] NG AllocateMemory 0
   186:  2236.928 [MEM] Total = 0x7be000, Free = 0x3148b8, MaxReg = 0x2a31a0
   187:  2237.184 [MEM] Num Alloc = 4864, Num Free = 460

# Current almost working full ML Hello World
[    PowerMgr:ff134450 ] (04:02) current=44140 max_reg=412876 allocate_size=0
   185:  1226.752 [MEM] NG AllocateMemory 0
   186:  1227.008 [MEM] Total = 0x7be000, Free = 0x3148b8, MaxReg = 0x2a31f0
   187:  1227.264 [MEM] Num Alloc = 4864, Num Free = 460
Title: Re: ML on EOS-M2
Post by: dfort on July 22, 2017, 04:19:51 AM
My previous post was about what is almost working over here. This post is about what should be working but is a little further away than "almost."

#define CONFIG_ALLOCATE_MEMORY_POOL

Find out where the minimal ML is loaded (draw the map before and after). Find out the memory pool used by AllocateMemory. Find out where it's initialized (hint: check QEMU source). Patch it.

Is that QEMU source hint in memcheck.c? There are stubs in there but only for the 500D. So other cameras don't need this or is the 500D supported better in QEMU than any other camera? Ok, lots of other interesting stuff in there including something that looks like it is triggering the error message on my HIJACK_CACHE_HACK attempt:

Code: [Select]
assert(addr < 0x20000000);
[EDIT] This also looks like it can be useful once I learn how to use it:

Code: [Select]
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-readelf ~/magic-lantern/platform/EOSM2.103/magiclantern -a | grep " memcpy$"
  5694: 00148c94   360 FUNC    GLOBAL DEFAULT    1 memcpy

I'm still trying to understand how AllocateMemory works and believe me I'm trying. Here I created a huge table and found that while most addresses didn't change between No ML, Minimal ML and the almost working HIJACK_CACHE_HACK build, there were some very significant changes in the AllocateMemory attempt.

Code: [Select]
   186:  1221.888 [RSC] --- Common Top ----     No ML                               Minimal ML                          Almost working full ML Hello World  AllocateMemory (not working)                             
   187:  1221.888 [RSC] [TOP1]                  0x40C2A000                          0x40C2A000                          0x40C2A000                          0x0
   188:  1222.144 [RSC] REPLACE_IMAGE_VRAM      0x40C2A000 0x00032000 204800        0x40C2A000 0x00032000 204800        0x40C2A000 0x00032000 204800        0x0 0x00032000 204800
   189:  1222.144 [RSC] SSS_DEVELOP_WORK        0x40C5C000 0x00038000 229376        0x40C5C000 0x00038000 229376        0x40C5C000 0x00038000 229376        0x32000 0x00038000 229376
   190:  1222.400 [RSC] SDS_DEVELOP_WORK        0x40C94000 0x00038000 229376        0x40C94000 0x00038000 229376        0x40C94000 0x00038000 229376        0x6A000 0x00038000 229376
   191:  1222.400 [RSC] DARKCUR_COMP_WORK       0x40CCC000 0x00020000 131072        0x40CCC000 0x00020000 131072        0x40CCC000 0x00020000 131072        0xA2000 0x00020000 131072
   192:  1222.656 [RSC] FENCING_WORK            0x40CEC000 0x00010000 65536         0x40CEC000 0x00010000 65536         0x40CEC000 0x00010000 65536         0xC2000 0x00010000 65536
   193:  1222.656 [RSC] DCFNO                   0x40CFC000 0x00004000 16384         0x40CFC000 0x00004000 16384         0x40CFC000 0x00004000 16384         0xD2000 0x00004000 16384
   194:  1222.912 [RSC] LVMARGE_P_DEF_DATA_1    0x40D00000 0x0000A000 40960         0x40D00000 0x0000A000 40960         0x40D00000 0x0000A000 40960         0xD6000 0x0000A000 40960
   195:  1223.168 [RSC] LVMARGE_P_DEF_DATA_2    0x40D0A000 0x0000A000 40960         0x40D0A000 0x0000A000 40960         0x40D0A000 0x0000A000 40960         0xE0000 0x0000A000 40960
   196:  1223.168 [RSC] LVMARGE_P_DEF_DATA_3    0x41FF0000 0x0000A000 40960         0x41FF0000 0x0000A000 40960         0x41FF0000 0x0000A000 40960         0x41FF0000 0x0000A000 40960
   197:  1223.424 [RSC] LVMARGE_P_DEF_DATA_ZOOM 0x40D14000 0x0000C000 49152         0x40D14000 0x0000C000 49152         0x40D14000 0x0000C000 49152         0xEA000 0x0000C000 49152
   198:  1223.424 [RSC] FILE_HEADER             0x40D20000 0x00240000 2359296       0x40D20000 0x00240000 2359296       0x40D20000 0x00240000 2359296       0xF6000 0x00240000 2359296
   199:  1223.680 [RSC] SAF WORK                0x40FA0000 0x00200000 2097152       0x40FA0000 0x00200000 2097152       0x40FA0000 0x00200000 2097152       0x376000 0x00200000 2097152
   200:  1223.936 [RSC] BMPVRAM1                0x411A0000 0x00080000 524288        0x411A0000 0x00080000 524288        0x411A0000 0x00080000 524288        0x576000 0x00080000 524288
   201:  1223.936 [RSC] BMPVRAM2                0x41220000 0x00080000 524288        0x41220000 0x00080000 524288        0x41220000 0x00080000 524288        0x5F6000 0x00080000 524288
   202:  1224.192 [RSC] ENGINE_MIRROR           0x412A0000 0x00044000 278528        0x412A0000 0x00044000 278528        0x412A0000 0x00044000 278528        0x676000 0x00044000 278528
   203:  1224.192 [RSC] VSHADING_COMP_WORK      0x412E4000 0x000DC000 901120        0x412E4000 0x000DC000 901120        0x412E4000 0x000DC000 901120        0x6BA000 0x000DC000 901120
   204:  1224.192 [RSC] STILL SCAR              0x413C0000 0x00075B00 482048        0x413C0000 0x00075B00 482048        0x413C0000 0x00075B00 482048        0x413C0000 0x00075B00 482048
   205:  1224.448 [RSC] TUNEDATA                0x41435B00 0x00140000 1310720       0x41435B00 0x00140000 1310720       0x41435B00 0x00140000 1310720       0x41435B00 0x00140000 1310720
   206:  1224.704 [RSC] TUNEDATA2               0x41575B00 0x00160000 1441792       0x41575B00 0x00160000 1441792       0x41575B00 0x00160000 1441792       0x41575B00 0x00160000 1441792
   207:  1224.704 [RSC] FIXDATA                 0x416D5B00 0x0021E500 2221312       0x416D5B00 0x0021E500 2221312       0x416D5B00 0x0021E500 2221312       0x416D5B00 0x0021E500 2221312
   208:  1224.704 [RSC] LVMARGE_P_DEF_DATA_CROP 0x418F4000 0x0000C000 49152         0x418F4000 0x0000C000 49152         0x418F4000 0x0000C000 49152         0x418F4000 0x0000C000 49152
   209:  1224.960 [RSC] WIRELESS_WORK2          0x41900000 0x00300000 3145728       0x41900000 0x00300000 3145728       0x41900000 0x00300000 3145728       0x41900000 0x00300000 3145728
   210:  1224.960 [RSC] WIRELESS_WORK1   *      0x41C00000 0x00200000 2097152       0x41C00000 0x00200000 2097152       0x41C00000 0x00200000 2097152       0x41C00000 0x00200000 2097152
   211:  1224.960 [RSC] ADAPTER_TRANSFER *      0x0 0x00000000                      00x0 0x00000000                     00x0 0x0000000                      00x0 0x00000000 0
   212:  1225.216 [RSC] EEKO                    0x41E00000 0x001E0000 1966080       0x41E00000 0x001E0000 1966080       0x41E00000 0x001E0000 1966080       0x41E00000 0x001E0000 1966080
   213:  1225.216 [RSC] SHOOTING_CREATIVEFILTER 0x41FE0000 0x00010000 65536         0x41FE0000 0x00010000 65536         0x41FE0000 0x00010000 65536         0x41FE0000 0x00010000 65536
   214:  1225.216 [RSC] EXMEM3_AREA_4           0x0 0x00000000                      00x0 0x00000000                     00x0 0x00000000                     00x0 0x00000000 0
   215:  1225.472 [RSC] --- Usually Mode ----
   216:  1225.472 [RSC] MEMORY_MGR              0x42000000 0x04000000 67108864      0x42000000 0x04000000 67108864      0x42000000 0x04000000 67108864      0x42000000 0x04000000 67108864
   217:  1225.472 [RSC] ONLY MEM1 1             0x46000000 0x02000000 33554432      0x46000000 0x02000000 33554432      0x46000000 0x02000000 33554432      0x46000000 0x02000000 33554432
   218:  1225.728 [RSC] ONLY MEM1 2             0x48000000 0x02000000 33554432      0x48000000 0x02000000 33554432      0x48000000 0x02000000 33554432      0x48000000 0x02000000 33554432
   219:  1225.728 [RSC] IMGPLAY_WORK            0x4A000000 0x00A00000 10485760      0x4A000000 0x00A00000 10485760      0x4A000000 0x00A00000 10485760      0x4A000000 0x00A00000 10485760
   220:  1225.728 [RSC] IMGPLAY_WORK2           0x4AA00000 0x00400000 4194304       0x4AA00000 0x00400000 4194304       0x4AA00000 0x00400000 4194304       0x4AA00000 0x00400000 4194304
   221:  1225.984 [RSC] SS_DEVELOP1             0x4A000000 0x00E00000 14680064      0x4A000000 0x00E00000 14680064      0x4A000000 0x00E00000 14680064      0x4A000000 0x00E00000 14680064
   222:  1225.984 [RSC] EXMEM3_AREA_2           0x4AE00000 0x000EA000 958464        0x4AE00000 0x000EA000 958464        0x4AE00000 0x000EA000 958464        0x4AE00000 0x000EA000 958464
   223:  1225.984 [RSC] AVERAGE_WORK_TOP        0x4AEEA000 0x01116000 17915904      0x4AEEA000 0x01116000 17915904      0x4AEEA000 0x01116000 17915904      0x4AEEA000 0x01116000 17915904
   224:  1226.240 [RSC] AVERAGE_WORK_BOTTOM     0x4C000000 0x01116000 17915904      0x4C000000 0x01116000 17915904      0x4C000000 0x01116000 17915904      0x4C000000 0x01116000 17915904
   225:  1226.240 [RSC] SS_DEVELOP_OTHER_WORK   0x4D116000 0x00400000 4194304       0x4D116000 0x00400000 4194304       0x4D116000 0x00400000 4194304       0x4D116000 0x00400000 4194304
   226:  1226.496 [RSC] SLIDE_SHOW_WORK         0x4D516000 0x00800000 8388608       0x4D516000 0x00800000 8388608       0x4D516000 0x00800000 8388608       0x4D516000 0x00800000 8388608
   227:  1226.496 [RSC] CAPTURE_WORK1           0x4D600000 0x00240000 2359296       0x4D600000 0x00240000 2359296       0x4D600000 0x00240000 2359296       0x4D600000 0x00240000 2359296
   228:  1226.496 [RSC] EXMEM3_AREA_1           0x4DD16000 0x016BA000 23830528      0x4DD16000 0x016BA000 23830528      0x4DD16000 0x016BA000 23830528      0x4DD16000 0x016BA000 23830528
   229:  1226.752 [RSC] IMGVRAM1                0x4F3D0000 0x00410000 4259840       0x4F3D0000 0x00410000 4259840       0x4F3D0000 0x00410000 4259840       0x4F3D0000 0x00410000 4259840
   230:  1226.752 [RSC] IMGVRAM2                0x4F7E0000 0x00410000 4259840       0x4F7E0000 0x00410000 4259840       0x4F7E0000 0x00410000 4259840       0x4F7E0000 0x00410000 4259840
   231:  1226.752 [RSC] IMGVRAM3                0x4FBF0000 0x00410000 4259840       0x4FBF0000 0x00410000 4259840       0x4FBF0000 0x00410000 4259840       0x4FBF0000 0x00410000 4259840
   232:  1227.008 [RSC] ---   GIS Mode   ----
   233:  1227.008 [RSC] TEMPMEM1                0x48000000 0x02000000 33554432      0x48000000 0x02000000 33554432      0x48000000 0x02000000 33554432      0x48000000 0x02000000 33554432
   234:  1227.008 [RSC] WORK                    0x4A000000 0x08600000 140509184     0x4A000000 0x08600000 140509184     0x4A000000 0x08600000 140509184     0x4A000000 0x08600000 140509184
   235:  1227.264 [RSC] IMGPLAY_WORK            0x4A000000 0x00A00000 10485760      0x4A000000 0x00A00000 10485760      0x4A000000 0x00A00000 10485760      0x4A000000 0x00A00000 10485760
   236:  1227.264 [RSC] IMGPLAY_WORK2           0x4AA00000 0x00400000 4194304       0x4AA00000 0x00400000 4194304       0x4AA00000 0x00400000 4194304       0x4AA00000 0x00400000 4194304
   237:  1227.264 [RSC] MOVIE_REC_WORK          0x4AE00000 0x00FA0000 16384000      0x4AE00000 0x00FA0000 16384000      0x4AE00000 0x00FA0000 16384000      0x4AE00000 0x00FA0000 16384000
   238:  1227.520 [RSC] MOVIE_PLAY_WORK         0x4BE00000 0x00E00000 14680064      0x4BE00000 0x00E00000 14680064      0x4BE00000 0x00E00000 14680064      0x4BE00000 0x00E00000 14680064
   239:  1227.520 [RSC] SLIDE_SHOW_WORK         0x4D516000 0x00800000 8388608       0x4D516000 0x00800000 8388608       0x4D516000 0x00800000 8388608       0x4D516000 0x00800000 8388608
   240:  1227.776 [RSC] MOVIE_STREAM            0x4DD16000 0x01400000 20971520      0x4DD16000 0x01400000 20971520      0x4DD16000 0x01400000 20971520      0x4DD16000 0x01400000 20971520
   241:  1227.776 [RSC] IMGVRAM1                0x4F3D0000 0x00410000 4259840       0x4F3D0000 0x00410000 4259840       0x4F3D0000 0x00410000 4259840       0x4F3D0000 0x00410000 4259840
   242:  1228.032 [RSC] IMGVRAM2                0x4F7E0000 0x00410000 4259840       0x4F7E0000 0x00410000 4259840       0x4F7E0000 0x00410000 4259840       0x4F7E0000 0x00410000 4259840
   243:  1228.032 [RSC] IMGVRAM3                0x4FBF0000 0x00410000 4259840       0x4FBF0000 0x00410000 4259840       0x4FBF0000 0x00410000 4259840       0x4FBF0000 0x00410000 4259840
   244:  1228.032 [RSC] EXMEM3_1_AREA           0x42000000 0x06000000 100663296     0x42000000 0x06000000 100663296     0x42000000 0x06000000 100663296     0x42000000 0x06000000 100663296
   245:  1228.288 [RSC] EXMEM3_2_AREA           0x4CC40000 0x004D6000 5070848       0x4CC40000 0x004D6000 5070848       0x4CC40000 0x004D6000 5070848       0x4CC40000 0x004D6000 5070848
   246:  1228.288 [RSC] ---   HDR Mode   ----
   247:  1228.288 [RSC] TEMPMEM1                0x48000000 0x02000000 33554432      0x48000000 0x02000000 33554432      0x48000000 0x02000000 3355443       20x48000000 0x02000000 33554432
   248:  1228.544 [RSC] WORK                    0x4800000 0x0A600000 174063616      0x4800000 0x0A600000 174063616      0x4800000 0x0A600000 174063616      0x4800000 0x0A600000 174063616
   249:  1228.544 [RSC] IMGPLAY_WORK            0x4A000000 0x00A00000 10485760      0x4A000000 0x00A00000 10485760      0x4A000000 0x00A00000 10485760      0x4A000000 0x00A00000 10485760
   250:  1228.544 [RSC] IMGPLAY_WORK2           0x4AA00000 0x00400000 4194304       0x4AA00000 0x00400000 4194304       0x4AA00000 0x00400000 4194304       0x4AA00000 0x00400000 4194304
   251:  1228.800 [RSC] MOVIE_REC_WORK          0x4AE00000 0x00FA0000 16384000      0x4AE00000 0x00FA0000 16384000      0x4AE00000 0x00FA0000 16384000      0x4AE00000 0x00FA0000 16384000
   252:  1228.800 [RSC] MOVIE_PLAY_WORK         0x4BE00000 0x00E00000 14680064      0x4BE00000 0x00E00000 14680064      0x4BE00000 0x00E00000 14680064      0x4BE00000 0x00E00000 14680064
   253:  1228.800 [RSC] SLIDE_SHOW_WORK         0x4D516000 0x00800000 8388608       0x4D516000 0x00800000 8388608       0x4D516000 0x00800000 8388608       0x4D516000 0x00800000 8388608
   254:  1229.056 [RSC] MOVIE_STREAM            0x4DD16000 0x01400000 20971520      0x4DD16000 0x01400000 20971520      0x4DD16000 0x01400000 20971520      0x4DD16000 0x01400000 20971520
   255:  1229.312 [RSC] IMGVRAM1                0x4F3D0000 0x00410000 4259840       0x4F3D0000 0x00410000 4259840       0x4F3D0000 0x00410000 4259840       0x4F3D0000 0x00410000 4259840
   256:  1229.312 [RSC] IMGVRAM2                0x4F7E0000 0x00410000 4259840       0x4F7E0000 0x00410000 4259840       0x4F7E0000 0x00410000 4259840       0x4F7E0000 0x00410000 4259840
   257:  1229.568 [RSC] IMGVRAM3                0x4FBF0000 0x00410000 4259840       0x4FBF0000 0x00410000 4259840       0x4FBF0000 0x00410000 4259840       0x4FBF0000 0x00410000 4259840
   258:  1229.568 [RSC] EXMEM3_1_AREA           0x42000000 0x06000000 100663296     0x42000000 0x06000000 100663296     0x42000000 0x06000000 100663296     0x42000000 0x06000000 100663296
   259:  1229.824 [RSC] EXMEM3_2_AREA           0x4CC40000 0x004D6000 5070848       0x4CC40000 0x004D6000 5070848       0x4CC40000 0x004D6000 5070848       0x4CC40000 0x004D6000 5070848
   260:  1229.824 [RSC] ---    NR Mode   ----
   261:  1229.824 [RSC] NR_MEMORY_MGR           0x42000000 0x08000000 134217728     0x42000000 0x08000000 134217728     0x42000000 0x08000000 134217728     0x42000000 0x08000000 134217728
   262:  1230.080 [RSC] COMPOSITION_WORK_TOP    0x0 0x00000000                      00x0 0x00000000                     00x0 0x00000000                     00x0 0x00000000 0
   263:  1230.080 [RSC] COMPOSITION_WORK_BOTTOM 0x0 0x00000000                      00x0 0x00000000                     00x0 0x00000000                     00x0 0x00000000 0
   264:  1230.080 [RSC] ---    DP Mode   ----
   265:  1230.336 [RSC] DP_SINGLE               0x42000000 0x05E00000 98566144      0x42000000 0x05E00000 98566144      0x42000000 0x05E00000 98566144      0x42000000 0x05E00000 98566144
   266:  1230.336 [RSC] DP_MULTI                0x47E00000 0x04D94000 81346560      0x47E00000 0x04D94000 81346560      0x47E00000 0x04D94000 81346560      0x47E00000 0x04D94000 81346560
   267:  1230.336 [RSC] DP_CAPTURE_WORK1        0x4CB94000 0x00040000 262144        0x4CB94000 0x00040000 262144        0x4CB94000 0x00040000 262144        0x4CB94000 0x00040000 262144
   268:  1230.592 [RSC] DP_AVERAGE_TOP          0x4DBD4000 0x01116000 17915904      0x4DBD4000 0x01116000 17915904      0x4DBD4000 0x01116000 17915904      0x4DBD4000 0x01116000 17915904
   269:  1230.592 [RSC] DP_AVERAGE_BOTTOM       0x4ECEA000 0x01116000 17915904      0x4ECEA000 0x01116000 17915904      0x4ECEA000 0x01116000 17915904      0x4ECEA000 0x01116000 17915904
   270:  1230.848 [RSC] --- Indev Mode ----
   271:  1230.848 [RSC] [INDVMGR]               0x00x00x00x0
   272:  1230.848 [RSC] YUV                     0x4AEEA000 0x0222C000 35831808      0x4AEEA000 0x0222C000 35831808      0x4AEEA000 0x0222C000 35831808      0x4AEEA000 0x0222C000 35831808
   273:  1230.848 [RSC] YUV_OUT                 0x42000000 0x0222C000 35831808      0x42000000 0x0222C000 35831808      0x42000000 0x0222C000 35831808      0x42000000 0x0222C000 35831808
   274:  1231.104 [RSC] INDV_WORK               0x0 0x00000000                      00x0 0x00000000                     00x0 0x00000000                     00x0 0x00000000 0

I've also been pouring over the code and zeroed in on this comment:

boot-hack.c
Code: [Select]
    // We shrink the AllocateMemory (system memory) pool in order to make space for ML binary
    // Example for the 1100D firmware
    // ff0197d8: init_task:
    // ff01984c: b CreateTaskMain
    //
    // ff0123c4 CreateTaskMain:
    // ff0123e4: mov r1, #13631488  ; 0xd00000  <-- end address
    // ff0123e8: mov r0, #3997696   ; 0x3d0000  <-- start address
    // ff0123ec: bl  allocatememory_init_pool

    // So... we need to patch CreateTaskMain, which is called by init_task.
    //
    // First we use Trammell's reloc.c code to relocate init_task and CreateTaskMain...

I looked over my disassemble.pl version of the 1100D (and 550D) and without giving away any more than what was already published--came up with this for the EOSM2:

Code: [Select]
EOSM2 stub:
NSTUB(0xFF0C57A0,  init_task)

ff0c57a0: push {r4, lr}
ff0c5814: b loc_ff0c3064 <-- call CreateTaskMain
...
ff0c3064: push {r1, r2, r3, r4, r5, lr}
...
ff0c30a4: ldr r1, [pc, #344] ; ff0c3204: (00c2a000)   <-- end address??
ff0c30a8: ldr r0, [pc, #344] ; ff0c3208: (0046c000)   <-- start address??
...
ff0c30c4: bl loc_ff146d3c <-- allocatememory_init_pool?

I'm pretty sure about the allocatememory_init_pool but not sure at all that I found the start and end addresses. I've been trying different addresses for ROM_ALLOCMEM_END but keep getting the same disappointing results.

consts.h
Code: [Select]
// Used in boot-hack.c with CONFIG_ALLOCATE_MEMORY_POOL
#define ROM_ITASK_START 0xff0c57a0
#define ROM_ITASK_END  0xff0cb994
#define ROM_CREATETASK_MAIN_START 0xff0c3064
#define ROM_CREATETASK_MAIN_END 0xff0c33dc
#define ROM_ALLOCMEM_END 0xff0c4a8c // 0xff0c30a8 0xff0c30a4 // kinda iffy
#define ROM_ALLOCMEM_INIT 0xff0c30c4
#define ROM_B_CREATETASK_MAIN 0xff0c5814

Had this camera been able to use the "classic" boot process (a.k.a. malloc?) we would probably be running code on the camera by now, right?
Title: Re: ML on EOS-M2
Post by: a1ex on July 22, 2017, 05:51:57 PM
Quote
So other cameras don't need this or is the 500D supported better in QEMU than any other camera?

500D was the first to get menu navigation in QEMU, and right now there are still some things that only work there (such as changing display color, or the memcheck tool). Also, in some places such as photo capture, Canon code is simpler (easier to understand).

Quote
ff0c30a4:    ldr r1, [pc, #344] ; ff0c3204: (00c2a000)   <-- end address??
ff0c30a8:    ldr r0, [pc, #344] ; ff0c3208: (0046c000)   <-- start address??
...
ff0c30c4:    bl loc_ff146d3c <-- allocatememory_init_pool?

Almost there - start and end address are correct, but allocatememory_init_pool is not.

During a function call, R0-R3 are not preserved; in particular, R0 is also used for return value. Therefore, whatever was loaded in R0 and R1 are parameters for the function call that follows immediately, but not for the subsequent functions.

Therefore, allocatememory_init_pool is the one called right after loading the parameters into registers:
Code: [Select]
FF0C30AC                 BL      0x7ABC <-- this one

Note that both 0x81F0 (AllocateMemory) and 0x7ABC (allocatememory_init_pool) reference the same memory address (0x90CC8). The latter (0x7ABC) writes something to this address (the result of 0x79FC), and this call contains a solid hint about the meaning of R0 and R1: start and end. Why? Because 0x79FC receives R0 = start and R1 = end-start, so the latter must be size:
Code: [Select]
00007ABC
...                      ; nothing else touching R0=start and R1=end
00007AD0                 SUB     R1, R1, R0
00007AD4                 BL      sub_79FC

In other words, the AllocateMemory pool is from 0x46c000 to 0xc2a000. Note that, unlike my previous comments (je me suis trompé), this is not the system memory area:

Code: [Select]
(gdb) set $pc=0xFF0C77EC
System Memory Information
  Start Address       = 0x0018ac08
  End Address         = 0x002aac00
  Total Size          = 0x0011fff8 (  1179640)
  Allocated Size      = 0x00062328 (   402216)
  Allocated Peak      = 0x00064b30 (   412464)
  Allocated Count     = 0x00000051 (       81)
  Free Size           = 0x000bdcd0 (   777424)
  Free Block Max Size = 0x000bb240 (   766528)
  Free Block Count    = 0x00000003 (        3)

I have a feeling this might be where DryOS allocates stack space for its tasks. Let's check:
Code: [Select]
arm-none-eabi-gdb -x EOSM2/patches.gdb & ./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S -d debugmsg,v |& grep "Current stack" | sort | cut -d ' ' -f 1-3 | uniq
...
Current stack: [18af38-18acb8]
...
Current stack: [1ed9b0-1ec9b0]

Confirmed. Finding the allocator for the system memory would be good for cameras with very little RAM (such as 1100D).

Back to our case - AllocateMemory uses a different block of memory (not sys_mem), so I'd better update the wrong comments in the source code.

Let's try to find out how much free space we have (GetMemoryInformation). From mem.c, we know this about it:
Code: [Select]
extern int GetMemoryInformation(int* total, int* free);

So, it takes 2 parameters, pointers to 32-bit integers. It will write the total amount into the first integer, and the amount of free space into the second integer.

Let's call it from gdb. Since we don't care about code execution after this function returns, we can just pick two arbitrary addresses to store the two integers (never do this on real hardware!)
Code: [Select]
(gdb) set $r0 = 4
(gdb) set $r1 = 8
(gdb) set $pc = 0xFFD25774
(gdb) b *$lr
Breakpoint 2 at 0xff352220
(gdb) c
Continuing.

Breakpoint 2, 0xff352220 in ?? ()
(gdb) x/2 4
0x4: 0x7be000 0x3148d0

Cross-checking: 0xc2a000 - 0x46c000 = 0x7be000.

So, that's what we have to patch in order to load ML.

TODO: I'd like to update 100D to use the "classic" boot process as well.
Title: Re: ML on EOS-M2
Post by: nikfreak on July 22, 2017, 07:23:33 PM

TODO: I'd like to update 100D to use the "classic" boot process as well.

as discussed here (https://bitbucket.org/hudson/magic-lantern/pull-requests/672/dryos-task-hooks-for-newer-cameras-6d-70d/diff) I failed to use AllocateMemory pool but:

Quote from: nikfreak
...I am able to load 100d into malloc but the interesting part I can only bring up ML menu with the task related changes from this PR in addition with a fixed task_dispatch_hook and undefining hijack_task_addr as instructed earlier. Otherwise ML menu wouldn't come up.

I'm ready If you want to give it another go.
Title: Re: ML on EOS-M2
Post by: dfort on July 23, 2017, 02:12:25 AM
Almost there - start and end address are correct, but allocatememory_init_pool is not.
...
...allocatememory_init_pool is the one called right after loading the parameters into registers:
Code: [Select]
FF0C30AC                 BL      0x7ABC <-- this one

Yikes! That's the first one I tried but later dismissed it.

In order to follow along on my disassembly I'm doing this:

Code: [Select]
0x7ABC + RAM_OFFSET
Code: [Select]
00007ABC
...                      ; nothing else touching R0=start and R1=end
00007AD0                 SUB     R1, R1, R0
00007AD4                 BL      sub_79FC

In other words, the AllocateMemory pool is from 0x46c000 to 0xc2a000. Note that, unlike my previous comments (je me suis trompé)...

Je suis clueless -- Hey, Google did the translation.

Let's check:
Code: [Select]
arm-none-eabi-gdb -x EOSM2/patches.gdb & ./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S -d debugmsg,v |& grep "Current stack" | sort | cut -d ' ' -f 1-3 | uniq
...
Current stack: [18af38-18acb8]
...
Current stack: [1ed9b0-1ec9b0]

Here is what I got:

Code: [Select]
arm-none-eabi-gdb -x EOSM2/patches.gdb & ./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S -d debugmsg,v |& grep "Current stack" | sort | cut -d ' ' -f 1-3 | uniq
[8] 28220

Getting rid of all the tricky stuff there really isn't much to search.

Code: [Select]
./run_canon_fw.sh EOSM2,firmware=boot=0 -s -S -d debugmsg,v
DebugMsg=0x4398 (from GDB script)
Lockdown read 0
Lockdown read 0
Lockdown read 1
Lockdown read 1
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 1FFFFFFF: eos.ram
40001000 - 5FFFFFFF: eos.ram_uncached
F0000000 - F0FFFFFF: eos.rom0
F1000000 - F1FFFFFF: eos.rom0_mirror
F2000000 - F2FFFFFF: eos.rom0_mirror
F3000000 - F3FFFFFF: eos.rom0_mirror
F4000000 - F4FFFFFF: eos.rom0_mirror
F5000000 - F5FFFFFF: eos.rom0_mirror
F6000000 - F6FFFFFF: eos.rom0_mirror
F7000000 - F7FFFFFF: eos.rom0_mirror
F8000000 - F8FFFFFF: eos.rom1
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
C0000000 - DFFFFFFF: eos.iomem
[EOS] enabling code execution logging.
[EOS] loading './EOSM2/ROM0.BIN' to 0xF0000000-0xF0FFFFFF
[EOS] loading './EOSM2/ROM1.BIN' to 0xF8000000-0xF8FFFFFF
[EOS] loading './EOSM2/SFDATA.BIN' as serial flash, size=0x1000000
[MPU] warning: non-empty spell #31 (08 06 03 1f) has duplicate(s): #40
[MPU] warning: non-empty spell #41 (0a 08 01 3b) has duplicate(s): #37 #38
[MPU] warning: non-empty spell #45 (26 24 01 4e) has duplicate(s): #46

[MPU] Available keys:
- Arrow keys   : Navigation
- [ and ]      : Main dial (top scrollwheel)
- SPACE        : SET
- DELETE       : guess
- M            : MENU
- P            : PLAY
- I            : INFO/DISP
- Q            : guess
- L            : LiveView
- Shift        : Half-shutter
- B            : Open battery cover
- F1           : show this help

Setting BOOTDISK flag to 0

Maybe a problem with this Mac QEMU? Seemed to be working fine up until now. Ok--moving on.

Finding the allocator for the system memory would be good for cameras with very little RAM (such as 1100D).

I was thinking of trying an alternate booting method on the original EOSM to see if that takes care of the shutter-bug. That is if I can ever get through this.

Code: [Select]
(gdb) set $r0 = 4
(gdb) set $r1 = 8
(gdb) set $pc = 0xFFD25774
(gdb) b *$lr
Breakpoint 2 at 0xff352220
(gdb) c
Continuing.

Breakpoint 2, 0xff352220 in ?? ()
(gdb) x/2 4
0x4: 0x7be000 0x3148d0

Ok--this works but how did you know to give r0 = 4 and r1 = 8? Then there's that tricky x/2 4. I tried other values and of course came up with different results. In any case, the important part is that:

Code: [Select]
end address - start address = free space
Great psudo code heh? Now is that really free space? Free as in beer? Or--is that total space? The latest autoexec.bin file I made was:

Code: [Select]
File size : 0x686A0

So--

Code: [Select]
0x7be000 - 0x686A0 = 0x755960
Plenty of space but is it shared with the Canon firmware? Yes--but there is still enough room for everybody?

So, that's what we have to patch in order to load ML.

Great, let's do this. First I saw what was done for the 550D and 1100D (the only other cameras that uses AllocateMemory pool) and added a special case for the EOSM2:

boot-hack.c
Code: [Select]
    #elif defined(CONFIG_EOSM2)
    // change end limit to 0xc2a000 => reserve 512K for ML
    *addr_AllocMem_end = MOV_R1_0xC2A000_INSTR;
    ml_reserved_mem = 512 * 1024;   

Next I added MOV_R1_0xC2A000_INSTR for the start address of the EOSM2:

arm-mcr.h
Code: [Select]
#define MOV_R0_0_INSTR 0xe3a00000
#define MOV_R1_0xC2A000_INSTR 0xe3a0???? // mov r1, 0xc2a000

I'm kind of stuck figuring out what to plug in and if there is anything else that needs to be changed. For example RESTARTSTART is set to 0x100E00 so I'm getting this:

Code: [Select]
Now jump to AUTOEXEC.BIN!!
0010E5F4: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
0010E5F4: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D
[BOOT] changing init_task from 0xff0c57a0 (-15968352) to 0x1015f8 (1054200)
[BOOT] autoexec.bin loaded at 100E00 - 181840.

I'm also getting these message that makes me think this isn't working:

Code: [Select]
ff0c8314: !!!! can not fixup jump from 0016dc9c to fd77ab1c (offset -00a7cc62)
...
ff0c8948: !!!! can not fixup jump from 0016e2d0 to fd77b150 (offset -00a7cc62)

Finally, seeing how the 500D work, it ends up like this:

Code: [Select]
Fixups=cd4730 entry=cd4740 free_space=10
[BOOT] changing sys_mem_end:
0x00cd4760:  e3a0160d      mov r1, #13631488 ; 0xd00000
0x00cd4760:  e3a018c6      mov r1, #12976128 ; 0xc60000
K270 READY
[      init:ff1d3b58 ] create_semaphore('EventProcedure', 1)
Temporary breakpoint 15 at 0xff1d3b5c

While the EOSM2 winds up like this:

Code: [Select]
Fixups=171390 entry=17135c free_space=ffffffcc
Title: Re: ML on EOS-M2
Post by: a1ex on July 23, 2017, 08:36:46 AM
In order to follow along on my disassembly I'm doing this:

Code: [Select]
0x7ABC + RAM_OFFSET

That's exactly the reason I've listed the RAM stubs in the ROM_ADDR - RAM_OFFSET format in stubs.S - so one can just copy the ROM address and look it up in a ROM disassembly, without requiring the RAM segments to be set up. I should probably include the RAM address in comments as well - a job for the stubs formatting scripts.

Quote
Ok--this works but how did you know to give r0 = 4 and r1 = 8?

Just picked two RAM addresses that I thought they won't be used in this routine. Since in some cases, null pointers are used for optional output arguments, I've chosen non-zero pointers. Addresses 4 and 8 are actually exception vectors (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0211h/Babfeega.html) - Undefined instruction and Software interrupt. Our routine is not going to trigger these, and they are easy to type.

x/2 4 means 2 items from address 4, and by default, an item is a 32-bit integer. Therefore, it's printing the memory contents at 4 and 8 (our pointers).

Alternatives:
- allocate on the stack (below $sp) - probably the safest option if you debug a real target
- use some high address that's unlikely to be used (anything above 0x10000000 on a 256M camera will do, since QEMU uses 512M for all models, to keep it simple)
- find some other address unlikely to be used (e.g. in the middle of some RAM string, or some other statically allocated variable)
- pick something random and repeat until it succeeds (emulation only!)

Quote
Code: [Select]
#define MOV_R1_0xC2A000_INSTR 0xe3a0???? // mov r1, 0xc2a000

You don't need to hardcode a MOV here - it uses PC-relative addressing. Look at ff0c3204.

Will take a closer look later, also for 100D, since now I have the tools to do so :D
Title: Re: ML on EOS-M2
Post by: dfort on July 23, 2017, 01:36:10 PM
You don't need to hardcode a MOV here - it uses PC-relative addressing. Look at ff0c3204.

That's why my patching isn't working? It always comes up like this:

Code: [Select]
File size : 0x67D40
Now jump to AUTOEXEC.BIN!!
0010E5F4: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
0010E5F4: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D
[BOOT] changing init_task from 0xff0c57a0 (-15968352) to 0x1015e0 (1054176)
[BOOT] autoexec.bin loaded at 100E00 - 181840.
Fixing from ff0c57a0 to ff0cb994

Those [BOOT] messages are handy but only available in the QEMU branch. If merging QEMU into unified (https://bitbucket.org/hudson/magic-lantern/pull-requests/818/qemu-full-firmware-emulation/diff) doesn't break anything it would be lovely. :D

In any case, it seems to be doing the right thing.

This is still a problem--noticed I didn't give enough information in my previous post:

Code: [Select]
ff0c8314: 3b9aca00 BL ff9aca00 => fd77ab1c
ff0c8314: !!!! can not fixup jump from 0016dc9c to fd77ab1c (offset -00a7cc62)
...
ff0c8948: 3b9aca00 BL ff9aca00 => fd77b150
ff0c8948: !!!! can not fixup jump from 0016e2d0 to fd77b150 (offset -00a7cc62)

Another problem is that we're not getting to this (using the 550D example):

Code: [Select]
[BOOT] changing sys_mem_end:
Title: Re: ML on EOS-M2
Post by: dfort on July 24, 2017, 01:35:51 AM
Thought I'd take a detour and attempt to get AllocateMemory pool working on the 700D. Although I really wanted to do this on the EOSM to see if it would take care of the shutter-bug, the 700D plays better in QEMU and it should be easy to port any changes from the 700D to the EOSM.

Ok--just for the record, this is needed or AllocateMemory pool won't compile. This applies to both the EOSM2 and 700D as well as the 550D and 1100D. In other words, all cameras using AllocateMemory pool:

magic-lantern/platform/700D.114/Makefile.setup.default
Code: [Select]
#Makefile for 700D

CONFIG_LVAPP_HACK_RELOC = y

Here is what I found using the EOSM2 as an example:

magic-lantern/platform/700D.114/consts.h
Code: [Select]
// Used in boot-hack.c with CONFIG_ALLOCATE_MEMORY_POOL
#define ROM_ITASK_START 0xff0c5408
#define ROM_ITASK_END  0xff0ca68c
#define ROM_CREATETASK_MAIN_START 0xff0c3000
#define ROM_CREATETASK_MAIN_END 0xff0c339c
#define ROM_ALLOCMEM_END 0xff0c304c
#define ROM_ALLOCMEM_INIT 0x6fc4
#define ROM_B_CREATETASK_MAIN 0xff0c547c

And of course:

magic-lantern/platform/700D.114/internals.h
Code: [Select]
/** This camera loads ML into the AllocateMemory pool **/
#define CONFIG_ALLOCATE_MEMORY_POOL

Taking into account the different addresses between the 700D and EOSM2, the results were pretty much identical.

Code: [Select]
File size : 0x701C0
Now jump to AUTOEXEC.BIN!!
0010E920: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
0010E920: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D
[BOOT] changing init_task from 0xff0c5408 (-15969272) to 0x7f3e8 (521192)
[BOOT] autoexec.bin loaded at 7EC00 - 106940.
Fixing from ff0c5408 to ff0ca68c

Code: [Select]
ff0c85cc: 3b9aca00 BL ff9aca00 => fd77add4
ff0c85cc: !!!! can not fixup jump from 000f3dec to fd77add4 (offset -00a5e408)
...
ff0c8c00: 3b9aca00 BL ff9aca00 => fd77b408
ff0c8c00: !!!! can not fixup jump from 000f4420 to fd77b408 (offset -00a5e408)
Title: Re: ML on EOS-M2
Post by: a1ex on July 24, 2017, 03:03:36 PM
as discussed here (https://bitbucket.org/hudson/magic-lantern/pull-requests/672/dryos-task-hooks-for-newer-cameras-6d-70d/diff) I failed to use AllocateMemory pool but:

I'm ready If you want to give it another go.

Got it working in QEMU, on both 6D (https://bitbucket.org/hudson/magic-lantern/commits/261ca8ad47130b3666904e98931cbcfd158e3492) and 100D (https://bitbucket.org/hudson/magic-lantern/commits/858a20c1ff1fa8851b26e1e91963989bab0d62a6) (they are very similar, and 700D is from the same group). EOSM2 is just a tiny bit different.

You'll probably need new-dryos-task-hooks for EOSM2 as well. Hopefully this time I'll get the confirmation from 6D and 70D in order to merge it in mainline :D
Title: Re: ML on EOS-M2
Post by: Audionut on July 24, 2017, 03:23:32 PM
Hopefully this time I'll get the confirmation from 6D

Need to get a compiler up and running again, then I can test.
Title: Re: ML on EOS-M2
Post by: dfort on July 24, 2017, 06:16:03 PM
Great news. I got the the latest 100D with AllocateMemory pool working in QEMU before running off to work this morning. Looking forward to figuring out how to apply this to the EOSM2 (and 700D and EOSM).

@Audionut -- I recently updated the Macintosh (http://www.magiclantern.fm/forum/index.php?topic=16012.0) and Windows (Cygwin) (http://www.magiclantern.fm/forum/index.php?topic=15894.0) tutorials so you should be able to get a development environment up and running in a matter of minutes. Of course if you are on Linux you probably already have all you need.
Title: Re: ML on EOS-M2
Post by: dfort on July 25, 2017, 09:50:41 PM
Still on a detour working with the 700D but got full ML Hello World working with AllocateMemory pool.

(https://farm5.staticflickr.com/4297/36122575666_9fedfc1c6f.jpg)
Title: Re: ML on EOS-M2
Post by: dfort on July 25, 2017, 11:18:18 PM
Still on detour -- this time with the original EOSM running on a real camera. (Not easy doing a Screenshot of that Free Memory screen on the EOSM.)

AllocateMemory pool
(https://farm5.staticflickr.com/4310/35773230390_a592a87813.jpg)

Nightly.2017Jul16.EOSM202 from downloads page (jenkins build)
(https://farm5.staticflickr.com/4323/35358219053_bc9466bcff.jpg)

And the shutter-bug is still present--ugh!

Ok--back to the EOSM2 after taking a break.
Title: Re: ML on EOS-M2
Post by: dfort on July 26, 2017, 08:06:09 AM
AllocateMemory pool seems to be working on the EOSM2

Code: [Select]
File size : 0x67D40
Now jump to AUTOEXEC.BIN!!
0010E5F4: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005107D
0010E5F4: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D
[BOOT] changing init_task from 0xff0c57a0 (-15968352) to 0x44c984 (4508036)
[BOOT] autoexec.bin loaded at 44C100 - 4C6940.
Fixing from ff0c57a0 to ff0c5978
...
Fixups=4b6638 entry=4b6640 free_space=8
[BOOT] changing AllocMem limits:
0x004b6680:  e59f1158      ldr r1, [pc, #344] ; 0x4b67e0
0x004b6684:  e59f0158      ldr r0, [pc, #344] ; 0x4b67e4
0x004b6680:  e59f1158      ldr r1, [pc, #344] ; 0x4b67e0
0x004b6684:  e3a0084e      mov r0, #5111808 ; 0x4e0000
: %x
 READY
128K Sector FROM From BL 0xffff

Things seem to go fine and the Canon menu pops up, it pauses for a while then:

Code: [Select]
[      init:0044cb84 ] task_create(ml_init, prio=1e, stack=4000, entry=44c528, arg=0)
[     ml_init:ff696760 ] (23:01) sdReadBlk: st=256, num=32, buf=0x4035e000
[     ml_init:ff6951bc ] (23:01) sdDMAReadBlk: st=256, num=32
qemu: fatal: Trying to execute code outside RAM or ROM at 0x20000000

R00=ffffffff R01=009fbc5a R02=001f3912 R03=00000000
R04=19980030 R05=00000000 R06=597375e6 R07=19980218
R08=1998002e R09=19980218 R10=19980218 R11=19980218
R12=0000000f R13=001f3918 R14=0044d1d0 R15=20000000
PSR=60000013 -ZC- A svc32
FPSCR: 00000000
qemu: fatal: Trying to execute code outside RAM or ROM at 0x20000000

Hum, where have I seen that before? Oh yeah, when I tried it with HIJACK_CACHE_HACK. The error is nearly identical:

Then it gets ugly:

Code: [Select]
[      init:0010137c ] task_create(ml_init, prio=1e, stack=4000, entry=101510, arg=0)
[     ml_init:ff696760 ] (23:01) sdReadBlk: st=73344, num=32, buf=0x4035e000
[     ml_init:ff6951bc ] (23:01) sdDMAReadBlk: st=73344, num=32
qemu: fatal: Trying to execute code outside RAM or ROM at 0x20000000

R00=ffffffff R01=00987c0a R02=001f3912 R03=00000000
R04=19980030 R05=00000000 R06=596f0ae0 R07=19980218
R08=1998002e R09=19980218 R10=19980218 R11=19980218
R12=00000007 R13=001f3918 R14=00101cc0 R15=20000000
PSR=60000013 -ZC- A svc32
FPSCR: 00000000
qemu: fatal: Trying to execute code outside RAM or ROM at 0x20000000

On the 700D it prints "Hello World" and the firmware signature. That same bit of code that's tripping up the EOSM2 looks like this on the 700D:

Code: [Select]
[     ml_init:ff74c988 ] (23:01) sdReadBlk: st=256, num=32, buf=0x402fe000
[     ml_init:ff74b3e4 ] (23:01) sdDMAReadBlk: st=256, num=32
[     ml_init:ff74c988 ] (23:01) sdReadBlk: st=320, num=32, buf=0x40306000
[     ml_init:ff74b3e4 ] (23:01) sdDMAReadBlk: st=320, num=32
...

From the looks of that message it seems like it is having a problem reading the SD card image file. The 700D saves a ROM dump but the EOSM doesn't so maybe it is a write issue? The address of that "ml_init" points to something named "sdWriteBlk: Emergency Stop3" in the firmware. Stumped again--still no "Hello World" with the full ML and of course no firmware signature yet.

These messages might be a clue:

Code: [Select]
[   CSMgrTask:ff6978ec ] (23:03) ---- SDEventHandler(ID=1:Event=8) ----
    64:   129.536 [MR] mvrChangeAckCBR : Video - Mode=0, Type=2, Rate=30, GOP=15
    82:    71.936 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050038
    83:    71.936 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050041
    84:    71.936 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050042
    85:    71.936 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050043
    86:    71.936 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050044
    87:    71.936 [PROPAD] ERROR GetPropertyData ID (1) = 0x0105004F
    88:    71.936 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050050
    89:    71.936 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050051
    90:    72.192 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050052
    91:    72.192 [PROPAD] ERROR GetPropertyData ID (1) = 0x0105010E
    92:    72.192 [PROPAD] ERROR GetPropertyData ID (1) = 0x0105010F
    93:    72.192 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050110
    94:    72.192 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050111
    95:    72.192 [PROPAD] ERROR GetPropertyData ID (1) = 0x0104000B
    96:    72.192 [LVCOM] InitializeLiveViewDefectDetection
    97:    72.192 [LVCOM] ExecuteDefectMarge Start
    98:    72.448 [LVCOM] ExecuteDefectMarge End
   100:    76.800 [LV]  PROP_LV_BLOCK  PROP_LV_UNBLOCKING 0
   102:    78.336 [AUDIO] RegisterCBRSDIOCableConnect
   103:    85.248 [WFT] InitializeAdapterControl END

That [WTF] seems like a good way to end this post.
Title: Re: ML on EOS-M2
Post by: dfort on July 27, 2017, 05:12:14 PM
Found something that may or may not shed light into what is causing the EOSM2 to crash when running the full ML "Hello, World!" I was able to reproduce the crash outside of ML:

Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -d debugmsg -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb

...
[  DisplayMgr:ff1790cc ] (9a:02) fTunOnDisp = On
^C
Program received signal SIGINT, Interrupt.
0xff352318 in ?? ()
(gdb) set $pc=0xff697870
(gdb) c
Continuing.
qemu: fatal: Trying to execute code outside RAM or ROM at 0x20000000

R00=c0400000 R01=00000080 R02=19980218 R03=19980218
R04=0000021c R05=0017ee2c R06=19980218 R07=19980218
R08=19980218 R09=19980218 R10=19980218 R11=19980218
R12=19980218 R13=0018b330 R14=ff352220 R15=20000000
PSR=600000d3 -ZC- A svc32
FPSCR: 00000000
qemu: fatal: Trying to execute code outside RAM or ROM at 0x20000000

That is pretty much the error I've been getting when trying to run ML on the EOSM2 (in QEMU of course) and shows up outside of ML when calling a function that has this bit of interesting information in it:

Code: [Select]
ff6978dc: e28f2f6e add r2, pc, #440 ; ff697a9c: (2d2d2d2d)  *"---- SDEventHandler(ID=%d:Event=%d) ----"

So what is the state of SDEventHandler at this point?

Code: [Select]
(gdb) set $pc = 0xff6978ac
(gdb) c
Continuing.
[    PowerMgr:ff51d13c ] (1e:01) MapLogToPhysic: pLStorage=0x19980218
[    PowerMgr:ff51d184 ] (1e:06) MapLogToPhysic: Logical Storage Not Found(BAD_LOGICAL_STORAGE)
   185:  1118.720 [CSMGR] ERROR MapLogToPhysic: Logical Storage Not Found(BAD_LOGICAL_STORAGE
[    PowerMgr:ff6978ec ] (23:03) ---- SDEventHandler(ID=429392408:Event=128) ----
[    PowerMgr:ff697dfc ] (23:06) Invalid Event(Event=128)
   186:  1118.976 [SD] ERROR Invalid Event(Event=128)

Switching over to the 700D and calling these same functions created the same messages. So what is the point? Somehow when running ML the EOSM2 is tripping up on this while the 700D sails right through it and displays "Hello, World!" along with the firmware signature. I've been double checking suspect stubs and constants and as far as I can tell they are correct. At least when checking against similar cameras like the EOSM, 100D and 700D.

So what is going on? I don't know, I haven't been successful setting breakpoints and stepping through the code. Looks like I need to do a remedial class in GDB source code debugging.

Oh no--the dog ate my homework!

(https://farm5.staticflickr.com/4329/36034379792_486de879fc_n.jpg)

...the graphs on the placing ML into shoot memory (http://www.magiclantern.fm/forum/index.php?topic=5071.0) topic have disappeared when using the Chrome browser. Looking into the issue it seems that Google has been implementing stricter rules that is affecting the link...
Title: Re: ML on EOS-M2
Post by: nikfreak on July 27, 2017, 07:15:54 PM
a1ex always told me to use the blink code (led blinking) whenever I got stuck while porting to 70D/100D.
That way it was rather easy to determine at which part of the code we got stuck. Mostly the symptom for becoming stuck was a continuous LED light and not a blinking one.
In your case I would start here in boot-hack.c:

Code: [Select]
/* This runs ML initialization routines and starts user tasks.
 * Unlike init_task, from here we can do file I/O and others.
 */
static void my_big_init_task()
{
    _find_ml_card();
    _load_fonts();

and place some strings/printf's/debugmsg (OK1/2/3...) before or in between to see if you reach that part of the code in qemu. Afterwards continue or revert until you reach a code part where you don't get stuck. As last time I used QEMU with ML is years ago i can't tell you really what code exactly to use for the blinking LED alternative. You need something you will see in qemu console...
Title: Re: ML on EOS-M2
Post by: dfort on July 27, 2017, 09:43:19 PM
Hi @nicfreak

That gave me an idea:

Code: [Select]
static void my_big_init_task()
{
//    _find_ml_card();
    _load_fonts();

#ifdef CONFIG_HELLO_WORLD
    hello_world();

Skip the card for now and just print "Hello, World!" and the firmware signature.

(https://farm5.staticflickr.com/4313/35813325560_0cc45d71b3.jpg)

Well at least it doesn't crash out of QEMU and the LED is blinking. The font addresses check out so it is something else. Oh, and I navigated out of the Canon menu just to get a clean screenshot. The Canon menus continue to work but it looks even worse with them on.
Title: Re: ML on EOS-M2
Post by: nikfreak on July 27, 2017, 10:13:40 PM
sounds like you need to triple-check the FIO stubs cause _find_ml_card() is part of fio-ml and most of the code is FIO related.
Title: Re: ML on EOS-M2
Post by: dfort on July 28, 2017, 01:24:10 AM
Yep, you nailed it. A couple of my FIO stubs were off.

Code: [Select]

 /** File I/O **/
 NSTUB(0xFF357704,  FIO_CloseFile)
-NSTUB(0xFF3576FC,  FIO_FindClose)
+NSTUB(0xFF3586FC,  FIO_FindClose)
 NSTUB(0xFF35861C,  FIO_FindNextEx)
 NSTUB(0xFF3574B4, _FIO_ReadFile)
-NSTUB(0xFF357704,  FIO_SeekSkipFile)
+NSTUB(0xff357564,  FIO_SeekSkipFile)
 NSTUB(0xFF357654, _FIO_WriteFile)
 NSTUB(0xFF357F60, _FIO_CreateDirectory)
 NSTUB(0xFF357360, _FIO_CreateFile)

Finally!

(https://farm5.staticflickr.com/4314/35816268030_d34eeb9957.jpg)

Moving beyond "Hello, World!" it saves ROM0.BIN and ROM1.BIN and prints error messages and saves ASSERT00.LOG and... Looks like there's more work to do.

So here is where we're at now:

Code: [Select]
Error loading 'ML/MODULES/EOSM2_103.sym': File does not exist
...
ML ASSERT:
streq(stateobj->type, "StateObject")
at ../../src/state-object.c:251 (stateobj_start_spy), task ml_init
lv:0 mode:3

But wait, it is there! Right at the top of the list:

Code: [Select]
ls -la /Volumes/EOS_DIGITAL/ML/modules/
total 1824
drwxrwxrwx  1 rosiefort  staff   16384 Jul 27 16:07 .
drwxrwxrwx  1 rosiefort  staff   16384 Jul 27 16:06 ..
-rwxrwxrwx  1 rosiefort  staff   36278 Jul 27 16:06 EOSM2_103.sym
-rwxrwxrwx  1 rosiefort  staff      96 Dec 31  1999 LOADING.LCK
-rwxrwxrwx  1 rosiefort  staff   21876 Jul 27 16:07 adv_int.mo
-rwxrwxrwx  1 rosiefort  staff   13200 Jul 27 16:07 arkanoid.mo
-rwxrwxrwx  1 rosiefort  staff   18804 Jul 27 16:07 autoexpo.mo
-rwxrwxrwx  1 rosiefort  staff   18128 Jul 27 16:07 bench.mo
-rwxrwxrwx  1 rosiefort  staff    8536 Jul 27 16:07 deflick.mo
-rwxrwxrwx  1 rosiefort  staff   15916 Jul 27 16:07 dual_iso.mo
-rwxrwxrwx  1 rosiefort  staff   32372 Jul 27 16:07 ettr.mo
-rwxrwxrwx  1 rosiefort  staff   15668 Jul 27 16:07 file_man.mo
-rwxrwxrwx  1 rosiefort  staff  305600 Jul 27 16:07 lua.mo
-rwxrwxrwx  1 rosiefort  staff   41680 Jul 27 16:07 mlv_lite.mo
-rwxrwxrwx  1 rosiefort  staff   45272 Jul 27 16:07 mlv_play.mo
-rwxrwxrwx  1 rosiefort  staff   64384 Jul 27 16:07 mlv_rec.mo
-rwxrwxrwx  1 rosiefort  staff   11248 Jul 27 16:07 mlv_snd.mo
-rwxrwxrwx  1 rosiefort  staff    6916 Jul 27 16:07 pic_view.mo
-rwxrwxrwx  1 rosiefort  staff   83852 Jul 27 16:07 selftest.mo
-rwxrwxrwx  1 rosiefort  staff   21952 Jul 27 16:07 silent.mo

I believe that LOADING.LCK file is because I don't know how to exit from QEMU cleanly. Either that or my system is on Throwback Thursday.
Title: Re: ML on EOS-M2
Post by: a1ex on July 28, 2017, 03:01:43 PM
Error loading 'ML/MODULES/EOSM2_103.sym': File does not exist

But wait, it is there!

Long (https://en.wikipedia.org/wiki/File_Allocation_Table#Patents) Live (https://www.google.com/patents/US5758352?dq=5,758,352) Microsoft (http://www.microchip.com/forums/m474654.aspx) :)

This feature is only available in older models (5D2 generation).

Quote
I believe that LOADING.LCK file is because I don't know how to exit from QEMU cleanly.

Right. There is an attempt to emulate a shutdown (press B to simulate opening the battery door), but it's incomplete.
Title: Re: ML on EOS-M2
Post by: dfort on July 28, 2017, 06:26:31 PM
EOSM2103.FIR - Looks like Canon is taking all they can get out of an 8.3 filename.

Following what was done on the 1100D:

Code: [Select]
# Definitions for version 103
ML_MODULES_SYM_NAME=m2_$(FW_VERSION).sym

Got past that. Now on to the next issue:

ASSERT00.LOG
Code: [Select]
ML ASSERT:
streq(stateobj->type, "StateObject")
at ../../src/state-object.c:251 (stateobj_start_spy), task ml_init
lv:0 mode:3

ml_init stack: 1f3978 [1f39c8-1ef9c8]
0xUNKNOWN  @ 44c8dc:1f39b0
0x0044CA04 @ 477e28:1f39a8
0x0044C468 @ 44ca64:1f3978

Magic Lantern version : Nightly.2017Jul28.EOSM2103
Mercurial changeset   : 69d91c7c4317 (qemu-wip) tip
Built on 2017-07-28 15:40:15 UTC by [email protected]
Free Memory  : 344K + 1158K

Is this typical of a new port or is the EOSM2 an especially stubborn little bastard?

BTW--I keep the EOSM2 branch updated with the latest changes that work in QEMU: https://bitbucket.org/daniel_fort/magic-lantern/branch/EOSM2.103_wip
Title: Re: ML on EOS-M2
Post by: dfort on July 29, 2017, 01:14:19 AM
Found another stub that was off, _engio_write, though this time it didn't resolve the current issue.

Code: [Select]
/**
 * State object hooks are pieces of code that run in Canon tasks (state objects). See state-object.c .
 * They might slow down Canon code, so here you can disable all of them (useful for debugging or early ports)
 */
#define CONFIG_STATE_OBJECT_HOOKS

Tried disabling CONFIG_STATE_OBJECT_HOOKS but it won't compile and it was a bit too complicated for me trying to find all the pieces needed to get it to build.

I did track down this QEMU message:

Code: [Select]
[   menu_task:0044db24 ] (32:03) read_entire_file:736: failed

to this:

fio.ml.c
Code: [Select]
uint8_t* read_entire_file(const char * filename, int* buf_size)
...
getfilesize_fail:
    DEBUG("failed");
    return NULL;

All of this is happening in task ml_init so I take it that we still have a long journey into the UNKNOWN ahead.

Code: [Select]
ml_init stack: 1f3978 [1f39c8-1ef9c8]
0xUNKNOWN  @ 44c8dc:1f39b0
0x0044CA04 @ 477e28:1f39a8
0x0044C468 @ 44ca64:1f3978

Any hints on how to track this down? Maybe where to put in a break point?
Title: Re: ML on EOS-M2
Post by: a1ex on July 29, 2017, 09:30:22 AM
http://www.magiclantern.fm/forum/index.php?topic=19933 -> commands to translate the numbers from the stack trace into source code lines. These addresses are from ML code; if I compile my own from the same source, I would probably get different results, unless I'd have the same compiler version and the same modifications to the source code, if any. Still, let me try it:

Code: [Select]
hg clone https://bitbucket.org/daniel_fort/magic-lantern/
cd magic-lantern
hg up 69d91c7c4317 -C  # changeset from the stack trace log

# all options and source code modifications are visible in autoexec.bin, but as I don't have it, I'm just guessing
echo "CONFIG_QEMU=y" > Makefile.user
sed -i 's!#define CONFIG_HELLO_WORLD!//#define CONFIG_HELLO_WORLD!' src/config-defines.h

cd platform/EOSM2.103
make clean; make

eu-addr2line -s -S --pretty-print -e magiclantern 0x44c8dc 0x477e28 0x44ca64
my_big_init_task+0x58 at boot-hack.c:307
stateobj_start_spy.constprop.0+0x2c at state-object.c:251
ml_assert_handler+0x60 at boot-hack.c:539

eu-addr2line -s -S --pretty-print -e magiclantern 0x0044CA04 0x0044C468
ml_assert_handler at boot-hack.c:530
backtrace_getstr at backtrace.c:877

Looks OK!

The stack trace with -d callstack is more complete (it finds the 0xUNKNOWNs and also contains function arguments); you can get it with a breakpoint on ml_assert_handler and calling print_current_location_with_callstack from there.

Even better - we are debugging code code compiled by us, which - on the qemu branch - also has debug info for gdb, in the same way as a regular PC program has debug info (https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html). This info is not copied to the card - it's kept in the "magiclantern" file, which is actually an elf. With this info, gdb can print a backtrace as well, and it's probably better than ours, as long as the error is in our code. There's no debug info on Canon firmware, other than their (very helpful) debug messages.

Code: [Select]
. ./export_ml_syms.sh EOSM2.103
./run_canon_fw.sh EOSM2,firmware="boot=1" -d debugmsg,callstack -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
...
CTRL-C before the error
(gdb) symbol-file ../magic-lantern/platform/EOSM2.103/magiclantern
(gdb) b ml_assert_handler
(gdb) continue
...
Breakpoint 4, ml_assert_handler (...)

(gdb) bt
#0  ml_assert_handler ([email protected]=0x4a5ad8 "streq(stateobj->type, \"StateObject\")", [email protected]=0x4a5afd "../../src/state-object.c", [email protected]=0xfb, [email protected]=0x49ca48 <__func__.7031> "stateobj_start_spy") at ../../src/boot-hack.c:530
#1  0x00477e2c in stateobj_start_spy (stateobj=0xe51f3e14, spy=0x477cd0 <stateobj_lv_spy>) at ../../src/state-object.c:251
#2  0x0044c8e0 in call_init_funcs () at ../../src/boot-hack.c:307
#3  my_big_init_task () at ../../src/boot-hack.c:448
#4  0x0000ca18 in ?? ()

(gdb) print_current_location_with_callstack
Current stack: [1f39c8-1ef9c8] sp=1f39a8                                         at [ml_init:44ca04:477e2c] (ml_assert_handler)
0x44C884 my_big_init_task(0, 44c884 my_big_init_task, 19980218, 19980218)        at [ml_init:ca14:1f39c0] (pc:sp)
 0x477E80 state_init(32, 3, 49d60d "Calling init_func %s (%x)", 477e80 state_init)
                                                                                 at [ml_init:44c8dc:1f39b0] (my_big_init_task) (pc:sp)
  0x44CA04 ml_assert_handler(4a5ad8 "streq(stateobj->type, "StateObject")", 4a5afd "../../src/state-object.c", fb, 49ca48 "stateobj_start_spy")
                                                                                 at [ml_init:477e28:1f39a8] (stateobj_start_spy.constprop.0) (pc:sp)

With debug info available, gdb gives a pretty good backtrace. We don't have this luxury when debugging Canon code though, and that's the reason I wrote the callstack analysis. The callstack trace does not require any debug info, but requires the code to be instrumented (therefore it's slower than normal execution). The backtrace from the assert log does not require instrumentation, but also gives a lot less info.

With my WIP version of QEMU (option to identify tail function calls), the stack trace would be:
Code: [Select]
[...] -d debugmsg,callstack,tail [...]
[...]
(gdb) print_current_location_with_callstack
Current stack: [1f39c8-1ef9c8] sp=1f39a8                                         at [ml_init:44ca04:477e2c] (ml_assert_handler)
0x44C884 my_big_init_task(0, 44c884 my_big_init_task, 19980218, 19980218)        at [ml_init:ca14:1f39c0] (pc:sp)
 0x477E80 state_init(32, 3, 49d60d "Calling init_func %s (%x)", 477e80 state_init)
                                                                                 at [ml_init:44c8dc:1f39b0] (my_big_init_task) (pc:sp)
  0x477DFC stateobj_start_spy.constprop.0(e51f3e14, 4bd9a4, 0, 477e80 state_init)
                                                                                 at [ml_init:477e9c:1f39b0] (state_init) (pc:sp)
   0x44CA04 ml_assert_handler(4a5ad8 "streq(stateobj->type, "StateObject")", 4a5afd "../../src/state-object.c", fb, 49ca48 "stateobj_start_spy")
                                                                                 at [ml_init:477e28:1f39a8] (stateobj_start_spy.constprop.0) (pc:sp)

Note: call_init_funcs() is not listed in my stack trace because the compiler inlined it. Still, gdb did a very good job identifying it. In my trace, it only says state_init was called from 44c8dc which maps to boot-hack.c:307.

Why did my stack trace list 0x4bd9a4 as the second argument of stateobj_start_spy?! In gdb's backtrace, it's 0x477cd0 (which is correct).

Answer: the compiler hardcoded this one, so the compiled function (in assembly) only receives one argument:
Code: [Select]
(gdb) disas state_init
   0x00477e80 <+0>: push {r3, lr}
   0x00477e84 <+4>: mov r3, #589824 ; 0x90000
   0x00477e88 <+8>: ldr r0, [r3, #1456] ; 0x5b0
   0x00477e8c <+12>: bl 0x477dfc <stateobj_start_spy>
   0x00477e90 <+16>: mov r3, #262144 ; 0x40000
   0x00477e94 <+20>: ldr r0, [r3, #1252] ; 0x4e4
   0x00477e98 <+24>: pop {r3, lr}
   0x00477e9c <+28>: b 0x477dfc <stateobj_start_spy>

(gdb) disas disas stateobj_start_spy
...
   0x00477e58 <+92>: ldr r3, [pc, #28] ; 0x477e7c <stateobj_start_spy+128>
   0x00477e5c <+96>: str r3, [r4, #12]
   0x00477e60 <+100>: mov r0, #0
   0x00477e64 <+104>: pop {r4, pc}

(gdb) x 0x477e7c
0x477e7c <stateobj_start_spy+128>: 0x00477cd0

Anyway. The error from state objects appears to be a check that's working very well :D (which means, the state object definitions on working ports can be trusted to be correct).

The error from read_entire_file is unrelated. Exercise: find out where it comes from (using the same technique).
Title: Re: ML on EOS-M2
Post by: DeafEyeJedi on July 29, 2017, 11:40:03 PM
This is all very exciting progress so far and keep them rolling along!
Title: Re: ML on EOS-M2
Post by: JohanJ on July 30, 2017, 06:21:29 PM
This is all very exciting progress so far and keep them rolling along!
+1

Sent from my SM-G930F using Tapatalk

Title: Re: ML on EOS-M2
Post by: dfort on July 30, 2017, 07:53:44 PM
And the crowd goes wild!

@DeafEyeJedi - Thanks again for letting me borrow your 100D, I'm getting a lot of mileage out of the firmware dump.

The error from read_entire_file is unrelated. Exercise: find out where it comes from (using the same technique).

That was a bit of a wild goose chase. I'll spare you all the nitty-gritty details but basically:

Code: [Select]
#0  read_entire_file ([email protected]=0x49f806 "ML/SETTINGS/CURRENT.SET", [email protected]=0x1f38f4) at ../../src/fio-ml.c:707
#1  0x0045e704 in config_choose_startup_preset () at ../../src/config.c:771
#2  config_load () at ../../src/config.c:903
#3  0x0044c910 in my_big_init_task () at ../../src/boot-hack.c:458
#4  0x0000ca18 in ?? ()
...
#0  read_entire_file ([email protected]=0x1f38f8 "ML/SETTINGS/magic.cfg", [email protected]=0x4ba78c <config_file_size>) at ../../src/fio-ml.c:707
#1  0x0045e2cc in config_parse_file (filename=0x1f38f8 "ML/SETTINGS/magic.cfg", [email protected]=0x1f38f0 "\023") at ../../src/config.c:316
#2  0x0045ea1c in config_load () at ../../src/config.c:913
#3  0x0044c910 in my_big_init_task () at ../../src/boot-hack.c:458
#4  0x0000ca18 in ?? ()
...
#0  read_entire_file (filename=0x18e2a0 "ML/SETTINGS/MENU.CFG", [email protected]=0x18e298 "\030\002\230\031", buf_size=0x18e29c, [email protected]=0x18e294) at ../../src/fio-ml.c:707
#1  0x00454a50 in menu_load_flags (filename=0x18e298 "\030\002\230\031") at ../../src/menu.c:5600
#2  config_menu_load_flags () at ../../src/menu.c:5633
#3  menu_task (unused=<optimized out>) at ../../src/menu.c:4982
#4  0x0000ca18 in ?? ()

So the failed read_entire_file message is because it is loading the configuration files but since this is a first run there are no saved settings yet. What would a camera that is known to work do in this case? How about the 700D?

Code: [Select]
[     ml_init:0044db24 ] (32:03) read_entire_file:736: failed
[     ml_init:0045e344 ] (32:03) config_parse: Read 0 config values

So like the state objects message, read_entire_file seems to be working fine. However, the 700D running in QEMU displays an endless loop, apparently waiting for user input:

Code: [Select]
[****] task_hook(141b34) 13fb60() -> 13fb60(), from 141b34
[****] task_hook(13fb60) 0(????????) -> 141b34(T ??), from 13fb60
[****] task_hook(141b34) 13fb60() -> 13fb60(), from 141b34
[****] task_hook(141990) 0(????????) -> 141b34(T ??), from 141990
[****] task_hook(13fb60) 0(????????) -> 141990(), from 13fb60

While the EOSM2 stops displaying messages. So the problem seems to be getting to the next task.

I tried that eu-addr2line trick but ran into a problem, it isn't available on the Mac and I was having trouble compiling elfutils from source. However, I did have gaddr2line from Homebrew and it supports ARM code. It is somewhat different from eu-addr2line but seems to work:

Code: [Select]
gaddr2line -sf --pretty-print -b elf32-littlearm -e magiclantern 0x44c8dc 0x477e28 0x44ca64
call_init_funcs at boot-hack.c:307
stateobj_start_spy at state-object.c:251
ml_assert_handler at boot-hack.c:539

gaddr2line -sf --pretty-print -b elf32-littlearm -e magiclantern 0x0044CA04 0x0044C468
ml_assert_handler at boot-hack.c:530
backtrace_getstr at backtrace.c:877

One question -- if the the state objects message is not a problem, why is it printing an error message and saving a crash log?

(https://farm5.staticflickr.com/4317/35875189750_0037717f78.jpg)
Title: Re: ML on EOS-M2
Post by: a1ex on July 30, 2017, 09:19:34 PM
One question -- if the the state objects message is not a problem, why is it printing an error message and saving a crash log?

It shows where the problem is. This is what I meant by "a check that's working very well" - if there's something wrong with the state object definitions, it shows the error, rather than allowing it to go undetected.
Title: Re: ML on EOS-M2
Post by: dfort on July 31, 2017, 08:04:26 AM
Got it, the error check is working properly so that means that I've still got some errors--probably in stubs.S or consts.h? I keep going over them and keep finding issues. Partially because when I went through it the first time I picked whatever camera seemed to be the closest to matching the section of code I was doing my pattern checking on but I've been copying from stubs that are off on other platforms.

Here's one that should be checked out.

700D.114/stubs.S
Code: [Select]
-NSTUB(0xFF702A3C,  PlayMain_handler)
+NSTUB(0xFF3B9E94,  PlayMain_handler)

I'm pretty sure that this is the correct "fix" but how to confirm it?

Haven't found the silver bullet for whatever is haunting the EOSM2.
Title: Re: ML on EOS-M2
Post by: a1ex on July 31, 2017, 11:47:26 AM
There are a few more camera-specific files under the platform directory.

Regarding 700D PlayMain_handler:
Code: [Select]
cd platform/700D.114
hg blame -c stubs.S | grep PlayMain_handler
3c718689749d: NSTUB(0xFF702A3C,  PlayMain_handler)

hg log -r 3c718689749d
changeset:   14427:3c718689749d
branch:      700D
parent:      14406:96ca71e19bf1
user:        [email protected]
date:        Sat Aug 13 09:23:49 2016
summary:     700D: fix PlayMain_handler stub (fixes SET+MainDial and others)

hg export 3c718689749d
...
-NSTUB(0xFF3B9E94,  PlayMain_handler)
+NSTUB(0xFF702A3C,  PlayMain_handler)

;)

Title: Re: ML on EOS-M2
Post by: dfort on August 01, 2017, 08:29:22 AM
Oh yeah and I commented on that 700D fix (https://bitbucket.org/hudson/magic-lantern/pull-requests/750/700d-minor-fixes/diff). Well at least I found the address where it should have worked if the 700D was just a little bit more like the EOSM.

There are a few more camera-specific files under the platform directory.

Yes, but some of that stuff looks really scary and maybe needs the dm-spy-experiments branch running on the camera to ferret them out?

Then there's that directory with yet another platform subdirectory with a couple of files that can't possibly be the one that will solve the state objects issue.  ???

magic-lantern/platform/EOSM.103/include/platform/state-object.h
Code: [Select]
#ifndef __platform_state_object_h
#define __platform_state_object_h

#define DISPLAY_STATE DISPLAY_STATEOBJ
#define INPUT_SET_IMAGE_VRAM_PARAMETER_MUTE_FLIP_CBR 26 // need to verify
#define INPUT_ENABLE_IMAGE_PHYSICAL_SCREEN_PARAMETER 27 // need to verify
#define EVF_STATE    (*(struct state_object **)0x91CF0)
#define MOVREC_STATE (*(struct state_object **)0x93AF8)
#define SSS_STATE    (*(struct state_object **)0x9169C)

#endif // __platform_state_object_h

Ok--that fixed it. So what's next? It seems to be running but I can't get to the Magic Lantern menu to check it out. Guess I should try to figure out how you did it (http://www.magiclantern.fm/forum/index.php?topic=2864.msg187289#msg187289).
Title: Re: ML on EOS-M2
Post by: a1ex on August 01, 2017, 10:19:43 AM
That's probably because the M2 does not show the "idle" Canon screen (the one with shooting settings); as soon as you close the date/time dialog, it will go to LiveView (which doesn't work in QEMU).

You should be able to work around it by allowing the menu to come up in any GUI state, not just when "idle".
Title: Re: ML on EOS-M2
Post by: dfort on August 01, 2017, 07:55:50 PM
You should be able to work around it by allowing the menu to come up in any GUI state, not just when "idle".

I tried commenting out "idle" statements like this one:

menu.c
Code: [Select]
        if (gui_state == GUISTATE_IDLE || (gui_menu_shown() && !beta_should_warn()))
        {
            give_semaphore( gui_sem );
            return 0;
        }

but still no ML menus. I did discover that I missed a setting in menu.c for long press down key (a.k.a. trash button) but that didn't do it either.

What I'm seeing is this screen when it boots up:

(https://farm5.staticflickr.com/4301/36180441021_452550ae36.jpg)

I could change the date but it doesn't save it so I gave up doing that and keep reliving the same day over and over again until I get it right--like on the movie Groundhog Day. As soon as I close the date/time dialog (by pressing the "m" key) it doesn't go to LiveView, it goes to this screen:

(https://farm5.staticflickr.com/4306/35479384954_a567f1c9db.jpg)

Once again I can navigate all over the Canon menus and change settings but they aren't saved. Pressing "m" once more gets into what I take it is LiveView--just a black screen. No need to show a screenshot of that one! The frustrating part is once in LiveView, always in LiveView--there doesn't seem to be any way to get back to the Canon menus while on other cameras pressing the "m" key will get you back.

ML does seem to be running in the background because if I do a second QEMU session without first removing the "LOADING.LCK" file the "Skipping module loading." message shows up even when in LiveView.

(https://farm5.staticflickr.com/4311/36180468141_df3c6b5351.jpg)

One more screenshot, here is what happens when using "CONFIG_QEMU=y" in Makefile.user and not building in the qemu branch.

(https://farm5.staticflickr.com/4296/35479384394_355d5942cd.jpg)

Obviously not useful for the EOSM2 but it is interesting seeing some of the other camera button options.

Ok--I've got to ask. At what point can we run at least the minimal "Hello, World!" on the camera? I've been told that in order to set the boot flag on the camera I need to ask for a "ML-SETUP.FIR" from a developer because that is one thing that a mere minion like me is not allowed to have unless he has proven himself worthy. Am I there yet?

BTW--if I brick the camera it would probably disappoint the two EOSM2 owners who are following this topic more than it does me. At least I could move on to other projects!
Title: Re: ML on EOS-M2
Post by: DeafEyeJedi on August 01, 2017, 08:15:33 PM
Quote
BTW--if I brick the camera it would probably disappoint the two EOSM2 owners who are following this topic more than it does me. At least I could move on to other projects!

Well if that's the case then you are more than welcome to borrow my soon to be arriving M2 body after ordering a decent used one through Amazon recently.  :P
Title: Re: ML on EOS-M2
Post by: dfort on August 01, 2017, 08:24:58 PM
So there's no way to get out of this, come hell or high water!
Title: Re: ML on EOS-M2
Post by: glassescreditsroll on August 02, 2017, 09:49:19 PM


BTW--if I brick the camera it would probably disappoint the two EOSM2 owners who are following this topic more than it does me. At least I could move on to other projects!
I check in every other day I don't known what's going on but I'm eggerly waiting for this to finally work on EOS m2 lol
Title: Re: ML on EOS-M2
Post by: dfort on August 03, 2017, 08:24:50 AM
I'm eggerly waiting

This egg looks like it is about to hatch but not quite yet--that is if it doesn't crack first!

What is going on is that as someone who is a non-developer with very limited coding abilities but with some success (https://bitbucket.org/hudson/magic-lantern/pull-requests/?state=MERGED&author=daniel_fort) tinkering and contributing to the Magic Lantern project, I decided to take on the challenge of porting a camera that should be relatively easy. I keep running into problems and a1ex keeps pointing me in the right direction--though sometimes figuring out his hints is a challenge in itself.

I'm eager to see something working on the camera but a1ex knows better than I that this is a process that shouldn't be rushed and it is better to make sure it runs well on QEMU before trying it on the camera. Basically the only ML program I ran on the EOSM2 so far has been the firmware dumper, everything else has been done on a "virtual" EOSM2 via QEMU running on a MacBook Pro.

I picked the EOSM2 because it is cheap and should be one of the easier cameras to port. This camera also had a limited distribution so there aren't a bunch of users putting pressure on me to hurry up and get it working, though I think we're all eager to see at least "Hello, World!" running on the "real" camera.

The latest problem I solved was that the selftest module wasn't compiling because the AbortEDmac stub was missing. In the process of trying to figure out what was going on I also found several places where I needed to give the EOSM2 the same treatment as the EOSM because these cameras are very closely related.

I'm still trying to figure out how to get the ML menu to show up in QEMU.

That's probably because the M2 does not show the "idle" Canon screen (the one with shooting settings); as soon as you close the date/time dialog, it will go to LiveView (which doesn't work in QEMU).

You should be able to work around it by allowing the menu to come up in any GUI state, not just when "idle".

Can I phone a friend or ask the audience for the answer?
Title: Re: ML on EOS-M2
Post by: dfort on August 05, 2017, 07:24:23 AM
Tried my luck bringing up the ML menus in QEMU on some other cameras with pretty much the same results as the EOSM2--nada, nuthin, zip. Maybe it is a Mac keyboard thing with the delete key not mapping to the camera trash button? It shouldn't matter on the EOSM2 because the trash button is also the down arrow key.

Also found some errors that look like they might be pointing to a problem:

Code: [Select]
    13:    34.304 [SEQ ERROR] NotifyComplete (Cur = 1, 0x2, Flag = 0x20000000)
    14:    38.400 [PROPAD] ERROR GetPropertyData ID (0) = 0x00030048
    15:    38.400 ERROR [RTC] PROPAD_GetPropertyData : PROP_RTC
    16:    42.752 [RTC] ChangePropertyCBR 0x0, 0x0
    17:    43.520 [RTC] RTC_Permit 0x0
...
    83:   253.952 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050038
    84:   254.464 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050041
    85:   254.720 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050042
    86:   254.720 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050043
    87:   254.976 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050044
    88:   255.232 [PROPAD] ERROR GetPropertyData ID (1) = 0x0105004F
    89:   255.232 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050050
    90:   255.488 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050051
    91:   190.208 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050052
    92:   190.720 [PROPAD] ERROR GetPropertyData ID (1) = 0x0105010E
    93:   190.976 [PROPAD] ERROR GetPropertyData ID (1) = 0x0105010F
    94:   190.976 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050110
    95:   190.976 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050111
    96:   191.232 [PROPAD] ERROR GetPropertyData ID (1) = 0x0104000B

The PROPAD_GetPropertyData stub was removed (https://bitbucket.org/hudson/magic-lantern/pull-requests/684/mlv_rec-eliminate-propad_getpropertydata/diff) a while back in part to resolve one of my bug reports (https://bitbucket.org/hudson/magic-lantern/issues/2460/700d-t5i-mlv-idnt-metadata-incorrect). Had no idea what was going on back then and still don't understand it. Seems to be a problem with the Properties stubs but after quadruple checking them they look fine.
Title: Re: ML on EOS-M2
Post by: a1ex on August 05, 2017, 09:38:36 AM
Those errors are likely just imperfect emulation (we are using properties from 100D, not from a real camera).

However, we should be close to getting these things from real hardware. If the dm-spy-experiments branch saves a valid log in QEMU with CONFIG_DEBUG_INTERCEPT_STARTUP=y and CONFIG_QEMU=n, that means we are already there and I'll enable the boot flag.

We'll also need the sf_dump module - that should re-create the SFDATA.BIN file, although I've never tested it that way (todo: include this in the test suite).
Title: Re: ML on EOS-M2
Post by: dfort on August 06, 2017, 01:05:53 AM
Getting closer--but not quite yet.

End of QEMU run with dm-spy-experiments branch merged with EOSM2.103_wip:
Code: [Select]
[  debug_task:ff0d8b9c ] (85:03) GUI_Control:-7 0x0
[ GuiMainTask:ff0d8f50 ] (84:01) GUI_CONTROL:-7
[ GuiMainTask:ff1c1638 ] (84:06) ***** GUI_Control_Post(-7)
[ GuiMainTask:ff1c187c ] (84:01) gui control end
[ GuiMainTask:ff1c189c ] (84:01) 0msec = 5550 - 5550
[ GuiMainTask:ff1c18b8 ] (84:01) 256msec = 563456 - 563712
   187:  5609.984 [GUI_M] ERROR ***** GUI_Control_Post(-7)

And we know how to work with this Assert LOG:
Code: [Select]
ML ASSERT:
mem_sem
at ../../src/mem.c:854 (__mem_malloc), task ml_init
lv:0 mode:3

ml_init stack: 1f38d0 [1f39c8-1ef9c8]
0xUNKNOWN  @ 44c7f0:1f39b0
0x00453F44 @ 49468c:1f39a8
0x004501E0 @ 45423c:1f3968
0x0044F124 @ 450260:1f3950
0x0044C914 @ 44f15c:1f3900
0x0044C468 @ 44c974:1f38d0

Magic Lantern version : Nightly.2017Aug05.EOSM2103
Mercurial changeset   : d538e46a12aa+2214781fcb95+ (dm-spy-experiments-EOSM2.103) tip
Built on 2017-08-05 22:41:51 UTC by [email protected]
Free Memory  : 344K + 1158K

Before getting back to debugging, looks like I found a couple of missing stubs for the EOSM:

Code: [Select]
NSTUB(0xff0d7830,  GUI_ChangeMode)
...
NSTUB(0xff1c4670,  gui_massive_event_loop)

or were these removed on purpose?
Title: Re: ML on EOS-M2
Post by: dfort on August 07, 2017, 07:32:25 AM
How does a "bad merge" happen? Just wondering because I might have been dealing with one. I'm sure I resolved the conflicts properly.

Those problems in my last post also showed up on the 700D:

Code: [Select]
ML ASSERT:
mem_sem
at ../../src/mem.c:854 (__mem_malloc), task ml_init
...
Magic Lantern version : Nightly.2017Aug06.700D114
Mercurial changeset   : 2c1d19295d9f (dm-spy-experiments-EOSM2.103)

which I have running with CONFIG_ALLOCATE_MEMORY_POOL and also on the 550D which I didn't touch:

Code: [Select]
ML ASSERT:
mem_sem
at ../../src/mem.c:854 (__mem_malloc), task ml_init
...
Magic Lantern version : Nightly.2017Aug06.550D109
Mercurial changeset   : 2c1d19295d9f (dm-spy-experiments-EOSM2.103)

What I did was merge my EOSM2.103_wip branch with dm-spy-experiments. Obviously something went wrong. On the regular dm-spy-experiments branch these cameras run fine in QEMU. In fact I was able to get into and navigate around the ML menus.

I've been doing lots of changes and merging so maybe I should start from a clean working dm-spy-experiments branch and start over again.
Title: Re: ML on EOS-M2
Post by: a1ex on August 07, 2017, 09:05:47 AM
In this case, the contents of boot-hack.c are identical on dm-spy-experiments-EOSM2.103 (de9f09df06e7) and EOSM2.103_wip (495f8c25235c):
Code: [Select]
hg diff -r 495f8c25235c -r de9f09df06e7 src/boot-hack.c
(no output)

In other words, it does not contain the dm-spy changes.

In my merge tool (Meld), if they are conflicts, I should first solve them, and then select Merge all. Sometimes I forget to select "Merge all" and run into similar errors - that's probably what happened on my side with 2214781fcb95. In this case I redo the merge and/or compare the merged changeset with both ancestors. For example, between dm-spy-experiments and dm-spy-experiments-EOSM2.103 I expect to see only the M2 changes, for example:
Code: [Select]
diff -r 63d4b3396a5f -r 501eb2ccd140 src/boot-hack.c
--- a/src/boot-hack.c
+++ b/src/boot-hack.c
@@ -660,31 +660,32 @@
 
     uint32_t* addr_AllocMem_end     = (void*)(CreateTaskMain_reloc_buf + ROM_ALLOCMEM_END + CreateTaskMain_offset);
     uint32_t* addr_BL_AllocMem_init = (void*)(CreateTaskMain_reloc_buf + ROM_ALLOCMEM_INIT + CreateTaskMain_offset);
+    uint32_t* addr_B_CreateTaskMain = (void*)(init_task_reloc_buf + ROM_B_CREATETASK_MAIN + init_task_offset);
 
-    #if defined(CONFIG_550D) || defined(CONFIG_60D) || defined(CONFIG_7D)
-    // change end limit to 0xc60000 => reserve 640K for ML
+    #if defined(CONFIG_EOSM2)
+    /* R0: 0x44C000 (start address, easier to patch, change to 0x4E0000 => reserve 592K for ML) */
+    /* R1: 0xD3C000 [6D, 700D] / 0xC3C000 [100D] / 0xD6C000 [EOSM] / 0xC2A000 [EOSM2] (end address, unchanged) */
+    addr_AllocMem_end[1] = MOV_R0_0x4E0000_INSTR;
+    ml_reserved_mem = 0x4E0000 - RESTARTSTART;
+    #elif defined(CONFIG_550D) || defined(CONFIG_60D) || defined(CONFIG_7D)
+    // change end limit from 0xd00000 to 0xc60000 => reserve 640K for ML
     *addr_AllocMem_end = MOV_R1_0xC60000_INSTR;
-    ml_reserved_mem = 640 * 1024;
+    ml_reserved_mem = 0xD00000 - RESTARTSTART;
     #else
-    // change end limit to 0xc80000 => reserve 512K for ML
+    // change end limit from 0xd00000 to 0xc80000 => reserve 512K for ML
     *addr_AllocMem_end = MOV_R1_0xC80000_INSTR;
-    ml_reserved_mem = 512 * 1024;
+    ml_reserved_mem = 0xD00000 - RESTARTSTART;
     #endif
 
     // relocating CreateTaskMain does some nasty things, so, right after patching,
     // we jump back to ROM version; at least, what's before patching seems to be relocated properly
     *addr_BL_AllocMem_init = B_INSTR(addr_BL_AllocMem_init, ROM_ALLOCMEM_INIT);
     
-    uint32_t* addr_B_CreateTaskMain = (void*)init_task_reloc_buf + ROM_B_CREATETASK_MAIN + init_task_offset;
+    // replace call to CreateMainTask (last sub in init_task)
     *addr_B_CreateTaskMain = B_INSTR(addr_B_CreateTaskMain, new_CreateTaskMain);
     
-   
-    /* FIO_RemoveFile("B:/dump.hex");
-    FILE* f = FIO_CreateFile("B:/dump.hex");
-    FIO_WriteFile(f, UNCACHEABLE(new_CreateTaskMain), CreateTaskMain_len);
-    FIO_CloseFile(f);
-   
-    NotifyBox(10000, "%x ", new_CreateTaskMain); */
+    /* before we execute code, make sure a) data caches are drained and b) instruction caches are clean */
+    sync_caches();
     
     // Well... let's cross the fingers and call the relocated stuff
     return new_init_task;

If you run this, you'll spot the mistake right away:
Code: [Select]
hg diff -r 63d4b3396a5f -r de9f09df06e7

I've also got differences in edmac-memcpy.c (where hg considered it was a conflict, but in Meld, I only had to select Merge all without changing anything) and in qemu-util.c (which should be deleted).

That said, I've ran 495f8c25235c+2214781fcb95 in QEMU and only seems to work with CONFIG_QEMU=y, but not without. Looking into it.

BTW - two tricks to speed up the compilation:
Code: [Select]
# only recompiles and installs autoexec.bin, without modules
cd platform/EOSM2.103; make installq ML_MODULES_DYNAMIC=

Code: [Select]
# requires a tiny change from latest unified (g3gg0 found out yesterday)
make -j4
Title: Re: ML on EOS-M2
Post by: dfort on August 08, 2017, 07:31:55 PM
If the dm-spy-experiments branch saves a valid log in QEMU with CONFIG_DEBUG_INTERCEPT_STARTUP=y and CONFIG_QEMU=n, that means we are already there and I'll enable the boot flag.

Cleaned up and updated the EOSM2.103_wip branch so that a pull request on the latest unified branch is showing only the M2 changes. Then I used that to do a new dm-spy-experiments merge and was able to save a DM-0000.LOG (https://pastebin.com/b4b9cGc0). Yay! There are a few error messages in it so as a sanity check I tried the 700D from the latest dm-spy-experiments branch (without the EOSM2 merge) and there are more error messages in the 700D log than in the EOSM2 log!

We'll also need the sf_dump module - that should re-create the SFDATA.BIN file, although I've never tested it that way (todo: include this in the test suite).

Ok--so I included the sf_dump module and on the 700D I was able to get into the ML menu, turn it on and on the next QEMU run (after removing the LOADING.LCK file because of the unclean shutdown) I was able to get into the Debug menu and select "Dump serial flash" but it didn't save a SFDATA.BIN file.

Basically, the EOSM2 is behaving pretty much like the 700D except that I can't get into the ML menus because of the unresponsive LiveView behavior of the EOSM2. Haven't figured out how to workaround it yet.
Title: Re: ML on EOS-M2
Post by: dfort on August 11, 2017, 06:26:27 PM
I can't get to the Magic Lantern menu to check it out.

That's probably because the M2 does not show the "idle" Canon screen (the one with shooting settings); as soon as you close the date/time dialog, it will go to LiveView (which doesn't work in QEMU).

You should be able to work around it by allowing the menu to come up in any GUI state, not just when "idle".

Still struggling with this. No matter what I tried, closing the Canon menu sends it into a black abyss. The QEMU console shows activity when pressing the buttons but nothing comes up on the screen.

How does the dm-spy-experiments startup log (https://pastebin.com/b4b9cGc0) look?

[EDIT] Superfast compilation:
Code: [Select]
make -j4 installq ML_MODULES_DYNAMIC=
Note that the card needs to have at least the ML/modules directory in order to save the .sym file or compilation will fail and running QEMU requires the other directories along with the files that belong in them or else:

(https://farm5.staticflickr.com/4363/36371975081_2961cf41c3.jpg)
Title: Re: ML on EOS-M2
Post by: dfort on August 17, 2017, 07:09:04 PM
I might be bumping up against imperfect emulation. Are we ready to run some tests on the real hardware?

Those errors are likely just imperfect emulation (we are using properties from 100D, not from a real camera).

However, we should be close to getting these things from real hardware. If the dm-spy-experiments branch saves a valid log in QEMU with CONFIG_DEBUG_INTERCEPT_STARTUP=y and CONFIG_QEMU=n, that means we are already there and I'll enable the boot flag.

We'll also need the sf_dump module - that should re-create the SFDATA.BIN file, although I've never tested it that way (todo: include this in the test suite).
Title: Re: ML on EOS-M2
Post by: vagaboundedu on August 26, 2017, 02:03:04 PM
Do you already have an M2 to test on? How do you know when it's time?
Title: Re: ML on EOS-M2
Post by: dfort on August 26, 2017, 07:11:01 PM
Yes and when a1ex makes the decision that it is time.

Like I implied in prior posts, I hit a wall. I can't get the ML menus to come up in QEMU. Maybe I need to re-read a1ex's posts about MPU communication (http://www.magiclantern.fm/forum/index.php?topic=17596.msg188965#msg188965) or maybe it is because we're still using a 100D SFDATA.BIN and need to figure out how to get the "real" EOSM2 SFDATA.BIN.

Then again a1ex hinted that he might go ahead and enable the boot flag, something that only a developer with the right tools can do. If so maybe we'll be able to see ML working on the M2--or maybe we'll brick it.
Title: Re: ML on EOS-M2
Post by: vagaboundedu on August 27, 2017, 05:35:47 AM
Okay! Well, I definitely hope it's the former! :)
Title: Re: ML on EOS-M2
Post by: dfort on September 08, 2017, 02:57:36 AM
@a1ex

Don't want to be a pest but the EOSM2 port is feeling a little jealous lately. Any hint on what the next step should be? Maybe turn on the boot flag?
Title: Re: ML on EOS-M2
Post by: a1ex on September 10, 2017, 08:41:40 PM
You are not running into emulation issues yet (except for the lack of LiveView, not needed at this stage) - this camera requires new-style DryOS task hooks (https://bitbucket.org/hudson/magic-lantern/pull-requests/672/dryos-task-hooks-for-newer-cameras-6d-70d/diff) (that's why it doesn't handle the buttons). There are two ways to deal with it:

- the old 6D method from unified (which I don't like, as it increases the "ifdef" complexity and has some missing functionality)
- the new one, which was recently confirmed on 100D and - less than 24 hours ago - on 70D.

If you are not rushing, let me merge the new DryOS hooks into unified first. I've already started to clean up QEMU for merging, since that's a pre-requisite. Maybe also 100D and 70D (the former looks good to me, but I wanted to use the new backends for it, the latter has a few of rough edges, but hopefully not show-stoppers).
Title: Re: ML on EOS-M2
Post by: dfort on September 10, 2017, 09:54:23 PM
I'm not rushing--just feeling that I lost the momentum.

Last night I built a new QEMU testing environment with all the latest changes and that's when I discovered that silent.mo wasn't building in my EOSM2 branch. Digging deeper I found the same problem existed on all the other cameras. Now that I'm a little more familiar with the ML code thanks to this porting project, I was able to submit a fix instead of just submit a bug report.

Of course I'd like to get the camera boot flag turned on and start playing around with ML on this camera but that's the little kid in me wanting to play with his toy.
Title: Re: ML on EOS-M2
Post by: bookemdano on September 17, 2017, 04:34:28 AM
As someone who just bought an M2 I'm really pulling for you dfort. I specifically chose the M2 over the M3 and newer cameras because like the M it runs DryOS and is therefore capable of running ML. Plus it uses the uber-cheap LP-E12 batteries and there's no stupid hassle with using third party batteries/chargers. I chose it over the M because of the faster focusing speed & more focusing points, the lighter/smaller body and the built-in WiFi (since none of the Ms can do tethered shooting over USB, WiFi control is better than nothing at all and is a possible avenue for future innovation).

I am not well-versed enough in coding to assist with the actual porting, but I have a fairly high risk tolerance and a mind for diagnostics. So when it comes time to put an alpha through its paces, sign me up. The M2 is not my main camera, and they can be had somewhat cheaply on ebay so if I brick it, it's not the end of the world.

I'm heartened to hear A1ex's comments that this should be a fairly straightforward port. And dfort I've seen enough of your other contributions here to know that you've got what it takes to do this. So I guess I just want to give you simultaneous pat on the back/shove to keep going. The M2 is the best Canon mirrorless model capable of running ML, so it deserves to run ML :D

Seriously though, thank you guys for all the time you've spent so far on this endeavor. I'll enjoy my new M2 even without ML, but man I hope I get to run ML on it.
Title: Re: ML on EOS-M2
Post by: dfort on September 17, 2017, 08:21:39 AM
@bookemdano -- are you able to use Mercurial (command line or through a GUI like SourceTree) and compile ML? That would be the best way to test, once the camera boot flag is enabled of course. So while we're waiting for that, take the time to set up a testing/development environment. It isn't that hard. I've got a few tutorials on how to get something up quickly on Mac or Windows. If you're on Linux you don't need a tutorial.
Title: Re: ML on EOS-M2
Post by: odell_matt on September 28, 2017, 04:52:55 PM
Im sorry but I have no idea whats going on. I have a Canon Rebel T6 and i want to know if it possible to run it. Someone recommended this forum but i don't know like anything about coding or that stuff. Can anyone help me with what i need to do?
Title: Re: ML on EOS-M2
Post by: bookemdano on October 02, 2017, 06:42:08 AM
@bookemdano -- are you able to use Mercurial (command line or through a GUI like SourceTree) and compile ML? That would be the best way to test, once the camera boot flag is enabled of course. So while we're waiting for that, take the time to set up a testing/development environment. It isn't that hard. I've got a few tutorials on how to get something up quickly on Mac or Windows. If you're on Linux you don't need a tutorial.

First of all, sorry for the delay in response. I posted my earlier message and then promptly left on a two week vacation. I'm back now and followed your very thorough OS X tutorial. I just successfully compiled the Oct 1 nightly for the 6D, although I haven't tried actually running it on my 6D yet (guess I should do that before I deem it successful). But I think I'm ready to go for when you've got something ready to test.

I used the M2 on my trip and I'm really impressed with how much camera Canon packed into such a tiny body. I was prepared for the slow-ish focus--it's not a big deal to me. My only real gripe is that it chewed through the wimpy LP-E12 batteries like candy. I think I'm going to pick up a generic ACK-E12 AC adapter for when I test ML on it. I'm still glad to not have to hassle with the E17 and the "feature" Canon added that makes using generic batteries as annoying as possible.

So... any progress lately? I know each body's ML port is like a crying puppy badly needing love and there aren't enough devs here to tend to them all. And the M2 would definitely be the runt of the litter given how few of them were sold.  So no worries if you're prioritizing something else that will benefit more people. But by all means, if there is anything I can do to assist, let me know. I don't have much knowledge about ML development but I'm pretty decent at (eventually) figuring stuff out with some google-fu, asking dumb questions and good old trial and error.

Title: Re: ML on EOS-M2
Post by: dfort on October 02, 2017, 07:15:20 AM
...I know each body's ML port is like a crying puppy badly needing love and there aren't enough devs here to tend to them all. And the M2 would definitely be the runt of the litter given how few of them were sold...

Great analogy!

I went as far as I could go for now. I either need to wait get the camera boot flag enabled to test it on the camera or wait until full emulation is available on QEMU. Not an unlikely scenario, the original EOSM has just recently had the menus working in QEMU. In any case, a1ex has a long list (http://www.magiclantern.fm/forum/index.php?topic=15895.msg189856#msg189856) and being the runt of the litter we're near the end of the queue.
Title: Re: ML on EOS-M2
Post by: a1ex on October 02, 2017, 10:13:08 AM
Full emulation (aka LiveView) is unlikely to happen anytime soon; the EOS M was just catching up and it's currently in the same state as M2, emulation-wise.

What the M2 requires is new DryOS task hooks (https://bitbucket.org/hudson/magic-lantern/pull-requests/672/dryos-task-hooks-for-newer-cameras-6d-70d). That's not a QEMU limitation; the DryOS internals changed on recent models - if I enable the boot flag now, you'll have the same issue on the real camera. If you haven't been able to solve it in the emulator (where you have debugging tools available), I doubt you'll be able to solve it on the physical camera.

I'm trying to get new DryOS hooks into unified, but we've got into trouble on 100D (http://www.magiclantern.fm/forum/index.php?topic=16040.msg190279#msg190279) (some cameras don't boot with this method, or they do so randomly, apparently dependent on some Canon settings).

Of course, you can try the method meanwhile (just merge new-dryos-task-hooks), or try the old 6D workarounds, or try this exercise (http://www.magiclantern.fm/forum/index.php?topic=15895.msg187913#msg187913) on the original M (which has old-style DryOS).

Or, find some configuration (Canon settings) on both the original M and on the M2 where the camera doesn't go directly in LiveView when powering on, and ML menu can be started from that screen (not sure if there is such screen on these cameras), dump the ROM in that state, maybe get a startup-log (dm-spy-experiments) and try it.

And new-dryos-task-hooks depends on QEMU, so I should get that one in unified first (that was the reason for making sure it compiles and installs on most common operating systems, btw).

So, there are still a couple of things to try until the new backends will be ready.
Title: Re: ML on EOS-M2
Post by: dfort on October 02, 2017, 03:22:59 PM
Thanks for the tips. I've also been trying to work out the kinks on my other cameras, EOSM and 700D, and have actually gotten out in the field with the 5D3. Looks like I should spend some more time with this little runt. When I first started this port I thought it would be easy--ha!
Title: Re: ML on EOS-M2
Post by: bookemdano on October 07, 2017, 07:54:59 PM
In hopes of trying to contribute something I spent the last hour seeing if there was some way of getting the M2 to power on to any other screen other than LV, and unfortunately I wasn't able to find one. I know with my PowerShot S95 I can press the Play button when the camera is off and it powers on and goes directly to playback mode. But with the M2, none of the buttons appear functional until the Power button is pressed, and that directly goes to LV mode, no matter what settings I tried in the menus. Does the original M have the same limitation?

Title: Re: ML on EOS-M2
Post by: dfort on October 07, 2017, 08:26:45 PM
The EOSM and EOSM2 work the same when it comes to starting the camera with the play button. They start up in playback mode which is not LiveView.

I've been busy on other projects so I haven't been able to look into it but the problems with the new DryOS task hooks that are causing problems on the 100D are likely a problem on the EOSM2 because these cameras are very similar. I'll follow the "fix" on the 100D when it is ready.

In the meantime you might look into doing a firmware dump and running it in QEMU. Yeah, I know it is a challenge. Just start here (http://www.magiclantern.fm/forum/index.php?topic=15895.msg185084#msg185084), take it a step at a time and follow what was already posted. Note that compiling ML and getting QEMU up and running is much easier these days.
Title: Re: ML on EOS-M2
Post by: bookemdano on October 07, 2017, 09:10:20 PM
The EOSM and EOSM2 work the same when it comes to starting the camera with the play button. They start up in playback mode which is not LiveView.

I've been busy on other projects so I haven't been able to look into it but the problems with the new DryOS task hooks that are causing problems on the 100D are likely a problem on the EOSM2 because these cameras are very similar. I'll follow the "fix" on the 100D when it is ready.

In the meantime you might look into doing a firmware dump and running it in QEMU. Yeah, I know it is a challenge. Just start here (http://www.magiclantern.fm/forum/index.php?topic=15895.msg185084#msg185084), take it a step at a time and follow what was already posted. Note that compiling ML and getting QEMU up and running is much easier these days.

Oh, derp. I see now you have to hold down the play button for 1+ seconds to get it to start in playback mode--a momentary press won't cut it. That's probably even in the manual for the camera which I probably ought to read.

Was that what a1ex was talking about then--a way to start up the camera in a screen other than LV and launch ML from that screen? Or can ML not run from Playback mode either? Maybe he was just referring to running it within QEMU. Sorry if those are dumb questions.

I'll take your last paragraph as a stretch goal and see how far I can get.
Title: Re: ML on EOS-M2
Post by: dfort on October 08, 2017, 12:02:22 AM
What a1ex was talking about was to save the firmware dump in a setting other than LiveView. His exact words:

...find some configuration (Canon settings) on both the original M and on the M2 where the camera doesn't go directly in LiveView when powering on, and ML menu can be started from that screen (not sure if there is such screen on these cameras), dump the ROM in that state...
Title: Re: ML on EOS-M2
Post by: dfort on October 21, 2017, 10:29:11 PM
What the M2 requires is new DryOS task hooks (https://bitbucket.org/hudson/magic-lantern/pull-requests/672/dryos-task-hooks-for-newer-cameras-6d-70d). That's not a QEMU limitation; the DryOS internals changed on recent models - if I enable the boot flag now, you'll have the same issue on the real camera. If you haven't been able to solve it in the emulator (where you have debugging tools available), I doubt you'll be able to solve it on the physical camera.
...
Of course, you can try the method meanwhile (just merge new-dryos-task-hooks)...

Finally got around to trying out the new DryOS task hooks but still no luck getting to the ML menus. Haven't tried the other suggestions yet.

On the Mac "fn delete" brings up the ML menu on the 700D but nothing on the EOSM2. In fact the EOSM2 still goes into the black abyss when leaving the Canon menu and the "M" key doesn't bring it back to life.

I've been trying out the EOSM2 on various branches and here is what I'm doing in QEMU:

Code: [Select]
make -C ../magic-lantern/platform/EOSM2.103 install_qemu
./run_canon_fw.sh EOSM2,firmware="boot=1" -d debugmsg -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb

Don't have to bother mounting and unmounting the sd disk image. Nice!
Title: Re: ML on EOS-M2
Post by: vagaboundedu on November 11, 2017, 10:11:47 PM
Thank you for your work on this. Here's hoping there will be a way to get through this issue!
Title: Re: ML on EOS-M2
Post by: orielsy on December 02, 2017, 04:25:47 AM
Finally got around to trying out the new DryOS task hooks but still no luck getting to the ML menus. Haven't tried the other suggestions yet.

On the Mac "fn delete" brings up the ML menu on the 700D but nothing on the EOSM2. In fact the EOSM2 still goes into the black abyss when leaving the Canon menu and the "M" key doesn't bring it back to life.

I've been trying out the EOSM2 on various branches and here is what I'm doing in QEMU:

Code: [Select]
make -C ../magic-lantern/platform/EOSM2.103 install_qemu
./run_canon_fw.sh EOSM2,firmware="boot=1" -d debugmsg -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb

Don't have to bother mounting and unmounting the sd disk image. Nice!

Hello all,

I'm a computer science graduate and would like to join in on tackling this as I just purchased the M2. These days I mostly deal with Frontend Development so it's been a while since I've touched C++, Assembly or anything like that.  I'm hoping I can chip in though.

Any info to help me get up to speed helps. In the mean time I'll be reading all the comments here.
Title: Re: ML on EOS-M2
Post by: Audionut on December 04, 2017, 07:31:25 AM
Sticky topics in this section (http://www.magiclantern.fm/forum/index.php?board=25.0) will get you started.
Title: Re: ML on EOS-M2
Post by: platerytter on December 14, 2017, 05:50:21 PM
Just registered to say there's more people cheering for you guys! The m2 is a fantastic camera and deserves a little magic :)
Title: Re: ML on EOS-M2
Post by: dfort on December 15, 2017, 08:35:17 PM
Yes, it would be great to end the year with at least "Hello World" running on the M2 but that requires an ML-SETUP.FIR file and a1ex decides who's been naughty or nice enough to get that present.
Title: Re: ML on EOS-M2
Post by: vagaboundedu on December 18, 2017, 04:24:37 AM
 :)
Title: Re: ML on EOS-M2
Post by: dfort on December 27, 2017, 10:03:32 PM
Enabling the boot flag on the camera might be one small step but it feels like a giant leap.

(https://farm5.staticflickr.com/4634/39308994962_83c9ede315_z.jpg) (https://flic.kr/p/22TASGs)

First issue that came up was that the firmware signature that I got out of QEMU didn't match what I got running the code on the camera:

src/fw-signature
Code: [Select]
-#define SIG_EOSM2_103 0x17D200D6
+#define SIG_EOSM2_103 0x1f321405

Still to do--figure out the Trash button code so we can get to the ML menu. There's also some other obvious issues but hey, it's alive!

(https://farm5.staticflickr.com/4636/39308998392_6e4e6933a6_z.jpg) (https://flic.kr/p/22TATHA)
Title: Re: ML on EOS-M2
Post by: Lars Steenhoff on December 27, 2017, 10:14:26 PM
Thats a great step!  congrats  :)
Title: Re: ML on EOS-M2
Post by: Kharak on December 27, 2017, 10:14:51 PM
Yes, it would be great to end the year with at least "Hello World" running on the M2 but that requires an ML-SETUP.FIR file and a1ex decides who's been naughty or nice enough to get that present.

You've beev a good boy it seems :) Congrats!
Title: Re: ML on EOS-M2
Post by: dfort on December 27, 2017, 11:00:07 PM
Got a basic in-camera startup log (https://pastebin.com/nzYgVS5y). Still looking for that magic Trash button code.
Title: Re: ML on EOS-M2
Post by: chrissul13 on December 28, 2017, 05:21:22 PM
This makes me SO happy.  I just got my EOS M2 which i bought without realizing ML did not work with it...and now it may!!! can't wait.  I'm mainly just wanting focus peaking as it is HARD to focus this camera manually
Title: Re: ML on EOS-M2
Post by: platerytter on January 03, 2018, 09:27:50 AM
Terrifc update dfort! Happy new years to you!
Title: Re: ML on EOS-M2
Post by: vagaboundedu on January 13, 2018, 06:24:10 PM
This is awesome! It made my day to see the pictures you posted!

I agree--the focus peaking will be very helpful, as will clean video output for recording productions.
Title: Re: ML on EOS-M2
Post by: dfort on January 16, 2018, 01:15:23 AM
@a1ex committed a change for the EOSM2 (https://bitbucket.org/hudson/magic-lantern/commits/c33141cd12a9b2d610c386a8357b14d6b4935b2d) on the qemu branch so of course I tried it out. Wish I could say everything was rainbows and unicorns but--

Code: [Select]
./run_canon_fw.sh EOSM2 -s -S &
arm-none-eabi-gdb -x EOSM2/patches.gdb -ex quit

...
Breakpoint 1, 0xff0c5144 in ?? ()
Patching LeoLens (infinite loop)
[MPU] Received: 06 05 09 11 01 00  (PROP_LV_DISPSIZE - spell #22)
[MPU] Received: 12 11 09 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00  (PROP 80050020 - spell #23)
[MPU] Received: 14 13 09 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  (unnamed - spell #24)
[MPU] Received: 06 05 01 5a 00 00  (PROP_CONTINUOUS_AF_VALID - spell #25)
[MPU] Sending : 06 05 01 59 01 00  (PROP_MOVIE_SERVO_AF)
[MPU] Received: 06 05 09 2f 01 00  (unnamed - spell #26)
[MPU] Received: 06 05 0e 22 1e 00  (unknown - unnamed)
    70:   121.344 [MR] mvrChangeAckCBR : Video - Mode=0, Type=2, Rate=30, GOP=15
    88:   125.440 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050038
    89:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050041
    90:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050042
    91:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050043
    92:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050044
    93:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x0105004F
    94:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050050
    95:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050051
    96:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050052
    97:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x0105010E
    98:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x0105010F
    99:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050110
   100:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x01050111
   101:    60.160 [PROPAD] ERROR GetPropertyData ID (1) = 0x0104000B
   102:    60.160 [LVCOM] InitializeLiveViewDefectDetection
   103:    60.416 [LVCOM] ExecuteDefectMarge Start
   104:    60.416 [LVCOM] ExecuteDefectMarge End
   106:    61.184 [LV]  PROP_LV_BLOCK  PROP_LV_UNBLOCKING 0
   108:    62.208 [AUDIO] RegisterCBRSDIOCableConnect
   109:    64.256 [WFT] InitializeAdapterControl END
SD: Unknown CMD1
[SDIO] Error
SD: Unknown CMD1
[SDIO] Error
SD: Unknown CMD1
[SDIO] Error
   124:   151.808 [SD] ERROR SDINTREP=0x00000000
   125:   151.808 [SD] ERROR UNEXPECTED ERROR
   131:   113.152 [RSC] WARN ILLEGAL SUBFREECLUSTERCOUNT ShootStorage.c 686
   157:   184.832 [DISP] ERROR PROP_TFT_SETTING_PARAM DON'T FIND
   158:   184.832 [DISP] ERROR Factory Adjust For TftCom
   159:   185.088 [MR_MOV] (Empty Func) MVW_RegisterXmpDataCallback
   160:   142.336 [TCH]Touch IC Ver : 0x0000
   161:   569.600 [TCH]ERROR  TouchPanelIC Ack Error
   162:   569.856 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   163:   570.112 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   164:   570.112 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   165:   570.112 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   166:   570.368 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   167:   570.368 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   168:   570.368 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   169:   570.624 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   170:   570.624 WARN [I2C] localI2C_Read : 378 (Task : Startup)
   171:   572.672 [IMPP] H264E InitializeH264EncodeFor1080pDZoom
   172:   572.672 [IMPP] H264E InitializeH264EncodeFor1080p25fpsDZoom
   179:   578.816 [STARTUP] startupInitializeComplete
   185:   580.864 [CEC]CEC OFF

I usually use debugmsg.gdb instead of patches.gdb so I gave that a go but couldn't get Hello World to print, much less the firmware signature. Going back to my previous build it worked--sort of. As expected, it printed the wrong firmware signature.

There is some positive news to report. Although I still can't get to the ML menu on the camera or QEMU I hacked the ML/SETTINGS/MAGIC.CFG file to see if any of the features are working--say like focus peaking?

It works! Yay!

So what's the next step of this walk through? Seems like we need to find the code for the Trash button, which on this camera is also the down key or bottom of the thumb wheel. Maybe do a serial flash dump? I could probably get everything set up but how to trigger a module without access to the ML menu?
Title: Re: ML on EOS-M2
Post by: a1ex on January 16, 2018, 08:58:03 AM
Hello World is working out of the box here, with latest sources from EOSM2.103_wip (both minimal and CONFIG_HELLO_WORLD, both debugmsg.gdb and patches.gdb), same firmware signature as on real hardware (does this (http://www.magiclantern.fm/forum/index.php?topic=15895.msg186872#msg186872) make any more sense now?)

Didn't test on Mac though; I'll try later if it still doesn't work. Without loading ML, is the Canon menu still working? (GUI emulation is covered in the test suite (http://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-tests/), which runs for every few commits, or every non-trivial commit).

Next steps were covered before: new-dryos-task-hooks (done for 1300D (http://www.magiclantern.fm/forum/index.php?topic=17969.msg195883#msg195883), some stubs apparently wrong on M2), a tiny hack in menu.c to bring menu in QEMU (not needed for camera), and if there are any buttons not recognized, just print their codes.

For working with modules, this tutorial should help: http://www.magiclantern.fm/forum/index.php?topic=19232.0
Title: Re: ML on EOS-M2
Post by: dacampora on January 17, 2018, 12:22:28 AM
Hello.  First post but long time reader. Just here to vouch my support for the M2. Mostly interested in time lapse.
Title: Re: ML on EOS-M2
Post by: dfort on January 17, 2018, 07:05:54 AM
Got it working on Windows Subsystem for Linux (WSL) -- (Scream like a little girl!)

(https://farm5.staticflickr.com/4701/27958206339_5a96826c35.jpg) (https://flic.kr/p/JAz7Gk)

(does this (http://www.magiclantern.fm/forum/index.php?topic=15895.msg186872#msg186872) make any more sense now?)

Yes it does. Anytime the ROM is patched the firmware signature changes. Is that the lesson here?

Didn't test on Mac though; I'll try later if it still doesn't work. Without loading ML, is the Canon menu still working?

Yeah, looks like there is a Mac issue, but only with patches.gdb. Running ML with debugmsg.gdb does show the firmware signature and it matches what I'm getting in camera. It was just that the commit you pointed out (https://bitbucket.org/hudson/magic-lantern/commits/c33141cd12a9b2d610c386a8357b14d6b4935b2d) was on patches.gdb so I thought it was necessary to run it with patches.gdb.

One other observation - on Mac it pauses for user input while on WSL it doesn't:

Code: [Select]
---Type <return> to continue, or q <return> to quit---
I merged in the new-dryos-task-hooks a while back but maybe I screwed it up. I'll try it again and see if I can track down the bogus stubs.

..a tiny hack in menu.c to bring menu in QEMU (not needed for camera), and if there are any buttons not recognized, just print their codes.

A tiny hint on how to print out the button codes?
Title: Re: ML on EOS-M2
Post by: a1ex on January 17, 2018, 09:36:25 AM
Quote
Yeah, looks like there is a Mac issue, but only with patches.gdb.

Reproduced on Mac. With just patches.gdb, it didn't work before that commit either...

However, running with patches.gdb and with -d debugmsg.gdb brings the GUI. Must be a timing issue, and the additional debug messages are slowing it down; in the end, that slowdown ends up helping. These timing issues are why many of the tests (http://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-tests/) are still failing (nondeterministically; in many cases just giving slightly different screenshots, not what the test suite expects).

Reproduced on Linux with -icount 1 or 2 (this gives deterministic execution). Any other number between 3 and 10 is working.

BTW, debugmsg.gdb always includes patches.gdb, and adds additional debug messages.

Quote
One other observation - on Mac it pauses for user input while on WSL it doesn't:

I only get the prompt when the terminal window is too small. It doesn't interfere with the "-ex quit" added recently; that's good.

Quote
A tiny hint on how to print out the button codes?

Debug -> Show GUI events.
Title: Re: ML on EOS-M2
Post by: chrissul13 on January 18, 2018, 02:36:06 AM
I'm not saying i'm squealing like a little girl, but....well, focus peaking would be awesome.  I'm getting to know the camera and that's like my only weakness with it. 

Goodluck, can't wait for more
Title: Re: ML on EOS-M2
Post by: dfort on January 21, 2018, 04:06:15 AM
Next steps were covered before: new-dryos-task-hooks (done for 1300D (http://www.magiclantern.fm/forum/index.php?topic=17969.msg195883#msg195883), some stubs apparently wrong on M2)

I tried merging new-dryos-task-hooks again and this time it looks like it worked. At least "Hello World" is running--tested on the camera too.

You can now see DryOS tasks switching if you compile with CONFIG_QEMU=y and you enable DEBUG_TASK_HOOK in boot-hack.c. Without the latter, only new tasks will be displayed.

Did that too. Don't know what exactly to look for but there are a lot more messages flying through the terminal when run in QEMU.

So--one small step.
Title: Re: ML on EOS-M2
Post by: a1ex on January 21, 2018, 09:34:33 AM
You should see DryOS tasks switching back and forth (try on some other camera model, in particular, 6D, 100D, 70D or 1300D). Caveat: you should undefine CONFIG_HELLO_WORLD, as that option disables the task hook (to prevent running unwanted GUI code or other tasks).

Similar info is printed when running with "-d tasks" (useful for cross-checking the messages).

I don't see any of these messages here -> my_task_dispatch_hook does not get called. That's why I believe some stubs might be wrong - on 1300D I had to fix task_dispatch_hook (https://bitbucket.org/hudson/magic-lantern/commits/8b06129b51ca) (see also the commit for 6D (https://bitbucket.org/hudson/magic-lantern/commits/381a5bfde951bceb36bcf2216a76976dbed83364#chg-platform/6D.116/stubs.S))
Title: Re: ML on EOS-M2
Post by: dfort on January 21, 2018, 10:30:33 PM
Fixed task_dispatch_hook so it matches the changes on the 1300D and 6D. I couldn't follow the comments on the task_dispatch_hook for those cameras but I used my best pattern matching skills and also checked against the 100D and 70D so I'm pretty confident that I've got this right. By the way, the EOSM doesn't fall into the same pattern as the other cameras. Is new-dryos-task-hooks working properly on the EOSM?

In the process I also found a typo on task_trampoline and fixed it.

Code: [Select]
/** Tasks **/
NSTUB(   0x8FBE0,  task_dispatch_hook)                      // changed from 0x8FAB4 - now it doesn't work on the camera.
NSTUB(0xFFD24B44 - RAM_OFFSET,  task_create)
NSTUB(0xFFD2A1D8 - RAM_OFFSET,  task_trampoline)

However, as you can see from my comment it no longer works on the camera. LED turns on and camera won't boot up. So there must be something else that needs fixing. I know there are other things to fix. The lens focal length is displayed as 0 thought the f/stop and shutter speed is fine.

So it is one step forward and two steps back.

Still to do:

...a tiny hack in menu.c to bring menu in QEMU (not needed for camera), and if there are any buttons not recognized, just print their codes.

Big discovery for today is that adding this line to MAGIC.CFG the camera boots up with the console open.

Code: [Select]
module.console = 1

(https://farm5.staticflickr.com/4610/39791604802_89828e4992.jpg) (https://flic.kr/p/23CfnML)

Now how to get the console to show button events? I'll bet the answer is to get the task hooks working properly.
Title: Re: ML on EOS-M2
Post by: dfort on January 22, 2018, 07:39:37 AM
Took another step forward -- got a SFDATA.BIN dump from the camera. I still can't get to the ML menu so here's how I did it.

In order to load modules on startup simply add an empty file with the name of the module in the ML/SETTINGS directory. For the sf_dump module it has to be named like this:

Code: [Select]
SF_DUMP.EN
Now in order to get the module to auto run without having to start it from the Debug menu I did this hack to sf_dump_init():

Code: [Select]
//    menu_add("Debug", sf_dump_menu, COUNT(sf_dump_menu));
    sf_dump_task();
    return 0;

It also worked in QEMU but since we've been using a 100D SFDATA.BIN all that happened was that it copied the 100D file to the card image. Now I've got a "real" EOSM2 SFDATA.BIN to work with.
Title: Re: ML on EOS-M2
Post by: a1ex on January 22, 2018, 06:32:39 PM
Fixed task_dispatch_hook so it matches the changes on the 1300D and 6D. I couldn't follow the comments on the task_dispatch_hook for those cameras but I used my best pattern matching skills and also checked against the 100D and 70D so I'm pretty confident that I've got this right.

Looks right to me.

The comments are still valid; for example the 1300D one:

// task_trampoline -> last call -> last non-empty BL -> one indirect call here
task_trampoline (0xFFD2A1D8 - RAM_OFFSET) -> 0xC9F4.
Last call: B sub_C8FC
Last non-empty BL: sub_C8FC ends at C9F0, the BL at C9E8 calls an empty function, the one before it calls sub_1D7C.
One indirect call here:
Code: [Select]
1D88                 LDR     R0, =0x8FBE0
1D90                 LDR     R3, [R0]
1D94                 CMP     R3, #0
1DA4                 BLXNE   R3

Answer: 0x8FBE0.

The comments from 6D are easier to follow with a decompiler, but they follow the same logic.

Quote
By the way, the EOSM doesn't fall into the same pattern as the other cameras. Is new-dryos-task-hooks working properly on the EOSM?

From what I could tell in QEMU, it works fine. If ML is still working on the camera with new-dryos-task-hooks (or lua_fix, which includes the former), then it works fine.

The EOSM uses old-style task hooks (that's a property of Canon code, we can't change it); our debug messages are still printed with the new-dryos-task-hooks branch (on the old-style code path; they look slightly different). The point of that PR is to have a unified codebase that covers both old-style and new-style cameras.

Quote
However, as you can see from my comment it no longer works on the camera. LED turns on and camera won't boot up.

That's odd, as with your vanilla code, it boots fine in QEMU. Just in case: you haven't run the binary compiled with CONFIG_QEMU=y on the camera by mistake, right? (that would result in lock-up)

You still have to enable the new-style DryOS hooks; noticed that was a bit non-intuitive, so I've just refactored it to use CONFIG_NEW_DRYOS_TASK_HOOKS in internals.h. Previously, you had to comment out HIJACK_TASK_ADDR to enable the new hooks. Not enabling the new-style hooks should not result in camera lock-up.

Side note: confirmed the new DryOS hooks, in their current shape, are also compatible with DIGIC 6 (tested on 80D) and from what I could tell without trying, also with DIGIC 7 (not tested, but the task hook call looks very similar).

Quote
Now how to get the console to show button events? I'll bet the answer is to get the task hooks working properly.

Right.
Title: Re: ML on EOS-M2
Post by: dfort on January 23, 2018, 02:13:42 AM
It's Alive!

(https://farm5.staticflickr.com/4605/39814203202_0958e3455b_z.jpg) (https://flic.kr/p/23Efcvm)

I've just refactored it to use CONFIG_NEW_DRYOS_TASK_HOOKS in internals.h.

That's all it needed. The Trash button brings up the ML menu on the camera, no need to hunt down the button code.

Of course this isn't the end of the adventure, there's still lots to do. The ML menus look a little rough, the screenshot feature doesn't work and [EDIT - Didn't work on the first boot but now it works] there are other obvious things that need fixing but hey--it is finally running on the camera.

BTW--Yesterday was my birthday and this is the best present!
Title: Re: ML on EOS-M2
Post by: JohanJ on January 23, 2018, 07:13:39 AM
Congratulations to this breakthrough - and happy birthday dfort!!


Sent from my SM-G930F using Tapatalk

Title: Re: ML on EOS-M2
Post by: dfort on January 23, 2018, 01:31:00 PM
@a1ex -- A question about porting a new camera.

I would think that the goal is to eventually make a pull request in order to add a new camera to the unified branch so I created a "dummy" pull request in my ML fork:

https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/4/eosm2103-wip/diff

Looks like I've got lots of things in there that aren't a part of the unified branch yet. Should I continue merging in branches to my work in progress branch or start over with a clean branch from unified and add in my changes? My gut feeling is that I should continue on my wip branch. The reason I'm asking is because I believe that the next step I should take is to merge in the latest dm-spy-experiments and make an in camera startup log. This might resolve issues we're having with QEMU like not recognizing some of the buttons and losing the GUI after going into Live View.

Then again maybe the goal is to make a pull request to the "bleeding edge" crop_rec_4k branch and bring in all the good stuff from the various branches as long as it doesn't break the other platforms?

I know we're far from a pull request, much less getting it approved and merged but thought I'd ask anyway. After all it is working--sort of. Let's just say it is crawling for now.

[EDIT] Speaking of QEMU issues, when running "./run_canon_fw.sh EOSM2 -d debugmsg -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb" it works fine but running "./run_canon_fw.sh EOSM2 -d debugmsg" I'm getting an infinite loop like this on the Mac:

Code: [Select]
   252:  6418.176 WARN [I2C] localI2C_Write : 317 (Task : Startup)
[     Startup:ff349fd8 ] (14:02) I2C > [01] 02
[     Startup:ff356f04 ] (00:26) [I2C] localI2C_Write : 317 (Task : Startup)
[     Startup:ff34a020 ] (14:06) I2C abort 0(1020000)
   253:  6466.816 WARN [I2C] localI2C_Write : 317 (Task : Startup)
   254:  6466.816 [AUDIO] ERROR I2C abort 0(1020000)
[     Startup:ff349fd8 ] (14:02) I2C > [01] 02
[     Startup:ff356f04 ] (00:26) [I2C] localI2C_Write : 317 (Task : Startup)
[     Startup:ff34a0a4 ] (14:03) I2C_Write retry 1 1 c3

No issues with pausing if the terminal window is "too small" though.
Title: Re: ML on EOS-M2
Post by: a1ex on January 23, 2018, 02:08:34 PM
For 1300D (http://www.magiclantern.fm/forum/index.php?topic=17969.msg195883#msg195883), I've merged new-dryos-task-hooks (which you need anyway), qemu, lua_fix (which should reach the mainline soon) and 1200D (for similarity). I think it's best to start a clean branch starting from unified, with the first 3 branches merged.

You could also consider including 100D, which is very similar to EOSM2 and also waits for the first 3 backends to reach the mainline (otherwise it's pretty much ready). 70D is a bit more bleeding edge (it uses patchmgr, which I can still crash with ERR70, although not exactly reproducible), so let's leave this one aside for now.

You can include dm-spy-experiments in your current wip branch and use it for reverse engineering (understanding how things work). This branch breaks things on some cameras (for example, 600D did not even boot (http://www.magiclantern.fm/forum/index.php?topic=15360.msg196261#msg196261)), so let's not include this one in the PR yet.
Title: Re: ML on EOS-M2
Post by: Danne on January 23, 2018, 04:54:56 PM
dfort, what an achevement, bravo, and happy birthday as well. And thanks to a1ex who makes all of this possible.
Title: Re: ML on EOS-M2
Post by: dfort on January 23, 2018, 06:42:06 PM
Thanks @Danne - Not much is working and it has a long way to go but it feels like we reached a milestone.

@a1ex - The dm-spy-experiments merge broke a few things so I think I'll make that a separate branch and keep the wip branch in its current somewhat working state so I can cherry pick the pieces to put into a new clean branch.

I was able to create a startup log with mpu events that might help with QEMU. The camera locked up on startup and I had to do a battery pull but here's the log it created (https://pastebin.com/U80iRVEq). The lock up problem also happened on the EOSM so it isn't just an EOSM2 issue, it worked fine on the 700D.
Title: Re: ML on EOS-M2
Post by: bouncyball on January 23, 2018, 07:10:05 PM
@dfort: Congratulations! And Happy Birthday! :D
Title: Re: ML on EOS-M2
Post by: vagaboundedu on January 23, 2018, 11:05:56 PM
Congratulations on this huge milestone! I'm very impressed! It's all hidden in mystery for me. :)
Title: Re: ML on EOS-M2
Post by: a1ex on January 23, 2018, 11:57:27 PM
The lock up problem also happened on the EOSM [...]

Is it still an issue with current startup-log builds (https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log/)?

(I thought I've fixed that one back then, when you reported it, but maybe there are still rough edges)
Title: Re: ML on EOS-M2
Post by: dfort on January 24, 2018, 12:56:18 AM
I thought we fixed it too but that EOSM build you pointed to is doing the same thing, locking up the camera on startup. The LED stays lit solid--no read/write activity and requires a battery pull. Startup logs do get saved though.
Title: Re: ML on EOS-M2
Post by: a1ex on January 25, 2018, 11:51:26 PM
If I remember well, the issue was caused by MPU_DELAY_SEND in LiveView; that's why I've redefined it to enable it only outside LV. That works fine on 5D3, even when starting the camera at 60 FPS.

Does it help if you undefine MPU_DELAY_SEND?
Title: Re: ML on EOS-M2
Post by: dfort on January 26, 2018, 02:21:53 AM
Actually, now that I think of it on the EOSM what worked was to start up using the playback button. I made sure to have an image on the card so it won't go into LiveView, pressed playback and everything seems to work without a hitch. Here is the link to the startup log (https://pastebin.com/Az5dKwK1).

[EDIT] I also tried undefining MPU_DELAY_SEND and it worked fine starting up the camera normally into LiveView. This time it created two log files on startup.

DM-0000.LOG (https://pastebin.com/ZDW0TAqM)
DM-0001.LOG (https://pastebin.com/Kx2N94VX)
Title: Re: ML on EOS-M2
Post by: dfort on January 27, 2018, 05:13:10 PM
I have been going through the stubs and constants with a fine toothed comb and made some corrections on the wip branch before getting the pull request started.

One thing that is a problem is that the LiveView keeps freezing up. When shooting a still image it shows, "Raw error, falling back to YUV overlays" so I took a closer look at the YUV addresses (https://bitbucket.org/hudson/magic-lantern/commits/f3afe0d4fd876b27296e422fa246fcc1decd0e56) and found something that I don't understand at all:

src/mem.c
Code: [Select]
static struct { uint32_t addr; char* name; } common_addresses[] = {
    { RESTARTSTART,         "RST"},
    { YUV422_HD_BUFFER_1,   "HD1"},
    { YUV422_HD_BUFFER_1,   "HD2"},
    { YUV422_LV_BUFFER_1,   "LV1"},
    { YUV422_LV_BUFFER_2,   "LV2"},
    { YUV422_LV_BUFFER_3,   "LV3"},
};

Shouldn't the "HD2" line look like this?

Code: [Select]
    { YUV422_HD_BUFFER_2,   "HD2"},

Back to the addresses I'm using, I copied this from the EOSM but it is likely different on the EOSM2:

platform/EOSM2.103/consts.h
Code: [Select]
// http://magiclantern.wikia.com/wiki/ASM_Zedbra
// skipped for now, will come up with a way to autodetect these values
// http://www.magiclantern.fm/forum/index.php?topic=15895.msg186493#msg186493
#define YUV422_HD_BUFFER_1 0x44000080
#define YUV422_HD_BUFFER_2 0x46000080

I read the links but can't quite figure it out. Back on Reply #133 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg187318#msg187318) I posted this QEMU output:

Code: [Select]
   270:  3187.200 [RSC] --- Indev Mode ----
   271:  3187.456 [RSC] [INDVMGR]               0x0
   272:  3187.456 [RSC] YUV                     0x4AEEA000 0x0222C000 35831808
   273:  3187.456 [RSC] YUV_OUT                 0x42000000 0x0222C000 35831808
   274:  3187.712 [RSC] INDV_WORK               0x0 0x00000000 0

Maybe that's a clue to finding the YUV422_HD_BUFFER addresses?

One of the three YUV422_LV_BUFFER addresses was found and mentioned in Reply #87 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg186493#msg186493) but what about the other two? I found out that the addresses on other cameras are offset by 0x410000 so taking a guess at which one of the three addresses was published I came up with this:

platform/EOSM2.103/consts.h
Code: [Select]
// Started out by using the one found value (0x4f3d7800)for all three as a workaround
// then adding 0x410000 to determine the other two.
// http://www.magiclantern.fm/forum/index.php?topic=15895.msg186493#msg186493
#define YUV422_LV_BUFFER_1 0x4F3D7800
#define YUV422_LV_BUFFER_2 0x4F7E7800
#define YUV422_LV_BUFFER_3 0x4FBF7800
Title: Re: ML on EOS-M2
Post by: a1ex on January 27, 2018, 05:23:16 PM
These addresses all visible from the EDMAC channels screenshot (edmac.mo); can be guessed from their size.

When there are more image buffers used, all of them will end up, sooner or later, in the same EDMAC screenshot; keep the down arrow pressed so they will cycle faster.

Back then, we had all sorts of methods to guess them - diff'ing RAM dumps, FFT analysis to find image size, trying to make sense of various display structures... now it's much easier. We may still have to redo some of this low-level stuff for D6, but I don't expect any surprises on D5.
Title: Re: ML on EOS-M2
Post by: dfort on January 27, 2018, 05:54:24 PM
These addresses all visible from the EDMAC channels screenshot (edmac.mo); can be guessed from their size.

Where do we start guessing?

(https://farm5.staticflickr.com/4664/39896753942_0dc0586170.jpg) (https://flic.kr/p/23MxhXY)

(https://farm5.staticflickr.com/4761/39030957065_e647812d37.jpg) (https://flic.kr/p/22t2RHB)
Title: Re: ML on EOS-M2
Post by: a1ex on January 27, 2018, 07:31:22 PM
Here: http://magiclantern.wikia.com/wiki/VRAM/Geometry
or here: http://www.magiclantern.fm/forum/index.php?topic=15233

The LV buffer is 720x480 in most D4/5 cameras (the only exception being 1100D); the HD buffer is usually a bit larger.

(I should get rid of all these hardcoded buffers, as there is at least one camera where their address is not fixed)
Title: Re: ML on EOS-M2
Post by: dfort on January 28, 2018, 07:50:47 AM
The LV buffer is 720x480..

I don't see anything that size on the EDMAC screen. I also checked on the original EOSM and it looks almost identical--no 720x480 sized buffer on the EDMAC list.

Oh wait--1440 is half of 720 so this must be it.

(https://farm5.staticflickr.com/4696/39229104974_4291000054.jpg) (https://flic.kr/p/22LxqbS)

Searching the wiki I came across VRAM ADDR from code (http://magiclantern.wikia.com/wiki/VRAM_ADDR_from_code) which looks very promising. I modified it so it should work with the EOSM2. The only change needed was to find SetBitmapVramAddress which was quite easy:

Code: [Select]
int i;
unsigned int *bmp_ram_addr = bmp_vram_info;
for (i=0; i<2; i++)
  DebugMsg( DM_MAGIC, 3, "bmp_vram[]=0x%08x, 0x%08x, 0x%08x",
    bmp_ram_addr[3*i+0],  bmp_ram_addr[3*i+1], bmp_ram_addr[3*i+2] );
unsigned int *vram_info_addr = vram_info;
for (i=0; i<3; i++)
  DebugMsg( DM_MAGIC, 3, "vram_info[]=0x%08x, w=%4d, h=%4d, p=%4d, n=%4d",
      vram_info_addr[5*i+0],  vram_info_addr[5*i+1],
      vram_info_addr[5*i+2], vram_info_addr[5*i+3], vram_info_addr[5*i+4] );
unsigned int *stateobj_disp = 0x90494+0x128; // see FF137ACC SetBitmapVramAddress
    DebugMsg( DM_MAGIC, 3, "stateobj_disp+0xb0[]=0x%08x,0x%08x,0x%08x,",
    stateobj_disp[0], stateobj_disp[1], stateobj_disp[2]);

The problem is, there's no instructions on where this code goes. At first I tried it in run_test() in debug.c but that didn't work. It seems that it should go here:

vram.c:
Code: [Select]
void vram_init()
{
    menu_add("VRAM", vram_menus, COUNT(vram_menus));
    old_buffer_pos = YUV422_LV_BUFFER_1;
}

// code goes in here

INIT_FUNC(__FILE__, vram_init);
#endif

However, I couldn't get it to display on the console or write to a log. Too bad, the output should provide some of the missing information. This example is from the 550D.109:

Code: [Select]
2109:  9760.005 [MAGIC] bmp_vram[]=0xc0f140d0, 0x00000000, 0x02087100
2110:  9760.045 [MAGIC] bmp_vram[]=0xc0f140d4, 0x00000000, 0x02087100
2111:  9760.082 [MAGIC] vram_info[]=0x40d07800, w= 720, h= 720, p= 480, n=   2
2112:  9760.116 [MAGIC] vram_info[]=0x4c233800, w= 720, h= 720, p= 480, n=   0
2113:  9760.149 [MAGIC] vram_info[]=0x4f11d800, w= 720, h= 720, p= 480, n=   0
2114:  9760.194 [MAGIC] stateobj_disp+0xb0[]=0x42080008,0x40d07800,0x40958c3c,

The more I look into this, the more it seems that this section is correct. In fact checking the EOSM2 side by side with an EOSM it looks like much of this YUV/VRAM stuff is identical on the two cameras.

Whatever is causing the instability issues is probably elsewhere. Checking Free Memory will reboot or even crash the camera when it gets to SRM job total. There are other obvious problems:

(https://farm5.staticflickr.com/4667/39939568831_68bfd185b7.jpg) (https://flic.kr/p/23RjJkH)

[EDIT] Had a screenshot of a lens issue here but I was able to resolve it so I removed the image. Found out that in EOSM2 uses the same prop_lv_lens structure as the 6D and 5D3.123. Didn't expect that, thought it would be the same as the EOSM.

Sorry EOSM2 enthusiasts, this needs some more work before releasing a test build.
Title: Re: ML on EOS-M2
Post by: dfort on January 28, 2018, 07:45:26 PM
I got lucky finding such a simple fix for the lens data issue. Sometimes this camera is more like the 6D than the original EOSM.

Today I thought I'd tackle the shutter issue hoping for a simple solution and that it also resolve some of the other problems--maybe something is using some memory that's messing things up? A while back I put some stuff on the back burner and now that ML is running on the camera it is time to revisit these items.

Code: [Select]
// Get back to this after figuring out how parse_bin.py works
// not used on 700D and 100D so maybe it can wait until adtg_gui is working on EOSM2
//#define FRAME_SHUTTER_BLANKING_ZOOM   (*(uint16_t*)0x40481B20) // ADTG register 805f
//#define FRAME_SHUTTER_BLANKING_NOZOOM (*(uint16_t*)0x40481B24) // ADTG register 8061
//#define FRAME_SHUTTER_BLANKING_READ   (lv_dispsize > 1 ? FRAME_SHUTTER_BLANKING_NOZOOM : FRAME_SHUTTER_BLANKING_ZOOM) /* when reading, use the other mode, as it contains the original value (not overriden) */
//~ #define FRAME_SHUTTER_BLANKING_WRITE  (lv_dispsize > 1 ? &FRAME_SHUTTER_BLANKING_ZOOM : &FRAME_SHUTTER_BLANKING_NOZOOM)
#define LV_DISP_MODE (MEM(0xDF1BC + 0x7C) != 3)

parse_bin.py lives in modules/adtg_log and there is very little documentation on it other than this from commit 8855c9a (https://bitbucket.org/hudson/magic-lantern/commits/8855c9abac4f28d6b13fdcb20bc407cad8a46aa5) on Bitbucket:
Quote
adtg_log: python script to parse binary log file. "parse_bin.py -f TEST.BIN > out.txt"

Which .BIN file are we talking about? I suppose it is ROM1.BIN but when I ran parse_bin.py on it all I got was gibberish that didn't match anything that I saw in the ADTG and CMOS registers (https://www.magiclantern.fm/forum/index.php?topic=6751.0) topic. Lots of talk about the adtg_log module, but I tried several times to compile that module. One small issue seems to be that it is missing this line:

Code: [Select]
#include <beep.h>
However, I'm still getting compile errors even after turning on these options:

Code: [Select]
CONFIG_GDB      = y
CONFIG_GDBSTUB  = y

I also compiled the trace module, looked up where *"[REG] @@@@@@@@@@@@ Start ADTG[CS:%lx:%lx]" is at in the disassembly, ffd60614, but couldn't figure out what to do with that. Ugh, another dead end.

So how about adtg_gui? It works!

(https://farm5.staticflickr.com/4720/39052197085_f7c023e994.jpg) (https://flic.kr/p/22uUHCR)

Plugged in the numbers:

Code: [Select]
#define FRAME_SHUTTER_BLANKING_ZOOM   (*(uint16_t*)0x416D7B7C) // ADTG register 805f
#define FRAME_SHUTTER_BLANKING_NOZOOM (*(uint16_t*)0x416D7B80) // ADTG register 8061
/* when reading, use the other mode, as it contains the original value (not overriden) */
#define FRAME_SHUTTER_BLANKING_READ   (lv_dispsize > 1 ? FRAME_SHUTTER_BLANKING_NOZOOM : FRAME_SHUTTER_BLANKING_ZOOM)
#define FRAME_SHUTTER_BLANKING_WRITE  (lv_dispsize > 1 ? &FRAME_SHUTTER_BLANKING_ZOOM : &FRAME_SHUTTER_BLANKING_NOZOOM)
#define LV_DISP_MODE (MEM(0xDF1BC + 0x7C) != 3)

It works in still photo mode - Yay!

(https://farm5.staticflickr.com/4672/39052388525_fe8a129739.jpg) (https://flic.kr/p/22uVGxx)

But in movie mode--the shutter angle looks right but the shutter speed is alternating between 0.7" and 1.7" which is obviously wrong.

(https://farm5.staticflickr.com/4709/39918558012_dfbeb6ba06.jpg) (https://flic.kr/p/23Pt3yd)

(https://farm5.staticflickr.com/4758/39052384805_21d765730e.jpg) (https://flic.kr/p/22uVFrp)

The camera is still quite unstable but at least the issues are getting resolved one baby step at a time.
Title: Re: ML on EOS-M2
Post by: vagaboundedu on January 29, 2018, 10:31:24 PM
Sorry EOSM2 enthusiasts, this needs some more work before releasing a test build.

Hey, we're just thrilled to see the progress. Very cool!
Title: Re: ML on EOS-M2
Post by: dfort on January 30, 2018, 02:27:11 AM
I've been running the Stubs API test just like Danne is doing on the 1100D (https://www.magiclantern.fm/forum/index.php?topic=1009.msg196504#msg196504). Both the EOSM2 and EOSM are failing on the same tests as the 1100D. Of course that needs to be worked on but I wanted to see which tests are failing and if there was something that might be easier to start with so I tried running one test at a time.

These are the tests that are failing:

Code: [Select]
//        stub_test_malloc_n_allocmem();      stub_test_save_log(); // fails and doesn't save log
//        stub_test_exmem();                  stub_test_save_log(); // fails and doesn't save log

Something that I thought would be easier to debug was the failures in the stub_test_gui:

EOSM2
Code: [Select]
[Pass] is_play_mode() => 0x1
       SetGUIRequestMode(1); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x1
       SetGUIRequestMode(2); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x2
       SetGUIRequestMode(0); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x0
[Pass] display_idle() => 0x1
       GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[Pass] PLAY_MODE => 0x1
[Pass] MENU_MODE => 0x0
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(1000);
[FAIL] MENU_MODE => 0x0
[FAIL] PLAY_MODE => 0x1
[Pass] dialog->type => 'DIALOG'
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[FAIL] PLAY_MODE => 0x1
       SW1(1,100)
[Pass] HALFSHUTTER_PRESSED => 0x1
       SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[FAIL] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x1
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[FAIL] is_pure_play_movie_mode() => 0x1

The EOSM is also failing on some of these:
Code: [Select]
[Pass] is_play_mode() => 0x1
       SetGUIRequestMode(1); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x1
       SetGUIRequestMode(2); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x2
       SetGUIRequestMode(0); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x0
[Pass] display_idle() => 0x1
       GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[Pass] PLAY_MODE => 0x1
[Pass] MENU_MODE => 0x0
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(1000);
[Pass] MENU_MODE => 0x1
[Pass] PLAY_MODE => 0x0
[Pass] dialog->type => 'DIALOG'
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[Pass] PLAY_MODE => 0x0
       SW1(1,100)
[Pass] HALFSHUTTER_PRESSED => 0x1
       SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[FAIL] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x1
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[FAIL] is_pure_play_movie_mode() => 0x1

The 700D passes all of the tests in camera but when I tried the stub_test_gui in QEMU it had similar failures:
Code: [Select]
[Pass] is_play_mode() => 0x1
       SetGUIRequestMode(1); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x1
       SetGUIRequestMode(2); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x2
       SetGUIRequestMode(0); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x0
[Pass] display_idle() => 0x1
       GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[FAIL] PLAY_MODE => 0x0
[Pass] MENU_MODE => 0x0
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(1000);
[FAIL] MENU_MODE => 0x0
[Pass] PLAY_MODE => 0x0
[FAIL] dialog->type => ''
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[Pass] PLAY_MODE => 0x0
       SW1(1,100)
[FAIL] HALFSHUTTER_PRESSED => 0x0
       SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[FAIL] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[FAIL] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0

I checked gui.h on various cameras it looks like most cameras use pretty much the same addresses. I thought that maybe something was different because the EOSM2 (top black camera) has an extra photo mode setting that the EOSM (bottom red camera) doesn't have.

(https://farm5.staticflickr.com/4615/39074665595_7dbdb0a07e.jpg) (https://flic.kr/p/22wTSJX)

However, running the extract_button_codes.py script in QEMU it turns out that both cameras have identical codes.

So is this anything to be concerned about at this point? Seems like I have bigger fish to fry.
Title: Re: ML on EOS-M2
Post by: dfort on January 30, 2018, 05:06:50 AM
Looks like I was a bit impatient - stub_test_malloc_n_allocmem does save a log file but it takes a very long time. The fail is just like the EOSM. I thought that maybe this commit for the 1100D (https://bitbucket.org/hudson/magic-lantern/commits/6e08beeda8d4303bfd04925371fe9c93#comment-5741298) would help but it didn't.

Here's where things go bad on the EOSM2--same place as the EOSM:

Code: [Select]
...
[Pass] ABS(MOD(t1-t0, 1048576)/1000 - 250) => 0x4
       LoadCalendarFromRTC( &now )
       s0 = now.tm_sec => 0x26
       Date/time: 2018/01/29 08:36:38
       msleep(1500)
       LoadCalendarFromRTC( &now )
       s1 = now.tm_sec => 0x28
[Pass] MOD(s1-s0, 60) => 0x2
[Pass] MOD(s1-s0, 60) => 0x2
       m0 = MALLOC_FREE_MEMORY => 0x516c0
[Pass] p = (void*)_malloc(50*1024) => 0x12ecf8
[Pass] CACHEABLE(p) => 0x12ecf8
       m1 = MALLOC_FREE_MEMORY => 0x44eb0
       _free(p)
       m2 = MALLOC_FREE_MEMORY => 0x516c0
[Pass] ABS((m0-m1) - 50*1024) => 0x10
[Pass] ABS(m0-m2) => 0x0
       m0 = GetFreeMemForAllocateMemory() => 0x200014
[Pass] p = (void*)_AllocateMemory(256*1024) => 0xaa72d8
[Pass] CACHEABLE(p) => 0xaa72d8
       m1 = GetFreeMemForAllocateMemory() => 0x1c0008
       _FreeMemory(p)
       m2 = GetFreeMemForAllocateMemory() => 0x200014
[Pass] ABS((m0-m1) - 256*1024) => 0xc
[Pass] ABS(m0-m2) => 0x0
       m01 = MALLOC_FREE_MEMORY => 0x516c0
       m02 = GetFreeMemForAllocateMemory() => 0x200014
[Pass] p = (void*)_alloc_dma_memory(256*1024) => 0x40aa7318
[Pass] UNCACHEABLE(p) => 0x40aa7318
[Pass] CACHEABLE(p) => 0xaa7318
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x40aa7318
       _free_dma_memory(p)
[FAIL] p = (void*)_shoot_malloc(24*1024*1024) => 0x0
[FAIL] UNCACHEABLE(p) => 0x40000000
       _shoot_free(p)
       m11 = MALLOC_FREE_MEMORY => 0x516a0
       m12 = GetFreeMemForAllocateMemory() => 0x1fffbc
[Pass] ABS(m01-m11) => 0x20
[Pass] ABS(m02-m12) => 0x58
[FAIL] p = (void*)_shoot_malloc(24*1024*1024) => 0x0
[FAIL] UNCACHEABLE(p) => 0x40000000
[FAIL] p = (void*)_shoot_malloc(24*1024*1024) => 0x0
[FAIL] UNCACHEABLE(p) => 0x40000000
...
Title: Re: ML on EOS-M2
Post by: a1ex on January 30, 2018, 01:53:02 PM
In QEMU, the Free Memory dialog crashes at srm_malloc_suite - wrong stub?

Code: [Select]
shoot buffer: 4dd16064 ... 4f3ce063
shoot buffer: 4ae00064 ... 4aee8063
shoot buffer: 45f240e4 ... 45ffc0e3
shoot buffer: 44000064 ... 45e88063
srm_malloc_suite(0)...
[MPU] Received: 06 05 04 01 01 00  (PROP_ICU_UILOCK - spell #56)
[MPU] Sending : 06 05 04 01 01 00  (PROP_ICU_UILOCK)
UILock: 00000000 -> 41000001 => 41000001
< Error Exception>
TYPE        : 4
ISR         : 0
TASK IDSR   : 5111821
TASK Name   : RscMgr
Title: Re: ML on EOS-M2
Post by: dfort on January 30, 2018, 07:41:07 PM
How in the world are you running this in QEMU? I can't get to the ML menus at all on the EOSM2, EOSM or 1100D for that matter. Are you getting the same error on the EOSM? I'm getting the same errors on both EOSM and EOSM2. I don't think that I've been ever able to successfully run the Stubs API test from the selftest module on the EOSM so what are the chances of it working on the EOSM2?

Checked ptpPropSetUILock and all of the Memory allocation and ExMem stubs once again and they seem to check out fine. Maybe there's something quirky in one of the stubs? I remember a while back finding something on the 700D that didn't match what was being used on other cameras. Searched for it but couldn't find the discussion. Was it "AbortEDmac" ?
Title: Re: ML on EOS-M2
Post by: a1ex on January 30, 2018, 07:50:04 PM
On 1100D it works out of the box, but uses a different button - look at this picture (http://i.imgur.com/ML5SF.jpg).

On M2, patch handle_ml_menu_erase so it doesn't check for GUISTATE_IDLE, and define BGMT_TRASH as 0xD (probably a button not physically present on the camera). That was the easy coding task mentioned earlier.

What's interesting is that BGMT_TRASH is defined as 04 01 on the MPU side (the raw button code that comes from the MPU) on every single camera model that uses a dedicated button for this function (and most other buttons also have consistent codes). Also, since EOS firmwares appear to be derived from a common codebase, they happen to interpret other button codes correctly as well.

Checked on EOSM - in the Free Memory dialog, shoot_total is only 23MB. Do you get different value on the camera? Even 1100D has 39MB total; the test tries to allocate 35MB (it used to ask for 64MB before the 1100D changes).

On M2, I believe SRM_AllocateMemoryResourceFor1stJob is at FF0E9660 (unless I'm looking at the wrong firmware version :D )
Title: Re: ML on EOS-M2
Post by: dfort on January 30, 2018, 09:11:55 PM
Checked on EOSM - in the Free Memory dialog, shoot_total is only 23MB. Do you get different value on the camera?

That's what I get on the EOSM with the unified build.

EOSM
(https://farm5.staticflickr.com/4628/26117993828_4e55920134.jpg) (https://flic.kr/p/FMXxCq)

On M2, I believe SRM_AllocateMemoryResourceFor1stJob is at FF0E9660 (unless I'm looking at the wrong firmware version :D )

Must have gone over that stub 10 times but now that you point it out... Couldn't get to the Free Memory before that change. Looks pretty close to the original:

EOSM2
(https://farm5.staticflickr.com/4747/28211463849_9bcc9b52f0.jpg) (https://flic.kr/p/JYX8k8)

So is this why the M1 and M2 keep failing the Stubs API test?

On M2, patch handle_ml_menu_erase so it doesn't check for GUISTATE_IDLE, and define BGMT_TRASH as 0xD (probably a button not physically present on the camera). That was the easy coding task mentioned earlier.

You make juggling chainsaws look easy. Ok, you dropped several hints but I still don't quite get how you did it. So it doesn't go into the abyss when you get into LiveView in QEMU? I can never get back to the Canon menu after closing it with the "M" key in QEMU.

Speaking of buttons, so it was like pressing the button for wrong floor on the elevator all this time with the 1100D. BTW, shouldn't commit 4ea94f5 (https://bitbucket.org/hudson/magic-lantern/commits/4ea94f53c0a5908e86e05909c981bce5b944c5eb) from unified be applied to the allocate-raw-lv-buffer branch?
Title: Re: ML on EOS-M2
Post by: a1ex on January 30, 2018, 09:25:12 PM
Yeah, that's what I've got in QEMU as well.

Quote
So it doesn't go into the abyss when you get into LiveView in QEMU?

Of course it does - that's the entire point of this patch, to allow you to open ML menu before entering LiveView (for example, while you are on Canon menu). Will commit it, as I don't expect LiveView emulation anytime soon.
Title: Re: ML on EOS-M2
Post by: platerytter on February 02, 2018, 10:15:59 AM
Late to the party bus but just wanted to chime in with congrats on both birthday and reaching this milestone!
Title: Re: ML on EOS-M2
Post by: a1ex on February 02, 2018, 11:47:52 AM
Finally got the exmem tests working (https://bitbucket.org/hudson/magic-lantern/commits/a9728feef91e1755117eac064e26d01b6e90bbae?at=allocate-raw-lv-buffer) hopefully on all models (tested 1100D, EOSM, EOSM2, 5D4, 6D, 500D, 550D, 700D, all in QEMU). Had to change them a bit to account for the significant variations in available memory. Committed the menu hack (https://bitbucket.org/hudson/magic-lantern/commits/90f702cde5dc45dc112164556fb300ab3045fce7?at=qemu), too.

Incredible how stuff working well on some models fails miserably on others. Then, after fixing it for these others, it fails on the models where it used to work. Rinse, repeat.

Still got stuff to fix, for example the memory benchmarks aren't starting on all models (problem in memory backend - it doesn't know how much free space is in the shoot memory buffer before attempting to allocate from it). Many models are able to allocate 2x16MB from there, but not all.
Title: Re: ML on EOS-M2
Post by: dfort on February 05, 2018, 07:19:40 AM
Just wanted to document where things are at with the EOSM2.

I wanted to surprise everyone by posting some EOSM2 screenshots on the 12-bit (and 10-bit) RAW video development discussion as per Reply #1579 (https://www.magiclantern.fm/forum/index.php?topic=5601.msg196632#msg196632). At first I tried merging the EOSM2 a bit at a time into the allocate-raw-lv-buffer branch just to see what it would be like to cherry pick from the wip branch but ran into some problems and the camera wouldn't start up so I ended up merging the branches and it worked. Sort of. The important part of the test is switching video modes and it obviously isn't working yet. Maybe it needs a different edmac channel or something like that?

(https://farm5.staticflickr.com/4656/25220150897_f45b2d53b4.jpg) (https://flic.kr/p/EqBScT)

There's definitely something fishy going on because when leaving the ML menu sometimes LiveView is stuck on a still frame and/or the ML overlays won't come back. There is also some noise every once in a while on the ML menus. This is something I've seen before on a very early 100D build. What I haven't seen before is the shutter speed flicking to different values in movie mode. This is something I pointed out before (https://www.magiclantern.fm/forum/index.php?topic=15895.msg196476#msg196476).

(https://farm5.staticflickr.com/4758/39052384805_21d765730e.jpg) (https://flic.kr/p/22uVFrp)

[EDIT] This is probably related - the FPS override flips between a couple of values even though it isn't active:

(https://farm5.staticflickr.com/4657/39382323234_a91304fcc2.jpg) (https://flic.kr/p/2315GD1)

(https://farm5.staticflickr.com/4748/25221756357_180f1ec643.jpg) (https://flic.kr/p/EqL6se)

I think that I should resolve these issues before moving on. I was able to do this which might help:

You can include dm-spy-experiments in your current wip branch and use it for reverse engineering (understanding how things work). This branch breaks things on some cameras...so let's not include this one in the PR yet.


So I currently have three branches, allocate-raw-lv-buffer, dm-spy-experiments and of course the main work in progress branch. I think the issues noted above should be fixed before moving on to the pull request branch. Paraphrasing the instructions for the PR build:

new-dryos-task-hooks..., qemu, lua_fix... I think it's best to start a clean branch starting from unified, with the first 3 branches merged.

You could also consider including 100D, which is very similar to EOSM2 and also waits for the first 3 backends to reach the mainline (otherwise it's pretty much ready)...

I'm kind of not sure what to tweak in order to get the camera to do something useful. I mean ML is running on the camera but I can't take any pictures or record video with it. I could post a build for testers--call it the tits on a bull build? Just kidding of course but I could use a hint or two.
Title: Re: ML on EOS-M2
Post by: a1ex on February 05, 2018, 09:26:32 AM
Generic stuff: if it interferes with some Canon feature (such as, not being able to capture images, or unexplained crashes or whatever), and you have no idea where to start looking, try going back to Hello World (i.e. no user tasks started). Did that work? Narrow down by not starting some of our tasks (trial and error). Found the task? Narrow down there (avoid executing all the stuff).

Does it work after disabling the task dispatch hook? Likely some important GUI event gets blocked (incorrectly) by our code. Find out which one (again, trial and error - maybe by commenting out some or all event handlers in gui-common.c). Still no luck? Use only our GUI task, without calling any of our event handlers - take the "if (magic_is_off())" code path in gui.c. Once it's working, start enabling things to see where it breaks.

Shutter not displayed correctly? Find out where it's displayed (look for strings) -> in movie mode, this will use get_current_shutter_reciprocal_x1000. There you'll get a couple of methods - ideally it should be read directly from ADTG registers, as this value is used to configure the hardware, and likely to be the most accurate value we can get (http://www.magiclantern.fm/forum/index.php?topic=16814.msg164062#msg164062); the others are just guesswork for models where this doesn't work yet (todo: remove them, maybe keep the others only as documentation). Double check the stubs / consts used by that code.
Title: Re: ML on EOS-M2
Post by: dfort on February 06, 2018, 07:08:54 AM
Just a few quick tests.

Hello World works fine in both minimal builds and regular builds.

Not sure how not to start tasks or where the task list is located but I did comment out some of the features in all_features.h and found out that without FEATURE_GLOBAL_DRAW the camera will shoot stills and record H.264. Same thing with commenting out "task_dispatch_hook = my_task_dispatch_hook;" in boot-hack.c but then I couldn't get into the ML menu.

One baby step I took was finding this:

Code: [Select]
SRM_BUFFER_SIZE 0x1F24000
That reminds me--shouldn't all of the known SRM_BUFFER_SIZE values be entered into the crop_rec_4k branch? I believe we have values for all cameras but they are spread out all over various forum posts.

[EDIT] Maybe these screenshots of the Debug "Show tasks" screens might help?

(https://farm5.staticflickr.com/4766/39399564914_a9904c7f06.jpg) (https://flic.kr/p/232B4Zm)

(https://farm5.staticflickr.com/4753/39212416075_d9696f0e22.jpg) (https://flic.kr/p/22K4Tae)
Title: Re: ML on EOS-M2
Post by: dfort on February 06, 2018, 09:42:07 PM
Took another look in consts.h and one thing that was questionable was the values of YUV422_LV_BUFFER_1,2,3. One of the buffers was found in QEMU (https://www.magiclantern.fm/forum/index.php?topic=15895.msg186493#msg186493) but is this buffer 1, 2 or 3? The buffers on other Digic 5 cameras are spaced 0x410000 apart so I did this.

Code: [Select]
// Started out by using the one found value (0x4f3d7800)for all three as a workaround
// then adding 0x410000 to determine the other two.
// http://www.magiclantern.fm/forum/index.php?topic=15895.msg186493#msg186493
#define YUV422_LV_BUFFER_1 0x4F3D7800
#define YUV422_LV_BUFFER_2 0x4F7E7800
#define YUV422_LV_BUFFER_3 0x4FBF7800

Is this correct? First I checked to see if something obvious happens if I just put in bogus values. Yes, the histogram stops working. Next I tired each of the addresses for all of the buffers and they all worked. That is, the histogram worked. Finally, I took the address that was found, subtracted 0x410000 and the histogram stopped working. So now I'm pretty sure these are correct, but what about the order? Does that make any difference? The EOSM has the buffer addresses listed in ascending order (1,2,3) but what about the other cameras?

Code: [Select]
EOSM    1,2,3
700D    2,1,3
6D      2,3,1
650D    2,1,3
100D    2,1,3
5D3.113 1,2,3
5D3.123 3,2,1,4 (quad buffered)

Searching the forum I found this post (https://www.magiclantern.fm/forum/index.php?topic=2602.msg17123#msg17123) and this one (https://www.magiclantern.fm/forum/index.php?topic=5071.msg30260#msg30260) that talks about YUV422_LV_BUFFER and it looks like the first buffer is treated differently from the other two.

This didn't bring me any closer to resolving the issues that currently plague the EOSM2 but thought these observations were curious enough to post.
Title: Re: ML on EOS-M2
Post by: dfort on February 07, 2018, 07:36:07 AM
I kept going over and over the stubs and it seemed like they were correct. One thing I did to make it easier to find in the disassembly was to write some of them like this:

Code: [Select]
#define CURRENT_GUI_MODE (*(int*)(0x92860+0x5C)) // in SetGUIRequestMode

This shouldn't make a difference but it allowed the lua test to complete instead of getting stuck when it tried to switch to LiveView.

Code: [Select]
#define CURRENT_GUI_MODE (*(int*)0x928BC) // in SetGUIRequestMode (0x92860+0x5C)

Here is the first complete lua api test:

Code: [Select]
===============================================================================
ML/SCRIPTS/API_TEST.LUA - 2018-2-6 11:20:00
===============================================================================

Strict mode tests...
Strict mode tests passed.

Generic tests...
camera = table:
  shutter = table:
    raw = 96
    apex = 5
    ms = 31
    value = 0.03125
  aperture = table:
    raw = 40
    apex = 4
    value = 4
    min = table:
      raw = 24
      apex = 2
      value = 2
    max = table:
      raw = 80
      apex = 9
      value = 22.6
  iso = table:
    raw = 72
    apex = 5
    value = 100
  ec = table:
    raw = 0
    value = 0
  flash_ec = table:
    raw = 0
    value = 0
  kelvin = 6500
  mode = 20
  metering_mode = 5
  drive_mode = 0
  model = "Canon EOS M2"
  model_short = "EOSM2"
  firmware = "1.0.3"
  temperature = 196
  state = 0
  shoot = function: p
  bulb = function: p
  reboot = function: p
event = table:
  pre_shoot = nil
  post_shoot = nil
  shoot_task = nil
  seconds_clock = nil
  keypress = nil
  custom_picture_taking = nil
  intervalometer = nil
  config_save = nil
console = table:
  write = function: p
  hide = function: p
  clear = function: p
  show = function: p
lv = table:
  enabled = true
  paused = false
  running = true
  zoom = 1
  pause = function: p
  stop = function: p
  start = function: p
  resume = function: p
  wait = function: p
  info = function: p
lens = table:
  name = "EF-M22mm f/2 STM"
  focal_length = 22
  focus_distance = 190
  hyperfocal = 6412
  dof_near = 186
  dof_far = 193
  af = true
  af_mode = 0
  focus = function: p
display = table:
  idle = false
  height = 480
  width = 720
  line = function: p
  circle = function: p
  on = function: p
  off = function: p
  load = function: p
  clear = function: p
  notify_box = function: p
  rect = function: p
  draw = function: p
  pixel = function: p
  screenshot = function: p
  print = function: p
key = table:
  last = 0
  press = function: p
  wait = function: p
menu = table:
  visible = false
  new = function: p
  block = function: p
  set = function: p
  open = function: p
  get = function: p
  close = function: p
testmenu = userdata:
  value = 0
  name = "Script API tests"
  help = "Various tests for the Lua scripting API."
  help2 = "When adding new Lua APIs, tests for them should go here."
  advanced = 0
  depends_on = 0
  edit_mode = 0
  hidden = false
  icon_type = 5
  jhidden = false
  max = 0
  min = 0
  selected = true
  shidden = false
  starred = false
  submenu_height = 0
  submenu_width = 0
  unit = 0
  works_best_in = 0
  run_in_separate_task = 0
  select = function: p
  update = nil
  info = nil
  rinfo = nil
  warning = nil
movie = table:
  recording = false
  stop = function: p
  start = function: p
dryos = table:
  clock = 20
  ms_clock = 20650
  prefix = "IMG_"
  dcim_dir = table:
    exists = true
    create = function: p
    children = function: p
    files = function: p
    parent = table:
      exists = true
      create = function: p
      children = function: p
      files = function: p
      parent = table:
        exists = true
        create = function: p
        children = function: p
        files = function: p
        parent = nil
        path = "B:/"
      path = "B:/DCIM/"
    path = "B:/DCIM/100CANON/"
  config_dir = table:
    exists = true
    create = function: p
    children = function: p
    files = function: p
    parent = table:
      exists = true
      create = function: p
      children = function: p
      files = function: p
      parent = table:
        exists = true
        create = function: p
        children = function: p
        files = function: p
        parent = nil
        path = "B:/"
      path = "ML/"
    path = "ML/SETTINGS/"
  ml_card = table:
    cluster_size = 32768
    drive_letter = "B"
    file_number = 7211
    folder_number = 100
    free_space = 31112864
    type = "SD"
    _card_ptr = userdata
    path = "B:/"
  shooting_card = table:
    cluster_size = 32768
    drive_letter = "B"
    file_number = 7211
    folder_number = 100
    free_space = 31112864
    type = "SD"
    _card_ptr = userdata
    path = "B:/"
  date = table:
    sec = 2
    min = 20
    month = 2
    yday = 37
    isdst = false
    hour = 11
    day = 6
    year = 2018
    wday = 3
  call = function: p
  remove = function: p
  directory = function: p
interval = table:
  time = 10
  count = 0
  running = 0
  stop = function: p
battery = table:
function not available on this camera
stack traceback:
[C]: in ?
[C]: in for iterator 'for iterator'
ML/SCRIPTS/LIB/logger.lua:125: in function 'logger.serialize'
ML/SCRIPTS/API_TEST.LUA:30: in function <ML/SCRIPTS/API_TEST.LUA:29>
[C]: in function 'xpcall'
ML/SCRIPTS/API_TEST.LUA:29: in function 'print_table'
ML/SCRIPTS/API_TEST.LUA:75: in function 'generic_tests'
ML/SCRIPTS/API_TEST.LUA:634: in function 'api_tests'task = table:
  yield = function: p
  create = function: p
property = table:
Generic tests completed.

Module tests...
Copy test: autoexec.bin -> tmp.bin
Copy test OK
Append test: tmp.txt
Append test OK
Testing exposure settings, module 'camera'...
Camera    : Canon EOS M2 (EOSM2) 1.0.3
Lens      : EF-M22mm f/2 STM
Shoot mode: 20
Shutter   : Ç30 (raw 96, 0.03125s, 31ms, apex 5)
Aperture  : Å4.0 (raw 40, f/4, apex 4)
Av range  : Å2.0..Å22 (raw 24..80, f/2..f/22.6, apex 2..9)
ISO       : 100 (raw 72, 100, apex 5)
EC        : 0.0 (raw 0, 0 EV)
Flash EC  : 0.0 (raw 0, 0 EV)
Please switch to M mode.
Setting shutter to random values...
Setting ISO to random values...
Setting aperture to random values...
Please switch to Av mode.
Setting EC to random values...
Setting Flash EC to random values...
Exposure tests completed.

Testing module 'lv'...
Starting LiveView...
Setting zoom to x1...
Setting zoom to x5...
Setting zoom to x10...
Setting zoom to x5...
Setting zoom to x1...
Setting zoom to x10...
Setting zoom to x1...
Pausing LiveView...
Resuming LiveView...
Stopping LiveView...
LiveView tests completed.

Focus distance: 170
Focusing backward...
Focus distance: 655350
Focusing forward with step size 3, wait=true...
...
Focus distance: 140
Focusing backward with step size 3, wait=true...
................
Focus distance: 655350
Focus range: 173 steps forward, 16 steps backward.
Focusing forward with step size 3, wait=false...
...
Focus distance: 655350
Focusing backward with step size 3, wait=false...

Focus distance: 655350
Focus range: 3 steps forward, 0 steps backward.
Focusing forward with step size 2, wait=true...

Focus distance: 655350
Focusing backward with step size 2, wait=true...

Focus distance: 655350
Focus range: 0 steps forward, 0 steps backward.
Focusing forward with step size 2, wait=false...

Focus distance: 655350
Focusing backward with step size 2, wait=false...

Focus distance: 655350
Focus range: 0 steps forward, 0 steps backward.
Focusing forward with step size 1, wait=true...

Focus distance: 655350
Focusing backward with step size 1, wait=true...

Focus distance: 655350
Focus range: 0 steps forward, 0 steps backward.
Focusing forward with step size 1, wait=false...

Focus distance: 655350
Focusing backward with step size 1, wait=false...

Focus distance: 655350
Focus range: 0 steps forward, 0 steps backward.
Focus test completed.

Done!
Title: Re: ML on EOS-M2
Post by: dfort on February 07, 2018, 09:23:40 PM
More tinkering without resolving anything.

The shutter speed / shutter angle display issue seems to be pointing to a problem here:

platform/EOSM2.103/consts.h
Code: [Select]
#define VIDEO_PARAMETERS_SRC_3 MEM(0x91CD4) // (0x91CC8+0xC)
#define FRAME_ISO (*(uint8_t*)(VIDEO_PARAMETERS_SRC_3+0))
#define FRAME_APERTURE (*(uint8_t*)(VIDEO_PARAMETERS_SRC_3+1))
#define FRAME_SHUTTER (*(uint8_t*)(VIDEO_PARAMETERS_SRC_3+2))
#define FRAME_SHUTTER_TIMER (*(uint16_t*)(VIDEO_PARAMETERS_SRC_3+6))
#define FRAME_BV ((int)FRAME_SHUTTER + (int)FRAME_APERTURE - (int)FRAME_ISO)

I'm pretty sure the VIDEO_PARAMETERS_SRC_3 is correct. I printed it out using this:

Code: [Select]
NotifyBox(10000, "VIDEO_PARAMETERS_SRC_3 0x%x", VIDEO_PARAMETERS_SRC_3);

And got 0x6FEC3C. So, that should be the FRAME_ISO, next is the FRAME_APERTURE at 0x6FEC3D, etc... Now how to verify that it is working properly? IDK. The 5D3 uses the same method to find VIDEO_PARAMETERS_SRC_3 but the constants are offset by different amounts. Since I was willing to try anything I used the offsets from the 5D3 and got the same (wrong) results for the shutter speed and correct shutter angle when the camera is in movie mode. Figured how to get it to use the "fallback to APEX units" method in src/fps-engio.c and it displayed the right shutter speed but the wrong shutter angle. Ugh.

In my previous post I was able to get the lua api test working but it didn't resolve the issue of the ML overlays disappearing and getting the "Raw error, falling back to YUV overlays" error message when taking a picture.

Oh yeah, no audio meters either. Still not ready for testers--unless someone wants to see their EOSM2 print "Hello World" on the screen.
Title: Re: ML on EOS-M2
Post by: pureaxis on February 07, 2018, 10:11:45 PM
Registered to voice support! Eagerly awaiting release!  :)
Title: Re: ML on EOS-M2
Post by: dfort on February 14, 2018, 07:50:45 AM
Got the adtg_gui module working so I thought I'd try finding the values needed for Dual ISO. It was fairly easy to check the registers on the 700D (https://www.magiclantern.fm/forum/index.php?topic=7139.msg197238#msg197238) but on the EOSM and EOSM2 I can't seem to be able to get into photo mode. Is there any way to show "ShootCapture" in adtg_gui on these cameras?
Title: Re: ML on EOS-M2
Post by: a1ex on February 14, 2018, 11:18:08 AM
There is an option to disable logging in LiveView (Advanced menu); IIRC it was written with the EOS M in mind.
Title: Re: ML on EOS-M2
Post by: dfort on February 15, 2018, 02:58:06 AM
Thanks -- found that the disable logging feature is in the iso-research branch version of adtg_gui. It took me several tries to get the EOSM2 working on that branch but I did it. Well, it sort of works. Taking a still photo will reboot the camera. Haven't figured that one out. Managed to to get FRSP working just enough to find the address needed for dual_iso PHOTO_CMOS_ISO_START but the DNG was ng.

Still very much a work in progress but it has started sprouting branches!

[EDIT] When taking a still photo it sometimes reboots the camera, crashes or the ML overlays don't return. In all cases it shows the "Raw error, falling back to YUV overlays" message but no log file is saved. Any hints on where to start looking for this issue?

(https://farm5.staticflickr.com/4678/39562907944_d2d4592b56.jpg) (https://flic.kr/p/23h3fbu)
Title: Re: ML on EOS-M2
Post by: a1ex on February 16, 2018, 12:15:57 AM
The reason for "raw error" messages is printed to the console if you enable RAW_DEBUG in raw.c (maybe some more of these messages should be printed by default). There are a few possible reasons for this error.
Title: Re: ML on EOS-M2
Post by: dfort on February 16, 2018, 01:22:45 AM
Thanks, I'll check into that.

One thing I've been trying is to vary these values and was able to change the time between starting the camera and LiveView freezing.

platform/EOSM2.103/include/platform/state-object.h
Code: [Select]
#define DISPLAY_STATE DISPLAY_STATEOBJ
#define INPUT_SET_IMAGE_VRAM_PARAMETER_MUTE_FLIP_CBR 23 // need to verify
#define INPUT_ENABLE_IMAGE_PHYSICAL_SCREEN_PARAMETER 24 // need to verify

Searched but couldn't find anything that explains how to set these values.
Title: Re: ML on EOS-M2
Post by: dfort on February 16, 2018, 02:08:45 AM
Ok, did this:

Code: [Select]
#define RAW_DEBUG        /* define it to help with porting */

and when taking a still photo with the console open it doesn't print any debug information but when I closed the console and shot another still it opened the console and printed:

Code: [Select]
...
Modules loaded
Save configs . . .
Save configs . . .
raw update update from lv_playback
Photo raw size error

Note that the message won't print if the console is already open. It needs to be closed in order to get this message. Restarting the camera it prints this:

Code: [Select]
...
Modules loaded
raw update from livev_hiprio_task
LV RAW size too small
raw update from livev_hiprio_task
LV RAW size too small
...

That message is repeated 5 times.

Searched for livev_hiprio_task and found it in zebras.c so I tried it again with Zebras turned off and got the same results. Turned off Global Draw and no debug messages. Though that's maybe because the console doesn't show up if Global Draw is off?
Title: Re: ML on EOS-M2
Post by: dfort on February 20, 2018, 03:03:22 PM
Did some more debugging. Added this line to see what is going on.

Code: [Select]
        /* the raw edmac might be used by something else, and wrong numbers may be still there */
        /* e.g. 5D2: 1244x1, obviously wrong */
        if (width < 320 || height < 160)
        {
            dbg_printf("LV RAW size too small\n");
+           dbg_printf("width x height = %d x %d\n", width,height);
            return 0;
        }

Looks like the height is ok but the width is way off:

Code: [Select]
raw update from livev_hiprio_task
LV RAW size too small
width x height = -16 x 727
Title: Re: ML on EOS-M2
Post by: a1ex on February 20, 2018, 08:10:53 PM
This one is puzzling. Does the code actually read registers 0xC0F06800 and 0xC0F06804? (from what I could tell from the source, it should). Can you print the raw values of top_left and bot_right?

The 727 was manually set, so the code followed the top half (CONFIG_EDMAC_RAW_SLURP) of raw_lv_get_resolution. The above registers appear to be set to expected values in Canon code (e.g. 0x10013 and 0x4A701D7 near A8468, sub_62BD0 => 1808x1190). Are they overwritten anywhere else? (adtg_gui and io_trace should be able to tell). Does anything in ML code interfere? Try reading them from the minimal codebase.

Code: [Select]
uint32_t top_left  = shamem_read(0xC0F06800);
uint32_t bot_right = shamem_read(0xC0F06804);
char msg[64];
snprintf(msg, sizeof(msg), "%x %x", top_left, bot_right); // copy it from stdio.c
font_draw(..., msg);   
Title: Re: ML on EOS-M2
Post by: dfort on February 21, 2018, 01:25:18 AM
One step at a time:

Can you print the raw values of top_left and bot_right?

EOSM2.103
Code: [Select]
top_left = 4
bot_right = 0

width x height = -16 x 727

This can't be right. Checking the original:

EOSM.202
Code: [Select]
top_left = 65552
bot_right = 77988308

width x height = 1808 x 1189

Interesting, that's the mv1080 buffer size for the EOSM.
Title: Re: ML on EOS-M2
Post by: dfort on February 21, 2018, 03:59:13 AM
Think I stumbled on the next step.

Copied the snprintf code from stdio.c and put it into src/minimal.c then I did this:

Code: [Select]
static int
my_init_task(int a, int b, int c, int d)
{
    init_task(a,b,c,d);
   
    /* wait for display to initialize */
    while (!bmp_vram_info[1].vram2)
    {
        msleep(100);
    }

    while(1)
    {
        MEM(CARD_LED_ADDRESS) = LEDON;
        msleep(500);
        MEM(CARD_LED_ADDRESS) = LEDOFF;
        msleep(500);
       
//        font_draw(100, 75, COLOR_WHITE, 3, "Hello, World!");

        uint32_t top_left  = shamem_read(0xC0F06800);
        uint32_t bot_right = shamem_read(0xC0F06804);
        char msg[64];
        snprintf(msg, sizeof(msg), "%x %x", top_left, bot_right); // copy it from stdio.c
        font_draw(100, 75, COLOR_WHITE, 3, msg);   

    }
   
    return 0;
}

Compiled from the minimal/EOSM2 directory.

I had to shoot a video of the screen to see what was going on. At startup it would show "1 40020000" then it would write over the 1 and the 4 without clearing the screen so the numbers are superimposed and illegible. When turning off the camera it would show "4 0" so perhaps that's what was superimposed?

Ran the same test on the EOSM and it displayed "10010 4a601d4" without superimposing any other value over it so maybe I did run the test properly? This matches the decimal values for the top_left = 65552 bot_right = 77988308 found on the previous test.
Title: Re: ML on EOS-M2
Post by: a1ex on February 21, 2018, 12:54:03 PM
Okay, somebody (some Canon code) must be overwriting the value; adtg_gui can tell what happened, but it requires some fiddling (it won't do so out of the box - too many registers out there); a better tool for diagnosing this would be io_trace (https://www.magiclantern.fm/forum/index.php?topic=2388.msg196941#msg196941) (monitored range: 0xC0F06000, 0x1000).
Title: Re: ML on EOS-M2
Post by: dfort on February 21, 2018, 02:05:23 PM
Startup log with io-trace monitored range: 0xC0F06000, 0x1000

https://pastebin.com/jEzAy9cv

Hope this works. The EOSM2 needs to be started in "Play" mode. Normal startup in LV will not boot and no log is saved.

Makefile.user
Code: [Select]
CONFIG_DEBUG_INTERCEPT_STARTUP = y
CONFIG_MMIO_TRACE=y

[EDIT] Saved another startup log. This time starting the camera in "Play" mode and immediately switching to LV using a half-shutter press. Log looks different but I don't see any C0F06800 or C0F06804 events.

https://pastebin.com/1Tjieg03

[EDIT 2] Discovered there was a second log saved when the camera switched from Play to LV--still no C0F06800 or C0F06804 events.

https://pastebin.com/06LvGwxu

[EDIT 3] Just realized that I didn't save the changed to io_trace.c so I ran another startup log.

https://pastebin.com/4JT7uF9T

Code: [Select]
static ASM_VAR uint32_t protected_region = REGION(0xC0F06000, 0x1000);
Title: Re: ML on EOS-M2
Post by: a1ex on February 21, 2018, 02:31:23 PM
All these logs show the GPIO range. The log has to be captured in LiveView; otherwise it won't be useful. Starting from PLAY mode is OK as long as it also goes to LiveView. Starting from LiveView may or may not be useful, depending on where this register is set. Starting into a video mode with lower FPS may help (don't start into 60p).

Lock-ups are hard to debug - some hints here (https://www.magiclantern.fm/forum/index.php?topic=2388.msg196991#msg196991).

The io_trace_full branch (https://www.magiclantern.fm/forum/index.php?topic=2388.msg197313#msg197313) might also help, but for small ranges like this, I wouldn't expect major improvements.
Title: Re: ML on EOS-M2
Post by: dfort on February 21, 2018, 03:02:19 PM
Ok -- let's start with a clean slate. Merged EOSM2 into the io_trace_full branch and made sure to save the changes to monitored range: 0xC0F06000, 0x1000. This time I started in 1080/24 movie mode in LV and waited a long time, it never completed startup but it did save a couple of startup logs:

DM-0000.LOG (https://pastebin.com/y3K8w9J1) DM-0001.LOG (https://pastebin.com/cEjCB8sy)
Title: Re: ML on EOS-M2
Post by: a1ex on February 21, 2018, 03:51:00 PM
Comment out all the "extra" stuff (calls to dm_spy_extra_install/uninstall) and only record a small subset of the messages (for example, those starting with 'e' from 'evf'). The default set is too verbose to cover the entire LiveView startup (and the overhead of all these messages might be too large). Also, keep in mind CONFIG_DEBUG_INTERCEPT_STARTUP is not compatible with CONFIG_MMIO_TRACE in the io_trace_full branch (the main reason it's yet another branch). Only plain CONFIG_DEBUG_INTERCEPT works there (with manual selection from menu).

The message filtering is done in my_DebugMsg, somewhere at the beginning:
Code: [Select]
    if (fmt[0] != 'e') return;

You could also write small test sequences, such as:
Code: [Select]
static void run_test()
{
    msleep(1000);
    SetGUIRequestMode(GUIMODE_PLAY); // go to PLAY mode
    msleep(1000);
    debug_intercept();     // start logging
    SetGUIRequestMode(0);  // back to LiveView
    msleep(1000);
    debug_intercept();     // stop logging
}
Title: Re: ML on EOS-M2
Post by: dfort on February 21, 2018, 07:46:54 PM
Followed your instructions and also added:

debug.c
Code: [Select]
#include "dm-spy.h"
but I'm getting:

Code: [Select]
[ LD       ]   magiclantern
debug.o: In function `run_test':
/Users/rosiefort/magic-lantern/platform/EOSM2.103/../../src/debug.c:290: undefined reference to `debug_intercept'
/Users/rosiefort/magic-lantern/platform/EOSM2.103/../../src/debug.c:293: undefined reference to `debug_intercept'
io_trace.o: In function `io_trace_log_message':
/Users/rosiefort/magic-lantern/platform/EOSM2.103/../../src/io_trace.c:451: undefined reference to `debug_format_msg'
make: *** [magiclantern] Error 1

debug_intercept and debug_format_msg are defined in dm-spy.h. io_trace.c already includes dm-spy.h

Can't seem to be able to get past this.

[EDIT] Never mind -- only "CONFIG_DEBUG_INTERCEPT = y" is compatible with this, right? I had "CONFIG_DEBUGMSG = y" selected by mistake.
Title: Re: ML on EOS-M2
Post by: a1ex on February 21, 2018, 07:49:03 PM
CONFIG_DEBUG_INTERCEPT=y and CONFIG_MMIO_TRACE=y in Makefile.user? Also, make clean?
Title: Re: ML on EOS-M2
Post by: dfort on February 21, 2018, 08:22:26 PM
I was almost ready to give up but finally got it running. I couldn't get into the ML menus in movie mode but look at this in photo mode:

(https://farm5.staticflickr.com/4696/39509115885_dd2f29825f.jpg) (https://flic.kr/p/23chxFc)

Screeenshot from the Debug menu only created black images.

Here is the log created from the "Don't click me!" code:

https://pastebin.com/08uQPXaZ
Title: Re: ML on EOS-M2
Post by: a1ex on February 21, 2018, 08:26:18 PM
Ouch, these pixels over the screen don't look good at all.

The bottom bar hack can be commented out from internals.h (it's not needed for the log).

The extra loggers are still there, and very verbose; comment them out.
Title: Re: ML on EOS-M2
Post by: nikfreak on February 21, 2018, 08:43:40 PM
I remember this "dirty" pixels and this is what fixed it for me on early stages of 100D porting:

https://bitbucket.org/hudson/magic-lantern/pull-requests/757/adding-support-for-the-eos-100d-sl1/diff#Lsrc/bmp.cT81

Check bmp.c:

Quote
.....// This fixes "dirty" LCD output for 100D
Title: Re: ML on EOS-M2
Post by: dfort on February 21, 2018, 08:46:40 PM
Having one of those days. Realized that one of my files wasn't saved as I was cleaning up so I saved, recompiled and got a much smaller log in photo mode:

https://pastebin.com/3y5zcwRt

This was before your reply came in so I went ahead and did a second attempt turning off the bottom bar hack. Couldn't get into the ML menus in photo mode so I did this one in movie mode. Somewhat different but at least that error isn't showing up.

https://pastebin.com/w78M6RYH

Yeah, ouch. Thanks nikfreak - I remember seeing those pixels on DeafEyeJedi's camera with an early 100D build. Thanks for the tip.
Title: Re: ML on EOS-M2
Post by: a1ex on February 21, 2018, 09:36:11 PM
Code: [Select]
0.027.660         Evf:ff2c6f58:MMIO : [0xC0F06800] <- 0x00010013
0.027.661         Evf:ff2c6f58:MMIO : [0xC0F06804] <- 0x02D801D7

These values are OK, both set from engio_write. I could not find other instances. What happened to the shadow memory, then?!

Generally, ENGIO registers cannot be read back directly (with very few exceptions), so Canon code also writes their value into RAM (possibly to read them back later, or for debugging). On M2, this shadow memory is at 0x9696C -> 0x412a0000, and a register is written there like this:
Code: [Select]
*reg = value;
*(reg & 0x3FFFF | shadow_addr) = value;

In other words, the value written into register 0xC0F06800 would be also written to memory at 0x412a6800.

We've got a problem: 0x412a0000 & 0x3FFFF is not 0. The value written to 0xC0F26800 (EDMAC channel 0x18) will be also written to the same memory address, at 0x412a6800. When reading this back, we'll get whatever was written last (of these two registers).

It's the first model I'm aware of with this problem. 5D3 has the shadow memory at 0x29C04 -> 0x41700000. 700D: 0x31708 -> 0x41400000. For other models, the value can be found in gdb+qemu; I didn't even think about it until now, since it just worked.

Can these registers be read directly from hardware? (answer: no - they won't crash, but they will return just 0 or 1)

BTW, this probably means the ENGIO register range is from 0xC0F00000 to 0xC0F3FFFF ("only" 65536 registers?) and the other ranges are not meant to be written with these routines (engio_write / EngDrvOut). I should enforce this in the code.



Stack trace to see where this shadow memory is allocated:
Code: [Select]
0x35F20(6109f0 &"StageClass", 35f20, 19980218, 19980218)                         at [ShootCapture:ca14:19dfc8] (pc:sp)
 0xFF0D38C0(406108e8 &"ShootCapture", 0, ff0c5724, 40000)                        at [ShootCapture:35f7c:19dfa0] (pc:sp)
  0x3637C(61096c &"StateObject", 406108e8 &"ShootCapture", 0, ff0c5724)          at [ShootCapture:ff0d38ec:19df88] (pc:sp)
   0x363B4(61096c &"StateObject", 406108e8 &"ShootCapture", 0, ff0c5724)         at [ShootCapture:363ac:19df78] (pc:sp)
    0xFF1567B4(406108e8 &"ShootCapture", ff0c5724, 40000, ff1567b4)              at [ShootCapture:36434:19df58] (pc:sp)
     0xFF23398C(412a0000, 44000, 1, ff1567b4)                                    at [ShootCapture:ff156810:19df20] (pc:sp)
      0xFF4ADB84(412a0000, 44000, 1, 0)                                          at [ShootCapture:ff2339cc:19dee0] (pc:sp)
       0xFF2C6BE8(412a0000, 44000, 1, 0)                                         at [ShootCapture:ff4adb8c:19ded8] (pc:sp)

Size appears hardcoded to 0x44000 (so, 412a0000 - 0x412e4000). Doesn't help much. Can be found on the RscMgr memory map (https://www.magiclantern.fm/forum/index.php?topic=5071.msg186874#msg186874) as well:
Code: [Select]
ENGINE_MIRROR           0x412A0000 0x00044000 278528

We might be able to find another buffer (https://www.magiclantern.fm/forum/index.php?topic=5601.msg196632#msg196632) for this.
Title: Re: ML on EOS-M2
Post by: dfort on February 21, 2018, 10:15:48 PM
Figures I'd pick the problem camera. Let me know what tests to run.

@nikfreak -- Your tip worked. No more dirty pixels!
Title: Re: ML on EOS-M2
Post by: a1ex on February 22, 2018, 06:27:21 AM
We have 3 ways to proceed:

1) hardcode the resolutions (and get bitten by this Canon bug in other parts of the code)
2) reallocate this buffer from somewhere else (where?)
3) patch ENGIO routines to use ADD instead of ORR, to make them able to work on unaligned buffers

I'd try the last route first. These addresses are:
Code: [Select]
FF2C6C40 (in EngDrvOut)
FF2C6CD8 (in EngDrvIn)
FF2C6D30 (in EngDrvBits)
FF2C6D3C not
FF2C6DA4 (in EngDrvOuts)
FF2C6F64 ORRNE (in engio_write)
FF2C6F94 (in EngDrvOut_mirror)
FF2C6FC4 (in EngDrvBits_mirror)
FF2C6FD0 not
FF2C6FF4 (in engio_memcpy_maybe)

Example:
Code: [Select]
FF2C6C40 02 00 80 E1                 ORR     R0, R0, R2

should be changed to:
Code: [Select]
FF2C6C40 02 00 80 E0                 ADD     R0, R0, R2

With the patch manager (patchmgr) merged:
Code: [Select]
patch_instruction(0xFF2C6C40, 0xE1800002, 0xE0800002, "engio");

The other instructions should be changed in the same way, and tested in QEMU first.
Title: Re: ML on EOS-M2
Post by: dfort on February 23, 2018, 12:00:46 AM
Merged patchmgr and created this block of code:

Code: [Select]
#if defined(CONFIG_EOSM2)
// patch ENGIO routines to use ADD instead of ORR, to make them able to work on unaligned buffers
// https://www.magiclantern.fm/forum/index.php?topic=15895.msg197682#msg197682
#include "patch.h" // if not already included
patch_instruction(0xFF2C6C40, 0xE1800002, 0xE0800002, "engio");
patch_instruction(0xFF2C6CD8, 0xE1800001, 0xE0800001, "engio");
patch_instruction(0xFF2C6D30, 0xE1822001, 0xE0822001, "engio");
patch_instruction(0xFF2C6D3C, 0xE1811005, 0xE0811005, "engio");
patch_instruction(0xFF2C6DA4, 0xE1807001, 0xE0807001, "engio");
patch_instruction(0xFF2C6F64, 0x1181100C, 0x1081100C, "engio");
patch_instruction(0xFF2C6F94, 0xE1800002, 0xE0800002, "engio");
patch_instruction(0xFF2C6FC4, 0xE1811002, 0xE0811002, "engio");
patch_instruction(0xFF2C6FD0, 0xE1822004, 0xE0822004, "engio");
patch_instruction(0xFF2C6FF4, 0xE1800003, 0xE0800003, "engio");
#endif

Not sure where this goes or if I did it right. If this is inserted in let's say lv-img-engio.c errors like this come up when compiling:

Code: [Select]
../../src/lv-img-engio.c:23:24: error: expected declaration specifiers or '...' before numeric constant
patch_instruction(0xFF2C6C40, 0xE1800002, 0xE0800002, "engio");
                  ^

Since this is a camera specific patch wouldn't it be best to figure out a way to put this in the platform/EOSM2.103 directory? This may be the first camera that requires such patching but maybe there will be others?

Speaking of checking this in QEMU, I still can't get into the ML menu. Has this been committed yet?

...that's the entire point of this patch, to allow you to open ML menu before entering LiveView (for example, while you are on Canon menu). Will commit it, as I don't expect LiveView emulation anytime soon.
Title: Re: ML on EOS-M2
Post by: a1ex on February 23, 2018, 12:09:21 AM
It probably needs to go in boot-hack.c before init_task - that way, it will affect all the ENGIO calls. However, for testing, you may want to try from "don't click me" first (it would take effect after a LiveView refresh). Might also work as an INIT_FUNC, though if these happen to run during LiveView, you may require to refresh LiveView before things start working.

Commit 90f702c (https://www.magiclantern.fm/forum/index.php?topic=15895.msg196689#msg196689) (you have already used it).
Title: Re: ML on EOS-M2
Post by: dfort on February 23, 2018, 03:05:07 AM
Hum, that would be quite a senior moment if I already used it on the EOSM2. Those screenshots I posted were done in camera. In any case, I'm using it in QEMU now.

(https://farm5.staticflickr.com/4603/38619012380_5273a20dd7.jpg) (https://flic.kr/p/21QCwV3)

Problem is, in QEMU "Don't click me!" just goes to a grey screen. In fact almost anything will send QEMU into a grey screen and it refuses to come out of it.

So, let's brick a camera:

(https://farm5.staticflickr.com/4629/40429867991_f57a885666.jpg) (https://flic.kr/p/24ADDcv)

Just kidding, it worked perfectly. I'm still having problems figuring out exactly where to put this in boot-hack.c and how to code it. Seems this needs to be in a function to work? The way I listed it in Reply #280 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg197715#msg197715) doesn't cut the mustard.
Title: Re: ML on EOS-M2
Post by: dfort on February 24, 2018, 11:55:28 PM
Found a place to put the patch code:

boot-hack.c
Code: [Select]
    #elif defined(CONFIG_EOSM2)
    /* R0: 0x44C000 (start address, easier to patch, change to 0x4E0000 => reserve 592K for ML) */
    /* R1: 0xD3C000 [6D, 700D] / 0xC3C000 [100D] / 0xD6C000 [EOSM] / 0xC2A000 [EOSM2] (end address, unchanged) */
    addr_AllocMem_end[1] = MOV_R0_0x4E0000_INSTR;
    ml_reserved_mem = 0x4E0000 - RESTARTSTART;
    patch_instruction(0xFF2C6C40, 0xE1800002, 0xE0800002, "engio");
    patch_instruction(0xFF2C6CD8, 0xE1800001, 0xE0800001, "engio");
    patch_instruction(0xFF2C6D30, 0xE1822001, 0xE0822001, "engio");
    patch_instruction(0xFF2C6D3C, 0xE1811005, 0xE0811005, "engio");
    patch_instruction(0xFF2C6DA4, 0xE1807001, 0xE0807001, "engio");
    patch_instruction(0xFF2C6F64, 0x1181100C, 0x1081100C, "engio");
    patch_instruction(0xFF2C6F94, 0xE1800002, 0xE0800002, "engio");
    patch_instruction(0xFF2C6FC4, 0xE1811002, 0xE0811002, "engio");
    patch_instruction(0xFF2C6FD0, 0xE1822004, 0xE0822004, "engio");
    patch_instruction(0xFF2C6FF4, 0xE1800003, 0xE0800003, "engio");

Things that didn't work are starting to work now, but not enough to put up a build for testers. The LiveView screen keeps freezing, Global Draw overlays disappear when going into and out of ML menus, shooting a CR2 will still result in "Raw error, falling back to YUV overlays" and VU meters aren't working. There's probably more but you get the picture. Speaking of, silent picture is working -- sometimes. I didn't save any DNG's but as expected the focus pixels look pretty much like the 100D.

The EOSM2.103_wip branch has so many other branches merged into it that I'm thinking of making a clean start with the crop_rec_4k branch--or is crop_rec_4k_mlv_lite_snd the branch du jour? When I started this project I made a "fake" pull request to track the changes made to the unified branch and there may be too many changes to consider merging the EOSM2 into unified.

https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/4/eosm2103-wip/diff

[EDIT] Here you go, a simple silent DNG using the default mv720 (5x3) raw buffer on the EOSM2 with a ton of focus pixels to deal with.

(https://farm5.staticflickr.com/4707/39569238645_6889e70ff6_c.jpg) (https://flic.kr/p/23hAG5v)

[EDIT2] Running selftest - API stubs test. Can't get through stub_test_malloc_n_allocmem, stub_test_exmem and consistently fails 4 times on these:

Code: [Select]
[FAIL] MENU_MODE => 0x0
[FAIL] PLAY_MODE => 0x1
[Pass] dialog->type => 'DIALOG'
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[FAIL] PLAY_MODE => 0x1
       SW1(1,100)
[Pass] HALFSHUTTER_PRESSED => 0x1
       SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[FAIL] is_pure_play_photo_mode() => 0x0
Title: Re: ML on EOS-M2
Post by: dfort on February 26, 2018, 07:26:45 AM
Started applying only the EOSM2 specific changes to the crop_rec_4k branch (https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/17/eosm2103-crop-rec-4k-wip/diff) and already the Stubs API test from the selftest module is working better. At least it is getting through all of the tests and marking the problem areas:

Code: [Select]
[Pass] is_play_mode() => 0x1
[Pass] src = fio_malloc(size) => 0x4de1a084
[Pass] dst = fio_malloc(size) => 0x4e61e090
[Pass] memcmp(dst, src, 4097) => 0x10
[Pass] edmac_memcpy(dst, src, 4097) => 0x4e61e090
[Pass] memcmp(dst, src, 4097) => 0x0
[Pass] edmac_memcpy(dst, src, 4097) => 0x4e61e090
[Pass] memcmp(dst, src, size) => 0x84
[Pass] edmac_memcpy(dst, src, size) => 0x4e61e090
[Pass] memcmp(dst, src, size) => 0x0
[Pass] memcmp(dst, src, size) => 0x19
[Pass] edmac_memcpy_start(dst, src, size) => 0x4e61e090
       dt => 0x296f
[Pass] copied => 0x400b70
[Pass] copied => 0x400b70
[Pass] copied => 0x400b70
[Pass] memcmp(dst, src, copied) => 0x0
[Pass] memcmp(dst, src, copied + 16) => 0xfffffff3
       edmac_memcpy_finish()
       free(src)
       free(dst)
Cache test A (EDMAC on BMP buffer)...
[Pass] bmp = bmp_load("ML/CROPMKS/CINESCO2.BMP", 1) => 0xa9f4a4
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x80f
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x0
Cache test B (FIO on 8K buffer)...
[Pass] tries[0] => 0xef
[Pass] tries[1] => 0x103
[Pass] tries[2] => 0xfc
[Pass] tries[3] => 0xfa
[Pass] failr[0] => 0x47
[Pass] failw[0] => 0x88
[Pass] failr[1] => 0x4b
[Pass] failw[1] => 0x0
[Pass] failr[2] => 0x0
[Pass] failw[2] => 0x8c
[Pass] failr[3] => 0x0
[Pass] failw[3] => 0x0
       times[0] / tries[0] => 0x1d
       times[1] / tries[1] => 0x1f
       times[2] / tries[2] => 0x1e
       times[3] / tries[3] => 0x20
Cache tests finished.

[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x1
[Pass] lv_focus_status => 0x3
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x1
[Pass] lv_focus_status => 0x3
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x1
[Pass] lv_focus_status => 0x3
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x1
[Pass] lv_focus_status => 0x3
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x1
[Pass] lv_focus_status => 0x3
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x1
[Pass] lv_focus_status => 0x3
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x1
[Pass] lv_focus_status => 0x3
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x1
[Pass] lv_focus_status => 0x3
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x1
[Pass] lv_focus_status => 0x3
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x1
[Pass] lv_focus_status => 0x3
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x2
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x2
[Pass] f = FIO_CreateFile("test.dat") => 0x5
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
       FIO_CloseFile(f)
[Pass] FIO_GetFileSize("test.dat", &size) => 0x0
[Pass] size => 0x20000
[Pass] p = (void*)_alloc_dma_memory(0x20000) => 0x40aa121c
[Pass] f = FIO_OpenFile("test.dat", O_RDONLY | O_SYNC) => 0x5
[Pass] FIO_ReadFile(f, p, 0x20000) => 0x20000
       FIO_CloseFile(f)
       _free_dma_memory(p)
[Pass] count => 0x3a98
[Pass] buf = fio_malloc(0x1000000) => 0x4de1a084
[Pass] FIO_GetFileSize_direct("test.dat") => 0x82000000
[Pass] f = FIO_OpenFile("test.dat", O_RDWR | O_SYNC) => 0x5
[Pass] FIO_SeekSkipFile(f, 0, SEEK_END) => 0x82000000
[Pass] FIO_WriteFile(f, buf, 0x10) => 0x10
[Pass] FIO_SeekSkipFile(f, -0x20, SEEK_END) => 0x81fffff0
[Pass] FIO_WriteFile(f, buf, 0x30) => 0x30
[Pass] FIO_SeekSkipFile(f, 0x20, SEEK_SET) => 0x20
[Pass] FIO_SeekSkipFile(f, 0x30, SEEK_CUR) => 0x50
[Pass] FIO_SeekSkipFile(f, -0x20, SEEK_CUR) => 0x30
[Pass] FIO_GetFileSize_direct("test.dat") => 0x82000020
[Pass] is_file("test.dat") => 0x1
[Pass] FIO_RemoveFile("test.dat") => 0x0
[Pass] is_file("test.dat") => 0x0
[Pass] SetTimerAfter(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x8c78
       msleep(900)
[Pass] timer_func => 0x0
       msleep(200)
[Pass] timer_func => 0x1
[Pass] ABS((timer_time/1000 - t0) - 1000) => 0x6
[Pass] ABS((timer_arg - ta0) - 1000) => 0xa
[Pass] timer = SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x8ca6
       msleep(400)
       CancelTimer(timer)
[Pass] timer_func => 0x0
       msleep(1500)
[Pass] timer_func => 0x0
[Pass] SetHPTimerAfterNow(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetHPTimerAfterNow(100000, timer_cbr, overrun_cbr, 0) => 0x330dc
       msleep(90)
[Pass] timer_func => 0x0
       msleep(20)
[Pass] timer_func => 0x1
[Pass] ABS(DeltaT(timer_time, t0) - 100000) => 0x11a
[Pass] ABS(DeltaT(timer_arg, ta0) - 100000) => 0xff
[Pass] ABS((get_us_clock() - t0) - 110000) => 0x15b
[Pass] SetHPTimerAfterNow(90000, next_tick_cbr, overrun_cbr, 0) => 0x330de
       msleep(80)
[Pass] timer_func => 0x0
       msleep(20)
[Pass] timer_func => 0x3
       msleep(80)
[Pass] timer_func => 0x3
       msleep(20)
[Pass] timer_func => 0x1
[Pass] ABS(DeltaT(timer_time, t0) - 300000) => 0x1ea
[Pass] ABS(DeltaT(timer_arg, ta0) - 300000) => 0x1d0
[Pass] ABS((get_us_clock() - t0) - 310000) => 0x145
       t0 = GET_DIGIC_TIMER() => 0x27d7f
       msleep(250)
       t1 = GET_DIGIC_TIMER() => 0x641e7
[Pass] ABS(MOD(t1-t0, 1048576)/1000 - 250) => 0x4
       LoadCalendarFromRTC( &now )
       s0 = now.tm_sec => 0x4
       Date/time: 2018/02/25 10:54:04
       msleep(1500)
       LoadCalendarFromRTC( &now )
       s1 = now.tm_sec => 0x6
[Pass] MOD(s1-s0, 60) => 0x2
[Pass] MOD(s1-s0, 60) => 0x2
       m0 = MALLOC_FREE_MEMORY => 0x60448
[Pass] p = (void*)_malloc(50*1024) => 0x11e768
[Pass] CACHEABLE(p) => 0x11e768
       m1 = MALLOC_FREE_MEMORY => 0x53c38
       _free(p)
       m2 = MALLOC_FREE_MEMORY => 0x60448
[Pass] ABS((m0-m1) - 50*1024) => 0x10
[Pass] ABS(m0-m2) => 0x0
       m0 = GetFreeMemForAllocateMemory() => 0x1ee0e8
[Pass] p = (void*)_AllocateMemory(128*1024) => 0xaa11dc
[Pass] CACHEABLE(p) => 0xaa11dc
       m1 = GetFreeMemForAllocateMemory() => 0x1ce0dc
       _FreeMemory(p)
       m2 = GetFreeMemForAllocateMemory() => 0x1ee0e8
[Pass] ABS((m0-m1) - 128*1024) => 0xc
[Pass] ABS(m0-m2) => 0x0
       m01 = MALLOC_FREE_MEMORY => 0x60448
       m02 = GetFreeMemForAllocateMemory() => 0x1ee0e8
[Pass] p = (void*)_alloc_dma_memory(128*1024) => 0x40aa121c
[Pass] UNCACHEABLE(p) => 0x40aa121c
[Pass] CACHEABLE(p) => 0xaa121c
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x40aa121c
       _free_dma_memory(p)
[Pass] p = (void*)_shoot_malloc(16*1024*1024) => 0x4de1a074
[Pass] UNCACHEABLE(p) => 0x4de1a074
       _shoot_free(p)
       m11 = MALLOC_FREE_MEMORY => 0x60448
       m12 = GetFreeMemForAllocateMemory() => 0x1ee0e8
[Pass] ABS(m01-m11) => 0x0
[Pass] ABS(m02-m12) => 0x0
[Pass] suite = shoot_malloc_suite_contig(16*1024*1024) => 0x102390
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1000000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1023b8
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1000000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite_contig(0) => 0x102390
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x14b4000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1023b8
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x14b4000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       largest_shoot_block = suite->size => 0x14b4000
[INFO] largest_shoot_block: 21MB
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(largest_shoot_block + 1024*1024) => 0x102390
[Pass] suite->signature => 'MemSuite'
[FAIL] suite->num_chunks => 0x1
[Pass] suite->size => 0x15b4000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1023b8
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x15b4000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x15b4000
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(0) => 0x102390
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x3
[Pass] suite->size => 0x1700000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1023b8
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x15b4000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       chunk = GetNextMemoryChunk(suite, chunk) => 0x1023f0
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x169c000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4ae00064
[Pass] UNCACHEABLE(p) => 0x4ae00064
       chunk = GetNextMemoryChunk(suite, chunk) => 0x117458
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1700000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x45f240e4
[Pass] UNCACHEABLE(p) => 0x45f240e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x1700000
       shoot_free_suite(suite); suite = 0; chunk = 0;
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[Pass] strlen("abc") => 0x3
[Pass] strlen("qwertyuiop") => 0xa
[Pass] strlen("") => 0x0
[Pass] strcpy(msg, "hi there") => 0x205a8c
[Pass] msg => 'hi there'
[Pass] snprintf(a, sizeof(a), "foo") => 0x3
[Pass] snprintf(b, sizeof(b), "foo") => 0x3
[Pass] strcmp(a, b) => 0x0
[Pass] snprintf(a, sizeof(a), "bar") => 0x3
[Pass] snprintf(b, sizeof(b), "baz") => 0x3
[Pass] strcmp(a, b) => 0xfffffff8
[Pass] snprintf(a, sizeof(a), "Display") => 0x7
[Pass] snprintf(b, sizeof(b), "Defishing") => 0x9
[Pass] strcmp(a, b) => 0x4
[Pass] snprintf(buf, 3, "%d", 1234) => 0x2
[Pass] buf => '12'
[Pass] memcpy(foo, bar, 6) => 0x205a60
[Pass] foo => 'asdfghuiop'
[Pass] memset(bar, '*', 5) => 0x205a40
[Pass] bar => '*****hjkl;'
       bzero32(bar + 5, 5)
[Pass] bar => '****'
       EngDrvOut(LCD_Palette[0], 0x1234)
[Pass] shamem_read(LCD_Palette[0]) => 0x1234
       call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
       call("TurnOffDisplay")
[Pass] DISPLAY_IS_ON => 0x0
       call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
       task_create("test", 0x1c, 0x1000, test_task, 0) => 0xdb2e00ea
[Pass] test_task_created => 0x1
[Pass] get_current_task_name() => 'run_test'
[Pass] get_task_name_from_id(current_task->taskId) => 'run_test'
[Pass] task_max => 0x84
[Pass] task_max => 0x84
[Pass] mq = mq ? mq : (void*)msg_queue_create("test", 5) => 0xdb3000ba
[Pass] msg_queue_post(mq, 0x1234567) => 0x0
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x0
[Pass] m => 0x1234567
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x9
[Pass] sem = sem ? sem : create_named_semaphore("test", 1) => 0xdb320088
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] take_semaphore(sem, 500) => 0x9
[Pass] give_semaphore(sem) => 0x0
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] give_semaphore(sem) => 0x0
[Pass] rlock = rlock ? rlock : CreateRecursiveLock(0) => 0xdb3400fe
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0xf
       SetGUIRequestMode(1); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x1
       SetGUIRequestMode(2); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x2
       SetGUIRequestMode(0); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x0
[Pass] display_idle() => 0x1
       GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[Pass] PLAY_MODE => 0x1
[Pass] MENU_MODE => 0x0
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(1000);
[FAIL] MENU_MODE => 0x0
[FAIL] PLAY_MODE => 0x1
[Pass] dialog->type => 'DIALOG'
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[FAIL] PLAY_MODE => 0x1
       SW1(1,100)
[Pass] HALFSHUTTER_PRESSED => 0x1
       SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[FAIL] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x1
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
=========================================================
Test complete, 11366 passed, 24 failed.
.

LUA Script API Tests don't complete. Maybe there's a clue in here why?

Code: [Select]
===============================================================================
ML/SCRIPTS/API_TEST.LUA - 2018-2-25 11:18:02
===============================================================================

Strict mode tests...
Strict mode tests passed.

Generic tests...
arg = table:
  [0] = "API_TEST.LUA"
camera = table:
  shutter = table:
    raw = 96
    apex = 5.
    ms = 31
    value = 0.03125
  aperture = table:
    raw = 24
    apex = 2.
    value = 2.
    min = table:
      raw = 24
      apex = 2.
      value = 2.
    max = table:
      raw = 80
      apex = 9.
      value = 22.6
  iso = table:
    raw = 88
    apex = 7.
    value = 400
  ec = table:
    raw = 0
    value = 0
  flash_ec = table:
    raw = 0
    value = 0
  kelvin = 6500
  mode = 3
  metering_mode = 3
  drive_mode = 0
  model = "Canon EOS M2"
  model_short = "EOSM2"
  firmware = "1.0.3"
  temperature = 211
  gui = table:
    menu = false
    play = false
    play_photo = false
    play_movie = false
    qr = false
    idle = false
  bulb = function: p
  reboot = function: p
  burst = function: p
  wait = function: p
  shoot = function: p
event = table:
  pre_shoot = nil
  post_shoot = nil
  shoot_task = nil
  seconds_clock = nil
  keypress = nil
  custom_picture_taking = nil
  intervalometer = nil
  config_save = nil
console = table:
  hide = function: p
  show = function: p
  clear = function: p
  write = function: p
lv = table:
  enabled = true
  paused = false
  running = true
  zoom = 1
  overlays = false
  pause = function: p
  start = function: p
  resume = function: p
  info = function: p
  wait = function: p
  stop = function: p
lens = table:
  name = "EF-M22mm f/2 STM"
  focal_length = 22
  focus_distance = 210
  hyperfocal = 12780
  dof_near = 207
  dof_far = 212
  af = true
  af_mode = 0
  focus = function: p
  autofocus = function: p
display = table:
  idle = nil
  height = 480
  width = 720
  circle = function: p
  rect = function: p
  screenshot = function: p
  notify_box = function: p
  off = function: p
  draw = function: p
  line = function: p
  print = function: p
  on = function: p
  pixel = function: p
  clear = function: p
  load = function: p
key = table:
  last = 10
  press = function: p
  wait = function: p
menu = table:
  visible = false
  new = function: p
  close = function: p
  set = function: p
  block = function: p
  select = function: p
  open = function: p
  get = function: p
movie = table:
  recording = false
  start = function: p
  stop = function: p
dryos = table:
  clock = 76
  ms_clock = 76256
  image_prefix = "IMG_"
  dcim_dir = table:
    exists = true
    create = function: p
    children = function: p
    files = function: p
    parent = table:
      exists = true
      create = function: p
      children = function: p
      files = function: p
      parent = table:
        exists = true
        create = function: p
        children = function: p
        files = function: p
        parent = nil
        path = "B:/"
      path = "B:/DCIM/"
    path = "B:/DCIM/100CANON/"
  config_dir = table:
    exists = true
    create = function: p
    children = function: p
    files = function: p
    parent = table:
      exists = true
      create = function: p
      children = function: p
      files = function: p
      parent = table:
        exists = true
        create = function: p
        children = function: p
        files = function: p
        parent = nil
        path = "B:/"
      path = "ML/"
    path = "ML/SETTINGS/"
  ml_card = table:
    cluster_size = 32768
    drive_letter = "B"
    file_number = 7263
    folder_number = 100
    free_space = 31064288
    type = "SD"
    path = "B:/"
    _card_ptr = userdata
  shooting_card = table:
    cluster_size = 32768
    drive_letter = "B"
    file_number = 7263
    folder_number = 100
    free_space = 31064288
    type = "SD"
    path = "B:/"
    _card_ptr = userdata
  date = table:
    wday = 1
    day = 25
    min = 18
    hour = 11
    isdst = false
    sec = 3
    year = 2018
    yday = 56
    month = 2
  rename = function: p
  directory = function: p
  call = function: p
  remove = function: p
interval = table:
  time = 10
  count = 0
  running = false
  stop = function: p
battery = table:
function not available on this camera
stack traceback:
[C]: in ?
[C]: in for iterator 'for iterator'
ML/SCRIPTS/LIB/logger.lua:125: in function 'logger.serialize'
ML/SCRIPTS/API_TEST.LUA:36: in function <ML/SCRIPTS/API_TEST.LUA:35>
[C]: in function 'xpcall'
ML/SCRIPTS/API_TEST.LUA:35: in function 'print_table'
ML/SCRIPTS/API_TEST.LUA:81: in function 'generic_tests'
ML/SCRIPTS/API_TEST.LUA:1338: in function 'api_tests'
ML/SCRIPTS/API_TEST.LUA:1364: in main chunktask = table:
  yield = function: p
  create = function: p
property = table:
Generic tests completed.

Module tests...
Testing file I/O...
Copy test: autoexec.bin -> tmp.bin
Copy test OK
Append test: tmp.txt
Append test OK
Rename test: apple.txt -> banana.txt
Rename test OK
Rename test: apple.txt -> ML/banana.txt
Rename test OK
File I/O tests completed.

Testing Canon GUI functions...
Enter MENU mode...
Exit MENU mode...
Enter MENU mode...
Enter PLAY mode...
Enter MENU mode...
Exit MENU mode...
Enter MENU mode...
Exit MENU mode...
Pause LiveView...
Enter MENU mode...
Exit MENU mode...
Pause LiveView...
Resume LiveView...
Enter PLAY mode...
Enter MENU mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter MENU mode...
Enter MENU mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Exit PLAY mode...
Title: Re: ML on EOS-M2
Post by: dfort on February 27, 2018, 09:52:12 PM
Seems like everything about the EOSM2 is a bit quirky. For example, the crop_rec module is pretty much the same on all the APS-C Digic 5 cameras:

Code: [Select]
    else if (is_camera("EOSM", "2.0.2"))
    {
        CMOS_WRITE = 0x2998C;
        MEM_CMOS_WRITE = 0xE92D41F0;
       
        ADTG_WRITE = 0x2986C;
        MEM_ADTG_WRITE = 0xE92D43F8;

The CMOS_WRITE and ADTG_WRITE are easy to find in either the disassembly or the adtg_gui module code. The 100D/700D/EOSM all share the same MEM_CMOS_WRITE and MEM_ADTG_WRITE so I assumed the EOSM2 would follow suit--but you know what happens when you assume.

MEM_CMOS_WRITE looked just like the others - look at the green numbers at the bottom:

(https://farm5.staticflickr.com/4653/26651731118_23328867e9.jpg) (https://flic.kr/p/GB868u)

However, MEM_ADTG_WRITE is different:

(https://farm5.staticflickr.com/4704/39812422014_724bcabf35.jpg) (https://flic.kr/p/23E652d)

So for the EOSM2, this is what works for the crop_rec module:

Code: [Select]
    else if (is_camera("EOSM2", "1.0.3"))
    {
        CMOS_WRITE = 0x432A4;
        MEM_CMOS_WRITE = 0xE92D41F0;
       
        ADTG_WRITE = 0x42E34;
        MEM_ADTG_WRITE = 0xE51F7224;

Haven't gotten mlv_lite/mlv_rec working yet but crop_rec works in H.264.

(https://farm5.staticflickr.com/4672/39812840894_78679da578.jpg) (https://flic.kr/p/23E8dxh)

Just the basic 720p/60 3x3 video mode but that's all the original EOSM can do for now too.
Title: Re: ML on EOS-M2
Post by: dfort on February 28, 2018, 12:16:10 AM
More log files. This time I setup an EOSM alongside the EOSM2 running the crop_rec_4k branch. Although not much seems to be working properly on the EOSM2, these test results surprised me.

EOSM2 - selftest module STUBTEST.LOG
Code: [Select]
[Pass] is_play_mode() => 0x1
[Pass] src = fio_malloc(size) => 0x4de3609c
[Pass] dst = fio_malloc(size) => 0x4e63a0a8
[Pass] memcmp(dst, src, 4097) => 0xffffffd5
[Pass] edmac_memcpy(dst, src, 4097) => 0x4e63a0a8
[Pass] memcmp(dst, src, 4097) => 0x0
[Pass] edmac_memcpy(dst, src, 4097) => 0x4e63a0a8
[Pass] memcmp(dst, src, size) => 0x61
[Pass] edmac_memcpy(dst, src, size) => 0x4e63a0a8
[Pass] memcmp(dst, src, size) => 0x0
[Pass] memcmp(dst, src, size) => 0xffffffee
[Pass] edmac_memcpy_start(dst, src, size) => 0x4e63a0a8
       dt => 0x2946
[Pass] copied => 0x400358
[Pass] copied => 0x400358
[Pass] copied => 0x400358
[Pass] memcmp(dst, src, copied) => 0x0
[Pass] memcmp(dst, src, copied + 16) => 0xffffffe1
       edmac_memcpy_finish()
       free(src)
       free(dst)
Cache test A (EDMAC on BMP buffer)...
[Pass] bmp = bmp_load("ML/CROPMKS/CINESCO2.BMP", 1) => 0xaa0708
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x7bf
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x0
Cache test B (FIO on 8K buffer)...
[Pass] tries[0] => 0xe3
[Pass] tries[1] => 0xf5
[Pass] tries[2] => 0x109
[Pass] tries[3] => 0x107
[Pass] failr[0] => 0x44
[Pass] failw[0] => 0x8e
[Pass] failr[1] => 0x41
[Pass] failw[1] => 0x0
[Pass] failr[2] => 0x0
[Pass] failw[2] => 0xaa
[Pass] failr[3] => 0x0
[Pass] failw[3] => 0x0
       times[0] / tries[0] => 0x1e
       times[1] / tries[1] => 0x1d
       times[2] / tries[2] => 0x1e
       times[3] / tries[3] => 0x1e
Cache tests finished.

[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] f = FIO_CreateFile("test.dat") => 0x5
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
       FIO_CloseFile(f)
[Pass] FIO_GetFileSize("test.dat", &size) => 0x0
[Pass] size => 0x20000
[Pass] p = (void*)_alloc_dma_memory(0x20000) => 0x40aa2480
[Pass] f = FIO_OpenFile("test.dat", O_RDONLY | O_SYNC) => 0x5
[Pass] FIO_ReadFile(f, p, 0x20000) => 0x20000
       FIO_CloseFile(f)
       _free_dma_memory(p)
[Pass] count => 0x3a98
[Pass] buf = fio_malloc(0x1000000) => 0x4de3609c
[Pass] FIO_GetFileSize_direct("test.dat") => 0x82000000
[Pass] f = FIO_OpenFile("test.dat", O_RDWR | O_SYNC) => 0x5
[Pass] FIO_SeekSkipFile(f, 0, SEEK_END) => 0x82000000
[Pass] FIO_WriteFile(f, buf, 0x10) => 0x10
[Pass] FIO_SeekSkipFile(f, -0x20, SEEK_END) => 0x81fffff0
[Pass] FIO_WriteFile(f, buf, 0x30) => 0x30
[Pass] FIO_SeekSkipFile(f, 0x20, SEEK_SET) => 0x20
[Pass] FIO_SeekSkipFile(f, 0x30, SEEK_CUR) => 0x50
[Pass] FIO_SeekSkipFile(f, -0x20, SEEK_CUR) => 0x30
[Pass] FIO_GetFileSize_direct("test.dat") => 0x82000020
[Pass] is_file("test.dat") => 0x1
[Pass] FIO_RemoveFile("test.dat") => 0x0
[Pass] is_file("test.dat") => 0x0
[Pass] SetTimerAfter(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x8738
       msleep(900)
[Pass] timer_func => 0x0
       msleep(200)
[Pass] timer_func => 0x1
[Pass] ABS((timer_time/1000 - t0) - 1000) => 0x2
[Pass] ABS((timer_arg - ta0) - 1000) => 0xa
[Pass] timer = SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x875c
       msleep(400)
       CancelTimer(timer)
[Pass] timer_func => 0x0
       msleep(1500)
[Pass] timer_func => 0x0
[Pass] SetHPTimerAfterNow(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetHPTimerAfterNow(100000, timer_cbr, overrun_cbr, 0) => 0x31aae
       msleep(90)
[Pass] timer_func => 0x0
       msleep(20)
[Pass] timer_func => 0x1
[Pass] ABS(DeltaT(timer_time, t0) - 100000) => 0x117
[Pass] ABS(DeltaT(timer_arg, ta0) - 100000) => 0xf9
[Pass] ABS((get_us_clock() - t0) - 110000) => 0x29e
[Pass] SetHPTimerAfterNow(90000, next_tick_cbr, overrun_cbr, 0) => 0x31ab0
       msleep(80)
[Pass] timer_func => 0x0
       msleep(20)
[Pass] timer_func => 0x3
       msleep(80)
[Pass] timer_func => 0x3
       msleep(20)
[Pass] timer_func => 0x1
[Pass] ABS(DeltaT(timer_time, t0) - 300000) => 0x32d
[Pass] ABS(DeltaT(timer_arg, ta0) - 300000) => 0x312
[Pass] ABS((get_us_clock() - t0) - 310000) => 0x285
       t0 = GET_DIGIC_TIMER() => 0xd4406
       msleep(250)
       t1 = GET_DIGIC_TIMER() => 0x106ac
[Pass] ABS(MOD(t1-t0, 1048576)/1000 - 250) => 0x4
       LoadCalendarFromRTC( &now )
       s0 = now.tm_sec => 0xa
       Date/time: 2018/02/27 02:57:10
       msleep(1500)
       LoadCalendarFromRTC( &now )
       s1 = now.tm_sec => 0xb
[Pass] MOD(s1-s0, 60) => 0x1
[Pass] MOD(s1-s0, 60) => 0x1
       m0 = MALLOC_FREE_MEMORY => 0x602f8
[Pass] p = (void*)_malloc(50*1024) => 0x11e798
[Pass] CACHEABLE(p) => 0x11e798
       m1 = MALLOC_FREE_MEMORY => 0x53ae8
       _free(p)
       m2 = MALLOC_FREE_MEMORY => 0x602f8
[Pass] ABS((m0-m1) - 50*1024) => 0x10
[Pass] ABS(m0-m2) => 0x0
       m0 = GetFreeMemForAllocateMemory() => 0x1edb64
[Pass] p = (void*)_AllocateMemory(128*1024) => 0xaa2440
[Pass] CACHEABLE(p) => 0xaa2440
       m1 = GetFreeMemForAllocateMemory() => 0x1cdb58
       _FreeMemory(p)
       m2 = GetFreeMemForAllocateMemory() => 0x1edb64
[Pass] ABS((m0-m1) - 128*1024) => 0xc
[Pass] ABS(m0-m2) => 0x0
       m01 = MALLOC_FREE_MEMORY => 0x602f8
       m02 = GetFreeMemForAllocateMemory() => 0x1edb64
[Pass] p = (void*)_alloc_dma_memory(128*1024) => 0x40aa2480
[Pass] UNCACHEABLE(p) => 0x40aa2480
[Pass] CACHEABLE(p) => 0xaa2480
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x40aa2480
       _free_dma_memory(p)
[Pass] p = (void*)_shoot_malloc(16*1024*1024) => 0x4de3608c
[Pass] UNCACHEABLE(p) => 0x4de3608c
       _shoot_free(p)
       m11 = MALLOC_FREE_MEMORY => 0x602f8
       m12 = GetFreeMemForAllocateMemory() => 0x1edb64
[Pass] ABS(m01-m11) => 0x0
[Pass] ABS(m02-m12) => 0x0
[Pass] suite = shoot_malloc_suite_contig(16*1024*1024) => 0x11e798
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1000000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x11e7c0
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1000000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de36088
[Pass] UNCACHEABLE(p) => 0x4de36088
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite_contig(0) => 0x117380
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1498000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1173a8
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1498000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       largest_shoot_block = suite->size => 0x1498000
[INFO] largest_shoot_block: 21MB
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(largest_shoot_block + 1024*1024) => 0x117380
[Pass] suite->signature => 'MemSuite'
[FAIL] suite->num_chunks => 0x1
[Pass] suite->size => 0x1598000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1173a8
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1598000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x1598000
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(0) => 0x117380
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x3
[Pass] suite->size => 0x1700000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1173a8
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x15b4000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       chunk = GetNextMemoryChunk(suite, chunk) => 0x1173e0
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x169c000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4ae00064
[Pass] UNCACHEABLE(p) => 0x4ae00064
       chunk = GetNextMemoryChunk(suite, chunk) => 0x117418
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1700000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x45f240e4
[Pass] UNCACHEABLE(p) => 0x45f240e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x1700000
       shoot_free_suite(suite); suite = 0; chunk = 0;
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[Pass] strlen("abc") => 0x3
[Pass] strlen("qwertyuiop") => 0xa
[Pass] strlen("") => 0x0
[Pass] strcpy(msg, "hi there") => 0x233714
[Pass] msg => 'hi there'
[Pass] snprintf(a, sizeof(a), "foo") => 0x3
[Pass] snprintf(b, sizeof(b), "foo") => 0x3
[Pass] strcmp(a, b) => 0x0
[Pass] snprintf(a, sizeof(a), "bar") => 0x3
[Pass] snprintf(b, sizeof(b), "baz") => 0x3
[Pass] strcmp(a, b) => 0xfffffff8
[Pass] snprintf(a, sizeof(a), "Display") => 0x7
[Pass] snprintf(b, sizeof(b), "Defishing") => 0x9
[Pass] strcmp(a, b) => 0x4
[Pass] snprintf(buf, 3, "%d", 1234) => 0x2
[Pass] buf => '12'
[Pass] memcpy(foo, bar, 6) => 0x2336e0
[Pass] foo => 'asdfghuiop'
[Pass] memset(bar, '*', 5) => 0x2336c0
[Pass] bar => '*****hjkl;'
       bzero32(bar + 5, 5)
[Pass] bar => '****'
       EngDrvOut(LCD_Palette[0], 0x1234)
[Pass] shamem_read(LCD_Palette[0]) => 0x1234
       call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
       call("TurnOffDisplay")
[Pass] DISPLAY_IS_ON => 0x0
       call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
       task_create("test", 0x1c, 0x1000, test_task, 0) => 0xec2400ea
[Pass] test_task_created => 0x1
[Pass] get_current_task_name() => 'run_test'
[Pass] get_task_name_from_id(current_task->taskId) => 'run_test'
[Pass] task_max => 0x84
[Pass] task_max => 0x84
[Pass] mq = mq ? mq : (void*)msg_queue_create("test", 5) => 0xec2600ba
[Pass] msg_queue_post(mq, 0x1234567) => 0x0
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x0
[Pass] m => 0x1234567
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x9
[Pass] sem = sem ? sem : create_named_semaphore("test", 1) => 0xec280252
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] take_semaphore(sem, 500) => 0x9
[Pass] give_semaphore(sem) => 0x0
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] give_semaphore(sem) => 0x0
[Pass] rlock = rlock ? rlock : CreateRecursiveLock(0) => 0xec2a004c
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0xf
       SetGUIRequestMode(1); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x1
       SetGUIRequestMode(2); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x2
       SetGUIRequestMode(0); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x0
[Pass] display_idle() => 0x1
       GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[Pass] PLAY_MODE => 0x1
[Pass] MENU_MODE => 0x0
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(1000);
[FAIL] MENU_MODE => 0x0
[FAIL] PLAY_MODE => 0x1
[Pass] dialog->type => 'DIALOG'
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[FAIL] PLAY_MODE => 0x1
       SW1(1,100)
[Pass] HALFSHUTTER_PRESSED => 0x1
       SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[FAIL] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x1
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
=========================================================
Test complete, 11346 passed, 44 failed.
.

EOSM - selftest module STUBTEST.LOG
Code: [Select]
[Pass] is_play_mode() => 0x1
[Pass] src = fio_malloc(size) => 0x4de1a084
[Pass] dst = fio_malloc(size) => 0x4e61e090
[Pass] memcmp(dst, src, 4097) => 0x75
[Pass] edmac_memcpy(dst, src, 4097) => 0x4e61e090
[Pass] memcmp(dst, src, 4097) => 0x0
[Pass] edmac_memcpy(dst, src, 4097) => 0x4e61e090
[Pass] memcmp(dst, src, size) => 0x63
[Pass] edmac_memcpy(dst, src, size) => 0x4e61e090
[Pass] memcmp(dst, src, size) => 0x0
[Pass] memcmp(dst, src, size) => 0x3e
[Pass] edmac_memcpy_start(dst, src, size) => 0x4e61e090
       dt => 0x294d
[Pass] copied => 0x400470
[Pass] copied => 0x400470
[Pass] copied => 0x400470
[Pass] memcmp(dst, src, copied) => 0x0
[Pass] memcmp(dst, src, copied + 16) => 0x17
       edmac_memcpy_finish()
       free(src)
       free(dst)
Cache test A (EDMAC on BMP buffer)...
[Pass] bmp = bmp_load("ML/CROPMKS/CINESCO2.BMP", 1) => 0x80ea18
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0xa00
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x0
Cache test B (FIO on 8K buffer)...
[Pass] tries[0] => 0xfa
[Pass] tries[1] => 0xf9
[Pass] tries[2] => 0xfe
[Pass] tries[3] => 0xf7
[Pass] failr[0] => 0x72
[Pass] failw[0] => 0xe3
[Pass] failr[1] => 0x7b
[Pass] failw[1] => 0x0
[Pass] failr[2] => 0x0
[Pass] failw[2] => 0xe4
[Pass] failr[3] => 0x0
[Pass] failw[3] => 0x0
       times[0] / tries[0] => 0x1d
       times[1] / tries[1] => 0x1d
       times[2] / tries[2] => 0x1e
       times[3] / tries[3] => 0x1f
Cache tests finished.

[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[FAIL] wait_focus_status(1000, 3) => 0x0
[FAIL] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] lv_focus_status => 0x1
[Pass] HALFSHUTTER_PRESSED => 0x1
[Pass] wait_focus_status(1000, 3) => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] lv_focus_status => 0x1
[Pass] f = FIO_CreateFile("test.dat") => 0x3
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
       FIO_CloseFile(f)
[Pass] FIO_GetFileSize("test.dat", &size) => 0x0
[Pass] size => 0x20000
[Pass] p = (void*)_alloc_dma_memory(0x20000) => 0x40863270
[Pass] f = FIO_OpenFile("test.dat", O_RDONLY | O_SYNC) => 0x3
[Pass] FIO_ReadFile(f, p, 0x20000) => 0x20000
       FIO_CloseFile(f)
       _free_dma_memory(p)
[Pass] count => 0x3a98
[Pass] buf = fio_malloc(0x1000000) => 0x4de1a084
[Pass] FIO_GetFileSize_direct("test.dat") => 0x82000000
[Pass] f = FIO_OpenFile("test.dat", O_RDWR | O_SYNC) => 0x3
[Pass] FIO_SeekSkipFile(f, 0, SEEK_END) => 0x82000000
[Pass] FIO_WriteFile(f, buf, 0x10) => 0x10
[Pass] FIO_SeekSkipFile(f, -0x20, SEEK_END) => 0x81fffff0
[Pass] FIO_WriteFile(f, buf, 0x30) => 0x30
[Pass] FIO_SeekSkipFile(f, 0x20, SEEK_SET) => 0x20
[Pass] FIO_SeekSkipFile(f, 0x30, SEEK_CUR) => 0x50
[Pass] FIO_SeekSkipFile(f, -0x20, SEEK_CUR) => 0x30
[Pass] FIO_GetFileSize_direct("test.dat") => 0x82000020
[Pass] is_file("test.dat") => 0x1
[Pass] FIO_RemoveFile("test.dat") => 0x0
[Pass] is_file("test.dat") => 0x0
[Pass] SetTimerAfter(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0xb51e
       msleep(900)
[Pass] timer_func => 0x0
       msleep(200)
[Pass] timer_func => 0x1
[Pass] ABS((timer_time/1000 - t0) - 1000) => 0xa
[Pass] ABS((timer_arg - ta0) - 1000) => 0x14
[Pass] timer = SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0xb58c
       msleep(400)
       CancelTimer(timer)
[Pass] timer_func => 0x0
       msleep(1500)
[Pass] timer_func => 0x0
[Pass] SetHPTimerAfterNow(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetHPTimerAfterNow(100000, timer_cbr, overrun_cbr, 0) => 0x32238
       msleep(90)
[Pass] timer_func => 0x0
       msleep(20)
[Pass] timer_func => 0x1
[Pass] ABS(DeltaT(timer_time, t0) - 100000) => 0x111
[Pass] ABS(DeltaT(timer_arg, ta0) - 100000) => 0xf0
[Pass] ABS((get_us_clock() - t0) - 110000) => 0xffffffd7
[Pass] SetHPTimerAfterNow(90000, next_tick_cbr, overrun_cbr, 0) => 0x3223a
       msleep(80)
[Pass] timer_func => 0x0
       msleep(20)
[Pass] timer_func => 0x3
       msleep(80)
[Pass] timer_func => 0x3
       msleep(20)
[Pass] timer_func => 0x1
[Pass] ABS(DeltaT(timer_time, t0) - 300000) => 0x76
[Pass] ABS(DeltaT(timer_arg, ta0) - 300000) => 0x55
[Pass] ABS((get_us_clock() - t0) - 310000) => 0xffffffc0
       t0 = GET_DIGIC_TIMER() => 0xf5496
       msleep(250)
       t1 = GET_DIGIC_TIMER() => 0x31cfe
[Pass] ABS(MOD(t1-t0, 1048576)/1000 - 250) => 0x3
       LoadCalendarFromRTC( &now )
       s0 = now.tm_sec => 0x1f
       Date/time: 2018/02/27 14:09:31
       msleep(1500)
       LoadCalendarFromRTC( &now )
       s1 = now.tm_sec => 0x20
[Pass] MOD(s1-s0, 60) => 0x1
[Pass] MOD(s1-s0, 60) => 0x1
       m0 = MALLOC_FREE_MEMORY => 0x38a18
[Pass] p = (void*)_malloc(50*1024) => 0x136e30
[Pass] CACHEABLE(p) => 0x136e30
       m1 = MALLOC_FREE_MEMORY => 0x2c208
       _free(p)
       m2 = MALLOC_FREE_MEMORY => 0x38a18
[Pass] ABS((m0-m1) - 50*1024) => 0x10
[Pass] ABS(m0-m2) => 0x0
       m0 = GetFreeMemForAllocateMemory() => 0x335284
[Pass] p = (void*)_AllocateMemory(128*1024) => 0x863230
[Pass] CACHEABLE(p) => 0x863230
       m1 = GetFreeMemForAllocateMemory() => 0x315278
       _FreeMemory(p)
       m2 = GetFreeMemForAllocateMemory() => 0x335284
[Pass] ABS((m0-m1) - 128*1024) => 0xc
[Pass] ABS(m0-m2) => 0x0
       m01 = MALLOC_FREE_MEMORY => 0x38a18
       m02 = GetFreeMemForAllocateMemory() => 0x335284
[Pass] p = (void*)_alloc_dma_memory(128*1024) => 0x40863270
[Pass] UNCACHEABLE(p) => 0x40863270
[Pass] CACHEABLE(p) => 0x863270
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x40863270
       _free_dma_memory(p)
[Pass] p = (void*)_shoot_malloc(16*1024*1024) => 0x4de1a074
[Pass] UNCACHEABLE(p) => 0x4de1a074
       _shoot_free(p)
       m11 = MALLOC_FREE_MEMORY => 0x38a18
       m12 = GetFreeMemForAllocateMemory() => 0x335284
[Pass] ABS(m01-m11) => 0x0
[Pass] ABS(m02-m12) => 0x0
[Pass] suite = shoot_malloc_suite_contig(16*1024*1024) => 0x130648
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1000000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x130670
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1000000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite_contig(0) => 0x130648
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x12b4000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x130670
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x12b4000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       largest_shoot_block = suite->size => 0x12b4000
[INFO] largest_shoot_block: 19MB
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(largest_shoot_block + 1024*1024) => 0x130648
[Pass] suite->signature => 'MemSuite'
[FAIL] suite->num_chunks => 0x1
[Pass] suite->size => 0x13b4000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x130670
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x13b4000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x13b4000
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(0) => 0x130648
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x3
[Pass] suite->size => 0x1700000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x130670
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x13b4000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
       chunk = GetNextMemoryChunk(suite, chunk) => 0x136e58
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x149c000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4ae00064
[Pass] UNCACHEABLE(p) => 0x4ae00064
       chunk = GetNextMemoryChunk(suite, chunk) => 0x136e90
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1700000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x419ff0a4
[Pass] UNCACHEABLE(p) => 0x419ff0a4
       chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x1700000
       shoot_free_suite(suite); suite = 0; chunk = 0;
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[FAIL] suite->num_chunks => 0x1
[Pass] strlen("abc") => 0x3
[Pass] strlen("qwertyuiop") => 0xa
[Pass] strlen("") => 0x0
[Pass] strcpy(msg, "hi there") => 0x213d3c
[Pass] msg => 'hi there'
[Pass] snprintf(a, sizeof(a), "foo") => 0x3
[Pass] snprintf(b, sizeof(b), "foo") => 0x3
[Pass] strcmp(a, b) => 0x0
[Pass] snprintf(a, sizeof(a), "bar") => 0x3
[Pass] snprintf(b, sizeof(b), "baz") => 0x3
[Pass] strcmp(a, b) => 0xfffffff8
[Pass] snprintf(a, sizeof(a), "Display") => 0x7
[Pass] snprintf(b, sizeof(b), "Defishing") => 0x9
[Pass] strcmp(a, b) => 0x4
[Pass] snprintf(buf, 3, "%d", 1234) => 0x2
[Pass] buf => '12'
[Pass] memcpy(foo, bar, 6) => 0x213d20
[Pass] foo => 'asdfghuiop'
[Pass] memset(bar, '*', 5) => 0x213d00
[Pass] bar => '*****hjkl;'
       bzero32(bar + 5, 5)
[Pass] bar => '****'
       EngDrvOut(LCD_Palette[0], 0x1234)
[Pass] shamem_read(LCD_Palette[0]) => 0x1234
       call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
       call("TurnOffDisplay")
[Pass] DISPLAY_IS_ON => 0x0
       call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
       task_create("test", 0x1c, 0x1000, test_task, 0) => 0xe96800ca
[Pass] test_task_created => 0x1
[Pass] get_current_task_name() => 'run_test'
[Pass] get_task_name_from_id(current_task->taskId) => 'run_test'
[Pass] task_max => 0x68
[Pass] task_max => 0x68
[Pass] mq = mq ? mq : (void*)msg_queue_create("test", 5) => 0xe96a00b6
[Pass] msg_queue_post(mq, 0x1234567) => 0x0
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x0
[Pass] m => 0x1234567
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x9
[Pass] sem = sem ? sem : create_named_semaphore("test", 1) => 0xe96c0200
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] take_semaphore(sem, 500) => 0x9
[Pass] give_semaphore(sem) => 0x0
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] give_semaphore(sem) => 0x0
[Pass] rlock = rlock ? rlock : CreateRecursiveLock(0) => 0xe96e00c8
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0xf
       SetGUIRequestMode(1); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x1
       SetGUIRequestMode(2); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x2
       SetGUIRequestMode(0); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x0
[Pass] display_idle() => 0x1
       GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[Pass] PLAY_MODE => 0x1
[Pass] MENU_MODE => 0x0
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(1000);
[Pass] MENU_MODE => 0x1
[Pass] PLAY_MODE => 0x0
[Pass] dialog->type => 'DIALOG'
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[Pass] PLAY_MODE => 0x0
       SW1(1,100)
[Pass] HALFSHUTTER_PRESSED => 0x1
       SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[FAIL] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x1
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
=========================================================
Test complete, 11349 passed, 41 failed.
.

So there were just 3 more fails on the EOSM2 on what looked like menu switching tasks. Probably relatively minor issues.

EOSM2 - LUATEST.LOG
Code: [Select]
===============================================================================
ML/SCRIPTS/API_TEST.LUA - 2018-2-27 03:16:50
===============================================================================

Strict mode tests...
Strict mode tests passed.

Generic tests...
arg = table:
  [0] = "API_TEST.LUA"
camera = table:
  shutter = table:
    raw = 104
    apex = 6.
    ms = 16
    value = 0.015625
  aperture = table:
    raw = 24
    apex = 2.
    value = 2.
    min = table:
      raw = 24
      apex = 2.
      value = 2.
    max = table:
      raw = 80
      apex = 9.
      value = 22.6
  iso = table:
    raw = 72
    apex = 5.
    value = 100
  ec = table:
    raw = 0
    value = 0
  flash_ec = table:
    raw = 0
    value = 0
  kelvin = 3200
  mode = 20
  metering_mode = 5
  drive_mode = 0
  model = "Canon EOS M2"
  model_short = "EOSM2"
  firmware = "1.0.3"
  temperature = 208
  gui = table:
    menu = false
    play = false
    play_photo = false
    play_movie = false
    qr = false
    idle = false
  reboot = function: p
  bulb = function: p
  burst = function: p
  shoot = function: p
  wait = function: p
event = table:
  pre_shoot = nil
  post_shoot = nil
  shoot_task = nil
  seconds_clock = nil
  keypress = nil
  custom_picture_taking = nil
  intervalometer = nil
  config_save = nil
console = table:
  write = function: p
  show = function: p
  clear = function: p
  hide = function: p
lv = table:
  enabled = true
  paused = false
  running = true
  zoom = 1
  overlays = false
  resume = function: p
  start = function: p
  pause = function: p
  info = function: p
  stop = function: p
  wait = function: p
lens = table:
  name = "EF-M22mm f/2 STM"
  focal_length = 22
  focus_distance = 655350
  hyperfocal = 12780
  dof_near = 12537
  dof_far = 1000000
  af = true
  af_mode = 0
  autofocus = function: p
  focus = function: p
display = table:
  idle = nil
  height = 480
  width = 720
  on = function: p
  screenshot = function: p
  print = function: p
  load = function: p
  pixel = function: p
  clear = function: p
  notify_box = function: p
  line = function: p
  rect = function: p
  draw = function: p
  circle = function: p
  off = function: p
key = table:
  last = 10
  press = function: p
  wait = function: p
menu = table:
  visible = false
  set = function: p
  block = function: p
  new = function: p
  close = function: p
  open = function: p
  select = function: p
  get = function: p
movie = table:
  recording = false
  stop = function: p
  start = function: p
dryos = table:
  clock = 19
  ms_clock = 19541
  image_prefix = "IMG_"
  dcim_dir = table:
    exists = true
    create = function: p
    children = function: p
    files = function: p
    parent = table:
      exists = true
      create = function: p
      children = function: p
      files = function: p
      parent = table:
        exists = true
        create = function: p
        children = function: p
        files = function: p
        parent = nil
        path = "B:/"
      path = "B:/DCIM/"
    path = "B:/DCIM/100CANON/"
  config_dir = table:
    exists = true
    create = function: p
    children = function: p
    files = function: p
    parent = table:
      exists = true
      create = function: p
      children = function: p
      files = function: p
      parent = table:
        exists = true
        create = function: p
        children = function: p
        files = function: p
        parent = nil
        path = "B:/"
      path = "ML/"
    path = "ML/SETTINGS/"
  ml_card = table:
    cluster_size = 32768
    drive_letter = "B"
    file_number = 7274
    folder_number = 100
    free_space = 30936992
    type = "SD"
    path = "B:/"
    _card_ptr = userdata
  shooting_card = table:
    cluster_size = 32768
    drive_letter = "B"
    file_number = 7274
    folder_number = 100
    free_space = 30936992
    type = "SD"
    path = "B:/"
    _card_ptr = userdata
  date = table:
    year = 2018
    sec = 51
    min = 16
    wday = 3
    month = 2
    isdst = false
    hour = 3
    yday = 58
    day = 27
  rename = function: p
  remove = function: p
  directory = function: p
  call = function: p
interval = table:
  time = 10
  count = 0
  running = false
  stop = function: p
battery = table:
function not available on this camera
stack traceback:
[C]: in ?
[C]: in for iterator 'for iterator'
ML/SCRIPTS/LIB/logger.lua:125: in function 'logger.serialize'
ML/SCRIPTS/API_TEST.LUA:36: in function <ML/SCRIPTS/API_TEST.LUA:35>
[C]: in function 'xpcall'
ML/SCRIPTS/API_TEST.LUA:35: in function 'print_table'
ML/SCRIPTS/API_TEST.LUA:81: in function 'generic_tests'
ML/SCRIPTS/API_TEST.LUA:1338: in function 'api_tests'
ML/SCRIPTS/API_TEST.LUA:1364: in main chunktask = table:
  yield = function: p
  create = function: p
property = table:
Generic tests completed.

Module tests...
Testing file I/O...
Copy test: autoexec.bin -> tmp.bin
Copy test OK
Append test: tmp.txt
Append test OK
Rename test: apple.txt -> banana.txt
Rename test OK
Rename test: apple.txt -> ML/banana.txt
Rename test OK
File I/O tests completed.

Testing Canon GUI functions...
Enter MENU mode...
Enter PLAY mode...
Enter MENU mode...
Enter MENU mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Exit PLAY mode...

EOSM - LUATEST.LOG
Code: [Select]
===============================================================================
ML/SCRIPTS/API_TEST.LUA - 2018-2-27 14:22:39
===============================================================================

Strict mode tests...
Strict mode tests passed.

Generic tests...
arg = table:
  [0] = "API_TEST.LUA"
camera = table:
  shutter = table:
    raw = 104
    apex = 6.
    ms = 16
    value = 0.015625
  aperture = table:
    raw = 24
    apex = 2.
    value = 2.
    min = table:
      raw = 24
      apex = 2.
      value = 2.
    max = table:
      raw = 80
      apex = 9.
      value = 22.6
  iso = table:
    raw = 72
    apex = 5.
    value = 100
  ec = table:
    raw = 0
    value = 0
  flash_ec = table:
    raw = 0
    value = 0
  kelvin = 6500
  mode = 20
  metering_mode = 5
  drive_mode = 0
  model = "Canon EOS M"
  model_short = "EOSM"
  firmware = "2.0.2"
  temperature = 218
  gui = table:
    menu = false
    play = false
    play_photo = false
    play_movie = false
    qr = false
    idle = true
  wait = function: p
  bulb = function: p
  burst = function: p
  shoot = function: p
  reboot = function: p
event = table:
  pre_shoot = nil
  post_shoot = nil
  shoot_task = nil
  seconds_clock = nil
  keypress = nil
  custom_picture_taking = nil
  intervalometer = nil
  config_save = nil
console = table:
  write = function: p
  show = function: p
  clear = function: p
  hide = function: p
lv = table:
  enabled = true
  paused = false
  running = true
  zoom = 1
  overlays = 2
  pause = function: p
  stop = function: p
  info = function: p
  resume = function: p
  wait = function: p
  start = function: p
lens = table:
  name = "EF-M22mm f/2 STM"
  focal_length = 22
  focus_distance = 320
  hyperfocal = 12780
  dof_near = 314
  dof_far = 326
  af = true
  af_mode = 0
  focus = function: p
  autofocus = function: p
display = table:
  idle = nil
  height = 480
  width = 720
  pixel = function: p
  rect = function: p
  clear = function: p
  on = function: p
  draw = function: p
  off = function: p
  print = function: p
  circle = function: p
  screenshot = function: p
  line = function: p
  load = function: p
  notify_box = function: p
key = table:
  last = 9
  press = function: p
  wait = function: p
menu = table:
  visible = false
  block = function: p
  get = function: p
  new = function: p
  select = function: p
  set = function: p
  close = function: p
  open = function: p
movie = table:
  recording = false
  start = function: p
  stop = function: p
dryos = table:
  clock = 18
  ms_clock = 18171
  image_prefix = "IMG_"
  dcim_dir = table:
    exists = true
    create = function: p
    children = function: p
    files = function: p
    parent = table:
      exists = true
      create = function: p
      children = function: p
      files = function: p
      parent = table:
        exists = true
        create = function: p
        children = function: p
        files = function: p
        parent = nil
        path = "B:/"
      path = "B:/DCIM/"
    path = "B:/DCIM/100CANON/"
  config_dir = table:
    exists = true
    create = function: p
    children = function: p
    files = function: p
    parent = table:
      exists = true
      create = function: p
      children = function: p
      files = function: p
      parent = table:
        exists = true
        create = function: p
        children = function: p
        files = function: p
        parent = nil
        path = "B:/"
      path = "ML/"
    path = "ML/SETTINGS/"
  ml_card = table:
    cluster_size = 32768
    drive_letter = "B"
    file_number = 5922
    folder_number = 100
    free_space = 31071520
    type = "SD"
    path = "B:/"
    _card_ptr = userdata
  shooting_card = table:
    cluster_size = 32768
    drive_letter = "B"
    file_number = 5922
    folder_number = 100
    free_space = 31071520
    type = "SD"
    path = "B:/"
    _card_ptr = userdata
  date = table:
    sec = 41
    month = 2
    min = 22
    year = 2018
    hour = 14
    day = 27
    wday = 3
    isdst = false
    yday = 58
  directory = function: p
  remove = function: p
  call = function: p
  rename = function: p
interval = table:
  time = 10
  count = 0
  running = false
  stop = function: p
battery = table:
function not available on this camera
stack traceback:
[C]: in ?
[C]: in for iterator 'for iterator'
ML/SCRIPTS/LIB/logger.lua:125: in function 'logger.serialize'
ML/SCRIPTS/API_TEST.LUA:36: in function <ML/SCRIPTS/API_TEST.LUA:35>
[C]: in function 'globals.xpcall'
ML/SCRIPTS/API_TEST.LUA:35: in function 'globals.print_table'
ML/SCRIPTS/API_TEST.LUA:81: in function 'globals.generic_tests'
ML/SCRIPTS/API_TEST.LUA:1338: in function 'globals.api_tests'
ML/SCRIPTS/API_TEST.LUA:1364: in main chunktask = table:
  create = function: p
  yield = function: p
property = table:
Generic tests completed.

Module tests...
Testing file I/O...
Copy test: autoexec.bin -> tmp.bin
Copy test OK
Append test: tmp.txt
Append test OK
Rename test: apple.txt -> banana.txt
Rename test OK
Rename test: apple.txt -> ML/banana.txt
Rename test OK
File I/O tests completed.

Testing Canon GUI functions...
Pause LiveView...
Resume LiveView...
Enter MENU mode...
Enter PLAY mode...
Exit PLAY mode...

The cameras were sitting next to each other during these tests so it does look like there's something going on with the lens = table block but again, nothing major is standing out.

Comparing the test results against the original EOSM there aren't many issues that these tests are revealing that are issues unique to the EOSM2.

The benchmark tests are also working and it is showing that the EOSM2 is pretty much the same as the other ML supported APS-C Digic 5 cameras.

(https://farm5.staticflickr.com/4667/26637164298_51209d2c46.jpg) (https://flic.kr/p/GzQqVq)
Title: ML on EOS-M2
Post by: DeafEyeJedi on March 04, 2018, 12:34:00 AM
Better late than never... finally got the EOS-M2 back and you can definitely count me in for any crash course test you dare to throw upon per your request. I’ll be keeping an eye on this thread exclusively from here on out, @dfort!
Title: Re: ML on EOS-M2
Post by: pureaxis on March 06, 2018, 10:47:00 PM
I'm ready to fire up my EOS M2 as well, just having peaking would be great! ;)
Title: Re: ML on EOS-M2
Post by: dfort on March 07, 2018, 07:01:33 PM
If you have an EOSM2 and want to jump on the Magic Lantern train, there's no secrets here. I haven't posted any test builds yet because I feel that it is not yet ready for user feedback. I mean the first time you shoot a picture with ML installed the screen will freeze, picture looks good though!

Ok, so this is how to get it. First set up your computer to compile Magic Lantern. Don't freak out, it is really easy if you follow either my Mac (https://www.magiclantern.fm/forum/index.php?topic=16012.0) or Cygwin (https://www.magiclantern.fm/forum/index.php?topic=15894.0) (for Windows) tutorials. If you are on Windows 10 you can set up a Linux subsystem (https://www.magiclantern.fm/forum/index.php?topic=20214.0) and if you're on Linux, well then you probably don't need my help.

I use and recommend the Sourcetree app (https://www.sourcetreeapp.com/).

If you just want to get ML installed on your EOSM2 in a hurry, here's how to do it once you have your development environment working. You can copy and paste these commands into your terminal window:

Code: [Select]
# Making sure you are in the directory where you want to install the repository--
# This will install my repository in one named magic-lantern-dfort so it doesn't clobber
# magic-lantern repository you may already have:
hg clone https://bitbucket.org/daniel_fort/magic-lantern magic-lantern-dfort

# Now let's get to the EOSM2 branch and compile it
cd magic-lantern-dfort
hg update EOSM2.103_crop_rec_4k_wip
cd platform/EOSM2.103/
make

# All good? If you have a card reader you can install directly to the SD card like this:
make install

# If you want to make a zip file just like on the nightly downloads do this
make zip

# The file will be named magiclantern-Nightly with the date and camera information in the filename

# Once you are done clean up your mess
make clean

You'll want to make sure you have the latest changes. To pick them up do this:

Code: [Select]
hg pull
hg update

Got it?
Title: Re: ML on EOS-M2
Post by: dfort on March 24, 2018, 12:24:42 AM
Still stuck trying to figure out why the camera is locking up when shooting stills. Played around on QEMU and am seeing things I've never seen before--LiveView! Well, sort of:

ML LiveView
(https://farm1.staticflickr.com/800/40935117952_8b454c9d2c.jpg) (https://flic.kr/p/25nibpJ)

One of Canon LiveView screens
(https://farm5.staticflickr.com/4779/40935117892_053990019f.jpg) (https://flic.kr/p/25niboG)

Never seen these menus show up on QEMU before:
(https://farm1.staticflickr.com/787/40976460631_c2efc0470f.jpg) (https://flic.kr/p/25qX59x)
Title: Re: ML on EOS-M2
Post by: chrissul13 on April 10, 2018, 06:17:19 AM
Following for update.  Hopefully something soon? 
Title: Re: ML on EOS-M2
Post by: dfort on April 10, 2018, 07:47:49 AM
I've been doing some firmware updates on other cameras to see if maybe it serves as practice to solve the problems I ran into on the M2. Any help would be greatly appreciated.
Title: Re: ML on EOS-M2
Post by: pureaxis on April 11, 2018, 11:22:44 PM
Unfortunately I don't know enough about coding but I'd be happy to test builds compiled by others.
Title: Re: ML on EOS-M2
Post by: chrissul13 on April 26, 2018, 07:01:25 AM
I would be so happy to just get focus peaking.  I have a lot of old M42 mount lenses and they are hard to focus quickly on the screen.  can't wait for a bit more progress here!  Thanks again!
Title: Re: ML on EOS-M2
Post by: dfort on April 26, 2018, 05:09:56 PM
I can't wait for more progress here either.

There has been no progress because I can't figure out how to track down the current issues. It is working quite well in QEMU but it crashes when shooting pictures or video. However, silent stills sort of works. In any case, I hesitantly just posted a test build of the crop_rec_4k branch which is the one that is almost working.

https://bitbucket.org/daniel_fort/magic-lantern/downloads/

BTW--Still welcoming anyone with an M2 willing to set up a development platform and help search for the last few pieces of the puzzle.
Title: Re: ML on EOS-M2
Post by: chrissul13 on April 26, 2018, 08:09:45 PM
I would love to volunteer.  I'm going to try the test build as soon as i'm able today but i'm not sure i have much experience to help.  Here's hoping!  Thanks for all of your hard work
Title: Re: ML on EOS-M2
Post by: pureaxis on June 12, 2018, 05:56:47 PM
I can't wait for more progress here either.

There has been no progress because I can't figure out how to track down the current issues. It is working quite well in QEMU but it crashes when shooting pictures or video. However, silent stills sort of works. In any case, I hesitantly just posted a test build of the crop_rec_4k branch which is the one that is almost working.

https://bitbucket.org/daniel_fort/magic-lantern/downloads/

BTW--Still welcoming anyone with an M2 willing to set up a development platform and help search for the last few pieces of the puzzle.

Tested on my camera, I seem to be only able to enter ML menu from C1 and not video mode. Could not get raw or crop mode working.
Title: Re: ML on EOS-M2
Post by: chrissul13 on August 06, 2018, 05:41:07 AM
Found a refurbished 550D for $87 and couldn't turn it down..just for ML.  Now i'm really seeing what i wanted in the M2.  Here's hoping for some progress soon.
Title: Re: ML on EOS-M2
Post by: dfort on August 06, 2018, 05:37:33 PM
Here's hoping for some progress soon.

There has been some progress though nothing big to report--like ML is actually working properly on the M2. A few bad stubs were found by critix and I merged in the latest qemu branch to the work in progress code in order to make it easier to compile builds for either the camera or emulator.

For what its worth there's a new test build on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).
Title: Re: ML on EOS-M2
Post by: uizin on August 09, 2018, 03:44:21 PM
Great! Good to know another piece of the puzzle is sorted out!
Guys do not stop you great work! :)
Title: Re: ML on EOS-M2
Post by: pureaxis on August 13, 2018, 04:29:18 PM
tried the new update, can't get much to work but I'm glad there is progress!
Title: Re: ML on EOS-M2
Post by: dfort on September 07, 2018, 04:45:03 PM
Just a quick announcement--

Since I've been stuck trying to figure out what is causing the instability issues on the EOSM2 ML port for a long time and no other developer seems to have access to this camera, I shipped my EOSM2 to @critix. He has been doing a great job on the 1300D though that camera is also in development hell (https://en.wikipedia.org/wiki/Development_hell). (Ok--that link is the movie industry definition of "development hell" but it is close enough.)
Title: Re: ML on EOS-M2
Post by: Skozyashiy on September 19, 2018, 09:05:31 PM
Hi guys. What is the current status of the port? Does it contain any more or less stable functions? I mostly interested in timelapse..
Title: Re: ML on EOS-M2
Post by: Audionut on September 24, 2018, 06:31:14 AM
Hi guys. What is the current status of the port?

https://wiki.magiclantern.fm/faq#any_progress_on_xyz

https://www.magiclantern.fm/forum/index.php?topic=17253.0
Title: Re: ML on EOS-M2
Post by: Jenus on October 30, 2018, 01:59:33 AM
Just dropping in to say that it would be an amazing feat to get ML and focus peaking on my M2. If you need anyone for testing, just hit me up.
Title: Re: ML on EOS-M2
Post by: uizin on December 08, 2018, 07:51:45 AM
@critix did you receive dfort's M2? I'm in for testing too!
Thank you for your efforts guys! :)
Title: Re: ML on EOS-M2
Post by: critix on December 08, 2018, 08:17:11 AM
Yes. I'm working it...
Can you test this?
https://bitbucket.org/ccritix/magic-lantern/downloads/magic-lantern-crop_rec_4k_mlv_snd_isogain_1x3.2018Dec07.EOSM2103.zip (https://bitbucket.org/ccritix/magic-lantern/downloads/magic-lantern-crop_rec_4k_mlv_snd_isogain_1x3.2018Dec07.EOSM2103.zip)
Title: Re: ML on EOS-M2
Post by: JohanJ on December 08, 2018, 04:23:08 PM
And there is definitively progress! Great work @critix and @dfort!

Critix, your test build does not include a FIR file. I picket the one from dforts latest M2 version on his download page and that worked fine to activate bootflag in the cam. Since I am mostly into still photography I quickly made some test only in this area. Here are some very simple results. My set-up is M2 w/ EF-M 22mm, SanDisk ExtremePro 95 MB/s

NB: (+) positive (-) negative remark

1. (+) ML is able to boot in any shooting mode A+, C1, C2, movie. I used C2 for my quick tests.
2. (-) The ML default config makes live view freeze when panning. I mannaged to revive Liveview by pressing some buttons (no pattern), but it hung again after a while.
3. (+) Entering ML menu by holding trash can button works fine, also from frozen LV
4. (+) After inactivating all ML functions no more hanging in LiveView. I chose that method to activate ML functions one by one to narrow down the problem
5. (-) Leaving ML menu with "shoot" or "Menue" button brings you back to LV but there are no standard Canon overlays any more, not even AF indicators, just a clean LV. Pressing INFO button multiple times to switch between Canon LV modes does not change anything.
(6.) (+) BUT taking still pictures works fine
(7.) (+) Entering Canon Menu with Menu button and returning to LV brings back all stock overlays :)
(8.) (+) Activating "Global Draw in all modes" together with "Focus Peaking" works fine. Same behaviour when leaving ML menu described in (7.)
(9.) (+) Adding "Zebras" works fine too but brings up the known error messag "Raw error, falling back to YUV Overlays"
(10.) (---) Adding "Histogram" in RAW RGB, Log and BANG! LV freezes when panning!

(11.) (---) Same freezing LV when only "Histogram" is activated in "Global Draw in all modes". So histogram seems to be the bad guy.
So far my simple tests. I hope I can contribute more later on.
Title: Re: ML on EOS-M2
Post by: Danne on December 08, 2018, 04:51:22 PM
Is raw recording working as well?
Title: Re: ML on EOS-M2
Post by: critix on December 08, 2018, 05:16:32 PM
No, raw recording is not work...
Title: Re: ML on EOS-M2
Post by: JohanJ on December 08, 2018, 08:20:40 PM
Is raw recording working as well?
Well, mlv_lite creates an .MLV file but you get the the following assert
Code: [Select]
ML ASSERT:
0
at mlv_lite.c:2697 (compress_task), task compress_task
lv:1 mode:0

compress_task stack: 216b88 [216c18-215c18]
0x0044C9B0 @ af2fc8:216bb8
0x0044C478 @ 44ca0c:216b88

Magic Lantern version : Nightly.2018Dec07.EOSM2103
Mercurial changeset   : 061afdbde1ad+ (crop_rec_4k_mlv_snd_isogain_1x3_presets) tip
Built on 2018-12-07 09:42:05 UTC by [email protected]
Free Memory  : 383K + 1846K


I did not look into the file as such.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 08, 2018, 08:33:55 PM
I would be so happy to just get focus peaking.  I have a lot of old M42 mount lenses and they are hard to focus quickly on the screen.  can't wait for a bit more progress here!  Thanks again!
You should test the latest build Critix published today. Focus peaking seems stable to me.
Title: Re: ML on EOS-M2
Post by: pureaxis on December 09, 2018, 04:29:27 AM
wow good to see renewed progress, will test this build soon  :D
Title: Re: ML on EOS-M2
Post by: dfort on December 09, 2018, 07:16:39 AM
Looks like this is where the assert message is coming from -- mlv_lite.c line 2697

Code: [Select]
            /* only report compression errors while recording
             * some of them appear during video mode switches
             * unlikely to cause actual trouble - silence them for now */
            if (compressed_size < 0 && !RAW_IS_IDLE)
            {
                printf("Compression error %d at frame %d\n", compressed_size, frame_count-1);
                ASSERT(0);
            }

Have you tried other compression settings? Maybe uncompressed 14-bit? See if you get a different assert log.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 09, 2018, 03:11:11 PM
Have you tried other compression settings? Maybe uncompressed 14-bit? See if you get a different assert log.
You are right dfort. I did not check the default settings, just kicked on mlv_lite to see what would happen.

Default was 14 bit loosless which explains the error message. Changing to 10 /12 / 14 bit uncompressed does not create any assert. 12 and 14 bit uncompressed  freezes LV instantly, but creates a file. 10 bits uncompressed seems to work w/ liveview.
Unfortunately I do not have the time to dig into it more deeply right now (posting all settings and so on).  So this is the right moment where all MLV_LITE experts should join the party. There is defenitivley a good base for intensive testing.
Title: Re: ML on EOS-M2
Post by: Walter Schulz on December 09, 2018, 03:31:21 PM
ML settings are stored in ML/Settings directory. Zip, upload somewhere and link it.
Title: Re: ML on EOS-M2
Post by: uizin on December 09, 2018, 10:36:11 PM
Thanks @critix and @dfort for the great job!

I am trying this build on my M2: focus peaking and zebras work fine.
@JohanJ, I am not experiencing LV freezes with Histogram enabled.

Also, I noticed that in C2 I can not enter the settings menu, because when I hold the trash button, the Canon ISO selection comes up.

I'll keep testing!  :)
Title: Re: ML on EOS-M2
Post by: JohanJ on December 09, 2018, 11:12:51 PM
Also, I noticed that in C2 I can not enter the settings menu, because when I hold the trash button, the Canon ISO selection comes up.
Go to Canon Menu C.FnIV Operation/Others (6) "Trash Can button" and change your setting from 2:ISO speed to 0:Normal
This should do the trick to enter ML menu.
Title: Re: ML on EOS-M2
Post by: uizin on December 10, 2018, 02:15:44 PM
Yes @JohanJ! I had that setting and confirm that it works also in C2 now. I think I will keep the custom setting to quickly select the ISO, otherwise I'll need to browse in the menus...
Title: Re: ML on EOS-M2
Post by: dfort on December 12, 2018, 02:49:36 AM
I've been stuck on this port for a while but now @critix and @Danne are working on it and we've got at least three users willing to test. Keep checking on this topic for progress reports.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 12, 2018, 02:21:13 PM
Yes @JohanJ! I had that setting and confirm that it works also in C2 now. I think I will keep the custom setting to quickly select the ISO, otherwise I'll need to browse in the menus...
Right. That comment was helpful! My first thought was that you are probaly not shooting stills in RAW format. Maybe you do. But the freezing has to do with RAW parameters for certain  ML overlays!

Both "histogram" and "spotmeter" have parameters for RAW data analysis. As soon as you set RAW depending parameters the LV tends to freeze w/ moving objects or half-shutter pressed moving or simple panning. Tipping half-shutter again refreshes LV.
High ISO values seem to speed the freezing. But here I am not sure I have to test more carefully.

Anyway when using overlays with RGB or non RAW based parameters there is no freezing  at all. I can even add more overlays same time - no problem when shooting stills.

Hope this can help.

Sent from my SM-G930F using Tapatalk

Title: Re: ML on EOS-M2
Post by: Danne on December 12, 2018, 03:47:02 PM
Having way to little time on my hands but read through this thread, grasping maybe one third of it, realizing what hard work was put into these initial stages from dfort and A1ex. Wanting to pin down the freezing issue I tried looking around in raw.c, and mlv_lite.c to see if anything related to the issue was to be find in there. Maybe something can come out of what I tested so far.
Enabling mlv_lite seems ok, and once it sets resolution there are a few moments before something is updated and then the freeze kicks in. In mlv_lite.c there´s a module:
Code: [Select]
MODULE_CBR(CBR_SHOOT_TASK, raw_rec_polling_cbr, 0)Not sure where that leads into(shoot.c) and maybe more places but if I comment out the module mlv_lite won´t freeze when starting RAW video. Then again that is probably because resolution stays at 0x0 so what´s there to freeze. However by sharing this information maybe we can continue trace where raw video is failing? A1ex might have a suggestion or two about what is going on here hopefully. Write channel issues?
Working from this branch:
https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/24/eosm2103-crop-rec-4k-wip/diff


EDIT:
Managed to record a MLV with footage on:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/M12-1727.MLV

Not sure how but I started disabling stuff in RAW video menu. Set to real-time etc. Restarting camera let me record corrupted MLV files and liveview freezes but it´s start...

Title: Re: ML on EOS-M2
Post by: Danne on December 12, 2018, 04:36:32 PM
Working 10bit video!
https://bitbucket.org/Dannephoto/magic-lantern/downloads/M12-1737.MLV

I erased this in mlv_lite.c:
Code: [Select]
    MODULE_CONFIG(resolution_index_x)and manage to record in 10bit. Probably works with 12 and 14bit too. Lossless giving corrupted files and freezed screen. Screen freezes more less always when recording raw.
Question. Are recording in mv1080p already, reason for freezes? Sure looks like it.

mv1080p(somebody needs to check the mlv file, I have to run)?
(https://i.postimg.cc/FzHjNxk5/Screenshot-2018-12-12-at-16-45-44-png-scaled.png)
Title: Re: ML on EOS-M2
Post by: dfort on December 12, 2018, 05:09:56 PM
Yay!

mlv_dump -v M12-1737.MLV
Code: [Select]
Block: RAWI
...
    Res:  1736x584
    raw_info:
      api_version      0x00000001
      height           727
      width            1808
...
Block: RAWC
...
    raw_capture_info:
      sensor res      5184x3456
      sensor crop     1.62 (APS-C)
      sampling        5x3 (read 1 line, skip 4, bin 3 columns)
Block: IDNT
...
     Camera Name:   'Canon EOS M2'
...
     Camera Model:  0x80000355

Image looks good -- especially considering the 5x3 sampling.

(https://farm5.staticflickr.com/4820/32416632158_1e7893a8f0.jpg) (https://flic.kr/p/RoxHn1)

Look at those focus pixels!

(https://farm5.staticflickr.com/4848/32416632618_839627699e.jpg) (https://flic.kr/p/RoxHuW)

Question. Are recording in mv1080p already, reason for freezes? Sure looks like it.

No, this is definitely mv720.
Title: Re: ML on EOS-M2
Post by: Danne on December 12, 2018, 09:17:27 PM
Got this when taking a cr2 still image in movie mode:
Code: [Select]
ML ASSERT:
0
at ../../src/raw.c:669 (raw_lv_realloc_buffer), task shoot_task
lv:1 mode:3

shoot_task stack: 213a30 [213c08-211c08]
0x00496BA8 @ 4771f8:213ba0
0xUNKNOWN  @ 496bfc:213b88
0x00B03948 @ b05194:213b18
0x0048CFA4 @ b03998:213b08
0x0048CF64 @ 48cfa8:213af0
0x0048C598 @ 48cf7c:213ae0
0x0048A3F0 @ 48c638:213a80
0x0044C8CC @ 48a54c:213a60
0x0044C478 @ 44c928:213a30

Magic Lantern version : Nightly.2018Dec12.EOSM2103
Mercurial changeset   : 88eba9bdb6c8+ (EOSM2.103_crop_rec_4k_wip)
Built on 2018-12-12 14:55:58 UTC by [email protected]
Free Memory  : 379K + 1867K

When shooting in 14bit lossless:
Code: [Select]
ML ASSERT:
0
at mlv_lite.c:2697 (compress_task), task compress_task
lv:1 mode:3

compress_task stack: 216b88 [216c18-215c18]
0x0044C8CC @ b0a698:216bb8
0x0044C478 @ 44c928:216b88

Magic Lantern version : Nightly.2018Dec12.EOSM2103
Mercurial changeset   : 88eba9bdb6c8+ (EOSM2.103_crop_rec_4k_wip)
Built on 2018-12-12 14:55:58 UTC by [email protected]
Free Memory  : 379K + 1930K
Title: Re: ML on EOS-M2
Post by: uizin on December 12, 2018, 11:40:04 PM
Right. That comment was helpful! My first thought was that you are probaly not shooting stills in RAW format. Maybe you do. But the freezing has to do with RAW parameters for certain  ML overlays!

Yes! I was shooting in jpg. Switching to RAW I experience freezing too. I confirm that in jpg LV is more stable.
Title: Re: ML on EOS-M2
Post by: dfort on December 13, 2018, 08:15:53 AM
What might help track down these issues is using one of the logging branches:

Code: [Select]
EOSM2.103_dm-spy-experiments 18168:e8396696980f
EOSM2.103_io_trace         18167:d5a0e069c803
EOSM2.103_io_trace_full    18166:4a41ee21b185
Title: Re: ML on EOS-M2
Post by: Danne on December 13, 2018, 10:11:10 AM
Yes, gotta nail down the bug. Lossless is not working at all. Do we have the correct raw buffer for lossless?

Here is mv1080p by the way, 10bit:
MLV file:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/EOSM2_mv1080p.MLV


(https://i.postimg.cc/XYSVthcy/Screenshot-2018-12-13-at-10-09-08-png-scaled.png)


It´s like registers are moving around and either it´s coded to freeze somewhere or the freeze occurs as a result of faulty registers? Also noted that shamem registers cannot be read in raw.c like with eosm. Or maybe something else is going on. Maybe adtg registers not applied...

Trying to see if registers are added in raw.c:
Code: [Select]
NotifyBox(5000, "shamem_read(0xC0F07150) 0x%x", shamem_read(0xC0F07150));

In crop_rec.c:
Code: [Select]
static inline uint32_t reg_override_3x3_eosm2(uint32_t reg, uint32_t old_val)
{
    switch (reg)
    {
        case 0xC0F06804: return 0x4a601d4;
case 0xC0F37014: return 0xe;
        case 0xC0F0713c: return 0x4a7;
case 0xC0F07150: return 0x475;
    }

    return 0;

}

Adding the notifybox above yields a very short flash showing 0x455(not 475 which it should) of the register and then it´s back to its origin which is 0x2d8. Set registers isn´t hooked here.

This works obviously since we are getting stretched liveview:
Code: [Select]
     case CROP_PRESET_3x3_mv1080_EOSM2:
adtg_new[0] = (struct adtg_new) {6, 0x800C, 2};
break;


On a sidenote. When adtg_gui is enabled, engio registers and show known registers the 10bit liveview will be less prone to get stuck. This gives more stable recordings. Somehow adtg_gui is having some stabilizing effect here.
Title: Re: ML on EOS-M2
Post by: dfort on December 13, 2018, 06:14:12 PM
Do we have the correct raw buffer for lossless?

I don't know but this might be related. There are only two resources groups and I figured the M2 belongs to the first group but maybe not? Maybe it doesn't fit into either group? I'm not sure how to verify this.

modules/silent/lossless.c
Code: [Select]
    if (is_camera("700D", "*") || is_camera("650D", "*") || is_camera("EOSM", "*") || is_camera("EOSM2", "*") || is_camera("100D", "*"))
    {
        uint32_t resources[] = {
            0x00000 | edmac_channel_to_index(edmac_write_chan),
            0x10000 | edmac_channel_to_index(edmac_read_chan),
            0x20005,
            0x20016,
            0x30002,
            0x50034,
            0x5002d,
            0x50010,
            0x90001,
            0x90000,
            0xa0000,
            0x160000,
            0x260000,
            0x260001,
            0x260002,
            0x260003,
        };

        TTL_ResLock = CreateResLockEntry(resources, COUNT(resources));
    }
    else if (is_camera("5D3", "*") || is_camera("6D", "*") || is_camera("70D", "*"))
    {
        uint32_t resources[] = {
            0x00000 | edmac_channel_to_index(edmac_write_chan),
            0x10000 | edmac_channel_to_index(edmac_read_chan),
            0x30001,    /* Read connection 1 (uncompressed input) */
            0x2002d,    /* Write connection 45 (compressed output) */
          //0x20016,    /* Write connection 22 (for WR2 - not used) */
            0x50034,
            0x5002d,
            0x50010,
            0x90001,
            0x230000,
            0x160000,
            0x260000,
            0x260001,
            0x260002,
            0x260003,
        };
Title: Re: ML on EOS-M2
Post by: Danne on December 14, 2018, 11:48:35 AM
Kind of nailed down where to look further for the liveview freezing on the eosm2. Seems to have to do with raw_slurp:
Maybe these registers are faulty?
Code: [Select]
#ifdef CONFIG_EOSM2
#define DEFAULT_RAW_BUFFER MEM(0x91CF0 + 0x78)
#define DEFAULT_RAW_BUFFER_SIZE (0x48C00000 - 0x48798100)
#endif

Anyway. What I did was checking different parts in raw.c and then came in here:
Code: [Select]
#ifdef CONFIG_EDMAC_RAW_SLURP

void FAST raw_lv_vsync()
{
    /* where should we save the raw data? */
    void* buf = redirected_raw_buffer ? redirected_raw_buffer : raw_get_default_lv_buffer();
   
    if (buf && lv_raw_enabled)
    {
        /* this needs to be set for every single frame */
        EngDrvOut(RAW_TYPE_REGISTER, lv_raw_type);

        if (lv_raw_gain)
        {
            /* optional - adjust digital gain */
            /* fixme: hardcoded for 5D3 */
            EngDrvOut(RAW_TYPE_REGISTER, 0x12);
            EngDrvOut(SHAD_GAIN_REGISTER, lv_raw_gain);
        }

        /* pull the raw data into "buf" */
        int width, height;
        int ok = raw_lv_get_resolution(&width, &height);
        if (ok)
        {
            int pitch = width * raw_info.bits_per_pixel / 8;
            if (raw_lv_buffer_size >= pitch * height)
            {
                edmac_raw_slurp(CACHEABLE(buf), pitch, height);
            }
        }
    }
   
    /* overriding the buffer is only valid for one frame */
    redirected_raw_buffer = 0;
}

Commenting out following leaves liveview alone and stops from freezing:
Code: [Select]
/* uncommenting keeps EOSM2 liveview from freezing */
        /* pull the raw data into "buf" */
        int width, height;
       /* int ok = raw_lv_get_resolution(&width, &height); */
       /* if (ok) */
       /* { */
           int pitch = width * raw_info.bits_per_pixel / 8;
          /*  if (raw_lv_buffer_size >= pitch * height) */
          /*  { */
                /* edmac_raw_slurp(CACHEABLE(buf), pitch, height); */
           /* } */
       /* } */
        }


New code part looks like this:
Code: [Select]
#ifdef CONFIG_EDMAC_RAW_SLURP

void FAST raw_lv_vsync()
{
    /* where should we save the raw data? */
    void* buf = redirected_raw_buffer ? redirected_raw_buffer : raw_get_default_lv_buffer();
   
    if (buf && lv_raw_enabled)
    {
        /* this needs to be set for every single frame */
        EngDrvOut(RAW_TYPE_REGISTER, lv_raw_type);

        if (lv_raw_gain)
        {
            /* optional - adjust digital gain */
            /* fixme: hardcoded for 5D3 */
            EngDrvOut(RAW_TYPE_REGISTER, 0x12);
            EngDrvOut(SHAD_GAIN_REGISTER, lv_raw_gain);
        }

/* uncommenting keeps EOSM2 liveview from freezing */
        /* pull the raw data into "buf" */
        int width, height;
       /* int ok = raw_lv_get_resolution(&width, &height); */
       /* if (ok) */
       /* { */
           int pitch = width * raw_info.bits_per_pixel / 8;
          /*  if (raw_lv_buffer_size >= pitch * height) */
          /*  { */
                /* edmac_raw_slurp(CACHEABLE(buf), pitch, height); */
           /* } */
       /* } */
    }
   
    /* overriding the buffer is only valid for one frame */
    redirected_raw_buffer = 0;
}

/* integer gain used to fix the image darkening caused by lv_raw_gain */
/* this gain must not (!) change the raw data */
int _raw_lv_get_iso_post_gain()
{
    if (lv_raw_gain)
    {
        return 4096 / lv_raw_gain;
    }

    return 1;
}
}
It sometimes has to be updated by pressing canon menu back and forth but it works recording 10bit, 12bit, 14bit files. Lossless is still an issue and so are certain registers from crop_rec which aren´t applied.
What next? A lot of time and testing. Hopefully a1ex can see something/pointing us a bit further.
Title: Re: ML on EOS-M2
Post by: critix on December 14, 2018, 01:35:35 PM
The values seem ok.
Code: [Select]
#ifdef CONFIG_EOSM2
#define DEFAULT_RAW_BUFFER MEM(0x91CF0 + 0x78)

About these do not know what to say :
Code: [Select]
#define DEFAULT_RAW_BUFFER_SIZE (0x48C00000 - 0x48798100)
#endif
Title: Re: ML on EOS-M2
Post by: Danne on December 14, 2018, 03:06:33 PM
Updated my uncommenting stuff above:
https://bitbucket.org/Dannephoto/magic-lantern/commits/1d378c7735b0d0ae5fc920e122ceffcdadf8b82e

This proves liveview can run without freezes but to the cost of corrupted footage also in 10-12bit.

So the redirect buffer I assume to make everything work is going here:
edmac-memcpy.c
Code: [Select]
void edmac_raw_slurp(void* dst, int w, int h)
{
    /* see wiki, register map, EDMAC what the flags mean. they are for setting up copy block size */
#if defined(CONFIG_650D) || defined(CONFIG_700D) || defined(CONFIG_EOSM2) || defined(CONFIG_EOSM) || defined(CONFIG_100D)
    uint32_t dmaFlags = EDMAC_2_BYTES_PER_TRANSFER;
#elif defined(CONFIG_6D)
    uint32_t dmaFlags = EDMAC_4_BYTES_PER_TRANSFER;
#else
    uint32_t dmaFlags = EDMAC_8_BYTES_PER_TRANSFER;
#endif

And to:
lv_rec.c
Code: [Select]
    {
        /* copy 2 byte per transfer */
        data.dmaFlags = 0x20000000;
        /* read from YUV connection */
        data.dmaSourceConn = 0x1B;
       
        /* no special treatment, save the exact size */
        save_data.frameSize = save_data.frameSizeReal;
        save_data.bottomDrop = 0;
    }

Since we are very close, or actually working, 10bit files there is the possibility of some interference somewhere else. Right now I have no idea where to go from this...

Title: Re: ML on EOS-M2
Post by: dfort on December 15, 2018, 12:50:23 AM
About these do not know what to say :
Code: [Select]
#define DEFAULT_RAW_BUFFER_SIZE (0x48C00000 - 0x48798100)

I'd say we found these values:

EOSM2: 48798100 - 48CC40C4

More about how we found it:

https://www.magiclantern.fm/forum/index.php?topic=5601.msg197778#msg197778

[EDIT] Yeah, it is confusing because the addresses are transposed and the first value is rounded down but if you check the other cameras you'll see that this should work for the EOSM2.
Title: Re: ML on EOS-M2
Post by: dfort on December 15, 2018, 02:21:12 AM
I won't have the EOSM2 in my hands until January but since there are users willing to be guinea pigs I'll start posting test builds on my Bitbucket downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/). Note that this is highly experimental--you've been warned.

Today's build was taken from Danne's latest changes as noted on Reply #332 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209312#msg209312).
Title: Re: ML on EOS-M2
Post by: dfort on December 15, 2018, 02:52:59 AM
What Danne is finding seems to point to a problem with the YUV addresses:

platform/EOSM2.103/consts.h
Code: [Select]
// Started out by using the one found value (0x4f3d7800)for all three as a workaround
// then adding 0x410000 to determine the other two.
// http://www.magiclantern.fm/forum/index.php?topic=15895.msg186493#msg186493
#define YUV422_LV_BUFFER_1 0x4F3D7800
#define YUV422_LV_BUFFER_2 0x4F7E7800
#define YUV422_LV_BUFFER_3 0x4FBF7800

// http://magiclantern.wikia.com/wiki/VRAM_ADDR_from_code
// stateobj_disp[1]
#define YUV422_LV_BUFFER_DISPLAY_ADDR (*(uint32_t*)(0x90494+0x12C))

#define REG_EDMAC_WRITE_LV_ADDR 0xC0F04208 // SDRAM address of LV buffer (aka VRAM)
#define REG_EDMAC_WRITE_HD_ADDR 0xC0F04108 // SDRAM address of HD buffer (aka YUV)

#define YUV422_HD_BUFFER_DMA_ADDR (shamem_read(REG_EDMAC_WRITE_HD_ADDR)) // first line from DMA is dummy

// http://magiclantern.wikia.com/wiki/ASM_Zedbra
// skipped for now, will come up with a way to autodetect these values
// http://www.magiclantern.fm/forum/index.php?topic=15895.msg186493#msg186493
#define YUV422_HD_BUFFER_1 0x44000080
#define YUV422_HD_BUFFER_2 0x46000080

We're using some placeholder values here but maybe they have already been found and I just don't know how to use this information?

EOS M2, QEMU:
...
Code: [Select]
  1160: 48852.480 [RSC] YUV                     0x4AEEA000 0x0222C000 35831808
  1161: 48852.480 [RSC] YUV_OUT                 0x42000000 0x0222C000 35831808
Title: Re: ML on EOS-M2
Post by: dfort on December 15, 2018, 04:46:16 PM
@uizin @pureaxis @Skozyashiy @Jenus @JohanJ @DeafEyeJedi @chrissul13 @vagaboundedu @platerytter @dacampora @bookemdano @orielsy @glassescreditsroll @jonkjon @godashram @bender @brocolimayo @Skylin3 @yazcui @Palpatine @neoplanta @GenMeiHikaru

And all other EOS M2 users "waiting" for Magic Lantern. After a long time of hearing, "Are we there yet? Are we there yet?" test builds have been posted (https://bitbucket.org/daniel_fort/magic-lantern/downloads/) and the developers are asking for your input.

We know it isn't quite ready for prime time but maybe the one or two features you're craving are working? How is focus peaking looking? Able to shoot a timelapse?

This is a community project and the more users can get involved the more this port will improve.

@a1ex - Any hints where to go from here? Seems like we're getting close but your direction works much better than invoking the infinite monkey theorem.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 15, 2018, 07:10:02 PM
Focus peaking worked just fine with the build I was checking out ;) I am travelling this weekend. Back on Tuesday. Will continue testing then for sure!

Sent from my SM-G930F using Tapatalk

Title: Re: ML on EOS-M2
Post by: uizin on December 16, 2018, 03:15:45 PM
I started testing overlay features! Dfort, thank you for your last build.

The camera has a vintage lens installed, so both aperture and focus are fully manual.
General comment: to enable overlays I need to enter and exit Canon menu after leaving ML menus.

When taking pictures in RAW, I get "RAW error, falling back to YUV overlays" message, but pictures are saved.
If I switch to JPG shooting, this message does not appear.

Many overlays work in LiveView in video mode, while in C2 mode I only see these overlays in QuickReview, even if "Global draw" in settings shows "ON, all modes".
(Zebras, spotmeter, False Colors, Histogram, Waveform).

Magic zoom
Flickers with all the settings combinations I tested. This happens both in video mode and C2 mode.

Focus Peak
Looks ok!

Cropmarks
Looks ok!

Vectorscope
Looks ok!

I also tried the Advanced Bracket and Intervalometer features, everything seems working.
I'm having strange feedbacks with Bulb Timer, I need to test more before reporting.

I think I'm not understanding how the "ExpSim" and "Expo. Override" settings work. I'll dig the forum to get a background on this ;)
As I'm new to ML (this is the only camera I can test on), I still have to understand many features, so sorry if I'm not being very useful.

I'm here to continue the tests, if you need something in particular, just ask! :)


Title: Re: ML on EOS-M2
Post by: dfort on December 16, 2018, 05:11:55 PM
@uizin - Excellent reporting!

When taking pictures in RAW, I get "RAW error, falling back to YUV overlays" message, but pictures are saved.
If I switch to JPG shooting, this message does not appear.

That's a good hint, I have also seen that on the EOSM2 and other cameras. Turn global draw off and shoot a CR2, does that still bring up the message? Have you tried shooting silent stills? That's where it was showing up when I reported it on the 5D3.113 crop_rec_4k branch (https://www.magiclantern.fm/forum/index.php?topic=18443.msg188744#msg188744).

General comment: to enable overlays I need to enter and exit Canon menu after leaving ML menus.
...
Many overlays work in LiveView in video mode, while in C2 mode I only see these overlays in QuickReview, even if "Global draw" in settings shows "ON, all modes".

I keep going back to the YUV values pointed out in Reply #335 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209332#msg209332) but am at a loss how to check these values.

Magic zoom
Flickers with all the settings combinations I tested. This happens both in video mode and C2 mode.

That issue has come up on other cameras too (https://bitbucket.org/hudson/magic-lantern/issues?q=magic+zoom). Last time it came up on the EOSM the fix was to tweak the fps timer values (https://bitbucket.org/hudson/magic-lantern/pull-requests/670/eosm-fps-engio-timer-fixes/diff). Well, at least I believe that's what finally fixed it--I may be wrong but looking at the code we're still using values copied from the EOSM as a place holder so the correct values still need to be found:

src/fps-engio.c
Code: [Select]
#elif defined(CONFIG_EOSM2) // using EOSM values for now
    #define TG_FREQ_BASE 32000000
    #define FPS_TIMER_A_MIN (ZOOM ? 716 : MV1080CROP ? 532 : 520)
    #undef FPS_TIMER_B_MIN
    #define FPS_TIMER_B_MIN ( \
    RECORDING_H264 ? (MV1080CROP ? 1750 : MV720 ? 990 : 1970) \
                   : (ZOOM || MV1080CROP ? 1336 : 1970))

There's also another assumption in fps-engio.c that may or may not be true:

src/fps-engio.c
Code: [Select]
    #if defined(CONFIG_EOSM) || defined(CONFIG_EOSM2)
    if (!RECORDING_H264) return 0;  /* EOS-M is stubborn, http://www.magiclantern.fm/forum/index.php?topic=5200.msg104816#msg104816 */
    #endif

Hum, that link goes to a discussion on Auto ETTR and doesn't explain why that line of code is necessary. At least I can't see the connection.
Title: Re: ML on EOS-M2
Post by: uizin on December 16, 2018, 08:20:49 PM
That's a good hint, I have also seen that on the EOSM2 and other cameras. Turn global draw off and shoot a CR2, does that still bring up the message? Have you tried shooting silent stills? That's where it was showing up when I reported it on the 5D3.113 crop_rec_4k branch (https://www.magiclantern.fm/forum/index.php?topic=18443.msg188744#msg188744).

Yes, if I turn off global draw there is no error message on the screen.

I tried the silent stills module (both in DNG and MLV): whit half shutter is pressed, LV shows a "Preparing..." message, but stops there and no file is saved on the card.
Title: Re: ML on EOS-M2
Post by: dfort on December 16, 2018, 11:33:43 PM
I tried the silent stills module (both in DNG and MLV): whit half shutter is pressed, LV shows a "Preparing..." message, but stops there and no file is saved on the card.

Ok, simple silent stills used to work (https://www.magiclantern.fm/forum/index.php?topic=15895.msg197781#msg197781) so we'll need to dig into that.
Title: Re: ML on EOS-M2
Post by: Danne on December 19, 2018, 02:01:58 PM
Ok, might have found the culprit to why liveview was freezing. It seems fps related. To test it do following:
Download following build:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_2018Dec19.EOSM2103.zip

1 - Enable  mlv_lite.mo
2 - Enable RAW video(screen will freeze)
3 - Set FPS override to 24
4 - Go to advanced inside FPS override and set following:
FPS timer A 574 (FT+46)

Hit canon menu button twice. Screen should not freeze now and you will be able to even record in lossless!

EDIT: These numbers needs more experimenting. Or updated in fps-engio of course.
Title: Re: ML on EOS-M2
Post by: dfort on December 19, 2018, 05:39:07 PM
Nice find. I mentioned in Reply #339 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209378#msg209378) that the timer values were copied from the EOSM and need to be updated. Not sure about the process but we had similar issues on the EOSM a while back.

Next on my list:

1. fps override - let's fix this first so nightly builds will work again. Dunno if anyone has played with overcranking on other builds, but the EOSM shoots up to 45fps 1080p (crop mode, h264, low-light method) it's pretty awesome. So let's get that back working again.

2. magic zoom is useless in crop mode, we need to slow it down to stop the flicker, - this is lower on my list of priorities since I can navigate with my external monitor attached now...

This is the pull request (https://bitbucket.org/hudson/magic-lantern/pull-requests/670/eosm-fps-engio-timer-fixes/diff) that fixed the timer values on the EOSM so maybe backtrack through the discussion. Note that it was also a problem on the 1100D (https://www.magiclantern.fm/forum/index.php?topic=1009.msg146321#msg146321) so checking out how that was resolved might help.
Title: Re: ML on EOS-M2
Post by: Danne on December 19, 2018, 07:00:10 PM
Cannot see any obvious from your posts dfort. Feel free to present a few numbers or any ideas what to do in fps-engio code.
Eosm2 is a pain in the ...
Title: Re: ML on EOS-M2
Post by: dfort on December 19, 2018, 08:35:30 PM
Maybe the 12 to 24 fps (FPS override Problem) (https://www.magiclantern.fm/forum/index.php?topic=14959.msg153212#msg153212) topic will provide the information we need?

Sorry, don't have the camera in my hands right now to run these tests.

Also:

We have 3 ways to proceed:

1) hardcode the resolutions (and get bitten by this Canon bug in other parts of the code)
2) reallocate this buffer from somewhere else (where?)
3) patch ENGIO routines to use ADD instead of ORR, to make them able to work on unaligned buffers

I'd try the last route first.

Ok, so patching worked but that means the EOSM2 depends on the patch manager to function. Wasn't option 2, reallocate this buffer, found here (https://www.magiclantern.fm/forum/index.php?topic=5601.msg197778#msg197778)?

EOSM2: 48798100 - 48CC40C4

Or is this unrelated?
Title: Re: ML on EOS-M2
Post by: dfort on December 20, 2018, 09:18:14 AM
Posted a new test build on my Bitbucket downloads page. (https://bitbucket.org/daniel_fort/magic-lantern/downloads/) Same disclaimer as always, this is highly experimental. This time I started with a clean raw_video_10bit_12bit branch and added just the pieces need to get the EOSM2 working.
Title: Re: ML on EOS-M2
Post by: uizin on December 20, 2018, 02:49:10 PM
@dfort do you need some specific tests on this build?
Title: Re: ML on EOS-M2
Post by: dfort on December 20, 2018, 05:16:30 PM
Never mind -- got a report that the new build I posted only does the LED blink thing so I took it down.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 21, 2018, 12:29:26 AM
Just trying to get an overview about the different builds published by @critix, @danne and @dfort so far. I feel a bit unsure how I should continue testing on which build. Took some RAW pictures and tested basics with all OVERLAY functions again on all three of these versions and came up with the following observation (again from a still photo point of view. Not that much MLV skills here - yet):

A build magic-lantern-crop_rec_4k_mlv_snd_isogain_1x3.2018Dec07.EOSM2103 (critix)
B build crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_2018Dec19.EOSM2103 (danne).
C build magiclantern-Nightly.2018Dec14.EOSM2103 (dfort)

A & B both show the same freezing effect in LV photo mode 2 as soon as overlays are activated based on RAW depending parameters (Histogram and/or Spotmeter - as discribed in post #321 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209269#msg209269))
C does not at all freeze in LV photomode even with activated histogram in RAW RGB, LOG while shooting RAW stills!  That's good!

So from that perspective I tend to continue testing w/ build C! But there is another minor observation, it is about lens information shown in the ML Overlay bar:

A build shows correctly focal lenght 22mm, also a varying focus distance as well as the DOF range when activated for LV.
B & C builds do not! Focal lenght is 0mm and focus distance is constantly 56m, DOF range is not shown at all, even when activated for LV. Something got lost in these builds!

Last but not least all builds have in common:
- DUAL-ISO module crashes for all builds directly after re-booting (some error messages are sent to the console. Will post them later)
- Leaving ML menue always requires doubble-press Canon menu button to get into photo mode with all overlays shown (see #308 comment 5)

Based on Build A I also did a bunch of tests for all funtions in Shoot / Focus / Display menue - mostly w/ positive results (as far as I recall). But I will wait for your hint what build should be the one to continue working with before spending time with texting (unnecessarily).

Title: Re: ML on EOS-M2
Post by: gukuangshi on December 21, 2018, 04:05:53 AM
Peak focus and zoom in focus work well on my eos m2 using MD 58 1.4 lens (magiclantern-Nightly.2018Dec14.EOSM2103). And the interval time-lapse is also great. But the temperature is growing fast,and the power consumption is fast. I hope that next vision will fix the high power consumption.  New functions such as digital interpolation zoom and trap focus are expected.  Please keep trying! We will do some test and feedback.
Title: Re: ML on EOS-M2
Post by: dfort on December 21, 2018, 08:51:57 AM
Excellent report! A+

Ok--so it looks like the "C" build is the most stable but it doesn't show the lens focal length. This is actually from Danne's crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2 branch with some of the lines in raw.c commented out.

Found the problem. The EOSM2 uses lens properties like the other Digic 5 cameras while the EOSM uses a different set of lens properties. Let's see if the December 20 build that is on my Bitbucket downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/) is any better.

Here's the commit (https://bitbucket.org/daniel_fort/magic-lantern/commits/624633b34a6a1e01cd21087e637744b3c27475ff) if anyone wants to see what's going on.
Title: Re: ML on EOS-M2
Post by: gukuangshi on December 21, 2018, 09:34:45 AM
magiclantern-Nightly.2018Dec20.EOSM2103.zip now is available for eos m2, I don’t find any deadly bug, and it works well on my camera. The temperature is rising fast and I wonder it can be solved or not. 
Title: Re: ML on EOS-M2
Post by: dfort on December 21, 2018, 05:53:18 PM
@gukuangshi - Welcome to the forum!

using MD 58 1.4 lens

You're using a Minolta MD Rokkor 50 mm f/1.4 (http://vintagelensreviews.com/vlr/reviews/minolta-md-rokkor-50-mm-f1-4-md-i/) or is it a MC Rokkor-PF 58 mm f/1.4 (http://vintagelensreviews.com/vlr/reviews/minolta-mc-rokkor-pf-58-mm-f1-4-mc-ii/)?

(https://farm5.staticflickr.com/4842/45495404515_b850b6be21_m.jpg) (https://flic.kr/p/2cjgQJ8)(https://farm5.staticflickr.com/4861/44591380690_d3fc2d6b87_m.jpg) (https://flic.kr/p/2aWotWs)

In any case, the ability to adapt so many different lenses is one of the strong points of this camera.

The temperature is rising fast and I wonder it can be solved or not. 

Using LiveView on any camera will raise the temperature and being a mirrorless camera it is always in LiveView mode. Now is ML causing the temperature faster than normal? Hard to see because the Canon overlays don't show the sensor temp. I don't have the EOSM2 in my hands at this time but what I did was to run this test on an EOSM. Turn on the camera with ML and checked the starting temperature, in my case 18C. Then pulled the card and turned on the camera and let it sit on LiveView for 1 minute, the temp rose to 24C. Let the camera cool back down to 18C and turned it on again this time with ML running for 1 minute--same results. Try it on the EOSM2, you should see the same results.

I hope that next vision will fix the high power consumption.

I'll let you figure out how to test this out, chances are power consumption will be pretty much the same whether or not you're using ML. Of course if you start using some of the advanced features like Danne's 100fps 4k feature  :P it will probably burn through batteries.

New functions such as digital interpolation zoom and trap focus are expected.

Don't expect too much right away, we're still trying to make a somewhat stable build for this camera. Check out the Feature comparison matrix (https://builds.magiclantern.fm/features.html) page. If a feature isn't working on the EOSM, it probably won't work on the EOSM2.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 21, 2018, 11:10:15 PM
Found the problem. The EOSM2 uses lens properties like the other Digic 5 cameras while the EOSM uses a different set of lens properties. Let's see if the December 20 build that is on my Bitbucket downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/) is any better.
I can confirm that lens focal information works perfectly with the new December 20 build! I will continue testing with this build (let's call it D) and will post results asap.

I promised earlier to post the error log from the crashing DUO-ISO module. Here we go:

Code: [Select]
Locking cache
Lens moving (1561,  0)
Scanning modules...
Load modules ...
  [i] Load:  dual_iso.mo
Linking ..
tcc: error: undefined symbol 'mlv_set_type'
  [E] failed to link modules
updating Movie Tweaks -> Movie Logging
updating Movie Tweaks -> Time indicator

Title: Re: ML on EOS-M2
Post by: dfort on December 22, 2018, 02:24:49 AM
Error reproduced on EOSM. New test build posted -- the winter solstice build.

Gee are we that far along that we're testing modules? Note there are issues with dual_iso on this camera:

Code: [Select]
    else if (is_camera("EOSM2", "1.0.3")) // WIP found movie mode but photo mode is taken from EOSM
Title: Re: ML on EOS-M2
Post by: dfort on December 22, 2018, 06:04:53 PM
In order to find the addresses missing in dual_iso (https://www.magiclantern.fm/forum/index.php?topic=7139.msg197146#msg197146) we need to use the iso-research branch. Lucky for us the patch manager was recently merged into iso-research (https://bitbucket.org/hudson/magic-lantern/commits/e86e27cd86397ab975c96b5bc0db9f5c440b5796) so we should be able to use the patches needed for the EOSM2 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg197715#msg197715). Not sure if the LiveView hack Danne posted in Reply #330 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209308#msg209308) is needed. You tell me -- iso-research build posted on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).
Title: Re: ML on EOS-M2
Post by: JohanJ on December 22, 2018, 07:23:51 PM
Some more test results based on build magiclantern-Nightly.2018Dec21.EOSM2103

I tested all functions in Expo menu in M mode, most of them even in Av & Tv as far as applicable. Everything works just fine except the following:

- Expo. Presets -> Press SET: SET activates Canon LV menu (might be as designed for M/M2?). With setting "Press Info" toggeling between two modes works fine (but you can't reach Canon Info screen anymore, of course).
- Expo.Override crashes the cam in LV if ExpSim is activated same time! To get out there I have to pull the battery! At least 4 different crash logs are written on the card.

Code: [Select]
CRASHLOG0.LOG

ASSERT: 0
at ./LvCommon/LvGainController.c:893, Evf:17bd0
lv:1 mode:3

Evf stack: 1be758 [1be8a0-1bdca0]
0xUNKNOWN  @ ca14:1be898
0xUNKNOWN  @ 36684:1be870
0x0003637C @ ff0d6258:1be858
0xUNKNOWN  @ 363ac:1be848
0xUNKNOWN  @ 478e00:1be820
0xUNKNOWN  @ 36434:1be800
0x00017B84 @ 1363c:1be798
0x00001900 @ 17bcc:1be790
0x0044C478 @ 44c57c:1be758

Magic Lantern version : Nightly.2018Dec21.EOSM2103
Mercurial changeset   : 577a7023a9f9 (crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2) tip
Built on 2018-12-22 01:17:20 UTC by [email protected]
Free Memory  : 384K + 1911K

CRASHLOG1.LOG

ASSERT: !IS_ERROR( TryPostEvent( this->hTaskClass, this, EV_READOUTDONE_INTERRUPT_EVF, NULL, 0 ) )
at ./Evf/EvfState.c:520, **INT-D9h**:11bdc
lv:1 mode:3

debug_task stack: 2abfb0 [20fbd8-20dbd8]
0x0044C478 @ 44c57c:2abfb0

CRASHLOG2.LOG = CRASHLOG3.LOG = CRASHLOG4.LOG

ASSERT: !IS_ERROR( TryPostEvent( this->hTaskClass, this, EV_SETPARAM_INTERRUPT_EVF, NULL, 0 ) )
at ./Evf/EvfState.c:503, **INT-E0h**:11b9c
lv:1 mode:3

debug_task stack: 2abfb0 [20fbd8-20dbd8]
0x0044C478 @ 44c57c:2abfb0


CRASHLOG5.LOG

ASSERT: !IS_ERROR( TryPostEvent( this->hTaskClass, this, EV_VD_INTERRUPT_EVF, NULL, 0 ) )
at ./Evf/EvfState.c:545, **INT-6Ah**:11c40
lv:1 mode:3

debug_task stack: 2abfa0 [20fbd8-20dbd8]
0x0044C478 @ 44c57c:2abfa0

==> Pulled battery!


- Expo.Override seems to work fine if ExpSim is off

Besides these observations all functions in Expo menu are stable (as they are in Overlay menu as well as in Focus menu). More to come!
Title: Re: ML on EOS-M2
Post by: JohanJ on December 22, 2018, 07:33:45 PM
In order to find the addresses missing in dual_iso (https://www.magiclantern.fm/forum/index.php?topic=7139.msg197146#msg197146) we need to use the iso-research branch. Lucky for us the patch manager was recently merged into iso-research (https://bitbucket.org/hudson/magic-lantern/commits/e86e27cd86397ab975c96b5bc0db9f5c440b5796) so we should be able to use the patches needed for the EOSM2 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg197715#msg197715). Not sure if the LiveView hack Danne posted in Reply #330 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209308#msg209308) is needed. You tell me -- iso-research build posted on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).

In fact the latest change in magiclantern-Nightly.2018Dec21.EOSM2103 made it possible to load Dual ISO without crashing but it cannot be used. When activating DualISO in Expo Menu you get the following message:
Code: [Select]
ISOless PH err(15)
I will look into the iso-research build later. I would like to finish tests on the current standard build first.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 22, 2018, 07:57:08 PM
Thanks Walter. I can see that dfort was involved in this discussion. let's see where it brings us from there.

Sent from my SM-G930F using Tapatalk

Title: Re: ML on EOS-M2
Post by: dfort on December 22, 2018, 10:10:41 PM
Hum -- seems that Walter's post got flagged as a "Hall of Shame" post. Here it is:

About ISOless errors:
https://www.magiclantern.fm/forum/index.php?topic=7139.msg197139#msg197139

That's the same issue I pointed out in Reply #356 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209600#msg209600). Follow Bilal's instructions to find the addresses (https://www.magiclantern.fm/forum/index.php?topic=7139.msg197146#msg197146) and I'll plug them into the code.
Title: Re: ML on EOS-M2
Post by: critix on December 23, 2018, 10:30:21 AM
You tell me -- iso-research build posted on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).
I ran the iso_research bracket and below put the result from the adtg_gui logs:
Code: [Select]
Canon EOS M2 1.0.3
00f00000:     803 (was 84b)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f0 Analog ISO (most cameras)
00f00003:     f08 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f6 Analog ISO on 6D
00f00004:       2 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f8 ISO-related?
00f00006:     78b ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93fc ISO 50 or timing related: FFF => darker image
00028882:     41c (was 40e)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8640 ISO ADTG gain (per column, mod 4 or mod 8)
00028884:     41e (was 410)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8644 ISO ADTG gain (per column, mod 4 or mod 8)
00028886:     418 (was 40e)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8648 ISO ADTG gain (per column, mod 4 or mod 8)
00028888:     41c (was 40e)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d864c ISO ADTG gain (per column, mod 4 or mod 8)
==================================================================
Canon EOS M2 1.0.3
00f00000:     803 (was 84b)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f0 Analog ISO (most cameras)
00f00003:     f08 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f6 Analog ISO on 6D
00f00004:       2 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f8 ISO-related?
00f00006:     78b ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93fc ISO 50 or timing related: FFF => darker image
00028882:     41c (was 40e)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8640 ISO ADTG gain (per column, mod 4 or mod 8)
00028884:     41e (was 410)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8644 ISO ADTG gain (per column, mod 4 or mod 8)
00028886:     418 (was 40e)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8648 ISO ADTG gain (per column, mod 4 or mod 8)
00028888:     41c (was 40e)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d864c ISO ADTG gain (per column, mod 4 or mod 8)
==================================================================
Canon EOS M2 1.0.3
00f00000:     803 (was 86f)      ISO=0 Tv=125 Av=56 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f0 Analog ISO (most cameras)
00f00003:     f08 ISO=0 Tv=125 Av=56 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f6 Analog ISO on 6D
00f00004:       2 ISO=0 Tv=125 Av=56 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f8 ISO-related?
00f00006:     78b ISO=0 Tv=125 Av=56 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93fc ISO 50 or timing related: FFF => darker image
00028882:     41c (was 400)      ISO=0 Tv=125 Av=56 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8640 ISO ADTG gain (per column, mod 4 or mod 8)
00028884:     41e (was 400)      ISO=0 Tv=125 Av=56 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8644 ISO ADTG gain (per column, mod 4 or mod 8)
00028886:     418 (was 400)      ISO=0 Tv=125 Av=56 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8648 ISO ADTG gain (per column, mod 4 or mod 8)
00028888:     41c (was 400)      ISO=0 Tv=125 Av=56 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d864c ISO ADTG gain (per column, mod 4 or mod 8)
==================================================================
Canon EOS M2 1.0.3
0002c002:     190 (was 19f)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=4ac30 addr=416d8f04
0002c080:       0 (was ff)       ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=4ac30 addr=416d8f08
0002c0c1:       0 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46374 addr=416d977c
0002c517:       0 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46140 addr=416d9734
0002c518:       0 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46140 addr=416d9738
0002c519:       0 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46140 addr=416d973c
0002c026:       0 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46140 addr=416d9730
00028830:       1 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46160 addr=416d85f8 Only slightly changes the color of the image (g3gg0)
000288b0:       0 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46160 addr=416d85fc
0002805f:      c1 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46270 addr=416d7b7c Shutter blanking for x5/x10 zoom
00028061:      c1 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46270 addr=416d7b80 Shutter blanking for LiveView 1x
00028172:     3b7 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46270 addr=416d7b84 PowerSaveTiming 'on', set to Line count + 1
00028173:     46a ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46270 addr=416d7b88 PowerSaveTiming 'off', should be slightly below FPS timer B
00f00000:     86f ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d9456 Analog ISO (most cameras)
00f00001:     4ce ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d9458 Vertical offset
00f00002:     742 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d945a Horizontal offset / column skipping
00f00003:     f08 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d945c Analog ISO on 6D
00f00004:       2 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d945e ISO-related?
00f00005:      20 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d9460 Fine vertical offset, black area maybe
00f00006:     78b ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d9462 ISO 50 or timing related: FFF => darker image
00f00007:     800 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d9464 5D3: image fading out; 6D, 700D: vertical offset
00f00008:     800 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d9466 Unknown, used on 6D
00f00009:      81 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d9468
0006c079:     525 (was 929)      ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=445d4 addr=1be2d4
0002c082:       0 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46338 addr=416d8c78
0002c09b:     177 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46338 addr=416d8c7c
0002c00d:    5249 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46338 addr=416d8c80
0002c00e:       7 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46338 addr=416d8c84
0002c00f:       7 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46338 addr=416d8c88
0002c010:       7 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46338 addr=416d8c8c
0002c011:       7 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46338 addr=416d8c90
00028882:     400 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8640 ISO ADTG gain (per column, mod 4 or mod 8)
00028884:     400 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8644 ISO ADTG gain (per column, mod 4 or mod 8)
00028886:     400 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d8648 ISO ADTG gain (per column, mod 4 or mod 8)
00028888:     400 ISO=0 Tv=125 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46364 addr=416d864c ISO ADTG gain (per column, mod 4 or mod 8)
==================================================================
Because the file is bigger, we just put some of it ... the rest is in the link below:
https://drive.google.com/open?id=1z7W6sY1AhmRss0wRiYWW7vjZCgWzSbMR (https://drive.google.com/open?id=1z7W6sY1AhmRss0wRiYWW7vjZCgWzSbMR)
I hope it's ok what I put ... If it's done differently, please tell me to restore ...
Thank you
Title: Re: ML on EOS-M2
Post by: JohanJ on December 23, 2018, 11:44:05 AM
Follow Bilal's instructions to find the addresses and I'll plug them into the code.
Well, I hope I got it right. ADTG-GUI came up with same values both for video and for foto mode:
Code: [Select]
Evf:46284:416d93f0 v=2051(0x803) nrzi_dec=4093(0xffd)
At least I can find these values in Critix post too.
Title: Re: ML on EOS-M2
Post by: Danne on December 23, 2018, 12:41:53 PM
Could you try this module?
https://bitbucket.org/Dannephoto/magic-lantern/downloads/dual_iso.mo

Test both photo and movie mode.

i put in your register here in dual_iso.c:
Code: [Select]
    else if (is_camera("EOSM2", "1.0.3")) // WIP found movie mode but photo mode is taken from EOSM
    {
        is_eosm2 = 1;

        FRAME_CMOS_ISO_START = 0x416d93f0; // CMOS register 0000 - for LiveView, ISO 100 (check in movie mode, not photo!)
        FRAME_CMOS_ISO_COUNT =          6; // from ISO 100 to 3200
        FRAME_CMOS_ISO_SIZE  =         34; // distance between ISO 100 and ISO 200 addresses, in bytes

        PHOTO_CMOS_ISO_START = 0x416d93f0
; // CMOS register 0000 - for photo mode, ISO 100
        PHOTO_CMOS_ISO_COUNT =          6; // from ISO 100 to 3200
        PHOTO_CMOS_ISO_SIZE  =         16; // distance between ISO 100 and ISO 200 addresses, in bytes

        CMOS_ISO_BITS = 3;
        CMOS_FLAG_BITS = 2;
        CMOS_EXPECTED_FLAG = 3;
    }
Title: Re: ML on EOS-M2
Post by: JohanJ on December 23, 2018, 01:21:14 PM
Could you try this module?
https://bitbucket.org/Dannephoto/magic-lantern/downloads/dual_iso.mo
I put the module into Dforts build December 21 and started in photo mode but the module fails to load with the same error as posted here (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209583#msg209583). Dfort made a minor change in reply #355 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209584#msg209584) which fixed it.

There was another message repeatedly printed to the console:
Code: [Select]
Black 1/5: mean too different (8152, ref 8013+-0.00)
Maybe worth to look into it too, this message does not show when going back to dfort's original DUAL_ISO.mo
Title: Re: ML on EOS-M2
Post by: Danne on December 23, 2018, 01:34:36 PM
Ok, coming from dfort branch:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/dual_iso.mo
Title: Re: ML on EOS-M2
Post by: JohanJ on December 23, 2018, 01:58:36 PM
No more linking error but
Code: [Select]
ISOless PH err(8)Now with error code 8 instead of err(15) both in photo and video mode.
Title: Re: ML on EOS-M2
Post by: Danne on December 23, 2018, 02:02:05 PM
Oki. Are you able to compile? If so play around with changes in dual_iso.c and compile and put it on to your camera.
I have ran out of time atm...

Maybe only one place should have its registry changed?

Code: [Select]
int err = isoless_enable(PHOTO_CMOS_ISO_START, PHOTO_CMOS_ISO_SIZE, PHOTO_CMOS_ISO_COUNT, backup_ph);
Title: Re: ML on EOS-M2
Post by: JohanJ on December 23, 2018, 03:45:39 PM
Made another observation: the value for CMOS[0] is alway the same 416d93f0 when
Does that make sense?
Title: Re: ML on EOS-M2
Post by: dfort on December 23, 2018, 07:08:25 PM
@Danne -- you need to fix this formatting error:

Code: [Select]
        PHOTO_CMOS_ISO_START = 0x416d93f0
; // CMOS register 0000 - for photo mode, ISO 100

Should be:

Code: [Select]
        PHOTO_CMOS_ISO_START = 0x416d93f0; // CMOS register 0000 - for photo mode, ISO 100

Does that make sense?

CMOS register 0000 doesn't change between photo and movie mode on this camera? That doesn't make sense but this camera is full of surprises. You don't need to load dual_iso to find the right values. Set the ISO to 100 and follow Bilal's instructions (https://www.magiclantern.fm/forum/index.php?topic=7139.msg197146#msg197146). Try using the iso-research for this. Do screenshots and post them if possible.

In the meantime I posted a new build that has PHOTO_CMOS_ISO_START and FRAME_CMOS_ISO_START set to the same address. Let's see if that clears up the ISOless PH err(?).
Title: Re: ML on EOS-M2
Post by: Danne on December 23, 2018, 07:26:31 PM
isoless 8 still persists.
Can confirm the same adress for both movie and photo mode. I can also confirm that you can manually set dual iso cmos[0] register and achieve dual iso.
There are two photo mode switches on eosm2. The 1 one actually gives another register than in movie mode and in photo mode. I tried using that one instead but no luck. So maybe there´s some hook in register that do not apply still for cmos registry? SOmething similar seems to happen with crop_rec. cmos doesn´t seem to change using that code too.
Title: Re: ML on EOS-M2
Post by: critix on December 23, 2018, 07:39:39 PM
Hi!
@dfort, I have memory error when i try to use adtg_gui with iso-research.2018Dec22.EOSM2103.zip:
Code: [Select]
shoot_malloc(1.0MB|TMP|DMA) FAILED AT adtg_gui.c:1004, log_iso_regs.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 23, 2018, 08:28:04 PM
You don't need to load dual_iso to find the right values. Set the ISO to 100 and follow Bilal's instructions (https://www.magiclantern.fm/forum/index.php?topic=7139.msg197146#msg197146). Try using the iso-research for this. Do screenshots and post them if possible.
I did all this already following Bilal's  instructions using your the ISO research build from your repository.  The result is posted in #362 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209617#msg209617). Same values for photo mode 2 as well as video mode made me suspicious whether I did right or not so I repeated a couple of times but in the end it was no difference.

In the meantime I posted a new build that has PHOTO_CMOS_ISO_START and FRAME_CMOS_ISO_START set to the same address. Let's see if that clears up the ISOless PH err(?).
Unfortunately the result is the same as posted here (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209622#msg209622)
Title: Re: ML on EOS-M2
Post by: dfort on December 23, 2018, 09:39:44 PM
I have memory error when i try to use adtg_gui with iso-research.2018Dec22.EOSM2103.zip:

I updated the latest build with the latest adtg_gui module. See if that works. magiclantern-Nightly_with_adtg_gui.2018Dec23.EOSM2103
Title: Re: ML on EOS-M2
Post by: JohanJ on December 24, 2018, 01:24:09 AM
I updated the latest build with the latest adtg_gui module. See if that works. magiclantern-Nightly_with_adtg_gui.2018Dec23.EOSM2103
Ok, now photo mode and video mode show different results. A strange thing was that in photo mode I got even 2 different values, one before taking a picture and another one after taking a picture (both having dual iso activated). But ever since then the second value got kind of persistent and I cannot reproduce the initial one (though I have a screenshot, but ... never mind). So here are the new values for COMS[0]:

Photo mode 2--> Value after taking a shot -> since then kind of persistent
Code: [Select]
Evf:46284:416d949a v=2231(0x8b7) nrzi_dec=3877(0xf25)
Video mode --> this is the same as in previous tests based on iso_research build
Code: [Select]
Evf:46284:416d93f0 v=2051(0x803) nrzi_dec=4093(0xffd)
Title: Re: ML on EOS-M2
Post by: dfort on December 24, 2018, 02:34:24 AM
That looks better.

PHOTO_CMOS_ISO_SIZE might be a problem. I remember figuring this out a while back but can't recall exactly how I did it. In any case, if there are still issues we need to double check this one:

Code: [Select]
        PHOTO_CMOS_ISO_SIZE  =         16; // distance between ISO 100 and ISO 200 addresses, in bytes

Just today lua_fix was merged into iso-research (https://bitbucket.org/hudson/magic-lantern/commits/69580658b766ebc4a5e3f82854bd02305860fd36) so I merged that into EOSM2_iso-research. I also did a big cleanup of the test builds so please try out the latest EOSM2 test builds at the top of my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).
Title: Re: ML on EOS-M2
Post by: gukuangshi on December 24, 2018, 03:01:52 AM
@gukuangshi - Welcome to the forum!

You're using a Minolta MD Rokkor 50 mm f/1.4 (http://vintagelensreviews.com/vlr/reviews/minolta-md-rokkor-50-mm-f1-4-md-i/) or is it a MC Rokkor-PF 58 mm f/1.4 (http://vintagelensreviews.com/vlr/reviews/minolta-mc-rokkor-pf-58-mm-f1-4-mc-ii/)?

(https://farm5.staticflickr.com/4842/45495404515_b850b6be21_m.jpg) (https://flic.kr/p/2cjgQJ8)(https://farm5.staticflickr.com/4861/44591380690_d3fc2d6b87_m.jpg) (https://flic.kr/p/2aWotWs)

In any case, the ability to adapt so many different lenses is one of the strong points of this camera.

Using LiveView on any camera will raise the temperature and being a mirrorless camera it is always in LiveView mode. Now is ML causing the temperature faster than normal? Hard to see because the Canon overlays don't show the sensor temp. I don't have the EOSM2 in my hands at this time but what I did was to run this test on an EOSM. Turn on the camera with ML and checked the starting temperature, in my case 18C. Then pulled the card and turned on the camera and let it sit on LiveView for 1 minute, the temp rose to 24C. Let the camera cool back down to 18C and turned it on again this time with ML running for 1 minute--same results. Try it on the EOSM2, you should see the same results.

I'll let you figure out how to test this out, chances are power consumption will be pretty much the same whether or not you're using ML. Of course if you start using some of the advanced features like Danne's 100fps 4k feature  :P it will probably burn through batteries.

Don't expect too much right away, we're still trying to make a somewhat stable build for this camera. Check out the Feature comparison matrix (https://builds.magiclantern.fm/features.html) page. If a feature isn't working on the EOSM, it probably won't work on the EOSM2.
I am using MC Rokkor-PF 58 mm f/1.4, as the color is more beautiful than md-rokkor-50-mm-f1.4. I once own many visions of minolta lens, the mc 50 1.4 pg processes better sharpness.  I will test the temperature again. In my camera, the temperature rises from 16-36 degrees after using 20 minutes. One more things, could you tell me how can I remain  center focus using free moving one point. In the manual, it says that when you touch other place, you can press delete(down) to turn back to the center focus. Thank you for your efforts, I will keep using newest vision of ML on my camera and report my advice.
Title: Re: ML on EOS-M2
Post by: uizin on December 24, 2018, 02:10:55 PM
@dfort, same CMOS[0] values with your last published build!
Don't know if relevant, but the iso_regs modules gives Err when loaded.

I'm still experiencing the "RAW error, falling back to YUV overlays" message.

Also: in A+ and C1 mode the shutter button is not working (half press partially shows Canon info in LV, and on full press shutter is not released). In C2 and Movie mode I can shoot with shutter button though.

Any further test we can perform?
Title: Re: ML on EOS-M2
Post by: JohanJ on December 24, 2018, 03:32:06 PM
I also did a big cleanup of the test builds so please try out the latest EOSM2 test builds at the top of my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).
Using your latest build Dec 23 from last night still comes up with the same error ISOless PH err 8 . I made some more tests and had en observation which makes me wonder if we are looking at the correct register.

Some thoughts: Meaning the CMOS[0] register changes values in depencence of the shutter speed. So, are we looking at the right register?

Title: Re: ML on EOS-M2
Post by: a1ex on December 24, 2018, 04:00:03 PM
Meaning the CMOS[0] register changes values in depencence of the shutter speed. So, are we looking at the right register?

Yes, but you are looking at it in LiveView; you need to look at it in still photo capture mode.

In photo mode LiveView, Canon firmware uses exposure simulation (i.e. the actual exposure values are not necessarily the ones dialed in their menus, but something with equivalent brightness). That's why CMOS[0] appears to depend on shutter speed - because Canon firmware is actually changing ISO.

In manual movie mode, exposure values are the one dialed in menus, so CMOS[0] will behave as expected (i.e. it will change only with ISO). No surprises expected there.

Photo mode 2--> Value after taking a shot -> since then kind of persistent
Code: [Select]
Evf:46284:416d949a v=2231(0x8b7) nrzi_dec=3877(0xf25)
Video mode --> this is the same as in previous tests based on iso_research build
Code: [Select]
Evf:46284:416d93f0 v=2051(0x803) nrzi_dec=4093(0xffd)

Look at the task name - "Evf" is Canon's task for LiveView on recent models. For still photos, it's "ShootCapture".

For stills, you should look at that register during photo capture, outside LiveView. As soon as you return to LiveView, the registers in the ADTG menu will be overridden.

If the camera cannot operate without returning to LiveView, you have an option to disable logging in LiveView, in the Advanced menu. That option was written specifically for the EOS M, which had the same issue.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 24, 2018, 04:13:07 PM
Thanks a1ex! M2 like M is in permanent LV mode. I will check the advanced features later, now it is time for Xmas celebrations.

Seasons greatings from snowy Sweden to all of you!
Title: Re: ML on EOS-M2
Post by: uizin on December 24, 2018, 06:12:20 PM
Exported a log after shooting in Video mode, and filtered for ShootCapture task, may this be interesting?

Code: [Select]
c0f1b080:80000000 (was 1)        ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8d74
c0f1b020:       6 (was 1)        ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8bb4
c0f1b1c0:80000000                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8d7c
c0f1b034:       0                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8bdc
c0f1b100:80000000                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8d84
c0f1b028:       5                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8bc4
c0f1b0c0:80000000                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8d8c
c0f1b024:       1                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8bbc
c0f1b0c4:       3 (was 0)        ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8c44
c0f1b0c8:10000700 (was 0)        ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8c4c
c0f1b044:80000000                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8db4
c0f1b03c:       0                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8bec
c0f1b140:80000000                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8d94
c0f1b02c:       4 (was 1)        ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8bcc
c0f1b180:80000000                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8d9c
c0f1b030:       1 (was 3)        ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8bd4
c0f1b010:80000000 (was 0)        ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8da4
c0f1b038:       3 (was 4)        ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8be4
c0f1b284:       4                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8d5c
c0f1b280:       0                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8d64
c0f1b288:      11                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8ce4
c0f1b2b0: d61c684 (was d2cc000)  ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414cb0 addr=19e2c8
c0f1b2b8:  f00140                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff414ca8 addr=a8cec
c0f1b040:80000000                ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=1 res=0 crop=0 task=ShootCapture pc=ff4153ec addr=a8dac
Title: Re: ML on EOS-M2
Post by: dfort on December 24, 2018, 07:25:10 PM
What we're searching for is in photo mode, non LiveView.
Title: Re: ML on EOS-M2
Post by: uizin on December 24, 2018, 10:06:49 PM
Here is another log filtered for ShootCapture:

Code: [Select]
c0f27000:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bb50
c0f27004:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bb58
c0f27008:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bb60
c0f2700c:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bb68
c0f27010:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bb70
c0f27014:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bb78
c0f27080:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bb80
c0f27084:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bb88
c0f27088:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bb90
c0f2708c:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bb98
c0f27090:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bba0
c0f27094:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bba8
c0f07168:  c80100 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff415f9c addr=9a7a8
c0f08100:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff416e3c addr=19e2c8 CCDSEL (0-1)
c0f08114:       5 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff416e48 addr=19e2c8 LV raw type (see lv_af_raw, lv_set_raw) - DIGIC IV (PACK32_ISEL)
c0f082d4:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff416e54 addr=19e2c8 WDMAC32_ISEL (0-7)
c0f38324:80000000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5ccb6c addr=19e2a0
c0f38318:80000000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5ccb78 addr=19e2a0
c0f3831c:     114 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff79e9a4 addr=19e248
c0f38320:32100001 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5ccce0 addr=19e250
c0f42264:10000c00 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691880
c0f42268:3ec03fc0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691888
c0f4226c:       2 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691890
c0f42280:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691898
c0f42284:10000c00 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=406918a0
c0f42288:3ec03fc0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=406918a8
c0f4228c:       2 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=406918b0
c0f422a4:10000c00 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=406918c0
c0f422a8:3ec03fc0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=406918c8
c0f422ac:       2 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=406918d0
c0f422c0:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=406918d8
c0f422c4:10000c00 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=406918e0
c0f422c8:3ec03fc0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=406918e8
c0f422cc:       2 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=406918f0
c0f42500:  fa00a0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691aa8
c0f42504:  280048 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ab0
c0f42508:  10001b ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ab8
c0f4250c:  3c0028 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ac0
c0f42510:  6d005b ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ac8
c0f42514:  9c0081 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ad0
c0f42520: 63f0002 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ad8
c0f42530:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ae0
c0f42534:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ae8
c0f42538:     15e ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691af0
c0f4253c:     190 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691af8
c0f42540:      96 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b00
c0f42544:     258 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b08
c0f42548:   20020 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b10
c0f42550:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b18
c0f42560: 63f0010 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b20
c0f42570:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b28
c0f42574:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b30
c0f42578:     15e ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b38
c0f4257c:     190 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b40
c0f42580:      96 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b48
c0f42584:     258 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b50
c0f42588:   20020 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b58
c0f42600:  fa00a0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b60
c0f42604:  280048 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b68
c0f42608:  10001b ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b70
c0f4260c:  3c0028 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b78
c0f42610:  6d005b ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b80
c0f42614:  9c0081 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b88
c0f42620: 63f0010 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b90
c0f42630:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691b98
c0f42634:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ba0
c0f42638:     12c ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ba8
c0f4263c:      c8 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691bb0
c0f42640:      7d ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691bb8
c0f42644:     12c ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691bc0
c0f42648:   20020 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691bc8
c0f42650:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691bd0
c0f42654:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691bd8
c0f42658:      bc ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691be0
c0f4265c:      70 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691be8
c0f42660:      b0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691bf0
c0f42664:      2d ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691bf8
c0f42668:      3f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c00
c0f4266c:      32 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c08
c0f42670:       5 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c10
c0f42674:       6 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c18
c0f42678:       6 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c20
c0f4267c:  280010 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c28
c0f42680:   6003f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c30
c0f42684: 3a8003e ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c38
c0f42688:   6003f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c40
c0f4268c: 1b4003e ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c48
c0f42690:  200040 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c50
c0f42694:      20 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c58
c0f426a0:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c60
c0f426b0: 63f0010 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c68
c0f426c0:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c70
c0f426c4:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c78
c0f426c8:     12c ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c80
c0f426cc:      c8 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c88
c0f426d0:      7d ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c90
c0f426d4:     12c ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691c98
c0f426d8:   20020 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bca20 addr=40691ca0
c0f08c90:1010032d ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff41480c addr=416da3c0
c0f081c0:   10001 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414838 addr=9b014
c0f0820c: a4f0000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414838 addr=9b01c
c0f08208:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4148cc addr=9b03c
c0f081a0:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4148d8 addr=9b094
c0f08200:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4170cc addr=9b064
c0f081b8:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4170cc addr=9b06c
c0f081bc:      a8 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4170cc addr=9b074
00028011:    d38c ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6308
00028012:    ffff ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d630c
00028013:    51e5 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6310
00028014:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6314
00028015:    b68f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6318
00028016:    ffff ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d631c
00028017:    34d6 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6320
00028018:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6324
00028019:    d276 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6328
0002801a:    ffff ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d632c
0002801b:    77ed ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6330
0002801c:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6334
0002801d:    5d0d ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6338
0002801e:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d633c
0002801f:      64 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6340
00028020:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6344
00028021:     b6b ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6348
00028022:     100 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d634c
0002800d:       2 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6350
0002800e:       c ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6354
00028024:      22 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6358
00028025:      7a ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d635c
00028048:      6e ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6368
00028049:      56 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d636c
00028065:      2c ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6370
00028066:      7c ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6374
0002802d:      25 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6378
0002802e:      66 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d637c
00028067:      7b ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6380
00028068:      73 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6384
00028095:      c4 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d638c
00028096:      2b ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6390
0002818e:      2b ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6394
0002818f:      2b ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=23c5c addr=416d6398
c0f37218:80000000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff415438 addr=9b7cc
c0f37224:     120 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414af0 addr=9b78c
c0f37228:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414af0 addr=9b794
c0f3722c:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414af0 addr=9b79c
c0f37230:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414af0 addr=9b7a4
c0f37234:    3210 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414af0 addr=9b7ac
c0f085b0:    3fff ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414af4 addr=9b28c
c0f27400:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bbc0
c0f27040:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba40
c0f27044:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba48
c0f27048:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba50
c0f2704c:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba58
c0f27050:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba60
c0f27054:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba68
c0f27058:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba70
c0f2705c:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba78
c0f27060:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba80
c0f27064:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba88
c0f27068:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba90
c0f2706c:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9ba98
c0f27070:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9baa0
c0f27074:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9baa8
c0f27078:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bbb0
c0f2707c:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bab8
c0f270c0:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bac0
c0f270c4:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bac8
c0f270c8:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bad0
c0f270cc:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bad8
c0f270d0:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bae0
c0f270d4:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417758 addr=9bbb8
c0f270d8:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9baf0
c0f270dc:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9baf8
c0f270e0:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bb00
c0f270e4:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bb08
c0f270e8:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bb10
c0f270ec:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bb18
c0f270f0:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bb20
c0f270f4:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bb28
c0f270f8:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bb30
c0f270fc:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4176a0 addr=9bb38
c0f050f0:       5 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=30b70 addr=19e2a0
c0f05218:      23 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=30ab0 addr=19e2a8
c0f085d0:80000000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4153d0 addr=9b8ac
c0f085d4:       2 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417580 addr=9b86c
c0f085d8: dc80527 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417580 addr=9b874
c0f085dc:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414be8 addr=9b884
c0f08d3c:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414be8 addr=9b88c
c0f09078:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc14c addr=a895c
c0f0b0c0:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bbfe4 addr=a87b4
c0f0b0e8:       4 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bbfe4 addr=a87d4
c0f0b140:  e30037 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a87f4
c0f0b144:  e30037 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a87fc
c0f0b148:  e30037 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a8804
c0f0b14c:   e0014 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a880c
c0f0b138:      10 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a8814
c0f0b150:  800080 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a881c
c0f0b154:  800080 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a8824
c0f0b158: 1000100 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a882c
c0f0b15c: 1000100 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a8834
c0f0b160: 7ff0000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a883c
c0f0b164: 7ff0000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a8844
c0f0b168: 7ff0000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a884c
c0f0b16c: 7ff0000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff5bc058 addr=a8854
c0f0a104: dc80527 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c18 addr=19e2c8
c0f0a108:  c90001 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4ae200 addr=19e2c0
c0f0a10c: d310011 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c40 addr=19e2c8
c0f0a014:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4ae104 addr=19e2c0
c0f2e000:80000000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4153dc addr=9bd18
c0f2e004:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417960 addr=9bcc8
c0f2e008:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417960 addr=9bcd0
c0f2e00c:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417960 addr=9bcd8
c0f2e018:       4 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417960 addr=9bce0
c0f2e01c:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417960 addr=9bce8
c0f2e020:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417960 addr=9bcf0
c0f2e024:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff417960 addr=9bcf8
c0f2e028:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6a94
c0f2e02c: dc80527 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6a9c
c0f2e030:       c ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6aa4
c0f2e034:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6aac
c0f2e038:  3e0014 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6ab4
c0f2e03c: dbd0525 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6abc
c0f2e040:  800080 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6ac4
c0f2e044:  800080 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6acc
c0f2e048:20413520 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6ad4
c0f2e04c:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6adc
c0f2e050:77772222 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6ae4
c0f2e054:       f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6aec
c0f2e058:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6af4
c0f2e05c:333b343f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6afc
c0f2e060:   c0a12 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b04
c0f2e064:e1ae733f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b0c
c0f2e068:    fdf3 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b14
c0f2e06c:d8000505 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b1c
c0f2e070:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b24
c0f2e074:bf000111 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b2c
c0f2e078:      25 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b34
c0f2e07c:   d0008 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b3c
c0f2e080:   b0001 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b44
c0f2e084:      25 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b4c
c0f2e088:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b54
c0f2e08c:      71 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b5c
c0f2e090:     527 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b64
c0f2e094:     707 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414c94 addr=e6b6c
c0f1b260:80000000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff4153ec addr=a8d6c
c0f1b084:    1000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8bf4
c0f1b088: dc80527 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8bfc
c0f1b1c4:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c04
c0f1b1c8: dc80527 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c0c
c0f1b1cc:  3e0015 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c14
c0f1b1d0: dbd0524 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c1c
c0f1b1d4:  3e0015 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c24
c0f1b1d8: dbd0524 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c2c
c0f1b1dc:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c34
c0f1b1e0:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c3c
c0f1b104:   10010 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c54
c0f1b108:   35051 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c5c
c0f1b10c:     4ff ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c64
c0f1b110: d7f0510 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c6c
c0f1b184:       d ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c74
c0f1b188: 35f013f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c7c
c0f1b18c:      21 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c84
c0f1b144:      10 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c8c
c0f1b148:  330512 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c94
c0f1b14c:  ef0000 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8c9c
c0f1b150: 35f013f ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8ca4
c0f1b204:       1 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8cac
c0f1b264:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8cb4
c0f1b268:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8cbc
c0f1b26c:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8cc4
c0f1b270:       0 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=ff414ca8 addr=a8ccc
c0f05010:      35 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=30ab0 addr=19e2b0
Title: Re: ML on EOS-M2
Post by: JohanJ on December 25, 2018, 01:26:21 AM
That is interesting. @uizin could you describe how you get these log entries? Are you testing in photo mode?

I ran the following test a couple of times but the file adtg.log did not show a single line with the task = "ShootCapture", only lots of Evf entries. My procedure was:
 - work in photo mode 2, M expo, Exp.Sim off.
 - load adtg_gui.mo
 - Debug: ADTG Registers on
 - Enter ADTG registers submenu Advanced
 - Set Disable logging in Live view
 - Set Auto Log registers after taking a pic
 - leave ML menu
 - take a picture
 - message on the display that 35 registers have been logged in a .ca. 4k file

Did the same test w/ "Disable logging Off" but the result was approx. the same. What am I missing here?

Sent from my SM-T719 using Tapatalk

Title: Re: ML on EOS-M2
Post by: dfort on December 25, 2018, 05:17:07 AM
What am I missing here?

Look on your SD card under ML/LOGS/ADTG.LOG

Here is the line I'm looking for (this one is from the EOSM):

Canon EOS M 2.0.2
Code: [Select]
00f00000:     803 ISO=100 Tv=160 Av=35 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=16d14 addr=4048124c Analog ISO (most cameras)

In my camera, the temperature rises from 16-36 degrees after using 20 minutes.

That seems about normal.

One more things, could you tell me how can I remain  center focus using free moving one point. In the manual, it says that when you touch other place, you can press delete(down) to turn back to the center focus.

ML uses the down arrow (trash button) to open the ML menu. If you start without ML (press the SET button when starting) it should work. Note that you can change the behavior of the trash button using the Canon Custom Functions -- C.FnIV:Operation/Others [6]

[EDIT] On the EOSM using the unified branch a quick press of the trash button centers the focus box and a longer press opens the ML menu. On the iso-research branch a quick press of the trash button doesn't center the focus box.
Title: Re: ML on EOS-M2
Post by: gukuangshi on December 25, 2018, 07:21:48 AM
Look on your SD card under ML/LOGS/ADTG.LOG

Here is the line I'm looking for (this one is from the EOSM):

Canon EOS M 2.0.2
Code: [Select]
00f00000:     803 ISO=100 Tv=160 Av=35 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=16d14 addr=4048124c Analog ISO (most cameras)

That seems about normal.

ML uses the down arrow (trash button) to open the ML menu. If you start without ML (press the SET button when starting) it should work. Note that you can change the behavior of the trash button using the Canon Custom Functions -- C.FnIV:Operation/Others [6]

[EDIT] On the EOSM using the unified branch a quick press of the trash button centers the focus box and a longer press opens the ML menu. On the iso-research branch a quick press of the trash button doesn't center the focus box.
Thank you very much. Merry Christmas to you. The Cannon Custom Functions of  the down arrow (trash button) won't work by a quick press. And to start the camera when press the center button (SET button), the camera still possesses ML.  And weather long press or short press, it's the same. I'm using magiclantern-Nightly.2018Dec23.EOSM2103.zip. I hope one day, a quick press of the trash button will realize Cannon Custom Functions with ML.
Title: Re: ML on EOS-M2
Post by: uizin on December 25, 2018, 11:26:10 AM
@JohanJ I followed the same steps you described (also enabling ENGIO Registers, don't know if it's relevant). After taking that shoot I pressed the play button to exit LiveView and review the image, and noticed the saving message over the image. But now I'm trying again, and does not seem to work the same.
Also, I set the advanced options before enabling the recording (so the counter on the right remains to 0 uniq / 0 until I take a shoot.
I made many changes to the settings, and now i don't seem to be able to save any log to the SD... Still experimenting!

@dfort, I serached the logs for something similar to what you are looking for, and that address line has Evf, not ShootCapture...

Code: [Select]
00f00000:     827 ISO=100 Tv=50 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d9412 Analog ISO (most cameras)
Title: Re: ML on EOS-M2
Post by: JohanJ on December 25, 2018, 11:30:51 AM
Look on your SD card under ML/LOGS/ADTG.LOG

Here is the line I'm looking for (this one is from the EOSM):

Canon EOS M 2.0.2
Code: [Select]
00f00000:     803 ISO=100 Tv=160 Av=35 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=16d14 addr=4048124c Analog ISO (most cameras)
Sure, that's what I did. My point is that there is not a single row with "task=ShootCapture", task=Evf only, what ever I changed in the procedure.

Here is a part of the file matching the Analog ISO line
Code: [Select]
00f00000:     86f (was 893)      ISO=100 Tv=30 Av=20 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d9456 Analog ISO (most cameras)

And here (https://drive.google.com/file/d/1tXEOEo3evzq_w3gJLLLbAaZt1kRaLN6t/view?usp=sharing) is the entire file.

EDIT: I changed the link to the LOG file, I had published the wrong one. Now correct values with "Logging disabled in LV ". The NEW link should work now. Also changed the extracted line in code.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 25, 2018, 12:50:22 PM
Also, I set the advanced options before enabling the recording (so the counter on the right remains to 0 uniq / 0 until I take a shoot.
Just to make it clear for me, are you in photo mode or do you take a picture in movie mode (talking about recording)?
Title: Re: ML on EOS-M2
Post by: uizin on December 25, 2018, 12:57:24 PM
Just to make it clear for me, are you in photo mode or do you take a picture in movie mode (talking about recording)?

I was in photo mode (with recording I meant saving log data).
Title: Re: ML on EOS-M2
Post by: JohanJ on December 25, 2018, 04:27:08 PM
I made many changes to the settings, and now i don't seem to be able to save any log to the SD... Still experimenting!

Same happend to me with build magiclantern-Nightly.2018Dec23.EOSM2103. I reinstalled the build after having low level formatted the card but no luck. ADTG GUI does not write a file anymore. No idea why!

I used a new card with the latest iso-research.2018Dec23.EOSM2103 build instead and got out a new file with all registered logged. But here we have again another value
Code: [Select]
00f00000:     803 ISO=100 Tv=200 Av=20 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f0 Analog ISO (most cameras)
As you can see Tv is higher than in post #388 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209718#msg209718) which leads to anoher value for CMOS[0].

In other words, all tests are still in Evf mode for LV and Canon firmware takes over. Looks like the advanced settings in ADTG_GUI.mo do not work for EOSM2.
I am pretty much stuck here. Maybe @a1ex has an idea how to continue.

Here is the entire ADTG.LOG (https://drive.google.com/file/d/1VCU1zWPDfGl2amvVy6yeDGDXpKGy2Qjr/view?usp=sharing) if needed.

Title: Re: ML on EOS-M2
Post by: dfort on December 25, 2018, 05:39:17 PM
As you can see Tv...

I believe that Tv and Av are the property values and will vary depending on how the camera is metering at that point in time.

src/lens.c
Code: [Select]
PROP_HANDLER( PROP_APERTURE_AUTO )
{
    /* this gets updated in Tv mode (where PROP_APERTURE is not updated); same for P, Auto and so on */
    /* it becomes 0 when camera is no longer metering */

I still can't see anything in the EOSM2 logs that match what the EOSM log is showing. Now I'm starting to wonder if we're using the right address for LiveView since it keeps changing.

[EDIT] Another issue is the possibility that the address found on one camera won't work on another camera. This happened on the 700D and the 650D:

dual_iso ISOless ( 8 ) & (15) err finally solved for Canon 700D that have this problem!
The problem was in CMOS (0) Registers at ISO 100, It was different in my camera.

Then again it could even change on the same camera:

... depending on what's stored in their settings area (properties) and where that stuff happens to be allocated at startup. It can happen on any camera model, but some of them were just lucky.

@JohanJ - You are blocking PM's. Sometimes we need to pass along information via PM. You might want to check your settings:

(https://farm8.staticflickr.com/7830/31520557037_eb0dfb5376_z.jpg) (https://flic.kr/p/Q2n6rX)
Title: Re: ML on EOS-M2
Post by: JohanJ on December 26, 2018, 12:10:47 PM
I believe that Tv and Av are the property values and will vary depending on how the camera is metering at that point in time.
That's is totally correct and it was  provoked in my test scneario just to show that the value we are looking for is changing when exposure (Tv) is changing. a1ex commented here (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209685#msg209685)

In photo mode LiveView, Canon firmware uses exposure simulation (i.e. the actual exposure values are not necessarily the ones dialed in their menus, but something with equivalent brightness). That's why CMOS[0] appears to depend on shutter speed - because Canon firmware is actually changing ISO....
Look at the task name - "Evf" is Canon's task for LiveView on recent models. For still photos, it's "ShootCapture"....
If the camera cannot operate without returning to LiveView, you have an option to disable logging in LiveView, in the Advanced menu. That option was written specifically for the EOS M, which had the same issue.
I ran all the tests with this advanced feature "disabled logging in LiveView", still the result in ADTG.LOG shows task=EvF (=LV) only, instead of task=ShootCapture - which makes me conclude:
 - LV is still active and the address we are searching gets continously overwritten by Canon firmware changing ISO due to ExposureSimulation
 - the advanced Logging fetaure written for EOS M does not work as expected for EOS M2

By the way, I inactivated Exp.Sim in ML exposure menu for all testing, w/o any effect, Canon firmware seems to use it anyway.
Title: Re: ML on EOS-M2
Post by: dfort on December 26, 2018, 04:43:41 PM
By the way, I inactivated Exp.Sim in ML exposure menu for all testing, w/o any effect, Canon firmware seems to use it anyway.

Interesting. I looked up Exposure Simulation and I just copied this from the EOSM:

platform/EOSM2.103/internals.h
Code: [Select]
/** We can't change ExpSim from ML (at least not yet) **/
#define CONFIG_EXPSIM

Seems to me like the comment says we can't but it is defined so it say that we can. Anyway, this turns on a couple of features:

src/all_features.h
Code: [Select]
#ifdef CONFIG_EXPSIM
    #define FEATURE_EXPSIM
#endif
...
    #ifdef CONFIG_EXPSIM
    #define FEATURE_LV_ZOOM_AUTO_EXPOSURE
    #endif

We should probably trace through the code and see if maybe there's some more addresses that need fixing.

I was looking at the state objects addresses because it looks like I never did get that figured out (https://www.magiclantern.fm/forum/index.php?topic=15895.msg197354#msg197354). What are state objects?

platform/EOSM2.103/internals.h
Code: [Select]
/**
 * State object hooks are pieces of code that run in Canon tasks (state objects). See state-object.c .
 * They might slow down Canon code, so here you can disable all of them (useful for debugging or early ports)
 */
#define CONFIG_STATE_OBJECT_HOOKS

So, this is what I've got for the EOSM2:

platform/EOSM2.103/include/platform/state-object.h
Code: [Select]
#ifndef __platform_state_object_h
#define __platform_state_object_h

#define DISPLAY_STATE DISPLAY_STATEOBJ
#define INPUT_SET_IMAGE_VRAM_PARAMETER_MUTE_FLIP_CBR 26 // need to verify
#define INPUT_ENABLE_IMAGE_PHYSICAL_SCREEN_PARAMETER 27 // need to verify
#define EVF_STATE    (*(struct state_object **)0x91CF0)
#define MOVREC_STATE (*(struct state_object **)0x93AF8)
#define SSS_STATE    (*(struct state_object **)0x9169C)

#endif // __platform_state_object_h

Mostly copied from the EOSM but since the EOSM2 seems to be using the same sensor as the 100D I thought I'd take a look:

platform/100D.101/include/platform/state-object.h
Code: [Select]
#ifndef __platform_state_object_h
#define __platform_state_object_h

#define DISPLAY_STATE DISPLAY_STATEOBJ
//#define INPUT_SET_IMAGE_VRAM_PARAMETER_MUTE_FLIP_CBR 24 /* unused */
#define INPUT_ENABLE_IMAGE_PHYSICAL_SCREEN_PARAMETER 25
#define EVF_STATE (*(struct state_object **)0x6733C)
// #define MOVREC_STATE (*(struct state_object **)0x691AC)
// #define SSS_STATE (*(struct state_object **)0x91BD8)

#endif // __platform_state_object_h

Huh? Maybe some of this was either not being used or causing problems?

Note that state object is also mentioned here:

platform/EOSM2.103/consts.h
Code: [Select]
// http://magiclantern.wikia.com/wiki/VRAM_ADDR_from_code
// stateobj_disp[1]
#define YUV422_LV_BUFFER_DISPLAY_ADDR (*(uint32_t*)(0x90494+0x12C))

Mentioned this on Reply #335 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209332#msg209332) - maybe someone could double check I have the correct address?
Title: Re: ML on EOS-M2
Post by: critix on December 26, 2018, 06:13:13 PM
Code: [Select]
#define YUV422_LV_BUFFER_DISPLAY_ADDR (*(uint32_t*)(0x90494+0x12C))
From my point of view, the value is correct. I checked it again today (and yesterday I looked at that value).
Title: Re: ML on EOS-M2
Post by: dfort on December 26, 2018, 06:49:44 PM
I tried to find the value of INPUT_SET_IMAGE_VRAM_PARAMETER_MUTE_FLIP_CBR for the EOSM2 and couldn't figure it out. Then I searched the code and couldn't find any place where it is used. Looks like MOVREC_STATE and SSS_STATE aren't being used either so maybe we should do like on the 100D and comment out those lines.
Title: Re: ML on EOS-M2
Post by: a1ex on December 27, 2018, 12:05:14 PM
#define INPUT_ENABLE_IMAGE_PHYSICAL_SCREEN_PARAMETER 27 // need to verify

Confirmed (https://www.magiclantern.fm/forum/index.php?topic=16040.msg202394#msg202394). (edit: sorry, it's 28)

Quote
#define INPUT_SET_IMAGE_VRAM_PARAMETER_MUTE_FLIP_CBR 26 // need to verify

This one is incorrect, but it's no longer used (removed by nikfreak in 874dfa6 (https://bitbucket.org/hudson/magic-lantern/commits/874dfa6), this PR (https://bitbucket.org/hudson/magic-lantern/pull-requests/666/650d_700d_magic_zoom_flicker_fix/diff)), so you can just comment it out.

Will try to find a way to create/update those state object graphs with the new tools (QEMU+GDB).




I ran the following test a couple of times but the file adtg.log did not show a single line with the task = "ShootCapture", only lots of Evf entries. My procedure was:
 - work in photo mode 2, M expo, Exp.Sim off.
 - load adtg_gui.mo
 - Debug: ADTG Registers on
 - Enter ADTG registers submenu Advanced
 - Set Disable logging in Live view
 - Set Auto Log registers after taking a pic
 - leave ML menu
 - take a picture
 - message on the display that 35 registers have been logged in a .ca. 4k file

Did the same test w/ "Disable logging Off" but the result was approx. the same. What am I missing here?

Did the same test with 5D3, with current CMOS/ADTG build from the Experiments page. Result: 36 registers logged, all of them from the ShootCapture task. Not sure what's wrong - maybe M2 doesn't get out of LiveView when taking a picture. To check this, make sure PROP_LV_ACTION actually gets executed (add a printf there, for example). If it does, write down the value of buf[0] before taking the picture (expected 1) and after returning to LiveView (expected 0).

There is another way to log photo capture alongside with LiveView - in adtg_gui, in the Advanced menu, set "Unique Key" to "Register + caller task". That way, still photo and LiveView registers will be logged as separate entities, rather than grouped together (even if both tasks will override the same register).

Caveat: you have to enable that option *before* enabling ADTG registers (i.e. it's not something you can change during a logging session). Go to the submenu first, while the stuff is still grayed out, change the unique key, then go back to enable the main menu entry.
Title: Re: ML on EOS-M2
Post by: dfort on December 27, 2018, 05:15:27 PM
Thanks a1ex!

Found I had the wrong value for INPUT_ENABLE_IMAGE_PHYSICAL_SCREEN_PARAMETER on some of my branches, including that build we've been using that is somewhat stable. Posted a new test build to my downloads page. (https://bitbucket.org/daniel_fort/magic-lantern/downloads/)
Title: Re: ML on EOS-M2
Post by: a1ex on December 27, 2018, 05:29:30 PM
Actually I've looked at it again and it seems to be 28, sorry about that...

"EnableImagePhysicalScreenParameter pCBR=%x" used in 100D DisplayStateWithImgMute_S01_I25 and EOSM2  DisplayStateWithImgMute_S01_I28.

Edit: please find some initial state object graphs for EOSM2 here (https://a1ex.magiclantern.fm/bleeding-edge/EOSM2/states/index.html) (still checking the output).
Title: Re: ML on EOS-M2
Post by: dfort on December 27, 2018, 05:47:59 PM
Got it -- thanks again.
Title: Re: ML on EOS-M2
Post by: Danne on December 27, 2018, 07:38:32 PM
Cool. Framing preview now working!
Hm, still not able to see why freezes occur with RAW video. Can mostly be dodged by increasing fps override a-timer but that doesn´t relly help when running in idle mode with fps override set to off.
Title: Re: ML on EOS-M2
Post by: dfort on December 27, 2018, 08:01:36 PM
Probably because we still need to figure this out:

src/fps-engine.c
Code: [Select]
#elif defined(CONFIG_EOSM2) // using EOSM values for now
    #define TG_FREQ_BASE 32000000
    #define FPS_TIMER_A_MIN (ZOOM ? 716 : MV1080CROP ? 532 : 520)
    #undef FPS_TIMER_B_MIN
    #define FPS_TIMER_B_MIN ( \
    RECORDING_H264 ? (MV1080CROP ? 1750 : MV720 ? 990 : 1970) \
                   : (ZOOM || MV1080CROP ? 1336 : 1970))
Title: Re: ML on EOS-M2
Post by: Danne on December 27, 2018, 08:05:32 PM
I don't think so. This is only enabled when fps override is on. Not in idle and set to off. Even if it's timer related it might not be in fps-engio.c.
Title: Re: ML on EOS-M2
Post by: Danne on December 28, 2018, 02:39:04 AM
Did the same test with 5D3, with current CMOS/ADTG build from the Experiments page. Result: 36 registers logged, all of them from the ShootCapture task. Not sure what's wrong - maybe M2 doesn't get out of LiveView when taking a picture. To check this, make sure PROP_LV_ACTION actually gets executed (add a printf there, for example). If it does, write down the value of buf[0] before taking the picture (expected 1) and after returning to LiveView (expected 0).

In propvaluse.c:
Code: [Select]
#ifdef CONFIG_LIVEVIEW
PROP_HANDLER( PROP_LV_ACTION )
{
    lv = !buf[0];
NotifyBox(5000, "lv 0x%x", lv);
}
#endif
Gives 0x1 on the eosm2 when camera is on telling me liveview is on. Taking a picture briefly shows 0x0 then back to 0x1. This goes for both photo and movie mode.
Title: Re: ML on EOS-M2
Post by: dfort on December 28, 2018, 03:14:25 AM
Guess that proves the M2 briefly gets out of LiveView when taking a picture but maybe all of the ShootCapture tasks aren't being logged?

Combing through the log files I found the shutter blanking values were consistent, at least on the two cameras that were tested:

Code: [Select]
0002805f:      c1 ISO=0 Tv=60 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46270 addr=416d7b7c Shutter blanking for x5/x10 zoom
00028061:      c1 ISO=0 Tv=60 Av=56 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46270 addr=416d7b80 Shutter blanking for LiveView 1x

So it confirms this is correct:

platform/EOSM2.103/consts.h
Code: [Select]
#define FRAME_SHUTTER_BLANKING_ZOOM   (*(uint16_t*)0x416D7B7C) // ADTG register 805f
#define FRAME_SHUTTER_BLANKING_NOZOOM (*(uint16_t*)0x416D7B80) // ADTG register 8061

However, it might not apply to all M2's. Why? Because it happened on the 700D (https://bitbucket.org/hudson/magic-lantern/commits/58d67357be15201ba9b4cd08c47628c3cede3f8d?at=crop_rec_4k#comment-6978283). It would help to get log files from several M2's.

The next few lines are also interesting:

Code: [Select]
/* when reading, use the other mode, as it contains the original value (not overriden) */
#define FRAME_SHUTTER_BLANKING_READ   (lv_dispsize > 1 ? FRAME_SHUTTER_BLANKING_NOZOOM : FRAME_SHUTTER_BLANKING_ZOOM)
#define FRAME_SHUTTER_BLANKING_WRITE  (lv_dispsize > 1 ? &FRAME_SHUTTER_BLANKING_ZOOM : &FRAME_SHUTTER_BLANKING_NOZOOM) // commented out on EOSM

That line commented out on the EOSM was recently activated but only on the crop_rec_4k branch. It is still commented out on the EOSM in the iso-research branch we're using. Why? Here's the commit where it was commented out (https://bitbucket.org/hudson/magic-lantern/commits/f68f196807a3442a6bb09d40ecae89f00cb7697a). Note that it also affects the 50D. So maybe this should also be commented out on the EOSM2? Let's try that and see if there's any improvement. Uploaded a new iso-research test build.
Title: Re: ML on EOS-M2
Post by: Danne on December 28, 2018, 03:21:59 AM
Shutter blanking might change from cam to cam on this model:
https://www.magiclantern.fm/forum/index.php?topic=19300.msg208546#msg208546
Title: Re: ML on EOS-M2
Post by: dfort on December 28, 2018, 03:38:11 AM
Well if shutter blanking changes on the 100D and 700D, it probably also applies to the EOSM2. They are all about the same vintage.
Title: Re: ML on EOS-M2
Post by: dfort on December 28, 2018, 07:17:47 AM
Danne's experiment on Reply #404 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209816#msg209816) gave me an idea.

We know that the camera is pretty much always in LiveView.

(https://farm8.staticflickr.com/7921/45582410185_dd56e1d60d.jpg) (https://flic.kr/p/2crXLtT)

But when it goes into image review mode it is out of LiveView:

(https://farm8.staticflickr.com/7886/45582410875_db2e6e452f.jpg) (https://flic.kr/p/2crXLFM)

When I set Image review to Off I can't even see it get out of LiveView but when set to Hold it stays out of LiveView.

Pressing the INFO button until you get to this screen also gets the camera out of LiveView (funky colors with Screenshot is a known issue):

(https://farm8.staticflickr.com/7862/44678748470_068149cdc9.jpg) (https://flic.kr/p/2b57gku)

So, using JohanJ's steps in Reply #384 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209698#msg209698) to get a log file with a few changes, in red:

 - work in photo mode 2, M expo, Exp.Sim off. Image review from Canon menu set to Hold
 - load adtg_gui.mo
 - Debug: ADTG Registers on
 - Enter ADTG registers submenu Advanced
 - Set Disable logging in Live view
 - Set Auto Log registers after taking a pic
 - leave ML menu
 - Press INFO button until the camera is out of LiveView
 - take a picture (releasing the shutter from the non-LiveView INFO screen)
 - message on the display - Saved XX registers, XXXXX bytes

Maybe that will log the elusive task=ShootCapture...Analog ISO (most cameras) we're looking for?
Title: Re: ML on EOS-M2
Post by: Danne on December 28, 2018, 09:42:43 AM
Captured  logs following dfort´s suggestions:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/ADTG_photo_and_movie_mode%20EOSM2.LOG

Below was with ENGIO registers on as well:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/ADTG_photo_mode_EOSM2.LOG
https://bitbucket.org/Dannephoto/magic-lantern/downloads/ADTG_movie_mode_EOSM2.LOG

Doubt it worked but maybe some other fun stuff was logged.
Title: Re: ML on EOS-M2
Post by: dfort on December 28, 2018, 04:42:27 PM
Still can't find it. Looks like it is different on the 6D so it might also be the case on the EOSM2? It is probably in the logs but we don't know which one it is?

Code: [Select]
00f00000:     803 ISO=100 Tv=60 Av=35 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f0 Analog ISO (most cameras)
...
00f00003:     f08 ISO=100 Tv=60 Av=35 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d93f6 Analog ISO on 6D

@Danne -- Don't see any task=ShootCapture events in your logs.  ???

Something @JohanJ pointed out that might help is turning on this ML image review option:

(https://farm5.staticflickr.com/4878/46448971132_dc3f1c97af.jpg) (https://flic.kr/p/2dLx7RS)

Something else that just occurred to me is that we can only save JPEG stills on the EOSM (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209282#msg209282), right? Could that the ShootCapture event we're looking for isn't happening? That address is needed for the Dual ISO module and that works with MLV, DNG and CR2 but not JPEG.
Title: Re: ML on EOS-M2
Post by: Danne on December 28, 2018, 04:55:54 PM
Cr2 files are saved just fine.
How to get ShootCapture events?
Image Review trick don't seem to work.


EDIT:
ShootCapture seems to register saving to log manually:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/ADTG_shoot.LOG



On a regular EOSM it looks like this. Assume this is what we´re after but on the eosm2?
Code: [Select]
Canon EOS M 2.0.2
00f00000:     803 ISO=100 Tv=50 Av=45 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=16d14 addr=4048124c Analog ISO (most cameras)

Yup. In dual_iso.c:
Code: [Select]
        PHOTO_CMOS_ISO_START = 0x4048124C;
Title: Re: ML on EOS-M2
Post by: dfort on December 28, 2018, 05:35:54 PM
Ok--now you're getting the ShootCapture events but what we're looking for still doesn't show up in the log. I take it that manual logging isn't happing at the same time the shutter fires?

Maybe figure out how to release the shutter when invoking manual logging?

[EDIT]
On a regular EOSM it looks like this. Assume this is what we´re after but on the eosm2?
Code: [Select]
Canon EOS M 2.0.2
00f00000:     803 ISO=100 Tv=50 Av=45 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=16d14 addr=4048124c Analog ISO (most cameras)

Yes, that's what we're looking for on the EOSM2.
Title: Re: ML on EOS-M2
Post by: Danne on December 28, 2018, 10:15:36 PM
Tried trigger the shootCapture event by logging regs while intervalometer would shoot a cr2 but with no success  :P
Title: Re: ML on EOS-M2
Post by: dfort on December 28, 2018, 11:09:53 PM
This works on the EOSM:

Code: [Select]
diff --git a/modules/adtg_gui/adtg_gui.c b/modules/adtg_gui/adtg_gui.c
--- a/modules/adtg_gui/adtg_gui.c
+++ b/modules/adtg_gui/adtg_gui.c
@@ -20,6 +20,8 @@
 #include "io_trace.c"
 #endif
 
+#include <shoot.h>
+
 #define DST_DFE     0xF000
 #define DST_CMOS16  0x0F00
 #define DST_CMOS    0x00F0
@@ -1006,6 +1008,8 @@
     msg[0] = 0;
     int len = 0;
     int saved_regs = 0;
+   
+    take_a_pic(0);
 
     len += snprintf(msg+len, size-len, "%s %s\n", camera_model, firmware_version);
     for (int i = 0; i < reg_num; i++)

Then just go into the ADTG Registers Advanced menu and run Log Registers Now.
Title: Re: ML on EOS-M2
Post by: dfort on December 29, 2018, 12:27:12 AM
Never mind. My EOSM2 arrived just now so I tried it and these were the only ShootCapture events it logged:

Code: [Select]
Canon EOS M2 1.0.3
...
0002c517:     500 (was 0)        ISO=100 Tv=100 Av=80 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=240ec addr=416d736c
0002c518:       0 ISO=100 Tv=100 Av=80 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=240ec addr=416d7370
0002c519:       0 ISO=100 Tv=100 Av=80 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=240ec addr=416d7374
0002c026:       0 ISO=100 Tv=100 Av=80 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=240ec addr=416d7368
...

Maybe that first one is the one we're looking for?

[EDIT] No, that gives "ISOless PH err(2)"
Title: Re: ML on EOS-M2
Post by: Danne on December 29, 2018, 09:39:46 AM
Err 2 instead of err 8. Always something  8)
Title: Re: ML on EOS-M2
Post by: JohanJ on December 29, 2018, 10:59:22 PM


There is another way to log photo capture alongside with LiveView - in adtg_gui, in the Advanced menu, set "Unique Key" to "Register + caller task". That way, still photo and LiveView registers will be logged as separate entities, rather than grouped together (even if both tasks will override the same register).

Caveat: you have to enable that option *before* enabling ADTG registers (i.e. it's not something you can change during a logging session). Go to the submenu first, while the stuff is still grayed out, change the unique key, then go back to enable the main menu entry.

Tried to set "Unique Key" to "Register + caller task" before doing anything else in the  ADTG Register Advanced submenu but as soon as I hit any key in Unique Key submenu I get the following yellow  message in ML bottom bar: "You can no longer change  this, sorry. Restart the camera."

Tried both dfort's latest nightly and the ISO research build. Both come up with this message.  adtg_gui.mo was the only thing active, everything else in ML menus like global draw etc. was inactivated before. Has this message been hard coded and the needed function been removed?

Sent from my SM-T719 using Tapatalk

Title: Re: ML on EOS-M2
Post by: Danne on December 29, 2018, 11:21:49 PM
Did you restart camera and went into the unique setting without turning adtg_gui on? After selection turn on adtg_gui.
Title: Re: ML on EOS-M2
Post by: JohanJ on December 29, 2018, 11:26:39 PM
Did you restart camera and went into the unique setting without turning adtg_gui on? After selection turn on adtg_gui.
Ah, my bad. Was not aware of that I can enter ADTG menu w/o activation. Now it works

Edit: still the same result,only Evf tasks logged

00f00000:     8b7 ISO=100 Tv=100 Av=20 lv=0 zoom=1 mv=0 res=-1 crop=-1 task=Evf pc=46284 addr=416d949a Analog ISO (most cameras)

Title: Re: ML on EOS-M2
Post by: dfort on December 30, 2018, 02:32:15 AM
@JohanJ - I spent several hours on it today and couldn't get that elusive address either.

Found out what was causing the LiveView screen freezes in photo mode was the raw histogram. I took out that feature for now and discovered that one line is out of place:

src/zebra.c (https://bitbucket.org/daniel_fort/magic-lantern/commits/cee3e91c8288bc1ba86ebbfb4bf6e56909040046)
Code: [Select]
             {
                 .name = "Histogram type",
                 .priv = &hist_type,
+                #ifdef FEATURE_RAW_HISTOGRAM
                 .update = raw_histo_update,
-                #ifdef FEATURE_RAW_HISTOGRAM
                 .max = 3,
                 #else
                 .max = 1,

Taking out this feature prevents a few modules from building but we're far from getting all the modules and features working properly on this camera.

I put up a new test build on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/). This time I wanted to see how many modules would compile. If you want to test any of these modules please read up on them first. So far we know dual_iso isn't working, simple silent is but full resolution silent isn't, no raw video recording yet and well, you tell me what else.

Found something interesting on this camera. It looks like they brought back Digital Zoom:

(https://farm8.staticflickr.com/7865/32643053248_ea63e7ba6d.jpg) (https://flic.kr/p/RJybsU)

What's interesting is that ML Movie crop mode is also working.

I'll be off for a week on vacation with an EOSM2 in my hands. I'll post some pictures using this latest build, provided it doesn't blow up!

[EDIT] On the bright side, the EOSM2 doesn't have the nasty shutter-bug that plagues the EOSM.
Title: Re: ML on EOS-M2
Post by: Danne on December 30, 2018, 08:55:39 AM
Regarding finding adress for dual iso wonder if it's a timing issue. When I check registers set in crop_rec I can see registers flash by in raw.c. first they will be set but quickly goes back to original registers. This is not the case when registers are set manually from adtg_gui. One  theory is that shootCapture might be shown briefly but it won't be logged because of some interrupting issue causing registers back into original state.
Title: Re: ML on EOS-M2
Post by: dfort on December 30, 2018, 03:21:38 PM
In cases like that what I would do is shoot a video of the screen then look at it frame-by-frame to find what the changed registers are doing. Here's a fun example (https://www.magiclantern.fm/forum/index.php?topic=21108.msg193855#msg193855).

Since we found the CMOS 0 value for LiveView I thought I'd check and see if the change for ShootCapture could be calculated but only the 650D and 700D values match. The others are all over the place and to find it by brute force would require something like 2,000 iterations. Ugh!

Interesting that shooting simple silent DNG's works but not MLV's. Figuring that out might also solve other issues like raw histogram freezing the screen.

I'm still thinking that a few stubs are off but critix and I have gone over them several times and they all seem to check out fine.
Title: Re: ML on EOS-M2
Post by: a1ex on December 31, 2018, 12:35:41 AM
OK, now that's a mystery. I've tried dfort's iso-research.2018Dec28.EOSM2103.zip in the emulator and had very little trouble getting ADTG registers from the ShootCapture task in ML menu. I did tweak the emulation quite a bit to be able to initiate a photo capture, so... it won't work out of the box; don't try it.

Code: [Select]
Canon EOS M2 1.0.3
0002c001:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6b90
0002c021:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6b94
0002c009:       6 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6b98
0002c0a5:     1e4 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6b9c
0002c0dc:    f281 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6ba0
0002c0de:    7a09 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6ba4
0002c0d9:    4009 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6ba8
0002c0f0:    4904 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6bac
0002c0dd:     571 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6bb0
0002c0df:     ca0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6bb4
0002c0fb:       7 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6bb8
0002c0d8:    4805 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6bbc
0002c070:     e22 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6bc0
0002c0e1:     419 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6bc4
0002c0e2:       2 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6bc8
0002c002:     19f ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e08 addr=416d6bcc
0002c000:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22e7c addr=416d6bec
0002c020:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c4c
0002c00d:    5249 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c50
0002c058:       3 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c54
0002c075:    2202 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c58
0002c01c:    22fe ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c5c
0002c01b:     ff1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c60
0002c0b0:    e000 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c64
0002c0b1:     1e3 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c68
0002c0b3:    ffff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c6c
0002c0b4:    ffff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c70
0002c0b5:    1fff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c74
0002c0b7:     201 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c78
0002c014:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c7c
0002c012:      18 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c80
0002c00e:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c84
0002c00f:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c88
0002c010:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c8c
0002c011:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c90
0002c015:     800 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c94
0002c016:     800 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c98
0002c017:     800 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6c9c
0002c018:     800 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6ca0
0002c019:     fff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6ca4
0002c01a:     fff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6ca8
0002c079:    2000 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cac
0002c07a:    2000 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cb0
0002c06e:    1808 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cb4
0002c06f:    3828 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cb8
0002c077:     410 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cbc
0002c078:     832 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cc0
0002c06d:    1000 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cc4
0002c07d:    2202 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cc8
0002c030:       6 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6ccc
0002c031:       7 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cd0
0002c032:       9 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cd4
0002c037:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cd8
0002c038:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cdc
0002c039:      72 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6ce0
0002c03a:     472 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6ce4
0002c03b:      72 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6ce8
0002c03c:     472 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cec
0002c03d:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cf0
0002c03e:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cf4
0002c03f:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cf8
0002c040:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6cfc
0002c041:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d00
0002c042:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d04
0002c043:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d08
0002c044:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d0c
0002c047:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d10
0002c048:     100 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d14
0002c049:       5 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d18
0002c04a:     401 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d1c
0002c04b:       8 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d20
0002c056:      ff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d24
0002c083:    3003 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d28
0002c082:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d2c
0002c093:      40 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d30
0002c094:       2 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d34
0002c086:       4 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d38
0002c087:    ffff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d3c
0002c088:    ffff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d40
0002c089:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d44
0002c08a:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d48
0002c0a0:       3 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d4c
0002c09c:     400 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d50
0002c09b:     177 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d54
0002c080:      ff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d58
0002c0c0:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d5c
0002c0c1:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f30 addr=416d73b4
0002c0c2:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d64
0002c00a:      70 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d68
0002c004:      18 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d6c
0002a000:    fff1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d70
0002a001:    4001 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d74
0002a002:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d78
0002a003:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d7c
0002a004:    fff2 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d80
0002a005:    4001 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d84
0002a006:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d88
0002a007:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d8c
0002a008:    fff4 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d90
0002a009:    4001 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d94
0002a00a:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d98
0002a00b:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6d9c
0002a00c:    fff8 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6da0
0002a00d:    4001 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6da4
0002a00e:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6da8
0002a00f:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dac
0002a010:    fff9 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6db0
0002a011:    4001 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6db4
0002a012:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6db8
0002a013:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dbc
0002a014:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dc0
0002a015:     14a ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dc4
0002a016:    8000 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dc8
0002a017:       2 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dcc
0002a018:    f005 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dd0
0002a019:    ffff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dd4
0002a01a:    ffff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dd8
0002a01b:     fff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6ddc
0002a01c:       6 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6de0
0002a01d:     dc9 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6de4
0002a01e:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6de8
0002a01f:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dec
0002a020:      5c ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6df0
0002a021:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6df4
0002a022:      70 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6df8
0002a023:     fff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6dfc
0002c500:       8 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22efc addr=416d6e00
00028900:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65d0
00028802:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65d4
00028804:      79 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65d8
00028806:       8 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65dc Causes interlacing artifacts
0002880e:     800 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65e0
00028812:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65e4
00028813:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65e8
000288fc:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65ec
00028820:     300 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65f0
00028821:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65f4
00028822:      21 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65f8
00028826:       9 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d65fc
00028827:      65 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6600
00028828:    3222 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6604
00028829:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6608
0002882a:     7ff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d660c
0002882c:     800 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6610
0002882e:       6 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6614
00028830:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6618 Only slightly changes the color of the image (g3gg0)
00028832:      22 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d661c
00028836:    1022 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6620
00028837:      11 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6624
00028838:      cd ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6628
00028839:       4 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d662c
0002883a:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6630
0002883c:      69 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6634
00028840:      35 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6638
00028842:      6a ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d663c
00028846:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6640
00028848:     1ff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6644
0002884a:     600 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6648
0002884b:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d664c
00028862:      31 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6650
00028866:       d ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6654
00028868:       4 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6658
0002886a:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d665c
00028880:     800 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6660 Black level (reference value for the feedback loop?)
00028889:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6664
0002888a:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6668
000288b2:     742 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d666c
000288b4:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6670
000288b6:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6674
000288b8:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6678
000288ba:      fe ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d667c
000288bc:      ff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6680
000288c2:      13 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6684
000288d4:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6688
000288e9:      10 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d668c
000288ea:      61 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6690
000288ec:      ff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6694
000288ee:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f08 addr=416d6698
00028300:    3001 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f6c
00028005:       6 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f70
00028006:     7c2 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f74
00028007:     7c2 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f78
0002800a:      41 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f7c
00028026:       6 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f80
00028027:       8 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f84
0002802c:     110 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f88
0002802f:     864 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f8c
00028030:     822 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f90
00028031:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f94
00028032:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f98
00028035:      1f ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5f9c
00028036:      13 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fa0
00028037:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fa4
0002803b:     864 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fa8
0002803c:     822 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fac
0002803d:      1f ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fb0
0002803e:      13 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fb4
0002803f:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fb8
00028043:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fbc
00028044:       6 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fc0
00028047:     110 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fc4
0002804a:     82f ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fc8
0002804b:     812 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fcc
0002804c:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fd0
0002804d:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fd4
00028050:      36 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fd8
00028051:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fdc
00028052:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fe0
00028056:     82f ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fe4
00028057:     812 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fe8
00028058:      36 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5fec
00028059:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5ff0
0002805a:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5ff4
0002805e:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5ff8 Shutter blanking for x5/x10 zoom
0002805f:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d5ffc Shutter blanking for x5/x10 zoom
00028060:       6 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6000 Shutter blanking for LiveView 1x
00028061:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6004 Shutter blanking for LiveView 1x
00028069:     839 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6008
0002806a:     832 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d600c
0002806b:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6010
0002806c:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6014
0002806f:      39 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6018
00028070:      2d ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d601c
00028071:     839 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6020
00028072:     832 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6024
00028073:      39 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6028
00028074:      2d ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d602c
00028079:     101 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6030
00028080:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6034
00028081:      2d ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6038
00028082:      3c ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d603c
00028083:      2d ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6040
00028084:      3c ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6044
00028088:      21 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6048
00028089:     164 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d604c
0002808c:      21 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6050
0002808d:     164 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6054
00028097:      19 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6058
00028098:     869 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d605c
0002809d:       3 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6060
0002809e:      13 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6064
0002809f:      90 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6068
000280a0:     199 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d606c
000280a1:      19 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6070
000280a2:     869 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6074
000280a3:       3 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6078
000280a4:      13 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d607c
000280a5:      90 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6080
000280a6:     199 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6084
000280ae:      21 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6088
000280af:      78 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d608c
000280b0:      b1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6090
000280b1:     16d ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6094
000280ba:      21 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6098
000280bb:      78 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d609c
000280bc:      b1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60a0
000280bd:     16d ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60a4
000280c9:      21 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60a8
000280ca:      78 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60ac
000280cb:      ca ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60b0
000280cc:      be ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60b4
000280d5:      21 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60b8
000280d6:      78 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60bc
000280d7:      ca ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60c0
000280d8:      be ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60c4
000280e4:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60c8
000280e5:     164 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60cc
000280e6:      cc ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60d0
000280f1:     164 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60d4
000280f2:      cc ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60d8
00028101:      b4 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60dc
00028102:     1b7 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60e0
00028103:      b4 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60e4
00028104:     1b7 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60e8
00028134:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60ec
00028135:      61 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60f0
00028136:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60f4
00028137:      61 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60f8
0002813a:     110 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d60fc
0002814d:      26 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6100
0002814e:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6104
0002814f:      60 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6108
00028150:      26 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d610c
00028151:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6110
00028152:      60 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6114
00028155:      10 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6118
00028170:      11 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d611c
00028176:      11 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6120
0002817a:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6124
0002817b:     101 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6128
0002817c:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d612c
0002817d:     101 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6130
000281a2:      11 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6134
000281a4:    2901 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6138
000282a9:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d613c
000282aa:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6140
000282af:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6144
000282b0:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6148
000282b5:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d614c
000282b6:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6150 PowerSaveTiming 'on'? set to Line count - 1
000282bb:      1a ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6154
000282bc:      27 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6158
000282c7:      1a ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d615c
000282c8:      27 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6160
000282d7:      1a ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6164
000282d8:      27 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6168
000282e3:      1a ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d616c
000282e4:      27 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6170
000282f0:     500 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6174
000282f3:     318 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6178 Line count that gets darker (top optical black related)
000282f6:     400 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d617c
000282fa:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6180
000282fb:      61 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6184
000282fc:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6188
000282fd:      61 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d618c
0002811a:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f14 addr=416d6190
0002c51b:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f2c addr=416d7284
0002c51c:    1100 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f2c addr=416d7288
0002c501:    5454 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b7c addr=416d72a8
0002c502:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b7c addr=416d72ac
0002c503:     707 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b7c addr=416d72b0
0002c504:     707 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b7c addr=416d72b4
0002c505:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b7c addr=416d72b8
0002c506:       3 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d72d8
0002c51a:       2 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d72dc
0002c507:    3fff ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d72e0
0002c508:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d72e4
0002c509:      4e ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d72e8
0002c50a:       1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d72ec
0002c50b:      5a ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d72f0
0002c50c:       2 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d72f4
0002c50d:      55 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d72f8
0002c50e:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d72fc
0002c50f:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d7300
0002c510:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d7304
0002c511:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d7308
0002c512:       3 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d730c
0002c513:      e6 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d7310
0002c514:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d7314
0002c515:      5a ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d7318
0002c516:    2000 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22b8c addr=416d731c
00024002:    1886 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75ac
00024003:      28 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75b0
00024004:    1906 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75b4
00024005:      1c ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75b8
00024006:    1a86 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75bc
00024007:      12 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75c0
00024008:     186 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75c4
00024009:    c0e1 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75c8
0002400a:     106 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75cc
0002400b:    c0a7 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75d0
0002400c:    1006 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75d4
0002400d:    ffd9 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75d8
0002400e:      15 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75dc
0002400f:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75e0
00024010:      25 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75e4
00024011:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75e8
00024012:      86 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75ec
00024013:     411 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75f0
00024014:    218c ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75f4
00024015:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75f8
00024016:      86 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d75fc
00024017:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7600
00024018:    210c ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7604
00024019:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7608
0002401a:      35 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d760c
0002401b:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7610
0002401c:      2d ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7614
0002401d:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7618
0002401e:      86 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d761c
0002401f:     413 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7620
00024020:    218c ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7624
00024021:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7628
00024022:      86 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d762c
00024023:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7630
00024024:    210c ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7634
00024025:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7638
00024026:      35 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d763c
00024027:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7640
00024028:      86 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7644
00024029:     411 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7648
0002402a:    218c ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d764c
0002402b:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7650
0002402c:      86 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7654
0002402d:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7658
0002402e:    210c ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d765c
0002402f:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7660
00024030:    7106 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7664
00024031:      40 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7668
00024032:      35 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d766c
00024033:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f4c addr=416d7670
00027c0b:       3 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74a4
00027c0f:       3 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74a8
00027c25:      7e ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74ac
00027ce0:      80 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74b0
00027ce5:      c0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74b4
00027cf1:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74b8
00027d02:      c0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74bc
00027d0d:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74c0
00027cd0:     173 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74c4
00027cd1:      23 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74c8
00027cd8:     173 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74cc
00027cd9:       6 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74d0
00027cda:     173 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74d4
00027cdb:      26 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74d8
00027d03:       3 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74dc
00027ce3:    d000 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f5c addr=416d74e0
00027c34:       2 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f6c addr=416d7500
00027c22:      10 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f6c addr=416d7510
00027c21:       0 ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f6c addr=416d7508
00027c20:    ffef ISO=100 Tv=8 Av=99 lv=1 zoom=1 mv=0 res=-1 crop=-1 task=ShootCapture pc=22f6c addr=416d750c
==================================================================

I've even got the CMOS registers on the console, but couldn't get back into menu afterwards, so these were not in the log. Not sure if it's of any help, as the memory address might be dynamic (like on 700D and others), and I could only capture it at ISO 100, but here it goes:
Code: [Select]
[ShootCapture:000232e8 ] cmos_write(0x416D70E0)
                             CMOS[0] <- 0x803
                             CMOS[1] <- 0x4CE
                             CMOS[2] <- 0xC6
                             CMOS[3] <- 0x900
                             CMOS[4] <- 0x2
                             CMOS[5] <- 0x0
                             CMOS[6] <- 0x42B
                             CMOS[7] <- 0x800
                             CMOS[8] <- 0x0
                             CMOS[9] <- 0x81

In other words, I have no idea why it fails to log ShootCapture events on real hardware. Maybe I should just double-check everything from scratch (stubs, consts and so on).

There is a minor difference in one of the stubs (these are mine (https://bitbucket.org/hudson/magic-lantern/commits/3fd9477c4966e4c4d86a55067b0ea1cb3dd6ae0a)), but I highly doubt it makes a difference.

Regarding finding adress for dual iso wonder if it's a timing issue. When I check registers set in crop_rec I can see registers flash by in raw.c. first they will be set but quickly goes back to original registers. This is not the case when registers are set manually from adtg_gui. One  theory is that shootCapture might be shown briefly but it won't be logged because of some interrupting issue causing registers back into original state.

No, adtg_gui does not poll anything. It attempts to log every single call to adtg_write, cmos_write and so on, no matter who calls these functions. Even if the registers are overridden in the next microsecond, it should be able to log them.

I've got another theory, after playing with it in QEMU: adtg_gui only saves *visible* registers, but the visibility bit is only set when you actually browse the menu (specifically, the "Show" menu entry does the update); otherwise, all of the entries are hidden by default. So, rather than auto-logging, try looking in the menu first, and afterwards, after you see the ShootCapture registers in the menu, save them to card ("Log registers now") manually.
Title: Re: ML on EOS-M2
Post by: dfort on December 31, 2018, 06:04:52 AM
Thanks for the tips.

I tried your ADTG_WRITE_FUNC stub but that didn't make a difference. I also tested 0x416D70E0 for PHOTO_CMOS_ISO_START but still get ISOless PH err( 8 ).

I'm able to capture a bunch of ShootCapture events with "Log registers now" manually but that elusive 00f00000 ShootCapture event just doesn't seem to reveal itself.
Title: Re: ML on EOS-M2
Post by: dfort on January 02, 2019, 02:47:39 AM
How about taking the EOSM2 with ML out in the field? Yeah, not many features are working yet but here's one that is:

Movie crop mode
(https://farm8.staticflickr.com/7906/45649366535_b956bba721.jpg) (https://flic.kr/p/2cxSWgH)

Same settings without Movie crop mode
(https://farm8.staticflickr.com/7828/44745601760_5a67ac9689.jpg) (https://flic.kr/p/2bb1Uuq)

No big deal. These are from H.264 files and the EOSM2 has digital zoom mode for video that does the same thing but hey, the camera is usable while ML is loaded so that's an accomplishment!

(https://farm8.staticflickr.com/7801/45839515864_4953dc397c.jpg) (https://flic.kr/p/2cQFv3q)

BTW--These were shot at the Elephant Seal Rookery in San Simeon, California. These are in the wild and not in a zoo. Canon EF-S 55-250mm STM lens with an EF to EF-M adapter.

Shooting CR2 and JPEG with ML loaded is also working. Yay!

(https://farm5.staticflickr.com/4918/31622635947_846bde6b78.jpg) (https://flic.kr/p/QbogXa)

(https://farm8.staticflickr.com/7893/46563605711_8298d0651f.jpg) (https://flic.kr/p/2dWEDJ8)
Title: Re: ML on EOS-M2
Post by: Danne on January 02, 2019, 08:09:33 AM
Nice animal.
You can shoot raw lossless. Set fps override to 24 then push timer a under advanced settings with something like 50 units, can't remember exactly. Free liveview by pushing menu button twice.
Title: Re: ML on EOS-M2
Post by: dfort on January 02, 2019, 09:02:44 AM
Really? Try doing that while being chased by an elephant seal.

Anyway--thought I'd try running some tests with yet another new build. Merged in qemu and lua_fix. Test build on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).

Call for testers - as lately I've been hunting various bugs on this branch, and noticed some of the changes introduced model-specific issues (for example, api_test.lua was failing on 60D on one of the earliest tests).

For every single camera model available on the Experiments page (lua_fix build), please run:

- api_test.lua (upload the log)
- selftest.mo -> stubs tests (upload the log)
- bench.mo -> memory benchmarks (upload the screenshot)
- overall sanity check (for example, if you decide to take this build out and use it for a couple of hours, please report back)

Looks like there is a problem with the Menu/GUI stubs? Also looks like this camera has some nunchucks -- I mean num_chunks issues.

api_test.lua
(https://farm8.staticflickr.com/7857/46567100731_cc4c7ea4c1.jpg) (https://flic.kr/p/2dWYyF6)

LUATEST.LOG
Code: [Select]
===============================================================================
ML/SCRIPTS/API_TEST.LUA - 2019-1-1 23:20:32
===============================================================================

Strict mode tests...
Strict mode tests passed.

Generic tests...
arg = table:
  [0] = "API_TEST.LUA"
camera = table:
  shutter = table:
    raw = 104
    apex = 6.
    ms = 16
    value = 0.015625
  aperture = table:
    raw = 48
    apex = 5.
    value = 5.6
    min = table:
      raw = 40
      apex = 4.
      value = 4.
    max = table:
      raw = 80
      apex = 9.
      value = 22.6
  iso = table:
    raw = 72
    apex = 5.
    value = 100
  ec = table:
    raw = 0
    value = 0
  flash = true
  flash_ec = table:
    raw = 0
    value = 0
  kelvin = 6500
  mode = 3
  metering_mode = 3
  drive_mode = 0
  model = "Canon EOS M2"
  model_short = "EOSM2"
  firmware = "1.0.3"
  temperature = 211
  gui = table:
    menu = false
    play = false
    play_photo = false
    play_movie = false
    qr = false
    idle = false
  shoot = function: 0xb0c564
  wait = function: 0xb0b490
  bulb = function: 0xb0c798
  reboot = function: 0xb0c538
  burst = function: 0xb0c818
event = table:
  pre_shoot = nil
  post_shoot = nil
  shoot_task = nil
  seconds_clock = nil
  keypress = nil
  custom_picture_taking = nil
  intervalometer = nil
  config_save = nil
console = table:
  hide = function: 0xb09e14
  show = function: 0xb09e24
  write = function: 0xb09eb8
  clear = function: 0xb09e04
lv = table:
  enabled = true
  paused = false
  running = true
  zoom = 1
  overlays = false
  pause = function: 0xb0d048
  stop = function: 0xb0c9b0
  wait = function: 0xb0d408
  info = function: 0xb0cd44
  resume = function: 0xb0d038
  start = function: 0xb0c9a0
lens = table:
  name = "EF-S55-250mm f/4-5.6 IS STM"
  focal_length = 55
  focus_distance = 655350
  hyperfocal = 28540
  dof_near = 27357
  dof_far = 1000000
  af = true
  af_mode = 0
  focus = function: 0xb0e0b4
  autofocus = function: 0xb0deec
display = table:
  idle = nil
  height = 480
  width = 720
  load = function: 0xb0ec24
  off = function: 0xb0e930
  print = function: 0xb0fd60
  clear = function: 0xb0e84c
  notify_box = function: 0xb0e9f4
  pixel = function: 0xb0fb94
  screenshot = function: 0xb0e85c
  on = function: 0xb0e940
  rect = function: 0xb0f568
  draw = function: 0xb0eadc
  line = function: 0xb0f8cc
  circle = function: 0xb0f298
key = table:
  last = 10
  press = function: 0xb10538
  wait = function: 0xb10270
menu = table:
  visible = false
  set = function: 0xb11b24
  close = function: 0xb10898
  new = function: 0xb12960
  get = function: 0xb11d04
  block = function: 0xb10aa0
  select = function: 0xb11a50
  open = function: 0xb108b0
movie = table:
  recording = false
  stop = function: 0xb0e4b4
  start = function: 0xb0e548
dryos = table:
  clock = 23
  ms_clock = 23408
  image_prefix = "IMG_"
  config_dir = table:
    exists = true
    create = function: 0xb13c84
    children = function: 0xb13b0c
    files = function: 0xb139f0
    parent = table:
      exists = true
      create = function: 0xb13c84
      children = function: 0xb13b0c
      files = function: 0xb139f0
      parent = table:
        exists = true
        create = function: 0xb13c84
        children = function: 0xb13b0c
        files = function: 0xb139f0
        parent = nil
        path = "B:/"
      path = "ML/"
    path = "ML/SETTINGS/"
  ml_card = table:
    drive_letter = "B"
    dcim_dir = table:
      exists = true
      create = function: 0xb13c84
      children = function: 0xb13b0c
      files = function: 0xb139f0
      parent = table:
        exists = true
        create = function: 0xb13c84
        children = function: 0xb13b0c
        files = function: 0xb139f0
        parent = table:
          exists = true
          create = function: 0xb13c84
          children = function: 0xb13b0c
          files = function: 0xb139f0
          parent = nil
          path = "B:/"
        path = "B:/DCIM/"
      path = "B:/DCIM/100CANON/"
    file_number = 1393
    folder_number = 100
    free_space = 13128
    image_path = function: 0xb13e60
    type = "SD"
    path = "B:/"
    _card_ptr = userdata
  shooting_card = table:
    drive_letter = "B"
    dcim_dir = table:
      exists = true
      create = function: 0xb13c84
      children = function: 0xb13b0c
      files = function: 0xb139f0
      parent = table:
        exists = true
        create = function: 0xb13c84
        children = function: 0xb13b0c
        files = function: 0xb139f0
        parent = table:
          exists = true
          create = function: 0xb13c84
          children = function: 0xb13b0c
          files = function: 0xb139f0
          parent = nil
          path = "B:/"
        path = "B:/DCIM/"
      path = "B:/DCIM/100CANON/"
    file_number = 1393
    folder_number = 100
    free_space = 13128
    image_path = function: 0xb13e60
    type = "SD"
    path = "B:/"
    _card_ptr = userdata
  cf_card = nil
  sd_card = table:
    drive_letter = "B"
    dcim_dir = table:
      exists = true
      create = function: 0xb13c84
      children = function: 0xb13b0c
      files = function: 0xb139f0
      parent = table:
        exists = true
        create = function: 0xb13c84
        children = function: 0xb13b0c
        files = function: 0xb139f0
        parent = table:
          exists = true
          create = function: 0xb13c84
          children = function: 0xb13b0c
          files = function: 0xb139f0
          parent = nil
          path = "B:/"
        path = "B:/DCIM/"
      path = "B:/DCIM/100CANON/"
    file_number = 1393
    folder_number = 100
    free_space = 13128
    image_path = function: 0xb13e60
    type = "SD"
    path = "B:/"
    _card_ptr = userdata
  date = table:
    hour = 23
    sec = 33
    year = 2019
    month = 1
    isdst = false
    wday = 3
    yday = 1
    day = 1
    min = 20
  directory = function: 0xb13550
  rename = function: 0xb13410
  call = function: 0xb1320c
  remove = function: 0xb134e4
interval = table:
  time = 10
  count = 0
  running = false
  stop = function: 0xb148a0
battery = table:
function not available on this camera
stack traceback:
[C]: in ?
[C]: in for iterator 'for iterator'
ML/SCRIPTS/LIB/logger.lua:125: in function 'logger.serialize'
ML/SCRIPTS/API_TEST.LUA:45: in function <ML/SCRIPTS/API_TEST.LUA:44>
[C]: in function 'globals.xpcall'
ML/SCRIPTS/API_TEST.LUA:44: in function 'globals.print_table'
ML/SCRIPTS/API_TEST.LUA:90: in function 'globals.generic_tests'
ML/SCRIPTS/API_TEST.LUA:1494: in function <ML/SCRIPTS/API_TEST.LUA:1490>
[C]: in function 'globals.xpcall'
ML/SCRIPTS/API_TEST.LUA:1490: in function 'globals.api_tests'
ML/SCRIPTS/API_TEST.LUA:1529: in main chunktask = table:
  create = function: 0xb15088
  yield = function: 0xb14f08
property = table:
Generic tests completed.

Module tests...
Testing file I/O...
Copy test: autoexec.bin -> tmp.bin
Copy test OK
Append test: tmp.txt
Append test OK
Rename test: apple.txt -> banana.txt
Rename test OK
Rename test: apple.txt -> ML/banana.txt
Rename test OK
SD card (B:/) present
- free space: 13128 MiB
- next image: B:/DCIM/100CANON/IMG_1394.CR2
- DCIM dir. : B:/DCIM/100CANON/
- B:/DCIM/100CANON/IMG_1352.CR2
- B:/DCIM/100CANON/IMG_1353.CR2
- B:/DCIM/100CANON/MVI_1354.MOV
- B:/DCIM/100CANON/MVI_1355.MOV
- B:/DCIM/100CANON/MVI_1356.MOV
- B:/DCIM/100CANON/MVI_1357.MOV
- B:/DCIM/100CANON/MVI_1358.MOV
- B:/DCIM/100CANON/MVI_1359.MOV
- B:/DCIM/100CANON/MVI_1360.MOV
- B:/DCIM/100CANON/IMG_1361.CR2
- B:/DCIM/100CANON/IMG_1362.CR2
- B:/DCIM/100CANON/IMG_1363.CR2
- B:/DCIM/100CANON/IMG_1364.CR2
- B:/DCIM/100CANON/IMG_1365.CR2
- B:/DCIM/100CANON/MVI_1366.MOV
- B:/DCIM/100CANON/MVI_1367.MOV
- B:/DCIM/100CANON/MVI_1368.MOV
- B:/DCIM/100CANON/MVI_1369.MOV
- B:/DCIM/100CANON/IMG_1370.CR2
- B:/DCIM/100CANON/IMG_1371.CR2
- B:/DCIM/100CANON/IMG_1372.CR2
- B:/DCIM/100CANON/IMG_1373.CR2
- B:/DCIM/100CANON/IMG_1374.CR2
- B:/DCIM/100CANON/IMG_1375.CR2
- B:/DCIM/100CANON/IMG_1376.CR2
- B:/DCIM/100CANON/IMG_1377.CR2
- B:/DCIM/100CANON/IMG_1378.CR2
- B:/DCIM/100CANON/IMG_1379.CR2
- B:/DCIM/100CANON/IMG_1380.CR2
- B:/DCIM/100CANON/IMG_1381.CR2
- B:/DCIM/100CANON/IMG_1382.CR2
- B:/DCIM/100CANON/IMG_1383.CR2
- B:/DCIM/100CANON/IMG_1384.CR2
- B:/DCIM/100CANON/MVI_1385.MOV
- B:/DCIM/100CANON/MVI_1386.MOV
- B:/DCIM/100CANON/IMG_1387.CR2
- B:/DCIM/100CANON/MVI_1388.MOV
- B:/DCIM/100CANON/MVI_1389.MOV
- B:/DCIM/100CANON/IMG_1390.CR2
- B:/DCIM/100CANON/MVI_1391.MOV
- B:/DCIM/100CANON/IMG_1392.CR2
- B:/DCIM/100CANON/MVI_1393.MOV
- B:/SPOTLI~1/
  - B:/SPOTLI~1/STORE-V2/
    - B:/SPOTLI~1/STORE-V2/DEEEAF~1/
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~1.REP/
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~1.COR/
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~1.LIV/
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~2.LIV/
        - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~2.LIV/RETIRE.26
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~3.LIV/
        - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~3.LIV/JOURNA~1.163
        - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~3.LIV/RETIR~1.163
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~4.LIV/
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~1.ASS/
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~2.ASS/
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~1.HEA/
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~1.MIG/
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~2.MIG/
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~1.SCA/
        - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~1.SCA/RETIRE.582
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/PSID.DB
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/TM~1.SNO
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/TM~1.LIO
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIO~1.CRE
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/TMP.CAB
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/CA~1.CRE
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/INDEXS~1
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~1.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~~2.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~~~3.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~~~~4.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~1.SHA
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~~~~~5.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~~~~~~37.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~~~~~~40.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~1.DIR
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/STOR~1.UPD
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/0DIREC~1.SHA
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~~2.SHA
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~~~~~~54.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~~~~~~57.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/~~~~~~60.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~1.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/PERMST~1
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/CA~1.MOD
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~2.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~3.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~4.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~1.SHA
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~5.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~90.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~93.IND
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/STORE.DB
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/STOR~1.DB
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/REVERS~1
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/TMPSPO~1.STA
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/STORE_~1
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/JOURNA~1
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/SHUTDO~1
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/REVERS~1.SHA
      - B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~152.SH