Messages

Dear all,
is it possible to use FRSP bulb mode with EOS 700D?

Yes (probably), but "capture_err_time_addr" and "bulb_end_addr" addresses need to be found for 700D, disassembling a ROM dump from your camera.

See:

http://www.magiclantern.fm/forum/index.php?topic=12523.msg168467#msg168467
http://www.magiclantern.fm/forum/index.php?topic=12523.msg168553#msg168553

And:  Tutorial: finding stubs

Launching  the redraw test, that's what I see:

- The ML menu closes, Canon's normal status screen in photo mode appears. the blue led in liveview button blinks during several secons, and after that it stops blinking, so the redraw action starts. I can not see the effect of the redraw, because in this screen the 50D does not show any overlayed info (On a 500D doing the same test, I see the overlays blinking)
- I press the "menu" button, Canon menu appears, but the top icon raw, containing the taps to access every page in menu, is not shown, is all blank (this does not happen on 500D)
- When I move camera's main dial, the tabs start to show, but I only see two of them (the actually selected and the last one previously seen, the other icons seen before disappear when moving the dial away from them)
- I can come back to normal status screen half-pressing the shutter button, but I can't longer enter ML menu pressing trash button.
- I can shut down the camera  normally with the power switch, no need to extract battery.

If I enter the "format" function in Canon menu, the camera hangs when rebooting after format, as usual. Having the redraw test active does not make any difference.

If I launch the rectangle test and then the redraw test, I do not see any difference on 50D respect launching only the rectangle text. The rectangles get erased quickly anyway, so I can see parts of the underlying normal status screen. This is different behaviour that in 500D, on this camera the rectangle test launched alone fills all the screen so I can't longer see the underlying Canon status screen.

   

I have been testing this issue tonight, been guided by A1ex on IRC.  Not solved yet, we will continue another day.

Follow the forum dicussions, specially in the "Developing Magic Lantern" section, including the subforums located there (General Development, Modules repository, Reverse engineering) and you will see the features that are being developed or improved. The most common help needed is to test and debug these features in all cams, so you can help staying tuned and testing on your 70D eveything needed.

