Messages

We are not able to build .fir anymore.
It has bootflag enabled, so try to run a portable rom dumper in autoexec.bin format (do not put any .fir on the card).

If that boots then probably it can be done.

Another way is to switch flags via UART. In such a state if you try to turn on the camera without any card - it will appear completely dead. But it is not - there's a tool (FROMUTIL) running on UART port that allows you to change flags, flash arbitrary files and so on. If used unwisely it can brick the device to the point where physical soldering is needed, but in this case it is just a matter of using one option to toggle the firmware flag.

How did you end up in this situation?

Almost all stubs are functions (maybe all?)

Not all, there are some data pointers (vram info, etc)

No posts = no progress.

Ah, you refer to file naming counter. This doesn't reflect internal shutter count in any way (the one you get from CAM_INFO.XML). It only increases with each shot.

6D mk I:



From top to bottom:

Code Select Expand

1 EEKO_TX
2 EEKO_RX
3 ?? (3v3), trying to transmit resets ICU
4 ICU_TX
5 ICU_RX
6 GND
7 ?? (3v3)
8 MPU_TX
9 MPU_RX
10 ?? (3v3)


Code Select Expand

Dry> vers
DRYOS version 2.3, release #0051
  Dry-MK 2.60
  Dry-DM 1.20
  Dry-stdlib 1.52
  Dry-NET6 0.33 111125+4796
  Dry-ECI6 0.20+110927
  Dry-DNS 1.23pre 120130-4845
  Dry-DHCPC 2.23
  Dry-PX 1.09
  Dry-drylib 1.21
  Dry-shell 1.17
  Dry-command alpha 058

Code Select Expand


Dry> help
[Debug]
xd  xm  task  PCMcheck  PCMclear
[EekoLog]
GetEekoLog  PutEekoLog


Fun story: This was a dead camera body, no signs of life. After power was applied it immediately printed "UndefinedInstruction" on ICU UART in loop.
The issue was a blown fuse on power PCB. One of ICU RAM power rails was missing due to that.

Interesting though if resetting the count in menu resets the total count via this method?

There's no menu option to reset the count. It can't be done easily.

Where are you from?
If EU and willing to ship it, I can take a look.

Do you have rom backups stored from card?

GUI on HDMI output works differently, it doesn't cover the whole output.
IIRC in the past different models handled HDMI differently, and there are multiple possible HDMI resolutions. HDMI liveview (image) resolution is not tied to GUI resolution directly.

I assume this is a limitation of Magic Lantern source code that assumes all cameras have the same display resolution, which is not true.
Funny is that except LiveView, Canon does the same assumption (example: SX740 that scales gui horizontally to fill the lcd)

[1]

I think with that news I can say that we planned a Xmas 2021 development build for multiple Digic 6/7/8 models.
In fact just to achieve it I spent 3 weeks of last December working full time on Magic Lantern.

Here we are, just shy 4 days of November 2022 with first public build for just a single model.
I think that shows well two things:
- how complicated development is, and
- how small the team is right now

Thank you @names_are_hard for your hard work! I mostly wasn't able to participate during last 6 months, but I hope to get back on track soon.

[EOS 7D Mark 1]

EOS 7D Mark 1

This is actually a success story of unbricking 7D mk1 on our Discord channel.
Photos kudos to @roscombot, who is the owner of now fully functional 7D.

Back story - something had happened during a downgrade from 2.0.5 to 1.2.3 that made camera inoperable.
Story goes that this was many years ago when camera was still on warranty, and Canon service center was not able to fix it.

What we found is Master CPU was running 1.2.3 firmware and screaming about broken properties. Slave CPU was running 2.0.5 and waiting for communication from Master.
Long story short is that after some digging in QEMU and Ghidra we were able to successfully drop to FROMUTILITY menu and start upgrade from there. While downgrading everything to 1.2.3 did not solve the problem, upgrading to 2.0.5 fixed it.

Important notes are:
- one can start FROMUTILITY on both CPUs, but on Master it is broken (?) some options just hang, other appear to work but do nothing. Slave has more options.
- Thanks to Walter for poking around and finding Slave CPU UART. That was a key to unbricking this camera.

btw: Slave CPU runs GUI, etc... and MagicLantern also runs there.

[SX740]

Oh, I forgot to post SX740.
Unfortunately on PCB, requires a complete disassembly. Hard to solder without damaging traces...



