Now I implemented on camera autoexec.bin selecter.
Situation:
1: usually using ML2.3 release
2: added new function or solved bug at new beta autoexec.bin
3: installed new one , and forget it.
4: bring camera to venue for shooting
5: ** new bug or problem found at veneu. also no PC situation**
6: ===> on camera selecter is good!!!
https://bitbucket.org/miyake_t/magic-lanternselectautoexec
(http://chirari.ddo.jp/pub/SelectBinScreenShot.png)
It's tested on my 600D and working fine.
this code is:
1: browse SD card root and find "AE_" prefix files.
2: add AE_ files to "Select bin" submenu.
3:when push bin name in submenu, copy original file to BIN.TMP file.
4: remove autoexec.bin and rename BIN.TMP to AUTOEXEC.bin
I think the critical point only 4. and 4 is really short time, so I think it has no critical.
If you interested in "select bin" please try and test it.
:D nice, will try
Nice! While I won't be needing this, it's definitely great for testing specific features.
Awesome!
Quote from: Malcolm Debono on August 16, 2012, 10:10:52 PM
Nice! While I won't be needing this, it's definitely great for testing specific features.
Yes but not only, it could be a workaround for some feat request.
HINT: can compile ML with different default settings and the load then bin you want without using autosave config and here you have a dirty multi setting setup. ;D
Just remember that I forget to implement "no AE_ files" exception.
One more thing, this extension need a supported this function on all installed autoexec.bin. Then we can return back to previous autoexec.bin.
Finally, Is this implementation need to change a plugin style? If so, all autoexec.bin only need to enable plugin function.
Good idea, now I can load a bunch of different bins without so much card swapping.
Quote from: 1% on August 17, 2012, 05:52:54 AM
Good idea, now I can load a bunch of different bins without so much card swapping.
Yes, me toooooooo. Keep our SD card door ;)
Quote from: scrax on August 16, 2012, 11:07:43 PM
HINT: can compile ML with different default settings and the load then bin you want without using autosave config and here you have a dirty multi setting setup. ;D
Didn't think of that. That would be cool!
this is going in direction of the current idea i have - Magic Boot Loader.
had this idea to wor around some hacks and problems we have with current method.
a) ROM doesnt have to read megabytes of autoexec.bin, but only a small loader and can decide between multiple real ML binaries (startup speedup)
b) those ML binaries can be compressed to speed up loading process even more (startup speedup)
c) we can add selectors for alternative firmware images depending on hw/config
d) we can add rom dumper features etc to this slim bootloader and use it as development base for new models
@g3gg0
I think
a) plugin architecture will cover big size autoexec.bin issue.(But it's good at increasing a capability)
bc) uncompress need more time? and autoexec.bin reading is not so slow now. and ROM selecter need a timeout like a linux grub or lilo. So more time will need boot sequence. I guess
Please let me know bc) things.
On the other hand, your idea have no risk to change autoexec.bin. And It's most safety. Also ROM dumper is attractive.
My function is really compact and we can be default hidden, then user not get a confusing. I guess advanced user will use it until you create boot loader function.
I think now we can use combine both ideas
seems great!
Quote from: miyake on August 17, 2012, 10:22:23 AM
a) plugin architecture will cover big size autoexec.bin issue.(But it's good at increasing a capability)
bc) uncompress need more time? and autoexec.bin reading is not so slow now. and ROM selecter need a timeout like a linux grub or lilo. So more time will need boot sequence. I guess
a) true, but still ML is monolithic for some good reason. but what i dont like is the merging of all camera models in *one* autoexec.bin. it works, but is some thing that can be improved
b) depending on compression algorithm data can be decompressed faster than load from SD card in ROM without DMA
c) timeouts? no gui, no user interaction, nothing to have to wait for.
there are users who already are irritated by the small delay on some models and i wondered how minimal and modular we can make magic lantern.
and true, yours is available *now*, mine is theory yet ;)
Ah, I see, Now I clearly understand what you are thinking.
Thank you for explaining.
First, I imagine linux micro-kernel architecture.
Architecture is similar to linux micro-kernel. But objective is different.
note:
to be honest, calling ML monolithic is wrong. i meant non-modular of course.
linux is modular and monolithic.
Thank you. It's not my specialty part. I just learned it.
I mean only overview of loading style.
I just added make file tweak for on/off "bin select" in Makefile.inc
I think all testing version of autoexec.bin must turn on this func. Then all testers will get happy when they bring testing firmware to venue.
How do you think?
Since the tweak is very small, could you port the feature to the config file too? This will allow us to have real multi-settings in camera :D
@nanomad
Are you telling me that is it's not enough. right?
In this time, this code doesn't need config file values(don't need to use CONFIG_INT).
Because, all submenu values are getting from actual AE_*.BIN files(name).
--------
Ah, I just understand it. Now this code has no handring config files.
You mean copy AE_600DA.BIN and AE_600DA.CFG together. right?
It's easy to adding codes , but now I'm writting PTP codes. So some one please help me to writting codes.
Just added code for copy config file together. Not tested, someone test it please.
Thanks miyake, I'll test it on my 1100D after polishing a few things
Could this feature for selecting different Autoexec.bin's be used in the future, if you (the developers) decide to make custom ML themes/styles, so we could change Magic Lantern themes/appearance in the camera? Or do the Autoexec.bin's not matter for the appearance of Magic Lantern? I don't really know about them a lot, but it would be cool, if it was possible in the future to have different themes/appearance for Magic Lantern.
Basically yes.
But I think, if so, we need to manage a lot of different source codes. So I think the best thing is theme selecting function in menu interface.
Currently, this func is for emergency. It's a really short time but it has a risk for broken autoexec.bin(rename file).