Thanks to g3gg0 it's coming soon now, so it's time to open this topic... :-)
I've already built 7D ML from the latest source and started to check the features.
What is the workflow of the developing?
The current problem is how to enable the bootflag without having to distribute Canon code.
Currently, user code runs after loading the FIR, but the camera gets restarted after a very small period of time (g3gg0 estimated 50ms). It's probably not safe to alter the ROM in this situation.
Indy's solution was to post a bspatch. I don't like to use this idea for regular users (for developers may be OK) because:
1) it's not that easy to use
2) it enables other users to do a derivative work from Canon's copyrighted code (the updater); if they post it online, I smell trouble.
Point 2) applies to any program that patches the original firmware IMO.
I see.
I enabled the bootflag on my camera with a patched firmware update too.
Hmm. And we cannot make a magiclantern.fir file as for the other cameras...
Quote from: Pelican on October 02, 2012, 12:41:29 PM
I see.
I enabled the bootflag on my camera with a patched firmware update too.
Hmm. And we cannot make a magiclantern.fir file as for the other cameras...
you enabled the flag on 7D? Or did you enable it on models where we can run our own (not canon patched) updater code?
thats the problem on 7D. we can run our updater code, but it seems we must do some special comm, else the slave cpu gets reset.
i dont know if it is IPC comm with master processor, or if it is some watchdog or whatever.
the "normal" firmware boot with ML enabled is now possible because of the ipc command register, we have to write with 0x80000010. see reboot.c.
if we don't write that command, both digics are out of sync and firmware will halt.
(see http://magiclantern.wikia.com/wiki/Register_Map in section IPC - there is a list of Slave->Master commands
written to that register.
a more cleaner version of that missing piece for 7D looks like that:
/* clear IPC interrupt lines */
*(volatile int*)0xC0A0000C = *(volatile int*)0xC0A00008;
/* send command to master processor, so it is in right state for rebooting */
*(volatile int*)0xC0A00024 = 0x80000010;
/* wait for interrupt */
asm("MCR p15, 0, R0, c7, c0, 4\n":::"r0");
/* clear IPC interrupt lines */
*(volatile int*)0xC0A0000C = *(volatile int*)0xC0A00008;
Quote from: g3gg0 on October 02, 2012, 03:04:44 PM
you enabled the flag on 7D?
Yes, I've enabled the bootflag with the original Canon 1.1.0 fw updater patched by TH (or Indy?) wich makes the ROM dumps.
very good :)
at the moment i am focusing on how to make the first alpha user-ready.
features and how good they are working are explained here:
http://magiclantern.wikia.com/wiki/7D_support
many features work fine, some not due to property setting is still disabled.
(enabling property setting could cause some unrecoverable error!)
as soon there is a clean way to run ML without patching/distributing canon code,
i will head over to the alpha feature set. this means i will disable all the functions that
are not working clean or dont work at all. (like alex' 5D3 alpha)
And why you cannot purify the updater fir to a very very basic one which would set the bootflag only and do nothing else?
It could contain almost none Canon code.
(That was my idea to run ML long time ago: put the whole ML to the updater and run as a fw update, but never got working.)
do you mean to keep some basic canon code that statisfies the wdt behavior?
then we still have legal issues. so this is a (almost) no-go
if you mean we should jump to reset vector/firmware from our updater1 context, then
we still have the problem i am stuck at - master processor is in a different state due to
the slave bootloader sending it there right before the .fir gets executed.
the commands sent before executing .fir updater1 (slave side)
0x80000052 (fromutil_ipc_wakeup)
0x80000031 (before entering autoexec.bin)
to undo: 0x80000010, then boot normal firmware
0x80000034 or 0x80000030 (before entering FIR load code)
to cancel: 0xC8000000, then continue fromutil
0x88000001 (when going to load .FIR)
to cancel: 0xC8000000, then continue fromutil
0x98000000 (when going to execute .FIR)
0xB8000000|fir_length (when going to execute .FIR)
0x80000040 (when going to execute .FIR)
to cancel: no idea
when bootflag is set and our autoexec.bin was executed, we simply
can send command 0x80000010 and can continue normal boot.
when updater1 gets executed - we are already at bottom of the list. 0x80000040.
and i have no clue (yet) how to go back
and the problem we have everywhere - there is some watchdog. either master processor is resetting us
or there is some dedicated WDT module
This patched updater does its job and right after the camera restarts.
No hang up just restart.
It could be enough for us, isn't it?
I mean you don't have to return from updater1...
I don't remember how the dumper code ended but you can check it.
code from the end of dumper.c:
...
abort_firmup1();
LOG();
abort_firmup2();
LOG();
uint32_t dummy = 0;
reboot_icu( 0x80010003, dummy, 4 );
...
Maybe this is how you can finish the fw update...
i tried another way. and the results look promising :)
Good to hear... :)
was able to boot ML from fir ;)
will release a video in a few minutes.
about the technical details:
i couldnt get further with resetting master processor into the fitting state.
no idea how to get that done, as the master updater already was running.
so i decided to replace master updater code with a plain reboot into firmware main at 0xF8010000
whereas the slave does the same with magic lantern enabled.
one + for this methos is - we can also hook master firmware now using cache hacks ;)
but only as long we run ML from .fir. when switching to autoexec.bat, this feature is lost.
but that would help to get e.g. a bootrom dump from master processor.
Congratulations! :)
Waiting for the video...
will appear here in some minutes:
http://youtu.be/cyZRC16XEQw
Congratulations, you seem not to sleep ... everyday surprises us more ... every day more big news ...
haha "you seem not to sleep" - you sound like my girlfriend ;)
well, this demonstrated .fir wouldnt have been possible if indy wouldnt have made that great tools for replacing updaters
and also if trammels initial work on the 7D had failed and we wouldnt have any bootrom dump.
i just put the missing piece of code between some lines ;)
you're our hero lol
good work
yeeha
using the FIR method i was able to hijack both processors.
so i am running my own RPC handler on both devices.
one ML can send commands and data via "official" RPC interfaces to the other processor.
e.g. triggered via RPC call the code
"master_write_memory("ROM1.BIN", 0xf8000000, 0x00800000);"
on the master processor.
master_write_memory is a canon function that uses FIO_WriteFile over RPC to write files on slave device.
so i was able to dump the master processor ROM (8MiB)
Sorry to intervene, but WOW, does this mean that you can take advantage of BOTH processors of the 7D?? Will we be seeing awesome features because of their power??
I'm checking the forums every day.. and I never thanked you.. THANK YOU!!!!!!!!! YOU'RE MY HERO!!!!
Quote from: tonybeccar on October 03, 2012, 07:20:43 PM
Sorry to intervene, but WOW, does this mean that you can take advantage of BOTH processors of the 7D?? Will we be seeing awesome features because of their power??
I'm checking the forums every day.. and I never thanked you.. THANK YOU!!!!!!!!! YOU'RE MY HERO!!!!
i guess there will no awesome features, just more problems when it comes to special features that need to access the correct digic.
Well done G3gg0. Amazing work!
I am waiting for this moment for 3 years... 8) OMG!
Unfortunately I'm very busy with a special Nikon camera mod/remote right now, but after that I'll jump right into the 7D ML source...
I was playing with ML this afternoon and found an interesting bug.
When minute changes in the camera's clock the Date/Time/Zone menu item displays the top of the ML stuff.
It happens only when the Date/Time/Zone menu item selected in My Menu settings.
The position of the Date/Time/Zone item on the ML screen is the same as on the My Menu screen.
It shows on ML menu only less than a second but stays on the ML info screens (because these are drawn once?).
i didnt fix that specific bug yet, thanks.
in meantime you can apply this patch to current source tree:
http://upload.g3gg0.de/pub_files/d97c09226e2de63d370d0b59c8399934/7D.patch
there are a lot of other fixes.
also those features that dont work yet, are disabled.
Do you want access to the bitbucket repository?
(patch pushed, hope you don't mind)
Thank you! (Both of you)
It's working... :)
ah nice, thanks :)
Quote from: nanomad on October 05, 2012, 09:03:03 PM
Do you want access to the bitbucket repository?
sorry forgot to answer.
already talked to alex about that.
in theory "yes". but as i didnt work with mercurial yet, i would probably break something ;)
i am used to CVS/SVN, but not to this client.
no rush :)
and here the latest patch.
http://upload.g3gg0.de/pub_files/3747c82d249e973381434c45ba75a43d/7D.patch
fixed a lot of details.
Thank you! 7d owner always wanted to have ML on it. What your are doing is great. Any chance ti have Fps overide on the 7d one day ?
Quote from: joespace on October 07, 2012, 01:00:24 AM
Thank you! 7d owner always wanted to have ML on it. What your are doing is great. Any chance ti have Fps overide on the 7d one day ?
thanks.
for what i know now, it seems to be a lot of work again, as the known timers are not used for fps timing.
so i think it will take its time to find that out. maybe next year ;)
Quote from: g3gg0 on October 07, 2012, 12:09:46 AM
and here the latest patch.
http://upload.g3gg0.de/pub_files/3747c82d249e973381434c45ba75a43d/7D.patch
fixed a lot of details.
Merged ;)
Getting a working arm toolchain on centos 5 is a PITA. Hopefully I'll have a working arm toolchain tonight.
This latest doesn't work for me.
Without the splash bmp:
Freezing in sensor cleaning. If I skip sensor cleaning then the camera can work but no display.
With the splash:
Splash screen appears for half of the second (but the "alpha" text is plain purple) after that the display turns black but still on and remains on this stage forever (no menu, no info, no play) Camera works otherwise.
If I skip the sensor cleaning (and the splash) then the camera and ML works normally.
I want to be sure that my compiler makes the same code as others so could anyone of you send me an autoexec.bin for 7D?
@phiber:
you cannot run this on "normal" 7Ds as the bootflag is not enabled. (or is it?)
@Pelican:
true. didnt test it with sensor cleaning.
thanks for pointing out!
will provide an update
Is it safe (and easy) to install it on my 7D right now ?
You guys are doing great job. As i don't know how to help, i made a small donation.
@joespace:
you cannot run this on "normal" 7Ds as the bootflag is not enabled. (or is it?)
As a didn't understand what does bootflag stand for ... i better wait for an official ML release for the 7D. :D
Quote from: g3gg0 on October 07, 2012, 11:57:08 PM
you cannot run this on "normal" 7Ds as the bootflag is not enabled. (or is it?)
I'm sorry, but what does "normal 7D" mean? As far as I know, there's only one type of 7D camera, am I wrong?
Also, what is the bootflag and how can it be enabled if needed?
Quote from: Toni on December 05, 2012, 06:03:07 PM
I'm sorry, but what does "normal 7D" mean? As far as I know, there's only one type of 7D camera, am I wrong?
Also, what is the bootflag and how can it be enabled if needed?
there are developer models that have the bootflag set.
also there are some cameras on that we enabled the boot flag.
boot flag = load autoexec.bin (ML) from CF card on startup
Quote from: g3gg0 on December 05, 2012, 06:06:13 PM
there are developer models that have the bootflag set.
also there are some cameras on that we enabled the boot flag.
boot flag = load autoexec.bin (ML) from CF card on startup
OK. And can it be enabled on all "normal" cameras? How?
Also, what is a "developer model"? Do you mean some models used only by Canon developers?
Quote from: Toni on December 05, 2012, 08:19:05 PM
OK. And can it be enabled on all "normal" cameras? How?
Also, what is a "developer model"? Do you mean some models used only by Canon developers?
as soon ML for 7D is stable, we will have some sort of FIR that enables bootflag on every camera out there.
yes, "developer model" i call those used by canon devs.
Wait, developer mode, as in used by Canon when they work on 7D?
What does it do?
its the boot flag....
My 7D* surely a developer model because I use ML from autoexec.bin. :)
*D=Developer
OMG I don't know how you guys do it... how do you hold back? :o
Quote from: Stedda on December 06, 2012, 01:52:46 PM
OMG I don't know how you guys do it... how do you hold back? :o
you will get it as soon its comes out of alpha state.
Oh I'm not asking about the firmware, I'm not one of those.
I'm asking about the stupid questions...
Quote from: g3gg0 on December 05, 2012, 10:30:37 PM
as soon ML for 7D is stable, we will have some sort of FIR that enables bootflag on every camera out there.
yes, "developer model" i call those used by canon devs.
OK, thanks a lot :)