Hi there folks,
I'm excited about this new camera but I will buy mine at December which is long time to wait without any info so if you have a 7DII already please share your experiences and thoughts about it.
Also very interested to port ML to it.
Lots of reviews online.
I figure I'm one of the first in my area to get one, been on the pre-order list since forever ago. Five consecutive 0s in my serial number lol.
10FPS is amazing. Was really missing it when I upgraded to the 5D3. Such a beautiful sound.
Frame rate doesnt suffer immensely when you have a SD card inserted. Used with a UHS SD card pictures transferred fast. not sure HOW fast since there is no ML yet, but its fast.
the grip feels sharper than the 5D3, it fits in your hand very snugly, somehow it just feels BETTER than the 5D3 (which is already a step ahead of the 7D Mk I in my opinion)
Silent shutter is super quiet and reasonably fast. Like, library quiet. lol.
ISO performance is greatly improved. Anyone saying its just a re-hashed 70D sensor needs to boil their bottom. Images are fantastic!
AF system reaches further to the sides, tho not far enough up and down in my opinion. Still, its an improvment and its pretty excellent.
SO MANY SETTINGS. Im going to be reading and re-reading this manual for months making sure I know the ins and outs of this camera. So many little features.
LEVEL IN THE VIEWFINDER?!? Yes please! Always on level in the viewfinder, among other useful information making full use of the transparent LCD display.
The list goes on and on and on, this is an upgrade to the 7D in every way.
ONLY GRIPE so far: They COULD have put a touchscreen on it. Im not sad its not a flippy screen, those have their place but not in a high end camera IMO, and a touchscreen COULD be useful for video or live view focusing while not creating extra bulk or interfering with weather sealing.
Oh, and they could have kept the old battery and wifi grips instead of charging another ludicrous $800 for a wifi grip. Im going to be seriously looking into other options, that's for sure.
Last tiny gripe is that the raw files dont work anywhere (yet) tho that will be fixed next update, reportedly.
Thanks for the report!
I'm curious what card speed it can fully utilise. I'm planning to buy the 160 mb/s cf and the 95 mb/s SD from sandisk but maybe the camera's interface is not fast enough especially the SD interface like in other canon cameras.
I'm really interested in the 7D mkii also - looking to upgrade body finally and kind of stuck inbetween getting a 7d mkii or just springing a few hundred extra and getting a used 5d iii. Magic Lantern is playing a big part of my decision making process although I've heard extremely good reviews about the 7d mkii so far :D
Lots of discussions on the Canon Rumours site. Take a look there.
Not so enthusiastic for quality improvements: http://www.dxomark.com/Cameras/Canon/EOS-7D-Mark-II :P
DXO's score is heavily weighted to low ISO. For a good discussion of why this may not be so important to the 7D2, take a look at https://www.youtube.com/watch?v=FTuBr0W0Zhw.
For an deeper look at the considerable quality in the 7D2 sensor that Magic Lantern might be able to tap, take a look at Roger Clark's analysis. (http://www.clarkvision.com/reviews/evaluation-canon-7dii/index.html)
There's a lot to like about the 7D2 and Magic Lantern would be a fantastic addition.
I've got my camera yesterday and I'm eagerly waiting to try it (today is another day with traveling to the rainforest).
It has fw version 1.0.2
Another review:
http://www.clarkvision.com/reviews/evaluation-canon-7dii/
"The data shown here for the Canon 7D Mark II indicate that the camera is operating at near perfect levels for the sensor with lower apparent read noise and impressively low pattern noise compared to all other current Canon cameras tested and better than that in the 7D Mark I. This means that for high signals, noise is dominated by photon statistics. Sensitivity is improved 14% over the 7D Mark 1, and the sensitivity per square micron is the highest that I have measured for any Canon camera to date.
The approximately 10x lower thermal dark current is a game changing factor, making this camera the top Canon camera for long exposure low light photography that I have tested. The superb autofocus system, comparable to Canon 1D series pro cameras with 65 autofocus points is another game changing innovation, as the camera is at a price point that is affordable to more people."
Hi ! I have the 7D2 since 15 days
Very nice !
A question about Magic lantern :
Do you know when the 7DmkII port coming ? Some news ?
Thxs
Top of page -> User Guide -> FAQ -> Section "Troll Questions" -> Last one
(http://pel.hu/tn/pel.hu.blog.0015.01.7D000825.jpg) (http://pel.hu/pic/pel.hu.blog.0015.01.7D000825.jpg)
(http://pel.hu/tn/pel.hu.blog.0017.01.7D001316.jpg) (http://pel.hu/pic/pel.hu.blog.0017.01.7D001316.jpg)
The bat picture. Perfection.
It seems that the 7D2 is the first Canon camera with SD slot faster than 45MB/s
SD SanDisk Extreme Pro 95MB/s - http://www.cameramemoryspeed.com/canon-7d-mark-ii/fastest-sd-cf-card-comparison/
74.9MB/s :o
So CF + SD will be about 175 - 200MB/s
The 7D Mark II is just short of being my ideal camera. The only 2 things I want that it lacks is a touchscreen for touch AF and a sensor big enough to capture raw video at 1920 width. It's unfortunate that the CF slot is fast enough to record full 1920x1080 raw like the 5D3, but the sensor is just a hair too small to reach 1920. The max width will be 1824, which is obviously close but still not pixel-for-pixel after stretching (unless I'm misunderstanding something about how ML raw video works). Because of these 2 things, I don't think it's worth the money to me, even if ML was ported to it. I guess I keep waiting! :P
Quote from: DigitalVeil on January 02, 2015, 04:24:25 PM
but the sensor is just a hair too small to reach 1920. The max width will be 1824, which is obviously close but still not pixel-for-pixel after stretching (unless I'm misunderstanding something about how ML raw video works).
Well, even having 1920 pixels doesn't mean you'll get a full true 1920px output, because of the CFA (http://en.wikipedia.org/wiki/Color_filter_array), and the demosaicing process, which is already having to do interpolation. I doubt there would be any noticeable difference from 1824.
You would actually much more likely notice a difference between something recorded at much higher than 1080p resolution in raw and then downscaled to 1080p after demosaicing, compared to something recorded directly at 1080p raw resolution.
This is all because each raw pixel only contains one color value (either red green or blue), and the values of the other colors must be interpolated from the neighbors. "Normal" image/video data contains 3 color values per pixel, and no interpolation is needed. In this sense it's even sort of a "lie" to call the 5D3's 1080p, true 1080p since there's still interpolation going on.
Typically the demosaicing interpolation is very good, because there is normally a very strong correlation between the color channels. However, it's not perfect and if you're going to nitpick about the difference between 1824 and 1920 (a difference of less than 1%), then I'm going to nitpick about demosaicing.
Lets not even get into potential line skipping/aliasing issues :P
I think the camera has so much potential, with ML it could be a jackpot... :)
The CF and SD card interface is already fast enough for RAW video and there is an USB 3.0 to get more speed.
I'm happy to help any developer with testing, dumping, etc.
I have Sandisk 160 MB/s CF and 95 MB/s SD for speed test.
Quote from: Pelican on January 03, 2015, 12:44:50 AM
I think the camera has so much potential, with ML it could be a jackpot... :)
The CF and SD card interface is already fast enough for RAW video and there is an USB 3.0 to get more speed.
I'm happy to help any developer with testing, dumping, etc.
I have Sandisk 160 MB/s CF and 95 MB/s SD for speed test.
Pelican, you made the original 7D port right?
No.
g3gg0 did it.
I couldn't even port ML from 2.0.3 to 2.0.5 on 7D... :(
But I can help to the more skilled developers with testing, finding stubs, etc.
Unfortunately none of them interested to do it.
Quote from: Pelican on January 12, 2015, 04:55:24 PM
No.
g3gg0 did it.
I couldn't even port ML from 2.0.3 to 2.0.5 on 7D... :(
But I can help to the more skilled developers with testing, finding stubs, etc.
Unfortunately none of them interested to do it.
Gotcha. It's a shame there hasn't been interest in the 7D2 yet, it could be the first camera capable of recording max-res raw at 48fps or even 60fps with no squashing.
Now that I have spent more time with it...
The SD card slot is FAST. Not sure how fast, but its fast. I have SD cards I benchmark on my computer at 80MB/s (write) and on the 5D3 I noticed they were slow to write. As we know the 5D3 had horrbile write speeds to the SD slot. On the 7D2 however I notice no slowdown. I do not hesitate to write jpg to the SD and raw to the CF slot.
The buffer is large however it can fill fast at 10FPS. It also clears fast with high speed cards (my CF is personally benchmarked at 110MB/s write)
The biggest upgrade that people can notice off the bat is the viewfinder.... OMG the viewfinder is nice. I love how customizable it is.
Under the hood, the 7D2 autofocus system is super awesome. There are a tonne of settings, like the 5D3, but once you have it dialed in you can set it to react the way you need it to for that scenario. My hit to miss ratio is better than ever!
I can't wait for developers to start working on this gody. I would gladly chip in if a dev decided they were going to go at it full time.
Quote from: Pileot on February 13, 2015, 05:13:42 AM
The SD card slot is FAST. Not sure how fast, but its fast.
You can see how fast it is:
Quote from: Greg on December 27, 2014, 02:15:54 PM
It seems that the 7D2 is the first Canon camera with SD slot faster than 45MB/s
SD SanDisk Extreme Pro 95MB/s - http://www.cameramemoryspeed.com/canon-7d-mark-ii/fastest-sd-cf-card-comparison/
74.9MB/s :o
So CF + SD will be about 175 - 200MB/s
Two full resolution sample shots from me:
http://pel.hu/pic/7D005282_Full.jpg
(1/320, f/5.6, ISO 200, 300/2.8L IS, handheld)
http://pel.hu/pic/7D005225_Full.jpg
(1/800, f/5.6, ISO 100, 300/2.8L IS, handheld)
That is sharpness!
Nice!
Very sharp!
Indeed, it is spot on!
I bought mine back in Nov '14 to replace my old 7D. Great camera!! Very happy overall and looking forward to a ML port.
...but I'm having forward focus problems on all of my Canon lenses... :(
I've been slowly using the DotTune method for all of them and getting better results. Highly recommend calibrating before going on holiday. Cheers!
https://www.youtube.com/watch?v=7zE50jCUPhM (https://www.youtube.com/watch?v=7zE50jCUPhM)
Is there any way to help sponsor a 7D MK2 for an accomplished developer? I donated some to the generic magic lantern bitcoin address when I still had a 70D, but would like to help contribute towards a 7DMKII port. Even $20-50 from relatively few people would be able to cover a dev-cam.
It sounds like the original 7D was a bear, something about the dual DIGIC right?
EDIT: I realize it might not even be a matter of finances, but more of time. I understand the complexity of coding, and am not suggesting giving someone a 7DMK2 would magically produce a port unless they were actually interested in doing the extensive and time consuming work involved.
Unless you convince g3gg0 to do it -> there will be no ML for 7D2.
He did the magic breakthrough with the 7D...
hey.
its mainly an issue of spare time.
we need more devs who can keep up maintaining the supported models.
before that isnt resolved, its reckless to add another model.
Hi,
I do have a 7DII and and some knowledge in reverse engineering and embedded development. The current problem apparently is that the known ways of getting the firmware fail with the 7DII.
Hi i know is not good asking on developing release times and i know developers are really busy at the moment.
But like many others i really need to have a ML on the 7D MKII .
Is possible to have any general idea on many time it can take to be compiled? weeks? months? 2-3-6 ?
is possible to make a donation specific for this developing?
Thanks in advance to all ML programmers.
I received my 7D mark II the last Saturday, great upgrade from the "old" 7D I was using until now with ML since it has been available.
I already participated to ML development for the 7D, mainly back porting code to the main trunk like FPS override, raw recording display indicator,... Also fixing some code to let it work for 7D, like fullres silent pics,...
I'm very interested to participate on a 7D mark II port !
As I understand it we are stuck now on the firmware dumping as there is no firmware upgrade available ?
See 70D thread: No firmware update but porting is going on.
Quote from: Walter Schulz on April 13, 2015, 04:25:02 PM
See 70D thread: No firmware update but porting is going on.
Yes, I did and have understood that the first action we have to do is to dump the firmware memory using a signed code, I'm right ?
That's for g3gg0 and a1ex to answer, I think.
aside from that my main concern is that we do not have developers who provide long term support.
It would be great to see the potentials in the 7D2... Right now it could be the best camera for RAW video.
Agreed
Yeah, with DualPixel AF and RAW it could be best camera with price tag <3k$, but probably never happen.
Stepping up from a t3i I've been enjoying my 7D2 for photography work but I'm really excited to see what it will do with ML installed. I'm crossing fingers hopefully that happens soon :)
We really need to have ML run on the 7D MKII.
Knowing how the things are happening here, unless a keen developer does not have 7Dmk2 in his hands and a lot of spare time - won't happen. Dual processor is difficult without knowledge how the load is arranged and managed. and for 7Dmk2 it is DUAL DIGIC 6 (5Ds & 5Dr also), so new processor, so that would take more time. And also there are many features that have to be finished for current cameras, before jumping to new ones.
yes 7Dmk2 seams to be very promising, with the few glimpses I had it in my hands and could do tests - I love the results.
Could a dev outline how to get the firmware?
Right now the only starting point I know is waiting for an update.
As far as I know the actual firmware dumping method won't work for dual-digic6 (yet to be confirmed for single digic6 (http://www.magiclantern.fm/forum/index.php?topic=14990.msg146952#msg146952) @a1ex 8)). So you have to wait for an official 7D2-firmware to be released by canon.
Canonrumours have written about a 7D2 firmware update coming in the next few weeks, and that should make a magic lantern port possible, right? Of course a dev will have to spend time on it tho. If it is a matter of financials i would love to support it. I run ML on my T3I right now, and i really want to be able to use magic lantern as fast as possible when i pick up a 7D2 by the end of the month.
http://www.canonrumors.com/2015/05/eos-7d-mark-ii-firmware-1-04/
Sources say the first firmware UPDATE for the 7D2 will be available tomorrow!
It is already available here : http://support-ph.canon-asia.com/contents/PH/EN/0400206202.html !
A new firmware is available!
http://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos_7d_mark_ii.aspx?type=firmware
Lets get the ball rolling.
Should be out by x-mas if not earlier... :P
You lucky ones. The fw update popped up rather fast. I am still awaiting one for 70D :P
It seems they've changed the decipher keys for the updater (or just haven't slept enough). :-(
that would be bad news. @a1ex can you confirm?
No. My fault. Just haven't found the 'gaonisoy' string in the updaters...
pheeeew. Keep us updated about your progress. If you need in any case some help with porting I would gladly help.
I'd also gladly help if needed
Really hoping ML comes to the Canon 7DMII. I just purchased this awesome camera for video work dealing with weddings, music videos, special events, sports, etc. It has been marketed as a lightening fast camera (and is) and putting ML on it would put the 7DMII over the top and be what every cinema photographer dreams of! (especially being under $2,000) If there is any way I could donate money to help develop it please direct me to the site. Being a teacher I have summers off, wishing I knew all the dev stuff or wishing I could donate all my free time I have coming up haha :D But seriously if there is any way I can help, big or small, let me know!! ML IS A MUST ON CANON 7DMII
Clean HDMI out to record Prores 422, No moire , 1080 60P, the The poorman dream machine
It's only missing one thing :-X
yeaaa ML
Last night, g3gg0 and I took a quick loook at the firmware update, and here are our first notes:
- instruction set is Thumb-2. Juicy stuff here: http://chdk.setepontos.com/index.php?topic=9992
- both master and slave start at 0xFE0A0000, in ARM mode, no gaonisoy
- both of them switch to Thumb mode from 0xFE0A000C
- during startup, the following things are copied to RAM:
- on master:
- from 0xFEC1A798 to 0x00000000 size=0x3C9D (at FE0A00B2)
- from 0xFEC1E438 to 0x80000800 size=0xB37C (at FE0A00C6)
- from 0xFEC297B4 to 0x00004000 size=0x37FB4 (at FE0A00DA)
- on slave:
- from 0xFE472804 to 0x00000000 size=0x3C9D (at FE0A00B2)
- from 0xFE4764A4 to 0x80000800 size=0xB144 (at FE0A00C6)
- from 0xFE4815E8 to 0x00004000 size=0x8500 (at FE0A00DA)
- caching bit is still 0x40000000 (from alloc_dma_memory FE6834D0)
- there appears to be an extra memory block at 0x80000000 (not sure how big)
- MMIO range expanded (C0000000 - DFFFFFFF); CHDK guys mentioned it as well
- to enable the UART console (TIO) on master firmware, patch 0xFEC4DCBC from 0 to 1
- there is a FPGA which handles SD, CF, USB and "SYS"
- there is hardware integer division (SDIV)
Interesting strings:
OpenGL ES-CM 1.1
OpenGL_ES OpenVG
lvae_afledon
PROP_LED_LIGHT
Still unknown:
- card LED address
Early QEMU logs ( source at https://bitbucket.org/hudson/magic-lantern/commits/branch/qemu ):
DRYOS version 2.3, release #0055+p4
Copyright (C) 1997-2013 by CANON Inc.
K289M READY
K289S READY
http://pastebin.com/vpPFXDFE
http://pastebin.com/u9C5WfMC
Thank you all so much for working on this :)
Fantastic news! I just donated towards the development of ML and encourage others to do same ;)
Can you give link?
http://www.magiclantern.fm/donate.html
Quote from: a1ex on May 15, 2015, 12:33:15 AM
Last night, g3gg0 and I took a quick loook at the firmware update, and here are our first notes:
Thank you! I hope you and g3gg0 can make a dumper for it.
I would be happy to try.
Quote from: a1ex on May 15, 2015, 12:33:15 AM
- instruction set is Thumb-2.
So the Digic6 has an ARMv7-M architecture, isn't it?
Even tho ML for the 7D2 is not confirmed yet it is awesome to see that the devs are at least looking into it. It is really nice knowing that the devs actually care about the users!
Chucho has just found an interesting string in the fw:
0xfe1a0912 "MemMgr (Rec4K2K) %ld %ld"
Keep it going Team ML :D
Quote from: Pelican on May 15, 2015, 11:23:52 PM
Chucho has just found an interesting string in the fw:
0xfe1a0912 "MemMgr (Rec4K2K) %ld %ld"
Wait... Does this mean there is a "Hidden" 4K function in the 7D2? Im not an expert or anything, so someone will have to explain.
no one will be able to explain anything at this early stage. take it with a grain of salt. 70D rom also contains hints for CF card in rom but has only SD. Just an example...
Holy crap! I've been away from this forum for a few months now and I gave up hope we'd ever seen ML for the 7DII, but I checked for a new 70D build today and saw this! Amazing news, the potential for this camera is insane. I know a port is still a very long ways off, and not even a sure thing, but to see any progress at all makes me really happy! Right now things are kinda tight financially for me, but I'm gonna try to pony up some cash to donate.
Another interesting strings: hundreds of COCOA functions.
http://en.wikipedia.org/wiki/Cocoa_(API) (http://en.wikipedia.org/wiki/Cocoa_(API))
I just read on Canonrumors that a lot of people have an issue with the 7D2 locking up with the new firmware. Has anyone here experienced this?
Quote from: Pelican on May 16, 2015, 07:27:07 PM
Another interesting strings: hundreds of COCOA functions.
http://en.wikipedia.org/wiki/Cocoa_(API) (http://en.wikipedia.org/wiki/Cocoa_(API))
it seems to be used in movie functions only.
Chipped in another $40. Traded my 70D for the 7D MK2 before I was able to familiarize myself with ML. Would love to put this fast CompactFlash interface to good use since the 70D will never do 1080P raw... Especially since the 7D MK2 lacks the 70D's 1:1 2.9x crop video mode that was so handy for extra reach...
Just placed my order on a 7D2! Cant wait to test it out.
Awesome news! please keep this way! Big Thx to g3gg0 and A1ex! and i go to place some money on it right now!
Hi,
could I please get access to the firmware?
You download the firmware from Canons webpage, if you are talking about the 1.0.4 update that is
When getting my 7D2 (Hopefully today) I will use my CF card in it. And my SD card will switch between my 600D and 7D2. I have ML on my 600D. Is it safe to have a 600D ML file on a SD card and use said card in my 7D2?
I recommend not switching cards between different camera types.
I'm talking about the decrypted firmware from those images.
A friend of mine said it would be fine and that the 7D2 wont read the ML file. But i wanted to ask here if i can do it. Even though it may not be recommended, can i do it? Hahahaha.
I think they just opened the firmware in some sort of program to read the code. I have no idea tho
Hi Infraspace. I use ML on my 600D and swap SDs with my 7DMK2. I get no issues whatsoever.. of course ML wouldn't automatically load on the 7DMK2 (Yet) as it would need the bootflags / firmware to be altered like the first install on the 600D
Quote from: eborg on May 23, 2015, 09:06:31 PM
Hi Infraspace. I use ML on my 600D and swap SDs with my 7DMK2. I get no issues whatsoever.. of course ML wouldn't automatically load on the 7DMK2 (Yet) as it would need the bootflags / firmware to be altered like the first install on the 600D
Ive been doing the same the last two days and it is fine
Any news? can't wait to use Raw on 7d MKII
Let's be realistic. The news you are expecting isn't going to be announced in the near future. I would say it could happen in 2016 - maybe earlier if one of the core devs picks one up and spends some hundreds or even thousands hours of work into it (QEMU boot may be easier to get working though) ...
guys, im about to make the choice between the 5d mk3 and the 7d mark 2, and the only thing preventing me from going with the 7d mark 2 is the compression rate on its video. Does anyone know what the compression bitrate is on 1080 or the 7d mark 2? thanks
Pedwin, may be join the forum on canonrumours.com.
Is anyone working on the 7dII right now? If so, how to best coordinate so there isn't too much duplicate work being done?
Would using an external video recorder, like a atomas ninja, on a canon 7d Mark II improve video quality close to RAW? Would it be a must have for serious video work since ML is not out yet?
Not raw but close
https://www.youtube.com/watch?v=2eU84vSsutE
Awesome if it will ever happen MLRAW on 7D2, I will instant buy the body as probably many others. ML boosting canon's sales :P
Quote from: canonballz on June 03, 2015, 04:41:24 AM
Would using an external video recorder, like a atomas ninja, on a canon 7d Mark II improve video quality close to RAW? Would it be a must have for serious video work since ML is not out yet?
No it wont be close to RAW quality. You can find comparison between 5d3 via ninja and raw on youtube. Also you will never get same freedom for grading as you're getting with RAW footage.
From what I saw the USB3 port is implemented via an FPGA. If that is true someone with a lot of time on their hands might be able to do something fancy with the world connected FPGA
So would you say getting an external video recorder isn't worth it for the 7DMII if you wanted to improve video quality with pro res.
Quote from: canonballz on June 04, 2015, 04:14:26 PM
So would you say getting an external video recorder isn't worth it for the 7DMII if you wanted to improve video quality with pro res.
Read again what i said.
Clear HDMI will improve quality over the regular in-cam footage. It's obvious.
But it will be not close to uncompressed RAW if you could get ML running on 7D2.
Commenting to stay up to date. Expecting my7d2 this week, love ML in my 600d and 650d.
Hi im new user here, i own a 7DII, i cannot wait for a ML version to release about this one..for this reason i want to help the team.
So, there is a way to donate ML team? I want to boost their works!!!
Ty for any answer i will get (i didn't read the whole threads sorry if i re-post something!!)
Yes. Home-->about-->donate.
Hi Guys/Gals
Got a 7Dii here and looking to help get the ball rolling.
It has been a few years but I do remember getting the 450d to respond to the boot flag switch when messing with CHDK so willing to give it a try here.
Currently learning C# as my first programming language although I understand ML is in C.
Any help would be appreciated.
Ok I have looked into this a bit more and it seems canon has added AES encryption to the loader and the firmware so will no longer work with dissect and decrypt.
From what I understand this key is not going to be disclosed by the group and so is going to be a non starter for anyone outside of the group who wants to decrypt the image to work on it.
I guess Pelican is on the inside of the group now as he has managed to decode it?
Any help would be appreciated.
Cheers
Any updates? It seemed like some of you guys started toying with the new software a couple of weeks ago?
I wouldn't hold your breath for it. ML development is extremely short-handed these days :/
Unfortunately, nobody is working on the 7D2 ML (as I know).
Not even a firmware dumper is available.
We have only the updater file which contains a big part of the code, so if somebody want to do something he can start with that.
Or she...
Do you know any female ML developer?
It's a little hard to determine gender on the www.
Woof-woof!
I got my 7DII last week and had a chance to take take it for a spin over the weekend. It's a superb camera for stills - from the autofocus to the frame rates, to the 16000 native ISO! It's a great Camera! I slapped the Sigma 18-35 F1.8 Art on it and the images are beautiful.
The video capability though was disappointing. It is as bad as the h.264 video on the 5DMIII. But we all know that what Canon gives us is not what is really under the hood and I am willing to bet that Magic Lantern RAW on this camera will be as good as - if not better than - the 5DMIII. The 7DMII in my view is to the 5DMIII what the 50D was to the 5DMII - just a smaller version of the same camera. Video will truly shine on this camera once ML is running on it. Focus tracking especially is going to be really useful for RAW video.
For now I will continue to use the 50D as my RAW workhorse but I think ML RAW on the 7DMII will be a leap!
Any chance to get a 7DII version of the linux mod?
Bump
Is it possible for the 7D mark ii to shoot 1080p at 120fps, or 4k 60? Just curious.
NO
1080 120fps would be a dream for BMX footage. 4K would be a dream for clients, hahaha. RAW is a must have.
Waiting :'(
Don't hold your breath...
New Firmware for 7DII
http://www.canonrumors.com/firmware-canon-eos-7d-mark-ii-v1-05/
Quote from: lebuenski on September 09, 2015, 01:54:46 PM
New Firmware for 7DII
http://www.canonrumors.com/firmware-canon-eos-7d-mark-ii-v1-05/
Thanks Man 8)
:D thanx for new firmware man....
Hello guys I will sell my 70D because I was hoping more from Raw video and I think is not enough 1600x600 at 2.67:1 continue is the best resolution that I can use in my 70D but the question is wait for ML 7D2 or get a 5D2
and I would like to know how good is work those camara in high ISO? thanks
If there is no dev working on it do not hold your breath. Act like there will be no ML for your cam ever.
I am a new owner of a 7D2. One of my favorite things on the 6D port was the GPS hack. Unfortunately, the 7D2 is plagued by the same issue. If you don't turn it off; it continues sucking juice from the battery.
Focus peaking is another thing I love on the 6D build, and would love to see on the 7D2.
Dang, I've had Magic Lantern on my T3i for years and love it. I just purchased a 7dM2 and wanted to use some of the same amazing tools. Amongst other things, I love that I have expanded aperture ranges and that I can access all of my exposure settings in one place. Soooo.... Looks like this is going to take awhile... If ever. I'm disappointed as using the Magic Lantern Tools actually factored into why I continue to buy and use Canon Camera's.
Quote from: filmguy5 on September 25, 2015, 06:12:43 PM
Dang, I've had Magic Lantern on my T3i for years and love it. I just purchased a 7dM2 and wanted to use some of the same amazing tools. Amongst other things, I love that I have expanded aperture ranges and that I can access all of my exposure settings in one place. Soooo.... Looks like this is going to take awhile... If ever. I'm disappointed as using the Magic Lantern Tools actually factored into why I continue to buy and use Canon Camera's.
Exactly my same story.. I wish I had done better research before :'(
Looks like it will take a while? More like it looks like it'll never happen at all.
Or scoop up a solid used 7D for $300-$500 while you're at it...
Is it possible to get a word from the developers if this is even something that is on their mind at all?... I am starting to consider getting myself a GH4 as the 7D2 ML possibilities are looking kind of dark... Chose a 7D2 over a GH4 with ML in mind.
I'm not a developer but if there is no port for your cam I suggest acting like there will be no port ever.
This is going to be like the 7D. It was a loooong time before it got ML.
Right now, it seems to me that ML is putting all it's efforts in developing for Apertus. You can sort of tell because of little news coming from ML in the longest I can remember . . . or they could be holding out for maximum shock and awe...
SO... Waiting or convert to A7sii :/ 14bit uncompressed raw pictures 5 axis stabilizer.... internal 4K recording..and S-Log3..
. Im dying here :'(
Quote from: Infraspace on October 27, 2015, 03:16:34 PM
Is it possible to get a word from the developers if this is even something that is on their mind at all?
I'm not tempted to get a 7D2 myself, but I'll continue to experiment with it in QEMU, and I'll also try to print Hello World. This is a low-priority task for me, so I can't promise anything.
My available time dropped a lot lately, and it's not because of Apertus. The proof is left as an exercise to the reader (hint: Apertus is open source). I actually hope that, once (if) I'll start working with them, I'll get more time for ML as well.
I have a 70D and bought a 7DM2 as my primary sports body and I would be very interested in magic lantern for the 7DM2. But considering I already have a 70D to use as my video rig/second body, it wouldn't be a priority.
Devs, keep doing what you are doing.
Everyone else, be patient.
Anything ! :-\
Quote from: hesham007 on November 26, 2015, 08:35:09 PM
Anything ! :-\
Don't hold your breath, if it ever gets ML (and thats a big IF) it wont be for quite a long time. I don't think anybody is even working on it at all right now, save for maybe Alex spending a little time in QEMU here and there. An ML 7D2 would likely be the best ML cam since the ML 5D3, probably even better, so of course there is incentive. But ML development isn't what it used to be, it's more about maintaining the cameras that already have it at this point.
By the time ML is ported to the 7D2 the camera will likely be a whole lot cheaper, at which point it will be a great cam to get.
After getting used what is ML RAW, there's no real point to use any Canon cameras without it. At least for video it's 100%
B&H price drop? $1049?
http://www.canonrumors.com/deal-canon-eos-7d-mark-ii-dslrpixma-pro-100-printer-kit-1049-reg-1399/
How many 7D2 users are in here? If we can prove that we are many enough maybe that will help.
Quote from: PanzerMamba on December 07, 2015, 07:57:54 PM
B&H price drop? $1049?
http://www.canonrumors.com/deal-canon-eos-7d-mark-ii-dslrpixma-pro-100-printer-kit-1049-reg-1399/
Of course it will drop. Who needs plain Canon bodies w/o ML RAW?! :)
Quote from: Infraspace on December 16, 2015, 08:42:59 AM
How many 7D2 users are in here? If we can prove that we are many enough maybe that will help.
Nope. Just demanding support will not help finding a maintainer.
I own the original 7D and now have the 7D2. Initially, I was happily shooting MLV on the 7D, then, it stopped recognizing the 64GB 1000x Komputerbay cards I bought :( So, if anyone has any ideas how to fix that, please do let me know. Ultimately, I hope that there is ML for the 7D2. That might keep me from selling it to buy a Sony A7R2 next year some time ;)
Ask 7D related question in 7D thread or open a new thread in "General Help Q&A".
I am about to sell my 70D and get a second 7D Mark II due to the fact I need a faster camera for sports. After the second week of January I won't really need a second body for a few months so I would be willing to loan my second 7Dm2. But if a few people are willing to pool a bunch of money to buy a developer a body, I would throw down $100-200 to do so.
This is not a place to sell cameras. It's a thread with important information for us.
Maybe some one can move this post to there one place.
I think is a good deal, if some one want to port ML to the 7D II =)
Quote from: budafilms on December 21, 2015, 02:54:06 AM
This is not a place to sell cameras. It's a thread with important information for us.
Pretty sure hes not trying to sell us his camera. All he said is that he could loan them his camera or us 7D2 users could buy a new 7D2 for the devs.
No I'm not trying to sell anything. I'm willing to loan my second 7d2 for a few months. Or I think what would be a better long term solution is to pool money and buy a permanent development body
@Infraspace @kaptainkatsu
Ok, my apologies.
Quote from: kaptainkatsu on December 23, 2015, 02:25:22 AM
I'm willing to loan my second 7d2 for a few months.
What when your 7D2 will be permanently damaged by the developer? :o
Hypothetical. It wouldn't happen because - at time of writing - no dev is able/willing to port 7D2 on top of the workload they already have.
<macro: Sermon> Money is *not* the problem. Community funded some tools in the past without hassle. Whenever dev team asked for something they were not able to afford the forum made it happen.
If you want a port running: Get/become a maintainer willing and able to put several hundred hours into it.</macro>
Real bummer that nobody is working on this. The 7D Mark II would be the most amazing Raw video camera, so much potential. If I knew how to get into the firmware, I would totally get going on it myself. I sure hope more developers come on board to maintain and work on new ports.
Agreed. I feel really bad because I have recommended it to many and now I look like an idiot. Now, I'm going to have to get an Ursa Mini 4.6K to even remotely get that same quality.
You are welcome! Make firmware EOS 7D Mark II MagicLantern
Now Walter, please don't yell at me...I'm just talking here.
So, a member over at DVXUSER mentioned that he felt that Canon would soon push out a firmware update to allow 4K recording on the 7D2. His words were "Mark My Words: The Canon EOS 7D Mark II will get a firmware update adding 4K to match the Nikon D500. Way more likely than a quick correctional successor with it. Canon ain't Nikon."
Post: http://www.dvxuser.com/V6/showthread.php?340905-Canon-1Dx-mkII-to-shoot-4k-video-5D-mkIV-not-so-much-Also-C100-4k-witin-18-months&p=1986610187&viewfull=1#post1986610187
I thought "too good to be true." Then I quickly remembered a post from page three of this thread:
QuoteChucho has just found an interesting string in the fw:
0xfe1a0912 "MemMgr (Rec4K2K) %ld %ld"
Interesting times indeed. I was really hoping for ML Raw, it would be incredible on this camera. However, my hopes are now leaning a little more towards Canon actually delivering a firmware update to allow 4K, heck, I'll even go out on a limb and hope for Canon Log. I know, dreaming right? You never know...
This makes me want to keep my 7D2. Been really on the fence between selling it and getting a GH4 and keeping it. These news makes me want to keep at least for a while to see if theres anything to it. Id prefer ML raw over 4K tho.
Quote from: ddelreal on February 02, 2016, 12:17:45 AM
Now Walter, please don't yell at me...I'm just talking here.
So, a member over at DVXUSER mentioned that he felt that Canon would soon push out a firmware update to allow 4K recording on the 7D2. His words were "Mark My Words: The Canon EOS 7D Mark II will get a firmware update adding 4K to match the Nikon D500. Way more likely than a quick correctional successor with it. Canon ain't Nikon."
Post: http://www.dvxuser.com/V6/showthread.php?340905-Canon-1Dx-mkII-to-shoot-4k-video-5D-mkIV-not-so-much-Also-C100-4k-witin-18-months&p=1986610187&viewfull=1#post1986610187
I thought "too good to be true." Then I quickly remembered a post from page three of this thread:
Interesting times indeed. I was really hoping for ML Raw, it would be incredible on this camera. However, my hopes are now leaning a little more towards Canon actually delivering a firmware update to allow 4K, heck, I'll even go out on a limb and hope for Canon Log. I know, dreaming right? You never know...
After that ''4k" rumor **crosing fingers**
Quote from: hesham007 on February 02, 2016, 11:11:03 PM
After that ''4k" rumor **crosing fingers**
Me too. Met my first client ever asking about 4K the other day. Felt so weird to say I dont film 4K when the client owns a A7RII. Lucky for me the camera itself doesnt make a movie.
So .... looks like sony is getting so far this time . The α6300 is a finally here :
.
.http://www.dpreview.com/news/3240829197/sony-announces-24mp-a6300-mirrorless-camera
.
24MP CMOS APS-C sensor with copper wiring
425-point on-sensor phase-detection AF system....... {{WORLD RECORD}}
11 fps continuous shooting (8fps continuous live view)
Silent shooting in continuous drive (3 fps with AF/AE)
Max ISO of 51200
4K video capture up to 100 Mbps
Phase-detect AF compatible with A-mount lenses via LA-EA3 adapter
.
.only for : 999 USD !!!!!!!
.
. i'm defiantly buying one
Now Canon will really have to step up their game. I read somewhere that Canon struggles to put 4K in their DSLRs because of how much heat a full frame sensor produces. With the 7D2 crop sensor heat shouldnt be that big of a problem.
If nothing happens to the 7D2 soon (The rumored 4k or ML) ill have to jump ship. If can be patient enough the new RED raven is a really solid option.
" Camera-specific discussion
Find the thread for your camera and discuss porting issues there. For raw video, please use the dedicated section below (not here)."
-> "General Chat
Chat about new camera models ("when is the 1DZmkII port coming!?!"), DSLR filmmaking accessories, your favorite (or least favorite) picture styles, tricks of the trade, and any other related topic."
or
-> Canon Rumours
We got kinda off topic with the A6300 but the conversation is still very much relevant to the 7D2 (4K rumors and ML progress)
Please enlight me how an unannounced firmware update will have anything to do with a 7D2 port nobody is working on.
This thread is for the 7D2. And we were talking about the 7D2. Also everyone here is still hoping for the 7D2 port so were talking about that as well. Theres only been like one reply not about the 7D2.
You're wrong: "Find the thread for your camera and discuss porting issues there." Talking about an non-existent firmware update doesn't fit.
It would be necessary to find a developer willing to take the burden maintaining this cam. Obviously there is none around here.
Okay, then im sorry for having a conversation with someone on the internet about a much needed (Or at least wanted) port.
I purchased the Canon 7D MkII about 6 months ago. I am incredibly happy with this camera. I primarily use it for video and it serves this purpose very well compared to other Canon cameras (even when compared to the 5DmkIII) considering it has servo AF for video, audio metering and (speaking of new functionality that once was only accessible through magic lantern) also has time-lapse functionality built in. Having the added features that a Magic Lantern build for the 7dmkII brings, however, would allow this camera to do everything I need it to do. I'd especially be interested in having the option to turn peaking on and off, to assist with focusing while recording. Bulb-ramping time lapse options would be amazing, and what I was really hoping for was the ability to shoot HDR video. Finally rumors that magic lantern could unleash 4k potential on the 7DmkII would be a cherry on the top.
I bought this camera assuming Magic Lantern firmware would be developed for it, and I hope down the line developers are able to bring the firmware to the 7DmkII. It looks like developing the firmware for the 6D is taking precedence, as well as maintaining other builds. However, the 7DmkII stands to be one of the most powerful Canon cameras, especially when it comes to video, when paired with the added capabilities of magic lantern, and I hope the developers see the incredible potential here.
Without Magic Lantern for the 7DmkII, I probably would have been better off buying a Nikon D500: With the D500 I could get almost all the same standard camera features plus 4k video recording functionality at a similar price point as the 7DmkII. Magic lantern is the only thing keeping Canon competitive on the market anymore. So kudos to all the hardworking developers at Magic Lantern. And a huge thank you for all you bring to the Canon-user's universe!
Quote from: pebenson on February 12, 2016, 06:06:21 AM
and I hope the developers see the incredible potential here.
Sorry, but you're missing the point. Amazing feature sets doesn't change the fact there is no developer at hand willing/able to take the lead for this port.
Quote from: pebenson on February 12, 2016, 06:06:21 AM
I purchased the Canon 7D MkII about 6 months ago. ....
I probably would have been better off buying a Nikon D500
Me too probably would have been better off buying 5D Mark IV... 6 months ago, and with ML preinstalled!!!
7d mark II owner here as well.
checking here to see if any good news..but it looks dead.
is there anything we mortals can do? I could maybe try to move forward if at all possible.
but we can't waste this oportunity...
please...someone explain what can one do to help...i offer my time..any guide?
thanks
Do you have programming skills in C and assembler for embedded devices (preferable ARM) and are you willing to put several hundred hours into porting this cam? And being there after offering long time support?
no but I can make good coffe.... :o
just thought there was something for us to do...
with all the advances done over this years in magic lantern, I thought it became easier, meaning less things to figure out..unless canon changes the whole thing and is like haven't to start from 0.
To me, i will drop support for many other cameras that might be obsolete by now..but maybe I am being selfish...I do still have t2i and t3i and 5d mark ii....
anyways..I gave it a try.
thanks
Unfortunately i can't nothing about coding, and I know that you couldn't pay someone to make a firmware. This is just a guess but could a "Kickstarter" projekt be more correct? I mean a "Kickstarter" projekt for the making of the 7d2 firmware and also for other upcoming camera firmweres in the future!?
I don't try to advertise https://www.kickstarter.com/ (https://www.kickstarter.com/)
You have to explain your train of thought.
You are stating "I know that you couldn't pay someone to make a firmware." and asking about collecting money for this very purpose after. In my opinion that's a contradiction.
@_OLLE_:
You miss the main point of the "kickstarter project": you should provide any proof you can complete it; any working prototype, or something like that :)
Man, every time I see this thread in the recent posts section my heart skips a beat and I sit up in my chair as I click the link to this thread with high hopes that somebody finally committed to porting and maintaining ML for the 7D2. I then start to read the posts and discover that nothing has changed and I sink back into my chair and my heart sinks as well. Dang. Come on somebody.
@Walter Schluz
I mean something like explained here: http://www.magiclantern.fm/forum/index.php?topic=6367
A person called @krashnik has pretty intresting thoughts!
http://www.magiclantern.fm/forum/index.php?topic=16642.msg162215#msg162215
Yeah, krashnik had interesting thoughts, self serving interesting thoughts, and was told no by just about every developer and the people who started this journey...
Hello, I need a little help and technical support.
I recently bought a Canon 7D Mark II and generally I am satisfied, the beast from the camera but there is one small drawback when it comes to a focus group, which could be resolved with the next update.
Focus groups are in most cases only vertical but not horizontal, which means a lot when taking pictures of athletes on the podium, announcement of the winners or shooters who stand in a row, one behind the other, or when you take a picture of your friends in the audience who are sitting next to each other, then you would like one to two rows of horizontal focus points, sometimes three, so that only your friends can be in focus, but not a whole bunch of people who sit in four vertical rows.
To be clear I am sending you a picture on exactly what I mean.
I hope that good people from ML can do somthing abouth this? :-\
(http://i.imgur.com/Gp5Fxeg.jpg)(http://i.imgur.com/vv12rQo.jpg)
(http://i.imgur.com/w9ZEEH9.jpg) (http://i.imgur.com/uaTAKV4.jpg)
(http://i.imgur.com/A7UwgOG.jpg) (http://i.imgur.com/EUxUTND.jpg)
(http://i.imgur.com/LUwrQv6.jpg)(http://i.imgur.com/0EWEPwa.jpg)
There is no ML for 7D2. Nobody is working on it. And there is nobody in sight planning to work on it.
I know that, but if somebody do a patch that will bring this possibility it would be great, not the entire ML. :-\
Sorry, that's not how it works.
Contact Canon support.
That's what I did. They told me that what I'm saying makes sense and they will take my suggestion to team that is responsible for the new firmware and that is possible that the new patch which will bring 4K video, will also bring this focus option. The problem is that they did not say when that will happen. :-X
So Canon says they are working on it.
Here is no one working on it and not even planning to do so.
Quote from: djordje.janjic29 on February 18, 2016, 12:00:43 PM
That's what I did. They told me that what I'm saying makes sense and they will take my suggestion to team that is responsible for the new firmware and that is possible that the new patch which will bring 4K video, will also bring this focus option. The problem is that they did not say when that will happen. :-X
They just kidding you:-)
Yap, it can be. I'm getting' desperate about it. I just bought this camera and I can see that it does not meet my needs. :'(
I think I would cry if Canon released a 4K firmware update. Come on Canon! Hurry up!
C'mon guys!
I was desperate user of 7D since 2009 and if not g3gg0's hack for dual digic I'd sell it right away long time ago despite nice photos I shot with it. Just 2 things keep me using my 5d3 - glass and ML (Thanx so much to devs and all the comunity here). Canon makes fun of users of XXXXD/XXXD/XXD series. Look at the ridiculous 80D innovations and then look at sony A6300 for 1K USD. It's a lot more advanced peace of hardware than even 1D series canons ever been or will be... ehh... It's aa... I just wanted to let the steam out... sorry ;)
bb
Hi,
Am I correct to assume there are no current plans and no current work for Magic lantern to 7D MK II?
I am considering purchasing the 7D MK II and ML is a crucial consideration for me.
Whenever we get our hopes up the devs tell us about there being no plans for a 7D2 ml. So im pretty sure theyre not planning on doing it any time soon. Youre better off buying a GH4 or an A6300
Meaning non Canon which would require replacing all my other gear as well - lenses and flashes - a VERY expensive choice.
I think I'll stick with my T3i for now.
Do you think there is any development taking place concerning support of Ml in new models or only nightly builds?
Thanks anyway,
Quote from: janjan on February 24, 2016, 04:06:17 PM
Do you think there is any development taking place concerning support of Ml in new models or only nightly builds?
This sentence doesn't make much sense.
And if there is no ML for your cam I suggest to act like there will be no ML for this cam ever.
I currently have the T3i which has ML support.
It adds so much more that I'll think twice before buying a new camera which has NO ML support.
Not all new canon models have ML support, hence my comment.
If there is no ML for a cam I suggest to act like there will be no ML for this cam ever.
If you are thinking video you could buy a speedbooster to continue using your canon glass. I didnt know ML gives any features for photography. I used to have ML on my old T3i and only used it for video.
Quote from: Infraspace on February 24, 2016, 04:53:58 PM
I didnt know ML gives any features for photography.
Trap focus, intervalometer, auto expo, auto ETTR, HDR bracketing, Dual-ISO, auto AFMA, focus stacking, bulb, silent pic ...
I only use it for photography and it presents great improvements.
So the bottom line is that it will not be available for Canon 7D MK II, am I correct?
If there is no ML for a cam I suggest to act like there will be no ML for this cam ever.
"I have said it thrice"
@Walther Schulz
Nobody wants from you anything, ok, why are you so opposed and pessimistic?
Walter is not pessimistic, he knows what is talking about, and he is patient enough to answer to the same questions again and again.
Porting Magic Lantern is a very difficult and time consuming task, that needs a lot of reverse engineering and hundreds of hours of work by a highly skilled programmer. Nikfreak could tell you about it, it has done the most recent ports, for 70D and 100D.
But new Canon cameras need a lot more extra work: they use a different version of ARM code, so ML needs to be rewritten for them, and also most of the tools the developers have written during last years to do reverse engineering on Canon cameras need to be rewritten as well. And no developer here has started this huge task, and they say they have no time and interest to do it.
I agree, programming a camera would take a lot of effort and reverse engineering makes it even harder.
Still, if no one it pumping new blood (Canon models) to the system, this great project will eventually die, it that not so?
After all, the older models will not be here forever.
Please try to understand "And no developer here has started this huge task, and they say they have no time and interest to do it."
5D Mark III, 6D, 70D, 100D, are still current Canon models, and they are all supported by ML. And 700D, 60D and the original EOS M probably are still in production, and are also supported by ML. So if you need ML you have plenty of choices.
And to get ML ported to the newer Digic 6 cameras (a huge task, as I said), probably the 7D Mk II will not be the best candidate: it's expensive to do bleeding edge experiments with it, and his dual digic processor makes the programming a lot more difficult. The only advantage it has over other Digic 6 DSLRs is that there is a firmware update for it already distributed by Canon, and this makes ML development easier.
Ok,
Is there anyone working on developing ML for ANY new camera today or no one?
No, as far as I know, for any Digic 6 camera. Nikfreak's ports for 70D and 100D are the most recent efforts to expand ML support for new models. Some initial work has been done on 1200D, also, but then discontinued. But nothing for Digic 6 cameras, as I said, this is way more difficult.
He is pessimistic and if he already have this forum, then answer the questions or let it some one else do it for him instead. On the other hand, no one asked him anything personally, so he have no obligation to answer, ok.
If people donate, then stop whining, it's hard work, people pay, you do, there's no much philosophy in it.
And of course, existing models will not be here forever and yes if we continue to think like this, then this project has doomed.
To be realistic we wont get ML for 7D2 mark II in a really fucking long time. If im not mistaken the developers will eventually have to write code for the Digic 6 chips anyway to keep ML going. And maybe then the 7D2 can get ML too
Quote from: djordje.janjic29 on February 25, 2016, 01:49:04 PM
If people donate, then stop whining, it's hard work, people pay, you do, there's no much philosophy in it.
You are wrong, what you are describing is one possible philosophy, the commercial way. But there is another philosophy, completely different: the open source, community driven projects, based on volunteer effort. The developers here, who have created ML, prefer the second model. And they are afraid that hiring a particular developer to improve ML with a paid job will negatively affect the whole community based project.
So please, do not insist in taking the commercial way, asking for donations, etc. This has been discussed many times, and the answer has always been "no".
More than that: ML dev team has declared to drop out if devs were paid.
Dmilligan posted this one and it pretty much contains all: http://www.magiclantern.fm/forum/index.php?topic=16642.msg162215#msg162215
So: Make ML commercial -> Kill ML as you know it.
I dont think a commercialized ML would be a good plan. As soon as you start capitalizing on a project like this things may escalate. The last thing you want during a shoot is for your camera to start playing an ad ;) haha.
Edit: English
Hey everyone,
I'm sure many many people would love to help the team to create the ML for canon EOS 7D mark II.
Maybe Need donation, quick starter, anythings we can help we would do. It will help a lot of people to have ML on this camera and even if it would cost some things to have it, people would buy it!
I'm not good into create program like ML but i would help in the way which I can help!
Cheers from Switzerland :D
Sorry, but haven't you read the "discussion" we had on this very page?
Yes why ;)
Because it was pointed out that by paying someone to do the work devs will drop out and project will die.
However, as pointed out by you, no ML is available for any of the new camera models with the new processor.
This will also kill the project eventually.
Quote from: janjan on March 01, 2016, 02:49:07 PM
However, as pointed out by you, no ML is available for any of the new camera models with the new processor.
This will also will kill the project eventually.
I strongly agree with that. People will eventually move on to cameras that you guys dont support and by the time you catch up no one will remember to download ML. Personally I am moving on to a different system once i can afford it.
If collecting ways to kill the project helps keeping the project alive: Keep em coming.
Okay, now seriously: If there are any ideas solving the problem and not already excluded (as listed above), be my guest.
I may be biased. But honestly I do feel like you could start phasing out some of the older cameras. I dont think too many people uses a 50D anymore, and if they do and ML is super important to them they can get a 70D realtively cheap when the 80D comes out. If not they can continue using a functioning build of ML.
Okay, let me take this in order (the one I have in mind, of course).
You are taking it for granted that dropping older cams from support will set free resources and those resources will be relocated to port newer cams.
But that is - at time of writing - just a premise and I want facts before going deeper. And pointing out a specific cam may be not the best start. (For example you have to discuss the fact 70D makes a lousy replacement for 50D for RAW movie).
To do:
First: Ask dev team if dropping older cams will in fact help reducing workload by a significant number.
Second: Will dev team take it into consideration to drop support for older cams?
Third: If so, which candidates are there?
Side effects to consider? Sure. If you get a maintainer for a specific cam pissed because it is dropped he may be not in the mood taking part in porting a newer one. And there may be others. Devs will more likely (IMO) going to drop a cam from support if it is unmaintained/blindly maintained. -> No maintainer -> Nobody there taking up the load.
Quote from: Infraspace on March 01, 2016, 07:36:25 PM
I may be biased. But honestly I do feel like you could start phasing out some of the older cameras. I dont think too many people uses a 50D anymore, and if they do and ML is super important to them they can get a 70D realtively cheap when the 80D comes out. If not they can continue using a functioning build of ML.
Bad example.
I use a 50D with ML. This cam records Full HD 1920x1080 at 23 FPS continuous. The 70D can't do that, because the SD interface is limited to 41 MB/S. And several ML functions for stills that work perfectly on 50D do not work on 70D (focus stacking, etc.)
And keeping ML running on older cameras is not as hard as porting it to new models, the initial effort to get it working needs much higher developing skills and a lot of time. And porting ML to Digic 6 cameras needs a much harder work, as already explained.
Posting hundreds of complains saying "Why there is no ML for my cam?" in this forum do not help to get to this job done automatically. We need more people coding, testing and debugging, no more people complaining.
I may be biased also, but biased to have fun experimenting with inexpensive second-hand cameras. But I think that if someone wants more features for the latest Canon cameras, he should ask Canon. The Canon guys can access ML code, it is public, and they could implement ML's features in their cams easily if they want. It's very difficult for a reverse engineered and volunteer based project to catch up with latest commercial products, that land in the market at such fast rate.
I've gotta chime in here because this thread keeps popping up and bugging me haha
The devs said they aren't going to do it, and it doesn't seem like anyone is going to talk them into it so that's that.
If it's really that important to those of you who want ML on the newer cams learn how to develop it yourself then you can be on the dev side and maintain builds and whatever else goes into that.
If you aren't willing to do that, then it isn't THAT important to you.
ML is free and open source and because of the features made possible with it, I know I personally have saved a decent amount of money.
If you're asking for more, you've got to be taking what's already been given for granted. If that's not the case, and you "really care about the future of ML" then, like I said before, do something about it yourself.
Quote from: josepvm on March 01, 2016, 08:07:11 PM
Bad example.
I use a 50D with ML. This cam records Full HD 1920x1080 at 23 FPS continuous. The 70D can't do that, because the SD interface is limited to 41 MB/S.
The 70D records full HD without ML? If you by continuous mean more than 4GB files thats not really an issue as it probably splits the file into multiple ones? At least my 7D2 does that.
Quote from: cmccullum on March 01, 2016, 08:08:16 PM
If that's not the case, and you "really care about the future of ML" then, like I said before, do something about it yourself.
I would if I could. But I simply cant invest the time to learn coding. And i know we cant the demand that the devs spend their time on the ML project either, so I do understand if they do not have the time needed. But if they just made a "Final" stable build for some of the older cameras and then moved on to the newer ones I think that would be the best solution over time.
Quote from: Infraspace on March 01, 2016, 09:11:18 PM
The 70D records full HD without ML? If you by continuous mean more than 4GB files thats not really an issue as it probably splits the file into multiple ones? At least my 7D2 does that.
Look, that's the problem with naming a cam in particular because now your case is farther away from being discussed and you are in a "Cam A vs. cam B" discussion" and - because you are missing the point - opened a third discussion about RAW/MLV recording (and this is unknown territory for you right now).
Please drop it right now. 70D is just a lousy replacement for 50D. Period. And, please, end of this part of discussion right now! You are losing ground.
And you opened the fourth front, because going into stable vs. nightly discussion. Drop that, too!
Quote from: Infraspace on March 01, 2016, 09:11:18 PM
I would if I could. But I simply cant invest the time to learn coding. And i know we cant the demand that the devs spend their time on the ML project either, so I do understand if they do not have the time needed. But if they just made a "Final" stable build for some of the older cameras and then moved on to the newer ones I think that would be the best solution over time.
You CAN invest the time. If it is important enough to you, you can sacrifice other things, and spend time to learn how to code and port to new cameras. It simply isn't worth it to you. Maybe the devs just don't WANT to work on the new cameras. To me, that's a perfectly valid reason for them not doing so, and everyone who isn't willing to help should stop trying to convince them to give MORE.
The best solution here is for people who care enough to jump on board and join the devs
Working as a freelance videographer i really cant. At least not right now. But yea, if they dont want they shouldnt do it.
Quote from: Infraspace on March 01, 2016, 09:11:18 PM
The 70D records full HD without ML? If you by continuous mean more than 4GB files thats not really an issue as it probably splits the file into multiple ones? At least my 7D2 does that.
I was talking about ML raw video recording, sorry for not stating it clearly. 70D can only record 720p raw, because the writing speed for the SD interface is limited to ~ 40MB/s, and raw video files are huge. A 50D, with a fast CF card, is able to record 1080p raw video.
Quote from: cmccullum on March 01, 2016, 09:24:39 PM
You CAN invest the time. If it is important enough to you, you can sacrifice other things, and spend time to learn how to code and port to new cameras. It simply isn't worth it to you. Maybe the devs just don't WANT to work on the new cameras. To me, that's a perfectly valid reason for them not doing so, and everyone who isn't willing to help should stop trying to convince them to give MORE.
I am EE engineer and telling someone to learn code is like telling you to design a computer chip - it is not that easy!
I totally agree it takes time and time=money, is it not so?
I don't expect anyone to invest that much time on trying to decode the digic6 and rewrite the code and as we all agree, no one is doing it right now and probably will never do.
So I still think the only option to "convince" someone to do it is by giving him/her an incentive.
And the donations people argued for and against here, is one kind of an incentive.
People here suggesting incentives as a solution after they heard about devs opinion: 1 (you)
Don't get me wrong!
I don't argue with any dev. It's their choice and we can only thank them for the work they've done so far, and for FREE!!!
I am saying, that if this project is due to die, which is the only conclusion possible since no one will continue developing it, then it does not leave too many options.
Canon will never do this! it's against their interest. They DO NOT want to sell you a chip camera with the power of an expensive one.
Of course they can but this is all about marketing and money. They disable some code in the cheaper models or not bother developing it on purpose.
People here are not trying to ruin your ideology.
What people are saying here is that if no one is willing to develop new code, they are willing to pay for it.
Quote from: josepvm on March 01, 2016, 08:07:11 PM
Posting hundreds of complains saying "Why there is no ML for my cam?" in this forum do not help to get to this job done automatically. We need more people coding, testing and debugging, no more people complaining.
You're not fully correct there. I think there're more people like me, who didn't buy new Canons only because there's no dev yet who at least could think about try to port ML. It's recursive. Give us a hope, I'm sure there will more people for testing and debugging at least.
Quote from: josepvm on March 01, 2016, 08:07:11 PM
I may be biased also, but biased to have fun experimenting with inexpensive second-hand cameras. But I think that if someone wants more features for the latest Canon cameras, he should ask Canon. The Canon guys can access ML code, it is public, and they could implement ML's features in their cams easily if they want. It's very difficult for a reverse engineered and volunteer based project to catch up with latest commercial products, that land in the market at such fast rate.
Canon will never implement any most important features of ML by two reasons. First they're maniacal paranoid about anything that can cannibalize their cinema line cameras. (No focus peaking in 1DX II, unbelievable LOL in 20216 but true). Second they would never risk run any code that push camera processor to the max and as follow has small, but still a chance to break the camera.
Quote from: janjan on March 02, 2016, 07:47:38 AM
I am EE engineer and telling someone to learn code is like telling you to design a computer chip - it is not that easy!
I totally agree it takes time and time=money, is it not so?
I don't expect anyone to invest that much time on trying to decode the digic6 and rewrite the code and as we all agree, no one is doing it right now and probably will never do.
So I still think the only option to "convince" someone to do it is by giving him/her an incentive.
And the donations people argued for and against here, is one kind of an incentive.
I never said it was easy to learn (but don't forget that all of the current ML code, and the knowledge of the devs is readily on hand for anyone starting this project). If it was I would just learn and develop the stuff myself just to end this! The thing that I'm saying is that if a person wants something bad enough, they will take the necessary steps to get said thing. If this person is not willing to take those steps then they do not want the thing badly enough. That is the simple part.
People want something for nothing. Funny thing is that the ML team has given them exactly that, and they want more for nothing.
As far as people "willing to pay", the price tag is that of their camera of choice that already has the features ML makes available (don't forget those exist)
Quote from: janjan on March 02, 2016, 08:14:47 AM
I don't argue with any dev.
You have to.
- Devs told to drop out if incentives are involved.
- You insist in paying is a solution for lack of resources.
It has been told to you several times. You won't accept it.
Donation was discussed so many times here and there as path to nowhere. But why not look on it from other side, like donation to buy camera for dev(s) to start work with? Or it's the same?
There have been several crowd-funding actions (usual crowd-funding sites not involved) in the past. Cameras and very, very expensive debugging tool licences, for example.
It was never a problem and will not be a problem (IMHO) for the community to pile up more money to cover such items.
Donations won't change the problem and the problem still is
No developer/maintainer available for porting and long term support.
See reply #29 ...
I understand all this but it does not change the situation.
No dev will take this job because it takes a LOT of time and, sorry to write this again, but time = money.
No new cameras will ever be supported by ML (probably) which will eventually kill the project.
Can we agree on this?
I am not here to convince anyone to do anything he or she does not wish to, especially not on their free time.
Asking people to learn code and reverse engineer Canon code is an option but a very unlikely one.
The tools and the code here cannot be use for the new processor else they would have been already used.
Can you offer any solution to stop the (slow) death of this project?
Quote from: janjan on March 02, 2016, 09:26:20 AM
No dev will take this job because it takes a LOT of time and, sorry to write this again, but time = money.
Sorry, I end this here. Stop talking to me.
In the future I will just respond more of this stuff coming from you by just pointing to dmilligan's answer because it will cover most of it.
http://magiclantern.fm/forum/index.php?topic=16642.msg162215#msg162215
Quote from: dmilligan on February 12, 2016, 11:01:04 PM
This is not how it works here.
There are plenty of old threads about ML and money. Here's one with some good responses: http://www.magiclantern.fm/forum/index.php?topic=6367
http://www.magiclantern.fm/forum/index.php?topic=6367.msg49861#msg49861
But if you actually post your request, and it's reasonable and possible, it might actually get done.
Hey, no need to get mad.
We all love ML and all we try to do is get some hope regarding the continuation of this great project.
http://magiclantern.fm/forum/index.php?topic=16642.msg162215#msg162215
Locking this thread until someone PM's to say they are porting to this camera, or I remember at some future stage to open it again.
This development project doesn't need more opinions.
Willing and able people are the only thing this development project has ever needed. If you're willing and able to learn some code, or help with a bunch of other stuff that doesn't need coding skills (http://www.magiclantern.fm/forum/index.php?topic=12657.0), have some fun and like cameras, then this is probably a good project for you. If you can't do that, then the least you can do is cease with all the dire claims about the projects pending doom, and then feigning innocence when someone gets frustrated that it's taken thirteen posts for you to get the point.
Cheers.
Some recent findings from CHDK: https://chdk.setepontos.com/index.php?topic=11316.msg128643#msg128643
At a quick glance, their findings seem to apply to 7D2 as well.
I still don't know the LED address, but I'm starting to understand the firmware well enough to adapt ML boot process and create a ROM dumper. If somebody helps me with a really boring task, I might have it ready pretty soon.
What I need: in arm-mcr.h, we have B_INSTR and BL_INSTR for encoding the two ARM instructions. I need the same macros for Thumb-2 instructions B.W and BLX.W.
You guessed: I'm actually looking for somebody familiar with (or willing to learn) Thumb assembly to help with this port.
Keeping my eyes and ears open for coders, might know somebody that can help. I'll keep you posted.
Great job @a1ex
Yes, great job a1ex!
I don't know how to code. I'm willing to help. I own a 7d2. Where can I go to start learning thumb assembly?
I have in the past messed with Bosch engine management, engine tuning.
@a1ex - Got a buddy here who's a coder. Just asked for his permission to participant on this port and he gave me a thumbs up. PM me if you want his contacts.
If anyone is willing to contribute, just do it. It's open source ;)
Quote from: a1ex on May 26, 2016, 08:07:31 PM
What I need: in arm-mcr.h, we have B_INSTR and BL_INSTR for encoding the two ARM instructions. I need the same macros for Thumb-2 instructions B.W and BLX.W.
I don't know what is .W at the end of B and BLX but uncoditional B is 0b11100ooooooooooo where oo..oo is the offset/2 (+-2KB,-2048 to +2046)
so the macro is something like this
#define B_THUMB(pc,dest) \
( 0xE000 \
| ((( ((uint16_t)dest) - ((uint16_t)pc) - 4 ) >> 1) & 0x7FF) \
)the BLX is two 16 bit thumb instructions 0b11110ooooooooooo and 0b11101sssssssssss where oo..oo is the upper 11 bit of offset and ss..ss is the lower 11 bit of the offset (the last bit must be 0)
#define BLX_THUMB(pc,dest) \
( 0xF000E800 \
| (((( ((uint32_t)dest) - ((uint32_t)pc) - 4 ) >> 12) & 0x7FF) << 16) \
| ((( ((uint32_t)dest) - ((uint32_t)pc) - 4 ) >> 1) & 0x7FF) \
)
Quote from: Pelican on May 29, 2016, 06:29:24 PM
I don't know what is .W at the end of B and BLX...
The .W forces a 32-bit instruction in Thumb-2 mode, even if a 16-bit instruction existed. [1]
I also tried to construct the macro for B.W, based on the ARMv7-M specification which defines the 32-bit B.W [2]. Here's what I came up with:
#define OFFSET(pc,dest) ((uint32_t)(dest) - (uint32_t)(pc) - 4)
#define S(offset) (((offset) >> 24) & 0x1)
#define I1(offset) (((offset) >> 23) & 0x1)
#define I2(offset) (((offset) >> 22) & 0x1)
#define IMM10(offset) (((offset) >> 12) & 0x3ff)
#define IMM11(offset) (((offset) >> 1) & 0x7ff)
#define J1(i1,s) ((!((i1) ^ (s))) & 0x1)
#define J2(i2,s) ((!((i2) ^ (s))) & 0x1)
#define B_W_INSTR(pc,dest) \
( \
0xf0009000 | \
(S(OFFSET(pc,dest)) << 26) | \
(IMM10(OFFSET(pc,dest)) << 16) | \
(J1(I1(OFFSET(pc,dest)),S(OFFSET(pc,dest))) << 13) | \
(J2(I2(OFFSET(pc,dest)),S(OFFSET(pc,dest))) << 11) | \
(IMM11(OFFSET(pc,dest))) \
)Not extensively tested, so feel free to fix and improve.
I guess the binutils implementation [3] could be used as a reference too.
For the BLX I did not find a specification that defines the .W version. If such a specification exists, I'd be glad to see it.
From the ARM page [1] I can see that there are two different BLX instructions: BLX <Rm>, and BLX <label>. The latter one seems to be the only one which has a 32-bit version. Is that the one you're after, a1ex? Although, both the ARM page and the ARMv7-M spec says that the BLX <label> is not part of ARMv7-M. Do we know for sure what architecture the DICIG 6 has?
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489e/Cihfddaf.html
[2] https://web.eecs.umich.edu/~prabal/teaching/resources/eecs373/ARMv7-M_ARM.pdf
[3] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-arm.c;h=3b0a021a379bc72c21ba8f0c312789fc25dd2d5e;hb=HEAD#l22108
Thanks atonal and Pelican.
I don't know the exact architecture, but there are both ARM and Thumb-2 instructions in the firmware, so it's probably not ARMv7-M. In IDA, I've used ARMv7-A&R, if that tells you anything, and in QEMU I've used ARM_FEATURE_V8 (CPU definition here (https://bitbucket.org/hudson/magic-lantern/src/6a2c25d98855fc84496a08c8ad438ffc6528a544/contrib/qemu/qemu-2.5.0.patch?at=qemu-nkls&fileviewer=file-view-default#qemu-2.5.0.patch-87)). I managed to get it somewhat working with ARM_FEATURE_V7 and ARM_FEATURE_MPU as well, but got errors about execution permissions (these are probably configured by the bootloader code, which I don't have).
From what I could tell from the updater code, the bootloader loads the firmware update at 0x40800120 on both cores and expects ARM code (just like the 7D), so we don't actually have to compile Thumb code. To call Thumb functions, I've declared them as "long call" and made sure the function address has the LSB bit set (not sure if there's a simpler way with gcc).
For figuring out DryOS internals in QEMU, I've also used the EOS M3 firmware (yes, it's a PowerShot, but the DryOS core is the same) and the 100D QEMU patches from @nkls (http://www.magiclantern.fm/forum/index.php?topic=2864.msg166936#msg166936) (his changes allowed me to trace Canon's debug messages from GDB, without having to load custom code in the firmware).
For the dumper, I've used atonal's code, slightly modified (swapped the 16-bit halves and turned it into a function), compared it to gcc output (test code here (https://bitbucket.org/hudson/magic-lantern/commits/502a53105b44)) and seems to work fine. Didn't test Pelican's code.
For BLX.W (this is how IDA displays it, for example FE0A0B36 E2 F1 90 E3 BLX.W bzero32), I've changed the 0xf0009000 to 0xf000c000. Don't know where to find it in the spec, but it matches gcc output and gets recognized by IDA (at least for this particular case).
Emulation log for master core, with the dumper loaded: 7D2-master-dumper.log (http://a1ex.magiclantern.fm/bleeding-edge/qemu/7D2-master-dumper.log)
Dumper source code: https://bitbucket.org/hudson/magic-lantern/branch/7D2-dumper
So, I'm looking for a volunteer to try the dumper on his 7D2 1.0.4 :)
I could probably do it but wouldn't be able to get to it until later this week.
I could try this Tuesday or Wednesday.
I could do it, but I do not quite understand, this is a firmware for the camera, and I can test it?
My camera has 1.0.5 firmware, it will not work with ML?
I've just put 1.0.4 to my 7D2 but I cannot find the updater fir
Should I compile it by myself?
If somebody could compile it would save a lot of time for me because I have no gcc on my laptop right now...
Already tried it with atonal, but didn't work. Simply jumping to 0xFE0A0000 on both cores didn't work either (gives black screen).
Back to the drawing board.
:(
Assuming I have a running gcc on my MBP (gcc-arm-none-eabi-4_8-2013q4) and recently when I tried cloning the dumper source code it gives me these enlisted options and wasn't sure which one to choose from via command terminal?
Last login: Mon Jun 13 10:48:46 on ttys000
Apples-Macintosh-10:~ DeafEyeJedi$ hg clone -r https://bitbucket.org/hudson/magic-lantern/branch/7D2-dumper
hg clone: invalid arguments
hg clone [OPTION]... SOURCE [DEST]
make a copy of an existing repository
options ([+] can be repeated):
-U --noupdate the clone will include an empty working directory
(only a repository)
-u --updaterev REV revision, tag or branch to check out
-r --rev REV [+] include the specified changeset
-b --branch BRANCH [+] clone only the specified branch
--pull use pull protocol to copy metadata
--uncompressed use uncompressed transfer (fast over LAN)
-e --ssh CMD specify ssh command to use
--remotecmd CMD specify hg command to run on the remote side
--insecure do not verify server certificate (ignoring web.cacerts
config)
(use "hg clone -h" to show more help)
Apples-Macintosh-10:~ DeafEyeJedi$
Happy to help with this dumper as I also have a co-worker that owns a 7D2 and is willingly to have me test/play with it for you guys as well.
How do I "unwatch" this thread??
Quote from: cmccullum on June 14, 2016, 06:34:08 AM
How do I "unwatch" this thread??
Best "motivational" phrase.
On-topic: I'm looking for a 7D2 user able and willing to measure the current from his camera while running this FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/DUMMY7D2.FIR). It can be done easily with an external power adapter and a multimeter, but you may need to sacrifice the cable.
The FIR simply jumps to 0xFE0A0000 on both cores (which I thought it should boot Canon firmware), but gives black screen according to atonal. Firmware version doesn't matter for this test.
00800120: e51ff004 ldr pc, [pc, #-4] ; 00800124 <_start+0x4>
00800124: fe0a0000 .word 0xfe0a0000
I'm looking at this option for two reasons:
- I want to find out whether the camera locks up or shuts down
- if I manage to lock up the camera without starting the main firmware (which was quite hard on the original 7D, as there was a watchdog shutting it down if the other digic was not initialized), I'm thinking to execute two code sequences that result in different power consumption (such as entering powersaving mode vs a busy waiting loop). This will let me dump the ROM bit by bit (probably slow). That's because I know neither the LED address, nor how to drive any other device that could give some sort of output, nor how to start Canon firmware.
Just to elaborate a bit on the trial with my camera: after trying to do the firmware update with the DUMMY7D2.FIR, the screen went black and the camera became totally unresponsive. Shutting down and removing the battery for a while made the camera come back to live again. Here's a short video, so you know what to expect: https://dl.dropboxusercontent.com/u/37493196/MOV_0017.mp4
Unfortunately I don't have an external power adapter nor a multimeter, so I can't help with this step.
That's a good sign => the camera is locked up.
In this case, it would be best if, instead of a multimeter, one could use an arduino board that reads the current from the analog input pin, then sends the data to the serial port so you can plot it on the PC. Tutorials: for example this (http://www.vwlowen.co.uk/arduino/current/current.htm) and this (http://www.build-electronic-circuits.com/arduino-oscilloscope/) (there are many other similar projects, so feel free to use the one you like best).
Quote from: a1ex on June 15, 2016, 06:13:44 PM
Best "motivational" phrase.
Haha Sorry I guess I should've been more clear. I'm getting email notifications every time a post is made here because I "watched" the thread at some point, and I can't figure out how to undo that.
Quote from: a1ex on June 15, 2016, 07:59:04 PM
That's a good sign => the camera is locked up.
Excellent progress, guys! :)
FYI I have managed to get ahold of my co-worker to bring his 7D2 tomorrow into work as well as finding another colleague from the engineering dept at work that uses a Multimeter.
I also do have a Canon ACK-E6 AC Adapter Kit that can be put to use (even if I have to sacrifice the cable) which then can be 'fixed' with an electric tape.
@atonal -- would you mind sending me a PM with the DUMMY7D2.FIR attachment if possible as the gcc has been acting up on my MBP as of late.
Quote from: cmccullum on June 15, 2016, 08:53:59 PM
Haha Sorry I guess I should've been more clear. I'm getting email notifications every time a post is made here because I "watched" the thread at some point, and I can't figure out how to undo that.
At the top of the thread, below the big notification box regarding MLV lite and such, on the right hand side. "Mark as unread".
This message and yours will self destruct in 24 hours. Good luck Ethan Hawk.
Quote from: DeafEyeJedi on June 16, 2016, 12:12:39 AM
would you mind sending me a PM with the DUMMY7D2.FIR attachment
You can find the link to the FIR from a1ex's post:
Quote from: a1ex on June 15, 2016, 06:13:44 PM
I'm looking for a 7D2 user able and willing to measure the current from his camera while running this FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/DUMMY7D2.FIR).
Quote from: a1ex on June 15, 2016, 06:13:44 PM
I'm looking for a 7D2 user able and willing to measure the current from his camera while running this FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/DUMMY7D2.FIR). It can be done easily with an external power adapter and a multimeter, but you may need to sacrifice the cable.
The FIR simply jumps to 0xFE0A0000 on both cores (which I thought it should boot Canon firmware), but gives black screen according to atonal. Firmware version doesn't matter for this test.
00800120: e51ff004 ldr pc, [pc, #-4] ; 00800124 <_start+0x4>
00800124: fe0a0000 .word 0xfe0a0000
I'm looking at this option for two reasons:
- I want to find out whether the camera locks up or shuts down
- if I manage to lock up the camera without starting the main firmware (which was quite hard on the original 7D, as there was a watchdog shutting it down if the other digic was not initialized), I'm thinking to execute two code sequences that result in different power consumption (such as entering powersaving mode vs a busy waiting loop). This will let me dump the ROM bit by bit (probably slow). That's because I know neither the LED address, nor how to drive any other device that could give some sort of output, nor how to start Canon firmware.
So what should I see on the multimeter with this firmware?
Is it oscillating current or not?
Yes, it is probably locked, it does nothing (black screen no response) until battery remove.
My external power adapter just died :( so I can use the cable of it to play with.
I'm going to photograph butterflies right now but next week I can test if the firmware can produce different current (3-4 sec period could be easy to measure)
With the above FIR, you will probably only see a constant value.
I can prepare other FIRs which - hopefully - give different values on the multimeter. Once we have that part working, we can replace the multimeter with an arduino board and dump the firmware.
I might have found the LED address.
Please try BLINK7D2.FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/BLINK7D2.FIR) (should work on any firmware version) and let me know whether the LED blinks.
Credits: https://chdk.setepontos.com/index.php?topic=11316.msg111290#msg111290
The LED blinks!
Yay!
Next steps: http://chdk.wikia.com/wiki/Obtaining_a_firmware_dump#Hardware-software_solution
Please let me know once you have the hardware ready.
Quote from: a1ex on June 18, 2016, 10:07:25 AM
Please let me know once you have the hardware ready.
(http://pel.hu/down/7d2blink.jpg)
Hi Guys,
Looks like you're all working hard, I am not a developer just an ML user, I have not had time to read up this thread very far so sorry for the probably annoying/obvious questions. I was just curious as to whether one day we will have a functioning ML for the 7d2 and what it will be capable of. 4k, raw etc. Sorry to interrupt your coding conversation, I am very keen to use it on mine as I previously used it on my 60D and was very disappointed to see that it's not yet available. Although not a coder I am happy to be an extra pair of hands if anything else is needed! Thanks everyone. :)
Can you show me your setup so i can do the same with my canon 80D! Please
Quote from: dinissilva on June 21, 2016, 07:26:54 PM
Can you show me your setup so i can do the same with my canon 80D! Please
You need not only the photodiode connected to a serial port but a signed fw for your 80D...
But if a1ex can dump the 7D2 I'm sure the 80D will be the next.
Thanx man!! :D
Hi everyone...
I just received my 7d mk ii yesterday. I've upgraded from a t2i. yay!
There's no ML. boo.
I don't have any coding to contribute, but inspiration! Keep trying. Alot of us are depending on you.
I guess I'll patiently wait with the rest of you.
Thanks devs.
~Eric
Ditto.
I'm not a smart person when it comes to things like coding. It takes a different kind of brain than the one I've got, but I'm very thankful for those at ML who do such amazing things. So I just wanted to express my gratitude. I had assumed ML would never come to the 7D MKII, and I'm ecstatic to see that you guys are working on it. I understand that each camera is like a puzzle, and it takes a lot of hard work to crack.
I'll be silently watching and rooting for you.
Once again, THANK YOU.
Don't know what testing is left but my 7D2 should be available this weekend.
Hi
You may have had issues, it will be from ML 7d mk2 ?
thx
Please rephrase your question ...
when to expect magic lantern from 7D MK II ?
thx
When it's ready.
Top of page -> User Guide -> FAQ -> Troll Questions section
Is someone working on ML for 7D Mk2? What's the latest update news, if any? Thx!
Refer the post inmediately before yours.......
Sent from my GT-I9505 using Tapatalk
Patience. a1ex, Pelican and some others are working to dump the firmware. It'll get here when it gets here.
Quote from: a1ex on July 16, 2016, 10:38:25 AM
(http://a1ex.magiclantern.fm/bleeding-edge/7D2/DISP-7D2.JPG)
(thanks atonal)
Note: this was made possible after looking at the 80D bootloader (http://www.magiclantern.fm/forum/index.php?topic=17434.msg169638#msg169638), so credits go to zloe as well :)
Nice!!!
That's awesome! Thanks for your hard work guys, especially a1ex, atonal and zloe. Great progress with DIGIC 6.
EDIT: P.S. It will be interesting to see the results of resolution/binning/crop mode (once we get there) and continuous recording as well.
Is there anything we, mere mortals can do to help? What are the next steps?
I think - speaking of development - there is not that much "we mere mortals" can do right now. There is some dirty (and sometimes boring) work to do poking into the (hay)stack. It will take serious hours (estimated 3 digits range?) to make ML run on 7D2.
But there is work to do all the time. Documentation is a big and ongoing issue. Take a look into Audionut's signature http://www.magiclantern.fm/forum/index.php?action=profile;u=469
Any supporter/mere user with a cam running ML can dig in.
Hey, I wanted to know, where your Code for the 7d2 can be found, so that I could start building my custom version of ML for the 7d2 ? ;)
You can follow progress on bitbucket: https://bitbucket.org/hudson/magic-lantern/branch/7D2-dumper
The silence is deafening.... Calm before the storm?
Anyhow, it will be very interesting to see what Canon has up their sleeve for the rumored upcoming firmware update to the 7D2. I hope it brings more than just functionality to the rumored WiFi accessory that is soon to be announced. 4K video???
Quote from: ddelreal on August 09, 2016, 10:07:52 PM
The silence is deafening.... Calm before the storm?
Nope, I'm a bit stuck. Trying to jump to Canon firmware on the slave processor doesn't work (I need to see the bootloader code), and LED blinking from that processor doesn't work either. So, I have to understand the IPC mechanism (inter-processor communication, I guess) and how to use it from the master processor's bootloader (the place where I can run user code) in order to dump the slave bootloader.
The 80D will be easier, as I was able to jump to Canon firmware, but there I have trouble with self-modifying code (caches) on the new ARM architecture. I still have a few things to try, but the ARM documentation is a bit overwhelming for me (so, any help is welcome).
For 760D/750D, probably similar to 80D, I have no feedback (I sent a few copies of the firmware dumper, but there was no response from the testers).
Well I disappear for a short while and almost missed the boat!
Quote from: a1ex on August 10, 2016, 03:35:22 AM
Nope, I'm a bit stuck. Trying to jump to Canon firmware on the slave processor doesn't work (I need to see the bootloader code), and LED blinking from that processor doesn't work either. So, I have to understand the IPC mechanism (inter-processor communication, I guess) and how to use it from the master processor's bootloader (the place where I can run user code) in order to dump the slave bootloader.
The 80D will be easier, as I was able to jump to Canon firmware, but there I have trouble with self-modifying code (caches) on the new ARM architecture. I still have a few things to try, but the ARM documentation is a bit overwhelming for me (so, any help is welcome).
For 760D/750D, probably similar to 80D, I have no feedback (I sent a few copies of the firmware dumper, but there was no response from the testers).
Hi A1ex
I'm more than willing to help.
I have a 7D II, admittedly limited programming experience (Bit of python and C++) but indepth knowledge of decoding hex in unique applications/filesystems.
(Already mapped out the FW for 1.0.4 months ago then realised they encrypted it with new keys and no tool to extract)
Anyway, anything you want me to try i'd be more than happy to help.
Ah, gotcha. I'll reach out to my coding friends to see if they can help.
Hi @A1ex
Just a quick update as I was getting myself upto speed. (Installing arm, Mercurial etc)
Anyway, spotted a little bug that might stumble some.
I tried the DUMMY7D2 and BLINK7D2 FIR files and they would not work.
Turns out if you have normal firmware files on your card the selection menu comes up and this triggers some kind of check which makes the two files invalid.
Renaming the other files got the BLINK7D2 file to work.
However I do not have a photodiode to dump the FW. Pity no one has done a headphone output instead (Given there is a photodiode to mic input method).
So i'll be pretty much stuck till I can dump the FW.
Anyway moving on.
I did compile your 7D2-dumper, but noted it only gives me Autoexec.bin and Magiclantern.bin and no .FIR file due to the missing build_fir7.py file which I understand to be the AES encryption to make a FIR file.
Any chance you can make a bootflag FIR file so I can get it to read the Autoexec.bin files as I understand they don't have to be encrypted and would allow me to help out.
Currently trying to get QEMU installed but I obviously won't be able to get that working without FW either.
Cheers.
Hi A1ex,
I was about to buy a 70d to run ML but I'd consider getting an 80d to help out testing, the guy in the other thread that was helping out says he's back tho. As far as doing physical modes or coding. I'm no help. Totally not my field of experience. If there's a chance 80d can be cracked id be willing to give it a shot instead of the 70d
Please find a test I'd like you to run on DIGIC 6 cameras: http://www.magiclantern.fm/forum/index.php?topic=17714
@JagoUK: normally, we enable the boot flag after being able to run user code on top of main firmware. I could try to enable it on the master processor from the bootloader (we did that on the old 5D), but the bricking risk is pretty high, because I have no idea what to do about the slave processor.
If any of you have a 7D2 body you don't mind tossing out, I can give it a try. It may be best to try on a cheaper DIGIC 6 body first.
Hi A1ex
Responded to your other post, as did atonal.
As for bootflag firmware.
I was under the impression the bootflag is a simple switch using a known command ENABLEBOOTFLAG and not sending random commands?
As long as there is not a bootable card in containing an Autoexec.bin the camera should boot properly no?
I appreciate running an Autoexec.bin with bad code could be a big problem though.
I am happy to give it a try if my interpretation is correct.
Would like to get on with being able to dump firmware as I have a photodiode connected via a raspberry pi but the recordings appear very noisy (Might be due to the pi)
Anyway let me know and i'll do what I can to help. I have already managed to compile your autoexec.bin so customising the code should be ok this end.
Cheers
Thanks @JagoUK for all your help. You, a1ex, atonal and others working on 7D2 are greatly appreciated!
No need to thank me, i've not done anything.
Any luck with this bootflag Alex?
I see you have a dumper for 80d, any chance of one for 7D2? Would really like to get a look at the FW. Obviously bootflag is more important as I could craft my own dumper if bootflag was enabled.
Cheers
I've compiled the 80D dumper for 7D2 (DMPD-7D2.FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/DMPD-7D2.FIR)), but given the previous tests on this camera, I don't have high hopes. But you are welcome to give it a try.
If it works, that would make the bootflag enabling process a lot easier.
Thanks for trying. Afraid it does not work. Camera locked up and wouldn't respond to power button or card flap. Had to take battery out.
https://www.dropbox.com/s/2vc6s05oi7tp0iz/7d2.png
There was an image embedded, but for some reason this forum does not like dropbox links in its own IMG tags? Untagged it now.
I tried to use the blinker last night to get the firmware out
I seem to be having the same issue as Fraggy where every byte seems the same.
QuoteSo i tested LCD Firmware... And it worked...
So next step is testing the extractor...
Got no sync...
Looks like every blink contains the same bit...
https://www.dropbox.com/s/2f91dqj1xd43t5b/7d2%20dump.png
The blinker linked above is just a simple LED test.
I've compiled a dumper for 7D2 bootloader, using the CHDK soundcard method, here: BDMP-7D2.FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/BDMP-7D2.FIR). The decoder is under contrib/led_blink_dumper in the digic6-dumper branch.
Finally got the 7D2 in my hands from a co-worker. Downloaded and installed BDMP-7D2.FIR. Ran firmware update and now I get a constant led blink (no flashing) just stays on. I plan on taking the battery out. Am I expecting anything to be written on the card?
Also let me know if you still need me to run CPUI-7D2.FIR from CHDK cpuinfo (http://www.magiclantern.fm/forum/index.php?topic=17714.msg170993;topicseen#msg170993CHDK%20cpuinfo) thread?
Quote from: a1ex on August 22, 2016, 02:46:25 PM
I've compiled a dumper for 7D2 bootloader, using the CHDK soundcard method
Definitely needed coffee. Thanks for the reminder, Walter and now I gotta ask the guys around here at work to see if they have a soundcard device for me to use.
Your PC has no mic input jack?
My MBP does have an input jack ... if I were to find a 3.5mm jack and plug one end into the 7DII whilst the other end into the MBP -- which software can I use to read the LED blinker (if any)?
Quote from: a1ex on August 22, 2016, 02:46:25 PM
The blinker linked above is just a simple LED test.
I've compiled a dumper for 7D2 bootloader, using the CHDK soundcard method, here: BDMP-7D2.FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/BDMP-7D2.FIR). The decoder is under contrib/led_blink_dumper in the digic6-dumper branch.
Hi Alex.
Thanks for that, unfortunately I have had to order a new diode so will have to wait till tomorrow.
One thing I have noticed is that the flashing appears to stop after 5mins. Isn't this too quick for a 30MB dump?
Shame the dump to card does not work.
Bootloader is 640K, so I guess it should be fine. This is the dumper that worked on 80D, but there we had to dump the entire thing. On 7D2, I need the two bootloaders, but I only know how to dump one of them.
Ah ok, BDMP-7D2.FIR is to dump the 1st Bootloader only (should have read closer!).
Wouldn't a dump of all the whole ROM capture both bootloaders?
You need a diode for the sound card method?
Quote from: ddelreal on August 22, 2016, 10:48:57 PM
You need a diode for the sound card method?
Yes, you capture the Blinks of the LED from the Card Port.
http://chdk.wikia.com/wiki/Obtaining_a_firmware_dump#Using_soundcard_input
I had it working with a Raspberry Pi on the GPIO port pin 18 too but this seems easier. I just cut off a 3.5mm jack off a set of old Apple headphone (4pole to match my laptop dual mic/headphone port.)
I was using an IRled that I shaved the IR coating off but it ended upbreaking after too much abuse so I just ordered a set of 20 photodiodes for £2
Quote from: a1ex on August 22, 2016, 10:26:31 PM
Bootloader is 640K, so I guess it should be fine. This is the dumper that worked on 80D, but there we had to dump the entire thing. On 7D2, I need the two bootloaders, but I only know how to dump one of them.
Hi Alex.
New photodiodes arrived.
Almost there, having some sync errors in the decoding, but interesting stuff coming out.
https://www.dropbox.com/s/qsopaubye3c5fd5/bootflag.png
https://www.dropbox.com/s/ky82acqbnnidkko/master-slaveRAM-ROM.png
https://www.dropbox.com/s/gworqqeu2zrbrem/SD-CF-SLAVE.png
Think I may have found the problem! AGC on my mic port. Now to find out if I can turn it off!
Yes, while in movie mode, you can go to the audio menu and switch to Manual.
Quote from: JagoUK on August 23, 2016, 08:35:48 PM
Think I may have found the problem! AGC on my mic port. Now to find out if I can turn it off!
http://superuser.com/questions/362343/how-do-i-disable-microphone-volume-auto-adjusting
Quote from: ddelreal on August 23, 2016, 09:29:23 PM
Yes, while in movie mode, you can go to the audio menu and switch to Manual.
I was referring to the Mic input on Laptop.
Quote from: Pelican on August 24, 2016, 12:44:49 AM
http://superuser.com/questions/362343/how-do-i-disable-microphone-volume-auto-adjusting
Problem is it does it in Windows and Linux.
I have managed to get a 217K dump so far
Quote from: JagoUKI was referring to the Mic input on Laptop.
Ah, sorry.
Quote from: JagoUK on August 24, 2016, 01:21:56 AM
I have managed to get a 217K dump so far
Haven't you used the dumper which dumps the 0xffff000-ffffffff area? That is only 64 kB.
Quote from: Pelican on August 24, 2016, 02:37:58 PM
Haven't you used the dumper which dumps the 0xffff000-ffffffff area? That is only 64 kB.
The DIGIC 6 cameras don't boot using HIVECS, instead they start at *(uint32_t*)0xFC000000 (which is FC000008 on EOS and a non-round value on M3/M10).
Bootloader on EOS DIGIC 6 cameras is from FC000000 to FC0A0000. On 7D2, there is a bootloader on each CPU, at the same address (each CPU has its own memory), but I only know how to access one of them. Trying to blink the LED from the other CPU did not work.
Too early to put a sticky on this thread?
Oh yes, far too early.
I sent A1ex a copy of what I could get earlier, hopefully it had something useful in it.
I will keep trying to flash the whole code out but I cannot seem to disable AGC.
The program to convert is supposed to allow you to use multiple dumps to create a complete dump but it doesn't seem to be working. (Or you have to manually dump the right parts, instructions are not clear)
Are you on a Mac?
Quote from: ddelreal on August 24, 2016, 11:16:12 PM
Are you on a Mac?
Quote from: JagoUK on August 24, 2016, 01:21:56 AM
I was referring to the Mic input on Laptop.
Problem is it does it in Windows and Linux.
I have managed to get a 217K dump so far
Nope just a normal PC laptop.
Not got anything else to record it onto (Phone didn't like it either)
I'm thinking the diodes are sophisticated enough to have their own gain.
Regarding the EOS 7D Mark II digital SLR camera, we are planning to release Firmware Version 1.1.0 for download from the Web in order to enhance the functions.
this should help I hope. 8)
I think they're trying to get a dumper on the current version. The dual Digic6 on the 7D2 seems to be especially difficult.
Don't know if this helps but the new firmware is available:
https://www.usa.canon.com/internet/portal/us/home/support/details/cameras/dslr/eos-7d-mark-ii/eos-7d-mark-ii#drivers_downloads_tab
Quote from: ddelreal on September 08, 2016, 05:04:43 AM
Don't know if this helps but the new firmware is available:
https://www.usa.canon.com/internet/portal/us/home/support/details/cameras/dslr/eos-7d-mark-ii/eos-7d-mark-ii#drivers_downloads_tab
Cheers for that, thought we were going to have to wait a little while longer for it.
I would advise against upgrading as I believe recent FW has disabled the ability to downgrade FW and currently only v1.0.4 is being worked on. (1.0.5 has the ability to roll back to 1.0.4)
could make sense to upgrade if one owns the W-E1 adapter agreeing also to dismantle it and solder some wires onto it as well as modify the sdcard door for the wires to hang out while the card is inserted. I am interested in the serial output. Guess it's some kind of PTPoIP but also think that Canon uses some init sequence to identify it's own card prior allowing the communication / wifi to become active.
Please try: Is EOS Utility 2.x able to communicate with the cam and firmware update menu available?
Quote from: JagoUKCheers for that, thought we were going to have to wait a little while longer for it.
I would advise against upgrading as I believe recent FW has disabled the ability to downgrade FW and currently only v1.0.4 is being worked on. (1.0.5 has the ability to roll back to 1.0.4)
Good info, thanks for that. My cameras came with 1.0.5 already installed, I can't find 1.0.4 anywhere on Canon's site. Can somebody point me in the right direction to get that just in case?
I don't mind the upgrade to the latest version; only JagoUK should stay on 1.0.4 for the first boot flag test (otherwise he'll have to blink the bootloader again).
The tools from this thread (blinker, soundcard-based dumper, and non-working SD card dumper) are portable (they should work on any firmware version). Do they work on the latest?
1.0.4 (win) firmware package:
https://www.dropbox.com/s/xjvh6z4kplrwi2u/eos7d2-v104-win.zip
Pelican's repository should do well: http://pel.hu/eoscard
And "win" does not mean that much but win-win: Unzip and use it. OS X/Windows/Linux ...
Thanks guys.
Thanks devs and testers for all of your hard work.
Hi guys,
I'm a (web)Developer and 7D2 owner.
Is there a step trough guide to help me set up for testing?
The person who finally gets this working will be my greatest hero. Please keep up the great work! I know this is hard but its so worth it!! I LOVE ML. Just think of the raw video capabilities of the 7D Mark ii. Its gonna be amazing! Maybe even 4k too!!
I just made an account for the forum to say thanks to all the developers who are currently working on a 7DII ML built!
Used Magic Lantern since I got my t2i 3 years ago and hope that it will be available for the 7DII as well in the future.
Until then, don't give up developers, you'll make it!
Good luck from Germany :)
Quote from: mmellwayThe person who finally gets this working will be my greatest hero. Please keep up the great work! I know this is hard but its so worth it!! I LOVE ML. Just think of the raw video capabilities of the 7D Mark ii. Its gonna be amazing! Maybe even 4k too!!
Couldn't agree more.
Hi everyone !
I stopped by and couldn't believe: this is happening! You, Great developpers out there are going to make the best ML support ever for a canon DSLR. For that thanks a lot !
I know it won't be that simple, but I give you a lot of support from France.
Keep the good work guys !
:) :D
Hello everyone! I'm curious if anyone believes it's possible to write a dual pixel moduke for the dual pixel sensors, not for the focus shift but is it possible to apply ISO gain to half of the information from the pixel and get a dual iso without resolution loss. I'm curious, what other possibilities does magic lantern have if each pixel can record two different values?
www.magiclanternrumours.com (https://www.youtube.com/watch?v=oHg5SJYRHA0)
Ohh Walter you got me good :P
Do you not have faith in these guys? They were unable to unlock raw video recording, you don't think they could unlock the dual pixel?
http://wiki.magiclantern.fm/faq#any_progress_on_xyz
If there hasn't been anything posted on the progress of it in weeks, I think it's safe to assume it's dead. At least for the time being.
so. its officially released for 5Div but not yet for 7dii .. feels so bad :(
Officially released? 5D4? I don't think so.
hesham007 is probably talking about this:
http://www.canonrumors.com/magic-lantern-cracks-the-eos-5d-mark-iv/
That is not an ML official release announcement, and does not show ML running on 5D Mk IV. It only shows the portable binary test (http://www.magiclantern.fm/forum/index.php?topic=14732.0), that runs on many cameras that do not have a ML port for them.
And as A1ex said (http://www.magiclantern.fm/forum/index.php?topic=17360.msg172928#msg172928), the first ML port for Digic 6/6+/7 cameras probably will be the 80D port. Porting ML to 7D Mk II is a lot more challenging, because of the dual Digic.
Quote from: hesham007 on November 07, 2016, 11:39:34 PM
so. its officially released for 5Div but not yet for 7dii .. feels so bad :(
Forget about 7DII ML. I'm sorry guys, but you bought wrong camera.
Quote from: KelvinKForget about 7DII ML. I'm sorry guys, but you bought wrong camera.
I don't believe that. ML for the 7D2 may be more difficult to achieve because of the Dual Digic, but IMHO, it would be one of the best for ML.
Quote from: ddelreal on November 09, 2016, 05:32:43 PM
I don't believe that. ML for the 7D2 may be more difficult to achieve because of the Dual Digic, but IMHO, it would be one of the best for ML.
Being "one of the best for ML" is not a guarantee of being achievable, IMHO.
Quote from: ddelreal on November 09, 2016, 05:32:43 PM
I don't believe that. ML for the 7D2 may be more difficult to achieve because of the Dual Digic, but IMHO, it would be one of the best for ML.
There's no need to believe it or not :) It's a fact. The main reason why old 7D got ML port was quite big amount of camera owners and devs with free time. 7D was a successful Canon's camera and was one of the best crop camera at time of release. 7D2 unfortunately not at all.
Quote from: eduperezBeing "one of the best for ML" is not a guarantee of being achievable, IMHO.
Agreed, never meant that it should. Just a hope.
Quote from: KelvinKThere's no need to believe it or not :) It's a fact. The main reason why old 7D got ML port was quite big amount of camera owners and devs with free time. 7D was a successful Canon's camera and was one of the best crop camera at time of release. 7D2 unfortunately not at all.
Yeah, I get it. I have already been in contact with a couple of Devs over PM about it, I understand that it takes time and the dual Digic is more difficult. The 7D2 may never see ML and I'm okay with that. My opinion is that the 7D2 could be the crop version of the 5D3 with ML - Dual Pixel Auto Focus doesn't hurt either. Also, to your point about "wrong camera", I love my 7D2's. I use them with a Ninja2 and get beautiful ProRes 422HQ - even though it's still 8 bit, the 422 color space helps somewhat.
dont forget that adding even the most unimportant feature to ML will cause the effort to check its impact on a dozen cameras.
will it boot? will it work? does it cause weirdnesses? etc.
dropping 10 old camera models and make a "new models only" version would make you happy.
and a million of other users unhappy.
Purchased my 7D2 this time last year for an amazing deal of £800, was really pleased with it but the video was not quite there as we all probably agree which is why we're here. What does everyone think, sell my camera now for more than I bought it most likely and move to mirrorless, or wait it out for this development. I am confident the talented devs will get there one day after learning more about the Dual digic chips but just not sure if I am prepared to wait. Anyone on the fence like myself? Would like to hear what others are going to do with their slightly annoying 7D2's. (I am thinking sony alpha platform at this stage but don't really know much about it)
P.s I call the camera annoying but don't get me wrong; the stills from this camera are beautiful.
Act like there will never be ML for the 7D2. In the meantime, I just use the Atomos Ninja 2 to record ProRes 422HQ via the clean HDMI out (using Technicolor Cinestyle).
How do you find grading cinestyle prores footage vs the cameras internal rec with cinestyle?
Just a minor improvement. It's still 8 bit but at least it's 422 color space. Helps (very little) with highlights, less banding.
Sorry for my opinions but if everyone really need RAW video just get a blackmagic pocket or micro they are both 1080p 23.98, 24, 30 fps and micro has 59 and 60 fps.
Well since I already own a couple of 550D's and a couple of 7D2's, I'd say it's a welcome addition to have Magic Lantern available for Raw and other things (hoping 7D2 version comes soon). If I were to purchase any new camera now it would shoot 4K or better at this point. Neither BMC Micro and Pocket offer that.
I'm actually considering the new DJI X5S with the Inspire 2 Drone, shoots 5.2K Raw.
Hi All
Great to see some great progress in attempting to port ML to 7DMk2 or 80D. Which brings me to this question. I have a 40D thats got a broken CF pin and needs some TLC, so in the meantime I need to replace my camera. Tossing up on a 7DMk2 or an 80D. Which would be most likely to get a port for ML and could I assist in anyway? I have some background in electronics and can certainly run up some photo diodes/serial ports etc to assist. No programming or debug knowledge however sorry. Unsure of FW version on camera when I purchase either.
Let me know.
Thanks
Magic Ball says: 80D will get ported first.
But there is no ETA. Count years, not weeks.
Hi there,I am using Canon 5D Mark iii with your firmware and many thanks for your works. The words are not enough to explain my respect to you guys.
I want to ask you simple question about 7D Mark ii. As far as i can see Canon will never use 4K option in their Cameras until bankruptcy of their company. If Magic Lantern wont do something there will never be 4K in 7D Mark ii. Before selling my 7D Mark ii, I want to ask you that do you have any plan about Magic Lantern for 7D Mark ii ? I am still struggling for using the Canon because I cant left my lens sets, I spend many of year for collect them and there is an emotional connection between us:).
Have a Good Evening
Best Regards
Iskender Sisman
Quote from: isko on December 21, 2016, 07:47:39 PM
As far as i can see Canon will never use 4K option in their Cameras until bankruptcy of their company.
https://www.dpreview.com/reviews/canon-eos-5d-mark-iv/12
Quote
The 5D Mark IV is capable of capturing 4K video at both 24p and 30p
I'm not sure, but ... isko, he speaks about something else, about the alternative firmware .... no?
Got a 7dII here. I'm in for tests and other stuff even if I'm a noob in programming.
Inviato dal mio LG-D855 utilizzando Tapatalk
I too, have a 7DM2 and would love to beta test any version of ML that may be in the works :)
If there's anything worth testing, it can be found in this thread.
Is there anyone in or around the Seattle, WA area that would like to collaborate on this? I really am ignorant when it comes to much of this stuff but I would like to help and get ML on the 7D2.
7D2 is probably the last Digic 6 cam you want to start deployment with because it's dual processor architecture is known to cause major headache.
Some people are working on the first Digic 6 port for other cams.
You probably have to wait long, long time to see ML for 7D2. In the meantime: Don't hold your breath!
Quote from: Walter Schulz on April 15, 2017, 06:44:13 AM
7D2 is probably the last Digic 6 cam you want to start deployment with because it's dual processor architecture is known to cause major headache.
Some people are working on the first Digic 6 port for other cams.
You probably have to wait long, long time to see ML for 7D2. In the meantime: Don't hold your breath!
Yes, I am aware. I'm seeking someone local that I can work with and she/he can show me and work with me in person on the 7d2. If working on other Digic 6 first would make the 7d2 easier we can start there.
If you find someone willing to go with Digic 6: This offer (http://www.magiclantern.fm/forum/index.php?topic=17627.msg179772#msg179772) hasn't been taken yet.
Can any digic 6 camera work? Can I go buy a cheaper PowerShot? I wouldn't mind if that bricked. I've got a 7d2 too.
Quote from: hindra on April 16, 2017, 10:20:14 PMCan I go buy a cheaper PowerShot?
Powershots and M3 do use other code. That's CHDK realm.
and M5, M6, M10...
M3 and M10 already run CHDK :P
FYI. New firmware v1.1.1 just came out. Minor changes.
Firmware Version 1.1.1 incorporates the following improvement and fix:
Enhances reliability of communications when transferring images using Wireless File Transmitter WFT-E7 (A/B/C/D/E).
Corrects the phenomenon of Err70 which occurs with certain combinations of settings.
Corrects the phenomenon in which in very rare cases the shutter can no longer be released.
Enhances reliability of operations for specific custom function settings.
Read more: http://www.canonrumors.com#ixzz4flBiPYCW
And
Quote from: khrisgarcia on April 30, 2017, 08:46:54 PM
FYI. New firmware v1.1.1 just came out.
And revoked by Canon last week.
http://www.canonrumors.com/canon-pulls-firmware-v1-1-1-for-the-eos-7d-mark-ii/
Thought I'd check in on this today. Not that I expected there to be any news on this front, it's just still disappointing this camera most likely wont get ML when it has so much potential. Oh well
Quote from: DigitalVeil on May 27, 2017, 09:16:30 PM
Thought I'd check in on this today. Not that I expected there to be any news on this front, it's just still disappointing this camera most likely wont get ML when it has so much potential. Oh well
Agreed.
And firmware 1.1.2 in on the road.
Corrects a problem after updating from 1.0.5 or earlier to 1.1.1.
Problem does not happen after updating from 1.1.0 to 1.1.1.
Link to Canon USA (https://www.usa.canon.com/internet/portal/us/home/support/details/cameras/dslr/eos-7d-mark-ii/?tab=)
Ready to enable the boot flag: http://www.magiclantern.fm/forum/index.php?topic=17360.msg189584#msg189584
BOOTU7D2.FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/BOOTU7D2.FIR)
(still don't know how to jump to main firmware, but...)
Registered an account just to say great work A1ex, keep it up :D
Quote from: a1ex on September 03, 2017, 10:04:06 PM
Ready to enable the boot flag: http://www.magiclantern.fm/forum/index.php?topic=17360.msg189584#msg189584
BOOTU7D2.FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/BOOTU7D2.FIR)
(still don't know how to jump to main firmware, but...)
Hi Alex
Nice to see you trying 7dmkii again.
Just to let you know I tried your bootflag enabler. It ran but didn't set bootflag :(
(http://thumb.ibb.co/kjFO15/bootflag.png) (http://ibb.co/kjFO15)
The BOOTU7D2.FIR was a dummy version; it did not actually enable the boot flag, but only printed what it's going to do. To enable it:
BOOTF7D2.FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/BOOTF7D2.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) (not working on 7D2, figure out why)
- 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)
Have fun!
@JagoUK: I still need a copy of the 7D2 booloader (currently I have the blinked one from you, with errors); maybe you can try g3gg0's graphical dumper (http://www.magiclantern.fm/forum/index.php?topic=17714.msg189692#msg189692) from the recovery branch?
Quote from: a1ex on September 19, 2017, 01:55:14 AM
The BOOTU7D2.FIR was a dummy version; it did not actually enable the boot flag, but only printed what it's going to do. To enable it:
BOOTF7D2.FIR (http://a1ex.magiclantern.fm/bleeding-edge/7D2/BOOTF7D2.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) (not working on 7D2, figure out why)
- 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)
Have fun!
@JagoUK: I still need a copy of the 7D2 booloader (currently I have the blinked one from you, with errors); maybe you can try g3gg0's graphical dumper (http://www.magiclantern.fm/forum/index.php?topic=17714.msg189692#msg189692) from the recovery branch?
Hi Alex, yes found the F version and enabled flag ;D
(http://thumb.ibb.co/ngqLEQ/bootflagok.png) (http://ibb.co/ngqLEQ)
Tested on camera and confirm dumper didn't work btw, i'll see if I can reset my environment to compile the graphical dumper.
Useful bit of info for anyone else testing.
With the autoexec.bin files they will freeze on a pink screen (Even without turning power on) unless you do a specific sequence to load.
Open battery compartment.
Eject battery.
Open memory card compartment.
Remove memory card.
Reinsert memory card.
Close memory card compartment.
Insert battery.
Close battery compartment.
Turn on camera.
Any other sequence including skipping ejecting SD card results in a pink screen with no text.
Tested with
Portable display
http://www.magiclantern.fm/forum/index.php?topic=14732.0
Portable rom dumper (Pink screen then goes to a black backlit screen)
http://www.magiclantern.fm/forum/index.php?topic=16534.0
EDIT:
Interestingly the CPUINFO doesn't work from here
http://a1ex.magiclantern.fm/debug/portable-cpuinfo/autoexec.bin
Just gives the first two lines of text
CHDK CPU info for 0x289 7D2
-----------------------------------------
Then nothing.
The FIR file did work ok. Not sure if 7D2 is not enabled in source though.
Hey, I decided to poke around and I got this.
What does it mean when everything except the firmware file loads fine?
Here is what I will contribute:
(http://thumb.ibb.co/eoBbWR/IMG_2976.jpg) (http://ibb.co/eoBbWR)
Thanks!
I want magic lantern on my new 7Dm2 :(
Welcome to ML development! You know where to start, I suppose.
I am not a techie, but i keep coming back here to see if there is any development happening to ML build for 7dm2 :-\
Thanks to everyone for all your hardwork. Hoping this camera will become a beast someday with ML.
:D
You could try selling your 7D2 and perhaps use the $ for two or three decent used 7D bodies. Recently 10-12-bit was just finally made possible (http://www.magiclantern.fm/forum/index.php?topic=5601.msg194222#msg194222finally%20made%20possible) to record on it and maybe Lossless eventually will quirk its way into this ageless gem!
Let me wait for sometime. :)
If nothing happens. Sadly i will switch to sony a6500. :-\
Well I decided to pop back and check in after I found a CF card.
I've tested the portable binary display tester (Autoexec.bin) which now works
(https://thumb.ibb.co/d2Z5DU/Display_Tester_SD.png) (https://ibb.co/d2Z5DU)
I've tested the portable rom dumper (May 2018) which now displays info but still doesn't dump
ROMBASEADD Cycles down to 0xFE0A0000
(https://thumb.ibb.co/gf3Af9/May2018_PRD_SD.png) (https://ibb.co/gf3Af9)
As for the CF card (Which is the primary card in the camera)
When I run DMPD-7D2.fir from the CF as opposed to the SD card I get a graphical glitch at the top of the screen like it is reading through data (Lasts about 30 seconds and wrapped around the screen)
(https://thumb.ibb.co/i0PSSp/DMPD_7d2_fir_CF.png) (https://ibb.co/i0PSSp)
If I can find a CF card reader i'll test the PRD on it given that it finds the ROMBASEADDR..
Just found the portable binary test for rom layout checking. Posting here for completeness.
(https://thumb.ibb.co/eM2Zq9/romlayout_sd.png) (https://ibb.co/eM2Zq9)
Maybe also worth mentioning that g3gg0's 5DS experiments (https://www.magiclantern.fm/forum/index.php?topic=22267.0) are probably valid for 7D2 as well. At least the boot trick should be similar, if not identical.
@JagoUK: does it help if you write the 256MB image to the SD card? The dumper definitely works in QEMU (https://builds.magiclantern.fm/jenkins/view/Experiments/job/QEMU-tests/344/console) and was confirmed to work on most other DIGIC 6 and 7 models, with the card formatted as 256MB. That detail is important, as Canon's bootloader FIO routines don't seem to like large cards (https://www.magiclantern.fm/forum/index.php?topic=16534.msg200458#msg200458).
7D2M: SD: ROM1.BIN: OK
If you want to use CF card for ROM dumping, just replace DRIVE_SD with DRIVE_CF on the recovery branch, then compile from platform/portable.000 with CONFIG_BOOT_DUMPER=y .
Yes I used the SD.img.xz. Still did not dump.
I don't have a CF card reader and connecting camera only allows upload of .FIR files to CF card, won't allow autoexec.bin
Here is what happens when you run your old fir file from CF card.
https://youtu.be/PkcrWRHLGbA
Just to clarify, i'd rather use SD card as I can read that. CF card was just testing because I found one.
Ok i've tried compiling the portable dumper and getting this error.
(https://thumb.ibb.co/hehK8U/valuetoobig.png) (https://ibb.co/hehK8U)
Using /usr/bin/arm-none-eabi-gcc (from PATH).
../../src/Makefile.src:362: target 'isspace.o' given more than once in the same rule
Makefile:21: warning: overriding recipe for target 'magiclantern'
../../src/Makefile.src:197: warning: ignoring old recipe for target 'magiclantern'
[ VERSION ] ../../platform/portable.000/version.bin
Not building magiclantern.bin
[ CC ] reboot.o
reboot.c: In function 'print_line':
reboot.c:292:20: warning: assignment to 'char *' from 'long unsigned int' makes pointer from integer without a cast [-Wint-conversion]
log_buffer = (uintptr_t) log_buffer_alloc | caching_bit;
^
/tmp/ccVvWJ7V.s: Assembler messages:
/tmp/ccVvWJ7V.s:34: Error: invalid offset, value too big (0x00000BF0)
make: *** [../../Makefile.filerules:21: reboot.o] Error 1
Got a similar message with gcc-arm-none-eabi-7-2017-q4-major (different offset), but works fine with gcc-arm-none-eabi-5_4-2016q3 and gcc-arm-none-eabi-6-2017-q2-update. It seems to be from the "loaded_as_thumb" block. Fix pushed.
Here's what I did to diagnose the error:
# compile only, but don't assemble yet (to see how that temporary file looks like)
~/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi-gcc [blah blah, copied from "make V=1"] -S ../../src/reboot.c -o reboot.s
# now assemble it to see where exactly the error is
~/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi-gcc -c reboot.s
reboot.s: Assembler messages:
reboot.s:34: Error: invalid offset, value too big (0x00000664)
# reboot.s near line 34:
.code 16
loaded_as_thumb:
LDR R0, =1 <--- this is line 34
LDR R1, _cstart_addr
BX R1
NOP
_cstart_addr:
.word cstart
With "MOV R0, #1" instead of "LDR R0, =1" -> Error: cannot honor width suffix -- `mov R0,#1'.
With "MOVS R0, #1" it worked, here's why (http://www.keil.com/support/man/docs/armasm/armasm_dom1361289878994.htm).
Thanks.
It compiled despite errors.
Seems to be doing the same thing stuck on "Dumping ROM1..."
I'll leave it another 10 minutes.
Alright, so this route is likely not an easy one. Let's try what worked on 5DS (blindly, assuming their bootloaders are similar). Apply this patch on top of the digic6-dumper branch:
diff -r b2e0efa1d090 platform/7D2.104/Makefile.platform.default
--- a/platform/7D2.104/Makefile.platform.default
+++ b/platform/7D2.104/Makefile.platform.default
@@ -22,3 +22,2 @@
ML_MINIMAL_OBJ = minimal-d6.o
-ML_SRC_EXTRA_OBJS += log-d6.o stdio.o
endif
diff -r b2e0efa1d090 src/boot-d6.c
--- a/src/boot-d6.c
+++ b/src/boot-d6.c
@@ -52,2 +52,10 @@
+#if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+static void set_S_TX_DATA(int value)
+{
+ while ( !(MEM(0xD0034020) & 0x10) );
+ MEM(0xD0034014) = value;
+}
+#endif
+
void
@@ -96,2 +104,6 @@
+ #if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+ set_S_TX_DATA(0x20040);
+ #endif
+
// We enter after the signature, avoiding the
diff -r b2e0efa1d090 src/minimal-d6.c
--- a/src/minimal-d6.c
+++ b/src/minimal-d6.c
@@ -13,4 +13,18 @@
+static void led_blink(int times, int delay_on, int delay_off)
+{
+ for (int i = 0; i < times; i++)
+ {
+ MEM(CARD_LED_ADDRESS) = LEDON;
+ msleep(delay_on);
+ MEM(CARD_LED_ADDRESS) = LEDOFF;
+ msleep(delay_off);
+ }
+}
+
static void DUMP_ASM dump_task()
{
+ /* LED blinking test */
+ led_blink(5, 500, 500);
+
#if 0
@@ -32,6 +46,2 @@
#endif
-
- /* save a diagnostic log */
- log_finish();
- call("dumpf");
}
@@ -41,3 +51,2 @@
{
- log_start();
}
This disables the code parts for which we don't have the stubs defined yet, and enables a simple LED blinker on top of the main firmware (tested in QEMU). If that works, you'll be pretty much at the same stage as 80D after finding the missing stubs.
If that doesn't work, we'll need a good copy of the bootloader...
Cheers.
I'm getting a 404 when trying to clone the branch atm so will have to try later.
Quote from: a1ex on August 27, 2018, 08:13:57 PM
Alright, so this route is likely not an easy one. Let's try what worked on 5DS (blindly, assuming their bootloaders are similar). Apply this patch on top of the digic6-dumper branch:
diff -r b2e0efa1d090 platform/7D2.104/Makefile.platform.default
--- a/platform/7D2.104/Makefile.platform.default
+++ b/platform/7D2.104/Makefile.platform.default
@@ -22,3 +22,2 @@
ML_MINIMAL_OBJ = minimal-d6.o
-ML_SRC_EXTRA_OBJS += log-d6.o stdio.o
endif
diff -r b2e0efa1d090 src/boot-d6.c
--- a/src/boot-d6.c
+++ b/src/boot-d6.c
@@ -52,2 +52,10 @@
+#if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+static void set_S_TX_DATA(int value)
+{
+ while ( !(MEM(0xD0034020) & 0x10) );
+ MEM(0xD0034014) = value;
+}
+#endif
+
void
@@ -96,2 +104,6 @@
+ #if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+ set_S_TX_DATA(0x20040);
+ #endif
+
// We enter after the signature, avoiding the
diff -r b2e0efa1d090 src/minimal-d6.c
--- a/src/minimal-d6.c
+++ b/src/minimal-d6.c
@@ -13,4 +13,18 @@
+static void led_blink(int times, int delay_on, int delay_off)
+{
+ for (int i = 0; i < times; i++)
+ {
+ MEM(CARD_LED_ADDRESS) = LEDON;
+ msleep(delay_on);
+ MEM(CARD_LED_ADDRESS) = LEDOFF;
+ msleep(delay_off);
+ }
+}
+
static void DUMP_ASM dump_task()
{
+ /* LED blinking test */
+ led_blink(5, 500, 500);
+
#if 0
@@ -32,6 +46,2 @@
#endif
-
- /* save a diagnostic log */
- log_finish();
- call("dumpf");
}
@@ -41,3 +51,2 @@
{
- log_start();
}
This disables the code parts for which we don't have the stubs defined yet, and enables a simple LED blinker on top of the main firmware (tested in QEMU). If that works, you'll be pretty much at the same stage as 80D after finding the missing stubs.
If that doesn't work, we'll need a good copy of the bootloader...
Hi Alex, I applied the patch and loaded the SD card, when I powered on I got 4 solid blinks.
Was each blink 0.5 seconds on and 0.5 seconds off? If in doubt, change the delay to some larger values.
Were these blinks in background, while Canon's own firmware was running? Were you able to take pictures after the blinks?
If yes, try to take a picture with call("Release") at the end of dump_task. Otherwise, there's some double-checking to be done, but for that I need to know the full outcome of that patch (not just whether it blinked or not).
Quote from: a1ex on August 28, 2018, 09:44:10 PM
Was each blink 0.5 seconds on and 0.5 seconds off? If in doubt, change the delay to some larger values.
Were these blinks in background, while Canon's own firmware was running? Were you able to take pictures after the blinks?
If yes, try to take a picture with call("Release") at the end of dump_task. Otherwise, there's some double-checking to be done, but for that I need to know the full outcome of that patch (not just whether it blinked or not).
After switching on, card read then 4 blinks.
https://youtu.be/PkcrWRHLGbA
Sorry unsure what you mean by take a picture with call ("Release") at the end of dump_task?
Ah I take it you are referring to this?
Quote from: a1ex on March 07, 2018, 07:44:29 AM
On all EOS models we have tried (including DIGIC 7), we can execute custom code. The question is - can we do anything useful with it?
On DIGIC 7 (https://www.magiclantern.fm/forum/index.php?topic=19737), for example, we don't even know how to blink a LED (so our code does not have any visible side effects - we only know it runs because it locks up the camera).
On all DIGIC 6 models we have tried, we can display things on the screen from bootloader. Canon firmware is not running in this case, but it's useful to find out stuff about the hardware (find out what CPU (https://www.magiclantern.fm/forum/index.php?topic=17714.msg185363#msg185363) it has, dump the ROM (https://builds.magiclantern.fm/#rom-dumpers) and so on).
On some DIGIC 6 models (including 80D), we can execute this code alongside Canon firmware (for example, by starting DryOS tasks). This is a huge progress (compared to bootloader stage) and you can already start tweaking various functions in Canon firmware. You cannot print things on screen yet, but you can blink the LED and save files on the SD card.
Right now, you can compile from the digic6-dumper (https://bitbucket.org/hudson/magic-lantern/branch/digic6-dumper) branch and experiment. You can run these experiments either on camera, or - with some major limitations - in QEMU. I don't have any DIGIC 6 cameras (sorry, the GAS is over (https://www.magiclantern.fm/forum/index.php?topic=17627.msg191184#msg191184)), so please don't wait for me - start experimenting on your own. The codebase is ready for other developers to jump in and start porting. The emulator is also in pretty (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst) good (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst) shape (https://www.magiclantern.fm/forum/index.php?topic=17360.msg194898#msg194898) these days.
Tip: 5DS experiments (https://www.magiclantern.fm/forum/index.php?topic=17695.msg197085#msg197085) are also available, and useful as documentation.
Whetting your appetite: put this in dump_task (https://bitbucket.org/hudson/magic-lantern/src/digic6-dumper/platform/80D.102/minimal.c?at=digic6-dumper&fileviewer=file-view-default#minimal.c-118):
msleep(5000);
call("Release");
Don't try that with EraseSectorOfRom or other functions you don't know what they do ;)
BTW - if anyone skilled in ARM assembly is reading - this (https://www.magiclantern.fm/forum/index.php?topic=2388.msg196941#msg196941) will be very helpful for understanding how DIGIC 6 works. Code won't run out of the box, but can be debugged in QEMU first.
Well I finally finished.
I modified the portable display dumper to dump to CF card and it wrote to the SD card anyway :D
I have managed to dump the ROM1.
33,554,432 bytes
MD5 = 3179c1504591b28c1a01ec50c1927b03 ROM1.BIN.
Dumped successfully all 3 times and only took one minute too!
(https://thumb.ibb.co/fs15k9/dumprom.png) (https://ibb.co/fs15k9)
I think there is a bit of garbage data at the beginning and end so parameters may have to be changed.
Disp_Dump works too.
(https://thumb.ibb.co/dLeQk9/displaydump.png) (https://ibb.co/dLeQk9)
I tried to get the serial flash stubs dump but I don't even think the code is there for it?
(https://thumb.ibb.co/iG2OEe/B3_D76443_6_F5_C_49_DA_AD13_8_F925_AB05377.jpg) (https://ibb.co/iG2OEe)
That's rather our autodetection not recognizing the code patterns from 7D2 bootloader. Pretty sure this camera has a serial flash (otherwise there wouldn't be a SROM menu). The code is meant to be generic, for all DIGIC 6 models, but there may be some unhandled variations. It was tested on 80D, 750D (real hardware), 760D and 5D4 (QEMU), but I did not try it on 7D2 / 5DS yet.
You guys can do it, despite the time I've noticed they've come a long way. Courage, you can achieve it. :) :D
7D mk II is nice camera for 1080P 60fps
Watting magiclantern for 7D MK II
Quote from: JagoUK on August 29, 2018, 03:39:08 AM
I modified the portable display dumper to dump to CF card and it wrote to the SD card anyway :D
Reproduced the issue in QEMU - it crashes, hopefully because I didn't emulate the DIGIC 6 CF interface yet.
There is a string that suggests how drives are coded:
"select storage(1:SD 2:CF) :"
If you follow the code from there, SD is coded as 2 and CF is coded as 1 (they are reversed). In other words, the vanilla code (from the recovery branch) should dump to CF. Why did 0 even work?! I've noticed explicit checks whether drive_id is 2 in the bootloader...
Can you set boot_open_write to 0x102D10 and try to dump to CF (first argument 1) ?
That's pretty much a nitpick, as the dumper already worked on SD; I just wanted to understand why it locks up when using the CF card.
Hey guys!
We are all holding breath waiting for your success with ML for 7DMkII.
I have this camera, so if I can help somehow, please PM me.
Updated ROM dumper, but got no way to test. Does it work?
Quote from: a1ex on January 16, 2019, 09:06:18 AM
Master/Slave: 7D2 (https://a1ex.magiclantern.fm/debug/portable-rom-dumper/new/DUMP_7D2.FIR)
And btw... did anyone try the patch from reply #406 (https://www.magiclantern.fm/forum/index.php?topic=13746.msg205499#msg205499)? I don't see any valid feedback for that patch, in subsequent replies. The patch no longer applies cleanly on the latest codebase, so here's an updated version:
diff -r 6bc1f65d50dc platform/7D2.104/Makefile.platform.default
--- a/platform/7D2.104/Makefile.platform.default
+++ b/platform/7D2.104/Makefile.platform.default
@@ -21,5 +21,4 @@
ML_SRC_PROFILE = minimal
ML_MINIMAL_OBJ = minimal-d6.o
-ML_SRC_EXTRA_OBJS += log-d6.o stdio.o
endif
diff -r 6bc1f65d50dc src/boot-d6.c
--- a/src/boot-d6.c
+++ b/src/boot-d6.c
@@ -51,4 +51,12 @@
}
+#if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+static void set_S_TX_DATA(int value)
+{
+ while ( !(MEM(0xD0034020) & 0x10) );
+ MEM(0xD0034014) = value;
+}
+#endif
+
void
__attribute__((noreturn,noinline,naked))
@@ -95,4 +103,8 @@
sync_caches();
+ #if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+ set_S_TX_DATA(0x20040);
+ #endif
+
// We enter after the signature, avoiding the
// relocation jump that is at the head of the data
diff -r 6bc1f65d50dc src/minimal-d6.c
--- a/src/minimal-d6.c
+++ b/src/minimal-d6.c
@@ -73,6 +73,6 @@
/* save a diagnostic log */
- log_finish();
- call("dumpf");
+ //log_finish();
+ //call("dumpf");
}
@@ -81,5 +81,5 @@
{
#ifdef LOG_EARLY_STARTUP
- log_start();
+ //log_start();
#endif
}
@@ -89,5 +89,5 @@
{
#ifndef LOG_EARLY_STARTUP
- log_start();
+ //log_start();
#endif
Quote from: a1ex on January 19, 2019, 09:25:10 AM
Updated ROM dumper, but got no way to test. Does it work?
And btw... did anyone try the patch from reply #406 (https://www.magiclantern.fm/forum/index.php?topic=13746.msg205499#msg205499)? I don't see any valid feedback for that patch, in subsequent replies. The patch no longer applies cleanly on the latest codebase, so here's an updated version:
diff -r 6bc1f65d50dc platform/7D2.104/Makefile.platform.default
--- a/platform/7D2.104/Makefile.platform.default
+++ b/platform/7D2.104/Makefile.platform.default
@@ -21,5 +21,4 @@
ML_SRC_PROFILE = minimal
ML_MINIMAL_OBJ = minimal-d6.o
-ML_SRC_EXTRA_OBJS += log-d6.o stdio.o
endif
diff -r 6bc1f65d50dc src/boot-d6.c
--- a/src/boot-d6.c
+++ b/src/boot-d6.c
@@ -51,4 +51,12 @@
}
+#if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+static void set_S_TX_DATA(int value)
+{
+ while ( !(MEM(0xD0034020) & 0x10) );
+ MEM(0xD0034014) = value;
+}
+#endif
+
void
__attribute__((noreturn,noinline,naked))
@@ -95,4 +103,8 @@
sync_caches();
+ #if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+ set_S_TX_DATA(0x20040);
+ #endif
+
// We enter after the signature, avoiding the
// relocation jump that is at the head of the data
diff -r 6bc1f65d50dc src/minimal-d6.c
--- a/src/minimal-d6.c
+++ b/src/minimal-d6.c
@@ -73,6 +73,6 @@
/* save a diagnostic log */
- log_finish();
- call("dumpf");
+ //log_finish();
+ //call("dumpf");
}
@@ -81,5 +81,5 @@
{
#ifdef LOG_EARLY_STARTUP
- log_start();
+ //log_start();
#endif
}
@@ -89,5 +89,5 @@
{
#ifndef LOG_EARLY_STARTUP
- log_start();
+ //log_start();
#endif
Spooky, just checked here after months and you just posted too!
Just to let you know I tried your new dumper and it does dump to a 2GB formatted SD card.
Unfortunately the MD5 changes each time (prob due to areas dumped)
(https://i.ibb.co/N3npHW2/FCBA02-FA-13-E1-4-C05-BAFD-7-BF9666925-B9.jpg) (https://ibb.co/N3npHW2)
MD5 change is fine; Canon code is reflashing the main ROM at every camera shutdown. Card size is no longer an issue.
Does the patched startup code work?
I'm afraid I don't have an environment setup at the moment to compile the patched code.
When I used a larger memory card I got "Failed to mount partition, the format of the MBR was unrecognised". It was a 64GB card, I think FAT32 and not GPT.
64GB card: pretty sure it wasn't FAT32.
Startup code: autoexec.bin (https://a1ex.magiclantern.fm/bleeding-edge/7D2/autoexec.bin). It requires firmware 1.0.4. I'm currently integrating the 5DS experiments into the digic6-dumper branch (i.e. for all Dual DIGIC 6 models).
Tested in QEMU. Does it work on real hardware?
Hey fellas,
If I can help you with anything I will be happy to do that.
I'm not a programmer, but I have 7DmkII and various flash drives CF and SD from 1Gb up to 64Gb
If it is safe for camera I might try something that you need...
I'm a first year computer engineering student and an owner of 7D2. I know how to code in C, and would like to help, but i'm not sure where to start. I read the guide already and have the environment setup, but when I run 7D2 firmware, I got gray screen in QEMU. Also, I can't make any sense out of the discussion including this guide https://t.co/jZqGIQXMMT . I think I need some guide to get me started.
I also would like to know what is the difficulty/problems that prevent ML from porting into 7D2, and maybe I could help with that.
QEMU won't run the 7D2 GUI yet - it might do so in a few years. Yes, it's that difficult because of the Dual DIGIC architecture, and for this reason, not a priority for me. The good news - porting the basic ML features may not require support for both CPU cores - see e.g. the Hello World PoC for 5DS/R, also Dual DIGIC models.
In your case, it's a lot easier to debug on real hardware, i.e. adapting code already debugged on other D6 (single-DIGIC) models. I've already debugged the startup process in QEMU - this code is already used on other DIGIC 6 models, and - guess what - it was written for 7D2 first (but nobody confirmed it on this camera yet).
Start by compiling the digic6-dumper branch and report back. I expect Hello World to be working already - it compiles, but nobody tested it (see e.g. reply #422 - still waiting for a confirmation). You may follow other DIGIC 6/7/8 threads for hints.
Hi a1ex,
I have some experience in Android programming before, so I'd guess it's similar because this is also ARM, right? but in android, we have a tool where we can plug our phone in and debug the log. Is there similar tool available for my camera? Also, I read "how to develop magic lantern," but it doesn't seems to talk about "how to port into a new camera." I read the example of porting into EOS M2, but I got confused. In C, C++, when you comply, you end up with executable .exe right? What would be the complied file that i need to put on the camera and run it? Also, which piece of code that I need to tweak? Can you guide me roughly? I tried to search the forum already, but ended up inconclusive.
Thanks
Yes, the PoC code in the digic6-dumper branch (i.e. what you get by compiling from platform/7D2.104) does just that - logging. Hello World is in minimal/hello-world - same source code covering all DIGIC 4..8 models (for now).
This sticky topic (https://www.magiclantern.fm/forum/index.php?topic=991) should be a good starting point.
edit: you also have an Edit button, FYI ;)
I just realized that the branches is "a version" of the magic lantern. I thought i need to download the branches and put inside the main magic lantern clone, then compile.
So, I got autoexec.bin and ML folder, how do I execute that?
First you enable the boot flag in the camera (reply #390), then you make the card bootable (EOSCard/MacBoot/make_bootable.sh).
Then copy autoexec.bin to the card.
This flowchart (https://www.magiclantern.fm/forum/index.php?topic=23641.msg213338#msg213338) should help.
Quote from: a1ex on March 12, 2019, 10:59:48 AM
(https://a1ex.magiclantern.fm/bleeding-edge/ml-startup.png)
Thanks, I will give it a shot and report back
(https://i.ibb.co/rkPKz93/error.png) (https://ibb.co/rkPKz93)
i got some error during build, that's fine right?
No, you shouldn't get errors (some warnings are normal).
The issue is with some builds that there are no modules, then the build fails.
For the 77D I solve that by building one random module for another camera model (e. g. arkanoid for 5D3.113). After this I can do the 77D builds with "ML_MODULES=" without errors.
See https://github.com/calle2010/magic-lantern-77d-vagrant#compile-and-run-magic-lantern for examples.
(https://i.ibb.co/RyKksWN/good.png) (https://ibb.co/RyKksWN)
No luck
Even if you copy a sample module from other camera... it will be replaced when running "make zip".
If you want to use this method, look at console output to know what is getting compiled and after your see your selected module get compiled for 2nd time, then quickly copy and paste "modulename.mo" in modules/yourmodule path.
Otherwise you can simply use "make" and get only autoexec.bin compiled and then copy it into card.
At the moment ut is the only ML file needed in order to run Hello World and early d678 experiments
My camera lockup and it doesn't boot at all. autoexec.bin seems to be too small (12kb), for 5d3, it's 66kb in size
hg up digic6-dumper -C
cd minimal/hello-world
make MODEL=7D2 clean
make MODEL=7D2
make MODEL=7D2 install # works fine here, it doesn't ask for any modules
My autoexec is about 9.5K.
If it doesn't boot, the first step is to go into reboot.c and enable the "jump to main firmware" section.
If jumping to main firmware works, the next step is in boot-d6.c, copy_and_restart. Try the same trick (i.e. jump to ROMBASEADDR at the end). If that works, try starting the relocated code without overriding init_task (comment out the line using my_init_task).
For QEMU:
make MODEL=7D2 clean
make MODEL=7D2 install_qemu CONFIG_QEMU=y
./run_canon_fw.sh 7D2,firmware=boot=1 -d debugmsg
./run_canon_fw.sh 7D2,firmware=boot=1 -d debugmsg -s -S & arm-none-eabi-gdb -x 7D2/debugmsg.gdb
You will see ML code running alongside Canon firmware, starting tasks and so on, but... that's pretty much how far the emulation goes on this camera.
Running "make clean" is important, btw; the code compiled with CONFIG_QEMU=y will not work on real hardware.
I just noticed that my camera running firmware 1.1.0, but the code is for 1.0.4. Do I need to change anything?
Quote from: a1ex on February 12, 2019, 10:53:14 PM
Startup code: autoexec.bin (https://a1ex.magiclantern.fm/bleeding-edge/7D2/autoexec.bin). It requires firmware 1.0.4.
Quote from: https://www.ietf.org/rfc/rfc2119.txt
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
So, my camera is useless for now?
Looks like there is a newer 1.1.2 firmware (https://www.canonwatch.com/canon-eos-7d-mark-ii-firmware-1-1-2-released/amp/) for 7d2
KenSoftTh you can try to downgrade from 1.1.0 to 1.0.4 if your camera allow this or try to update stubs.S to the newer firmware.
In the second case just update your camera and the start by dumping the firmware with Portable rom dumper (https://www.magiclantern.fm/forum/index.php?topic=16534.0) and then follow two (https://www.magiclantern.fm/forum/index.php?topic=12177.0) tutorials (https://www.magiclantern.fm/forum/index.php?topic=6785.msg187436#msg187436) for finding stubs
I'll definitely take Assembly course next year in college....
1.0.4 available at https://pel.hu/down
Is it possible to flash the older version over the new one?
Extra points for finding out ...
Spoiler: It would be the first cam unable to be downgraded.
(https://i.ibb.co/PNLfLKX/WIN-20190408-20-47-07-Pro.jpg) (https://ibb.co/PNLfLKX)
Success! Hello World from Bangkok, Thailand. Now, what's next...?
(https://i.ibb.co/K7tW1GW/20190408-205603.jpg) (https://ibb.co/K7tW1GW)
A little bit of Tweaking...
Next step would be capturing some detailed logs of whatever the firmware does. I've covered these steps in detail in other threads; other contributors will be able to guide you through this process. The logs will only cover the activity on one of the cores; these will reveal many useful hints, button codes and so on.
I might be able to capture a log from the second core, but it's not exactly a trivial task and - I hope - not required for porting the basic ML functionality.
Meanwhile, I'm cleaning up the M50 changes to make them compatible with hopefully all earlier models; stay tuned.
I'll definitely need a lot of help because I have never do a lot of assembly and machine code like this before. Thanks for your help so far a1ex!
Can a1ex or anyone link a thread about log capturing on real hardware? As far as I go through the forum, most people are working on QEMU. I'm also confused about how to implement GUI menu like in M50, an example code will be nice as I have no idea what to do. Thanks!
Such logs were already captured on 80D, 5D4, DIGIC 7. The procedure for capturing basic logs was covered earlier in this very thread.
Quote from: a1ex on April 08, 2019, 10:42:32 AM
Yes, the PoC code in the digic6-dumper branch (i.e. what you get by compiling from platform/7D2.104) does just that - logging.
BTW, if you don't receive a reply within an hour (or day or whatever), that does not mean you need to open another thread with the same question ;)
sorry about that, I thought it would be more useful to post in General Development room. Please don't get annoy, i'm totally newbie here and trying to learn about ARM architecture. I have never done something like this before. I'm getting confused because the magic lantern repository is like 100x bigger than what i did in the past.
73: 28394.530 [CAPE] HivshdReadEDmacCompleteCBR
74: 28425.826 [CAPE] Image Addr(CH=2)=0x6392700(0x46390064)
75: 28425.839 [CAPE] TOPV=1, BTMV=3720, CRAW WIDTH=9884
76: 28426.205 [CAPE] WB Integ Addr(CH=15)=0x2c3f904(0x42c3f904)
77: 28426.220 [CAPE] OHYEAR MID Addr(CH=14)=0x2c41b04(0x42c41b04)
78: 28426.286 [CAPE] FencDmac Addr(CH=18)=0x2c59c84(0x42c59c84)
79: 28524.534 [CAPE] FencingWriteEDmacCompleteCBR
80: 28524.547 [CAPE] WbDetectionPathCompleteCBR
81: 28524.590 [CAPE] HivshdVReadEDmacCompleteCBR
82: 28524.754 [CAPE] CCDWriteEDmacCompleteCBR
83: 28525.042 [CAPE] DefmReadEDmacCompleteCBR
84: 28525.057 [CAPE] Defm2ReadEDmacCompleteCBR
85: 28525.071 [CAPE] Image Addr(CH=2)=0x86a31e0(0x0)
86: 28525.083 [CAPE] FencDmac Addr(CH=18)=0x2cefc84
87: 28525.094 [CAPE] WB Integ Addr(CH=15)=0x2c41704
88: 28525.105 [CAPE] OHYEAR MID Addr(CH=14)=0x2c56704
89: 28539.870 [COL] ./LensCorrect/GetLensCorrectionData.c 3185
90: 28637.636 [SHTSS] SHT_SSDEVELOP_PATH_CORE_InitRawToYuv
91: 28638.082 [SHTSS] SHT_SSDEVELOP_PATH_CORE_RegisterCompleteRawToYuvCBR
92: 28638.093 [SHTSS] SHT_SSDEVELOP_PATH_CORE_SetRawToYuv
93: 28638.158 [SHTSS] SHT_SSDEVELOP_PATH_CORE_StartRawToYuv
94: 28638.197 [SHTSS] SHT_SSDEVELOP_PATH_CORE_SetAddressRawToYuv Addr[0x55938000]
95: 28638.222 [SHTSS] SHT_SSDEVELOP_PATH_CORE_RegisterCompleteMem1ToRawCBR
96: 28638.234 [SHTSS] SHT_SSDEVELOP_PATH_CORE_SetMem1ToRaw
97: 28638.453 [SHTSS] SHT_SSDEVELOP_PATH_CORE_StartMem1ToRaw
98: 28743.401 [SHTSS] Mem1ToRawCompleteCBR
99: 28743.567 [SHTSS] SHT_SSDEVELOP_PATH_CORE_StopMem1ToRaw
100: 28743.678 [SHTSS] SHT_SSDEVELOP_PATH_CORE_UnregisterCompleteMem1ToRawCBR
101: 28774.155 [SHTSS] RawToYuvCompleteCBR 2
102: 28789.272 [SHTSS] RawToYuvCompleteCBR 1
103: 28789.625 [SHTSS] SHT_SSDEVELOP_PATH_CORE_StopRawToYuv
104: 28791.204 [SHTD]SHT_DEVELOP_PATH_CORE_RegisterJpegCompleteCBR
105: 28791.215 [SHTD]SHT_DEVELOP_PATH_CORE_SetJpegPath
106: 28791.549 [SHTD]SHT_DEVELOP_PATH_CORE_StartJpegPath Addr[0x55938000]
107: 28898.087 [SHTD]JpegPathDivCompleteCBR
108: 28898.138 [SHTD]JpegPathCompleteCBR Size=0x3388ba Err=0x0
109: 28898.395 [SHTD]SHT_DEVELOP_PATH_CORE_StopJpegPath
110: 28898.605 [SHTD]SHT_DEVELOP_PATH_CORE_UnregisterJpegCompleteCBR
111: 28902.045 [SHTD]SHT_DEVELOP_PATH_CORE_RegisterDcfCompleteCBR
112: 28902.056 [SHTD]SHT_DEVELOP_PATH_CORE_SetDcfPath
113: 28902.348 [SHTD]SHT_DEVELOP_PATH_CORE_StartDcfPath Addr[0x5a848000]
114: 28904.221 [SHTD]DcfPathCompleteCBR Size=0x30ac Err=0x0
115: 28904.294 [SHTD]SHT_DEVELOP_PATH_CORE_StopDcfPath
116: 28904.363 [SHTD]SHT_DEVELOP_PATH_CORE_UnregisterDcfCompleteCBR
117: 28905.273 [SHTD]SHT_DEVELOP_PATH_CORE_RegisterJpegCompleteCBR
118: 28905.283 [SHTD]SHT_DEVELOP_PATH_CORE_SetJpegPath
119: 28905.612 [SHTD]SHT_DEVELOP_PATH_CORE_StartJpegPath Addr[0x55938000]
120: 29012.148 [SHTD]JpegPathDivCompleteCBR
121: 29012.183 [SHTD]JpegPathCompleteCBR Size=0xa8697f Err=0x0
122: 29012.278 [SHTD]SHT_DEVELOP_PATH_CORE_StopJpegPath
123: 29012.387 [SHTD]SHT_DEVELOP_PATH_CORE_UnregisterJpegCompleteCBR
124: 29013.090 [SHTD]SHT_DEVELOP_PATH_CORE_RegisterDcfCompleteCBR
125: 29013.100 [SHTD]SHT_DEVELOP_PATH_CORE_SetDcfPath
126: 29013.364 [SHTD]SHT_DEVELOP_PATH_CORE_StartDcfPath Addr[0x5a848000]
127: 29015.238 [SHTD]DcfPathCompleteCBR Size=0x30ac Err=0x0
128: 29015.301 [SHTD]SHT_DEVELOP_PATH_CORE_StopDcfPath
129: 29015.372 [SHTD]SHT_DEVELOP_PATH_CORE_UnregisterDcfCompleteCBR
130: 29376.446 [SHTAECA]CapSetSize(1536,37)
131: 29376.463 [SHTAECA]CapSetAddr(CH=2)=0xeb74000(0x4eb74000)
132: 29417.384 [SHTAECA]AeCapCCDComp:(0/1)
133: 29417.989 [SHTAECA]CapSetSize(1536,729)
134: 29418.005 [SHTAECA]CapSetAddr(CH=2)=0xeb82400(0x4eb82400)
135: 29418.123 [SHTAECAL]SHTAE_AECALC_PATH_CORE_GetBVRoutine2
136: 29418.139 [SHTAECAL]pAEIntegAddrs is NULL
137: 29420.585 [SHTAECAL][AE] BV 458 BV_ave 446 ETTLBV 456 FG289
138: 29424.380 [SHTAECAL]SHTAE_AECALC_PATH_CORE_CalculateWhiteSearch_AlphaValue
139: 29435.450 [SHTAECA]AeCapCCDComp:(0/3)
140: 29435.463 [SHTAECA]AeCapShadeComp:(1/3)
141: 30344.914 [CAPE] HivshdReadEDmacCompleteCBR
142: 30372.940 [CAPE] Image Addr(CH=2)=0x13622700(0x53620064)
143: 30372.953 [CAPE] TOPV=1, BTMV=3720, CRAW WIDTH=9884
144: 30373.315 [CAPE] WB Integ Addr(CH=15)=0x2c3f904(0x42c3f904)
145: 30373.330 [CAPE] OHYEAR MID Addr(CH=14)=0x2c41b04(0x42c41b04)
146: 30373.397 [CAPE] FencDmac Addr(CH=18)=0x2c59c84(0x42c59c84)
147: 30471.660 [CAPE] FencingWriteEDmacCompleteCBR
148: 30471.672 [CAPE] WbDetectionPathCompleteCBR
149: 30471.717 [CAPE] HivshdVReadEDmacCompleteCBR
150: 30471.882 [CAPE] CCDWriteEDmacCompleteCBR
151: 30472.164 [CAPE] DefmReadEDmacCompleteCBR
152: 30472.179 [CAPE] Defm2ReadEDmacCompleteCBR
Got this while recording the video
(https://i.ibb.co/jvSxsPr/interesting.png) (https://ibb.co/jvSxsPr)
Update: Seems like 4 log commands reveals 6 file, 4 is almost empty and 2 are fill with goodies
After playing around, I noticed that video seems to not output any log (the log above is for still photo) and the log start to have something when you fill the buffer during continuous shot. This make me believe that I'm currently thinking that the log seems to be from the secondary processor.
It should save a file named DEBUGMSG.LOG (and maybe also ROM and RAM dumps, if you uncomment them in minimal-d678.c). Double-checked the dump_file stub - it only saves on the B:/ drive. That's the SD card on most models.
It only dump the first one second, which is useless. File size seems to be limited to 2048KB, which only contain interrupts and boot sequence.
https://drive.google.com/file/d/1KZoZLrKMaOa_jQr_dhS_67sjpdsqift9/view?usp=sharing
Actually it *skips* the first second, and logs the next 1.5 seconds. Still, it's quite useful.
What's interesting, and different from the original 7D - the main CPU core receives MPU messages directly. That's good for us!
You can play with logging options, for example, skip the interrupts. That will cover some more seconds of the startup process, in these 2048KB, but of course it will be less detailed.
Next - enable CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP, find possibly unused memory areas and enable early logging. That should cover the entire startup process. I believe the 7D2 has only 512MB (https://www.magiclantern.fm/forum/index.php?topic=5071.msg169044#msg169044) visible from the main CPU; maybe there's some more accessible by some other means?
OK, I will do that after the long holiday here in Thailand. I think it's 512MB for each CPU because it has similar buffer size to 80D (why they would put half memory on higher end camera) and taking sequence of continuous shot reveals half of JPEG processing log compared to number of images, that means other half is processed by another CPU?
1.723282 Startup:fe18ba5b:2f:05: ### MovieRecorder:ddec1c:11:fe18940f:1
1.723487 MovieRecor:fe189443:2f:02: RecEvent 0[0->1]
1.723519 MovieRecor:fe189485:2f:02: RlyEvent 0[0->1]
1.723568 PropMgr:fe18ada1:2f:03: mvrResultCBR : 0xddf50c
1.723637 PropMgr:fe18af29:2f:03: mvrChangeAckCBR : PROP_USBDEVICE_CONNECT(-1)
1.723674 PropMgr:fe18b543:2f:05: mvrChangeAckCBR : Video - Mode=0,Type=0,Rate=5994,GOP=30,St=3
1.723732 PropMgr:fe18b543:2f:03: mvrChangeAckCBR : Sound Manual(C=2,R=48000,B=16)
1.723758 PropMgr:fe18b543:2f:03: mvrChangeAckCBR : AE_MODE(3)
1.723775 PropMgr:fe18b543:2f:03: mvrChangeAckCBR : ISO(104)
1.723806 PropMgr:fe18b543:2f:03: mvrChangeAckCBR : BodyID = 0x08,0xda3a7746
1.723877 PropMgr:fe18b543:2f:03: mvrChangeAckCBR : RecCount = 0x7a5
1.723913 PropMgr:fe18b543:2f:03: mvrChangeAckCBR : ModelID = 0x80000289
1.724021 PropMgr:fe18b543:2f:03: mvrChangeAckCBR : MOVIE_REC_VOLUME(L:54 R:54)
1.724072 PropMgr:fe18b4dd:2f:03: mvrChangeAckCBR : WindCut On
1.724111 PropMgr:fe18b543:2f:03: TimeCode Mode:1
1.724153 PropMgr:fe18b543:2f:03: TimeCode DropFrame Mode:0
1.724184 PropMgr:fe18b543:2f:03: PROP_FILE_PREFIX:8J8A
1.724221 PropMgr:fe18b543:2f:03: PROP_USER_FILE_PREFIX:KSTH,
1.724255 PropMgr:fe18b543:2f:03: PROP_USER_FILE_PREFIX:KS_,
1.724291 PropMgr:fe18b543:2f:03: PROP_SELECTED_FILE_PREFIX:KSTH,1
1.724322 PropMgr:fe18b543:2f:03: PROP_CARD1_CLUSTER_SIZE:32768
1.724353 PropMgr:fe18b543:2f:03: PROP_CARD2_CLUSTER_SIZE:32768
1.724384 PropMgr:fe18b543:2f:03: PROP_CARD3_CLUSTER_SIZE:0
1.724441 PropMgr:fe18b4dd:2f:03: mvrChangeAckCBR : Attenuator Off
1.724475 PropMgr:fe18b543:2f:03: mvrChangeAckCBR : TimeLapse = 0x0
1.724648 PropMgr:fe18ad83:2f:01: mvrStateResultCBR : 0xddf778
Turned interrupt off. Got something interesting about the video, can we change parameter to improve video quality?
Full Log
https://drive.google.com/file/d/1hzUcBCu8DcGXnDwjJMOzwTU1cOg0a3YP/view?usp=sharing
@a1ex,
I did some test regarding the buffering of 7D Mark II. I went out to shoot the timelapse and noticed that if I set resolution to mRAW (4104 x 2736) with 6fps burst rate, then I can shoot until my 32gb 90MB/s SD card filled. I noticed that in the mRAW file, there is L-Fine JPEG attached (full sensor resolution) and total file size for each mRAW frame was 16.3MB at ISO 100 and seems like the card is the bottleneck. If we managed to port magic lantern onto this camera, can we turn off JPEG preview, reduced bit depth to 10 bit, recording to CF and hope for 4K 24fps video? or the sensor readout rate will be the next bottleneck? Just wanna know from your experience and what to expect.
Generatlly speaking i have the feeling most devs expect to cross a bridge when they come to it.
I remember a1ex writing about his experiences with m/sRAW and almost bricking his cam permanently, though.
Interesting, can you link to it? so that maybe I can learn more about porting.
Quote from: KenSoftTH on April 12, 2019, 07:23:23 PM
Interesting, can you link to it?
Home Help
Search -> Advanced search, sraw, user a1ex ...
That was about m/sRAW on unsupported models (Rebel cameras). This option was made available in a fork of ML, and it resulted in corrupted images (i.e. data lost). Users were also unable to switch back to plain RAW without clearing Canon settings.
This is why I'm reluctant to play with certain settings - because I had trouble with them (and in some case I had to find out how to restore a soft-bricked camera). These things didn't result in permanent camera damage, but still, it wasn't funny to clean up the mess done by others.
However, the question was about maximum frame rate; in this case, the sensor readout speed is going to be the first bottleneck. If you can't capture the frames fast enough, it doesn't make sense to worry about compression, card writing speed and other stuff like that. So, let's find out the frame rate for full resolution capture.
From 0xFE32B0F6 VSizeSetting, I can tell it's reading out 3720 lines in 83 ms, so the theoretical limit would be about 12 fps at full resolution. Raw resolution registers seem to be:
0xD0006800: 0x0001000f ; (x0, y0)
0xD0006804: 0x0e8802d1 ; (x1, y1)
Lower half is X divided by number of channels, higher half is Y (on most models it's not divided by anything). Effective resolution (from wikipedia) is 5472 × 3648. From the above values, readout size must be 5648 x 3719, using 8 channels (i.e. 8 columns read out in parallel). TODO: cross-check with a full CR2 size (dcraw -i -v).
FPS timer A (from register 0xD0006008) appears to be 0x305, i.e. 774 units (as the hardware register is programmed with N-1). One line is read out in 22.3 microseconds. That means, main FPS clock must be... 774 / 22.3 = 34.7 MHz ?!
Timer B is close to 3720, likely 0xE8B = 3724 units (from VSizeSetting). Cross-checking: 34.7 MHz / 3724 / 774 = 12.04 FPS.
That means, in theory, maximum resolution at 24p might be about 5472x1700 (or something close). Or, maybe 4096x2200 with 1.33x crop. That doesn't guarantee we can actually figure out how to achieve these; they are just theoretical figures.
Still, the clock value is quite unusual, so... let's check the actual timer values used by the camera. For the above numbers, I've only grepped the ROM for known registers and looked for values that seemed to make sense.
To confirm my theory, try to capture a diagnostic log while capturing a still image. It should contain 0xD0006008, 0xD0006014, 0xD0006800 and 0xD0006804 (among others). Something along these lines:
msleep(5000); // wait for camera to start
log_start();
call("Release"); // take a picture (happens in background)
msleep(2000); // wait for the picture to be captured
log_finish();
Also try to capture the values of the above registers while *entering* LiveView, at known frame rates (24, 25, 30 and so on). That is, start logging just before entering LiveView, and stop it 2-3 seconds after entering.
is the clock of 34.7 MHz high? and how is it compared to 5D Mark III and 80D?
Hey a1ex,
sorry for the delay, here's the value.
0xD0006008 0x3050305
0xD0006014 0xffff
0xD0006800 0x6000a
0xD0006804 0x640006a
full log
https://drive.google.com/file/d/1KRN2pVnoKU8wJYRPGP7jkKozytGh63Hh/view?usp=sharing
Entering Live View and only Address 6014 was found, which is inconclusive
https://drive.google.com/file/d/1ad4ATJMWQrJzql896xkBGghfJoSGbasD/view?usp=sharing
Recording at 720p59.94 gives
5.403438 Evf:000134a7:91:01: [REG] Total:2
5.403454 Evf:0001448f:91:01: [0](0xd0006014),(0x2f9)
5.403471 Evf:0001448f:91:01: [1](0xd0006024),(0x2f9)
5.403488 Evf:0001448f:91:01: [2](0xd0006000),(0x1)
UPDATE: Full 720p59.94 Log
https://drive.google.com/file/d/18xO7EUZpF4neEgZDnebf8Br6zAeEnShS/view?usp=sharing
Used live view RAM dump method from 80D thread
Before
(https://i.ibb.co/rbQB577/RAM4-BF-BIN.png) (https://ibb.co/rbQB577)
matrix movie explained (https://movieplotholes.com/the-matrix-plot-holes)
After
(https://i.ibb.co/jJSDgq6/RAM4-AF-BIN.png) (https://ibb.co/jJSDgq6)
@a1ex, please guide me what to do next
Great job!
7D MKII is a nice camera for shotting Raw video.
Bump. Can someone help me out?
Terrible timing ...
https://www.magiclantern.fm/forum/index.php?topic=23296.msg215471#msg215471
Didn't see that. Thank you for letting me know.
Watching patiently....
"eventually" we will have a build....
/Howard
Vancouver, B.C. (retired)
www.howardtitman.com
Hello guys! I know nothing about porting or how ML realy works on canon firmware, but I have a 7DMKII and desire to learn. So how can I help you? It's too very easy just to give up and change my cam or just buy a external recorder, but is that easy street isn't always the best route. If I can help you, please, let me know.
Thank you so much!
Dual processor cams might be hard nuts to crack. 7D port (Dual Digic 4) was several years late because of this and it's the only ML supported dual processor cam right now. Still missing some features available for other Digic 4 cams, though.
And there is no full Digic 6 ML port available right now.
Sounds like fighting the end boss in level 1.
For starters it might be a good idea to lower the bar with a cam like 750D/760D/80D. But I'm not a programmer/developer.
Anyway: Lookup https://twitter.com/autoexec_bin/status/954662020271493120 for starting guide.
Hi everyone - I hope this message finds everyone in good spirits.... I'm a videographer who owns this camera. I have been watching this thread for quite some time and I'm wondering if someone can kindly give a project status update on where you all officially stand with developing ML for Canon 7D Mark II.
Is this still active? Do you need anything from the community to move forward?
Thank you
This thread is where updates are most likely to be posted. If you don't see any, then probably no progress has been made.
The most needed thing is people experienced in reverse engineering, embedded systems, ARM asm and C.
Just come here to post final update. I bought the Canon 90D and I'm not going to work on this anymore.
Seriously guys, anyone who have knowledge on this field can earn serious amount of bucks and it doesn't worth their hassle working on the custom firmware for free. They're better off spending their money on the camera that does the work in the first place.
Like others said, it just not worth it.
@KenSoftTH,
I'm confused. Who exactly are you posting a final update to? What exactly are/were you doing here?
@KenSoftTH,
Not every man on this forum can earn "serious amount of bucks" and invest it on the camera. Which camera, by the way? There are quite a lot of good Canon cameras that can shoot raw, using ML, in highest quality previously available when using profi cinema cameras only. And these Canon cameras cost much, much less than those profi cinema cameras - I mean, Arri Alexa, Red (any), etc. There are cheap SD, CF cards (comparing to the profi cards or whatever), cheap lenses anyone can get great videos with. You can make almost any kind of image using raw from these Canon cameras, and this, may I call it, ML RAW SYSTEM costs much, much less money than any of those professional cinema raw systems. OK, this is all just my POV, but anyone already can make documentaries using ML raw. Using their own cameras, not the rented ones. And I want to thank all programmers that are working on this great project that, undoubtedly, has great future. I'm from Russia, for instance, and we have hard times by now (economical crisis, dictatorship, etc), but even now (!) I can afford myself shooting ML raw in highest possible quality, and I'm going to further evolve my raw system, because, again, I CAN afford it myself without investing tens of thousands of bucks into it. Just as I can afford myself to record sound (music) on tape from the mikes - and again, without those great investments. I can get great professionally looking picture for some hundreds of bucks with the camera that costed me... um... $200 with lens (!). Of course, there are BMCC, BMPCC, etc, but, to my mind, ML raw is better and even more cheap. ML is free of charge, by the way, isn't it great?
that sounds right not every person can afford a new camera but should have access to raw and all the goodies that happen in ml, i wish and hope for the development of digic 6 7 8, while i wait i play with the current developments in ML. the best is to have some older and new models if possible,you have to be a canon user to understand .this been going on even in the 35mm film camera era. eos 650 ,620, 630 eos 1.for those people that don't have programming skills and are waiting i would like to encourage the talented individuals and Thank them for there time and effort ,without this there would not be any magic lantern. it is better to encourage and be patient .
I meant to say that ML can be used professionally.
The next step for ML developers is 6, 7 and 8 Digics. If they would make, say, EOS R work with ML then much greater possibilities would open because it's card controller supports writing speed up to 200 MB/s, and that is huge speed, so many tricks would be available such as (IMHO) 4K 50 FPS or something around 6K. Man that will be a great camera!
This camera has two Digic 6 and CF 120 MB/s, so it's great, too.
Well I think that u can use ML current models in a pro. level but you would want few cameras that do the same thing that way you ..have control over your production it really matters on what type of work your doing like weddings would work only for some of the footage but if you were to do music videos or short film you can control your actors and scene etc. i see all type of videos with ml from car to anything .so much out there just do a search on different plat forms and ideas well come .plus the footage from raw is beast even if it is 239:1 1736x726 like from t5i 700d with a experimental build https://builds.magiclantern.fm/experiments.html or eos m with danne build you can get 2k raw upscale to 4k in post ..you have to start playing with current models and new build will come in time . plus i think dual digic will take much longer development than single and more people have other models 7d mark2 is a sports photographer camera the more specialized camera the less development numbers game !
@ KenSoftTH
yes, I agreed! your right! Still thanks you hacking trying!
I'm useing BMPCC 6K with speed booster x1.2 ,but still waiting for 7DMKII' ML.
Hope someone can hacking it。
7dmk2 is really a good camera for 2K raw video shooting.
Canon has managed to protect its product >:(
Quote from: tsengvane on June 08, 2020, 07:44:14 PM
still waiting for 7DMKII' ML.
Hope someone can hacking it。
Me too, and I hope so too.
Hummm... I last checked this in 2015.
Quote from: Wlad81 on May 05, 2020, 12:00:26 AM
@KenSoftTH,
Not every man on this forum can earn "serious amount of bucks" and invest it on the camera. Which camera, by the way? There are quite a lot of good Canon cameras that can shoot raw, using ML, in highest quality previously available when using profi cinema cameras only. And these Canon cameras cost much, much less than those profi cinema cameras - I mean, Arri Alexa, Red (any), etc. There are cheap SD, CF cards (comparing to the profi cards or whatever), cheap lenses anyone can get great videos with. You can make almost any kind of image using raw from these Canon cameras, and this, may I call it, ML RAW SYSTEM costs much, much less money than any of those professional cinema raw systems. OK, this is all just my POV, but anyone already can make documentaries using ML raw. Using their own cameras, not the rented ones. And I want to thank all programmers that are working on this great project that, undoubtedly, has great future. I'm from Russia, for instance, and we have hard times by now (economical crisis, dictatorship, etc), but even now (!) I can afford myself shooting ML raw in highest possible quality, and I'm going to further evolve my raw system, because, again, I CAN afford it myself without investing tens of thousands of bucks into it. Just as I can afford myself to record sound (music) on tape from the mikes - and again, without those great investments. I can get great professionally looking picture for some hundreds of bucks with the camera that costed me... um... $200 with lens (!). Of course, there are BMCC, BMPCC, etc, but, to my mind, ML raw is better and even more cheap. ML is free of charge, by the way, isn't it great?
Go re-read my post. I know that not everyone has serious buck to afford those camera. I said that anyone who has the knowledge in ARM microprocessor or VLSI will earn serious buck and won't spend their time doing the hacking unless they are passion about it. You guy are expecting to do 4K, 6K or whatever, but there are many contraint in both hardware and software that developer need to overcome and many time it's just better off buying the camera that has that feature in the first place instead as it would be more stable in most cases. I'm not saying that it's impossible to do it, but it does require more brain power than ever before as Canon implement more and more lockdown on its firmware.
Quote from: KenSoftTH on June 30, 2020, 07:39:54 PM
I'm not saying that it's impossible to do it, but it does require more brain power than ever before as Canon implement more and more lockdown on its firmware.
you are right
Canon is protecting its products and no one will be able to operate ML on any recent release of Canon cameras
Canon hasn't added any protection measures. We can already run code on Digic 6, 7 and 8 cameras. I don't know where this idea is coming from.
Quote from: names_are_hard on July 01, 2020, 02:00:22 AM
Canon hasn't added any protection measures. We can already run code on Digic 6, 7 and 8 cameras. I don't know where this idea is coming from.
I used the wrong word. I should have said that Canon changed to newer CPU architecture that are more complex to reverse engineer. But by switching to newer ARM processor does in fact requires modder to redo almost everything from scratch.
Sorry, but I was a little bit confusing when I wrote the post above.
Quote from: names_are_hard on July 01, 2020, 02:00:22 AM
Canon hasn't added any protection measures. We can already run code on Digic 6, 7 and 8 cameras. I don't know where this idea is coming from.
Yes, maybe you can Hack 7DmkII by youself, Go ahead!
Or maybe you can do it yourself. What's stopping you? We need doers, not beggars.
This place is full of arrogance
When you were unable to progress and penetrate the new Canon processors, you make excuses until you have arrived. You want everyone to be programmed ???
For several years a1ex was adamant about being unable to supply new ports and asking for support. I'm unable to call this arrogance
This is supposed to be a community not a company.
Somewhere here I read a topic regarding support and donation and you or one of the moderators told us that the a1ex refuses to do so
Me and many here are ready to donate to a certified account so we can get Ml on 7Dii and 5Dvi
There are many reasons to be careful around donations. There´s always risks when money involved. Both a1ex and others have explained this multiple times. Maybe you ignored those parts.
"A1ex asking for support". Okay, there might be a hammer/nail problem in perception. What I meant: Asking for *people* able to help by working on the project or at least willing to learn programming.
Quote from: shhd on July 01, 2020, 10:20:16 PM
This place is full of arrogance
When you were unable to progress and penetrate the new Canon processors, you make excuses until you have arrived. You want everyone to be programmed ???
Ha ha, already using BMPCC 6K, not waiting ML for 7D MKII.
Hello
Please help me by answering my question
Anyone who does ML on 7D ii or 5Div
Because I own a 7D ii number of shutters only 5000
Should i wait, sell or buy used 5d iii
Please help me with your opinions
I don't want to sell 7D ii because it's new and the focus remains during the video other than 5Diii
There is no ML for 7D2 or 5D4.
Quote from: shhd on July 21, 2020, 04:54:22 PM
Hello
Please help me by answering my question
Anyone who does ML on 7D ii or 5Div
Because I own a 7D ii number of shutters only 5000
Should i wait, sell or buy used 5d iii
Please help me with your opinions
I don't want to sell 7D ii because it's new and the focus remains during the video other than 5Diii
Use BMPCC 6K
Why don't I necro this thread?
https://i.imgur.com/apyBOfQ.mp4
Barebones port, no ML features yet. Currently there is a significant bug around task creation that prevents important things working. Other than that it was an easy port - while this is dual-digic, autoexec runs on the same CPU as the majority of tasks. Some stuff is on the slave and I don't know how to run code there yet.
Card performance seems good, 80MB/s on SD by default. The above bug stops me benchmarking in card-spanning mode, shame :)
I really like the controls and feel of this cam, certainly it's the nicest cam I own!
Hi champ, it will be amazing when it works on this camera :-*
It does work on 7D2, that's what the video is :)
Great work :-* , but I understood that the menus work but the functions do not work. Can you test and which version is suitable for it?
Quote from: shhd on March 06, 2023, 08:23:08 PM
Can you test and which version is suitable for it?
? What does this mean? What is "it"?
Many people understand ML as "raw recoding", not as "a framework for modifications of EOS firmware".
Thus it = any feature, not the fact that we are able to run menus.
I mean version 7D ii which version should the camera be stacked to install ML, and is it possible to install a version that works at least raw video recording
"At least". LOL
Again: Menu works. Almost nothing else does. And "at least" is far, far, far away. Some features require a major breakthrough because Digic 6 works very, very different compared to Digic 4, 5.
Quote from: shhd on March 06, 2023, 09:06:54 PM
I mean version 7D ii which version should the camera be stacked to install ML, and is it possible to install a version that works at least raw video recording
Now you are asking a useful question :)
There is no raw video recording at this time. FW version is 1.1.2.
Great job !
I finally got a "little" time to get started, in between cleaning poo from 5 cats, making dinner for 2 kids (wife was working), Cleaning up after 2 kids (refusing to help), cleaning the bathroom, driving forth and back to my old mom, just to switch off her broken fire alarm, ::). Anyone that wants to help out porting the 7D2 are warmly welcome, we might actually have some progress in the next month years, and helping out now is the right time.
My software was 1.1.3 and we're building for 1.1.2 so I needed a downgrade. I'm on linux, and EOS utility 3.0 does not run on linux/wine. I took 1.1.2 and put in on a 32 GB highspeed card, but the camera refused to downgrade (it actually checked the version within the FIR update file) and told me that I has the newest version!. I then renamed the file - pretending it was version 1.1.4, but the camera still refused. Then I took a old slow 8GB card and put the 1.1.2 on it, rename it to look like 1.1.4 and now it wanted to start the update procedure, but it failed right away after pressing ok (some odd message). The solution was to resort to the "dual card - switch card when pressing ok" trick. The final solution was:
My downgrade to 1.1.2 :o
1. Charge your battery to full capacity.
2. Get two CF card, one 8GB and one 32GB.
3. Put Canon firmware "FIR" file for 1.1.2 on both card and change the last digic "2" to "4" in both filenames.
4. Put the 8GB into the camera and initiate the upgrade procedure - but dont press "OK"
5. At the very same time you press "OK" open the card door.
6. Switch the CF cards to the 32GB and close the card door.
7. Wait a minute until the camera allows you to upgrade.
8. Verify that firmware version is 1.1.2
Btw. If your camera break, you get to keep both pieces
Upgrade to 1.1.2:
- Follow canons instructions .. (https://asia.canon/en/support/0400323102)- Follow canons instructions ..
ROM dumper:
- Available at the portable rom dumper page, remember to use a SD card (CF does not work) (https://www.magiclantern.fm/forum/index.php?topic=16534.0)
- Worked fine, screen was red =>
(https://lh3.googleusercontent.com/pw/ADCreHdFa7_k5rlJ4SD5E-eK_K3GVJXZVtAOjMSc-e9Op_IPM6Dn8KxNBprqA42jFKJpBPUdvvd5XETfnIKUBGuWuw9eybheGa_pAookbWyMfNlagT2asUVmyCoLOmw_Bp6Ynn3qUTVKq5gFfOIAy8z5UbKW=w1504-h1100-s-no?authuser=0)
Enable Bootloader flag:
Somewhere in this thread
You've got a large workforce, you just need to get them motivated. Training the cats to make dinner might be the place to start.
We can update 7D2 version to 1.1.3 if you prefer, I think I picked 1.1.2 because it's the version before they implement downgrade "prevention". Wouldn't take long to update it, it's a barebones port at present.
I can certainly help with porting work, though I don't recall if I have an easy cable connection for 7D2 uart. Since it's my work so far, if you have any questions I feel obliged to answer them :) You might want to follow the Discord link at the top of the page, it's better for quick questions than the forum (it's like IRC but easier to use).
Quote from: names_are_hard on October 11, 2023, 03:12:35 PM
You've got a large workforce, you just need to get them motivated. Training the cats to make dinner might be the place to start.
We can update 7D2 version to 1.1.3 if you prefer, I think I picked 1.1.2 because it's the version before they implement downgrade "prevention". Wouldn't take long to update it, it's a barebones port at present.
I can certainly help with porting work, though I don't recall if I have an easy cable connection for 7D2 uart. Since it's my work so far, if you have any questions I feel obliged to answer them :) You might want to follow the Discord link at the top of the page, it's better for quick questions than the forum (it's like IRC but easier to use).
4 tiny cats :D will soon have a new home (two weeks left, before we are allowed to pass them to new owners)
Discord, sure, I actually wanted to get on discord, but I ran out of time. I only have "real" time on Tuesdays and Sundays (other days .. it's at most "ghidra" reading days), I'll try to sneak in from time to time, so we can have a discussion.
I prefer to keep "1.1.2" as it. More workload is not preferred.
About downgrade: Apollo7 found the door method some time ago. A1ex took a look into it and had a concern about possible hickup (possibly bricking the cam) and refined the routine. It is refered as "Method B" and we propagate this procedure only. Seen in installation instructions for 5D3.
No worries were reported so far. Hari made a video tutorial.
https://www.magiclantern.fm/forum/index.php?topic=24926.msg231788#msg231788
Introducing a third method ... may we rather not?
Okay, 1.1.2 it is - easier for me too. I'm currently working on making MMU patching nicer, but hopefully will chat to you Sunday :)
PS I request pictures of tiny cats.
Working, stumbled over some strings
ds "VRAM_InitializeVramPath LVx10"
ds "VRAM_InitializeVramPath LVAf90fps"
ds "VRAM_InitializeVramPath LVx1"
ds "VRAM_InitializeVramPath LVx1Ta10"
ds "VRAM_InitializeVramPath LVx5"
ds "VRAM_InitializeVramPath FHD30P(FLICK)"
ds "VRAM_InitializeVramPath FHD60P"
ds "VRAM_InitializeVramPath FHD30P"
ds "VRAM_InitializeVramPath DIORAMA_FHD"
ds "VRAM_InitializeVramPath 720P60P"
ds "VRAM_InitializeVramPath VGA"
ds "VRAM_InitializeVramPath DIORAMA_VGA"
What is DIORAMA (?) also interesting with the 90 fps
From the manual, one of the Creative Filters is "Miniature effect", which "Creates a diorama effect". Might be that.
LVAf90fps suggests AF refreshes at 90fps, or at least has one mode to do this. Seems plausible.
Fixed the task problem, which was embarrassingly simple in the end. The OS defines a maximum number of tasks, and this cam happens to be quite close to that limit. By coincidence, ML tasks were just below that limit before running the benchmarks, and so the second one triggered an assert.
The limit is defined during OS initialisation, and we control that during boot. I've added an option to increase the task limit, which can be defined per cam:
https://github.com/reticulatedpines/magiclantern_simplified/commit/9df8de520ff38e47386404a10a262062cb7ab09e
Benchmarks look quite promising:
https://i.imgur.com/7bbLlNv.png (https://i.imgur.com/7bbLlNv.png)
And that's without SD overclocking (no idea if it will work on 7D2).
Good job. Amazing speed. 8), looks real promissing.
Quote from: names_are_hard on November 08, 2023, 09:19:09 PM
Fixed the task problem, which was embarrassingly simple in the end. The OS defines a maximum number of tasks, and this cam happens to be quite close to that limit. By coincidence, ML tasks were just below that limit before running the benchmarks, and so the second one triggered an assert.
The limit is defined during OS initialisation, and we control that during boot. I've added an option to increase the task limit, which can be defined per cam:
https://github.com/reticulatedpines/magiclantern_simplified/commit/9df8de520ff38e47386404a10a262062cb7ab09e
Benchmarks look quite promising:
https://i.imgur.com/7bbLlNv.png (https://i.imgur.com/7bbLlNv.png)
wow cf 135mb/s sd 80 mb/s.
if ml works on 7d2, it easily betters 5d3, can do 4k or even 6k 1x1.
7D2 has just 20.2 Megapixel and pixel-wise it comes to 5.472x3.648 pixels. Have fun glueing some additional pixels for 6k.
Roughly 6k. 5.4k 1x1 14 bit color depth uncompressed raw is golden, even for the next several decades.
Well, if 3840 = 4K, then 5472 = 5.7K ;)
But 14-bit 1x1 5.7K would require something in the range 250 - 300 MB/s I guess, even with 1:2.5 aspect ratio and 24 fps.
5472 x (5472:2.5) x 24 x 14 x 0.4 / 8 = 192 MByte/s
216 in benchmark - 10 percent for overhead (est.) = 194.4 MByte
Close call.
You are right for sure Walter, but I cannot understand where I'm wrong. Please advice.
With your formula
3840 x ( 3840 : 2.5 ) x 24 x 14 x 0.4 / 8 = 95 MByte/s.
However with UHD my personal experience is that it is difficult to get less than 130 MBytes/s. Typically I will get something more in the range 140-150 (no continuous rec but often long enough for short clips).
What am I missing?
Nothing I guess!
Have to play around a bit with 5D3 go get a better understanding how this cam behaves in high res MLV recording.
The only thing we know for now: 7D2 seems not hampered by 5D3's interface limit. Both cards work the same speed in single card benchmark and combined.
Cool.
What does 0.4 in your formula stand for anyway? Expected compression ratio?
( 3840 * ( 3840 / 2.5 ) * 23.976 * 14 ) / ( 8 * 1024 * 1024 ) = 236MB/s
^ width a.r. ^ fps ^ bit dpth.^ ^---^--------^ bits to Bytes to KB to MB conversion
x0.4 in @WalterSchulz computation is the lossless compression ratio, which seems quite optimistic to me depending of the overall video exposure and the ISO (close to 100=less noise pattern=better compression): if you just increase it slightly to x0.5 then you get ~118MB/s, which sounds more realistic in real conditions with potential partial overexposures.
Quote from: Walter Schulz on November 12, 2023, 09:29:15 AM
5472 x (5472:2.5) x 24 x 14 x 0.4 / 8 = 192 MByte/s
216 in benchmark - 10 percent for overhead (est.) = 194.4 MByte
Close call.
If sd is overclocked to 240 mhz, maybe can add another 40 MB/s.
Quote from: a.sintes on November 13, 2023, 10:03:09 AM
( 3840 * ( 3840 / 2.5 ) * 23.976 * 14 ) / ( 8 * 1024 * 1024 ) = 236MB/s
^ width a.r. ^ fps ^ bit dpth.^ ^---^--------^ bits to Bytes to KB to MB conversion
x0.4 in @WalterSchulz computation is the lossless compression ratio, which seems quite optimistic to me depending of the overall video exposure and the ISO (close to 100=less noise pattern=better compression): if you just increase it slightly to x0.5 then you get ~118MB/s, which sounds more realistic in real conditions with potential partial overexposures.
In my experience, wide angle shots with heavy foliage the ratio is about 0.7, which is the worst scenario.
the more important and practical is if 7d2 can do uhd 60p lossless 14 bit or even 10 bit raw. this makes ml on par with other high end cinema cameras. many cameras claim they can do 4k or 6k 120p or 240p, but typically there is cropping or dual iso disabled. etc, the sensor readout is not fast enough. so 4k 60p raw is very practical.
7D2 can't do raw of any kind at present. This card speed test isn't touching the sensor, we have no idea of the capabilities.
The most important thing is getting things working, not dreaming about 60fps!
Certainly, there is potential. We need more devs.
I have started to search for the remaining stubs, I hope that this task can be compled before newyear. The only thing I'll try to work on (beside finding stubs) is the the advanced intervalometer, because I would like to have it working before my winter/ski/christmas holiday in Sweden.
Which stubs do you mean? The 7D2 has all stubs found that I'd expect *given what we know how to do* for D678X cams. Some stubs probably no longer exist. Some likely exist but in an altered form, EDMAC is probably in this category. The pattern of calls to DMA related functions is quite different on 200d, at least. Haven't checked a D6 in detail.
A guess a few stubs is missing if you want to do some debugging ect.
I have the intervalometer running, but need to test is in all condition and all modes, which required me to find DISPLAY_IS_ON, so once I have tested it thoroughly I will push the code.
I guess it depends how you want to debug :) For that cam I don't have a cable made up, so I mostly used Qemu or bmp_printf(). Not ideal.
For intervalometer, that makes sense, I misunderstood the context. Yes, you'll have to find new stuff for enabling features.
Are you finding it stable so far? I haven't tested much at all with 7D2, just did enough work to get barebones GUI working and benchmarks.
Looking forward to a "new" feature :) Nice to have someone else joining in on these new cams - and hopefully intervalometer will be an easy port to other models.
We found intervalometer broken at least on D8 - Canon evproc used for that crashes the camera (null pointer) if previous shot was unsuccessful. Otherwise it worked - wonder if that's an issue on D6.
Oh yeah, I remember that now - this could be forced by not letting the AF lock, if I'm thinking of the same thing.
Yes, that was the crash trigger for me - if AF was enabled and didn't lock. We use factory mode functions underneath so it is not surprising they have edge cases.
I spent a few days looking for a better way to make a photo from code but was unsuccessful.
Sorry to interrupt. Don't know if it is related:
Legacy ML's intervalometer disables AF. If you use ML feature "Use Autofocus" and AF fails to lock you get this one:
https://foss.heptapod.net/magic-lantern/magic-lantern/-/issues/2923
Is your intervalometer code different?
EDIT: Didn't try to find out the build corrupting AF feature. I assume it worked once upon a time.
So far I have only testet it lightly, but in all modes, with and without focus enabled, with and without flash, no crashes yet, seems to be pretty stable and solid. Only bulb mode (dial B) does not shoot if you don't enable bulb timer in ML, but I guess that is the way is should work.
I also been looking for the size of the SRM buffers (to complete the memory system), but failed to find the size, yet it seems it does not matter what size you set the SRM buffer to, the exmem system still works. Tried different sizes (32,33,34,35MB) and all times I succesfully got 5 buffers.
Another thing, less good, once I have executed "dont press me button" with any code more than 8-9 times, the executing time for the next "dont press me button" test takes longer and longer time, feels odd and incorrect. All I did in that run_test code was
foo += 0x100000.
Good to hear it's pretty stable for you.
SRM works differently (and badly) on Digic 7, where I have spent most time. Haven't looked at it at all on 6. Consequently I don't know much about this system.
I'd have to see the code to guess at a cause for the "don't click me" behaviour. Fork my repo and push a branch?
I will try to push the code tomorrow, next week I might need to go traveling, so I'll be busy for the whole week.
Turned out I wasn't pushing my luck with regards to SRM memory, there a limit just above 36MB, so I'll do a bruteforce run and find the correct limit. . Read the exmem.c code check what srm_malloc_crb returns ... 0x2314000 ;D
EDMAC address on 7D2. On all other cameras the engine DMA address range was 0xC0Fxxxxx but on the 7D2 it's 0xD00xxxx
0xD0004x00 ; x = channel
0xD0026x00 ; x = channel
0xD0030x00 ; x = channel
I did not find 0xD0027x00
Yup, this is the same on 200D. On that cam, there's an array starting at 0x66264, where each element is something like: {uint32_t channel_addr, uint32_t ModeInfo}.
I think it's the same EDMAC device, or at least the API is very similar, mapped to a different address. There's a partial write up in my post here:
https://www.magiclantern.fm/forum/index.php?topic=26249.msg245565#msg245565
In Kitor's dumps of the tables from various cams you can see the 0xd0004000 range is used on various D7 and D8 cams.
Please note most EDMAC related functions now take a struct, which holds two channels, rather than two functions being used, each taking one channel. This means (I think!) that there are no direct equivalents to the EDMAC stubs for D45 cams. One such struct is roughly described here:
https://github.com/reticulatedpines/magiclantern_simplified/commit/7a67edc5011d27c7080c6c940385328ab3aae82e#diff-9450d43dd0c51c7b781f01100a2d37e9ef1903d6a16fcf51be40b03f3d8aed38R693
Comparing 650d to 200d, I see for example that c0f2b000 is used in the same way d002b000 is for 200d. So quite probably just the base address of the device has changed. I don't have experience working with EDMAC on older cams. Do you know of a good writeup anywhere? I'm finding lots of similarities, but I don't have a good idea of what to do with them.
Quote from: names_are_hardDo you know of a good writeup anywhere?
Not really, I used the post "EDMAC Internals", Fandom wiki and the code.
Too bad the EDMAC api is different, the 7D2 is not like D345 cam's, nor like D78X, it's a unicorn. And while I was getting annoying of the missing EDMAC api, which is a hard requirement for RAW video. I started to look for alternatives, and ended testing the simple DMA memory tranfer which for some unknown reason completly failed, ( I guess I failed to find the dma_memcpy initialization function that initialized the DMA's). I found benchmark on the forum around 80-100 MB/s, but found none at full "EDMAC" speed. I then ended up writing a simple DMA memcpy test and testing different configuration I found in 40D and 7D2 I finally got 599 MB/S (photo mode). I tested two different copy methods single DMA and a parallel double DMA. The speed depends on the configuration values of the DMA, "0x30001" is the magic number. This one could be used as an EDMAC alternative (atleast for the time being, of course only for block copies, raw video "fixed width")
My benchmark from 7D2 (4 MB blocks), the transfer rate speeds depends on which mode your choose (photo,LV):
Single DMA = 70-80 MB/s, slow config (byte copy ?)
Double DMA = 74-84 MB/s, slow config (byte copy ?)
Single DMA = ~525 MB/s, fast config
Double DMA = 559-599 MB/s, fast config
Configuration, see
https://magiclantern.fandom.com/wiki/Register_Map#DMASlow config:
DMA_BASE+0x04 = 0x0
DMA_BASE+0x08 = 0x1
DMA_BASE+0x14 = 0x1 or 0x7
Fast config (all combinations is valid):
DMA_BASE+0x04 = 0x0
DMA_BASE+0x08 = 0X3001
DMA_BASE+0x14 = 0x1 or 0x7 or 0xf
Fast config (all combinations is valid):
DMA_BASE+0x04 = 0x2
DMA_BASE+0x08 = 0X30001
DMA_BASE+0x14 = 0x1 or 0x7
I also found references to DMA_BASE+0x04 = 0x1 but I did'nt find any success with this value.
Interesting and seems good progress!
I've had the dma_memcpy stub found for 200D for a long time but the copy speed isn't very high. It would really help if you could link to the commit where you make these changes (what am I supposed to do with the DMA_BASE info? How do I use this?). Given the clues, maybe this is CONFIG_EDMAC_MEMCPY related? I've avoided that code so far because it wants a lot of EDMAC stubs found. I've never worked with D45 cams, so I don't know how EDMAC is supposed to work when doing a port. The more you can share about *how* you're finding things, the better chances I'll have to understand how to do similar on other cams.
7D2 has some of the same strings I'm finding useful in 200D, but not all of them. A large difference is that they are mostly in the Omar code. Omar is another ARM core, which the ICU initialises by copying part of the ROM over. It's Thumb capable. I suspect ShtVfx processing is all done on Omar. So you may need to look there for EDMAC usage. I'm fairly sure the EDMAC hardware has the same interface as D45. This has been discussed on Discord before, you should find recent references if you search for Omar.
E.g. see "ShtVfxMultiShotPathState" - this exists in 200D main rom, doesn't exist in 7D2 main rom, but is in Omar instead. E.g. e008f84a() on 200D is 01af4ae8() on 7D2 Omar. Most of the MultiShot functions seem to use EDMAC.
The (old) DMA is not related to the EDMAC. This DMA is a old school DMA engine that was been in the DIGIC chips since the dawn of times, I guess the only problem has been that we're been using it incorrectly, maybe without knowing it's true capacity. There are 4 DMA channels "DMA_BASE's" (0xC0A10000, 0xC0A20000, 0xC0A30000, 0xC0A40000). For each DMA channels the following configuration exists: https://magiclantern.fandom.com/wiki/Register_Map#DMA
I have checked in my test code here: see the run_test's functions
https://github.com/jmheder/magiclantern_simplified/commit/0ca296a7447ac6b702441ba479ef11d89f6ad063
It's a quick bruteforce way to test the DMA - some of the tests fails (due to incorrect configuration) while others are a success. While the testing takes place the display will show progress and memcpy transfer speeds, also a log is written to disk. The test requires SRM memory to work.
But basically a simple version could be:
// This code snipped has not been tested .. its an example
#define DMA1_BASE 0xC0A10000
#define DMA2_BASE 0xC0A20000
#define DMA3_BASE 0xC0A30000
#define DMA4_BASE 0xC0A40000
#define DMA_ENABLE 0x0
#define DMA_UNK1 0x4
#define DMA_CONTROL 0x8
#define DMA_UNK2 0xC
#define DMA_ACK 0x10
#define DMA_CONFIG 0x14
#define DMA_SRC 0x18
#define DMA_DST 0x1C
#define DMA_SIZE 0x20
// pseudo memcpy, not tested
memcpy(uint_32t *dst, uint_32t *src, uint32_t size, uint32_t DMA_BASE)
{
MEM(DMA_BASE+DMA_ENABLE) = 0x1;
MEM(DMA_BASE+DMA_UNK1) = unk1; // 0 or 2
MEM(DMA_BASE+DMA_ACK) = 0x0;
MEM(DMA_BASE+DMA_SRC) = (uint32_t)pSrc;
MEM(DMA_BASE+DMA_DST) = (uint32_t)pDst;
MEM(DMA_BASE+DMA_SIZE) = size;
MEM(DMA_BASE+DMA_CONFIG) = config; // 0x1 or 0x7 or 0xF
// start DMA transfer
MEM(DMA_BASE+DMA_CONTROL) = control; // 0x1 or 0x30001
// wait for complete
while (MEM(DMA_BASE+DMA_ACK)==0)
msleep(1);
}
There are still unknowns I have not looked at, like DMA_CONFIG defines if interrupt must be used, I don't know how to install these interrupt handler.
CONFIG_EDMAC_MEMCPY is just a EDMAC version of memcpy, properly because the dma_memcpy never was used correctly (i.e. slow dma_memcpy using wrong configuration)
Great, thanks a lot, good write up! So this is an improvement on an old system. Sounds useful and will be interesting to see how it interacts with EDMAC - can we use both at once, do we hit ram limits, etc?
Doesn't look like we use dma_memcpy() much, but there are a few places. I'll see if I can improve mem benchmark module with this change, and test on a few cams.
We can use both at the same time. I ran the test in photo mode (without other anything running) but also in LV mode - I assume Canon's EDMAC are running here. I did however not benchmark inside LV with recording on. We will hit SDRAM speed limits. On the 7D2 I ran test (photo mode) on a single DMA and got ~525 MB/s, but two parallels only got 599 MB/s, so there is a limit. While testing in LV mode the benchmark dropped around 10%.
I played around with this and now understand it more. I haven't been able to do direct comparison between EDMAC on modern digic and fast dma_memcpy(), for complicated reasons.
Heder isn't using dma_memcpy() the *function*, he's using the underlying physical DMA controller in a similar manner to how the code tries to do it, but via direct access. I suspect the reason you're doing that is because dma_memcpy() doesn't work on 7D2? At least, that's what I find: it always fails for me, taking the "Nothing DMA ch now!" path, which I think means it fails to find a free DMA channel, possibly because they haven't been initialised.
7D2 has EDMAC, and it lives on Omar core. https://www.magiclantern.fm/forum/index.php?topic=26249.msg245605#msg245605
If we want to use EDMAC resources that are sometimes used by *any* DryOS instance, we may have to go through Omar, or we're going to get into trouble with races / contention of physical resources. If we can find channels / ports that are never used by DryOS then we can probably do stuff direct from ICU. Or if there's some signalling method, RPC or interrupts etc to synchronise across cores.
D7 has a very different dma_memcpy() to older gens. The functionality is the same, but the code is doing things in a very different way, no use of digic registers are easily found. Might exist deeper into the code, I haven't spent a lot of time on it (EDMAC works for memory copies here).
Given that dma_memcpy() looks deliberately not working on 7D2 ICU, but does work on Digic 7, maybe this functionality is supposed to happen via Omar on D6? It's not clear to me.
After a lot of reading very old forum posts, and much messing about in Ghidra, I now have some important stubs found for 7D2 1.1.2. These are all on Omar:
8000626a EngDrvOut
800062a4 EngDrvBits
800062ba EngDrvOuts
80006298 shamem_read
800063c2 StartEDmac
80006498 edmac_set_addr
800064c2 edmac_set_size
80006bfe ConnectWriteEDmac
80006c10 ConnectReadEDmac
80006c42 RegisterEDmacCompleteCBR
Alex's notes say edmac_set_addr() and edmac_set_size() together act like SetEDmac, I haven't checked that. If true, we can wrap these together to provide that function.
As is, we cannot call these functions from ICU. The 0x8000_XXXX address space does not contain the same content if you read it from ICU vs Omar.
Heder - are any other stubs required to attempt reading from e.g. the sensor? To be safe, we need to find unused channels - anything else?
Quote from: names_are_hard on December 14, 2023, 09:36:57 PM
After a lot of reading very old forum posts, and much messing about in Ghidra, I now have some important stubs found for 7D2 1.1.2. These are all on Omar:
8000626a EngDrvOut
800062a4 EngDrvBits
800062ba EngDrvOuts
80006298 shamem_read
800063c2 StartEDmac
80006498 edmac_set_addr
800064c2 edmac_set_size
80006bfe ConnectWriteEDmac
80006c10 ConnectReadEDmac
80006c42 RegisterEDmacCompleteCBR
Alex's notes say edmac_set_addr() and edmac_set_size() together act like SetEDmac, I haven't checked that. If true, we can wrap these together to provide that function.
As is, we cannot call these functions from ICU. The 0x8000_XXXX address space does not contain the same content if you read it from ICU vs Omar.
Heder - are any other stubs required to attempt reading from e.g. the sensor? To be safe, we need to find unused channels - anything else?
This is really good news. From a minimalistic approach, the only thing we really need is access from omar so we can use: shamem_read, EngDrvOut and EngDrvIn (not used in Canon's code anymore ?, equvivalent to the MEM macro). We could also go for a larger approach, i.e. get access to all functions or similar, but time has never cheap, and my sweet wife is actually getting slightly annoying :o when I spend too much time digging into assembly code @ home, so I need to use my time with caution. Accessing these 3 function are the minimum, the remaining can be supported in function-overrides.c. I tried accessing all of the old raw video registers (old 0xc0fxxxx now relocated to 0xd00xxxxx) and found I could NOT get access from ICU, that address range is only to be accessible from omar.
The first few registers from each EDMAC had readback capabilities, all cameras I believe, including the destination registers. I dumped the EDMAC channels a few days ago and there are many free once (atleast in HD video mode). The EDMAC SDRAM destination registers ends is the "0x8". I just need to do more testing HD Live Mode mode and then do a dump and see which one are free. I'm not concerned about not being able to access the EDMAC API from Omar, I can code that myself if needed.
*************************************
Edmac = 0xD0004000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x405A8F40
0xC = 0x0
*************************************
Edmac = 0xD0004200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004300
0x0 = 0x1
0x4 = 0x0
0x8 = 0x126E9E0
0xC = 0x0
*************************************
Edmac = 0xD0004400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x20000000
0xC = 0x0
*************************************
Edmac = 0xD0004600
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004800
0x0 = 0x1
0x4 = 0x0
0x8 = 0x9B2D80
0xC = 0x0
*************************************
Edmac = 0xD0004900
0x0 = 0x1
0x4 = 0x0
0x8 = 0x46DB80
0xC = 0x0
*************************************
Edmac = 0xD0004A00
0x0 = 0x1
0x4 = 0x0
0x8 = 0x9584B8
0xC = 0x0
*************************************
Edmac = 0xD0004B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x16BAEF40
0xC = 0x0
*************************************
Edmac = 0xD0004E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026500
0x0 = 0x8
0x4 = 0x0
0x8 = 0x1617A000
0xC = 0x79
*************************************
Edmac = 0xD0026600
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15D3EBA0
0xC = 0x14
*************************************
Edmac = 0xD0026700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1840715A
0xC = 0x0
*************************************
Edmac = 0xD0026900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026A00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15D38700
0xC = 0x1FEF
*************************************
Edmac = 0xD0026B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15C8D200
0xC = 0x1FC2
*************************************
Edmac = 0xD0026C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x18543000
0xC = 0x0
*************************************
Edmac = 0xD0030100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1A683C00
0xC = 0x0
*************************************
Edmac = 0xD0030200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1A684400
0xC = 0x0
*************************************
Edmac = 0xD0030300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x40ABF4F0
0xC = 0x0
*************************************
Edmac = 0xD0030400
0x0 = 0x8
0x4 = 0x0
0x8 = 0xAA9928
0xC = 0x0
*************************************
Edmac = 0xD0030500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030600
0x0 = 0x1
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x405BFF24
0xC = 0x0
************************************
Edmac = 0xD0030A00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1835FB80
0xC = 0x0
*************************************
Edmac = 0xD0030B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x409EA314
0xC = 0x0
*************************************
Edmac = 0xD0030E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
call("lv_save_raw",1) also works as expected :), RAW EDMAC is 0xD0004200. I dumped the raw image just to verify that it actually did work, I disregarded synchronization so I only got a part image, but it's raw bayer sensor data. The raw width is 1984, image size is 1832 the rest 143+9 is black borders, height is still unknown. Unpacked a image quick and dirty, post processed to show the bayer pattern: (press to expand)
(https://lh3.googleusercontent.com/pw/ABLVV84CoCXU_8bWuKBBXYw1wnCyDxRt_BuRIn3IgcM_gJBE1_4vLHhtEpuM0MWlCnZRgtZUJcoGv-V3wr-d9C1TVxje6khx5GiBfNnJ3Krq3wsVJ5U41pUlqYiE40csoiPaWpIG3yfUPwLlMyh08gWdsDqF=w1984-h824-s-no-gm)
Nice, glad it's useful to you! I've been looking for these for ages (more the 200D ones really), and now I know how to do it, it's not even that hard to find. But the docs for what anything means are so fragmentary :(
The EDMAC stuff you're talking about helps me, it's easier to understand the wiki page now: https://magiclantern.fandom.com/wiki/Register_Map#EDMAC
It would make sense to me if you could read back the edmac_info region values, I'll try that. I want to map out usage, I assume channels get remapped when in different modes / purposes. I'm reading up on EDMAC (again) and intend to run tests on 200D - Digic 7 doesn't have Omar, and we can patch rom via MMU, so it's easier. The code in edmac-memcpy.c has a lot of very ugly hard-coded values, as does the module. I will look at making these general, should help me understand how things work, and it would be good to have these working on modern cams.
Re running code on Omar, I can think of a few ways. The cleanest would be finding an existing Canon RPC mechanism. It feels likely this exists (probably the code near fe0a30b2 is doing RPC with Omar). If it doesn't, or we can't find it, since Omar is running DryOS, and ICU supplies the firmware it runs, it wouldn't be that hard to create our own RPC. Bilal pointed me at some experiments on Eeko RPC here: https://www.magiclantern.fm/forum/index.php?topic=13408.msg175842#msg175842 Might be useful? It's not clear how it triggers code in shared mem to run, presumably via the 0xc0XX_YYYY registers, but it's not explained.
So, we have options. Since I don't know how to use EDMAC yet perhaps it makes sense for you to get it working however you want, and I can try and make a cleaner RPC method if needed. Presumably 5D4 is similar, would be nice to have it somewhat general.
lv_save_raw is new to me. The function just sets a flag, and indeed forum search suggests "There's a debug flag (lv_save_raw) that enables this". I see that CONFIG_EDMAC_RAW_SLURP is supposed to be "better" than lv_save_raw. Trying to understand this from reading forum posts is so incredibly slow. I'm glad you're still around to keep the old knowledge alive :)
Possibly related... take a look at 7d2 master rom1, fe25570a. This is clearly Omar init related and looks to be doing something EDMAC.
I believe 13dfe() is send_msg_to_Omar(), there's a similar ComForOmar on the other side. No idea on the message contents (refs Postman, so probably the same system, whatever that is).
fe0ad874 is load_Omar(). This copies (somehow, indirectly) Omar firmware from 7D2 master, and does some other region setup.
I would guess 0xdff0_0000 is mirrored to 0x8000_0000, 0xdff4_0800 to 0x8000_0800. However, my quick tests on phys cam don't make sense. Maybe I did something wrong, maybe my assumptions are wrong. Either way, it seemed potentially useful enough that I wanted to share before fully understanding it.
Bear in mind, we think the Omar core is Digic 5: ARMv5t. D6 is ARMv7-R. I know that's not forward compatible: -R has hardware division ops. Can't remember if it's backwards compatible. I think so? Running Omar code from ICU may be dumb for a bunch of other reasons too, but you know that :D
EDIT: mistake identified. I'd got two comments in the wrong places in a struct.
omar_dst_01 0xdff00000 // this is mapped as Omar atcm at 0x0
icu_src_01 code at 0xfe6afd04
len_01 0x6c80
omar_dst_02 0xdff40800 // this is mapped as Omar btcm at 8000_0800
icu_src_02 code at 0xfe6b698c
len_02 0xa0f0
omar_dst_03 0x1ac0000
icu_src_03 0xfe6c0a84
len_03 0x95c8
omar_dst_04 0x1ae0000
icu_src_04 0xfe6ca054
len_04 0x1f2ea8
So, all the Omar EDMAC func code should be readable (and writable!) in the dff40800 region. Good luck flushing Omar's icache, I guess.
Big post ;D
This is a kinda of magic. In programming there a way of saying that there's two kind of people those that understand and those does does not. 1+1=10 , but the truth is right now that when we do ping pong reverse engineering the truth is more like 1+1=3. In fact we don't need to access to omar core at all, we now have everything we need now. The omar btcm memory 0x80000000 is mapped the other core, were we're running ML. Take a deeper look and the puzzle suddenly become much more clear. The function names_are_hard in fact accessible and useable from both cores.
1. Shadow memory, aka. shamem_read.
From Wiki:
In computing, shadow memory is a technique used to track and store information on computer memory used by a program during its execution. Shadow memory consists of shadow bytes that map to individual bits or one or more bytes in main memory. These shadow bytes are typically invisible to the original program and are used to record information about the original piece of data.
This functionality was introducted in DIGIC 4 processor. I was working on the DIGIC 3 (40D) which was missing huge parts of the API that was present in the DIGIC4 camera's. Remeber that DIGIC4 camera's where the foundation of ML. shamem_read was missing on 40D so I had to understand it, and create a software abtration layer was mimicked this. The reason behind this is cost (assumption), i.e. time to design and manufactor a complex SoC system. Look at the EDMACs where the first few registers are read/writeable, yet the last EDMAC registers are not. This have never changed since D3 processor. The reason is the SoC design become more and more complex. If you design a SoC and need to make all registers (register in GPIO address space) read/writeable is will cost you a lot of additional logic and internal wires. You could make it much more simple if you only allow to write to a part design without being capable of reading, this would save you internal wires and clock logic. Yet if you still needed to read some of these registers a simple solution is present, just to copy the value you write to shadow memory, i.e. backup memory, before you actually write the value of the GPIO.
On DIGIC 4+ camera (1300D), the shadow memory shamem_read/EngDrvOut mask is 0x3FFFF, meaning there a table 65k longs of shadow GPIO values, example:
EngDrvOut(0xC0F06084,0x12345678)
Step 1. *(shadow_mem_ptr| 0x3FFFF & 0xC0F06084) = 0x12345678
Step 2. *0xC0F06084 = 0x12345678
The shadow memory range is different on newer than older cameras, On the 7D2 the mask is 0xD007FFFF, which equal 131k logns of shadow values. The shadow memory is inside SDRAM and accessible to us. The only draw back is that Canon ONLY calls EngDrvOut and friends when the need to store the shadow value, while other times they access the GPIO directly and thus the shadow values is not updated.
2. PIC mapped 0xdffffxxxx to omar internal cache 0x80000000
This is really a gem named_are_hard has found. The code is PIC code (position independent code) using generic arm instructions that can be used any both processor. Basically this mean that both cores can used these functions. The Omar code we need is sitting at "icu_src_02 code at 0xfe6b698c", here all the function are that we need. shamem_read sitting at 0xfe6bc424 works flawlessly, I tested it.
3. Write access to GPIO on both core, yahoo!.
[/b]I tried reading from the 0xD007FFFF range, but failed, that is because I did not know that the individual sub port of the SoC no longer have read access and that the shadow memory range was expanded, on the 40D alot of value where still readable, but on 7D2 they're not. Write however works from both cores!, so we can overwrite any GPIO value from any core.
Final thoughts:
4. I don't see any reason anymore to access and change the omar core, we should have everything we need.
5. A minor problem we are facing is more of an internal coding. The MEM() macro is now outdated. On the 7D2 we now need to use the shamem_read for all 0xD007FFFF read operations, which MEM() does not allow for. The MEM() macro does not specific if you going to read or write, it just cast into a *uint32_t pointer. In the 7D2 case we now need MEM(address,operation), where operation can either we read or write. If it's a write we can do it directly, but if it's a read we need to call shamem_read() and I guess this is also the same with D78X
6. Another minor problem is that some values are not stored in the shadow memory or might have change position.
Proff of concept:
I ran some tests on overwriting FPS A + FPS B register in run_test() and got the FPS down to approx 1-2 fps seconds :D.
MEM(0xD0006008)= 0x7d207d2;
MEM(0xD0006014)= 1234;
MEM(0xD0006000)= 1;
EDMAC's taking while in LiveView (HD mode). I got more EDMAC values now, but keep in mind the Shadow memory is only update when Canon call EngDrvOut and frields, many places the EDMAC are accessed directly and thus we don't see these value.
*************************************
Edmac = 0xD0004000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004200
0x0 = 0x2
0x4 = 0x20301008
0x8 = 0x1A67C000
0xC = 0x0
0x10 = 0x42B0D90
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004300
0x0 = 0x4
0x4 = 0x20008000
0x8 = 0x1288800
0xC = 0x0
0x10 = 0x19705A0
0x14 = 0x0
0x18 = 0x20
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004400
0x0 = 0x1
0x4 = 0x60000000
0x8 = 0x3180D00
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004500
0x0 = 0x4
0x4 = 0x20008000
0x8 = 0x1F02E000
0xC = 0x0
0x10 = 0x4370F00
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004600
0x0 = 0x4
0x4 = 0x60000000
0x8 = 0x31EB200
0xC = 0x4A
0x10 = 0x1000
0x14 = 0x1000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004800
0x0 = 0x4
0x4 = 0x0
0x8 = 0xAB32B8
0xC = 0x0
0x10 = 0xDF07D0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x20001000
*************************************
Edmac = 0xD0004900
0x0 = 0x4
0x4 = 0x20001000
0x8 = 0x46D8E8
0xC = 0x0
0x10 = 0xDF07D0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x20001000
*************************************
Edmac = 0xD0004A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0xA5AB88
0xC = 0x0
0x10 = 0x42B0008
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x60000000
*************************************
Edmac = 0xD0004B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004C00
0x0 = 0x4
0x4 = 0x60000000
0x8 = 0x3180D00
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004D00
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x16F3E800
0xC = 0x0
0x10 = 0x3FB0E30
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0xB
0x14 = 0xC0000030
0x18 = 0x1
0x1C = 0x0
0x20 = 0x0
0x24 = 0x33
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026000
0x0 = 0x1
0x4 = 0x60000000
0x8 = 0x32AA400
0xC = 0x12
0x10 = 0xC00
0x14 = 0x1000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026200
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x1A49DBC0
0xC = 0x0
0x10 = 0x160050
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026500
0x0 = 0x2
0x4 = 0x60001008
0x8 = 0x0
0xC = 0x79
0x10 = 0x1EC0
0x14 = 0x8000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026600
0x0 = 0x2
0x4 = 0x60001008
0x8 = 0x0
0xC = 0x39
0x10 = 0x7610
0x14 = 0x8000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026800
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x1A478000
0xC = 0x0
0x10 = 0x11C03B6
0x14 = 0x0
0x18 = 0x14A
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x0
0xC = 0x1FFF
0x10 = 0xFFFE
0x14 = 0xFFFE
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026B00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x0
0xC = 0x1FFF
0x10 = 0xFFFE
0x14 = 0xFFFE
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030000
0x0 = 0x4
0x4 = 0x0
0x8 = 0x1830A800
0xC = 0x0
0x10 = 0x1670500
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030100
0x0 = 0x6
0x4 = 0x300008
0x8 = 0x1A685A00
0xC = 0x0
0x10 = 0xF01E0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030200
0x0 = 0x6
0x4 = 0x40300008
0x8 = 0x1A683E00
0xC = 0x0
0x10 = 0xC0200
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030400
0x0 = 0x6
0x4 = 0x300008
0x8 = 0xBACC80
0xC = 0x0
0x10 = 0x28
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030600
0x0 = 0x4
0x4 = 0x0
0x8 = 0x3397300
0xC = 0x0
0x10 = 0x3B00A0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x183166A6
0xC = 0x0
0x10 = 0x11A03B2
0x14 = 0x0
0x18 = 0x14E
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030B00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x184D2800
0xC = 0x0
0x10 = 0x1DF0500
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
GPIO taking while in LiveView (HD mode). Keep in mind the offsets are wrong 0xC0FXxxxx have changed to 0xD00XXXX. Some values seems to have change position (they're 0 ), but is you scroll down, you'll see all the LV size values are in the same positions as before, some time must be spend on finding the new positions for the missing value i.e. raw width and height for RAW video have changed position or is not recorded.
MEM(0xC0F03074) = 0x0 (Playback: horizontal banding (500D only?))
MEM(0xC0F03050) = 0x0 (Playback: vertical banding / darken?)
MEM(0xC0F08024) = 0x1000 (ISO related? (SHAD_MODE) (5D2: used for ISO 25600))
MEM(0xC0F08030) = 0x14C0 (Digital gain for ISO (SHAD_GAIN))
MEM(0xC0F08034) = 0x0 (Black level in LiveView / BW offset in photo mode (SHAD_PRESETUP))
MEM(0xC0F0819C) = 0xC38 (Saturate Offset (photo mode) (HIV_POST_SETUP))
MEM(0xC0F12054) = 0x0 (White level?)
MEM(0xC0F06000) = 0x0 (FPS register for confirming changes)
MEM(0xC0F06004) = 0x0 (FPS related, SetHeadForReadout)
MEM(0xC0F06008) = 0x0 (FPS register A)
MEM(0xC0F0600C) = 0x0 (FPS related)
MEM(0xC0F06010) = 0x0 (FPS related)
MEM(0xC0F06014) = 0x0 (FPS register B)
MEM(0xC0F06018) = 0x0 (FPS related)
MEM(0xC0F0601C) = 0x0 (FPS related)
MEM(0xC0F06020) = 0x0 (FPS related)
MEM(0xC0F06084) = 0x0 (RAW first line|column. Column is / 2. 600D: 0x0001007E.)
MEM(0xC0F06088) = 0x0 (RAW last line|column. 600D: FHD 1182|1070, 3x 1048|1102, HD 720|1070)
MEM(0xC0F06800) = 0x0 (RAW first line|column. Column is / 8 on 5D3 (parallel readout?))
MEM(0xC0F06804) = 0x0 (RAW last line|column. 5D3: f6e|2fe, first 1|18 => 5936x3950)
MEM(0xC0F07000) = 0x0 (HEAD timers (SSG counter, 0x01 to restart))
MEM(0xC0F07004) = 0x0 (HEAD timers)
MEM(0xC0F0700C) = 0x0 (HEAD timers, 0x01 to stop/standby)
MEM(0xC0F07010) = 0x0 (HEAD timers)
MEM(0xC0F07014) = 0x0 (HEAD timers)
MEM(0xC0F07018) = 0x0 (HEAD timers)
MEM(0xC0F0701C) = 0x0 (HEAD timers)
MEM(0xC0F07038) = 0x0 (HEAD timers, 0x01 <- stops processing?)
MEM(0xC0F0707C) = 0x0 (HEAD timers)
MEM(0xC0F071AC) = 0x0 (HEAD timers)
MEM(0xC0F070C8) = 0x0 (HEAD timers, State 2 Register / VCount?)
MEM(0xC0F07048) = 0x0 (HEAD1 timer (start?))
MEM(0xC0F0704C) = 0x0 (HEAD1 timer)
MEM(0xC0F07050) = 0x0 (HEAD1 timer (ticks?))
MEM(0xC0F0705C) = 0x0 (HEAD2 timer (start?))
MEM(0xC0F07060) = 0x0 (HEAD2 timer)
MEM(0xC0F07064) = 0x0 (HEAD2 timer (ticks?))
MEM(0xC0F07134) = 0x0 (HEAD3 timer (start?))
MEM(0xC0F07138) = 0x0 (HEAD3 timer)
MEM(0xC0F0713C) = 0x0 (HEAD3 timer (ticks?))
MEM(0xC0F07148) = 0x0 (HEAD4 timer (start?))
MEM(0xC0F0714C) = 0x0 (HEAD4 timer)
MEM(0xC0F07150) = 0x0 (HEAD4 timer (ticks?))
MEM(0xC0F08D1C) = 0x0 (Vignetting correction data (DIGIC V))
MEM(0xC0F08D24) = 0x0 (Vignetting correction data (DIGIC V))
MEM(0xC0F08578) = 0x0 (Vignetting correction data (DIGIC IV))
MEM(0xC0F0857C) = 0x0 (Vignetting correction data (DIGIC IV))
MEM(0xC0F140C4) = 0x0 (Display saturation)
MEM(0xC0F141B8) = 0x0 (Display brightness and contrast)
MEM(0xC0F14140) = 0x0 (Display filter (EnableFilter, DIGIC peaking))
MEM(0xC0F14164) = 0x0 (Display position (vertical shift))
MEM(0xC0F140CC) = 0x0 (Display zebras (used for fast zebras in ML))
MEM(0xC0F37AE4) = 0x200 (ISO digital gain (5D3 photo mode))
MEM(0xC0F37AF0) = 0x200 (ISO digital gain (5D3 photo mode))
MEM(0xC0F37AFC) = 0x200 (ISO digital gain (5D3 photo mode))
MEM(0xC0F37B08) = 0x200 (ISO digital gain (5D3 photo mode))
MEM(0xC0F37AE0) = 0x73C8 (ISO black/white offset (5D3 photo mode))
MEM(0xC0F37AEC) = 0x73C8 (ISO black/white offset (5D3 photo mode))
MEM(0xC0F37AF8) = 0x73C8 (ISO black/white offset (5D3 photo mode))
MEM(0xC0F37B04) = 0x73C8 (ISO black/white offset (5D3 photo mode))
MEM(0xC0F08004) = 0x0 (DARK_MODE (bitmask of bits 0x113117F))
MEM(0xC0F08008) = 0x0 (DARK_SETUP (mask 0x7FF signed) (brightns/darkens frame))
MEM(0xC0F0800C) = 0x0 (DARK_LIMIT (mask 0x3FFF) (no noticeable change))
MEM(0xC0F08010) = 0x0 (DARK_SETUP_14_12 (mask 0x07FF) (brighten, overwrites DARK_SETUP))
MEM(0xC0F08014) = 0x0 (DARK_LIMIT_14_12 (0x0000 - 0x0FFF) (no noticeable change))
MEM(0xC0F08018) = 0x0 (DARK_SAT_LIMIT (0x0000 - 0x3FFF) (no noticeable change))
MEM(0xC0F082A0) = 0x0 (DARK_KZMK_SAV_A (0/1) (causes white or black screen))
MEM(0xC0F082A4) = 0x0 (DARK_KZMK_SAV_B (0/1) (no noticeable change))
MEM(0xC0F08100) = 0x0 (CCDSEL (0-1))
MEM(0xC0F08104) = 0x0 (DS_SEL (0-1))
MEM(0xC0F08108) = 0x0 (OBWB_ISEL (0-7))
MEM(0xC0F0810C) = 0x0 (PROC24_ISEL (0-7))
MEM(0xC0F08110) = 0x0 (DPCME_ISEL (0-15))
MEM(0xC0F082D0) = 0x0 (PACK16_ISEL (0-15))
MEM(0xC0F082D4) = 0x0 (WDMAC32_ISEL (0-7))
MEM(0xC0F082D8) = 0x0 (WDMAC16_ISEL (0-1))
MEM(0xC0F082DC) = 0x0 (OBINTG_ISEL (0-15))
MEM(0xC0F082E0) = 0x0 (AFFINE_ISEL (0-15))
MEM(0xC0F08390) = 0x0 (OBWB_ISEL2 (0-1))
MEM(0xC0F08394) = 0x0 (PROC24_ISEL2 (0-1))
MEM(0xC0F08398) = 0x0 (PACK32_ISEL2 (0-3))
MEM(0xC0F0839C) = 0x0 (PACK16_ISEL2 (0-3))
MEM(0xC0F083A0) = 0x0 (TAIWAN_ISEL (0-3))
MEM(0xC0F08220) = 0x0 (ADKIZ_ENABLE?)
MEM(0xC0F08224) = 0x0 (ADKIZ_THRESHOLD)
MEM(0xC0F08238) = 0x0 (ADKIZ_INTR_CLR)
MEM(0xC0F0825C) = 0x0 (ADKIZ_THRESHOLD_14_12)
MEM(0xC0F08234) = 0x0 (ADKIZ_TOTAL_SIZE)
MEM(0xC0F0823C) = 0x0 (ADKIZ_INTR_EN)
MEM(0xC0F08060) = 0x0 (DSUNPACK_ENB?)
MEM(0xC0F08064) = 0x0 (DSUNPACK_MODE)
MEM(0xC0F08274) = 0x0 (DSUNPACK_DM_EN)
MEM(0xC0F08130) = 0x1 (DEFM_ENABLE?)
MEM(0xC0F08138) = 0x0 (DEFM_MODE)
MEM(0xC0F08140) = 0x0 (DEFM_INTR_NUM)
MEM(0xC0F0814C) = 0x5 (DEFM_GRADE)
MEM(0xC0F08150) = 0x0 (DEFM_DAT_TH)
MEM(0xC0F08154) = 0x0 (DEFM_INTR_CLR)
MEM(0xC0F08158) = 0x0 (DEFM_INTR_EN)
MEM(0xC0F0815C) = 0x0 (DEFM_14_12_SEL)
MEM(0xC0F08160) = 0x0 (DEFM_DAT_TH_14_12)
MEM(0xC0F0816C) = 0x0 (DEFM_X2MODE)
MEM(0xC0F08180) = 0x1 (HIV_ENB)
MEM(0xC0F0818C) = 0x0 (HIV_POS_V_OFST)
MEM(0xC0F08190) = 0x0 (HIV_POS_H_OFST)
MEM(0xC0F08420) = 0x4FF (HIV_BASE_OFST)
MEM(0xC0F08428) = 0x0 (HIV_GAIN_DIV)
MEM(0xC0F0842C) = 0x0 (HIV_PATH)
MEM(0xC0F08218) = 0x0 (HIV_IN_SEL)
MEM(0xC0F08214) = 0x0 (HIV_PPR_EZ)
MEM(0xC0F082C4) = 0x0 (HIV_DEFMARK_CANCEL)
MEM(0xC0F08240) = 0x0 (ADMERG_INTR_EN)
MEM(0xC0F08244) = 0x0 (ADMERG_TOTAL_SIZE)
MEM(0xC0F08250) = 0x0 (ADMERG_2_IN_SE)
MEM(0xC0F08020) = 0x0 (SHAD_ENABLE?)
MEM(0xC0F08028) = 0x0 (SHADE_PRESETUP)
MEM(0xC0F0802C) = 0x0 (SHAD_POSTSETUP)
MEM(0xC0F08038) = 0x800 (SHAD_POSTSETUP_14_12)
MEM(0xC0F08280) = 0x0 (SHAD_CBIT)
MEM(0xC0F08284) = 0x0 (SHAD_C8MODE)
MEM(0xC0F08288) = 0x0 (SHAD_C12MODE)
MEM(0xC0F08290) = 0x0 (SHAD_COF_SEL)
MEM(0xC0F0828C) = 0x0 (SHAD_RMODE)
MEM(0xC0F082A8) = 0x0 (SHAD_KZMK_SAV)
MEM(0xC0F08040) = 0x0 (TWOADD_ENABLE)
MEM(0xC0F08044) = 0x0 (TWOADD_MODE)
MEM(0xC0F08050) = 0x0 (TWOADD_SETUP_14_12)
MEM(0xC0F08054) = 0x0 (TWOADD_LIMIT_14_12)
MEM(0xC0F08048) = 0x0 (TWOADD_SETUP)
MEM(0xC0F0804C) = 0x0 (TWOADD_LIMIT)
MEM(0xC0F08058) = 0x0 (TWOADD_SAT_LIMIT)
MEM(0xC0F082AC) = 0x0 (TWOA_KZMK_SAV_A)
MEM(0xC0F082B0) = 0x0 (TWOA_KZMK_SAV_B)
MEM(0xC0F08114) = 0x0 (LV raw type (see lv_af_raw, lv_set_raw) - DIGIC IV (PACK32_ISEL))
MEM(0xC0F37014) = 0xE (LV raw type (see lv_af_raw, lv_set_raw) - DIGIC V)
MEM(0xC0F10064) = 0x42B01EF (LV resolution (RAW.height | RAW.width))
MEM(0xC0F080B0) = 0x0 (LV resolution (RAW.height | RAW.width))
MEM(0xC0F08184) = 0x0 (LV resolution (RAW.height) aka HIV_V_SIZE )
MEM(0xC0F08188) = 0x0 (LV resolution (RAW.width) aka HIV_H_SIZE )
MEM(0xC0F08194) = 0x0 (LV resolution (RAW.width))
MEM(0xC0F08198) = 0x0 (LV resolution (RAW.width))
MEM(0xC0F1D014) = 0x0 (LV resolution (raw.j.height? | raw.j.width?))
MEM(0xC0F11394) = 0x3FB0717 (LV resolution (raw.j.height | raw.j.width))
MEM(0xC0F1151C) = 0x437077F (LV resolution (raw.j.height | raw.j.width))
MEM(0xC0F1A00C) = 0x3FB0717 (LV resolution (raw.j.width | raw.j.height))
MEM(0xC0F25054) = 0x0 (LV resolution (raw.j.width))
MEM(0xC0F2500C) = 0x0 (LV resolution (raw.j.width))
MEM(0xC0F1155C) = 0x437077F (LV resolution (raw.j.height | hd.width))
MEM(0xC0F112D4) = 0x16F0280 (LV resolution (raw.j.height | ?) before upsampling?)
MEM(0xC0F11314) = 0x2D0027 (LV resolution (raw.j.height | lv.width) before upsampling?)
MEM(0xC0F08548) = 0x0 (LV resolution * downsize factor? (RAW.height * D | RAW.width * D))
MEM(0xC0F09050) = 0x340031 (Aewb metering area (y1|x1))
MEM(0xC0F09054) = 0x41401E1 (Aewb metering area (y2|x2))
MEM(0xC0F383D4) = 0x0 (Preview area (y1 | x1/4))
MEM(0xC0F383DC) = 0x41001C8 (Preview area (y2 | x2/4))
MEM(0xF000180E) = 0x0 (Blue LED)
MEM(0xF0001810) = 0x0 (LightMeasure)
MEM(0xF0001D02) = 0x0 (DFE gain (similar to ADTG 888x))
MEM(0xF0001D04) = 0x0 (DFE gain (similar to ADTG 888x))
MEM(0xF0001D06) = 0x0 (DFE gain (similar to ADTG 888x))
MEM(0xF0001D08) = 0x0 (DFE gain (similar to ADTG 888x))
My time for ML this year is running out, Christmas & New Year is closing in fast, but the fact that we have come so far now is cool, ML is comming to 7D2 :)
Quote from: names_are_hard on December 14, 2023, 09:36:57 PM
8000626a EngDrvOut
800062a4 EngDrvBits
800062ba EngDrvOuts
80006298 shamem_read
800063c2 StartEDmac
80006498 edmac_set_addr
800064c2 edmac_set_size
80006bfe ConnectWriteEDmac
80006c10 ConnectReadEDmac
80006c42 RegisterEDmacCompleteCBR
These are also present at the 0xfe6b698c region and stubs can be created and included in stubs.h the only question is ... does the EDMAC system known which core called RegisterEDmacCompleteCBR ?
It may not be safe to run the Omar code from ICU. These cores are similar but different ARM architectures. The code may not be compatible with ICU. I also don't know if this code is truly PIC. Arm code tends to be mostly PIC by default, but this is no guarantee it all is. And, calling shamem_read() from ICU may well give incorrect results - assuming it's intended to be read from Omar, the masking may be the reverse of what you expect.
Some of the EDMAC routines obtain kernel locks before proceeding. Since the Omar core is running an entirely different instance of the OS, I wouldn't expect these to be shared locks with the ICU. This is untested. And, since the kernel locks probably aren't shared between different OS instances, the cam will crash if you contest for resources on different cores.
The Omar 0x8000_6XXX code is populated by a copy from fe6X_YYYY rom region. See the struct created in fe0ad874(). After the copy, the memory is visible at 0xdfXXXXXX on 7D2, or 0x8000_XXXX on Omar - I haven't tested writing the 7D2 side so I don't know if this is a mirror (my guess) or a copy.
Triggering arbitrary code from Omar looks easy, so this may be the safer route. That way we know code is running in the intended context. If you can prove all the code is appropriate and safe to run from ICU context that's fine too. Feels like more work to me. It also seems fairly likely there is an existing RPC mechanism.
The shamem info is useful to me, thanks. I've not worked with this before, it doesn't seem to exist on D7 and above.
Accordingly to ARM TCM memories are non-cacheable non-sharable normal memory. I wonder if the 0x80000000 is real TCM memory ...
Can't trust anything you read :D Nothing beats testing. I would expect 0x8XXXYYYY to be separate (different address space?) comparing Omar and ICU. But I'm guessing 0xdfXXYYYY is mirrored, so it doesn't matter. If Omar instead copies from that range into 0x8XXXYYYY, then it may be harder to mess with.
Quote from: names_are_hard on December 18, 2023, 11:34:17 PM
Can't trust anything you read :D Nothing beats testing.
Yea, testing is always required ;)
Bascially i'm trying to work my way out of RPC'ing too much, eventually we'll properly have to do this, but I want to explore the options not to. Dont get me wrong, RPC'ing is the right way, but
jumping over the fence at the smallest point is'nt the worst approch either.
I did try to locate the RPC function on the Omar side but failed :(, on the ICU side they're quite easy to find, the naming is the same as the old stubs.
Also I wonder (yes another test to do done) if Omar support but uncacheable bit. The Omar EngDrvOut/shamem_read and friends uses a pointer stored in RAM to read/write shadow values. I could alternate this pointer value and set the uncacheable bit, but I wonder if Omar support this. If it does, both cores would be in sync, when using these function. I also wonder is writing to a uncache address in ICU will clear the cache version in Omar, if Omar has a cache version of the value..
soo many question, too few answers ::)
I have no problem with hacks while exploring :) Only if we give stuff to other people do we need to make sure it's doing things in a sensible way.
Which old RPC stubs are these? Omar is a new core with digic 6. Something like Eeko, but not the same.
It's pretty sure it's nearly the same like the old api. RequestRPC has the same arguments. RegisterRPCHandler on 7D2 has a third argument, but it's always 0.
The two important RPC functions:
THUMB_FN(80003416, RPCRegisterHandler)
THUMB_FN(8000351e, RequestRPC)
Current prototypes from dryos.h
uint32_t RegisterRPCHandler (uint32_t rpc_id, uint32_t (*handler) (uint8_t *, uint32_t));
uint32_t RequestRPC (uint32_t id, void* data, uint32_t length, uint32_t cb, uint32_t cb_parm);
Ghidra Examples:
RegisterRPCHandler(0x4005,DAT_fe0ba558,0); // Id, and handler function (DAT_fe0ba558 points to a function at FE0B9F7Bh)
RequestRPC(0x1024,0,0,0,0); // only Id
RequestRPC(&LAB_00002046,puVar1,4,0,0); // Id, data and size of data (puVar1 is pointer to a 32 bits variable)
Ah, that RPC handler. Isn't that the one for doing master-slave comms? 7D2 has master, slave *and* Omar.
Yes, it easily get confusing, with this new design. There's also a function to send message to Omar, FMID_COM_SengMsgToOmar, but I have not tried to decode that function. Use many places and afterward the code wait for TakeSemaphore.
I getting confused reading this page:
https://chdk.fandom.com/wiki/Digic_6-7_Porting
Ah, okay, so not a confirmed Omar RPC function. Oh well :) Yes, I've seen that msg send function. I haven't tried logging it to see what it sends, don't know if it allows RPC.
Something I hadn't noticed before from that wiki page, they claim Omar is also R4. I thought it was a Digic 5 chip, but if it's R4 I'm wrong. Could use cpu ID registers to check. If it is, then we at least know the Omar firmware blob is compatible with ICU (we still don't know if it all makes sense to run from ICU context).
R4, source via reyalp at CHDK -> https://chdk.setepontos.com/index.php?topic=11316.msg142241#msg142241
Quote from: kitor on December 20, 2023, 08:40:08 AM
R4, source via reyalp at CHDK -> https://chdk.setepontos.com/index.php?topic=11316.msg142241#msg142241
Thia is really convenient and will make the port more easy, but still it's a strange beast, "dual core + single core"
Both 7D2 master and slave have their own Omar. I've done a little investigation, I have suspicions that it might be a true dual-core part, if so, this is "dual-socket dual-core", with four R4 cores in total. Hard to prove fully without a nice x-ray machine I suppose :)
Quote from: heder on December 20, 2023, 04:52:44 PM
Thia is really convenient and will make the port more easy, but still it's a strange beast, "dual core + single core"
Huh? D6 is one R4 core (Marius, what we call ICU) and one secondary R4 (Omar), also one secondary Xtensa (Zico, GPU accel) and two tiny cores (Arima, Shirahama; IIRC Xtensa, in single CPU models related to lens comm. They run tiny dryos variant like MPU)
7D2 has two physical D6 chips, thus twice that. So four R4 cores in total across two physical CPUs.
The Master ICU processor has a "DSEngio" engio write (0x00013ea0) function which is used to activate LiveView (0x00017c24), including FPS registers, it's set all the standard FPS registers - but a the new address range 0xD00060{08,10,0c,14}. This is quite usefull. Inside this engio write function there is a DryOsDebugMessage for each write, I can hijack this DryOsDebugMessage and investigate everything that the master writes. This write is not backup'ed in the shamem_read (shamem seems to only be controlled by the Master Omar processor).
I have created a BL_INST_T2 which performs the same actions as BL_INST but in thumb2 mode, that can be used to hijack instruction BL instructions in thumb2 mode - but ofc only in RAM, also it can only jump +/-22 bits, but this ain't a problem on the 7D2 ML starts around 0x1CC440 which is less than 22 bits from 0x0.
I have RAW video up and running. I'm going to Egypt next month Giza, Luxor and the valley on the kings and the Nile, was there 24 years ago, going back so I'm really excited. But going there without ML RAW video is bad karma, so I had to investigate every possible way of getting the camera to do as I wish.
- Tryed ordinary DMA failed, failed it's too slow in LV mode
- Tryed Omar EDMAC functions .. failed, they're not compatible
- Tryed Recreating all edmac functions .. failed
- Tryed direct buffering (edmac not needed) using 14 bits .. success 8) using a very old mlv_lite module
Im was recording the entire RAW buffer including black border, 1984x1068x14bits, around 85 MiB/s for 24 fps. I will try to record a large file using a fast CF card ( DMA-6) in the following days to see if I get frame drops. The following video was recording using 25 fps, and recoded to H.264
Nice work! I'm still struggling with edmac on 200D.
Show me your code or I will send assassins to Egypt :D
The code is pure spaghetti carbonára :P. I was hacking for a whole month, nothing worked until I used direct buffering, turned out it worked. But the direct buffering only works on the full stream, i.e. full image, but for a beginning it's quite useful. I have not pushed the code into git I will check-in the mlv_lite in tomorrow. The magic is done in mlv_lite process_frame(), only changed a few lines of code.
Yup, understood. I have 7D2 so anything I can verify will help me a lot, there's sure to be things I can steal for other cams.
Code can be crap quality for now and made nice before merging to dev branch.
7D2 is using 3x3 binning as 5D3. So moiré/aliasing should not be a big concern using full sensor.
But why UDMA-6 CF? Cam supports UDMA-7.
Quote from: Walter Schulz on January 18, 2024, 07:42:13 AM
7D2 is using 3x3 binning as 5D3. So moiré/aliasing should not be a big concern using full sensor.
But why UDMA-6 CF? Cam supports UDMA-7.
I did not see any moiré/aliasing so far, I'll have to do some more testing today.
Yes the camera support UDMA-7, but I never got to the point of buying a UDMA-7 card, as my old camera (40D) is PIO mode only. But I will need to upgrade soon. Btw. in Zoom (x5,x10) mode the format goes to 3616 x 1348, not bad for a beginning, yet that requires around 195 MiB/s at 24 fps, which can only be achieved if we can use both cards slots at the same time.
Congrats heder, it sounds like a big step forward!!! :o
Quote from: heder on January 17, 2024, 10:53:04 PM
I have RAW video up and running. I'm going to Egypt next month Giza, Luxor and the valley on the kings and the Nile, was there 24 years ago, going back so I'm really excited. But going there without ML RAW video is bad karma, so I had to investigate every possible way of getting the camera to do as I wish.
- Tryed ordinary DMA failed, failed it's too slow in LV mode
- Tryed Omar EDMAC functions .. failed, they're not compatible
- Tryed Recreating all edmac functions .. failed
- Tryed direct buffering (edmac not needed) using 14 bits .. success 8) using a very old mlv_lite module
Im was recording the entire RAW buffer including black border, 1984x1068x14bits, around 85 MiB/s for 24 fps. I will try to record a large file using a fast CF card ( DMA-6) in the following days to see if I get frame drops. The following video was recording using 25 fps, and recoded to H.264
Wow. Great stuff.
There´s an 7D mark II for sale in Sweden for 4000:-. Maybe I should buy it.
You may want to hold off a little. We're making fast progress behind the scenes. Heder knows how Edmac is supposed to work on the old cams, and I've done a lot of work finding Edmac code in new cams, as well as in general making the new cams run ML. So we're giving each other the missing pieces.
I don't know what this "direct buffering" is that Heder mentions, but I'm hoping when I see the code it will be easy to port to other cams. I can already get HD 422 YUV from 200D, and I have Edmac APIs 95% working there, too. Digic 7 cams will in general be easier to hack around on, due to MMU.
On the other hand, 7D2 is a nice cam, why not buy it anyway? :)
I wonder what could a 5Ds do with magic lantern ::)
Same dual Digic 6 as the 7D Mark II, but lots of pixels, so in theory high processing capacity and memory... very curious :D
Don't expect too much. Most likely this cam is hampered by rolling shutter galore.
Haven't tested it yet, though.
Rolling shutter galore 😂.
I'll keep messing with eos m for a while. Nice progress though. First cam with full HD 60fps.
5DS can't do this ootb.
Don't get me wrong: 5DS (plus/minus R) is a fascinating cam but I'm afraid it will disappoint for raw recording. 7D2 and rest of D6 bunch may see some boost, though. Esp. 7D2 because of 3x3 binning.
Quote from: names_are_hard on January 18, 2024, 05:42:24 PM
...
I don't know what this "direct buffering" is that Heder mentions, but I'm hoping when I see the code it will be easy to port to other cams.
...
Buffering in mlv_lite, click to expand images
- A: Sensor
- B: Canon Liveview RAW image buffers
- C: ML (mlv_lite,mlv_rec) double RAW buffers
- D: ML image (save) buffers
- E: CF/SD card slot
(https://lh3.googleusercontent.com/pw/ABLVV87fkEJsUnHYnuXJkWxIE6N24eh-oVsgWbX7GuqjDEFaHojxpAT6kWQ8bveYBVyFNGYxtyDokKKJWSpzzAiACQpw2414v12T1Kx5JO2JVdfN-2I8-zRlb_MiAFyuqePaVfwk34jrEvB_fPeapRb20ALI=w951-h617-s-no-gm)
When we enable RAW, call("lv_save_raw), canon firmware will create a "RAW" EDMAC transfer from sensor (A) to its own buffers (B). The size of the RAW images is set by canon. (I know on some builds you can mess with the sizes, but this is NOT portable and re-useable on all platforms)
(https://lh3.googleusercontent.com/pw/ABLVV86yaotKdakiRImLbgbtXiyfR0kebe9ga0syn1wsetISdRtrjBOfTIlbzu8M1XQhHijiadV2khxA5e1rtN1DbyAEf7WTFZhVZHOcmwhUUHGJvWUbQ-nmYryg2qr3ivvgP-bjHmToGK8GGlI9V78qd7Tr=w1032-h617-s-no-gm?authuser=0)
When we start mlv_lite or mlv_rec recording ML re-routes the "RAW" EDMAC destination from canon buffers (A) to our own ML buffers (C). Both Canon and ML buffers are equal size. Then ML will create an additional EDMAC transfer, that performs a sub-image copy to the user format (i.e. user requested width and height). the final image ends in the save buffer (D) before being written to CF/SD card (E).
Doing it in this way will make the code portable and re-useable between builds and cameras, that is pretty important. We cant have too many #ifdef if the code, itwill kill the project. Also keep in mind that on many camera it's not the internal hardware , sensors, memory that is a problem, it's the maximum save bandwidth on the CF/SD cards, thus using a smaller format (if possible) less bit (is possible), overclocking CF/SD card (if possible) if what you want to achieve your goals.
(https://lh3.googleusercontent.com/pw/ABLVV86wWy01qnLoAmlV8ETB51HZd4w25cCQoamwnS4_PlID9J9ziB752crl1GIqIfjhe1sZev8jZH60P3KDXSgVD4mDT6qY29y6v_6sb-bSCADTHF8nUITtIiPm6MF8FK525K3-Fa1iPJr78UtBqjm9Ycuy=w996-h617-s-no-gm?authuser=0)
Direct Buffering.
The last option is direct buffering, which is more simple but also less good in terms of options. Here we re-route the "RAW" EDMAC image directly into the save buffers and save them to CF/SD cards. This can also be done in a portable and re-useable way.
BUT we can't control the width and height in a proper portable and re-useable way. We're kinda locked to the width and height that canon chooses.
Pros
- Easy to implement
- Works without finding the EDMAC stubs, good for an early build
Cons
- No width and height control
- You need a fast CF/SD card for shooting continuously
Should this approch go into the code ? .. I have no idea. We will need to get the EDMAC stubs/code running correctly, it's mandatory for a proper build, but until we get there, direct buffering is a cheap way of getting RAW video out of the camera. If saving on both CF+SD is possible in parallel, when even the 3616 x 1348 x 14 bits in zoom mode is possible, but the file sizes will suck.
The experimental 7D2 "hacky" repo with RAW video.
the code was been stored as a single zip file, rather than a git repo and temporary on google drive. Its was messy repo. I have used some time to make it less messy. Take what you need and put it into the repo, don't wait for me to submit it, that will take forever for me, as my time is limited. I will try .. to explain that I have done.
https://drive.google.com/file/d/1GeoqHV1r1D4EOAy702CAhAMYYsnOHZHD/view?usp=drive_link
* addlog
In the code you'll see addlog() .. it's must my own version of a similar DryOsDebugMessage, just regards those.
* vsync hack
vsync_func (state-objects.cpp) is called once per frame in LiveViev. This execute all modules frame syncronization (CBR_VSYNC). The vsync_func is normally called from the LiveHandlerapp handler, but on the 7D2 the stubs has not been found. This one is necessary for all modules that requires a frame syncronization, like mlv_rec and mlv_lite. They way I solved this was by hijacking function located in RAM. I used "olddumpfall","dumpfall" to dump the DryOsDebugMessages to card and analyzed them. Found some functions what there called on a regular basis, one seemed to interrupt functions. To make this work I implemented a thumb-2 BL_INST_T2 which could be used to hijack a BL instruction in thumb-2 mode in RAM and make the code jump somewhere else. It makes the same result as BL_INST but in thumb-2 mode. The max jump is (24 bits?) and the instruction size is 4(!) bytes, really messy instruction and hard to implement). The BL_INST_T2 code is worth getting into the new branch. I then used the BL_INST_T2 to hijack a DryOsDebugMessage and instead called vsync_func() for frame synchronization
1. BL_INST_T2 hijacks a instruction (run_test_2,debug.c) which will call private vsync function in function-override.c
2. private vsync function in is used to compute frametime and then it calls the vsync_function in state_objects.c
3. vsync_function in state_objects.c execute module CBR_VSYNC.
4. fps-engio.c is alo hacked and uses the frametime from function-override.c to return correct value via fps_get_current_x1000()
* raw video (raw.c)
I had to do some hacks in raw.c (CONFIG_7D2) to get everything to work. The raw width and height is decoded from the RAW EDMAC by looking at the EDMAC sizes register. I'm actually using shamem_read() from Omar. The Omar code on this particularly function is position independent and the shamem memory is located inside RAM so reading the EDMAC shamem values works as intended. The border values (black border around RAW image) in raw liveview is hardcoded to 0, so I can do direct buffering. Also I needed to avoid some code (there's a odd return somehwere) that crashed the camera, some additional info that raw.c api provides, but which is strictly not needed.
* mlv Lite (mlv_lite.c)
I'm using a old mlv_lite only supporting 14 bits. The new module was complex so I decided to use the old mlv_lite from the vxworks brach instead. This did not work either so I had to do some hacks were as-well. I could not get CBR_KEYPRESS / raw_rec_keypress_cbr() to start the camera, maybe because some functions returning if the camera is idle or not does not work as intended. raw_rec_keypress_cbr() was changed for the worse. I'm using a run_test_alt() in debug.c to set a flag so I can start recording (start_stop_RAW_recording) when setting this flag and performing HALFSHUTTER_PRESSED then it will start recording.
Direct buffering: Inside mlv_lite.c I force the width,height to be maximum (from value returned via the raw.c api) so I can do direct buffering. That is important because then mlv_lite will allocate buffer images which is equal size to the EDMAC canon raw video buffers. The direct buffering is done in raw_rec_vsync_cbr()/process_frame(). raw_rec_vsync_cbr is called once per frame and changes Canon EDMAC buffer to our own temporary buffer using raw_lv_redirect_edmac(), then -(normally) we would use EDMAC copy in process_frame() to copy the pixels from this buffer into our array of images that will be saved. This is now changed so we skip the EDMAC copy and just change Canon EDMAC buffer into the right image in our save image buffer array. This only works when we use the entire image format. Mlv_lite also has a autocheck (all versions) that the buffer are in fact filled with the RAW image (there a signature check), this still works, so that if you get dropped frames, the recording will stop.
* Changed some code: Somewhere in mlv_lite I also needed to skip/change? some code, AFAIR was due to skipping code in raw.c. ML video needs alot of information like black levels ect, so the MLV header regarding these additional information it not fully correct. Black level is around 2048(?).
* Somehwere along the line: I lost the ability to compile module correctly (module_string.h could not be created), so currently only mlv_lite is enabled and I have a module_string.h from a clean branch included, and when it compiles. If you make a complete clean, the module_string.h will disapeer, compilation will then fails.
And finally .. Start recording on this hacky,wacky bleeding edge build:
1 start the camera
2 enable mlv_lite module
3 reboot the camera
4.Enable RAW recoding in ML, the format is fixed and can't be changed, Enable SRM memory!.
5 Select debug menu -> vsync
6 Go in to LiveView recording mode (not LiveView photo mode)
7 Select debug menu -> start recording
8 Do half shutter press once or twice to start record
To stop recording do 7+8 again. Sometimes when pressing a button it's like ML gets the button command twice, and then it does not work, just exit video recording mode and start from 6.
-R-O-A-D---M-A-P-
I have no roadmap for the 7D2, other that at some point in time, says around April .. but not the 1st ;D we should make a barebone build with RAW video enabled available to everyone.
Thanks so much for all the explanations :) There are some very important points in here that I was missing knowledge of before. Reads like you've been busy.
I agree about BL_INST_T2 being a weird encoding. My version is in boot-d678.c, patch_thumb_branch(): https://github.com/reticulatedpines/magiclantern_simplified/blob/764c54e8d5e1c8182343c2be9452f66708c87214/src/boot-d678.c#L60
It's done as a function, so might be useful for you to adapt. Will need the parts around the reloc buffer offset changing.
For general hook patching I use mov pc, [pc + 4] instead. This means the encoding is fixed, which is nice. It takes more bytes but allows jumping any distance. You need to do fixup in the hook, but you can write it as code, not magic bytes, so it's fairly easy.
https://github.com/reticulatedpines/magiclantern_simplified/blob/764c54e8d5e1c8182343c2be9452f66708c87214/src/patch_mmu.c#L248
Example hook code:
static void __attribute__((noreturn,noinline,naked,aligned(4)))log_CRLE(void)
{
asm(
// push all
"push { r0-r11, lr }\n"
);
// log stuff
uint32_t pResources, resCount, lr;
asm __volatile__ (
"mov %0, r0\n"
"mov %1, r1\n"
"mov %2, lr\n" : "=&r"(pResources), "=&r"(resCount), "=&r"(lr)
);
// adjust stack for task_create(), which spills one arg to stack,
// to avoid stack corruption when we return to CRLE
asm (
"mov r8, sp\n" // store old sp
"sub sp, sp, #4\n" // get space for one arg
);
struct log_args *log_args = malloc(sizeof(struct log_args)); // freed in edmac_logger
log_args->r0 = pResources;
log_args->r1 = resCount;
log_args->lr = lr;
log_args->caller_ID = 1;
task_create("edmac_log", 0x1c, 0x200, edmac_logger, (void *)log_args);
// restore sp
asm (
"mov sp, r8\n"
);
asm(
// pop all
"pop { r0-r11, lr }\n"
// do overwritten instructions
"push {r4,r5,r6,r7,r8,r9,r10,lr}\n"
"mov r8, r0\n"
"ldr r5, =0x10990\n"
// jump back
"ldr pc, =0xe04b3741\n" // NB set Thumb bit appropriately
);
}
I will brave the zip file soon and try to make a sensible series of commits in a branch, so you can approve them later (and re-author them for the credit if you want).
I suspect I've already done similar with 200D, but not using mlv_lite. Much nicer putting it there but was easier hacking it in to test. I was missing the lv_save_raw step - I can capture full sensor, but it's YUV 422 and already resized to 1080. Maybe we can get both cams working at the same time :)
I have called off the assassins, enjoy your giant triangles in peace!
I finally got a little time to test the build with a fast CF card, turned out it was indeed a Sandisk UDMA-7 Extreme card (but limited to 120 MB/s), a little resume form the test (24 and 25 fps)
- No vsync/tearing issues, vsync hijack location is valid :), this was critical
- UDMA-7 card, zoom(x1), 1984x1068x14 bits (active area 1832x1044), direct buffering,limited RAM ~ 250MB, continuously shooting
- UDMA-7 card, zoom(x10), 3616x1348x14 bits (active area 3472x1320), direct buffering,limited RAM ~ 250MB, you get max 24-70 frames
Quote from: names_are_hard on January 19, 2024, 04:25:48 PM
I suspect I've already done similar with 200D, but not using mlv_lite. Much nicer putting it there but was easier hacking it in to test. I was missing the lv_save_raw step - I can capture full sensor, but it's YUV 422 and already resized to 1080. Maybe we can get both cams working at the same time :)
Direct buffering is always possible, even if it's only a temporary solution. The YUV422 (EDMAC) is always available (and it should be possible to re-size it, did that on 40D), but the save requirements is much worse than the raw format.
Have now looked at heder's archive of code. It's a little hard to work with since there are no commits, just changes from the base. But most of the changes are simple I think, I just need to understand it a little better to reduce the noise, and work out a nice sequence to apply them. There are three copies of mlv_lite module :D
I think I will try to get 200D working using a similar approach, and apply that to the modern mlv_lite, then port heder's. That way I'm sure I understand what I'm doing before adapting the 7D2 code.
Heder, re "module_string.h could not be created": this normally means you are missing rst2html. Given that you were using an old version of a module, it's possible you reverted changes I made to make everything python3 compatible. It'll be something in this area, anyway.
Yea, we're abit to early on. I need a little more time to make thing pretty. The quick and dirty port was only to prepare for my next travel. My next task is to complete direct buffering and push it to a repo, so it becomes usefull for all. But I need to understand all the EDMAC offsets first.
Yup, it wasn't intended as criticism, early code is never how you want it to look. I'm happy I can use it to check things and learn new things about mlv_lite.
With call("lv_save_raw"), how are you tracking usage of new channels? On 200d, I don't see this call triggering any new channels to be used (I'm hooking StartEDmac() so I think I should see all new uses). Maybe I should be looking for a change to the size of copy, on an existing in use channel? My basic approach is log all channels that ever go active (but only log the first use), msleep(2500) while I put it in LV, and movie LV, then call("lv_save_raw"). From your description I'm expecting to see a new channel used for the first time (which should show in my logging, while previously used channels would not). Instead, I see nothing.
Hooking only works when the FW calls the StartEDmac function, on many occasion they don't but only EngDrvOut. If you want to see what is happening you'll need to dig deep and find the function that trigger lv_save_raw. All those function call("func") is registered somewhere and each "func" has a function attached to it. But the easyway to find the RAW EDMAC is quite simple. Dump all EDMAC address into a file. To do this, please use shamem_read because it's stores more EDMAC values. If you don't have shamem_read when you can still read the first registers of each EDMAC using the MEM(...) macro were you can access fro 0x0 to 0xC in each EDMAC but using shamem_read you get all. The next code (see below) values is inside Liveview before doing the call("lv_save_raw"), look carefully at 0xD0004200, it's all zeros. This is before I found shamem_read, so I had to use MEM(...) and could only read from 0x0 to 0xC using the MEM(..) macro.
*************************************
Edmac = 0xD0004000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x405A8F40
0xC = 0x0
*************************************
Edmac = 0xD0004200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004300
0x0 = 0x1
0x4 = 0x0
0x8 = 0x126E9E0
0xC = 0x0
*************************************
Edmac = 0xD0004400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x20000000
0xC = 0x0
*************************************
Edmac = 0xD0004600
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004800
0x0 = 0x1
0x4 = 0x0
0x8 = 0x9B2D80
0xC = 0x0
*************************************
Edmac = 0xD0004900
0x0 = 0x1
0x4 = 0x0
0x8 = 0x46DB80
0xC = 0x0
*************************************
Edmac = 0xD0004A00
0x0 = 0x1
0x4 = 0x0
0x8 = 0x9584B8
0xC = 0x0
*************************************
Edmac = 0xD0004B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x16BAEF40
0xC = 0x0
*************************************
Edmac = 0xD0004E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026500
0x0 = 0x8
0x4 = 0x0
0x8 = 0x1617A000
0xC = 0x79
*************************************
Edmac = 0xD0026600
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15D3EBA0
0xC = 0x14
*************************************
Edmac = 0xD0026700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1840715A
0xC = 0x0
*************************************
Edmac = 0xD0026900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026A00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15D38700
0xC = 0x1FEF
*************************************
Edmac = 0xD0026B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15C8D200
0xC = 0x1FC2
*************************************
Edmac = 0xD0026C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x18543000
0xC = 0x0
*************************************
Edmac = 0xD0030100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1A683C00
0xC = 0x0
*************************************
Edmac = 0xD0030200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1A684400
0xC = 0x0
*************************************
Edmac = 0xD0030300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x40ABF4F0
0xC = 0x0
*************************************
Edmac = 0xD0030400
0x0 = 0x8
0x4 = 0x0
0x8 = 0xAA9928
0xC = 0x0
*************************************
Edmac = 0xD0030500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030600
0x0 = 0x1
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x405BFF24
0xC = 0x0
************************************
Edmac = 0xD0030A00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1835FB80
0xC = 0x0
*************************************
Edmac = 0xD0030B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x409EA314
0xC = 0x0
*************************************
Edmac = 0xD0030E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
Then I found shamem_read and also turned on call("lv_save_raw"), when I dumped all EDMAC again and now look at 0xD0004200, now it non-zero and 0xD0004210 = 0x42B0D90, this is the configuration in "EDMAC internals" post that a1ex says describes as "Simplest WxH"
xb * (yb+1) (xb repeated yb times)
0xD0004210 = 0x42B0D90 ==> (0x042B0000 | 0x00000D90)==> Simplest HxW = 1068(H) x 3472(W) ==> 1984(W) x 1068(H) @ 14 bits.
So the RAW EDMAC transfers a bayer image of size 1984(W) x 1068(H) @ 14 bits. This is including black border, to find the borders you'll need to save the RAW image and investigate the raw bytes, or get mlv_lite or similar to save a mlv video with (borders 0,0,0,0) and check the image.
*************************************
Edmac = 0xD0004000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004200
0x0 = 0x2
0x4 = 0x20301008
0x8 = 0x1A67C000
0xC = 0x0
0x10 = 0x42B0D90
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004300
0x0 = 0x4
0x4 = 0x20008000
0x8 = 0x1288800
0xC = 0x0
0x10 = 0x19705A0
0x14 = 0x0
0x18 = 0x20
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004400
0x0 = 0x1
0x4 = 0x60000000
0x8 = 0x3180D00
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004500
0x0 = 0x4
0x4 = 0x20008000
0x8 = 0x1F02E000
0xC = 0x0
0x10 = 0x4370F00
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004600
0x0 = 0x4
0x4 = 0x60000000
0x8 = 0x31EB200
0xC = 0x4A
0x10 = 0x1000
0x14 = 0x1000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004800
0x0 = 0x4
0x4 = 0x0
0x8 = 0xAB32B8
0xC = 0x0
0x10 = 0xDF07D0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x20001000
*************************************
Edmac = 0xD0004900
0x0 = 0x4
0x4 = 0x20001000
0x8 = 0x46D8E8
0xC = 0x0
0x10 = 0xDF07D0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x20001000
*************************************
Edmac = 0xD0004A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0xA5AB88
0xC = 0x0
0x10 = 0x42B0008
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x60000000
*************************************
Edmac = 0xD0004B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004C00
0x0 = 0x4
0x4 = 0x60000000
0x8 = 0x3180D00
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004D00
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x16F3E800
0xC = 0x0
0x10 = 0x3FB0E30
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0xB
0x14 = 0xC0000030
0x18 = 0x1
0x1C = 0x0
0x20 = 0x0
0x24 = 0x33
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026000
0x0 = 0x1
0x4 = 0x60000000
0x8 = 0x32AA400
0xC = 0x12
0x10 = 0xC00
0x14 = 0x1000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026200
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x1A49DBC0
0xC = 0x0
0x10 = 0x160050
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026500
0x0 = 0x2
0x4 = 0x60001008
0x8 = 0x0
0xC = 0x79
0x10 = 0x1EC0
0x14 = 0x8000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026600
0x0 = 0x2
0x4 = 0x60001008
0x8 = 0x0
0xC = 0x39
0x10 = 0x7610
0x14 = 0x8000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026800
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x1A478000
0xC = 0x0
0x10 = 0x11C03B6
0x14 = 0x0
0x18 = 0x14A
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x0
0xC = 0x1FFF
0x10 = 0xFFFE
0x14 = 0xFFFE
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026B00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x0
0xC = 0x1FFF
0x10 = 0xFFFE
0x14 = 0xFFFE
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030000
0x0 = 0x4
0x4 = 0x0
0x8 = 0x1830A800
0xC = 0x0
0x10 = 0x1670500
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030100
0x0 = 0x6
0x4 = 0x300008
0x8 = 0x1A685A00
0xC = 0x0
0x10 = 0xF01E0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030200
0x0 = 0x6
0x4 = 0x40300008
0x8 = 0x1A683E00
0xC = 0x0
0x10 = 0xC0200
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030400
0x0 = 0x6
0x4 = 0x300008
0x8 = 0xBACC80
0xC = 0x0
0x10 = 0x28
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030600
0x0 = 0x4
0x4 = 0x0
0x8 = 0x3397300
0xC = 0x0
0x10 = 0x3B00A0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x183166A6
0xC = 0x0
0x10 = 0x11A03B2
0x14 = 0x0
0x18 = 0x14E
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030B00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x184D2800
0xC = 0x0
0x10 = 0x1DF0500
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
Quote from: heder on January 23, 2024, 06:52:09 AM
Hooking only works when the FW calls the StartEDmac function, on many occasion they don't but only EngDrvOut.
Good to know it wouldn't be foolproof anyway, but there's no EngDrvOut() or shamem_read() on 200D, so I can't hook those. They're inlined on 200D. I've also written a monitor function that polls dma_state fields of all MMIOs, but this is unreliable; I suspect they stay with 1 bit set for too short a window for this approach to work.
Quote
But the easy way to find the RAW EDMAC is quite simple. Dump all EDMAC address into a file.
I've been doing that for weeks, it does not work. Well, I don't dump them to file, I have uart logging so I can see them change in realtime. But I do dump the data content of any EDMAC region that is larger than a configurable size to disk. So far, it's never been Bayer data, only YUV (or weird junk noise, or maybe, I'm not noticing Bayer pattern data).
Quote
Then I found shamem_read and also turned on call("lv_save_raw"), when I dumped all EDMAC again and now look at 0xD0004200
I don't see any change to edmac regions when I enable lv_save_raw.
Quote
So the RAW EDMAC transfers a bayer image of size 1984(W) x 1068(H) @ 14 bits
I've never seen bayer data. I have seen a (1984 * 2) wide region in some tests, but it contains YUV data. I don't see any regions of a different size if I toggle lv_save_raw.
The above hopefully explain why I want to learn if there are any changes due to lv_save_raw that
don't need me to find the image buffer. Does it trigger a new channel to be used? Or a device ID that's previously not been accessed? Creation of a different sized region? Etc. Looking for the Bayer data in buffers does not seem to work on 200D. I have a few ideas on how to possibly catch the data by changing timings on when I sample MMIO data, but low confidence.
Possibly worth noting, I'm not making any attempt to sync with vsync yet. I was assuming this would not be a major problem, I'd see tearing in the image data, but I could fix that later. Would you expect lv_save_raw to still give you bayer data if you weren't running at vsync?
Dont mind vsync, it's not critical for now.
With no EngDrvOut and shamem and inlined code, this is going to be hell. So let do some sane checking..
1. Does "lv_save_raw" exist as a string in ghidra ?. It might also have changed name, like on the 7D2 I cant find any more "fdump" its now called "fdumpall" or "oldfdumpall", search for "save_raw" and investigate those places.
2. All those call("func_name") will be registered somewhere using a registerfunction call, like
registerfunction(pointer to "func_name", function pointer *_func);
The _func will be called when someone perform the call("func_name"). In 7D2 look up the address 0xfe0abde0 here you will see lots of registering
FUN_fe100a6a(s__dumpall_fe0ac0cc + 4,0,s__dumpall_fe0ac0cc._0_4_);
FUN_fe100a6a(s_dumpfall_fe0ac0dc,0,DAT_fe0ac0d8);
FUN_fe100a6a(s_olddumpall_fe0ac0ec,0,DAT_fe0ac0e8);
FUN_fe100a6a(s_olddumpfall_fe0ac0fc,0,DAT_fe0ac0f8);
FUN_fe100a6a(s_grepall_fe0ac10c,0,DAT_fe0ac108);
FUN_fe100a6a(s_dumpentire_fe0ac118,0,DAT_fe0ac114);
FUN_fe100a6a(&DAT_fe0ac128,0,DAT_fe0ac124);
FUN_fe100a6a(s_DisablePowerSave_fe0ab5cc,0,DAT_fe0ac124);
FUN_fe100a6a(s_EnablePowerSave_fe0ab5e0,0,DAT_fe0ac12c);
FUN_fe100a6a(s_SetTuningFlag_fe0ac154,0,DAT_fe0ac150);
...
...
FUN_fe100a6a = register call name .
There's many functions around in the code, even a call("grepall",?) function ???
Quote from: heder on January 23, 2024, 03:15:59 PM
Dont mind vsync, it's not critical for now.
Good to know.
Quote
1. Does "lv_save_raw" exist as a string in ghidra ?. It might also have changed name, like on the 7D2 I cant find any more "fdump" its now called "fdumpall" or "oldfdumpall", search for "save_raw" and investigate those places.
Yes, the same function exists, I've called it. I've had it marked in my 200D project for over a year. It doesn't do what you describe (on this cam). As in my previous post: running call("lv_save_raw") does not trigger any new usage of channels or devices that I can see, and there is no bayer data saved to in-use edmac buffers.
That's why I'm asking questions about how you see edmac usage change when *you* call it. So I can try to find the buffer *without* looking for the bayer data directly, since that doesn't happen here (or, perhaps the buffer is reused quickly and my logging isn't fast enough, etc).
Quote from: names_are_hard on January 23, 2024, 03:33:23 PM
That's why I'm asking questions about how you see edmac usage change when *you* call it. So I can try to find the buffer *without* looking for the bayer data directly, since that doesn't happen here (or, perhaps the buffer is reused quickly and my logging isn't fast enough, etc).
The way I found the RAW EDMAC channel on 40D and 7D2 was starting LiveView and by reading the uint32_t value from all MEM(EDMAC_CHANNEL + 0x10) before and after call("lv_save_raw"). The channel that changed from 0 to something was the RAW EDMAC channel.
Thanks, I haven't monitored that field changing, worth a try. I'm very likely going to refactor the code to stop using those ugly consts for edmac MMIO. The struct looks like this:
413 struct edmac_mmio
414 {
415 uint32_t dma_state;
416 uint32_t dma_flags;
417 uint32_t ram_dst_offset;
418 uint32_t yn_xn;
419 uint32_t yb_xb;
420 uint32_t ya_xa;
421 uint32_t off1b;
422 uint32_t off2b;
423 uint32_t off1a;
424 uint32_t off2a;
425 uint32_t off3;
426 uint32_t unk_01;
427 uint32_t irq_reason;
428 uint32_t irq_related;
429 uint32_t unk_02;
430 uint32_t unk_03;
431 uint32_t fencing_related_maybe;
432 uint32_t unk_04[0x2f]; // padding? Probably some but not all.
433 };
434 SIZE_CHECK_STRUCT(edmac_mmio, 0x100);
You can then cast the MMIO "channel" addresses. Much nicer checking mmio->yb_xb.
I may have found the buffer used by lv_save_raw via static analysis (there's a pointer global, get's populated in LV). I've dumped image data from it and it's clearly real, but I don't understand the format. It might be packed 14-bit bayer, but if so I'm missing some detail required to decode it to a sane image, colours are all wrong.
Could you share a dump of that mem region, for a known good capture?
On R (D8) this evproc sequence saves the raw buffer on card. Format unknown, selected by lv_set_raw_wp. There are 26 formats (?) to choose from, coming from SantaPath or SAP Path. edmac_info source suggests biggest size is 2016x921 (?) which when decoded as YUV produces completely broken image with somehow visible outline of original context.
lv_set_mm 1
lv_set_raw_wp 0
lv_save_raw 1
lv_raw_dump
Reference frame
(https://kitor.pl/eos/r_edmac/test1_reference.jpg)
Source file (buffer dump): https://kitor.pl/eos/r_edmac/test1.raw
Source decoded as YUV
(https://kitor.pl/eos/r_edmac/test1_yuv.th.jpg) (https://kitor.pl/eos/r_edmac/test1_yuv.jpg)
Fixed. I can scrape 14-bit packed raw data. I had some bug in the python I was using to unpack to 16-bit. Still not sure what it is, rewrote it in C.
https://i.imgur.com/LklrBm3.png
I'll now try and get 7D2 and 200D working with modern mlv_lite.
Quote from: kitor on January 23, 2024, 09:46:09 PM
selected by lv_set_raw_wp. There are 26 formats (?) to choose from,
Possibly something related:
https://www.magiclantern.fm/forum/index.php?topic=18393.msg176315#msg176315
I re-encoded the raw 14 bits stream into 16 bits unsigned stream, saved it, and loaded it into gimp. Gimp can load RAW images if they're
encoded correctly (Grey little endian 16 bits).
#include <stdio.h>
#include <stdlib.h>
#include "string.h"
int main(int argc, char *argv[])
{
FILE *f;
unsigned int length;
unsigned short *u16;
unsigned short *bayer;
f = fopen(argv[1],"r");
if (f==NULL || argc != 3)
{
printf("No such file. Input argument is : filename length\n");
return -1;
}
sscanf(argv[2],"%d",&length);
u16 = malloc(2*length);
bayer = malloc(length);
memset(u16,0x0,2*length);
memset(bayer,0x0,length);
fread(bayer,1,length,f);
int k=1,i=0;
for (i=0;i<length;i+=8)
{
u16[i+0] = (bayer[k+0] & 0xFFFC) >> 2;
u16[i+1] = (bayer[k+0] & 0x0003) << 12 | (bayer[k+1] & 0xFFF0) >> 4;
u16[i+2] = (bayer[k+1] & 0x000F) << 10 | (bayer[k+2] & 0xFF00) >> 6;
u16[i+3] = (bayer[k+2] & 0x003F) << 8 | (bayer[k+3] & 0xFC00) >> 8;
u16[i+4] = (bayer[k+3] & 0x00FF) << 6 | (bayer[k+4] & 0xF000) >> 10;
u16[i+5] = (bayer[k+4] & 0x03FF) << 4 | (bayer[k+5] & 0xC000) >> 12;
u16[i+6] = (bayer[k+5] & 0x0FFF) << 2 | (bayer[k+6] & 0x3000) >> 14;
u16[i+7] = (bayer[k+6] & 0x3FFF) << 0;
k+= 7;
}
FILE *fout = fopen("output.data","w+");
fwrite(u16,1,i*2,fout);
fclose(fout);
return 0;
}
I used this on a RAW dump from sensor https://drive.google.com/file/d/1mhUpk9ju65U3oGHgyxbSqMW4hUfXCdx4/view?usp=sharing and got
(https://lh3.googleusercontent.com/pw/ABLVV84CoCXU_8bWuKBBXYw1wnCyDxRt_BuRIn3IgcM_gJBE1_4vLHhtEpuM0MWlCnZRgtZUJcoGv-V3wr-d9C1TVxje6khx5GiBfNnJ3Krq3wsVJ5U41pUlqYiE40csoiPaWpIG3yfUPwLlMyh08gWdsDqF=w1984-h824-s-no-gm)
Yup, @names_are_hard wrote unpacking again in C... and it works, both for 200D and R.
R turned out to be 2304x922 (including black borders), 2257x900 when cut. So many bad pixels ::)
There is a slight glitch in upper part. All pixels shifted 1-2 pixels sideways. Normal?
EDIT: 1 glitch > 2 pixel. Below at least 2 other glitches.
Probably not important - I suspect heder did what I did for this first test: handheld it and dumped data direct to disk with FIO_WriteFile(). Mine all look the same, it's not fast enough to avoid tearing. Heder's real code uses a faster method, I assume no problem there.
Cleanly adapting modern cams to the existing code will require significant changes.
An example from edmac.c (there are many examples I could use!):
119 uint32_t edmac_get_base(uint32_t channel)
120 {
121 if (channel >= NUM_EDMAC_CHANNELS)
122 {
123 return -1;
124 }
125
126 uint32_t bases[] = { 0xC0F04000, 0xC0F26000, 0xC0F30000 };
127 uint32_t edmac_block = channel >> 4;
128 uint32_t edmac_num = channel & 0x0F;
129
130 return bases[edmac_block] + (edmac_num << 8);
131 }
132
133 static uint32_t edmac_get_block(uint32_t reg)
134 {
135 switch (reg & 0xFFFFF000)
136 {
137 case 0xC0F04000: return 0;
138 case 0xC0F26000: return 1;
139 case 0xC0F30000: return 2;
140 default: return 0xFFFFFFFF;
141 }
142 }
This hardcodes the same magic addresses twice, in different places. The addresses don't hold for new cams. And new cams use 4 regions, not 3. Edmac code doesn't use structs, but uses raw offsets to base addresses, with no explanations. It's really ugly code, with no docs or explanations in the code (some on the wiki).
Changing the old code needs to be done carefully, or it will fail on old cams. Changing the old code must be done, or it can't work on new cams.
I could hack in a quick version for 200d (or 7d2), but I'd greatly prefer taking the time to fix things so any cam can use the same code, probably with some new platform/XXD constants defined.
And btw, DIGIC 8 EDMAC MMIO registers doesn't match old ones at all (offsets, number of registers used for various stuff). That was expected after we found it uses extra dimension... but even if we understand the new controller, integrating that without structures would be a total mess.
Btw, @names_hare_hard I think we should probably pull this recent discussion into a separate thread.
_engio_write() is probably at 13ea0. Untested. Testing it is potentially risky, I assume you already know that, heder :)
Yes, and it's to pretty important for FPS engio override. It's lucky for us that ICU/Marius seems to set the FPS registers via this function and even more luck, it's located in RAM so we even can hijack it (if needed). We'll properly need to log the FPS registers values (0xD0006008. 0xD0006014) for the different canon fps to find the pixel clock needed in fps-engio.c, either via the canon log (it call DryOsDebugMessage) or via hijacking.
Brief update.
Sorry too little time for discord :(
I'm cleaning the old hack repo and making a new clean one. Updating to the newest mlv_lite and creating a version with direct buffering so all can use this if they need it. Also inforcing that both ICU(Marius) and Omar cores uses shamem, should make fps override easy to use. Next milestone will be around 7th of Marts. The biggest issue atm is missing edmac api, as all the functions are located on Omar, but I know for a fact that ICU(Marius) does use edmac channels (firmware string "mossy") so it's possible to use edmac from ICU(Marius). Also I will look into card spamming on mlv_lite as this could enable 3k@14bit recording ~ 195 MiB/s ..
* clean repo
* fix start/stop record activation issues
* Enforce Marius to use shamem
* Enable fps override
* Investigate card spanning on mlv_rec
* Investigate how allocate more memory
You can check card spanning implementation on mlv_lite here. @Ilia3101 effort.
https://bitbucket.org/Dannephoto/magic-lantern_dannephoto_git/src/master/
https://bitbucket.org/Dannephoto/magic-lantern_dannephoto_git/src/master/modules/mlv_lite/mlv_lite.c
Quote from: heder on February 02, 2024, 09:53:35 AM
Also I will look into card spamming on mlv_lite as this could enable 3k@14bit recording ~ 195 MiB/s ..
This commit (https://github.com/bilalfakhouri/magiclantern_hg_02/commit/e5cb69ecaffbd857fae375c9b2c490e8d4c15c12) adds card spanning support for mlv_lite might help you too.
Quote from: heder on February 02, 2024, 09:53:35 AM
I'm cleaning the old hack repo and making a new clean one. Updating to the newest mlv_lite and creating a version with direct buffering so all can use this if they need it. Also inforcing that both ICU(Marius) and Omar cores uses shamem, should make fps override easy to use. Next milestone will be around 7th of Marts. The biggest issue atm is missing edmac api, as all the functions are located on Omar, but I know for a fact that ICU(Marius) does use edmac channels (firmware string "mossy") so it's possible to use edmac from ICU(Marius). Also I will look into card spamming on mlv_lite as this could enable 3k@14bit recording ~ 195 MiB/s ..
Progress sounds good!
I have 200D working with modern mlv_lite, with normal buffering. So you may want to do that part last, as I am still intending to port your 7D2 code in a similar way. When I have 200D working cleanly with nice code, porting 7D2 should be easy enough. Unfortunately, I still have some last problem to work out; the video data captured from 200D is scrambled when mlv_lite is used. I think perhaps some bad offset or width calculation - if I manually capture the buffer the data is correct. There are lots of hard-coded constants, it's been quite tedious to debug things :(
I'm not forcing you to use discord but it would make things easier to coordinate :P You don't have to install anything, it works from a browser.
Quote from: Danne on February 02, 2024, 11:42:34 PM
You can check card spanning implementation on mlv_lite here. @Ilia3101 effort.
https://bitbucket.org/Dannephoto/magic-lantern_dannephoto_git/src/master/
https://bitbucket.org/Dannephoto/magic-lantern_dannephoto_git/src/master/modules/mlv_lite/mlv_lite.c
Quote from: theBilalFakhouri on February 03, 2024, 03:31:09 AM
This commit (https://github.com/bilalfakhouri/magiclantern_hg_02/commit/e5cb69ecaffbd857fae375c9b2c490e8d4c15c12) adds card spanning support for mlv_lite might help you too.
Thats awesome!, that feature is absolutely fantastic, one less problem to deal with.
Quote from: names_are_hard on February 03, 2024, 03:00:31 PM
Unfortunately, I still have some last problem to work out; the video data captured from 200D is scrambled when mlv_lite is used. I think perhaps some bad offset or width calculation - if I manually capture the buffer the data is correct. There are lots of hard-coded constants, it's been quite tedious to debug things :(
One scenario is that the timing is wrong, i.e. the module_cbr syncronization call that ends up in mlv_lite:process_frame() needs to be correct, otherwise the frame will be "data noise". on 7D2 I had to guess and hijack different function before I got lucky.
It's a code problem in mlv, not sure where yet. It's producing an output file that claims to be 1920 * 1080, but contains data that is 2096 * 1164 (the correct size of the image). mlvdump, and mlvapp, seem to be trusting the 1920 * 1080 fields, but filling the display from the 2096 wide data, so everything is the wrong colours and skewed. I can see both values inside the file:
(https://i.imgur.com/XR89GXZ.png)
https://i.imgur.com/XR89GXZ.png
Time to learn mlv format and fix the code I guess.
Quote from: names_are_hard on February 04, 2024, 03:29:57 PM
It's a code problem in mlv, not sure where yet. It's producing an output file that claims to be 1920 * 1080, but contains data that is 2096 * 1164 (the correct size of the image). mlvdump, and mlvapp, seem to be trusting the 1920 * 1080 fields, but filling the display from the 2096 wide data, so everything is the wrong colours and skewed. I can see both values inside the file:
(https://i.imgur.com/XR89GXZ.png)
https://i.imgur.com/XR89GXZ.png
Time to learn mlv format and fix the code I guess.
Did you set the correct black borders values in raw.c ?
/**
* The RAW file has unused areas, usually black; we need to skip them.
*
* To find the skip values, start with 0,
* load the RAW in your favorite photo editor (e.g. ufraw+gimp),
* then find the usable area, read the coords and plug the skip values here.
*
* Try to use even offsets only, otherwise the colors will be screwed up.
*/
#ifdef CONFIG_5D2
skip_top = zoom ? 52 : 18;
skip_left = 160;
#endif
#ifdef CONFIG_5D3
skip_top = zoom ? 60 : mv720 ? 20 : 28;
skip_left = 146;
skip_right = 2;
#endif
#ifdef CONFIG_6D
/* same skip offsets in 1080p and 720p; top/left bar is the same in x5 zoom as well */
skip_top = 28;
skip_left = 80;
skip_right = zoom ? 0 : 10;
#endif
#ifdef CONFIG_500D
// FIXME: are these values correct for 1080p or 720p? (which of them?)
skip_top = 24;
skip_left = zoom ? 64 : 74;
#endif
#if defined(CONFIG_550D) || defined(CONFIG_600D)
// FIXME: are these values correct for 720p and crop modes?
skip_top = 26;
skip_left = zoom ? 0 : 152;
skip_right = zoom ? 0 : 2;
#endif
#ifdef CONFIG_1100D
skip_top = 16;
skip_left = zoom ? 72 : 68;
#endif
#ifdef CONFIG_60D
skip_top = 26;
skip_left = zoom ? 0 : mv640crop ? 150 : 152;
skip_right = zoom ? 0 : mv640crop ? 0 : 2;
#endif
#ifdef CONFIG_50D
skip_top = 26;
skip_left = zoom ? 64: 74;
skip_right = 0;
#endif
#if defined(CONFIG_EOSM) || defined(CONFIG_700D) || defined(CONFIG_650D) || defined(CONFIG_100D)
skip_top = 28;
skip_left = 72;
skip_right = 0;
#ifdef CONFIG_100D
/* 720p: H=727-1, last valid line at y=723, 2 white lines at bottom */
/* VRAM dumps, please: http://www.magiclantern.fm/forum/index.php?topic=12375.0 */
skip_bottom = zoom ? 0 : mv1080crop ? 0 : mv720 ? 2 : 0;
#else
/* 720p: H=726+1, last valid line at y=723, 3 white lines at bottom */
/* 1080p: H=1189+1, 2 white lines at bottom */
/* x5 zoom: H=1107+1, no bad lines at bottom; 1108-28=1080 */
/* 1080 crop: H=1059+1, no bad lines at bottom */
skip_bottom = zoom ? 0 : mv1080crop ? 0 : mv720 ? 3 : 2;
#endif
#endif
#ifdef CONFIG_7D
// FIXME: are these values correct for 720p and crop modes?
skip_top = 26;
skip_left = zoom ? 0 : 256;
#endif
#if defined(CONFIG_70D)
skip_top = 28;
skip_left = 144; // 146 could work, too
skip_right = zoom ? 0 : 8;
#endif
#ifdef CONFIG_7D2
skip_top = 0;
skip_left = 0;
skip_left = 0;
skip_right = 0;
#endif
Nope, because I had no idea I should look there. This code is really poorly organised. There's different sensor size values in at least three different files, and they all interact. Feels like a simpler system must be possible. Why are some per cam values in platform/XXD, where you can find them, some are in src/random_file.c, where you can't, and some are in modules/random/random.c? Ugh.
Thank you for coming back and teaching me this impossible ancient knowledge :)
The per cam stuff in raw.c should probably be moved into platform, right?
Quote from: names_are_hard on February 04, 2024, 11:44:39 PM
Nope, because I had no idea I should look there. This code is really poorly organised. There's different sensor size values in at least three different files, and they all interact. Feels like a simpler system must be possible. Why are some per cam values in platform/XXD, where you can find them, some are in src/random_file.c, where you can't, and some are in modules/random/random.c? Ugh.
Thank you for coming back and teaching me this impossible ancient knowledge :)
The per cam stuff in raw.c should probably be moved into platform, right?
It's kind of patching on patches, but no one took the time to fix it completely. The ML group was also very much result oriented, which is why we got result so fast (end users never really give us credit for good programming), but there is also a price to pay for that. Alex did a great work, but even he could no do everything. And yes specific camera defines should go in platform/XXD.
200D raw video now works, using normal mlv_lite code. You might find my changes helpful for some parts, on this branch: https://github.com/reticulatedpines/magiclantern_simplified/tree/200d_raw_draft
I'm expecting to change that branch before merging to dev, but not very much.
I can spend some more time on 7D2 if there are things I could do that would help? I don't want to waste either of our time by duplicating work.
I've looked a little for EDMAC related stuff and it all seems to use RPC.
fe154724 is a function doing EDMAC stuff with Mossy, but very probably using RPC to do it.
fe255db8 might be CreateResLockEntry_RPC(int *, uint). If so, d2000004 might be MMIO related to triggering the RPC.
I have however found something quite interesting and perhaps very useful. I avoided the need to do a full edmac transfer on 200D because there's a convenience function that does a mem to mem copy using edmac region structs. This is called in two places, some test code, and Vfx code.
Take a look at fe24ee8c - this function is Vfx related and has lots of mem to mem strings. And it ends with a call to send_msg_to_Omar(). This might well be setting up for a copy that it's instructing Omar to run via edmac. There are related functions around init and terminate Mem2Mem. These also exist on 200D - but without RPC. Since this is probably easier to understand than full edmac, and we only need mem to mem copies for raw video, getting this function working for us is something to consider.
That is indeed interesting what you what you have found, keep digging. I only had a few minutes this morning to look and now in sitting in Copenhagen Airport waiting for next plane to Cairo. I wont have any time the next week, but i will be shooting some RAW video. After our trip I will continue and finalize the cleanup of my build also Ill convert some of the RAW footage and upload it to YouTube.
tiny status update ..
I have been programming in few weeks only with little progress. I was trying to get FPS override to run on the 7D2 but found it was pretty different from the other camera (due to multiple core,ICU,Omar) so I ended up hijacking the Marius/ICU engio_write function in such a way that it would play nice with fps-engio.c. That only worked somewhat and after crashing my camera too many times, I got bored and left the project for a week. On most occuations video stream would freezes and very seldom the camera would reboot, making the system useless. Today I finally found a solution :) : ONLY when enabling FPS override in Canons 60 fps mode and using "Exact FPS mode" then everything works a like a charm, so for now fps override will be limited to 60 fps using "Exact FPS mode".
The last thing I need atm is getting the record button to play nicely with MLV, and when I can push the repo to public domain.
Progress does not happen at a steady speed :)
I'm still documenting DMA and EDMAC stuff, got distracted by not having working tools for benchmarks.
I know you got DMA working directly, but did you ever have dma_memcpy() work on 7D2? Or related functions, there's an async one for example.