Proposal: Continue boot on wrong autoexec.bin

Started by Marsu42, October 17, 2013, 10:28:36 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Marsu42

Sorry if you feel bombarded with "this would be a good idea" threads, but here's another one that I feel should be addressed when using different models in parallel and swapping cards between cameras (yes-i-know-this-is-not-recommended, but large-gb-cards-do-not-grow-on-trees):

1. Make settings model-specific, for example by moving them to sub-directories. This esp. would prevent reading wrong props from the config file - the code is supposed to double-check this, but I wouldn't bet on it, esp. if I wrote it :-p so imho completely avoiding bricking would be safer. Also, the config file isn't really compatible anyway because different cameras use different features (or need different settings) - so why not simply separate the configs altogether?

2. Continue boot on incompatible autoexec.bin - this is a minor annoyance, but anyway: If I switch cards (I have different sizes) between 6d & 60d and a single-model autoexec.bin is on them, the cameras simply fail to boot. This not only gives me a near heart attack each time, but also prevents me using them in case even without ml. Would it be possible to simply continue booting the camera without ml instead of halting it?

Thanks for taking the time to evaluate these :-)

a1ex

2 is easy to do; the universal dumper that we used on all new cameras since 650D and EOS M searches for the firmware start address and jumps there.

Problem: if it boots plain Canon firmware, you may believe the card is no longer bootable. Blinking the LED in some unusual way before booting should prevent this ambiguity IMO.

(you could even "print" something in Morse by blinking the LED)

Marsu42

Quote from: a1ex on October 17, 2013, 10:38:48 PM
Problem: if it boots plain Canon firmware, you may believe the card is no longer bootable. Blinking the LED in some unusual way before booting should prevent this ambiguity IMO.

Yes, I also thought of this problem but didn't know if there's the possibility of executing some "generic" ml code - so a delay + blinking is a good idea, and it would signal that if absolutely nothing happens there's really something wrong other than just mixing up the autoexec.bin

a1ex

Delay is generic, blinking LED is not quite. You can autodetect the camera at boot time, and then run some camera-specific stuff, like the unified bin does, but it needs some legwork to update the autodetection for all current models.

The current unified approach would require a HUGE binary to run on all cameras (which will slow down the boot time), and we don't have portable file I/O access from bootloader to select a binary from there. So, at some point I thought to write a small loader that can do basic file I/O on any supported camera, and loads the camera-specific ML binary as soon Canon code initializes the filesystem in the main firmware. This will enable a single zip for all cameras again, without the fat binary; jumping to Canon firmware can be used as a generic fallback, if the camera is not recognized or camera-specific bin could not be loaded.

It's not easy though, and I'm not sure if it's worth the effort.

Marsu42

Quote from: a1ex on October 17, 2013, 11:11:17 PM
It's not easy though, and I'm not sure if it's worth the effort.

Sounds nice of course, but there are probably better uses for your time :-o ... but just jumping to the known address of the Canon fw instead of halting would be easier to implement?

I'd still favor this over halting, being not able to use a "wrong" card (from another camera of mine or another person) can be a problem when away and lose you shots while checking if the card is bootable is easy, as is copying the correct autoexec.bin at home.

a1ex

We already have the code to find Canon startup address in a portable way and jump there.

Marsu42

Quote from: a1ex on October 17, 2013, 11:18:56 PM
We already have the code to find Canon startup address in a portable way and jump there.

Well, don't let me detain you (quote from Lord Vetenari in Discworld :-p) as this is well beyond my current skill or knowledge of ml. Or we can wait for other opinions of halting vs. booting.

Marsu42

Quote from: a1ex on October 17, 2013, 11:11:17 PMThis will enable a single zip for all cameras again

I only just now understood what you mean since I didn't try it before, but now had a look at reboot-all.c - currently there is no way to generate a autoexec.bin that works with both 60D & 6D?

