Canon 40D

[theBilalFakhouri]

Expanding the preview is done in YUV HD path, that would mean in x5 Mode you can get less crop in YUV HD stream . . Changing YUV HD buffer is not required to expand the preview .. but

I could change YUV HD buffer size too, in 700D in Idle mv720 and mv1080 YUV HD buffer is 960x540, when recording H.264 video in mv1080 the buffer changes to 1728x1151, in mv720 it changes to 1280x689, and after that H.264 Encoder compresses it , taking a look what's happening between Idle and H.264, I can identify one EDMAC channel register which control the buffer size, and other registers related to it which make the expanded YUV buffer size usable instead of being black.

I got in mv1080 1728x1151 instead of 960x540 in Idle
           mv720   1728x540   instead of 960x540 in Idle (1728x689 would be possible)

So now 1 RAW Pixel = 1 YUV Pixel

in x5 Mode Buffer size is 1032x687 which matches 1032x687 of RAW data directly, expanded the processed RAW data in YUV HD stream (Expanding the preview) with increasing the YUV buffer size is possible, I got more than 1032 buffer width matches more than 1032 RAW data , but there is a limit at some point.

More Info at LiveView Investigation.

I don't think you need to change ADTG or CMOS, unless you want to increase the RAW data.

[heder]

Hi theBilalFakhouri

Thanks for the input, looks really interessing with the YUV changes in your liveview thread, I'll try that out when I am ready. Currently working on the initial release, then afterward expanded the YUV buffer sizes so I can fit more pixels into that. In raw video x5 mode I get max 1920x804, and getting mjpeg 1920x804 would be nice for a camera that was'nt build with video recording capabilities.   

[theBilalFakhouri]

That would very cool for 40D, Good Luck, Nice work! I am excited to take a look into MJPEG code

[Ant123]

I am excited to take a look into MJPEG code

You can look into my current version

But:

On newer models (DIGIC 5, IIRC also 60D and newer DIGIC 4), this function no longer runs automagically while in LiveView, so this approach is only valid for older models.

[heder]

This is what happens in the main lv jpeg compression function called in liveview

"LVJpegEncodePath":
1. Create a event flag
2. lock used engine resources
3. Setup edmacs, jpeg core registers
4. Start edmac transfers (YUV422 => jpeg core) and start jpeg core
5. Wait for core to complete (wait for event flag)
6. Delete flag
7. unlock used engine resources

Its going to be hard to get that running on other cams, but is not impossible. This actually look 99.99% excat the same as when photo mode does the excat same compression on the 40D ("JpegEncodePath"). It's a single isolated function, called in the LiveView.

[ArchThor]

Hi all,

So, went through all pages here and just wanted to confirm if I maybe a bit too dumb to understand the codes used here or the LiveView "timeout" is not on the list of mods planned.

Currently my 40D times out at around 30 min and closes LiveView (I am using at work as a webcam to present stuff to the team, so EOS Camera Movie Recorder + OBS), but I could only find the LiveView mentions as being part of the video function, if I got it correctly. Do you know if there is any flag I could maybe change to remove the limit to it?

Thanks!

[heder]

Hi all,

So, went through all pages here and just wanted to confirm if I maybe a bit too dumb to understand the codes used here or the LiveView "timeout" is not on the list of mods planned.

Currently my 40D times out at around 30 min and closes LiveView (I am using at work as a webcam to present stuff to the team, so EOS Camera Movie Recorder + OBS), but I could only find the LiveView mentions as being part of the video function, if I got it correctly. Do you know if there is any flag I could maybe change to remove the limit to it?

Thanks!

Hi ArchThor.

I didn't even know there was a 30 minute limitation, so I will look into this when I have the time. I have LUA scripting
module running (but not released yet), and perhaps I can merge with the LUA fix scripting branch, and using
the LUA module avoid/fix this limitation, but no ETA on when this is ready.

[imme]

hi,
any updates 

[heder]

I'm still working on mjpeg streaming.  Ant123's module would not run record smoothly, so I reworking Ant123's module, making it more towards mlv_lite but my reworked module is not working yet.  Also due to house renovation progress is a little slow lately, but I have not forgotten the ML project 


 

[kidkoala83]

Managed to boot your build in qemu, now i can boot both canon firmware and your ML build.