EOS R5, under a plastic cover under the screen. FZC8, pinout same as EOS R.

I did not understand how camera behaves with no card and with freshly formatted card on PC.

Thing to check:
Remove .FIR file from Magic Lantern card, see if it boots successfully.
If not, make card bootable using EOSCard, retry.

This may get you into main firmware with Magic Lantern. Not a fix, but will tell us something more.

Another:
Have you tried just putting on Canon firmware update (.FIR file) on clean card (formatted on PC)?
As it boots in firmware update mode, "updating" firmware should fix the firmware and a flag.

From the recorded camera behavior + no responses from the seller I have a "scam" feeling.

I'm missing info what build are you using on those cameras. The fact that top LCD stays on is indicative of some crash/assert on shutdown, or hardware malfunction.

No offence, there were already assumptions from other people from CHDK world 

RP evprocs are listed in first post: https://www.magiclantern.fm/forum/index.php?topic=25662.0 R is very similar to that.

Maybe StartGyroRec? This is the closest "name" I can find - but requires checking in ROM.

M3 is PS base, don't assume cbasic interpreter means evprocs will exist on EOS firmware base.

No idea, unfortunately now I don't have a lot of time to do any development stuff, I just took the small opportunity I had to upstream SX740/R5 work.

If you have SX740, you can try yourself - code is already on dev branch of magiclantern_simplified repo. I don't remember what params needs to be set to GUI_SetImgComposition to enable JPG+RAW. But I found a partial crash log on Discord, and it was indeed an assert:

Code Select Expand

    10806:  36140.093 [SHTD] ERROR SemTimeOut SetJpegDispEncodePathForRawJpeg
    10807:  36140.144 [STARTUP] ERROR ASSERT : Warp::ShtDevCommon.c
    10808:  36140.323 [STARTUP] ASSERT : Task = ShootEncodeSub
    10809:  36140.330 [STARTUP] ASSERT : Core 0
    10810:  36140.334 [STARTUP] ASSERT : Line 125
    10811:  36140.338 [STARTUP] ASSERT : bFlag
    10812:  36140.346 [STARTUP] < StackDump >

EXIFTOOL shows 71mm.

Windows shows 7mm, see my screenshot / "Długość ogniskowej" = Focal Length. Though other parameters doesn't make any sense, like 60s expo... yes, for sure.

7mm from EXIF should be about right, as it was quite wide and lens is 4.3-172mm.

No, I had no time to dig into that RAW more. Most likely it needs a rom patching in a few places to get it right.
Like enabling CR3+JPG gives ERR70 after a shot attempt, which is for sure code hitting some assert.

https://twitter.com/_kitor/status/1533767862531268608

WIP PR open: https://github.com/reticulatedpines/magiclantern_simplified/pull/62

This already has some challenges to be solved. At this state none of the features work (ok, I lied, it can display connected lens info )

On the other notes I have a lot of Digic 8 ML code working on SX740, but also have a nasty crash that I can't trace yet. Thus for now it lives on branch in my fork.

It is always a stub. This time FreeMemory was bad. PR opened, including unsafe CR3 experiment. Merged to dev branch.

Since Names_are_hard is experimenting with MMU and ROM patches, it may become safe(ish) in near future.

Digic X models have no Resource Manager (it got replaced with a brand new solution - RscMgr2) and somehow maps memory into 32 bit address space + offloads a lot of memory transfer using some new interfaces (IBus)

It is too early to tell anything about those, except that effort will be significantly higher than for D78.
We may also hit some more important roadblocks, but I can't/won't tell more unless someone have R7/R10 in hand.

We can run code on these but not as much work has been done, no active devs happen to have D6.

Turns out it is enough not to commit for 5 days to become inactive dev My 750D is sad.

Yes, definitely something Digic 78X. I consider D6 lost generation due to hardware differences - but from effort PoV IMO it makes more sense to do 78X and backport things to D6 where applicable.

M50 yes, but again - UART hard to access, and since we don't have a proper emulation - it is in "very nice to have" category.

800 eur is definitely RP, and maybe even R territory. I think R is (obviously) the best understood so far in D8 generation, and almost everything up to now was easy backported to other D8 models + a lot to D7 and DX.

M50 from hardware PoV is very similar to R. While we don't understand the new EDMAC controller, channel configuration is almost 1:1. There's "just" half of the RAM available.

