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?
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.
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.
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...
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.
Volunteer found, but I need some assistance. It would take me some time to prepare the fir file myself.
- zlo
Hey,
I don't know much about coding!! But i own a Canon 80D, and you have my support any time!!
Dinis Silva
I have tested the LED Adress on Canon 80D and...BLINKS!!
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.
I can try! But I gonna need some help! :-X
Ok, photo transistor connected to Audacity, ready to record.
Just need to attach it a bit better to the cam.
Hi
An important question is do you think will be the 80d in 4k video ??
or what is theoretically expected resolution?
thx
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.
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
You can expect ML for 80D ready when it's ready.
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
Hi,
I also own the Canon 80D and am available for testing.
Please contact me via PM if interested.
Thanks!
DenW
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 :)
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
I have both 760d and 7d2
I can help
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.
LED address identified, thanks zloe :)
https://bitbucket.org/hudson/magic-lantern/commits/6ea5fa498ef0
Hey, I have an 80D and would love to help. I know a thing or two about low level programming too.
Exciting stuff! :o 8)
In deed guys let's give the developers some LOVE!! For the great work!!
Hello I want to ask if you will work with 5Ds & R?
Guys! please! it's not going faster because you are asking!
Nobody is asking for it to go faster. All I see is people offering help, and appreciation.
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)).
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 (?)
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
Done ;)
:P
404 ;)
Added my interpretation of the memory mapping to the wiki.
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.
(http://a1ex.magiclantern.fm/debug/portable-hello-world/80D/PALE180D.jpg)
8)
Here back to do some tests!!
Picked up an 80d today. Let me know how I can help.
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 !
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.
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.
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.
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 ...
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?
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
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!
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.
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.
...
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
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? :)
Boots in QEMU, but not on the actual camera (caching issues). Details on reply #40.
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
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.
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.
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
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.
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.
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 :->
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)
:)
Quote from: a1ex link=topic=17360.msg172969#msg172969
date=1475668950Yes, 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
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.
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 ;-)
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
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)
Take it to PMs guys.
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.
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.
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.
Sounds good. Have you got it working in QEMU?
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.
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.
Interesting findings @LesterL and I'll be sending you a PM re: CP Profile. Thanks for sharing!
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!
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.
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?
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
HeyThere St' Nik & Alex
I'll bet You Can You guess what I would Really Like for Christmas ~
ORR ~ DeanB
that sounds great guys. hopefully one day we'll see ML on 80D
If ML is available for 80d in the future, what do you guys think the capabilities of the camera will be?
selfishly, all I need is Focus Peaking for video!
;D
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)
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!
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!
There is a new firmware for the 80D available , maybe this will help developing an 80D ML Version ?
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...
Nice eye! I didn't even notice there was an update!
How would a new firmware help in the development of Magic Lantern?
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.
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 ;)
(https://s8.postimg.cc/asvnkyt4l/80d_qemu.png)
When we will see exactly the same picture on the camera display? :)
It's alive!
Great work @Greg!
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) ;)
@Greg
NOT FUNNY ~
ORR ~ DeanB
Is this for real or trolling ?
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.
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" :)
EnableBootDisk
0xFE5F150C(0xFC040004, -1);
DisableBootDisk
0xFE5F150C(0xFC040004, 0);
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
I do not have 80D. It's too expensive.
I have only qemu cameras :P
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.
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)
Greetings to ML developers,
I have an 80D. Contact me if you want to help with testing of early version.
Thanks in advance. :)
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!
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 :)
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.
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.
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.
Any plans with digic 6/7?
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)
It looks like no one wants a sensor in technology from 15 years ago. :P
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
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.
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" ?
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).
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.
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!!!
Thanks you for your engagement , keep the work up :)
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?
No.
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 ;)
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.
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).
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?
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.
: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)
Nice!
Very much looking forward to 80d can use magic lantern
Hi, I do not have experience with this programming language.
But is there anything I can do? I have a 80d.
any news?
Sure! (http://www.bbc.com/news)
:)
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.
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.
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
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.
Ok. Is it possible to test cache-related issues in QEMU? Or is it safe enough to test on real camera?
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.
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
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)
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)).
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)
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.
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
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!!!
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).
I've just tried this FIR file on real camera with 1.0.2 firmware - LCD just turns blue and nothing else happens :(
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)
Yes, ROM dumper works fine. This second FIR file (BOOTE80D.FIR) also works:
(https://i.imgur.com/evmIXhK.jpg?1)
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).
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.
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 :)
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 :/
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 :)
@Alex
Attempt to Download JMPE,F,G brings up "404 Not Found"
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.
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)
It's also possible that code is fine - maybe RESTARTSTART addres (or any other stub for that matter) just changed in 1.0.2.
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)
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
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.
JMPJ_80D.FIR - camera locks up
JMPK_80D.FIR - camera locks up
Awesome work @a1ex
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.
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.
"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.
-> Reply #157, #159
@Walter
Insufficient/Incorrect answer ~
Correct answer would have been >
Try This >
http://a1ex.magiclantern.fm/bleeding-edge/80D/BOOTF80D.FIR
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.
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.
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.
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
You guys are awesome !!! Keep up the hard work !
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!
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!
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
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!
@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 :/
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)
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.
:-* :-* :-*
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 !
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
@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.
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.
I totally understand. Just wanted to facilitate if you were wanting one.
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 :)
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
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.
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.
8) awesome news
(https://media.giphy.com/media/NnGGHE0muVqpO/giphy.gif)
Super!! :D
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).
awesome work @a1ex I'm gonna have to get a 80D to help with the Porting.
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.
@a1ex ok copy..
@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
@a1ex
I can confirm that it works. Weird thing - LOG000.LOG is in chinese (https://hastebin.com/woxahugocu) :o
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).
Thanks, with cat I'm getting proper output which looks pretty same as yours - link (https://hastebin.com/egixulobah.vbs).
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.
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!!
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
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)
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).
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
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.
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.
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
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.
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
Great work guy's.. :D
@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 :'(.
@t3r4n
Have you tried to dump only 0x100 (256 bytes, default value) starting from 0x10000?
Yep no success...
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!
To think the 40D and the 80D might be on the cusp of being freed from their shackles is inspiring. :)
@a1ex
I've tried this wrapper but same result as for t3r4n - in qemu it works, in camera I'm getting only zeroes.
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?
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;
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
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
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
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...
Happy New Year everyone.. @a1ex @sombree awesome job with the 80D.
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
Wow, great to hear about this.
@sombree Awesome.. :)
Committed some logging experiments - please try the intermediate changesets (not just the last one) and report their outcome.
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
Excellent - all of them worked! Committed some more.
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
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.
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.
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.
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.
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
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.
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?
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
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.
Ask Canon to change firmware. Tariff penalty for cams recording > 29:59 was ditched mid 2016.
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.
"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 ?
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.
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?
@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 ~
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.
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)
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!
I'm not sure that this is useful until emulation reaches the mzrm initialization.
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 :(
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! :)
You cannot have used ML on 350D because it doesn't exist. You may have used CHDK instead.
@ WhomEver is working on the 80D ML
Not trying to be Pushy > But > My Birthday is only about a Week away {:~))
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.
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
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)"
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.
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!
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!
Really hooo man
Oh sweet! 8) What's the next step you'd recommend?
TWEIMC
Thanks to an SFDATA Dumper & Help from Thomas Mathieson I have an SFDATA.BIN
from My 80D if anyone is interested ~
ORR ~ DeanB
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
hey Alex,i ran both test .do you need the log files?
Yes, please. Also whether the tests worked or not, and a silent picture (silent.raw, it's overwritten if you try more than once).
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. :)
I'm not sure if silent photo capture works - I can't open output file (https://drive.google.com/open?id=1qGtcjzXN6V1hzqd8oACjevhNBkBytw02) with anything.
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
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) :)
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.
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)
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
Great job guy's..
Goodluck guys! I'm new here I wish I can help. I just bought an 80d.
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.
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...
So, realistically what are the chances of getting 4k?
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
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.
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?
Right, unless someone figures out how to do mjpeg which isn't totally out of the question.
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?
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".
hey Alex,if you have any new files you want us to test on camera we are always here.just in case.
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.
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).
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).
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).
@ Alex
Sweet ~ & the DNG opens in IridientDeveloper Beautifully ~
works well in adobe ACR. looks good too!
To early to open a bottle of champagne? :P
Great work Team..
13 stops dynamic range
On sensor ADC
Dual pixel AF
80MB/s write speed
Couldn't shoot cats with it.
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 |
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.
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.
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.
@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.
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.
@ 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?
Hm, it locked up.
Let's try again on a different start address (same link).
@ Alex
Getting Closer? > https://ibb.co/eeZ9UH
@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 ???
Screen colors have nothing to do with card contents.
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.
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.
@a1ex
On your autoexec.bin I don't have these warnings about inconsistency.
Last commit 7eaab92:
(https://i.imgur.com/5qTDKGa.png)
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.
@ Alex
Is there a way to Uninstall/Reset the BootFlag on the 80D so as to try a Reinstall?
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.
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.
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.
its working on mine.
(https://thumb.ibb.co/hbewwx/80d.jpg) (https://ibb.co/hbewwx)
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.
@OlRivrRat
Did you make your card bootable after shrinking partition?
@ Sombree
Yes ~
How? What program did you use?
@ Sombree
Same 1 I Always Use > MacBoot ~
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.
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'.
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.
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 :)
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.
@alex how is it coming with the 80D?
I have a brand new one and might help if you need it.
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.
How can I help sir? I have an 80d and maybe can run some tests.
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.
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
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)
Read reply #313
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!
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).
@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.
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
@Kotik
As I posted back in Reply #265 > I have an SFDATA.BIN from My 80D if anyone is interested
@OlRivrRat
Did send you a 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
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).
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!
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
@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.
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?
Nothing shows up on the SD
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.
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 .
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?
@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.
@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)
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?
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
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
Best of luck Kotik. I spent too little time on qemu concepts but I'm certain it's worth every minute digging.
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.
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)
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.
Cool, my credentials worked over here so will keep an eye on this issue.
Many thanks Danne! ;)
@Danne
OK Danne, Feelin Gutsy > Going to give Compiler a Shot. Got to step3 & 80D is not on list so what do I choose
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...
Yes, qemu install
Thought I'd try 100D but it isn't on list either ~
I have the 100D folder in my qemu folder. Checked inside the installed folder?
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 ~
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.
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
@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.
@Danne
That link gives > "Link Has No Power Here"
@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 ~
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
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$
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.
I do not "qemu-eos" so guessing I never got all the way through Via Compiler before getting Stymied
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$
& 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$
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 ~
@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)!
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.
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
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 `&'
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
@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!
If running the qemu installer on that machine the script will skip .bash_profile as it looks now. Should work. At least with dbg...
@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?
@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.
@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.
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...
@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!
@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.
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.
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)
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).
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)
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.
Attempting to Run this
https://a1ex.magiclantern.fm/bleeding-edge/80D/DMPF_80D.FIR
on 258MB SD on My 80D causes Soft Brick.
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=
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)
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
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.
@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.
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).
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
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).
You mean something like this (https://bitbucket.org/hudson/magic-lantern/commits/83be266e66f00480a6b9eee47ebc60010ce3b7e2)?
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).
Sadly, it's way beyond my coding skills ???
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).
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.
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
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).
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?
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
OK, that makes sense. Can you redo a regular startup with 5 seconds delay? Reason: timestamps printed with %05X are unreadable after the overflow.
Sure - link (https://drive.google.com/open?id=14af4YMLj9SJ6YcxEBczrJoObIe1bpVMN).
1 - no lens,
2 - with lens,
both with 0xD400000C.
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.
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).
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).
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
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.
Keep going at it boys! were rooting for you :o :o :o :-*
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.
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.
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
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?
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...
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...
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!
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.
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)
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.
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.
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.
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
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.
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!
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?
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.
@ 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 .
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
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.
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.
Hi.
Can you give me dump for this cam?
Thanks a lot...
@Critix
Yes > Provide EMail Address ~
ORR ~ DeanB
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.
- You have to have the matching ML ".fir" ("boot-flag" [developer mode] firmware update/patch) for the installed original Canon firmware
- Once the developer mode is activated on the camera, the ML flavoured SD card can be inserted (Canon original with ML loads) or a non-ML flavoured SD card can be inserted (Canon original without ML loads)
- 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.
- Having register access can also mean to be able to destroy (not only brick) the camera.
- There are "soft" bricks, which can be "solved" by turning off the camera and ejecting the SD card.
- 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
That being said (and maybe corrected by you)...
- What is the current ML firmware version level - if there is any - to unlock the development mode and load code/ML from SD card?
- "Recently", Canon released the 80D original firmware version 1.0.2, which I am planning to upgrade to if it isn't already installed on the camera. Is 1.0.2 supported by the current "implementation" (I heard the "debug screen" and "dump screen" works)?
- 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?
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).
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.
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.
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 !!
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:
- Is this assumption likely correct? Or did I wast my time?
- If this assumption is correct and the emulation is ceasing because of this NFC error, what are the next steps? NFC emulation?
- Can NFC emulation be skipped by NOPing NFC related tasks in the ROM1.BIN (for the purpose of camera emulation only)?
- If the NFC needs to be emulated, how would that be done and where should the code go? (remember I'm new to this...)
- Can anyone see anything to indicate that I have identified the wrong chip?
Thanks for your help, and hopefully this info will assist somehow.
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/
Is there a a download for the 80d yet?
Please Please Please say yes!! T^T
please download link for canon 80d
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???
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.... :-[
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
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
I agree :)
Yes! I would most definitely support a kickstarter or any thing in that matter to have someone who could work on this port!
So what exactly do we need to do?
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.
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
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
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
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.
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
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)
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)
@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
I compiled and the camera blinks for 1 minute,did all the test but no logs are saved.
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.
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?
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 :)
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.
Yep, no crash, just a little longer camera start up :)
As for CONFIG_80D - you're right, it's defined by the Makefile.
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.
https://www.dropbox.com/s/g8u4gmchldcngxr/DEBUGMSG.LOG?dl=0
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.
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.
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.
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.
Does MMIO trace work in LiveView mode?
On EOS M3 io_trace causes crash in Rec mode.
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)).
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.
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?).
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).
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.
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).
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.
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)
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)
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.
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)
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).
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?
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).
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;
}
}
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)
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!
@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
And sombree , he did a great job too.
Absolutely, Sombree & Ant are doing Great Work & will hopefully be able to Get The Ball To The Goal ~
ORR ~ DeanB
Proof of concept using code from font_direct.c and disp_direct.c:
(https://i.imgur.com/g3E0VmI.jpg)
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? :)
@Sombree
Looks as if You on to something Good ~ Keep it Rolling > Please & Thank You ~
ORR ~ DeanB
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. :-\
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.
When will all these buffers be supported in QEMU?
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).
So just how far do you think from getting ML on the 80D is at this point?
Top of page -> User Guide -> FAQ -> Troll questions section
So what's left to figure out to get everything running on the 80D?
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.
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.
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?
Yes, it works :)
With default "Hello, World!" text position:
(https://i.imgur.com/jDLydGb.jpg?1)
(https://i.imgur.com/noY6juM.jpg?1)
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?
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 .
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.
Dang, thought the 80D would be the one to get the April 1st announcement.
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.
M50. Already ported? Wow.
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)
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
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).
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
still waiting ???
do not know until when :'(
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.
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
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.
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.
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 :)
Hello world, anyone can help me how to download and install ML to 80D canon.
No. Because you cannot download and install something that doesn't exist!
@karthiksivakumar
Does not exist Yet & Quite Actually & Sadly > May Never ~
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.
@ 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 ?
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.
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.)
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?
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.
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
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)
@Alex & WeEIMC
I have Upped My 80D to 103 & now Have ROM & SFData Dumps if anyone is interested ~
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.
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
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!
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/)
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.
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. :(
@Riky
Welcome ~ But Saddly No Mag'Lan' for 80D @ this time ~ Cross Your Fingers ~
ORR ~ DeanB
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!
I have an 80D with no knowledge of coding I can help if I am provided with files.
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?
If you start learning programming now it might be possible to have an early port in 2023.
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.
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
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. ;)
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?
See reply #556
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
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.
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. :)
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.
See reply #556. Seriously!
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.
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
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.
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
No, there is no ML for 80D. There is no need to ask again - if progress is made, somebody will update this thread.
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." ;-)
-> Dev talk takes place at Discord. Quite talkative at times. Devs-to-be get support. Still a messy thing, true.
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.
Link works here.
(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.
Thanks for your work. I look forward to more posts about 80D ML development. :)
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.
Thanks Kitor. Looking forward to your next post.
Quote from: 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.
Hi Kitor I bought a Canon 80D back when it was newly released and anxiously waited for years for a magic lantern version for my camera the years passed by and nothing but I am still using my 80D
And apparently so are other people too
When I first saw your posts about trying out the firmware on the 80D I was happy like as if I was a child on Christmas :D
But a year has passed and no new posts on the subject from you or any other dev
So I went to discord and asked about it and they told me that there never will be a 80D version of magic lantern
And I wonder if this is true or if you just don't had the time to finish your work but plan to eventually
Could you please update us of your intentions about the 80D firmware ?
Also is the 80D for some reason (if so which ? ) hard to "crack" and put magic lantern on it? I am asking because I think quite a few models got magic lantern a lot sooner than 80D
And 80D is a really good camera for both amateurs and even professionals (aside it not being FF ) so I can't see why it's so much neglected.. :(
Quote from: papajo on April 28, 2024, 08:22:05 PMSo I went to discord and asked about it and they told me that there never will be a 80D version of magic lantern
Who said that?
Quote from: papajo on April 28, 2024, 08:22:05 PMCould you please update us of your intentions about the 80D firmware ?
There are no
intentions. Digic 6 is just hard to get working due to its unique design. It is just easier in later models running Digic 7 and 8.
Remember this is just a hobby project of a few people. We work on it when we feel like it, and work on what we want. I have a pile of 10+ Canon cameras and tbh I favour EOS R as it was my re-entry into Canon ecosystem - and also my entry into Magic Lantern / camera hacking world.
Quote from: papajo on April 28, 2024, 08:22:05 PMI think quite a few models got magic lantern a lot sooner than 80D
Then you are wrong - right now they exist just two "builds" of Magic Lantern for newer models: one for EOS M50 - which does nothing except card benchmark. And one for 200d which also doesn't have almost any features - it was released as a proof of concept that project is still alive.
I think you should get familiar with Current state of Magic Lantern project (https://www.magiclantern.fm/forum/index.php?topic=26852.0). This will answer many of your questions.
Quote from: kitor on April 30, 2024, 10:11:42 PMWho said that?
Well, if taken literally: You. https://discord.com/channels/671072748985909258/844581352082898975/1206757404230942721
Let's taken it for granted papajo is not accustomed dealing with questions to engineers/programmers and mind set embedded in their answers. ;-)
First of all thank you for your response also I am sorry if I seemed abrupt or for some things that didn't get through as I thought, it is because I am not a native English speaker.
Quote from: kitor on April 30, 2024, 10:11:42 PMWho said that?
I can't remember his handle cause this discussion was months ago or at least a few weeks but I think he avatar had a joker face (from some cartoon version of the Batman series) and posts a lot or at least he did wen I went to discord.
Quote from: kitor on April 30, 2024, 10:11:42 PMThere are no intentions. Digic 6 is just hard to get working due to its unique design. It is just easier in later models running Digic 7 and 8.
Remember this is just a hobby project of a few people. We work on it when we feel like it, and work on what we want. I have a pile of 10+ Canon cameras and tbh I favour EOS R as it was my re-entry into Canon ecosystem - and also my entry into Magic Lantern / camera hacking world.
Yes I understand that and I am not entitled or something it's just that since I saw your posts I got my hopes up but after a year I didn't see any other progress+ the discord "confirmation" I got for it never being released that made me ask you in person since maybe that guy's reply might have been just his opinion
When I used the word "intentions" I meant if that guy from discord was right saying that you quit the efford or if you feel like it would be plausible for you to get back at it some time.
Thanks also for mentioning that the digic 6 is has a unique design that hinders the porting sounds interesting and I will research more on that.
Also I respect your stance about wanting to focus more on R series and obviously I don't want to give you directions or anything with what I'm about to say but I just want to share my opinion which is that mirrorless cameras getting updated more frequently now and substantially because they are the new tech...
But DSLR cams don't get the same firmware attention and also have a lot more "juice" to squize out of them cause (given the capabilities added "post mortem" for cameras as old as e.g the 50D) their features plausibly were undercut by canon so that they not "eat up" sales from the more expensive models in the same line.
So in that sense getting magic lantern for older models will produce more "bang for the buck" where "bang" is the gap given by increased capabilities compared to stock firmware and "buck" the time an engineer gives to port magic lantern to it.
Again just my piece of mind I don't try to imply or assert something.
Quote from: kitor on April 30, 2024, 10:11:42 PMThen you are wrong - right now they exist just two "builds" of Magic Lantern for newer models: one for EOS M50 - which does nothing except card benchmark. And one for 200d which also doesn't have almost any features - it was released as a proof of concept that project is still alive.
I think you should get familiar with Current state of Magic Lantern project (https://www.magiclantern.fm/forum/index.php?topic=26852.0). This will answer many of your questions.
I meant the magic lantern version was ready in less time (since a camera's release counting up to when it got a magic lantern version ready for it ) I didn't specifically mention "camera models newer than 80d"
If it seemed like that I'm sorry as I said I'm not a native English speaker and I usually post to forums a little bit before going to bed :P
Thanks again for taking the time to respond :)
P.S @mods would it possible for me not to have to paste that 3 line text security question along with the handle etc cause I have to log out because somehow if I log in with one browser in my tablet and check to "keep me logged in" I am some how logged in any other browser I have too and the same goes for logging off...
Now for example I was writing my reply in chrome and opened Firefox (where I never logged into your forum from there before ) and I was already logged in, I logged out in order to select the account creation option and copy the huge text "I am no spammer etc etc ..."
And that lead to me not being able to post on chrome cause it logged me off from there too and I had to rewrite the entire reply on my tablet with my thumbs which was mentally and physically exhausting thanks 👍