Next I'll try to run it in the camera and dump the RAM.. Also.. How would one go about finding the half shutter button? Id like to try that.
Thanks for your work heder!

[heder]

Managed to boot your build in qemu, now i can boot both canon firmware and your ML build.



Next I'll try to run it in the camera and dump the RAM.. Also.. How would one go about finding the half shutter button? Id like to try that.
Thanks for your work heder!

Hi, your qemu looks really good  (mine is crap)


My lastest build is here my lastest build (source code) is here
https://github.com/jmheder/ml/raw/master/vxworks_1.0.5.zip The half shutter fix is included, but only lightly tested. The source that fixes the half shutter is platform/40D.111/sal-digic4/sal-gui.c (the function is called sal_GUI_E_Control). Basically i'm hijacking the GUI_E_Control function and checking for half shutter.  It's not the best solution, but because the half shutter on Digic3 is not like on the Digic4 platform, hijacking GUI_E_Control was the easy way of getting "the job done".

If you get stuck, just ask, there's no bad questions, just bad answers.

I'm still working on mjpeg, totally stuck, fighting with odd errors, I dont understand.

[heder]

A new incomplete list of stuff todo

* edmac module fails (edmac is working, but module fails)
* beep sound not implemented
* auto exposure value not detected (I gave up on this one)
* ants mjpeg module is not recording correctly (working on this)
* get 40D branch on heptapod
* compile and test 40D with gcc 6.x compiler.
* Lua module is loading and working, but is it useable ??
* 1st memory job stub function not found.
* lots of PROP_ (properties) not aligned.
* zebras in liveview missing
* global draw (zebras,histogram) not shown in photo mode (= crash)
* Better SW1/SW2 activation
* continue to update https://magiclantern.fandom.com/wiki/Register_Map/40D
* Optimal Mirror lockup not implemented (as minimum the curtain is activated), disable the curtain activation

* 10/12 bits raw video,
  => Theoretical: (10 bits, 23.976 fps, 1:2.39 = 1056x432) &  (12 bits, 23.976 fps, 1:2.39 = 960x400)
  => Require merge with 10/12 bit branch

* LV state mashine
   => not re-engineered
   => VSync er performed via EngDrvOut hijack (ok for now)

* FIO_SeekSkipFile does not work at all .. why ?
   => SEEK_CUR,SEEK_END fails.
   => only SEEK_SET seems to work ..
   => could be cache ?
   => could be interface ? / parameter swapped ?

* selftest module fails
  => only a few tests runs as they should

* bench module fails
   => issue with memory allocation,
   => CF card benchmark may not be performed with buffers > 2 MB or the system halts
 
* memory system allocation
   => still fails on large buffers, bench module fails, selftest modules fails.
   => mlv_lite does not fail. (allocates above 20 MB)

[heder]

Finally a little progress on the port.

I finally found the missing bugs in the FIO_ system which have been annoying, I found two issues.

The interface on FIO_SeekSkipFile is wrong. The interface in magic lantern (DryOs) is specified as: int64_t FIO_SeekSkipFile(FILE *, int64_t offset, int whence); but VxWorks interface is actually: int32_t FIO_SeekSkipFile(FILE *, int32_t offset, int whence); No wonder I could'nt seek inside a file at all! (all seeks was SEEK_SET due to wrong parameter sizes)

The other bug was the O_SYNC flag screws up operations. FIO_CreateFileOrAppend would not perform correctly when seeking inside a file because if was opended with O_SYNC. It seems like O_SYNC is'nt supported (?). I tryed with both cache and uncache memory, both fails with O_SYNC. Removing O_SYNC from opening file solved the issue.

And with console.c writing console.log correctly (now) I can assume hunting the last fio_malloc() bugs ..

[Ant123]

FIO_SeekSkipFile: should be testable in QEMU, with a large SD image and the test code from selftest.mo. That test will create a large file (2GB) and seek within that file.

There are two versions in Canon firmware: one that accepts 32 bits for the position and another one that accepts 64 bits. They are not interchangeable at binary level.

[heder]

Yep, using the 32 bits worked, but I also needed O_SYNC removed.

[heder]

Good news. Memory management on the 40D soon complete

SRM allocation is up and running in QEMU and camera




