600D has limited memory to load the autoexec.bin binary into memory during boot. This is just a result of how the Canon bootloader works, and how ML starts up, not a result of total memory available (Why? It's very common for bootloaders in general to have very little resources available, in fact this is the very reason it is called bootstrapping; this article is about x86 not ARM, but the same principles apply:
http://wiki.osdev.org/Boot_Sequence).
For us, there are only 512KB (0x80000) of memory available for autoexec.bin during bootstrapping for whatever reason (this is true for 600D and 1100D, other cameras have more, so they work fine if autoexec is bigger than 512KB). Later on we have vastly more memory available (several hundred MB usually, depending on what Canon firmware is doing and how much it needs), this is why we can still load lots of modules, they aren't loaded until later on when a lot more memory is available*.
Going over 512KB is very bad. This is my understanding of why: it basically means that an arbitrary chunk of ML's code is basically going to be missing, and there may be, for example, functions that point into uninitialized/invalid memory locations. Due to the lack of memory protection on the ARM CPU, this means that arbitrary code can execute, which is VERY BAD! What's worse is that if it's only a small chunk missing, then most things may appear to be working until all of a sudden, randomly later on, you try to execute something in the missing chunk and you get a hard crash.
Always check the MemSiz header in the build output:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x073918 0x00cf3918 0x00cf3918 0x00008 0x00008 R 0x4
LOAD 0x000100 0x00c80100 0x00c80100 0x73820 0x7ff0c RWE 0x100It must be less than 0x80000 for 600D and 1100D. Above is the last valid 600D build, notice it's right on the edge. The current ML source results in something about 8KB over the limit.
So, whoever is doing this: hege.cc/magic-lantern/ should probably disable it until this issue is resolved, or they should disable ML features to get the size below 512KB. Because arbitrary code can execute, there is a possibility of bricking. This is no joke.
*This should give you some clue as to a possible solution: move stuff to modules. There are two main issues moving things to modules. 1) A lot of the ML core is tightly coupled (things depend on each other), so it's hard to move things out without refactoring out the tight coupling (it is possible to remove a lot of dependencies, just time consuming). 2) There are a ton of macros that specify unique camera specific code all over the place in the core. This is not allowed in modules, modules are supposed to be camera agnostic or at least they contain all the code for all cameras if there's a difference, (e.g. dual_iso), so the same module can be used on all cameras. Again, there is refactoring that can be done to alleviate some of this, but it is considerable work. I've been trying to work on this some b/c one of my cameras, 1100D, is also plagued by this issue.
Another possible solution (and a much better one actually) is an 'ML bootloader'. Basically the part of ML that goes in autoexec.bin is just a minimal core that knows how load some camera specific binary from a specific location. This too is a lot of work. It has the advantage of allowing one single download for all supported cameras, and the ability to use the same ML SD/CF card on different cameras.
