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 :)
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 ...
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.
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:
Quote from: thetechhimself on September 05, 2015, 10:41:16 PM
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.
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
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.
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?
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 :(
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)
Quote from: a1ex on October 04, 2014, 08:30:21 AM
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 :)
Interesting.
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!
wouldn't it make more sense to start a new thread for the 7D MKII instead of posting the question here??
does this mean we could start porting ml to eos m2?
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?
Quote from: glassescreditsroll on October 19, 2015, 09:15:54 AM
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.
Quote from: godashram on October 20, 2015, 12:57:29 AM
Guess the biggest issue would be finding someone to actively work on an M2 build?
Correct.
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
Quote from: godashram on October 20, 2015, 12:57:29 AM
Guess the biggest issue would be finding someone to actively work on an M2 build?
Quote from: a1ex on November 01, 2015, 07:08:36 PM
Correct.
Current developers are happy to help. But there needs to be someone else to take on the bulk of the development work.
Quote from: Audionut on November 06, 2015, 06:08:50 AM
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 :)
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.
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.
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...!
Wow, thats prety cheap. I bought mine for about 280 dolars, without lens.
WOW, for $285 with 2 lenses is NUTS! it's a great camera... but hunting down someone to work on it isn't easy :(
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...
fulfilled by amazon.... so maybe...
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
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.
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.
any updates for the M2? :)
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 :)
nope, as far as I know, there isn't anyone willing to work on it.
Bump. Is there any progress with m2? I can help with testing ML, I have m2.
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?
Quote from: dfort on May 24, 2017, 05:50:16 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.
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:
{
.name = "EOSM2",
.digic_version = 5,
}
The others are likely model-specific, so let's not assume too much from the beginning. Let's try:
./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:
.serial_flash_size = 0x1000000,
Unfortunately, this step doesn't change anything in the emulation. Let's look at the next messages:
...
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):
./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):
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:
./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:
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.
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:
QuoteCorrects 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.
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.
Quote from: a1ex on May 24, 2017, 09:23:14 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:
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.
Quote from: a1ex on October 04, 2014, 08:30:21 AMIt 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.
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).
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:
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:./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.
Took some more baby steps. First a fall.
Quote from: a1ex on May 24, 2017, 12:17:11 PM
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:
.serial_flash_size = 0x1000000,
All that did was to consistently give me this error when running QEMU:
[EOS] loading './EOSM2/ROM0.BIN' to 0xF0000000-0xF0FFFFFF
[EOS] loading './EOSM2/ROM1.BIN' to 0xF8000000-0xF8FFA6FF
Could not open ./EOSM2/SFDATA.BINI 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.
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"
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?
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.
Quote from: 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)
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.
-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.
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.
Quote from: a1ex on May 24, 2017, 12:17:11 PM
To be continued.
Looking forward to it!
Alright, so let's start from where we've left off.
Quote from: a1ex on May 24, 2017, 12:17:11 PM
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:
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):
./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:
[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:
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:
./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):
(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:
disas 0x4B0,0x6B0
Method 3: dump the memory from gdb:
(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):
(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:
./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:
(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:
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:
./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):
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:
./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):
./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):
# ./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
./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:
.current_task_addr = 0x8FBCC,
That's it for today.
Quote from: a1ex on May 26, 2017, 11:09:39 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.
./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).
Quote from: a1ex on May 26, 2017, 11:09:39 PM
We now have task information and debug messages!
... and also an option to show all context switches:
./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)
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!
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.
Quote from: a1ex on May 24, 2017, 12:17:11 PM
.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
QuoteReverse 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:
SerialFlash Initialize
[EEPROM-DMA]! [0x2D0000] -> [0x416D5B00] (0x1DC400 bytes)
Also, error messages like this will disappear after declaring .serial_flash_size:
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:
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:
.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:
[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:
[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:
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:
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:
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.
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:
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:
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:
# 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:
[ 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:
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:
(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:
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:
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:
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:
(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:
# 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:
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:
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):
[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.
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!
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.
Quote from: a1ex on May 26, 2017, 11:09:39 PM
...One of these covers the functions we are interested in:
[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:
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:
[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.
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.
Quote from: dfort on June 03, 2017, 07:02:50 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.
QuoteThe 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 ;)
Quote from: a1ex on May 26, 2017, 11:09:39 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.
Quote from: a1ex on May 26, 2017, 11:09:39 PM
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:
./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.
(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."
Quote from: a1ex on May 26, 2017, 11:09:39 PM
OK, so the register we are looking for is read at 0x510. Let's disassemble with GDB:
(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.
You need to type the gdb commands at the gdb prompt. You'll need to start qemu like this:
./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:
./run_canon_fw.sh EOSM2,firmware="boot=0" -d io,int,nochain -singlestep |& grep "Enabled interrupt 0Ah"
Hope I'm not wearing out my QEMU welcome -- still stuck here:
Quote from: a1ex on May 26, 2017, 11:09:39 PM
./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):
(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?
[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:
(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.
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.
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./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S & arm-none-eabi-gdb -x debug-logging.gdb 2> error.txt
and found this:-bash: arm-none-eabi-gdb: command not found
Seems like I've got a configuration issue. It appears to be in the right place.
/Users/rosiefort/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gdb
If I make that long command even longer, it works:
./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?
This may help: https://unix.stackexchange.com/questions/183295/adding-programs-to-path
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.
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:
Quote from: a1ex on May 26, 2017, 11:09:39 PM
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:
./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.
...
[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:
./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:
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.
./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.
Quote from: a1ex on May 26, 2017, 11:09:39 PM
./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.
./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.
Quote from: a1ex on May 28, 2017, 03:13:05 PM
./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.
./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
QuoteChanging '|&' 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.
As I suspected the bash issue was a Mac thing.
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.
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:
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.
Been checking back everyday and was excited to see the updates today. Thanks so much for your continued work on this!
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:
Quote from: a1ex on May 29, 2017, 11:47:06 AM
Anyway, let's continue figuring out the emulation.
.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:
./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.
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:
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.
Quote from: a1ex on June 19, 2017, 09:43:34 AM
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.
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.
Seems oh so close.
EOSM2/debugmsg.gdb
# 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.
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)
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)
QuoteExercises:
- (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.
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.
Quote from: a1ex on June 20, 2017, 04:25:13 PM
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.
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.
Quote from: a1ex on June 21, 2017, 10:06:33 AM
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.
./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?
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
Wow--big progress! Did you already try it on your M2?
Quote from: dfort on June 21, 2017, 04:05:07 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.
Quote from: vagaboundedu on June 21, 2017, 07:47:08 PM
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.
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:
# 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):
# 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:
# 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:
# 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:
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:
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:
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:
. ./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):
. ./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:
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:
#!/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
./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:
. ./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?
Quote from: a1ex on June 24, 2017, 10:17:13 AM
# 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
Quote from: a1ex on June 24, 2017, 10:17:13 AM
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:
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.
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)
Quote from: a1ex on June 24, 2017, 10:17:13 AM
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)
Quote from: a1ex on June 24, 2017, 10:17:13 AM
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:
pip install gdbgui --upgradeYeah, 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:
sudo pip install gdbgui --upgrade --userNow 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:
brew tap homebrew/core
brew install dddAnd...
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.
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:
brew install cgdbWow, 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:
- Why isn't this version of splitgdb.sh by nkls in the qemu branch? I tried the current script and it skipped most of the breaks we put in debugmsg.gdb, missed the jump to autoexec.bin and launched the Canon GUI.
- Is the firmware signature it displayed to be trusted?
│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?
│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:
DRYOS PANIC: Module Code = 1, Panic Code = 2Catch 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.)
Quote from: dfort on June 25, 2017, 04:46:14 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).
QuoteIs 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).
QuoteOops! You have found a bug in DDD.
That's too bad - a very powerful piece of software apparently unmaintained for about 8 years...
QuoteDRYOS 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:
-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):
(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).
Quote from: a1ex on June 25, 2017, 05:16:06 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
Quote from: a1ex on June 25, 2017, 05:16:06 PM
...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
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:
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.
60D in QEMU (from don't click me):
. ./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):
# 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:
# 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.
Quote from: a1ex on June 26, 2017, 11:00:55 AM
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:
"[LVEVF] evVdInterrupt LastRamClear Start!![4f1d7800]":That matches the first of the three buffers I'm searching for:
#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:
"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.
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.
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.
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.
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:
#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:
#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:
#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:
// #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:
#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.
For firmware 1.01 on 100D it's like you found out:
Quote from: dfort on June 30, 2017, 04:50:13 PM
#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.
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_COMBINATIONSFound this constant used in bitrate.c:
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- | 1920 | 24 | NTSC/PAL |
2- | 1920 | 25 | PAL |
3- | 1920 | 30 | NTSC |
4- | 1280 | 50 | PAL |
5- | 1280 | 60 | NTSC |
5- | 640 | 25 | PAL |
7- | 640 | 30 | NTSC |
However, this is what is in consts.h:
5D3.113
#define MOV_RES_AND_FPS_COMBINATIONS 5 // 3 fullhd, 2 hd, not changing the two VGA modes; worth trying with 9
100D.101
#define MOV_RES_AND_FPS_COMBINATIONS 4 // 2FHD, 1HD, 1VGA
700D.114, EOSM.202
#define MOV_RES_AND_FPS_COMBINATIONS 9Ok--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_PRESSEDThe 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:
#define AE_STATE (*(int8_t*)(0x366B8 + 0x1C))
#define AE_VALUE (*(int8_t*)(0x366B8 + 0x1D))Shouldn't it be?
#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.
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:
#define AE_STATE (*(int8_t*)(0x367B4 + 0x1C))
#define AE_VALUE (*(int8_t*)(0x367B4 + 0x1D))
...
#define HALFSHUTTER_PRESSED (*(int*)0x24884) is ok [0x2486C+0x18].
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...
Quote from: 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
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)
Quote from: JohanJ on July 01, 2017, 08:38:32 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.
Quote from: nikfreak on July 01, 2017, 08:16:47 PM
...
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??] |
Quote from: a1ex on July 01, 2017, 08:34:21 PM
[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.
Quote from: nikfreak on July 01, 2017, 08:16:47 PM
Take this for 700D.114:
#define AE_STATE (*(int8_t*)(0x367B4 + 0x1C))
#define AE_VALUE (*(int8_t*)(0x367B4 + 0x1D))
...
That's right--my bad.
Quote from: a1ex on July 01, 2017, 08:34:21 PM
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:
Quote from: xlc on January 01, 2017, 10:21:36 PM
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
But you can't use autoexpo.mo anyway on M/M2 because you don't have (one) more hardware buttons, right?
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.
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):
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:
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));
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:
Quote from: g3gg0 on July 02, 2017, 01:59:22 AM
... 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.
Quote from: 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.
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
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:
// 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
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
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
// http://magiclantern.wikia.com/wiki/Fonts
#define BFNT_CHAR_CODES 0xf71e485c
#define BFNT_BITMAP_OFFSET 0xf71e7a10
#define BFNT_BITMAP_DATA 0xf71eabc4Oops--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
0xff423a50: (+0x24) char_codes[]. 3165 charsAnd the addressed used in consts.h is:
#define BFNT_CHAR_CODES 0xF7363A50Revisiting the last time I ventured into the font rabbit hole:
Quote from: a1ex on February 14, 2017, 08:28:58 AM
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?
Quote from: dfort on July 03, 2017, 06:49:25 PM
So confused -- why doesn't find_fnt.py just spit out the right numbers?
It does - try this:
python find_fnt.py ROM0.BIN 0xF0000000
python find_fnt.py ROM0.BIN 0xF0000000
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?
// 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:
#define BFNT_CHAR_CODES 0xf7c5E9C0Running "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?
if (len(sys.argv)>2):
base = int(sys.argv[2], 16)
else:
base = 0xff010000I thought that was supposed to work with DIGIC 4 cameras.
Quote from: a1ex on July 02, 2017, 08:39:12 AM
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?
Quote from: a1ex on February 14, 2017, 08:28:58 AM
... 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.
QuoteYou 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.
Got it...I think.
boot-hack.c
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:
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.
Quote from: a1ex on July 03, 2017, 09:50:39 PM
...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.
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:
Quote from: g3gg0 on June 27, 2013, 12:31:10 AM
the bin can be parsed with the python script in the module directory ;)
In any case, running this:
python parse_bin.py -f ROM1.BINcreated 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:
#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.
Thought I'd try something easy:
Quote from: a1ex on May 29, 2017, 11:47:06 AM
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:
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:
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:
./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)
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:
[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:
./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:
...
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:
# 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:
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:
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:
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.
Quote from: a1ex on July 06, 2017, 05:24:47 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:
QuoteThe 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
#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
Quote from: a1ex on July 06, 2017, 05:24:47 PM
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
#define HIJACK_INSTR_BSS_END 0xFF0C1C94 //BSS_END is 0x17EC74in order to match the disassembly:
; ff0c1c90: (00100d80)
; ff0c1c94: (0017ec74)
Quote from: a1ex on July 06, 2017, 05:24:47 PM
...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?
b *0x1900
assert_log
That might be useful.
Quote from: a1ex on July 06, 2017, 05:24:47 PM
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"
Quote from: a1ex on July 06, 2017, 05:24:47 PM
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:
Quote from: a1ex on May 29, 2017, 11:47:06 AM
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.
...
[ 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?
# 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.
Quote from: 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.
The code to find it doesn't seem too complex:
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?
QuoteThe 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?
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.
Quote from: a1ex on May 29, 2017, 11:47:06 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:
# 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:
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:
^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:
^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!
Quote from: dfort on July 08, 2017, 03:04:49 AM
At least it doesn't slow down to a crawl when it hits the TouchMgr section.
... it no longer boots the GUI ...
Quote from: a1ex on July 08, 2017, 07:32:58 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:
# ./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:
185: 2214.144 [WINSYS] allocated=44140 max_region=412876
Minimal ML:
[ PowerMgr:ff13432c ] (04:16) allocated=0 max_region=1066808
Couldn't find smemShowFix ("..smemShowFix") but this looks interesting:
No ML:
(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:
[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
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))
Yes, much faster.
Am I doing it right?
./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:
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--
cd minimal/5D3.113/
RosieFoComputer:5D3.113 rosiefort$ make
../../platform/Makefile.platform.base:46: *** ROMBASEADDR is not defined. Stop.
What the?
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.
Quote from: a1ex on July 08, 2017, 09:10:41 PM
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.)
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.
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).
What finally worked with the 5D3.113 for me was simply:
./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"
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?)
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:
[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:
Quote from: 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.
I kept it commented out but it looks like it is time to figure it out in order to get to the next step.
Quote from: a1ex on May 29, 2017, 11:47:06 AM
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:
Quote from: a1ex on July 06, 2017, 05:24:47 PM
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)
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
QuoteCONFIG_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).
Quote from: a1ex on July 10, 2017, 09:26:03 AM
...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.
./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:
...
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
[0m[[1;36m init:ff352260 [0m] [1;34mtask_create(PowerMgr, prio=20, stack=400, entry=ff352084, arg=0)
[0m[0m[[1;36m init:0003671c [0m] [1;34mtask_create(DbgMgr, prio=1f, stack=0, entry=36628, arg=46e584)
[0m[0m[[1;36m init:ff0f5f24 [0m] [1;34mtask_create(Startup, prio=19, stack=2800, entry=ff0f5d68, arg=46e880)
[0m[0m[[1;36m init:ff0c33d4 [0m] [1;34mtask_create(TaskMain, prio=1d, stack=0, entry=ff0c28d8, arg=0)
[0m[0m[[1;36m Startup:ff0c375c [0m] [1;34mtask_create(Startup2, prio=11, stack=400, entry=ff0c3604, arg=0)
[0m[0m[[1;36m Startup:0003671c [0m] [1;34mtask_create(PropMgr, prio=14, stack=0, entry=36628, arg=4d7ca8)
[0m[0m[[1;36m Startup:ff0d261c [0m] [1;34mtask_create(DL, prio=f, stack=400, entry=ff0d23fc, arg=0)
[0m[0m[[1;36m Startup:0003671c [0m] [1;34mtask_create(EventMgr, prio=f, stack=0, entry=36628, arg=4e3898)
[0m[0m[[1;36m Startup:0003671c [0m] [1;34mtask_create(FileCache, prio=14, stack=0, entry=36628, arg=603d08)
[0m[0m[[1;36m Startup:0003671c [0m] [1;34mtask_create(RscMgr, prio=12, stack=0, entry=36628, arg=604110)
[0m[0m[[1;36m Startup:ff129dbc [0m] [[1;31mASSERT[0m] this at ./FileMgr/FileMgr.c:2279, ff129dc0Looks like it stopped on "FM_RegisterSpaceNotifyCallback" -- more patching to do?
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:
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.
Quote from: a1ex on July 10, 2017, 09:26:03 AM
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:
[0m[0m[[1;36m Startup:ff129dbc [0m] [[1;31mASSERT[0m] this at ./FileMgr/FileMgr.c:2279, ff129dc0Here 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.
# 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.
Did a little more QEMU'ing with the 550D. Why? Because it seems to be the best supported in QEMU and this:
Quote from: a1ex on July 06, 2017, 05:24:47 PM
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:
./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
// 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
/** 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:
Quote from: g3gg0 on April 06, 2013, 03:25:20 PM
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:
...
[ 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:
Quote from: a1ex on July 06, 2017, 05:36:55 PM
EOS M2, QEMU:
(https://a1ex.magiclantern.fm/bleeding-edge/RscMgr/EOSM2.png)
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!
https://en.wikipedia.org/wiki/Mebibyte
Thanks!
So -- 1 MiB = 220 bytes = 1024 kibibytes = 1048576bytes = 0x100000
~/magic-lantern/platform/EOSM2.103/Makefile.platform.default
# 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.
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.
From your console output (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-EOSM2/13/consoleFull):
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.
Quote from: a1ex on July 13, 2017, 12:26:27 PM
Will explain CONFIG_ALLOCATE_MEMORY_POOL later.
Turned it on:
internals.h
/** This camera loads ML into the AllocateMemory pool **/
#define CONFIG_ALLOCATE_MEMORY_POOLand set up a special case for the EOSM2
boot-hack.c
#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?
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
Quote from: dfort on July 16, 2017, 01:32:15 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?
Quote from: a1ex on July 16, 2017, 10:06:22 AM
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.
Quote from: a1ex on July 06, 2017, 05:24:47 PM
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:
/* 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:
Quote from: g3gg0 on April 06, 2013, 01:43:18 PM
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:
Quote from: a1ex on May 08, 2016, 06:06:13 PM
...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:
Quote from: a1ex on May 08, 2016, 06:06:13 PM
- compile the dm-spy-experiments branch, with CONFIG_DEBUG_INTERCEPT=y in Makefile.user
- put this in don't click me...
(For the EOSM2)
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
/** 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.
Quote from: dfort on July 16, 2017, 08:02:45 PM
Now how did you run that?
As simple as... (http://www.magiclantern.fm/forum/index.php?topic=15895.msg186872#msg186872)
./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
QuoteIs that two ways of looking at the same thing?
Yes.
QuoteBefore and after memory allocation?
No.
QuoteOk--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.
Excellent! Here are some highlights of the output--totaling over 3625 lines!
^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:
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 0It is also interesting to look at an alternate version and follow along in the disassembly:
[ 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:
Quote from: a1ex on July 17, 2017, 12:39:54 AM
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.
You may wonder - why are all these messages doubled?
[ 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.
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):
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.
[ 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:
[ 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
# 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
# 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
# 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
# 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
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_POOLQuote from: a1ex on July 17, 2017, 12:39:54 AM
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:
assert(addr < 0x20000000);[EDIT] This also looks like it can be useful once I learn how to use it:
~/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.
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
// 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:
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
// 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?
QuoteSo 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:
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:
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:
(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:
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:
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!)
(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.
Quote from: a1ex on July 22, 2017, 05:51:57 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.
Quote from: a1ex on July 22, 2017, 05:51:57 PM
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:
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:
0x7ABC + RAM_OFFSETQuote from: a1ex on July 22, 2017, 05:51:57 PM
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.
Quote from: a1ex on July 22, 2017, 05:51:57 PM
Let's check:
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:
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.
./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.
Quote from: a1ex on July 22, 2017, 05:51:57 PM
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.
(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 0x3148d0Ok--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:
end address - start address = free spaceGreat 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:
File size : 0x686A0
So--
0x7be000 - 0x686A0 = 0x755960Plenty of space but is it shared with the Canon firmware? Yes--but there is still enough room for everybody?
Quote from: a1ex on July 22, 2017, 05:51:57 PM
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
#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
#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:
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:
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:
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:
Fixups=171390 entry=17135c free_space=ffffffcc
Quote from: dfort on July 23, 2017, 02:12:25 AM
In order to follow along on my disassembly I'm doing this:
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
#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
Quote from: a1ex on July 23, 2017, 08:36:46 AM
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:
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:
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):
[BOOT] changing sys_mem_end:
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
#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
// 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
/** 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.
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
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)
Quote from: nikfreak on July 22, 2017, 07:23:33 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
Quote from: a1ex on July 24, 2017, 03:03:36 PM
Hopefully this time I'll get the confirmation from 6D
Need to get a compiler up and running again, then I can test.
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.
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)
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.
AllocateMemory pool seems to be working on the EOSM2
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:
[ 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:
Quote from: dfort on July 22, 2017, 12:59:44 AM
Then it gets ugly:
[ 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:
[ 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:
[ 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.
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:
./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:
ff6978dc: e28f2f6e add r2, pc, #440 ; ff697a9c: (2d2d2d2d) *"---- SDEventHandler(ID=%d:Event=%d) ----"
So what is the state of SDEventHandler at this point?
(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)
Quote from: dfort on July 16, 2017, 08:02:45 PM
...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...
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:
/* 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...
Hi @nicfreak
That gave me an idea:
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.
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.
Yep, you nailed it. A couple of my FIO stubs were off.
/** 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:
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:
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.
Quote from: dfort on July 28, 2017, 01:24:10 AM
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.
EOSM2103.FIR - Looks like Canon is taking all they can get out of an 8.3 filename.
Following what was done on the 1100D:
# Definitions for version 103
ML_MODULES_SYM_NAME=m2_$(FW_VERSION).sym
Got past that. Now on to the next issue:
ASSERT00.LOG
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
Found another stub that was off, _engio_write, though this time it didn't resolve the current issue.
/**
* 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:
[ menu_task:0044db24 ] (32:03) read_entire_file:736: failed
to this:
fio.ml.c
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.
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?
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:
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.
. ./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 (msg=msg@entry=0x4a5ad8 "streq(stateobj->type, \"StateObject\")", file=file@entry=0x4a5afd "../../src/state-object.c", line=line@entry=0xfb, func=func@entry=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:
[...] -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:
(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).
This is all very exciting progress so far and keep them rolling along!
Quote from: DeafEyeJedi on July 29, 2017, 11:40:03 PM
This is all very exciting progress so far and keep them rolling along!
+1
Sent from my SM-G930F using Tapatalk
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.
Quote from: a1ex on July 29, 2017, 09:30:22 AM
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:
#0 read_entire_file (filename=filename@entry=0x49f806 "ML/SETTINGS/CURRENT.SET", buf_size=buf_size@entry=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 (filename=filename@entry=0x1f38f8 "ML/SETTINGS/magic.cfg", buf_size=buf_size@entry=0x4ba78c <config_file_size>) at ../../src/fio-ml.c:707
#1 0x0045e2cc in config_parse_file (filename=0x1f38f8 "ML/SETTINGS/magic.cfg", filename@entry=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", filename@entry=0x18e298 "\030\002\230\031", buf_size=0x18e29c, buf_size@entry=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?
[ 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:
[****] 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:
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:877One 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)
Quote from: dfort on July 30, 2017, 07:53:44 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.
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
-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.
There are a few more camera-specific files under the platform directory.
Regarding 700D PlayMain_handler:
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: alex@thinkpad
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)
;)
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.
Quote from: a1ex on July 31, 2017, 11:47:26 AM
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
#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_hOk--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).
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".
Quote from: a1ex on August 01, 2017, 10:19:43 AM
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
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!
QuoteBTW--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
So there's no way to get out of this, come hell or high water!
Quote from: dfort on August 01, 2017, 07:55:50 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
Quote from: glassescreditsroll on August 02, 2017, 09:49:19 PM
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.
Quote from: 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".
Can I phone a friend or ask the audience for the answer?
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:
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.
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).
Getting closer--but not quite yet.
End of QEMU run with dm-spy-experiments branch merged with EOSM2.103_wip:
[ 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:
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 rosiefort@RosieFoComputer.
Free Memory : 344K + 1158K
Before getting back to debugging, looks like I found a couple of missing stubs for the EOSM:
NSTUB(0xff0d7830, GUI_ChangeMode)
...
NSTUB(0xff1c4670, gui_massive_event_loop)
or were these removed on purpose?
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:
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:
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.
In this case, the contents of boot-hack.c are identical on dm-spy-experiments-EOSM2.103 (de9f09df06e7) and EOSM2.103_wip (495f8c25235c):
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:
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:
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:
# only recompiles and installs autoexec.bin, without modules
cd platform/EOSM2.103; make installq ML_MODULES_DYNAMIC=
# requires a tiny change from latest unified (g3gg0 found out yesterday)
make -j4
Quote from: a1ex on August 05, 2017, 09:38:36 AM
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!
Quote from: a1ex on August 05, 2017, 09:38:36 AM
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.
Quote from: dfort on August 01, 2017, 08:29:22 AM
I can't get to the Magic Lantern menu to check it out.
Quote from: 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".
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:
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)
I might be bumping up against imperfect emulation. Are we ready to run some tests on the real hardware?
Quote from: 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).
Do you already have an M2 to test on? How do you know when it's time?
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.
Okay! Well, I definitely hope it's the former! :)
@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?
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).
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.
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.
@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.
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?
Quote from: 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.
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.
Quote from: bookemdano on October 02, 2017, 06:42:08 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.
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.
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!
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?
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.
Quote from: 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.
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.
What a1ex was talking about was to save the firmware dump in a setting other than LiveView. His exact words:
Quote from: a1ex on October 02, 2017, 10:13:08 AM
...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...
Quote from: a1ex on October 02, 2017, 10:13:08 AM
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:
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!
Thank you for your work on this. Here's hoping there will be a way to get through this issue!
Quote from: dfort on October 21, 2017, 10:29:11 PM
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:
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.
Sticky topics in this section (http://www.magiclantern.fm/forum/index.php?board=25.0) will get you started.
Just registered to say there's more people cheering for you guys! The m2 is a fantastic camera and deserves a little magic :)
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.
:)
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
-#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)
Thats a great step! congrats :)
Quote from: 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.
You've beev a good boy it seems :) Congrats!
Got a basic in-camera startup log (https://pastebin.com/nzYgVS5y). Still looking for that magic Trash button code.
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
Terrifc update dfort! Happy new years to you!
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.
@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--
./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?
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
Hello. First post but long time reader. Just here to vouch my support for the M2. Mostly interested in time lapse.
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)
Quote from: a1ex on January 16, 2018, 08:58:03 AM
(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?
Quote from: a1ex on January 16, 2018, 08:58:03 AM
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:
---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.
Quote from: a1ex on January 16, 2018, 08:58:03 AM
..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?
QuoteYeah, 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.
QuoteOne 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.
QuoteA tiny hint on how to print out the button codes?
Debug -> Show GUI events.
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
Quote from: a1ex on January 16, 2018, 08:58:03 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.
Quote from: a1ex on January 12, 2018, 07:35:46 PM
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.
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))
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.
/** 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:
Quote from: a1ex on January 16, 2018, 08:58:03 AM
...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.
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.
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:
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():
// 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.
Quote from: 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.
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:
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.
It's Alive!
(https://farm5.staticflickr.com/4605/39814203202_0958e3455b_z.jpg) (https://flic.kr/p/23Efcvm)
Quote from: a1ex on January 22, 2018, 06:32:39 PM
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!
Congratulations to this breakthrough - and happy birthday dfort!!
Sent from my SM-G930F using Tapatalk
@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:
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.
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.
dfort, what an achevement, bravo, and happy birthday as well. And thanks to a1ex who makes all of this possible.
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.
@dfort: Congratulations! And Happy Birthday! :D
Congratulations on this huge milestone! I'm very impressed! It's all hidden in mystery for me. :)
Quote from: dfort on January 23, 2018, 06:42:06 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)
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.
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?
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)
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
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?
{ 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
// 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:
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
// 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
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.
Quote from: 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.
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)
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)
Quote from: a1ex on January 27, 2018, 07:31:22 PM
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:
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:
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:
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.
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.
// 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:
Quoteadtg_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:
#include <beep.h>However, I'm still getting compile errors even after turning on these options:
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:
#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.
Quote from: dfort on January 28, 2018, 07:50:47 AM
Sorry EOSM2 enthusiasts, this needs some more work before releasing a test build.
Hey, we're just thrilled to see the progress. Very cool!
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:
// 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
[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:
[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:
[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.
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:
...
[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
...
In QEMU, the Free Memory dialog crashes at srm_malloc_suite - wrong stub?
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
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" ?
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 )
Quote from: a1ex on January 30, 2018, 07:50:04 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)
Quote from: a1ex on January 30, 2018, 07:50:04 PM
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?
Quote from: a1ex on January 30, 2018, 07:50:04 PM
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?
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.
Late to the party bus but just wanted to chime in with congrats on both birthday and reaching this milestone!
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.
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:
Quote from: a1ex on January 23, 2018, 02:08:34 PM
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:
Quote from: a1ex on January 23, 2018, 02:08:34 PM
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.
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.
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:
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)
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.
// 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?
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.
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:
#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.
#define CURRENT_GUI_MODE (*(int*)0x928BC) // in SetGUIRequestMode (0x92860+0x5C)
Here is the first complete lua api test:
===============================================================================
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!
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
#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:
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.
Registered to voice support! Eagerly awaiting release! :)
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?
There is an option to disable logging in LiveView (Advanced menu); IIRC it was written with the EOS M in mind.
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)
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.
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
#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.
Ok, did this:
#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:
...
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:
...
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?
Did some more debugging. Added this line to see what is going on.
/* 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:
raw update from livev_hiprio_task
LV RAW size too small
width x height = -16 x 727
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.
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);
One step at a time:
Quote from: a1ex on February 20, 2018, 08:10:53 PM
Can you print the raw values of top_left and bot_right?
EOSM2.103
top_left = 4
bot_right = 0
width x height = -16 x 727This can't be right. Checking the original:
EOSM.202
top_left = 65552
bot_right = 77988308
width x height = 1808 x 1189Interesting, that's the mv1080 buffer size for the EOSM.
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:
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.
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).
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
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
static ASM_VAR uint32_t protected_region = REGION(0xC0F06000, 0x1000);
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.
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)
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:
if (fmt[0] != 'e') return;
You could also write small test sequences, such as:
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
}
Followed your instructions and also added:
debug.c
#include "dm-spy.h"
but I'm getting:
[ 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.
CONFIG_DEBUG_INTERCEPT=y and CONFIG_MMIO_TRACE=y in Makefile.user? Also, make clean?
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
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.
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
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.
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:
*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:
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:
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.
Figures I'd pick the problem camera. Let me know what tests to run.
@nikfreak -- Your tip worked. No more dirty pixels!
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:
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:
FF2C6C40 02 00 80 E1 ORR R0, R0, R2
should be changed to:
FF2C6C40 02 00 80 E0 ADD R0, R0, R2
With the patch manager (patchmgr) merged:
patch_instruction(0xFF2C6C40, 0xE1800002, 0xE0800002, "engio");
The other instructions should be changed in the same way, and tested in QEMU first.
Merged patchmgr and created this block of code:
#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:
../../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?
Quote from: a1ex on January 30, 2018, 09:25:12 PM
...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.
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).
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.
Found a place to put the patch code:
boot-hack.c
#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:
[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
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:
[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?
===============================================================================
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...
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:
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:
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.
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
[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
[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
===============================================================================
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
===============================================================================
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)
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!
I'm ready to fire up my EOS M2 as well, just having peaking would be great! ;)
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:
# 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:
hg pull
hg update
Got it?
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)
Following for update. Hopefully something soon?
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.
Unfortunately I don't know enough about coding but I'd be happy to test builds compiled by others.
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!
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.
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
Quote from: 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.
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.
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.
Quote from: chrissul13 on August 06, 2018, 05:41:07 AM
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/).
Great! Good to know another piece of the puzzle is sorted out!
Guys do not stop you great work! :)
tried the new update, can't get much to work but I'm glad there is progress!
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.)
Hi guys. What is the current status of the port? Does it contain any more or less stable functions? I mostly interested in timelapse..
Quote from: Skozyashiy on September 19, 2018, 09:05:31 PM
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
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.
@critix did you receive dfort's M2? I'm in for testing too!
Thank you for your efforts guys! :)
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)
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.
Is raw recording working as well?
No, raw recording is not work...
Quote from: Danne on December 08, 2018, 04:51:22 PM
Is raw recording working as well?
Well, mlv_lite creates an .MLV file but you get the the following assert
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 root@cristi.
Free Memory : 383K + 1846K
I did not look into the file as such.
Quote from: 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!
You should test the latest build Critix published today. Focus peaking seems stable to me.
wow good to see renewed progress, will test this build soon :D
Looks like this is where the assert message is coming from -- mlv_lite.c line 2697
/* 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.
Quote from: dfort on December 09, 2018, 07:16:39 AM
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.
ML settings are stored in ML/Settings directory. Zip, upload somewhere and link it.
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! :)
Quote from: uizin on December 09, 2018, 10:36:11 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.
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...
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.
Quote from: 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...
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
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:
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...
Working 10bit video!
https://bitbucket.org/Dannephoto/magic-lantern/downloads/M12-1737.MLV
I erased this in mlv_lite.c:
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)
Yay!
mlv_dump -v M12-1737.MLV
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)
Quote from: Danne on December 12, 2018, 04:36:32 PM
Question. Are recording in mv1080p already, reason for freezes? Sure looks like it.
No, this is definitely mv720.
Got this when taking a cr2 still image in movie mode:
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 + 1867KWhen shooting in 14bit lossless:
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
Quote from: JohanJ on December 12, 2018, 02:21:13 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.
What might help track down these issues is using one of the logging branches:
EOSM2.103_dm-spy-experiments 18168:e8396696980f
EOSM2.103_io_trace 18167:d5a0e069c803
EOSM2.103_io_trace_full 18166:4a41ee21b185
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:
NotifyBox(5000, "shamem_read(0xC0F07150) 0x%x", shamem_read(0xC0F07150));
In crop_rec.c:
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:
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.
Quote from: Danne on December 13, 2018, 10:11:10 AM
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
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,
};
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?
#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:
#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:
/* 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:
#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.
The values seem ok.
#ifdef CONFIG_EOSM2
#define DEFAULT_RAW_BUFFER MEM(0x91CF0 + 0x78)
About these do not know what to say :
#define DEFAULT_RAW_BUFFER_SIZE (0x48C00000 - 0x48798100)
#endif
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
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
{
/* 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...
Quote from: critix on December 14, 2018, 01:35:35 PM
About these do not know what to say :
#define DEFAULT_RAW_BUFFER_SIZE (0x48C00000 - 0x48798100)
I'd say we found these values:
Quote from: a1ex on February 01, 2018, 12:51:29 AM
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.
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).
What Danne is finding seems to point to a problem with the YUV addresses:
platform/EOSM2.103/consts.h
// 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 0x46000080We're using some placeholder values here but maybe they have already been found and I just don't know how to use this information?
Quote from: a1ex on July 06, 2017, 05:36:55 PM
EOS M2, QEMU:
...
1160: 48852.480 [RSC] YUV 0x4AEEA000 0x0222C000 35831808
1161: 48852.480 [RSC] YUV_OUT 0x42000000 0x0222C000 35831808
@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.
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
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! :)
@uizin - Excellent reporting!
Quote from: uizin on December 16, 2018, 03:15:45 PM
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).
Quote from: uizin on December 16, 2018, 03:15:45 PM
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.
Quote from: uizin on December 16, 2018, 03:15:45 PM
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
#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
#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.
Quote from: dfort on December 16, 2018, 05:11:55 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.
Quote from: uizin on December 16, 2018, 08:20:49 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.
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.
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.
Quote from: dpjpandone on August 12, 2015, 07:26:05 AM
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.
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 ...
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:
Quote from: 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.
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)?
Quote from: a1ex on February 01, 2018, 12:51:29 AM
EOSM2: 48798100 - 48CC40C4
Or is this unrelated?
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.
@dfort do you need some specific tests on this build?
Never mind -- got a report that the new build I posted only does the LED blink thing so I took it down.
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).
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.
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.
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.
@gukuangshi - Welcome to the forum!
Quote from: gukuangshi on December 21, 2018, 04:05:53 AM
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.
Quote from: gukuangshi on December 21, 2018, 09:34:45 AM
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.
Quote from: gukuangshi on December 21, 2018, 04:05:53 AM
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.
Quote from: gukuangshi on December 21, 2018, 04:05:53 AM
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.
Quote from: dfort on December 21, 2018, 08:51:57 AM
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:
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
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:
else if (is_camera("EOSM2", "1.0.3")) // WIP found movie mode but photo mode is taken from EOSM
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/).
Some more test results based on build
magiclantern-Nightly.2018Dec21.EOSM2103I
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.
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!
Quote from: 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/).
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:
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.
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
Hum -- seems that Walter's post got flagged as a "Hall of Shame" post. Here it is:
Quote from: Walter Schulz on December 22, 2018, 07:37:20 PM
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.
Quote from: dfort on December 22, 2018, 06:04:53 PM
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:
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
Quote from: dfort on December 22, 2018, 10:10:41 PM
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:
Evf:46284:416d93f0 v=2051(0x803) nrzi_dec=4093(0xffd)
At least I can find these values in Critix post too.
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:
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;
}
Quote from: Danne on December 23, 2018, 12:41:53 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:
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
Ok, coming from dfort branch:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/dual_iso.mo
No more linking error but ISOless PH err(8)
Now with error code 8 instead of err(15) both in photo and video mode.
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?
int err = isoless_enable(PHOTO_CMOS_ISO_START, PHOTO_CMOS_ISO_SIZE, PHOTO_CMOS_ISO_COUNT, backup_ph);
Made another observation: the value for CMOS[0] is alway the same
416d93f0 when
- Dual_iso.mo was not loaded
- Dual_iso.mo was loaded but not activated
- Dual_iso.mo was loaded and activated
Does that make sense?
@Danne -- you need to fix this formatting error:
PHOTO_CMOS_ISO_START = 0x416d93f0
; // CMOS register 0000 - for photo mode, ISO 100
Should be:
PHOTO_CMOS_ISO_START = 0x416d93f0; // CMOS register 0000 - for photo mode, ISO 100
Quote from: JohanJ on December 23, 2018, 03:45:39 PM
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(?).
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.
Hi!
@dfort, I have memory error when i try to use adtg_gui with iso-research.2018Dec22.EOSM2103.zip:
shoot_malloc(1.0MB|TMP|DMA) FAILED AT adtg_gui.c:1004, log_iso_regs.
Quote from: dfort on December 23, 2018, 07:08:25 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.
Quote from: dfort on December 23, 2018, 07:08:25 PM
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)
Quote from: critix on December 23, 2018, 07:39:39 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
Quote from: dfort on December 23, 2018, 09:39:44 PM
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
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
Evf:46284:416d93f0 v=2051(0x803) nrzi_dec=4093(0xffd)
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:
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/).
Quote from: dfort on December 21, 2018, 05:53:18 PM
@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.
@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?
Quote from: dfort on December 24, 2018, 02:34:24 AM
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:
- The test results in movie mode posted here (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209640#msg209640) where taken in Manual video mode to be able to set ISO 100. Exposure constalation is static and the identified addres was 416d93f0.
- In photo mode 2 my first tests in post #362 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209617#msg209617) were taken in M exposure mode too, shutter speed was 1/30 sec and the result was 416d93f0, too. Today I think that was a kind of coincidence (as the stills were taken under same exposure conditions as in movie mode).
- The photo mode result posted late yesterday in #374 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209647#msg209647) were produced in Av mode. I got two different results and the first was not reproducable so I took the second one.
- Today I repeated these tests in Av mode with the latest build and got different values again - but reproducable: 416d949a, 416d9478, 416d93f0 and others. Theses values simply changed depending on the light in the scene and the shutter speed automatically changes in Av (I did not get that yesterday night, it was simply dark)
- Switched to M exposuer in Photo mode 2 and chose 2 sec shutter speed. Result is 416d9478 whereas at 1/30 it is 416d93f0
Meaning the CMOS[0] register changes values in depencence of the shutter speed. So, are we looking at the right register?
Quote from: JohanJ on December 24, 2018, 03:32:06 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.
Quote from: JohanJ on December 24, 2018, 01:24:09 AM
Photo mode 2--> Value after taking a shot -> since then kind of persistent
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
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.
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!
Exported a log after shooting in Video mode, and filtered for ShootCapture task, may this be interesting?
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
What we're searching for is in photo mode, non LiveView.
Here is another log filtered for ShootCapture:
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
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
Quote from: JohanJ on December 25, 2018, 01:26:21 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
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)
Quote from: gukuangshi on December 24, 2018, 03:01:52 AM
In my camera, the temperature rises from 16-36 degrees after using 20 minutes.
That seems about normal.
Quote from: gukuangshi on December 24, 2018, 03:01:52 AM
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.
Quote from: dfort on December 25, 2018, 05:17:07 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
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.
@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...
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)
Quote from: dfort on December 25, 2018, 05:17:07 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
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
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.
Quote from: uizin on December 25, 2018, 11:26:10 AM
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)?
Quote from: JohanJ on December 25, 2018, 12:50:22 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).
Quote from: uizin on December 25, 2018, 11:26:10 AM
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
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.
Quote from: JohanJ on December 25, 2018, 04:27:08 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
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:
Quote from: theBilalFakhouri on February 11, 2018, 12:53:02 PM
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:
Quote from: a1ex on April 23, 2018, 05:18:12 PM
... 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)
Quote from: dfort on December 25, 2018, 05:39:17 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)
Quote from: a1ex on December 24, 2018, 04:00:03 PM
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.
Quote from: JohanJ on December 26, 2018, 12:10:47 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
/** 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
#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
/**
* 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
#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
#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
// 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?
#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).
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.
Quote from: dfort on December 26, 2018, 04:43:41 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).
Quote from: JohanJ on December 25, 2018, 01:26:21 AM
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.
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/)
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).
Got it -- thanks again.
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.
Probably because we still need to figure this out:
src/fps-engine.c
#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))
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.
Quote from: a1ex on December 27, 2018, 12:05:14 PM
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:
#ifdef CONFIG_LIVEVIEW
PROP_HANDLER( PROP_LV_ACTION )
{
lv = !buf[0];
NotifyBox(5000, "lv 0x%x", lv);
}
#endifGives 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.
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:
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
#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:
/* 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.
Shutter blanking might change from cam to cam on this model:
https://www.magiclantern.fm/forum/index.php?topic=19300.msg208546#msg208546
Well if shutter blanking changes on the 100D and 700D, it probably also applies to the EOSM2. They are all about the same vintage.
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?
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.
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?
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.
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?
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:
PHOTO_CMOS_ISO_START = 0x4048124C;
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]
Quote from: Danne on December 28, 2018, 04:55:54 PM
On a regular EOSM it looks like this. Assume this is what we´re after but on the eosm2?
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.
Tried trigger the shootCapture event by logging regs while intervalometer would shoot a cr2 but with no success :P
This works on the EOSM:
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.
Never mind. My EOSM2 arrived just now so I tried it and these were the only ShootCapture events it logged:
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)"
Err 2 instead of err 8. Always something 8)
Quote from: a1ex on December 27, 2018, 12:05:14 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
Did you restart camera and went into the unique setting without turning adtg_gui on? After selection turn on adtg_gui.
Quote from: 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.
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)
@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)
{
.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.
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.
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.
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.
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:
[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.
Quote from: 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.
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.
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.
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)
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.
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/).
Quote from: a1ex on December 16, 2017, 01:36:42 AM
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
===============================================================================
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.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~155.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~1.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE4D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~2.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~168.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~171.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~174.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~177.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~181.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~186.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~3.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~2.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~4.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~5.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~204.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/REVERS~1.UPD
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~211.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/TMPSPO~1.LOC
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~217.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~220.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~224.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~227.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~231.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~234.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~238.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE0D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~245.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~248.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~251.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~254.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~257.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~3.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE5D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~267.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~270.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~273.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~276.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~279.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~282.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~285.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~288.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~292.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~295.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~299.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~302.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~305.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~308.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~311.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~314.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~4.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE1D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~324.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~327.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~330.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~333.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~336.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~339.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~343.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~346.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~349.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~352.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~355.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~358.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~5.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE3D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~368.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~371.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~374.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~377.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~417.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~420.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~424.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~427.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~430.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~433.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~436.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~439.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~442.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE2D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~449.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~452.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~455.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~458.IND
- B:/SPOTLI~1/STORE-V1/
- B:/SPOTLI~1/STORE-V1/VOLUME~1.PLI
- B:/SPOTLI~1/VOLUME~1.PLI
- B:/ML/
- B:/ML/MODULES/
- B:/ML/MODULES/M2_103.SYM
- B:/ML/MODULES/ADTG_GUI.MO
- B:/ML/MODULES/ADV_INT.MO
- B:/ML/MODULES/ARKANOID.MO
- B:/ML/MODULES/AUTOEXPO.MO
- B:/ML/MODULES/BENCH.MO
- B:/ML/MODULES/BOLT_REC.MO
- B:/ML/MODULES/CROP_REC.MO
- B:/ML/MODULES/DUAL_ISO.MO
- B:/ML/MODULES/EDMAC.MO
- B:/ML/MODULES/FILE_MAN.MO
- B:/ML/MODULES/FILEPREF.MO
- B:/ML/MODULES/IME_BASE.MO
- B:/ML/MODULES/IME_NULL.MO
- B:/ML/MODULES/IME_ROT.MO
- B:/ML/MODULES/IME_STD.MO
- B:/ML/MODULES/IMG_NAME.MO
- B:/ML/MODULES/IO_CRYPT.MO
- B:/ML/MODULES/ISO_REGS.MO
- B:/ML/MODULES/LUA.MO
- B:/ML/MODULES/MEM_SPY.MO
- B:/ML/MODULES/MLV_LITE.MO
- B:/ML/MODULES/MLV_PLAY.MO
- B:/ML/MODULES/MLV_REC.MO
- B:/ML/MODULES/MLV_SND.MO
- B:/ML/MODULES/MPU_DUMP.MO
- B:/ML/MODULES/PIC_VIEW.MO
- B:/ML/MODULES/PLOT.MO
- B:/ML/MODULES/RAW_DIAG.MO
- B:/ML/MODULES/RAW_TWK.MO
- B:/ML/MODULES/SD_UHS.MO
- B:/ML/MODULES/SELFTEST.MO
- B:/ML/MODULES/SF_DUMP.MO
- B:/ML/MODULES/SILENT.MO
- B:/ML/MODULES/TRACE.MO
- B:/ML/MODULES/LOADING.LCK
- B:/ML/FONTS/
- B:/ML/FONTS/ARGHLF22.RBF
- B:/ML/FONTS/ARGNOR23.RBF
- B:/ML/FONTS/ARGNOR28.RBF
- B:/ML/FONTS/ARGNOR32.RBF
- B:/ML/FONTS/TERM12.RBF
- B:/ML/FONTS/TERM20.RBF
- B:/ML/DATA/
- B:/ML/DATA/APSC8P.LUT
- B:/ML/DATA/APSC8R.LUT
- B:/ML/DATA/FF8P.LUT
- B:/ML/DATA/FF8R.LUT
- B:/ML/CROPMKS/
- B:/ML/CROPMKS/CINESCO2.BMP
- B:/ML/CROPMKS/CRSSMTR2.BMP
- B:/ML/CROPMKS/PASSPORT.BMP
- B:/ML/CROPMKS/PHIPHOTO.BMP
- B:/ML/CROPMKS/PHIVIDEO.BMP
- B:/ML/SCRIPTS/
- B:/ML/SCRIPTS/LIB/
- B:/ML/SCRIPTS/LIB/LOGGER.LUA
- B:/ML/SCRIPTS/LIB/KEYS.LUA
- B:/ML/SCRIPTS/LIB/CONFIG.LUA
- B:/ML/SCRIPTS/LIB/STRICT.LUA
- B:/ML/SCRIPTS/DARKFR~1.LUA
- B:/ML/SCRIPTS/25K10B~1.LUA
- B:/ML/SCRIPTS/1080P1~1.LUA
- B:/ML/SCRIPTS/REBOOT.LUA
- B:/ML/SCRIPTS/SDOVER~1.LUA
- B:/ML/SCRIPTS/ADTGHE~1.LUA
- B:/ML/SCRIPTS/SCRNSHOT.LUA
- B:/ML/SCRIPTS/25K10B~2.LUA
- B:/ML/SCRIPTS/MENUTEST.LUA
- B:/ML/SCRIPTS/1080P1~2.LUA
- B:/ML/SCRIPTS/COPY2M.LUA
- B:/ML/SCRIPTS/UNLOAD.LUA
- B:/ML/SCRIPTS/API_TEST.LUA
- B:/ML/DOC/
- B:/ML/LOGS/
- B:/ML/LOGS/ROM1.BIN
- B:/ML/LOGS/ROM0.BIN
- B:/ML/LOGS/STUBTEST.LOG
- B:/ML/LOGS/LUATEST.LOG
- B:/ML/SETTINGS/
- B:/ML/SETTINGS/LUA.EN
- B:/ML/SETTINGS/MAGIC.CFG
- B:/ML/SETTINGS/MENUS.CFG
- B:/TRASHE~1/
- B:/TRASHE~1/501/
- B:/TRASHE~1/_50~1
- B:/DCIM/
- 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:/DCIM/EOSMISC/
- B:/DCIM/EOSMISC/M2100.CTG
- B:/MISC/
- B:/FSEVEN~1/
- B:/FSEVEN~1/FSEVEN~1
- B:/FSEVEN~1/000000~1
- B:/FSEVEN~1/000000~2
- B:/ML-SETUP.FIR
- B:/AUTOEXEC.BIN
- B:/BENCH0.PPM
File I/O tests completed.
Testing Canon GUI functions...
Enter MENU mode...
Enter MENU mode...
Enter PLAY mode...
Exit PLAY mode...
ML/SCRIPTS/API_TEST.LUA:309: assertion failed!
stack traceback:
[C]: in function 'globals.assert'
ML/SCRIPTS/API_TEST.LUA:309: in function 'globals.test_camera_gui'
ML/SCRIPTS/API_TEST.LUA:1498: 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 chunk
===============================================================================
ML/SCRIPTS/API_TEST.LUA - 2019-1-1 23:22: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 = 213
gui = table:
menu = false
play = false
play_photo = false
play_movie = false
qr = false
idle = false
shoot = function: 0xb0c564
burst = function: 0xb0c818
reboot = function: 0xb0c538
bulb = function: 0xb0c798
wait = function: 0xb0b490
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: 0xb09eb8
show = function: 0xb09e24
hide = function: 0xb09e14
clear = function: 0xb09e04
lv = table:
enabled = true
paused = false
running = true
zoom = 1
overlays = false
resume = function: 0xb0d038
stop = function: 0xb0c9b0
info = function: 0xb0cd44
wait = function: 0xb0d408
start = function: 0xb0c9a0
pause = function: 0xb0d048
lens = table:
name = "EF-S55-250mm f/4-5.6 IS STM"
focal_length = 55
focus_distance = 2000
hyperfocal = 28540
dof_near = 1882
dof_far = 2134
af = true
af_mode = 0
autofocus = function: 0xb0deec
focus = function: 0xb0e0b4
display = table:
idle = nil
height = 480
width = 720
load = function: 0xb0ec24
circle = function: 0xb0f298
pixel = function: 0xb0fb94
draw = function: 0xb0eadc
rect = function: 0xb0f568
off = function: 0xb0e930
print = function: 0xb0fd60
notify_box = function: 0xb0e9f4
screenshot = function: 0xb0e85c
on = function: 0xb0e940
line = function: 0xb0f8cc
clear = function: 0xb0e84c
key = table:
last = 10
wait = function: 0xb10270
press = function: 0xb10538
menu = table:
visible = false
open = function: 0xb108b0
close = function: 0xb10898
get = function: 0xb11d04
block = function: 0xb10aa0
new = function: 0xb12960
select = function: 0xb11a50
set = function: 0xb11b24
movie = table:
recording = false
start = function: 0xb0e548
stop = function: 0xb0e4b4
dryos = table:
clock = 144
ms_clock = 144112
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 = 1394
folder_number = 100
free_space = 13110
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 = 1394
folder_number = 100
free_space = 13110
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 = 1394
folder_number = 100
free_space = 13110
image_path = function: 0xb13e60
type = "SD"
path = "B:/"
_card_ptr = userdata
date = table:
min = 22
month = 1
sec = 34
day = 1
isdst = false
yday = 1
year = 2019
wday = 3
hour = 23
call = function: 0xb1320c
rename = function: 0xb13410
remove = function: 0xb134e4
directory = function: 0xb13550
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: 13110 MiB
- next image: B:/DCIM/100CANON/IMG_1395.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:/DCIM/100CANON/IMG_1394.CR2
- 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.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~155.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~1.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE4D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~2.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~168.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~171.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~174.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~177.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~181.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~186.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~3.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~2.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~4.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~5.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~204.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/REVERS~1.UPD
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~211.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/TMPSPO~1.LOC
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~217.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~220.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~224.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~227.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~231.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~234.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~238.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE0D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~245.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~248.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~251.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~254.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~257.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~3.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE5D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~267.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~270.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~273.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~276.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~279.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~282.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~285.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~288.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~292.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~295.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~299.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~302.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~305.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~308.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~311.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~314.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~4.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE1D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~324.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~327.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~330.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~333.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~336.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~339.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~343.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~346.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~349.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~352.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~355.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~358.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~~~5.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE3D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~368.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~371.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~374.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~377.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~417.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~420.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~424.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~427.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~430.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~433.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~436.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~439.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~442.DIR
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE2D~1.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~449.SHA
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~452.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~455.IND
- B:/SPOTLI~1/STORE-V2/DEEEAF~1/LIVE~458.IND
- B:/SPOTLI~1/STORE-V1/
- B:/SPOTLI~1/STORE-V1/VOLUME~1.PLI
- B:/SPOTLI~1/VOLUME~1.PLI
- B:/ML/
- B:/ML/MODULES/
- B:/ML/MODULES/M2_103.SYM
- B:/ML/MODULES/ADTG_GUI.MO
- B:/ML/MODULES/ADV_INT.MO
- B:/ML/MODULES/ARKANOID.MO
- B:/ML/MODULES/AUTOEXPO.MO
- B:/ML/MODULES/BENCH.MO
- B:/ML/MODULES/BOLT_REC.MO
- B:/ML/MODULES/CROP_REC.MO
- B:/ML/MODULES/DUAL_ISO.MO
- B:/ML/MODULES/EDMAC.MO
- B:/ML/MODULES/FILE_MAN.MO
- B:/ML/MODULES/FILEPREF.MO
- B:/ML/MODULES/IME_BASE.MO
- B:/ML/MODULES/IME_NULL.MO
- B:/ML/MODULES/IME_ROT.MO
- B:/ML/MODULES/IME_STD.MO
- B:/ML/MODULES/IMG_NAME.MO
- B:/ML/MODULES/IO_CRYPT.MO
- B:/ML/MODULES/ISO_REGS.MO
- B:/ML/MODULES/LUA.MO
- B:/ML/MODULES/MEM_SPY.MO
- B:/ML/MODULES/MLV_LITE.MO
- B:/ML/MODULES/MLV_PLAY.MO
- B:/ML/MODULES/MLV_REC.MO
- B:/ML/MODULES/MLV_SND.MO
- B:/ML/MODULES/MPU_DUMP.MO
- B:/ML/MODULES/PIC_VIEW.MO
- B:/ML/MODULES/PLOT.MO
- B:/ML/MODULES/RAW_DIAG.MO
- B:/ML/MODULES/RAW_TWK.MO
- B:/ML/MODULES/SD_UHS.MO
- B:/ML/MODULES/SELFTEST.MO
- B:/ML/MODULES/SF_DUMP.MO
- B:/ML/MODULES/SILENT.MO
- B:/ML/MODULES/TRACE.MO
- B:/ML/MODULES/LOADING.LCK
- B:/ML/FONTS/
- B:/ML/FONTS/ARGHLF22.RBF
- B:/ML/FONTS/ARGNOR23.RBF
- B:/ML/FONTS/ARGNOR28.RBF
- B:/ML/FONTS/ARGNOR32.RBF
- B:/ML/FONTS/TERM12.RBF
- B:/ML/FONTS/TERM20.RBF
- B:/ML/DATA/
- B:/ML/DATA/APSC8P.LUT
- B:/ML/DATA/APSC8R.LUT
- B:/ML/DATA/FF8P.LUT
- B:/ML/DATA/FF8R.LUT
- B:/ML/CROPMKS/
- B:/ML/CROPMKS/CINESCO2.BMP
- B:/ML/CROPMKS/CRSSMTR2.BMP
- B:/ML/CROPMKS/PASSPORT.BMP
- B:/ML/CROPMKS/PHIPHOTO.BMP
- B:/ML/CROPMKS/PHIVIDEO.BMP
- B:/ML/SCRIPTS/
- B:/ML/SCRIPTS/LIB/
- B:/ML/SCRIPTS/LIB/LOGGER.LUA
- B:/ML/SCRIPTS/LIB/KEYS.LUA
- B:/ML/SCRIPTS/LIB/CONFIG.LUA
- B:/ML/SCRIPTS/LIB/STRICT.LUA
- B:/ML/SCRIPTS/DARKFR~1.LUA
- B:/ML/SCRIPTS/25K10B~1.LUA
- B:/ML/SCRIPTS/1080P1~1.LUA
- B:/ML/SCRIPTS/REBOOT.LUA
- B:/ML/SCRIPTS/SDOVER~1.LUA
- B:/ML/SCRIPTS/ADTGHE~1.LUA
- B:/ML/SCRIPTS/SCRNSHOT.LUA
- B:/ML/SCRIPTS/25K10B~2.LUA
- B:/ML/SCRIPTS/MENUTEST.LUA
- B:/ML/SCRIPTS/1080P1~2.LUA
- B:/ML/SCRIPTS/COPY2M.LUA
- B:/ML/SCRIPTS/UNLOAD.LUA
- B:/ML/SCRIPTS/API_TEST.LUA
- B:/ML/DOC/
- B:/ML/LOGS/
- B:/ML/LOGS/ROM1.BIN
- B:/ML/LOGS/ROM0.BIN
- B:/ML/LOGS/STUBTEST.LOG
- B:/ML/LOGS/LUATEST.LOG
- B:/ML/SETTINGS/
- B:/ML/SETTINGS/LUA.EN
- B:/ML/SETTINGS/MAGIC.CFG
- B:/ML/SETTINGS/MENUS.CFG
- B:/TRASHE~1/
- B:/TRASHE~1/501/
- B:/TRASHE~1/_50~1
- B:/DCIM/
- 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:/DCIM/100CANON/IMG_1394.CR2
- B:/DCIM/EOSMISC/
- B:/DCIM/EOSMISC/M2100.CTG
- B:/MISC/
- B:/FSEVEN~1/
- B:/FSEVEN~1/FSEVEN~1
- B:/FSEVEN~1/000000~1
- B:/FSEVEN~1/000000~2
- B:/ML-SETUP.FIR
- B:/AUTOEXEC.BIN
- B:/BENCH0.PPM
- B:/VRAM0.PPM
- B:/VRAM1.PPM
- B:/VRAM2.PPM
- B:/VRAM3.PPM
- B:/VRAM4.PPM
- B:/VRAM5.PPM
- B:/VRAM6.PPM
- B:/VRAM7.PPM
- B:/VRAM8.PPM
- B:/VRAM9.PPM
- B:/VRAM10.PPM
- B:/VRAM11.PPM
- B:/VRAM12.PPM
- B:/VRAM13.PPM
- B:/VRAM14.PPM
- B:/VRAM15.PPM
File I/O tests completed.
Testing Canon GUI functions...
Enter MENU mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Exit PLAY mode...
ML/SCRIPTS/API_TEST.LUA:309: assertion failed!
stack traceback:
[C]: in function 'globals.assert'
ML/SCRIPTS/API_TEST.LUA:309: in function 'globals.test_camera_gui'
ML/SCRIPTS/API_TEST.LUA:1498: 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 chunkselftest.mo -> stubs tests
STUBTEST.LOG
[Pass] is_play_mode() => 0x1
[INFO] Camera model: Canon EOS M2 1.0.3 (0x80000355 EOSM2)
[Pass] is_camera("DIGIC", "*") => 0x1
[Pass] is_camera(__camera_model_short, firmware_version) => 0x1
[Pass] src = fio_malloc(size) => 0x4de3609c
[Pass] dst = fio_malloc(size) => 0x4e63a0a8
[Pass] memcmp(dst, src, 4097) => 0xffffffea
[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) => 0xffffffc7
[Pass] edmac_memcpy(dst, src, size) => 0x4e63a0a8
[Pass] memcmp(dst, src, size) => 0x0
[Pass] memcmp(dst, src, size) => 0xffffffea
[Pass] edmac_memcpy_start(dst, src, size) => 0x4e63a0a8
dt => 0x293c
[Pass] copied => 0x400958
[Pass] copied => 0x400958
[Pass] copied => 0x400958
[Pass] memcmp(dst, src, copied) => 0x0
[Pass] memcmp(dst, src, copied + 16) => 0x2
edmac_memcpy_finish()
free(src)
free(dst)
Cache test A (EDMAC on BMP buffer)...
[Pass] bmp = bmp_load("ML/CROPMKS/CINESCO2.BMP", 1) => 0xa9e728
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x81e
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x0
Cache test B (FIO on 8K buffer)...
[Pass] tries[0] => 0xf4
[Pass] tries[1] => 0xfe
[Pass] tries[2] => 0x10a
[Pass] tries[3] => 0xec
[Pass] failr[0] => 0x4c
[Pass] failw[0] => 0x97
[Pass] failr[1] => 0x44
[Pass] failw[1] => 0x0
[Pass] failr[2] => 0x0
[Pass] failw[2] => 0x9f
[Pass] failr[3] => 0x0
[Pass] failw[3] => 0x0
times[0] / tries[0] => 0x1c
times[1] / tries[1] => 0x1c
times[2] / tries[2] => 0x1f
times[3] / tries[3] => 0x1e
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 => 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
[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 => 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
[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 => 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
[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 => 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
[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 => 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
[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 => 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
[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 => 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
[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 => 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
[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 => 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
[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 => 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) => 0x40aa04a0
[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) => 0x8808
msleep(900)
[Pass] timer_func => 0x0
msleep(200)
[Pass] timer_func => 0x1
[Pass] ABS((timer_time/1000 - t0) - 1000) => 0x1
[Pass] ABS((timer_arg - ta0) - 1000) => 0xa
[Pass] timer = SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x882e
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) => 0x32bc4
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) => 0xfd
[Pass] ABS((get_us_clock() - t0) - 110000) => 0x1b4
[Pass] SetHPTimerAfterNow(90000, next_tick_cbr, overrun_cbr, 0) => 0x32bc6
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) => 0x244
[Pass] ABS(DeltaT(timer_arg, ta0) - 300000) => 0x228
[Pass] ABS((get_us_clock() - t0) - 310000) => 0x195
t0 = GET_DIGIC_TIMER() => 0xff3b3
msleep(250)
t1 = GET_DIGIC_TIMER() => 0x3b4f5
[Pass] ABS(MOD(t1-t0, 1048576)/1000 - 250) => 0x4
LoadCalendarFromRTC( &now )
s0 = now.tm_sec => 0x37
Date/time: 2019/01/01 23:18:55
msleep(1500)
LoadCalendarFromRTC( &now )
s1 = now.tm_sec => 0x39
[Pass] MOD(s1-s0, 60) => 0x2
[Pass] MOD(s1-s0, 60) => 0x2
m0 = MALLOC_FREE_MEMORY => 0x602e8
[Pass] p = (void*)_malloc(50*1024) => 0x11e7a8
[Pass] CACHEABLE(p) => 0x11e7a8
m1 = MALLOC_FREE_MEMORY => 0x53ad8
_free(p)
m2 = MALLOC_FREE_MEMORY => 0x602e8
[Pass] ABS((m0-m1) - 50*1024) => 0x10
[Pass] ABS(m0-m2) => 0x0
m0 = GetFreeMemForAllocateMemory() => 0x1ecce4
[Pass] p = (void*)_AllocateMemory(128*1024) => 0xaa0460
[Pass] CACHEABLE(p) => 0xaa0460
m1 = GetFreeMemForAllocateMemory() => 0x1cccd8
_FreeMemory(p)
m2 = GetFreeMemForAllocateMemory() => 0x1ecce4
[Pass] ABS((m0-m1) - 128*1024) => 0xc
[Pass] ABS(m0-m2) => 0x0
m01 = MALLOC_FREE_MEMORY => 0x602e8
m02 = GetFreeMemForAllocateMemory() => 0x1ecce4
[Pass] p = (void*)_alloc_dma_memory(128*1024) => 0x40aa04a0
[Pass] UNCACHEABLE(p) => 0x40aa04a0
[Pass] CACHEABLE(p) => 0xaa04a0
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x40aa04a0
_free_dma_memory(p)
[Pass] p = (void*)_shoot_malloc(16*1024*1024) => 0x4de3608c
[Pass] UNCACHEABLE(p) => 0x4de3608c
_shoot_free(p)
m11 = MALLOC_FREE_MEMORY => 0x602e8
m12 = GetFreeMemForAllocateMemory() => 0x1ecce4
[Pass] ABS(m01-m11) => 0x0
[Pass] ABS(m02-m12) => 0x0
[Pass] suite = shoot_malloc_suite_contig(16*1024*1024) => 0x11e7a8
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1000000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x11e7d0
[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) => 0x102390
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1498000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1023b8
[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) => 0x102390
[Pass] suite->signature => 'MemSuite'
[FAIL] suite->num_chunks => 0x1
[Pass] suite->size => 0x1598000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1023b8
[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) => 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") => 0x205a7c
[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) => 0xde9400ea
[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) => 0xde9600ba
[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) => 0xde980102
[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) => 0xde9a004c
[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, 11368 passed, 24 failed.
.bench.mo -> memory benchmarks
(https://farm8.staticflickr.com/7927/45652906325_1e5b634454.jpg) (https://flic.kr/p/2cyc5wz)
NICE work on digital zoom. I have tried this vision, and I find that I can't take a photo with the Movie crop mode. One more question is that once the white balance is adjusted, it can't turn back to auto, and when taking photos, the liveview will change. Hope trap Focusing mode will come one day.
Quote from: gukuangshi on January 03, 2019, 01:18:02 AM
...I can't take a photo with the Movie crop mode.
That is by design, same as on the EOSM. In fact you should get a warning screen like this:
(https://farm8.staticflickr.com/7914/44761574480_f065436204.jpg) (https://flic.kr/p/2bcqLC9)
Interesting that the EOSM shows the same warning even though it doesn't "officially" support Digital zoom from the Canon menu.
Quote from: gukuangshi on January 03, 2019, 01:18:02 AM
...once the white balance is adjusted, it can't turn back to auto...
You need to use the Canon menu to switch back to auto white balance. (Once again funky colors when doing a screenshot of the Canon menus.)
(https://farm5.staticflickr.com/4869/44761575120_8d45990fc2.jpg) (https://flic.kr/p/2bcqLPb)
(https://farm8.staticflickr.com/7831/32705728968_c69a59808b.jpg) (https://flic.kr/p/RQ6pLL)
Quote from: gukuangshi on January 03, 2019, 01:18:02 AM
...and when taking photos, the liveview will change.
Not sure what you mean by that. The ML overlays often vanish, that's a bug.
Quote from: gukuangshi on January 03, 2019, 01:18:02 AM
Hope trap Focusing mode will come one day.
Don't hold your breath. The EOSM, 100D, 650D and 700D can't do it. Check out the features matrix (https://builds.magiclantern.fm/features.html).
Thank you a lot for your careful answers. I do get the warning when taking photo in Digital zoom mod. I thought the white balance could be adjusted back to auto in ML menu.
Quote from: dfort on January 03, 2019, 04:28:38 AM
That is by design, same as on the EOSM. In fact you should get a warning screen like this:
(https://farm8.staticflickr.com/7914/44761574480_f065436204.jpg) (https://flic.kr/p/2bcqLC9)
Interesting that the EOSM shows the same warning even though it doesn't "officially" support Digital zoom from the Canon menu.
You need to use the Canon menu to switch back to auto white balance. (Once again funky colors when doing a screenshot of the Canon menus.)
(https://farm5.staticflickr.com/4869/44761575120_8d45990fc2.jpg) (https://flic.kr/p/2bcqLPb)
(https://farm8.staticflickr.com/7831/32705728968_c69a59808b.jpg) (https://flic.kr/p/RQ6pLL)
Not sure what you mean by that. The ML overlays often vanish, that's a bug.
Don't hold your breath. The EOSM, 100D, 650D and 700D can't do it. Check out the features matrix (https://builds.magiclantern.fm/features.html).
I've been merging in the great work that Danne has been doing on the EOSM. Don't expect it to work on the EOSM2. However, there are some tools in the builds I'm posting on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/) that should help us figure it out.
Wow, 17 downloads for the January 4 test build and no user reports? I didn't even advertise that one.
I re-enabled raw histogram because several modules weren't building without that feature enabled. In addition, I had LiveView screen freezes even with the non-raw histogram. I didn't want to mess around with the default settings so you'll have to disable the histogram then restart the camera to keep the screen from freezing up right away.
So--what's working and what's broken? I've been testing the arkanoid module for hours (instead of doing anything productive) and it feels pretty solid. Any other reports?
Quote from: dfort on January 07, 2019, 12:29:43 AM
Wow, 17 downloads for the January 4 test build and no user reports? I didn't even advertise that one.
I admit that I was one of them. Even though I was busy testing out the EOSM experimental builds that @Danne has been posting lately which seems to be more stable than the 100D atm :D
Quote from: dfort on January 07, 2019, 12:29:43 AM
I re-enabled raw histogram because several modules weren't building without that feature enabled. In addition, I had LiveView screen freezes even with the non-raw histogram. I didn't want to mess around with the default settings so you'll have to disable the histogram then restart the camera to keep the screen from freezing up right away.
I second that. Thanks for the pointers. Also noticed I must turn off the cam frequently (or sometimes go into canon menu and/or simply half pressed shutter) which can also do the trick. Strange as to be expected. Love the boat loads of Modules that are included. Especially the tools that can helps dig through. Thanks @dfort!
Quote from: dfort on January 07, 2019, 12:29:43 AM
So--what's working and what's broken? I've been testing the arkanoid module for hours (instead of doing anything productive) and it feels pretty solid. Any other reports?
I went ahead and tried a bunch of MLV's (both uncompressed & lossless in varieties of bits) to my surprise that most if not all had certain rumbling effects of its own. Seems I had to turn off Camera after each recording to try and unfreeze the LiveView. Upon reviewing files within MLVApp I managed to get at least 1 or 2 clean footage until halfway through of the file is when the jumbling dumplings came back. Though none of the lossless seem to work well. Uncompressed seem to spit out OK until halfway through the file itself.
By after this point I decided just to put the card back in and try to run some self tests (the 15 minute one) which seem to get stuck during the "photo taken during recording" part even after letting it run for 15+ minutes to no avail. So then I decided just to try simple things first such as Silent Picture to see if I could pull off FRSP on this toy. As expected, Simple DNG (even Lossless) spat out fine while not with FRSP. Heck even the Intervalometer works w Silent Picture which is a plus.
You probably already know this but I get 'ISOless PH err( 8 )' message on the LiveView once I enable Dual-ISO (disable module and turn off/on cam fixes it) while I also notice that it keeps telling me I have set 12-bit lossless in crop_rec.mo even when I have it off. Is this to be expected?
More to come... It definitely feels cheerfully sentimental to at least be crawling back into the swaps to be with you guys once again.
There's also things that do work:
Overlay -- need to restart for screen to refresh
- Zebras
- Focus Peak (though not at the same time as Magic Zoom of course)
- Magic Zoom
- Cropmarks
- Spotmeter
- False color
- Histogram (though raw histogram freeze LV in Photo mode)
- Waveform
- Vectorscope
Other features I tried and works:
- Intervalometer
- Audio RemoteShot
- Motion Detect
- Anamorphic
The sf_dump module seems to work though I've been having problems running the EOSM2 in QEMU lately (https://www.magiclantern.fm/forum/index.php?topic=2864.msg210226#msg210226).
Anyway -- a lot is working but the camera is still temperamental to say the least.
Just for fun, I took the EOSM2 on vacation with me. Here's a simple silent still color graded to show those lovely focus pixels. Hum--got some work to do.
(https://farm5.staticflickr.com/4872/46655294611_710739f07e_z.jpg) (https://flic.kr/p/2e5LzDe)
Quote from: dfort on January 07, 2019, 12:29:43 AM
I re-enabled raw histogram because several modules weren't building without that feature enabled. In addition, I had LiveView screen freezes even with the non-raw histogram.
LV did not freeze with (RAW) histogram enabled in photo mode for the nightly builds between 14th of Dec 2018 and at least 27 of Dec 2018, but it was freezing for the ISO research builds during this time interval. Yesterday I was loading the latest nightly build from January 7th and now LV is dead again with RAW histograms enabled (I cannot tell for the builds between 27/12 and yesterday, I was off there).
@dfort, you stated here (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209531#msg209531)
Quote from: dfort on December 21, 2018, 08:51:57 AM
Ok--so it looks like the "C" build is the most stable ..... 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.
C build was from magiclantern-Nightly.2018Dec14.EOSM210 and LV was stable with RAW histogram. So maybe some lines in raw.c had been activated again by merging in different new developments?
Good point.
Danne commented out a section of code (https://bitbucket.org/daniel_fort/magic-lantern/commits/1d378c7735b0d0ae5fc920e122ceffcdadf8b82e#chg-src/raw.c) then reverted the change (https://bitbucket.org/daniel_fort/magic-lantern/commits/c7565fdfe24f73b01ca24d96a0ce0bc2d63fd112). I was just following along but we should take a closer look at this and see what's going on. Commented out section once again (https://bitbucket.org/daniel_fort/magic-lantern/commits/9b460382b1e8540f0987288f4b2b43c727426185) to get raw histogram working without lv freezing.
January 8 test build posted (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).
This part let us record raw without freezes but the content is gonna be noise only. Anyway, that's how far I got. One thing to test is enabling fps override and push tha A-timmer and see if that also fixes raw histogram freeze.
Here is something that might help track down one of the problems. Open up the console to see what's going on.
EOSM2
(https://farm5.staticflickr.com/4892/45941989944_5aec22e2b0.jpg) (https://flic.kr/p/2cZJH1U)
EOSM - same changeset
(https://farm8.staticflickr.com/7849/45751686165_6054fd81d2.jpg) (https://flic.kr/p/2cGVmkg)
Any clues where to look?
src/raw.c
/* allow the local sigma to be less than 3 * ref_sigma */
if (local_stdev_x100 > ref_stdev_x100 * 3)
{
printf("Black %d/%d: stdev too large (%d/100, ref %d/100)\n", i+1, N, local_stdev_x100, ref_stdev_x100);
return 0;
}
Found a fix to pass the black_level_check_left (https://bitbucket.org/daniel_fort/magic-lantern/commits/1a91df18ee956020921bded24541b6572b0edbdb).
(https://farm8.staticflickr.com/7836/39712078903_ef3848070c.jpg) (https://flic.kr/p/23vdMvz)
LiveView screen freezing is still a problem so I'm keeping Danne's temp fix in place for now. Also merged in Danne's latest and posted a new test build (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).
One step forward, one step back.
Checking with the various RAW_DEBUG options it looks like yesterday's "fix" didn't fix anything. I'm checking the results from the EOSM2 against the EOSM and found another problem that needs to be tracked down.
src/raw.c
#define RAW_DEBUG /* define it to help with porting */
EOSM2
(https://farm5.staticflickr.com/4822/46692583601_fff4804752.jpg) (https://flic.kr/p/2e94GmR)
EOSM
(https://farm8.staticflickr.com/7896/31751185127_6d411ebd18.jpg) (https://flic.kr/p/QnK89k)
Also narrowed down the LiveView freeze issue to one line, the call to edmac_raw_slurp, so I'm trying some printf statements to figure out what parameters are being passed to edmac_raw_slurp.
src/raw.c
if (raw_lv_buffer_size >= pitch * height)
{
printf("buf %x, (CACHEABLE(buf) %x, pitch %d, height %d\n", buf, CACHEABLE(buf), pitch, height);
edmac_raw_slurp(CACHEABLE(buf), pitch, height);
}
EOSM2
(https://farm5.staticflickr.com/4829/46692584041_e0251d495e.jpg) (https://flic.kr/p/2e94Gur)
EOSM
(https://farm5.staticflickr.com/4823/31751185697_8a46b33680.jpg) (https://flic.kr/p/QnK8ja)
Not sure if I'm getting warmer or colder because I don't really know what I'm doing here.
Raw2lv test -6 -6 (726, 486)
Should be 0, 0 (720, 480)
Wrong active areas?
Also wonder if the freeze is caused by some lock in ml code or unrelated.
Quote from: Danne on January 11, 2019, 05:40:29 AM
Wrong active areas?
I don't know. Ran raw_diag and it looks good to me. At least compared to the EOSM.
EOSM2
(https://farm8.staticflickr.com/7829/46666466252_5213b2b021.jpg) (https://flic.kr/p/2e6KQzJ)
EOSM
(https://farm5.staticflickr.com/4841/31777672517_7c2cf1b0d6.jpg) (https://flic.kr/p/Qq5SVt)
EOSM2
(https://farm5.staticflickr.com/4851/32844178778_0a1ae33295.jpg) (https://flic.kr/p/S3k15s)
EOSM
(https://farm8.staticflickr.com/7921/45994557274_9a68ac399d.jpg) (https://flic.kr/p/2d5o8sb)
With raw histogram turned on and in photo mode the camera starts normally, screen is drawn and then between 1 and about 40 seconds the screen freezes. Going into the Canon menu and back to LiveView will "unfreeze" it but will freeze again in about the same timeframe.
With the raw histogram disabled the LiveView doesn't freeze, this is what the console shows:
EOSM2
(https://farm5.staticflickr.com/4850/45995967184_7ed890ec2b.jpg) (https://flic.kr/p/2d5vmyY)
Enabling the raw histogram will freeze LiveView in photo mode. Both the EOSM and EOSM2 show pretty much the same information on the console:
EOSM2
(https://farm8.staticflickr.com/7871/46720548561_e170ff1084.jpg) (https://flic.kr/p/2ebx2nk)
EOSM
(https://farm5.staticflickr.com/4903/45805167375_782705576f.jpg) (https://flic.kr/p/2cMDsr6)
One thing that might be a problem is the small size difference of the LV raw buffer between these two similar cameras, 0x48798100 for the EOSM2 verses 0x46798080 for the EOSM in this test. In any case it seems to point back to what running RAW_DEBUG back in Reply #440 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg210391#msg210391) turned up where the EOSM2 showed an LV raw buffer of 0x8798100 verses 0x6798080 for the EOSM on that test.
Thought I'd write up a quick update on a long process.
I've been trying to track down the issue with the LiveView freezing in photo mode when the raw histogram is active. I discovered that switching from RAW in the Canon menu to one of the JPEG options (except RAW + L) it will not freeze but then again we need it set to RAW for simple silent stills (FRSP is not working). I found some different PREFERRED_RAW_TYPE addresses by using the RAW_DEBUG_TYPE option that didn't freeze LiveView but then it wouldn't save valid silent stills. Took another look at the console with RAW_DEBUG enabled and things are looking pretty normal now--I think:
(https://farm5.staticflickr.com/4828/45843285035_7b99eb480b.jpg) (https://flic.kr/p/2cR1Pu8)
Danne reported that in movie mode, mlv_lite enabled and raw recording on he also gets the LiveView freeze. He discovered that with global draw turned off, FPS override set to 24fps and Timer A pushed to (FT+30) it will actually record raw video. Whew--took me a while to follow that but I tried it with the latest test build and yes, it does work.
The LiveView freeze is really bugging me but it is working--or at least limping. That's where we're at on this. Any other reports? Any hints on how to debug this?
Quote from: Danne on January 08, 2019, 07:26:51 PM
...One thing to test is enabling fps override and push tha A-timmer and see if that also fixes raw histogram freeze.
Getting back to this -- it is also working in photo mode. In other words, turn on FPS override, set it to 24fps and push timer A to (FT+30) and no more LiveView freezes.
A while back fps-engio.c intentionally failed to build on the EOSM and 1100D because the timer values needed to be tested. I'm not exactly sure how it is supposed to work but I looked up those discussions:
https://www.magiclantern.fm/forum/index.php?topic=14959.msg148768#msg148768
https://www.magiclantern.fm/forum/index.php?topic=1009.msg151433#msg151433
Looks like it is time to understand how this works.
[EDIT] Does fps-engio.c even come into play if FPS override it not enabled?
Great work Dan. Feels like you are getting there soon :). Quite the journey. NIce that we got the correct engio stub for crop_rec.c working at least :P
Quote from: dfort on January 16, 2019, 06:39:31 AM
Getting back to this -- it is also working in photo mode. In other words, turn on FPS override, set it to 24fps and push timer A to (FT+30) and no more LiveView freezes.
The final frame rate is still 24 fps, or a bit lower? If it's still 24 fps, then it doesn't make much sense (i.e. why specifically +30).
Quote
Does fps-engio.c even come into play if FPS override it not enabled?
It shouldn't.
Otherwise, the FPS limits should be the same as on 100D - they share the same focus pixel pattern, if I'm not mistaken.
#define TG_FREQ_BASE 32000000
#define FPS_TIMER_A_MIN (ZOOM ? 724 : MV1080CROP ? 540 : 520)
#define FPS_TIMER_B_MIN (ZOOM ? 1450 : MV1080CROP ? 1750 : MV720 || (lv && lv_dispsize==1 && !is_movie_mode()) ? 990 : 1970)
Quote from: a1ex on January 16, 2019, 08:53:10 AM
The final frame rate is still 24 fps, or a bit lower? If it's still 24 fps, then it doesn't make much sense (i.e. why specifically +30).
Not specifically +30. However pushing timer A by a lot will have the positive side effect of freeing liveview from freezing thus giving the space to record lossless. It´s not fool proof. It sometimes freezes anyway but it´s way better than the starting point which is a complete ice age.
What could be related to fps override timers freeing liveview?
Edit: Added the 100D timers. Freezing liveview. Enabling fps override to 23.976 and looking at the a-timer and it´s on 528. Testing simply enabling this and pushing canon menu button frees liveview after about 3 seconds. Pushing timer-a to 588 and timer b will be at 2265 and now 24.027 fps and liveview stays free for a minute or longer.
Quote from: a1ex on January 16, 2019, 08:53:10 AM
...the FPS limits should be the same as on 100D - they share the same focus pixel pattern, if I'm not mistaken.
I also thought of that and have been using the 100D values on the EOSM2 (https://bitbucket.org/daniel_fort/magic-lantern/commits/dbd4d56ea778f274f7a6bff69f1494ffc56d3bdb) for my tests.
News update -- made some major changes.
I was merging in Danne's latest EOSM changes but because there were so many branches merged into my M2 experiments branch it turned out that this branch wasn't working properly with the EOSM. After lots of trial and error I finally got it working on the EOSM so now we should be in a better place to continue debugging the M2.
Got basic crop_rec working!
Ok--not nearly as exciting as what Danne is doing on the EOSM but using his bleeding edge branch with the EOSM2 merged in and trying out just the basic crop_rec (https://bitbucket.org/daniel_fort/magic-lantern/commits/df2f2903a9e1b2aba683a58c32a2e1c59c22d58d) which is 3x3 sampling with the 1280x720/60p setting I was able to record H.264. Better still, setting FPS override to 24fps and pushing the A timer to +30 recording raw video is possible. Here's the proof:
mlv_dump -v
...
Res: 1736x696
raw_info:
api_version 0x00000001
height 727
width 1808
...
sampling 3x3 (read 1 line, skip 2, bin 3 columns)
...
Camera Name: 'Canon EOS M2'
Already done here:
https://www.magiclantern.fm/forum/index.php?topic=15895.msg209291#msg209291
Since the correct adtg and engio adreeses was added all registers changes as expected. Still freezes though...
I'm always a few steps behind Danne. Ok--good to know that the basic crop_rec setting is still working and it is easy to switch between the "is_basic" settings and the new and improved settings.
The main issue to work on is the LiveView freeze. Looks like it is time to go back to creating startup logs and see if that reveals anything. First thing I tried was the dm-spy-experiments branch. It doesn't boot into LiveView on the EOSM/M2 with "CONFIG_DEBUG_INTERCEPT_STARTUP=y" but it is showing something that might be a hint:
grep "TouchMgr" EOSM2_1.LOG
756A8> TouchMgr:ff34630c:c1:03: touchSetCommand
756EA> TouchMgr:ff345ef8:c1:03: touchIgnore
757AD> TouchMgr:ff345f60:c1:03: touchInit
7B06D> TouchMgr:ff346008:c1:16: Touch IC Ver : 0x0009
8C331> TouchMgr:ff3455dc:c1:01: ### CheckTouchEvent ###
9DFFC> TouchMgr:ff345748:c1:01: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(15,15)
9E03E> TouchMgr:ff345a9c:c1:03: touchHandle : Not Working
A33EB> TouchMgr:ff3455dc:c1:01: ### CheckTouchEvent ###
A392A> TouchMgr:ff345748:c1:01: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(15,15)
A396D> TouchMgr:ff345a9c:c1:03: touchHandle : Not Working
A8D1E> TouchMgr:ff3455dc:c1:01: ### CheckTouchEvent ###
A9269> TouchMgr:ff345748:c1:01: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(15,15)
A92AB> TouchMgr:ff345a9c:c1:03: touchHandle : Not Working
...
BLAH BLAH BLAH
[EDIT] Ran the same test on the EOSM and it isn't complaining:
73E90> TouchMgr:ff335208:c1:16: Start Sensibility = 0
73ED9> TouchMgr:ff335430:c1:03: NORMAL SENSIBILITY
73F9A> TouchMgr:ff334c78:c1:01: skip Touch polling
7408F> TouchMgr:ff335d80:c1:03: TOUCH_UILOCK OFF GUI = 1 UILock = 0
7C393> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
845F8> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
8A2AF> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
91C06> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
9B02E> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
A255A> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
A9A7D> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
B0F8B> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
B84A5> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
BFAC8> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
C6F4C> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt1 #1 X0 Y479 0 0 ID(1,15)
CE461> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt2 #1 X0 Y479 0 0 ID(1,15)
D59E7> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #1 X0 Y479 0 0 ID(1,15)
DCF04> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt2 #1 X1 Y479 0 0 ID(1,15)
E4415> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #1 X1 Y479 0 0 ID(1,15)
EB904> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt1 #1 X2 Y479 0 0 ID(1,15)
F2E22> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt3 #1 X6 Y479 0 0 ID(1,15)
FA35B> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt1 #1 X9 Y479 0 0 ID(1,15)
01885> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt2 #1 X10 Y479 0 0 ID(1,15)
08DC3> TouchMgr:ff3355e0:c1:02: F:0 O:0 B:0 Cnt0 #1 X14 Y479 0 0 ID(1,15)
I took the EOSM2.103_dm-spy-experiments branch from you @dfort, I compiled with "CONFIG_DEBUG_INTERCEPT_STARTUP = y", but unfortunately, it does not save me a log. Do I miss something? Anything to be done?
LiveView never turns on and the orange LED flickers, right? Just let it cook for a while, pull the battery and there should be a log file in the card's root directory.
BTW--I turn on the "CONFIG_DEBUG_INTERCEPT_STARTUP=y" option by placing it in a Makefile.user file in the top magic-lantern directory.
I did not run EOSM2.103_dm-spy-experiments branch in the EOSM2, but in qemu.
I do not have my device now.
New stubs value found:
-NSTUB(0xFF3CF44C, PlayMain_handler)
+NSTUB(0xFF787304, PlayMain_handler)
That is in line with what I found a while back on the EOSM (https://www.magiclantern.fm/forum/index.php?topic=9741.msg201175#msg201175):
platform/EOSM.202/stubs.S
-NSTUB(0xFF3BC078, PlayMain_handler)
+NSTUB(0xFF715BA4, PlayMain_handler)
Feature request -- put the changeset information in the log file. I'm searching for that perfect selftest run on the EOSM but can't figure out which changeset I used. Specifically, I'm trying to find out which commit caused this to show up on the EOSM/EOSM2:
[FAIL] suite->num_chunks => 0x1
Quote from: dfort on January 22, 2019, 01:00:24 AM
I'm trying to find out which commit caused this to show up on the EOSM/EOSM2:
[FAIL] suite->num_chunks => 0x1
Found it:
exmem: reworked shoot_malloc to handle large requests better
- moved autodetection to dedicated functions (for both fragmented and continuous allocations)
- autodetect the max available size for large requests (slower, but when it fails, it fails gracefully)
Revision:
17094
Changeset:
da3cfb7600fcd96d1020690372ebc23c5fd58f85 [da3cfb7600fc]
Parents:
17093
Author:
alex@thinkpad
Date:
February 23, 2018 at 3:26:53 PM PST
Branch:
lua_fixWorking on narrowing it down even further if possible.
Narrowed it down on the EOSM. Reverting the following code at line 435:
src/exmem.c
-/* called from RscMgr task */
-static REQUIRES(RscMgr) void srm_malloc_cbr(void** dst_ptr, void* raw_buffer, uint32_t raw_buffer_size)
+static void srm_malloc_cbr(void** dst_ptr, void* raw_buffer, uint32_t raw_buffer_size)
Resolves the suite->num_chunks fails when running the selftest module Stubs API test. However, it doesn't resolve it on the EOSM2. This probably isn't a "fix" but it does seem to point out a problem on the EOSM. Now to get back on track and see if it can be "fixed" on the M2.
[EDIT 1] Note that regressing exmem.c all the way back to revision 17093 - changeset 21264fc914dc does "fix" the issue on the M2.
[EDIT 2] Narrowed down the issue with the EOSM2 failing the selftest module exmem tests to 'struct memSuite * _shoot_malloc_suite_contig(size_t size)'. Replacing that block of code with the version in the "working" lua_fix changeset resolves the exmem fails on the selftest module. This hack also works with the EOSM. I'm thinking that what this is pointing to is a problem with one or more ExMem stubs on the EOSM/EOSM2. Checking the EOSM against the 700D and 100D I found some differences in the AddMemoryChunk stub. Another stub that doesn't look like a perfect pattern match between these platforms is GetFirstChunkFromSuite. Hard to tell but DeleteMemorySuite and GetMemoryAddressOfMemoryChunk might be different too.
Facepalm moment.
Using the latest exmem.c from the crop_rec_4k_mlv_snd branch and the latest selftest module from the lua_fix branch and the EOSM doesn't show the num_chunks fails but the EOSM2 does. Hacking exmem is obviously not the solution so took yet another look at the EOSM2 ExMem stubs but found nothing that looked out of place. Any hints? Seems I took one step forward and two steps back these last couple of days.
No big breakthrough to report but what I've been doing today might help other users wanting to dive into coding so...
I've mentioned the num_chunks fails before but there's another problem that the selftest Stubs API test is showing on the EOSM2. It is showing up on the GUI stub test so I narrowed down the tests like this:
modules/selftest/selftest.c
/* save log after each sub-test */
for (int i=0; i < n; i++)
{
stub_test_model_id(); stub_test_save_log();
/* Skip down to the GUI test
stub_test_edmac(); stub_test_save_log();
stub_test_cache(); stub_test_save_log();
stub_test_af(); stub_test_save_log();
stub_test_file_io(); stub_test_save_log();
stub_test_gui_timers(); stub_test_save_log();
stub_test_other_timers(); stub_test_save_log();
stub_test_malloc_n_allocmem(); stub_test_save_log();
stub_test_exmem(); stub_test_save_log();
stub_test_strings(); stub_test_save_log();
stub_test_engio(); stub_test_save_log();
stub_test_display(); stub_test_save_log();
stub_test_dryos(); stub_test_save_log();
*/
stub_test_gui(); stub_test_save_log();
beep();
}
I recently discovered that the EOSM had a problem with the PlayMain_handler stub. Nobody probably noticed it because it only showed up as a problem on the test log.
...
[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
...
Not much of a hint on what to fix is it? Now that the EOSM is fixed and the EOSM2 is nearly identical I thought why not try breaking some stubs on the EOSM and that might help find which stubs to fix on the EOSM2. I found a couple of them and put in some additional information in the log.
For example for the PlayMain_handler issue:
modules/selftest/selftest.c
/* take a picture and go to play mode */
lens_take_picture(64, AF_DISABLE);
msleep(2000);
enter_play_mode();
TEST_FUNC_CHECK(is_play_mode(), != 0);
TEST_MSG("[INFO] Checking stub = PlayMain_handler\n"); // <---- Added which stub is being tested to the log
TEST_FUNC_CHECK(is_pure_play_photo_mode(), != 0);
TEST_FUNC_CHECK(is_pure_play_movie_mode(), == 0);
I kept breaking the Dialog handlers stubs one at a time and came up with only two that show up in the tests. Ok--so let's get back to the EOSM2:
STUBTEST.LOG
[Pass] is_play_mode() => 0x1
[INFO] Camera model: Canon EOS M2 1.0.3 (0x80000355 EOSM2)
[Pass] is_camera("DIGIC", "*") => 0x1
[Pass] is_camera(__camera_model_short, firmware_version) => 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
[INFO] Checking stub = LiveViewShutterApp_handler
[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
[INFO] Checking stub = PlayMain_handler
[Pass] is_pure_play_photo_mode() => 0x1
[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, 25 passed, 3 failed.
.
So at least we know that those two stubs are fine. It would be great if the selftest log included the names of the stubs being tested so we could be able to zero in on what needs fixing but I imagine that would be a lot of work. At least a lot of work the way I'm doing it.
One more tip. If you want to speed up the install by building just the modules you're testing:
make install ML_MODULES="selftest"
The latest test build on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/) includes some annotations in the selftest module Stubs API tests log.
I've been running these test way too much for my sanity these past few days. If you read my last several posts you'll notice that I have been obsessed with trying to get a perfect test run.
The most frustrating has been the num_chunks fails because it doesn't seem to be consistent. I recently found out how to always pass the ExMem test on both the EOSM and the EOSM2. Simply restore the Canon settings to their default. Now the default settings are something no Magic Lantern power user would ever use, in fact ML will flash a warning to get out of Auto mode. Still, when resetting to factory defaults there are no num_chunks failures.
Another issue that seems to disappear is the LiveView freeze. I said "seems to disappear" because the Canon defaults to JPEG instead of RAW in photo mode and it turns out that switching to RAW will freeze LiveView with the raw histogram enabled.
There are a few tests that fail on the EOSM2 that pass on the EOSM, I annotated those. Then there are some tests that fail on both of these cameras so it will require some more digging to figure out which stub is causing this. There are a few autofocus tests that pass in photo mode but not in movie mode depending on which lens is mounted on the camera and maybe if it is a full moon because I know that I was able to get a perfect score on the EOSM (https://www.magiclantern.fm/forum/index.php?topic=9741.msg201175#msg201175) a while back but for the life of me I can't replicate it.
In any case, here's one of my EOSM2 test runs--enjoy!
[Pass] is_play_mode() => 0x1
[INFO] Camera model: Canon EOS M2 1.0.3 (0x80000355 EOSM2)
[Pass] is_camera("DIGIC", "*") => 0x1
[Pass] is_camera(__camera_model_short, firmware_version) => 0x1
[Pass] src = fio_malloc(size) => 0x4de1a084
[Pass] dst = fio_malloc(size) => 0x4e61e090
[Pass] memcmp(dst, src, 4097) => 0xffffffcf
[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) => 0xffffffb1
[Pass] edmac_memcpy(dst, src, size) => 0x4e61e090
[Pass] memcmp(dst, src, size) => 0x0
[Pass] memcmp(dst, src, size) => 0xfffffff2
[Pass] edmac_memcpy_start(dst, src, size) => 0x4e61e090
dt => 0x2978
[Pass] copied => 0x400b70
[Pass] copied => 0x400b70
[Pass] copied => 0x400b70
[Pass] memcmp(dst, src, copied) => 0x0
[Pass] memcmp(dst, src, copied + 16) => 0x4b
edmac_memcpy_finish()
free(src)
free(dst)
Cache test A (EDMAC on BMP buffer)...
[Pass] bmp = bmp_load("ML/CROPMKS/CINESCO2.BMP", 1) => 0x809ce4
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x890
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x0
Cache test B (FIO on 8K buffer)...
[Pass] tries[0] => 0xea
[Pass] tries[1] => 0xe8
[Pass] tries[2] => 0x104
[Pass] tries[3] => 0x112
[Pass] failr[0] => 0x3f
[Pass] failw[0] => 0x9c
[Pass] failr[1] => 0x40
[Pass] failw[1] => 0x0
[Pass] failr[2] => 0x0
[Pass] failw[2] => 0xb4
[Pass] failr[3] => 0x0
[Pass] failw[3] => 0x0
times[0] / tries[0] => 0x1e
times[1] / tries[1] => 0x1e
times[2] / tries[2] => 0x1e
times[3] / tries[3] => 0x1e
Cache tests finished.
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] HALFSHUTTER_PRESSED => 0x1
[INFO] ****** EOSM/M2 usually fails here but sometimes passes ******
[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
[INFO] ****** EOSM/M2 usually fails here but sometimes passes ******
[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
[INFO] ****** EOSM/M2 usually fails here but sometimes passes ******
[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
[INFO] ****** EOSM/M2 usually fails here but sometimes passes ******
[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
[INFO] ****** EOSM/M2 usually fails here but sometimes passes ******
[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
[INFO] ****** EOSM/M2 usually fails here but sometimes passes ******
[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
[INFO] ****** EOSM/M2 usually fails here but sometimes passes ******
[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
[INFO] ****** EOSM/M2 usually fails here but sometimes passes ******
[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
[INFO] ****** EOSM/M2 usually fails here but sometimes passes ******
[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
[INFO] ****** EOSM/M2 usually fails here but sometimes passes ******
[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) => 0x40a97ae0
[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) => 0x89ae
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) => 0x89d2
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) => 0x32ec6
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) => 0xfa
[Pass] ABS((get_us_clock() - t0) - 110000) => 0xdb
[Pass] SetHPTimerAfterNow(90000, next_tick_cbr, overrun_cbr, 0) => 0x32ec8
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) => 0x169
[Pass] ABS(DeltaT(timer_arg, ta0) - 300000) => 0x148
[Pass] ABS((get_us_clock() - t0) - 310000) => 0xf9
t0 = GET_DIGIC_TIMER() => 0xa622a
msleep(250)
t1 = GET_DIGIC_TIMER() => 0xe2bb2
[Pass] ABS(MOD(t1-t0, 1048576)/1000 - 250) => 0x2
LoadCalendarFromRTC( &now )
s0 = now.tm_sec => 0x23
Date/time: 2019/01/24 14:54:35
msleep(1500)
LoadCalendarFromRTC( &now )
s1 = now.tm_sec => 0x25
[Pass] MOD(s1-s0, 60) => 0x2
[Pass] MOD(s1-s0, 60) => 0x2
m0 = MALLOC_FREE_MEMORY => 0x603e8
[Pass] p = (void*)_malloc(50*1024) => 0x11e7c8
[Pass] CACHEABLE(p) => 0x11e7c8
m1 = MALLOC_FREE_MEMORY => 0x53bd8
_free(p)
m2 = MALLOC_FREE_MEMORY => 0x603e8
[Pass] ABS((m0-m1) - 50*1024) => 0x10
[Pass] ABS(m0-m2) => 0x0
m0 = GetFreeMemForAllocateMemory() => 0x1efc38
[Pass] p = (void*)_AllocateMemory(128*1024) => 0xa97aa0
[Pass] CACHEABLE(p) => 0xa97aa0
m1 = GetFreeMemForAllocateMemory() => 0x1cfc2c
_FreeMemory(p)
m2 = GetFreeMemForAllocateMemory() => 0x1efc38
[Pass] ABS((m0-m1) - 128*1024) => 0xc
[Pass] ABS(m0-m2) => 0x0
m01 = MALLOC_FREE_MEMORY => 0x603e8
m02 = GetFreeMemForAllocateMemory() => 0x1efc38
[Pass] p = (void*)_alloc_dma_memory(128*1024) => 0x40a97ae0
[Pass] UNCACHEABLE(p) => 0x40a97ae0
[Pass] CACHEABLE(p) => 0xa97ae0
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x40a97ae0
_free_dma_memory(p)
[Pass] p = (void*)_shoot_malloc(16*1024*1024) => 0x4de1a074
[Pass] UNCACHEABLE(p) => 0x4de1a074
_shoot_free(p)
m11 = MALLOC_FREE_MEMORY => 0x603e8
m12 = GetFreeMemForAllocateMemory() => 0x1efc38
[Pass] ABS(m01-m11) => 0x0
[Pass] ABS(m02-m12) => 0x0
[Pass] suite = shoot_malloc_suite_contig(16*1024*1024) => 0x1023e0
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1000000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x102408
[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) => 0x1023e0
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1f24000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x102408
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1f24000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x44000064
[Pass] UNCACHEABLE(p) => 0x44000064
largest_shoot_block = suite->size => 0x1f24000
[INFO] largest_shoot_block: 31MB
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(largest_shoot_block + 1024*1024) => 0x1023e0
[Pass] suite->signature => 'MemSuite'
[INFO] ************ Reset Canon settings if suite->num_chunks => 0x1 fails ************
[Pass] suite->num_chunks => 0x4
[Pass] suite->size => 0x2024000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x102408
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x15b4000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
chunk = GetNextMemoryChunk(suite, chunk) => 0x117510
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x169c000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4ae00064
[Pass] UNCACHEABLE(p) => 0x4ae00064
chunk = GetNextMemoryChunk(suite, chunk) => 0x11e7c8
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1774000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x45f240e4
[Pass] UNCACHEABLE(p) => 0x45f240e4
chunk = GetNextMemoryChunk(suite, chunk) => 0x11e800
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x2024000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x44000064
[Pass] UNCACHEABLE(p) => 0x44000064
chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x2024000
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(0) => 0x1023e0
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x4
[Pass] suite->size => 0x3300000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x102408
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x15b4000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4de1a070
[Pass] UNCACHEABLE(p) => 0x4de1a070
chunk = GetNextMemoryChunk(suite, chunk) => 0x117510
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x169c000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4ae00064
[Pass] UNCACHEABLE(p) => 0x4ae00064
chunk = GetNextMemoryChunk(suite, chunk) => 0x11e7c8
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1774000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x45f240e4
[Pass] UNCACHEABLE(p) => 0x45f240e4
chunk = GetNextMemoryChunk(suite, chunk) => 0x11e800
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x3300000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x44000064
[Pass] UNCACHEABLE(p) => 0x44000064
chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x3300000
[INFO] ************ Reset Canon settings if suite->num_chunks => 0x1 fails ************
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] strlen("abc") => 0x3
[Pass] strlen("qwertyuiop") => 0xa
[Pass] strlen("") => 0x0
[Pass] strcpy(msg, "hi there") => 0x233b0c
[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) => 0x233ae0
[Pass] foo => 'asdfghuiop'
[Pass] memset(bar, '*', 5) => 0x233ac0
[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) => 0xebd600ea
[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) => 0xebd800ba
[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) => 0xebda029c
[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) => 0xebdc0064
[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
[INFO] ************ Checking stub = LiveViewShutterApp_handler ************
[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);
[INFO] ************ EOSM2 fails here ************
[FAIL] MENU_MODE => 0x0
[INFO] ************ EOSM2 fails here ************
[FAIL] PLAY_MODE => 0x1
[Pass] dialog->type => 'DIALOG'
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[INFO] ************ EOSM2 fails here ************
[FAIL] PLAY_MODE => 0x1
SW1(1,100)
[Pass] HALFSHUTTER_PRESSED => 0x1
SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[INFO] ************ Checking stub = PlayMain_handler ************
[Pass] is_pure_play_photo_mode() => 0x1
[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, 11689 passed, 23 failed.
.
Looks like those fails on the focus tests are not valid on the EOSM/EOSM2.
So, we're down to just a few stubs to hunt down in the GUI tests.
modules/selftest/selftest.c
// GUI_Control
msleep(1000);
TEST_VOID(GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000););
TEST_FUNC_CHECK(PLAY_MODE, != 0);
TEST_FUNC_CHECK(MENU_MODE, == 0);
TEST_VOID(GUI_Control(BGMT_MENU, 0, 0, 0); msleep(1000););
TEST_MSG("[INFO] ************ EOSM2 fails here ************\n");
TEST_FUNC_CHECK(MENU_MODE, != 0);
TEST_MSG("[INFO] ************ EOSM2 fails here ************\n");
TEST_FUNC_CHECK(PLAY_MODE, == 0);
// also check dialog signature here, because display is on for sure
struct gui_task * current = gui_task_list.current;
struct dialog * dialog = current->priv;
TEST_FUNC_CHECK_STR(dialog->type, "DIALOG");
TEST_VOID(GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500););
TEST_FUNC_CHECK(MENU_MODE, == 0);
TEST_MSG("[INFO] ************ EOSM2 fails here ************\n");
TEST_FUNC_CHECK(PLAY_MODE, == 0);
STUBTEST.LOG
...
[INFO] Camera model: Canon EOS M2 1.0.3 (0x80000355 EOSM2)
...
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
[INFO] ************ Checking stub = LiveViewShutterApp_handler ************
[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);
[INFO] ************ EOSM2 fails here ************
[FAIL] MENU_MODE => 0x0
[INFO] ************ EOSM2 fails here ************
[FAIL] PLAY_MODE => 0x1
[Pass] dialog->type => 'DIALOG'
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[INFO] ************ EOSM2 fails here ************
[FAIL] PLAY_MODE => 0x1
SW1(1,100)
[Pass] HALFSHUTTER_PRESSED => 0x1
SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[INFO] ************ Checking stub = PlayMain_handler ************
[Pass] is_pure_play_photo_mode() => 0x1
[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, 11689 passed, 23 failed.
.
I can't find anything wrong in stubs.S so the problem must be somewhere else? Maybe in consts.h or gui.h?
Staring at the following bit of code but where to go from here?
platform/EOSM2.103/consts.h
#define PLAY_MODE (gui_state == GUISTATE_PLAYMENU && CURRENT_GUI_MODE == GUIMODE_PLAY)
#define MENU_MODE (gui_state == GUISTATE_PLAYMENU && CURRENT_GUI_MODE == GUIMODE_MENU)
[EDIT] Think maybe this is where the problem is at:
platform/EOSM2.103/consts.h
#define CURRENT_GUI_MODE (*(int*)0x928BC) // in SetGUIRequestMode (0x92860+0x5C)
Taking a close look at these two tests in the selftest module:
TEST_VOID(GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000););
TEST_VOID(GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500););
After running each one how about printing out which mode the camera is in:
TEST_MSG("[INFO] MENU_MODE: 0x%X\n", MENU_MODE);
TEST_MSG("[INFO] PLAY_MODE: 0x%X\n", PLAY_MODE);
Testing on the EOSM to see how it is supposed to work:
EOSM
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x1
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x1
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x1
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x1
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x1
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x0
Changing from play to menu to play makes sense. I didn't expect it to toggle the mode on/off, learned something new.
Now how about the EOSM2:
EOSM2
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x1
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x1
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x1
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x0
The toggling works but there's a problem when in play mode and you switch to menu mode.
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
This is not an issue going the other way:
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[INFO] MENU_MODE: 0x1
[INFO] PLAY_MODE: 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[INFO] MENU_MODE: 0x0
[INFO] PLAY_MODE: 0x1
Just for the record, I did these tests like this:
modules/selftest/selftest.c
static void stub_test_gui()
{
msleep(1000);
TEST_VOID(GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500););
TEST_MSG("[INFO] MENU_MODE: 0x%X\n", MENU_MODE);
TEST_MSG("[INFO] PLAY_MODE: 0x%X\n", PLAY_MODE);
TEST_VOID(GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000););
TEST_MSG("[INFO] MENU_MODE: 0x%X\n", MENU_MODE);
TEST_MSG("[INFO] PLAY_MODE: 0x%X\n", PLAY_MODE);
}
Any hints on which stub is the culprit here?
[EDIT] Can't be this, can it?
platform/EOSM2.103/gui.h
#define BGMT_MENU 0x6
I thought that maybe logging activity while pressing the Menu and Play buttons would give some sort of clue whether or not the button codes are correct so I built dm-spy-experiments with CONFIG_DEBUG_INTERCEPT and CONFIG_MMIO_TRACE. Got plenty of information but nothing that I could see that would help with the button codes in the previous post.
However, there were some interesting bits in the EOSM2 log that looked promising.
DBECD> DisplayMgr:ff1395e0:82:01: SetImageVramParameter pAddress=0x4f7e7800 pFlipCBR=0
E4151> DisplayMgr:ff1395e0:82:01: SetImageVramParameter pAddress=0x4fbf7800 pFlipCBR=0
EC4A4> DisplayMgr:ff1395e0:82:01: SetImageVramParameter pAddress=0x4f3d7800 pFlipCBR=0
Checking against the EOSM log it confirmed that this bit of guesswork is valid:
platform/EOSM2.103/consts.h
// 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
Another related issue was finding the YUV422 HD Buffers:
platform/EOSM2.103/consts.h
// 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
Found this in the log:
FAF31> Evf:00039cdc:a9:01: [BUFF] RELEASEWRITING[YuvArray] (State[3] Addr[0x48000100][0])
FAF5B> Evf:00039fa8:a9:01: [BUFF] RELEASEREADING[YuvArray] (State[4] Addr[0x483cc100][1])
Turns out that this matches the 700D, ran a log on that camera too to verify this. Wait--it is
wrong on the EOSM, but what is this? Where is it used? Seems like it is only used in an obscure feature that is disabled on the EOSM (https://www.magiclantern.fm/forum/index.php?topic=9741.msg211033#msg211033) called PLAY_EXPOSURE_FUSION. Don't know what it does but I turned it on so testers can have something else to play with. Here's a description of what it does (https://wiki.magiclantern.fm/userguide#image_review_settings):
QuoteExposure Fusion: combine two or more images, useful for previewing HDR images or multiple exposures.
Sounds interesting -- but:
Quote from: Walter Schulz on January 26, 2019, 09:14:01 PM
422 options are gone, though.
Something learned, nothing fixed.
Maybe found something that is causing the LiveView freezes, though no solution yet.
The freezes only happens in photo mode when the raw histogram is active which means that the Canon setting also must be set for RAW and not JPEG. In movie mode it happens when in raw video mode, not in H.264. Ok--so that means that we're in this section of the code:
src/raw.c
#ifdef CONFIG_RAW_LIVEVIEW
...
#endif /* CONFIG_RAW_LIVEVIEW */
That's a pretty big section to look at but in there is some printf statements that are visible when you turn on the console (Debug -> Show console). One section in particular seemed interesting and I added a few more printf statements and compared it to the EOSM:
static void raw_lv_free_buffer()
{
printf("Freeing LV raw buffer %x.\n", raw_lv_buffer);
printf("raw_allocated_lv_buffer : %x.\n", raw_allocated_lv_buffer);
printf("raw_lv_buffer_size : %x.\n", raw_lv_buffer_size);
if(raw_allocated_lv_buffer) {
free(raw_allocated_lv_buffer);
raw_allocated_lv_buffer = 0;
So, this is what I get on the EOSM2:
(https://farm8.staticflickr.com/7889/46886720472_afa45df0e5.jpg) (https://flic.kr/p/2erdGuh)
For comparison, this is the EOSM:
(https://farm5.staticflickr.com/4847/46938923691_d1b27e7a9e.jpg) (https://flic.kr/p/2evQfFM)
My guess is that raw_lv_buffer is an address so we'd better not mess with that, raw_allocated_lv_buffer is a boolean which is set the same on both cameras and raw_lv_buffer_size is the actual size of the LiveView buffer. There's a huge difference in sizes between the two cameras. From what I can see, raw_lv_buffer_size is being assigned here:
#ifdef CONFIG_EOSM2
#define DEFAULT_RAW_BUFFER MEM(0x91CF0 + 0x78)
#define DEFAULT_RAW_BUFFER_SIZE (0x48CC0000 - 0x48798100) // exact value = 0x48CC40C4 https://www.magiclantern.fm/forum/index.php?topic=5601.msg197778#msg197778
#endif
...
raw_lv_buffer = (void *) DEFAULT_RAW_BUFFER;
raw_lv_buffer_size = DEFAULT_RAW_BUFFER_SIZE;
So yes, 0x48CC0000 - 0x48798100 = 0x527F00. That is tiny compared with the EOSM. But wait, the 100D also has 527F00 so that isn't the problem so let's look somewhere else.
src/raw.c
/* our default LiveView buffer (which can be DEFAULT_RAW_BUFFER or allocated) */
static void* raw_get_default_lv_buffer()
{
#if !defined(CONFIG_EDMAC_RAW_SLURP)
return CACHEABLE(shamem_read(RAW_LV_EDMAC));
#else
return CACHEABLE(raw_lv_buffer);
#endif
}
What if we add another printf statement:
printf("CACHEABLE(raw_lv_buffer) : %x.\n", CACHEABLE(raw_lv_buffer));
EOSM2
(https://farm5.staticflickr.com/4911/31998413887_7507008497.jpg) (https://flic.kr/p/QKAeDa)
EOSM
(https://farm8.staticflickr.com/7814/46887300842_92be5cde7a.jpg) (https://flic.kr/p/2ergF1E)
Is that a significant finding?
I could have saved some space on this post by writing down the results instead of posting screenshots but what's that going in the EOSM2 screenshots? Looks like some corruption. It doesn't look like that when looking at it, what it looks like is a frozen LiveView but maybe this is a clue to what is going on? IDK -- don't even have a clue where to look to next.
Noticed that there have been several downloads on the test builds I've been posting (https://bitbucket.org/daniel_fort/magic-lantern/downloads/). The first thing that will happen if you start in photo mode and have your Canon capture settings on RAW is that the LiveView screen will freeze. Switching to a non-LiveView screen like Play or Menu will free it up temporarily. If you turn off Global Draw it wont' freeze. The minimum needed is to change from raw to yuv histogram:
(https://farm8.staticflickr.com/7827/46940124501_57dae884fb.jpg) (https://flic.kr/p/2evWpDp)
Loading the silent or mlv_lite or mlv_rec modules and activating those modules will also freeze LiveView. Basically, anything that activates RAW_LIVEVIEW will freeze the screen.
Been working with the bleeding edge branch so much that it has now become the most stable for the EOSM2. Loaded up the dm-spy-experiments branch and it was a wild ride but was able to save a log that might show the LiveView freeze. For comparison, I went through the same steps and saved an EOSM log so we can have something that doesn't freeze for comparison:
EOSM2_lv_freeze_DM-0000.LOG (https://pastebin.com/Un9v3RbB)
EOSM_no_lv_freeze_DM-0000.LOG (https://pastebin.com/gUfjNMdR)
Maybe this is a clue?
EOSM2
5446A> Evf:00038564:a9:01: [VRAM] FrameParam[0x714160][0x4fbf7800][0x0][0x0]EOSM
E64C3> Evf:00024120:a9:01: [VRAM] FrameParam[0x75b5c4][0x4f1d7800][0xdfffffd7][0x0]Or maybe this?
EOSM2
54721> Evf:ff53fdd0:ad:01: [PATH] LVx1_60fps_StartYuvPath[483cc100,48000100]
54760> Evf:ff53fa30:ad:01: [PATH] LVx1_60fps_StartVramPath2[4fbf7800][0]EOSM
E66C4> Evf:ff50a394:ad:01: [PATH] RecStandby_x1_60fps_StartYuvPath[463cc080,46000080]
E6709> Evf:ff509fe0:ad:01: [PATH] RecStandby_x1_60fps_StartVramPath[4f1d7800][0][EDIT] Also got a couple of crash logs that might point to something.
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
...
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
PowerMgr stack: 2abfb0 [18b340-18af40]
0x0044C478 @ 44c4f4:2abfb0
Magic Lantern version : Nightly.2019Jan30.EOSM2103
Mercurial changeset : 447b1fb774c7 (EOSM2.103_dm-spy-experiments)
Built on 2019-01-30 15:08:00 UTC by [email protected].
Free Memory : 332K + 2110K
Very cool. How can we test vram and evf parameters?
I'm not really sure how to check vram and evf parameters but I just ran dm-spy-experiments on the 700D--putting the camera in photo mode and LiveView like the EOSM/M2.
700D
0638D> Evf:ff36d1ec:a9:01: [VRAM] FrameParam[0x750b8c][0x4bde7800][0x5459a600][0x0]
Looks to me like this might be a hint:
EOSM2
5446A> Evf:00038564:a9:01: [VRAM] FrameParam[0x714160][0x4fbf7800][0x0][0x0]
^^^ MISSING
The other part that stood out to me when comparing the M to the M2 now look perfectly fine:
700D
F64B6> Evf:ff500e28:ad:01: [PATH] LVx1_60fps_StartYuvPath[463cc080,46000080]
F64FF> Evf:ff500a64:ad:01: [PATH] LVx1_60fps_StartVramPath[4bde7800][0]
EOSM2
54721> Evf:ff53fdd0:ad:01: [PATH] LVx1_60fps_StartYuvPath[483cc100,48000100]
54760> Evf:ff53fa30:ad:01: [PATH] LVx1_60fps_StartVramPath2[4fbf7800][0]
Some of those addresses look familiar?
platform/700D.115/consts.h
#define YUV422_LV_BUFFER_1 0x4bde7800 <---- this one
#define YUV422_LV_BUFFER_2 0x4b9d7800
#define YUV422_LV_BUFFER_3 0x4c1f7800
...
#define YUV422_HD_BUFFER_1 0x463cc080 <---- and these two
#define YUV422_HD_BUFFER_2 0x46000080
platform/EOSM2.103/consts.h
#define YUV422_LV_BUFFER_1 0x4F3D7800
#define YUV422_LV_BUFFER_2 0x4F7E7800
#define YUV422_LV_BUFFER_3 0x4FBF7800 <---- this one
...
#define YUV422_HD_BUFFER_1 0x483cc100 <---- and these two
#define YUV422_HD_BUFFER_2 0x48000100
Maybe the order of the YUV422_LV_BUFFER's is important?
EOSM
#define YUV422_LV_BUFFER_1 0x4F1D7800 <---- log is showing this one
#define YUV422_LV_BUFFER_2 0x4F5E7800
#define YUV422_LV_BUFFER_3 0x4F9F7800
Changed the order on the EOSM2 and the screen still freezes so nope, that's not it.
EOSM2
#define YUV422_LV_BUFFER_1 0x4FBF7800 <---- made this one the first buffer like on the 700D
#define YUV422_LV_BUFFER_2 0x4F3D7800
#define YUV422_LV_BUFFER_3 0x4F7E7800
Quote from: dfort on February 02, 2019, 07:09:25 PM
700D
0638D> Evf:ff36d1ec:a9:01: [VRAM] FrameParam[0x750b8c][0x4bde7800][0x5459a600][0x0]
Looks to me like this might be a hint:
EOSM2
5446A> Evf:00038564:a9:01: [VRAM] FrameParam[0x714160][0x4fbf7800][0x0][0x0]
^^^ MISSING
This seems interesting don´t you think? Like needle in a haystack. Even worse i´d say. Probably would have found 10 needles by now. We need guidance 8)
Hm, double check stubs and constants for vram related regs?
Yes, that looks interesting but will it lead to resolving the freezing LiveView issue?
Another issue with this camera is finding the addresses needed for dual iso. That is also bringing up another issue that the addresses should not be hardcoded, but how to find them dynamically?
Quote from: a1ex on January 27, 2019, 04:18:23 PM
The solution is to avoid making assumptions about the addresses of these registers, i.e. to get rid of these hardcoded addresses. See reply #2968 (https://www.magiclantern.fm/forum/index.php?topic=7139.msg197612#msg197612) and this topic (https://www.magiclantern.fm/forum/index.php?topic=23086). I find it hard to believe there are only 2 possible values on a given camera model. FRAME_SHUTTER_BLANKING constants should be probably handled in the same way (i.e. hardcoded addresses should be deleted).
The CMOS data is in the middle of Canon's property data structure, so playing around with prop_diag, or with Canon's property functions in QEMU, might reveal something. One possible step is identifying these properties (for example, by parsing a RAM dump around the known addresses with prop_diag).
I got prop_diag working as a stand alone app and was able to parse ROM1.BIN but am stuck trying to figure out how to parse the RAM4.BIN, especially, "...around the known address..." As Sergeant Schultz would say, "I know nothing!"
Loading ROM1.BIN...
Scanning from 0x102c4f000 to 0x103c4f000...
Trying offset 0x60000, status=0xffff, size=0xd2c...
Prop c000004 4 01003110
Prop c000002 3316 00641031 00000CF2 00000030 00010001 00000000*8 00011031 ...
Trying offset 0x80000, status=0x0, size=0x1084...
Skipping inactive block 0x80000, status=0x0, size=0x1084...
Trying offset 0x82000, status=0x0, size=0x1084...
Skipping inactive block 0x82000, status=0x0, size=0x1084...
Trying offset 0x84000, status=0x0, size=0x1084...
Skipping inactive block 0x84000, status=0x0, size=0x1084...
Trying offset 0x86000, status=0x0, size=0x1084...
Skipping inactive block 0x86000, status=0x0, size=0x1084...
Trying offset 0x88000, status=0x0, size=0x1084...
Skipping inactive block 0x88000, status=0x0, size=0x1084...
Trying offset 0x8a000, status=0x0, size=0x1084...
Skipping inactive block 0x8a000, status=0x0, size=0x1084...
Trying offset 0x8c000, status=0x0, size=0x1084...
Skipping inactive block 0x8c000, status=0x0, size=0x1084...
Trying offset 0x8e000, status=0x0, size=0x1084...
Skipping inactive block 0x8e000, status=0x0, size=0x1084...
Trying offset 0x90000, status=0x0, size=0x1084...
Skipping inactive block 0x90000, status=0x0, size=0x1084...
Trying offset 0x92000, status=0x0, size=0x1084...
Skipping inactive block 0x92000, status=0x0, size=0x1084...
Trying offset 0x94000, status=0x0, size=0x1084...
Skipping inactive block 0x94000, status=0x0, size=0x1084...
Trying offset 0x96000, status=0x0, size=0x1084...
Skipping inactive block 0x96000, status=0x0, size=0x1084...
Trying offset 0x98000, status=0x0, size=0x1084...
Skipping inactive block 0x98000, status=0x0, size=0x1084...
Trying offset 0x9a000, status=0x0, size=0x1084...
Skipping inactive block 0x9a000, status=0x0, size=0x1084...
Trying offset 0x9c000, status=0x0, size=0x1084...
Skipping inactive block 0x9c000, status=0x0, size=0x1084...
Trying offset 0x9e000, status=0x0, size=0x1084...
Skipping inactive block 0x9e000, status=0x0, size=0x1084...
Trying offset 0xa0000, status=0x0, size=0x1084...
Skipping inactive block 0xa0000, status=0x0, size=0x1084...
Trying offset 0xa2000, status=0x0, size=0x1084...
Skipping inactive block 0xa2000, status=0x0, size=0x1084...
Trying offset 0xa4000, status=0x0, size=0x1084...
Skipping inactive block 0xa4000, status=0x0, size=0x1084...
Trying offset 0xa6000, status=0x0, size=0x1084...
Skipping inactive block 0xa6000, status=0x0, size=0x1084...
Trying offset 0xa8000, status=0x0, size=0x1084...
Skipping inactive block 0xa8000, status=0x0, size=0x1084...
Trying offset 0xaa000, status=0x0, size=0x1084...
Skipping inactive block 0xaa000, status=0x0, size=0x1084...
Trying offset 0xac000, status=0x0, size=0x1084...
Skipping inactive block 0xac000, status=0x0, size=0x1084...
Trying offset 0xae000, status=0x0, size=0x1084...
Skipping inactive block 0xae000, status=0x0, size=0x1084...
Trying offset 0xb0000, status=0xffff, size=0x1084...
Prop 2000000 4 0000FFFF
Prop 2000001 36 "1.0.3" 00 "7A(2b)" 00629F00 0000000C 004DAB00 19980218 ...
Prop 2000005 36 "6.0.6 7A(2b)" 00629F00 0000000C 004DAB00 19980218 ...
Prop 2000002 4 00000013
Prop 2000003 4 FFFFFFFF
Prop 2000004 32
Prop 2000006 16 00060006 7A00002B 08000000 00303030
Prop 2000007 36 "0.0.0"
Prop 2000008 4
Prop 2010000 4 0000008E
Prop 2010001 4 00000064
Prop 2010002 4 00000064
Prop 2010003 4
Prop 2010004 4 00000602
Prop 2010005 4
Prop 2010009 4
Prop 201000a 4 000764D1
Prop 201000b 4
Prop 2010006 4
Prop 2010007 4 00008000
Prop 2010008 4
Prop 201000d 4
Prop 201000e 4
Prop 201000f 4
Prop 2010010 4 00000064
Prop 2010011 4 00000065
Prop 2010012 4 00000064
Prop 2010013 4 00010000
Prop 2010014 4
Prop 2020000 44 00000000*8 040001FD 028B0400
Prop 2020008 44 00000000*8 040001FD 028B0400
Prop 2020009 44 00000000*8 040001FD 028B0400
Prop 202000a 44 00000000*8 040001FD 028B0400
Prop 202000b 44 00000000*8 040001FD 028B0400
Prop 2020005 4 00000001
Prop 2020006 4 00000002
Prop 2020001 4 00000008
Prop 2020002 4 00000008
Prop 2020003 4 00000008
Prop 2020004 4 00000008
Prop 202000c 4
Prop 202000d 40 00000000*8 04000400*2
Prop 202000e 40 00000000*8 04000400*2
Prop 202000f 40 00000000*8 04000400*2
Prop 2020010 40 00000000*8 04000400*2
Prop 2020011 40 00000000*8 04000400*2
Prop 2030000 28 51010000 52000000 57010000 54010000 55010000 50000000 ...
Prop 2030001 12 00000001
Prop 2030002 36 00000302 01008100 01000100 00000002 000100FF 00010001 ...
Prop 2030004 4
Prop 2030005 4
Prop 2030003 4
Prop 2030006 12 00000001
Prop 2040000 4 00000004
Prop 2040001 4 00000001
Prop 2040002 4
Prop 2040003 4
Prop 2040004 4
Prop 2040005 4 00000001
Prop 2040007 4 00000001
Prop 2040008 4 00000602
Prop 2040009 4 00000001
Prop 204000a 4 00000001
Prop 204000b 4
Prop 204000c 4 00000001
Prop 204000d 4
Prop 204000f 76
Prop 2050000 184 0000000F 00000000*2 00000009 00000000*14 00000009 ...
Prop 2050001 4 00004185
Prop 2050002 4 00000003
Prop 2050004 8 "IMG_" 00033200
Prop 2050005 4
Prop 2050003 4
Prop 2050006 4
Prop 2050007 4
Prop 2050008 4
Prop 2050009 8 00474D49 00033200
Prop 205000a 4
Prop 205000b 8 00000A7C 00000701
Prop 205000d 4
Prop 205000e 4 00000002
Prop 205000f 4 00000005
Prop 2050013 4
Prop 2050014 4
Prop 2050016 4
Prop 2050017 4 002F002F
Prop 2050018 48 00000010
Prop 2050019 8
Prop 205001a 4
Prop 205001c 4
Prop 205001f 4 0000001E
Prop 2050020 4
Prop 2050011 4
Prop 2050021 4
Prop 2050023 4
Prop 2050024 4 00000001
Prop 2050025 4
Prop 2050022 4 00000004
Prop 205001b 4 00000001
Prop 205001d 48 00000000*3 0000001E 0000000F 00000000 00000001 00000000*2 ...
Prop 2050026 4 0000001F
Prop 2050027 4 00000001
Prop 2050028 4
Prop 2050029 4
Prop 205001e 4
Prop 205002a 4
Prop 205002b 4 00000002
Prop 205002d 4
Prop 205002e 16 00000A7C 00000701 00000A7C 00000701
Prop 205002f 4 00000002
Prop 2050034 8 00000000 0000000F
Prop 205003a 4
Prop 205003b 4
Prop 2050037 4 00000001
Prop 2050036 4
Prop 2060000 4 00000001
Prop 2060001 24 00000000 00000003 00000000*2 DEADBEEF*2
Prop 2060002 24 00000000 00000002 00000000*2 DEADBEEF*2
Prop 2060003 24 00000000 00000004 00000000*2 DEADBEEF*2
Prop 2060004 24 00000000*4 DEADBEEF*2
Prop 2060005 24 00000000*4 DEADBEEF*2
Prop 2060006 24 00000000 00000003 DEADBEEF*2
Prop 2060007 24 00000000 00000003
Prop 2060008 24 00000000 00000003
Prop 2060009 24 00000000 00000003
Prop 206000a 4 00000087
Prop 206000b 4 00000087
Prop 206000c 4 00000087
Prop 206000d 24 00000000 00000003 00000000*2 DEADBEEF*2
Prop 206000e 24 00000000 00000002 00000000*2 DEADBEEF*2
Prop 206000f 24 00000000 00000004 00000000*2 DEADBEEF*2
Prop 2060010 24 00000000*4 DEADBEEF*2
Prop 2060011 24 00000000*4 DEADBEEF*2
Prop 2060012 24 00000000 00000003 DEADBEEF*2
Prop 2060013 24 00000000 00000003
Prop 2060014 24 00000000 00000003
Prop 2060015 24 00000000 00000003
Prop 2060016 4 00000081
Prop 2060017 4 00000081
Prop 2060018 4 00000081
Prop 2060019 24 00000000 00000003 00000000*2 DEADBEEF*2
Prop 206001a 24 00000000 00000002 00000000*2 DEADBEEF*2
Prop 206001b 24 00000000 00000004 00000000*2 DEADBEEF*2
Prop 206001c 24 00000000 00000003 DEADBEEF*2
Prop 206001e 24 00000000 00000003 00000000*2 DEADBEEF*2
Prop 2060021 300 63422100 DFBFA182 3F1F00FF BF9F7F5F 2300FFDF A2856746 ...
Prop 2060020 24 00000000 00000003 00000000*2 DEADBEEF*2
Prop 206001f 24 00000000 00000003 00000000*2 DEADBEEF*2
Prop 2060022 52 00000000 00000087 00000000 00000003
Prop 2060023 52 00000000 00000087 00000000 00000003
Prop 2060024 4 0000000D
Prop 2060025 24 FFFFFFFD 00000004 FFFFFFFD*2
Prop 2070000 4
Prop 2070001 4 00000001
Prop 2070002 8 5C4E33F9 00000004
Prop 2070004 16 0000002F
Prop 2070005 4
Prop 2070006 4 00000007
Prop 2070003 4
Prop 2070007 4 FFFFFFFF
Prop 2070008 4 FFFFFFFF
Prop 2070009 4
Prop 207000a 4
Prop 2070012 4
Prop 2070013 44 00000000*4 00000001 00000000 000007D0 00000006
Prop 2070014 4
Prop 2070015 4
Prop 2070016 48 00000000*4 FFFFFFFF 00000000 00000006
Prop 2070017 4
Prop 2070018 4
Prop 2080000 4 10000000
Prop 2080001 4 20000000
Prop 2090000 4 00000001
Prop 2090001 4
Prop 2090002 4
Prop 2090003 4
Trying offset 0xf00000, status=0xffff, size=0x1aedc...
Prop b000000 110256 001A0F3C 00800030 00000000*2 03400020 00E00010 00000640 ...
Trying offset 0xf60000, status=0x0, size=0x173b8...
Skipping inactive block 0xf60000, status=0x0, size=0x173b8...
Trying offset 0xf80000, status=0xffff, size=0x173b8...
Prop 5010000 28 0000001C 00000000*3 00000001*2 00000002
Prop 5010001 544 00000000 0000006C 00000001 0201A8C0 00FFFFFF 00000000*23 ...
Prop 5010002 2204 00000000 000001B8 1401A8C0 "192.168.1.20" 00000000*6 ...
Prop 5010003 1264 00000000 000000FC 00000002*2 "Wft-canon" 00 00 00 ...
Prop 5010004 64 00000000 0000000C 00000000*2 0000000C 00000000*2 ...
Prop 5010005 44 00000000 00000008 00000001 00000008 00000001 00000008 ...
Prop 5010006 784 00000000 0000009C 00000000*17 00000001 00000000*20 ...
Prop 5010007 28 0000001C 00000000*2 00000001 00000002*2
Prop 5010008 24
Prop 5010009 84
Prop 501000a 504 00000000 00000064 00000000*24 00000064 00000000*24 ...
Prop 501000b 224 000000E0 00000000*54 00000050
Prop 501000c 4 00000001
Prop 501000d 288 00000124 00000000*70 FFFFFFFF
Prop 501000e 448 00000000 FFFFFFFF 00000000 FFFFFFFF*2 00000000*10 ...
Prop 4000000 40 00000000*8 04000400*2
Prop 4000001 40 00000000*8 04000400*2
Prop 4000002 40 00000000*8 04000400*2
Prop 4000003 40 00000000*8 04000400*2
Prop 4000004 40 00000000*8 04000400*2
Prop 4010000 4
Prop 4010001 16704
Prop 4010002 4
Prop 4010003 16704
Prop 4010004 4
Prop 4010005 16704
Prop 4020000 12400
Prop e000001 2048 FFFFF000*284 52BCA004 FFFFF000*227
Prop e000002 3072 FFFFF000*32 D480F000 FFFFF000*243 0E84F000 FFFFF000*246 ...
Prop e000003 1024 FFFFF000*255
Prop e000004 6252 00000000 0000003C 00000078 000000B4 000000F0 0000012C ...
Prop e020001 56 00000010 00000001*2 00000000 00000002 00000004 00000003 ...
Prop e020002 484 00000000 00000030 00000000*7 00000031 00000000*7 ...
Prop e020004 244
Prop e030000 1024 00000001
Prop e040000 4
Prop e060000 8 "0000"
Prop e060001 4
Prop e060002 8 "0000"
Prop e060003 8 "0000"
Prop 2090000 4 00000001
Prop e070000 64
Prop e070001 64
Prop e080001 20 "mog-M2"
Prop 80040055 20 00000000*4 FFFFFFFF
Prop e080003 2544 00000001 0000001C 00000000*2 00000001 00000002*2 ...
Prop e080004 1496 00000001 00000000*2 FFFFFFFF*2 00000000*10 FFFFFFFF*2 ...
Prop e080005 1568 00000000*3 00000006 00000002 "mog-M2" 00 6F 0000006E ...
Prop e080006 1196 00000000*3 FFFFFFFF*2 00000000*10 FFFFFFFF*2 00000000 ...
Prop e080007 1384 00000000*2 FFFFFFFF*2 00000000*10 FFFFFFFF*2 00000000 ...
Prop e080008 1192 00000000*2 FFFFFFFF*2 00000000*10 FFFFFFFF*2 00000000 ...
Prop e080009 1516 00000000*2 FFFFFFFF*2 00000000*10 FFFFFFFF*2 00000000 ...
- Camera model: ???
- Firmware version: 1.0.3 / 6.0.6 7A(2b)
- IMG naming: 100?????/IMG_1538.JPG
I take it this isn't Canon proprietary code because it has a lot of DEADBEEF (https://en.wikipedia.org/wiki/Hexspeak) in it.
Indeed interesting needles... closer to 10, if not more. HA. DEADBEEF it is. Needless to say... thanks for the reminder (even tho I had missed it Happy Belated Bday @dfort) would you still need me to try and get on the ISO-research tasks for this cam similar to how I did with this (https://www.magiclantern.fm/forum/index.php?topic=16040.msg191131#msg191131) to help push this forward?
Thanks for the Bday wishes DeafEyeJedi!
Please feel free to run whatever tests your heart desires. I've been publishing test builds (https://bitbucket.org/daniel_fort/magic-lantern/downloads/) and pushing commits (https://bitbucket.org/daniel_fort/magic-lantern/commits/all) in the hopes that more users and developers will get involved in helping to bring this little gem into the mainline.
QuoteI got prop_diag working as a stand alone app and was able to parse ROM1.BIN but am stuck trying to figure out how to parse the RAM4.BIN, especially, "...around the known address..." As Sergeant Schultz would say, "I know nothing!"
Starting from https://www.magiclantern.fm/forum/index.php?topic=12177.msg117735#msg117735 (https://www.magiclantern.fm/forum/index.php?topic=12177.msg117735#msg117735) I tried to unblock RAM4.BIN. The problem is I do not know what offset to use.
I tried with 0xF0000000 and with 0xE0000000. The RAM4.BIN.strings file resulted. No matter what offset I've tried, the files are the same. Still running disassemble.pl, so I still do not have a result. I will return with a result when it is ready.
[Edit]
Maybe I got the offset wrong. Looking in the source, I found that RAM4 is saved with offset 0x10000000. So I run the script with offset 0x10000000. Let's see what's coming out.
@critix - Are you using prop_diag from the recovery branch? It is quite easy to build. The documentation explains how to enter the offsets but I'm not sure what offset to use.
src/prop_diag.c
/**
* Property parsing code inspired from g3gg0's Property Editor and Indy's parse_prop.py,
* but rewritten from scratch :)
*
* This tool can also be built as a standalone program, from the "src" directory:
* gcc prop_diag.c -o prop_diag
* or:
* make prop_diag
*
* Python version available on request.
*
* Data structure: in ROM, properties are organized in blocks, sub-blocks and sub-sub-blocks.
*
* Each nesting level uses the same structure:
* [status_1 size_1 data_1 status_2 size_2 data_2 ... status_n size_n data_n terminator]
*
* - "size" covers the size of "status", "size" and "data" fields, so "data" has size-8 bytes
* - "data" is either an array of sub-blocks [subblock_1 subblock_2 ... subblock_n terminator]
* or the property data itself.
* - "status", "size" and "terminator" are 32-bit integers each.
*
* Consistency check: sum of size_i == buffer_len - 4.
* There are 4 nesting levels: let's call them "class", "group", "subgroup" and "property".
*
* There are multiple copies of various setting blocks, and only one of them is marked
* as "active" (status = 0xFFFF); this is probably (just a guess) used for wear leveling
* and maybe also to save a "last known good" configuration (or that's just a side effect).
*
* New models may have different header structure for the main blocks;
* in particular, status and size are no longer the first items.
*/
No, I use:
/disassemble.pl 0x1000000 RAM4.BIN
[Edit]
If you use prop_diag with the camera, then in prop_diag you have to put the offset. If you use offline, then you do not need offset.
That's why I'm trying with that script.
Found something interesting. Going back to something Danne commented on in Reply #426 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg210018#msg210018) - the LiveView freezing in Photo mode doesn't happen when FPS override is set like this:
(https://farm5.staticflickr.com/4902/32036525547_508fde92bc.jpg) (https://flic.kr/p/QNXyUK)
There are probably other settings that work but this is something that users can experiment with using a test build from my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).
Ok--so why would you use FPS override (https://wiki.magiclantern.fm/userguide#fps_override) while in Photo mode?
QuoteTip: this feature also works in photo mode, making LiveView usable in dark environments. Combine it with display gain (https://wiki.magiclantern.fm/userguide#display-gain).
So is there anything here we can use to resolve the raw LiveView freezing issue?
My post is not about the bits and bytes behind but my experience with ML on the M2 as a user. First of all, thanks so much for your work! Maybe what I've found can help you devs flush something out?
I've been testing mostly in RAW trying to use settings that seem to work for others on the M. The quirks I've noticed that might be meaningful relate to dfort's discovery of the FPS timer setting. I don't know how that was discovered but I've noticed in testing that if I do not configure the FPS timer A to 588 then I get a black band on the right side of video with my RAW settings. The band seems to vary in width depending on the frame rate I use although it is constant during any given recording.
My settings for this were as follows:
Modules loaded: mlv_lite, mlv_play, mlv_snd, sd_uhs, lua.
I then enable my M2 with "RAW video" and "FPS override". FPS override is set at 23.976 exact. RAW is set to a resolution of 1736x474 with a 1.61 crop, 14 bit lossless. I then do the 2.5k trick of going back to Canon's LiveView (LV) interface and zoom in to 5x. LV unfreezes (previously frozen) and I can view and record live motion. I go back to the ML menu and set RAW to record at 1972x872 with a 1:2 crop. This seems to work for me and I get usable footage. Looks great (MLV App with Chroma Smooth 3x3 to eliminate Focus Pixels)! However, on the right side is the banding I mentioned:
(https://i.ibb.co/MBVbyCR/black-band-m2.png) (https://ibb.co/MBVbyCR)
UNLESS:
I go back into the Canon LV mode and disable the 5x zoom then go into the FPS override and set the FPS timer A to the 588 mentioned. I have not tried other values to see if bands appear elsewhere if I go higher or lower. If I go back into the Canon LV and enable 5x zoom then my recordings no longer have the black band on the right. I've tried it with other resolutions and also with 24fps exact and the black band on the right is gone. I did notice that it seems to be precise amount above 588 and not 588 itself since the timer changes depending on frame rate and zoom ratio but stays a constant +64 above. 64 sounds like an address shift of some kind.
Another thing I've noticed is that the 5x zoom does not center the image. At least on mine it doesn't. Whatever I see on in LV is of course smaller than what I record but the resulting footage shows that the LV zoom, while centered on the screen (meaning the little positioning square is smack dab in the middle of its container), is off to the left of what it's recording. So much so that it looks like there's nothing recorded to the left of what I shot and double that to the right. Like this [x ] where "x" is what I saw on LV and [] represent frame bounds. I would have expected [ x ].
(https://i.ibb.co/nR4sJWt/left-crop-m2.png) (https://ibb.co/nR4sJWt)
The green dotted line is what I see in LV.
Maybe that's no help at all or maybe you've encountered similar or already know this. I'm happy to test anything you'd like but will need guidance if you want log files. Trying to go through the setup on my Mac for dev work but my machine is a Jenga tower of developer tools and something's not playing right and silently failing so I'll have to figure that one out before whatever the next step will be.
Funny how the M2 can do close to 4k raw video but can't save a still photo with ML loaded.
What I've been doing is to keep merging Danne's EOSM branch into my bleeding edge EOSM2 branch and posting test builds. It has been getting several downloads. Good to finally get some feedback.
The black bars and FPS override are settings that can probably be tweaked. Danne knows more about what to adjust than I do -- by the way he also has an M2.
As far as the focus pixels, I have added map files for the EOSM2. They are mostly theoretical but since most of the map files are the same between the various cameras I'm pretty sure they should work. You can download them from my ML Focus Pixels (https://bitbucket.org/daniel_fort/ml-focus-pixels) repository. Look in the focus_pixel_map_files directory, the M2 files start with 80000355. Put them next to the executable file in either MLVFS or MLV App. Check out the last several posts on the Dealing with Focus Pixels in raw video (https://www.magiclantern.fm/forum/index.php?topic=16054.new#new) topic for more information.
I have the development environment configured on my machine now, am able to build but it looks like I have several tutorials to run though to get me up to speed with the typical workflow of ML development. Currently my QEMU displays a blank black screen past the date/time screen although I can see the console recording keypresses. Might have to do with my Mac or version conflicts or a myriad of other possible incompatibilities.
However, I'm not sure if QEMU is even used at this stage of development. Are you building and testing directly on the M2?
Until I'm up to speed I can only report what I'm finding as a user attempting RAW video. I'm able to record 1800x1012 in 3x crop mode in 16:9 and all the way up to the 2.5k in 5x crop mode but the 2.5k has a significant number of purple frames and is unusable. I use a 64GB SanDisk Extreme Pro with the sd hack in both cases. If I lower the resolution to 1920x872 in 5x crop (I believe it's 1:2.35) then I can record continuously. I can do these in 14bit lossless. If I use 12bit lossless then every other frame is frozen (as in either black or a repeat of the very first frame of video).
The 1800x1012 in 3x crop mode is very finicky. If I start recording immediately after the sd_uhs script completes its autorun then I have been able to record continuously without issue. However, if I wait to record for some undetermined amount of time live view freezes up. The only way I can unfreeze live view is to toggle through the 4 view modes with the Info button. There are 2 Canon GUI modes, the ML GUI then the pure settings GUI mode. I have to cycle through the settings GUI mode back to the first Canon mode and then I'll see an unfrozen live view again. However, if I don't start recording immediately it will freeze again and I have to cycle through the screens to get it back. I can play this game only two times, unfortunately. The third time all of the view modes are a blank black screen.
I've tried flipping to camera mode and back to video but once I see a blank black live view mode I have to restart the camera for video work. Fortunately I can play this game all over again after rebooting.
If there are particular files with configurations that are tedious to build and test I'm happy to build and grunt test them locally but would need to know the files and rough plan. Otherwise it will be a while before I can contribute to the freezing issue.
I know you mentioned M2 development is stalled due to some issues not replicable in QEMU so I'd like to see about getting some grease on my hands. I'm a developer but just a young Padawan in this realm. I've been reading through the developer guides and have tried to repeat the porting process in this tread but...why reinvent the wheel? Plus it's taken nearly two years of your effort to get this far and I'm missing things not found in the thread partly due to my environment being different.
For instance, I'm using Ubuntu 16LTS on a VirtualBox machine because my Mac is heavily configured for other development work and I don't want to accidentally break it for my paying work. I did get QEMU up and running on the Mac but got endless logs and a blank gray UI with a red dot in the lower right then it would crash. Actually took my Mac with it which I rarely ever see. I decided on some separation.
Following the guide here https://www.magiclantern.fm/forum/index.php?topic=991.0 (https://www.magiclantern.fm/forum/index.php?topic=991.0) for installing magiclantern I have a sandboxed environment to play in. Seems to work just fine. However, I see no EOSM2 in the platform directory. So I tried merging in your branch (hg merge crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort) but that fails with an "unknown revision" error.
I tried from scratch using your version of the bleeding edge branch (hg clone https://bitbucket.org/daniel_fort/magic-lantern/branch/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort).
Renaming the resulting directory "magic-lantern" lets me complete the qemu setup process. However, if I update QEMU (hg up qemu -C) I again have no EOSM2 directory. If I don't update qemu and instead update the tip (hg update tip) then I get your EOSM2 directory in the platform folder.
I then create the gcc-arm path (PATH="$HOME/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH") in .bashrc since it wouldn't work in .profile. After this I'm able to run the install.sh for qemu (the one in your branch) without a problem.
I then make magic-lantern in the ml EOSM2 directory (make clean && make install_qemu).
This updates the sd.img in the new qemu-eos directory (same level as magic-lantern directory). Seems like I'm good to go.
However, running QEMU with ./run_canon_fw.sh EOSM2 results in errors concerning the format of long unsigned int values. I've tried commenting out the code it references since they're just status updates but the more I comment, the more keep coming and I doubt this is how you're building it.
So I start over and build qemu exactly according to the instructions in the link above. Then I clone your branch as before, build the EOSM2 with make clean && make install_qemu and everything seems peachy keen. I copy my ROMs (ROM0, ROM1, SFDATA) into qemu's EOSM2 directory and again try ./run_canon_fw.sh EOSM2 but get the same gray screen I got on my Mac and it kills the virtual machine with the same endless loop of "WARN [I2C] localI2C_Write : 317 (Task : Startup)". It also spits out "[AUDIO] ERROR I2C abort 0(1020000)" repeatedly. If I kill the qemu window quickly enough then I can regain control.
I've tried various .run... commands but everything results in an endless loop or runs to a crash or runs to a lockup. I'm unable to get anything in QEMU. Since I only have the EOS M2 I can't test with any other build just to see what I'm doing wrong (no ROM files for anything else). I did order an M for comparison but it's not arrived yet.
So, I'd like to get up and running with testing in QEMU but I think I might be acting above my pay grade. I'm happy to take advice.
In the meantime I keep testing with your releases. As I understand it they are just updated syncs with the bleeding edge EOS M branch and have nothing to do with getting the M2 past its live view freezing issues. Is that a fair read?
@liquidether - Wow, best news for the EOSM2 in a long time.
Sorry I missed your March 13 post, got hit with other things to do--like being the President of the HOA, shooting a no-budget feature film, preparing for my tax appointment, making through my wife's honey do list, you get the picture. I'm also the least qualified of the ML users with "Developer" status. When I started porting the M2 I thought it would be a nice little introduction to a fairly easy camera to get ML working. Ha!
Back on topic. I'm also having problems getting the M2 working in QEMU. It should work and it used to work in past for me. Note that the current qemu branch is set up to work with the M2, though it is missing from the "platform" directory. I'll PM you with something that you can use to check your QEMU setup.
In the meantime I've been doing most of my testing on the camera. If you clone or fork my repository (https://bitbucket.org/daniel_fort/magic-lantern) you'll see lots of experimental EOSM2 branches. I've got to update some of these, like the lua_fix branch that is finally working on the EOSM and might help with the M2.
It looks like you've got the M2 working about as well as anyone. That "bleeding edge" build I keep posting is just keeping up with Danne's latest EOSM changes. It happens to be the most stable build at this time though I don't quite understand why that's so.
As EOSM2 Magic Lantern users (and abusers) know, I've been merging in Danne's EOSM experiments to my almost but not quite yet working EOSM2 bleeding edge branch and posting test builds. Today I merged in the latest lua_fix changes and tried running the Script API Tests. It turned up a problem in the menu test when trying to change the FPS override. Tried changing it manually and there does seem to be something weird going on.
Testing ML menu API...
ML/SCRIPTS/API_TEST.LUA:411: assertion failed!
stack traceback:
[C]: in function 'assert'
ML/SCRIPTS/API_TEST.LUA:411: in function 'test_menu'
ML/SCRIPTS/API_TEST.LUA:1573: in function <ML/SCRIPTS/API_TEST.LUA:1564>
[C]: in function 'xpcall'
ML/SCRIPTS/API_TEST.LUA:1564: in function 'api_tests'
ML/SCRIPTS/API_TEST.LUA:1603: in main chunk
I commented out test_menu() and got an error on the test_camera_take_pics(). This was a strange one because it asked to switch to M mode when the camera was already in manual mode.
Testing picture taking functions...
Please switch to M mode.
Snap simulation test...
Single picture...
ML/SCRIPTS/API_TEST.LUA:1029: attempt to call a nil value (method 'image_path')
stack traceback:
ML/SCRIPTS/API_TEST.LUA:1029: in function 'test_camera_take_pics'
ML/SCRIPTS/API_TEST.LUA:1574: in function <ML/SCRIPTS/API_TEST.LUA:1564>
[C]: in function 'xpcall'
ML/SCRIPTS/API_TEST.LUA:1564: in function 'api_tests'
ML/SCRIPTS/API_TEST.LUA:1603: in main chunk
Next issue, test_lv():
Testing module 'lv'...
LiveView is running; stopping...
ML/SCRIPTS/API_TEST.LUA:1240: assertion failed!
stack traceback:
[C]: in function 'globals.assert'
ML/SCRIPTS/API_TEST.LUA:1240: in function 'globals.test_lv'
ML/SCRIPTS/API_TEST.LUA:1578: in function <ML/SCRIPTS/API_TEST.LUA:1564>
[C]: in function 'globals.xpcall'
ML/SCRIPTS/API_TEST.LUA:1564: in function 'globals.api_tests'
ML/SCRIPTS/API_TEST.LUA:1603: in main chunk
So much for the tests that aren't working. Here is what is working:
===============================================================================
ML/SCRIPTS/API_TEST.LUA - 2019-3-23 12:38:09
===============================================================================
Strict mode tests...
Strict mode tests passed.
Generic tests...
arg = table:
[0] = "API_TEST.LUA"
camera = table:
shutter = table:
raw = 101
apex = 5.625
ms = 20
value = 0.020263
aperture = table:
raw = 48
apex = 5.
value = 5.6
min = table:
raw = 37
apex = 3.625
value = 3.5
max = table:
raw = 80
apex = 9.
value = 22.6
iso = table:
raw = 104
apex = 9.
value = 1600
ec = table:
raw = 0
value = 0
flash = "auto"
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 = 196
gui = table:
menu = false
play = false
play_photo = false
play_movie = false
qr = false
idle = true
burst = function: p
reboot = function: p
shoot = function: p
wait = function: p
bulb = 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
write = function: p
clear = function: p
show = function: p
lv = table:
enabled = true
paused = false
running = true
zoom = 1
overlays = 2
info = function: p
wait = function: p
pause = function: p
resume = function: p
start = function: p
stop = function: p
lens = table:
name = "EF28-105mm f/3.5-4.5 USM"
focal_length = 28
focus_distance = 3900
hyperfocal = 7424
dof_near = 2582
dof_far = 8093
af = true
af_mode = 0
autofocus = function: p
focus = function: p
display = table:
idle = nil
height = 480
width = 720
notify_box = function: p
on = function: p
off = function: p
draw = function: p
load = function: p
line = function: p
clear = function: p
circle = function: p
pixel = function: p
rect = function: p
screenshot = function: p
print = function: p
key = table:
last = 9
press = function: p
wait = function: p
menu = table:
visible = false
open = function: p
new = function: p
get = function: p
select = function: p
close = function: p
block = function: p
set = function: p
movie = table:
recording = false
start = function: p
stop = function: p
dryos = table:
clock = 13
ms_clock = 13556
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 = 1560
folder_number = 100
free_space = 31112320
type = "SD"
path = "B:/"
_card_ptr = userdata
shooting_card = table:
cluster_size = 32768
drive_letter = "B"
file_number = 1560
folder_number = 100
free_space = 31112320
type = "SD"
path = "B:/"
_card_ptr = userdata
date = table:
year = 2019
isdst = false
day = 23
yday = 82
wday = 7
min = 38
sec = 11
month = 3
hour = 12
directory = function: p
rename = function: p
remove = 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: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:1568: in function <ML/SCRIPTS/API_TEST.LUA:1564>
[C]: in function 'globals.xpcall'
ML/SCRIPTS/API_TEST.LUA:1564: in function 'globals.api_tests'
ML/SCRIPTS/API_TEST.LUA:1603: 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...
Enter MENU mode...
Enter PLAY mode...
Enter PLAY mode...
Enter MENU mode...
Enter MENU mode...
Enter PLAY mode...
Exit PLAY mode...
Enter MENU mode...
Exit MENU mode...
Pause LiveView...
Enter MENU mode...
Enter MENU mode...
Enter MENU mode...
Enter MENU mode...
Exit MENU mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Exit PLAY mode...
Enter PLAY mode...
Enter MENU mode...
Enter MENU mode...
Enter MENU mode...
Enter PLAY mode...
Enter MENU mode...
Exit MENU mode...
Enter PLAY mode...
Enter PLAY mode...
Enter MENU mode...
Exit MENU mode...
Pause LiveView...
Resume LiveView...
Stop LiveView...
Enter PLAY mode...
Exit PLAY mode...
Stop LiveView...
Enter PLAY mode...
Enter PLAY mode...
Enter MENU mode...
Exit MENU mode...
Stop LiveView...
Start LiveView...
Pause LiveView...
Resume LiveView...
Enter PLAY mode...
Exit PLAY mode...
Pause LiveView...
Enter MENU mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Exit PLAY mode...
Pause LiveView...
Enter MENU mode...
Enter MENU mode...
Enter MENU mode...
Enter MENU mode...
Enter MENU mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter PLAY mode...
Enter MENU mode...
Exit MENU mode...
Pause LiveView...
Resume LiveView...
Enter PLAY mode...
Exit PLAY mode...
Pause LiveView...
Resume LiveView...
Enter PLAY mode...
Exit PLAY mode...
Pause LiveView...
Resume LiveView...
Canon GUI tests completed.
Testing multitasking...
Only one task allowed to interrupt...
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Multitasking tests completed.
Testing half-shutter...
Half-shutter test OK.
Testing lens focus functionality...
Focus distance: 3900
Autofocus in LiveView...
Please trigger autofocus (half-shutter / AF-ON / * ).
59...Autofocus triggered.
Autofocus completed.
Focus distance: 6820
Focusing backward...
Focus distance: 655350
Focus motor position: 10533
Focusing forward with step size 3, wait=true...
........
Focus distance: 470
Focus motor position: 293
Focusing backward with step size 3, wait=true...
....
Focus distance: 655350
Focus motor position: 10533
Focus range: 8 steps forward, 4 steps backward.
Motor steps: 10240 forward, 10240 backward, 0 lost.
Focusing forward with step size 3, wait=false...
..............................
Focus distance: 470
Focus motor position: 293
Focusing backward with step size 3, wait=false...
......................
Focus distance: 655350
Focus motor position: 10533
Focus range: 30 steps forward, 22 steps backward.
Motor steps: 10240 forward, 10240 backward, 0 lost.
Focusing forward with step size 2, wait=true...
.........................
Focus distance: 470
Focus motor position: 293
Focusing backward with step size 2, wait=true...
.....................
Focus distance: 655350
Focus motor position: 10533
Focus range: 25 steps forward, 21 steps backward.
Motor steps: 10240 forward, 10240 backward, 0 lost.
Focusing forward with step size 2, wait=false...
...............................................................................
Focus distance: 470
Focus motor position: 293
Focusing backward with step size 2, wait=false...
......................................................................
Focus distance: 655350
Focus motor position: 10533
Focus range: 79 steps forward, 70 steps backward.
Motor steps: 10240 forward, 10240 backward, 0 lost.
Focus test completed.
Testing exposure settings...
Camera : Canon EOS M2 (EOSM2) 1.0.3
Lens : EF28-105mm f/3.5-4.5 USM
Shoot mode: 3
Shutter : �50 (raw 101, 0.020263s, 20ms, apex 5.625)
Aperture : �5.6 (raw 48, f/5.6, apex 5.)
Av range : �3.5..�22 (raw 37..80, f/3.5..f/22.6, apex 3.625..9.)
ISO : �1600 (raw 104, 1600, apex 9.)
EC : 0.0 (raw 0, 0 EV)
Flash EC : 0.0 (raw 0, 0 EV)
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 movie recording...
Please switch to Movie mode.
Movie recording tests completed.
Done!
Sometimes I feel like I'm trying to start an old car. Pull battery, pull card, reinsert battery, start camera without card, reinsert card... but hey, this is still a new port even though this topic was started back in September 2015.
In any case, these tests should point to areas that still need some more work. Any help would be greatly appreciated.
Finally got the EOSM2 working in QEMU. It has been a while and I thought things were broken but they are working. It is hard as ... to get to the ML menus on this camera in QEMU and I wanted to see if I could run the lua tests so I ended up copying over the EOSM settings with the tests on autorun. Looks like it is working.
Here's what the QEMU console shows when running the strict_tests() and generic_tests():
[ module_task:00b009ec ] task_create(lua_load_task, prio=1c, stack=10000, entry=b02190, arg=0)
[MPU] Received: 06 05 03 07 60 00 (unknown - PROP_BURST_COUNT)
[MPU] Received: 06 05 03 11 02 00 (unknown - PROP_ICU_AUTO_POWEROFF)
[lua_load_task:ff14a4f0 ] register_interrupt(null, 0x94, 0xff14a344, 0x7)
[lua_load_task:ff14a4f0 ] register_interrupt(null, 0x94, 0xff14a344, 0x7)
Note that nothing is showing up on the QEMU gui but these tests did seem to complete successfully:
LUATEST.LOG
===============================================================================
ML/SCRIPTS/API_TEST.LUA - 2017-9-30 04:15:00
===============================================================================
Strict mode tests...
Strict mode tests passed.
Generic tests...
arg = table:
[0] = "API_TEST.LUA"
camera = table:
shutter = table:
raw = 80
apex = 3.
ms = 125
value = 0.125
aperture = table:
raw = 61
apex = 6.625
value = 9.900001
min = table:
raw = 41
apex = 4.125
value = 4.1
max = table:
raw = 84
apex = 9.5
value = 26.899999
iso = table:
raw = 72
apex = 5.
value = 100
ec = table:
raw = 0
value = 0
flash = true
flash_ec = table:
raw = 0
value = 0
kelvin = 4600
mode = 3
metering_mode = 3
drive_mode = 0
model = "Canon EOS M2"
model_short = "EOSM2"
firmware = "1.0.3"
temperature = 161
gui = table:
menu = false
play = false
play_photo = false
play_movie = false
qr = false
idle = false
bulb = function: p
shoot = function: p
burst = function: p
wait = 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:
hide = function: p
write = function: p
show = function: p
clear = function: p
lv = table:
enabled = true
paused = false
running = true
zoom = 1
overlays = false
info = function: p
pause = function: p
resume = function: p
wait = function: p
stop = function: p
start = function: p
lens = table:
name = "EF-S18-55mm f/3.5-5.6 IS STM"
focal_length = 0
focus_distance = 90
hyperfocal = 0
dof_near = 0
dof_far = 0
af = true
af_mode = 0
autofocus = function: p
focus = function: p
display = table:
idle = nil
height = 480
width = 720
print = function: p
clear = function: p
rect = function: p
line = function: p
circle = function: p
draw = function: p
load = function: p
pixel = function: p
notify_box = function: p
off = function: p
screenshot = function: p
on = function: p
key = table:
last = 0
press = function: p
wait = function: p
menu = table:
visible = false
close = function: p
set = function: p
select = function: p
block = function: p
get = function: p
open = function: p
new = function: p
movie = table:
recording = false
start = function: p
stop = function: p
dryos = table:
clock = 3
ms_clock = 3404
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 = 1395
folder_number = 100
free_space = 433216
type = "SD"
path = "B:/"
_card_ptr = userdata
shooting_card = table:
cluster_size = 32768
drive_letter = "B"
file_number = 1395
folder_number = 100
free_space = 433216
type = "SD"
path = "B:/"
_card_ptr = userdata
date = table:
month = 9
year = 2017
sec = 0
wday = 7
day = 30
isdst = false
hour = 4
yday = 273
min = 15
remove = function: p
rename = function: p
call = function: p
directory = 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:45: in function <ML/SCRIPTS/API_TEST.LUA:44>
[C]: in function 'xpcall'
ML/SCRIPTS/API_TEST.LUA:44: in function 'print_table'
ML/SCRIPTS/API_TEST.LUA:90: in function 'generic_tests'
ML/SCRIPTS/API_TEST.LUA:1568: in function <ML/SCRIPTS/API_TEST.LUA:1564>
[C]: in function 'xpcall'
ML/SCRIPTS/API_TEST.LUA:1564: in function 'api_tests'
ML/SCRIPTS/API_TEST.LUA:1603: in main chunktask = table:
create = function: p
yield = function: p
property = table:
Generic tests completed.
Module tests...
Done!
Now my question is, is this a valid test or am I wasting time? I was planning on going through each test one at a time to see if I can get a log and maybe the QEMU console will show some issues on the tests that are failing. I'm not sure if the tests that are failing can be run in QEMU so I was going to run them on the EOSM to see if that camera can complete the tests in QEMU.
These are the tests that the EOSM2 is having problems with and the EOSM is passing -- when run in camera:
test_menu()
test_camera_take_pics()
test_lv()
It is getting late and this is time consuming so I'm just throwing this out there before getting some shut eye. Planning on giving this a go in the morning.
Quote from: dfort on March 27, 2019, 07:22:03 AM
It is hard as ... to get to the ML menus on this camera in QEMU
It still works fine over here, and menu navigation is covered by the test suite for quite some time (i.e. tested after every group of commits). For example, latest log (https://builds.magiclantern.fm/jenkins/job/QEMU-tests/361/console):
Testing Canon menu...
EOSM2: ................................. OK
Key press sequence for that test:
MENU_SEQUENCE[EOSM2]="m space space space up up space m up space m up space m up space m right space space m m m l i q q 9 0 space i i m" # starts in LiveView
Screenshots resulted from that test:
(https://builds.magiclantern.fm/jenkins/view/Experiments/job/QEMU-tests/361/artifact/qemu-eos/tests/EOSM2-menu.png)
It's working on the Mac VM, too.
Some time ago I've reproduced your issue by swapping SFDATA.BIN from another camera (100D). Make sure it's not that; the first word in SFDATA.BIN is the model ID of the camera (0x80000355 for M2, 0x80000346 for 100D). Then, there comes a version number (6.0.3 for M2, 4.2.1 for 100D). If the SFDATA.BIN is the correct one, send me your ROMs (including SFDATA) so I can reproduce it.
Quote
Now my question is, is this a valid test or am I wasting time?
Generally speaking, if the log from emulator matches what you'd get on real hardware, it's probably a valid test. Things like file I/O, DryOS task switches or general-purpose computations are working very well. Once you get into LiveView, or photo capture, or even a plain half-shutter press in some cases, that's where things are starting to break.
If the log doesn't match, that usually indicates incorrect emulation (either bug in the emulator, or just not yet implemented). Some tests might be nondeterministic, for example the DryOS context switch order is no longer to match the one from real hardware, as it's not deterministic. You won't get the same order on real hardware either. There may be small differences between the two environments (such as, different card size or free space available), but these are already nitpicks.
A better way to debug these tests is to look at the line that failed:
ML/SCRIPTS/API_TEST.LUA:1240: assertion failed!
api_test.lua:1240 assert(lv.vidmode == "PH-NOLV")
lua_lv.c -> look for "vidmode" -> get_video_mode_name()
-> !is_movie_mode() && display_idle() ? "PH-NOLV" : /* Regular photo mode outside LV (ready to take a picture) */
Now, "all" you have to do is to check if both return 1 in what the script expects to be "photo mode", i.e. after getting out of LiveView via lv.stop(). That function calls close_liveview(). On EOS M, it does this:
#ifdef CONFIG_EOSM
{
/* To shut off LiveView switch to the info screen */
SetGUIRequestMode(21);
msleep(1000);
}
#else
# other ways to exit LiveView, for other models
#endif
It's probably commit 085b79c2b (the info/shooting screen is no longer running as GUISTATE_IDLE on the M series, unlike regular DSLRs). The same issue might be present on all other mirrorless models, so maybe it's time to define CONFIG_MIRRORLESS (assuming M50 and R/RP have the same quirk).
Thanks for the tips to track down the last few hiccups on this camera.
I have no problems navigating through the Canon menus and the emulation seems pretty good. The frustrating part is getting to the ML menus. Not that it is impossible, just very difficult. At least I haven't found a reliable way to open them in QEMU. No issues on the actual hardware.
(https://farm8.staticflickr.com/7904/46567086055_57e11015d6.jpg) (https://flic.kr/p/2dWYuj4)
This is what I've got:
src/movtweaks.c
void close_liveview()
{
if (lv)
#if defined(CONFIG_EOSM) || defined(CONFIG_EOSM2)
{
/* To shut off LiveView switch to the info screen */
SetGUIRequestMode(21);
msleep(1000);
}
#else
Maybe I shouldn't assume that the EOSM2 is using the same SetGUIRequestMode codes as the EOSM? This is still a learning processes for me.
Back to running the lua tests in QEMU.
I keep coming up with a strange issue where the lua test is asking to switch to M mode when the (virtual) camera is already in M mode.
(https://farm8.staticflickr.com/7882/46568644155_4819115bfc.jpg) (https://flic.kr/p/2dX7ttR)
Maybe it has something to do with the rather odd double photo modes switch on the EOSM2? Note that there are two photo settings while the EOSM has just one:
(https://c1.staticflickr.com/5/4227/34014053584_75ea69bf64_z.jpg)
The #2 is the one I have set for manual mode and seems to be the one that QEMU displays in the gui but maybe it is actually looking at the #1 settings which are not in M mode?
So much for the dual photo mode switch on the M2, the EOSM also has a problem figuring out what mode it is in when running the lua tests in QEMU.
(https://farm8.staticflickr.com/7854/47490545981_d4263e4b54.jpg) (https://flic.kr/p/2fmzsLV)
It also can't verify whether or not it is in movie mode.
(https://farm8.staticflickr.com/7916/47490548251_7370fabb24.jpg) (https://flic.kr/p/2fmzts4)
So this isn't just an EOSM2 emulation issue.
BTW -- On the EOSM2 the still photo mode #1 is "Basic Zone Modes" where Manual mode is not possible and #2 is "Creative Zones Modes" and is where you'll find the Manual mode.
Following, I'm a total potato at coding, but ill send positive vibes? I just picked up an M2 for a killer deal and would love to make it my main shooter!
@alex
Could I ask you for what this is doing in state-object.c?
#ifdef EVF_STATE
stateobj_start_spy(EVF_STATE, stateobj_lv_spy);
#endif
Clearly affects liveview causing freezes when RAW video is enabled. Uncommenting and no freeze. Not able to record as well obviously when not enabled.
Seems mentioned here as well:
https://www.magiclantern.fm/forum/index.php?topic=15895.msg187795;topicseen#msg187795
This installs a hook in Canon's "Evf" task, allowing our code to run before and/or after each state transition.
Among others, this triggers the VSync hooks, i.e. functions called once for every LiveView frame. One of them is raw_lv_vsync, which you have found it may be related to the crash (https://www.magiclantern.fm/forum/index.php?topic=15895.msg209308#msg209308).
That could be either some incorrect stub called by that function, or some EDMAC transfer writing data into unallocated memory, or something along these lines.
EDMAC transfers appear to work; they were reported to pass the stubs API test. You could also try running the EDMAC screen test from selftest.mo, but I believe it will work.
Memory issues are a little harder to debug, but not impossible. I don't have a shortcut, but I'll be available this week starting Wednesday - if we can sync on the chat, we can debug this one together. It would probably take a couple of hours, or maybe more.
Quote from: a1ex on May 27, 2019, 03:16:45 PM
EDMAC transfers appear to work; they were reported to pass the stubs API test. You could also try running the EDMAC screen test from selftest.mo, but I believe it will work.
Memory issues are a little harder to debug, but not impossible. I don't have a shortcut, but I'll be available this week starting Wednesday - if we can sync on the chat, we can debug this one together. It would probably take a couple of hours, or maybe more.
Can´t say no to that offer. Friday or saturday would work here so let´s see if we can sync(); here. I´ll pm later.
Fast test:
Selftest.mo seems not to happy with ot without RAW video enabled. Two examples:
ML ASSERT:
dst == UNCACHEABLE(dst)
at ../../src/edmac-memcpy.c:142 (edmac_copy_rectangle_cbr_start), task run_test
lv:1 mode:0
run_test stack: 233af8 [233c50-22bc50]
0x0048DDA4 @ b4f880:233c00
0x0048DD40 @ 48dddc:233be0
0x0048DAD0 @ 48dd90:233bb0
0x0044C9AC @ 48db50:233b28
0x0044C478 @ 44ca08:233af8
Magic Lantern version : Nightly.2019May27.EOSM2103
Mercurial changeset : 15f42e1abbf2+ (crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2)
Built on 2019-05-27 13:35:28 UTC by [email protected].
Free Memory : 372K + 1370KAnother:
ML ASSERT:
dst == UNCACHEABLE(dst)
at ../../src/edmac-memcpy.c:142 (edmac_copy_rectangle_cbr_start), task run_test
lv:0 mode:0
run_test stack: 233af8 [233c50-22bc50]
0x0048DDA4 @ b4f880:233c00
0x0048DD40 @ 48dddc:233be0
0x0048DAD0 @ 48dd90:233bb0
0x0044C9AC @ 48db50:233b28
0x0044C478 @ 44ca08:233af8
Magic Lantern version : Nightly.2019May27.EOSM2103
Mercurial changeset : 15f42e1abbf2+ (crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2)
Built on 2019-05-27 13:35:28 UTC by [email protected].
Free Memory : 372K + 1384K
hm:
/* make sure we are writing to uncacheable memory */
ASSERT(dst == UNCACHEABLE(dst));Branch used atm, mainly dfort ports:
https://bitbucket.org/Dannephoto/magic-lantern/branch/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2
EDIT:Hm, getting similar results with my eosm so maybe not indicating anything here:
ML ASSERT:
dst == UNCACHEABLE(dst)
at ../../src/edmac-memcpy.c:139 (edmac_copy_rectangle_cbr_start), task run_test
lv:0 mode:3
run_test stack: 213d18 [213e70-20be70]
0x000E0CF4 @ b4acd0:213e20
0x000E0C90 @ e0d2c:213e00
0x000E0A20 @ e0ce0:213dd0
0x0009EC30 @ e0aa0:213d48
0x0009E558 @ 9ec8c:213d18
Magic Lantern version : Nightly.2019May27.EOSM202
Mercurial changeset : 759e482088c8 (crop_rec_4k_mlv_snd_isogain_1x3_presets) tip
Built on 2019-05-27 09:22:45 UTC by [email protected].
Free Memory : 215K + 3213K
For those EOSM2 users who are checking out the progress and trying out the builds I've been posting (https://bitbucket.org/daniel_fort/magic-lantern/downloads/) -- have you noticed things are getting better? It still has a ways to go but those gnarly screen freezes are gone and Danne has even started playing around with some advanced crop_rec settings. Full resolution silent pictures are still a problem but hey, one step at a time.
@dfort
Waiting like a praying mantis for you video guys to sort things out for us Neanderthal-like, knuckle dragging still photography types :)
Yes a1ex of course guiding, troublechecking.
Got mv1080p rewired mode working but still a hackish state but fully capable of producing raw recordings.
Quote from: garry23 on May 30, 2019, 10:16:41 PM
Waiting like a praying mantis for you video guys to sort things out for us Neanderthal-like, knuckle dragging still photography types :)
LOL!
Did you know that I was a still photographer from about 1973 through 1993 then worked in motion picture post production until just a couple years ago?
This is one of my cameras back when I was a photographer:
(https://live.staticflickr.com/65535/47968415933_8d06bf285c.jpg) (https://flic.kr/p/2g5NES2)
This is what a1ex and I were looking at today:
(https://live.staticflickr.com/65535/47967663351_3c626dc3bb.jpg) (https://flic.kr/p/2g5JP9t)
How things have changed!
We now return to your regularly scheduled forum topic.
:) :) :) :)
Joining the testing team today ! :D Just tested Danne's latest build:
- Anamorphic unsqueeze seems to work;
-Having trouble with both RAW modules, even in crope mode, frame freezes during recording. The result is a pretty good first frame, but then we have glitches flickering and some times the first frame coming back. No error message from ML.
-Noticing different glitch patterns between the different modes.
-Liveview sometimes freeze, esoecially when activating RAW shooting.
-Made some benchmarks: getting around 54mb/s with an Integral SD card that can write up to 100mb/s (80-90 in reality, method 4 for memory allocating, didn't try other modes for the moment)
-Had the console popping and not going away when skipped a frame during RAW shooting.
Will make more tests and note different errors.
PS: Tried different methods to push the recording resolution to its limits but couldn't get past 1800p.
Well. I can upload a build that would work with anamorphic and mcm rewired mode similar to the 100D. A bit buggy bit without freezes.
But later. Not at home yet...
Posting a test build here:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_2019Jul04.EOSM2103.zip
Branch:
https://bitbucket.org/Dannephoto/magic-lantern/branch/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2
Don´t have the camera atm but these two presets should work (after some menu pressing) without freezes:
"mv1080p_rewired"
"4K anamorphic rewired"
Enable:
crop_rec.mo
mlv_lite.mo
mlv_snd.mo
mlv_play.mo
sd_uhs.mo
Also added the direct patch for sd_uhs.mo which should patch your sd card upon start up. Files will have focus pixels very much like 100D. Use these pixel maps and put them inside Mlv App. Also set chroma smooth to 3x3 will help:
https://bitbucket.org/daniel_fort/ml-focus-pixels/downloads/
Todo:
Pretty much go through the whole code and fix bugs. Biggest one the "freeze" issue. a1ex is trying to figuring that one out, well when there will be time for doing it. Raw buffer related.
Happy testing, please report what´s working or not.
Danne I installed the camera firmware, then I installed your firmware, how to start ML, it was flashed, but it does not start. >:(
Then I downloaded your files by reference, pasted in the ML folder on the card, tried to start. The camera does not turn on, the black screen continuously flashes the power icon, I waited a bit, turned off the power icon, took down the ML card and installation files from the card. Camera works.
Hey PitbulZil, have you tried the previous build ?
@PitbulZil - Danne took down his EOSM2 builds. Maybe you have been trying to run an EOSM build on your M2? It is a bit confusing. The EOSM have EOSM202 in the file name while the M2 has EOSM2103.
I've got test builds on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/). I have been trying to keep up with Danne's changes but have fallen behind lately because he is so productive and each merge requires working out conflicts. Not between Danne and me personally but because of the way 'hg merge' is working on our crop_rec.c source code.
Quote from: dfort on June 24, 2019, 01:39:05 PM
each merge requires working out conflicts. Not between Danne and me personally but because of the way 'hg merge' is working on our crop_rec.c source code.
haha :P
I've downloaded version 2103, take her here https://bitbucket.org/daniel_fort/ml-focus-pixels/downloads/ the problem is that no software start ML and loaded with the standard Canon. I understand this: you do not need to press additional buttons to enter the interface . If I have downloaded ML, is the login done automatically?
Or after booting I need to press ?
(as on canon 650D)
@PitbulZil - Not sure what you are doing. What do you mean by login? ML works the same on the M2 as it does on all other cameras. It is still in the early porting stages and there are some features that aren't working. Basically unzip the archive, put the files on the root directory of the SD card, run firmware update to turn on the card and camera bootflags, restart camera, press the trash button and you should see the ML menus. If you don't see the ML menu when pressing the trash button then ML wasn't installed properly.
@PitbulZil - At the indicated address you can not find the archive.
Download at https://bitbucket.org/daniel_fort/magic-lantern/downloads/ (https://bitbucket.org/daniel_fort/magic-lantern/downloads/)
Putting a version back up:
https://www.magiclantern.fm/forum/index.php?topic=15895.msg217340#msg217340
This branch is used:
https://bitbucket.org/Dannephoto/magic-lantern/branch/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2
All at own risk of course. I do not own the camera anymore...
EOS M2 test thoughts:
Build July 04:
- Frozen Live View, actually unusable, (Live View is working in June 11 Build, sometimes a white bar appears on the bottom half, and that build is really nice, just lower resolution and more aliasing than the original EOS M, all focus pixels are all removed in MLV App with 3x3 chroma smooth, the build just needs more resolution @16:9 aspect ratio in RAW Video and playback is stretched like anamorphic with visible focus pixels across the whole frame). Testing out the others now...
Only thing expected to "work" are the crop_rec presets.
Tested July 05 Build EOSM2103:
I enabled the following:
crop_rec.mo
mlv_lite.mo
mlv_snd.mo
mlv_play.mo
sd_uhs.mo
*There is still the frozen frame issue, maybe I'm not enabling something important. I went into preview and set preview to frozen LV and the LV was back to normal for about 10 seconds. Not sure what can un-freeze the LV.
And what preset did you select? Anamorphic modes? Pressed canon menu and so on?
Run framing or real-time preview for testing.
Oddly enough, there are no anamorphic modes. Crop Mode is only 3x3 720p can't change it to anything else, and RAW Video Max resolution is 1736x586. Double tapped Menu, but still frozen LV even with the proper preview modes. To go into ML Menu, I must hold the 'down' wheel, no 'two-finger tap' function to enter ML Menu. I think the freeze issue is from the frame rate. Even though the Canon Menu is at 24fps, the ML fps is stuck always@ 29.958fps.
Quote from: ZEEK on July 06, 2019, 09:15:14 AM
Even though the Canon Menu is at 24fps, the ML fps is stuck always@ 29.958fps.
Check your EOSM on this one. It is the "normal" behavior. The ML fps display will change when you start recording.
I was going to ask Danne about CONFIG_EDMAC_RAW_SLURP. What I've been doing is to keep my experimental EOSM2 branch in sync with his crop_rec_4k_mlv_snd_isogain_1x3_presets branch. When I merged yesterday it wouldn't compile without raw slurp (https://bitbucket.org/daniel_fort/magic-lantern/commits/6b4586da80ee2c9988b4a3b531fbabad4707d2a9). That brought back the LiveView freezing issues. Simply turn off raw histogram to get past that for now.
At the moment I'm more interested in getting the basic ML functionality working on this camera rather than trying out new crop rec setting. If you want to try out the stuff Danne experimented with simply replace the "is_basic" block with the is_EOSM2 block that is commented out. This camera is very similar to the EOSM and 100D so something else you can try out is to "pretend" it is one of those models and copy in the block of code from another model.
else if (is_camera("EOSM2", "1.0.3"))
{
CMOS_WRITE = 0x432A4;
MEM_CMOS_WRITE = 0xE92D41F0;
ADTG_WRITE = 0x42E34;
MEM_ADTG_WRITE = 0xE51F7224;
ENGIO_WRITE = 0xFF2C6F44;
MEM_ENGIO_WRITE = 0xe51fc15c;
/* The basic crop_rec settings are (sort of) working on this camera */
is_basic = 1;
crop_presets = crop_presets_basic;
crop_rec_menu[0].choices = crop_choices_basic;
crop_rec_menu[0].max = COUNT(crop_choices_basic) - 1;
crop_rec_menu[0].help = crop_choices_help_basic;
crop_rec_menu[0].help2 = crop_choices_help2_basic;
/**********************************************************************************
is_EOSM2 = 1;
crop_presets = crop_presets_eosm2;
crop_rec_menu[0].choices = crop_choices_eosm2;
crop_rec_menu[0].max = COUNT(crop_choices_eosm2) - 1;
crop_rec_menu[0].help = crop_choices_help_eosm2;
crop_rec_menu[0].help2 = crop_choices_help2_eosm2;
**********************************************************************************/
}
I could use some help with the EOSM port. It seems to work ok in QEMU so whatever is going on will probably require the physical hardware (as opposed to virtual hardware) to debug.
Sorry guys. Compiled without the patch which included the anamorphic stuff in crop_rec menu:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_2019Jul06.EOSM2103.zip
Patch here:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/hack2.patch
When I sat down with a1ex he guided me into compiling with default buffer. We excluded raw_slurp and no freezes. So this means if we can live without higher resolutions the main issue seems solved. BUT, above version includes raw_slurp since we are using higher resolutions. This seems to work on anamorphic modes wihtout freezes. Go figure. Smaller buffer mv720p etc seems to freeze. Belive me, we want raw_slurp on this camera.
This camera is very close but yet seems so far away from getting into the hall of fame. It clearly needs some more magic lantern love...
I am very glad that I own Canon EOS M1 as well as eternally grateful to those guys who are constantly upgrading this camera through a magic lantern.
After reading the forum about Canon EOS 2, I did not find an answer for myself : So what gives the Canon EOS 2? Does he shoot video better?
@Dfort thanks I'll do some more build tests and play around with the settings.
@Danne, good work! I'll give the updated build a test and see if it can record 'automagically'.
Ok--just for fun I made a hack2_no_raw_slurp build and put in on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/). It is far from being ready for mass consumption but LiveView doesn't freeze up and it has a workable mv1080 3x3 sampling resolution. I also uploaded a build from my experimental branch without raw slurp but with the old school "is_basic" crop_rec setting.
[EDIT] Found this and thought it should be added to the discussion:
Quote from: a1ex on June 06, 2019, 09:51:33 AM
Without raw_slurp, you have no control on the amount of data transferred from image processor into main ram (i.e. over image size).
This is why the EOS M2 hack is *not* a fix, but just a temporary step in diagnosing the issue.
@Fadis
Both Digic 5, so not a difference in image quality. The differences are very minor but considering they are about the same price you would be more inclined to opt for the M2 if you didn't already have an EOS M already (however the EOS M is obviously more advanced in ML Raw which makes it the popular choice).
These are some of the differences:
EOS M EOS M2
Dynamic Range: 11.2 11.4
Lowlight ISO: 827 ISO 855 ISO
Hybrid CMOS AF II (Not much of a difference)
Wi-fi
8% Smaller
Great! Not stressed about the anamorphic stuff yet, although it is a bonus. As long as the mv1080 stuff is running smoothly, I think that's definitely a great improvement.
I tested the July 06 Build for the EOS M2, and I have to say, I'm extremely impressed. Full Resolution 1736 x 976 pixels. Brilliant. It's dark now so, can't test more yet.
July 06 Build, Enabled the following:
- Crop_Rec
- Mlv_lite
- Mlv_play
- Mlv_snd
- Sd_uhs
Crop mode: mv1080_rewired, 10 bit, set 25fps (ran nicely no issues), ratios off.
Raw Video: 1736x976 (claims 4.83x but it's not, looks 1.61x), 16:9, 14bit lossless.
Test .MLV File here (Canon 50mm f1.8 STM + Viltrox @ f1.2):
https://drive.google.com/open?id=1DtnSTuRWE-B_AnEK-rjrCFXYej3q9Xgt
Big improvement, thanks!
Nice set of vintage lenses.
(https://live.staticflickr.com/65535/48222084802_fdaa81bcb5.jpg) (https://flic.kr/p/2gtdMMd)
Just for the record, these are the versions of the modules you were using for this test:
crop_rec built 2019-07-06 17:03:22 UTC; commit 15f42e1 on 2019-02-18 16:29:26 UTC by dudek53: movie crop mode round trip. Partly working.
mlv_lite built 2019-07-06 17:03:05 UTC; commit 26e8008 on 2018-12-11 11:02:45 UTC by dudek53: First try on EOSM2. Thanks to dfort and critix
mlv_play built 2019-07-06 17:03:07 UTC; commit 0e38b89 on 2018-06-18 22:11:42 UTC by g3gg0: mlv_play: use less RAM, proper cleanup on error
mlv_snd built 2019-07-06 17:03:09 UTC; commit 9ec9c80 on 2018-07-03 22:20:19 UTC by g3gg0: mlv_lite/mlv_snd: rewrote state machine and placed WAVI writing...
sd_uhs built 2019-07-06 17:03:28 UTC; commit 26e8008 on 2018-12-11 11:02:45 UTC by dudek53: First try on EOSM2. Thanks to dfort
Looks like yet another new crop_rec resolution:
Block: RAWI
Offset: 0x00000034
Number: 1
Size: 180
Time: 0.765000 ms
Res: 1736x976
raw_info:
api_version 0x00000001
height 1187
width 1872
So I created a 80000355_1872x1187 map file (https://bitbucket.org/daniel_fort/ml-focus-pixels/commits/7ce5820351e5c31284023f3dab75b6166631b2c2) to deal with the focus pixels. Note that it shows a 3x3 sampling but the MLV metadata is showing 1x1 sampling. This could be a problem.
Block: RAWC
...
sampling 1x1 (read every line, read every column)
Quote from: dfort on July 07, 2019, 05:24:25 PM
Note that it shows a 3x3 sampling but the MLV metadata is showing 1x1 sampling. This could be a problem.
Block: RAWC
...
sampling 1x1 (read every line, read every column)
Nice find dfort. Does it affect handling in Mlv App for instance? Here are two examples of my cat with 1x1 and 3x3 metadata:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/M07-1803.MLV
https://bitbucket.org/Dannephoto/magic-lantern/downloads/M07-1801.MLV
Also updated eosm2 code so it records 3x3 metadata now instead:
Download:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_2019Jul07.EOSM2103.zip
Latest patch:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/hack3.patch
Quote from: Danne on July 07, 2019, 05:54:04 PM
Does it affect handling in Mlv App for instance?
I'm not sure. What is happening here is when opening ZEEK's sample file in MLV App the "Fix Focus Dots" defaults to Off while both your cat files default to On. Maybe MLV App doesn't recognize the EOSM2 as a camera that needs focus pixel fixing?
Quote from: Danne on July 07, 2019, 05:54:04 PM
Latest patch:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/hack3.patch
These are huge patch files. Why not start a new branch so we can see just the small changes you're making? Seems like users are happy with these new builds you are posting even if they aren't "proper" fixes. At least some of the ML features are usable.
Pushed all in here:
https://bitbucket.org/Dannephoto/magic-lantern/branch/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2
About pixel maps enabling. In Mlv App:
/* returns focus pixel pattern A, B or NONE in case of unsupported camera */
static int fpm_get_pattern(uint32_t camera_model)
{
switch(camera_model)
{
case 0x80000331:
return PATTERN_EOSM;
case 0x80000346:
return PATTERN_100D;
case 0x80000301:
return PATTERN_650D;
case 0x80000326:
return PATTERN_700D;
default: // unsupported camera
return PATTERN_NONE;
}
}
What´s the camera model id on eosm2? mlv_dump checking mlv right?
Edit:
Camera Model: 0x80000355
Seems easy to include eosm2. Added it into two files in Mlv App code and it now gets applied accrodingly.
@masc, could you take a look?
Thanks.
Hum--shouldn't your crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2 and crop_rec_4k_mlv_snd_isogain_1x3_presets be pretty much the same, except for the addition of the EOSM2 and the minimum needed to work without raw slurp (https://bitbucket.org/daniel_fort/magic-lantern/commits/21dcde2c3fb28fd2f4cdb02f590f7a809f5e69f5)? Looks like there are lots of other changes in there. I've been trying to keep my EOSM2 branch in sync with your latest that includes EOSM/100D/650D/700D/6D/5D3 -- did I leave anything out?
Looks like MLV App should support the EOSM2 -- though turning on "Fix Focus Dots" with the new map files does seem to work quite nicely.
Well, I think this eosm2 branch is derived from some patch manager branch. Can´t remember exactly. Anyway. Don´t think mixing in that particular branch into my eosm stuff would be good idea atm. Don´t even have the cam here.
If you want you could try and merge eosm2 into my eosm branch. Maybe without patches more like the other cameras? Or what is missing for eosm2 that needs special care?
By the way. Raw_slurp is enabled in this branch. Otherwise anamorphic would never work with higher resolution.
I've got all the cameras working in my EOSM2 branch. It has some other branches merged in there but as far as I can tell it isn't affecting the other platforms. Of course I haven't been doing much testing or am I as familiar with the code as you are but every once in a while I'll compile for the EOSM or 700D or 5D3 and it works.
https://bitbucket.org/daniel_fort/magic-lantern/branch/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort
Nice.
I checked, seems you merge all kinds of stuff to get all working in one branch. Hopefully working but needs testing :)
Right -- I tried doing a fake pull request against your branches but Bitbucket crashes there are so many changes!
There are literally thousands of things to watch out for. For example, you have this wrong in your branches:
modules/mlv_rec/raw_proc
/* focus pixel helper enums */
enum pattern { PATTERN_NONE = 0,
PATTERN_EOSM = 331,
PATTERN_EOSM2 = 331,
PATTERN_650D = 301,
PATTERN_700D = 326,
PATTERN_100D = 346
};
EOSM2 should be 355 but on the pull request it uses your values because your changes are newer than my changes--or at least I think that's what's going on. Tricky stuff going on here.
Tested July 07 M2 Build, works nicely.
Note:
* Camera screen turns off at times:
- After playback of clips
- After double tapping Menu Button
- At times when cycling through the info button
- After recording a clip
* Frame rate cannot be set to 1/50, its 1/43, 1/56, 1/70
Apart from that, mv1080p_rewired is working nicely, the clips look great, no focus pixel issues.
Quote from: dfort on July 08, 2019, 02:14:59 AM
EOSM2 should be 355 but on the pull request it uses your values because your changes are newer than my changes--or at least I think that's what's going on. Tricky stuff going on here.
But it's your branch to begin with :). Run it against your branch you had at early stages and changes should be fewer. What branch did you merge it against to start with?
Quote from: Danne on July 08, 2019, 06:42:58 AM
What branch did you merge it against to start with?
I've got the same question for you--
Your branch: :-X
(https://live.staticflickr.com/65535/48228865886_2e3174452a.jpg) (https://flic.kr/p/2gtPxys)
My branch: :D
(https://live.staticflickr.com/65535/48228865836_882b2fbc7b.jpg) (https://flic.kr/p/2gtPxxA)
How did this happen?
Checking some older messages starting out dec 11th it seems I might have gotten it from here:
https://bitbucket.org/ccritix/magic-lantern/src/
No longer available. Well. I don´t have the camera so I think I am pretty much out of the loop for the time being...
I added the EOS M2 to MLVApp. Now focus pixel fix should work and camera matrix is hopefully correct (is it the same like EOS M / 100D / 650D /... ? ) .
Would be cool if someone could check. I have no EOS M2 files here, so I am not able to test what I implemented.
The EOSM2 uses the same sensor as the 100D so that should be the closest match.
I have some new .MLV files here from the EOS M2 using the July 07 Build. Test shots with the Pentacon 50mm f1.8 + Viltrox EF-M2
Link:
https://drive.google.com/open?id=1La1Fphd6oIvI3RshRG9S5aqejX4qkrfN
Thank you @ZEEK. This will help a lot! ;)
Great! :)
After installing manually dfort's latest focus pixel maps to MLVApp, I can remove the focus dots from ZEEK's clips (with the same "success" like with other cams -> on some details it looks worse than without fix, depending on chosen method). Important is, that the maps are installed. Otherwise I get vertical stripes and don't know why. ;)
Edit: stripes fixed.
@Dfort, the M2 records nicely indeed, just one issue which if it can be fixed will be amazing.
- Every time after the recording, the M2 live view will go all black but is still on. You can press menu and it will take you to the menu, but when you get out of the menu, the live view is black and requires a restart each time after recording or sometimes even cycling through the live view displays using the info button.
- When you restart, the screen freezes, I double tap menu and it's working again. After recording the same thing happens (The LV goes black and requires a restart).
Build Used: JULY 07. Not sure what's causing this...Thanks.
sd sandisk pro 128gb, read speed 170, four hours of shooting with the sd overclocking module, no longer reads the magic lantern firmware. Record normally from the canon menu. I've tried everything, deep format, old builds ... ideas?
Yeah, do not crosspost!
Quote from: ZEEK on July 12, 2019, 10:17:07 AM
Build Used: JULY 07.
Hum--that must be one of Danne's builds. Does it also happen with my July 6 build? My version might not have the settings you want yet but I can probably get it working. Good getting some actual field testing on the M2. I did some early tests (https://www.magiclantern.fm/forum/index.php?topic=15895.msg210016#msg210016) just to see if ML interfered with regular Canon only functionality and it seemed to do fine.
Might be a good idea switching to your "omni" branch. I think adding eosm2 presets from crop_rec should do.
Quote from: dfort on July 14, 2019, 06:45:20 AM
=Does it also happen with my July 6 build? some early tests (https://www.magiclantern.fm/forum/index.php?topic=15895.msg210016#msg210016) just to see if ML interfered with regular Canon only functionality and it seemed to do fine.
The July 06 build worked fine but the reason for the July 07 was to fix the fact that it wasn't recording 3x3 metadata and the MLV data was showing 1x1 sampling. Would you prefer I use July 06 for further development? The July 07 is really fine, it's just the fact that you need to reset the camera after recording most times or when you cycle through the info button, apart from that I would classify it as really good.
Can you record mcm rewired with the dfort build?
No MCM Rewire in the July 06 Build. If crop mode is enabled, it only allows 3x3 720p and RAW Video becomes 0X0. Crop Mode off and you can record 1728x696 (1.61x).
Could you try crop_rec.mo from my build on top of dfort build?
Quote from: Danne on July 14, 2019, 12:36:07 PM
Could you try crop_rec.mo from my build on top of dfort build?
You mean copy the "crop_rec.mo" from your July 06 Build and paste it over onto the July 07 Build modules folder?
* Tried it, just makes Danne's July 07 Crop Mode 3X3 720p and freezes.
Other way around. My 07 july crop_rec onto dfort 06 july build. We want to see if it still need restarting or not after recording also in dfort build.
Excellent news....it worked perfectly! :D
No freeze, no restart required after recording, pressing menu, cycling through info, or after playback...Global Draw even works, such as Magic Zoom, without any flickering which occurred previously.
Everything is pretty much on point except for shutter speed of 1/54 which isn't the biggest deal. Great work!
Shutter can be fixed. Forked dfort repo and I saw three different branches. Hm which one to choose here ;):
1 crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2
2 crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort
3 crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_hack2
This is where I realize I need the camera in my hand again :P
This one:
2 crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort
#1 is your branch and #2 has your hack2 patch applied. I've been busy on another project that is taking up much of my time so I got behind syncing my branch with your latest changes.
You know you don't need to fork it -- I gave you write access to my repository so we don't need pull requests to merge changes. You can also pull in my branch into your repository, branch it (so we don't get multiple heads on future pulls) and take it over from there.
I'm hoping that once basic Magic Lantern is somewhat stable I (or anyone who wants to jump in) will make a pull request on the main repository so EOSM2 can join the rest of the supported cameras.
Could someone who owns a M2 please record a .cr2 picture and upload? I would like to read out camera matrix values from the file and check if my assumption was correct.
Glad to help...what's the best way to upload?
--Jon
Testing things out. Still pics and focus peaking are working great! Having issues with Crop Mode off and recording 1728x696 (1.62x) at either 10 or 14bpp. Lots of frame skipping unless i allow it and then video becomes unusable. Using SanDisk 64gb Ultra 80MB/s card.
HUGE thank you to everyone working on this. I don't know much about video but would be glad to test whatever...
My bad on the video as I didn't have the correct MLV module loaded. That sorted out the frame skipping. Much learning ahead to improve quality for me.... Thanks again to everyone!
Nightly.2019.Jul06.EOSM2103
--Jon
Quote from: jonkjon on July 15, 2019, 04:22:42 PM
Glad to help...what's the best way to upload?
Use any filehoster... dropbox and friends...
Here's a .cr2 file
https://www.dropbox.com/s/m5jhsvzovnqy05m/IMG_8579.CR2?dl=0 (https://www.dropbox.com/s/m5jhsvzovnqy05m/IMG_8579.CR2?dl=0)
--Jon
Thank you.
I extracted the color matrix values from the cr2 file and included them into MLVApp. Now "Use camera matrix" should bring correct color.
Quote from: masc on July 16, 2019, 02:15:23 PM
I extracted the color matrix values from the cr2 file and included them into MLVApp. Now "Use camera matrix" should bring correct color.
Would we just re-download the mlv_app?
--Jon
To use this change, download sources and compile. The next official release ( v1.8 ) will include it too.
Quote from: masc on July 16, 2019, 06:41:57 PM
To use this change, download sources and compile. The next official release ( v1.8 ) will include it too.
Been trying to compile this but getting errors about undefined references to min/max in amaze_demosaic.c and others too. Following the instructions at GitHub for compiling on windows. I'll keep trying. Thank you.
--Jon
Quote from: jonkjon on July 16, 2019, 07:08:00 PM
Been trying to compile this but getting errors about undefined references to min/max in amaze_demosaic.c and others too. Following the instructions at GitHub for compiling on windows. I'll keep trying. Thank you.
Normally this should work out of the box as described. Could you please post the compiler error message, then I'll have a look. What Qt and MinGW version do you use? But maybe better post into MLVApp thread, because it is a bit off-topic here.
https://www.magiclantern.fm/forum/index.php?topic=20025
Playing around a bit more and discovered that FPS override freezes and garbles live view during back button focus. Reset shutter button from custom function to default half press focus and same result. Only way I could get focus to work was turning off FPS_Override.
--Jon
After lots of fiddling with different settings and testing low light etc, things are working really well. I have downloaded the latest download from dfort's repository of 7-16. Shooting at 1764x444 and 24fps gives me pretty good raw results. I have tested Crop mode but don't really have much need for it. Probably because I don't fully understand the implementation of the presets and mv1080p mcm etc,.
The only niggle I have is I can't get the shutter speed to where I want it. i.e. at 24 fps I want 1/48 but can't get closer than 1/52. I know this was mentioned elsewhere.
Thank you to all who are working on this. I look forward to the intervalometer and some AP in the coming days.....
--Jon
Quote from: masc on July 11, 2019, 03:07:37 PM
After installing manually dfort's latest focus pixel maps to MLVApp, I can remove the focus dots from ZEEK's clips (with the same "success" like with other cams -> on some details it looks worse than without fix, depending on chosen method). Important is, that the maps are installed. Otherwise I get vertical stripes and don't know why. ;)
Edit: stripes fixed.
Sorry for the newb'ness but being a fledgling in the world of RAW video on my EOS-M I was hoping to get some help with all this. Short of reading through about 1200 posts from the beginning I'm hoping to fast track it a bit and skip a lot of the unnecessary developer chat. I have seen focus pixels first hand and know that in MLVapp (1.7) I can just turn on 3x3 chroma smoothing and get rid of them (I suspect at the cost of overall image quality reduction. After a bit of reading I see there is a more concise way of getting rid of them with pixel maps. I've seen the zip download for the pixel maps. Exactly how do I utilize them in MLVapp? Another thing I notice is my footage versus others and theirs specifically low light which is apparently shot between 100-800 and there is noise free (apparently without noise reduction in post). I shot a living room scene at ISO 800 and at ISO100.. it starts off bright near a window and pans to a darker area in the kitchen. On both shots there is chroma noise in the shadows. Maybe its a shot that would be hard to get in one continous shot where its full sunlight over into a darkened area, I always thought ISO 100 should be fairly noise free in shadows but not so much. (I was shooting ETTR of about .1-.8 on each of these)
Quote from: Nibby99 on July 18, 2019, 03:08:28 PM
...I've seen the zip download for the pixel maps. Exactly how do I utilize them in MLVapp? ...
Unpack, select maps for your camera, drop them on MLVApp, reload your clip and activate focus pixel fix. https://github.com/ilia3101/MLV-App/wiki#fix-focus-dots
RE: focus pixel maps. Does the resolution of the map have to match the resolution of the footage? I cannot shoot at anywhere close to the image sizes listed for the fpms...
--Jon
Quote from: jonkjon on July 18, 2019, 04:07:32 PM
RE: focus pixel maps. Does the resolution of the map have to match the resolution of the footage? I cannot shoot at anywhere close to the image sizes listed for the fpms...
No, the resolution of the map has to match the resolution from RAWI block. You can read this size with mlv_dump:
mlv_dump -v your.mlv > some_file.txt
then find block RAWI (example):
Block: RAWI
...
height yyyy
width xxxx
Or just install all files for your camera.
Thanks...
--Jon
Quote from: masc on July 18, 2019, 03:33:48 PM
Unpack, select maps for your camera, drop them on MLVApp, reload your clip and activate focus pixel fix. https://github.com/ilia3101/MLV-App/wiki#fix-focus-dots
Many thanks guy I will give this a shot when I get home. Hopefully there is some matching resolutions. I usually use mv1080 rewire and 16:9 or 2.35:1 and lower than usual resolution since I have a frigging Sandisk Extreme but not Extreme Pro (I think I max out around 38-40MBs).
Test footage shot today (7/18-2019)..https://youtu.be/c-OG6xFfjjE (https://youtu.be/c-OG6xFfjjE)
Working with the latest build from dforts repository and replacing the crop_rec with the presets from Danne is giving me the best results. I had some issues with Magic Zoom flickering using Danne's build but I get slightly higher res. using his. I do have to punch into the menu occasionally to get out of a lock up but it is much, much better than previous. Other than the shutter speed being off slightly, this thing is working pretty darn great. THANK YOU to everyone for the fantastic work!!!
--Jon
Yeah, that´s pretty nice. Branch should be merged and fixed but dfort seems busy these days. I have no cam so focusing on other stuff atm.
Magic Lantern on the EOS M2 has been going really great, really useable now. I have noticed that the M2 produces less noise as well as minuscule aliasing when compared to the EOS M.
One thing, though not major, is that the M2 doesn't work well with a monitor. It doesn't even recognize it is being connected to one and won't connect. Not sure what the issue is here, works well with the original M, guess ill have to play around with it more.
Quote from: ZEEK on July 21, 2019, 07:49:25 AM
One thing, though not major, is that the M2 doesn't work well with a monitor. It doesn't even recognize it is being connected to one and won't connect. Not sure what the issue is here, works well with the original M, guess ill have to play around with it more.
I think the A/V out has been crippled by Canon from the start with the M2. I haven't ever been able to get them to work except for using the wireless functionality and an iPad. I was holding out hope that they didn't actually cripple it via hardware....
--Jon
Thanks Jon,
yeah thats a shame, though not a big deal. Thanks for the response. :)
Hi, my EOS m2 is about to arrive in 2 days (including a external monintor)
I can't wait to test this out.
I lens I got is 17-40 & 50 1.4
Also I have eos m1 in the same time, it is excited to have a compare between these two models since there aren't many video about this.
Quote from: ZEEK on July 22, 2019, 12:22:25 AM
Thanks Jon,
yeah thats a shame, though not a big deal. Thanks for the response. :)
Good News! I was wrong! (As I often am) I discovered that having wi-fi enabled on the device disables the HDMI output. I haven't tried the usb connection as I don't think I have the proper cable.
--Jon
Cool to know! I'll give it a go and see how it plays out :) Thanks. Would be a game changer.
From what I get:
The AF system works well during recording the raw video
by using the settings:
mv 1080p_rewired on (12bit 16:9)
RAW Video on
Sound record on
All the Modules are loaded
with 50mm F1.4 @1.8
Used "crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_2019Jul07.EOSM2103.zip" by Danne
Here is the video: https://youtu.be/tohVR083V5M
However, I found that the camera will dead after record the raw video (Menus are available, but no images on the display. Won't fix by enter into the canon menu and exit)
And screen may froze after enter into the ML menu and exit (only once during my test).
The build is still kind of unstable, some problem like randomly black display or frozen; but a big thanks to you guys, the progress is so far so good
Also I found the focus pixel can not be removed even in the latest MLV APP
GOOD JOB GUYS
See reply #576 for better performance.
I see...there are even more interesting models lolll
I will test it for a while and give you guys feedbacks
Quote from: Aperture Science on July 25, 2019, 06:32:57 PM
Also I found the focus pixel can not be removed even in the latest MLV APP
Really? I could remove all focus pixels from EOS M2 MLV (mv1080p) files from 14 days ago without any problem. Have you installed focus pixel maps?
I could get rid of focus pixels since day one of using ml with the M2, even with 3x3 chroma smooth they're all gone!
I used Danne's July 07, but copied the crop_rec and replaced it into DForts July 06 Crop_rec. Works as good as the M now, with zero pink frames even with a monitor. Amazing Camera cheers to the team :)
Hi guys!
I saw this fantastic project 2 days ago, and then I bought a pre-owned EOS M2 ,even I had a EOS M at the same time.
I know a little about camera, video, coding, and so on. I will test this ML on EOS M2 and give feedback to you.
I hope I can help.
thank you very much for all the people who work in this project!
Quote from: masc on July 25, 2019, 07:11:22 PM
Really? I could remove all focus pixels from EOS M2 MLV (mv1080p) files from 14 days ago without any problem. Have you installed focus pixel maps?
interesting...I am using MLV APP v1.8 and I noticed there are many fpm files in the folder. Let me see if these can be installed into the MLV APP
Quote from: Aperture Science on July 26, 2019, 12:03:30 PM
interesting...I am using MLV APP v1.8 and I noticed there are many fpm files in the folder. Let me see if these can be installed into the MLV APP
->
Quote from: masc on July 23, 2019, 04:31:09 PM
https://www.youtube.com/watch?v=fYqSavtita0
Quote from: Aperture Science on July 25, 2019, 06:32:57 PM
The build is still kind of unstable...
I'm surprised it is somewhat usable. Seems the most success is by using my latest builds with Danne's crop_rec module from his EOSM2 build. I tried merging to get Danne's more advanced EOSM2 settings but there are way too many conflicts and it will regress some things that we don't want to regress. Since it is "only" adding mcm_mv1080 and anamorphic_rewired it shouldn't be that hard. The hard part is keeping up with Danne's changes without breaking anything that is already working.
Maybe easiest to put in my rewired presets into your branch so at least those will work and then keep going from there?
Done (https://bitbucket.org/daniel_fort/magic-lantern/commits/20cffb3bdd194208418d3d067d48dbd0f1525ac2) -- I think. Haven't had time to try it but it looks like there are some willing testers out there.
Nice. Will check later. Did you upload a build?
Quote from: Danne on July 26, 2019, 10:14:44 PM
Did you upload a build?
Yes - on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/).
New Settings July 26 Build has a few problems:
- New zoom modes are cool and work smoothly
- Shutter speed is working fine (1/49 compared to 1/56)
- The resolution has gone down from 1736x956 to 1736x568 or somewhere around there.
- When Global draw is on, pink frames are everywhere through the frames.
- Crop Mode Bid Depth is a "no-go zone". Enable it, and the whole image will go very dark with pink clipped areas in the highlights.
- Must enable 16:9 in Crop sub-menu otherwise image is black.
- When recording normally, in MV_1080, it has the anamorphic stretch with focus pixel dots all over the frame.
*Busy right now, but ill see if I can upload some MLV's sometime soon...
Hm, not sure how dfort implemented stuff here but there are still plenty code missing. I can take a look later.
Ok, pushed a lot of missing code into dfort branch. Feel free to test the crop_rec presets:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul27.EOSM2103.zip
Thanks, ill give it a go. :D
Danne July 27 EOS M2 Build Tested:
Works good, pretty weird results actually:
- Each time you restart the camera, you must enable "movie crop mode" as it is automatically set to "off" each time
- Oddly enough, the camera can now record with a "1.55x" crop [1800x1012] instead of the usual 1.61x and the footage looks fine on MLV App.
- shutter 1/45, 1/55 (Wouldn't mind using 1/45 if it weren't for the flickering lights in the ceiling)
https://drive.google.com/file/d/1-52gfqH2zjQhBNI9oWUiw_MjWwCkZwLp/view?usp=sharing
* Focus modes:
- "Focus Aid" becomes creates a blank white screen when half-pressed
- x3 Toggle won't work when pressing the down button (maybe interfering with "preview"?)
- x3 crop works
https://drive.google.com/file/d/1bsDIFAjpo6A0-QRRRl2Z-FNfuVC4CilI/view?usp=sharing
Great work though..
If that 1.55x crop [1800x1012] could be a kept resolution of the M2, that would be amazing...
Oki, thanks for feedback. Will check some more later.
The resolution 1800 is not true when checking files in mlv app. Will have a border.
The other features talked about is not looked into yet.
Edit: was 10bit working?
Yes, 10-bit is working now :)
My experience with the previous build pretty well matches Zeek's report. Only thing to add for me was I couldn't get 25fps without selecting fps override. In the previous build I could get 25fps just by selecting it from mv1080p preset options.
--Jon
Thanks for testing and giving feedback. Here´s another version:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul27.EOSM2103.zip
I expect the mcm rewired mode to be working but please also try the anamorphic mode. Dfort seemed to have disabled raw_slurp buffer so I assume this will cripple anamorphic resolutions. Please report what is working and not with these two modes. Not working is x3 toggle and focus aid.
Quote from: Danne on July 27, 2019, 05:29:25 PM
Dfort seemed to have disabled raw_slurp buffer so I assume this will cripple anamorphic resolutions.
Right, a little more stable but less resolution. Things were much simpler with just the basic crop_rec setting (720p buffer with 3x3 sampling).
Quote from: Danne on July 27, 2019, 05:29:25 PM
Thanks for testing and giving feedback. Here´s another version:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul27.EOSM2103.zip
I expect the mcm rewired mode to be working but please also try the anamorphic mode. Dfort seemed to have disabled raw_slurp buffer so I assume this will cripple anamorphic resolutions. Please report what is working and not with these two modes. Not working is x3 toggle and focus aid.
switching x3 crop on/off causes white screen or lined screen forcing a couple of menu presses to resolve. No big deal...
https://www.dropbox.com/s/7m94xn6hru6kacf/IMG_6308.JPG?dl=0 (https://www.dropbox.com/s/7m94xn6hru6kacf/IMG_6308.JPG?dl=0)
https://www.dropbox.com/s/r9gg2a4mezdffkr/IMG_6309.JPG?dl=0 (https://www.dropbox.com/s/r9gg2a4mezdffkr/IMG_6309.JPG?dl=0)
resolution is fine
magic zoom with half press works fine for me
shutter still 1/45, 1/55
Can't offer much in the way of anamorphic mode other than to say it does 'stretch' the image and everything else seems to work as above. I do not have anamorphic lenses to test.
This is a thing of beauty guys...thank you!
--Jon
Quote from: dfort on July 27, 2019, 08:21:04 PM
Right, a little more stable but less resolution. Things were much simpler with just the basic crop_rec setting (720p buffer with 3x3 sampling).
First I want to test what works with raw_slurp disabled. Then we simply enable and see where it leads.
@jonkjon
"resolution is fine"
Do you mean mcm rewired is working as it should? I want to know that the presets works as is selecting the different ratios in crop mode sub menu.
Anamorphic mode is a different beast. No special lens is required but it will probably max out on resolution so maybe next step will be to test a build with raw_slurp enabled. BEst scenario will be if this would work for these two presets but I suspect maybe that is what´s causing the black screen between takes.
x3crop. I have not looked into any extras yet. If you´re lucky things will work but don´t expect anything besides bitdepth and ratios to fully work atm.
Quote from: Danne on July 27, 2019, 10:18:23 PM
@jonkjon
"resolution is fine"
Do you mean mcm rewired is working as it should? I want to know that the presets works as is selecting the different ratios in crop mode sub menu.
.....
Yes. mcm rewired appears to be working fine. As best I can tell, the presets work with all the different ratios.
--Jon
Thanks man. Will get back about raw_slurp build tomorrow.
Tested the new M2 Build from the link:
MCM Rewire:
- Shoots 1736x976, but it has the black border towards the right side that appears when using the 1800x resolution.
- FPS 1/45, 1/55
4k Anamorphic Mode:
- Works fine like the on the M (Quality looks as good as Forrest Gump [1994])
Here is a question: how could you guys get a x1.55 crop on a sensor have physically x1.61 cropped?
That is amazing
Quote from: ZEEK on July 28, 2019, 02:52:03 AM
Tested the new M2 Build from the link:
MCM Rewire:
- Shoots 1736x976, but it has the black border towards the right side that appears when using the 1800x resolution.
- FPS 1/45, 1/55
4k Anamorphic Mode:
- Works fine like the on the M (Quality looks as good as Forrest Gump [1994])
Could you upload one MLV from mcm (1736x976) and one from anamorphic set to 16:9 or 2.39:1?
Yep..
MV_1080 Rewired [1736x976]:
https://drive.google.com/open?id=1X8hVd704MP8BlXd7vwnx9ES67Y6MRLY7
4k 2.39:1, 10 bit
https://drive.google.com/open?id=127P9tYmftNBFQsYmsLWJn9YncBx89GI6
Thanks for files.
Yes, anamorphic mode is not recorded with full buffer.
The right border on 1736x976. Are you sure this isn´t the case with when you replace my crop_rec.c into dfort older build? Could you check just to make sure?
I think next is to enable raw_slurp again and test what happens. Stay tuned.
Here is a build with raw_slurp enabled:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul28.EOSM2103_raw_slurp.zip
Please test mcm rewired and anmorphic to see if it works or not. Maybe also upload two sample files.
Quote from: Danne on July 28, 2019, 09:15:49 AM
The right border on 1736x976. Are you sure this isn´t the case with when you replace my crop_rec.c into dfort older build?
*Yes, this wasn't the case. When I merged your crop_rec into Dforts Build, the resolution was fine.
I shot a short video with the previous builds on the M2, never experienced the right borders. This was shot using MV_1080 Rewired, 16:9 (crop bars in post):
https://www.youtube.com/watch?v=XkDfcOPzRpw&t=61s
It's gone dark where I am now, unless other users can test it. I'll give the build with raw_slurp enabled a test sometime soon and see how it plays out.
Quote from: ZEEK on July 27, 2019, 04:35:24 AM
New Settings July 26 Build has a few problems:
- The resolution has gone down from 1736x956 to 1736x568 or somewhere around there.
Can´t remember but is resolution different in older build? Need a comparison file. Shouldn´t affect right borde though. Hm, Hard to work witout the camera. Word is out dfort is sending me his m2 to Sweden :P
Quote from: Danne on July 28, 2019, 11:14:05 AM
Can´t remember but is resolution different in older build? Word is out dfort is sending me his m2 to Sweden :P
No, the resolution is the same on yours and dforts. I said 1736x568 as a "guestimation" from memory. It's always been 1736x976. Congrats with the M2, it's a great mirrorless camera :)
Yes, it´s a nice cam but a total shadow to it´s sibling eosm right now :P
Haha, true. I guess in the meantime, it's a simple camera for simple people ;)
I normally just use MCM rewire on the original m and am really impressed with it. I remember about a year ago, the aliasing on the EOS M looked like a candy shop.
The rest of the modes are a true bonus for a wide range of vintage lenses or if you want some more artistry in your footage.
RE: crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul28.EOSM2103_raw_slurp
Running in either mode (anamorphic or MCM rewire) the screen randomly goes black when stopping the recording. By randomly, I mean that it doesn't always do it. I would guess about 70% of the time. When it does happen, it requires a restart of the camera. No need to remove the battery. It appears that the recording is saved to the card despite the black screen.
I only tested in 16:9 and 2.35:1 with each preset
Occasionally, the bottom third of the screen will "blink" when starting a recording. Stopping the recording and a menu press or two gets it going again.
Almost all of the recordings contain flashing pink frames.
https://www.dropbox.com/s/3xpixbb3y8drso1/pink_frames.jpg?dl=0 (https://www.dropbox.com/s/3xpixbb3y8drso1/pink_frames.jpg?dl=0)
https://www.dropbox.com/s/o9jpt9jgnd8e1u7/M28-0944.MLV?dl=0 (https://www.dropbox.com/s/o9jpt9jgnd8e1u7/M28-0944.MLV?dl=0)
Hope this is helpful....
--Jon
Thanks. Yes, helpful indeed.
What happens when you film with the other build 1736x976 setting? Also getting that black space as ZEEK?
Hey all !
Received my M2 3 days ago (Got a huge deal : 22mm f2+18-55+50 f1.8 STM for 400€ :o) and i've been tinkering around with the builds since.
Haven't posted day one since i wanted to separate what was user error and what was actual bugs before reporting anything :)
So far the builds from Danne have worked the best when recording RAW from my experience.
I'll be posting as much as possible ;)
Quote from: jonkjon on July 28, 2019, 04:55:28 PM
RE: crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul28.EOSM2103_raw_slurp
Running in either mode (anamorphic or MCM rewire) the screen randomly goes black when stopping the recording. By randomly, I mean that it doesn't always do it. I would guess about 70% of the time. When it does happen, it requires a restart of the camera. No need to remove the battery. It appears that the recording is saved to the card despite the black screen.
I only tested in 16:9 and 2.35:1 with each preset
Occasionally, the bottom third of the screen will "blink" when starting a recording. Stopping the recording and a menu press or two gets it going again.
Almost all of the recordings contain flashing pink frames.
https://www.dropbox.com/s/3xpixbb3y8drso1/pink_frames.jpg?dl=0 (https://www.dropbox.com/s/3xpixbb3y8drso1/pink_frames.jpg?dl=0)
https://www.dropbox.com/s/o9jpt9jgnd8e1u7/M28-0944.MLV?dl=0 (https://www.dropbox.com/s/o9jpt9jgnd8e1u7/M28-0944.MLV?dl=0)
Hope this is helpful....
--Jon
I too experienced black screens, also got some preview freeze, the latter went away after reverting some settings back to default but not the former.
Only one of my three recordings got pink frames and corruption but it also went away after some tweaking.
Only used mv_1080 and was able to reach 1736x1156 14bit lossless 24fps without crop (When with previous builds i was limited to 1736x586 or something close to that). Didn't experience the black space that I got with the previous build.
Thanks for your efforts !
Quote from: Danne on July 28, 2019, 05:10:26 PM
What happens when you film with the other build 1736x976 setting? Also getting that black space as ZEEK?
Not seeing any black bars/space on the right edge or left edge shooting 1736x976 in either preset with the previous build. Maybe I don't know what I am looking for here....
--Jon
Sounds good.
Noticed some weird things with more tinkering around, these are not super important bugs and can wait, but fixing them is needed for the final experience :
1. Dual ISO in the crop_rec settings is not working. It's flickering but produces pink frames and isn't detected by MLVApp. Tried the one directly in the video menu (HDR Video), no flickering at all and pink frames too (Noticed that these pink, corrupted frames were hapenning every 2-4 images)
2. Sometimes when editing a setting the bottom bar is flickering (ISO or shutter speed for example)
3. The "Color scheme" (In Display>Advanced settings) option is working but flickers randomly, like it goes back to the unmodified color scheme and brightness
4. Shutter fine tuning is not working at all
5. I was curious about CPU usage and using the percentage indicator I noticed that when i was using ML overlays the CPU usage went right to 100% (And I only have Magic Zoom and Histogram enabled o_0)
6. When using Magic Zoom i can see focus dots
I also did a lot more test recordings and tests and got a lot more corrupted footage (Pink frames cut through like bellow), black screens and some random LV freezes
(https://i.imgur.com/cFQQuLQ.png)
And finally I have a question : Will it be possible once porting of the core (By core I mean the feature set that is available now) is stable and "over" to have the same recording modes as the original M (Like those shown bellow) ?
(https://i.imgur.com/WLJhDsA.jpg)
Quote from: GiacoAV on July 29, 2019, 12:04:26 AM
And finally I have a question : Will it be possible once porting of the core (By core I mean the feature set that is available now) is stable and "over" to have the same recording modes as the original M (Like those shown bellow) ?
(https://i.imgur.com/WLJhDsA.jpg)
I tried to move the crop.mo from eosm's firmware to eosm2's. However it doesn't work. Since these two camera are very similar, I believe it will come very soon.
New test video on the dynamic range of the EOS M2 with 14 bit-losses.
Because I put it on my bike...so it is shaky, sorry for that
However it shows a excellent DR. BTW this video is shooting under AF.
Also thanks "masc" for links to video and "d_fort"'s fpm files
Shutter speed == 1/54
FPS == 24fps
Aperture == f8
Lens == 17-40 f4
https://youtu.be/Z3iMnC3orPY
don't care about this floor, I wasted it
Tested Raw_Slurp Build for M2:
mv_1080 rewired:
- Max Resolution 1800x1012 (black border to the right side)
- (1736x976 cannot be achieved when lessening the resolution)
4K Anamorphic 2.39:1
- Works, but pink frames are consistent with 10 bit
Thanks. Let's skip raw_slurp for now.
The other version should be working normally not getting into 1800x when selecting mcm rewired. If you can, please test that as well only for mcm rewired 1736x976
This version:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul27.EOSM2103.zip
Yep. Cool will test tomorrow! Thanks :)
Quote from: Danne on July 29, 2019, 03:15:36 PM
Thanks. Let's skip raw_slurp for now.
The other version should be working normally not getting into 1800x when selecting mcm rewired. If you can, please test that as well only for mcm rewired 1736x976
This version:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul27.EOSM2103.zip
What works compared to last build:
- I didn't get the 100% CPU usage in LV (Still, around 95%)
- HDR ISO in crop_mode settings is working as it should without corruption
- Haven't got a black screen so far
- No corrupted footage or pink frames so far
What doesn't :
- Max resolution with mv1080 was reduced to 1736x1028 compared to raw_slurp 1152
- Color scheme is still flashing on and off
- Negative Digital ML ISO is not working, so is Shutter fine-tuning and Black Level, seems like the whole Image Fine-Tuning submenu is working :,(
- Bottom bar when editing a setting in seethrough mode is less flickery but a part of it is still flashing
- Dual ISO returns "ISOless PH err(8)" when enabled
Here's a test I did with two of my footage with the raw_slurp build :
(Excuse the bad focus pulling and shakyness)
Thanks for feedback. I am getting this cam eventually...
Nice movie! 1736x1156? Seems more like 2.39:1?
Quote from: Danne on July 29, 2019, 06:33:59 PM
Thanks for feedback. I am getting this cam eventually...
Nice movie! 1736x1156? Seems more like 2.39:1?
Thanks ! Was a quick test to mess around with skin color and detail in Resolve.
Yes it is, shot in 1736x1152 but cropped in post to customize my framing :)
I see. So it works kind of it seems with raw slurp build.
Quote from: Danne on July 29, 2019, 06:53:51 PM
I see. So it works kind of it seems with raw slurp build.
Kinda yeah, better resolution (By a small bit) but far less stable:)
Noticed now your question about other presets. All presets should be possible. However raw_slurp is needed and there´s some flaw here which is very hard to find. a1ex tried some where we noticed default buffer(canon) was working ok but raw_slurp was not. Still not found out why and who knows if it will ever happen...
While I know they may not be expected to work, I feel a bit foolish as I cannot even see options for 1736x1156 or 1800....I know I can change the ratios but I never see 1800 but do come close with 3:2 for 1736x1156. Am I missing something?
--Jon
Quote from: jonkjon on July 30, 2019, 12:41:12 AM
While I know they may not be expected to work, I feel a bit foolish as I cannot even see options for 1736x1156 or 1800....I know I can change the ratios but I never see 1800 but do come close with 3:2 for 1736x1156. Am I missing something?
--Jon
1800
without crop is impossible (As you saw in builds were it was it only added black pixels) as a 3x3 scan of the 18mp sensor (5208 x 3476) results in a max resolution or 1736x1158.
Using the raw_slurp build I was able to reach 1156 when using 3:2 aspect ratio, on the previous build it's limited to 5:3 (1736x1028)
Hope it answers your question ;)
1800x is only working with x3crop mode unmodified into mv1080p x1 mode. WHy it popped up before is an effect due to the roundtrip I am doing to get eosm cams working with regular mv1080p. It goes into movie crop mode but then sets cmos regs so we go back into mv1080p x1 mode.
The issue discussed is happening when restarting camera and the patch did not use movie crop mode. Then if added manually by pushing movie crop mode it would mix things up. Long story short. Should be fixed now ;).
Noticed two things :
- The first one i would like to see fixed asap : Even when "x3crop" is disabled in crop_rec digital zoom is enabled in the Canon menus, thus preventing the use of face tracking and flexizone AF :/
- The second one is about something i already reported : The "Color scheme" option is only flickering in ML menus, in LV and Canon menus it's working like it should.
Thanks folks for the explanation. Sorry for taking up valuable time with lame questions but curiosity gets the best of me. I understand now and greatly appreciate you taking the time to explain. Maybe it'll make me a better tester!
--Jon
@Danne Any news about dev on the M2 ? I see new builds on the M every 5 days or so but nothing on the M2 for more
than a week :)
Not that the builds that we have right now are unusable don't get me wrong, but that the better strategy is to work as much as possible on the M2 so it catches it's feature/rec mode gap than add features to both the M and M2, at least that's what I'm thinking, you're the dev and it's your schedule :D
Still, looking at evolution on the M and the newly added "Switch" menu i'm thinking about getting an M too (Get it hehe, "M too"/M2... I have to go)
Quote from: GiacoAV on August 07, 2019, 10:13:05 AM
@Danne Any news about dev on the M2 ? I see new builds on the M every 5 days or so but nothing on the M2 for more
than a week :)
Not that the builds that we have right now are unusable don't get me wrong, but that the better strategy is to work as much as possible on the M2 so it catches it's feature/rec mode gap than add features to both the M and M2, at least that's what I'm thinking, you're the dev and it's your schedule :D
Still, looking at evolution on the M and the newly added "Switch" menu i'm thinking about getting an M too (Get it hehe, "M too"/M2... I have to go)
I done all I can for the time being on this cam. Feel free to get manpower elsewhere if you are not able to help yourself.
The M2 is really good where it is at now and very stable The only pivotal issue I think is the shutter. The shutter speed increment is incorrect and flickers with indoor or night lights. Even with fps override 24fps @1/50 the street lights flicker. I guess it's a camera for the day :D ;D
Try and set to 25 fps either in crop mode submenu or in fps override.
Interesting stuff, thanks Danne! 8)
In the Crop Mode, I enabled 25fps and then set FPS Override 23.976 [Exact FPS] which now = 1/48 ~ 180* (No More Flicker ;D) Thanks!
What happens if you set canon menu to 25 fps as well?
25 fps ON Canon Menu - It becomes 1/46, 1/60 [with 23.976 fps Override]
25 fps ON Canon Menu - It becomes 1/41, 1/54 [with fps Override OFF]
25 fps ON Canon Menu - It becomes 1/48 [with 24 fps Override]
*The only thing with 25fps in Canon Menu is you cannot record continuous RAW.
Also, If im correct, you do also really appreciate Dannes work on his spare time ?for you to be able to use your own personal canon m2, right?
Dont forget this, he doesnt work for you. He works for his own interest.
""
If I could i would gladly donate to you Danne, but no way on how to do that yet.
Still interesting to follow all your input and enthusiasm, shining gold in the everyday life.
Thanks.
//Cheis
Quote from: GiacoAV on August 07, 2019, 10:13:05 AM
@Danne Any news about dev on the M2 ? I see new builds on the M every 5 days or so but nothing on the M2 for more
than a week :)
Not that the builds that we have right now are unusable don't get me wrong, but that the better strategy is to work as much as possible on the M2 so it catches it's feature/rec mode gap than add features to both the M and M2, at least that's what I'm thinking, you're the dev and it's your schedule :D
Still, looking at evolution on the M and the newly added "Switch" menu i'm thinking about getting an M too (Get it hehe, "M too"/M2... I have to go)
Quote from: Stousen on August 07, 2019, 06:09:57 PM
Also, If im correct, you do also really appreciate Dannes work on his spare time ?for you to be able to use your own personal canon m2, right?
Dont forget this, he doesnt work for you. He works for his own interest.
""
If I could i would gladly donate to you Danne, but no way on how to do that yet.
Still interesting to follow all your input and enthusiasm, shining gold in the everyday life.
Thanks.
//Cheis
Yes, yes and yes i know.
,,,,
I'm by no means different than you in that regard.
My message was by no mean a request for (r)evolution of the current M2 state. I was asking about the dev state, i'm glad i got an answer (Really quick too) and I was giving my opinion about a way to progress if there was so to be made.
The M2 is a very usable and stable camera as of right now and i'm very thankful for the work Danne, Dfort and others have made.
I'm currently in vacations (I hope that you do too and enjoy them) and will try to give a look and tinker around with a fork of Danne's work to try to help the community and M2 owners. Can't promise anything as the only programming language i know are Arduino and Visual Basic, i'm hoping it's C and that i'll understand it :D
Sorry for the misunderstanding, hoping to make it more clear next time, my objective is to give as much help as possible to push the project and community forward.
Cheers, Giaco
This cam is kind of in a vacuum state. a1ex could work out that freezing bug but it would probably mean going through a lot of code. Priorities.
Hi Danne,
I send you a personal email
please check :'(
I did not recieve anything in my inbox.
Hey Danne,
really enjoying testing the M2 at the moment and it's producing really nice videos. I was just wondering if the white level could be adjusted to 14200/15400 on the M2 as it seems to suffer a lot in this area?. The build I'm using is really good and stable with no issues, it's the merged crop_rec from yours and Dforts build of the M2. Thanks a lot!
M2 Build Using:
https://drive.google.com/open?id=1KrIoucZdcdJZbFeNXmAE6ZUoqdPQmpfm
I got an eosm2 from dfort yesterday. But I have very little time atm and doing other things so I see when I could take a look at this.
Cool. No problem, take your time! :)
I'm wanting to try this out. I just installed the version listed in Zeek's post on aug-24 at 2:58:09 and it crashed on startup, but eventually got through to let me play around a bit. is there a different recommended version at this stage or should i keep with this one?
Thanks for ALL of the help, this has been a tremendous amount of progress, so happy to see it come this far.
Quote from: Danne on August 24, 2019, 08:47:09 AM
I got an eosm2 from dfort yesterday. But I have very little time atm and doing other things so I see when I could take a look at this.
I'll be standing by w all of my support. M2 has been taken out of it's bag and will take a spin on this build 'EOSM2_dfort_2019Jul27.EOSM2103' from @Danne's Bitbucket for the time being.
Quote from: chrissul13 on September 02, 2019, 07:15:44 PM
Is there a different recommended version at this stage or should i keep with this one?
Dfort has a few on his page that you can try if you like.
Link:
https://bitbucket.org/daniel_fort/magic-lantern/downloads/
The one I'm currently using is a merged crop_rec between Dfort and Dannes Build and I haven't had any issues thus far. Been using it to record myself recently, very stable indeed. The only thing I see is "more" pronounced aliasing than the original M...but meh.
Good Luck!
Quote from: ZEEK on September 03, 2019, 04:58:43 AM
The one I'm currently using is a merged crop_rec between Dfort and Dannes Build...
I sent Danne my M2 in order to get that merge working on his experimental branch. In addition, I sort of hit a wall trying to get the M2 ported.
With Danne's help (and of course a1ex) the M2 went from a total disaster to a viable ML port. There's still some tough problems to work out before it can be labeled "stable" but it is getting there.
Here's the only thing i would like to see changed/fixed in the next build 🙂
Quote from: GiacoAV on July 30, 2019, 03:33:21 PM
Even when "x3crop" is disabled in crop_rec digital zoom is enabled in the Canon menus, thus preventing the use of face tracking and flexizone AF :/
Quote from: dfort on September 03, 2019, 07:44:06 AM
There's still some tough problems to work out before it can be labeled "stable" but it is getting there.
Yeah I heard you sent Danne an M2. Nice one!
I meant stable as in its record time. The Orange light barely blinks and playback doesn't require a reboot at times like the m.
But yes it still needs development in other areas.
Time schedule not known atm. It has a radioactive, piggy color to it as well :P.
Hi, I tried using Dual iso on the M2. What I found is the D-R increased from 10ev to 12ev with 100/400 option ON (which is exciting)
However, when I am using MLV App to process the video, I found these interesting lines:
https://youtu.be/B_HAzRzC_RE
I turned both fixing focus pixels and Dual iso options ON and these line appears. But if I only turn on the fixing focus pixels ON, there is not wired lines jumping anymore. I guess this because the MLV App first calculating the Dual ISO images than remove the focus pixels. I will trying remove the focus pixels first and output, than let MLV App calculating the Dual iso value, see what will happen.
MLVApp removes focus pixels before dual iso is processed.
Quote from: Aperture Science on September 09, 2019, 06:41:29 AM
I will trying remove the focus pixels first and output, than let MLV App calculating the Dual iso value, see what will happen.
How you want to do that? Exported MLVs still have focus pixels.
Quote from: masc on September 09, 2019, 04:40:40 PM
MLVApp removes focus pixels before dual iso is processed.How you want to do that? Exported MLVs still have focus pixels.
Remove the F-D first and output the dng
Than use dual iso dump
Quote from: Aperture Science on September 10, 2019, 05:55:30 PM
Remove the F-D first and output the dng
Than use dual iso dump
Quote from: Aperture Science on September 09, 2019, 06:41:29 AM
... than let MLV App calculating the Dual iso value...
Hm... but MLVApp won't import dng files.
Quote from: masc on September 10, 2019, 08:34:23 PM
Hm... but MLVApp won't import dng files.
Emmmmm...I can change setting to DNG-lossless in order to do that
Hello
Starting from Danne's branch
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959 (https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959)
I compiled for the EOSM2 model:
https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2019Sep14.EOSM2103.zip (https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2019Sep14.EOSM2103.zip)
I do not know yet if it is as functional as EOSM because I have not yet been able to do the tests.
@critix, what would be new with this September 14th ML on the M2? I use an old build now and then. It has mv1080 and 4k Anamorphic modes and works nicely. Thanks.
I used Danne's branch.
In the post https://www.magiclantern.fm/forum/index.php?topic=9741.msg220547#msg220547 (https://www.magiclantern.fm/forum/index.php?topic=9741.msg220547#msg220547) and
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959 (https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959) he describes what's new.
I'll give it a test as I have 2 EOS M 2's and can afford to lose one! :P
Quote from: critix on September 15, 2019, 10:27:37 AM
I used Danne's branch.
In the post https://www.magiclantern.fm/forum/index.php?topic=9741.msg220547#msg220547 (https://www.magiclantern.fm/forum/index.php?topic=9741.msg220547#msg220547) and
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959 (https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959) he describes what's new.
Interesting. Could you share the code for these changes to eosm2?
@critix
Tested it. It's not functional yet. No presets can be selected to record.
Quote from: Danne on September 15, 2019, 12:15:44 PM
Interesting. Could you share the code for these changes to eosm2?
Yes, I will share the code a little later, when I get to the laptop.https://bitbucket.org/ccritix/magic-lantern/branch/crop_rec_4k_mlv_snd_raw_only-EOSM2 (https://bitbucket.org/ccritix/magic-lantern/branch/crop_rec_4k_mlv_snd_raw_only-EOSM2)
Quote from: ZEEK on September 15, 2019, 02:26:23 PM
@critix
Tested it. It's not functional yet. No presets can be selected to record.
No preset because modules not loaded. Please load modules.
Hi all, newbie here. I've tried reading through this thread but I think I don't know enough to follow the current state of things, so pardon my asking... Is ML stable enough on the M2 if I mainly just want to use focus peaking? Are the instabilities people mention general problems that need to be solved, or are they problems with specific ML features?
Thanks in advance, and big thanks for taking on this project!
Quote from: critix on September 15, 2019, 03:33:05 PM
Yes, I will share the code a little later, when I get to the laptop.
https://bitbucket.org/ccritix/magic-lantern/branch/crop_rec_4k_mlv_snd_raw_only-EOSM2 (https://bitbucket.org/ccritix/magic-lantern/branch/crop_rec_4k_mlv_snd_raw_only-EOSM2)
No preset because modules not loaded. Please load modules.
Tested it too, it's very unstable, here's what i experienced :
- There's something weird hapenning with the ML menus, there's glitches all over like shown here (As you can see cache is locked too... Don't know if this is supposed to happen) : (https://i.imgur.com/uVuBEY1.jpg)
- Using this build (On my camera at least) is impossible as the camera randomly restarts without any reason :(
All modules are enabled and i'm on the right firmware revision, this different menu structure seems interesting though !
Quote from: GiacoAV on September 16, 2019, 08:50:26 PM
All modules are enabled...
No wonder it is unusable--enable only the modules you are testing out. Most of the modules aren't working on the M2.
Quote from: dfort on September 16, 2019, 09:06:57 PM
No wonder it is unusable--enable only the modules you are testing out. Most of the modules aren't working on the M2.
Tried that with only RAW + DualISO (Would show an error otherwise)
Also added LUA in another try
Stil reboots :P
hello,
I just got myself an EOS M2, planning to use it mainly for video. Thanks to all the devs who have put work so far into porting ML to the M2
What's the best ML build/config for it so far?
Also, my coding skills are quite basic but I'd love to help with any testing necessary.
https://youtu.be/ezeRCz9z7a4
I took another shoot to see if dual-iso works,
for this video I used 100/800 on the dual iso and get 14ev stops of DR
The result is amazing and beautiful, however the green line still exist.
I tried use my way which I mentioned before, it doesnt works. lol
Still, it is good to see this noise level and DR on EOSM2. Good job
Green line? Take off bit depth in the crop sub menu and keep aspect ratio 16:9. X3 crop works best for dual iso. No aliasing or artefacts. The only issue I have are the focus pixels. 3x3 won't cure them with both x3 & dual iso enabled...
Quote from: ZEEK on September 20, 2019, 03:04:56 PM
Green line? Take off bit depth in the crop sub menu and keep aspect ratio 16:9. X3 crop works best for dual iso. No aliasing or artefacts. The only issue I have are the focus pixels. 3x3 won't cure them with both x3 & dual iso enabled...
Yes, the focus pixels is what I mean. Focus pixels fix seems can not work with dual iso?
So what is the current write speed for the M2. I spent a few minutes looking but haven't come up with an answer.
Debating between buying the M or M2 and right now I seen an M2 for $152 which seems like a good deal compared to $130 for an M
Which do you recommend for RAW?
Which do you recommend for normal + continuous AF?
If you are after reliable continuous AF you should not consider buying a EOS M or M2.
Quote from: Walter Schulz on September 27, 2019, 02:36:55 PM
If you are after reliable continuous AF you should not consider buying a EOS M or M2.
To my testing... EOS M2's continuous AF is usable on the object that does not move too much, a interview for example.
However the EOS M indeed, do not have a reliable continuous AF even if the object is not moving.
EOSM2's AF system has been improved to the level which is usable.
https://youtu.be/LgIO7bQvFo4
Just for fun lol.
Anamorphic feeling
ISO 6400 and the noise level is acceptable :))
What's with all the download activity on the magiclantern-Nightly.2019Jul26.EOSM2103_new-settings build I posted on my downloads page (https://bitbucket.org/daniel_fort/magic-lantern/downloads/)? Does it actually work? Don't have this camera anymore to try it out.
1). https://drive.google.com/file/d/10yp_aeFTQlvALuI-pjjsw7TQVbV58p1J/view?usp=drivesdk
2).
https://drive.google.com/file/d/11412Iqgu3BTIk1ZpgLltK23l-5CNVGbn/view?usp=drivesdk
3).
https://drive.google.com/file/d/11ESHk9NH3CSrxNhP5zrHmSRwPa1Qc_UC/view?usp=drivesdk
Not a useable build at all (July26). The merged build is amazing, use it all the time, no issues with it, continuous recording, perfectly working with external monitors, MCM rewire works fine as well as 4k anamorphic and x3 crop, it just can't achieve 1/50. Increment is 1/43 - 1/56.
Some issues with this build:
- Way too many modules.
- Stuck at ~30fps
- Once raw video is recorded @16:9 1736x976 the footage playback looks like anamorphic with focus pixel dots everywhere.
Quote from: ZEEK on October 05, 2019, 12:01:30 PM
perfectly working with external monitors
I've just purchased an M2 and intend to install ML. Zeek, when you say perfectly working do you mean only with 480p setting limitation?
No, the 480p thing was with mv1080 a lot of builds ago before we had mcm rewire. It works with mcm rewire 1080 no need to set 480 on the monitor. The M2 works well with my different monitors such as the FOTGA A50T and the Feelworld 4K Monitor F570.
"WARNING" - Just make sure you "TURN OFF" Wi-fi when using an external monitor on the EOS M2, otherwise nothing will show up ;)
FWIW I finally went ahead and put the latest M2 build from danne's archive on mine. I mostly wanted focus assist features for my manual lenses, and those are working just as I'd expect them to. Focus peaking, zoom when the shutter's half-pressed, etc. Thanks for the great work of getting this going!
Quote from: ZEEK on October 06, 2019, 08:35:11 AM
No, the 480p thing was with mv1080 a lot of builds ago before we had mcm rewire. It works with mcm rewire 1080 no need to set 480 on the monitor. The M2 works well with my different monitors such as the FOTGA A50T and the Feelworld 4K Monitor F570.
"WARNING" - Just make sure you "TURN OFF" Wi-fi when using an external monitor on the EOS M2, otherwise nothing will show up ;)
Thanks Zeek.
I received my M2 last week. I've spent that time learning ML but was mystified why I could not achieve any higher than ~1376x5xx continuous, regardless of setting (I did a lot of testing with different settings). Even worse, the performance seemed to be slowly getting worse over time. From ~23-24MB/s down to 20-21. Never anywhere close to 30. I used a brand new 128GB Extreme Pro 95 UHS-I ordered from Ebay. Finally I decided to buy another card from a local electronics chain - this time a 64GB 170 Extreme Pro. Now I get 33mb/s and continuous no problem. I don't know if the 128 was fake or a bad batch being offloaded for cheap or just bad luck. But I thought it worth mentioning.
According to an unverifiable source around 30 percent of all SD-cards offered by non-official dealers are faked.
If you purchase a card from such a source a thorough after-buy check is mandatory (in all other cases highly recommended).
Check for faked speed specification:
- Fast cardreader + PC + a benchmark program like CrystalDiskMark (Windows) or Blackmagic Disk Speed Test (macOS).
You only need to run sequential R/W. Compare with benchmark runs from reliable sources like www.cameramemoryspeed.com
Check for faked capacity number:
- Cardreader + PC + h2testw (Windows) or f3/F3 QT (macOS)
If capacity info is altered by some crook you will get serious data corruption because cam will overwrite data recorded previously if physical storage limit is reached. Cam's firmware (and your PC, too) rely on card's info set to be correct and will not check if data set numbers and reality match.
Agree 100% with Walter here.
These sellers who sell fake copies are pathetic in their intentions. I've bought all my cards locally; SanDisk, Lexar PRO 1000x, you name it.
Even whilst I had the BMPCC I had cards that would work and some that wouldn't with it.
Key is to know the difference between the fake and real ones and run benchmarks as mentioned above.
The M2 is fabulous by the way, really loving the WiFi support for editing photos on the go in Snapseed.
Quote from: Walter Schulz on October 14, 2019, 11:02:28 AM
According to an unverifiable source around 30 percent of all SD-cards offered by non-official dealers are faked.
If you purchase a card from such a source a thorough after-buy check is mandatory (in all other cases highly recommended).
Check for faked speed specification:
- Fast cardreader + PC + a benchmark program like CrystalDiskMark (Windows) or Blackmagic Disk Speed Test (macOS).
You only need to run sequential R/W. Compare with benchmark runs from reliable sources like www.cameramemoryspeed.com
Ok, thanks Walter. With Transcend USB3.0 card reader I got:
SD 95 = Seq. Read of 92mb/s and 27mb/s write.
SD 170 = R 94mb/s and W 84mb/s.
I guess I got a fake one alright. Thanks for the info guys.
So i've been trying one of the versions that was put out here earlier and i really like it but i'm experiencing more than the normal amount of graphical glitches and i'm assuming i'm using an older version. wha'ts the latest and greatest? My version does do Raw and Focus peaking which were 2 things i really wanted, but it hangs or crashes more than what anyone else is mentioning.
Thanks for the help, amazing work on this
Latest and greatest are usually located in @Danne's bitbucket download page:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/
In this case not so. For now I refer to ZEEK who uses a mixed build.
Sorry, no time atm for this cam.
Could someone explain what exactly 4k Anamorphic means as used in the M/2? I am trying to read as many threads as I can but it's hard to trace origins/definitions of terms. For instance I'm playing around with the M2 and I see I can turn on 4k Anamorphic at x3 Crop with Raw set to 1736x868 (2:1).
x3 Crop I understand, Raw mode I understand, but '4k' Anamorphic isn't clear to me (yes, I know what traditional 'anamorphic' means).
Could someone shed some insight? It would be much appreciated.
Whatever it means, I was able to record about a min straight at ~54MB/s.
You can read about what´s going on with the regular 1st gen eosm:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959
These presets mostly don´t apply to the eos m2 atm. If you really want it working you need to take the long route and learn about compiling and to understand the code around magic lantern. There are also specific issues with eos m2 such as freezes, only working stable with raw_slurp disabled etc. Not solved yet so don´t expect too much here.
Quote from: Danne on October 17, 2019, 09:55:30 AM
You can read about what´s going on with the regular 1st gen eosm:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959
These presets mostly don´t apply to the eos m2 atm. If you really want it working you need to take the long route and learn about compiling and to understand the code around magic lantern. There are also specific issues with eos m2 such as freezes, only working stable with raw_slurp disabled etc. Not solved yet so don´t expect too much here.
Thanks. I don't necesarrily need it working, just wanted to know how what it meant/how it works. I think I found the relevant information after more searching.
I have an EOS M on the way, since it looks like that's where the bulk of development is right now.
I had raw working exactly like i wanted and loved it...then i recorded stuff today and the files completely disappeared. The space is 'used' on the card but i cannot seem to locate them. Any recommendations on how to scan for the MLV files? I was able to see them in the camera viewer before i pulled the card out but now i can't find a trace.
Quote from: chrissul13 on October 23, 2019, 01:08:17 AM
I had raw working exactly like i wanted and loved it...then i recorded stuff today and the files completely disappeared. The space is 'used' on the card but i cannot seem to locate them. Any recommendations on how to scan for the MLV files? I was able to see them in the camera viewer before i pulled the card out but now i can't find a trace.
Look at the name of the file in the mlv_play, and search it in your computer
Hey guys, I was just wondering if there is at all any way we could get 2.5K working on the EOS M2? If Not, that's okay, but it would be cool to see if the M2 could record for longer in this mode. Cheers! 8)
Longer? How so?
Isn't x5 zoom enabling 2.5k already?
The EOS M for me requires a warm up, at least one recording upon startup, before it can record continuously (it may be just my experience), but the M2 barely ever stops. Even with 14 bit raw (not lossless it has recorded a good length) so i was just guessing that the m2 may perform well with 2.5K @full resolution dunno.
About the x5 zoom, I can't find that feature anywhere (looking for the magnify glass). I'll see if I can download the m2 manual. But looking at the live view and cycling through info all I can find is digital zoom 3-10x.
Hello all.
i tried this build: crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul27.EOSM2103.zip
I found that I can't enter into ML menu if the dial on mode 2 and set custom function - trash button function (C.FnIV 6) into one of these two:
1:Depth-of-field preview
2:ISO speed
regards
Quote from: itx on November 07, 2019, 05:19:51 AM
Hello all.
i tried this build: crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul27.EOSM2103.zip
I found that I can't enter into ML menu if the dial on mode 2 and set custom function - trash button function (C.FnIV 6) into one of these two:
1:Depth-of-field preview
2:ISO speed
regards
I think that's to be expected, because you've remapped the function of that button? In any case, it should work if you switch to movie mode first (as a workaround).
Quote from: ZEEK on November 06, 2019, 11:49:50 PM
i was just guessing that the m2 may perform well with 2.5K @full resolution dunno.
Yes, I sense the force is strong with the M2.
Quote from: Wushuliu on November 08, 2019, 10:53:57 PM
Yes, I sense the force is strong with the M2.
It may have the "High Ground" ;D
Doing some head to head comparisons with M2 v. M. M2 shows focus dots, even with pixel maps loaded. I use 3x3 Chroma smooth, which helps to a great degree however when watching footage on a large 4k TV, banding is still visible:
(https://lh3.googleusercontent.com/0cV5-GdqYIctpatGNuQuJHqyALOf5yBqmoz13OKx7Uzpfi2mQZSN_n0b3Kg-plcEDcKBXxxufAoowDeTMeg9Q37V3afw3W9ILEOQBbQirwBA0kLMews5MO1bpzb1_CrKnIHDIwpO2_gyzSgjUHO5rwt5e8s3rl_AHX3HrVCewrE3TEzmR2q2CR3_c5RwxcPiJkgFUX8EkZ6iAAX0ueYPwDJmDvsyaekJ3FNYBMrv_T5dqNqLuctWXSW5Xu4p_kD5MTZZZ_lNAqwwNn4NlG8e2wLjxPXXQm_Pf_8TPEx4kYj7aL-96yDEkp7RW6XrgYn85HZf5R2I9NKqyDvIirUUAr0--A_q-IPVBedQ1oIb0wKSxLpKb1YEsxWaBAreonlCGqWx7td6G7DPzqZusY_awJzRLA1qLG-lDQdAquz8I4_TmB5rVvENpHdU_g-RqqhFZqr2Laef_bLhwVM_N60xDJ6FWo3UAawyJuUzkCv7tBq37wB4XIYMmtULe8RKLtMz3npzuxencwatP1V65n3DEiZj3390Kt95qlQnHXcPcUybBQbNaCN7m2FFr6x0bANIfH3UQ5qB0ibGaL8Vp5aA75szuGj_B-30srhL6fsS_zlDSA9j5PYCYr6YVA5ZA3Ey20bx_-cN1Luo75PzlxehoIGR5tZQJ18h1Vt03cOSm-IpSHI2OTMfyx4=w583-h388-no)
It's harder to see with a still frame.
This is with MCMRewire 24fps 1/50 (sometimes 1/55) shutter speed at 400 ISO. But also present at 100 ISO.
For the M2, I copied all the focus pixel maps in the folder and dragged them into MLV App and now there are no more focus pixels/dots present in each file with the M2.
Quote from: ZEEK on November 20, 2019, 12:44:38 AM
For the M2, I copied all the focus pixel maps in the folder and dragged them into MLV App and now there are no more focus pixels/dots present in each file with the M2.
Yeah, I've tried that. Downloaded the repository, did a drag and drop of all the maps as well as pasting them in the same folder as mlvapp. No luck.
Are you using the merged M2 ML Build or DForts M2 ML Build?
Quote from: ZEEK on November 20, 2019, 02:01:33 AM
Are you using the merged M2 ML Build or DForts M2 ML Build?
Using the M2 build listed from your recent M2 Raw AF video (I recently rebuilt my PC and didn't want to hunt down my previous files on my other drive, so I just downloaded your link).
Ah cool! 8) The focus pixels appear usually in x3 crop mode or anamorphic mode on the M2. But none exist for the MCM Rewire MLV Files.
Hi, how is ML M2 development going? Does anyone deal with it? I really need the fixed dual iso. I using the 19.07.27. date build in which dual iso doesn't work.
Hi guys! I want to order M2 . I decided to switch from the first version to the second because of the size and autofocus :)
Does M2 support 256Gb of memory?
EOS M2 supports SDXC specs. SDXC storage limit is 2 TB.
Quote from: Walter Schulz on December 01, 2019, 02:53:32 PM
EOS M2 supports SDXC specs. SDXC storage limit is 2 TB.
is a Samsung EVO plus 128-256Gb memory card a good choice?
https://www.magiclantern.fm/forum/index.php?topic=12862.msg208719#msg208719
No idea if overclocking is working.
Quote from: Fadis on December 01, 2019, 07:56:50 PM
is a Samsung EVO plus 128-256Gb memory card a good choice?
One word: Terrible.
I have used this one before meant for my smartphone, but I used it on the EOS M as a test and it was the worst performer. You don't want micro sd.
Stick with Lexar PRO 1000x or SanDisk Extreme Pro. I've used both of these on the M & M2. No issues. My favourite is probably the Lexar PRO 1000x. I know we always aim to get the cheapest for best value, but sometimes you have to spend the extra bucks to get good, reliable products.
ZEEK, which Evo plus?
old (slow): MB-MC128DA/EU
new (fast): MB-MC128GA/EU
it was the orange & white one:
I think its the MB-MC128GA/EU
This one right here:
https://www.officeworks.com.au/shop/officeworks/p/samsung-evo-plus-128gb-microsdxc-memory-card-samcevo128?cm_mmc=Google:SEM:OW%7CShopping:PLA&istCompanyId=0403b0ba-0671-498f-aeb7-e2ff71b61924&istFeedId=ea709c9a-279e-40be-951f-2668243ec753&istItemId=wliawrqmt&istBid=t&gclsrc=aw.ds&&gclid=EAIaIQobChMIwrvyiO6V5gIVxhWPCh14TQilEAQYAyABEgJbefD_BwE
AFAIK they cannot be tell apart by visual inspection. GA's write rate is well beyond 80 MByte/s.
Ah right!..I don't have it anymore, so I won't be able to recall. ::)
with "crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul27.EOSM2103.zip" I found that when an outer monitor attached, EOSM2 have the trouble on the bad(pink) frames. But this doesn't appears on the EOSM. The problem of the image buffer? PS: the monitor is running on 1080p
Quote from: Danne on July 29, 2019, 03:15:36 PM
Thanks. Let's skip raw_slurp for now.
The other version should be working normally not getting into 1800x when selecting mcm rewired. If you can, please test that as well only for mcm rewired 1736x976
This version:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort_2019Jul27.EOSM2103.zip
Another News is this is the stablest version I ever used.
With 1080p monitor attached and 1600x863@14-bit(not losses), it can recording normally without bad frames.
With inside monitor, basically everything are so far so good.
This is a tip for future developing (if it keeps), this version is on the right track.
Never experienced bad frames before on the M2 with three different branded monitors I've used. Also never had issues with the current build I'm using for the M2. Works flawlessly. Great camera! ;)
Eosm will probably work as good with monitor if raw slurp is disabled.
@Danne, really? That would be superb. Is it easy to disable raw slurp? If raw slurp is disabled on the EOS M, I would wonder how anamorphic modes and 2.5k mode would behave...Cheers!
Disable raw slurp and all presets besides mv1080p and x5 zoom(non raw slurp)will break.
It´s defined for all presets now but I guess it could be undefined with mv1080p but low priority here. I never use monitors on eosm.
Yeah fair enough! Makes sense. Keep the M2 for monitors, and the EOS M for the fun stuff 😉👍
You know how it's like these days with film-makers, we all have to have monitors on our rig irrespective if we use them or not. 🤣
Cheers for the reply and keep up the good work. I recently got a 5D2 but I'm still hyped with using the M & M2.
Well, someone with code skills could undefine raw_slurp for specific purposes.
Yep!
Quote from: ZEEK on December 11, 2019, 09:44:24 PM
Never experienced bad frames before on the M2 with three different branded monitors I've used. Also never had issues with the current build I'm using for the M2. Works flawlessly. Great camera! ;)
How...? I have no trouble using the built-in monitor, but with a 1080p monitor attracted, problems are just all over the place. :'(
Using a merged M2 build from Danne and DForts M2Builds:
https://drive.google.com/file/d/1o6e0LMn7r3bbNj84O06ThT3qezL14iEf/view
Quote from: ZEEK on December 12, 2019, 11:59:29 AM
Using a merged M2 build from Danne and DForts M2Builds:
https://drive.google.com/file/d/1o6e0LMn7r3bbNj84O06ThT3qezL14iEf/view
This is cool!
Let me try out for this :) :) :)
Thank you!!!
Quote from: ZEEK on December 12, 2019, 11:59:29 AM
Using a merged M2 build from Danne and DForts M2Builds:
https://drive.google.com/file/d/1o6e0LMn7r3bbNj84O06ThT3qezL14iEf/view
Super stoked to try this. My M2 has not been very stable with previous tests. Not like the M1 anyhow.. That thing is a tank. Thank you Zeek, DFort and Danne for your amazing work in all of this. Do y'all have any funding / donation options?
Quote from: ZEEK on December 12, 2019, 05:58:53 AM
Yeah fair enough! Makes sense. Keep the M2 for monitors, and the EOS M for the fun stuff 😉👍
You know how it's like these days with film-makers, we all have to have monitors on our rig irrespective if we use them or not. 🤣
Cheers for the reply and keep up the good work. I recently got a 5D2 but I'm still hyped with using the M & M2.
Na....this is not working either, I am buying a HDMI hacker to force EOSM2 output a 480p signal in order to decrease the usage of the CPU. Lets see what will it do.
Quote from: ZEEK on December 12, 2019, 11:59:29 AM
Using a merged M2 build from Danne and DForts M2Builds:
https://drive.google.com/file/d/1o6e0LMn7r3bbNj84O06ThT3qezL14iEf/view
Hi @ZEEK -- hope you don't mind me asking but who did the merge for this and where exactly did it come from originally?
Really wanted to use ML on the EOS M2 as I loved the EOS M. Dfort had some M2 Builds and I think Danne had one. In communication with both of them in regard to the builds and their issues, they kept refining them. Dannes build had stuff that didn't work so well compared to Dforts and then the opposite. Placomf some of Dforts M2 ML Build Module/s into Dannes seemed to do the trick and then that was the "mergerd build" that is useable as you can see. No frozen live view or anything. All you need to do is couple tap menu in live view for refresh register.
*Shutter is usually 1/45 to 1/56 increment. So to get 1/50 you just set Original Shutter to "Full Range".
I would like to request that whenever someone has the time if they could please port 2.5K Raw to the EOS M2. Thanks a lot!
I am having a problem getting proper framing from live view as everything seems shifted down vertically when watching the recorded video compared to what was seen on the live view screen. It seems much worse especially when you use a 2.35:1 aspect ratio with crop marks cause you cant get the framing right without using the "Framing" option for Live View, but that is way too slow to use the camera like this I think. Is there anything else I can do? Thanks
Help please. I have an official version 1.03 (not a magic lantern)
She takes photos with manual lens not correctly. The image after the shot is much brighter than the one that is visible on the display at the time of shooting. This happens on all manual lenses. Because of the big difference, I can't properly expose the image. How to solve this problem?
Are there any older versions of firmware 1.02 on the forum?
Up. Hack bag:
this happens only in M mode, switching the camera to AV and TV mode, the brightness of the exposure on the screen and in the image become the same.
I want to try the old firmware.
Quote from: PitbulZil on January 20, 2020, 08:49:22 PM
She takes photos with manual lens not correctly. The image after the shot is much brighter than the one that is visible on the display at the time of shooting. This happens on all manual lenses
The EOS-M1 does not have proper exposure simulation when using manual lenses. Not sure if it is the same with the EOS-M2
However, it seems that Magiclantern can provide proper exposure simulation with the EOS-M1 and manual lenses (https://www.magiclantern.fm/forum/index.php?PHPSESSID=n50g3f2fho53d5107u9jhjekd45tr7uk&topic=9741.msg221910#msg221910). The trick is to go to the ML "Exposure" menu and disable "ExpSim" and enable "ExpoOveride."
I made a some cropmarks for the pixel shift that happens with vertical and horizontal live view compared to actual framing to compensate if anyone wants to test. Can't really do much about the horizontal pixel shift but it is good enough fixing the vertical since that shifts much more. This was only tested for 2.35:1 aspect ratio, mv1080_rewire, and 1736x738 on the EOS M2. I did not test other settings or cameras. Let me know if it needs adjusted at all. I couldn't figure out how to compress the .bmp for smaller file size from the instructions I found, but I'll give it another go in the near future. The first image has solid black bars, while the second has transparent bars. If you film in those settings with the M2, you shouldn't have to check your framing using these since it will match what you see on live view, for the most part.
https://drive.google.com/open?id=1tjSMb4GnqrPNQ_abCetMsANU9AI2XXft (https://drive.google.com/open?id=1tjSMb4GnqrPNQ_abCetMsANU9AI2XXft)
https://drive.google.com/open?id=1TXkRFLRbXAz_e6IJeSIvNV5B_1WmGKfB (https://drive.google.com/open?id=1TXkRFLRbXAz_e6IJeSIvNV5B_1WmGKfB)
To get 1/48 Shutter, set the Canon Menu to "1920x1080 > 30 FPS"... and the Magic Lantern Menu to "FPS Override > 24 (from 30) > Exact FPS". mv1080p_rewired Crop Mode and Raw Video 1736x738.
Google Drive shouldn't convert anything.
Quote from: names_are_hard on January 30, 2020, 02:08:21 AM
Google Drive shouldn't convert anything.
Yeah, I was just trying to use an image service without a bandwidth limit, but Google Photos probably has one anyway. I switched them to Google Drive download links.
Quote from: ZEEK on December 12, 2019, 11:59:29 AM
Using a merged M2 build from Danne and DForts M2Builds:
https://drive.google.com/file/d/1o6e0LMn7r3bbNj84O06ThT3qezL14iEf/view
Hallo zeek, i have m2 finally, and i have tried "M2 build from Danne and DForts M2Builds" but the result is my camera stuck after taking photo , and cannot record the video. I used SANDISK SDCARD EXTREME PRO 64GB 170MB S CLASS 10 SD CARD EXTREME PRO 64 GB 170 MBPS CLASS10. I have followed all your youtube tutorial regarding this M2 hack. thanks for your answer sir .
Quote from: John Deep on February 11, 2020, 01:29:15 PM
Hallo zeek, i have m2 finally, and i have tried "M2 build from Danne and DForts M2Builds" but the result is my camera stuck after taking photo , and cannot record the video. I used SANDISK SDCARD EXTREME PRO 64GB 170MB S CLASS 10 SD CARD EXTREME PRO 64 GB 170 MBPS CLASS10. I have followed all your youtube tutorial regarding this M2 hack. thanks for your answer sir .
Set camera to video mode, go into Magic Lantern Movie tab and turn off Crop Mode and Raw Video. Then you can switch to photo mode and should be able to take photos.
Anyone know if its possible to record in H264 but with the framerate override option so I can still get the true 24p? I can't seem to figure it out but not sure which options I should enable/disable. The reason I need H264 instead of raw is that I got 4 of these cameras that will be on tripods recording for 8 hours straight. If its raw that would be 1tb of data for each, requiring a $400 1TB SD Card for each. Thanks in advance.
Starting with the changes made by Danne to:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959 (https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959), I added support for EOSM2.
It's not finished yet ... there are some adjustments to be made, but it's functional.... I hope ;D
Download:
https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2020May19.EOSM2103.zip (https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2020May19.EOSM2103.zip)
Branch:
https://bitbucket.org/ccritix/magic-lantern/branch/crop_rec_4k_mlv_snd_raw_only-EOSM2 (https://bitbucket.org/ccritix/magic-lantern/branch/crop_rec_4k_mlv_snd_raw_only-EOSM2)
And for firmware version 1.0.4:
https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2020May21.EOSM2104.zip (https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2020May21.EOSM2104.zip)
Branch:
https://bitbucket.org/ccritix/magic-lantern/branch/update_to_EOSM2.104 (https://bitbucket.org/ccritix/magic-lantern/branch/update_to_EOSM2.104)
Last edit:
I changed some values in mlv-lite, and rebuilt ML.
Awesome Critix, thanks a lot
@Zeek: You think you can merge with the more stable merged build if needed?
Builds should be tested and reported working or not. I just tested @critix briefly but still default raw buffer only. A lot of functions not at all working. Not blaming anyone since porting is vast work. Still long way to go and main issues are not fixed yet.
The build I'm using is pretty good for the M2. Like the MCM Rewire 1080 Mode is working perfect and I like it. I'm not quite sure what the aim is to develop on the M2. Would 2.5K Mode be a possible option as a next step? To get it to the state of the M,...not sure how farfetched that idea is.
@Mythic Cinema, I'm not sure what the point of merging would be, as in what that would add. The build I'm using can shoot MCM 1080 fine.
I'll test it out anyway, but Danne has mentioned that the issues haven't been fixed yet.
I think I just misunderstood what was updated, but yea there is a lot of issues on M2 other than mv1080 raw. I think I'll just probably replace the cameras with M versions and keep one M2.
As much as I love the M2 for better low light, wifi photo transfer, etc. The M with ML right now is the better choice! Good luck! ;D
Quote from: ZEEK on May 22, 2020, 02:50:45 PM
As much as I love the M2 for better low light, wifi photo transfer, etc. The M with ML right now is the better choice! Good luck! ;D
I think the main reason there was never much interest is because they are Japanese exclusive cameras, which makes them less common. Even though they are technically a little better than the EOS M.
Could anyone, please, tell me what is the bandwidth of the M's and M2's card controller for write? What does show benchmark with the fastest SD card you can get?
Controller is running SDR50/DDR50: Around 50 MByte/s. That is without overclocking.
Fastest benchmark write speeds with overclocking: Around 67 MByte/s.
Fastest benchmark write speeds without overclocking: Around 43 MByte/s.
Almost the same as with 100D.
Quote from: critix on May 20, 2020, 08:04:28 AM
Starting with the changes made by Danne to:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959 (https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959), I added support for EOSM2.
It's not finished yet ... there are some adjustments to be made, but it's functional.... I hope ;D
Download:
https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2020May19.EOSM2103.zip (https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2020May19.EOSM2103.zip)
Branch:
https://bitbucket.org/ccritix/magic-lantern/branch/crop_rec_4k_mlv_snd_raw_only-EOSM2 (https://bitbucket.org/ccritix/magic-lantern/branch/crop_rec_4k_mlv_snd_raw_only-EOSM2)
And for firmware version 1.0.4:
https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2020May21.EOSM2104.zip (https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2020May21.EOSM2104.zip)
Branch:
https://bitbucket.org/ccritix/magic-lantern/branch/update_to_EOSM2.104 (https://bitbucket.org/ccritix/magic-lantern/branch/update_to_EOSM2.104)
Last edit:
I changed some values in mlv-lite, and rebuilt ML.
Your built for firmware ver. 1.04 prompts for firmware ver. 1.03, so I couldn't install it in my now firmware ver. 1.04 EOS M2.
hi everyone if it possible to make some fast fps modes on eos m2 48-50-60 fps in raw?
Yes, ML-SETUP.FIR is for version 1.0.3.
With version 1.0.3, the ML-SETUP.FIR is updated with which the bootflag is set. Then update to version 1.0.4 and use ML for version 1.0.4.
Unfortunately, there is no ML-SETUP.FIR for 1.0.4 yet.
Hello!
I installed recommended by ZEEK the M2 build from Danne and DForts M2Builds:
https://drive.google.com/file/d/1o6e0LMn7r3bbNj84O06ThT3qezL14iEf/view
But whenever you try to record RAW, stripes appear that are visible both on the preview in the camera and in the MLVProducer program.
What can it be and is it possible to fix it?
THX!
https://ibb.co/ykdCWB3
https://ibb.co/KrhM3PX
I'm just starting to shoot photos and videos on M2 with ML, trying, exploring the possibilities.
I have updated the version to 1.0.4. and installed ML. I shot for several days, then ML fell and now it does not start from this card. Writes logs, but does not start.
How should I reinstall it?
Should I reformat my card again and install ML for version 1.0.4?
Thank you in advance for your reply. I really want to shoot a video as soon as possible!))
It looks like I really need your help with my EOS M2 as well
1. I got camera with 1.0.2 firmware
2. Upgraded it 1.0.3
3. Installed ML (got link to it from Zeek's youtube video – thanks for that video)
4. It worked OK, when I used camera with 18-55mm lens...just one thing went wrong – I have assigned "trash can" button for Depth-of-Field reviewing and found, the same button have to be used for ML, so I removed that DOF and could access ML menu (I pushed "trash can" button a few times and it froze camera all that times)
5. I bolted on 11-22mm lens and camera froze on a first frame...I played with 11-22mm until camera started to display corrupted image (some pink stripes at the bottom of screen)
6. Tried to reinstall ML a few times with no success – now it freezes on a first frame even with 18-55mm lens...formatted card in camera and PC
7. Removed ML and it works as it should
8. Tried a few attempts to upgrade with 1.0.4, but camera is not recognizing firmware on a card and freezing
I like this camera and really want to install ML on it.
solved
1.0.3 firmware + merged ML works great, no issues for a couple days
After installation "Restore ML defaults" at "Config options"
Quote from: ZEEK on December 20, 2019, 07:32:49 AM
All you need to do is couple tap menu in live view for refresh register.
...not sure, how to do that - it wold be great if you explain it with more details
and there is a big surprise - Focus stacking is working :) reliability is not confirmed yet, but it works
a disappointing thing is the fact 11-22mm lens can not be used with ML - it was main reason to buy this camera
Everything is explained in this video:
https://youtu.be/T0UYMluXR0Q
Tapping the menu button a few times is necessary when the Liveview is in frozen state to unfreeze, or even before shooting a clip to avoid footage error.
Zeek,
Thanks a lot for quick reply. I watched it again, but could not find any steps you are doing for "refresh register".
Is M2 affected by something like M's shutter bug? Didn't wrote A1ex a "minimal" autoexec.bin for M to determine if it's a timing problem or not?
Which card type are you using, AVS? Have you tried to run ML with other cards?
Quote from: AVS on September 28, 2020, 08:27:46 AM
Zeek,
Thanks a lot for quick reply. I watched it again, but could not find any steps you are doing for "refresh register".
When the LV freezes, I'm pressing the Menu button a few times (until back to LV), this unfreezes the LV, then it works fine again (Liveview is not frozen).
Zeek, thank you
One more question - anybody using 11-22mm lens (or 15-45mm) with ML?
I've had the 15-45mm, quality is quite poor. I've seen good things from the 11-22mm though.. quality looks nice.
I already got 11-22mm and my question was, if it works with M2 + ML...mine is not working - it freezes camera when I put it on ...LED light is blinking red/yellow, when I push switch on
Maybe a link to a sample video could help. If you are in stills mode/photo icon on the M2, LV will freeze because you need to take off RAW Video, restart camera, then disable Crop Mode in ML Tab 3. For Video Mode, it should work fine, try enabling release without shutter in the custom functions menu, although it's probably not related, it could help with other lenses if already not enabled. Otherwise, it chould be the shutter-bug issue which I have never encountered before.
spent whole evening trying different combinations
here is what I found:
camera works fine with lens, which was bolted on in process of ML installation (not sure about firmware)...when I try to mount different lens (camera is off), it freezes camera when I switch it on.
It is the same situation with 18-55mm and 11-22mm - camera works with one lens only
It looks like camera registers lens at installation and can't register another one later
I have found that turning on autofocus with RAW locks up the cameras. as such, i can't use the stock lens since there is no real way to turn off autofocus.
Hello , can anybody tell if it possible to make some fast fps modes on eos m2 48-50-60 fps in raw?
Guys, thank you for all the effort to port ML to the M2.
The lack of wifi or USB remote shooting of the original M is the biggest downside of it for me.
I'm thinking of getting the M2 to replace my M because fo that feature, but not having the 2.5K RAW 24fps is putting me back. That's the mode i use more often (95% of the time).
Is anyone working on that port right now? (since the lastest build is from may 2020)
Quote from: vicenzzopaiva on February 02, 2021, 04:03:26 PM
Is anyone working on that port right now?
Sorry, but the answer is no.
Quote from: Fedor on August 10, 2020, 03:30:38 PM
Hello!
I installed recommended by ZEEK the M2 build from Danne and DForts M2Builds:
https://drive.google.com/file/d/1o6e0LMn7r3bbNj84O06ThT3qezL14iEf/view
But whenever you try to record RAW, stripes appear that are visible both on the preview in the camera and in the MLVProducer program.
What can it be and is it possible to fix it?
THX!
https://ibb.co/ykdCWB3
https://ibb.co/KrhM3PX
It happens to me too.
Can anybody help us?
Eos M2 1.03 with ML last versión.
If I record in h264 everything is fine
Happens when 1080p crop is activated
Thanks
Quote from: dangerbyte on February 27, 2021, 10:48:52 PM
It happens to me too.
Can anybody help us?
Eos M2 1.03 with ML last versión.
If I record in h264 everything is fine
Happens when 1080p crop is activated
Thanks
I have done tests. The problme is not in the ISO values. YOu Have to war luminous lenses. At High F values, noise appears. From 1.4 to 2.2 there is no noise. With F values greater than 3, noise appears.
Fix focus pixels!
Hello !
I have Canon EOS M2. I'd like to install ML on my camera, but.. My M2 is with 1.0.2. The only thing I could find is ML for 1.0.3. I tried to install 1.0.3..
I made format of the SD card, copy - paste the FIR file on the PC.. I've started to update the firmware and this caption appears :
(https://serving.photos.photobox.com/83335905b1b5581509e8b9cc21ce821a972a71e85fdce9f68b33c59a243bcd8cb168c037.jpg)
No OK button, no other options.. Just CANCEL.. After 9 minutes the green light got on.. 25 minutes after that the Canon goes out..
Please, tell me.. What to do ?
The OK button should be accessible by pressing one of your fingers on the OK button. The OK button is placed to the right of highlighted Cancel button.
Or use main dial to navigate to OK button (which will be highlighted) and press SET.
That's the problem. I see the button OK, but.. The button is not active. I try to push it in many ways but.. No chance..
I'm pressing at 3 o'clock too.. No access..
Madame Trash Heap told me that touchscreen and dial/wheel are deactivated for this function due to security. Press dial at 3 o'clock to access OK.
Canon provides PDFs with installation instructions within downloaded file. Follow the instructions. If in-cam update fails again try EOS Utility as described in PDF.
I remade the ML for the EOS M2:
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov17.EOSM2103.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov17.EOSM2103.zip)
The links below were no longer functional.
Quote from: critix on May 20, 2020, 08:04:28 AM
Starting with the changes made by Danne to:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959 (https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959), I added support for EOSM2.
It's not finished yet ... there are some adjustments to be made, but it's functional.... I hope ;D
Download:
https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2020May19.EOSM2103.zip (https://bitbucket.org/ccritix/magic-lantern/downloads/magiclantern-Nightly.2020May19.EOSM2103.zip)
Branch:
https://bitbucket.org/ccritix/magic-lantern/branch/crop_rec_4k_mlv_snd_raw_only-EOSM2 (https://bitbucket.org/ccritix/magic-lantern/branch/crop_rec_4k_mlv_snd_raw_only-EOSM2)
Last edit:
I changed some values in mlv-lite, and rebuilt ML.
Quote from: critix on November 24, 2021, 02:12:31 PM
I remade the ML for the EOS M2:
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov17.EOSM2103.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov17.EOSM2103.zip)
The links below were no longer functional.
Just to clarify, this version supports 2.5k raw and other resolutions/modes that the EOS M supports? Is there any differences in the firmware? Thanks for all your work on developing this!
Quote from: critix on November 24, 2021, 02:12:31 PM
I remade the ML for the EOS M2:
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov17.EOSM2103.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov17.EOSM2103.zip)
The links below were no longer functional.
This build does seem to enable up to 5K but when switching to video mode the screen becomes black and nothing is recorded but black. Switching back to photo mode however (1 or 2) it does show input.Anyone has a solution for this?
Hi New member here. A few questions regarding dev on the M2:
1. Is development of ML on the M2 dead at this point?
2. Is the build in the quote below (Nov21) the recommended/most stable build?
If not could someone please point me to it?
Zeek if you see this I also have the build from your M2 videos, but it is more than a year older than this build...
It seems I may have jumped the gun on getting an M2 if this is dead and there is no long term stable build.
A couple of things to note:
I only care about 1080P
Stable/working HDMI out to monitor would be a big plus
Focus peaking is nice
Thanks in advance for any help or even a reply ;-)
Quote from: critix on November 24, 2021, 02:12:31 PM
I remade the ML for the EOS M2:
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov17.EOSM2103.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov17.EOSM2103.zip)
The links below were no longer functional.
1) Yes
2) There are 2 builds available. If you tell me how to measure stability I may be able to answer this question.
Thank you Walter,
Stability for me is the ability to record 1080P RAW (10 bit or more) without dropped frames, pink frames, lock ups etc while having focus peaking and histogram on. Autofocus on is a plus as is audio recording. I will be using cards of sufficient speed (90+ mbs on my EOS M+ML Danne's build overclocked).
Stable HDMI out a plus in order to use a 5" monitor to help with framing/focus.
I have all of this on my EOS M (without stable HDMI out), but I am interested in the better low light performance and better AF of the M2 and I don't care at all about modes over 1080P.
I would love to try both builds as I have 2 EOS m2's on the way...
Thank you so very much for your help!
Eos M2 has some serious bugs. With some luck it´s able to record in 1080p if I recall correctly but it is very buggy.
Walter and Danne,
What if all I wanted was the extended feature set of ML (focus peaking, histogram, zebras, audio meters better live view info at bottom of screen etc) and didn't even TRY for the RAW modes?
Any idea if there is a stable M2 build for that.
BTW would be great if someone could link the 2 builds in a reply....
Thanks!
Quote from: psieg2 on January 06, 2023, 04:46:17 AM
Thank you Walter,
Stability for me is the ability to record 1080P RAW (10 bit or more) without dropped frames, pink frames, lock ups etc while having focus peaking and histogram on. Autofocus on is a plus as is audio recording. I will be using cards of sufficient speed (90+ mbs on my EOS M+ML Danne's build overclocked).
Stable HDMI out a plus in order to use a 5" monitor to help with framing/focus.
I have all of this on my EOS M (without stable HDMI out), but I am interested in the better low light performance and better AF of the M2 and I don't care at all about modes over 1080P.
I would love to try both builds as I have 2 EOS m2's on the way...
Thank you so very much for your help!
There are no stable builds. There were efforts made to port most functions from eos m and it mostly worked. Except it's buggy and livieview freezes constantly. If you follow the eos m2 thread you"ll see.
Better approach would be for someone to try and fix those serious bugs but it may require rechecking most stubs and code. Prior attempts did not solve the issues.
Danne,
Thank you for all you have done for the M, I am running your latest build on both of my M bodies.
I have an ask regarding the M2: If I could have ML for the M2 that gives me what your current M build does WITHOUT any RAW or higher bitrate capability I would be thrilled.
In essence I want the live view tools like histogram, zebras, and focus peaking... and the customized buttons so that I can set everything to work without touch (I use a loupe). Also The stereo recording level meters... I would be set.
I have no idea how big an ask this is and I am looking into compiling so I could do this myself, but think this may take me a while. It seems some of the things I want like the time counter and custom buttons are not just modules that I can drag onto the card (that I understand how to do!). In fact it seems none of what I want are modules and most of what I don't want ARE modules (RAW).
So would an M2 build that focused on offering some of the ML overlays be stable/possible. It seems from my reading on these forums that most/all of the funky instabilities come from pushing the BIT/RAW envelope...
The M2 with cinestyle is pretty great with just h264 1080P, but the cannon firmware lacks a lot that ML offers.
Thank you again, and feel free to tell me to go fish... you have done a great deal for all of us already.
What you test and get working is what is working at the moment. Why would it be otherwise?
I have no builds myself. All work on this from was from testing different stuff.
Hello guys, a newcomer here willing to test Magic Lantern on Canon eos M2.
I just tried with two different builds, the one provided by Critix (magiclantern-Nightly.2021Nov17.EOSM2103.zip) and the one provided by Zeek, with no success.
The Nightly build for M2 have no Live view, just black screen and the camera is doing strange noise as if it was trying to focus in the dark :), and Zeek's build does not start to record at all. Live view is working though. But the record button doesn't do anything.
In case the developer of Magic Lantern is reading this, please let me know how I can contribute with running tests on the Crop Mood build. That one looks the most promising of all.
It would be great if eos M2 can record at least 1080p in RAW and have a working live view at the same time.
The camera I have is in mint condition, the SD card is SanDisk Extreme Pro, so at least from hardware point of view there should not be any issues.
Thanks
We don't need testers, we need more developers :) If we do need testers, we will ask.
That said, I have an M2 and whatever build I'm using works well for the very light usage I use that cam for (just a webcam). It does glitch out a bit sometimes when I change modes or settings. It's not expected to be reliable, and nobody is working on improving M2 builds that I'm aware of.
Ive been working with a pretty stable version of eos m2 and I was wondering if anyone knew about a repository for the Focus Pixel Mapps? ( I did check the main repository)
I have some m2 Maps installed (I think there is like 18 or so) however I notice that on one of my files it still shows the focus dots in MLVAPP , and when I investigate it shows that it has loaded one (green) but it obviously is not the correct one. anyone post more somewhere ?
Thanks in advance.
I would grab the code from Mlv App and try add m2 in there. I think it's even represented in a basic way but uncommented. Enabling the cam then trying to simply use eos m maps to see if they will work.
good idea, will try. Thanks