Etiquette, expectations, entitlement...
@autoexec_bin | #magiclantern | Discord | Reddit | Server issues
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Really? DUMP_M50.FIR isn't working for you? Maybe try a smaller SD card though the new dumper should be able to work on the larger cards as long as it is formatted as FAT32.
edit: updated ROM dumpers (SX740 untested):
and uploaded FIRs for getting the CPU info:
Great work, @leathc!
The M50 also has a serial flash, so one of the next steps is dumping its contents (easy; one way is to adapt this code on the minimal codebase, which is not able to load modules yet, and the other is to work from the "recovery" branch, i.e. directly from bootloader). Probably not a very straightforward task for a newcomer, but it's not very hard either.
I have the green screen running on QEMU for the M50, but I can't get the screen you posted.
I had no idea it was this far along. Feel like we were just given the password to get into a speakeasy and now it is time to get drunk.
A couple of forum topics that will help get your Mac up and running in a hurry:
Setting up a Magic Lantern development environment on a Macintosh
Magic Lantern development compiler.app (Mac OS)
PM me when you get back to LA if you want to get together. I live nearby in Redondo Beach.
I keep thinking about getting an M50 for my next ML project--once the M2 is up and running.
Docs:
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst
However, that easy coding task mostly applies to models other than M50 and 200D. The current experiments are working out of the box on these two cameras; it's the other 3 models that could use some help from the community in order to reach the same stage.
I have yet to commit the emulator bits for M50, but I've got most of the stuff working locally (including file I/O after manually calling the initialization routine from the serial console). For now, you may run the ROM dumper and follow the steps from the "Initial firmware analysis" section in the docs. ROM layout and startup code on M50 are pretty much identical to DIGIC 7 (to the point that some stubs are identical with 200D).
Once you are ready to run this code on your camera, I can prepare a tool to enable the boot flag (for any model from this thread).
So far, the worst case I've recovered successfully was a Canon firmware update interrupted in the middle (i.e. not caused by ML). Last time I've unbricked a camera was two days ago (an EOS M with invalid video settings; ask Danne for details).
Docs:
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst
However, that easy coding task mostly applies to models other than M50 and 200D. The current experiments are working out of the box on these two cameras; it's the other 3 models that could use some help from the community in order to reach the same stage.
I have yet to commit the emulator bits for M50, but I've got most of the stuff working locally (including file I/O after manually calling the initialization routine from the serial console). For now, you may run the ROM dumper and follow the steps from the "Initial firmware analysis" section in the docs. ROM layout and startup code on M50 are pretty much identical to DIGIC 7 (to the point that some stubs are identical with 200D).
Once you are ready to run this code on your camera, I can prepare a tool to enable the boot flag (for any model from this thread).
If anyone is looking for some low-hanging fruit to get started with development, the new stubs are relatively easy to find and they can be tested in QEMU