If so, coding a generic bootloader actually would be a good idea, as written I dual-use my cards since I don't know with which camera I'll shoot the most, and currently I'm obviously forced to decide which cards works with which camera :-\

a1ex


RenatoPhoto

Could ML move towards a unified skeletal autoexec.bin that could bring in modular code based on the camera used similar to modules?  I suppose memory restriction will not make this approach feasible.
http://www.pululahuahostal.com  |  EF 300 f/4, EF 100-400 L, EF 180 L, EF-S 10-22, Samyang 14mm, Sigma 28mm EX DG, Sigma 8mm 1:3.5 EX DG, EF 50mm 1:1.8 II, EF 1.4X II, Kenko C-AF 2X

a1ex

Small problem: module overhead is not that small (position-independent code is a little larger).

chris_overseas

This is a little ugly (and perhaps not technically feasible) but what about this:

autoexec.bin checks the camera model on startup. If it's the right camera for the binary, obviously we're all good. If it's the wrong camera, try to find the correct autoexec.bin (eg by looking for 5D3/autoexec.bin). If it finds that, copy that binary over top of itself (difficult/impossible?) and reboot the camera (or flash/beep and hang, to indicate the user needs to power cycle it). If the correct autoexec.bin is not found, boot without ML. There's a pathological case of infinite reboots if someone puts eg a 60D binary in the 5D3 location, hopefully not a big problem in practice.

This way position-independent code can be avoided for the bulk of the executable, one card could work across multiple cameras, and cards that don't have the correct version of ML won't prevent the camera from starting.

Apologies if that isn't practical and I'm just adding noise.
EOS R5 1.1.0 | Canon 16-35mm f4.0L | Tamron SP 24-70mm f/2.8 Di VC USD G2 | Canon 70-200mm f2.8L IS II | Canon 100-400mm f4.5-5.6L II | Canon 800mm f5.6L | Canon 100mm f2.8L macro | Sigma 14mm f/1.8 DG HSM Art | Yongnuo YN600EX-RT II

a1ex

Possible, but if we go that far, we may as well implement a loader that always loads the binary at some (camera-specific) fixed address. So it can be somewhat like a module, but not in a standard elf format.

nanomad

Here's a sketch of  a possible solution we discussed a while ago, but as a1ex said the user may think ML is not working when instead he has to run the firmware upgrade to copy stuff in the correct place.
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

Marsu42

Quote from: nanomad on October 19, 2013, 11:20:19 AM


The image is broken (403), could you repost it or enable access?

As for the user thinking ml isn't working - most users will have either the universal autoexec or the appropriate 6d/5d3 version, so imho newbies running into this problem doesn't seem very likely to me. Also the installation instructions seem to be very clear and step by step, so is this really necessary?

On the other hand. having to have different ml autoexec (like I do with 60d & 6d) and then wanting to swap cards in the field is a real possibility, and I don't see why ml would have to halt the entire boot process as a "friendly reminder" that the autoexec is wrong if simply going to plain Canon fw is easy to do.

Marsu42

Concerning the "continue boot even with the wrong autoexec.bin" request...

... yesterday I had to think of it again because I put the wrong card in my camera (60d sd into 6d) because I was in a hurry and ended up with an unusable camera. Yes, call me a big dodo, but still I would find it extremely useful if a camera wouldn't be semi-bricked because there's a wrong ml on the card - and it seems we won't see a unification of digic4/5 autoexec.bin anytime soon.

Question: Can I easily modify the ml source myself so the camera continues booting into the Canon fw if the boot process detects the autoexec.bin is for the wrong model, or would these changes be more extensive?

1%

You could have something like if signature fails, boot canon fw. The only way to really go back to unified might be to implement that arm bootloader posted which ran on eos.

Marsu42

Quote from: 1% on November 07, 2013, 03:22:59 PM
You could have something like if signature fails, boot canon fw.

Sounds like what I want, though I don't know how/where to implement it, I never looked at the whole ML bootprocess source :-o