I have found that SRM_AllocateMemoryResource1stJob functionality is present in the Vxwork firmware, but the code is completely different from the DryOS cameras. Calling call("FA_CreateTestImage") and call("FA_GetCwRawBuf") did however still work like a charm, and I get access to a full Craw buffer = 18153360 bytes. Thus I have created compatible SRM_AllocateMemoryResource1stJob+free functions that uses the call("") functions, this should also work for 400D. SRM_AllocateMemoryResource1stJob on the 40D can actually allocate more or less all memory, outside Liveview I get 14 buffers, inside Liveciew I get 11 buffers. The camera has total 256 MB on board and most can be allocated using SRM_AllocateMemoryResource1stJob and shoot_config(0). I can allocate a total ~240 MB, Mlv_lite  will benefit from this (mjpeg recording too - when it is done). Next step is to update mlv_lite to use this memory, so we can start recording less useless formats.

Beside this I found that the largest non-temp block (malloc,AllocateMemory) on 40D that can be allocate is very small a little less than 4MB, but the code assumed 20 MB, and this could crash the camera, fixed.

[heder]

Open beta update (1.0.6).

https://www.magiclantern.fm/forum/index.php?topic=1452.msg224594#msg224594

With the memory system nearly completed, its time for another beta release, as mlv_lite can utilize this. This improves the recording capabilites abit.

Memory system:
* SRM compatible function implemented inorder to avoid new code, I used [SBF]CreateSharedBuffer for allocation.
* malloc fully supported in fio_malloc (get free region fixed)
* Largest shoot malloc block is around 4MB, fio_malloc updated to pass allocation to SRM above 4 MB.
* Disabled memory analysis overlay (debug menu), it will crash the camera (overlay width,height incorrect?)

Bug fixes / minor changes:
* CACHEABLE() & UNCACHEABLE() changed due to incompatible between digic4 and digic3.
* edmac channels now switch automatically between 0x4 and 0x5
* console now uses FONT_MED due to low resolution display, and included more options and buffering
* FIO_SeekSkipFile interface corrected and FIO_CreateFileorAppend corrected.
* FIO_WriteFile wrapper not checking for digic4 uncacheable pointers correctly

mlv_lite:
* mlv_lite can now allocate ~208 MB, instead of ~40 MB
* srm memory allocation enabled (if set true in menu)
* pre-recording disabled - will prevent camera from recording correctly
* Starting and stopping LiveView multiple times may set preview=black, resolve this by power off and on.

[names_are_hard]

Lots of work went into this I'm sure - well done.  I think this is the oldest supported cam?  You are now a record holder

[Walter Schulz]

Not quite. 5D (classic) preceeds 40D. https://www.magiclantern.fm/forum/index.php?topic=1010.0

[heder]

Last update stops at 1.0.6.

Next update will be in 2022/2023. I ran out of luck (time), RL is taking all my time, shit happens once a while.

I'll be watching this thread and ML forum until then.

[MagicJohny]

Hello everyone, I need your help.
After installing this firmware, the camera did not want to start, although everything was done according to the instructions + video. From time to time I can achieve that the red light is on.
I ask for help, can someone tell me how I can forcibly roll back to the old firmware version or install this version correctly?

[Walter Schulz]

After installing this firmware, the camera did not want to start, although everything was done according to the instructions + video. From time to time I can achieve that the red light is on.

Magic Ball tells: Don't use SD-to-CF adapters. They are crap and ML doesn't support issues with this kind of adapter.
If Magic Ball is wrong: Remove battery, remove card. Insert battery. Do not insert card. Startup cam and report back.

[MagicJohny]

Magic Ball tells: Don't use SD-to-CF adapters. They are crap and ML doesn't support issues with this kind of adapter.
If Magic Ball is wrong: Remove battery, remove card. Insert battery. Do not insert card. Startup cam and report back.

It started without a memory card. I do not use SD-to-CF adapters. Thank you.
If I insert a card, it is still busy in the mode and the red indicator is on.

[Walter Schulz]

Give some details about the card you are using.
Check card contents. Is autoexec.bin located in card root?
Do you have a spare card to use with ML?

[MagicJohny]

Give some details about the card you are using.
Check card contents. Is autoexec.bin located in card root?
Do you have a spare card to use with ML?

kingston compact flash cf/16gb-u2