[info for developers]
No display, and ERR70 when attempting to go in LiveView / movie.
Solution: start camera with a HDMI monitor.
ERR70 at every startup
When you start the camera, you get ERR70 at every startup, even without ML.
Usually, one of the Properties was set to some invalid value and got saved into NVRAM.
Since you have no access to Canon menu, you can't reset the camera to defaults.
Known properties which may cause this (based on what we experienced during development):
- PROP_PIC_QUALITY (0x80000031 on 550D)
- PROP_MOVIE_SOUND_RECORD* (0x2050013-0x2050015 on 5D Mark II 2.1.1)
- PROP_VIDEO_MODE (0x80000039 on 5D Mark III 1.1.2)
Simply reboot the camera without a card and clear the settings.
Go to C mode, change the affected setting back and forth from Canon menu, reboot in CA mode, then reboot in M mode. 
Attempt to restore a valid value. This is possible because Magic Lantern still loads and is running behind the ERR70 dialog.
If you know what property you have changed last time, should be easy (you need to know a valid value to restore it).
If you don't know... save a debug log (call "dumpf", see Debugging Magic Lantern) and look for failed asserts. You'll see something like:
11: 50.637 [STARTUP] ERROR ASSERT : PropertySatellite.c, Task = PropMgr 12: 50.737 [STARTUP] ERROR ASSERT : Line 624 13: 50.779 [STARTUP] ERROR ASSERT : TempMovSoundRecord != PROP_MOV_SOUND_RECORD_ON
So... let's look at the code (with GPL Tools/ARM console):
s TempMovSoundRecord ff85e364: 'TempMovSoundRecord != PROP_MOV_SOUND_RECORD_ON' r ff85e364: PROP_HANDLER:str:PROP_MOVIE_SOUND_RECORD_FOR_CREAT+420: ff85e22c: 028f0e13 addeq r0, pc, #304 ; *'TempMovSoundRecord != PROP_MOV_SOUND_RECORD_ON' 'TempMovSoundRecord != PROP_MOV_SOUND_RECORD_ON'
Let's decompile this:
dec PROP_HANDLER:str:PROP_MOVIE_SOUND_RECORD_FOR_CREAT [...] if arg0 == 67764263/2: DebugMsg(129, 3, msg='PROP_MOVIE_SOUND_RECORD %d %d %d %d ######', *0x2708, *(arg2), *0x270C, *0x2710, *(arg2), ...) if *(arg2) == 0: TH_assert('TempMovSoundRecord != PROP_MOV_SOUND_RECORD_ON', 'PropertySatellite.c', 0x270) [...]
Looks like property 67764263/2 = 0x2050013 should not be zero. Valid values are 1,2,3 (with property spy on a healthy camera, or with guesswork if you don't have one).
Be careful: setting one property may cause other properties to be changed.
If you are really unlucky, trying to restore the right value via prop_request_change will not work (the camera will simply refuse to accept the new value due to failed assertions).
What to do?
In : dec TH_assert if aAJ_TH_assert_struct_0x19C8_0x00_to_0x08.off_0 == 0 /*EQ*/: TH_con_puts('\x07Assert: File %s, Expression %s, Line %d\n', arg1, arg0, arg2) => ret_TH_con_puts_FF814D00 AJ_msleep_sub1_assert_fail(arg1, arg1, arg0, arg2) => ret_AJ_msleep_sub1_assert_fail_FF814D0C if aAJ_TH_assert_struct_0x19C8_0x00_to_0x08.off_0 != 0 /*NE*/: JUMP(aAJ_TH_assert_struct_0x19C8_0x00_to_0x08.off_0)
If you really have cojones, install your own assertion handler in order to ignore failed asserts. This should give you access to the menu. But... the consequences of doing this might be arbitrarily bad in theory.
Anyway... for PROP_PIC_QUALITY on my 5D2 it just worked (and it also unbricked a camera damaged by a USB remote control app ). Calling prop_request_change did not work (same call that worked on 550D and 60D for the same problem).
Possible alternative solution (not tested!)
You may call FA_SetDefaultSetting to restore your camera to defaults. Details at http://groups.google.com/group/ml-devel/msg/51b4518bf0a2278f . The command works, but the therapeutic effect is not guaranteed :)
Will removing the clock battery help?
No. The clock battery only stores the clock, not the shooting settings. Poor design, IMO.