But first you need to learn how to build the ML source code, setting up a development machine. Doing it in Linux is usually easier (It's possible also to build ML with OSX and even Windows, but the configuration is harder). If you don't have already a  computer running Linux, you can use a VirtualBox to run a Linux virtual machine with the ARM compiler and other software needed to build ML.   

There is already a network of open source ML developers, built around this forum.

The source code is here (as announced in the opening post of this thread):  https://bitbucket.org/nikfreak/magic-lantern/commits/branch/70D-merge

And the information needed to build the code and to help in development is already available in this ML forum. Start reading here: Getting started with development

But no, it's not easy to develop Magic Lantern, because it's a reverse engineering project. Canon will not help you with any info about how their cams work. Everything needs to be discovered by disassembling and analysing the firmware. This needs a good knowledge of ARM assembly, and countless hours of learning and experimenting .. with no warranty at all that you will achieve ever a viable way to get the camera do something you want ... that's why you cannot anticipate the rate of development. It's ready when it's ready.

There are simple tasks in which you can help to improve and debug Magic Lantern, with minimum programming skills. And any help is very welcomed here.

But keep in mind that the whole project has been possible thanks to a small group of highly skilled ant talented developers. And they do it simply for the fun of doing it, and spending the hours they can and want to spend of their free time.

 

All other ML supported cameras do not have a Dual-Pixel sensor, so yes, the 70D is different.

If you think you can do it better and faster, simply do it yourself. All the code is available to everybody. But complaining will not speed up the development.

Thanks, David !!!

This is my modified "silent.c" based on your version, but with included support for 30 sec.  and bulb mode FRSP for the 50D:

silent.c

Works with the latest unified branch, already tested in camera.

The 50D has a "bulb" shutter speed setting in M mode, exactly as the 500D.  I have tested 45 sec. exposures (using ML bulb timer) and it works.

In other words: the 50D has not a "B" mode in the main dial. The 5D Mk II and 60D have this dedicated "B" mode.

Ok, tested, with bulb_end_addr = 0x3218.  It works.

So FRSP in bulb mode for 50D is working. 

I have updated my "silent.c" file. I repeat the link here


Update:
----------

It works using Greg's branch.  If I put the modified "silent.c" file in the current "unified" branch, the silent module fails to build:

Code Select Expand


Building module silent...
Updated HGVERSION
[ README   ]   module_strings.h
[ CC       ]   silent.o
silent.c: In function 'silent_pic_take_lv':
silent.c:969:9: error: implicit declaration of function 'PauseLiveView' [-Werror=implicit-function-declaration]
         PauseLiveView();
         ^
silent.c:1014:9: error: implicit declaration of function 'ResumeLiveView' [-Werror=implicit-function-declaration]
         if (LV_PAUSED) ResumeLiveView();
         ^
silent.c: In function 'display_off_if_qr_mode':
silent.c:1083:13: error: implicit declaration of function 'display_off' [-Werror=implicit-function-declaration]
             display_off();
             ^
silent.c: In function 'silent_pic_take_fullres':
silent.c:1228:9: error: implicit declaration of function 'display_on' [-Werror=implicit-function-declaration]
         display_on();
         ^
cc1: some warnings being treated as errors
make[3]: *** [silent.o] Error 1

********************************************************
WARNING: module silent failed to build, deleting
********************************************************



500D

Code Select Expand

0x3314 + 0x10 = 0x3324

So try 0x3218 (I'm not 100% sure I don't have 50D ROM).
You can check if the address is correct with 30s exposure and delayed_call.

Ok, I see, for 500D:

Code Select Expand


ff07ccf0: e28f20a8 add r2, pc, #168 ; ff07cda0: (42736373)  *"scsBulbEnd"
ff07ccf4: e3a01003 mov r1, #3
ff07ccf8: e20000ff and r0, r0, #255 ; 0xff
ff07ccfc: ebffa765 bl loc_ff066a98
ff07cd00: e51f0500 ldr r0, [pc, #-1280] ; ff07c808: (00003314)
ff07cd04: e3a01001 mov r1, #1
ff07cd08: e5801010 str r1, [r0, #16]     <------------------


And for 50D:

Code Select Expand


ff879854: e28f20ac add r2, pc, #172 ; ff879908: (42736373)  *"scsBulbEnd"
ff879858: e3a01003 mov r1, #3
ff87985c: e20000ff and r0, r0, #255 ; 0xff
ff879860: ebffa8aa bl loc_ff863b10
ff879864: e51f088c ldr r0, [pc, #-2188] ; ff878fe0: (00003208)
ff879868: e3a01001 mov r1, #1
ff87986c: e5801010 str r1, [r0, #16]   <--------------------


So can I assume that "#16" in the last lines is a decimal value, and that's why I should add 0x10 to 00003208  ?

Which gcc version are you using? What about the arm cross-compiler? Mine are:
gcc: 5.1.1
arm-linux-gnu-gcc: 5.3.1
I think I saw recommendation to use 4.8.x (for both?).

I am using gcc  4.8.2  (Ubuntu 14.04 default package, 4:4.8.2-1ubuntu6) and 4.8.4 for the ARM cross-compiler (gcc-arm-none-eabi-4_8-2014q2)

I see that 50D does not have a dedicated bulb mode, only a "Bulb" exposure setting in M mode, so I wonder if Bulb FRSP could be possible in this camera.

Any hint to find "bulb_end_addr" for 50D? 

I suppose I need to find "scsBulbEnd" on Canon firmware. I have done it, and I see code like this:

Code Select Expand


ff079854: e28f20ac add r2, pc, #172 ; ff079908: (42736373)  *"scsBulbEnd"
ff079858: e3a01003 mov r1, #3
ff07985c: e20000ff and r0, r0, #255 ; 0xff
ff079860: ebffa8aa bl loc_ff063b10
ff079864: e51f088c ldr r0, [pc, #-2188] ; ff078fe0: (00003208)     


Is "bulb_end_addr" related to the value between parentheses  (00003208) ?   

Thanks A1ex. Tested, and it works now, I can take 30 sec. silent pictures.

I have updated the link to my slient.c in my previous post with the correct value.

Different results for me. 

Greg's branch works Ok on my 50D, no camera locks at all.  I have modified silent.c  (my version here)  adding an entry for 50D 1.0.9 in silent_init() and assigning capture_err_time_addr = 0xff085b14;

The build works, and I can take silent pictures ... but with a maximum of 16 sec. exposure time. If I try to set a longer exposure (20 s or 30 s) I see a "raw error" message, and the picture is not recorded on CF card. The camera does not freeze, however, I can continue setting a different exposure time and taking more silent pictures.

Tested only with DNG silent pictures, MLV format not tested yet.

The same code built for my 500D works perfectly, I can get 30 sec FRSP and bulb also works with FRSP

Code Select Expand

make 50D
cd modules
make
cd ..
cd platform/50D.109
make zip

Then you will find a file "magiclantern-Nightly.2016Jun17.50D109.zip" on platform/50D.109 directory.

Unzip this file and copy content to your CF card

They say they are planning to put an APS-C sized sensor on the device (a FF sensor is expensive), and you will have a camera with lenses designed for 35mm (so no short enough focal lengths available for wide angle views), and modern APS-C lenses probably will not fit in the camera mount.

So, I think is a lot easier to get a cheap second-hand APS-C DSLR instead. And much better if it is a 500D, 1100D, etc. This way you will be able to run Magic Lantern on it [emoji6]

No, it does not work on EOS-M2.

And no, there is not a known way to solve the shuttter bug. But there are ways to minimize it, mainly using some SD card brands and models that usually do not experience the bug.

Both questions have been already asked and answered many times in this thread. So please, read the thread from the beginning before posting.

Ok, thanks for clarifying [emoji6]

I have found the stubs for 50D. But there is something in this cam that does not happen in 60D and 500D. The stubs for 50D are duplicated, they can be found in two different places, with a fixed offset of 0x800000  (8MB block?).

These stubs are valid, keeping untouched all the previously used memory related stubs:

Code Select Expand

/** Memory allocation **/
NSTUB(0xFF8680C8,  GetMemoryInformation)
NSTUB(0xFF868074,  GetSizeOfMaxRegion)
NSTUB(0xFF867B54, _AllocateMemory)                          // thanks Alex
NSTUB(0xFF867D18, _FreeMemory)                              // release_mem in Indy's IDC
NSTUB(0xFF991018, _alloc_dma_memory)
NSTUB(0xFF818DC8, _free)
NSTUB(0xFF99104C, _free_dma_memory)
NSTUB(0xFF818CF4, _malloc)                                  // maybe it's better to use Allocate/Free?

/** Low-level allocators */

NSTUB(0xFF86755C, init_memory_pool)   // used to init the AllocateMemory pool and others
NSTUB(0xFF8679E4, allocate_memory_from_pool) // called from AllocateMemory
NSTUB(0xFF867B84, free_memory_to_pool) // called from FreeMemory
NSTUB(0xFF867FE0, get_max_region_of_pool) // called from GetSizeOfMaxRegion


But also this will be possible:

Code Select Expand


NSTUB(0xFF068074,  GetSizeOfMaxRegion)
NSTUB(0xFF067B54, _AllocateMemory)                       
NSTUB(0xFF067D18, _FreeMemory)                                                           

/** Low-level allocators */

NSTUB(0xFF06755C, init_memory_pool)   // used to init the AllocateMemory pool and others
NSTUB(0xFF0679E4, allocate_memory_from_pool) // called from AllocateMemory
NSTUB(0xFF067B84, free_memory_to_pool) // called from FreeMemory
NSTUB(0xFF067FE0, get_max_region_of_pool) // called from GetSizeOfMaxRegion


The functions are identical in both cases.


So a1ex, you will see which option is better. I suppose the second option could require changing the addresses of other stubs ...

Not much interesting here...

The good part is that 500D doesn't have issues with the general-purpose memory, so it's fine the way it is.

Yes, ML works perfectly on my little old 500D, no issues at all. And it is a nice, lighweight camera for stills work, very capable, thanks to ML 


Are the "Low-level allocators" stubs useful for your investigation ? Do you need them for other cameras?.  I could search them for 50D or EOS-M.

Here is the log, for 500D:

Code Select Expand

run_test:ff0bc2c8:80:16:
  run_test:ff0bc2e4:80:16: --- Common Top ----
  run_test:ff0bc30c:80:16: IMGPLAY_WORK            0x40D00000 0x00E00000 14680064
  run_test:ff0bc334:80:16: IMGVRAM1                0x41B00000 0x00410000 4259840
  run_test:ff0bc360:80:16: DEVELOP_WORK            0x41F90000 0x00040000 262144
  run_test:ff0bc38c:80:16: FENCING_WORK            0x41FD0000 0x00010000 65536
  run_test:ff0bc3b8:80:16: LV_MARGE_PDEFDATA       0x41FE0000 0x00010000 65536
  run_test:ff0bc3e4:80:16: LV_MARGE_PDEFDATA2      0x41FF0000 0x00010000 65536
  run_test:ff0bc414:80:16: EXMEM3_AREA             0x42000000 0x01431000 21172224
  run_test:ff0bc444:80:16: FILE_HEADER             0x43431000 0x00200000 2097152
  run_test:ff0bc474:80:16: BMPVRAM1                0x43631000 0x00080000 524288
  run_test:ff0bc4a4:80:16: BMPVRAM2                0x436B1000 0x00080000 524288
  run_test:ff0bc4b4:80:16: --- Usually Mode ----
  run_test:ff0bc4e0:80:16: MEMORY_MGR              0x44000000 0x0A000000 167772160
  run_test:ff0bc4f0:80:16: ---    NR Mode   ----
  run_test:ff0bc51c:80:16: NR_MEMORY_MGR           0x44000000 0x08000000 134217728
  run_test:ff0bc548:80:16: COMPOSITION_WORK_TOP    0x4C000000 0x00E5B600 15054336
  run_test:ff0bc574:80:16: COMPOSITION_WORK_BOTTOM 0x4CE5B600 0x00E5B600 15054336
  run_test:ff0bc584:80:16: ---    DP Mode   ----
  run_test:ff0bc5b0:80:16: DP_MULTI                0x44000000 0x04000000 67108864
  run_test:ff0bc8c4:80:16: DP_SINGLE               0x48000000 0x06000000 100663296
  run_test:ff0bc8d4:80:16: --- Common Bottom ----
  run_test:ff0bc904:80:16: IMGVRAM2                0x43731000 0x00410000 4259840
  run_test:ff0bc934:80:16: DCFNO                   0x4FFEAC00 0x00004000 16384
  run_test:ff0bc964:80:16: LV_WORK2                0x4FCB6C00 0x002A4000 2768896
  run_test:ff0bc994:80:16: ENGINE_MIRROR           0x4FF5AC00 0x00080000 524288
  run_test:ff0bc9c0:80:16: VSHADING_COMP_WORK      0x41F10000 0x00080000 524288
  run_test:ff0bc9f0:80:16: BATHTUB_COMP_WORK       0x4FFDAC00 0x00010000 65536
  run_test:ff0bca18:80:16: AVERAGE_WORK_TOP        0x4E000000 0x00E5B600 15054336
  run_test:ff0bca44:80:16: AVERAGE_WORK_BOTTOM     0x4EE5B600 0x00E5B600 15054336
  run_test:ff0bca74:80:16: IMGVRAM3                0x43B41000 0x00410000 4259840
  run_test:ff0bcaa4:80:16: LV_WORK                 0x43F51000 0x000AF000 716800

Sorry for the dumb question: which is the file where I have to insert the code for the "Don't click me" test? I have been looking everywhere in ML source tree and I still don't find it ...     It's "debug.c" file?


Edit:     I found it,  is the "run_test()" function in "debug.c"

Ok, for 500D is 0xFF0BC2BC

I will run the test later.

I have found the stubs for 500D:

Code Select Expand

/** Low-level allocators */

NSTUB(0xFF06A4CC, init_memory_pool)
NSTUB(0xFF06AB44, allocate_memory_from_pool)
NSTUB(0xFF06ADB0, free_memory_to_pool)
NSTUB(0xFF06A970, get_max_region_of_pool)


I will try to run the test later, but I don't know which value should I put on the sample code that a1ex has posted for 70D.  500D is not included in the list with values that Nikfreak has provided for several cameras. Is the same value of init_memory_pool ?

Have you selected MLV format? Then you need to load the mlv_rec module to get full res silent pictures working.