CF card not detected by computer anymore after attempting ML install.

[ilia3101]

I bought a canon 5D mark II, and installed ML succesfully on one card. I then copied the ML files from that card to a new card, hoping to save some time this way, by preserving the settings. I then ran firmware update from the new card and nothing happened. ML was not installed, but the red light now turns on now every time I use this card with my 5D2, so the camera is doing something ML related with that card. But my biggest issue now - computers refuse to read that card. My 5D mark II and III can read and write it just fine, but my mac and windows computers just don't see it. I am going to get a different card reader, just to make sure. But does anyone know a fix to this? Ideally without formatting the card... as I have some things I want to copy from it first.

[Walter Schulz]

Working hypothesis: Cardreader defunct.

Fits perfectly to issues as observed.
If so-> Unrelated to ML or cam.

To be falsified by: Running another CF in cardreader. -> Option not available.
To be verified by: Replacing suspicious component.

[ilia3101]

Thanks Walter

It still works with the other card though...

And ML failed to install on that card (I think I went the wrong way about installing it).

But I hope you are right

[Walter Schulz]

Both are UDMA-7 cards?

[ilia3101]

Ahh. No. The old card is not UDMA 7, the one I'm having problems with is an UDMA 7. It worked before though (I used this card reader to copy ML files to it)... But I'm now getting more and more optimistic the the card reader is the problem

[Walter Schulz]

Yes, there is a chance cardreader is the culprit. But cannot exclude UDMA-7 card acting up, too. My knowledge how 5D2 and 5D3 handle UDMA protocols is non-existent.

And thanks for asking! Good to have you back!
BTW: Discord is a faster communication channel.
We hardly use forum for anything else than documentation, long term things in general anymore.

[ilia3101]

Thank you for all the help and useful info! I will update what happens with my new card reader. This one is USB 2.0 and pretty outdated (but not old), so might be UDMA 7 issue too.

Good to know about the Discord. I will miss the days of the forum. Felt easier to keep track of threads and posts

[names_are_hard]

The forum is not gone, it has just slowed down   It's better for some things.

Discord is best for fast discussion - get an answer in minutes, not days!  Forum is good for longer storage of partly understood research.  I regularly post my progress:
https://www.magiclantern.fm/forum/index.php?topic=26814.0
https://www.magiclantern.fm/forum/index.php?topic=27258.msg247336;topicseen#msg247336

But forum was never a good place for documentation; e.g. you had to read 100 pages in 5 different threads to learn about EDMAC.  And the early pages often had mistakes, because it was exploration.  Wiki was better for docs, but still not great (formatting limitations, hosting problems, plus we have two different wikis...).

I am trying to write clear developer docs here: https://github.com/reticulatedpines/magiclantern_simplified/tree/dev/developer_guide
Having a single place for a dev guide makes the most sense to me.  Keeping it with the code it documents make it easy to find and possible to keep in sync.

[ilia3101]

@names_are_hard I love what you're doing! And yeah, that's true about reading forum threads outdated information Half of my knowledge was from reading incorrect/outdated forum posts back in the day

I had a go at compiling ML from simplified, and it didn't go well. Are we still stuck with using a very specific gcc toolchain? My problem was gcc not finding headers. But it might be to do with me attempting to use the basic arm-none-eabi-gcc from homebrew (mac).

Also I think I found some unecessary includes, like <stdio.h> in fio-ml.h, it seems to unly be used for the definition of FILE for file handles, but that's wrong because ML doesn't use the stdlib file type anyway. So you might as well replace it with something like this:

Code Select Expand

typedef void FILE;
Also, saw some over-specific non-C-standard (i think) includes which could have been replaced by stddef, etc. Maybe fixing little things like this could make compiling easier from other platforms like mac?

And what happened to 'make zip'?

Anyway, should take this to discord haha

[ilia3101]

And about the card - I managed to save my files by copying using file_man on a 5D3 with two cards. But formatting the card didn't fix it. I think the card is broken (it's a komputerbay 128gb 1066x). Can't make any card reader see it. Only my Canon cameras can read it, and the red light blinks even tho there's no ML on it.

[names_are_hard]

Hopefully the 2025 release will bring a few more people back, and we can improve the docs even more

I'm glad you asked about building   I did a lot of work improving and modernising this.  But we have no regular testers on Mac.  I do fix bugs when reported, so I would hope it still builds.  I removed several thousand lines of Make (!!) and some of this was related to auto-detecting build environment (badly).  This removed many targets that as far as I know, nobody used.

