Magic Lantern Forum

Developing Magic Lantern => Camera-specific Development => Topic started by: ariznaf on June 02, 2016, 09:27:03 AM

Title: Canon 80D
Post by: ariznaf on June 02, 2016, 09:27:03 AM
I have bought a Canon 80D right a few days ago.

I know it is to early to expect a magic lantern port for it, as probably no developer has one.

But hope is a human trait.

Is 80D hardware similar enough to 70D or 7DII in order to expect the port not being too difficult or lengthy?

I have read that the first thing developers need is a firmware image.

Is there a waty to obtain it?
Do we need to wait until a firmware update from Canon?
Title: Re: Canon 80D
Post by: Walter Schulz on June 02, 2016, 10:00:06 AM
Don't bother about firmware image.
Bother about DiGiC 6 featured. This will be the first ML port involving DiGiC 6.
This port will get as difficult and lengthy as you can imagine. It's a beastly task.
Title: Re: Canon 80D
Post by: violajsilver on June 03, 2016, 07:42:17 AM
The EOS 80D boasts a viewfinder coverage of approx. 100%. The newly-developed 45-point, all cross-type AF sensor and continuous shooting speed of up to 7.0fps makes it an excellent choice for capturing moving subjects. Movie shooting at a quality of up to Full HD 60p is also supported, and Dual Pixel CMOS AF, which makes it possible to achieve high speed AF during Live View shooting, has been enhanced to be compatible for use with all EF lenses. Remote shooting and image sharing with smart devices is also made simple as the camera supports Wi-Fi and NFC.
Title: Re: Canon 80D
Post by: ariznaf on June 05, 2016, 12:13:23 AM
Sorry to era that.

I would loke to teste ml for ten first time.
I was lookong for it in the 40d bit it dic note arribe.

Bit 7d ii has a digic 6 proceso top and ml is on the way...
Title: Canon 80D
Post by: a1ex on June 19, 2016, 09:01:51 PM
Current status:

Quote from: a1ex on June 18, 2016, 12:36:09 AM
My attempts to jump to Canon firmware failed on both 760D and 80D.

source (https://bitbucket.org/hudson/magic-lantern/commits/306fc3a33334)

Also tried to:
- identify the main firmware start address from the string "/_term" (tested on 7D2 in QEMU and on 60D; should work on all DIGIC 4/5 models)
- jump to 0xFFFF0000 (hivecs reset interrupt, tested on 60D, probably works on all DIGIC 4/5 models)
- jump to MEM(0xFC000000) (reset address for EOS M3 and M10)

All attempts resulted in black screen and camera locked up.

Then, from 7D2 thread:
Quote from: atonal on June 18, 2016, 09:41:36 AM
The LED blinks!

That means, our current options are:

Quote from: a1ex on June 15, 2016, 07:49:45 PM
I need some help from somebody willing to do a small hardware mod (details (http://www.magiclantern.fm/forum/index.php?topic=13746.msg168431#msg168431)). The FIR from the linked post won't work here, but I can prepare one for 760D (or any other DIGIC 6 camera) on request.

Quote from: a1ex on June 19, 2016, 08:57:33 PM
Meanwhile, I've found the LED address on 7D2 (http://magiclantern.fm/forum/index.php?topic=13746.msg168514#msg168514). It's unlikely to be the same address on other DIGIC 6 cameras, but it's likely to be in the same range. Therefore, we could try to poke a few addresses nearby [1] (https://chdk.setepontos.com/index.php?topic=1493.msg13469#msg13469) [2] (https://chdk.setepontos.com/index.php?topic=11316.msg111290#msg111290).

The second one is easier, so I'm looking for a volunteer to try it.
Title: Re: Canon 80D
Post by: zloe on June 20, 2016, 08:08:42 AM
Volunteer found, but I need some assistance. It would take me some time to prepare the fir file myself.

- zlo
Title: Re: Canon 80D
Post by: dinissilva on June 20, 2016, 02:44:11 PM
Hey,

I don't know much about coding!! But i own a Canon 80D, and you have my support any time!!

Dinis Silva
Title: Re: Canon 80D
Post by: dinissilva on June 20, 2016, 02:56:42 PM
I have tested the LED Adress on Canon 80D and...BLINKS!!
Title: Re: Canon 80D
Post by: a1ex on June 20, 2016, 03:02:57 PM
8)

Quote from: a1ex on June 20, 2016, 03:02:00 PM
The LED address is somewhere between 0xd20b0800 and 0xd20b1000 (source) (https://bitbucket.org/hudson/magic-lantern/commits/89f7063cd9460ab3942c86b8e219891e02abff73) (credits 1) (https://chdk.setepontos.com/index.php?topic=11316.msg111290#msg111290) (credits 2) (https://chdk.setepontos.com/index.php?topic=1493.msg13469#msg13469).

Looks like we no longer need the power supply hack :)

Next steps: http://chdk.wikia.com/wiki/Obtaining_a_firmware_dump#Hardware-software_solution

Please let me know once you have the hardware ready.
Title: Re: Canon 80D
Post by: dinissilva on June 20, 2016, 10:01:41 PM
I can try! But I gonna need some help!  :-X
Title: Re: Canon 80D
Post by: zloe on June 21, 2016, 07:56:25 PM
Ok, photo transistor connected to Audacity, ready to record.
Just need to attach it a bit better to the cam.
Title: Re: Canon 80D
Post by: can-on on June 22, 2016, 12:39:27 PM
Hi

An important question is do you think will be the 80d in 4k video ??
or what is theoretically expected resolution?

thx
Title: Re: Canon 80D
Post by: Walter Schulz on June 22, 2016, 12:47:33 PM
4k video is totally out of the question. Won't happen but for very, very short shots.
No ML enabled cam is able to do 4k continuous and it won't change for 80D, 7D2, 750D/760D.
SD-card interface is in the 100 MByte/s area and will therefore not outperform 5D3.
Title: Re: Canon 80D
Post by: can-on on June 22, 2016, 09:12:17 PM
ok thanks for the quick response.
Now can 80D,  MOV: 1920 x 1080p / 29.97 fps (90 Mbps) / 23.98 fps (90 Mbps)
                        MP4: 1920 x 1080p / 59.94 fps (60 Mbps) / 29.97 fps (30 Mbps)

what to expect, ML development ? 2,5K RAW Video ?

thx
Title: Re: Canon 80D
Post by: Walter Schulz on June 22, 2016, 09:19:20 PM
You can expect ML for 80D ready when it's ready.
Title: Re: Canon 80D
Post by: Welles on June 23, 2016, 12:40:52 PM
I would say 2,5K is very unlikely, especially in continuous recording. Do you have an idea of the SD card writing speed?

To get an idea of what is already possible with older DiGiCs, have a look at http://www.magiclantern.fm/forum/index.php?topic=6215.msg46857#msg46857
Title: Re: Canon 80D
Post by: DenW on June 25, 2016, 12:55:59 PM
Hi,

I also own the Canon 80D and am available for testing.
Please contact me via PM if interested.

Thanks!
DenW
Title: Re: Canon 80D
Post by: KelvinK on June 27, 2016, 11:45:49 AM
Quote from: zloe on June 21, 2016, 07:56:25 PM
Ok, photo transistor connected to Audacity, ready to record.
Just need to attach it a bit better to the cam.

Any news? All are waiting :)
Title: Re: Canon 80D
Post by: ariznaf on June 28, 2016, 12:00:24 AM
Great news to find you have been started working on the 80d.

I have not enough expertise in low level programming or electronics to help at this stage, but will try to help in testing as soon as an installable version is available.

I' ll keep an eye in your progress.
Thank you for your efforts
Title: Re: Canon 80D
Post by: yacenty on June 30, 2016, 10:19:01 PM
I have both 760d and 7d2
I can help
Title: Re: Canon 80D
Post by: OldMikeyJ on June 30, 2016, 11:43:34 PM
I've recently purchased an 80d and am willing to help in any way I can (mainly just testing a build). Please send me a msg if I can be of any assistance.
Title: Re: Canon 80D
Post by: a1ex on July 03, 2016, 09:02:15 PM
LED address identified, thanks zloe :)

https://bitbucket.org/hudson/magic-lantern/commits/6ea5fa498ef0
Title: Re: Canon 80D
Post by: mfituri on July 05, 2016, 09:06:54 PM
Hey, I have an 80D and would love to help. I know a thing or two about low level programming too.
Title: Re: Canon 80D
Post by: ccs86 on July 05, 2016, 09:27:20 PM
Exciting stuff!    :o 8)
Title: Re: Canon 80D
Post by: dinissilva on July 05, 2016, 09:47:10 PM
In deed guys let's give the developers some LOVE!! For the great work!!
Title: Re: Canon 80D
Post by: gsanchez922 on July 06, 2016, 04:38:35 AM
Hello I want to ask if you will work with 5Ds & R?
Title: Re: Canon 80D
Post by: _OLLE_ on July 06, 2016, 07:13:22 PM
Guys! please! it's not going faster because you are asking!
Title: Re: Canon 80D
Post by: ccs86 on July 07, 2016, 03:03:14 PM
Nobody is asking for it to go faster. All I see is people offering help, and appreciation.
Title: Re: Canon 80D
Post by: a1ex on July 12, 2016, 09:37:02 AM
Progress: zloe managed to dump the firmware using LED blinking :)

Early findings:

- the first address executed is *(uint32_t*)0xFC000000, just like EOS M3
- bootloader starts at FC000008, ARM code
- main firmware starts at FE0A0000, Thumb-2 code, and looks similar to 7D2 (http://www.magiclantern.fm/forum/index.php?topic=13746.msg147553;topicseen#msg147553)
- the bootloader prints progress in a way similar to LILO (https://en.wikipedia.org/wiki/LILO_%28boot_loader%29#Output): it prints "Boot" as the bootloader progresses, but in QEMU it just prints "Boo" :)

QEMU log so far:

FC000008: MCR p15,0,Rd,cr6,cr2,0:       RGNR <- 0x0
FC000010: MCR p15,0,Rd,cr6,cr1,0:      DRBAR <- 0x0
FC000018: MCR p15,0,Rd,cr6,cr1,2:       DRSR <- 0x3F
FC000020: MCR p15,0,Rd,cr6,cr1,4:      DRACR <- 0x320
FC000028: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x2001
FE020040: MCR p15,0,Rd,cr9,cr1,1:       BTCM <- 0x1
FE025884: MCR p15,0,Rd,cr6,cr2,0:       RGNR <- 0x1
FE02588C: MCR p15,0,Rd,cr6,cr1,0:      DRBAR <- 0x0
FE025894: MCR p15,0,Rd,cr6,cr1,4:      DRACR <- 0x329
FE02589C: MCR p15,0,Rd,cr6,cr1,2:       DRSR <- 0x3B
FE0258A4: MCR p15,0,Rd,cr6,cr2,0:       RGNR <- 0x2
FE0258AC: MCR p15,0,Rd,cr6,cr1,0:      DRBAR <- 0xBFE00000
FE0258B4: MCR p15,0,Rd,cr6,cr1,4:      DRACR <- 0x324
FE0258BC: MCR p15,0,Rd,cr6,cr1,2:       DRSR <- 0x29
FE0258C4: MCR p15,0,Rd,cr6,cr2,0:       RGNR <- 0x4
FE0258CC: MCR p15,0,Rd,cr6,cr1,0:      DRBAR <- 0xDFE00000
FE0258D4: MCR p15,0,Rd,cr6,cr1,4:      DRACR <- 0x324
FE0258DC: MCR p15,0,Rd,cr6,cr1,2:       DRSR <- 0x29
FE0258E4: MCR p15,0,Rd,cr6,cr2,0:       RGNR <- 0x5
FE0258EC: MCR p15,0,Rd,cr6,cr1,0:      DRBAR <- 0xEE000000
FE0258F4: MCR p15,0,Rd,cr6,cr1,4:      DRACR <- 0x329
FE0258FC: MCR p15,0,Rd,cr6,cr1,2:       DRSR <- 0x31
FE025904: MCR p15,0,Rd,cr6,cr2,0:       RGNR <- 0x6
FE02590C: MCR p15,0,Rd,cr6,cr1,0:      DRBAR <- 0xFE000000
FE025914: MCR p15,0,Rd,cr6,cr1,4:      DRACR <- 0x329
FE02591C: MCR p15,0,Rd,cr6,cr1,2:       DRSR <- 0x31
FE025924: MCR p15,0,Rd,cr6,cr2,0:       RGNR <- 0x3
FE02592C: MCR p15,0,Rd,cr6,cr1,0:      DRBAR <- 0xC0000000
FE025934: MCR p15,0,Rd,cr6,cr1,4:      DRACR <- 0x305
FE02593C: MCR p15,0,Rd,cr6,cr1,2:       DRSR <- 0x3B
FE025944: MCR p15,0,Rd,cr15,cr5,0:        idk <- 0x0
FE025944: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0x1005
FE020400: MCR p15,0,Rd,cr9,cr1,0:       ATCM <- 0x80000001
BooBTCM Start
MR[5]=00000001
MR[6]=00000011
MR[7]=00000000
MR[8]=00000018
MID=SAMSUNG
Erase FROM(start:0xFC080000,size:0x68)
Sector erase error
MEMIF Uncomplete


For emulation, I've used the Cortex R5 CPU in QEMU.

I'd appreciate if somebody would interpret the p15 registers listed above (you probably just have to look them up in the ARM ARM v7-A&R (http://liris.cnrs.fr/~mmrissa/lib/exe/fetch.php?media=armv7-a-r-manual.pdf)).
Title: Re: Canon 80D
Post by: tecgen on July 12, 2016, 12:41:07 PM
If MCR p15,0,Rd,cr6,cr2,0:       RGNR <- 0x0
is the same as MCR p15, 0, <Rt>, c6, c2, 0 ; Write Rt to RGNR
then I found the following section.

Quote
Accessing the RGNR

To access the RGNR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c6, <CRm> set to c2, and <opc2> set to 0. For example:
MRC p15, 0, <Rt>, c6, c2, 0 ; Read RGNR into Rt
MCR p15, 0, <Rt>, c6, c2, 0 ; Write Rt to RGNR

Do you need to know what RGNR and so on is?

RGNR = MPU Region Number Register
RGNR = MPU Region Number Register
DRBAR = Data Region Base Address Register
DRSR = Data Region Size and Enable Register
DRACR = Data Region Access Control Register
SCTLR = System Control Register (?)
BTCM =  B? Trapping Control Mechnism (?)
ATCM = A? Trapping Control Mechnism (?)

Title: Re: Canon 80D
Post by: a1ex on July 12, 2016, 01:01:59 PM
Yes, these registers show what memory ranges are configured for the memory protection unit, with what start address, what size, what access permisions and so on (in other words, the memory map).

You may fill the results on this page if you prefer: http://magiclantern.wikia.com/wiki/Memory_map
Title: Re: Canon 80D
Post by: tecgen on July 12, 2016, 01:18:57 PM
Done ;)
Title: Re: Canon 80D
Post by: nikfreak on July 12, 2016, 01:29:01 PM
 :P
Title: Re: Canon 80D
Post by: a1ex on July 12, 2016, 01:48:28 PM
404 ;)
Title: Re: Canon 80D
Post by: atonal on July 13, 2016, 07:48:31 PM
Added my interpretation of the memory mapping to the wiki.
Title: Re: Canon 80D
Post by: a1ex on July 14, 2016, 12:28:01 PM
Thanks atonal. I found a function in 80D firmware that reads these registers and decodes the base address, size and some access permissions:

[      init:fe237fa9 ] Memory region: start=00000000 end=00000000 flags=00000001
[      init:fe237fbf ] Memory region: start=00000000 end=00000000 flags=00000002
[      init:fe237fcb ] Memory region: start=E0000000 end=FFFFFFFF flags=00000020
[      init:fe237ffd ] Memory region: start=FE000000 end=FFFFFFFF flags=00000008
[      init:fe237ffd ] Memory region: start=EE000000 end=EFFFFFFF flags=00000008
[      init:fe237ffd ] Memory region: start=DFE00000 end=DFFFFFFF flags=00000004
[      init:fe237ffd ] Memory region: start=C0000000 end=FFFFFFFF flags=00000010
[      init:fe237ffd ] Memory region: start=BFE00000 end=BFFFFFFF flags=00000004
[      init:fe237ffd ] Memory region: start=00000000 end=3FFFFFFF flags=00000008
[      init:fe237ffd ] Memory region: start=00000000 end=FFFFFFFF flags=00000004
[      init:fe237e5f ] Memory region: start=00000000 end=FFFFFFFF flags=00000000


And here's CHDK cpuinfo log for the same memory regions:

MPU region 0 base 0x00000000
  Base address         0x0 0
MPU region 0 size & enable 0x0000003F
  Enabled              0x1 1
  Size                 0x1F 31 [4G]
  -                    0x0 0
  Sub-regions disabled 0x0 0 [00000000]
MPU region 0 access control 0x00000320
  Region attributes    0x20 32 [Inner Non-cacheable; Outer Non-cacheable; Non-shared]
  -                    0x0 0
  Access permission    0x3 3 [P:RW U:RW]
  -                    0x0 0
  Execute never        0x0 0
MPU region 1 base 0x00000000
  Base address         0x0 0
MPU region 1 size & enable 0x0000003B
  Enabled              0x1 1
  Size                 0x1D 29 [1G]
  -                    0x0 0
  Sub-regions disabled 0x0 0 [00000000]
MPU region 1 access control 0x00000329
  Region attributes    0x29 41 [Inner Write-back, write-allocate; Outer Write-back, write-allocate; Non-shared]
  -                    0x0 0
  Access permission    0x3 3 [P:RW U:RW]
  -                    0x0 0
  Execute never        0x0 0
MPU region 2 base 0xBFE00000
  Base address         0xBFE00000 -1075838976
MPU region 2 size & enable 0x00000029
  Enabled              0x1 1
  Size                 0x14 20 [2M]
  -                    0x0 0
  Sub-regions disabled 0x0 0 [00000000]
MPU region 2 access control 0x00000324
  Region attributes    0x24 36 [Inner Non-cacheable; Outer Non-cacheable; Shared]
  -                    0x0 0
  Access permission    0x3 3 [P:RW U:RW]
  -                    0x0 0
  Execute never        0x0 0
MPU region 3 base 0xC0000000
  Base address         0xC0000000 -1073741824
MPU region 3 size & enable 0x0000003B
  Enabled              0x1 1
  Size                 0x1D 29 [1G]
  -                    0x0 0
  Sub-regions disabled 0x0 0 [00000000]
MPU region 3 access control 0x00000305
  Region attributes    0x5 5 [Shareable device; Shareable]
  -                    0x0 0
  Access permission    0x3 3 [P:RW U:RW]
  -                    0x0 0
  Execute never        0x0 0
MPU region 4 base 0xDFE00000
  Base address         0xDFE00000 -538968064
MPU region 4 size & enable 0x00000029
  Enabled              0x1 1
  Size                 0x14 20 [2M]
  -                    0x0 0
  Sub-regions disabled 0x0 0 [00000000]
MPU region 4 access control 0x00000324
  Region attributes    0x24 36 [Inner Non-cacheable; Outer Non-cacheable; Shared]
  -                    0x0 0
  Access permission    0x3 3 [P:RW U:RW]
  -                    0x0 0
  Execute never        0x0 0
MPU region 5 base 0xEE000000
  Base address         0xEE000000 -301989888
MPU region 5 size & enable 0x00000031
  Enabled              0x1 1
  Size                 0x18 24 [32M]
  -                    0x0 0
  Sub-regions disabled 0x0 0 [00000000]
MPU region 5 access control 0x00000329
  Region attributes    0x29 41 [Inner Write-back, write-allocate; Outer Write-back, write-allocate; Non-shared]
  -                    0x0 0
  Access permission    0x3 3 [P:RW U:RW]
  -                    0x0 0
  Execute never        0x0 0
MPU region 6 base 0xFE000000
  Base address         0xFE000000 -33554432
MPU region 6 size & enable 0x00000031
  Enabled              0x1 1
  Size                 0x18 24 [32M]
  -                    0x0 0
  Sub-regions disabled 0x0 0 [00000000]
MPU region 6 access control 0x00000329
  Region attributes    0x29 41 [Inner Write-back, write-allocate; Outer Write-back, write-allocate; Non-shared]
  -                    0x0 0
  Access permission    0x3 3 [P:RW U:RW]
  -                    0x0 0
  Execute never        0x0 0


Side-note: the usual folks who were helping me are a bit busy these days; I'm looking for a volunteer to try a few things on 80D or 750D/760D.
Title: Re: Canon 80D
Post by: a1ex on July 15, 2016, 11:53:38 PM
(http://a1ex.magiclantern.fm/debug/portable-hello-world/80D/PALE180D.jpg)

8)
Title: Re: Canon 80D
Post by: dinissilva on July 15, 2016, 11:57:56 PM
Here back to do some tests!!
Title: Re: Canon 80D
Post by: Pierro777 on August 17, 2016, 03:37:45 AM
Picked up an 80d today. Let me know how I can help.
Title: Re: Canon 80D
Post by: hugovlnv on August 18, 2016, 11:53:27 AM
I'm hesitating buying an 80D right now just because I'm not sure how much time it'd take for ML to come out, probably quite a long way. Seems to be a great camera which could be made even greater with ML. Thanks for the appreciated work !

Title: Re: Canon 80D
Post by: a1ex on August 20, 2016, 12:22:27 PM
Please find a ROM dumper for 80D that does not require additional hardware:

DMPD_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/DMPD_80D.FIR)

Thanks zloe and Ant123 for confirmation.

The dumper is based on this code (http://www.magiclantern.fm/forum/index.php?topic=16534.0) and it saves 3 copies of the ROM, because the bootloader file I/O routines are tricky and sometimes they write invalid data. You only need one of the ROMs - check the MD5 sums to find out which copies are valid:


md5sum -c *.MD5


If it doesn't work, try a smaller card, or format it with an older filesystem (such as FAT12).

Please don't send me a copy of your ROM, I already have it. If your firmware version is not "1.0.1 6.2.2 9C(84)", please paste it. You can get the full firmware version with this command:

strings ROM1A.BIN | grep -C 2 "1\.0\.1"


To replicate my experiments in QEMU, duplicate the ROM contents to get a 64MB file, then run:


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


Happy hacking. I'll probably need some help writing self-modifying code on this ARM platform (Cortex R4 (http://www.magiclantern.fm/forum/index.php?topic=17714)), so if you already have experience with that, please get in touch with me.
Title: Re: Canon 80D
Post by: Pierro777 on August 29, 2016, 03:16:31 PM
If there a step by step or anything I can follow to help with this last step id gladly do it. I'm no programmer so the above post looks like gibberish to me. Sorry.
Title: Re: Canon 80D
Post by: vzhivkov on August 30, 2016, 07:29:51 PM
I'm a newbie. I just boght 80D and I'm so very sorry for that. I need it for many other reasons where Canon is great but I also need it for HDMI output and as I found out after I bought it that's not working as expected on 80D. So my question is whenever (doesn't matter when) ML for 80D is ready will it allow me to use HDMI out as clean HDMI? If it is not going to offer such thing I'd rather try to return the camera now until it is too late.
Title: Re: Canon 80D
Post by: Walter Schulz on August 30, 2016, 09:54:45 PM
ML has no "delivery date". Nobody is able to say how long it will take and if your cam is not supported by ML you should act like there will be no ML for your cam ever.
Top of page -> User Guide -> FAQ -> Troll Questions section
Same for features ...
Title: Re: Canon 80D
Post by: jtvision on August 30, 2016, 09:59:29 PM
Quote from: Walter Schulz on August 30, 2016, 09:54:45 PM
ML has no "delivery date". Nobody is able to say how long it will take and if your cam is not supported by ML you should act like there will be no ML for your cam ever.
Top of page -> User Guide -> FAQ -> Troll Questions section
Same for features ...

I have seen this quote several times in this forum. How many of your 4866 posts are copy paste of these, Walter Schulz? 
Title: Re: Canon 80D
Post by: Felipe on August 30, 2016, 10:17:46 PM
jtvision if you need ML functionality rareway, buy The Canon C100 Mark II only $4500,
The pleasure of using good things cost money,. ML Team is extremly generous
Title: Re: Canon 80D
Post by: jtvision on August 30, 2016, 10:26:18 PM
I am on this forum everyday. Because I am very curious of what developments are happening here. And developments are happening!
"if your cam is not supported by ML you should act like there will be no ML for your cam ever" is simply not true!
Title: Re: Canon 80D
Post by: Pierro777 on August 31, 2016, 11:04:48 PM
Can we stick on topic?

The devs do this out of the kindness of their heart. If you want ML on your camera like everyone else posting here offer to help...

That's the only way to get it.

If people are willing to chip in to get @A1ex a 80d id chip in.

Aside from that I could always offer to troubleshoot. I just don't know where to start.
Title: Re: Canon 80D
Post by: eduperez on September 01, 2016, 02:53:18 PM
Quote from: jtvision on August 30, 2016, 10:26:18 PM "if your cam is not supported by ML you should act like there will be no ML for your cam ever" is simply not true!

If you are thinking about buying a new camera and you positively need ML, do not buy one not supported now with hopes that it will be supported in the future; it may never be supported, and you will be stuck to an unsupported camera.

If you need ML for your project, and your camera is not supported, do not wait until it gets support, or you might wait forever and lose the opportunity to create your project.

...
Title: Re: Canon 80D
Post by: yostergeo on September 20, 2016, 02:46:09 AM
So I've been combing the web for help on this, but my 80D won't work with Canon Image Gateway.  Tells me it's not avilable in my region, despite me living in the US.  This is probably because i purchased a camera from the graymarket via Abes of Maine.  What i'm wondering is if I can flash my camera with the US version of the firmware.  If so how would I go about converting a US .bin dumped from an 80D to a .fir and would any of you be so kind as to send me your US .bin
Title: Re: Canon 80D
Post by: davicorn on September 22, 2016, 09:56:27 AM
Hi! What is the state of this?

I am a engineer and would love to help bring MagicLantern to the 80D. How can I help? :)
Title: Re: Canon 80D
Post by: a1ex on September 22, 2016, 11:53:10 AM
Boots in QEMU, but not on the actual camera (caching issues). Details on reply #40.
Title: Re: Canon 80D
Post by: Greg on September 23, 2016, 08:20:52 PM
80D File I/O stubs :

NSTUB(0xFE482A00 + 1, FIO_CloseFile)           // Thumb
NSTUB(0xFE4834CC + 1, FIO_FindClose)           // Thumb
NSTUB(0xFE48344A + 1, FIO_FindNextEx)          // Thumb
NSTUB(0xFE482880 + 1, FIO_ReadFile)            // Thumb
NSTUB(0xFE4828F0 + 1, FIO_SeekSkipFile)        // Thumb
NSTUB(0xFE482992 + 1, FIO_WriteFile)           // Thumb
NSTUB(0xFE482FEE + 1, _FIO_CreateDirectory)    // Thumb
NSTUB(0xFE4827AA + 1, _FIO_CreateFile)         // Thumb
NSTUB(0xFE4833B6 + 1, _FIO_FindFirstEx)        // Thumb
NSTUB(0xFE482AEC + 1, _FIO_GetFileSize)        // Thumb
NSTUB(0xFE482734 + 1, _FIO_Open)               // Thumb
NSTUB(0xFE482814 + 1, _FIO_RemoveFile)         // Thumb
Title: Re: Canon 80D
Post by: Marsu42 on October 04, 2016, 12:06:47 PM
Quote from: eduperez on September 01, 2016, 02:53:18 PM
If you are thinking about buying a new camera and you positively need ML, do not buy one not supported now with hopes that it will be supported in the future; it may never be supported, and you will be stuck to an unsupported camera.

... or something in between. As ML mostly relies on fw hooks or accessible variables, and there's no telling what Canon cooked up again, it's not certain what ML features will work or won't work ever. Combining the expanded dynamic range of the 80d with dual_iso would be a dream and beat Sonikon, but notice the "but".

So if you need something specific even a general "Look at qemu, ML will run on camera xyz sooner or later" announcement isn't enough to go ahead and purchase it.
Title: Re: Canon 80D
Post by: a1ex on October 04, 2016, 01:00:42 PM
Quote from: Marsu42 on October 04, 2016, 12:06:47 PM
Combining the expanded dynamic range of the 80d with dual_iso would be a dream and beat Sonikon, but notice the "but".

Even if dual iso will work (which we don't know yet), the gain will be small, probably about 0.5 stops at 100/1600. From DxO data (https://www.dxomark.com/Cameras/Compare/Side-by-side/Canon-EOS-80D-versus-Canon-EOS-70D___1076_895), I expect the 80D sensor at ISO 100 to be nearly as good as the 70D at say 100/800, without the resolution loss.

Quote from: Marsu42 on October 04, 2016, 12:06:47 PM
it's not certain what ML features will work or won't work ever

That's very true.

The 80D hardware is promising (1GB RAM (http://www.magiclantern.fm/forum/index.php?topic=5071.msg169727#msg169727), faster card speeds (http://www.magiclantern.fm/forum/index.php?topic=17067)), the firmware looks more or less familiar (the usual strings are present), but there's no way to tell what exactly will work, what will never work, and what will work only with significant research effort.

In any case, the 80D is most likely to say Hello World*) first, for the following reasons:
- I know how to start Canon firmware (same for 750D/760D, but this step doesn't work on 7D2/5D4)
- good testers available (with programming skills, likely to become developers)

*) The Hello World message should printed over Canon's GUI screen (in other words, by code running alongside Canon's firmware). The display tests you have seen recently are all standalone code (similar to the Linux port, if you want), so they are of limited use. They are proof we can run code on the camera, and this codebase provides a way to debug things with a little more than just LED blinks.
Title: Re: Canon 80D
Post by: Marsu42 on October 04, 2016, 11:59:24 PM
Quote from: a1ex on October 04, 2016, 01:00:42 PMEven if dual iso will work (which we don't know yet), the gain will be small, probably about 0.5 stops at 100/1600. From DxO data (https://www.dxomark.com/Cameras/Compare/Side-by-side/Canon-EOS-80D-versus-Canon-EOS-70D___1076_895), I expect the 80D sensor at ISO 100 to be nearly as good as the 70D at say 100/800, without the resolution loss.

Ugh!? How so? I understand the dr gain of the 80d is achieved by eliminating low-iso read noise, so higher iso values are just as they used to be - but still, an overlap should get us more than 0.5ev? https://www.dxomark.com/Cameras/Canon/EOS-80D---Measurements

And if dual_iso on 80d isn't really something to look forward to, it means even a ml'ed Canon doesn't reach recent Sonikon at all: https://www.dxomark.com/Cameras/Compare/Side-by-side/Canon-EOS-80D-versus-Nikon-D7200-versus-Canon-EOS-70D___1076_1020_895
Title: Re: Canon 80D
Post by: Greg on October 05, 2016, 01:36:18 AM
8MPx

ISO 100
80D -> 13.17EV
D7200 -> 14.59EV

ISO 100 + ISO 6400
80D -> 14.4EV
D7200 ->  15.22EV


24MPx

ISO 100
80D -> 12.33EV
D7200 -> 13.79EV

ISO 100 + ISO 6400
80D -> 13.37EV
D7200 ->  14.42EV


Loss of detail for 1EV more does not make sense.
Title: Re: Canon 80D
Post by: eduperez on October 05, 2016, 07:40:33 AM
Quote from: Marsu42 on October 04, 2016, 11:59:24 PM
Ugh!? How so? I understand the dr gain of the 80d is achieved by eliminating low-iso read noise, so higher iso values are just as they used to be - but still, an overlap should get us more than 0.5ev? https://www.dxomark.com/Cameras/Canon/EOS-80D---Measurements

And if dual_iso on 80d isn't really something to look forward to, it means even a ml'ed Canon doesn't reach recent Sonikon at all: https://www.dxomark.com/Cameras/Compare/Side-by-side/Canon-EOS-80D-versus-Nikon-D7200-versus-Canon-EOS-70D___1076_1020_895

Have a look at https://www.dpreview.com/reviews/canon-eos-80d-review/12 (https://www.dpreview.com/reviews/canon-eos-80d-review/12) and https://www.dpreview.com/reviews/canon-eos-80d-review/13 (https://www.dpreview.com/reviews/canon-eos-80d-review/13). In a 80D, there is little difference between raising the ISO and correcting the exposure in post processing, and dual-ISO's advantage is based precisely in that difference. With that camera, in most situations you can just take the shot at ISO 100 and then raise the shadows during post-processing.
Title: Re: Canon 80D
Post by: Marsu42 on October 05, 2016, 12:53:39 PM
Quote from: eduperez on October 05, 2016, 07:40:33 AM
With that camera, in most situations you can just take the shot at ISO 100 and then raise the shadows during post-processing.

Riiiight, so I understand with dual_iso the camera would basically capture the same information at both iso levels, minus the dynamic range that is clipped at higher iso values of every other scanline?

Quote from: Greg on October 05, 2016, 01:36:18 AMLoss of detail for 1EV more does not make sense.

I'd tend to disagree there, 1ev is double or half the light which is a lot. And it can be exactly the dynamic range that is clipped from the bright sky or detail drowned in deep shadows (like the eye of an animal, even though the rest of the scene is brighter). That's the hassle with digital photography - missing data is missing data, but a little data can be still recovered and worked with. Plus the afaik dual_iso's "loss of detail" only affects the semi-over/underexposed areas, so by definition with the 80d's little ev gain it would be little to worry about?

Anyway, I guess either the current dual_iso code works with the 80d or it doesn't b/c Canon has done some radical changes ... though knowing Canon, it's more likely everything is the same as before but the marketing brochure got a face-lift :->
Title: Re: Canon 80D
Post by: a1ex on October 05, 2016, 02:02:30 PM
Quote from: Marsu42 on October 05, 2016, 12:53:39 PM
I'd tend to disagree there, 1ev is double or half the light which is a lot.

Yes, but that comes at the cost of 4EV of aliased highlights at 100/1600, or 6EV at 100/6400.

And I somehow doubt the shadows at ISO 100/1600 will actually look cleaner than at ISO 100, because of the half resolution (which, in theory, reduces the DR by 0.5 stops and also affects the noise structure). So, without seeing the images, I'd say the tradeoff may not worth the extra effort.

If we have a bracketed image set, one at ISO 100 and another at ISO 1600, we can simulate a dual ISO image (lookup fake_dual_iso.exe) and see exactly if there is any extra shadow detail or not, compared to ISO 100.

Quote
Anyway, I guess either the current dual_iso code works with the 80d or it doesn't b/c Canon has done some radical changes ...

The CMOS registers are still used (strings are present), the implementation appears to have changed (strings look different), but ADTG strings are no longer there. Interesting that 5D4 contains ADTG strings on the AE processor, but none of them is present on the main procesor.

Some interesting strings from 80D, not present on earlier cameras (not even on 750D/760D):

RegisterSendCMOSGainCBR
( pCmosGain[0] & CMOS_ADDR_MASK ) == CMOS_REG_R_GAIN9
( pCmosGain[1] & CMOS_ADDR_MASK ) == CMOS_REG_R_GAIN10
( pCmosGain[2] & CMOS_ADDR_MASK ) == CMOS_REG_R_GAIN11
( pCmosGain[3] & CMOS_ADDR_MASK ) == CMOS_REG_R_GAIN12
(R_GAIN9_Param & CMOS_ADDR_MASK ) == CMOS_REG_R_GAIN9
(R_GAIN10_Param & CMOS_ADDR_MASK ) == CMOS_REG_R_GAIN10
(R_GAIN11_Param & CMOS_ADDR_MASK ) == CMOS_REG_R_GAIN11
(R_GAIN12_Param & CMOS_ADDR_MASK ) == CMOS_REG_R_GAIN12


Some strings from 750D/760D, not present in 80D:

( *pwRegister & 0xF000 ) == CMOS_VSKIP_START_ADDRESS
( *pwRegister & 0xF000 ) == CMOS_VSKIP_END_ADDRESS
( *pwRegister & 0xF000 ) == CMOS_HSKIP_ADDRESS
( *pwRegister & 0xF000 ) == CMOS_SAF_RESET_ADDRESS
[REG] @@@@@@@@@@@@ Start ADTGDMA[CS:%lx:%lx]size:%d


So, dual iso will probably work, maybe not out of the box, and there appears to be some potential for tweaking the gains.

However, at this point, it's just speculation. As in...

Quote from: Walter Schulz on October 02, 2016, 06:24:00 PM
www.magiclanternrumours.com (https://www.youtube.com/watch?v=oHg5SJYRHA0)

:)
Title: Re: Canon 80D
Post by: Marsu42 on October 06, 2016, 04:58:18 PM
Quote from: a1ex link=topic=17360.msg172969#msg172969
date=1475668950
Yes, but that comes at the cost of 4EV of aliased highlights at 100/1600

Well, looking at my personal photography the highlights are usually in the sky so I couldn't care less about aliasing there, it's just important that it isn't blown. ymmv.

QuoteAnd I somehow doubt the shadows at ISO 100/1600 will actually look cleaner than at ISO 100, because of the half resolution

That's probably true, and my experience with current dual_iso, too. But again, for it it's about *any* recognizable data other than plain noise being there. For example viewers won't look at the deep black fur parts of an animal in detail, but it is disturbing if some black parts look either clipped or like pushed plain shadow noise. ymmv if you don't shoot moving black buffaloes in bright back lighting at noon :-)

Quote(which, in theory, reduces the DR by 0.5 stops and also affects the noise structure).

You can translate the loss of resolution into dynamic range? That sound kind of strange, or is this some mathematic wizardry about noise?

QuoteIf we have a bracketed image set, one at ISO 100 and another at ISO 1600, we can simulate a dual ISO image (lookup fake_dual_iso.exe) and see exactly if there is any extra shadow detail or not, compared to ISO 100.

Well, but you'd have to do this with actual 80d shots, right? If any 80d owner reads this, please do go ahead and shoot a grey patch @iso 100/1600 and run it through fake_dual_iso and let's compare with a pushed and bracketed-hdr shot.

QuoteInteresting that 5D4 contains ADTG strings on the AE processor, but none of them is present on the main processor.

Which means 5d4 users are screwed, but there's hope for 80d and 760d, right?

That would serve 'em right, b/c remembering the discussion about the 1d, a camera in the price range of the 5d4 isn't exactly covered by "poor enthusiasts adding features to their budget and midrange cameras" :-o ...

... if some other camera should be covered by ml, it'd be the 1d4 which should be about what the 7d1 tech is ... but the 1d4 is really cheap by now. But don't let Canon hear :-p
Title: Re: Canon 80D
Post by: Marsu42 on October 06, 2016, 05:08:49 PM
An off-dev-topic question to you 80d owners: The spec say that all af pts except the center one are only f5.6-precise.

I have some fast lenses, say a 50/1.8. Does this in *reality* mean that such a lens is completely unusable except with the center pt when wider open (like f2.5), or are the outer pts better than advertised, or is the af pt expansion so good it makes up for the lack of precision? That's b/c even with the 60d's center point (f2.8-precise) the af performance of this lens is dubious at best.

Thanks for actual experiences with this camera, I'm still not sure if I should get it or stick with an older and cheaper one that runs ml right now and can recover the lack of dr with dual_iso.
Title: Re: Canon 80D
Post by: Mr.Click on October 07, 2016, 08:07:55 PM
No you´re wrong. All AF points work as cross sensors even with a slow f5,6 lens , but only the mid Sensor works as a dual cross Sensor with a fast lens ( f 0..-f 2,8)
The Mid AF Sensor even works at f8 . With Special lenses & Converters even 27 AF Sensors work at f8.

Please excuse my worse English ;-)
Title: Re: Canon 80D
Post by: Marsu42 on October 08, 2016, 03:26:00 PM
Quote from: Mr.Click on October 07, 2016, 08:07:55 PM
No you´re wrong. All AF points work as cross sensors even with a slow f5,6 lens , but only the mid Sensor works as a dual cross Sensor with a fast lens ( f 0..-f 2,8)
The Mid AF Sensor even works at f8 . With Special lenses & Converters even 27 AF Sensors work at f8.

I didn't ask about if it's cross or not, but how the *precision* of the f5.6 points with a lens faster than f5.6 is (like the mentioned 50mm prime). This is a real question, b/c the specs don't tell the whole story - the outer cross points a) could work quite well even with a fast lens, or b) could be totally worthless making the 80d a one-point-center-only camera with fast lenses. I have tested the 80d in a store, but only with the kit lens, that's why I'm asking other actual 80d users.

Btw the new motor-operated mirror makes me worry. With the older spring-operated mirror I got 330k shutter cycles out of my 60d, but I very much doubt a 80d will live that long if a motor is involved. Another case of "planned obsolescence"? Atm I'm rather thinking about getting a sturdy 7d1 with full magic lantern support right now :-o

My other general 80d comment of the day: Canon again put a lot of work into withholding features as the most useful af mode is missing ... "af pt expansion" is only on 7d2 and 5d3. So for precise af, it's one-point only with the 80d b/c the 9-point mode covers a much too large area :-\

QuotePlease excuse my worse English ;-)

Always a pleasure to exchange bad English with another German :-p
Title: Re: Canon 80D
Post by: Mr.Click on October 08, 2016, 09:59:23 PM
Ah you are German too  :D
You are still thinking wrong.  The outer AFCross  Sensors don´t work worser with a brighter lens. They work the same with a f 1,2 lens as they work with a f 5,6 lens. ( Same as most other EOS DSLR´s like 70D, 60D, 7D, 50D etc)
That only means that the lens doesnt´t have to be darker than f 5,6 . With a f 8 lens they probably stop working.
Only the Mid AF Sensor works with f8 Lenses and works as a Dual Cross Sensor with better light sensitivity when you mount f 2,8 glass or brighter.
With some rare lens combinations you even get 27 Af Points working at f8.
But all AF Sensors work very good with bright lenses( f 1-f 2,8) and also with dark lenses.(3,2- 5,6) No Problem.
Surprisingly the 80DAF works more accurate at all than it´s predecessors. I nearly have no AF misses since I have the 80D.
Hope you understand now. ( einfach umgekehrt denken, die Canon Beschreibung ist so geschrieben das man es schnell falsch versteht)
Title: Re: Canon 80D
Post by: ccs86 on October 10, 2016, 04:08:08 AM
Take it to PMs guys.
Title: Re: Canon 80D
Post by: Marsu42 on October 11, 2016, 01:36:19 PM
Quote from: ccs86 on October 10, 2016, 04:08:08 AM
Take it to PMs guys.

And you're using the forum to tell us to pm instead of sending us a pm yourself, Mr. spare-time mod? :-)

Anyway, this tech discussion is an important preliminary for supporting ML on the 80d as it details features found in this model vs. previous or other current d6 models, thus outlining the fw changes to be expected while looking for stubs.
Title: Re: Canon 80D
Post by: ariznaf on October 15, 2016, 11:04:01 AM
I am glad to know that there are experienced devs working in the port.

It is a ver y interesting camera, a step ahead previos models, with a very good focusing engine.

The day we could see the hello world message in it will be a great day.

With ML the camera will be a dream.

May be that ml could take advantages of the focusing system and put it a step further, closer to high end models.

Thanks for your grant work.

If I can help please tell me how, may be I have to wait to the alpha release to help in testing.
Title: Re: Canon 80D
Post by: jfkingsley on October 23, 2016, 09:46:20 PM
Hey all,

I've recently picked up an 80D, and also have a fair bit of experience working with low-level C, although admittedly less in terms of reverse-engineering embedded systems like this. I'd be very interested in lending a hand here if possible. I realise #40 is currently what we're up to, so if we're at a temporary waiting game so be it, but if not i'd be interested in gaining some pointers on where to start poking.

Jon.
Title: Re: Canon 80D
Post by: a1ex on October 23, 2016, 10:43:49 PM
Sounds good. Have you got it working in QEMU?
Title: Re: Canon 80D
Post by: LesterL on November 04, 2016, 03:07:41 PM
I own an 80D and have done some tests with low-iso dynamic range. I made a picture profile that expands the dynamic range in video and I've been very impressed by the clean results in the shadows. It looks very similar to the 13-stops that come off of the BMPCC. I think this camera would be amazing in RAW video, as the stills captured with this camera can be pushed a lot and still look clean. Plenty of youtube videos showing this.

I'm open for helping with the testing of a ML firmware. Also, if anyone would like the Custom Picture profile I created, I'd be glad to share it for use in the meantime. Just PM me.

Thanks to everyone working on this.
Title: Re: Canon 80D
Post by: LesterL on November 07, 2016, 08:08:06 PM
Some promising numbers from memory tests done with the 80D. Around 81MB/s possible sustained write speed. Which is really quite impressive.
Checkout the results from various cards.
http://www.cameramemoryspeed.com/canon-80d/sd-card-comparison/

With the recent progress in 10 and 12-bit raw recording options on the 5D III this could make for an impressive showing from the 80D down the road. If those can even be ported over to the 80D. We shall see.
Title: Re: Canon 80D
Post by: DeafEyeJedi on November 07, 2016, 10:27:58 PM
Interesting findings @LesterL and I'll be sending you a PM re: CP Profile. Thanks for sharing!
Title: Re: Canon 80D
Post by: dinissilva on November 25, 2016, 09:30:11 PM
Hey guys! Awesome progress! I was helping when we started testing the firmware! And now I'm back! Anythink i can help, please say it!
Title: Re: Canon 80D
Post by: julienpierb on December 10, 2016, 01:39:58 PM
Hey folks!
I just acquired a 80D two days ago and, I must say, that I already adore this camera.
I would be most interested in helping ML as best as I can.
I don't have coding knowledge, but I have a healthy amount of free time and I am a daily shooter.
If you need someone to test, I am most interested in doing so and answering as many questions.
Title: Canon 80D
Post by: AaronE on December 13, 2016, 10:41:06 PM
Hello as well!  Long time ML user on a T2i (and CHDK user before that on a P&S from a decade ago).

Just pulled the trigger on an 80D, and would love to lend a hand.  I've a lot of C and higher experience, a good bit of (rusty) embedded knowledge, some ASM and ARM chops, and a tiny bit of reverse engineering.  Looking forward to getting involved – the minds here (I'm looking at you, a1ex!) are pretty damn impressive.

Hopefully it's here by the end of the week and I'll be useful.  Anything I can do to get started (besides RTFM) to further the cause?
Title: Re: Canon 80D
Post by: Mashaal_m47 on December 16, 2016, 09:53:17 PM
I know thats its too early to expect an hack for canon 80d can i know that is there any work going on for canon 80d
Title: Re: Canon 80D ~ Dear Santa
Post by: OlRivrRat on December 21, 2016, 07:50:53 PM
      HeyThere St' Nik & Alex

   I'll bet You Can You guess what I would Really Like for Christmas ~

                     ORR ~ DeanB
Title: Re: Canon 80D
Post by: komocode on December 30, 2016, 10:12:56 AM
that sounds great guys. hopefully one day we'll see ML on 80D
Title: Re: Canon 80D
Post by: Jamie_Fenn on January 06, 2017, 02:21:19 AM
If ML is available for 80d in the future, what do you guys think the capabilities of the camera  will be?
Title: Re: Canon 80D
Post by: ltf3 on January 09, 2017, 10:51:36 PM
selfishly, all I need is Focus Peaking for video!
;D

Title: Re: Canon 80D
Post by: gsanchez922 on January 16, 2017, 08:32:16 AM
Quote from: ltf3 on January 09, 2017, 10:51:36 PM
selfishly, all I need is Focus Peaking for video!
;D


Hello man if you only need focus peak checkout Feelworld FW759 7 Inches Here is the link for amazon. This is ready to go.

https://www.amazon.com/gp/product/B0196JVB0S/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 (https://www.amazon.com/gp/product/B0196JVB0S/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1)
Title: Re: Canon 80D
Post by: gusjsph on February 05, 2017, 09:26:22 AM
hey there, just bought myself an 80D and would love to help if you need it! I really need the option to record video for longer than 30 minutes so if there's anything I can do to help the development process PM me and I'll do my best to assist. Thanks for your hard work on this software, much appreciated!
Title: Re: Canon 80D
Post by: Kaleb on February 18, 2017, 06:08:18 AM
Hey! First off, great work everyone! I love the progress that's being made.
I would like to offer my help as I have an 80D and would love to help if needed.

PM me if you need me! It would be an honour to further with the development of Magic Lantern for 80D with you all!
Title: Re: Canon 80D
Post by: Mr.Click on February 19, 2017, 02:03:54 PM
There is a new firmware for the 80D available , maybe this will help developing an 80D ML Version ?
Title: Re: Canon 80D
Post by: Ant123 on February 19, 2017, 02:23:11 PM
Quote from: Mr.Click on February 19, 2017, 02:03:54 PM
There is a new firmware for the 80D available , maybe this will help developing an 80D ML Version ?
No. Only finding the developer with the camera would help...
Title: Re: Canon 80D
Post by: Kaleb on February 22, 2017, 12:58:00 AM
Nice eye! I didn't even notice there was an update!

How would a new firmware help in the development of Magic Lantern?
Title: Re: Canon 80D
Post by: ariznaf on February 22, 2017, 11:52:33 AM
Because they have a firmware in a file to play with it in the emulators.

It seems that it is not easy to get the firmware out from the camera.
Title: Re: Canon 80D
Post by: a1ex on February 22, 2017, 12:11:36 PM
Quote from: ariznaf on February 22, 2017, 11:52:33 AM
It seems that it is not easy to get the firmware out from the camera.

Click! (http://www.magiclantern.fm/forum/index.php?topic=17360.msg171019#msg171019)

Anyone with basic command-line skills can get a copy of the firmware from his own camera and reproduce my experiments in the emulator. Hint, hint ;)
Title: Re: Canon 80D
Post by: Greg on February 24, 2017, 06:58:50 PM
(https://s8.postimg.cc/asvnkyt4l/80d_qemu.png)
Title: Re: Canon 80D
Post by: Ant123 on February 24, 2017, 07:17:20 PM
When we will see exactly the same picture on the camera display?   :)
Title: Re: Canon 80D
Post by: walter_schulz on February 24, 2017, 07:18:17 PM
It's alive!
Title: Re: Canon 80D
Post by: DeafEyeJedi on February 24, 2017, 07:36:34 PM
Great work @Greg!
Title: Re: Canon 80D
Post by: Greg on February 24, 2017, 08:07:22 PM
I just ran qemu :

./run_canon_fw.sh 80D,firmware=\"boot=1\" -s -S & arm-none-eabi-gdb -x 80D/debugmsg.gdb

I do not have 80D. It's just a joke (changed artist in hex editor)  ;)
Title: Re: Canon 80D
Post by: OlRivrRat on February 25, 2017, 07:39:19 AM
                       @Greg

             NOT FUNNY ~

                               ORR ~ DeanB
Title: Re: Canon 80D
Post by: Pierro777 on February 26, 2017, 12:32:20 AM
Is this for real or trolling ?
Title: Re: Canon 80D
Post by: a1ex on February 26, 2017, 03:09:32 PM
Quote from: Ant123 on February 24, 2017, 07:17:20 PM
When we will see exactly the same picture on the camera display?   :)

... about 7 months ago (http://www.magiclantern.fm/forum/index.php?topic=17360.msg169752#msg169752) ;)

Quote from: Pierro777 on February 26, 2017, 12:32:20 AM
Is this for real or trolling ?

Greg's screen is real; that's what any of you will get by running your ROM (http://www.magiclantern.fm/forum/index.php?topic=17360.msg171019#msg171019) in QEMU with default configuration (which runs the portable display test (http://www.magiclantern.fm/forum/index.php?topic=14732)).

Next step is figuring out how to fix the boot process. Experience with self-modifying code on ARMv7 will help.
Title: Re: Canon 80D
Post by: Ant123 on February 26, 2017, 03:26:48 PM
Quote from: a1ex on February 26, 2017, 03:09:32 PM
... about 7 months ago (http://www.magiclantern.fm/forum/index.php?topic=17360.msg169752#msg169752) ;)

I said "exactly", i.e. with "BOOT=-1"  :)
Title: Re: Canon 80D
Post by: Greg on February 26, 2017, 05:32:21 PM
EnableBootDisk
0xFE5F150C(0xFC040004, -1);

DisableBootDisk
0xFE5F150C(0xFC040004, 0);
Title: Re: Canon 80D
Post by: Ant123 on February 26, 2017, 07:24:28 PM
Quote from: Greg on February 26, 2017, 05:32:21 PM
EnableBootDisk
0xFE5F150C(0xFC040004, -1);

DisableBootDisk
0xFE5F150C(0xFC040004, 0);
Try it on YOUR camera first.  ;D
Title: Re: Canon 80D
Post by: Greg on February 26, 2017, 08:06:25 PM
I do not have 80D. It's too expensive.
I have only qemu cameras :P
Title: Re: Canon 80D
Post by: Straight_Shooter on March 05, 2017, 05:01:32 PM
I am now the owner of an 80D, in addition to my old 1100D.  :)

As soon as we have some binary that we can test I will be happy to help with testing.
Title: Re: Canon 80D
Post by: pawl on April 04, 2017, 10:01:39 AM
I'm still using 60d
The main reason I didn't upgrade it yet to 80d is because of ML not ready  :D :D :D

(in addition: 80D comes with DIGIC6, but 77D comes with DIGIC7. I'm afraid Canon will release a 8xD with DIGICx)
Title: Re: Canon 80D
Post by: JaSt on April 10, 2017, 10:12:28 AM
Greetings to ML developers,
I have an 80D. Contact me if you want to help with testing of early version.
Thanks in advance.  :)
Title: Re: Canon 80D
Post by: benzett on April 18, 2017, 04:16:42 PM
hey folks, are there any news about a ML version for the 80d? Im thinking about buying it, but unless i can get rid of the focus boxes, i wont... :) thanks for your work!
Title: Re: Canon 80D
Post by: Muwex on April 20, 2017, 02:59:51 PM
Hi!
I am also owner of Canon 80D and been for a long while, i have had Canon 500D which i had Magic lantern on sooooo.... i would be more than happy to finally have it on 80D.
Ofcourse i understand that it takes time, but if help is needed, i can try my best and do some testing :)

I do videos into 5 channels, this is my main channel: https://www.youtube.com/channel/UCXzdh4S1HOEpTTLreDBprlw
So i have like 5 years experiance with video making and creativity on YouTube :)
Title: Re: Canon 80D
Post by: deathbyderps on April 23, 2017, 01:45:27 PM
Hey i too got an 80d about a month back.
I'd be happy to test any form of early software, as unstable as it may be.
Feel free to drop me an email.
Title: Re: Canon 80D
Post by: Spakes on April 29, 2017, 07:55:52 AM
Hi. New here.
I got 80D too, updated it to 1.0.2 through EOS Utility 3. Don't have enough knowledge for QEMU/Low-Level C (only learning C++ and Java for Android), but open for testing anything. If you have some manuals for reverse engineering or need to test something, I'm ready to help. Just tell me what to do.
Title: Re: Canon 80D 1.0.2
Post by: Spakes on May 02, 2017, 01:57:33 PM
I know, there are minor updates in 1.0.2, but I still made a dump of 1.0.2 (why not, better for Norwegians and lens registration).
I can give you a link to all dumps if you PM me.
Is there also anything I can do which doesn't require a lot of time? I'll try to do some disassembly after June 10th, maybe, can't do it now 'cause exams.
Title: Re: Canon 80D
Post by: Greg on May 09, 2017, 06:23:16 PM
Any plans with digic 6/7?
Title: Re: Canon 80D
Post by: Ant123 on May 10, 2017, 08:07:50 AM
Quote from: Greg on May 09, 2017, 06:23:16 PM
Any plans with digic 6/7?

https://www.magiclantern.fm/forum/index.php?topic=17627.msg179772#msg179772 (https://www.magiclantern.fm/forum/index.php?topic=17627.msg179772#msg179772)
Title: Re: Canon 80D
Post by: Greg on May 10, 2017, 02:07:07 PM
It looks like no one wants a sensor in technology from 15 years ago.  :P
Title: Re: Canon 80D
Post by: emklap on May 11, 2017, 09:44:29 PM
Hi, I'm new here and have started on 80D reverse engineering.

I made custom firmware for the EOS 300D long time back and think its fun to try the port ML to the 80D.

I have virualbox setup and am able to compile the ML code, qemu still needs to be setup.

I use 80D FW1.0.2 because that was on my camera and could not find FW 1.0.1 . Th rom dumper worked fine a gave me three ROM1 dumps, one with a valid CRC.

(https://thumb.ibb.co/k1Soqk/IMG_0967.jpg) (https://ibb.co/k1Soqk)


I duplicated the file and load into IDA with offset 0xFC000000 and analysis of the code went smoothly. I now need to run an idc script because the automatic analyses does not start recognize the first character of a strings. See if my old code still works  :-)

Also the perl script disassamble.pl ran fine giving me lots of strings to work with. Some (2x) 330,000 way to may  :D to work with and I need to somehow remove the ones that do not make sense.

start of code looks like this
ROM:FC000000 ; Processor       : ARM
ROM:FC000000 ; ARM architecture: metaarm
ROM:FC000000 ; Target assembler: Generic assembler for ARM
ROM:FC000000 ; Byte sex        : Little endian
ROM:FC000000
ROM:FC000000 ; ===========================================================================
ROM:FC000000
ROM:FC000000 ; Segment type: Pure code
ROM:FC000000                 AREA ROM, CODE, READWRITE, ALIGN=0
ROM:FC000000                 ; ORG 0xFC000000
ROM:FC000000                 CODE32
ROM:FC000000
ROM:FC000000 loc_FC000000                            ; DATA XREF: sub_FC0274EC+34r
ROM:FC000000                                         ; sub_FC0274EC+40w
ROM:FC000000                 STC2            p0, c0, [R0], {8}
ROM:FC000004                 STC2            p0, c0, [R0], {0x48}
ROM:FC000008                 MOV             R0, #0
ROM:FC00000C                 MCR             p15, 0, R0,c6,c2, 0
ROM:FC000010                 MOV             R0, #0
ROM:FC000014                 MCR             p15, 0, R0,c6,c1, 0
ROM:FC000018                 MOV             R0, #0x3F
ROM:FC00001C                 MCR             p15, 0, R0,c6,c1, 2
ROM:FC000020                 MOV             R0, #0x320
ROM:FC000024                 MCR             p15, 0, R0,c6,c1, 4
ROM:FC000028                 MRC             p15, 0, R0,c1,c0, 0
ROM:FC00002C                 BIC             R0, R0, #0x20000
ROM:FC000030                 ORR             R0, R0, #1
ROM:FC000034                 DSB             SY
ROM:FC000038                 MCR             p15, 0, R0,c1,c0, 0
ROM:FC00003C                 ISB             SY
ROM:FC000040                 LDR             PC, =0xFE020000


and on FE0A0000 like this
ROM:FE0A0000                         ; ---------------------------------------------------------------------------
ROM:FE0A0000                         ; START OF FUNCTION CHUNK FOR sub_FE020000
ROM:FE0A0000
ROM:FE0A0000                         loc_FE0A0000                            ; CODE XREF: ROM:FC020E78j
ROM:FE0A0000                                                                 ; sub_FE020000+E78j
ROM:FE0A0000                                                                 ; DATA XREF: ROM:FC020E74o
ROM:FE0A0000                                                                 ; ROM:off_FC021278o ...
ROM:FE0A0000 04 00 8F E2                             ADR             R0, loc_FE0A000C
ROM:FE0A0004 01 00 80 E3                             ORR             R0, R0, #1
ROM:FE0A0008 10 FF 2F E1                             BX              R0 ; loc_FE0A000C
ROM:FE0A000C                         ; ---------------------------------------------------------------------------
ROM:FE0A000C                                         CODE16
ROM:FE0A000C
ROM:FE0A000C                         loc_FE0A000C                            ; CODE XREF: sub_FE020000+80008j
ROM:FE0A000C                                                                 ; DATA XREF: sub_FE020000:loc_FE0A0000o
ROM:FE0A000C 40 F2 00 00 C0 F2 00 00                 MOV             R0, #0
ROM:FE0A0014 40 F2 38 03 C0 F2 00 03                 MOV             R3, #0x38
ROM:FE0A001C 20 F0 01 00                             BIC.W           R0, R0, #1
ROM:FE0A0020 23 F0 01 03                             BIC.W           R3, R3, #1
ROM:FE0A0024 40 F2 00 01 C0 F2 00 01                 MOV             R1, #0
ROM:FE0A002C
ROM:FE0A002C                         loc_FE0A002C                            ; CODE XREF: sub_FE020000+80038j
ROM:FE0A002C 98 42                                   CMP             R0, R3
ROM:FE0A002E 3C BF                                   ITT CC
ROM:FE0A0030 50 F8 04 2B                             LDRCC.W         R2, [R0],#4
ROM:FE0A0034 41 F8 04 2B                             STRCC.W         R2, [R1],#4
ROM:FE0A0038 F8 D3                                   BCC             loc_FE0A002C
ROM:FE0A003A 4F F0 01 00                             MOV.W           R0, #1
ROM:FE0A003E 06 EE 12 0F                             MCR             p15, 0, R0,c6,c2, 0
ROM:FE0A0042 40 F2 21 11                             MOVW            R1, #0x121
ROM:FE0A0046 06 EE 91 1F                             MCR             p15, 0, R1,c6,c1, 4
ROM:FE0A004A BF F3 4F 8F                             DSB.W           SY
ROM:FE0A004E 19 EE 11 0F                             MRC             p15, 0, R0,c9,c1, 0
ROM:FE0A0052 00 F0 7D 00                             AND.W           R0, R0, #0x7D
ROM:FE0A0056 40 F2 01 01 C8 F2 00 01                 MOV             R1, #0x80000001
ROM:FE0A005E 40 EA 01 00                             ORR.W           R0, R0, R1
ROM:FE0A0062 09 EE 11 0F                             MCR             p15, 0, R0,c9,c1, 0
ROM:FE0A0066 40 F6 00 00 C8 F2 00 00                 MOV             R0, #0x80000800


The next step is to find stubs but have no clue where to start, IDA show just over 100000 functions!! again where do I start????
Can anyone provide some tips, e.g. which functions are important to find and which not? are there some easy one to start with.
Are the idc scripts available that can do some of the work for me/us.

Looking forward to some coding time



Title: Re: Canon 80D
Post by: a1ex on May 12, 2017, 01:50:52 PM
Hi - emklap from CHDK, right?

For IDA, you need to select ARMv7 A&R, and also*) load the same ROM at 0xFE000000.

*) Loading both ROMs makes IDA very slow (at least here), so it may be best to define two "projects": one for analyzing the bootloader at 0xFC000000 and another one for the main firmware at 0xFE000000.

The perl script has a custom version for DIGIC 6, but I didn't try it. You should know the CHDK forum better than me :D

Some of the stubs are listed in the digic6-dumper branch. There is an initial platform directory for 80D, which uses a minimal file structure (suitable for experimenting around) - this works fine in QEMU, but not on the actual hardware. I believe the issue is caching in the context of self-modifying code (ARMv7 has a different way to deal with this), but didn't look too much into it yet. Copying CHDK cache functions is probably enough to move forward.

When you are ready to run code on your camera, just get in touch with me on IRC.
Title: Re: Canon 80D
Post by: Ant123 on May 12, 2017, 10:15:02 PM
http://chdk.wikia.com/wiki/Digic_6_Porting (http://chdk.wikia.com/wiki/Digic_6_Porting)

Quote from: a1ex on May 12, 2017, 01:50:52 PMCopying CHDK cache functions is probably enough to move forward.

What is "CHDK cache functions" ?
Title: Re: Canon 80D
Post by: a1ex on May 12, 2017, 10:32:30 PM
https://app.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/lib/armutil/cache.c

Refer to ARM ARM v7, Cortex R4 TRM, and this blog post (https://community.arm.com/processors/b/blog/posts/caches-and-self-modifying-code).
Title: Re: Canon 80D
Post by: emklap on May 15, 2017, 12:54:33 PM
Hi A1ex,

Yes, I am the emklap of CHDK, there are not may of me around  :D
I already set IDA to ARMv7 A&R, didn't see any immediate change. I have no performance degradation with the entire FW Bootloader  & ROM RAM loaded in one IDA project, but the suggestion to split it is a nice one, might try that myself as well.

Next steps for me will be to get QEMU up and running and to adjust the CHDK IDC Scripts for my project.
I have limited time over the next weekends so it might take some time but I will report my progress in due time. I catch up with ARM disassembly as well.


Title: Re: Canon 80D
Post by: Pierro777 on May 20, 2017, 11:12:29 PM
Quote from: emklap on May 15, 2017, 12:54:33 PM
Hi A1ex,

Yes, I am the emklap of CHDK, there are not may of me around  :D
I already set IDA to ARMv7 A&R, didn't see any immediate change. I have no performance degradation with the entire FW Bootloader  & ROM RAM loaded in one IDA project, but the suggestion to split it is a nice one, might try that myself as well.

Next steps for me will be to get QEMU up and running and to adjust the CHDK IDC Scripts for my project.
I have limited time over the next weekends so it might take some time but I will report my progress in due time. I catch up with ARM disassembly as well.





I really hope you get it working!!!
Title: Re: Canon 80D
Post by: Mr.Click on May 31, 2017, 09:06:17 PM
Thanks you for your engagement , keep the work up  :)
Title: Re: Canon 80D
Post by: adindie on June 02, 2017, 07:46:42 PM
I'am a 80D owner too and i really want to install ML on this camera. I really want to shoot 4k video on my camera.

There is any update with ML status?
Title: Re: Canon 80D
Post by: Walter Schulz on June 03, 2017, 11:03:42 PM
No.
Title: Re: Canon 80D
Post by: Muwex on June 05, 2017, 06:18:00 PM
Hi!

Just putting here my update, that if there is need for testing, feel free to contact me for example pm or [email protected]
I have Canon 80D and i have had Canon 500D with magic lantern, i am no help for any coding work for sure, but for some testing i might be  ;)
Title: Re: Canon 80D
Post by: emklap on June 07, 2017, 10:37:01 PM
I'm, Stuck  >:(

I tried for several days to start the ROM dumper and the display test in qemu 1.6 but no luck. Can someone help me. this is what I tried so far.

I updated the file qemu/qemu-1.6.0/hw/arm/eos.c and added the lines
ML_MACHINE(80D,   0xFE0A0000);
EOS_MACHINE(80D,  0xFE0A0000);
qemu_register_machine(&canon_eos_machine_ml_80D);
qemu_register_machine(&canon_eos_machine_80D);

I also tried 0xFC000000 and 0xFC000008

In  the folder magiclantern/magic-lantern/platform I created a new folder (80D.102) and copied all files from folder of the 60D fw 1.1.1.
I added 80D.102 to the Makefile of ML.
Made updated the files Makefile and Makefile.platform.default located in the 80D.102 folder to reflect the 80D.
I used the following address in Makefile.platform.default in the 80D.102 folder.

#Makefile.setup.platform for 80D

CANON_NAME_FIR = 80D00102.FIR
FIRMWARE_ID = 0x80000350
UPDATE_NAME_FIR = BOOT_80D.FIR
FIR_BASE = 0x00800120
AUTOEXEC_BASE = 0x00800000

RESTARTSTART    = 0x001CC400
ROMBASEADDR     = 0xFE0A0000
ML_SRC_PROFILE  = minimal



Now the command make fails  (FYI If I set  "ML_SRC_PROFILE = generic" the make command finishes without errors).

The make command fails with the error "
Quoteminimal.c: In function 'my_create_init_task':
minimal.c:72:5: error: too many arguments to function 'create_init_task'
In file included from ../../src/dryos.h:41:0,
                 from minimal.c:5:
../../src/tasks.h:104:1: note: declared here

When changing the line in task.h to
Quotecreate_init_task( int a, int b, int c );
I get further but now the make command stops with a new error.
The new error is
Quotefont_direct.o: In function `font_draw':
font_direct.c:(.text+0xb0): undefined reference to `disp_set_pixel'
make: *** [magiclantern] Error 1

I am sure that disp_set_pixel is declared but the linker doesn't think so

Can some give me some tips / hints?. What am I doing wrong ? or what do I need to do to get the display test or ROM dumper  running in QEMU

Th s happens when i start quemu. I used the duplicate ROM from my 80D.102 to get a 64MB BIN file

Quotemake: Leaving directory `/home/magiclantern/qemu/qemu-1.6.0'
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 3FFFFFFF: eos.ram
40001000 - 7FFFFFFF: eos.ram_uncached
F0000000 - F0FFFFFF: eos.rom0
F1000000 - F1FFFFFF: eos.rom0_mirror_F1
F2000000 - F2FFFFFF: eos.rom0_mirror_F2
F3000000 - F3FFFFFF: eos.rom0_mirror_F3
F4000000 - F4FFFFFF: eos.rom0_mirror_F4
F5000000 - F5FFFFFF: eos.rom0_mirror_F5
F6000000 - F6FFFFFF: eos.rom0_mirror_F6
F7000000 - F7FFFFFF: eos.rom0_mirror_F7
F8000000 - F8FFFFFF: eos.rom1
F9000000 - F9FFFFFF: eos.rom1_mirror_F9
FA000000 - FAFFFFFF: eos.rom1_mirror_FA
FB000000 - FBFFFFFF: eos.rom1_mirror_FB
FC000000 - FCFFFFFF: eos.rom1_mirror_FC
FD000000 - FDFFFFFF: eos.rom1_mirror_FD
FE000000 - FEFFFFFF: eos.rom1_mirror_FE
FF000000 - FFFFFFFF: eos.rom1_mirror_FF
C0000000 - CFFFFFFF: eos.iomem
[EOS] loading 'ROM-80D.BIN' to 0xF0000000-0xF3FFFFFF
[EOS] loading 'ROM-80D.BIN' to 0xF8000000-0xFBFFFFFF

When I run ML-80D it loads autoexec.bin and qemu-helper.bin like this

Quote[EOS] loading 'ROM-80D.BIN' to 0xF0000000-0xF3FFFFFF
[EOS] loading 'ROM-80D.BIN' to 0xF8000000-0xFBFFFFFF
[EOS] loading 'autoexec.bin' to 0x00800000-0x0080207F
[EOS] loading 'qemu-helper.bin' to 0x30000000-0x30008C9F
[QEMU_HELPER] stub ff86af64 -> 30000130 (d195d000)
[QEMU_HELPER] stub ff9abbf4 -> 30000768 (ce83cf89)
[QEMU_HELPER] stub ff9abd20 -> 3000073c (294b2030)
[QEMU_HELPER] stub ff9abe20 -> 3000010c (93b8e0b2)
[QEMU_HELPER] stub ff9ab304 -> 3000027c (64616c62)
[QEMU_HELPER] stub ff9aac68 -> 300000dc (e3a781e3)
[QEMU_HELPER] stub ff9aabb4 -> 3000022c (e080a0ee)
[QEMU_HELPER] stub ff9aafa0 -> 3000033c (6f76754e)
[QEMU_HELPER] stub ff9ab150 -> 30000078 (36206163)
[QEMU_HELPER] stub ff9aad10 -> 30000054 (617262)
[QEMU_HELPER] stub ff9ab050 -> 30000830 (a4e5b498)
[QEMU_HELPER] stub ff85f0f0 -> 300001b8 (84cfb7ce)
[QEMU_HELPER] stub ff85f228 -> 3000019c (b49be583)
[QEMU_HELPER] stub ff9a8170 -> 30000184 (baef208b)

which gets followed by endless lines like this
[???] [0xE0411003] -> [0xCFFF9534] PC: 0x00000004
[???] [0xE12FFF1E] -> [0xCFFF9538] PC: 0x00000004
[???] [0xFF811DC0] -> [0xCFFF953C] PC: 0x00000004
[???] [0xE0030092] -> [0xCFFF9520] PC: 0x00000004
[???] [0xE0411003] -> [0xCFFF9524] PC: 0x00000004
[???] [0xE12FFF1E] -> [0xCFFF9528] PC: 0x00000004
[???] [0xFF811DC0] -> [0xCFFF952C] PC: 0x00000004
[???] [0xE0030092] -> [0xCFFF9510] PC: 0x00000004
[???] [0xE0411003] -> [0xCFFF9514] PC: 0x00000004
[???] [0xE12FFF1E] -> [0xCFFF9518] PC: 0x00000004
[???] [0xFF811DC0] -> [0xCFFF951C] PC: 0x00000004


Again, can some give me some tips / hints?. What am I doing wrong ? or what do I need to do to get the display test or ROM dumper  running in QEMU.
After that i would like to create my own bin file, rename it to autoexec.bin and load this file.
Title: Re: Canon 80D
Post by: a1ex on June 08, 2017, 07:09:41 AM
When all else fails... read the instructions. Any recent post on the QEMU thread, that references the install instructions, should do the trick.

Or, this walkthrough (http://www.magiclantern.fm/forum/index.php?topic=15895.msg185103#msg185103). You'll want QEMU 2.5.0 (not 1.6.0 and neither 2.9.0 - for now).

Don't rush to get "Hello world" yet; on digic 6 we need some more baby steps. If you really want to run it, you can take a look in src/minimal.c from the unified branch (that shows hello world with a minimal "display driver"), and you'll probably get that working in QEMU without much trouble. Note the 80D (in the digic6-dumper branch) has a different minimal.c.

However, this won't boot on the actual hardware until the caching issues (discussed earlier) are addressed.

BTW, the "generic" ROM dumper and display test are compiled from the "recovery" branch, and they work directly from the bootloader (without starting the main firmware).
Title: Re: Canon 80D
Post by: Spakes on June 11, 2017, 06:15:51 AM
Quote from: a1ex on June 08, 2017, 07:09:41 AM
When all else fails... read the instructions. Any recent post on the QEMU thread, that references the install instructions, should do the trick.

Or, this walkthrough (http://www.magiclantern.fm/forum/index.php?topic=15895.msg185103#msg185103). You'll want QEMU 2.5.0 (not 1.6.0 and neither 2.9.0 - for now).

Don't rush to get "Hello world" yet; on digic 6 we need some more baby steps. If you really want to run it, you can take a look in src/minimal.c from the unified branch (that shows hello world with a minimal "display driver"), and you'll probably get that working in QEMU without much trouble. Note the 80D (in the digic6-dumper branch) has a different minimal.c.

However, this won't boot on the actual hardware until the caching issues (discussed earlier) are addressed.

BTW, the "generic" ROM dumper and display test are compiled from the "recovery" branch, and they work directly from the bootloader (without starting the main firmware).
What caching issues and babysteps you are talking about?
Title: Re: Canon 80D
Post by: a1ex on June 12, 2017, 12:08:52 AM
Quote from: Spakes on June 11, 2017, 06:15:51 AM
What caching issues and babysteps you are talking about?

Answered a few posts above yours.
Title: Re: Canon 80D
Post by: emklap on June 14, 2017, 05:59:47 PM
:D, fresh install of Ubuntu 17 (64 BIT), toolchain 4.8.4 and qemu 2.5.0 did the trick

./run_canon_fw.sh 80D,firmware=\"boot=1\" -s -S & arm-none-eabi-gdb -x 80D/debugmsg.gdb

gives this display I wanted  :)

(https://thumb.ibb.co/iCsoV5/80_D_102_qemu.png)
Title: Re: Canon 80D
Post by: ddelreal on June 15, 2017, 01:11:44 AM
Nice!
Title: Re: Canon 80D
Post by: leonarka on June 15, 2017, 08:04:46 PM
Very much looking forward to 80d can use magic lantern
Title: Re: Canon 80D
Post by: aSoG_ on June 16, 2017, 06:37:51 PM
Hi, I do not have experience with this programming language.

But is there anything I can do? I have a 80d.
Title: Re: Canon 80D
Post by: fazorni on July 10, 2017, 04:34:11 PM
any news?
Title: Re: Canon 80D
Post by: Walter Schulz on July 12, 2017, 03:03:29 PM
Sure! (http://www.bbc.com/news)
Title: Re: Canon 80D
Post by: garry23 on July 12, 2017, 06:15:18 PM
 :)
Title: Re: Canon 80D
Post by: ariznaf on July 13, 2017, 11:20:40 AM
I post just to thank emkap efforts and a1ex support.

As the author of the original post, I am following all your steps.

As I cannot help in this phase of development, I am not posting often here.
I don't want to make the impression that I am trying to put preassure over developers.

Thanks again I hope you could get it working.
Title: Re: Canon 80D
Post by: a1ex on July 14, 2017, 01:48:37 PM
Just a heads up - QEMU is updated often with DIGIC 6 (https://bitbucket.org/hudson/magic-lantern/commits/all?search=keyword(%22DIGIC+6%22)+or+keyword(%22Thumb%22)) stuff.

For example, latest update is able to track direct jumps (http://www.magiclantern.fm/forum/index.php?topic=2864.msg187186#msg187186) to functions, which are used all over the place in Thumb-2 code.
Title: Re: Canon 80D
Post by: sombree on July 18, 2017, 08:42:23 PM
I've built autoexec.bin from latest digic6-dumper branch and run it in QEMU: https://hastebin.com/oyitotuyon.hs

I assume this means that our code did actually run:
[      init:001cc438 ] task_create(dump, prio=1e, stack=1000, entry=1cc6c0, arg=0)

By the look of minimal.c from unified branch I guess that to print "Hello, World!" in QEMU we need few more stubs (like bmp_vram_info, LCD_Palette) - am I right?

Also I've tried running this:
python find_fnt.py ROM1.BIN 0xF0000000
but this is the only output I'm getting:
Find bitmap fonts in Canon DSLR firmwares
Arm.Indy. based on work by Pel, Trammel Hudson and A1ex

Title: Re: Canon 80D
Post by: a1ex on July 18, 2017, 09:56:31 PM
The display backend changed significantly on DIGIC 6 - look it up on CHDK. I'm not sure of the pixel format used outside bootloader - first we need to run something on the camera alongside the main firmware (e.g. LED blinking).

Then we need to figure out how to print things on the screen; it will be probably similar to CHDK, but I'm not sure yet.

Only after doing this step we can see whether we need bmp_vram_info and LCD_Palette, or maybe some replacement.

The CanonGothic string is not present in the 80D ROM. No big deal - Canon fonts are not used in many places in our code.

BTW, the pixel format used in the bootloader is 8 BPP, palette-based; the palette is specified as YUV, but the U/V components are unsigned now (they were signed on previous cameras). See QEMU source and disp_direct.c on the recovery branch.
Title: Re: Canon 80D
Post by: sombree on July 18, 2017, 10:34:47 PM
Ok. Is it possible to test cache-related issues in QEMU? Or is it safe enough to test on real camera?
Title: Re: Canon 80D
Post by: a1ex on July 18, 2017, 11:17:22 PM
QEMU does not emulate cache behavior, other than a few status registers.

It's probably safe to perform these tests on the camera. However, at this point, you'll need some help from us to sign the binaries you want to run (currently the binaries can be run either as autoexec.bin or as FIR; the former needs a boot flag set in the ROM and the latter must be signed). To my knowledge, CHDK had trouble running the Canon firmware from a firmware update on most (if not all) digic 6 models, so we might have to enable the boot flag from the bootloader context, in order to run autoexec.bin. Traditionally, we enable the boot flag from main firmware, but we did enable it from bootloader on VxWorks models. It's probably best to try on a less expensive D6 model first; if anyone is willing to take the risk, I can prepare a FIR for enabling the boot flag in this way.

Having some other ARMv7 device to test things could be helpful, too.
Title: Re: Canon 80D
Post by: Walter Schulz on July 19, 2017, 12:06:44 AM
Cheapest option for Digic 6 today (Powershot derivates excluded): 750D, used. Listed at about 415 Euro (Germany).

And - if the offer is still standing - there is a 750D for free: https://www.magiclantern.fm/forum/index.php?topic=17627.msg179772#msg179772
Title: Re: Canon 80D
Post by: sombree on July 19, 2017, 12:20:40 PM
Are these settings correct? I know thah I have to change base architecture to ARMv7-A&R and uncheck both "delete instruction with no xfrefs" and "perform no-return analysis".

(https://thumb.ibb.co/c8JyC5/Clipboard01.png) (https://ibb.co/c8JyC5)
Title: Re: Canon 80D
Post by: a1ex on July 19, 2017, 05:12:16 PM
No, the ROM dump loads at FE000000 and FC000000 (http://www.magiclantern.fm/forum/index.php?topic=17360.msg184533#msg184533). The ROM is mirrored and code runs from both addresses, so you can either define two projects if you have a slow PC like mine, or just one (using the additional binary option in IDA) if you have a fast one like emklap's ;)

FE0A0000 is where you will find the main firmware after loading the ROM. The initialization code starts at FC000008, and the bootloader (LILO-style, prints "BootLoder" on the UART char by char) starts at FE020000. To start the main firmware, the bootloader writes 0 to 0xD20C0084, then jumps to FE0A0000.

There are a few additional blobs copied from ROM to RAM; you can get them from QEMU if you run it with "-d romcpy" (or just look them up in the QEMU test suite log (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-tests/lastSuccessfulBuild/console)).
Title: Re: Canon 80D
Post by: sombree on July 19, 2017, 05:57:06 PM
Sorry for these basic questions, but I was basing on info from this post (https://www.magiclantern.fm/forum/index.php?topic=6785.msg68973#msg68973). Anyway, this is how should I load files - am I correct?

(https://thumb.ibb.co/jb1S5Q/c2.png) (https://ibb.co/jb1S5Q)

(https://thumb.ibb.co/hnEfQQ/c3.png) (https://ibb.co/hnEfQQ)
Title: Re: Canon 80D
Post by: a1ex on July 19, 2017, 06:17:48 PM
Looks mostly fine. In the second box, try Loading segment 0, Loading offset 0xFE000000, and (not sure if this is needed with latest versions) number of bytes 0x1FFFFFC.
Title: Re: Canon 80D
Post by: sombree on July 19, 2017, 07:11:33 PM
Quote from: a1ex on July 19, 2017, 06:17:48 PM
Looks mostly fine. In the second box, try Loading segment 0, Loading offset 0xFE000000, and (not sure if this is needed with latest versions) number of bytes 0x1FFFFFC.

I think I'm close - for example this is what I see when I'm jumping to 0xFE2DB945 (sysmem_info stub):
ROM:FC2DB944                 PUSH            {LR}
ROM:FC2DB946                 SUB             SP, SP, #0x2C
ROM:FC2DB948                 ADD             R0, SP, #0x30+var_2C
ROM:FC2DB94A                 BLX             sub_FC3FBC70
ROM:FC2DB94E                 ADR             R0, aSystemMemoryIn ; "System Memory Information\n"
ROM:FC2DB950                 BL              sub_FC483CF0
ROM:FC2DB954                 LDR             R1, [SP,#0x30+var_2C]
ROM:FC2DB956                 ADR             R0, aStartAddress0x ; "  Start Address       = 0x%08lx\n"
ROM:FC2DB958                 BL              sub_FC483CF0
ROM:FC2DB95C                 LDR             R1, [SP,#0x30+var_28]
ROM:FC2DB95E                 ADR             R0, aEndAddress0x08 ; "  End Address         = 0x%08lx\n"
ROM:FC2DB960                 BL              sub_FC483CF0
ROM:FC2DB964                 LDR             R2, [SP,#0x30+var_24]
ROM:FC2DB966                 ADR             R0, aTotalSize0x08x ; "  Total Size          = 0x%08x (%9d)\n"
ROM:FC2DB968                 MOV             R1, R2
ROM:FC2DB96A                 BL              sub_FC483CF0
ROM:FC2DB96E                 LDR             R2, [SP,#0x30+var_20]
ROM:FC2DB970                 ADR             R0, aAllocatedSize0 ; "  Allocated Size      = 0x%08x (%9d)\n"
ROM:FC2DB972                 MOV             R1, R2
ROM:FC2DB974                 BL              sub_FC483CF0
ROM:FC2DB978                 LDR             R2, [SP,#0x30+var_1C]
ROM:FC2DB97A                 ADR             R0, aAllocatedPeak0 ; "  Allocated Peak      = 0x%08x (%9d)\n"
ROM:FC2DB97C                 MOV             R1, R2
ROM:FC2DB97E                 BL              sub_FC483CF0
ROM:FC2DB982                 LDR             R2, [SP,#0x30+var_18]
ROM:FC2DB984                 ADR             R0, aAllocatedCount ; "  Allocated Count     = 0x%08x (%9d)\n"
ROM:FC2DB986                 MOV             R1, R2
ROM:FC2DB988                 BL              sub_FC483CF0
ROM:FC2DB98C                 LDR             R2, [SP,#0x30+var_14]
ROM:FC2DB98E                 ADR             R0, aFreeSize0x08x9 ; "  Free Size           = 0x%08x (%9d)\n"
ROM:FC2DB990                 MOV             R1, R2
ROM:FC2DB992                 BL              sub_FC483CF0
ROM:FC2DB996                 LDR             R2, [SP,#0x30+var_10]
ROM:FC2DB998                 ADR             R0, aFreeBlockMaxSi ; "  Free Block Max Size = 0x%08x (%9d)\n"
ROM:FC2DB99A                 MOV             R1, R2
ROM:FC2DB99C                 BL              sub_FC483CF0
ROM:FC2DB9A0                 LDR             R2, [SP,#0x30+var_C]
ROM:FC2DB9A2                 ADR             R0, aFreeBlockCount ; "  Free Block Count    = 0x%08x (%9d)\n"


Though after loading additional binary file as you advised I'm getting this:
seg001:FE2DB945                 DCB 0xB5 ; Á
seg001:FE2DB946                 DCB 0x8B ; ő
seg001:FE2DB947                 DCB 0xB0 ; -
seg001:FE2DB948                 DCB    1
seg001:FE2DB949                 DCB 0xA8 ; Ę
seg001:FE2DB94A                 DCB 0x20
seg001:FE2DB94B                 DCB 0xF1 ; ˝
seg001:FE2DB94C                 DCB 0x92 ; ĺ
seg001:FE2DB94D                 DCB 0xE9 ; Ú
seg001:FE2DB94E                 DCB 0xB6 ; Â
seg001:FE2DB94F                 DCB 0xA0 ; á
seg001:FE2DB950                 DCB 0xA8 ; Ę
seg001:FE2DB951                 DCB 0xF1 ; ˝
seg001:FE2DB952                 DCB 0xCE ; +
seg001:FE2DB953                 DCB 0xF9 ; ¨
seg001:FE2DB954                 DCB    1
seg001:FE2DB955                 DCB 0x99 ; Ö
seg001:FE2DB956                 DCB 0x5C ; \
seg001:FE2DB957                 DCB 0xA0 ; á
seg001:FE2DB958                 DCB 0xA8 ; Ę
seg001:FE2DB959                 DCB 0xF1 ; ˝
seg001:FE2DB95A                 DCB 0xCA ; ¦
seg001:FE2DB95B                 DCB 0xF9 ; ¨
seg001:FE2DB95C                 DCB    2
seg001:FE2DB95D                 DCB 0x99 ; Ö
seg001:FE2DB95E                 DCB 0x63 ; c
seg001:FE2DB95F                 DCB 0xA0 ; á
seg001:FE2DB960                 DCB 0xA8 ; Ę
seg001:FE2DB961                 DCB 0xF1 ; ˝
seg001:FE2DB962                 DCB 0xC6 ; Ă
seg001:FE2DB963                 DCB 0xF9 ; ¨

I suppose it's because it wasn't analyzed though I'm not sure why.

Edit:
Oh, I didn't know that I can simply select huge chunk of code (like from 0xFE000000 to almost the end) and analyse it xD
Title: Re: Canon 80D
Post by: BobMiles on July 23, 2017, 01:12:59 PM
Hi guys,

new here, too! Just ordered a 80d and i'll be happy to help wherever I can.

I have some programming knowledge but mainly perl... I'll try and get myself up to speed and in the meantime follow your progress!

Thank you for the support!!!
Title: Re: Canon 80D
Post by: a1ex on September 03, 2017, 09:58:32 PM
Quote from: a1ex on July 18, 2017, 11:17:22 PM
Traditionally, we enable the boot flag from main firmware, but we did enable it from bootloader on VxWorks models. It's probably best to try on a less expensive D6 model first [...]

Last night, after a couple of hours of reversing, we (g3gg0 and I) ended up trying on a more expensive D6 model (http://www.magiclantern.fm/forum/index.php?topic=17714.msg189546#msg189546) first - it worked on the first try :)

As we did not have a ROM dump for that model (5DS), the boot flag enabling code was written to be portable (so it could work on an unknown model, likely similar to what we knew). Before running this code on 5DS, we have tested it in QEMU on 80D, 760D and 750D, and also visually checked it for 7D2 - where we only have an incomplete ROM dump (blinked, but with errors).

(http://a1ex.magiclantern.fm/bleeding-edge//80D/80D-bootflag-qemu.png)

In other words, we are ready to enable the boot flag on the above DIGIC 6 models :)

BOOTD80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTD80D.FIR) (display issue?)
BOOTE80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTE80D.FIR)


The above will run in dummy mode; it will only print what it's going to do. If the screenshot looks alright, I'll upload a FIR that will modify your camera.

Source: recovery branch (with the set_bootflag call commented out).
Title: Re: Canon 80D
Post by: sombree on September 04, 2017, 01:47:19 AM
I've just tried this FIR file on real camera with 1.0.2 firmware - LCD just turns blue and nothing else happens :(
Title: Re: Canon 80D
Post by: a1ex on September 04, 2017, 07:54:01 AM
Does the previous FIR from this thread (the ROM dumper) work for you? There is a color palette issue (it won't show the same color every time - probably the same caching issue described earlier).

I've compared both FIRs in QEMU - their I/O activity - prior to writing files to the card - is almost identical, with a minor difference - the color palette had the uncacheable memory flag in the ROM dumper. Here's a FIR without this diffference:

BOOTE80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTE80D.FIR)
Title: Re: Canon 80D
Post by: sombree on September 04, 2017, 10:09:38 AM
Yes, ROM dumper works fine. This second FIR file (BOOTE80D.FIR) also works:
(https://i.imgur.com/evmIXhK.jpg?1)
Title: Re: Canon 80D
Post by: a1ex on September 04, 2017, 10:23:43 AM
Alright, so that caching thing probably makes a difference. Here's one more that runs from uncacheable memory:

BOOTU80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTU80D.FIR)

Just for my own curiosity - if you try to run a FIR 10 or 20 times in a row, does it use the same colors every single time, or are there any differences? The question applies to all the 3 FIRs (BOOTD80D.FIR, BOOTE80D and BOOTU80D).
Title: Re: Canon 80D
Post by: sombree on September 04, 2017, 11:10:07 AM
BOOTD80D.FIR - now I've tried it after BOOTE80D.FIR and it kinda works (for 10 attempts: worked 3 times, 7 times it just turn blue); once background was red and twice it was blue: red (https://imgur.com/Ap7xwRa), blue (https://imgur.com/Ap7xwRa)
BOOTE80D.FIR - font is always blue (like in the screen from the qemu that you've posted) and background is black
BOOTU80D.FIR - works as BOOTE80D.FIR; only difference is the last line being dark blue: https://imgur.com/8W0aVJi (https://imgur.com/8W0aVJi)
I've run BOOTE80D and BOOTU80D ten times each and result was always the same.
Title: Re: Canon 80D
Post by: a1ex on September 04, 2017, 04:37:23 PM
The last line is using the last palette entry - I have a feeling this is a quirk that we have to understand in order to boot ML later. Let's try a barrier (DSB):

BOOTB80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTB80D.FIR)

Hope you don't mind trying this one 50 times to make sure it shows the same colors every time :)
Title: Re: Canon 80D
Post by: sombree on September 04, 2017, 05:19:11 PM
I don't have to check it 50 times - for 10 attempts seven times I've had normal (black) background and for three times I've had red background :/
Title: Re: Canon 80D
Post by: a1ex on September 04, 2017, 10:17:49 PM
Alright - so the caching issue is still not solved. However, the results from previous experiments gave me some ideas for solving the issue of running code alongside Canon firmware. Also found some more docs on this:

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053b/IHI0053B_arm_c_language_extensions_2013.pdf
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka14041.html
https://community.arm.com/community-help/f/discussions/2109/dmb-vs-dsb
https://stackoverflow.com/questions/15491751/real-life-use-cases-of-barriers-dsb-dmb-isb-in-arm

In particular, the second link has a concise explanation in the self-modifying code section. Let's try it.

All these FIRs should jump to Canon firmware (in other words, after the Loading screen, the camera should return to normal firmware). They will also execute various stages of loading ML - some may fail (camera will lock up). The outcome might not be always the same, so it's best to try each FIR a couple of times.

All of them will write the self-modifying code to uncacheable memory (something we didn't try before).

JMPA_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPA_80D.FIR) - jump to Canon firmware at 0xFE0A0000 (any firmware version)
JMPB_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPB_80D.FIR) - copy ML, DSB/ISB, then jump to Canon firmware (any firmware version)
JMPC_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPC_80D.FIR) - vanilla reboot.c, jump to Canon firmware from copy_and_restart (any firmware version)
JMPD_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPD_80D.FIR) - relocate Canon's startup code without patching it (1.0.1 only)
JMPE_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPE_80D.FIR) - relocate Canon's startup code, reserve RAM, jump to Canon firmware (1.0.1 only)
JMPF_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPF_80D.FIR) - LED blinking alongside Canon firmware (1.0.1 only).
JMPG_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPG_80D.FIR) - relocate Canon's startup code, reserve RAM, run our init task, dump ROM1.BIN on the card after 5 seconds (1.0.1 only)

Source code for all of the above (https://bitbucket.org/hudson/magic-lantern/branch/80D-troubleshooting)

Crossing fingers :)
Title: Re: Canon 80D
Post by: OlRivrRat on September 04, 2017, 10:43:21 PM
                    @Alex

            Attempt to Download JMPE,F,G brings up "404 Not Found"
Title: Re: Canon 80D
Post by: sombree on September 04, 2017, 10:44:26 PM
JMPA_80D.FIR - camera returns to normal firmware
JMPB_80D.FIR - camera returns to normal firmware
JMPC_80D.FIR - camera locks up
JMPD_80D.FIR - camera locks up
As for the rest - your server returns 404.
Title: Re: Canon 80D
Post by: a1ex on September 04, 2017, 10:46:04 PM
Solved - copy/paste error. However, if JMPC didn't work, the remaining ones won't work either.

If anyone wants to fiddle with the code, here's the FIR to enable the boot flag (on any firmware version):

BOOTF80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTF80D.FIR).

This will modify your camera.

After enabling the boot flag in the camera, you may run:

- the portable display test (http://www.magiclantern.fm/forum/index.php?topic=14732.0) (copy autoexec.bin and make your card bootable)
- the portable ROM dumper (http://www.magiclantern.fm/forum/index.php?topic=16534.0) (you may have to format the card to a very small size, or dd this 256MB image (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/sd.img.xz) - howto (https://thepihut.com/blogs/raspberry-pi-tutorials/17789160-backing-up-and-restoring-your-raspberry-pis-sd-card))
- anything compiled from the recovery (https://bitbucket.org/hudson/magic-lantern/branch/recovery) branch (it runs from bootloader context); check Makefile.user.default for options
- the digic6-dumper (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper) branch (you will have to modify the code and experiment - it won't boot in its current state)

For troubleshooting the above experiment (trying to run code alongside Canon firmware):
- make sure you are running firmware 1.0.1
- make your card bootable
- compile autoexec.bin from digic6-dumper (full boot, works in QEMU but not on the camera) or from 80D-troubleshooting (partial boot - last good is cc66eb4 = JMPB)
- no other data files are required at this time
- tell me what I'm doing wrong (you may study the above ARM docs, get an execution trace in QEMU, try similar code on another ARMv7 device or whatever else you can think of)

(I'm still looking into it)
Title: Re: Canon 80D
Post by: sombree on September 05, 2017, 11:32:48 AM
It's also possible that code is fine - maybe RESTARTSTART addres (or any other stub for that matter) just changed in 1.0.2.
Title: Re: Canon 80D
Post by: a1ex on September 05, 2017, 11:44:23 AM
Right - forgot about the new firmware. Can you PM me a ROM dump?

However, the steps that depend on the firmware version are starting from D. Step C is generic code that works on all D6 models.

BTW, two more generic FIRs (compatible with any firmware version):

JMPH_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPH_80D.FIR) - similar to JMPC, but runs all our code in uncacheable memory.
JMPI_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPI_80D.FIR) - similar to JMPC, but disables caches in SCTLR and memory region (http://magiclantern.wikia.com/wiki/Memory_map) 1 (DRACR 0x320; will be reconfigured by Canon firmware when booting).

And yet another attempt for fixing the colors (marked the memory as Shareable - I don't really know what I'm doing):

BOOTS80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTS80D.FIR)
Title: Re: Canon 80D
Post by: sombree on September 05, 2017, 04:24:20 PM
PM sent.
JMPH_80D.FIR - camera returns to normal firmware
JMPI_80D.FIR - camera returns to normal firmware
BOOTS80D.FIR - works only partially - sometimes LCD turns blue, sometimes it loads but background is blue or red
Title: Re: Canon 80D
Post by: a1ex on September 05, 2017, 04:40:18 PM
That means progress :)

JMPJ_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPJ_80D.FIR) - similar to JMPD, but for 1.0.2 and using the trick from JMPH.
JMPK_80D.FIR (http://a1ex.magiclantern.fm/bleeding-edge/80D/JMPK_80D.FIR) - similar to JMPD, but for 1.0.2 and using the trick from JMPI.

Title: Re: Canon 80D
Post by: sombree on September 05, 2017, 04:50:34 PM
JMPJ_80D.FIR - camera locks up
JMPK_80D.FIR - camera locks up
Title: Re: Canon 80D
Post by: goldenchild9to5 on September 05, 2017, 11:27:58 PM
Awesome work @a1ex
Title: Re: Canon 80D
Post by: matija on September 07, 2017, 09:07:07 PM
Hi,

I read through the whole topic, but just to make sure.
I have to install http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTF_80D.FIR, which will "only" modify the boot flag, after which the tests should not modify anything, they are just some test and then normal situation should resume? Can I go back to Canon firmware only? I am aware there is some risk involved.

Title: Re: Canon 80D
Post by: a1ex on September 07, 2017, 10:00:08 PM
Before enabling the boot flag, you'll see BOOT=0. Afterwards, you'll see BOOT=1.

Disabling the boot flag is easy - I can prepare a FIR for that, if needed.

So far, the boot flag enabler was confirmed to work on 5DS (g3gg0) and 760D (xabi) - that means, camera boots normally without card or with a formatted card, and runs autoexec.bin if the card is bootable (we have checked these scenarios). The 750D, 760D and 80D are very similar, so I don't expect any surprises.
Title: Re: Canon 80D
Post by: OlRivrRat on September 09, 2017, 02:46:21 AM
"I have to install http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTF_80D.FIR, which will "only" modify the boot flag,"

Is that supposed to be a Real Link > I get a 404 Not Found.
Title: Re: Canon 80D
Post by: Walter Schulz on September 09, 2017, 10:28:38 AM
-> Reply #157, #159
Title: Re: Canon 80D
Post by: OlRivrRat on September 09, 2017, 05:18:00 PM
      @Walter

   Insufficient/Incorrect answer ~

Correct answer would have been >

   Try This >

http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTF80D.FIR
Title: Re: Canon 80D
Post by: eduperez on September 09, 2017, 07:16:28 PM
Quote from: matija on September 07, 2017, 09:07:07 PMI have to install http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTF_80D.FIR, which will "only" modify the boot flag, after which the tests should not modify anything, they are just some test and then normal situation should resume?

Just for clarification: you only need to enable the boot flag to execute AUTOEXEC.BIN files, all .FIR files are executed using the firmware update procedure, and do not need the boot flag enabled.
On the other hand, only the "BOOTF_80D.FIR" makes changes to the camera, all other .FIR files are supposed to be harmless.
Title: Re: Canon 80D
Post by: sombree on September 15, 2017, 04:42:45 PM
Result of running BOOTF_80D.FIR:
(https://i.imgur.com/5QNaWlm.png)
I thought that BOOT will change to 1, not to -1. Also I've tried autoexec.bin with portable display test but nothing happens - camera loads to normal firmware.

Edit: my bad - after using Eoscard to make card bootable something happens - screen turns blue when camera turns on. In fact, it turns blue no matter if switch is set to ON or OFF  ???
Without modified card it boots to normal firmware as it supposed to.
Title: Re: Canon 80D
Post by: a1ex on September 15, 2017, 06:59:13 PM
That means, success. On the first run, you had BOOT=0; after that, you already have it enabled. The FIR doesn't check the boot flags; it just prints their raw value.

At this stage, anyone can compile run his own code on the camera.
Title: Re: Canon 80D
Post by: sombree on September 15, 2017, 10:31:35 PM
Ah, good to hear. Anyway before you've mentioned that probably we can copy cache functions from CHDK - what about something like this (https://www.diffchecker.com/ehHtcn9M)?  Though I guess that it's not that simple xD
Title: Re: Canon 80D
Post by: Pierro777 on September 16, 2017, 03:41:26 PM
You guys are awesome !!! Keep up the hard work !
Title: Re: Canon 80D
Post by: zeus12 on September 18, 2017, 10:02:45 PM
Wonderful news. It seems that 80D has a writing speed close to 80 mb/s (70D only 40 mb/s). It is quite possible that we can get more than 1080p with compressed raw. The 10 bit should work as well. Thanks guys!
Title: Re: Canon 80D
Post by: whoreable on September 22, 2017, 06:27:56 AM
wow, congrats with the new progress guys!

I love ML, I had it for my 50D which just finally died, not ML fault. It allowed me to do so much more, so Im hoping you guys can make that happen for the 80D here shortly! Happy holidays everyone!
Title: Re: Canon 80D
Post by: Fishhy on October 03, 2017, 07:37:34 PM
i am not really experienced with all this stuff, but i keep coming back here to check how it is going. i would like to say i appreciate what you are all doing and working to get this working. but what stage is this at. is this still early stages or is this late stages, i am happy to test if you have a working model but as long as its relatively safe.
thanks again
Title: Re: Canon 80D
Post by: tobixx on October 07, 2017, 05:49:28 PM
Oh my god! I'm so exited to read about ongoing development for the 80D! Coming from the mirror less world it feels a little bit like cutting off fingers. But with ML all the goodness will come back! Cheers to the developers! Thanks for your effort!
Title: Re: Canon 80D
Post by: sombree on October 09, 2017, 08:44:02 PM
@a1lex
I've tried building from digic6-dumper and running autoexec.bin - no succes, camera locks up. But with this change (https://www.diffchecker.com/c77MwMu9) (copy-paste from CHDK; I know that it's ugly) camera continues to boot to the main firmware. Basing on this (https://bitbucket.org/hudson/magic-lantern/commits/fa20c1e55e403950401d3c254825bbd44cdbeb98?at=digic6-dumper) and this (https://bitbucket.org/hudson/magic-lantern/commits/95e4cd924d56d3741f9e89c362662d68c95444c9?at=digic6-dumper) I've tried to dump the rom or blink the led but still no succes :/
Title: Re: Canon 80D
Post by: a1ex on October 10, 2017, 09:22:51 AM
Sounds promising; can you PM me a few autoexec.bin files you have experimented with, and their outcome? (in particular, the one that boots successfully and the one that attempts to blink the LED without success)
Title: Re: Canon 80D
Post by: sombree on October 10, 2017, 03:01:15 PM
Quote from: a1ex on October 10, 2017, 09:22:51 AM
Sounds promising; can you PM me a few autoexec.bin files you have experimented with, and their outcome? (in particular, the one that boots successfully and the one that attempts to blink the LED without success)

PM sent.
Title: Re: Canon 80D
Post by: whoreable on October 12, 2017, 08:02:28 AM
 :-* :-* :-*
Title: Shutter Count from Canon 80D - How ?
Post by: RavingRover on October 26, 2017, 01:33:29 AM
Generally ML can retrieve the shutter count from all ported cams, and is view-able via ML on cam.

Currently the ONLY method to get the 80D shutter/mirror count is to PAY $$ ($6 for winblows, $3.81 for mac - 2 diff apps), neither APT astronomy app, nor gphoto2 (linux) show it either - both free.  And no the jpeg does not show the shutter count either using a jpeg meta editor.

It appears ONLY via a usb conn and knowing specifically where the data is located, and dumping it and interpreting it correctly, is the only way to get this data.

So has anyone seen via a usb conn, some way or the place that the shutter count is stored, (maybe someone decompiling the rom dump, while trying to port ML, might have seen something like this or some hint to where ??)


TIA !
Title: Re: Canon 80D
Post by: zerocool22 on November 09, 2017, 01:16:18 PM
These guys also have software for it. Maybe you can get in touch with them? Or maybe decompile their code? if that is any help at all.

http://www.spt.info/index.php/service-adjustment-software

http://www.spt.info/sptstore.php/canon-eos-80d
Title: Re: Canon 80D
Post by: LesterL on November 09, 2017, 07:30:28 PM
@a1ex
Are you still in need of an 80D for doing testing? I would be willing to donate $100 to help speed up that process. I'm sure we could find 9 more people willing to as well so you could get your hands on one. That is if you're wanting or have the time to work on it. If not, I totally understand.
Title: Re: Canon 80D
Post by: a1ex on November 09, 2017, 11:20:21 PM
Sorry, I'm not interested in getting another camera (http://www.magiclantern.fm/forum/index.php?topic=17627.msg191184#msg191184). If any of you has the time, skills and motivation to complete the port, you are welcome to jump in.

Will resume looking at D6 models after merging the current QEMU developments and the recent DIGIC 5 ports into mainline. Meanwhile, please remember the development tools are public - you have a ROM dumper, a way to execute your own code on the camera and a way to emulate a small part of it; feel free to try sombree's findings and keep experimenting.
Title: Re: Canon 80D
Post by: LesterL on November 10, 2017, 12:14:19 AM
I totally understand. Just wanted to facilitate if you were wanting one.
Title: Re: Canon 80D
Post by: thejordanhall on November 10, 2017, 12:36:49 AM
Hey guys,

I have a Canon 80D and would be really interested in joining the mission to get ML for the 80D. However, I don't really want to brick it as I am a student and have barely any money to buy another. How would I be able to learn about coding/programing for the 80D ML and any other advice/tips for me to get into this?

It'd be awesome to make ML a thing for the 80D by the end of the year.

Thank :)
Title: Re: Canon 80D
Post by: a1ex on November 10, 2017, 08:02:36 AM
The best way to start learning, in my (biased) opinion, is to use the emulator. That way, the risk of bricking the camera drops to zero (as you will not experiment with real hardware, but with a PC-based program). Besides, the emulator shows a LOT of internals that are not obvious when running the code on the camera (at this stage, you'll most likely see a black screen and you'll wonder why it doesn't work).

Sure, at some point you will want to try the code on your camera. Having something that works in the emulator decreases the odds of getting into trouble, and during these early boot experiments, I'd say the bricking risk is fairly low - should anything go wrong, the camera will most likely not boot. Non-volatile memories with camera settings (ROM, serial flash, MPU eeprom) are updated on successful shutdown, to my knowledge. Experiments from bootloader (e.g. the "recovery" branch) should be fairly safe, as long as you are not calling things like EraseSectorOfRom.

Even if you manage to get some invalid setting written to ROM, we now understand how these things work and can look into it. Already recovered a couple of D4/5 cameras that way, soft-bricked by either our programming mistakes, or also by third party apps, on cameras that never ran ML before. Sure, we've never tried to recover a D6, so if your camera is mission-critical, don't try it.

To get the emulation further, I need two things:

- a log of MPU communication (http://www.magiclantern.fm/forum/index.php?topic=17596.0) (see mpu_send/mpu_recv stubs in the dm-spy-experiments branch)
- a serial flash dump (sf_dump module)

The first one can be probably started (but not completed) from bootloader. It's a bit tricky, I've got it somewhat (not reliably) working on D4/5 a while ago, the test code is somewhere in the Linux branch (look for MPU), but can be fully tested in QEMU.

The second one will probably not work from bootloader, but I haven't tested it. Todo: try on 700D/100D/M/6D/M2 in QEMU and ask owners of these cameras to try on real hardware).

Both of those will be a lot easier after being able to start DryOS tasks alongside Canon's main firmware, but if that step keeps proving difficult, there are still things to try.

BTW, high-resolution photos of the main board (http://magiclantern.wikia.com/wiki/Circuit_boards) are always welcome (for any camera model, not just 80D). No coding skills required for this one :D
Title: Re: Canon 80D
Post by: Spakes on November 19, 2017, 07:10:14 PM
Quote from: a1ex on November 10, 2017, 08:02:36 AM
The best way to start learning, in my (biased) opinion, is to use the emulator. That way, the risk of bricking the camera drops to zero (as you will not experiment with real hardware, but with a PC-based program). Besides, the emulator shows a LOT of internals that are not obvious when running the code on the camera (at this stage, you'll most likely see a black screen and you'll wonder why it doesn't work).

Sure, at some point you will want to try the code on your camera. Having something that works in the emulator decreases the odds of getting into trouble, and during these early boot experiments, I'd say the bricking risk is fairly low - should anything go wrong, the camera will most likely not boot. Non-volatile memories with camera settings (ROM, serial flash, MPU eeprom) are updated on successful shutdown, to my knowledge. Experiments from bootloader (e.g. the "recovery" branch) should be fairly safe, as long as you are not calling things like EraseSectorOfRom.

Even if you manage to get some invalid setting written to ROM, we now understand how these things work and can look into it. Already recovered a couple of D4/5 cameras that way, soft-bricked by either our programming mistakes, or also by third party apps, on cameras that never ran ML before. Sure, we've never tried to recover a D6, so if your camera is mission-critical, don't try it.

To get the emulation further, I need two things:

- a log of MPU communication (http://www.magiclantern.fm/forum/index.php?topic=17596.0) (see mpu_send/mpu_recv stubs in the dm-spy-experiments branch)
- a serial flash dump (sf_dump module)

The first one can be probably started (but not completed) from bootloader. It's a bit tricky, I've got it somewhat (not reliably) working on D4/5 a while ago, the test code is somewhere in the Linux branch (look for MPU), but can be fully tested in QEMU.

The second one will probably not work from bootloader, but I haven't tested it. Todo: try on 700D/100D/M/6D/M2 in QEMU and ask owners of these cameras to try on real hardware).

Both of those will be a lot easier after being able to start DryOS tasks alongside Canon's main firmware, but if that step keeps proving difficult, there are still things to try.

BTW, high-resolution photos of the main board (http://magiclantern.wikia.com/wiki/Circuit_boards) are always welcome (for any camera model, not just 80D). No coding skills required for this one :D

Hi, will VMWare mess with QEMU or it is going to be okay? I have enough power to do nice emulation (i7-6700HQ, 16 GB, GTX 1060), but don't want to mess with installation of Linux on main machine, since I wanted to get new SSD and install clover and Hackintosh with Windows (don't ask why).

UPD: Nevermind, I'll install it on Windows. Next question: where can I read about assembler and everything related to DIGIC 6 (including emulation) and what you have found except this topic? All I learned is basic C++ and Java.
Title: Re: Canon 80D
Post by: a1ex on December 20, 2017, 12:38:57 AM
Just a heads up - latest QEMU commits (https://bitbucket.org/hudson/magic-lantern/branch/qemu) have some significant progress on 80D (http://www.magiclantern.fm/forum/index.php?topic=2864.msg194899#msg194899) and - to a lesser extent - all other DIGIC 6 cameras.

Nothing fancy for the end-user, but the emulation now starts a LOT of tasks, initializes some filesystem drivers (didn't test whether file I/O actually works), wakes up the Omar (http://www.magiclantern.fm/forum/index.php?topic=13408.msg194424#msg194424) core, and if you enjoy tinkering, the Dry-shell console (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst#rst-header-dryos-internals) works!

You will need a patched SFDATA.BIN (https://bitbucket.org/hudson/magic-lantern/commits/652133663c39d58dd58360b1a3154ffc3f66b871?at=qemu) (serial flash dump) from a 70D (preferred), or 700D, 650D, EOSM, 6D (not sure about 100D). If you don't have one, just comment it out in model_list.c; most of the stuff appears to work without it.

MPU messages guessed from 60D, so they are no longer "must have" - just nice to have.

Fun stuff:

( sleep 3; echo "akashimorino";
  sleep 1; echo "SHM_SHOW_INFO";
  sleep 1; echo "SHM_SHOW_DIST_INFO";
) | ./run_canon_fw.sh 80D -serial stdio


Guide: https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/ (README)
Video: this sticky tweet (https://twitter.com/autoexec_bin/status/913530810686418944) and the same for Mac (http://www.magiclantern.fm/forum/index.php?topic=16012.msg191686#msg191686). GUI not working yet on D6.

Have fun.
Title: Re: Canon 80D
Post by: whoreable on December 20, 2017, 11:02:27 AM
 8) awesome news
Title: Re: Canon 80D
Post by: Theta Sigma on December 20, 2017, 12:46:44 PM
(https://media.giphy.com/media/NnGGHE0muVqpO/giphy.gif)
Title: Re: Canon 80D
Post by: emklap on December 21, 2017, 04:16:43 PM
Super!!  :D
Title: Re: Canon 80D
Post by: a1ex on December 22, 2017, 12:23:42 AM
Figured out file I/O as well.


(
  sleep 3; echo "akashimorino";
  sleep 1; echo "dumpf";
) | (
  ./run_canon_fw.sh 80D -serial stdio -s -S &
   arm-none-eabi-gdb -x 80D/patches.gdb
)


Result: LOG000.LOG created on the virtual SD card:

Sat Jan  1 00:00:06 2000
     0:    75.264 [STARTUP]
K350 ICU Firmware Version 1.0.2 ( 6.2.3 )
     1:    76.288 [STARTUP]
ICU Release DateTime 2016.12.27 09:58:00
     2:    79.872 [SEQ] CreateSequencer (Startup, Num = 6)
     3:    84.480 [SEQ] NotifyComplete (Cur = 0, 0x2018000, Flag = 0x10000)
     4:   104.704 [PROPAD] PROPAD_CreateFROMPropertyHandle DRAMAddr 0x415a7000
     5:   105.984 [PROPAD] PROPAD_CreateFROMPropertyHandle DRAMAddr 0x41487000
     6:   110.336 [PROPAD] SerialFlash Packages!! 0x10000
     7:   113.152 [SF] readManufactureCodeSerialFlash 0xc2
     8:   113.152 [SF] MACRONIX
     9:   123.392 [PROPAD] SerialFlash Packages!! 0x7
    10:   123.392 [PROPAD] pFromProperty->pNextWriteAddress 0x10000
    11:   123.648 [SEQ] NotifyComplete (Cur = 0, 0x2008000, Flag = 0x8000)
    12:   147.456 [SEQ] NotifyComplete (Cur = 0, 0x2000000, Flag = 0x2000000)
    13:   147.712 [SEQ] seqEventDispatch (Startup, 0)
    14:   147.712 [STARTUP] startupEntry
    15:   178.176 [PWM] PWM_Initialize
    16:   178.944 [ADC] InitializePollingADC
    17:   190.208 [ ADC ] Calibration Completed, 0x00000000
    18:   211.712 [PROPST] Initialize Adjective & Situation
    19:   232.192 [PROPST] Initialize FlaverPCValid 1 (0)
    20:   232.704 [PROPST] Initialize FlaverPCValid 2 (1)
    21:   232.704 [PROPST] Initialize FlaverPCValid 3 (1)
    22:   232.704 [PROPST] @@@JudgeRestoreFlavorPC 701
    23:   273.152 [STARTUP]startupCompleteCallback 0x2
    24:   273.664 [SEQ] NotifyComplete (Cur = 1, 0x2, Flag = 0x2)
    25:   281.344 [PRP] DivideCameraInitData in L:489
    26:   282.880 [PROPST] dwNewAeModeDial = 3
    27:   285.696 [PROPST] ChangeAEMode -> 3 @AE_MODE_DIAL
    28:   286.208 [PROPST] Active Adjective & Situation 2->3
    29:   286.208 [PROPST] ReqChangeCBR : Adjective 0, 0
    30:   286.208 [PROPST] Not ExecMultiConvert Already None : Adjective 0, 0
    31:   286.464 [PROPST] Not ExecMultiConvert : Situation 0
    32:   286.976 [PROPST] !! Convert End !!
    33:   288.000 [PROPAD] DataType = 0x2000000 fModify = TRUE
    34:   291.072 [PRP] Deliv WaitID = 0x80000001, 0xFE15E275(1)
    35:   319.488 [PROPST] PROP_DISTORTION_COMP 0
    36:   326.912 [PROPST] PROP_LIGHT_FALLOFF_COMP 1 (Excluding:0)
    37:   332.800 [PROPST] PROP_CHROMATISM 1 (Excluding:0)
    38:   353.792 [PRP] Complete WaitID = 0x80000001, 0xFE15E275(0)
    39:   354.048 [PRP] SpecialComplete ID = 0x80000001, 0x80000001 2907
    40:   378.368 [EM] emSlaveChangeCBR : AUTO_POWEROFF (1)
    41:   379.648 [EM] emSlaveChangeCBR : UILOCK (0x0)
    42:   417.792 [LENS]AfReqAeDataMasterResultCBR
    43:   425.472 [LENS]LensAedataReplyMasterResultCBR
    44:   435.200 [LENS]LensAfdataReplyMasterResultCBR
    45:   444.928 [LENS]LensStatusReplyMasterResultCBR
    46:   455.168 [LENS]MirrorupEmdReplyMasterResultCBR
    47:   463.104 [LENS]MirrorupShutterEndMasterResultCBR
    48:   471.040 [LENS]LensHaltReplyMasterResultCBR
    49:   479.744 [LENS]LensStatusChangeMasterResultCBR
    50:   487.936 [LENS]LvLensDataMasterResultCBR
    51:   499.712 [LENS]LensIdExtMasterResultCBR
    52:   509.184 [LENS]LensSceneDataCBR
    53:   516.608 [LENS]PowerZoomAdapterInfoCBR
    54:   526.848 [LENS]LensDataForImageCBR
    55:   536.064 [LENS]AfMonitorDataMasterResultCBR
    56:   560.640 [MSUB]PROP_LV_LENS
    57:   600.320 [SEQ] seqEventDispatch (Startup, 1)
    58:   600.832 [STARTUP] startupPrepareProperty
    59:   611.328 [PROPST] @@@ dwHdmiPhysicalConnect = 0(900)
    60:   627.456 [HPD] HotPlug TimelapseSetting = 0
    61:   629.760 [HPD] # 0 0 0
    62:   640.512 [HPD] Variangle State 2
    63:   645.376 [HPD] CreateTask Master End
    64:   651.776 [STARTUP] PROP_GPS_AUTO_TIME_SETTING 0
    65:   653.568 [STARTUP]startupCompleteCallback 0x20000000
    66:   653.824 [SEQ] NotifyComplete (Cur = 2, 0x20420010, Flag = 0x20000000)
    67:   653.824 [STARTUP] startupPrepareProperty : CLASSID_FLAG_PROPAD
    68:   654.080 [FM] FM_Initialize (0, 1, 0)
    69:   665.344 [FM] fmResultCBR (0x83b2b8)
    70:   669.952 [FM] PROP_HDD_DCIM_PATH (/)
    71:   672.256 [FC] FC_Initialize [drive:3][ClassID:39]
    72:   698.624 ERROR [RTC] RTC_REGISTER_TIME_CORRECT ERROR 0x0 -> 0x9e
    73:   708.352 ERROR [RTC] !! RTC CHECK ERROR !!

    74:   729.344 [RTC] SPECIAL_OPTION 0x0, 0x0
    75:   736.512 [RTC] permitCharge already permit 0x0
    76:   767.232 [RSC] srmGetShootMemAreaAddress(): Area[4] isn't Exist.
    77:   825.856 [RSC] CreatePackHeapObject
    78:   829.184 [RSC] AllocateMemoryUnit For OnlyMem1
    79:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    80:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    81:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    82:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    83:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    84:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    85:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    86:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    87:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    88:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    89:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    90:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    91:   829.440 [RSC] AllocateMemoryUnit For OnlyMem1
    92:   838.656 [RSCC] ClearBusy(0x1) 0x40->0x40,0x0(0x40)[0,0]
    93:   840.192 [RSC] RearrangeMemMgr add 1 0 2
    94:   840.192 [RSCC] ClearBusy(0x1) 0x40->0x40,0x0(0x40)[0,0]
    95:   841.216 [RSC] fDevDone 1, dwLvLock 0
    96:   841.216 [RSC] 0 0 0
    97:   841.728 [RSC] PROP_MEMORY_STATUS(SELF) (10->)13 (OTHER) 0, 4987
    98:   841.728 [RSC] Deliver PROP_MEMORY_STATUS 19
    99:   848.128 [RSC] MemMgr(IMAGE) 0 2
   100:   848.640 [RSC] MemMgr(IMAGE) 0 0
   101:   848.640 [RSC] MemMgr(IMAGE) 0 0
   102:   848.640 [RSC] MemMgr(IMAGE) 0 0
   103:   872.448 [RSCC] this->dwCardStatus[0] = 0x1(525)
   104:   873.728 [RSC] fDevDone 1, dwLvLock 0
   105:   873.728 [RSC] 0 0 0
   106:   883.200 [RSCC] this->dwCardStatus[1] = 0x1(525)
   107:   884.224 [RSC] fDevDone 1, dwLvLock 0
   108:   884.224 [RSC] 0 0 0
   109:   891.392 [RSCC] PROP_PC_HDD_STATUS = 0x1
   110:   898.816 [RSC] fDevDone 1, dwLvLock 0
   111:   899.072 [RSC] 0 0 0
   112:   908.544 [RSC] fDevDone 1, dwLvLock 0
   113:   909.056 [RSC] 0 0 0
   114:   921.344 [RSC] fDevDone 1, dwLvLock 0
   115:   921.600 [RSC] 0 0 0
   116:   944.640 [RSC] fDevDone 1, dwLvLock 0
   117:   944.896 [RSC] 0 0 0
   118:   954.880 [RSCC] PROP_SAVE_MODE = 0x1
   119:   963.584 [RSCC] PROP_CARD0_FOLDER_NUMBER
   120:   971.520 [RSCC] PROP_CARD1_FOLDER_NUMBER
   121:   995.072 [RSCC] PROP_NUMBER_OF_CONTINUOUS_MODE BaseDcfNo 8556
   122:  1001.984 [RSC] fDevDone 1, dwLvLock 0
   123:  1002.496 [RSC] 0 0 0
   124:  1010.944 [RSC] fDevDone 1, dwLvLock 0
   125:  1011.456 [RSC] 0 0 0
   126:  1021.696 [RSC] fDevDone 1, dwLvLock 0
   127:  1021.696 [RSC] 0 0 0
   128:  1022.208 [RSCC] PROP_CARD_EXTENSION 0
   129:  1041.920 [RSCC] PC_CLUSTER_SIZE = 0x1000
   130:  1067.264 [RSC] SetAutoIsoCode 0x83
   131:  1067.776 [RSCC] ChangeAutoIsoCode Factor:1 AutoIsoCode:131 -> 131
   132:  1076.224 [RSC] SetAutoIsoCode 0x83
   133:  1076.480 [RSCC] ChangeAutoIsoCode Factor:2 AutoIsoCode:131 -> 131
   134:  1079.808 [RSCC] ClearBusy(0x1) 0x40->0x40,0x0(0x40)[0,0]
   135:  1080.576 [RSC] fDevDone 1, dwLvLock 0
   136:  1080.576 [RSC] 0 0 0
   137:  1086.976 [RSC] fDevDone 1, dwLvLock 0
   138:  1087.232 [RSC] 0 0 0
   139:  1098.752 [RSCC] ClearBusy(0x40000) 0x40->0x40,0x0(0x40)[0,0]
   140:  1107.456 [RSCC] ClearBusy(0x40000) 0x40->0x40,0x0(0x40)[0,0]
   141:  1116.416 [RSCC] ClearBusy(0x40000) 0x40->0x40,0x0(0x40)[0,0]
   142:  1124.352 [RSCC] ClearBusy(0x40000) 0x40->0x40,0x0(0x40)[0,0]
   143:  1131.008 [RSC] SetAutoIsoCode 0x58
   144:  1131.264 [RSCC] ChangeAutoIsoCode Factor:0 AutoIsoCode:131 -> 88
   145:  1141.248 [RSCC] ClearBusy(0x1) 0x40->0x40,0x0(0x40)[0,0]
   146:  1141.760 [RSC] fDevDone 1, dwLvLock 0
   147:  1142.016 [RSC] 0 0 0
   148:  1148.928 [RSC] fDevDone 1, dwLvLock 0
   149:  1149.440 [RSC] 0 0 0
   150:  1157.632 [RSC] fDevDone 1, dwLvLock 0
   151:  1158.144 [RSC] 0 0 0
   152:  1188.608 [RSCC] RU CLUSTER_SIZE[0] = 0x407A0150
   153:  1196.288 [RSCC] RU CLUSTER_SIZE[1] = 0x407A015C
   154:  1213.440 [EM] emRegisterMulticastCallback : EventID = 0, ClassID = 68
   155:  1218.816 [EM] emRegisterMulticastCallback : EventID = 11, ClassID = 68
   156:  1220.096 [EM] Already SW1OFF
   157:  1230.080 [EM] emRegisterMulticastCallback : EventID = 14, ClassID = 68
   158:  1236.480 [EM] emRegisterMulticastCallback : EventID = 15, ClassID = 68
   159:  1242.368 [EM] emRegisterMulticastCallback : EventID = 4, ClassID = 68
   160:  1251.328 [FM] FM_RegisterSpaceNotifyCallback
   161:  1252.352 [MRK] MRK_RegisterSpaceNotifyCallback
   162:  1253.120 [MRK] RegisterSpaceNotifyCallback : DriveNo = 2
   163:  1253.376 [FM] voiRegisterSpaceNotifyCallback : DriveNo = 2
   164:  1253.376 [LVMOV][GPS] GPS_RegisterSpaceNotifyCallback
   165:  1253.632 [FM] [GPS] gpsRegisterSpaceNotifyCallback : DriveNo = 2
   166:  1253.888 [FM] RegisterSpaceNotifyCallback : DriveNo = 2
   167:  1254.144 [FC] FcmcRegisterSpaceNotifyCallback : DriveNo = 2
   168:  1254.400 [FM] FM_RegisterSpaceNotifyCallback
   169:  1261.056 [BIND] Stage : NORMAL
   170:  1263.616 [JOB] InitializeJobClass (ID = 8331, Num = 14)
   171:  1263.616 [JOB] InitializeJobClass 84 206 17216 22940
   172:  1267.456 [JOB] [BIND] dcsResultCBR (0x83d3a4)
   173:  1271.552 [JOB] PROP_GPS_INFORMATION fGPSConnect = 0x0
   174:  1271.552 [JOB] MPU 0x0 USB 0x0 WFT 0x0 INNER 0x0
   175:  1271.552 [JOB] PROP_MPU_GPS fGPSConnect = 0x0
   176:  1271.808 [JOB] MPU 0x0 USB 0x0 WFT 0x0 INNER 0x0
   177:  1272.576 [JOB] @@@setDefaultImgDirection
   178:  1272.832 [JOB] PROP_GPS_DEVICE_ACTIVE INNER 0x0 fGPSConnect = 0x0
   179:  1273.088 [JOB] @@@setDefaultImgDirection
   180:  1276.928 [JOB] PROP_BTDEVICE_CONNECT WFT 0x0 fGPSConnect = 0x0
   181:  1292.288 [EM] emLockControl (TYPE_JOBSTATE = 0x0)
   182:  1298.176 [RSC] fDevDone 1, dwLvLock 0
   183:  1298.944 [RSC] 0 0 0
   184:  1330.688 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   185:  1331.456 [PRP] ERROR NOT FOUND PROPERTY ID = 0x01000007 L:2849
   186:  1337.088 [EM] emRegisterMulticastCallback : EventID = 20, ClassID = 72
   187:  1341.440 [JOB] InitializeInnerDevelopJobClass (ID = 8331, Num = 16)
   188:  1341.696 [JOB] InitializeMultipleExposureShootJobClass ( Num = 28,11 )
   189:  1341.696 [JOB] InitializeMultipleExposureSaveAndEndJobClass ( Num = 14 )
   190:  1341.952 [JOB] InitializeHDRShootJobClass ( Num = 12 )
   191:  1341.952 [JOB] InitializeHDRSaveAndEndJobClass ( Num = 36 )
   192:  1342.208 [JOB] InitializeGISShootJobClass ( Num = 12 )
   193:  1342.208 [JOB] InitializeGISSaveAndEndJobClass ( Num = 27, 30 )
   194:  1342.976 [JOB] InitializeShufflehootJobClass (ID = 8331, Num = 14)
   195:  1348.864 [GUILOCK]InitializeGUILock (PUB)
   196:  1360.896 [GUILOCK][GUI] MasterResultCBR
   197:  1364.224 [TERM] terminateChangeCBR : SHUTDOWN (255)
   198:  1364.480 [TERMINATE] SHUTDOWN init comp
   199:  1364.736 [TERM] terminateChangeCBR : AUTO_POWEROFF (1)
   200:  1364.736 [TERMINATE] Abort init comp
   201:  1380.608 [EM] emRegisterMulticastCallback : EventID = 0, ClassID = 156
   202:  1385.472 [EM] emRegisterMulticastCallback : EventID = 1, ClassID = 156
   203:  1390.848 [EM] emRegisterMulticastCallback : EventID = 4, ClassID = 156
   204:  1399.296 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   205:  1400.064 [PRP] ERROR NOT FOUND PROPERTY ID = 0x01000007 L:2849
   206:  1401.344 [FSS] PROP_SHOOTING_TYPE (0x0->0x0)
   207:  1401.344 [FSS] PROP_AF_SHIFT_AFB_INFO (0x0 0)
   208:  1446.912 [EM] emRegisterMulticastCallback : EventID = 0, ClassID = 244
   209:  1452.032 [EM] emRegisterMulticastCallback : EventID = 11, ClassID = 244
   210:  1453.056 [EM] Already SW1OFF
   211:  1455.872 [MC] MeteringTimerStart
   212:  1459.200 [EM] emRegisterMulticastCallback : EventID = 7, ClassID = 244
   213:  1465.088 [EM] emRegisterMulticastCallback : EventID = 1, ClassID = 244
   214:  1469.952 [EM] emRegisterMulticastCallback : EventID = 4, ClassID = 244
   215:  1475.328 [EM] emRegisterMulticastCallback : EventID = 6, ClassID = 244
   216:  1480.192 [EM] emRegisterMulticastCallback : EventID = 3, ClassID = 244
   217:  1485.312 [EM] emRegisterMulticastCallback : EventID = 2, ClassID = 244
   218:  1491.200 [EM] emRegisterMulticastCallback : EventID = 20, ClassID = 244
   219:  1496.832 [EM] emRegisterMulticastCallback : EventID = 22, ClassID = 131
   220:  1501.952 [EM] emRegisterMulticastCallback : EventID = 23, ClassID = 131
   221:  1516.032 [MC] PROP_DISPLAY_OFF_SENSOR 1
   222:  1516.544 [MC] PROP_DISPSENSOR_CTRL 1(0)
   223:  1517.568 [MC] PROP_SHOOTING_TYPE 0
   224:  1517.824 [MC] set_lv_act2 : 0 -1 1 0
   225:  1518.080 [MC] PROP_GUI_STATE 0
   226:  1518.592 [MC] PROP_LV_ACTION LV_STOP
   227:  1518.848 [MC] judge_lv_disp_busy(mode_change): 0 0 1 1 0
   228:  1519.360 [MC] PROP_LV_DISPBUSY not Busy
   229:  1519.616 [MC] PROP_LV_LOCK LVLOCK_PERMIT
   230:  1519.616 [MC] set_lv_act2 : 0 1 1 0
   231:  1519.616 [MC] judge_lv_disp_busy(mode_change): 0 0 1 1 0
   232:  1519.872 [MC] PROP_DISABLE_PLAY_IMAGE Enable Play
   233:  1519.872 [MC] JobState 0
   234:  1519.872 [MC] on_digi_event start
   235:  1520.384 [MC] set_lv_act2 : 0 1 1 0
   236:  1520.384 [MC] judge_lv_disp_busy(mode_change): 0 0 1 1 0
   237:  1520.896 [MC] PROP_AE_MODE m_AeMode=0x03 m_SetTv =0x70 ,m_ModeBulb=0
   238:  1521.152 [MC] PROP_SET_TV  m_SetTv =0x4D m_AeMode=0x03 ,m_ModeBulb=0
   239:  1521.664 [MC] QRTime 0
   240:  1522.944 [DISP] ForceBackLightOff
   241:  1523.200 [DISP] ERROR BackLightCtrl:0
   242:  1523.712 [MC] PROP_VARIANGLE_GUICTRL Enable
   243:  1523.968 [MC] PROP_HEADPHONE_VOLUME_VALUE : 0
   244:  1523.968 [MC] PROP_MOVIE_PLAY_VOLUME : 0
   245:  1524.480 [MC] PROP_LCD_OFFON_BUTTON : 2
   246:  1524.736 [MC] PROP_LV_CFILTER 0
   247:  1524.736 [MC] set_lv_act2 : 0 1 1 0
   248:  1524.992 [MC] judge_lv_disp_busy(mode_change): 0 1 1 1 0
   249:  1530.880 [MC] PROP_GUIGROUND_STATE 0
   250:  1537.024 [MC] PROP_LV_ACTION LV_STOP
   251:  1537.536 [MC] judge_lv_disp_busy(mode_change): 0 1 1 1 0
   252:  1556.480 [MC] PROP_VARIANGLE_GUICTRL Disable
   253:  1576.192 [MC] PROP_LV_DISPBUSY Busy
   254:  1582.080 [MC] PROP_LV_DISPBUSY Busy
   255:  1586.944 [MC] PROP_LV_DISPBUSY Busy
   256:  1592.832 [MC] PROP_LV_DISPBUSY not Busy
   257:  1607.680 [MC] CardCover=0
   258:  1608.448 [MC] regist master CardCover
   259:  1611.776 [EM] emRegisterMulticastCallback : EventID = 13, ClassID = 244
   260:  1614.336 [TA10] TA10_Initialize : Start
   261:  1655.296 [TA10] ### TA10Setting Clear (OFF->OFF) ###
   262:  1656.576 [TA10] ERROR Irregular TotalSheets 0 !!
   263:  1657.344 [TA10] ChangePropCBR ShotsPlan 2 / TotalSheets 2
   264:  1704.960 [TA10] TA10_Initialize : End
   265:  1705.472 [HDR] HDR_Initialize : Start
   266:  1729.280 [HDR] ### HDRSetting Clear (OFF->OFF) ###
   267:  1730.304 [HDR] ChangePropCBR HDRFunc 0
   268:  1732.352 [HDR] HDRS_Initialize
   269:  1732.608 [HDR] CreateStageClass
   270:  1741.824 [HDR] HDRS_Initialize : End
   271:  1742.080 [HDR] HDR_Initialize : End
   272:  1742.336 [GIS] GIS_Initialize : Start
   273:  1762.560 [GIS] ### GISSetting Clear (OFF->OFF) ###
   274:  1763.328 [GIS] ChangePropCBR GISFunc 0
   275:  1766.912 [GIS] GISS_Initialize
   276:  1767.168 [GIS] CreateStageClass
   277:  1773.568 [GIS] GISS_Initialize : End
   278:  1773.824 [GIS] GIS_Initialize : End
   279:  1781.248 [FM] PROP_CARD1_STATUS = 0x1
   280:  1788.672 [FM] PROP_CARD1_FOLDER_NUMBER = 142
   281:  1796.352 [FM] PROP_CARD1_FILE_NUMBER = 0
   282:  1810.176 [FM] PROP_CARD2_STATUS = 0x1
   283:  1817.856 [FM] PROP_CARD2_FOLDER_NUMBER = 100
   284:  1826.560 [FM] PROP_CARD2_FILE_NUMBER = 8556
   285:  1837.056 [FM] PROP_FILE_NUMBERING_MODE = 1, 0
   286:  1841.408 [FM] PROP_CARD_EXTENSION = 0
   287:  1847.296 [FM] PROP_CURRENT_MEDIA = 2
   288:  1851.392 [FM] PROP_USBDEVICE_CONNECT = -1
   289:  1853.952 [FM] PROP_NUMBER_OF_CONTINUOUS_MODE = 8556
   290:  1853.952 [STARTUP]startupCompleteCallback 0x10
   291:  1854.208 [SEQ] NotifyComplete (Cur = 2, 0x420010, Flag = 0x10)
   292:  1858.304 [FM] PROP_DSDEFINE ModelId 80000350
   293:  1861.888 [FM] PROP_APPENDMOVINFO Handle 0,205001d
   294:  1862.400 [FM] PROP_APPENDMOVINFO VideoSnapMode 4,205001d
   295:  1867.008 [FM] PROP_SPECIAL_OPTION = 0
   296:  1871.104 [FM] PROP_SCREEN_SAVER = 0
   297:  1875.968 [FM] PROP_CARD1_RU_SIZE -1
   298:  1879.552 [FM] PROP_CARD2_RU_SIZE 65536
   299:  1885.952 [FM] fmInitialized
   300:  1893.888 [FC] _FC_SetDirSuffix (CANON)
   301:  1897.216 [FM] fmPrepare
   302:  1919.488 [CSMGR] Card ManageArea�@Address�@:�@0x008465c4
   303:  1920.256 [FM] fmAllocDcfNo(0x479e4c)(0x0)
   304:  1925.120 [RSCC] srmAllocDcfNoTable
   305:  1926.144 [FM] fmAllocateDcfNoCompleteCallback(0x43ae8c00,0x4000)
   306:  1935.360 [FM] fmAllocDcfNo : DcfNoTable(0x43ae8c00)
   307:  1946.880 [NFC] PropChange:PROP_SPECIAL_OPTION Wlan off (0x0)
   308:  1952.000 [SD] ---- SDEventHandler(ID=1:Event=8) ----
   309:  1975.296 [SD] SD initialize start
   310:  1990.144 [SD] SD initialize end speed=0 clock=12 UHS=0
   311:  1992.192 [SD] Name: QEMU! Size: 247(7bc00)
   312:  1992.448 [SD] nBlocks=506880, blksPerTrack=0, nHeads=0
   313:  1995.776 [FSU] fsuGetPart: Block(99, 506781, 506880)
   314:  2003.968 [FSU] efat_map_filesys 99 B: 1
   315:  2008.576 [SD] default ru size (SC)
   316:  2075.136 [FSU] AllocateMemory For Speed Class!!!
   317:  2013.696 [FSU] Attach SC 0 80 80 8 248 248
   318:  2016.512 [FM] EV_INSERTION_COMPLETE : ID = 2, stat = 8192
   319:  2016.512 [FM] bWormCard = 0
   320:  2016.512 [FM] bWriteOnceCard = 0
   321:  2020.096 [FM] fmNormalMountCard (ID = 2, Ret = 0)
   322:  2020.608 [FM] fmPrepareShooting (Drive = 2)
   323:  2021.120 [FC] _FC_PrepareCatalog (2, B:)
   324:  2114.304 [FM] DirNo = 100, FileNo = 0
   325:  2050.048 [FM] Cluster = 16384, Total = 15832, Free = 13444 RU = -1 FreeRU = 1653
   326:  2050.560 [FC] _FC_GetNewDirDcfNo (2, 0, 0, 0)
   327:  2050.816 [FM] fmSetInitialCardInfo (Drive = 2, 0)
   328:  2070.016 [RSCC] this->dwCardStatus[1] = 0x1(525)
   329:  2071.552 [RSC] fDevDone 1, dwLvLock 0
   330:  2071.552 [RSC] 0 0 0
   331:  2102.272 [RSCC] PROP_CARD1_FOLDER_NUMBER
   332:  2132.736 [RSCC] RU CLUSTER_SIZE[1] = 0x407A015C
   333:  2141.952 [FM] fmWrapperRU1 : DriveNo = 2 B: 1653
   334:  2141.952 [FM] fmWrapperRU : DriveNo = 2 B: 1653
   335:  2145.280 [RSCC] Storage Space 13444, FreeRUCount 1653
   336:  2224.384 [FM] pfNotifyDcfNoCBR(2:100_0000)
   337:  2162.432 [RSCC] srmNotifyDcfNo 0x2 100 0 0 1
   338:  2162.688 [RSCC] srmSetDcfNoTableOrDiff 1 100 0 1
   339:  2162.688 [RSCC] Diff Dcf List
   340:  2162.944 [RSCC] Create Diff Dcf ListItem 100
   341:  2163.456 [RSCC] fTemporary 1 pMaxDcfNoInFolder->fTemporary 1
   342:  2163.456 [RSCC] Diff Dcf Over Write 100
   343:  2163.968 [RSCC] ####### [1]DCF No 8556
   344:  2170.880 [RSC] ERROR GetEstimatedSizeOfMovie NOT Exist Size or FrameRate K347 0 1 0
   345:  2173.952 [RSC] ERROR GetMargineSizeOfMovie NOT Exist Size or FrameRate K347 0 1 0
   346:  2243.328 [RSC] ERROR GetEstimatedSizeOfMovieThumb NOT Exist Size or FrameRate K347 0
   347:  2181.120 [RSC] ERROR GetEstimatedSizeOfMovie NOT Exist Size or FrameRate K347 0 1 0
   348:  2184.192 [RSC] ERROR GetMargineSizeOfMovie NOT Exist Size or FrameRate K347 0 1 0
   349:  2253.568 [RSC] ERROR GetEstimatedSizeOfMovieThumb NOT Exist Size or FrameRate K347 0
   350:  2191.872 [RSC] ERROR GetEstimatedSizeOfMovie NOT Exist Size or FrameRate K347 0 1 0
   351:  2193.664 [RSCC] BURST 4 Enable 4 Reserve 32504576
   352:  2193.920 [RSCC] Burst 4 ENABLE 4 Reserve 32504576
   353:  2194.176 [RSCC] ClearBusy(0x2100) 0x40->0x40,0x0(0x40)[0,0]
   354:  2194.432 [STARTUP]startupCompleteCallback 0x20000
   355:  2194.688 [SEQ] NotifyComplete (Cur = 2, 0x420000, Flag = 0x20000)
   356:  2223.616 [STARTUP]startupCompleteCallback 0x400000
   357:  2224.128 [SEQ] NotifyComplete (Cur = 2, 0x400000, Flag = 0x400000)
   358:  2293.248 [FM] PROP_CARD2_STATUS = 0x1
   359:  2301.696 [FM] PROP_CARD2_FOLDER_NUMBER = 100
   360:  2243.072 [FM] PROP_CARD2_RU_SIZE -1
   361:  2252.032 [FM] PROP_CARD2_FILE_NUMBER = 8556
   362:  2253.568 [SEQ] seqEventDispatch (Startup, 2)
   363:  2320.128 [STARTUP] startupPrepareCapture
   364:  2334.464 [SHTLVME][MNAV] MEMNAVI_Initialize
   365:  2273.024 [SHTLVME][MNAV] MEMNAVI_SetMemoryMap: 1
   366:  2344.192 [EM] emRegisterMulticastCallback : EventID = 14, ClassID = 147
   367:  2350.080 [EM] emRegisterMulticastCallback : EventID = 2, ClassID = 147
   368:  2354.944 [EM] emRegisterMulticastCallback : EventID = 3, ClassID = 147
   369:  2360.832 [EM] emRegisterMulticastCallback : EventID = 15, ClassID = 147
   370:  2301.184 [EM] emRegisterMulticastCallback : EventID = 5, ClassID = 147
   371:  2372.608 [EM] emRegisterMulticastCallback : EventID = 6, ClassID = 147
   372:  2378.496 [EM] emRegisterMulticastCallback : EventID = 1, ClassID = 147
   373:  2383.104 [EM] emRegisterMulticastCallback : EventID = 4, ClassID = 147
   374:  2388.992 [EM] emRegisterMulticastCallback : EventID = 8, ClassID = 147
   375:  2393.344 [EM] emRegisterMulticastCallback : EventID = 9, ClassID = 147
   376:  2399.744 [EM] emRegisterMulticastCallback : EventID = 10, ClassID = 147
   377:  2340.864 [EM] emRegisterMulticastCallback : EventID = 17, ClassID = 147
   378:  2413.568 [EM] emRegisterMulticastCallback : EventID = 18, ClassID = 147
   379:  2420.224 [EM] emRegisterMulticastCallback : EventID = 19, ClassID = 147
   380:  2426.112 [EM] emRegisterMulticastCallback : EventID = 21, ClassID = 147
   381:  2437.632 [SHTC] scsProperty ID=0x80030012(0x0)
   382:  2441.728 [SHTC] scsIgnore
   383:  2449.152 [SHTC] scsProperty ID=0x0(0x200884)
   384:  2456.576 [SHTC] scsProperty ID=0x80040004(0x0)
   385:  2463.232 [SHTC] scsProperty ID=0x80040069(0x0)
   386:  2469.376 [SHTC] scsInit
   387:  2479.616 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   388:  2480.384 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   389:  2480.384 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   390:  2480.384 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   391:  2480.384 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   392:  2480.640 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   393:  2480.640 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   394:  2480.640 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   395:  2480.640 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   396:  2480.640 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   397:  2480.896 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   398:  2480.896 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   399:  2480.896 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   400:  2480.896 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   401:  2481.152 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   402:  2481.152 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   403:  2481.152 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   404:  2481.152 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   405:  2481.152 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   406:  2481.408 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   407:  2481.408 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   408:  2481.408 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   409:  2481.408 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   410:  2481.408 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   411:  2481.664 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   412:  2481.664 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   413:  2488.832 [CAPE] InitializeHeadControl
   414:  2489.856 [SHTC] Mem1Component Size=0x13c7b0
   415:  2490.624 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   416:  2492.672 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   417:  2498.560 [PROPAD] ERROR SearchPropertyPackage DataType (0) = 0x01000000(L:3114)
   418:  2504.192 [SHTC] DarkCurrentBuffer:0x4219c400, Size:139264
   419:  2504.960 [STARTUP]startupCompleteCallback 0x40000
   420:  2504.960 [SEQ] NotifyComplete (Cur = 3, 0xc0000, Flag = 0x40000)
   421:  2510.848 [RSCC] RealClearBusy(0x40) 0x40->0x0,0x0(0x0)
   422:  2536.704 [STARTUP]startupCompleteCallback 0x80000
   423:  2537.216 [SEQ] NotifyComplete (Cur = 3, 0x80000, Flag = 0x80000)
   424:  2555.648 [SHTB] sbsInit
   425:  2559.744 [SHTB] VShadingAddress:0x421be400, Size:2226176
   426:  2570.240 [SHTP] Init
   427:  2573.824 [SEQ] seqEventDispatch (Startup, 3)
   428:  2576.640 [FSU] RU defaults !
   429:  2577.664 [SD] ---- SDEventHandler(ID=1:< B: >) Mounted ----


8)

The current emulation state lets you debug pretty much anything relevant to porting ML, except... cache coherency issues (see posts from sombree; didn't investigate yet) and GUI (but see these messages about EOS M3 (http://www.magiclantern.fm/forum/index.php?topic=2864.msg194932#msg194932)).

@ anyone willing to help:

Please confirm this works on your system. I'm not looking for memes, but for DIGIC 6 owners willing to actively help porting ML to their camera; with this tiny step, I only want to make sure you can use the emulator on your PCs (if it only works for me, it's not good enough). If unsure where to start, please watch the videos linked earlier. Proof-reading the QEMU guide (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/) is also very welcome. If it helps, I can do similar video demo for Windows (http://www.magiclantern.fm/forum/index.php?topic=20214.0).
Title: Re: Canon 80D
Post by: goldenchild9to5 on December 22, 2017, 07:01:01 AM
awesome work @a1ex I'm gonna have to get a 80D to help with the Porting. 
Title: Re: Canon 80D
Post by: a1ex on December 22, 2017, 09:46:56 AM
The following does not require an 80D - any EOS model can be used, as long as ML runs on it or there's a ROM dumper available (models ranging from DIGIC 2 to DIGIC 6):

Quote from: a1ex on December 22, 2017, 12:23:42 AM
Proof-reading the QEMU guide (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/) is also very welcome.

By that I mean not just finding grammar issues or typos (although these are also welcome), but trying out the commands and finding typos there, or additional dependencies or whatever else you had to tweak to get things working on your system and so on.

I hope the above stuff can be easily ported to 750D/760D, and a little harder to 5D4, 5DS and 7D2 (hopefully that's the increasing order of difficulty); here, 80D just happened to be the easiest.
Title: Re: Canon 80D
Post by: goldenchild9to5 on December 23, 2017, 12:45:28 AM
@a1ex ok copy..
Title: Re: Canon 80D
Post by: OlRivrRat on December 23, 2017, 05:44:01 AM
                     @Alex

           I have access to 5DC, 5D2, SL1, 80D, & 70D ~ But absolutely no Coding Savvy ~ What can I do to help ?

Computer Hardware is Mac Pro Early'08 running OS 10.6.8 & 10.11.6 & Windows Vista (via Parallels Desktop)~

                                                                                     OWW ~ DeanB
Title: Re: Canon 80D
Post by: sombree on December 23, 2017, 01:40:14 PM
@a1ex
I can confirm that it works. Weird thing - LOG000.LOG is in chinese  (https://hastebin.com/woxahugocu) :o
Title: Re: Canon 80D
Post by: a1ex on December 23, 2017, 03:18:08 PM
Quote from: sombree on December 23, 2017, 01:40:14 PM
Weird thing - LOG000.LOG is in chinese  (https://hastebin.com/woxahugocu) :o

Try interpreting it as ASCII (notepad, cat to a terminal etc, hex editor as a last resort).
Title: Re: Canon 80D
Post by: sombree on December 23, 2017, 09:34:09 PM
Thanks, with cat I'm getting proper output which looks pretty same as yours - link (https://hastebin.com/egixulobah.vbs).
Title: Re: Canon 80D
Post by: dfort on December 24, 2017, 05:56:03 PM
Quote from: a1ex on November 10, 2017, 08:02:36 AM
Todo: try on 700D/100D/M/6D/M2 in QEMU and ask owners of these cameras to try on real hardware).

Tried on 700D:

Key event: b9 -> 0c00
[MPU] Sending : 06 05 06 0c 00 00  (GUI_SWITCH)
[MPU] Received: 06 05 03 19 01 00  (PROP_TFT_STATUS - spell #292)
[MPU] Received: 06 05 03 19 01 00  (PROP_TFT_STATUS - spell #292)
Save configs...
Opening serial flash...
Dumping serial flash... 100%
Closing serial flash...
Done!
[MPU] Received: 06 05 03 11 01 00  (unnamed - spell #14)


MD5 checks out between the SFDATA.BIN that was created on the camera and the one created in QEMU.


MD5 (/Users/rosiefort/qemu/700D/SFDATA.BIN) = bd83f093d587027a03922f47711b57da
MD5 (/Volumes/EOS_DIGITAL/ML/LOGS/SFDATA.BIN) = bd83f093d587027a03922f47711b57da


So is this really working? The SFDATA.BIN was needed to run QEMU on the 700D in the first place.

Back on topic -- will this work on the 80D in QEMU? Seems we are a long way away from getting the sf_dump module working on this camera.
Title: Re: Canon 80D
Post by: Randyc714 on December 24, 2017, 06:52:58 PM
I hope you can pull it off and it works on the 750d - I'd love to ditch the plugged in intravalometer and use ML like I could with a T3i!!
Title: Re: Canon 80D
Post by: OlRivrRat on December 25, 2017, 06:47:10 AM
                     TATMBI (To Any1 That Might Be Interested)

           Thanks to Clear Directions from DFort I have in My possession a Set of ROM Dumps from the 80D ~

EMail Me if You would like to have them to tinker with ~ [email protected] ~

                                                                                   ORR ~ DeanB
Title: Re: Canon 80D
Post by: sombree on December 27, 2017, 09:33:49 PM
I've playing a little with qemu and found this:
(https://i.imgur.com/KiDctrBm.png?1) (https://imgur.com/KiDctrB)
Sadly, console locks up after pushing any button.

Also, I think I've found stubs needed for sf_dump module:
/** File I/O **/
NSTUB(0xFE482A10 + 1,  FIO_CloseFile)
NSTUB(0xFE4834DC + 1,  FIO_FindClose)                           // proper name: FindClose
NSTUB(0xFE48345A + 1,  FIO_FindNextEx)
NSTUB(0xFE482890 + 1, _FIO_ReadFile)
NSTUB(0xFE482900 + 1,  FIO_SeekSkipFile)
NSTUB(0xFE4829A2 + 1, _FIO_WriteFile)
NSTUB(0xFE482FFE + 1, _FIO_CreateDirectory)
NSTUB(0xFE4827BA + 1, _FIO_CreateFile)
NSTUB(0xFE4833C6 + 1, _FIO_FindFirstEx)
NSTUB(0xFE482AFC + 1, _FIO_GetFileSize)
NSTUB(0xFE482744 + 1, _FIO_OpenFile)
NSTUB(0xFE482824 + 1, _FIO_RemoveFile)
// NSTUB(    ???, _FIO_RenameFile)

/** Serial Flash **/
NSTUB(0xFE344B2A + 1, SF_CreateSerial)
NSTUB(0xFE344AEE + 1, SF_readSerialFlash)
NSTUB(0xFE34663E + 1, SF_Destroy)
Title: Re: Canon 80D
Post by: a1ex on December 30, 2017, 09:40:12 AM
Nice - starting from this screenshot (which confirmed there are serial flash routines in the bootloader), we might have found a way to dump the... serial flash contents directly from bootloader (750D, easy to port to other D6 models):

http://www.magiclantern.fm/forum/index.php?topic=17627.msg195297#msg195297

BTW, to play with the FROMUTILITY menu, all you have to do is to delete AUTOEXEC.BIN from the virtual card and leave it bootable (see the "fromutil" test in run_tests.sh).
Title: Re: Canon 80D
Post by: sombree on December 30, 2017, 02:12:18 PM
Here is what I've found:
- 80D copies blob to 0x40100000 too; blobs size is 0xC890; blob start at 0xFE0259B4
- 6. SROM Dump (SIO READ) is at 0xFE02A8A8
- 7. SROM Dump (QUAD READ) is at 0xFE02ABD8

When I try to execute this from reboot.c
    SF_test     = (void*)0x40104EF4;
    SF_testl();

it shows proper output like "Read Address[0x000000-0x7FFF00]:0x".

Point is that when I'm doing this:
b *0x40104EF4
command
  silent
  print_current_location
  printf "sf_read_sio(%x { ", $r0
  set $addr = $r0
  while *(int*)$addr != -1
    printf "%x ", *(int*)$addr
    set $addr = $addr + 4
  end
  printf "-1 }, %x, %x, %x)\n", $r1, $r2, $r3
  c
end

console outputs this:
[CPU0] 408001CC: MCR p15,0,Rd,cr6,cr1,4:      DRACR <- 0x320      (P:RW U:RW; Inner Non-cacheable; Outer Non-cacheable; Non-shared)
[            :408002c8 ] sf_read_sio(0 { e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 e320f000 e59ff018 e59ff018 fe020040 40800014 40800014 40800014 40800014 0 40800014 40800014 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

After tons of zeores I have a lof of this:
000 e3e00000 e58d0004 e3a00000 eb0019fa e3560000 a000005 e3560001 a000006 e1a00006 eb000f88 e28dd028 e8bd87f0 e28f0e2a eb001a25 ea000002 e3a05001 e28f0fa5 eb001a21 eb000724 eb0006e8 e59f928c e5990024 e3700001 a000002 e28f0d0a eb001a19 e3a05001 e3550000 1a000024 e28f0f9f eb001a14 eb0004f4 e599000c e3700001 a000002 eb000740 eb00028b ea000017 e28f0f97 eb001a0b e3a00001 e5991004 e3710001 1a000003 e28f0f8a eb001a05 eb000735 eb0008ea e3500001 1a00000b e28f0e23 eb0019ff e5990000 e3700001 a000004 eb000744 e28f0f87 eb0019f9 e3a00001 eaffffcd eb000727 eb000272 e5990008 e3700001 a000000 eb0004c0 e59f01f8 e3a01c05 e580140c e2811802 e580140c e590640c e3a01c06 e580140c e2811802 e580140c e590740c e28d0004 eb000679 e59f01c8 e5908000 e3a05000 e3a0a000 ea0001d6 e28f0f6e eb0019dd e3a01e35 e28f0f79 eb001a41 e28f1f7a e28f0f7a eb001a3e e28f1f7b e28f0e1f eb001a3b e20610ff e28f0f7d eb001a38 e20620ff e3520001 a000002 e3520003 a000006 ea00000a e28f0e1e eb0019c9 e20710ff e28f0e1e eb001a2d ea000004 e28f0e1e eb0019c3 e20710ff e28f0f72 eb001a27 e59d0004 e20010ff e28f0e1d eb001a23 e59d0004 e20000ff e3500089 a000002 e35000c2 a000003 ea000004 e28f0e1a eb0019b3 ea000001 e28f0f6b eb0019b0 e208100f e28f0f6b eb001a14 e28f0f6d eb0019ab e28f0f71 eb0019a9 e28f0f73 eb0019a7 e28f0f75 eb0019a5 e28f0f78 eb0019a3 e28f0f7b eb0019a1 e5992000 e1a01009 e28f0e1f eb001a04 e5990000 e3700001 a0000a1 e28f0f7f eb001998 e5992004 e59f11f4 e28f0f7d eb0019fb e5990004 e3700001 a00009b e28f0f80 eb00198f e599200c e59f11fc e28f0f7f eb0019f2 e599000c e3700001 a000095 e28f0f6d eb001986 e28f0f80 eb001984 e28f0f83 eb001982 e3a00000 eb000689 e3500000 a00008e ea00008f 4c 706d756a a fc040000 6e654d0a 6c462075 4e4f2067 a 6f 64 65 72 d2030000 d6060000 2a2a2a0a 2a2a2a2a 2a2a2a2a 5246202a 54554d4f 54494c49 454d2059 5620554e 30207265 2037302e 2a2a2a2a 2a2a2a2a 2a2a2a2a a 7079545b 78253a65 20 4344 79646f42 2073253a 0 30302e30 0 69766552 6e6f6973 5d73253a a 4d41525b 2578303a 78 4d415328 474e5553 29 76655228 2578303a 292978 43494d28 294e4f52 0 4d4f5220 2578303a 78 43414d28 494e4f52 2958 462d4520 3a455355 78257830 a5d 78452e30 66207469 206d6f72 4d4f5246 6e654d20 a75 72452e31 20657361 74636553 a726f 72452e32 20657361 70696843 a 72452e33 20657361 6d726946 65724120 a61 72572e34 20657469 6d6f7266 72616320 a64 72572e35 20657469 6d6f7266 41524420 a4d 69462e36 20206d72 616c6620 78302067 78383025 25783020 20783830 0 a4e4f fc040004 6f422e37 2020746f 616c6620 78302067 78383025 25783020 20783830 0 a46464f 0 fc04000c 70552e38 65746144 616c6620 78302067 78383025 25783020 20783830 0 72432e39 65746165 6f6f4220 69442074 a6b73 78452e41 50206365 72676f72 66206d61 206d6f72 64726163 a e24f0064 eb0018f6 eaffff5c e24f0098 eb0018f3 eaffff62 e24f007c eb0018f0 eaffff68 e28f0f9b eb0018ed e28f0f9d eb0018eb e28f0f9f eb0018e9 e28f0fa1 eb0018e7 e28f0fa3 eb0018e5 e28f0fa5 eb0018e3 e28f3fa7 e28f2fa9 e28f1e2b e28f0fae eb001945 e28f1fb1 e28f0fb3 eb001942 e28f0fb5 eb0018d9 e5cda008 ea000001 eb0007f4 e5cd0008 e5dd0008 e3500000 afffffa e3a0000a e5cd0009 e5cda00a e28d0008 eb0018cd e5dd0008 e2400030 e350004b 308ff100 ea0000bd ea0000b7 ea000048 ea000049 ea00004a ea00004b ea00004c ea00004d ea00004f ea000051 ea000053 ea0000b2 ea0000b1 ea0000b0 ea0000af ea0000ae ea0000ad ea0000ac ea00004d ea00004f ea000051 ea000058 ea000059 ea00005a ea00005b ea00008e ea00008f ea000090 ea0000a1 ea0000a0 ea00009f ea00009e ea00009d ea00009c ea00009b ea00009a ea000089 ea000098 ea000089 ea00008a ea000095 ea00008a ea000093 ea00008b ea000091 ea000090 ea00008f ea00008e ea00008d ea00008c ea00002d ea00002f ea000031 ea000038 ea000039 ea00003a ea00003b ea00006e ea00006f ea000070 ea000081 ea000080 ea00007f ea00007e ea00007d ea00007c ea00007b ea00007a ea000069 ea000078 ea000069 ea00006a ea000075 ea00006a ea000073 ea00006b eb00032f ea000072 eb000318 ea000070 eb000301 ea00006e eb0002b2 ea00006c eb00025f ea00006a e3a00000 eb000163 ea000067 e3a00001 eb000160 ea000064 e3a00003 eb00015d ea000061 eb000736 ea00005f e3a00000 eb00022b ea00005c e28f0c01 eb000228 ea000059 e3a00000 eb000569 e3500000 a000001 eb0005a6 ea000053 eb00058c ea000051 eb0001eb ea00004f eb000181 ea00004d eb00016a ea00004b eb0007e2 ea000049 6f432e43 63656e6e 61632074 a6472 654d2e47 79726f6d 6d754420 a70 72572e49 20657469 61746144 a 69442e4a 74636572 6d754a20 a70 52532e53 4d204d4f a756e65 0 69462e55 75206d72 74616470 a65 48504943 422e5245 4e49 4f534552 45435255 4e49422e 0 544f4f42 4e49422e 0 73252e56 20732520 75207325 74616470 a65 42435242 2e444e49 4e4942 73252e5a 64707520 a657461 0 3e3e20 54474d49 2e545345 4e4942 eb000815 ea000015 eb0007ee ea000013 eb0000fb ea000011 eb0013b3 ea00000f eb000094 ea00000d eb000042 ea00000b e3a04000 e3a05001 ea000008 eb00001f ea000006 e28f002c eb00180d e3a04000 e3a05000 ea000001 e28f0020 eb001808 e3540000 1afffe26 eb0015b5 eb00054d e1a00005 eafffdd8 74697845 a2e 61766e69 2064696c 75706e69 a74 e3510075 a0027d7 e3510073 a002a42 e3b00000 e1a0f00e e1500001 1a000001 e1a00002 ea0017f2 e1a00003 ea0017f0 e92d401c e1a0000d eb000540 e3500000 1a000017 e3a00000 e58d0004 e59f4260 e59d0000 e28d3004 e1a02004 e28f1f95 eb000559 e3500000 1a00000d e59d2004 e3a03001 e1a01004 e3a0033f eb000396 e1a04000 e28f1f8b e28f0f8d eb00183f e28f3e23 e28f2f8f e3a01000 e1a00004 ebffffdc e8bd801c e92d41fc e3a04000 e1a0000d eb000521 e3500000 1a000035 e59f61ec e3a05c01 e3a07000 e58d7004 e59d0000 e28d3004 e1a02006 e28f1c02 eb000539 e3500000 a00002b e1a02005 e3a0133f e1a00006 eb00287a e59f51ec e3a08a15 e58d7004 e59d0000 e28d3004 e1a02005 e28f1f76 eb00052b e3500000 a000024 e59f11d8 e1a02008 e1a00005 eb00286c e59f51cc e3a08caf e58d7004 e59d0000 e28d3004 e1a02005 e28f1f6e eb00051d e3500000 a00001c e59f11b4 e1a02008 e1a00005 eb00285e e3540000 a000008 e3a03001 e3a02802 e1a01006 e3a0033f eb000354 e28f3f4e e28f2f51 e3a01000 ebffff9f e8bd81fc e59d0004 e2601c01 e2800101 e2800502 eb00289f e3a04001 eaffffd0 e59d0004 e2601a15 e0800005 eb002899 e3a04001 eaffffd8 e59d0004 e2601caf e0800005 eb002893 e3a04001 eaffffe0 e52de004 e24dd024 e3e01000 e3a00003 eb000465 eb00155a e3a00000 eb00153a e1a0100d e28d0004 eb00062a e3500005 308ff100 ea00001f ea000003 ea000009 ea00000d ea000011 ea000015 eb00151e eb0004b6 e59d1000 e28d0004 eb000696 e28dd024 e49df004 e3a00001 eb
and then
0 0 0 0 1 494d4448 0 0 0 0 0 0 0 1 49445541 4f 0 0 0 0 0 0 1 20554349 726556 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 }, fffffff0, 0, 40104ef4)
Read Address[0x000000-0x7FFF00]:0x2345
[EEPROM] CS = 0
[DIGIC6]   at 0x40104584:40104FA4 [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: Got READ (03h)
[EEPROM] Verbose: address is now: 0x002345
[EEPROM] Verbose: Sent 256 bytes
[EEPROM] CS = 1
[DIGIC6]   at 0x401046E8:40104FA4 [0xD20B0D8C] <- 0xD0002   : SPI
          5  6  7  8  9  A  B  C  D  E  F  0  1  2  3  4
00002345 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00002355 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00002365 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00002375 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00002385 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00002395 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000023A5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000023B5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000023C5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000023D5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000023E5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000023F5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00002405 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00002415 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00002425 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00002435 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

What am I doing wrong?

Edit: Ok, I got it to work. Still, output isn't exactly the same as yours from 750D:
AUTOEXEC.BIN not found.
File not found.
[GPIO]     at 0x00101CE4:00101EE8 [0xD20B0A24] <- 0xC0003   : Card LED
[DIGIC6]   at 0x0010011C:00101EE8 [0xD203040C] <- 0x500     : MR (RAM manufacturer ID)
[DIGIC6]   at 0x0010011C:00101EE8 [0xD203040C] <- 0x20500   : MR (RAM manufacturer ID)
[DIGIC6]   at 0x0010011C:00101EE8 [0xD203040C] -> 0x3       : MR (RAM manufacturer ID)
[DIGIC6]   at 0x0010011C:00101EE8 [0xD203040C] <- 0x600     : MR (RAM manufacturer ID)
[DIGIC6]   at 0x0010011C:00101EE8 [0xD203040C] <- 0x20600   : MR (RAM manufacturer ID)
[DIGIC6]   at 0x0010011C:00101EE8 [0xD203040C] -> 0x1       : MR (RAM manufacturer ID)
[FlashIF]  at 0x00101648:00101B4C [0xC0000000] -> 0x0       : ???
[FlashIF]  at 0x00101648:00101B4C [0xC0000000] <- 0x1000000 : ???
[FlashIF]  at 0x00101648:00101B4C [0xC0000010] <- 0xD9C50000: 'Write enable' enabled
[ROM1:2]   at 0x00101B4C:00101B4C [0xFC000AAA] <- 0xAA      : ???
[ROM1:2]   at 0x00101B4C:00101B4C [0xFC000554] <- 0x55      : ???
[ROM1:2]   at 0x00101B4C:00101B4C [0xFC000AAA] <- 0x90      : ???
[ROM1:2]   at 0x00101B4C:00101B4C [0xFC000000] <- 0xF0      : ???
[FlashIF]  at 0x00101668:00101B80 [0xC0000010] <- 0x0       : 'Write enable' disabled
[DIGIC6]   at 0x00100150:00101B80 [0xD6060000] -> 0x0       : E-FUSE

************ FROMUTILITY MENU Ver 0.07 ************
[Type:350 Body:DC Revision:0.00]
[RAM:0x3(MICRON)(Rev:0x1)) ROM:0x8 E-FUSE:0x0]
0.Exit from FROM Menu
1.Erase Sector
2.Erase Chip
3.Erase Firm Area
4.Write from card
5.Write from DRAM
6.Firm   flag 0xFC040000 0x00000000 ON
7.Boot   flag 0xFC040004 0xFFFFFFFF ON
8.UpDate flag 0xFC04000C 0xFFFFFFFF OFF
9.Create Boot Disk
A.Exec Program from card
G.Memory Dump
I.Write Data
J.Direct Jump
S.SROM Menu
U.Firm update
V.BOOT.BIN RESOURCE.BIN CIPHER.BIN update
Z.BRCBIND.BIN update
>>s
[DIGIC6]   at 0x0010574C:0010087C [0xD2090008] -> 0x10004   : CLOCK_ENABLE
[DIGIC6]   at 0x0010574C:0010087C [0xD2090008] <- 0x210004  : CLOCK_ENABLE

**** SROM(SIO2) Menu ****
0.Exit from SROM Menu
1.Erase Chip   0x00800000
2.Erase Block  0x00010000
3.Erase Sector 0x00001000
4.Write Data
5.Write from Card
6.SROM Dump(SIO Read)
7.SROM Dump(QUAD Read)
8.Get Info
>>6
Read Address[0x000000-0x7FFF00]:0x1234
[            :00104fa0 ] sf_read_sio(80000f10 { 3 0 12 34 -1 }, 80000b10, 100, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x00104588:00104FA4 [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: Got READ (03h)
[EEPROM] Verbose: address is now: 0x001234
[EEPROM] Verbose: Sent 256 bytes
[EEPROM] CS = 1
[DIGIC6]   at 0x001046E8:00104FA4 [0xD20B0D8C] <- 0xD0002   : SPI
          4  5  6  7  8  9  A  B  C  D  E  F  0  1  2  3
00001234 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00001244 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00001254 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00001264 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00001274 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00001284 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00001294 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000012A4 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000012B4 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000012C4 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000012D4 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000012E4 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000012F4 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00001304 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00001314 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00001324 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

**** SROM(SIO2) Menu ****
0.Exit from SROM Menu
1.Erase Chip   0x00800000
2.Erase Block  0x00010000
3.Erase Sector 0x00001000
4.Write Data
5.Write from Card
6.SROM Dump(SIO Read)
7.SROM Dump(QUAD Read)
8.Get Info
>>8
[            :001056bc ] sf_read_sio(80000f3c { 3 0 0 0 -1 }, 80000f0c, c, 1)                                                                                                                                                   
[EEPROM] CS = 0                                                                                                                                                                                                                 
[DIGIC6]   at 0x00104588:001056C0 [0xD20B0D8C] <- 0xC0003   : SPI                                                                                                                                                               
[EEPROM] Verbose: Got READ (03h)                                                                                                                                                                                                 
[EEPROM] Verbose: address is now: 0x000000                                                                                                                                                                                       
[EEPROM] Verbose: Sent 12 bytes                                                                                                                                                                                                 
[EEPROM] CS = 1                                                                                                                                                                                                                 
[DIGIC6]   at 0x001046E8:001056C0 [0xD20B0D8C] <- 0xD0002   : SPI                                                                                                                                                               
0x80000325                                                                                                                                                                                                                       
                                                                                                                                                                                                                                 
**** SROM(SIO2) Menu ****                                                                                                                                                                                                       
0.Exit from SROM Menu                                                                                                                                                                                                           
1.Erase Chip   0x00800000                                                                                                                                                                                                       
2.Erase Block  0x00010000                                                                                                                                                                                                       
3.Erase Sector 0x00001000                                                                                                                                                                                                       
4.Write Data                                                                                                                                                                                                                     
5.Write from Card                                                                                                                                                                                                               
6.SROM Dump(SIO Read)                                                                                                                                                                                                           
7.SROM Dump(QUAD Read)                                                                                                                                                                                                           
8.Get Info                                                                                                                                                                                                                       
>>7                                                                                                                                                                                                                             
Read Addr[0x000000-0x7FFF00]:0x1234                                                                                                                                                                                             
Read Size[0x4-0x800000]:0x100                                                                                                                                                                                                   
[            :00105194 ] sf_read_sio(80000ee8 { 9f -1 }, 80000edc, 3, 1)                                                                                                                                                         
[EEPROM] CS = 0
[DIGIC6]   at 0x00104588:00105198 [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: Got RDID
[EEPROM] Verbose: READ in RDID = C2h
[EEPROM] Verbose: READ in RDID = 10h
[EEPROM] Verbose: READ in RDID = 0Ch
[EEPROM] CS = 1
[DIGIC6]   at 0x001046E8:00105198 [0xD20B0D8C] <- 0xD0002   : SPI
MID=0xC2
[            :0010473c ] sf_read_sio(80000ebc { 6 -1 }, 0, 0, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x00104588:00104740 [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: Set Write Enable Latch
[EEPROM] CS = 1
[DIGIC6]   at 0x001046E8:00104740 [0xD20B0D8C] <- 0xD0002   : SPI
[            :00104768 ] sf_read_sio(80000ebc { 5 -1 }, 80000eb4, 1, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x00104588:0010476C [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: [SR] >> 0x2
[EEPROM] CS = 1
[DIGIC6]   at 0x001046E8:0010476C [0xD20B0D8C] <- 0xD0002   : SPI
[            :001047b4 ] sf_read_sio(80000ee8 { 1 40 -1 }, 0, 0, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x00104588:001047B8 [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: [SR] << ...
[EEPROM] Verbose: [SR] << 0x40
[EEPROM] CS = 1
[DIGIC6]   at 0x001046E8:001047B8 [0xD20B0D8C] <- 0xD0002   : SPI
[            :001047d8 ] sf_read_sio(80000ebc { 5 -1 }, 80000eb4, 1, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x00104588:001047DC [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: [SR] >> 0x40
[EEPROM] CS = 1
[DIGIC6]   at 0x001046E8:001047DC [0xD20B0D8C] <- 0xD0002   : SPI
[            :0010482c ] sf_read_sio(80000ebc { 4 -1 }, 0, 0, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x00104588:00104830 [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: Reset Write Enable Latch
[EEPROM] CS = 1
[DIGIC6]   at 0x001046E8:00104830 [0xD20B0D8C] <- 0xD0002   : SPI
[            :00104850 ] sf_read_sio(80000ebc { 5 -1 }, 80000eb4, 1, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x00104588:00104854 [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: [SR] >> 0x40
[EEPROM] CS = 1
[DIGIC6]   at 0x001046E8:00104854 [0xD20B0D8C] <- 0xD0002   : SPI
[EEPROM] CS = 0
[DIGIC6]   at 0x001052E0:00104854 [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: Got QOFR (6Bh)
[EEPROM] Verbose: address is now: 0x001234
[DIGIC6]   at 0x00105330:00105330 [0xD20B0D80] <- 0xA0005   : ???
[DIGIC6]   at 0x00105330:00105330 [0xD20B0D84] <- 0xA0005   : ???
[DIGIC6]   at 0x00105330:00105330 [0xD20B0D88] <- 0xA0005   : ???
[DIGIC6]   at 0x00105330:00105330 [0xD20B0A14] <- 0xF       : ???
[DIGIC6]   at 0x00105330:00105330 [0xD20B0A10] <- 0xF       : ???
[DIGIC6]   at 0x00105330:00105330 [0xD20B0A0C] <- 0xF       : ???
[DIGIC6]   at 0x00105330:00105330 [0xD20B0A08] <- 0xF       : ???
[DIGIC6]   at 0x00105330:00105330 [0xD20B0A04] <- 0xF       : ???
[DIGIC6]   at 0x00105330:00105330 [0xD20B0A00] <- 0xF       : ???
[DIGIC6]   at 0x00105330:00105330 [0xD209065C] <- 0x1       : ???
[SFIO]     at 0x0010537C:0010537C [0xC8070004] <- 0x1       : ???
[SFIO]     at 0x0010537C:0010537C [0xC8070090] <- 0xFFBFFFF9: ???
[SFIO]     at 0x0010537C:0010537C [0xC8070000] <- 0x0       : ???
[SFIO]     at 0x0010537C:0010537C [0xC8070018] <- 0xFF      : init?
[SFIO]     at 0x0010537C:0010537C [0xC807001C] <- 0x0       : ???
[SFIO]     at 0x0010537C:0010537C [0xC807002C] <- 0x80002701: response setup?
[SFIO]     at 0x0010537C:0010537C [0xC8070030] <- 0x0       : ???
[SFIO]     at 0x0010537C:0010537C [0xC8070070] <- 0xFFFF    : transfer status?
[SFIO]     at 0x0010537C:0010537C [0xC8070058] <- 0x3       : bus width
[SFIO]     at 0x0010537C:0010537C [0xC8070064] <- 0x610103  : bus width
[SFIO]     at 0x0010537C:0010537C [0xC8070074] <- 0x0       : ???
[SFIO]     at 0x0010537C:0010537C [0xC8070078] <- 0xFF      : ???
[SFIO]     at 0x0010537C:0010537C [0xC80700D0] <- 0x11040606: ???
[SFIO]     at 0x001053DC:0010537C [0xC8070068] <- 0x100     : read block size
[SFIO]     at 0x00105400:001053F4 [0xC807007C] <- 0x1       : transfer block count
[SFIO]     at 0x0010540C:001053F4 [0xC8070010] <- 0x0       : Status
[SFIO]     at 0x0010540C:001053F4 [0xC8070048] <- 0xFFFFFFFF: ???
[SFIO]     at 0x0010540C:001053F4 [0xC807004C] <- 0xFFFFFF  : ???
[SFIO]     at 0x0010540C:001053F4 [0xC8070050] <- 0xFFFFFFFF: ???
[SFIO]     at 0x0010540C:001053F4 [0xC8070054] <- 0xFFFFFF  : ???
[SFIO]     at 0x0010540C:001053F4 [0xC8070008] <- 0xF1      : DMA
[*unk*]    at 0x00105448:001053F4 [0xC8030000] <- 0x40800000: ???
[*unk*]    at 0x00105448:001053F4 [0xC8030004] <- 0x100     : ???
[*unk*]    at 0x00105448:001053F4 [0xC8030014] <- 0x0       : ???
[*unk*]    at 0x00105448:001053F4 [0xC8030018] <- 0x3       : ???
[*unk*]    at 0x00105448:001053F4 [0xC8030010] <- 0x39      : ???
[DIGIC6]   at 0x00105448:001053F4 [0xD20B0A14] <- 0xC0003   : ???
[DIGIC6]   at 0x00105448:001053F4 [0xD20B0A10] <- 0xA0005   : ???
[DIGIC6]   at 0x001050D0:00105478 [0xD2090630] <- 0x0       : ???
[DIGIC6]   at 0x001050D0:00105478 [0xD2090640] <- 0x104     : ???
[DIGIC6]   at 0x001050D0:00105478 [0xD2090644] <- 0x1D000002: ???
[DIGIC6]   at 0x001050D0:00105478 [0xD2090648] <- 0x0       : ???
[DIGIC6]   at 0x001050D0:00105478 [0xD2090654] <- 0x403     : ???
[DIGIC6]   at 0x001050D0:00105478 [0xD2090658] <- 0x403     : ???
[DIGIC6]   at 0x001050D0:00105478 [0xD209064C] <- 0x302     : ???
[DIGIC6]   at 0x001050D0:00105478 [0xD2090650] <- 0x403     : ???
[DIGIC6]   at 0x001050D0:00105478 [0xD2090634] <- 0x3       : ???
[DIGIC6]   at 0x0010511C:0010511C [0xD2090638] <- 0x1       : ???
[DIGIC6]   at 0x0010511C:0010511C [0xD209063C] <- 0x1       : ???
[SFIO]     at 0x00105478:0010511C [0xC8070024] <- 0x5100    : cmd_hi
[SFIO]     at 0x00105478:0010511C [0xC8070020] <- 0x1       : cmd_lo
[SFIO]     at 0x00105478:0010511C [0xC8070028] <- 0x30      : Response size (bits)
[SFIO]     at 0x00105478:0010511C [0xC807002C] <- 0x80002701: response setup?
[SFIO]     at 0x00105478:0010511C [0xC8070010] <- 0x0       : Status
[SFIO] sdio_send_command (UNHANDLED)
[SFIO]     at 0x00105478:0010511C [0xC807000C] <- 0x14      : Command flags?
[DIGIC6]   at 0x0010512C:001054AC [0xD209063C] <- 0x0       : ???
[DIGIC6]   at 0x00105144:00105144 [0xD2090638] <- 0x80000000: ???
[DIGIC6]   at 0x001054B4:001054B4 [0xD20B0A14] <- 0xF       : ???
[DIGIC6]   at 0x001050D0:001054C0 [0xD2090630] <- 0x0       : ???
[DIGIC6]   at 0x001050D0:001054C0 [0xD2090640] <- 0x104     : ???
[DIGIC6]   at 0x001050D0:001054C0 [0xD2090644] <- 0x1D000002: ???
[DIGIC6]   at 0x001050D0:001054C0 [0xD2090648] <- 0x0       : ???
[DIGIC6]   at 0x001050D0:001054C0 [0xD2090654] <- 0x403     : ???
[DIGIC6]   at 0x001050D0:001054C0 [0xD2090658] <- 0x403     : ???
[DIGIC6]   at 0x001050D0:001054C0 [0xD209064C] <- 0x302     : ???
[DIGIC6]   at 0x001050D0:001054C0 [0xD2090650] <- 0x403     : ???
[DIGIC6]   at 0x001050D0:001054C0 [0xD2090634] <- 0x3       : ???
[DIGIC6]   at 0x0010511C:0010511C [0xD2090638] <- 0x1       : ???
[DIGIC6]   at 0x0010511C:0010511C [0xD209063C] <- 0x1       : ???
[*unk*]    at 0x00105558:0010511C [0xC8030010] -> 0x0       : ???
[SFIO]     at 0x00105584:0010511C [0xC8070010] -> 0x200001  : Status
[SFIO]     at 0x001055AC:0010511C [0xC8070008] <- 0x0       : DMA
[DIGIC6]   at 0x0010512C:001055B4 [0xD209063C] <- 0x0       : ???
[DIGIC6]   at 0x00105144:00105144 [0xD2090638] <- 0x80000000: ???
[DIGIC6]   at 0x001055B4:00105144 [0xD209065C] <- 0x0       : ???
[EEPROM] CS = 1
[DIGIC6]   at 0x001055B4:00105144 [0xD20B0D8C] <- 0xD0002   : SPI
[DIGIC6]   at 0x001055B4:00105144 [0xD20B0D80] <- 0xF       : ???
[DIGIC6]   at 0x001055B4:00105144 [0xD20B0D84] <- 0xF       : ???
[DIGIC6]   at 0x001055B4:00105144 [0xD20B0D88] <- 0xF       : ???
[DIGIC6]   at 0x001055B4:00105144 [0xD20B0A14] <- 0xA0005   : ???
[DIGIC6]   at 0x001055B4:00105144 [0xD20B0A0C] <- 0xA0005   : ???
[DIGIC6]   at 0x001055B4:00105144 [0xD20B0A08] <- 0xA0005   : ???
[DIGIC6]   at 0x001055B4:00105144 [0xD20B0A04] <- 0xA0005   : ???
[DIGIC6]   at 0x001055B4:00105144 [0xD20B0A00] <- 0xA0005   : ???
          0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
40800000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40800010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40800020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40800030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40800040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40800050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40800060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40800070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40800080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40800090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
408000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
408000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
408000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
408000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
408000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
408000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

**** SROM(SIO2) Menu ****
0.Exit from SROM Menu
1.Erase Chip   0x00800000
2.Erase Block  0x00010000
3.Erase Sector 0x00001000
4.Write Data
5.Write from Card
6.SROM Dump(SIO Read)
7.SROM Dump(QUAD Read)
8.Get Info
Title: Re: Canon 80D
Post by: a1ex on December 30, 2017, 02:48:00 PM
The output looks quite good.

Next step would be to dump 8MB of serial flash data (starting from address 0) and save it to a file. This part is very easy.
Title: Re: Canon 80D
Post by: sombree on December 30, 2017, 04:32:39 PM
Ok, so with this
b *0x104588
command
  silent
  print_current_location
  printf "sf_read_sio(%x { ", $r0
  set $addr = $r0
  while *(int*)$addr != -1
    printf "%x ", *(int*)$addr
    set $addr = $addr + 4
  end
  printf "-1 }, %x, %x, %x)\n", $r1, $r2, $r3
  c
end

I have output like this
>>6
Read Address[0x000000-0x7FFF00]:0x10000
[            :00104fa0 ] sf_read_sio(80000f10 { 3 1 0 0 -1 }, 80000b10, 100, 1)
[EEPROM] CS = 0
[DIGIC6]   at 0x00104588:00104FA4 [0xD20B0D8C] <- 0xC0003   : SPI
[EEPROM] Verbose: Got READ (03h)
[EEPROM] Verbose: address is now: 0x010000
[EEPROM] Verbose: Sent 256 bytes
[EEPROM] CS = 1
[DIGIC6]   at 0x001046E8:00104FA4 [0xD20B0D8C] <- 0xD0002   : SPI
          0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
00010000 0F FF F0 00 00 00 01 20 00 00 00 00 18 CB C1 20
00010010 00 00 00 00 0F 00 20 00 00 00 00 00 10 C0 00 00
00010020 0F FF FF FF F0 10 00 00 10 C0 00 00 0F EA FD CB
00010030 A0 80 00 00 11 80 00 00 00 00 00 00 00 00 00 00
00010040 00 00 00 00 00 00 00 00 00 20 00 00 11 80 00 00
00010050 04 64 13 23 33 23 23 33 03 60 00 00 00 00 00 00
00010060 00 30 00 00 10 C0 00 00 00 41 00 00 00 40 00 00
00010070 10 C0 00 00 0E 40 C0 00 00 60 00 00 11 00 00 00
00010080 05 D0 00 00 08 F1 02 1D 80 70 00 00 11 00 00 00
00010090 04 94 D4 75 F0 00 00 00 00 90 00 00 10 C0 00 00
000100A0 00 00 00 00 00 A0 00 00 10 C0 00 00 00 00 00 00
000100B0 00 B0 00 00 11 00 00 00 00 00 00 00 00 00 00 00
000100C0 00 C0 00 00 11 C0 00 00 00 77 41 9B FD 64 35 76
000100D0 F9 C4 26 39 E7 26 88 EC 3B FF 24 7C 51 10 00 00
000100E0 1D 00 10 00 00 00 00 00 00 90 00 04 00 00 00 00
000100F0 02 80 00 00 0B 48 69 C0 00 00 00 00 01 A0 10 00

which means logging hook is alive, right?

But when have this in reboot.c:
static int (*sf_command_sio)(uint32_t command[], void * out_buffer, int out_buffer_size, int toggle_cs) = (void*) 0x104588;
char buffer[0x100];
int addr = 0x10000;
sf_command_sio((uint32_t[]) {3, (addr >> 16) & 0xFF, (addr >> 8) & 0xFF, addr & 0xFF, -1}, buffer, sizeof(buffer), 1);

emulation (./run_canon_fw.sh 80D,firmware="boot=1" -d io,sflash) ends with
03C30000: Palette[E] -> R195 G195 B195
03EB0000: Palette[F] -> R235 G235 B235
[DIGIC6]   at 0x40800C38:40804598 [0xD20139A0] <- 0x1       : Bootloader palette confirm
[DIGIC6]   at 0x40800A30:40800A04 [0xD2030108] <- 0x440000  : BMP VRAM
[ROM1:4]   at 0x00104588:408002F4 [0xFC040D8C] <- 0x104588  : ???
[EEPROM] Verbose: Got READ (03h)
[EEPROM] Verbose: address is now: 0x010000
[ROM1:4]   at 0x001046E8:408002F4 [0xFC040D8C] <- 0xD0002   : ???


Probably it's something obvious as I'm not good at coding.
Title: Re: Canon 80D
Post by: a1ex on December 30, 2017, 05:00:38 PM

int addr = 0x10000;

matches:

[EEPROM] Verbose: address is now: 0x010000


however, the chip select signal is wrong (either uninitialized or there is some sort of memory corruption):

[ROM1:4]   at 0x00104588:408002F4 [0xFC040D8C] <- 0x104588  : ???


From your second log:

[            :00104fa0 ] sf_read_sio(80000f10 { 3 0 12 34 -1 }, 80000b10, 100, 1)
[            :001056bc ] sf_read_sio(80000f3c { 3 0 0 0 -1 }, 80000f0c, c, 1)                                                                                                                                                   
[            :0010473c ] sf_read_sio(80000ebc { 6 -1 }, 0, 0, 1)
...


All these addresses have this instruction:

BL              sub_10456C


and 0x104588 is somewhere in the middle of that function.

The registers we are interested in (R0-R3) were not changed until that point, which is why the logging hook worked just fine.

What happened? Play this game (http://microcorruption.com) and you'll find the answer after a few levels :D
Title: Re: Canon 80D
Post by: t3r4n on December 30, 2017, 09:59:49 PM
Based on the ideas of a1ex I've started a dumper tool look here https://www.magiclantern.fm/forum/index.php?topic=17627.msg195393#msg195393 (https://www.magiclantern.fm/forum/index.php?topic=17627.msg195393#msg195393) happy hacking.
Title: Re: Canon 80D
Post by: sombree on December 30, 2017, 10:21:20 PM
I can confirm that 0x10456C is correct address for 80D. Also I'm able to dump serial flash in qemu using t3r4n's code :D

@t3r4n - to be able to save file you need some part of dump_rom_with_canon_routines function:
    init_boot_file_io_stubs();

    /* are we calling the right stubs? */

    if (!boot_open_write)
    {
        print_line(COLOR_RED, 2, " - Boot file write stub not set.\n");
        fail();
    }

    if (MEM(boot_open_write)  != 0xe92d47f0)
    {
        print_line(COLOR_RED, 2, " - Boot file write stub incorrect.\n");
        printf(" - Address: %X   Value: %X\n", boot_open_write, MEM(boot_open_write));
        fail();
    }

    if (!boot_card_init)
    {
        print_line(COLOR_YELLOW, 2, " - Card init stub not found.\n");
    }

    if ((((uint32_t)boot_open_write & 0xF0000000) == 0xF0000000) ||
        (((uint32_t)boot_card_init  & 0xF0000000) == 0xF0000000))
    {
        print_line(COLOR_YELLOW, 2, " - Boot file I/O stubs called from ROM.");
    }

    if (boot_card_init)
    {
        /* not all cameras need this, but some do */
        printf(" - Init SD... (%X)\n", boot_card_init);
        boot_card_init();
    }


Edit: dumpf from qemu with SFDATA.BIN from 80D - link (https://pastebin.com/fjMq2Tx0).

Also I've checked sf dumper in qemu with 8MB SFDATA.BIN from 700D. Sadly, sha1 is different for each file:
47b4da39f459c4a6d14a2458fa0ab8d2671b6402  /media/sombre/EOS_DIGITAL/SFDATA.BIN
955714c9ea9d60045ff57325ddf3b6a825a2d0b2  /home/sombre/Documents/temp2/qemu/80D/SFDATA.BIN


Edit2: Checked sha1 again, but this time using 16MB sfdata.bin from camera and now it's fine :)
3b4417fc421cee30a9ad0fd9319220a8dae32da2  /home/sombre/Documents/temp2/qemu/80D/SFDATA.BIN
3b4417fc421cee30a9ad0fd9319220a8dae32da2  /media/sombre/EOS_DIGITAL/SFDATA.BIN
Title: Re: Canon 80D
Post by: goldenchild9to5 on December 31, 2017, 12:00:44 AM
Great work guy's..  :D
Title: Re: Canon 80D
Post by: t3r4n on December 31, 2017, 01:31:06 PM
@sombree:
I've changed the code so that it will initialise the canon routines if you only compile with the CONFIG_BOOT_SROM_DUMPER=y option, but also with the CONFIG_BOOT_DUMPER=y so both routines or just one can be selected for the image.

@all:
- the code is prepared for more models, and as described above modularised
- still todo:
   - the byte vs char stuff to get it correct
   - make it work on my camera :(  qemu works now fine for me but the camera its still unwilling to put something else than 0x00 into the file  :'(.
Title: Re: Canon 80D
Post by: sombree on December 31, 2017, 02:45:44 PM
@t3r4n
Have you tried to dump only 0x100 (256 bytes, default value) starting from 0x10000?
Title: Re: Canon 80D
Post by: t3r4n on December 31, 2017, 03:05:34 PM
Yep no success...
Title: Re: Canon 80D
Post by: a1ex on January 01, 2018, 10:35:44 PM
This wrapper may help. Maybe a bit slow*), but...

*) "You can use several loads with a wheelbarrow, many loads with a bucket, or lots and lots of loads with a spoon" (Absolute FreeBSD, 2nd Ed.)


static void sf_read(uint32_t addr, uint8_t * buf, int size)
{
    static uint32_t teaspoon[0x100];

    for (int i = 0; i < size; i++)
    {
        if (i % COUNT(teaspoon) == 0)
        {
            uint32_t a = addr + i;
            sf_command_sio((uint32_t[]) {3, (a >> 16) & 0xFF, (a >> 8) & 0xFF, a & 0xFF, -1}, teaspoon, COUNT(teaspoon), 1);
        }

        buf[i] = teaspoon[i % COUNT(teaspoon)];
    }
}


Happy new year!
Title: Re: Canon 80D
Post by: Theta Sigma on January 02, 2018, 01:21:33 PM
To think the 40D and the 80D might be on the cusp of being freed from their shackles is inspiring. :)
Title: Re: Canon 80D
Post by: sombree on January 02, 2018, 04:42:14 PM
@a1ex
I've tried this wrapper but same result as for t3r4n - in qemu it works, in camera I'm getting only zeroes.
Title: Re: Canon 80D
Post by: t3r4n on January 02, 2018, 07:33:54 PM
Yeah in the meantime I did even try to dump some bytes to the screen (like the original function did) to make sure it is not the file writing that is wrong but to no avail.
So next thing I did was to modify the rom dumper and look what is in memory (at the moment only the copied section 0xX0100000 to ..e500. So far the following discoveries (using radiff2 from radare2):
- adresses 0x0000e470, 0x0000e480 are different every time. No other difference if I take a photo in the meantime (so no "shutter count"). This is true on qemu and cam.
- on the cam 0x0000e495 differs between starts and on qemu 0x0000e496 also some more differences in that area between the two "architectures".

Will include a1ex wrapper and make a push later.

BTW: Wouldn't it be better to move to the RE section and doing a "Joint digic6" thread?
Title: Re: Canon 80D
Post by: a1ex on January 03, 2018, 12:14:47 AM
This means, some additional hardware initialization may be required.


./run_canon_fw.sh 80D,firmware="boot=1" -d io,sflash

AUTOEXEC.BIN not found.
File not found.

(some I/O activity, unlikely to be any of these)

S.SROM Menu

>>s
[DIGIC6]   at 0x0010575C:0010087C [0xD2090008] -> 0x10004   : CLOCK_ENABLE
[DIGIC6]   at 0x00105764:0010087C [0xD2090008] <- 0x210004  : CLOCK_ENABLE

**** SROM(SIO2) Menu ****
...

>>0
Exit
[DIGIC6]   at 0x00105804:0010690C [0xD2090008] <- 0x10004   : CLOCK_ENABLE


That must be it - the clock_enable register is used to power various devices (for example, SD and display initialization also use something similar).

Before attempting to read the SROM contents, try this:

*(volatile uint32_t *)0xD2090008 |= 0x200000;
Title: Re: Canon 80D
Post by: sombree on January 03, 2018, 12:42:58 AM
I'm still getting only zeroes on real camera.
What about these lines? They appear when booting in qemu to fromutulity menu too.
[DIGIC6]   at 0xFE020400:FE02013C [0xD2090008] -> 0x0       : CLOCK_ENABLE
[DIGIC6]   at 0xFE020400:FE02013C [0xD2090008] <- 0x10004   : CLOCK_ENABLE

Title: Re: Canon 80D
Post by: a1ex on January 03, 2018, 12:48:53 AM
These happen before loading autoexec.bin. You could try printing this register's value on the screen: *(volatile uint32_t*)0xD2090008 (maybe before and after setting the above flag, to make sure it worked).

BTW, the SROM menu code also calls 0x105710 (no arguments) after setting 0x200000; try calling that too:


*(volatile uint32_t *)0xD2090008 |= 0x200000;
void (*srom_init_maybe)(void) = (void *) 0x105710;
srom_init_maybe();


That function also does some I/O (visible with -d io,sflash,v):


[DIGIC6]   at 0x0010575C:0010087C [0xD2090008] -> 0x10004   : CLOCK_ENABLE
[DIGIC6]   at 0x00105764:0010087C [0xD2090008] <- 0x210004  : CLOCK_ENABLE
[SIO2-SF]  at 0x0010572C:0010576C [0xC0820208] <- 0x1       : ???
[SIO2-SF]  at 0x00105734:0010576C [0xC0820200] <- 0x0       : ???
[SIO2-SF]  at 0x00105738:0010576C [0xC0820210] <- 0x0       : write mode?
[SIO2-SF]  at 0x0010573C:0010576C [0xC0820214] <- 0x0       : ???
[SIO2-SF]  at 0x00105744:0010576C [0xC0820238] <- 0xA00408  : mode
Title: Re: Canon 80D
Post by: sombree on January 03, 2018, 01:32:57 AM
Ok, it seems that srom_init_maybe() actually does something - SFDATA.BIN isn't empty anymore  :D
**** SROM(SIO2) Menu ****
0.Exit from SROM Menu
1.Erase Chip   0x00800000
2.Erase Block  0x00010000
3.Erase Sector 0x00001000
4.Write Data
5.Write from Card
6.SROM Dump(SIO Read)
7.SROM Dump(QUAD Read)
8.Get Info
>>8
[            :001056bc ] sf_read_sio(80000f3c { 3 0 0 0 -1 }, 80000f0c, c, 1)
0x80000350

0x80000350 is CanonModelID for 80D :D
Title: Re: Canon 80D
Post by: a1ex on January 03, 2018, 01:22:37 PM
Finally :D

Still, the emulation didn't advance much; only got rid of a warning about some missing property. Time to get some more logs from real hardware and move beyond bootloader stage.

Updated the digic6-dumper branch (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper) (including these cache changes (http://www.magiclantern.fm/forum/index.php?topic=17360.msg191399#msg191399)) and I'm now able to get a ROM dump from main firmware, in QEMU. Will let sombree tweak it further, should it require any more changes.

If that works, the next steps would be:
- getting a full diagnostic log, including MPU messages (mostly for emulation, but also helpful with porting)
- finding the remaining stubs (the "easy but boring" part)
- identifying the display buffer, printing hello world, opening ML menu...
Title: Re: Canon 80D
Post by: goldenchild9to5 on January 03, 2018, 02:22:39 PM
Happy New Year everyone.. @a1ex @sombree awesome job with the 80D. 
Title: Re: Canon 80D
Post by: sombree on January 03, 2018, 02:49:31 PM
I have good news - with latest changes we're able to run code on camera  :D
Full LOG000.LOG (https://pastebin.com/gUryNQ1j) from the camera.
Card led blinking: click (https://drive.google.com/open?id=1ovq36VemRoym21U3eYxgpC0Apj_YMdIx)  :D
Title: Re: Canon 80D
Post by: Danne on January 03, 2018, 03:17:29 PM
Wow, great to hear about this.
Title: Re: Canon 80D
Post by: goldenchild9to5 on January 03, 2018, 03:37:41 PM
@sombree Awesome..  :)
Title: Re: Canon 80D
Post by: a1ex on January 03, 2018, 07:21:37 PM
Committed some logging experiments - please try the intermediate changesets (not just the last one) and report their outcome.
Title: Re: Canon 80D
Post by: sombree on January 03, 2018, 08:04:03 PM
Link to logs. (https://drive.google.com/open?id=1uxBp4rfnkSn_t5zoI2Ry4g0D4GGAYzo3)
LOG000.LOG - latest commit is d54669e
LOG001.LOG - latest commit is f264082
LOG002.LOG - latest commit is 122cb55
LOG003.LOG - latest commit is f492292
Title: Re: Canon 80D
Post by: a1ex on January 03, 2018, 08:29:59 PM
Excellent - all of them worked! Committed some more.
Title: Re: Canon 80D
Post by: sombree on January 03, 2018, 08:49:18 PM
Link to logs. (https://drive.google.com/open?id=17WqAsgEO9yM_dOzdAZhsHws4CxbnpErU)
LOG004.LOG - latest commit is 85d4880
LOG005.LOG - latest commit is e439c1d
LOG006.LOG - latest commit is 07f0319
Title: Re: Canon 80D
Post by: a1ex on January 03, 2018, 09:03:05 PM
There are two memory regions commented out in 85d4880, since they might give trouble; can you try these as well?

If they don't work (crash or whatever), try smaller sizes.
Title: Re: Canon 80D
Post by: sombree on January 03, 2018, 09:15:35 PM
Link to LOG007 + one RAM region. (https://drive.google.com/open?id=1QKGwQ1WlOADqqDhzhuGS2GmkPM0qQM0c) EE00 doesn't crash the camera, but no file is created. I've tried something like dump_file("EE00.BIN", 0xEE000000, 0x01000000) but still no luck.
LOG007 - latest commit is f679e3d.
Title: Re: Canon 80D
Post by: a1ex on January 03, 2018, 09:40:18 PM
f679e3d didn't work quite well, can you disable sensor cleaning and - if possible - the main display (on other cameras it's done with the INFO button) and run it again?

The logs are trimmed if too many messages are present.

I should probably enable the full dm-spy-experiments code, which doesn't have this limitation.
Title: Re: Canon 80D
Post by: sombree on January 03, 2018, 09:51:26 PM
It's still cut - link (https://drive.google.com/open?id=1F-hd3OJNW6KMMBAZcCahqBWBnJR6kfHk). I've also tried with touch disabled but it's still not enough to capture whole log.
Title: Re: Canon 80D
Post by: michael1998 on January 04, 2018, 03:17:07 AM
so I basically read all the ten pages, and I'm not that familiar with coding and programming so I was not able to understand that much, but it looks like you guy made some progress so my question is do you guys think that it is possible to have it for the canon 80d ?? I'm not rushing into things or anything  you guys are doing your best and i appreciate that  but I'm just curious to know at what stage is it now does it still need a lot of work yet or is it at it final stage and I have the  canon 80d if there any way I can help with just tell me we can run some tests on my camera
Title: Re: Canon 80D
Post by: core51 on January 04, 2018, 09:18:25 AM
How can I help am feeling like dumb. I want to help :) but while looking at your posts and comment I don't know what you guys are talking about. Am not a tech guy but currently own 80d and want to help.
Title: Re: Canon 80D
Post by: ConanTheBarber on January 11, 2018, 04:10:25 AM
Quote from: ltf3 on January 09, 2017, 10:51:36 PM
selfishly, all I need is Focus Peaking for video!
;D

I would also REALLY enjoy Aperture Priority and other Priority filming modes. Anyone think this mighthinks possibility?
Title: Re: Canon 80D
Post by: kallitokaco on January 14, 2018, 12:55:03 PM
Hi,

professional c/c++ programmer here with an 80D and lack of time and fundamental understanding of ML. First of all, nice work guys.

I started to look at the MPU log.c and I'm curios why the buffer in mpu_recv_log() is updated by mpu_recv() after the buffer is already decoded? Shouldn't it be updated in advance to log the current msg?
And is there a reason why the argument "size" of mpu_recv_log() is not used, but the [-1]-Hack to get the size, although at [ 0 ] is always the encoded size, or is this not always the case?

Greetings
Title: Re: Canon 80D
Post by: teq on January 15, 2018, 08:59:07 PM
Is there any solution to avoid the 30 minute video limit?  As it stands now, the camera stops recording after 30 minutes.  I need to be able to record forever but I can't find any mention of this feature in the feature notes.
Title: Re: Canon 80D
Post by: Walter Schulz on January 15, 2018, 09:27:24 PM
Ask Canon to change firmware. Tariff penalty for cams recording > 29:59 was ditched mid 2016.
Title: Re: Canon 80D
Post by: a1ex on January 15, 2018, 09:50:00 PM
Quote from: kallitokaco on January 14, 2018, 12:55:03 PM
why the buffer in mpu_recv_log() is updated by mpu_recv() after the buffer is already decoded?

Shouldn't it be updated in advance to log the current msg?

In Canon code, this function is called indirectly (a pointer to it - mpu_recv_cbr - is stored to RAM) whenever a message is received from the MPU, so we have replaced that pointer with one to our own function (mpu_recv_log). Our function prints the message in Canon's log file, then calls Canon's function to process the message. So, it keeps the original functionality (whatever Canon code is supposed to do with each message from the MPU) and it logs each call. The protocol is documented here (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst#rst-header-mpu-communication).

Quote
And is there a reason why the argument "size" of mpu_recv_log() is not used, but the [-1]-Hack to get the size, although at [ 0 ] is always the encoded size, or is this not always the case?

From the above link, mpu_recv gets a pointer to payload_size (second char in the message), so it happens that buf[-1] is still available for reading. It's not really necessary to capture it though; payload_size is enough to interpret the messages. The logging code was written before we understood the message format (it was adapted from here (https://bitbucket.org/hudson/magic-lantern/src/dm-spy-experiments/src/dm-spy-extra.c)), and it was done that way to match the format from mpu_send (which receives a "full" message, with two size arguments).

But you are right, message_size can be dropped without any loss of information (now that we know the the first two parameters are always redundant). It would require updating mpu.c (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu.c) (to add logic for message_size, rather than just replaying it), extract_init_spells.py (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu_spells/extract_init_spells.py) and any other scripts that parse this kind of logs, though. And, of course, a script for updating any old logs to the new format.

BTW - nice to see others reading the low-level code and trying to understand what's going on.




Forgot to mention - since the code from the digic6-dumper branch is now able to dump the RAM while running Canon firmware, here's an easy coding task: find the image buffer addresses (Canon menus, overlays, LiveView image) in the RAM dump.

I didn't look into it yet, so can't give many hints right now, but I'm pretty sure the image buffers should be somewhere in RAM, and CHDK folks already documented the image format.
Title: Re: Canon 80D
Post by: OlRivrRat on January 16, 2018, 06:36:41 AM
"find the image buffer addresses (Canon menus, overlays, LiveView image) in the RAM dump"

           What would what You are asking to be looked for Look Like ?
Title: Re: Canon 80D
Post by: a1ex on January 16, 2018, 09:07:00 AM
Like... what you are seeing on the camera screen.

https://stackoverflow.com/questions/37867570/finding-images-in-ram-dump
https://w00tsec.blogspot.com/2015/02/extracting-raw-pictures-from-memory.html

The google-fu is also part of the exercise; it was meant to be a time saver for me, not I solve this and then teach you what I did. I already do that for the more difficult topics.
Title: Re: Canon 80D
Post by: ConanTheBarber on January 17, 2018, 12:14:21 AM
You guys working on these things. You have my utmost respect. Your work is exceptional! 

I am def tech savy but am not much of a coder. I do own an 80D and would like to help as well.

Is there any way to set this thread as a notification, whenever there is a new message?
Title: Re: Canon 80D
Post by: OlRivrRat on January 17, 2018, 08:00:19 AM
      @Alex

What the heck is "The google-fu"

"it was meant to be a time saver for me,"  > Assumed that & was wanting to see if I could help ~

"not I solve this and then teach you what I did."  > Assume that Neither of Us have the time left for that to happen &

Certainly Didn't think I was asking for that ~

Maybe this is 1 of those "If You have to ask then You probably don't have the necessary resources to participate" situations ~

Sorry to be a Bother ~
Title: Re: Canon 80D
Post by: a1ex on January 17, 2018, 10:42:59 AM
Google-fu (https://lmgtfy.com/?q=google-fu) is the most important skill you need to port ML on any camera.

We are reverse engineering an undocumented system (a newer hardware platform, different from what we already know). Translation: we don't know much about it; we are trying to understand how it works. If I had known how the image buffers look like in the RAM dump, I would already knew where they are. The point is to find something, in the RAM dump, that resembles (to some extent) what you are seeing on the screen (Canon menus). This task is well documented on other websites (for other devices) and can be done with existing GUI software (it doesn't require coding skills).

What I knew about this task was already mentioned:
Quote
I didn't look into it yet, so can't give many hints right now, but I'm pretty sure the image buffers should be somewhere in RAM, and CHDK folks already documented the image format.

To tell more details, I'd have to solve the task myself.

Already wasted too much time on this; will come back when there will be some meaningful progress. Current state allows anyone to print Hello World (and maybe even launch ML menu) within a couple of evenings, by following existing guides.
Title: Re: Canon 80D
Post by: Ant123 on January 17, 2018, 05:45:48 PM
found in RAM dump provided by sombree:
two uyvy buffers at 0x41785B00, 0x41901800
one RGBA buffer at 0x043ED100

bitmap buffers are 960*540 pixels with black bars:
(http://thumbs2.imagebam.com/50/2e/36/b383a2721669143.jpg) (http://www.imagebam.com/image/b383a2721669143)
Title: Re: Canon 80D
Post by: a1ex on January 17, 2018, 08:51:07 PM
Assign this to a hotkey (mpu.c):

eos_load_image(s, "RAM4.BIN", 0, s->model->ram_size, s->model->caching_bit, 0);
s->disp.bmp_vram = 0x41901800 + (30 * 960 + 120) * 2;
s->disp.bmp_pitch = 960 * 2;


then, in eos_update_display, pretend it's an EOSM3:

(http://a1ex.magiclantern.fm/bleeding-edge/qemu/80D.png)

Have fun!
Title: Re: Canon 80D
Post by: Ant123 on January 17, 2018, 09:42:27 PM
I'm not sure that this is useful until emulation reaches the mzrm initialization.
Title: Re: Canon 80D
Post by: gabi_tro on February 06, 2018, 06:45:56 PM
Yes I would love to know that as well. I am interested in finding out the shutter counter. I extracted those files but I have no ideea what to do with them :(
Title: Re: Canon 80D
Post by: nitram0 on February 09, 2018, 05:21:12 PM
Used to have ML on my super old 350D but since upgrading to the 80D, I have been looking forward to ML. If anything, would be amazing to have 1080p video in RAW (good 'ol 24fps). In theory, how fast does the card write speed even need to be for 24fps 1080p RAW?

Thanks to all those working on this project. Good luck!  :)
Title: Re: Canon 80D
Post by: Walter Schulz on February 11, 2018, 09:48:40 AM
You cannot have used ML on 350D because it doesn't exist. You may have used CHDK instead.
Title: Re: Canon 80D
Post by: OlRivrRat on February 12, 2018, 02:24:08 AM
   @ WhomEver is working on the 80D ML

Not trying to be Pushy > But > My Birthday is only about a Week away {:~))
Title: Re: Canon 80D
Post by: jackmehoffer on February 21, 2018, 12:24:50 AM
Hello, I just got an 80D to replace my 60D-ML. I just wanted to let you know that I appreciate all your hard work and thank you for everything that you.
Title: Re: Canon 80D
Post by: PeterPan on February 26, 2018, 05:57:45 PM
Hello, I just recently bought an 80D. As I have used ML on my 550d for a long time, I would lobe to see it on my 80d. I'm not a developer and I can't program, but if there is any way to help you guys, I would love to do that. Like testing some builds for example.
Keep up your great work
Title: Re: Canon 80D
Post by: snappy604 on March 07, 2018, 05:51:35 AM
Hi

Like many others, thank you for working on this. I used ML on my 7d and miss it now that I'm on an 80d.

Noticed this was slightly different on home page... what does this mean?

"80D, 750D, 5DS (can run code alongside Canon firmware)"
Title: Re: Canon 80D
Post by: a1ex on March 07, 2018, 07:44:29 AM
On all EOS models we have tried (including DIGIC 7), we can execute custom code. The question is - can we do anything useful with it?

On DIGIC 7 (https://www.magiclantern.fm/forum/index.php?topic=19737), for example, we don't even know how to blink a LED (so our code does not have any visible side effects - we only know it runs because it locks up the camera).

On all DIGIC 6 models we have tried, we can display things on the screen from bootloader. Canon firmware is not running in this case, but it's useful to find out stuff about the hardware (find out what CPU (https://www.magiclantern.fm/forum/index.php?topic=17714.msg185363#msg185363) it has, dump the ROM (https://builds.magiclantern.fm/#rom-dumpers) and so on).

On some DIGIC 6 models (including 80D), we can execute this code alongside Canon firmware (for example, by starting DryOS tasks). This is a huge progress (compared to bootloader stage) and you can already start tweaking various functions in Canon firmware. You cannot print things on screen yet, but you can blink the LED and save files on the SD card.

Right now, you can compile from the digic6-dumper (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper) branch and experiment. You can run these experiments either on camera, or - with some major limitations - in QEMU. I don't have any DIGIC 6 cameras (sorry, the GAS is over (https://www.magiclantern.fm/forum/index.php?topic=17627.msg191184#msg191184)), so please don't wait for me - start experimenting on your own. The codebase is ready for other developers to jump in and start porting. The emulator is also in pretty (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst) good (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst) shape (https://www.magiclantern.fm/forum/index.php?topic=17360.msg194898#msg194898) these days.

Tip: 5DS experiments (https://www.magiclantern.fm/forum/index.php?topic=17695.msg197085#msg197085) are also available, and useful as documentation.

Whetting your appetite: put this in dump_task (https://bitbucket.org/hudson/magic-lantern/src/digic6-dumper/platform/80D.102/minimal.c?at=digic6-dumper&fileviewer=file-view-default#minimal.c-118):

msleep(5000);
call("Release");


Don't try that with EraseSectorOfRom or other functions you don't know what they do ;)




BTW - if anyone skilled in ARM assembly is reading - this (https://www.magiclantern.fm/forum/index.php?topic=2388.msg196941#msg196941) will be very helpful for understanding how DIGIC 6 works. Code won't run out of the box, but can be debugged in QEMU first.
Title: Re: Canon 80D
Post by: a1ex on April 01, 2018, 03:33:27 PM
Today, April 1st, announcing...

Magic Lantern Blind Edition for DIGIC 6 :)

Step 0: make sure you are running firmware 1.0.2 (ML does not check for that!)
Step 1: enable the boot flag (https://www.magiclantern.fm/forum/index.php?topic=17360.msg189646#msg189646) (if you haven't already)
Step 2: copy autoexec.bin to your card (download links below)
Step 3: pray that your camera won't explode
Step 4: start the camera
Step 6: report back

Release 0.001 (https://a1ex.magiclantern.fm/bleeding-edge/80D/0.001/autoexec.bin)
Features:
- LED blinking
- Still photo capture after 10 seconds
- Diagnostic log

Release 0.002 (https://a1ex.magiclantern.fm/bleeding-edge/80D/0.002/autoexec.bin)
Features:
- LED blinking
- Silent photo capture (without shutter actuation) after 10 seconds (camera must be in PLAY mode started from LiveView; ML does NOT check for that!)
- Diagnostic log

Keep in mind these binaries are truly blind (I could not test this functionality in QEMU). Anything can happen if you try to run them. Your 80D may very well turn into 1DX or it may explode. If it breaks, I'm unable to pay for repairs, sorry.

(https://a1ex.magiclantern.fm/bleeding-edge/80D/80D-blind.png)

Source code: open the binaries with a text editor.
For other D6 models, adapting the source should be straightforward.
For DIGIC 7, see here (https://www.magiclantern.fm/forum/index.php?topic=19737). Emulation-wise it's mostly identical to D6.

Have fun!
Title: Re: Canon 80D
Post by: oc_masta on April 01, 2018, 11:50:17 PM
Alex, you and the rest of team...Bravo.

I honestly commend your tenacity with the magic lantern project. I feel a thank you doesn't do it justice, so I'll say Alex you sexy man!
Title: Re: Canon 80D
Post by: Felipe on April 02, 2018, 12:48:16 AM
Really  hooo man
Title: Re: Canon 80D
Post by: ricflair4life on April 04, 2018, 06:09:34 PM
Oh sweet! 8) What's the next step you'd recommend?
Title: Re: Canon 80D
Post by: OlRivrRat on April 04, 2018, 10:31:22 PM
                   TWEIMC

   Thanks to an SFDATA Dumper & Help from Thomas Mathieson I have an SFDATA.BIN

from My 80D if anyone is interested ~

                                                                  ORR ~ DeanB
Title: Re: Canon 80D
Post by: michael1998 on April 07, 2018, 09:09:33 PM
is this an Aprils fool day joke ???? and if it is not and i hope it is not,i have the camera can someone tell me what to exactly do to run some tests on it
Title: Re: Canon 80D
Post by: Chellyandruu on April 10, 2018, 01:56:59 AM
hey Alex,i ran both test .do you need the log files?
Title: Re: Canon 80D
Post by: a1ex on April 10, 2018, 06:44:50 AM
Yes, please. Also whether the tests worked or not, and a silent picture (silent.raw, it's overwritten if you try more than once).
Title: Re: Canon 80D
Post by: 201400005064 on April 10, 2018, 06:58:14 AM
I just bought 80d and had some exploration on this camera. I wondered about this witch camera. I thank you for doing all this effort, I hope someone can run tests. I'll try what I can do, maybe I'll run a few tests. I'm not a developer or whatever but maybe I can help with the tests.  :)
Title: Re: Canon 80D
Post by: sombree on April 10, 2018, 12:09:58 PM
I'm not sure if silent photo capture works - I can't open output file (https://drive.google.com/open?id=1qGtcjzXN6V1hzqd8oACjevhNBkBytw02) with anything.
Title: Re: Canon 80D
Post by: a1ex on April 10, 2018, 01:06:59 PM
The log looks promising! I can already tell a few things from it.

Memory allocation starts at FA_CreateTestImage, photo capture starts at FA_CaptureTestImage, file saving starts right after FA_GetCrawBuf. Buffer address looks sane to me. Exposure settings were: ISO 100 1/200, f/1.8 or manual lens (unsure). 0xD0006008 and 0xD0006014 are FPS timers A and B (closely related to image size). Camera reads 8 columns in parallel (timer A = 0x304 * 8 = 6176, slightly above horizontal resolution). MPU message 0e 2d appears to be sent periodically from LiveView (unknown meaning).

However, the image data was not good. Were the preconditions met when the image was captured? (was the camera in PLAY mode, entered from LiveView?) The MPU messages from the log (0e 2d present during image capture) and the semaphore error are strong hints that the camera was still in LiveView. Please follow the instructions to the letter; at this stage, ML cannot check whether the camera is in the right mode or not.

To open the file, see reply #246 (but only after you are sure the image was captured).

Also, did the regular photo capture test work? How does the log look like? Did the LED blink 10 times before the image capture? The test was really blind, I don't have a DIGIC 6 camera to check whether it works or not. The DIGIC 6 platform is very different from the models I know, so I cannot assume much if you don't report the details. Please read these for some background info:

https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
http://www.catb.org/esr/faqs/smart-questions.html#beprecise
Title: Re: Canon 80D
Post by: sombree on April 10, 2018, 02:09:42 PM
Release 0.001:
Led starts blinking. Sometimes it blinks ten times and takes regular photo. Some other times it blink few times and stops (led is still on) but camera doesn't lock up - entering menu (or pushing any other button) seems to "unlock" led blinking so after ten blinks it takes photo. Output is correct *.cr2 file. Logs. (https://drive.google.com/open?id=1VcHX-BW-DCCoLxmNcHvTGEC1IEHZEvIl)

Release 0.002:
Led blinks ten times and then it stops. After some time it turns on few more times (looks like camera is saving files to the card). I did as you said - entered Live View and then entered PLAY mode and waited until everything is done. I've also tried entering Live View and then entering menu but still no succes - SILENT.RAW looks like nothing in binview (https://chdk.setepontos.com/index.php?topic=12721.0).

Btw. you're right about exposure settings (lens with AF but set to manual mode) :)
Title: Re: Canon 80D
Post by: a1ex on April 10, 2018, 04:34:59 PM
The CR2 logs look good, although some messages are out of order, for some unknown reason. Quirks like this were the reason I wrote a custom logging framework, overriding Canon's DebugMsg.

The silent picture behavior is unexpected - is the 80D the first model that keeps LiveView active when entering PLAY or MENU?! I find it hard to believe, but who knows. Can you try to capture a silent picture outside LiveView? You should get a dark frame.

From this line, we can measure rolling shutter (http://www.magiclantern.fm/forum/index.php?topic=12656.0) (see FRSP timing analysis (http://www.magiclantern.fm/forum/index.php?topic=12523.msg121962#msg121962)):

80D: 7130: 11240.552 [CAPE] VSizeSetting Time:91 Acc:3181 loop:1
5D3: 13.715.002  ShootCaptu:ff213688:92:05: VSizeSetting Time:21 Acc:636 loop:1


5D3: Acc = 10000 * Time / 330, main clock = 24 MHz
timer A = 0x318 => one line read out in 0x318 / 24e6 = 33 microseconds
full image read out in 0xF76 * 33 = 130 ms
active area read out in 3870 * 33 = 127.7 ms

80D: Acc = 10000 * Time / 286 => one line read out in 28.6 microseconds
timer A = 0x304 => main clock = 27 MHz? (odd value)
timer B = 0xFDE => full image read out in 116 ms => 8.6 FPS theoretical limit.
Active area (6024 x 4022, from dcraw -i -v) read out in 115 ms.

I've expected the 80D sensor to be a little faster. Doesn't it do 1080p60 with Canon firmware? Tried to find out, but the values I've found in the ROM didn't make much sense to me, although they seemed to match the DIGIC 5 patterns at first sight; more details later.
Title: Re: Canon 80D
Post by: sombree on April 10, 2018, 06:28:54 PM
Camera throws Err 70 when I've tried silent photo without turning live view before. No log or *.RAW file.
I've also tried it while staying in live view and movie mode - still no success, but camera doesn't lock up or throw an error.
Interesting thing - no error when taking silent photo without live view and with half-pressed shutter release button.
Logs. (https://drive.google.com/open?id=13J9SnAlJ9zxssboebuk6TJJ1UYtXT-iy)
Title: Re: Canon 80D
Post by: a1ex on April 10, 2018, 07:44:42 PM
These logs are from LiveView (10 frames each) and do not have any FA_Create/CaptureTestImage messages. No error message either. Image is still empty - make sure the last attempt is the successful one. Try in PLAY mode without any images on the card, as that mode is a lot less verbose. Please don't send more huge "empty" files - look at them with a hex editor first.

This line is interesting (that's FPS timer B):


239065: 35638.106 [CAPD] [0](0xd0006014),(0x617)


Value varies: first log has 0x4de 4 times, 0x4df 15 times. Second log has 0x616 4 times, 0x617 9 times. Assuming 27MHz and timer A = 722 (found in ROM, e.g. FF01D340), that gives 29.970 (first log) and 23.976 (second log), on average.




edit: got a hypothesis about LiveView resolution, but will only post it after being 100% certain. For that, I need two RAM dumps from LiveView, one before call("lv_save_raw", 1) and one after. Please run call("sht_mirror") before and after, too. Run the procedure in 1080p24, 1080p30, 1080p50, 1080p60, 720p50 and 720p60 (edit: x5 zoom, too - doesn't matter where it's started from).

Something like this:

dump_file("RAM4-BF.BIN", 0x40000000, 0x40000000);
call("sht_mirror"); // will create MIRROR.txt
msleep(1000);
call("lv_save_raw", 1);
msleep(1000);
dump_file("RAM4-AF.BIN", 0x40000000, 0x40000000);
call("sht_mirror"); // will append to MIRROR.txt
Title: Re: Canon 80D
Post by: goldenchild9to5 on April 10, 2018, 08:00:29 PM
Great job guy's..
Title: Re: Canon 80D
Post by: 201400005064 on April 12, 2018, 05:37:57 PM
Goodluck guys! I'm new here I wish I can help. I just bought an 80d.
Title: Re: Canon 80D
Post by: sombree on April 12, 2018, 07:26:28 PM
Silent photo, PLAY mode without entering live view, no images on card - link (https://hastebin.com/quyedikoqo.md). Output file still looks like nothing.
As for the rest - you wanted me to go into movie mode and execute your example code with different resolutions/fps settings, right? If yes - link (https://drive.google.com/open?id=18B4PMW7L2ISPot5LLPP0jbNDIaT0uxIv).
Code diff (https://hastebin.com/jehugaxile.md) - I had to move log_finish() little higher - otherwise log file was empty.
Title: Re: Canon 80D
Post by: a1ex on April 12, 2018, 09:39:21 PM
MIRROR.TXT: unfortunately it's mostly empty (no data). We have to either catch all debug messages, or port io_trace (ideally both).

1080p30 (just picked one):

binwalk -E -J RAM4-BF.BIN
binwalk -E -J RAM4-AF.BIN


(https://a1ex.magiclantern.fm/bleeding-edge/80D/1080p30-ent.gif)

There's a sharp peak in the "after" dump; that's likely a 14-bit raw image buffer.

Pixel peeping: graph starts at x=96px, ends at x=984px, peak starts at 638px (gimp).
File size 1072562176 => approximate address 0x2705285c +/- 0x126e20 => 0x26f00000 ... 0x2720000 (rounded).
Go there in binview and notice the pattern changing.

FE2E4B33 lv_raw_dump -> FE23BA16 get_raw_buffer -> 0x66B0 + 0x54 -> 0x67066000 -> cacheable 0x27066000.
Go there in binview to confirm the exact match. Pattern ends at about 0x27478400 (from binview)
=> size 4269056 = 0x412400 (approximate). Extract this from the RAM dump:


dd if=RAM4-AF.BIN of=raw.data bs=$((0x1000)) skip=$((0x27066)) count=$((0x413))


Let's try rawcover.py (https://github.com/ethiccinema/mlrawviewer/blob/master/tools/rawcover.py):

python rawcover.py raw.data
...
Possible RAW Bayer data found
Estimated frame width: 2480  <-- likely incorrect


Looks like a dark frame :( (mean=2048, mad=15, std=86; assuming high ISO; log suggests 3200).

Was the lens cap on (https://petapixel.com/2012/11/28/six-years-of-daily-self-portraits-with-the-lens-cap-on/) during the experiment?! Please take it off...
Title: Re: Canon 80D
Post by: Midnight Son on April 18, 2018, 06:44:57 PM
So, realistically what are the chances of getting 4k?
Title: Re: Canon 80D
Post by: jai554 on April 18, 2018, 07:30:16 PM
Quote from: Midnight Son on April 18, 2018, 06:44:57 PM
So, realistically what are the chances of getting 4k?

Should I say no chance?
https://wiki.magiclantern.fm/faq
Title: Re: Canon 80D
Post by: dfort on April 18, 2018, 08:19:04 PM
Never say never and always avoid always because all generalizations are false.

Seriously, there has been some progress made on other cameras including the 700D and 5D2 that might get them closer to 4K. It seems to indicate that all these Canon DSLR's could possibly do 4k.

For the 80D it is a little too early to say because ML isn't far enough along on that camera yet.
Title: Re: Canon 80D
Post by: jai554 on April 19, 2018, 03:41:01 AM
Quote from: dfort on April 18, 2018, 08:19:04 PM
Never say never and always avoid always because all generalizations are false.

Seriously, there has been some progress made on other cameras including the 700D and 5D2 that might get them closer to 4K. It seems to indicate that all these Canon DSLR's could possibly do 4k.

For the 80D it is a little too early to say because ML isn't far enough along on that camera yet.

Only in RAW recording right?
Title: Re: Canon 80D
Post by: dfort on April 19, 2018, 03:47:41 AM
Right, unless someone figures out how to do mjpeg which isn't totally out of the question.
Title: Re: Canon 80D
Post by: jai554 on April 19, 2018, 01:48:10 PM
Quote from: dfort on April 19, 2018, 03:47:41 AM
Right, unless someone figures out how to do mjpeg which isn't totally out of the question.

maybe if someone can figure out how to take JPEG silent pic then MJPEG will be possible
isnt it will put too much strain on the processor inside the camera?
Title: Re: Canon 80D
Post by: Walter Schulz on April 19, 2018, 02:11:35 PM
Digic 4/5 based cams encode H.264/JPEG by dedicated silicon/chips and not by running some code on multi-purpose CPUs. Take it as an educated guess MJPEG is processed the same way.
"Not totally out of the question" might be added by "Do not hold your breath".
Title: Re: Canon 80D
Post by: Chellyandruu on April 20, 2018, 04:39:10 AM
hey Alex,if you have any new files you want us to test on camera we are always here.just in case.
Title: Re: Canon 80D
Post by: a1ex on April 20, 2018, 10:17:53 AM
Replies #275/279, in case you missed them.

The files saved by that snippet will allow finding the LiveView RAW resolution (they include the input data to save the first 14-bit DNG). I'm unable to identify resolution from a dark frame though (it would look correct at many other different resolutions), so please run that test (again) without a lens cap.
Title: Re: Canon 80D
Post by: a1ex on April 24, 2018, 10:23:36 AM
Updated portable ROM dumper (https://www.magiclantern.fm/forum/index.php?topic=16534.msg200458#msg200458) and would like you to run a few tests:

- color palette repeatability (including last line)
- MD5 checksums (on a 256MB filesystem)
- MD5 checksums without the cache trick (comment out disable_caches_region1_ram_d6 from reboot.c)

This dumper saves both ROM1.BIN and SFDATA.BIN (for emulation).
Title: Re: Canon 80D
Post by: sombree on April 24, 2018, 12:35:08 PM
with disable_caches_region1_ram_d6():
- screen seems to be normal
- it starts dumping ROM1
- 2GB card: the after five minutes it's still dumping ROM1 - I'm not sure if camera locked up or it's that slow (probably the latter one)
- 256MB card: it dumps both ROM1 and SFDATA, but it's not that fast; last line of the text is white

without disable_caches_region1_ram_d6():
- screens looks normal, last line of the text is white
- it's much faster
- tried it three times; ROM1 and SFDATA from all three times have same checksum; I've also tried these files in QEMU and they work as expected
- for both (256MB and 2GB) cards results are the same

This is how screen looks like every time - click (https://imgur.com/yPZBXBi).

Edit: 1080p60 lv without lense cap - click (https://drive.google.com/open?id=1Qu9EllfaMYMqUBHKizKQNrMkKSQqdLuf).
Title: Re: Canon 80D
Post by: a1ex on April 24, 2018, 04:41:05 PM
My hypothesis: the following appear to be video modes tweaked for various maximum FPS, and when you select something in Canon menu, it starts from one of these and adjusts timer B to decrease the FPS until the desired value. For example, the 60p video mode is likely based on the 63.925 FPS one. These are full raw buffer sizes, including black borders:

2096 x 676  (timer A = 722, B = 342, 109.345 FPS) @ feb47d48
2096 x 1162 (timer A = 722, B = 585, 63.925 FPS) @ ff01d1c0
2096 x 1372 (timer A = 722, B = 690, 54.197 FPS) @ ff01d250
2144 x 2402 (timer A = 722, B = 1205, 31.034 FPS) @ ff01d2e0


And these appear to be for photo mode:

6288 x 4057 (timer A = 772, B = 4061, 8.612 FPS) @ feb47c28
6288 x 4057 (timer A = 1064, B = 4061, 6.249 FPS) @ feb47cb8


Here, dcraw -i -v reports full size 6288 x 4056 (including black borders). One at 8.6 FPS, as predicted, other at 6.25 FPS. Does the 80D have some still photo mode with lower frame rate? Does that mode bring any advantages, such as lower noise?!




How I've got these numbers? Figured out registers 0xD0006008 and 0xD0006014 are the FPS timers, and D0006800/6804 are for raw resolution (DIGIC 5 uses the same registers, except they start with 0xC0F0 instead of 0xD000, and the values follow the same pattern). Scanned the ROM for known patterns (https://www.magiclantern.fm/forum/index.php?topic=16054.msg195213#msg195213) (scan_raw_res.py) and got the above values.

Example:

ROM:FF01D1C0 DCD 0xD0006800
ROM:FF01D1C4 DCD 0x3000E
ROM:FF01D1C8 DCD 0xD0006804
ROM:FF01D1CC DCD 0x248021A


=> (see raw_lv_get_resolution in raw.c for interpretation) 524x581 raw => 2096x1162 (horizontal multiplier 4, vertical multiplier 2).

The multiplier setup is quite unusual. So far, all D4/5 models seem to have a hardcoded horizontal multiplier, possibly being the number of columns read out in parallel, and vertical multiplier was always 1. For 80D, multipliers are (8,1) in photo mode and (4,2) in LiveView.

63.925 fps (LiveView) vs 8.612 fps (photo):

D0006800: 0x3000E
D0006804: 0x248021A
D0006804: 2096 x 1162

D0006800: 0x3000E
D0006804: 0xFDB0320
D0006804: 6288 x 4057





Enough chit-chat; please find the first 14-bit DNG from 80D, captured at 1080p60:

000000.DNG (https://a1ex.magiclantern.fm/bleeding-edge/80D/000000.DNG) / 000000.JPG (https://a1ex.magiclantern.fm/bleeding-edge/80D/000000.JPG)

Camera name deliberately misspelled in EXIF, otherwise it won't open in RawTherapee (figure out why).
Title: Re: Canon 80D
Post by: OlRivrRat on April 24, 2018, 06:05:55 PM
              @ Alex

       Sweet ~ & the DNG opens in IridientDeveloper Beautifully ~
Title: Re: Canon 80D
Post by: Lars Steenhoff on April 24, 2018, 09:44:52 PM
works well in adobe ACR. looks good too!
Title: Re: Canon 80D
Post by: Stathman on April 25, 2018, 12:02:10 AM
To early to open a bottle of champagne?    :P
Title: Re: Canon 80D
Post by: goldenchild9to5 on April 25, 2018, 12:25:41 AM
Great work Team..
Title: Re: Canon 80D
Post by: squig on April 25, 2018, 01:14:45 AM
13 stops dynamic range
On sensor ADC
Dual pixel AF
80MB/s write speed

Couldn't shoot cats with it.
Title: Re: Canon 80D
Post by: emklap on April 25, 2018, 10:51:24 AM
Nice progress guys :-)

80D burst speeds according to Canon's website






Approximate Speed:Shooting Conditions
Approx. 7 shots/sec.:during High-speed continuous shooting
Max. approx. 5.0 shots/sec:during Live View shooting or when [Servo AF] is set.
Approx. 3 shots/sec.:Low-speed continuous shooting Silent continuous shooting
Title: Re: Canon 80D
Post by: a1ex on April 25, 2018, 12:04:00 PM
Can you find out whether different drive modes result in different values on these lines from the startup log?


  29061: 11306.683 [CAPE] E-7.2 SetSsgVSize for Readout
  29062: 11306.692 [CAPE] VSIZE(0xfdd)
  29063: 11306.705 [CAPD] [0](0xd0006008),(0x3030303)
  29064: 11306.717 [CAPD] [1](0xd000600c),(0x3030303)
  29065: 11306.728 [CAPD] [2](0xd0006010),(0x303)
  29066: 11306.739 [CAPD] [3](0xd0006014),(0xfdd)


Expected: 0x4XX instead of 0x303 in the slower drive modes.
Title: Re: Canon 80D
Post by: OlRivrRat on April 26, 2018, 06:36:47 PM
   My 80D no longer wants to Play with ML. Any SD card with a BootLoader

or Rescue autoexec on it will cause the 80d to go Dark > No signs of Life.

   With "Normal" SD it works just fine.
Title: Re: Canon 80D
Post by: a1ex on April 26, 2018, 06:41:36 PM
Quote from: OlRivrRat on April 26, 2018, 06:36:47 PM
   My 80D no longer wants to Play with ML. Any SD card with a BootLoader

or Rescue autoexec on it will cause the 80d to go Dark > No signs of Life.

   With "Normal" SD it works just fine.

With the rescue autoexec, you can test the card on any other model that already runs ML. The rescue binary is portable, it loads on any camera from DIGIC 2 all the way to DIGIC 7 (and also on DIGIC 8, to some extent), as long as its boot flag is enabled.
Title: Re: Canon 80D
Post by: OlRivrRat on April 26, 2018, 11:01:44 PM
                     @Alex

           Reloaded Port'Rescue on 2 Diff' SDs, 8GB & 16GB & Both work fine in SL1.

In 80D I am now getting just a Blue Screen. Which is more than what it was doing earlier.
Title: Re: Canon 80D
Post by: a1ex on April 27, 2018, 10:58:40 AM
The blue screen may suggest the latest palette "fix" is incorrect. These cache issues are not deterministic, so if you try to start the camera a few times, it might work.

Can you try this one? autoexec.bin (http://a1ex.magiclantern.fm/debug/portable-rom-layout/autoexec.bin)

There are 3 things to see here:

1) whether the display works (I hope so :D)
2) repeatability of colors, including last line (requires many test runs, 10 is fair, 50 would be great)
3) ROM layout (camera might lock up on this one)

If you can compile, please check whether changeset a289731 (https://bitbucket.org/hudson/magic-lantern/commits/a289731b5ba4bb3520c9217e56ddefe1de121853) makes any difference regarding the first two points.
Title: Re: Canon 80D
Post by: OlRivrRat on April 27, 2018, 06:56:09 PM
      @ Alex

   That"s Better > 1st try gave Blue Screen with Magenta Verbiage,

2nd & 3rd try gave >      https://ibb.co/eUkKeH

   Seems incomplete, is that to be expected?
Title: Re: Canon 80D
Post by: a1ex on April 27, 2018, 07:01:59 PM
Hm, it locked up.

Let's try again on a different start address (same link).
Title: Re: Canon 80D
Post by: OlRivrRat on April 27, 2018, 07:47:34 PM
      @ Alex

   Getting Closer? >      https://ibb.co/eeZ9UH
Title: Re: Canon 80D
Post by: sombree on April 27, 2018, 08:40:03 PM
@a1ex
I think there might be another reason for black screen when you try to dump ROM on the same sdcard for the second time - during first time canon's bootloader fills up sdcard with some random garbage (https://imgur.com/JgUw4LB). You can find it in catalog on the sdcard (it'll be present in "System Volume Information" if there isn't any other catalog).
I can confirm it for 80D and 760D.
It happens both with and without disable_caches_region1_ram_d6() in reboot.c. I doubt it has anything to do with palette issue.
Formatting card fixes problem but it appears again (as bootloader is filling up sdcard again).

Edit:
Interesting - on my 80D screen colors are always as they supposed to be. On 760D first time background was blue instead of black but all next times - black  ???
Title: Re: Canon 80D
Post by: a1ex on April 27, 2018, 08:48:33 PM
Screen colors have nothing to do with card contents.
Title: Re: Canon 80D
Post by: sombree on April 27, 2018, 08:50:42 PM
I know. I was just saying that ROM dumper doesn't boot when card is filled up with previously generated random garbage. I was jus thinking that this was cause of OlRivrRat's black screen.
Title: Re: Canon 80D
Post by: OlRivrRat on April 28, 2018, 07:50:02 AM
   I have to admit that I am a bit concerned about My 80D. Just 3Weeks ago I was able to

get an SFDATA Dump from it & back in Dec I was able to get a ROM Dump from it & now it

will not accomplish Either. It won't even complete the Portable Rescue. Anybody have any

ideas as to what might have caused this or how to get it back on track. It seems to function

just fine otherwise.
Title: Re: Canon 80D
Post by: sombree on April 28, 2018, 11:11:46 AM
@a1ex
On your autoexec.bin I don't have these warnings about inconsistency.
Last commit 7eaab92:
(https://i.imgur.com/5qTDKGa.png)
Title: Re: Canon 80D
Post by: a1ex on April 28, 2018, 11:45:03 AM
That happens if it managed to read two different values from the same memory address (probably not unusual if there's no memory chip connected there, and probably not a deterministic behavior either).

There is some code commented out, if you want to explore further. I still wonder why the bootloader configures a memory region starting at 0xEE000000.
Title: Re: Canon 80D
Post by: OlRivrRat on April 28, 2018, 07:37:03 PM
                      @ Alex

           Is there a way to Uninstall/Reset the BootFlag on the 80D so as to try a Reinstall?
Title: Re: Canon 80D
Post by: a1ex on April 28, 2018, 07:45:10 PM
Your boot flag values are correct, there's nothing to adjust there.

What is very important for the ROM dumper is to use a tiny filesystem (such as the 256MB image that comes with QEMU); see the first post on the portable ROM dumper (https://www.magiclantern.fm/forum/index.php?topic=16534.0) thread. That appears to be a limitation in Canon code (bootloader file I/O routines don't handle large filesystems well). By not using a tiny filesystem, side effects can be either what sombree described earlier, or nothing obviously wrong if lucky, or not working at all if unlucky.

Also updated the portable ROM dumper autoexec on the latest codebase, just in case.
Title: Re: Canon 80D
Post by: OlRivrRat on April 28, 2018, 11:37:53 PM
       Created a 256MB Partition on My 1GB SD that has worked as a 1GB SD in the past,

loaded todays ROM Dumper & only get a Few LED Flashes @ StartUp then Nothing.
Title: Re: Canon 80D
Post by: a1ex on April 28, 2018, 11:49:50 PM
Does the same card work in another camera?

Can anyone else confirm the latest dumper is actually working on 80D? I've tested it in QEMU and could not see anything wrong with it.
Title: Re: Canon 80D
Post by: Chellyandruu on April 29, 2018, 12:06:24 AM
its working on mine.
(https://thumb.ibb.co/hbewwx/80d.jpg) (https://ibb.co/hbewwx)
Title: Re: Canon 80D
Post by: OlRivrRat on April 29, 2018, 03:55:38 AM
       The 256MB Partition won't Boot in either 80D or SL1 > It acts like a normal SD Card. The Latest ROM Dumper when placed on My 1GB SD locks up

@ Dumping ROM1 on 80D & Dumping ROM0 on SL1. Pretty Sure this is the SD that got Me ROM Dumps in Dec from the 80D.
Title: Re: Canon 80D
Post by: sombree on April 29, 2018, 03:56:41 PM
@OlRivrRat
Did you make your card bootable after shrinking partition?
Title: Re: Canon 80D
Post by: OlRivrRat on April 29, 2018, 05:39:09 PM
                     @ Sombree

       Yes ~
Title: Re: Canon 80D
Post by: sombree on April 29, 2018, 06:15:15 PM
How? What program did you use?
Title: Re: Canon 80D
Post by: OlRivrRat on April 29, 2018, 07:39:45 PM
                     @ Sombree

       Same 1 I Always Use > MacBoot ~
Title: Re: Canon 80D
Post by: Walter Schulz on April 29, 2018, 07:47:38 PM
Quote from: OlRivrRat on April 29, 2018, 07:39:45 PM
                     @ Sombree

       Same 1 I Always Use > MacBoot ~

You can check by copying portable display test autoexec.bin to card and inserting it into another cam with bootflag set.
Title: Re: Canon 80D
Post by: OlRivrRat on April 29, 2018, 08:28:09 PM
 portable display test autoexec.bin works just fine on SL1 but on 80D produces this >


(https://thumb.ibb.co/d3WTuH/IMG_7654_Xd.jpg) (https://ibb.co/d3WTuH)


https://ibb.co/eeZ9UH

This is on a 1GB SD > The Smallest I Have. If I try to Partition to 256mb then won't work in Either Cam'.
Title: Re: Canon 80D
Post by: arajasek on May 03, 2018, 08:37:17 AM
Hello Team, I am very new to this forum, I have an 80D and a little bit of programming experience and I am willing to help.
can someone please share a link on how to get started please? what do I need ?thanks.
Title: Re: Canon 80D
Post by: ricflair4life on May 07, 2018, 11:05:41 AM
I'm going to assume things are going well? Or can someone please explain the success so far? I'm sure I'm not the only person who doesn't understand the technical stuff behind this 🤷🏻‍♀️ Thanks :)
Title: Re: Canon 80D
Post by: Walter Schulz on May 07, 2018, 11:13:11 AM
Don't hold your breath. My advice (for all not involved in porting (or willing and able to get involved)): If there is no ML for your cam act like there will be no ML for your cam ever.
Title: Re: Canon 80D
Post by: JosiahD on May 08, 2018, 03:19:38 PM
@alex how is it coming with the 80D?
I have a brand new one and might help if you need it.
Title: Re: Canon 80D
Post by: a1ex on May 08, 2018, 09:34:33 PM
Short answer: https://wiki.magiclantern.fm/faq#any_progress_on_xyz

Long answer: if you want to help, start by reading this very thread. It covers how to run the proof of concept code on your camera, how to get started with reverse engineering, links to how the firmware works and so on. Continue by trying what you have read (first in the emulator, then on the camera if you trust your code). Feel free to ask when you get stuck (first the search engine, then here in the thread).

Again: I'm not working on this full-time, I don't have this camera and don't want one. I'm here to help, but it's your job to port ML if you want it. I'm just providing tools, proof of concept code and assistance to those of you interested in porting ML on their camera.
Title: Re: Canon 80D
Post by: 201400005064 on May 15, 2018, 02:55:21 AM
How can I help sir? I have an 80d and maybe can run some tests.
Title: Re: Canon 80D
Post by: eduperez on May 15, 2018, 10:13:59 AM
Quote from: JosiahD on May 08, 2018, 03:19:38 PM
@alex how is it coming with the 80D?
I have a brand new one and might help if you need it.

Quote from: 201400005064 on May 15, 2018, 02:55:21 AM
How can I help sir? I have an 80d and maybe can run some tests.

As @a1ex has commented before, you cannot help, but you can ask for help.
Title: Re: Canon 80D
Post by: ricflair4life on May 16, 2018, 02:06:03 PM
I understand you don't do this full time but all I want to know is the progress so far. Honestly, I don't think I'll be able to program or read any sort of codes anytime soon (or whatever goes into it). Although, I bet there's a lot of work and time needed to accomplish such a task and I appreciate that very much. To me this is all rocket science! 🤦🏻‍♀️ I bet it's like that for a lot of us as well and I'm sure a lot of us keep coming back to the forum to see if any progress has been made lol
Title: Re: Canon 80D
Post by: kotik on May 22, 2018, 06:15:38 PM
Trying to get a ROM dump of my 80D 1.0.2
No luck, blue or red background and nothing written to the SD card (Sony SDXC 64 GB).
https://ibb.co/magzrT (https://ibb.co/magzrT)
Title: Re: Canon 80D
Post by: Walter Schulz on May 22, 2018, 06:23:30 PM
Read reply #313
Title: Re: Canon 80D
Post by: kotik on May 24, 2018, 12:45:50 PM
An old 2GB SD card did the trick.
Did get three ROM dumps:
ROM1A.BIN, ROM1B.BIN and ROM1C.BIN and their checksums.

Oddly enough ROM1A.BIN and ROM1B.BIN have the same checksum each dump. Even after trying 3 times.

Dump#1/ROM1A.BIN 0e103ef26d93d3ba7f03d5141a3f351c
Dump#1/ROM1B.BIN 0e103ef26d93d3ba7f03d5141a3f351c
iMac-27:~ $
Dump#2/ROM1A.BIN d9bfe2012acae3af0ad7cb77b751d067
Dump#2/ROM1B.BIN d9bfe2012acae3af0ad7cb77b751d067
iMac-27:~ $
Dump#3/ROM1A.BIN 59b7f7756bb6deb90e67c1e4bd0ec167
Dump#3/ROM1B.BIN 59b7f7756bb6deb90e67c1e4bd0ec167


I suppose I can ignore ROM1A or ROM1B?

Not on topic: On my 6D Mark II I got two ROM dumps: ROM0.BIN and ROM1.BIN!
Title: Re: Canon 80D
Post by: a1ex on May 25, 2018, 02:32:56 PM
Right, the old dumper saves two files because of the known (https://www.magiclantern.fm/forum/index.php?topic=16534.msg170417#msg170417) issues (https://www.magiclantern.fm/forum/index.php?topic=16534.msg200458#msg200458) with file I/O routines from Canon bootloaders (just in case one of them ends up wrong). I should update the FIR to the latest codebase (https://www.magiclantern.fm/forum/index.php?topic=17360.msg200459#msg200459), which also saves a copy of the serial flash contents (you will need it for emulation).

DIGIC 7 has a different ROM layout; there, ROM1 is likely replacing the serial flash present on D6. This is covered in the initial firmware analysis (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst#rst-header-initial-firmware-analysis) notes from the QEMU guide, and also in the ROM dumper source (https://bitbucket.org/hudson/magic-lantern/src/recovery/src/reboot.c?fileviewer=file-view-default#reboot.c-1139).
Title: Re: Canon 80D
Post by: kotik on May 25, 2018, 03:23:29 PM
@a1ex
Thanks for the directions. The last time I worked a lot in assembler was with a 6502 microprocessor together with the 6510 second processor on an Acorn computer (BBC +). I still have a lot to catch up and the tons of ML information are pretty much fragmented on the website.
Title: Re: Canon 80D
Post by: kotik on May 27, 2018, 06:50:48 PM
Thanks to the more than excellent work of Danne on the Compiler.app I am able to compile ML on a Mac in a very short time. But the show must go on.

Have done the LED test with the 80D and it works.

As A1ex suggested I needed new ROM dumps with serial flash contents for emulation with the latest portable ROM dumper.

Didn't work with the 2GB SD card.
Made a 259.5MB SD partition, didn't work either!
There is some noise activity, but nothing read to the SD card, 80D works as usual.

iMac-27:~ $ diskutil list
/dev/disk0 (internal):
:
/dev/disk4 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *2.0 GB     disk4
   1:                 DOS_FAT_16 EOS_DIGITAL             2.0 GB     disk4s1

iMac-27:~ $ diskutil unmountDisk /dev/disk4
Unmount of all volumes on disk4 was successful
iMac-27:~ $ sudo dd if=/Users/xxxx/Desktop/sd.img of=/dev/disk4
Password:
506880+0 records in
506880+0 records out
259522560 bytes transferred in 128.059448 secs (2026579 bytes/sec)
iMac-27:~ $ sudo diskutil eject /dev/rdisk4
Disk /dev/rdisk4 ejected
iMac-27:~ $ diskutil list

/dev/disk4 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *2.0 GB     disk4
   1:                 DOS_FAT_16 EOS_DIGITAL             259.5 MB   disk4s1

Title: Re: Canon 80D
Post by: OlRivrRat on May 28, 2018, 02:50:09 AM
                   @Kotik

           As I posted back in Reply #265 > I have an SFDATA.BIN from My 80D if anyone is interested
Title: Re: Canon 80D
Post by: kotik on May 28, 2018, 01:46:29 PM
@OlRivrRat

Did send you a PM.
Title: Re: Canon 80D
Post by: OlRivrRat on May 28, 2018, 11:32:07 PM
                    @Alex

   My 80D is (@Least for the moment) again allowing ML Portable Rescue & other ML Stuff

to @Least attempt to do something. So I tried again to run the ROM + SFData Dumper that

You provided back on 28Apr > "autoexec.bin (2018Apr28, 7eaab92)" & it gets as far as

Dumping ROM1...  & then Freezes making Battery Removal required ~ Any THoughts?

                     ORR ~ DeanB
Title: Re: Canon 80D
Post by: a1ex on May 29, 2018, 09:53:01 AM
Asked and answered (https://www.magiclantern.fm/forum/index.php?topic=17360.msg200733#msg200733). The bootloader file write routines are very picky about the filesystem, in particular about its size.

Quote from: a1ex on April 23, 2017, 11:15:34 AM
So far, what worked every single time was formatting the card at a much lower capacity (I've used 256MB successfully in many cases). To do this, you can write the SD image that comes with QEMU (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/sd.img.xz) to your SD or CF card. This guide (https://thepihut.com/blogs/raspberry-pi-tutorials/17789160-backing-up-and-restoring-your-raspberry-pis-sd-card) is helpful; just don't forget to unzip the SD image. This image contains the portable display test (http://www.magiclantern.fm/forum/index.php?topic=14732) and is bootable (so, you can test it in the camera straight away).
Title: Re: Canon 80D
Post by: kotik on May 29, 2018, 01:51:25 PM
Just started all over again and now with success.
https://ibb.co/kQKqDJ (https://ibb.co/kQKqDJ)
Incidentally, the SFDATA.BIN differs from the SFDATA.BIN that I received from OlRivrRat.

UPDATE: No wonder that my SFDATA.BIN is different. Just 8.4MB of 0x00's!
Title: Re: Canon 80D
Post by: kotik on May 29, 2018, 04:45:10 PM
Interesting or not?
0fec9480 db "\n********** FACTORY ADJUSTMENT MENU **********\n", 0 ; DATA XREF=sub_fec9368+20
0fec94b0 db "0. Exit from Factory Adjustment\n", 0                  ; DATA XREF=sub_fec9368+28
0fec94d4 db "1. Leak Check\n", 0                                    ; DATA XREF=sub_fec9368+36
0fec94e4 db "2. ASV Display\n", 0                                   ; DATA XREF=sub_fec9368+44
0fec94f4 db "3. RAM Check\n", 0                                     ; DATA XREF=sub_fec9368+52
0fec9504 db "4. ROM Check\n", 0                                  ; DATA XREF=sub_fec9368+60
0fec9514 db "5. ICU Version Check\n", 0                          ; DATA XREF=sub_fec9368+68
0fec952c db "6. Serial Flash Check\n", 0                          ; DATA XREF=sub_fec9368+76
0fec9544 db "9. Input Device Unique\n", 0                        ; DATA XREF=sub_fec9368+84
0fec955c db "A. ALL Check\n", 0                                  ; DATA XREF=sub_fec9368+92
0fec956c db "B. Adjustment Data Display and Change\n", 0          ; DATA XREF=sub_fec9368+100
0fec9594 db "C. Check Flag Display and Initialization\n", 0        ; DATA XREF=sub_fec9368+108
0fec95d0 db "E. HDMI Check\n", 0                                  ; DATA XREF=sub_fec9368+124
0fec95e0 db "F. AUDIO Check\n", 0                                ; DATA XREF=sub_fec9368+132
Title: Re: Canon 80D
Post by: OlRivrRat on May 29, 2018, 06:36:59 PM
       @Alex

Have attempted to use " This guide " >

https://thepihut.com/blogs/raspberry-pi-tutorials/17789160-backing-up-and-restoring-your-raspberry-pis-sd-card

with no success ~

Back in Dec17 I was able to get ROM Dumps with My 1GB SD & in Apr18 when I tried to get SFData

with the same 1GB SD it wouldn't work so I tried a 16GB SD & it worked.

Have tried all ways I know to make My 1GB look like a 256MB > again without success.
Title: Re: Canon 80D
Post by: a1ex on May 29, 2018, 06:50:19 PM
Quote from: kotik on May 29, 2018, 01:51:25 PM
UPDATE: No wonder that my SFDATA.BIN is different. Just 8.4MB of 0x00's!

This problem was also present in reply #316 (where the dumper was reported to work); looks like I've missed some hardware initialization (that wasn't required in QEMU, so the tests I've ran didn't scream). And, since nobody bothered to check the files from the latest dumper (posted about 1 month ago, also on the 750D thread (https://www.magiclantern.fm/forum/index.php?topic=17627.msg200466#msg200466)), I wasn't even aware of the issue.

Updated the portable ROM dumper; please check whether it actually works and outputs valid files.


Quote from: OlRivrRat on May 29, 2018, 06:36:59 PM
Have attempted to use " This guide " >

https://thepihut.com/blogs/raspberry-pi-tutorials/17789160-backing-up-and-restoring-your-raspberry-pis-sd-card

with no success ~

What files do you have on the card after writing the SD image, and what is their size?
Title: Re: Canon 80D
Post by: OlRivrRat on May 29, 2018, 07:06:04 PM
Nothing shows up on the SD
Title: Re: Canon 80D
Post by: a1ex on May 29, 2018, 08:02:34 PM
That's not good; you should end up with a small autoexec.bin. That one is present on the QEMU SD image, so you should see it on the physical card after writing (or "restoring", as in the tutorial) the SD image to the card.
Title: Re: Canon 80D
Post by: OlRivrRat on May 29, 2018, 08:13:35 PM
     Also tried this >

https://support.plex.tv/articles/212523657-how-do-i-create-the-disk-image-for-my-sd-card-or-usb-stick/

My Educated Guess is that there is something about these instructions that I am Misunderstanding .
Title: Re: Canon 80D
Post by: a1ex on May 29, 2018, 08:32:22 PM
The second tutorial should work as well; no idea what's wrong, maybe you can upload some screenshots or maybe even record a video of your screen?
Title: Re: Canon 80D
Post by: kotik on May 29, 2018, 10:00:46 PM
@a1ex
I can confirm that the latest autoexec.bin is writing data to the SFDATA.BIN file.
Compared SFDATA.BIN to the one I received from OlRivrRat (yesterday), there are 70 differences.

@OlRivrRat
I used an old 2GB SD Card and didn't know how I used it before.
Nowadays I only use 128GB cards for video.
So this time I didn't format in the camera, but used SD Card Formatter.
Like you I used MacBoot to set the bootflag.

The rest I did was the same as I did in message #337.
Hope this helps.
Title: Re: Canon 80D
Post by: OlRivrRat on May 29, 2018, 10:59:01 PM
      @Alex

   So had some BrainFood for lunch & gave it another whirl with info I had gleaned from

Mistakes & got it to work > Now have 259.4MB SD & Complete? ROM & SFData Dumps .

   SD Card looks like >


(https://thumb.ibb.co/hhnM3J/Screen_shot_2018_05_29_at_2_57_14_PM.png) (https://ibb.co/hhnM3J)
Title: Re: Canon 80D
Post by: kotik on May 30, 2018, 11:16:36 AM
Where do I put the ROM1.BIN and SFDATA.BIN and how to start emulation?
Can I still use Danne's Compiler.app? Danne thought that a1ex or dfort were the ones who could help.

Where to put or make a SD-card image?
magic-lantern -> contrib -> qemu -> scripts -> 80D?
or
magic-lantern -> platform -> 80D.102?
Title: Re: Canon 80D
Post by: Danne on May 30, 2018, 12:17:02 PM
Did you go through this Kotik?
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst?fileviewer=file-view-default
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default

Title: Re: Canon 80D
Post by: kotik on May 30, 2018, 12:23:56 PM
Yep, even a few times. But all the simple testing (or install) command lines like

# all EOS models should run this without any trickery
/path/to/qemu-eos$  ./run_canon_fw.sh 60D,firmware="boot=1"


are giving me:
No such file or directory
Title: Re: Canon 80D
Post by: Danne on May 30, 2018, 01:15:25 PM
Best of luck Kotik. I spent too little time on qemu concepts but I'm certain it's worth every minute digging.
Title: Re: Canon 80D
Post by: a1ex on May 30, 2018, 01:24:42 PM
Tried following the video guides?

Quote from: a1ex on December 20, 2017, 12:38:57 AM
Guide: https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/ (README)
Video: this sticky tweet (https://twitter.com/autoexec_bin/status/913530810686418944) and the same for Mac (http://www.magiclantern.fm/forum/index.php?topic=16012.msg191686#msg191686). GUI not working yet on D6.
Title: Re: Canon 80D
Post by: Danne on May 30, 2018, 02:10:07 PM
Installing qemu as we speak and verbosity is zip. Is this correct?
*** Setting up QEMU in /Users/dan/qemu-eos...

Been waiting 10minutes and no progress so far. Checking console window:
AMFI: allowing exception handler for 'bash' (13379) because the handler was set by master-entitled process 'init' (1).

Will wait a little longer...

EDIT: Hold on, working:
     0K ........ ........ ........         100% 2.61M=9.3s

Initialized empty Git repository in /Users/dan/qemu-eos/qemu-2.5.0/.git/

Now compiling...

Ok:
Installed and compiled qemu through Compiler.app and then I put in both rom files from my 100D and did following:
dans-MacBook-Pro:qemu-eos dan$ ./run_canon_fw.sh 100D,firmware=boot=1

There´s a reaction but cannot load the image .
DebugMsg=0x4A74 (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 - 0FFFFFFF: eos.ram
40001000 - 4FFFFFFF: 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.mmio
[EOS] loading './100D/ROM0.BIN' to 0xF0000000-0xF0FFFFFF
[EOS] loading './100D/ROM1.BIN' to 0xF8000000-0xF8FFFFFF
Could not open ./100D/SFDATA.BIN


I miss this file:
Could not open ./100D/SFDATA.BIN
So, sf_dump module needed...

Compiling sf_dump.mo and enabling and:
Wrong version (v6.0, expected v7.0)
phew, so close...

Oops. Update sf_dump here:
https://bitbucket.org/hudson/magic-lantern/src/crop_rec_4k/modules/sf_dump/

Ok, we´re home:
(https://s15.postimg.cc/fn8h2nlor/Screen_Shot_2018-05-30_at_15.15.54.png_300px.jpg)
Title: Re: Canon 80D
Post by: kotik on May 30, 2018, 06:34:38 PM
Solved it myself.   :D

Running /Users/xxxx/qemu-eos/qemu-2.5.0/.git/
asked me this time for my email address and name.
The Compiler.app never did, and therefore the installation was incomplete and kept saying:"No such file or directory".

So I am up and running now.

(https://thumb.ibb.co/d2J3ky/DidIt.png) (https://ibb.co/d2J3ky)

@a1ex
Yes, I had seen the sticky tweet for Mac. I even loaded the animated GIF in PhotoShop to examine it frame by frame.
Title: Re: Canon 80D
Post by: Danne on May 30, 2018, 07:54:37 PM
Cool, my credentials worked over here so will keep an eye on this issue.
Title: Re: Canon 80D
Post by: kotik on May 30, 2018, 08:24:36 PM
Many thanks Danne!   ;)
Title: Re: Canon 80D
Post by: OlRivrRat on May 30, 2018, 08:49:24 PM
                     @Danne

       OK Danne, Feelin Gutsy > Going to give Compiler a Shot. Got to step3 & 80D is not on list so what do I choose
Title: Re: Canon 80D
Post by: Danne on May 30, 2018, 08:53:50 PM
Step three 3? Is that from the qemu install? I only installed qemu twice so not very familiar atm. I guess if no 80D present this is a bleeding edge case...
Title: Re: Canon 80D
Post by: OlRivrRat on May 30, 2018, 09:00:21 PM
Yes, qemu install
Title: Re: Canon 80D
Post by: OlRivrRat on May 30, 2018, 09:11:15 PM
Thought I'd try 100D but it isn't on list either ~
Title: Re: Canon 80D
Post by: Danne on May 30, 2018, 09:21:23 PM
I have the 100D folder in my qemu folder. Checked inside the installed folder?
Title: Re: Canon 80D
Post by: OlRivrRat on May 30, 2018, 09:27:34 PM
I think I'm TooOld for this stuff > I'm finding Lots of evidence that I somehow was running QEMU back in Dec17 but I have No Recollection of doing so or how I would have done it. Just lost the Gutsy Feelin ~
Title: Re: Canon 80D
Post by: OlRivrRat on May 30, 2018, 09:35:29 PM
There is a 100D & 80D Folder in My QEMU Folder & Both contain ROM & SFData. Appears as though there is a Folder for Dang Near Every Canon that ever was, in that QEMU Folder.
Title: Re: Canon 80D
Post by: Danne on May 30, 2018, 09:48:15 PM
wow, 80D too.
Put your rom files and create SFDATA.BIN with sf_dump.mo
Files into 100D folder.
ROM0.BIN
ROM1.BIN
SFDATA.BIN


What the heck. Here´s the sfdata.bin file.
https://bitbucket.org/Dannephoto/magic-lantern/downloads/SFDATA.BIN

cd into your qemu folde then run:
./run_canon_fw.sh 100D,firmware=boot=1
Title: Re: Canon 80D
Post by: kotik on May 30, 2018, 11:17:22 PM
@a1ex
Trying some older stuff:
(
>   sleep 3; echo "akashimorino";
>   sleep 1; echo "dumpf";
> ) | (
>   ./run_canon_fw.sh 80D -serial stdio -s -S &
>    arm-none-eabi-gdb -x 80D/patches.gdb
> )
-bash: arm-none-eabi-gdb: command not found
iMac-27:qemu-eos $ qemu-system-arm 25643   12u   REG   1,10 259522560 8133999 sd.img

Error: please unmount the SD image.
Title: Re: Canon 80D
Post by: OlRivrRat on May 31, 2018, 01:21:34 AM
       @Danne

That link gives > "Link Has No Power Here"
Title: Re: Canon 80D
Post by: OlRivrRat on May 31, 2018, 01:27:09 AM
       @Danne

Both 80D & 100D Folders Already have Rom & SFData. Where do I run

"./run_canon_fw.sh 100D,firmware=boot=1"

If I Run that in Terminal it says "No such file or directory"

I Really have No Clue what I am doing ~
Title: Re: Canon 80D
Post by: Danne on May 31, 2018, 01:39:02 AM
in terminal write:
cd [drag your qemu folder here] press enter

On my computer it looks like this when inside the folder:
dans-MacBook-Pro:qemu-eos dan$
Now let´s run this:
dans-MacBook-Pro:qemu-eos dan$ ./run_canon_fw.sh 100D,firmware=boot=1

If you still have issues maybe there are credential issues like Kotik describes above.

tip:
You can also set your preferences to open terminal by right clicking a folder:
http://www.betterhostreview.com/open-terminal-window-at-folder-finder-mac.html
Title: Re: Canon 80D
Post by: OlRivrRat on May 31, 2018, 01:45:05 AM
When I do >

in terminal write:
cd [drag your qemu folder here] press enter

I Get >

WDeans-Mac-Pro:~ ORRz$ cd/Users/ORRz/qemu
-bash: cd/Users/ORRz/qemu: No such file or directory
WDeans-Mac-Pro:~ ORRz$
Title: Re: Canon 80D
Post by: Danne on May 31, 2018, 01:53:29 AM
cd/Users/ORRz/qemu  should be cd /Users/ORRz/qemu
try space after the word cd
Anyway. If you ran qemu installation through Compiler.app it should hav a folder named qemu-eos in home folder. Not sure why it´s called qemu only.
Title: Re: Canon 80D
Post by: OlRivrRat on May 31, 2018, 01:59:06 AM
I do not "qemu-eos" so guessing I never got all the way through Via Compiler before getting Stymied
Title: Re: Canon 80D
Post by: OlRivrRat on May 31, 2018, 02:04:36 AM
So now I'm here >

WDeans-Mac-Pro:qemu ORRz$ cd /Users/ORRz/qemu
WDeans-Mac-Pro:qemu ORRz$ ./run_canon_fw.sh 100D,firmware=boot=1
diskimages-helper 10084 ORRz    5u   REG   1,17 259522560 2604389 sd.img

Error: please unmount the SD image.
WDeans-Mac-Pro:qemu ORRz$
Title: Re: Canon 80D
Post by: OlRivrRat on May 31, 2018, 02:11:37 AM
& now with SD Gone >

WDeans-Mac-Pro:qemu ORRz$  ./run_canon_fw.sh 100D,firmware=boot=1
Please call configure before running make!
make: *** [config-host.mak] Error 1
WDeans-Mac-Pro:qemu ORRz$
Title: Re: Canon 80D
Post by: OlRivrRat on May 31, 2018, 02:27:46 AM
Another attempt @ Installing QEMU Via Compiler gets Me to >


Would you like to install QEMU?
[y/n]
y

installing QEMU
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

This will setup QEMU for emulating Magic Lantern.
Thou shalt not be afraid of compiling stuff on Linux ;)
Continue? [y/n] y

*** Installing dependencies for Mac...

./install.sh: line 106: lsb_release: command not found
*** WARNING: 64-bit GDB is known not to work.

*** WARNING: a valid arm-none-eabi-gdb could not be found.
*** Downloading a toolchain and installing it without the package manager.
*** Will be installed in your home directory (Makefile.user.default expects it there).


*** Will download gcc-arm-none-eabi-5_4-2016q3 from:
    https://developer.arm.com/open-source/gnu-toolchain/gnu-rm

*** Toolchain already installed in:
    ~/gcc-arm-none-eabi-5_4-2016q3

*** Please add gcc binaries to your executable PATH.
*** Run this command, or paste it into your .profile and reopen the terminal:
    export PATH=~/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH

*** WARNING: 64-bit GDB is known not to work.
Continue anyway? [y/N]

         Thinkin I'm just Wastin Your Time ~ Might be good name for a song ~
Title: Re: Canon 80D
Post by: kotik on May 31, 2018, 08:38:26 AM
@OlRivrRat
I'm wondering which MacOSX version you're using.
In message #351 your screen dump still has the aqua graphical user interface which Apple flattened in 2014 (MacOS Yosemite)!
Title: Re: Canon 80D
Post by: a1ex on May 31, 2018, 08:50:51 AM
Quote from: kotik on May 30, 2018, 11:17:22 PM
@a1ex
Trying some older stuff:
(
>   sleep 3; echo "akashimorino";
>   sleep 1; echo "dumpf";
> ) | (
>   ./run_canon_fw.sh 80D -serial stdio -s -S &
>    arm-none-eabi-gdb -x 80D/patches.gdb
> )
-bash: arm-none-eabi-gdb: command not found
iMac-27:qemu-eos $ qemu-system-arm 25643   12u   REG   1,10 259522560 8133999 sd.img

Error: please unmount the SD image.


There are two error messages. The first one requires this step, which you already did during installation, but its effect vanished after opening a new terminal:

    export PATH=~/gcc-arm-none-eabi-whatever/bin:$PATH


though, for Mac, it's best to compile the latest gdb from source (https://www.magiclantern.fm/forum/index.php?topic=2864.msg200954#msg200954) (todo: update the install script to do that).

The second one tells you the SD image is in use by another QEMU process.
Title: Re: Canon 80D
Post by: Danne on May 31, 2018, 09:06:43 AM
export path issues probably due to installation part in Compiler.app:
    cd ~
    echo 'export PATH=~/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH' >> .profile
    source .profile
    cd magic-lantern
    hg update qemu -C
    cd contrib/qemu/
    ./install.sh


dfort made a .profile which sends export path there. Not sure if that is being used in terminal. Will check. It also appends the path so every time installing qemu it gets added to a new line. Will look over that one too.

brew install gdb is at version 8.1 atm.
/usr/local/cellar/gdb might not be where we want it though?

Native gdb mac OS sierra is already on v8:
Last login: Thu May 31 10:14:30 on ttys001
dans-MacBook-Pro:~ dan$ arm-none-eabi-gdb
GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git


Ok, the issue is that .bash.profile will run first and leave .profile alone after this. By adding the export path to .bash_profile instead the export path was noe working. Will change the install routine in Compiler.app.

Of course this has to change again if compiling version 8  :P

Fixes added:
    cd ~
    if ! grep 'export PATH=~/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH' <<< $(cat .bash_profile)
    then
    echo 'export PATH=~/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH' >> .bash_profile
    fi
    source .bash_profile
    cd magic-lantern
    hg update qemu -C
    cd contrib/qemu/
    ./install.sh
Title: Re: Canon 80D
Post by: kotik on May 31, 2018, 01:01:28 PM
Still learning, trying examples etc.
After this command line and (partially?) output the Terminal locks up.
./run_canon_fw.sh 80D,firmware="boot=0" -d debugmsg 2>&1 | grep -E --text Notify.*Cur
[        init:fe0dc20d ] (00:03) [SEQ] NotifyComplete (Cur = 0, 0x2018000, Flag = 0x10000)
[      SFRead:fe0dc20d ] (00:03) [SEQ] NotifyComplete (Cur = 0, 0x2008000, Flag = 0x8000)
[     RomRead:fe0dc20d ] (00:03) [SEQ] NotifyComplete (Cur = 0, 0x2000000, Flag = 0x2000000)
[    PowerMgr:fe0dc20d ] (00:03) [SEQ] NotifyComplete (Cur = 1, 0x2, Flag = 0x2)
[     Startup:fe0dc20d ] (00:03) [SEQ] NotifyComplete (Cur = 2, 0x20420010, Flag = 0x20000000)
[     FileMgr:fe0dc20d ] (00:03) [SEQ] NotifyComplete (Cur = 2, 0x420010, Flag = 0x10)
[     FileMgr:fe0dc20d ] (00:03) [SEQ] NotifyComplete (Cur = 2, 0x420000, Flag = 0x400000)


Learned from Danne that '|&' should be altered into the older '2>&1 |'. Otherwise you get an error.
-bash: syntax error near unexpected token `&'
Title: Re: Canon 80D
Post by: Danne on May 31, 2018, 01:13:24 PM
Bash 3 is default, |& is from bash 4.


Nice(100D):
(https://s15.postimg.cc/sxaa2s48r/Screen_Shot_2018-05-31_at_13.45.01.png_500px.jpg)

Not knowing too much here but is it valid to run gdb on native mac version? I mean why install it if already version 8?
gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.1.0 (clang-802.0.38)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


Edit: added check for native gcc 8:
    cd ~
#check for native gcc version(if less than version 8 use ongoing version)
   gcc=$(echo $(gcc --version | tail -n +1 | head -1 | cut -d ' ' -f4 | cut -d '.' -f1))
   if (( $gcc > 8))
    then
     if ! grep 'export PATH=~/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH' <<< $(cat .bash_profile)
     then
     echo 'export PATH=~/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH' >> .bash_profile
     source .bash_profile
     fi
   fi
    cd magic-lantern
    hg update qemu -C
    cd contrib/qemu/
    ./install.sh
Title: Re: Canon 80D
Post by: kotik on May 31, 2018, 05:01:34 PM
@Danne
On my iMac: version 9.1.0

gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin


Installed bash 4
$ bash --version
3.2.57(1)-release
brew install bash
sudo chsh -s /usr/local/bin/bash

bash --version
GNU bash, versie 4.4.19(1)-release (x86_64-apple-darwin17.3.0)
Copyright (C) 2016 Free Software Foundation, Inc.


Still getting:-bash: syntax error near unexpected token `&'

Danne suggested to skip the '&' altogether and now I do get a complete list of debug messages.
./run_canon_fw.sh 80D,firmware="boot=0" -d debugmsg | grep -E --text Notify.*Cur
...
[DM] FROM Write Complete!!!
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 0/2)


But the terminal locks up again!
Title: Re: Canon 80D
Post by: Danne on May 31, 2018, 05:40:20 PM
If running the qemu installer on that machine the script will skip .bash_profile as it looks now. Should work. At least with dbg...
Title: Re: Canon 80D
Post by: a1ex on May 31, 2018, 06:42:59 PM
@Danne: you don't need to run native GDB (that's used to debug host programs; in your case, Mac programs). You need to run arm-none-eabi-gdb. Version 8.0.50.20171008-git is known not to work (https://www.magiclantern.fm/forum/index.php?topic=2864.msg200882#msg200882), version 8.1 is known to work (https://www.magiclantern.fm/forum/index.php?topic=2864.msg200989#msg200989). I did not test intermediate versions.

There is a reason why the user has to type that PATH command. A subshell cannot change environment variables of the parent shell. Don't hide it.

No idea what to do about terminal lock-ups (aka problems from 1998 (https://www.magiclantern.fm/forum/index.php?topic=2864.msg201023#msg201023)). Run Linux in a VM?
Title: Re: Canon 80D
Post by: OlRivrRat on May 31, 2018, 06:54:08 PM
                     @Kotic

           I spend probably 99% of my Computer Time in 10.6.8 as there is some functionality that I have grown

accustomed to that has gone away in newer OSs. When I need to use a newer OS I use 10.11.6.
Title: Re: Canon 80D
Post by: kotik on May 31, 2018, 08:59:16 PM
@a1ex

I suspect the problem lies within Qemu.
If I press C to "open" the card door => also clean shutdown within Magic Lantern Rescue
the terminal locks up.

system_powerdown --> No response!

@OlRivrRat

Maybe someone here can confirm that your problems with ML could be related with the older MacOSX El Capitan.
Title: Re: Canon 80D
Post by: Danne on May 31, 2018, 09:05:22 PM
Quote from: a1ex on May 31, 2018, 06:42:59 PM
@Danne: you don't need to run native GDB (that's used to debug host programs; in your case, Mac programs). You need to run arm-none-eabi-gdb. Version 8.0.50.20171008-git is known not to work (https://www.magiclantern.fm/forum/index.php?topic=2864.msg200882#msg200882), version 8.1 is known to work (https://www.magiclantern.fm/forum/index.php?topic=2864.msg200989#msg200989). I did not test intermediate versions.

There is a reason why the user has to type that PATH command. A subshell cannot change environment variables of the parent shell. Don't hide it.

No idea what to do about terminal lock-ups (aka problems from 1998 (https://www.magiclantern.fm/forum/index.php?topic=2864.msg201023#msg201023)). Run Linux in a VM?
Ok, thanks.
Back to the drawing board...
Title: Re: Canon 80D
Post by: OlRivrRat on May 31, 2018, 10:29:12 PM
                     @Kotik

           Back when Switch came on scene I asked Danne if it would run in 10.11.6 & was assured that it would &

it does, Don't recall if I asked Him about Compiler but it does seem to work OK when I do things Correctly.

           I'm just pretty much a GUI kind of user so stumble a bunch in Terminal >

Might say I have a Terminal Illness, I'm > Terminally Not Savvy!
Title: Re: Canon 80D
Post by: kotik on May 31, 2018, 11:38:43 PM
@a1ex

Did the full install of the Mac sticky tweet.
Got the same result as with the Compiler.app.
If I press 'C' to "open" the card door => also clean shutdown within Magic Lantern Rescue,
or type 'system_powerdown' there is no response at all.

When I close the Qemu window:
iMac-27:qemu-eos $ c
-bash: c: command not found

And I'm able to use the same Terminal window as usual.
Title: Re: Canon 80D
Post by: a1ex on June 01, 2018, 08:14:31 AM
Sounds about right. The keys are not yet handled on DIGIC 6, as the emulation doesn't reach the GUI. This shutdown method applies to models where the GUI works; it depends on DryOS and the GUI tasks being alive to handle the shutdown events.
Title: Re: Canon 80D
Post by: emklap on June 01, 2018, 12:21:00 PM
Great to see some progress :-)

I found some time and have created new dumps on my camera  again, just for  fun. (80D / 1/.02) .Any interest in the files ROM1.BIN and SFDATA.BIN?

By the way, I performed 2 attempts on two SD cards. The MD5's of SFDATA is matching, the ones for ROM1 are not.

(https://thumb.ibb.co/egBLky/IMG_1135.jpg) (https://ibb.co/egBLky)

Title: Re: Canon 80D
Post by: a1ex on June 01, 2018, 12:39:05 PM
Looks good :)

Please find the updated ROM dumper, with serial flash support:

DMPF_80D.FIR (https://a1ex.magiclantern.fm/bleeding-edge/80D/DMPF_80D.FIR)

Outputs ROM1.BIN (bootloader + main firmware) and SFDATA.BIN (serial flash contents).
Codebase: portable ROM dumper (https://www.magiclantern.fm/forum/index.php?topic=16534.0) (check for background info and requirements / limitations).
To run FIR files, you do not need the boot flag enabled; just copy the FIR to a formatted card (not bootable) and run Firmware Update.

Next steps:
- you may use this ROM dump for emulation (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst), firmware (https://www.magiclantern.fm/forum/index.php?topic=6785.msg187436#msg187436) analysis (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst#rst-header-initial-firmware-analysis), finding stubs (http://www.magiclantern.fm/forum/index.php?topic=12177.0) etc
- to run your code on the camera (autoexec.bin files, e.g. if you compile from source (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper)), you need to:
  - enable the boot flag (https://www.magiclantern.fm/forum/index.php?topic=17360.msg189646#msg189646) in the camera
  - make your card bootable (EosCard, MacBoot or make_bootable.sh/py (https://bitbucket.org/hudson/magic-lantern/src/unified/contrib/make-bootable/)).

Please check whether it works and produces valid files (just in case; it's the same code as above).
Title: Re: Canon 80D
Post by: emklap on June 01, 2018, 03:47:21 PM
Tested this new dumper, manually executed from 2GB card.  The files looks fine to me, 32 MB & 8 MB with what looks to me read data.
Both BIN files contain data; SFDATA md5 matches previous ones, ROM1 md5 not.


(https://thumb.ibb.co/miNo7d/Untitled.png) (https://ibb.co/miNo7d)


2nd attempt on 128MB card + autoexecute.bin.Now background is normal (black) again.
New MD5 for ROM1.bin again, md5 SFDATA unchanged.

(https://thumb.ibb.co/maDWAy/IMG_1138.jpg) (https://ibb.co/maDWAy)
Title: Re: Canon 80D
Post by: a1ex on June 01, 2018, 04:42:58 PM
That means, the caching issues are not fully solved yet. Feel free to look into it - source code is in the recovery branch. Refer to 5DS experiments (https://bitbucket.org/hudson/magic-lantern/commits/branch/5Ds_experiments) as well. Keep in mind the issue is not deterministic - first step would be to find out how many start-up attempts are required to get at least one bad screen (rough guess: 10? 50?)

I'm unable to make further progress on this issue, as it requires trial and error with a DIGIC 6 camera in one's hands, and a large number of test runs to confirm the issue was, indeed, solved.
Title: Re: Canon 80D
Post by: OlRivrRat on June 01, 2018, 06:22:33 PM
Attempting to Run this

https://a1ex.magiclantern.fm/bleeding-edge/80D/DMPF_80D.FIR

on 258MB SD on My 80D causes Soft Brick.
Title: Re: Canon 80D
Post by: a1ex on June 01, 2018, 07:55:59 PM
Nothing printed on the screen? Repeatable? I find it unlikely to work only for some users, but not for others. Keep in mind the color palette issue is not deterministic (expect anything, not just red and black).




Updated the logging experiments to capture the entire MPU communication (previous logs were incomplete). I'm interested in the following logs:

- with latest changeset (1985d10): plain startup logs in regular photo mode, without LiveView (a few different logs, as the startup process is not deterministic)
- with previous changeset (22476f9): one plain startup log in regular photo mode
- if the above won't work, narrow down by trying older changesets

I've tested the logging code in QEMU, but that doesn't guarantee it will work on actual hardware.

Caveat: the latest logging code will create files named DEBUGMSG.LOG (unnumbered). You will need to either change their name or place them into folders.

Tip: you can debug this code in the emulator by compiling with:

make clean && make install_qemu ML_MODULES= CONFIG_QEMU=y


You'll get the "qprintf" messages on the QEMU console. However, the binary compiled that way won't work on the camera; use this for testing on real hardware:

make clean && make install ML_MODULES=
Title: Re: Canon 80D
Post by: sombree on June 01, 2018, 09:45:02 PM
With 1985d10 as last changeset:
- camera boots up
- DEBUGMSG.LOG is created
- logs (https://drive.google.com/open?id=1OEA7wfJ8XnJnmTisyqBnLp2ylYhFWUlV) - 1 to 3 were taken without lens; 4 to 6 - with lens attached

With 22476f9 as last changeset:
- camera boots up with Err70 but doesn't lock up - I can turn it off with a switch

With 4a8d74a as last changeset:
- camera boots up with Err70 but doesn't lock up - I can turn it off with a switch

With b35a216 as last changeset:
- camera boots up
- DEBUGMSG.LOG is created
- log (https://drive.google.com/open?id=12ffoUem2TGR6jzzwVMkQMwtbwV2vm1CT)
Title: Re: Canon 80D
Post by: a1ex on June 01, 2018, 10:05:40 PM
The first logs (last changeset) look good. I can imagine why 22476f9 would give error (too many messages coming from interrupts -> important interrupts might get delayed). However, I'm unable to explain why 4a8d74a would fail, while b35a216 would work - the only difference is what gets printed in the task name field.

Can you double-check 4a8d74a? Does it save a log, even if the error message appears? ERR70 is an assertion somewhere in DryOS (thousands of different conditions could cause this), but DryOS continues to runs after that and ML can save files (at least on earlier models).

If 4a8d74a is really causing ERR70 (which I doubt, but who knows), can you try to get a log from 22476f9 with 4a8d74a reverted? That is:

hg up --clean 22476f9
hg backout --no-commit 4a8d74a


Here's the annotated (https://www.magiclantern.fm/forum/index.php?topic=17596.msg198329#msg198329) MPU conversation from DEBUGMSG4.LOG:

mpu_send(06 04 02 00 00 00)                                        ; Init group
mpu_recv(06 05 01 00 03 00)                                        ; PROP_SHOOTING_MODE
mpu_recv(06 05 01 4f 00 00)                                        ; PROP_FIXED_MOVIE
mpu_recv(06 05 01 99 00 00)                                        ; PROP 80040057
mpu_recv(06 05 01 9a 00 00)                                        ; PROP 80040058
mpu_recv(06 05 01 06 18 00)                                        ; PROP_APERTURE
mpu_recv(06 05 01 3f 00 00)                                        ; PROP_FLASH_ENABLE
mpu_send(08 06 01 a7 00 01 00 00)                                  ; ???
mpu_send(08 06 01 a7 00 01 00 00)                                  ; ???
mpu_recv(30 2f 02 0d 03 03 00 00 01 00 00 00 00 01 00 01 00 01 02 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 01 00 01 00 0f 00 07 01 00 00 00 00) ; Card group
mpu_recv(5a 59 02 0f 01 02 00 08 01 01 00 00 00 00 00 00 00 00 00 00 17 6a 00 00 00 0f 00 00 00 00 00 00 00 03 00 00 00 01 00 00 00 00 00 02 03 01 01 00 00 00 00 00 00 00 00 00 03 01 2c 00 00 0b b5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; Movie group
mpu_recv(48 46 02 10 00 00 00 00 00 00 00 00 00 00 ff 03 00 00 00 f6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ff 00 00 02 01 01 00 03 00 01 00 04 00 00 01 05 00 01 01 00 00 00 00 47 47 00 02 00 00 00 00 00 00 00 00 00) ; AF group
mpu_send(06 04 0e 4c 00 00)                                        ; ???
mpu_send(24 22 0e 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; ???
mpu_send(2a 28 0e 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; ???
mpu_send(0c 0a 0e 2c 00 00 00 00 00 00 00 00)                      ; ???
mpu_send(06 05 0e 30 00 00)                                        ; ???
mpu_send(06 04 0e 31 00 00)                                        ; ???
mpu_send(06 04 0e 35 00 00)                                        ; ???
mpu_send(0c 0a 0e 38 00 00 00 00 00 00 00 00)                      ; ???
mpu_send(46 44 0e 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; ???
mpu_send(70 6f 0e 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; ???
mpu_send(12 10 0e 3d 00 00 00 00 00 00 00 00 00 00 00 00 00 00)    ; ???
mpu_recv(42 40 02 11 00 17 00 00 00 00 17 00 ff ff ff ff ff f8 00 00 00 ff ff ff ff ff f8 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 ff ff ff ff ff f8 00 00 00 00 00 00 00 00 00 00 18 00 00 00 00 00) ; AF2 group
mpu_recv(06 05 01 af 02 00)                                        ; ???
mpu_recv(10 0e 02 05 07 00 00 00 01 00 00 03 05 03 00 00)          ; PROP_CFN_1
mpu_recv(2e 2c 02 07 11 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 03 08 47 03 0f 00 11 10 03 00 00 00 f6 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP_CFN_3
mpu_send(12 10 0e 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00)    ; ???
mpu_send(26 24 0e 47 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; ???
mpu_recv(1e 1d 02 08 05 c3 00 00 00 14 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP_CFN_4
mpu_recv(06 05 01 95 02 00)                                        ; PROP 8004005C
mpu_recv(2e 2c 02 07 11 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 03 08 47 03 0f 00 11 10 03 00 00 00 f6 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP_CFN_3
mpu_send(0a 08 0e 3f fe ff ff ea 00 00)                            ; ???
mpu_send(08 06 0e 40 fe ff 00 00)                                  ; ???
mpu_send(06 05 0e 49 fe 00)                                        ; ???
mpu_send(06 05 0e 4b fe 00)                                        ; ???
mpu_recv(8e 8d 02 0e 03 03 03 04 00 00 00 5d 00 00 00 00 0e 10 00 00 00 00 21 00 00 01 03 00 00 06 04 00 00 01 00 01 00 00 03 84 00 65 18 00 00 00 00 00 00 00 00 01 03 00 00 83 48 00 00 70 48 80 48 80 48 83 48 58 48 90 01 00 03 03 01 00 01 00 00 03 00 00 00 00 01) ; Mode group
mpu_recv(06 05 03 37 00 00)                                        ; PROP_MIRROR_DOWN_IN_MOVIE_MODE
mpu_recv(0a 08 03 2f 00 40 00 00 00 00)                            ; PROP_SPECIAL_OPTION
mpu_recv(06 05 03 20 01 00)                                        ; PROP_STARTUP_CONDITION
mpu_recv(06 05 03 76 00 00)                                        ; ???
mpu_recv(08 06 01 a7 00 01 00 00)                                  ; ???
mpu_recv(64 62 02 12 01 10 50 00 c6 00 32 00 32 81 04 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 43 43 43 7e 7e 7e 43 43 01 70 01 70 01 70 00 96 00 96 00 96) ; Lens group
mpu_recv(06 05 03 35 01 00)                                        ; PROP_BATTERY_REPORT_COUNTER
mpu_recv(1c 1b 03 1d 35 02 00 00 00 e7 00 4c 50 2d 45 36 4e 00 00 00 00 01 00 00 65 16 15 00) ; PROP_BATTERY_REPORT
mpu_recv(06 04 03 36 00 00)                                        ; PROP_BATTERY_REPORT_FINISHED
mpu_recv(08 07 03 7e 91 99 ff 00)                                  ; ???
mpu_recv(08 06 01 a7 00 00 00 00)                                  ; ???
mpu_recv(06 05 04 06 05 00)                                        ; PROP_DEFAULT_LV_MANIP
mpu_recv(0e 0d 04 30 00 00 00 00 00 00 00 00 00 00)                ; ???
mpu_recv(06 05 01 48 01 00)                                        ; PROP_LIVE_VIEW_MOVIE_SELECT
mpu_recv(06 05 01 4b 01 00)                                        ; PROP_LIVE_VIEW_VIEWTYPE_SELECT
mpu_recv(06 05 01 49 01 00)                                        ; PROP_LIVE_VIEW_AF_SYSTEM
mpu_recv(06 05 01 12 00 00)                                        ; PROP_WBB_GM
mpu_recv(06 05 01 13 00 00)                                        ; PROP_WBB_BA
mpu_recv(10 0e 01 8f 00 00 00 00 00 00 00 00 00 00 00 00)          ; PROP_LV_CFILTER
mpu_recv(0e 0c 01 b1 00 00 00 00 00 00 00 00 00 00)                ; ???
mpu_recv(06 05 01 03 04 00)                                        ; PROP_DRIVE_MODE
mpu_recv(08 06 01 a7 00 01 00 00)                                  ; ???
mpu_recv(08 06 01 a7 00 00 00 00)                                  ; ???
mpu_recv(06 05 04 29 01 00)                                        ; ???
mpu_recv(06 05 01 01 03 01)                                        ; PROP_SHOOTING_MODE_CUSTOM
mpu_recv(06 05 01 2e 01 00)                                        ; PROP_SAVE_MODE
mpu_recv(46 44 09 00 00 c6 00 32 00 32 81 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 10 50 49 02 59 88 88 00 88 88 00 32 00 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP_LV_LENS
mpu_recv(06 05 01 2c 02 00)                                        ; PROP_CURRENT_MEDIA
mpu_recv(12 10 03 00 9d 00 00 84 0b 00 00 00 00 00 00 00 00 00)    ; PROP 80030000
mpu_recv(06 05 03 23 11 00)                                        ; ???
mpu_recv(16 15 03 24 45 46 35 30 6d 6d 20 66 2f 31 2e 34 20 55 53 4d 00 00) ; PROP_LENS_NAME
mpu_recv(06 05 03 04 00 00)                                        ; PROP_POWER_KIND
mpu_recv(06 05 03 05 04 00)                                        ; PROP_POWER_LEVEL
mpu_recv(06 04 03 25 00 00)                                        ; ???
mpu_recv(06 05 01 3d 00 00)                                        ; PROP_TEMP_STATUS
mpu_recv(06 05 03 0d 00 00)                                        ; PROP_CARD2_RECORD
mpu_recv(06 05 03 0c 00 00)                                        ; PROP_CARD1_RECORD
mpu_recv(30 2e 03 15 01 10 50 00 c6 00 32 00 32 81 04 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP_LENS
mpu_recv(24 22 03 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP 8003003C
mpu_recv(06 05 03 17 9c 00)                                        ; PROP_EFIC_TEMP
mpu_recv(06 05 03 6c 9b 00)                                        ; PROP 80030073
mpu_recv(30 2e 03 15 01 10 50 00 c6 00 32 00 32 81 04 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP_LENS
mpu_recv(24 22 03 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) ; PROP 8003003C
mpu_recv(0a 09 01 55 00 00 03 00 00 01)                            ; PROP_MULTIPLE_EXPOSURE_SETTING
mpu_recv(0a 09 01 70 00 00 01 00 00 01)                            ; PROP_HDR_SETTING
mpu_recv(0a 08 01 85 00 00 00 01 01 00)                            ; PROP_GIS_SETTING
mpu_recv(0c 0a 0e 2d 65 00 00 04 50 01 00 00)                      ; ???
mpu_recv(06 05 01 58 00 00)                                        ; PROP_VIDEOSNAP_MODE
mpu_recv(06 05 01 58 00 00)                                        ; PROP_VIDEOSNAP_MODE
mpu_recv(06 05 01 58 00 00)                                        ; PROP_VIDEOSNAP_MODE
mpu_recv(06 05 01 58 00 00)                                        ; PROP_VIDEOSNAP_MODE
mpu_recv(06 05 03 5c 00 00)                                        ; PROP 80030061
mpu_recv(06 05 01 59 01 00)                                        ; PROP_MOVIE_SERVO_AF
mpu_recv(06 05 01 59 01 00)                                        ; PROP_MOVIE_SERVO_AF
mpu_send(0a 08 09 24 00 00 00 00 00 00)                            ; ???
mpu_send(08 07 03 6a 00 02 00 00)                                  ; ???
mpu_send(0a 08 03 06 00 00 00 00 00 00)                            ; PROP_AVAIL_SHOT
mpu_send(06 04 03 10 00 00)                                        ; PROP 80030008
mpu_send(06 05 03 07 ff 00)                                        ; PROP_BURST_COUNT
mpu_send(06 05 01 2e 01 00)                                        ; PROP_SAVE_MODE
mpu_send(0a 08 03 0b 00 00 00 00 00 00)                            ; PROP 80030007
mpu_send(06 05 03 19 01 00)                                        ; PROP_TFT_STATUS
mpu_send(06 05 01 56 00 00)                                        ; ???
mpu_send(06 05 04 0e 01 00)                                        ; PROP 8002000D
mpu_send(06 05 03 40 00 00)                                        ; PROP 80030040
mpu_send(0c 0b 03 53 03 00 48 81 81 00 00 00)                      ; PROP 80030058
mpu_send(0c 0b 03 53 03 00 48 81 81 00 00 00)                      ; PROP 80030058
mpu_send(08 06 01 2a 05 68 00 00)                                  ; PROP_CARD2_FILE_NUMBER
mpu_send(06 05 03 07 14 00)                                        ; PROP_BURST_COUNT
mpu_send(0a 08 03 06 00 00 00 ea 00 00)                            ; PROP_AVAIL_SHOT
mpu_send(06 05 03 11 01 00)                                        ; PROP_ICU_AUTO_POWEROFF
mpu_send(06 05 02 0a 00 00)                                        ; PROP_PERMIT_ICU_EVENT
mpu_send(06 05 03 0d 00 00)                                        ; PROP_CARD2_RECORD
mpu_send(06 05 03 0c 00 00)                                        ; PROP_CARD1_RECORD
mpu_recv(06 05 01 58 00 00)                                        ; PROP_VIDEOSNAP_MODE
mpu_recv(06 05 01 58 00 00)                                        ; PROP_VIDEOSNAP_MODE
Title: Re: Canon 80D
Post by: sombree on June 01, 2018, 10:28:52 PM
I double-checked 4a8d74a and still no-go - camera gives Err70. Same thing happens with 22476f9 (as latest) and 4a8d74a reverted. Again, camera doesn't lock up - it reacts to pushing trigger button or on/off switch.
Btw. I tried extract_init_spells.py, rebuild qemu and got this log (https://hastebin.com/diyequpehe.go) from qemu. It seems that emulation goes little further.
Title: Re: Canon 80D
Post by: OlRivrRat on June 01, 2018, 10:52:32 PM
                     @Alex

       "Nothing printed on the screen? Repeatable?"

Just 1 Flash of LED then Dead Cam, Batt' Removal Necessary. Tried 6 Times, all same.

   The Portable Rescue & Your 29May Rom + SFData Dumper autoexe still work just fine.
Title: Re: Canon 80D
Post by: a1ex on June 02, 2018, 09:37:55 AM
Quote from: sombree on June 01, 2018, 10:28:52 PM
It seems that emulation goes little further.

Only seems to - with the new MPU messages, it no longer initializes the SD card (no more messages from CSMgrTask). I have a feeling some of the MPU messages were missed this time, too.

Can you try the latest changeset? (same sequence as before).

Quote from: OlRivrRat on June 01, 2018, 10:52:32 PM
Just 1 Flash of LED then Dead Cam, Batt' Removal Necessary. Tried 6 Times, all same.

Best guess: bootable card without autoexec.bin (in this case, the FIR is not auto-loaded; the camera enters factory menu, but you need a hardware interface to see the messages). Updated the instructions (https://www.magiclantern.fm/forum/index.php?topic=17360.msg202235#msg202235) to address this. The FIR file is meant for first-time contributors, who don't have the boot flag enabled yet. You can start it from a fresh card (format, copy the FIR and run Firmware Update from the menu).
Title: Re: Canon 80D
Post by: sombree on June 02, 2018, 01:08:40 PM
e833d47:
- camera boots up
- DEBUGMSG.LOG is created
- logs (https://drive.google.com/open?id=1EVItmQNCjwkEKmi13FB2LsyIsaqadxCd): 1 and 2 were taken without lens; 3 and 4 - with lens attached
Title: Re: Canon 80D
Post by: a1ex on June 02, 2018, 03:58:18 PM
Graphical view of the first log:

DEBUGMSG1.svg (https://a1ex.magiclantern.fm/bleeding-edge/80D/DEBUGMSG1.svg)

It's not 100% clear which mpu_recv is a reply to which mpu_send, so we may need to find a way to delay the mpu_send calls (this was the trick I've used on previous models to figure out the dependencies between MPU messages).
Title: Re: Canon 80D
Post by: sombree on June 02, 2018, 04:17:16 PM
You mean something like this (https://bitbucket.org/hudson/magic-lantern/commits/83be266e66f00480a6b9eee47ebc60010ce3b7e2)?
Title: Re: Canon 80D
Post by: a1ex on June 02, 2018, 05:30:25 PM
Yeah, same effect, except this time we are not able to patch ROM code. Figuring out how to do that would be a very useful contribution.

The technique used by io_trace (https://bitbucket.org/hudson/magic-lantern/pull-requests/900/mmio-tracing-backend-insanely-powerful) might be useful (idea: set up a memory protection region over the ROM that would redirect all reads and executions to RAM). Porting io_trace is also going to be extremely useful, but debugging is tedious (expect lots of crashes and trial and error).
Title: Re: Canon 80D
Post by: sombree on June 02, 2018, 06:02:40 PM
Sadly, it's way beyond my coding skills  ???
Title: Re: Canon 80D
Post by: a1ex on June 02, 2018, 07:33:40 PM
Don't worry, there are knowledgeable ARM folks around (some possibly following this thread). I'm going to try it as well.

Meanwhile, notice the log files are much smaller than buffer size, but there's some more going on during startup. Can you try to log the entire process?

Start by increasing the delay in init_task (5 seconds should be enough). If the log gets full, increase the buffer size as well (currently 256K, you can try 512K or maybe more).
Title: Re: Canon 80D
Post by: sombree on June 02, 2018, 08:26:29 PM
Logs (https://drive.google.com/open?id=1qFsDOAVc5qtrxhvA7hK7be8_tUVVek-0) with 5 seconds delay (1 is without lens, 2 is with lens attached). Changing buf[256 * 1024] to buf[512 * 1024] causes camera to lock up right after closing sdcard slot.
Edit: logs were taken with both wireless communication (wifi/nfc) and touch screen turned off.
Title: Re: Canon 80D
Post by: a1ex on June 02, 2018, 08:42:02 PM
If log size is near 100K, there's no point in increasing the log size (256K > 100K). I thought they are going to be larger.

Another issue: the DIGIC clock (0xD400000C) appears to have more than 20 valid bits. Questions:
- does the old timer register (0xC0242014) still work? (try it in log.c instead of 0xD400000C)
- try "%08X>" for printing the timestamps (that way, we'll see how many bits are actually used); try this one with both registers
Title: Re: Canon 80D
Post by: sombree on June 02, 2018, 08:57:10 PM
Link (https://drive.google.com/open?id=1dqyMbyktjsPwJUFnAakLcGz-XxLtKume)
1 - 0xD400000C and %08X>
2 - 0xC0242014 and %08X>
Does it mean that old timer register work?

Edit: Link updated (now from latest changeset).
Title: Re: Canon 80D
Post by: a1ex on June 02, 2018, 09:12:55 PM
Right; the old register still works as a 20-bit timer; the new one has at least 21 bits. For some reason, last value is 1498313 microseconds (nearly 1.5 seconds), while on previous logs captured with msleep(1000), last value is 999385 microseconds. That's unusual - older models keep printing messages while the main info screen (with shutter, aperture and other controls) is displayed.

Maybe you can get some more messages by starting in LiveView?
Title: Re: Canon 80D
Post by: sombree on June 02, 2018, 09:27:07 PM
Sorry, I forgot to mention - thats because I've changed init delay to 1.5 seconds.
Logs (https://drive.google.com/open?id=1-Sdq63rZZUxkuC4vA61qb9DIc-dcHkKQ):
1 - 0xD400000C and 5 sec delay
2 - 0xC0242014 and 5 sec delay
Title: Re: Canon 80D
Post by: a1ex on June 02, 2018, 09:33:18 PM
OK, that makes sense. Can you redo a regular startup with 5 seconds delay? Reason: timestamps printed with %05X are unreadable after the overflow.
Title: Re: Canon 80D
Post by: sombree on June 02, 2018, 09:40:00 PM
Sure - link (https://drive.google.com/open?id=14af4YMLj9SJ6YcxEBczrJoObIe1bpVMN).
1 - no lens,
2 - with lens,
both with 0xD400000C.
Title: Re: Canon 80D
Post by: a1ex on June 02, 2018, 09:52:06 PM
Looks good: DEBUGMSG1-5s.svg (https://a1ex.magiclantern.fm/bleeding-edge/80D/DEBUGMSG1-5s.svg)

You could also try to find out the number of bits used by 0xD400000C, but that may take a while. The procedure is simple - increase the delay and write down the maximum value. A 16-second delay would cover 16 bits. A 5-minute delay would cover 29 bits. If the timer has 32 bits, it will wrap around after 1 hour and 12 minutes.
Title: Re: Canon 80D
Post by: sombree on June 03, 2018, 10:36:02 AM
I guess timer has 32 bits - it wrapped shortly after 71 minutes - log (https://drive.google.com/open?id=1V7JBX_-sctqbRBFStHRQqON0Qt5muUmH). Buffer size was set to 320K, init delay to 4380000 (73 minutes).
Title: Re: Canon 80D
Post by: a1ex on June 03, 2018, 11:14:03 AM
Nice, finally a 32-bit microsecond timer :D

Found something interesting in this thesis (http://tuprints.ulb.tu-darmstadt.de/7243/7/dissertation_2018_matthias_thomas_schulz.pdf), page 59: they use the same CPU core (Cortex R4). They mention some debug registers (DBGDRAR and others); see Cortex R4 TRM section 12.3.3 (Debug register interface - Coprocessor registers summary). I remember some folks already tried it without much success, but I don't remember seeing the test code.

Added these registers to the "cpuinfo" section on the recovery branch. Compile with CONFIG_BOOT_CPUINFO=y CONFIG_BOOT_DUMPER=y . Will it work or will it lock up?

If it works, uncomment the DBGDSCR register as well. I've commented it out just in case (QEMU printed some different name).
Title: Re: Canon 80D
Post by: sombree on June 03, 2018, 11:42:32 AM
Link (https://drive.google.com/open?id=1RkrMMtgaWMf31K40pgCg5kyDFOv9Q3q3)
1 - without DBGDSCR
2 - with DBGDSCR
In all cases I removed disable_caches_region1_ram_d6() from reboot.c to speed up dumping process.

Edit:
3 (https://drive.google.com/open?id=1_BwNLoN1BIeU1ImNV1O3qe8oJCDKlWdb) - with latest changeset (237777f)
4 (https://drive.google.com/open?id=1RQwpuXgldYMXk2zvURN4XR7uOoBUb4aV) - with latest changeset and caches disabled
Title: Re: Canon 80D
Post by: ariznaf on June 18, 2018, 04:36:16 PM
Wowww

Great to see active developement in this model, with several of you working hard.
Thank you all for your efforts.
I will wait for the first working version to see if i can help with alpha testing.
You are great guys.
Title: Re: Canon 80D
Post by: whoreable on July 03, 2018, 10:07:50 AM
Keep going at it boys! were rooting for you  :o :o :o  :-*
Title: Re: Canon 80D
Post by: a1ex on July 03, 2018, 11:00:15 AM
Why don't you help us?

All you need is some courage to start following the notes. Browse the docs. Start poking around and write down what you discover. That's pretty much it; we don't really know what we are doing either.

I've just got a Raspberry Pi Zero (ARMv6) to try the above debug registers, but didn't power it on yet. You've got the real hardware; maybe you can read the thesis linked earlier and try to reproduce some of the results. Or maybe you can try something easier, like playing around with the logging code. Or try to figure out how to print some stuff on the screen. Watch this video (https://www.youtube.com/watch?v=GX8-K4TssjY) for a nice intro. Just some ideas.
Title: Re: Canon 80D
Post by: k!r+ on July 05, 2018, 03:29:57 AM
Hi all.

Been watching and playing for a while with some others who are studying software development at uni and we would like to get ML on the 80D as a fun but challenging project. We've taken the 80D apart and posted some photos of the main board. If we missed something let me know as there are a few more we took, or we could take it apart again if we really need to (may have to if we need to find anything out about the NFC chip).

Hopefully these photo's (https://magiclantern.wikia.com/wiki/Circuit_boards) will help with something.
Title: Re: Canon 80D
Post by: a1ex on July 05, 2018, 08:52:06 AM
Quote from: k!r+ on July 05, 2018, 03:29:57 AM
Hopefully these photo's (https://magiclantern.wikia.com/wiki/Circuit_boards) will help with something.

Very nice pictures, thanks!

If anyone identifies some circuits, you are welcome to edit the Datasheets (http://magiclantern.wikia.com/wiki/Datasheets) page. I'll start with the most obvious ones:

- AD80334 BBCZ (ADTG (http://magiclantern.wikia.com/wiki/ADTG), likely custom chip designed for Canon by Analog Devices)
- Elpida B8164B4PR (8Gb SDRAM; this camera has 1GB RAM (https://www.magiclantern.fm/forum/index.php?topic=5071.msg169727#msg169727))
- F74965A: MPU (https://www.magiclantern.fm/forum/index.php?topic=17596.msg199973#msg199973), same as 5D3
Title: Re: Canon 80D
Post by: Ant123 on July 05, 2018, 08:46:26 PM
According to this page (http://www.rf-china.com/n37/ad.asp)
QuoteAD80334BBCZ
4 CHANNEL, 14 bit , 50MSPS AFETG+PPP

80D sensor has no ADC onboard?
Title: Re: Canon 80D
Post by: eduperez on July 06, 2018, 09:49:32 AM
Quote from: k!r+ on July 05, 2018, 03:29:57 AM
Hopefully these photo's (https://magiclantern.wikia.com/wiki/Circuit_boards) will help with something.

Congrats on these photos, they are very clear.

I'm surprised to see that there is a button cell there, but it cannot be changed by the user...
Title: Re: Canon 80D
Post by: Faucheur on July 16, 2018, 10:43:18 AM
Quote from: eduperez on July 06, 2018, 09:49:32 AM
...

I'm surprised to see that there is a button cell there, but it cannot be changed by the user...

The MS614 is a rechargeable button cell, probably there only for timekeeping when there is no battery in the camera.
Since it's rechargeable, no need for user replacement...
Title: Re: Canon 80D
Post by: eduperez on July 17, 2018, 08:56:03 AM
Quote from: Faucheur on July 16, 2018, 10:43:18 AM
The MS614 is a rechargeable button cell, probably there only for timekeeping when there is no battery in the camera.
Since it's rechargeable, no need for user replacement...

Oh, I did not know that, thanks!
Title: Re: Canon 80D
Post by: taudris on July 19, 2018, 09:06:18 AM
Quote from: Ant123 on July 05, 2018, 08:46:26 PM
According to this page (http://www.rf-china.com/n37/ad.asp)
Quote
AD80334BBCZ
4 CHANNEL, 14 bit , 50MSPS AFETG+PPP
80D sensor has no ADC onboard?

50 MSPS is too slow for the 80D's sensor and capabilities, so it must be used for something else. 7 FPS at 25.8 MP (this is including the unexposed sensor area) is at least 181 MSPS, plus the fact that readout happens between exposures (the fastest this can be is the sync speed of 1/250sec, which at 7 FPS consumes 28ms per second).

Just a guess, but that chip could be used for the metering sensor or AF tracking.
Title: Re: Canon 80D
Post by: JosiahD on July 23, 2018, 04:04:50 AM
I know you guys are working hard thanks very much.
Is their a way can try what you have done already?
Will it support FTP to a server?
let me know if I can help.
Thank you 8)
Title: Re: Canon 80D
Post by: a1ex on July 23, 2018, 07:06:14 AM
QuoteIs their a way can try what you have done already?

Of course, just read previous posts (in particular, the April 1st "blind edition"). You will need to enable the boot flag.

Quote
Will it support FTP to a server?

Doable. None of my cameras have Wi-Fi, but Maqs documented the network interface on 6D:
http://magiclantern.wikia.com/wiki/6D/Networking

Feel free to put it to good use.
Title: Re: Canon 80D
Post by: iAndrewT on July 31, 2018, 03:46:28 PM
Quote from: a1ex on September 07, 2017, 10:00:08 PM
Disabling the boot flag is easy - I can prepare a FIR for that, if needed.

Hi,

Could we get the boot flag disable FIR please? I need to send my 80D in for service (broken autofocus) and would like my camera to be as factory as possible when I send it in (it's under warranty).

Also, what kind of reading material should I be looking for to learn ARM development and get an idea of what's going on with the development here? I've got an unused RPi 3 and all my computers currently run macOS.
Title: Re: Canon 80D
Post by: a1ex on August 01, 2018, 11:45:09 AM
Compile the recovery branch with CONFIG_BOOT_BOOTFLAG = y, from platform/portable.000, after applying the following diff:

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

@@ -1233,8 +1233,8 @@
     if (set_bootflag && set_flag_i)
     {
         /* enable the boot flag */
-        printf(" - Enabling boot flag...\n");
-        set_bootflag(1, -1);
+        printf(" - Disabling boot flag...\n");
+        set_bootflag(1, 0);
     }
}


If you prefer a ready-to-run version: BDIS_80D.FIR (https://a1ex.magiclantern.fm/bleeding-edge/80D/BDIS_80D.FIR) (tested only in QEMU).

Caveat: if things go wrong, I may not be able to run further diagnostics; disabling the boot flag removes the ability to run user code on the camera.

There are links to reading material in this very topic.
Title: Re: Canon 80D
Post by: iAndrewT on August 02, 2018, 09:44:06 AM
It worked! I'll do some research on the ARM development process over the next few weeks while my camera's in for service. I've also got a 750D so hopefully I can make myself useful for that camera too :D
Title: Re: Canon 80D
Post by: a1ex on August 02, 2018, 12:46:58 PM
Great; they are both very similar, so a low-hanging fruit would be porting the current 80D code to 750D. Expecting it to work out of the box after adjusting the stubs (http://www.magiclantern.fm/forum/index.php?topic=12177.0) (pretty much pattern matching between the two ROMs). This stage (startup code + simple experiments) can be debugged in the emulator.
Title: Re: Canon 80D
Post by: Dj4n90 on August 19, 2018, 11:55:56 PM
Hey everyone!

We've managed to get the emulation a bit further, to the point which some keys are being handled. The only ones which have visible actions are those which trigger shutdown (B and C). The other keys do appear to send MPU spells and some receive spells, however we're not able to see the effect they're having due to the lack of the GUI.

We've also run into a number of errors, which we have questions about:

ERROR [RTC] RTC_REGISTER_TIME_CORRECT ERROR 0x0 -> 0x9e
ERROR [RTC] !! RTC CHECK ERROR !!


Relevant Debug
[MPU] Received: 06 05 0e 4b fe 00  (unknown - unnamed)
[     Startup:fe5336b5 ] (00:01) [PM] Enable (ID = 3, cnt = 1/2)
[     Startup:fe19b2ec ] CreateStateObject => 83bab0 at fe19b2ec
[     Startup:fe552ae3 ] (00:01) [RTC] RTC_InitializeRTCDriver Fin
[      RTCMgr:fe552975 ] RTCMgrState: (0) --0--> (0)      fe19b62b (x=59a0a0 z=83badc t=2c)
[      RTCMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 3, cnt = 0/1)
[      RTCMgr:fe534253 ] register_interrupt(null, 0x117, 0xfe5340b5, 0x0)
[MPU] Sending : 28 26 02 07 0e 00 00 00 00 00 00 00 00 00 00 03 00 00 03 07 07 11 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  (PROP_CFN_3)
[      RTCMgr:fe533629 ] (00:01) [PM] Disable (ID = 3, cnt = 1/2)
[      RTCMgr:fe1f79dd ] (00:06) [RTC] RTC_REGISTER_TIME_CORRECT ERROR 0x0 -> 0x9e
[      RTCMgr:fe534253 ] register_interrupt(null, 0x117, 0xfe5340b5, 0x0)
[      RTCMgr:fe1f7afd ] (00:06) [RTC] !! RTC CHECK ERROR !!

[      RTCMgr:fe1f7afd ] (00:06) [RTC] !! RTC CHECK ERROR !!

[      RTCMgr:fe534253 ] register_interrupt(null, 0x117, 0xfe5340b5, 0x0)
[      RTCMgr:fe19b939 ] register_func('RTC_Prohibit', fe19ccc3, 0)
[      RTCMgr:fe19b941 ] register_func('RTC_Permit', fe19ccbf, 0)
[      RTCMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 3, cnt = 0/1)
[MPU] Sending : 06 05 03 37 00 00  (PROP_MIRROR_DOWN_IN_MOVIE_MODE)
[      RTCMgr:fe533629 ] (00:01) [PM] Disable (ID = 3, cnt = 1/2)
[      RTCMgr:fe19b949 ] register_func('RTC_CheckCharge', fe19b351, 0)
[      RTCMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 3, cnt = 0/1)
[      RTCMgr:fe19b951 ] register_func('RTC_WriteCorrectValue', fe19b337, 0)
[MPU] Sending : 0a 08 03 2f 00 40 00 00 00 00  (PROP_SPECIAL_OPTION)
[      RTCMgr:fe533629 ] (00:01) [PM] Disable (ID = 3, cnt = 1/2)
[      RTCMgr:fe19b959 ] register_func('RTC_ReadCorrectValue', fe19b321, 0)
[      RTCMgr:fe19b961 ] register_func('RTC_SaveCorrectValue', fe19b2ff, 0)
[      RTCMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 3, cnt = 0/1)


I've noticed that this error also appears in the 'Help I've bricked my camera!' error 70 posts on the forum which is making me question its actual involvement with the RTC chip. Is this an error with emulating the RTC chip or is it caused by something else breaking?
We've tried setting 'rtc_time_correct' to different values (including 0x9E) in model_list.c and through the RTC_WriteCorrectValue function in the shell, however we haven't seen anything change.

ASSERT : ./System/MariusAPI/OmarSysInfo.c, Task = RTCMgr, Line 73

Relevant Debug
[     Startup:fe14c196 ] CreateStateObject => 84a928 at fe14c196
[     Startup:fe465c77 ] task_create(ShootPreDevelop, prio=16, stack=8000, entry=fe465bdb, arg=84a954)
[ShootPreDevelop:fe14382f ] SPSState: (0) --0--> (1)      fe14c1b1 (x=84a8f8 z=0 t=0)
[ShootPreDevelop:fe14c1d1 ] (95:03) Init
[     Startup:fe0dc079 ] (00:05) [SEQ] seqEventDispatch (Startup, 3)
[      NFCMgr:fe63d8bb ] NFCMgrState: (0) --0--> (0)      fe718c5f (x=4749f0 z=0 t=0)
[     PropMgr:fe484ac9 ] PropState: (0) --3--> (0)      fe3d8305 (x=46f8f4 z=84ab38 t=14)
[      NFCMgr:fe63d8bb ] NFCMgrState: (0) --3--> (0)      fe717869 (x=4749f0 z=84ab7c t=8)
[      NFCMgr:fe71791b ] (4d:03)  PropChange:PROP_SPECIAL_OPTION ->init (0x4000)
[     PropMgr:fe484ac9 ] PropState: (0) --4--> (0)      fe3d855b (x=46f8f4 z=84ab58 t=0)
[      NFCMgr:fe63d8bb ] NFCMgrState: (0) --1--> (1)      fe71aa49 (x=4749f0 z=0 t=0)
[      NFCMgr:fe71aa53 ] register_func('nfcir', fe71a9df, 0)
[      NFCMgr:fe71aa5b ] register_func('nfciw', fe71a963, 0)
[      NFCMgr:fe71aa63 ] register_func('nfci2cchk', fe71a84f, 0)
[      NFCMgr:fe71aa6b ] register_func('nfcsread', fe71a7d9, 0)
[      NFCMgr:fe71aa73 ] register_func('nfcswrite', fe71a779, 0)
[      NFCMgr:fe71aa7b ] register_func('nfcsstatus', fe71a745, 0)
[      NFCMgr:fe71aa83 ] register_func('nfcswreg', fe71a285, 0)
[      NFCMgr:fe71aa8b ] register_func('nfcswriteb', fe71a225, 0)
[      NFCMgr:fe71aa93 ] register_func('nfcswrites', fe71a1bb, 0)
[      NFCMgr:fe71aa9b ] register_func('nfcswuriaar', fe71a115, 0)
[      NFCMgr:fe71aaa3 ] register_func('nfcswinitset', fe71a067, 0)
[      NFCMgr:fe71aaab ] register_func('nfcswempty', fe719fff, 0)
[      NFCMgr:fe71aab3 ] register_func('nfcchkWtime', fe719fbb, 0)
[      NFCMgr:fe71aabb ] register_func('nfcsetnirq', fe719a1d, 0)
[      NFCMgr:fe71aac3 ] register_func('nfcterminate', fe719a05, 0)
[      NFCMgr:fe71aacb ] register_func('nfcsetcamstate', fe7199db, 0)
[      NFCMgr:fe71aad3 ] register_func('nfccdread', fe719991, 0)
[      NFCMgr:fe71aadb ] register_func('nfccdwrite', fe7198ab, 0)
[      NFCMgr:fe71aae3 ] register_func('nfcresetcard', fe71988d, 0)
[      NFCMgr:fe71aaeb ] register_func('nfcsetwtime', fe719481, 0)
[      NFCMgr:fe71aaf3 ] register_func('nfcfreemsg', fe719465, 0)
[      NFCMgr:fe71aafb ] register_func('nfcswreg', fe71936d, 0)
[      NFCMgr:fe71ab03 ] register_func('nfcsrreg', fe719285, 0)
[      NFCMgr:fe71ab0b ] register_func('nfcchkmod', fe718e73, 0)
[      NFCMgr:fe71dadd ] register_func('nfctestferam', fe71da99, 0)
[      NFCMgr:fe533629 ] (00:01) [PM] Disable (ID = 77, cnt = 1/3)
[      NFCMgr:fe71ab37 ] (4d:03)  nfcmgrstate_Initialize:NewsDet_R Lo
[      NFCMgr:fe71aefd ] register_interrupt(NFCDET, 0x9a, 0xfe717fbd, 0x4749f0)
[      NFCMgr:fe168615 ] (00:01) [I2C] I2CD_Initialize
[      NFCMgr:fe16862f ] register_interrupt(I2C0_TIRQ, 0xdd, 0xfe167f29, 0x0)
[      NFCMgr:fe16863b ] register_interrupt(I2C0_SIRQ, 0xfd, 0xfe167fc7, 0x0)
[      NFCMgr:fe168653 ] register_interrupt(I2C1_TIRQ, 0x10d, 0xfe167f29, 0x1)
[      NFCMgr:fe168661 ] register_interrupt(I2C1_SIRQ, 0x12d, 0xfe167fc7, 0x1)
[      NFCMgr:fe168683 ] (00:01) [I2C] I2CD_Com mode[3], devAddr[0xA8]
[      NFCMgr:fe167ec7 ] (00:01) [I2C] CH1 bus ready
[      NFCMgr:fe167ec7 ] (00:01) [I2C] CH1 bus ready
[      NFCMgr:fe168465 ] (00:01) [I2C] read start condition
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=3c)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
    65:   486.400 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80040033 L:2483
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=3d)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
    66:   486.400 [PRP] PropertyList:12 Current:4
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=44)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
    83:   627.456 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80030075 L:2483
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=45)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
    84:   627.456 [PRP] PropertyList:23 Current:19
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=4a)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
    89:   636.160 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80010006 L:2483
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=4b)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
    90:   636.160 [PRP] PropertyList:40 Current:34
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=57)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   102:   652.288 ERROR [RTC] RTC_REGISTER_TIME_CORRECT ERROR 0x0 -> 0x9e
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=58)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   103:   592.128 ERROR [RTC] !! RTC CHECK ERROR !!

[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=59)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   104:   612.096 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80010007 L:2483
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=5a)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   105:   612.096 [PRP] PropertyList:25 Current:28
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=5d)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   108:   636.160 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80010006 L:2483
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=5e)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   109:   638.464 [PRP] PropertyList:40 Current:34
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=7a)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   137:   717.056 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80040033 L:2483
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=7b)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   138:   717.056 [PRP] PropertyList:12 Current:4
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=c1)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   208:   829.184 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80030075 L:2483
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=c2)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   209:   829.184 [PRP] PropertyList:23 Current:19
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=c3)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   210:   829.952 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80010006 L:2483
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=c4)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   211:   829.952 [PRP] PropertyList:40 Current:34
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=130)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   320:  1006.592 [DISP] ERROR BackLightCtrl:0
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=134)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   324:  1009.152 [MC] PROP_LCD_OFFON_BUTTON : 2
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=17f)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   399:  1205.760 [RSC] ERROR GetEstimatedSizeOfMovie NOT Exist Size or FrameRate K347 0 0 0
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=180)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   400:  1210.880 [RSC] ERROR GetMargineSizeOfMovie NOT Exist Size or FrameRate K347 0 0 0
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=181)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   401:  1213.696 [RSC] ERROR GetEstimatedSizeOfMovieThumb NOT Exist Size or FrameRate K347 0
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=182)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/4)
   402:  1214.208 [RSC] ERROR GetEstimatedSizeOfMovie NOT Exist Size or FrameRate K347 0 0 0
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/3)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=183)
[      NFCMgr:fe1684bd ] (00:03) CH1 read TCMP wait fail [0x09]
[      NFCMgr:fe168601 ] (00:03) [I2C] read data err
[      NFCMgr:fe168709 ] (00:01) [I2C] CH1 Init
[      NFCMgr:fe553eb5 ] (00:06) [I2C] I2C_Read[CH1] : 0xa8,0x00,0x01,0x00 (Task : NFCMgr)
[      NFCMgr:fe716a6f ] (4d:03)  nfcmgrstate_CeInitialize:ce_init 4194307
[      NFCMgr:fe71af13 ] (4d:03)  nfcmgrstate_Initialize ce_init
[      NFCMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 77, cnt = 0/2)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/3)
   403:  1214.976 [RSC] ERROR GetMargineSizeOfMovie NOT Exist Size or FrameRate K347 0 0 0
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/2)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=184)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/3)
   404:  1215.744 [RSC] ERROR GetEstimatedSizeOfMovieThumb NOT Exist Size or FrameRate K347 0
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/2)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=185)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/3)
   405:  1216.768 [RSC] ERROR GetEstimatedSizeOfMovie NOT Exist Size or FrameRate K347 0 0 0
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/2)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=1b8)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/3)
   456:  1599.232 ERROR [I2C] I2C_Read[CH1] : 0xa8,0x00,0x01,0x00 (Task : NFCMgr)
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/2)
[      RTCMgr:fe1f542b ] [ASSERT] 0 at ./System/MariusAPI/OmarSysInfo.c:73, fe1f542f
ASSERT : ./System/MariusAPI/OmarSysInfo.c, Task = RTCMgr, Line 73
[      RTCMgr:fe0d3f51 ] (8b:06) ASSERT : ./System/MariusAPI/OmarSysInfo.c, Task = RTCMgr
[      RTCMgr:fe0d3f5d ] (8b:06) ASSERT : Line 73
[      RTCMgr:fe0d3f69 ] (8b:06) ASSERT : 0
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=1bb)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/3)
   459: 11311.616 [STARTUP] ERROR ASSERT : ./System/MariusAPI/OmarSysInfo.c, Task = RTCMgr
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/2)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=1bc)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/3)
   460: 11312.128 [STARTUP] ERROR ASSERT : Line 73
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/2)
[      DbgMgr:800033c7 ] DMState: (0) --2--> (0)      1a01 (x=79e4d0 z=0 t=1bd)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/3)
   461: 11312.128 [STARTUP] ERROR ASSERT : 0
[      DbgMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 18, cnt = 1/2)
[      DbgMgr:800033c7 ] DMState: (0) --14--> (0)      1c63 (x=79e4d0 z=84b0c4 t=0)
[     PropMgr:fe484ac9 ] PropState: (0) --6--> (0)      fe3d8647 (x=46f8f4 z=84b08c t=10)
[     PropMgr:fe0d44cb ] (8b:16) startupErrorRequestChangeCBR (0x1d)
[     PropMgr:fe0d4501 ] (8b:16) startupErrorRequestChangeCBR : ErrorSend (101, ABORT)
[     PropMgr:fe484ac9 ] PropState: (0) --6--> (0)      fe3d8647 (x=46f8f4 z=84b0dc t=e)
[     PropMgr:fe533629 ] (00:01) [PM] Disable (ID = 3, cnt = 1/3)
[MPU] Received: 08 06 03 03 65 01 00 00  (unknown - unnamed)
[    PowerMgr:fe5336b5 ] (00:01) [PM] Enable (ID = 3, cnt = 0/2)
[      DbgMgr:fe533629 ] (00:01) [PM] Disable (ID = 18, cnt = 2/3)


This error is where the emulator is stopping. We are currently unsure about what is causing it and how to fix it. We are investigating the NFCMgr as it appears a few times just before the assert, however we aren't certain about its involvement.
We've tried 'patching' it like the EstimatedSize example in the HACKING.rst guide, however all the stack values we tried led to no change.

Any help you can provide would be greatly appreciated!
Title: Re: Canon 80D
Post by: diogosilvalmeida on August 20, 2018, 07:06:39 AM
Hello there!

I am a 80D owner, how can I help with the magic lantern development? I'm not really into programming nowadays, but if you tell me what to do... I hope I can help in the development...

So...What can I do to help?





Title: Re: Canon 80D
Post by: a1ex on August 20, 2018, 09:48:23 PM
Did some major refactoring on the digic6-dumper branch to make it easier to port ML on newer models. The code seems to be working in QEMU, but I'd still want a 80D owner to compile the latest code and make sure it's still working on the hardware.

There are no new features, but the codebase was confirmed to work on DIGIC 7 as well.

edit: confirmed by Chellyandruu, thanks.
Title: Re: Canon 80D
Post by: OlRivrRat on August 25, 2018, 05:08:19 PM
                     @ Alex

"but I'd still want a 80D owner to compile the latest code and make sure it's still working on the hardware."

           As always, Thanks Much for All Your Efforts. It might be helpful to supply some info as to where

that "latest code" might be found .
Title: Re: Canon 80D
Post by: maiadaharfendul on August 28, 2018, 12:53:36 PM
hi  everyone, i'm a new user of this forum  :)
I had own an old 550d with magic lantern, and It worked like a charm :)
now I have a eos 80d and I follow magic lantern development  with so many interest.
I have no skills of programming, but i can offer me (and my camera) as beta tester if requested :D
Title: Re: Canon 80D
Post by: ricflair4life on August 29, 2018, 06:17:34 AM
Dear God, please provide these men the time and interest to develop this magic lantern to work on my 80d. Quickly.... in Jesus's name, amen.
Title: Re: Canon 80D
Post by: dfort on August 29, 2018, 07:47:50 AM
Fun with cut and paste:

Quote from: OlRivrRat on August 25, 2018, 05:08:19 PM
It might be helpful to supply some info as to where
that "latest code" might be found .

Quote from: a1ex on August 20, 2018, 09:48:23 PM
the digic6-dumper branch

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

Quote from: ricflair4life on August 29, 2018, 06:17:34 AM
amen.
Title: Re: Canon 80D
Post by: critix on September 03, 2018, 07:21:01 AM
Hi.
Can you give me dump for this cam?
Thanks a lot...
Title: Re: Canon 80D
Post by: OlRivrRat on September 05, 2018, 04:43:33 PM
                       @Critix

           Yes > Provide EMail Address ~

                                 ORR ~ DeanB
Title: Re: Canon 80D - Canon firmware version and ML development
Post by: burnersk on September 19, 2018, 11:21:47 AM
It happened somehow that I now own an 80D. First I want to use the camera as it was intended to be (without ML). However to support the porting of ML to 80D, I would like to offer some help: supply patches and do some testing.

This would be my first ML "project", and I would like to address some question that may (most possible) have popped up somewhere but I want to double check if the previous made answers would also apply to the 80D system (e.g. new bootloader, signature check algo, etc.).

First some "facts" I have discovered using ML for my old EOS 550D.


That being said (and maybe corrected by you)...

Title: Re: Canon 80D
Post by: a1ex on September 19, 2018, 04:21:05 PM
Quote from: burnersk on September 19, 2018, 11:21:47 AM
When a Canon original firmware update is available, the update will disable the developer mode and another (matiching) ML ".fir" firmware patch have to be applied.
That didn't happen on 550D and other cameras I've tested (newest one being 700D).

Quote
But there are also "hard" bricks, which - in some rare cases - may can be fixed but requires expert knowledge with the board and bootloader proces. Mostly it will turn out as the camera is expensive paperweight

The biggest risk is reflashing the ROM by mistake. Unfortunately, Canon code does that at every shutdown (https://bitbucket.org/hudson/magic-lantern/pull-requests/825/prevent-canon-settings-from-being-saved/diff), and ML is able to write anywhere in the memory, so it's way too easy to insert garbage there (this is by design - DryOS does not offer any kind of memory isolation between tasks). Fortunately, that shouldn't touch the code or the bootloader, so it should be recoverable (i.e. you should still be able to dump the altered ROM, and we should be able to run it in QEMU, compare it with a good ROM and reflash it with correct contents). This issue happened at some point on 5D3, but didn't have to reflash or resolder anything; just patched the affected bytes in RAM, and at the next shutdown, the correct values were written back into ROM.

Some settings are sent over to the MPU (secondary CPU) and stored in its own non-volatile memory. These situations should also be recoverable, although I've encountered one case where I was afraid to go further, as the MPU is the one that powers off the camera: I was messing up with the auto power off setting on 5D3. After setting it to 10 seconds, the camera seemed to work, it turned off by itself after 10 seconds, as expected, but then it did not turn back on. Not sure what exactly it was; it came on by itself after swapping a few batteries.

Quote
What is the current ML firmware version level - if there is any - to unlock the development mode and load code/ML from SD card?

The development happens on the digic6-dumper (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper) branch, so... just look at the file names (https://bitbucket.org/hudson/magic-lantern/src/4f49d43a7f8dc3efba6b9d7d1458e9794db701a0/platform/80D.102/?at=digic6-dumper).

Quote
Is the "main work" to find the memory addresses and put them into constants or do every/this camera requires "actual code" (mostly) to become a alpha version?

That's the easy part, doable by anyone who's not afraid of CTRL and F (http://www.magiclantern.fm/forum/index.php?topic=12177.0).

One of the "harder" tasks is figuring out how to print things on the display. On EOS, the only half-successful experiment I'm aware of is this one, for 5DS (https://bitbucket.org/hudson/magic-lantern/commits/branch/5Ds_experiments). This part is best done with the camera in one's hands, although I'm (still) trying to bring the emulation far enough to initialize the display, so I could figure it out from there. On earlier models, writing into the display buffer is enough to make things appear on the screen; DIGIC 6 and newer models apparently use some sort of Takumi GPU (look it up on CHDK forum; they already figured it out for compacts).

Another "harder" task is logging all MMIO reads and writes (https://bitbucket.org/hudson/magic-lantern/pull-requests/900/mmio-tracing-backend-insanely-powerful) performed by the firmware. This one can be debugged in QEMU, but it's not exactly trivial.

And yet another "harder" task is figuring out how to patch code bits in the ROM. On earlier models, we use the so-called "cache hacks", but these are no longer available on D6. There are some debug registers (https://www.magiclantern.fm/forum/index.php?topic=17360.msg202322#msg202322) that might be usable for the same purpose, although Ant123 already tried them (https://www.magiclantern.fm/forum/index.php?topic=17714.msg174835#msg174835) without much success.

Then, there comes the easy but time-consuming part: enabling ML features, testing what works and what not, and fixing stuff in a way that doesn't break earlier models.

Right now you can experiment with simple things in C, for example an intervalometer. To take a picture:

call("Release");


Some fun stuff: found dual pixel raw streams in LiveView on both 70D (https://a1ex.magiclantern.fm/bleeding-edge/70D/dual-pixel/70D-dual-pixel.html) and 5D4 (https://a1ex.magiclantern.fm/bleeding-edge/5D4/dual-pixel/5D4-lv-daf-raw.html).
Title: Re: Canon 80D
Post by: burnersk on September 19, 2018, 08:19:24 PM
Thanks for the information  :)

Quote from: a1ex on September 19, 2018, 04:21:05 PM
That didn't happen on 550D and other cameras I've tested (newest one being 700D).
Oh, I heard but never checked it myself. So I will delete that now from my own personal heap  ;)

Quote from: a1ex on September 19, 2018, 04:21:05 PMRight now you can experiment with simple things in C, for example an intervalometer. To take a picture:

call("Release");

I guess, I will start with the most generic thing: Have a blank screen drawn and change the background color. Next up is your example and I will start figuring out, how the system actually works. After that, I hopefully be more helpful with supplying patches for the 80D port.
Title: Re: Canon 80D
Post by: a1ex on September 19, 2018, 08:30:56 PM
Quote from: burnersk on September 19, 2018, 08:19:24 PM
I guess, I will start with the most generic thing: Have a blank screen drawn and change the background color. Next up is your example [...]

I suggest starting with something that is known to work. Drawing on the screen from code running alongside main firmware (i.e. after the bootloader stage) is not working yet. For debugging, you've only got LED blinking and file I/O.

Be sure to check the blind edition (https://www.magiclantern.fm/forum/index.php?topic=17360.msg199134#msg199134), in particular its source code.
Title: Canon 80D vs 5D IV
Post by: RavingRover on October 04, 2018, 08:05:12 PM
80D has a DIGIC 6, the 5D IV has a DIGIC 6+, i do not know if either has been shown to be multi-core, but then why should that matter.

I believe i saw that typically the '+' DIGICs were just faster clock speeds, maybe something diff about them, don't know.

The 5DIV has only a sinlge DIGIC, & the 80D.

It appears that the 5DIV is progressing well in its port.

So why does not some/most/all of the 80D port (besides addresses) not benefit from the 5DIV effort and success ?

Just wondering since I have used ML on my old orig M model and do see lovely benefits, ML is nice and would love to see some of its benefits on my 80D as we all would.

Happy porting and much success !!
Title: Re: Canon 80D
Post by: k!r+ on October 08, 2018, 07:38:04 AM
Keeping in mind I'm new to both RE and open source projects.

As far as I can tell, most of the camera's with NFC are at a similar stage in emulation. I wonder if it is possible that at least one reason for this is to do with NFC.

Looking at the second Debug log from Dj4n90 (near the end), three lines before the line:

ASSERT : ./System/MariusAPI/OmarSysInfo.c, Task = RTCMgr, Line 73

there is the line:

   456:  1599.232 ERROR [I2C] I2C_Read[CH1] : 0xa8,0x00,0x01,0x00 (Task : NFCMgr)

which made me think that the ASSERT could be related to this error.

I took the camera apart again to take photo's (https://magiclantern.wikia.com/wiki/Circuit_boards#gallery-0) of the NFC board (sorry not as good as the last ones - ISO was too high). From the code on the chip and the chip pin-out I believe the NFC chip is a Panasonic MN63Y1214 (https://industrial.panasonic.com/content/data/SC/ds/ds4/MN63Y1214_E.pdf). The 0xa8 portion of the error code from Dj4n90's debug log is the standard i2c location for reading from this chip, but I don't know what the rest of the codes are asking for in that error.

Which brings me to my questions:

Thanks for your help, and hopefully this info will assist somehow.
Title: Re: Canon 80D
Post by: a1ex on October 08, 2018, 08:16:54 AM
Omar is a secondary CPU (https://www.magiclantern.fm/forum/index.php?topic=13408.msg194424#msg194424); from what I could tell, it does not use I2C at all. The two lines happen to be adjacent because of multitasking.

In particular, the Omar initialization is started in startupPrepareCapture; the patches from 80D/patches.gdb are trying to bypass it, without much success.

I don't think missing NFC emulation does any harm (there are I2C warnings on other cameras that boot the GUI, and you can patch either the I2C routine or the entire NFC task). There are a bunch of debug functions registered for NFC, which makes it a fairly low-hanging fruit for investigating how it works. Some info from real hardware in this log:
Quote from: sombree on June 01, 2018, 09:45:02 PM
With b35a216 as last changeset:
- log (https://drive.google.com/open?id=12ffoUem2TGR6jzzwVMkQMwtbwV2vm1CT)

2BE98>     NFCMgr:fe71aee7:4d:03:  nfcmgrstate_Initialize:NewsDet_R Hi
2BEF5>     NFCMgr:fe168615:00:01: [I2C] I2CD_Initialize
2BF12>     NFCMgr:fe168683:00:01: [I2C] I2CD_Com mode[3], devAddr[0xA8]
2BF31>     NFCMgr:fe167ec7:00:01: [I2C] CH1 bus ready
2BF46>     NFCMgr:fe167ec7:00:01: [I2C] CH1 bus ready
2BF60>     NFCMgr:fe168465:00:01: [I2C] read start condition
2C03B>   PowerMgr:001ccab0:00:0f: INT-0DDh FE167F29(0)
2C069>     NFCMgr:fe168187:00:01: [I2C] read stop condition
2C091>   PowerMgr:001ccab0:00:0f: INT-0FDh FE167FC7(0)
2C0AB>   PowerMgr:fe2807ed:00:01: [I2C] SIRQ
2C0BC>     NFCMgr:fe168709:00:01: [I2C] CH1 Init


On the other side, I'm pretty sure the incomplete Omar initialization is holding back the startup process (unlike DIGIC 5 models, where Eeko initialization is pretty much skipped without major side effects); this is because other initialization routines are waiting for this step to complete. Unfortunately, Omar communication is not exactly easy to figure out, at least for me. RE notes in the Eeko thread.

To log the info required to emulate this stuff, one has to port the MMIO tracing backend:
- https://bitbucket.org/hudson/magic-lantern/pull-requests/900/mmio-tracing-backend-insanely-powerful
- https://bitbucket.org/hudson/magic-lantern/commits/0a2e116 (same technique in a different context, allowing C callbacks)

If that works, we'll get a huge log with every MMIO access performed by the main CPU, i.e. several megabytes of numbers that have to be interpreted to figure out their meaning, or replayed somehow in the emulator. If there's any more energy left after dealing with trolls, that is.

Thanks for identifying the BLE chip. The pinout makes sense to me (direct link (https://vignette.wikia.nocookie.net/magiclantern/images/1/16/IMG_8833.jpg/revision/latest?cb=20181008045743), as it took me a while to find the picture). FYI, @ids1024 managed to reverse the protocol:
https://iandouglasscott.com/2018/07/04/canon-dslr-bluetooth-remote-protocol/
Title: Re: Canon 80D
Post by: Hubuki on October 25, 2018, 07:18:42 PM
Is there a a download for the 80d yet?
Please Please Please say yes!! T^T
Title: Re: Canon 80D
Post by: nagamayasi on November 04, 2018, 05:53:10 PM
please download link for canon 80d
Title: Re: Canon 80D
Post by: ricflair4life on November 23, 2018, 09:06:11 AM
Happy late thanksgiving, everyone! I'm PayPal'ing the person who can provide a working magic lantern for the 80d. Seriously, I check this thread several times a day everyday.. what's going on???
Title: Re: Canon 80D
Post by: nagamayasi on November 25, 2018, 09:21:28 AM
Quote from: ricflair4life on November 23, 2018, 09:06:11 AM
Happy late thanksgiving, everyone! I'm PayPal'ing the person who can provide a working magic lantern for the 80d. Seriously, I check this thread several times a day everyday.. what's going on???
yes same with me,
everyday i chehk this thread, and still waiting for magiclantern working on canon 80d.
from 2016....  :-[
Title: Re: Canon 80D
Post by: theBilalFakhouri on November 25, 2018, 10:11:43 AM
I don't think the right person has arrived to work on this camera seriously.

If you are ready to pay I will suggest to start an offer in freelancer.com for "Making Magic Lantern working in 80D" maybe we will catch him there  :D
Title: Re: Canon 80D
Post by: polkah on November 26, 2018, 03:52:06 PM
Quote from: ricflair4life on November 23, 2018, 09:06:11 AM
Happy late thanksgiving, everyone! I'm PayPal'ing the person who can provide a working magic lantern for the 80d. Seriously, I check this thread several times a day everyday.. what's going on???
Yeah, we should make a kickstarter to fund anyone that would make a working port for 80d
Title: Re: Canon 80D
Post by: waterfox11 on December 09, 2018, 04:33:41 PM
I agree :)
Title: Re: Canon 80D
Post by: GonJouls on December 13, 2018, 05:41:51 PM
Yes! I would most definitely support a kickstarter or any thing in that matter to have someone who could work on this port!
Title: Re: Canon 80D
Post by: ricflair4life on December 22, 2018, 10:10:57 AM
So what exactly do we need to do?
Title: Re: Canon 80D
Post by: ohdidntcall on December 22, 2018, 11:09:50 PM
I think that the best thing to do would be to wait and not bother the developers too much. I've been quietly reading this forum for years, and occasionally I see someone ask if the 80D nightly build is available yet, and sometimes even offer money. I dont think that these requests really speed up the process /: though I don't know if making a kickstarter will help. Of course, I'm dying for ML for 80D too (: but I think that it'd be best to just wait and see.
Title: Re: Canon 80D
Post by: polkah on January 03, 2019, 01:06:34 AM
Quote from: ohdidntcall on December 22, 2018, 11:09:50 PM
I think that the best thing to do would be to wait and not bother the developers too much. I've been quietly reading this forum for years, and occasionally I see someone ask if the 80D nightly build is available yet, and sometimes even offer money. I dont think that these requests really speed up the process /: though I don't know if making a kickstarter will help. Of course, I'm dying for ML for 80D too (: but I think that it'd be best to just wait and see.
Yeah you're right, I hope the developpers will figure a way out, it's great to have those people doing this amazing work basically as a hobby, I'm not especially in a hurry for ML for my 80d, but thought it could be nice to reward the develloppers for all of their great work
Title: Re: Canon 80D
Post by: whoreable on January 05, 2019, 11:18:01 AM
Lets start the GoFundMe and someone surely will take the challenge

Or atleast this thing will get into the several thousand dollar range enough to purchase an 80D to experiment on
Title: Re: Canon 80D
Post by: nikfreak on January 05, 2019, 04:42:02 PM
Quote from: whoreable on January 05, 2019, 11:18:01 AM
Lets start the GoFundMe and someone surely will take the challenge...


Quote from: g3gg0
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Here's the official forum site and the place where developers (new and old) can connect and talk. You need patience. "Someday" "someone" will announce ML for 80D or 5d Mark IV or any other unsupported cam. But that will happen here and not on external funding sites
Title: Re: Canon 80D
Post by: Papa Bless Finesse on January 09, 2019, 10:45:21 AM
Hey guys i hate to be that guy but if someone is currently working on ML for the 80d if you want someone to test it for you i would be happy to be guinea pig. as long as you guide me on how to fix if something goes wrong as im just a wee young lad that is probably stupid for doing this but doesnt care anyway then continues writing like this just because he can and doesnt really have much else to do but bust a nut and hope for ML for his camera sometime soon and yeah ah yeah. swag anyway *dab* if you or you know someone that is working on it. message me i guess but no late night booty calls. thanks guys.
Title: Re: Canon 80D
Post by: polkah on January 15, 2019, 11:10:22 PM
Quote from: Papa Bless Finesse on January 09, 2019, 10:45:21 AM
Hey guys i hate to be that guy but if someone is currently working on ML for the 80d if you want someone to test it for you i would be happy to be guinea pig. as long as you guide me on how to fix if something goes wrong as im just a wee young lad that is probably stupid for doing this but doesnt care anyway then continues writing like this just because he can and doesnt really have much else to do but bust a nut and hope for ML for his camera sometime soon and yeah ah yeah. swag anyway *dab* if you or you know someone that is working on it. message me i guess but no late night booty calls. thanks guys.
:D Same
Title: Re: Canon 80D
Post by: a1ex on January 27, 2019, 11:38:53 PM
Minor update (i.e. what I did last week):

- emulation is able to reach GuiMainTask (after updating the MPU messages and some trivial GDB patches - not yet committed)
- it gets stuck trying to communicate with Zico/MZRM (as expected)
- to understand how that's supposed to work, I need some detailed low-level logs
- I've managed to port io_trace on DIGIC 6 (tested in QEMU; not yet committed)
- "just" debugging io_trace took me a couple of days of intensive work (whew!)
- now, in order to test it on real hardware, I need some preparations
- I want to capture some huge logs (with lots of messages), from early startup until full boot
- problem: memory allocators are not available at early startup
- workaround: I can statically allocate some buffers, where Canon firmware won't touch them
- to find these areas, I need you to run a little test
- compile the latest changeset (bee6ec3 (https://bitbucket.org/hudson/magic-lantern/commits/bee6ec3)) with CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP enabled in config-defines.h
- the startup process will be slower than usual (it might even lock up)
- during the LED blinks (about 1 minute), exercise the camera a bit (open Canon menu, enter LiveView, take a photo and record a short video clip) - important!
- after the LED stops blinking, a log file will be saved
- the log should print a summary of memory areas that were not touched by Canon firmware
- these memory areas, likely unused by Canon code, can probably be reused for saving huge logs (with plenty of details about the startup process)
- if the log file gets full before the memory usage summary is printed, try adjusting what messages should be logged (in my_DebugMsg, identify them by class and level)
- if it's still not working, disable all other messages (e.g. assign a different class/level for the interesting messages, i.e. the ones showing memory usage summary, and drop everything else)
- brain dump complete (to be continued after getting the result of this test)
Title: Re: Canon 80D
Post by: Ant123 on January 28, 2019, 07:54:34 PM
Quote from: a1ex on January 27, 2019, 11:38:53 PM
- emulation is able to reach GuiMainTask (after updating the MPU messages and some trivial GDB patches - not yet committed)
- it gets stuck trying to communicate with Zico/MZRM (as expected)
Have you tried to apply modified EOS M3 patches? (0xFC3F1110, 0xFC3F1114, 0xFC3F1178)
Title: Re: Canon 80D
Post by: OlRivrRat on January 29, 2019, 01:59:19 AM
           @Alex

Would like to help with this but I am still Completely Compiling Illiterate. If someone could provide, what ever it is, already Compiled I'll give it a Whirl ~

                                                                          ORR ~ DeanB
Title: Re: Canon 80D
Post by: Chellyandruu on January 30, 2019, 09:47:44 PM
I compiled and the camera blinks for 1 minute,did all the test but no logs are saved.
Title: Re: Canon 80D
Post by: k!r+ on January 31, 2019, 04:03:11 AM
I have compiled and run the changeset with the config requested on the camera I have.

-      DEBUGMSG.LOG (http://s000.tinyupload.com/index.php?file_id=02789215485614049915)

The camera did not lock up at the beginning with just the standard configuration and allowed me to open the menu, liveView, movie, playback, etc. But at the end of the script (led stopped flashing) it did appear to "lock up" - the screen went blank and no input appeared to make any difference until the power switch was flicked, at which point the led came on for roughly one second. I don't think it was a full lockup, as I did not have to remove the battery. The file of the log output did appear to complete fully and provide a summary of memory usage. @a1ex if you want more logs to check against just let me know and the best way to get them to you.

Current focus has been on understanding trying to understand way CHDK print to screen in an effort to get "helloworld" happening.
Title: Re: Canon 80D
Post by: a1ex on January 31, 2019, 05:02:18 PM
Looks good. Also got a log from Chellyandruu, so here's a comparison: 80D-memory-map.html (https://a1ex.magiclantern.fm/bleeding-edge/80D/80D-memory-map.html)

Annotated logs:
DEBUGMSG-ch-a.log (https://a1ex.magiclantern.fm/bleeding-edge/80D/DEBUGMSG-ch-a.log)
DEBUGMSG-kr-a.log (https://a1ex.magiclantern.fm/bleeding-edge/80D/DEBUGMSG-kr-a.log)

Unless anyone proves me wrong with further logs, I'd choose:


52B00000 - 554FFFFF: 42.0M
55600000 - 57FFFFFF: 42.0M
58100000 - 5A9FFFFF: 41.0M
68000000 - 6A9FFFFF: 42.0M
6AB00000 - 6D4FFFFF: 42.0M
6D600000 - 6FEFFFFF: 41.0M
70000000 - 729FFFFF: 42.0M
72B00000 - 753FFFFF: 41.0M


or their cacheable counterparts (clear 0x40000000 from the address).

These addresses are camera-specific and workload-specific - they are likely unused *only* on 80D and *only* under the scenarios performed by the two testers. That is, roughly:
- plain startup (one of the logs was in M mode, the other in... some sort of Auto mode without flash, I guess)
- entered and exited LiveView (both photo and movie mode)
- video recording
- still photo capture

Some key moments in the two logs ("evf" is LiveView, "scs" is still photo capture):

0.081545     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 3
0.099797     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 3
1.411584     PropMgr:fe0fde4d:89:03: PROP_SHOOTING_TYPE : NORMAL
10.113758     PropMgr:fe0fde83:89:03: PROP_SHOOTING_TYPE : LV
10.153722         Evf:fe23c553:a7:03: evfStart
13.181087  ShootCaptu:fe0df243:93:03: scsReleaseOn
13.183348         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:91]
13.197543    EventMgr:fe100683:93:03: scsReleaseDataCBR
13.336106  ShootCaptu:fe0ded0d:93:03: scsReleaseEnd
13.336134  ShootCaptu:fe0df275:93:03: scsReleaseOff
13.489096         Evf:fe23c553:a7:03: evfStart
14.216208  ShootCaptu:fe0df243:93:03: scsReleaseOn
14.217897         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:22]
14.232051    EventMgr:fe100683:93:03: scsReleaseDataCBR
14.371102  ShootCaptu:fe0ded0d:93:03: scsReleaseEnd
14.371128  ShootCaptu:fe0df275:93:03: scsReleaseOff
14.520299         Evf:fe23c553:a7:03: evfStart
14.843084         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:10]
16.639859         Evf:fe23c553:a7:03: evfStart
16.842968     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 3
16.861439         Evf:fe323c75:ab:03: FHD60fps LCD
17.059484         Epp:fe120de3:99:07: VRAM_InitializeVramPath FHD30P
17.103158         Evf:fe323c75:ab:03: FHD60fps LCD
17.393141         Epp:fe120de3:99:07: VRAM_InitializeVramPath FHD30P
18.544355     CtrlSrv:fe59aabd:2f:05: MVR_StartRecord
18.916645     PropMgr:fe0fde95:89:03: PROP_SHOOTING_TYPE : MOVIE
25.327064     CtrlSrv:fe390c67:83:03: EndMovieRecSequence MVR_StopRecord()
26.921164     PropMgr:fe0fde83:89:03: PROP_SHOOTING_TYPE : LV
34.000766     PropMgr:fe0fde4d:89:03: PROP_SHOOTING_TYPE : NORMAL
34.003488         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:414]
34.086513     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 3


0.084690     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 15
0.104977     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 15
1.453584     PropMgr:fe0fde4d:89:03: PROP_SHOOTING_TYPE : NORMAL
17.994169     PropMgr:fe0fde83:89:03: PROP_SHOOTING_TYPE : LV
18.003630         Evf:fe323c75:ab:03: FHD60fps LCD
18.014741     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 15
18.035428         Evf:fe23c553:a7:03: evfStart
18.039131         Evf:fe323c75:ab:03: FHD60fps LCD
18.246843         Epp:fe120de3:99:07: VRAM_InitializeVramPath FHD30P
19.719062     CtrlSrv:fe59aabd:2f:05: MVR_StartRecord
20.070081     PropMgr:fe0fde95:89:03: PROP_SHOOTING_TYPE : MOVIE
21.468065     CtrlSrv:fe390c67:83:03: EndMovieRecSequence MVR_StopRecord()
23.116395     PropMgr:fe0fde83:89:03: PROP_SHOOTING_TYPE : LV
23.455943     PropMgr:fe0fde4d:89:03: PROP_SHOOTING_TYPE : NORMAL
23.458682         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:134]
23.597536     PropMgr:fe1447cb:81:03: dwNewAeModeDial = 15
24.613145     PropMgr:fe0fde83:89:03: PROP_SHOOTING_TYPE : LV
24.640969         Evf:fe23c553:a7:03: evfStart
26.879191     PropMgr:fe0fde4d:89:03: PROP_SHOOTING_TYPE : NORMAL
26.883264         Evf:fe23ddf7:a7:03: evfEnd[FrameNo:67]
41.471468  ShootCaptu:fe0df243:93:03: scsReleaseOn
41.472982    EventMgr:fe100683:93:03: scsReleaseDataCBR
41.597757  ShootCaptu:fe0ded0d:93:03: scsReleaseEnd
41.597783  ShootCaptu:fe0df275:93:03: scsReleaseOff


New code committed. Let's see - can we get a large startup log?
Title: Re: Canon 80D
Post by: sombree on January 31, 2019, 09:46:29 PM
Log made on latest (a706877) commit: log (https://drive.google.com/open?id=1GeBNoS-RanCqNuC79lxYVIimXXL66D1M) and log2 (https://drive.google.com/open?id=1RHkZabD9B7Hq7EMgQJCfw3iKsB-PoZj_). I've stressed camera a little bit - start to M mode, fiddle a bit with touchscreen, switch to LV and back, switch to movie mode -> record few secs -> back to photo mode, switch to play mode etc.
Btw. I had to define CONFIG_80D in log-d6.h - it's used in log-d6.c but it's not defined anywhere :)
Title: Re: Canon 80D
Post by: a1ex on January 31, 2019, 10:01:41 PM
Awesome! It saved all of that without crashing? :)

CONFIG_80D: it should be defined by the Makefiles. If I compile the same code on 5D4, for example, it will refuse to run. If I write some gibberish into the CONFIG_80D block from log-d6.c, I get a compile error (without having to define CONFIG_80D manually anywhere).

Back to cleaning up io_trace.
Title: Re: Canon 80D
Post by: sombree on January 31, 2019, 10:25:25 PM
Yep, no crash, just a little longer camera start up :)
As for CONFIG_80D - you're right, it's defined by the Makefile.
Title: Re: Canon 80D
Post by: a1ex on February 01, 2019, 10:34:28 PM
OK, io_trace code committed. Whew, this was hard!

Compile with: make clean && make CONFIG_MMIO_TRACE=y

If it locks up:
- try previous changesets
- reduce the logged range (for example, try logging from 0xC0220000, size 0x1000)
- give me as many details about the crash as you can (it's very hard to debug)

Fingers crossed.
Title: Re: Canon 80D
Post by: Chellyandruu on February 02, 2019, 01:25:17 AM
https://www.dropbox.com/s/g8u4gmchldcngxr/DEBUGMSG.LOG?dl=0
Title: Re: Canon 80D
Post by: a1ex on February 02, 2019, 07:09:21 AM
Make sure you compile with CONFIG_MMIO_TRACE=y on the command line. There should be 2 log files.

If in doubt, run "make clean" first (updated the command), as the build system doesn't know it needs to recompile if you change only the options. It only recompiles if you edit source files.
Title: Re: Canon 80D
Post by: sombree on February 02, 2019, 09:53:50 AM
It worked out of box :D
mmio log without lens (https://drive.google.com/open?id=1fBQ7K8y5LCYr6Pd2HCyaW0NWLecxYp4p)
mmio log with lens attached (https://drive.google.com/open?id=1CEnDzwKgENsVk3N5x1MJG02WiUzTvKIr)
another one (https://drive.google.com/open?id=1BnPT1Lua5JZx_lu2pc0u_kkNdng6vJay) - with a little exercise - took a photo, fiddled with a touchscreen, changed iso etc.
Title: Re: Canon 80D
Post by: a1ex on February 02, 2019, 07:48:36 PM
Really nice! These files contain the ultimate reference data for DIGIC 6!

Previously, I had to guess many of these values, from what the code seemed to expect. That took me probably months of trial and error (well, years with the fragmentation, as I didn't work only on this). You may ask - why didn't I start with this from the beginning? Err... back then, I simply did not understand how computers work, well enough to write the MMIO tracing code. I've learned it from... all of that trial and error (not only from the 80D firmware, but from investigating about 40 EOS models from different generations). I've tried to summarize what I've learned here (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst), but it's probably a bit too advanced for beginners.

Anyway, let's try logging some more address ranges:

- from 0xBFE00000, size 0x200000 (expecting some activity from GuiMainTask)
- from 0xEE000000, size 0x1000000 0x2000000 (no activity in QEMU; unused?)
- from 0xA0000000, size 0x40000000 (expecting all MMIO activity, i.e. C, D and BFE ranges) (nevermind, invalid range)

I'll be back with a guide on how to interpret these huge logs.
Title: Re: Canon 80D
Post by: sombree on February 02, 2019, 09:58:41 PM
from 0xBFE00000, size 0x200000  - camera locks up with Err70, no log is saved. Edit: sometimes camera locks up with Err70 but led still blinks as it's supposed to.
from 0xEE000000, size 0x1000000 - MMIO log looks empty - log (https://drive.google.com/open?id=15cv7-nTQSbR5BoyTMuYGwwEV0v7THZWa).
from 0xA0000000, size 0x40000000 - camera locks up without any error, no log is saved.
Title: Re: Canon 80D
Post by: Ant123 on February 03, 2019, 09:03:11 AM
Does MMIO trace work in LiveView mode?

On EOS M3 io_trace causes crash in Rec mode.
Title: Re: Canon 80D
Post by: sombree on February 03, 2019, 11:28:18 AM
Few times it didn't work in regular (photo) LiveView - on-screen image was garbled and there was no log. Right now I've tried again and no problem at all, both in photo and video LV (log (https://drive.google.com/open?id=1jSK4Ix3fyKqwBSScDAdABfZArUlkQ3lB)).
Title: Re: Canon 80D
Post by: Ant123 on February 03, 2019, 12:24:15 PM
Quote from: sombree on February 02, 2019, 09:58:41 PM
from 0xBFE00000, size 0x200000  - camera locks up with Err70, no log is saved.

0xBFF00000 memory region contains message buffers shared with MZRM core. So probably io_trace code is not fast enough for transfers caused by memcpy.
Title: Re: Canon 80D
Post by: sombree on February 03, 2019, 01:41:15 PM
After builiding with -O2 (instead of default -Os) I was able to get some partial logs:
from 0xBFE00000, size 0x200000 - log (https://drive.google.com/open?id=1Jxr-T4jPbjU3AfxhMgxKMAj8KGcEmIbI)
from 0xA0000000, size 0x40000000 - camera locks up with Err60, no log is saved.

Edit:
I checked from 0xA0000000, size 0xFFFFFFF - camera doesn't lock up and MMIO log is empty (unused range?).
Title: Re: Canon 80D
Post by: a1ex on February 04, 2019, 09:01:57 AM
Indeed, access in the BFE region is done with highly optimized code, memcpy and memcpy-like This is where io_trace struggles.

Possible reasons for crash:
- Too slow (noticeable with a huge number of events). In this case, using a lower frame rate for LiveView usually helps.
   - compiler optimization: the io_trace code is handwritten assembly (i.e. not affected at all)
   - maybe the other logging code (written in C) was improved by -O2, but I don't expect a big difference
   - I'd be surprised if the optimization level really helped in a repeatable way (i.e. consistently crashing with -Os and consistently working with -O2)
   - either way, these partial logs were really helpful, so whatever you did to capture them, it was good

- Re-execution context (register contents) slightly different. This could affect the outcome of the original code (the path it takes). My tracing code works by:
   - disallowing memory access in the logged area
      - this camera has a memory protection unit with 8 memory regions (from 0 to 7)
      - 80D firmware uses just the first 7 (likely true on other D6 models)
      - so, I could configure the last memory region (which has the highest priority) to cover the logged area and to disable the read/write permissions
   - this will cause a data abort exception for the instruction trying to read or write in the logged range
   - this instruction will have to be re-executed:
      - I need to log the result of that instruction (i.e. return value from a MMIO register), so I can't just jump back into the original code
      - therefore, I'm copying the original instruction in the middle of my data abort handler
      - before re-executing it, I disable the memory protection region, sync the caches and restore context (original registers)
      - then I re-enable the memory protection, to keep catching further MMIO reads/writes
   - this lets me to log stuff both before and after the trapped instruction
   - registers in data abort mode are not exactly the same as in user mode (SP and LR differ)
   - this is not usually a problem in regular MMIO code, but highly optimized code like memcpy does use LR as a general-purpose register; maybe also SP
   - this edge case (or corner case, if you prefer) is not handled well by io_trace
- other bugs in the low-level io_trace code, that I'm not aware of

The partial log shows a very important hint: at address 0xBFE00000, the firmware writes 0 or 1, but always reads 0. That means this address (possibly the entire range) behaves somewhat like MMIO, rather than like simple memory. It's probably shared memory, where the secondary cores (like Omar and Zico) are writing, too. Still, as long as we are not emulating these secondary cores, we need to model their behavior. If no code is executed by the main core from this memory range, modeling it as MMIO (rather than regular memory) is probably the way to go.

What to do about logging the activity in this range?
- fix the io_trace code to re-execute the trapped instruction with the original SP and LR
- replace memcpy with a slower function (easier to log with current code)
- try to log smaller regions

I'll look into the first two. You could attempt to log from 0xBFF00000, size 0x100000 (i.e. the upper half, used by MZRM). The lower half (0xBFF00000, size 0x100000) appears to be used by Omar.

In QEMU, logging the BFF range gives over 12000 MMIO events, starting with:

4.494781  GuiMainTas:fe64ee06:MMIO : [0xBFF20000] <- 0x00000106
4.494782  GuiMainTas:fe64ee0a:MMIO : [0xBFF20004] <- 0x8201FC60
4.495039  GuiMainTas:fe64ee0e:MMIO : [0xBFF20008] <- 0xA0FFFF01


It still contains highly optimized memcpy-like code, so don't worry if it won't work out of the box.




Size 0xFFFFFFF means, according to Cortex R4 TRM page 123:
- enabled
- region size: 4 GB
- all sub-regions disabled

In other words, it's effectively disabled (it won't log anything).

Size must be power of 2 (p. 124). Start address must be multiple of size (p. 178).




Noticed a typo - from 0xEE000000, the size should have been 0x2000000. Either way, there's no activity in QEMU on this address range. This comes from the startup configuration:

FE0258E4: MCR p15,0,Rd,cr6,cr2,0:       RGNR <- 0x5       
FE0258EC: MCR p15,0,Rd,cr6,cr1,0:      DRBAR <- 0xEE000000
FE0258F4: MCR p15,0,Rd,cr6,cr1,4:      DRACR <- 0x329      (P:RW U:RW; Inner Write-back, write-allocate; Outer Write-back, write-allocate; Non-shared)
FE0258FC: MCR p15,0,Rd,cr6,cr1,2:       DRSR <- 0x31       (0x2000000)





@Ant123: if you managed to run this on the M3, I'd like to see some logs :D




Found a slightly better way to merge the two logs:


cat DEBUGMSG.LOG MMIO.LOG | ansi2txt | sort -k 1n -s > STARTUP.LOG


Still, the first few lines (those timestamped with 0.000000, i.e. before the microsecond timer was started by Canon firmware) won't be merged in the right order. This is addressed in the full io_trace code (io-trace-full branch). I might be tempted to run that, too; just need to find the full set of stubs to compile the regular ML codebase. Easy coding task, if anyone wants to help.

Currently trying to find a way to annotate these huge logs (i.e. what each register does).
Title: Re: Canon 80D
Post by: sombree on February 04, 2019, 05:34:17 PM
Sure:
0xBFF00000, size 0x100000 - log (https://drive.google.com/open?id=1YXh1dxifPkF4dTvx77sucBoQgHpwDaTI)
Fun fact - with this base and size camera doesn't lock up (i.e. I can take a photo) but main screen doesn't work at all. It's just completely black. Secondary screen still works.
Title: Re: Canon 80D
Post by: a1ex on February 05, 2019, 07:54:05 PM
Managed to restore the original LR, so memcpy & related routines should no longer be affected, in theory. The register values reported in these highly optimized routines will still be bogus, but now I don't expect the io_trace code to change the outcome of the original routine. I've tested the change in QEMU on memcpy (0x80007C8C) and bzero32 (0x80007E84), with a buffer size of 0x100000. With previous io_trace code, 1/4 of the copied (or zeroed) data was corrupted (because it was written from LR). With current io_trace code, the memory contents was correct after copying / zeroing.

Whether this change will help with logging the tricky ranges (BFE/BFF)... I don't know. Let's find out.

The latest code also logs LR for each MMIO event. That's very useful information to have in some cases (and still insufficient in others, where a stack trace would be helpful). For this reason, I'd also like some new general-purpose logs after the latest changes, i.e. a plain startup log and another one with exercising (photo capture, LiveView).




P.S. @Ant123 is making great progress understanding the display routines on DIGIC 6 - here (https://chdk.setepontos.com/index.php?topic=12788.msg139365#msg139365) and here (https://www.magiclantern.fm/forum/index.php?topic=2864.msg211107#msg211107).
Title: Re: Canon 80D
Post by: sombree on February 05, 2019, 10:12:27 PM
It works :D
from 0xBFE00000, size 0x200000: regular (https://drive.google.com/open?id=1ZnsFlagAJcFIvD1NHxcccmIFx0uaGKXI) and with exercising (https://drive.google.com/open?id=14vi6tM-AF8X0yIptP6iSg7sDjuA718fg)
from 0xC0000000, size 0x20000000: regular (https://drive.google.com/open?id=1HdCsJIiUMcMUL4zsZ_yrKIH_jb8qiFrg) and with exercising (https://drive.google.com/open?id=1XGl27T5cSttBkx9veUwZfdXNu4-lt2io)
Btw. camera boots autoexec.bin a little faster than before.
Title: Re: Canon 80D
Post by: a1ex on February 05, 2019, 11:28:49 PM
Really nice!

Annotated versions for the regular (C0000000/20000000) logs:
STARTUP.log (https://a1ex.magiclantern.fm/bleeding-edge/80D/STARTUP.log) (plain startup, 21MB)
STARTUP-ph.log (https://a1ex.magiclantern.fm/bleeding-edge/80D/STARTUP-ph.log) (with exercise = photo capture, 24 MB)

An older log, with LiveView activity, but no LR:
LV.log (https://a1ex.magiclantern.fm/bleeding-edge/80D/LV.log) (75 MB)




Let's look for interesting stuff.

FPS registers and raw image size (discussed before (https://www.magiclantern.fm/forum/index.php?topic=17360.msg200479#msg200479)):

cat STARTUP-ph.log | grep MMIO | grep '0xD0006008\|0xD0006014\|0xD0006800\|0xD0006804'
2.797276  ShootCaptu:fe51786f:fe51786b:MMIO : [0xD0006800] <- 0x0002000E: start row/column for image capture
2.797298  ShootCaptu:fe51786f:fe51786b:MMIO : [0xD0006804] <- 0x0FDB0320: end row/column => 6288x4057
2.838859  ShootCaptu:fe51786f:fe51786b:MMIO : [0xD0006008] <- 0x03030303: FPS timer A: 772 [ wait a minute, 772 * 8 = 6176 < 6288, why?! ]
2.838921  ShootCaptu:fe51786f:fe51786b:MMIO : [0xD0006014] <- 0x00000FDD: FPS timer B: 4062 [ 27 MHz / 772 / 4062 = 8.6 FPS?! ]



cat LV.log | grep MMIO | grep '0xD0006008\|0xD0006014\|0xD0006800\|0xD0006804'
8.577698         Evf:fe51786e:MMIO : [0xD0006008] <- 0x02D102D1: FPS timer A: 722
8.577759         Evf:fe51786e:MMIO : [0xD0006800] <- 0x0003000E: start row/col
8.577779         Evf:fe51786e:MMIO : [0xD0006804] <- 0x02B1021A: end row/col: 2096x1372
8.578004         Evf:fe51786e:MMIO : [0xD0006014] <- 0x000004DE: FPS timer B: 1247/1248 (changes often)
8.719223         Evf:fe51786e:MMIO : [0xD0006014] <- 0x000004DF: FPS between 29.965 and 29.988 (averaged: 29.976)





Display buffer. From bootloader configuration (eos.c (https://bitbucket.org/hudson/magic-lantern/src/f5d3610d14662a0349326578a776a482e87e42cb/contrib/qemu/eos/eos.c?fileviewer=file-view-default#eos.c-5432), disp_direct.c (https://bitbucket.org/hudson/magic-lantern/src/recovery/src/disp_direct.c)), the relevant registers are:
- 0xD2013800, 0xD201381C: display resolution
- 0xD2030108: BMP VRAM address << 8
- 0xD20139A8: palette address << 4
- 0xD20139A0: palette confirm

Can we find any of these in our logs?


cat STARTUP.log | grep '0xD2013800\|0xD201381C\|0xD2030108\|0xD20139A8\|0xD20139A0'
0.420055     Startup:fe1e83d9:fe18b2bd:MMIO : [0xD2013800] -> 0x00000000; DIGIC6: Display resolution
1.309242   DispDCtrl:fe1e8409:fe198133:MMIO : [0xD2013800] <- 0x01E002D0; DIGIC6: Display resolution
1.309634   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018; DIGIC6: BMP VRAM
1.309651   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E; DIGIC6: BMP VRAM
1.510903   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018; DIGIC6: BMP VRAM
1.510924   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E; DIGIC6: BMP VRAM


0x01E002D0 is 720x480. So far, so good - most other Canons use this resolution.

VRAM address - cross-check with:
Quote from: Ant123 on January 17, 2018, 05:45:48 PM
two uyvy buffers at 0x41785B00, 0x41901800

0x40000000 is for disabling caches, value written to 0xD2030108 is shifted by 8, so... UNCACHEABLE(0x19018 << 8) is exactly 0x41901800. It matches!

The other number doesn't match, but let's look at the other log:

cat STARTUP-ph.log | grep '0xD2013800\|0xD201381C\|0xD2030108\|0xD20139A8\|0xD20139A0'
2.397632   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001785B; DIGIC6: BMP VRAM
... (a few other values) ...


There you have it.

Now, let's hack the camera:


#define HALFSHUTTER_PRESSED MEM(0x5CAC)

/* test code, somewhere in dump_task */
int offset = 0;
while(1)
{
    if (HALFSHUTTER_PRESSED)
    {
        MEM(CARD_LED_ADDRESS) = LEDON;
        MEM(0xD2030108) = 0x00019018 + offset++;    /* try other values, like 0x1234, random etc */
    }
    else
    {
        MEM(CARD_LED_ADDRESS) = LEDOFF;
    }

    msleep(50);
}


Expected outcome:
- SD card LED turning on when pressing shutter halfway, and off when releasing it
- gibberish on the screen, possibly shifting the main image, triggered by half-shutter press.
- image back to normal when entering Canon menu or otherwise changing the GUI mode.

Theory:
- there is a frame buffer in the main RAM (like before, just with a different image format: uyvy; previous models were palette-based)
- the display hardware knows about it from a MMIO register (0xD2030108) (like before, just different register)
- contents of that frame buffer is rendered on a secondary CPU (previous models were rendering the bitmap overlay on the main CPU)
- the frame buffer address only changes when the GUI subsystem goes into some different mode (e.g. from shooting mode to Canon menu)
- we *might* be able to redirect the display buffer anywhere else in the RAM and write what we want there (let's see the outcome of that hack)
Title: Re: Canon 80D
Post by: sombree on February 06, 2019, 12:04:14 AM
It works too :D
With 0x1234 LiveView (both in photo and video mode) screen flashes green with shutter pressed halfway. After that main screen's background changes from black to last LV frame when shutter is pressed halfway. Also LED blinks as it's supposed to :)
Edit:
(https://i.imgur.com/VFwpOrO.png)
Title: Re: Canon 80D
Post by: srsa on February 06, 2019, 12:28:23 AM
Quote from: a1ex on February 05, 2019, 11:28:49 PM
Theory:
- there is a frame buffer in the main RAM (like before, just with a different image format: uyvy; previous models were palette-based)
On D6 PowerShots, the overlay uses two buffers at the same time: one uyvy plus one "opacity" (1 byte per pixel). The opacity buffers are usually located close to the uyvy ones. If these cameras have the same display config, and you're planning to write to the uyvy buffers, you'll need to write the opacity buffers too.
Quote- the frame buffer address only changes when the GUI subsystem goes into some different mode (e.g. from shooting mode to Canon menu)
On newer D6 Powershots, buffers are switched continuously when there are animations on screen.
Title: Re: Canon 80D
Post by: a1ex on February 07, 2019, 08:20:27 AM
Thanks srsa for the hints.

@sombree: I'd like a full RAM/ROM dump captured in the same session as MMIO logging, covering PLAY mode and Canon menu.

That is, the following lines should be called right *after* log_finish():

    dump_file("ROM1.BIN", 0xFC000000, 0x02000000);
    dump_file("ATCM.BIN", 0x00000000, 0x00004000);
    dump_file("BTCM.BIN", 0x80000000, 0x00010000);
    dump_file("RAM4.BIN", 0x40000000, 0x40000000);
    dump_file("BFE0.BIN", 0xBFE00000, 0x00200000);  // if these cause lock-up, skip them
    dump_file("DFE0.BIN", 0xDFE00000, 0x00200000);


Ideally, the main memory should be zeroed out at startup, too (CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP like before, but without the logging code from minimal-d6.c).

And, as soon as the camera starts (i.e. during the LED blinks at the beginning of dump_task):
- press PLAY (make sure you've got a valid image there)
- press MENU to enter Canon menu
- leave the camera in this state until it completes the dump.




Misc small questions, easy to figure out with the camera in your hands:

- is D2030108 readable? [ print MEM(0xD2030108) to find out ]
- what is C8200008? max value 10000 decimal, maybe some timer? [ print MEM(0xC8200008) many times in a loop to find out ]




I've looked again into Omar (secondary core, called Eeko in DIGIC 5). Previously, this was not essential for emulating the basics. Now... I'm afraid it might be.

I was hoping to get away with emulating just the communication between the two, but...

Quote from: a1ex on September 14, 2018, 10:03:48 AM
80D 102:
dd if=ROM1.BIN of=00000000.BIN bs=1 skip=$((0x888824)) count=$((0x4700))
dd if=ROM1.BIN of=80000800.BIN bs=1 skip=$((0x88CF2C)) count=$((0xE258))
dd if=ROM1.BIN of=01AC0000.BIN bs=1 skip=$((0x89B18C)) count=$((0xADE8))
dd if=ROM1.BIN of=01AE0000.BIN bs=1 skip=$((0x8A5F7C)) count=$((0x2898F0))

The last two segments are shared with the main memory. The first two seem to be private. Not sure how much memory is actually shared and how much is available for this core only.

Memory regions configured:

00000000 - FFFFFFFF: background region                  ACR=0x121  (P:RW U:--; Inner Write-back, write-allocate; Outer Non-cacheable; Non-shared)
40000000 - 7FFFFFFF: uncacheable                        ACR=0x12C  (P:RW U:--; Inner Non-cacheable; Outer Write-back, write-allocate; Shared)
BFE00000 - BFFFFFFF: shared with main CPU and Zico?     ACR=0x124  (P:RW U:--; Inner Non-cacheable; Outer Non-cacheable; Shared)
C0000000 - FFFFFFFF: MMIO area                          ACR=0x1105 (P:RW U:--; Shareable device; Shareable; Execute never)
DFE00000 - DFFFFFFF: another shared area?               ACR=0x124  (P:RW U:--; Inner Non-cacheable; Outer Non-cacheable; Shared)
EC000000 - EFFFFFFF: ?!?                                ACR=0x121  (P:RW U:--; Inner Write-back, write-allocate; Outer Non-cacheable; Non-shared)
FC000000 - FDFFFFFF: main ROM?                          ACR=0x121  (P:RW U:--; Inner Write-back, write-allocate; Outer Non-cacheable; Non-shared)


It uses 4 bidirectional communication channels + a few others (control?) + interrupts. Messages exchanged are - so far - 2 x 32-bit each. They share memory addresses very often; this might require emulating both cores at the same time. I might be tempted to run io_trace on this core, too. Not a trivial task, but doable... given enough time to sit down and debug.

This core runs a lightweight DryOS (starts at 0, cstart at 4a4, init_task at 1180, task_create at 80003830, current_task at 1AC0058 etc). It handles image-related tasks, but also... networking!


[        init:01b865dd ] task_create(EvShel, prio=18, stack=8000, entry=1b8651d, arg=0)
[        init:80005143 ] task_create(DbgMgr, prio=1f, stack=0, entry=800050bf, arg=1e013b4)
[        init:80005143 ] task_create(SystemTask, prio=d, stack=400, entry=800050bf, arg=1e01ba8)
[        init:8000559f ] task_create(PComSysTask, prio=e, stack=1000, entry=1b8ae07, arg=0)
[        init:80005143 ] task_create(ShtCap, prio=f, stack=1000, entry=800050bf, arg=1e01d64)
[        init:80005143 ] task_create(ShtCapFpga, prio=f, stack=1000, entry=800050bf, arg=1e01d9c)
[        init:80005143 ] task_create(LvCap, prio=f, stack=1000, entry=800050bf, arg=1e01ef4)
[        init:80005143 ] task_create(ShtDev, prio=10, stack=1000, entry=800050bf, arg=1e0204c)
[        init:80005143 ] task_create(ShtDist, prio=10, stack=1000, entry=800050bf, arg=1e02084)
[        init:80005143 ] task_create(ShtSs, prio=10, stack=1000, entry=800050bf, arg=1e020bc)
[        init:80005143 ] task_create(LvDev, prio=10, stack=1000, entry=800050bf, arg=1e02274)
[        init:80005143 ] task_create(ShtVfx, prio=11, stack=1000, entry=800050bf, arg=1e025ac)
[        init:80005143 ] task_create(FmidCtrl, prio=12, stack=1000, entry=800050bf, arg=1e02740)
[        init:8000559f ] task_create(PComAppTask, prio=18, stack=1000, entry=1b8ac03, arg=0)
[        init:80005143 ] task_create(Color, prio=1d, stack=8000, entry=800050bf, arg=1e02a14)
[        init:80005143 ] task_create(MvRsz, prio=18, stack=400, entry=800050bf, arg=1e02a84)
[        init:80005143 ] task_create(MvThmRsz, prio=18, stack=400, entry=800050bf, arg=1e02abc)
[        init:80005143 ] task_create(MvThmEnc, prio=18, stack=400, entry=800050bf, arg=1e02af4)
[        init:80005143 ] task_create(MvHist, prio=18, stack=400, entry=800050bf, arg=1e02b2c)
[        init:80005143 ] task_create(MvTestChart, prio=18, stack=800, entry=800050bf, arg=1e02b64)
[        init:80005143 ] task_create(DP, prio=18, stack=400, entry=800050bf, arg=1e02d70)
[        init:01ba12fd ] task_create(PCNCom[Common], prio=1c, stack=0, entry=1ba11c7, arg=40d74a24)
[      EvShel:8000559f ] task_create(LowConsole, prio=19, stack=800, entry=1b87757, arg=0)
[      EvShel:8000559f ] task_create(ConsoleSvr, prio=18, stack=800, entry=1b87365, arg=0)



K350_OMAR[1]> ?
[CUStop]
[dmprint]
[grep]
[taskShow]
[drysh]
[CUStart]
[dmstore]
[CUPrint]
[dump]
[PCMCheck]
[memShow]

Dry[OMAR]> ?
[Kern]
extask  memmap  meminfo  mkcfg  dminfo  exobjinfo  stdlibcfg  sw  sysvers  xd
xm  prio  resume  suspend  release  sem  mutex  event  mq  exit
[DryNet]
init  cmd  wprd  ntbase  dryend  sdclk
[NetPComMem]
npcm

Dry[OMAR]> memmap
00000000 : DRY_EXCEP_VECTOR
00000000 : ATCM_START_ADDR
00008000 : ATCM_END_ADDR
80000000 : BTCM_START_ADDR
80010000 : BTCM_END_ADDR
01a00400 : heap start
           0x00056e9c(355996)
01a5729c : heap end
01a5729c : DRY_SYS_OBJS_START
           0x00004d64(19812)
01a5c000 : DRY_SYS_MEM_START
           0x00064000(409600)
01a00000 : DRY_ERREX_STACK_START
           0x00000400(1024)
01a00400 : DRY_ERREX_STACK
80000000 : DRY_EXCEP_STACK_START
           0x00000800(2048)
80000800 : DRY_EXCEP_STACK

Dry[OMAR]> exobjinfo
          MAX  COUNT   PEAK
task       68     25     25
sem       107     23     23
event     128      1      1
mq        112     24     24
mb          0      0      0
mutex      65      0      0
cond       64      0      0
timer       4      0      0
Timer1m    10      0      0
UTimer     16      0      0

Dry[OMAR]> init         # from DryNet
Dry[OMAR]> ?            # new commands appear
[Kern]
extask  memmap  meminfo  mkcfg  dminfo  exobjinfo  stdlibcfg  sw  sysvers  xd
xm  prio  resume  suspend  release  sem  mutex  event  mq  exit
[DryNet]
init  cmd  wprd  ntbase  dryend  sdclk
[NetPComMem]
npcm
[WELL]
nell-attach  nell-detach  nell-wakeup  nlog  up  down  stat  scan  join
leave  wset  wget  wep  w12get  w12set  crypto  elog  uap
[Test]
time  count  mktest  iotest  chkspi
[Net]
arp  mbufs  route  ifconfig  netstat  ping  timer  netvers



Updated annotations with some low-level details (grep for Omar):

Quote from: a1ex on February 05, 2019, 11:28:49 PM
STARTUP.log (https://a1ex.magiclantern.fm/bleeding-edge/80D/STARTUP.log) (plain startup, 21MB)
STARTUP-ph.log (https://a1ex.magiclantern.fm/bleeding-edge/80D/STARTUP-ph.log) (with exercise = photo capture, 24 MB)
LV.log (https://a1ex.magiclantern.fm/bleeding-edge/80D/LV.log) (75 MB)
Title: Re: Canon 80D
Post by: sombree on February 07, 2019, 07:59:05 PM
I have tried logging 0xD2030108 like this:
    DryosDebugMsg(0, 15, "MEM(0xD2030108) =");
    DryosDebugMsg(0, 15, MEM(0xD2030108));
    DryosDebugMsg(0, 15, "MEM(0xD2030108) = %d", MEM(0xD2030108));

but I'm not sure if that worked.

0xC8200008 was logged with this:
static void C8200008_log(int times, int delay)
{
    for (int i = 0; i < times; i++)
    {
        DryosDebugMsg(0, 15, "MEM(0xC8200008) %d / %d = %d", i, times, MEM(0xC8200008));
        msleep(delay);
    }
}

C8200008_log(100, 20);
I think it worked - you can see C8200008 values in log.

Also I was able to make a full ROM/RAM dump (camera on -> PLAY mode with valid image -> menu) - log (https://drive.google.com/open?id=1-QqhHlIO-Bd_HA3WUrE5EC4vD0U7hACB).
Title: Re: Canon 80D
Post by: a1ex on February 07, 2019, 09:02:16 PM
0xD2030108: no, it's not readable. It's not unusual - many MMIO registers in Canon hardware are write-only. They even use a mirror in the main memory for some registers they may want to read back (sht_mirror).

0xC8200008: it's not timer; it goes back and forth. In previous logs, it covers a wider range (min. 319, max 9943). Firmware subtracts it from 10000, but I'm not sure what exactly it does with the result.

Full RAM/ROM dump: can you also make one with the default MMIO range (C0000000/20000000) and CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP defined?
Title: Re: Canon 80D
Post by: sombree on February 07, 2019, 09:49:43 PM
Hm, with current tree there is no log when CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP is defined. I double checked with fresh, clean tree.
C0000000/20000000 without CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP defined - log (https://drive.google.com/open?id=1c9P4ElY1uLtzcM5MqSByVQ3i2_o1H0IP).
Title: Re: Canon 80D
Post by: a1ex on February 08, 2019, 09:00:47 PM
Decoded the log - sort of:

cat DEBUGMSG.LOG MMIO.LOG | sort -k 1n -s | ansi2txt > STARTUP.LOG
cat STARTUP.LOG | grep -E 'PRESS.*BUTTON|0xD203010' | grep -v PRESS_BUTTON_SOMETHING

1.449652   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000002
1.449655   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x00020077
1.449657   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018 ; overlay, 960x540 UYVY, see reply #251
1.449670   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000009
1.449672   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002003B
1.449674   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E ; opacity, FF everywhere, 960x540 bytes
1.650063   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000006
1.650065   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x00020077
1.650067   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018 ; overlay
1.650081   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x0000000C
1.650084   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002003B
1.650086   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E ; opacity
2.792424     CtrlSrv:fe5cf0af:83:03: IDLEHandler PRESS_PLAY_BUTTON
2.850511   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000002
2.850513   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x00020077
2.850515   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001785B ; overlay #2 (black)
2.850531   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000009
2.850533   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002003B
2.850535   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00017071 ; opacity #2 (FF everywhere)
3.137014   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x0000009F
3.137017   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002005B
3.137019   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x003F8170 ; image, 736x480 UYVY, 16px bar on the right
3.162051   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000006
3.162053   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x00020077
3.162056   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018 ; overlay
3.162070   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x0000000C
3.162072   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002003B
3.162074   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E ; opacity
4.191632     CtrlSrv:fe41bf47:83:03: DlgPlayMain.c PRESS_MENU_BUTTON
4.191660     CtrlSrv:fe5ceacb:83:03: IDLEHandler PRESS_MENU_BUTTON
4.219492   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000002
4.219494   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x00020077
4.219496   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001785B ; overlay #2
4.219513   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000009
4.219515   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002003B
4.219517   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00017071 ; opacity #2
4.331596   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000006
4.331599   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x00020077
4.331601   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018 ; overlay
4.331617   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x0000000C
4.331618   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002003B
4.331620   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E ; opacity


(https://a1ex.magiclantern.fm/bleeding-edge/80D/80D-menu.png)

Misc notes:
- both the bitmap overlay and the image use the same format (YUV422)
- previously, bitmap overlay was palette-based and image buffer was YUV422, so we used to call these BMP and YUV VRAM (or BMP and IMG VRAM)
- there are two bitmap buffers; they get overwritten (i.e. whatever was displayed during image playback is no longer in the RAM dump)
- bitmap overlay uses an opacity buffer (FF everywhere so far), see srsa's message
- bitmap overlay, opacity buffer and image VRAM are all set via [0xD2030108]
- bitmap overlay is always preceded by: [0xD2030104] <- 0x00020077
- opacity buffer is always preceded by: [0xD2030104] <- 0x0002003B
- image buffer is (always?) preceded by: [0xD2030104] <- 0x0002005B
- bitmap image in bootloader (palette-based) is preceded by: [0xD2030104] <- 0x0002002C (and [0xD2060044] <- 0x0002002C in DIGIC 7)

This might explain the result of the hack - we have modified the address of the opacity buffer. At 0x123400, the RAM dump has a large memory area filled with 0x55.

@sombree: can you perform the same procedure (full RAM/MMIO dump), but leave the camera in PLAY mode? Make sure you also have some overlays on the test image (press INFO to toggle them). No need to press MENU this time.

Regarding CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP - if you define this, but delete the associated code block from minimal-d6.c, it should have no effect on the logging process. I'm only interested in what this option does in reboot.c (during early startup, before launching Canon firmware). It will have some effect on the RAM dump.




Edit - got another idea for logging BFE and C/D ranges at the same time:

static ASM_VAR uint32_t protected_region_base = REGION_BASE(0x80000000);
static ASM_VAR uint32_t protected_region_size = REGION_SIZE(0x80000000) | 0xC700;


Translation:

001CDA9C: MCR p15,0,Rd,cr6,cr2,0:       RGNR <- 0x7       
001CDAA4: MCR p15,0,Rd,cr6,cr1,0:      DRBAR <- 0x80000000
001CDAAC: MCR p15,0,Rd,cr6,cr1,2:       DRSR <- 0xC73D     (0x80000000)
Subregion 80000000 - 8FFFFFFF: disabled
Subregion 90000000 - 9FFFFFFF: disabled
Subregion A0000000 - AFFFFFFF: disabled
Subregion B0000000 - BFFFFFFF: enabled
Subregion C0000000 - CFFFFFFF: enabled
Subregion D0000000 - DFFFFFFF: enabled
Subregion E0000000 - EFFFFFFF: disabled
Subregion F0000000 - FFFFFFFF: disabled


Can get a full RAM dump and MMIO log with the above configuration? Otherwise, same as before (camera left in PLAY mode, some overlays displayed on top of the test image, CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP defined and the corresponding code block deleted from minimal-d6.c).




Then, let's modify the display hack like this (with the same boilerplate code as before):

MEM(0xD2030100) = 2;  /* unsure; 2 or 6 */
MEM(0xD2030104) = 0x20077; /* meaning: we are going to change the bitmap buffer address */
MEM(0xD2030108) = /* address of new bitmap buffer, e.g. "0x00019018 + offset++", or 0x300000, or 0x280000, or 0x2AB000, or something allocated dynamically etc */





Another version of the display hack, this time attempting to modify the display buffer contents directly:


    while(1)
    {
        MEM(CARD_LED_ADDRESS) = LEDON;
        msleep(500);
        MEM(CARD_LED_ADDRESS) = LEDOFF;
        msleep(500);

        uint32_t * vram1 = (uint32_t *) 0x1901800;
        uint32_t * vram2 = (uint32_t *) 0x1785B00;
        for (int i = 0; i < 540; i++)
        {
            vram1[i + i * 960/2] = 0x46ff465e;
            vram2[i + i * 960/2] = 0x6d216d4b;
        }
    }
Title: Re: Canon 80D
Post by: sombree on February 09, 2019, 12:29:47 PM
C0000000/20000000 with CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP in PLAY mode with overlay - log (https://drive.google.com/open?id=1G1fWwZidx8COuQvALAIuqelyiqHdJ4hQ)
0x80000000/0x80000000|0xC700 with CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP in PLAY mode with overlay - log (https://drive.google.com/open?id=1Pv4MfMqWknIXQaGBuJxkGueuNSwWQb9a)

MEM(0xD2030100) = 2;  /* unsure; 2 or 6 */
MEM(0xD2030104) = 0x20077; /* meaning: we are going to change the bitmap buffer address */
MEM(0xD2030108) =  0x00019018 + offset++; /* address of new bitmap buffer, e.g. "0x00019018 + offset++", or 0x300000, or 0x280000, or 0x2AB000, or something allocated dynamically etc */

gives this when shutter is halfpressed - link to short slow motion clip (https://drive.google.com/open?id=1fGxyg_6V4W7VDy-YRaGkcfS6NSGoLDq2)


    while(1)
    {
        MEM(CARD_LED_ADDRESS) = LEDON;
        msleep(500);
        MEM(CARD_LED_ADDRESS) = LEDOFF;
        msleep(500);

        uint32_t * vram1 = (uint32_t *) 0x1901800;
        uint32_t * vram2 = (uint32_t *) 0x1785B00;
        for (int i = 0; i < 540; i++)
        {
            vram1[i + i * 960/2] = 0x46ff465e;
            vram2[i + i * 960/2] = 0x6d216d4b;
        }
    }

gives this - link to the image (https://drive.google.com/open?id=1Xxz-gJk2rTJS1DTFW4qU_j4akyNf_DF3)
Title: Re: Canon 80D
Post by: a1ex on February 09, 2019, 04:12:08 PM
Yay!

(https://a1ex.magiclantern.fm/bleeding-edge/80D/80D-overlay.png) (https://a1ex.magiclantern.fm/bleeding-edge/80D/80D-opacity.png)
(https://a1ex.magiclantern.fm/bleeding-edge/80D/80D-img.png) (https://a1ex.magiclantern.fm/bleeding-edge/80D/80D-play.png)


1.398333   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000002
1.398336   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x00020077
1.398338   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018 ; overlay
1.398351   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000009
1.398353   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002003B
1.398355   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E ; opacity, 0 = fully transparent, FF = fully opaque
1.615703   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000006
1.615706   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x00020077
1.615709   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018 ; BMP
1.615725   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x0000000C
1.615727   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002003B
1.615729   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E ; opacity
2.696875     CtrlSrv:fe5cf0af:83:03: IDLEHandler PRESS_PLAY_BUTTON
2.725693   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000002
2.725696   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x00020077
2.725698   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001785B ; overlay #2, black
2.725712   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000009
2.725714   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002003B
2.725716   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00017071 ; opacity #2, FF
3.037422   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x0000009F
3.037424   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002005B
3.037427   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x003F8170 ; image
3.058830   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x00000006
3.058833   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x00020077
3.058836   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018 ; overlay
3.058850   DispVCtrl:fe2085e7:fe2085e3:MMIO : [0xD2030100] <- 0x0000000C
3.058852   DispVCtrl:fe2085ef:fe2085e3:MMIO : [0xD2030104] <- 0x0002003B
3.058854   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E ; opacity


Bottom line: to print on the screen, all you need is to modify the contents of the image buffer. At least while in Canon menu, Canon code is not going to overwrite what you will draw there. The only significant difference from DIGIC 4/5 is the image format (UYVY rather than palette-based).

Yes, Canon's animations will overwrite our stuff, but that also happens on previous models, so it's not a big deal.

Quote from: sombree on February 09, 2019, 12:29:47 PM
    while(1)
    {
        MEM(CARD_LED_ADDRESS) = LEDON;
        msleep(500);
        MEM(CARD_LED_ADDRESS) = LEDOFF;
        msleep(500);

        uint32_t * vram1 = (uint32_t *) 0x1901800;
        uint32_t * vram2 = (uint32_t *) 0x1785B00;
        for (int i = 0; i < 540; i++)
        {
            vram1[i + i * 960/2] = 0x46ff465e;
            vram2[i + i * 960/2] = 0x6d216d4b;
        }
    }

gives this - link to the image (https://drive.google.com/open?id=1Xxz-gJk2rTJS1DTFW4qU_j4akyNf_DF3)

(https://a1ex.magiclantern.fm/bleeding-edge/80D/80D-diag.png)

You (80D owners) should have tested this one year ago, without waiting for me, after Ant123 published the image buffers. I think I've suggested this before:

Quote from: a1ex on January 03, 2018, 01:22:37 PM
If that works, the next steps would be:
[...]
- identifying the display buffer, printing hello world, opening ML menu...

Quote from: Ant123 on January 17, 2018, 05:45:48 PM
found in RAM dump provided by sombree:
two uyvy buffers at 0x41785B00, 0x41901800
one RGBA buffer at 0x043ED100

Quote from: a1ex on March 07, 2018, 07:44:29 AM
please don't wait for me - start experimenting on your own.

Quote from: a1ex on September 19, 2018, 04:21:05 PM
One of the "harder" tasks is figuring out how to print things on the display. On EOS, the only half-successful experiment I'm aware of is this one, for 5DS (https://bitbucket.org/hudson/magic-lantern/commits/branch/5Ds_experiments). This part is best done with the camera in one's hands, although I'm (still) trying to bring the emulation far enough to initialize the display, so I could figure it out from there. On earlier models, writing into the display buffer is enough to make things appear on the screen; DIGIC 6 and newer models apparently use some sort of Takumi GPU (look it up on CHDK forum; they already figured it out for compacts).




You now have all the low-level info you need for turning this into a Hello World, and then into a working ML port (not necessarily with all features, but I don't expect any trouble for things like intervalometer, Lua scripting or raw video). Difficulty level: just one notch above DIGIC 4/5. Previously, the difficulty level was believed to be much higher, simply because nobody tried to see what happens if you change the contents of the display buffer.

For now, my research on DIGIC 6 ends here. There are many other areas of ML waiting for my attention. In no particular order: DIGIC 2/3/4+/7/8 (new ports), DIGIC 4/5 (maintenance, firmware updates), crop_rec with arbitrary resolutions, Lua, manual lens info, ISO improvements, integrating stuff into mainline, in-camera help, user guide, bugfixes, test suite and so on (https://www.magiclantern.fm/forum/index.php?topic=23084.msg208831#msg208831).

I'll keep looking into the emulation side of things, but please don't forget - porting ML on this camera is your job. You are the beneficiaries, not me. I'll be here here to help, but I'll repeat - please do not wait for me. Start experimenting on your own.

Good luck!
Title: Re: Canon 80D
Post by: OlRivrRat on February 09, 2019, 05:20:33 PM
             @Alex

       "You (80D owners) should have tested this one year ago, without waiting for me, after Ant123 published the image buffers. I think I've suggested this before:"

       Thanks Ever So Much again for the work You have done on attempts to port ML to the 80D. Now I sincerely hope that Your apparent assumption, that there are those among Us 80D Owners that Share Your Knowledge & Abilities, is Correct. I wish I did but I definitely Do Not possess even the slightest clue of what to look for or where to look.

                                                                                  ORR ~ DeanB
Title: Re: Canon 80D
Post by: Chellyandruu on February 09, 2019, 05:32:04 PM
And sombree , he did a great job too.
Title: Re: Canon 80D
Post by: OlRivrRat on February 09, 2019, 06:36:08 PM
   Absolutely, Sombree & Ant are doing Great Work & will hopefully be able to Get The Ball To The Goal ~

                           ORR ~ DeanB
Title: Re: Canon 80D
Post by: sombree on February 10, 2019, 09:00:56 PM
Proof of concept using code from font_direct.c and disp_direct.c:
(https://i.imgur.com/g3E0VmI.jpg)
Title: Re: Canon 80D
Post by: wadehome on February 12, 2019, 07:43:36 AM
Nice work sombree! If you happen to get ML fully running on your 80D, I'd be interested in working with you remotely to get it running on my 5Div if you were interested? :)
Title: Re: Canon 80D
Post by: OlRivrRat on February 13, 2019, 08:11:27 AM
             @Sombree

       Looks as if You on to something Good ~ Keep it Rolling > Please & Thank You ~

                                                                      ORR ~ DeanB

Title: Re: Canon 80D
Post by: JosiahD on February 13, 2019, 11:34:37 PM
Thanks to those of you that put work into this project I have an 80D and can't what to get ML on it I would offer to help but would not know what I am doing. :-\
Title: Re: Canon 80D
Post by: a1ex on February 15, 2019, 04:10:09 PM
Just cross-checking some older notes:

Quote from: a1ex on July 15, 2016, 01:31:32 AM
BITMAP_VRAM              0x41707000 0x002F7C00   3111936

Quote from: a1ex on February 08, 2019, 09:00:47 PM
1.449657   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018 ; overlay, 960x540 UYVY, see reply #251
1.449674   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E ; opacity, FF everywhere, 960x540 bytes
4.219496   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001785B ; overlay #2
4.219517   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00017071 ; opacity #2

=>

opacity #2: 01707100 - 017859FF
overlay #2: 01785B00 - 01882CFF
opacity #1: 01882E00 - 019016FF
overlay #1: 01901800 - 019FE9FF


Looks OK; bitmap overlay buffers are, indeed, in the BITMAP_VRAM region hardcoded in RscMgr.


Quote from: a1ex on July 15, 2016, 01:31:32 AM
IMG_VRAM1                0x7F422800 0x003F4800   4147200
IMG_VRAM2                0x7F817000 0x003F4800   4147200
IMG_VRAM3                0x7FC0B800 0x003F4800   4147200

Quote from: a1ex on February 08, 2019, 09:00:47 PM
3.137019   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x003F8170 ; image, 736x480 UYVY, 16px bar on the right

=> image buffer (in playback mode) at 0x3F817000 - 0x3F8C37FF.

Matches IMG_VRAM2. In LiveView I expect all these 3 buffers to be used (4 on some models).

[ Side note: the addresses from RscMgr logs are uncacheable (bit 0x40000000). That means, 0x7F422800 and 0x3F422800 refer to the same physical memory address. Reading and writing - from the main CPU - at the first address will bypass the CPU caches and will access the physical memory directly. Reading and writing - from the main CPU - at the second address will use the CPU cache. ]

This is going to be useful for locating image buffers in other cameras, without analyzing the entire RAM dump.
Title: Re: Canon 80D
Post by: Ant123 on February 15, 2019, 04:25:34 PM
When will all these buffers be supported in QEMU?
Title: Re: Canon 80D
Post by: a1ex on February 22, 2019, 11:16:17 AM
When you will give me these three clones (https://www.magiclantern.fm/forum/index.php?topic=23084.msg208831#msg208831), pre-trained and ready to work ;)

Trying to find the answer to an older question, regarding DISP_SetUpdateOSDVram (https://www.magiclantern.fm/forum/index.php?topic=19737.msg210777#msg210777) on DIGIC 7. From 80D logs:

cat STARTUP.LOG | grep -a 'DISP_SetUpdateOSDVram(\|0xD2030108'
1.045569  GuiMainTas:fe44fae1:04:03: DISP_SetUpdateOSDVram(0x41882d00)(0)
1.236507     CtrlSrv:fe44fae1:04:03: DISP_SetUpdateOSDVram(0x419fea00)(1)
1.398338   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018
1.398355   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E
1.615709   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018
1.615729   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E
2.725351     CtrlSrv:fe44fae1:04:03: DISP_SetUpdateOSDVram(0x41882d00)(2)
2.725698   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001785B
2.725716   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00017071
3.037427   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x003F8170
3.058502     CtrlSrv:fe44fae1:04:03: DISP_SetUpdateOSDVram(0x419fea00)(3)
3.058836   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x00019018
3.058854   DispVCtrl:fe2085f1:fe2085e3:MMIO : [0xD2030108] <- 0x0001882E


In all of the 80D logs I've got, I could only find two arguments for DISP_SetUpdateOSDVram: 0x41882d00 and 0x419fea00. These appear to match the BMP (overlay) buffers. Their placement is a bit unusual - first we've got the opacity data, then the bitmap data, and the argument to DISP_SetUpdateOSDVram points right after these. It appears to be a descriptor of these image buffers:

xxd -e -s 0x1882d00 -l 0x2c 80D/RAM4.BIN
01882d00: 5652414d 41785b00 41707100 01000102  MARV.[xA.qpA....
01882d10: 000003c0 0000021c 41882d1c 4d454d50  .........-.APMEM
01882d20: 00000010 00000000 41707000           .........ppA

xxd -e -s 0x19fea00 -l 0x2c 80D/RAM4.BIN
019fea00: 5652414d 41901800 41882e00 01000102  MARV...A...A....
019fea10: 000003c0 0000021c 419fea1c 4d454d50  ...........APMEM
019fea20: 00000010 00000000 41707000           .........ppA

- 0x00: MARV (VRAM reversed)
- 0x04: pointer to bitmap data
- 0x08: pointer to opacity data (optional)
- 0x0C: flags?
- 0x10: xres (960)
- 0x14: yres (540)
- 0x18: pointer to some "permanent memory" structure?
- 0x1c: PMEM (identifier of "permanent memory" structure?)
- 0x20: ?
- 0x24: ?
- 0x28: pointer to BITMAP_VRAM area from RscMgr

The above structure appears to be valid on at least 5D4 and 77D (likely on all other DIGIC 6 and 7 models).
Title: Re: Canon 80D
Post by: Midnight Son on February 27, 2019, 01:37:19 AM
So just how far do you think from getting ML on the 80D is at this point?
Title: Re: Canon 80D
Post by: Walter Schulz on February 27, 2019, 07:36:36 AM
Top of page -> User Guide -> FAQ -> Troll questions section
Title: Re: Canon 80D
Post by: Nhmln on March 20, 2019, 05:06:18 AM
So what's left to figure out to get everything running on the 80D?
Title: Re: Canon 80D
Post by: a1ex on March 20, 2019, 11:43:57 AM
From the download page: somebody who has the camera and sufficient time, motivation and skill to complete the port. In other words, somebody willing and able to sit down and debug it. Don't look at me - I have more cameras than I can handle.

Long answers earlier on this page, earlier on this topic, earlier on other topics about new ports.
Title: Re: Canon 80D
Post by: Alucard on March 20, 2019, 05:40:30 PM
Quote from: a1ex on March 20, 2019, 11:43:57 AM
From the download page: somebody who has the camera and sufficient time, motivation and skill to complete the port. In other words, somebody willing and able to sit down and debug it. Don't look at me - I have more cameras than I can handle.

Long answers earlier on this page, earlier on this topic, earlier on other topics about new ports.

I am willing to help, I have the camera in hand as a spare. Currently using the A7iii as my main, so I can spare some concern for the 80D. However my coding knowledge is very basic. I can help with debugging and testing the camera if it makes things faster for you guys. Would be nice to have the ML port but I don't mind without it either as I don't see myself going back to the 80D as the main, maybe a B cam. I can help until I get rid of the 80D. So if there is anyone who want my help, hit me up.

TO EVERYONE ASKING WHEN,
Stop being a pain in the a** to who ever is working on it. If you have knowledge in this or spare time to learn C# then do it yourself. Obviously you guys have the camera with you. So if you have so much free time to ask WHEN everyday, please just go and learn how to port it. there is a lot of support material on this forum. IT WILL BE AVAILABLE WHEN IT IS READY!
I am just trying to collect the useful information for the port here and half of the thread is filled with WHEN???? please stop asking this. Obviously when it is ready you will see here and as it progresses you will see that here as well.
Title: Re: Canon 80D
Post by: a1ex on March 25, 2019, 11:58:25 PM
Committed the Hello World code contributed by @names_are_hard (200D) and @chris_overseas (5D4) - details (https://www.magiclantern.fm/forum/index.php?topic=19737.msg213945#msg213945).

Does it work on 80D?
Title: Re: Canon 80D
Post by: sombree on March 26, 2019, 06:25:23 PM
Yes, it works :)
With default "Hello, World!" text position:
(https://i.imgur.com/jDLydGb.jpg?1)
(https://i.imgur.com/noY6juM.jpg?1)
Title: Re: Canon 80D
Post by: a1ex on March 26, 2019, 07:40:09 PM
Got it. The 200D also has a 960x540 bitmap buffer, but its active area (720x480) is located at the top left. There, the message is aligned properly.

On 80D, the active area (720x480) is centered in the 960x540 bitmap buffer.

TODO: can the active area position be found in VRAM structures or register configuration, without hardcoding model-specific offsets?
Title: Re: Canon 80D
Post by: reddeercity on March 27, 2019, 11:38:48 PM
Great news !
I have a chance to get a 80D , good price ($675.00 CND)  60p 1080p  h264 , nice :)
and with the development going nicely here , it's getting to top my list of cam to get .
I'm reading on some site that 80D has 80MB's write speed on the SD Card , is this true ?
https://www.cameramemoryspeed.com/reviews/sd-cards/lexar-professional-2000x-uhs-ii-32gb-sdhc-memory-card/
(https://i.ibb.co/GR43qNk/SD-Card-write-speed-canon-cams.png) (https://imgbb.com/)

Seeing EOS R @ 179MB/s does the 80D have the same interface but just limited by canon firmware ?
If the 80D has the potential of the EOS R write speed (over clocking maybe ) then I would get a 80D to help out .

Edit: seems 80d has SDR104 bus mode , so maybe it does write at that speed .
I'm getting more interested .
Title: Re: Canon 80D
Post by: Greg on March 28, 2019, 12:14:10 AM
Quote from: reddeercity on March 27, 2019, 11:38:48 PM
Seeing EOS R @ 179MB/s does the 80D have the same interface but just limited by canon firmware ?

I doubt that 80D has a UHS-II connector.
Title: Re: Canon 80D
Post by: ddelreal on April 01, 2019, 09:05:29 PM
Dang, thought the 80D would be the one to get the April 1st announcement.
Title: Re: Canon 80D
Post by: a1ex on April 02, 2019, 08:13:23 AM
Why? All DIGIC 6/7/8 models (https://twitter.com/autoexec_bin/status/1112701492643971072) got the announcement, if you read closely.

Quote from: twitter
The best part - the above progress applies to ALL other DIGIC 6/7/8 models! At least the GUI code is going to work with little or no changes!

I just happened to pick the smallest / cheapest / most difficult to port model for myself. The M50 also has bits from PowerShot firmware, which makes it slightly different from others (but still closer to 80D & co. than any other DIGIC 5 firmware).

On 80D and maybe other D6 models (only confirmed the 5DS R so far, but not the 5D4), the only change to the GUI side would be fixing the alignment, i.e. declaring an offset. Screen buffer size is 960x540, physical screen size is 720x480, so... you do the math.
Title: Re: Canon 80D
Post by: Danne on April 02, 2019, 08:30:18 AM
M50. Already ported? Wow.
Title: Re: Canon 80D
Post by: KelvinK on April 02, 2019, 08:56:10 AM
Quote from: Danne on April 02, 2019, 08:30:18 AM
M50. Already ported? Wow.

Quote from: a1ex on April 01, 2019, 02:03:25 PM
magiclantern-fishy.2019Apr01.M50101.zip (https://a1ex.magiclantern.fm/bleeding-edge/M50/magiclantern-fishy.2019Apr01.M50101.zip)

(https://a1ex.magiclantern.fm/bleeding-edge/M50/bench.png)

8)

(https://i.postimg.cc/43RhNsbH/m50-2.jpg)
Title: Re: Canon 80D
Post by: Simour on April 07, 2019, 05:31:59 PM
I think sombree deserves to fork on the 80D. As soon as I receive my 80D I am ready to test and reassemble the logs if necessary
Title: Re: Canon 80D
Post by: ariznaf on May 17, 2019, 05:49:48 PM
Wowww.
I can see development has advanced a lot.

Thanks a lot to all people thas is participating.

May we consider the port in alpha stage?

I could not make myself an idea what is working now.

Is there a more or less simple way to try it in the camera?

I mean not having to compile source code or make changes to the camera, just something similar to installing the working firm of ML in other cameras.

May you provide a link to current firmware and way to install it, if you considere that it is time to be tested by final users?

I will like to test it and report bugs I find.

I have been waiting for many year to have a camera were I could test ML and see by my self what I just could imagine till now (previous owner of a 40D).
Title: Re: Canon 80D
Post by: andy kh on May 17, 2019, 05:54:07 PM
Quote from: ariznaf on May 17, 2019, 05:49:48 PM
May you provide a link to current firmware and way to install it, if you considere that it is time to be tested by final users?
I will like to test it and report bugs I find.

i wil provide a link for you when it is available
Title: Re: Canon 80D
Post by: nagamayasi on May 19, 2019, 05:23:04 PM
still waiting  ???
do not know until when  :'(
Title: Re: Canon 80D
Post by: andy kh on May 19, 2019, 05:26:46 PM
Quote from: nagamayasi on May 19, 2019, 05:23:04 PM
still waiting  ???
do not know until when  :'(

waiting is painful so dont wait....if you really need ML just buy a camera thats alraeady supported

and remember "If there is no ML for your cam act like there will be no ML for your cam ever.
Title: Re: Canon 80D
Post by: jdk on June 06, 2019, 06:56:02 AM
I've been working on finding stubs with k!r+ (https://www.magiclantern.fm/forum/index.php?action=profile;u=80350)
We found a list of stubs that we need to find by attempting to "make" magic lantern for the 80D and see which "undefined references" the compiler complains about.
By adding some dummy stubs/consts we were able to get the compilation to complete.

From this list we believe we have found a large amount of stubs, but we are unsure how to verify them. We looked at the finding stubs tutorial (https://www.magiclantern.fm/forum/index.php?topic=12177.0) but we are stuck at step 4.
It seems that this tutorial assumes that magic lantern is in a somewhat functional state for the camera already? How should we verify our stubs?

We've tried running the autoexec.bin we compiled earlier in QEMU with GDB attached. We've done this and gotten the emulation to go a fair way, however it stalls after a point and doesn't spit out any obvious error messages to debug

Side note: what would be the best way to share our stubs file? via a pull request or just attached to a forum post
Title: Re: Canon 80D
Post by: names_are_hard on June 07, 2019, 04:50:09 AM
Hi!  I'm fairly new here, working on 200D, so I'm not too sure about anything either.  However, I think the best way to share code is fork the Hudson repo and work on your fork.  When it gets to a useful stage, it can be merged back in.

My guess would be that QEMU is failing because of some hardware in the 80D that is not yet emulated (eg, some flash ROM, or a secondary processor).  I don't have enough experience to diagnose beyond that, and I could easily be wrong.  There are other threads about how QEMU was made to work on older hardware, which might help.

You could try building with CONFIG_HELLO_WORLD set - I've been told this is a simplified build.  Using less functionality means if you do have some stubs wrong it may not hit them.  I can build this but it doesn't boot for me.  Another approach that I have started trying is using digic6-dumper, and calling one untested stub at a time, to see if it crashes horribly.

Are you able to compare the stubs you've found with roms from a different camera?  From what I've seen, it is often fairly clear when you have it right (especially with a decompiler, not just a disassembler - Ghidra gives you this for free, if you don't have access to IDA).

The 80D is fairly close to the 200D - maybe you could help me?  I have found almost all of the stubs I need, but can't find any of the EDMAC functions.  If you can share any addresses with me that would help a great deal.
Title: Re: Canon 80D
Post by: jakepetre on June 11, 2019, 11:01:24 AM
I have an 80D on my desk. No knowledge of how to code but can learn. If someone can link me to the source code and a port tutorial I can do my best to get the port up and running.
Title: Re: Canon 80D
Post by: names_are_hard on June 13, 2019, 02:18:36 PM
Porting to a new camera will be very difficult if you have no knowledge of coding.  It's possible, but could easily take months.  It would be very helpful if you learn C, and how to read ARM assembly code.  You can learn this at the same time as some basic ML tasks that you will need later on.

While you are practising that, here are some early steps you can take:
- dump your 80D rom.  This is explained earlier in this thread
- Clone the main ML repo and learn how to build ML: https://bitbucket.org/hudson/magic-lantern/src/unified/
- get ML Qemu to build, too: https://bitbucket.org/hudson/magic-lantern/branch/qemu
- get ML Qemu working with your rom (it won't *do* much, but earlier in this thread you can see that it does start to boot)

If you need help with these things, it will be best to ask outside of this thread, as your early questions will probably be nothing to do with 80D :)
Title: Re: Canon 80D
Post by: karthiksivakumar on June 28, 2019, 06:22:28 PM
Hello world, anyone can help me how to download and install ML to 80D canon.
Title: Re: Canon 80D
Post by: Walter Schulz on June 29, 2019, 01:13:00 AM
No. Because you cannot download and install something that doesn't exist!
Title: Re: Canon 80D
Post by: OlRivrRat on June 29, 2019, 04:59:50 PM
           @karthiksivakumar

Does not exist Yet & Quite Actually & Sadly > May Never ~
Title: Re: Canon 80D
Post by: Theta Sigma on July 14, 2019, 07:26:39 AM
Quote from: OlRivrRat on June 29, 2019, 04:59:50 PM
           @karthiksivakumar

Does not exist Yet & Quite Actually & Sadly > May Never ~

Why would you say such a thing? In fact, the 200D has had some progress, and some have said there's similarity there.

Other are free to chime in, but I think you're in the minority here.
Title: Re: Canon 80D
Post by: OlRivrRat on July 14, 2019, 05:11:41 PM
      @ ThetaSigma

   I would say such a thing because logic dictates that until it actually comes to be

there is absolutely no way of knowing that it actually will ~

   Where have You seen comments of similarity between 80D & 200D ?
Title: Re: Canon 80D
Post by: Theta Sigma on July 14, 2019, 09:32:00 PM
Quote from: OlRivrRat on July 14, 2019, 05:11:41 PM
Where have You seen comments of similarity between 80D & 200D ?

8 posts above?

In any regard, my comment was in the context of an observer seeing that your post was quite negative in the face of many offering to help; not meant to imply a solution was close.

I'd simply hate to see offers to help dry up as a result of that kind of talk.
Title: Re: Canon 80D
Post by: emklap on July 17, 2019, 04:15:04 PM
I have seen offers to help several times on this forum, but I know from experience that the learning curve is steep, to say the least.

I have a VM machine set up with QEMU and ML myself and did do some analyses on the 80D Code. The difficult thing for me was to get the compiler working and make QEMU run the compiled code. The compiler was constantly showing errors due to missing libraries which I then had to to install. In the end I want sure anymore if my set-up was correct and had to stop participating.  :(

It would be a great help if someone could share a pre-setup VM image that could be downloaded and started by anyone with some knowledge of Linux and VMWare. That will give people a head-start and possibly kickstart the development. :D  Possibly with a 1 page start-up guide.

Is anyone able and willing to share a VM Image? (if it is within the rules of this Forum of course.)



Title: Re: Canon 80D
Post by: a1ex on July 17, 2019, 06:18:01 PM
Some time ago I've tested the QEMU installation script (which also installs everything you need to compile ML) on different Linux distros, and also on Mac and (Ubuntu-based) WSL. There is a getting started (https://www.magiclantern.fm/forum/index.php?topic=991.0) guide (sticky topic) and a video guide (https://twitter.com/autoexec_bin/status/913530810686418944) (sticky tweet). Of course, you won't get the GUI on 80D yet.

Main point is - the QEMU install script does not even run without a valid compiler and a "good" ARM gdb (as some versions are known not to work). It even offers to download these for you, or install them via package manager. Exactly what you say you are missing.

I'm not exactly a fan of uploading gigabytes worth of virtual machine, when all you have to do is to start with a vanilla Ubuntu distro (or Mac or WSL) and run a shell script. I'd rather see a clear bug report on where that script fails. My plan was to make the QEMU install script *the* default way to get started for development, and include it in the main README, but... if it doesn't work, then I have to fix it.

Quote from: a1ex on April 09, 2019, 02:25:06 PM
I'd also like to clean it up a bit, make sure it works on all major operating systems (anyone had trouble with the install script?) and merge the current state into mainline, as pretty much all recent developments depend on this.

Maybe you could help me with this?




Edit: looking through your previous posts, I see you got it working:

Quote from: emklap on June 14, 2017, 05:59:47 PM
:D, fresh install of Ubuntu 17 (64 BIT), toolchain 4.8.4 and qemu 2.5.0 did the trick

Am I missing something?
Title: Re: Canon 80D
Post by: emklap on July 18, 2019, 10:37:56 AM
Hi a1ex,

Thanks for your your reply. This manual will help people getting started with the environment set-up much faster. I did get a system work after several evenings of debugging and installing of libraries and apps. In the end I was not confident that I had the proper set-up because my gdb logs/screens did not always match what I saw from others . That's where a pre-configured VM image could help. Uploading gigabytes of data doesn't make sense when a vanilla Ubuntu distro is the prerequisite.

I will go through the getting started guide and a video guide once again.

If not me, the guideline will for sure help others as well.

Title: Re: Canon 80D
Post by: Elanus on August 06, 2019, 09:47:11 PM
Canon released a firmware update for the 80D. It fixes two vulnerabilities in PTP and firmware update process. Maybe they are blocking the installation of a future Magic lantern port.

Maybe they found a process to alter camera functions through PTP.

Sent from my Pixel XL using Tapatalk

Title: Re: Canon 80D
Post by: a1ex on August 06, 2019, 09:57:26 PM
Feel free to run the portable ROM dumper to find out.

(I'm expecting it to work out of the box on 1.0.3, but who knows)
Title: Re: Canon 80D
Post by: OlRivrRat on August 07, 2019, 06:51:19 PM
                     @Alex & WeEIMC

           I have Upped My 80D to 103 & now Have ROM & SFData Dumps if anyone is interested ~
Title: Re: Canon 80D
Post by: calle2010 on August 13, 2019, 03:46:22 PM
Here is the blog that describes why the security update was done by Canon.
https://research.checkpoint.com/say-cheese-ransomware-ing-a-dslr-camera/

Not so surprising, security obviously wasn't the main design goal or quality metric for Canon so far.

The blog mentions Scout debugging tool being loaded into the camera.
https://github.com/CheckPointSW/Scout
Unfortunately not more details are given. I wonder if this could be a good tool for ML porting purposes.
Title: Re: Canon 80D
Post by: chchrlam on August 15, 2019, 12:03:56 PM
Nice list of cameras onto which you can load Scout and use it as a network debugger using vulnerability CVE-2019-6001

EOS-1D X firmware version 2.1.0 and earlier
EOS-1D X MKII firmware version 1.1.6 and earlier
EOS-1D C firmware version 1.4.1 and earlier
EOS 5D MARK III firmware version 1.3.5 and earlier
EOS 5D MARK IV firmware version 1.2.0 and earlier
EOS 5DS firmware version 1.1.2 and earlier
EOS 5DS R firmware version 1.1.2 and earlier
EOS 6D firmware version 1.1.8 and earlier
EOS 6D MARK II firmware version 1.0.4 and earlier
EOS 7D MARK II firmware version 1.1.2 and earlier
EOS 70 D firmware version 1.1.2 and earlier
EOS 80 D firmware version 1.0.2 and earlier
EOS KISS X7I / EOS D REBEL T5I / EOS 700D firmware version 1.1.5 and earlier
EOS KISS X8I / EOS D REBEL T6I / EOS 750D firmware version 1.0.0 and earlier
EOS KISS X9I / EOS D REBEL T7I / EOS 800D firmware version 1.0.1 and earlier
EOS KISS X7 / EOS D REBEL SL1 / EOS 100D firmware version 1.0.1 and earlier
EOS KISS X9 / EOS D REBEL SL2 / EOS 200D firmware version 1.0.1 and earlier
EOS KISS X10 / EOS D REBEL SL3 / EOS 200D / EOS 250D firmware version 1.0.1 and earlier
EOS 8000D / EOS D REBEL T6S / EOS 760D firmware version 1.0.0 and earlier
EOS 9000D / EOS 77D firmware version 1.0.2 and earlier
EOS KISS X70 / EOS D REBEL T5 / EOS 1200D firmware version 1.0.2 and earlier
EOS D REBEL T5 RE / EOS 1200D MG / EOS HI firmware version 1.0.2 and earlier
EOS KISS X80 / EOS D REBEL T6 / EOS 1300D firmware version 1.1.0 and earlier
EOS KISS X90 / EOS D REBEL T7 / EOS 1500D / EOS 2000D firmware version 1.0.0 and earlier
EOS D REBEL T100 / EOS 3000D / EOS 4000D firmware version 1.0.0 and earlier
EOS R firmware version 1.3.0 and earlier
EOS RP firmware version 1.2.0 and earlier
EOS RP GOLD firmware version 1.2.0 and earlier
EOS M2 firmware version 1.0.3 and earlier
EOS M3 firmware version 1.2.0 and earlier
EOS M5 firmware version 1.0.1 and earlier
EOS M6 firmware version 1.0.1 and earlier
EOS M6(China) firmware version 5.0.0 and earlier
EOS M10 firmware version 1.1.0 and earlier
EOS M100 firmware version 1.0.0 and earlier
EOS KISS M / EOS M50 firmware version 1.0.2 and earlier) and PowerShot SX740 HS firmware version 1.0.1 and earlier
PowerShot SX70 HS firmware version 1.1.0 and earlier
PowerShot G5Xmark II firmware version 1.0.1 and earlier
Title: Re: Canon 80D
Post by: KenSoftTH on September 22, 2019, 04:32:53 PM
Hi,

I'm working on 7D2 port, but since it's the same CPU, can someone guide me the way to extract raw frame from video mode? I got hello world working a few months ago but don't have any idea how to continue. Please guide me a little if possible.

Thanks!
Title: Re: Canon 80D
Post by: EdgyGates on November 21, 2019, 05:35:18 AM
This thread has been rather silent. Any developments on porting ML for the 80D? The PTP vulnerability (CVE-2019-5995) show cased at Def Con 2019 seems promising for development considering they demoed a silent malicious firmware update using said exploit. If the exploit were to be utilized to install ML, this would mean many of canon's newer cameras could have ML.  (https://research.checkpoint.com/2019/say-cheese-ransomware-ing-a-dslr-camera/)
Title: Re: Canon 80D
Post by: RikySeco on November 23, 2019, 06:20:31 PM
Hi,

I'm new in the forum, but I want to know if exist something to enable RAW rec in the 80D. Please help me ahahahah.

Thanks in advance for the help.
Title: Re: Canon 80D
Post by: TheEngineer on December 30, 2019, 01:31:19 PM
Hi guys,

is there any news on ML for the 80D? I would love to have focus peaking for the 80D, just bought a Sigma 35mm f1.4 and got some focus issues with that. And I can't focus manually without focus peaking.  :(
Title: Re: Canon 80D
Post by: OlRivrRat on January 02, 2020, 05:00:16 PM
                     @Riky

           Welcome ~ But Saddly No Mag'Lan' for 80D @ this time ~ Cross Your Fingers ~

                                                                         ORR ~ DeanB
Title: Re: Canon 80D
Post by: JKerman511 on January 17, 2020, 03:48:44 AM
Very sad, I feel like this camera suffered majorly under Canon's cripple hammer given what the 70d was capable of. I hope one of those lads who seemed to be so common in late '19 comes back to work on this thing, especially given the aforementioned security thing which could give more information. I'm afraid I know nothing about this, though I have an 80d on my desk so I'm willing to do what I can.

But don't be defeatist! At least this development cycle is shorter than the one for the magical A7S3!
Title: Re: Canon 80D
Post by: Mnsmith05291 on February 09, 2020, 04:59:58 PM
I have an 80D with no knowledge of coding I can help if I am provided with files.
Title: Re: Canon 80D
Post by: Sch_Aron on April 23, 2020, 05:52:32 PM
Hi! How much longer do you reckon the development of Magic Lantern is going to take for the 80D? Is it possible that it will be done by the end of summer 2020?
Title: Re: Canon 80D
Post by: Walter Schulz on April 23, 2020, 09:50:32 PM
If you start learning programming now it might be possible to have an early port in 2023.
Title: Re: Canon 80D
Post by: Theta Sigma on May 06, 2020, 01:13:58 PM
Quote from: Sch_Aron on April 23, 2020, 05:52:32 PM
Hi! How much longer do you reckon the development of Magic Lantern is going to take for the 80D? Is it possible that it will be done by the end of summer 2020?

With what's going on? Not the best choice for a first post. I know the lockdown might have played a part in folks like heder working harder (and we're grateful), but you assume a lot.

Quote from: Walter Schulz on April 23, 2020, 09:50:32 PM
If you start learning programming now it might be possible to have an early port in 2023.

Despite the seeming thoughtlessness of the request, sarcasm isn't helpful either.
Title: Re: Canon 80D
Post by: Walter Schulz on May 06, 2020, 01:41:25 PM
Quote from: Theta Sigma on May 06, 2020, 01:13:58 PM
Despite the seeming thoughtlessness of the request, sarcasm isn't helpful either.

I really don't know why my realism is perceived as sarcasm. I offered an easy calculation for this assumption. Nobody challenged the numbers, yet.
https://www.magiclantern.fm/forum/index.php?topic=19737.msg225763#msg225763
Title: Re: Canon 80D
Post by: Theta Sigma on May 06, 2020, 02:34:51 PM
Quote from: Walter Schulz on May 06, 2020, 01:41:25 PM
I really don't know why my realism is perceived as sarcasm. I offered an easy calculation for this assumption. Nobody challenged the numbers, yet.
https://www.magiclantern.fm/forum/index.php?topic=19737.msg225763#msg225763

The post you cite doesn't help your case. ;)
Title: Re: Canon 80D
Post by: gregoffnerjr on May 29, 2020, 12:01:47 PM
While it's only been a few weeks since the last post, I'm wondering if there's been any progress on using ML with an EOS 80D?  The main (only) feature I need is the clean HDMI out as I'm going into my Mac thru a Blackmagic ATEM Mini (so the recent "fix" Canon announced is irrelevant for me)...so alternatively I'm curious if anybody could recommend a piece of hardware I could add to the mess of cables running through my "studio" to fix this issue.  The full setup is as follows:

multi cams going into ATEM Mini, into MacMini thru Ecamm to Zoom (generally) or FB Live.

I don't know enough about tech/coding to volunteer to help with builds, etc. but to the extent I can do something that would assist I'm happy to contribute with a little guidance. 

What's our next move?
Title: Re: Canon 80D
Post by: Walter Schulz on May 30, 2020, 07:43:00 AM
See reply #556
Title: Re: Canon 80D
Post by: Sam Dawjee on July 30, 2020, 10:41:55 PM
It's been 2 Years And I'm eagerly Waiting For Magic Lantern version For My 80D...Can I Install Magic Lantern in My Canon 80D..Please Le Me Know If Anyone Knows How Can I Install It In My 80D
Title: Re: Canon 80D
Post by: Aperture Science on July 31, 2020, 10:32:24 AM
Quick notice that ML is developed and released by a group of people who are doing this voluntary. Don't urge them or keep asking the same questions like "when is xxx model going to have ML firmware" if you are not a part of the developers, they are nice and friendly already by giving out the source code and the usable files out.
Title: Re: Canon 80D
Post by: Theta Sigma on September 26, 2020, 12:23:19 PM
Well, I'm very appreciative. I love that the 40D is chugging along to a usable version. Of course, I wish the 80D were in the same boat, but I am  willing to wait. :)
Title: Re: Canon 80D
Post by: [email protected] on October 30, 2020, 02:41:09 PM
Hi
I have a canon 80d and I'm willing to participate in the process of porting for 80d, i have no knowledge in coding but i can help by testing with camera.

Title: Re: Canon 80D
Post by: Walter Schulz on October 30, 2020, 07:24:12 PM
See reply #556. Seriously!
Title: Re: Canon 80D
Post by: T7i owner on October 30, 2020, 07:57:52 PM
Quote from: Walter Schulz on October 30, 2020, 07:24:12 PM
See reply #556. Seriously!
Lol
While your having fun, you should note that plenty of people will learn programming if they have a solid reason to. Giving over that advice in a more friendly manner can be the difference between them saying forget it or taking up the challenge.
Appearances do matter.
Title: Re: Canon 80D
Post by: the_jalenmr on November 19, 2020, 03:28:53 AM
Hello World! I am a brand new member of ML Forums and going in it's clear to say that there has been a stagnation in the progress of development on 80D's update (We owe great debt to A1ex and Ant, and others who have already done such heavy lifting :)).

Rather than complain about time or waste precious work towards production, I would love to help with debugging, and since the Hello World! feat has already been achieved, from this point on work is simple but arduous and long (to my understanding).

My only issue is that the bitbucket links to repositories all seem to be down in this forum? I have created an account to look at shared threads but all links to bitbuckets offering instructions on programming in the 80D section seem to be down. If a moderator or admin could kindly guide me to proper links I would be much obliged. I am not aware of the progress on the 80D given the quiet activity, I am only certain that I would love to take part in bringing all DIGIC6 units into compatibility with ML.

(https://lh3.googleusercontent.com/LeDkJ_cXi4mPWL8SqQqslJRX12XyMGGqug7oC1X_oP04UTisjS0KHw37Yj2P79QjfmFswg=s151)

I know the resolution is tiny for the image (first time HTML display in a while) but this display was the general message for the bitbucket links.

The message reads: This link has no power here
Title: Re: Canon 80D
Post by: names_are_hard on November 19, 2020, 04:44:48 PM
Hello, and welcome!

Bitbucket removed all Mercurial repositories, the new official repo is here: https://foss.heptapod.net/magic-lantern/magic-lantern

You may find that the required work is not simple.  It's not just debugging.  But we can provide assistance.  Feel free to ask questions here, or in the Discord.
Title: Re: Canon 80D
Post by: miarcoles on December 22, 2020, 09:04:00 PM
Hello, as someone far from the subject, I have a question?
Is it possible for us to get clean hdmi images with 80D? I see the same question being asked above, but I felt the need to ask again as time passed.

It is very sad not to get clean image with hdmi when auto focus on such a device
Title: Re: Canon 80D
Post by: names_are_hard on December 23, 2020, 09:59:42 AM
No, there is no ML for 80D.  There is no need to ask again - if progress is made, somebody will update this thread.
Title: Re: Canon 80D
Post by: Straight_Shooter on May 19, 2021, 03:14:16 PM
Quote from: Walter Schulz on May 06, 2020, 01:41:25 PM
I really don't know why my realism is perceived as sarcasm. I offered an easy calculation for this assumption. Nobody challenged the numbers, yet.
https://www.magiclantern.fm/forum/index.php?topic=19737.msg225763#msg225763

Well, may I challenge them? ;-)

Learning to program is one thing. But even if you have mastered C or C++ or whatever language, you are still a far cry away from being able to make any meaningful change in MagicLantern. We're talking about a complex piece of software here. To the best of my knowledge, there is no real requirement specification or design specification - if you want to get into it, you have to do so by jumping through dozens of threads on this here forum, and by reading thousands of lines of code. That is cumbersome work, to be quite honest. It's as if you wanted to climb a medium-sized hill, but then they tell you "No, you need to do the Seven Summits for starters. Then we're talking." ;-)
Title: Re: Canon 80D
Post by: Walter Schulz on May 19, 2021, 03:44:08 PM
-> Dev talk takes place at Discord. Quite talkative at times. Devs-to-be get support. Still a messy thing, true.

Title: Re: Canon 80D
Post by: yaha on June 28, 2021, 09:55:47 PM
Quote from: names_are_hard on November 19, 2020, 04:44:48 PM
Hello, and welcome!

Bitbucket removed all Mercurial repositories, the new official repo is here: https://foss.heptapod.net/magic-lantern/magic-lantern

You may find that the required work is not simple.  It's not just debugging.  But we can provide assistance.  Feel free to ask questions here, or in the Discord.

How can one get into Discord for 80D or in general? The link at the top of the forum seems to be outdated.
Title: Re: Canon 80D
Post by: Walter Schulz on June 29, 2021, 11:52:50 AM
Link works here.
Title: Re: Canon 80D
Post by: kitor on April 27, 2023, 08:16:41 AM
(https://kitor.pl/eos/img/80d_th.jpg) (https://kitor.pl/eos/img/80d.jpg)

After a quick test I have a bad stub or two (tasks view doesn't display names properly[1], in LV our menu closes almost instantly[2]), other than that seems on par with 750D.
That was a quick (< 3 hour) job after i learned how to use Ghidra Version Tracking (https://chdk.fandom.com/wiki/Ghidra_Version_Tracking_workflow_for_porting), thanks to @reyalp.

Ok, it took a week prior to that as I took the opportunity to create a proper loader script for Ghidra that should improve ghidra project quality a lot. More on that later.

E:
[1] Turns out one of task related structs is different.
[2] Fixed, wrong Canon dialog used in background.
Title: Re: Canon 80D
Post by: Theta Sigma on April 28, 2023, 08:15:45 AM
Thanks for your work. I look forward to more posts about 80D ML development. :)
Title: Re: Canon 80D
Post by: mcortes on May 11, 2023, 07:37:24 PM
Kitor thank you so much. I'm very excited to see this and can't wait to get some more life from my old canon 80d.
Title: Re: Canon 80D
Post by: chchrlam on May 14, 2023, 06:49:45 PM
Thanks Kitor. Looking forward to your next post.