A little more stuff:
There are two parts of the firmware: the bootloader and the main firmware.
The bootloader can:
- perform some low-level configuration (e.g. the MPU
*) registers, which can give hints about the memory map)
- load FIR files
- load AUTOEXEC.BIN (if the boot flag is enabled)
- show a small diagnostic menu (aka FROMUTILITY)
- jump to main firmware
*) MPU = memory protection unit (see the ARM docs). Not to be confused with what Canon calls
MPU (a microcontroller).
In DIGIC 5 and earlier, the bootloader starts at 0xFFFF0000 (aka HIVECS or high exception vectors in ARM docs).
The two parts are pretty much independent: once in bootloader context, your program can call other bootloader routines, and once in main firmware, you can call main firmware routines. If you mix them, it won't work. Exception: some very simple routines that don't use any state (such as strlen).
ML runs alongside main firmware. In order to do that, it has to modify the startup routine, reserve some memory (so Canon firmware won't overwrite it) and launch one user task. Once you did that, our code is running as a regular task on Canon's operating system (be it DryOS or VxWorks). From here, it can launch other tasks, call file I/O routines or whatever.
For trying out things, you can compile the "recovery" branch from ML, from platform/portable.000. This will give you a portable autoexec.bin that runs on all cameras (and also in QEMU), and has display access (from the bootloader context). Of course, this autoexec can be signed as FIR and loaded without requiring a boot flag.
The boot flag can be enabled from both bootloader context (as done in the old 5D) or from main firmware. EnableBootDisk only works from main firmware, but usually there is an equivalent bootloader routine, found in the FROMUTIL menu.