Rather than fill up email inboxs with unintelligible mush, I now have a 'wiki' for my 5d Mk II analysis!
AJ History
Joined ML team [2010_03_08]. Asked canon for uncompressed HDMI output option rather than than save to CF [2010_03_07]. Canon reponded with 'No Future Plans' [2010_03_20]
Got 2.0.4 ROM dumps from 5D mk II [2010_03_20]. Imported ROMs into IDA (industry leading disassembler by HexRays) [2010_03_20]
Found a memcpy routine in ASM (ARM assembler) that TH (Trammell) had already found. [2010_03_27] Reason: I'm a newbie! And my IDA setup still has Data and Code wrongly setup.
TH shares his 'idc' file that can be used to apply his IDA settings to your ROM dump. [2010_04_17] http://groups.google.co.uk/group/ml-devel/browse_thread/thread/5972db41f16b8a62?hl=en <tip> by commented out the detructive lines of an IDC file - you can run THs first, then yours (or visaversa) - ie and not throw away any analyis you've already done.
Checked all memory in IDA between FF800000->FFC40000 and FFFE0000->FFFFFFFF by hand looking for undefined data with 4th bytes like E1,E3,E5,E9, and forcing IDA to 'C'onvert into code. [2010_05_05]
AI (Arm.Indy) recommends http://www.idabook.com/ as an excellent book to further IDA expertise. [2010_05_08]
AJ (that me) send out garish Excel looking at 'engio' (Digic engine) routines called to setup the Digic. Lots of numbers and not meaning! [2010_05_11]
List of 48 engio routines, is actually groups 16 consecutive routines called for x1, x5, or x10 zooming respectively. [2010_05_26]
Pel thinks hes found a Mod Div function called all over the place. 0xFFC47924 PEL_DivideR0byR1() [2010_06_05] Return_R0=R0/R1 (R0 div R1), Return_R1=remainder (R0 mod R1).
Canon have released 2.0.7 - but I intend to keep eating away at 2.0.4!
[Started 2010_06_15] http://magiclantern.wikia.com/wiki/2.0.4_Engio_write AJ_engio_write() works on lists of [Addr, val], writing the 'val' into the 'addr'. This is used to communication with the DIGIC. (see example box above). Collating my informaiton in Excel or powerpoint is not ideal (even if it was colourful). Decided to try and working directly with IDA - which really means defining more routines first. <2.0.4 total_subs>=19,163 <AI_subs>=42 <PEL_subs>=1 <TH_subs>=NotSureYet! <AJ_subs>=7,006 [2010_07_24]
PC crashing every 2hrs -> every hour -> finally given up on it. IDA now up and running: Parallels 5 + XP Sp3 running on Octocore SL. Parallels is only £50! Amazing. [2010_06_19]
[this will be deleted at some point ->] Had a go with the 5D + GlideCam HD2000 + Adapter + SteadyCam vest for a few hours! Its fab:) Pic of adapter top right of this Wiki Page! [2010_06_26]
Listed all the StateObjects. Named all the routines that all the State objects call (for fun obviously). [2010_06_30] updated with MaxTransitions from CHDK [2010_07_23]
Wrote some code to find the picture data in memory ... found 21 segments that are updated (DMA) in real time.[Edit: Half of these were the DMA=Uncached version of the Non-DMA segments)
Rather than 'hack' the Zoom function in the dryos .. thought I'd have a go at writing my own - with the main purpose to be able to assist in focusing (as the screen resolution drops to 480p).
First attempt at a real time Zoom function (using pure luma) was disappointing as the LCD overlay has far fewer colours than the Vram. The basic issue is that it is not easier to focus if you have less colour information - even if slightly magnified.
There are 256 palette entries for the LCD overlay, described in terms of Y U V and Transparency.
Decoded dispcheck() (a DryOs function that converts the LCD overlay into RGB, then stores as a bmp with embedded lookup table). Found that the formula used for YUV -> RGB is (within 0.1%) the one at http://softpixel.com/~cwright/programming/colorspace/yuv/
Lookup table is currently using 7 bits Y, 4 bits U, 4 bits V. [2012_12_12] Here's a quick video of the palettizing (sp?) experiment of Vram -> Overlay http://www.youtube.com/watch?v=kMMWeouFqsA
Tested one of Alex's many tools to Sync IDC's. Thanks (& Indy too); I now have another 4% named!
Finally decided how I want the Real-time 5D2 magnification interface to work. Before I can write the high level 'C' code interface - I need to compile and test the optimised Zedbra Assebmler code (It does Zedbra over and uner exposure, Edge detection, Focus accumlation, YUV transform of Vram for magnified overlay, minimises Vram access, and empowers the caller with the ability to 'Draw' around objects on the screen). [25th Dec 2010]
Lots of heartache tried to get around a GCC bug. Upgrading to gcc 4.4.2 didn't fix the GCC bug. Lots of trial an error. If you call your C subroutine in a completely separate module then the inline assemby will compile .. and let you use ASM labels without telling you that you have a duplicate symbol. Sheesh.
I couldn't find an easy way of storing R13 in a .word .. and so I've creating some self-modifying code.
So. 1.5 days to write 600 lines of the assembler code. 4.5 days working out how to get GCC to compile it. The problem is that there is No good examples out there. And the ones out there are for people how want GCC to interfere with your ASM code.
[26th Dec 2010] Code compiles! Now it's time check that GCC hasn't 'played' with ASM (in IDA) then actually test it! (I'm expecting quite a few errors!).
For those of you wondering what was happening for the magification .... I was hoping that people who actually use the 5D to record films (and know the pitfalls of 5D focusing) would have suggested a great interface! 2 weeks on ... no suggestions - So I am going to design one myself :D
Quick summary of ASM issues so far: 1) Don't use R13 as DryOs interrupts expect to be valid (bad code on their part!).
First thoughts on Zebo (Zebra + magnified Overlay) GUI: Magnify button (left) : Cycle through size of Overlay: 1=Small, 2=Large, 3=Full Screen Magnify button (right): Zebo 'Off' & Clear screen.
Two ASM thoughts. 1) I've just changed my asm clobber lists in which the r0,r1,r2,r3 are modified by my asm to include: : // Output operands eg. [output1]"+r"(g_r13_temp_store) : // Input operands eg. [input]"m"(parm1) : "r0","r1","r2","r3" // eg "memory","cc" = Clobber list Even though they are parameters, Gcc may decide its more efficient to reuse the registers in the routine that call you (it). Can't do any harm. 2) I've have some rather stange behaviour in my code when converting the current position of the Rectangle into coordinates (starting point of the focus window). What happened is that the position of the DryOs rectangle 'jumped' back (just like the black cat in the Matrix). This stinks of the Rectangle data being in cachable memory, but updated by DMA? (ie I read it, which puts it in cache, then at some point the cache is emptied, and my stale version is written back to memory.) Not entirely sure at the moment...
ASM: No strange freezes since I've made the above changes.
Added Vector Cropmarks [2011_01_03] Enhanced Full screen mode to be more full screen (elliptical rather than round) Added ASM error checks in 'spare NOP' cycles to ensure parms passed are 'sensible'.
DMA issue: I am not entire sure it is a DMA issue. I tried 50 consecutive NOPs .. and it still froze (and that was asm volatile NOPs (so the GCC shouldn't optimise them out). No joy. However .. this piece of code brings 'balance to the force': char crap[]=""; bmp_printf(FONT_MED,260,456,crap);[Edit: When I deactivated ML Zebra task these problems vanished and have not returned]
After the forum discussions ... I have started working on incorporating Histogram. It quite an involved piece of C code that I need to rework, and I will be coding specific ARM routines for Pure_Histogram and Histogram_and_Zebra. Once tested - I will move onto design of Histogram Icon. My first thoughts are to use a 'Colouring' system that looks like the False Colour from Marshal.
Compiles warning with 'Create Task' ... due to the tasks being descibed as (void *). I haven't analysed what is correct, but note that most of the ML tasks have entry points with **_task(void); Based on this, I've altered the protype. (my code works).
Started interferfacing with ML menus. I don't intend to stored anything in config until I am happy the design meets it needs. I have also resorted to stealing info from the properties in Zebras' (usijng global variables) as someone mentioned that DryOs doesn't like too many new tasks or properties being added.
Activated the existing ML audio metres at the top of the screen to see how big they are. The system refresh speed plummeted. I'll come back to this after the Histogram code is working.
[2011_01_09] Linear Histogram changes sooo quickly and is so skewed - I couldn't see how people would usefully read it. I had a brainwave on implementing a very efficient logarithmic coverter to compress the range. Much happier with the look.
Horizontal Histogram: The main reason that I coded horizontally was because its 4 times more efficient. I have just throught of a way of doing it vertically and still being efficient. Its a bit more involved and involves (just reread .. no ... not a tautology) processing the colour of 4 pixels of the time and 'playing with it'. The onscreen display is disconnected from the the way the data is stored - so this can be addressed later on if you can't get to crips with the 'rainbow' of colours - horizontal histogram that I've thrown together!
[2011_01_10] Existing ML menu had fixed size, and not enough space for all the options. Hacked menu.c to introduce the ability for my menus to indicate how much space they actually needed (so not I have a mixure of font sizes / can pack more in. (NB .. maybe the exsiting menus could return this rather than 'void').
Introduced 4 dummy Vector Cropmarks. Had a look how Canon stretches the cropmarks in Std def, HDMI (normal), HD-HDMI (in live-view). Thought I catered for these.. and then found out that there is Yet another mode ... HD-HDMI when recording (I think the screen is stretched differently). My HDMI is connected + looking at vram resolution (to see if its in HD) is not enough to distinguish this extra option. The first cases I have coded code .. which means it would be straightforward to add another switch for the HD_HDMI case when recording in STD def. (not top of my list at the moment).
As the weekend rapidally aproaches .. I've started winding down on the AJ tab menu - as I'm going to need the entire weekend to sort out the Histogram & Zebra assembler routine (it's got bug somewhere .. It might be faster to rewrite this specific routine from scratch that debug the current one ... we will see).
Just thought of an acceptable way to sort out Cropmark setup ... Enter the 'Cropmark Override' functionality. I'll just squeeze this in before working on the Assembler. This may be unwise .. as I'm working my way through some cachasa that's turned up from Brazil....
[2011_01_14] 5 hrs later .... I think cropmarks the Cropmarks GUI works nicely now. I'll save the magic.cfg persisting for a rainy day.
[2011_01_15] Fixed the 'Screen corruption' when Play was pressed. I think was due to the earlier (eroneous) caching of vram. This is important .. as (I think) it means that the address of the hd_vram bank is static - and can be moved to the stubs file.
[2011_01_15] Looked outside ... it was raining (suprise surprise .. this is the UK!). (here's a 'shaky' vid - no persistence to ML config - just a demo of the GUI) http://www.youtube.com/watch?v=__xHleg7oiY
[2011_01_15] Frame rate of Histo is not high enough. Writing another version (user selectable) that can average 2 pixels to see how performance changes. (False colour routines won't be modified - so will keep to the per pixel histogram calculation)
[2011_01_15] Finished writing this ... but now thinking... if you average the pixels .. you are More likely to average a Under & Overexposed pair of pixels to be in the 'mid level'. Duh .. ok .. last time lucky, I am only going to process the 1st of each vram pixel pair for Histogram (when 'fast histogram' is selected!)
[2011_01_15] OK. Done to death. I'll leave the per pixel and average version (of Histogram calc) in the code - and if people want the slow version (like the turning 'Turbo' off on the old Amstrads) - they can use. Frame rate now is still > 15fps. Maybe a little faster. Still quite usable.
Next up its Audio Meters. Hmmm been working 12 hours flat out so far.... might need to go and track down the kitchen!
Just out of curiosity - I deactivated the 'Zebra.c' task to see what happens. Answer: The sensor cleaning message didn't go away at startup. I've added the line of code call( "FA_StartLiveView" ) to my startup task - and commented out zebra.c. All the properties are still active - and the old Zebra.c task can of course be enabled again.
Just disabled the audio_meter task. Reason (1): This wakes up, writes on the screen an goes to sleep. The AJ task also updates the screen - and so the ownership of update has moved. (its calls the same ML code that the old task ran). Reason (2): I read (I think from Alex) that there is an issues with too many tasks.
[2011_01_15] Interesting. I am not able to remove the 'Crap' hacks with the camera freezing. Also ... the camera doesn't freeze up when loading ML during bootup any more. This may just a happy coincidence (I am not convinced ... I think there is another reason!).
The ML audio meters .. are a little bit stubborn .. I'm sure my routines would be as stubborn if you tried to integrate them into your code!
[2011_01_16] Decided to pull the db structure from the Dryos and keep it in the C code (just in case Canon relocate theirs / alter it). Rewrote the audio meters using unsigned arithmetic for db. Meters now scale, or in my case 'shrink'. Relocated them to the bottom of the screen. Added some colour tint to the end of the scale. Distinguished the two 'dark blue' colours. Given user the option to have the current audio level displayed / not displayed (I've left the clash between the level and meters in there for posterity ... and because I am not sure it is needed)
[2011_01_17] With Everything switched on ... manged to get the Camea to overheat (after about 40min?). ML tasks run at lowest priority (31). Introduced two levels of scaled back performance ultimately reducing frame rate to around 3 frames / sec to avoid a meltdown.
Enhanced Focus Overlay icon to be more visible, and also to include visual feedback on temperature of CMOS. (starts by changing background colour, as things 'hot up' - also adds in numberical display so you to see how its coping).
[2011_01_17] Working on Battery Power level. Icon optional and so the rest of the icons scale to use the space (if not in use).
Found the Battery 'Juice' indicator burried in a Property.
[2011_01_19] Didn't think the font was legible enough. Started writing an anti-aliaisng routine. Stopped. Started searching for the Canon fonts hidden in memory. Stopped (they're not good enough). Was going to use the ML orignal HUGE font. Stopped. Hacked the ML routine to allow me to Override it (very very sorry, dirty hack). Done. Very happy with results.
[2011_01_20] Used Phillip Bloom interview to colour ISO and Shutter if you've selected the low-noise / good for 24p movies settings.
I think I've got 3 Must-Do activities left: 1) Persisting of data into ML config file 2) Work out how to distribute Alpha versions, and give the source code to ML (ahhh ... you get to see just how bad a coder I really am ;-)
And some back burner items: +) The drawing of the Histograms and Audio meters use of lot of CPU power (ie more heat) because I have haven't 'accelerated them to use a bespoke assembler routine to draw horizonal lines (would also increase frame rate too. I'll keep this on the back burner for now). +) The histogram icon in scaled in real time ... I'll accelerate this code for its current height (faster, less CPU power, less heat). +) Have a look at Alex's amazing work ... i'm intersted in the 'Power Save' ... not sure what they've done, but if ML can be prevented from killing your battery ... I'm interested.
[Alex] AJ, "Powersave: OFF" only prevents the camera from shutting down. [AJ] Thanks Alex. A better way of putting this was that you guys a fixing loads-of-stuff that I haven't had the chance to even read the emails that describe what your up to, let alone read / apply / test the patches :D
+) Clean exit of AJ task (I don't catch the shutdown sequence) +) Maybe replace of my hardcoded examination of memory for Canon Properties +) Maybe add in the loading of Bitmap that the screen could be cleared with (only of use Outide the Vector Cropmark region) +) Zebras don't work properly in HD_HDMI in LiveView (not when recording). I am less in inclined to look into this at the moment (its not too difficult to do .. but I don't have a HD_HDMI monitor to play with)
On second thoughts ... I thnk you've waited long enough to get your mits on it (actually, I think the best time to release Alpha code is when the configuration cannot be saved. Less chance of it causing issues with your current config file).
[2011_01_22] Thanks to Chris,Moira,JaKob for doing Alpha testing. I'm working my way through the list of issues.
[2011_01_23] Woke up with an inspiration .. ALL PROPERTY VARIABLES MUST BE SET AS 'VOLATILE'. Had a quick look at ML code ... a number of variables are not. This also included the Battery report variable that I was using that didn't look like it was updating. This will need to be fixed by the 550D gang too if they have not already done this.
[2011_02_01] Added a Quick Menu (rotate the ring of icons, select the one you want) Also added a Green Screen function which should allow a quick way of getting luma consistent.
[2011_02_03] Started writing a 'Hunt' for the HD Vram segments program> First guess: There are 3 banks of HD Vram segments on the 5D, only two (main + shadow) are in use. They are located at [Bank1=0x44000080], [Bank2=0x4C000080], [Bank3=0x50000080] Initially Bank1 & 2 are in use. When you play a record movie (ie Canon Play button used), this moves the active banks to Bank 1 & 3, or Bank 2 & 3.
By changing the HD_Vram location on the fly - I was able to reproduce what Chris was seeing (wavy lines).
Found and named the following variable: aAJ_0x44FC_LiveView_struct_0xC0_guess_HD_vram_base -> Fixed the magic Circles issue
Added inner cropmark storage to CF
Removed ML menus & AJ menus -> replaced with a new 'look-a-like' canon menu system, with on-screen help (so you don't have to read the manuals!) [2011_03_17]
[2011_03_27] Completely re-ordered startup that should (fingers crossed) fix the Startup corruptions issues!
[2011_04_07] I have found what seems to be a stable startup. I haven't managed to crack how to list Canon 'Properties' yet, but am able to track when they are changed .. and so if I watch Everything I can work out it current state (this is not an ideal solution!).
[2011_04_09] I've got a DP6. Wow .. what a difference to the LCD screen. It looks gorgeous. Three tasks to sort out -> i) How to get Startup to work consistently with a monitor connected ii) To be able to dump Properties at will (the current call to do this, involves semaphores .. and never returns.. so I need to understand how they work under the covers). Maybe you can only call this from within a property? Maybe the DryOs routine isn't working? Maybe I need to make sure a semaphore is created first? iii) For now I have a 'sledghammer' that monitors 4000 property changes. Once I have a consistent monitor startup -> I'll rip this out. iv) There may be other 'things' that need to be fixed to map to the screen.
[2011_04_16] Still trying different startups. There is something about ML props that the GUI task is very scared of. AJ Prop slave has no problems.
Magic startup Recipe[2011_04_17]
Here is todays Startup recipe:
+) Call dryOs 'init_task()' to kick of the Canon initialisation
+) 10 Hz (info task) is started {will be utilmately be removed}
+) DryOs starts the SoundDev task
-> which starts TH's ML SoundDev task
-> Task waits until AJ_task has finished initialisation
+) DryOs starts the GUI task -> which starts AJ modified GUI task
GUI task -> Creates 'Startup PROP slave' to control startup
GUI task -> Calls DryOs gui_init_end()
+) PROP_SHOOTBLACK: is triggered
-> AJ_task is started (waits for LiveView to be entered)
-> ML PROPs are all initialised (some wait for AJ task to be initialised)
+) PROP_TFT_STATUS: p[0]=0x0 -> Screen or Monitor is active
-> AJ SPLASH SCREEN displayed
NB: In Autoboot, this is not always 'fired' .. and so the SPLASH screen
will actually happen when in Liveview. (which avoid DryOs unpleasantness)
Ex: Set Autoboot -> Switch off (leave battery in) -> Remove CF ->
-> Put CF back in -> power on -> Screen blank until LiveView entered!
-----------------------------
USER PRESSES LIVEVIEW BUTTON
-----------------------------
+) AJ TASK WAKES UP and starts initialising:
-> creates task to create Magic Circle lookup array (takes 3 sec)
-> Reads the ML config (This may move back to before liveview)
-> Disables Canon Powersave (not sure if this works?)
-> Startup all the Other ML tasks
-> Marks AJ initialisation as complete
+) my_sounddev_task() -> allowed to continue configuring the AUDIO IC chip
[2011_05_15] Working on CBR and VBR for AJ5.6 -> Done
[2011_06] AJ 5.7 Couple of Bug fixes
[2011_06_14] Cleaned out some of the hardcoding -> Now using Canon Properties. Noted that Different batteries report differnent 'Raw levels' than the ones I coded for initially.
Cropmarks now correctly scaled on External HDMI montior.
Vram is in different location / and maybe resolution too. So histograms producing rubbish.
Also .. when shutting down, DryOs is going into Error.
[2011_06_15] AJ 5.8 Fixed % used for Battery Icon
[2011_07_13] Had an hour spare ... and threw together a hotplug routine - Yes it works .. but there is still problems with external montors when switching them off / or trying to use Play.
[2011_07_15] Pel has acquired a Canon 5d mk 2! And has just sent me a Stubs update -> 2.0.9
[2011_07_16] Canon 2.0.9 .. seems to be more stable with UDMA7 cards :D.
[2011_07_17] Pel found 2 x routines that were hardcoded in aj.c (thanks Pel!). I've replaced them with 'Calls' (which means will that they will not need to be found again).
