Can't reset boot flag on 500D

Issue #400 resolved
utnuc created an issue

Installed PreAlpha 1.12 in the usual manner on T1i. It ran as advertised. I am able to boot to stock default firmware by putting in a nonbootable SD card, but I would like to remove the SD card bootflag.

Attempted to remove bootflag by adding: magic.disable_bootdiskf = 1 to magiclantern.cfg, and ML does find the file upon booting, but I see no evidence that ML has parsed the file. I do not get a confirmation of magic.disable_bootdiskf change upon booting. ML continues to boot, despite these efforts.

The PreAlpha 1.12 release does not include the Boot menu to change the bootflag in ML. Does anyone have a prerelease firmware that has this ability? Alternatively, can someone compile a nobootflag.fir that I can run for the 500D?

Thanks for the info.

Comments (9)

  1. Roald Frederickx
    • changed status to open

    I'm having an issue myself with not being able to load any autoexec.bin anymore. More info here:

    This means that the second way of disabling the bootflag is out of the question for me. The .FIR file is the only method of getting anything of ML to run for me, atm.

    Regarding the actual bug: It looks to me like it has something to do with the config parser. See the attached bootlog at line 961:

    961:  1261.272 [MAGIC] config_parse_line: 'magic.disable_bootdiskf' => '1'
    962:  1261.302 [MAGIC] config_auto_parse: 'magic.disable_bootdiskf' unused?

    This was with a config file consisting of a single line:

    magic.disable_bootdiskf = 1

    Is the code for that .FIR publicly available somewhere, btw?

  2. Alex


    Are you able to compile a FIR file yourself, or do you need help on this? Any autoexec.bin can be compiled as a FIR, but on recent cameras (550D and newer) you need some code signing tools. I don't know if this is the case with 500D, but Chuchin knows (I'll ask him if needed). His repository seems to be offline.

    The code used for bootflags in 550D and newer is here:

    You may have to enable the following:

    • bootflag_display_all (to show the state of NVRAM)
    • bootflag_display/bootflag_toggle (to change it)
  3. Roald Frederickx

    Ah, I never realised that you could make the fir files from the same codebase. The Makefile on alins' bitbucket is unable to do this, however. I patched it up by looking at the 500d branch on the hudson's bitbucket:

    diff -r 940781630142 Makefile
    --- a/Makefile	Sat May 28 22:37:19 2011 -0400
    +++ b/Makefile	Sun May 29 11:55:06 2011 +0200
    @@ -455,19 +455,16 @@
     		conv=notrunc \
     		seek=0 \
    -magiclantern.fir: 500d-empty.fir 500d-flasher.bin 
    -	@if [ -f ../dumper/ ]; then \
    -		../dumper/ \
    -			$^ \
    -			$@ ; \
    -	else \
    -		echo "\n../dumper/ not found; will not build magiclantern.fir."; \
    -		[ -f magiclantern.fir ] && echo "Leaving magiclantern.fir unchanged.";\
    -		[ ! -f magiclantern.fir ] && echo "Please download magiclantern.fir from";\
    -		echo "";\
    -	fi; \
    -	stat -c "autoexec.bin: %s bytes" autoexec.bin
    +magiclantern.fir: autoexec.bin
    +	./assemble_fw \
    +                --output $@ \
    +                --user $< \
    +                --offset 0x120 \
    +                --flasher empty.bin \
    +                --id $(FIRMWARE_ID) \
    +                --zero \
     	perl -e 'print chr(0) x 24' > $@

    This does dump a magiclantern.fir file of the newest (on bitbucket) 500D ML code (haven't changed any other code regarding bootflags, yet). However, I'm a bit weary of trying it out.

    For starters, is the --offset flag that I gave correct? (and if it isn't, what are the consequences?) What's the worst I can realistically expect to go wrong?

    (And a minor question: is there such a thing as a firmware update counter on the 500D, that only allows for a limited number of updates?)

    EDIT: I assume the ../dumper/ file from the original Makefile is responsible for that code signing. Where can I find that file? (where can I find Chuchin's repo?)

  4. Alex

    Chuchin can give the best advice here; I've forwarded your question to him.

    Update counter: we don't know. It seems there may be no firmware update counter on 7D either, since Arm.Indy is now able to run code again on it: is not public, but I don't think you need it for 500D.

    As for risks, I understand that "firmware upgrade" process is just a way to run user code on the camera. It runs in a slightly different context (i.e. the code can figure out if it's running as a FIR or as autoexec.bin; I don't know if there are more differences). I did run an incorrect FIR on 60D (with incorrect RESTARTSTART); I've got black screen and had to take the battery out. I don't know if this had any influence on the fatal crash which happened the next day after this.

  5. Log in to comment