You don't want to use weird old versions of tools anymore.  gcc 14 and arm-none-eabi-gcc 14 work well for me.  All versions from 8 upwards were tested.  I'm not trying to maintain backwards compat for the toolchain, but 12 and 13 were used recently so anything in this range should be fine.  If you were using linux you would want to install these packages:
build-essential gcc-arm-none-eabi python3 python3-docutils python3-setuptools zip

Then, be in platform/ or platform/some_cam/ and run: make -j8

"make zip" no longer exists, zip is the default target.  Note that build output now consistently goes into build/ subdir.  No messy binaries output next to your source files.  There is some dependency I didn't capture in the build refactor meaning that you have to manually clean modules in some cases if you're building from platform/ or platform/some_cam.

Building one cam (if modules are unchanged) should take about 2s.  This is not a bug.  I made the build a lot faster.

File header redundancy is entirely plausibly a bug, but also, the build works and it would be very low prio to fix.  Unless it's causing a bug for you   Let me know how you get on.

For card: tried low-level format with overclocking disabled?  (OC probably shouldn't matter, CF, but this is the cleanest test).  Possibly, backup files first and md5sum compare with original ML files.  I've seen strange cases of corruption that give similar cam behaviour.  But not breaking other card readers detecting card, so, dunno.

[Walter Schulz]

I think the card is broken (it's a komputerbay 128gb 1066x). Can't make any card reader see it.

If you go for a replacement: I purchased some Integral Ultima Pro 1066x lately and they perform very well so far. And here in Germany they offer a very good price/GB ratio.
128 GB goes for 63 Euro and 256 for 129. Two weaks ago price for 256 variety was 93 ...

Komputerbay 1066x CF cards come with a warning label: Do not use in UDMA-6 devices. Or else!
They will get damaged. 5D2 got an update to handle UDMA-7 cards nicely.

[ilia3101]

@Walter I've had this card for at least 5 years. How come the firmware update didn't save the card from being damaged then?

@names_are_hard Just checked. Neither my 5D2 nor 5D3 can low level format a CF card. It's only an option for SD cards with the 5D3 it seems.

Also, downloading the arm toolchain from the arm website fixed the compilation issues. I think the home-brew one is missing something.

I also had a problem the python script. Seems distutils (which is used to check different versions of the rst2html command) was removed from python standard library in 3.12.

Installing setuptools provides that functionality now:

Code Select Expand

brew install python-setuptools
(Also installed docutils using homebrew a while ago)

Then I didn't have readelf, which was installed with

Code Select Expand

brew install binutils
But for some reason that wasn't added to path so I had to set READELF in makefile.globals to '/opt/homebrew/Cellar/binutils/2.44/bin/readelf'

STAT_CMD in makefile.globals also had to be changed for macOS:

Code Select Expand

STAT_CMD = stat -f "%N: %z bytes" for compatibility with macOS
Now it works. Despite these small issues, compiling is easier than ever with your repo. Glad you removed all that makefile slop. Looking forward to releases!

[names_are_hard]

Ah, that makes sense about low-level format.  SD devices are much closer to raw NAND flash than CF.  IDE hides the block level stuff.  Still, you may have file system corruption that a quick format won't fix.  Have you tried fsck (or whatever this is on Mac)?  A "non quick" format should also replace the lower level filesystem structures (and of course delete your files ).  I have seen a corrupted filesystem give very similar behaviour.  Failure during ML load leading to hang, even after I replaced the ML files.

Good to hear it compiles fairly easily.  There are no active devs using Mac, so test reports are rare.

These differences due to Mac being BSD derived and having weird paths are annoying to fix.  Since we have a dependency on python3, one option might be to replace these with python equivalents we manage ourselves.  Easier to be cross platform that way.

I'm running python 3.13 and it builds fine here.  I see a complaint about distutils re find_executable, but this is non fatal, only a warning.  Worth fixing but shouldn't cause you an actual failure.

I'd accept issues for replacing stat and fixing the DeprecationWarnings for modules: https://github.com/reticulatedpines/magiclantern_simplified/issues
I want to fix these anyway, but if you don't raise them I'm likely to forget.

Readelf looks more annoying to fix and I blame Mac for not having it in path.  Is the error message obvious?  If not, I would consider that a bug, it's easy to tell the user "readelf is missing or not in path".

A nicer solution for you is get your shell to add it to path, rather than polluting the repo.  I removed Makefile.user because I didn't want to support whatever random config people may apply!  If you find bugs in builds from a clean copy of the repo, I know it's some problem due to Mac build env, and I'll want to fix them.  If you've made changes to repo files, I can't be sure those are causing the problem.