[UNMAINTAINED] Canon 5D Classic Firmware ** Beta 4 **

[nanomad]

Please do not post copyrighted material

[vscd]

>Please do not post copyrighted material

Of course you're totally right but posting a repairmanual of a 7-8 Year old camera is not that bat at all, I guess. Other manufacturers publish this on the normal lifecycle (like lenovo thinkpad etc.). If you wan't to comply fully on the laws you can stop the whole magic lantern project because canon is not amused at it. There are already lawyers talking action agains any manipulation on the new 1Dx   ;(   

Repairing a camera should be a right to the owner!?!

[nanomad]

Last time I checked copyright expired after around 70 years...

[vscd]

...depends on the work or the kind of copyright. There are several forms and even the GPL is a copyright, but with no real fixed time terms.

[Buzzz57]

Please go back on subject....

... I think it was Auto ISO for the 5Dc... 

[Buzzz57]

ML installed on my 5Dc. It seems to work fine.

[Buzzz57]

I have a question about the beta 4.
What is the interest of having the cropmarks graphics ?
They are used only on the cameras with liveview. Aren't they ?
Each time I extract the picture from my memory card with Lightroom, I get an error message for the cropmark graphics.
Can I remove these files from the card without any risk ?

[scrax]

I have a question about the beta 4.
What is the interest of having the cropmarks graphics ?
They are used only on the cameras with liveview. Aren't they ?
Each time I extract the picture from my memory card with Lightroom, I get an error message for the cropmark graphics.
Can I remove these files from the card without any risk ?

I suppose that you will then have a warning message from ML instead of Lightroom (but ML will work ok, just without cropmarks).
Import only DCIM folder contents instead.


@Coutts or 0xAF, about my compiling problems, I'm still stuck with that strange -mlong-calls error even if 600D and other camera are working ok. I want to override INFO screen with one like on bodies without LCD, but can't do it until I can't compile for 5D.
Could it be a compiler issue (summon-arm on osx 10.7.5)? Or since it works for other cameras it should be something in the code?
I'm thinking about installing a virtual machine and use linux but if I can avoid would be perfect.

[sandisk]

Please do not post copyrighted material

What is the legality of the Magic Lantern firmware from Canon's point of view?

Am I breaking the law by installing ML on my Canon 5DC, or is it the software devs who might get in trouble.

I really don't know, can anyone say?

[scrax]

What is the legality of the Magic Lantern firmware from Canon's point of view?

Am I breaking the law by installing ML on my Canon 5DC, or is it the software devs who might get in trouble.

I really don't know, can anyone say?

Canon point of view is unknown, and has no legal value (if they want they can sue you for nothing and wait the process).
ML has no canon code, so there is no copyright issue with it, like installing an open source app in your computer.
For devs copyright issue in EU and USA are not a problem since reverse engineering is legal for interoperability between our hardware (since bought from Canon) and our software (self written).
It's similar to iphone jailbreak to me and that is legal in EU, probably also in USA, not sure.

A manual of an old camera is still copyrighted by canon, even if they don't care anymore about it.

[srb]

 Canon 5D Classic Firmware ** Beta 4 **

I followed the various version of instructions and all have worked through "continuous blue light". Removing and re-installing battery  only brings up a black screen, and pressing "Trash" button fails to bring up ML menu. Removing battery again "Menu" shows" ver 1.1.1", - should it not show "ML 1.1.1".  Apparently I can now install and un-install ML, but cannot get it to function.

Assistance is requested to bring ML to function.

[0xAF]

@Coutts or 0xAF, about my compiling problems, I'm still stuck with that strange -mlong-calls error even if 600D and other camera are working ok. I want to override INFO screen with one like on bodies without LCD, but can't do it until I can't compile for 5D.
Could it be a compiler issue (summon-arm on osx 10.7.5)? Or since it works for other cameras it should be something in the code?
I'm thinking about installing a virtual machine and use linux but if I can avoid would be perfect.

It smells like your toolchain problem. I use my toolchain (which i compiled almost 1 year ago) for 400Plus and ML and it compiles everything (i.e. 400Plus and all the ML cameras)
You may ask Coutts to send you his toolchain, or if you want a toolchain for linux i can send you mine (though here in the forum you can find a binary toolchain for linux)

[Buzzz57]

I trying to start developping for the 5Dc and my first step is to compile the existing code.
However, even at this low level, I have issues.
When I try to make the autoexec.bin file, I get this :

Code: [Select]

$ make 5DC
make -C /home/BuzziLa/magic-lantern/platform/5DC.111
make[1]: Entering directory `/home/BuzziLa/magic-lantern/platform/5DC.111'
[ CC       ]   dummy.o
../../platform/5DC.111/dummy.c: In function 'fps_get_current_x1000':
../../platform/5DC.111/dummy.c:25:32: warning: 'return' with a value, in function returning void [enabled by default]
../../platform/5DC.111/dummy.c: At top level:
../../platform/5DC.111/dummy.c:73:10: error: conflicting types for 'shamem_read'
../../src/dryos.h:58:17: note: previous declaration of 'shamem_read' was here
../../platform/5DC.111/dummy.c: In function 'ReleaseRecursiveLock':
../../platform/5DC.111/dummy.c:15:1: warning: control reaches end of non-void function [-Wreturn-type]
../../platform/5DC.111/dummy.c: In function 'AcquireRecursiveLock':
../../platform/5DC.111/dummy.c:13:1: warning: control reaches end of non-void function [-Wreturn-type]
../../platform/5DC.111/dummy.c: In function 'fps_get_shutter_speed_shift':
../../platform/5DC.111/dummy.c:11:1: warning: control reaches end of non-void function [-Wreturn-type]
../../Makefile.inc:624: recipe for target `dummy.o' failed
make[1]: *** [dummy.o] Error 1
make[1]: Leaving directory `/home/BuzziLa/magic-lantern/platform/5DC.111'
Makefile:64: recipe for target `5DC' failed
make: *** [5DC] Error 2


[0xAF]

I trying to start developping for the 5Dc and my first step is to compile the existing code.
However, even at this low level, I have issues.

Try using this repository: https://bitbucket.org/0xAF/magic-lantern-5dc-port-wip
Once I get the booting ported it will be merged with the main repo.

[Buzzz57]

No error report and Autoexec.bin has been created. Thanks.

[0xAF]

No error report and Autoexec.bin has been created. Thanks.

As for now, try to avoid changing the boot mechanism.
Until I find the place that hangs the CPU it will boot with the old method.

[Buzzz57]

So, I just have to replace the autoexec.bin on my CF card to install any new version ?
Are there changes to test on the version you have given to me, compared to B4?

[0xAF]

So, I just have to replace the autoexec.bin on my CF card to install any new version ?
Are there changes to test on the version you have given to me, compared to B4?

I did not made any changes related to features, so do not expect anything new.
Only the generic changes in the main repo which are for all cameras will be there (e.g. new icons in the menu)

[a1ex]

There were many backend changes (e.g. the separation of features with ifdef's) which were not tested at all on 5Dc afaik. So just try every single thingie and see what still works and what not.

[scrax]

I suppose that my toolchain is the same of coutts since i've installed it following his instructions, but will look for the linux one here in the forum.
By the way the toolchain is all in his folder so it can be copied from a computer to another or there are other things around the system needed/installed when compiling it?

After that i'll be able to start testing new features and remove or fix what is not working like flash/no flash option

Also since on that camera we have just a few features that need to be switched on and off during use (like braketing or intervalometer) I was thinking about adding shortcuts to all of them like it's now for MLU, suggestions about the button to use?
I was thinking about using the joystick, something like:

UP: Bracketing
DOWN: Intervalometer
LEFT: -1/3 flash exp comp.
RIGHT: +1/3 flash exp. comp.
DP: MLU

[0xAF]

I suppose that my toolchain is the same of coutts since i've installed it following his instructions, but will look for the linux one here in the forum.
By the way the toolchain is all in his folder so it can be copied from a computer to another or there are other things around the system needed/installed when compiling it?

for the binary toolchain see this: http://www.magiclantern.fm/forum/index.php?topic=991.msg1205#msg1205
though i havent tried it, but since alex suggest it, i guess it will work.

if you want to build yours, try either the summon-arm-toolchain - https://github.com/esden/summon-arm-toolchain
(i think alex had a modified version of it)
or this one https://github.com/jsnyder/arm-eabi-toolchain (has instructions for mac os). Alex confirmed that EABI works, and IMO it would be better to stick with EABI, though when i tried to make an EABI toolchain it failed with similar linking problems like yours ...

[Buzzz57]

There were many backend changes (e.g. the separation of features with ifdef's) which were not tested at all on 5Dc afaik. So just try every single thingie and see what still works and what not.

OK. No risk to brick my camera?

[a1ex]

See FAQ

[scrax]

for the binary toolchain see this: http://www.magiclantern.fm/forum/index.php?topic=991.msg1205#msg1205
though i havent tried it, but since alex suggest it, i guess it will work.

if you want to build yours, try either the summon-arm-toolchain - https://github.com/esden/summon-arm-toolchain
(i think alex had a modified version of it)
or this one https://github.com/jsnyder/arm-eabi-toolchain (has instructions for mac os). Alex confirmed that EABI works, and IMO it would be better to stick with EABI, though when i tried to make an EABI toolchain it failed with similar linking problems like yours ...

Thank's for the links,  will try the EABI first and then the prebuilt. I don't have any clue what's different from EABI and ELF, I've preferred ELF since alex was using it for Makefile compatibility, and now that it is customizable one toolchain or another for me don't make any difference, if works of course

I'm using the summon-arm toolchain modified by alex right now installed using the guide of coutts but with another package manager for osx instead of macport/fink.
Need to try to compile 400plus, since I've tried and it failed nearly one year ago when found how to compile the toolchain on mac.

[0xAF]

I don't have any clue what's different from EABI and ELF

I can't draw you the big picture, since I do not see it too, but basically these are 2 different ABIs (Application Binary Interface). It matters for linking.
The EABI is the newer and commonly accepted nowdays. It's made for embedded systems, hence the "E" letter. The idea for EABI is to have an ABI that has compatibility between different compilers, so basically you can have different object files (.o) made from different compilers and still link them together... It matters for dynamic libraries too (IIRC), so you can have different libraries made by different compilers and still link (statically or dynamic) between them. Hence the plugins compiled by different compilers.
Another difference (IIRC again) is that EABI uses some kind of optimized stack space (perhaps other tricks too), so it takes less memory (and size).
One more thing, I've read somewhere that the calling mechanism for the routines is different, but I'm not sure about it. Thus I had doubts if it will work in ML, because we are calling routines from OFW, but since Alex confirmed it, I guess it's backward compatible, or it is using the old method for calling a stub. IDK. Though I may be totally wrong here. There is plenty information on the net, but I'm lazy to read it. (search for "EABI")

Basically for us it doesn't matter if we use the old ABI or the newer EABI, but since the EABI is common nowdays and it's made for Embedded systems, I would guess it's better.


p.s.
If someone has more knowledge ready to be shared and thus saving me time for reading it, please correct me or share more



EDIT:
as it seems it has better FP Emulation: http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Why-ARMs-EABI-matters/