I also think that due to lack of IBIS but yet a very good sensor, R will drop in price quick and become a very popular 2nd hand model.
And being honest - IMO all three categories doesn't mean anything - the first body to get the features will become the popular one - just because we don't have anything for D6+ right now.

Thus the discussion point is if it makes sense to spend time trying to reverse engineer more similar models at the same time, or keep the effort more focused to have something concrete that is then relatively easy to port elsewhere. Of course that is up to you

Side note: it will be great to have someone on board with prior knowledge on EDMAC and so on. From people who contribute to D6+ world, we have no idea on how exactly it worked previously which makes it twice harder to reverse engineer for the "new world" models.

I believe the issue is with the country Bilal lives in and thus shipping + import taxes are this another $100+
If I ordered that specific offer into my country I would pay extra $70 in shipping and $50+ in taxes.

Most of developers are IIRC located in eurasia, thus US prices are not a good benchmark...

I don't want to shatter your dreams, but forget about it.

I can agree that it is mostly complete out of the box. From the list you provided, maybe 30 minutes limit can be removed the same way as on previous generations.
Other things - unlikely to happen.

Please bear in mind that Digic X is another generation of unknown hardware - but this time capable of doing raw natively. And as I stated before, a fundamental part of OS (Resource Manager) got completely replaced, which will break a lot of things. Not to mention that RAW is R5/R3 domain only - we don't touch R3 and as of R5 goes I am the only dev here with R5. And with a lot less time to invest lately due to "away from keyboard" stuff

- Canon Raw recording through USB port for USB SSDs (Jus a routing from CFexpress to USb or even a dual recording).

Impossible. CFExpress is just DMA over PCI Express, USB - even if camera had USB host functionality (and to my knowledge it doesn't) handling overhead and lack of implementation would be most likely too much to achieve it without a significant effort - if possible at all.

From the glimpses of new File I/O I saw - it seems that file I/O is hardware accelerated now (probably DMA using what is called IBus - Image Bus?).

Yes, I know Magic Lantern is famous for crossing items out of "troll questions" list, but if comparing against "well supported" generations, Digic 6 and newer models are in "early 2011" state of things, or worse.

Not sure what your point is, but OP (and others) have problems with ML documentation.  OP came to the forum to find an answer to a problem caused by incomplete ML documentation, and instead of getting straightforward help, it was suggested that the problem was his fault.

Magic Lantern is lacking everything:
* user friendliness
* user documentation
* support
* code review
* developer documentation (!)
* manpower to continue this project

As far as I'm concerned, due to its hackish nature it was always designed for "technology nerds", not for "general public".

What open source developers do is what they consider fun. If project assumes user had to have at least a bit of skill, then technically it is user fault if he doesn't.
https://mikemcquaid.com/2018/03/19/open-source-maintainers-owe-you-nothing/

There's a reason it is almost a year since Alex last logged in. User expectations are different than authors intentions, and it is devs who give you something to play with zero promises.

On the other hand - wiki is publicly editable. Feel free to improve it.

Yes, it should -- because of the problem with the instructions that is the cause of this thread.

And this is a different view from experienced dev vs user. No, it shouldn't.
Reason is simple - even now people think that Magic Lantern is installed into a camera. And whenever camera fails (99% of the time cause being not related to ML), we are accused of failure.

I see no way to explain to a technology noob why "firmware update" is not a firmware update, and what bootflag setting means + why it just can't brick / damage a camera.
If you can - please add a section to wiki. Everyone will benefit from that.

This is a difference between developer and user. The thing you see is "user friendly" may be actually damaging for project reputation. Yes, I'm probably exaggerating in that particular case, but when you know how it works from the other side, you tend to choose the words more carefully.

because most folks go to YouTube videos by @Zeek and others that show them how to do so -- they don't use the vague/incomplete ML instructions.

You see - those people do a great work. But they do it on their own, in their own medium.

You highlighted a very important issue here - there are people with knowledge, but there's not enough people who contribute that knowledge back to the project.

Those instructions should probably add:
"Go to the 'firmware' selection in the menus (usually in the gold 'tools' section of the menus), and update the firmware."

No, they shouldn't - because there's no actual firmware update performed. This is just a way to execute a program on stock camera.

It's not the "opposite" -- it just doesn't give any clue on how to "Launch the Firmware Update process..."

Because that may depend on model. It, in fact, didn't - however ML (unfortunately) is not a beginners tool, so finding how to execute firmware update is quite an easy task.