Messages

and here the latest patch.
http://upload.g3gg0.de/pub_files/3747c82d249e973381434c45ba75a43d/7D.patch

fixed a lot of details.

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

ah nice, thanks

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.

i am preparing the alpha.

depending on camera model, "analog ISO" goes up to 1600 or 3200.
if you go over this value, its just "digital ISO" which can be done in post also.

assuming you shoot RAW

could be easier on 7D

no idea, time will show.
but i dont expect more than 10% higher fps.

ML - and what this forum and their developer stand for - is a firmware addition to add cool and necessary features.
anything like porting firmware to other models is beyond our scope and has a higher risk of legal actions.

as far i can tell, most people here would agree to that.
if a developer is willing to do that - its his own private business.

Please give us ML for the 1D-X ! With clean HDMI out and 4K 24p/25p/30p video.

Now that you have overcome the problem with dual digic processors (7D) and you have ML running on the 5D3 (digic5),
I hope ML on the 1D-X will be possible soon.

I would gladly donate more (much) money for this to happen.

how about a 1D-X?

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.

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)

Any news on that?In this thread there are some guys who understood the protocol pretty good, maybe this helps.
Also they provide information on how to implement a chip that converts the 19 back to an 18, which let's good old Sigmas work again

Unfortunately it's a german forum, but if someone is interested in it I could try to translate some parts

well, i am german.
that are 50 pages :-/

as far i can tell, they replaced the commands 19 with 18

18 Aperture Analog
19 Aperture Digital

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

will appear here in some minutes:
http://youtu.be/cyZRC16XEQw

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.

i tried another way. and the results look promising

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

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)

yep, isnt that the dma_malloc structure of pointers to previous/next/top blocks?
thats the reason why all HD_BUFFER pointers end with 0x...80

your right, here is a stream from the 600d. Lets start with frame 1 0x42100070 just above this frame there is a line with 2 addresses and other information, the addresses are 0x42100010  and 0x42310110. here's a table with the address of the frame and address just above the frame.
Frame1 0x42100070               0x42100010, 0x42310110
Frame2 0x42130080               0x42100060, 0x42190090
Frame3 0x42160090               0x42100060, 0x421c00a0
Frame4 0x421900a0               0x42100060, 0x421f00b0
Frame5 0x421c00b0               0x42100060,0x422500d0
Frame6 0x421f00c0                0x42100060, 0x422500d0
Frame7 0x422200d0               0x42100060, 0x422B00f0
Frame8 0x422500e0               0x42100060, 0x422B00f0
Frame9 0x422800f0                0x42100060, 0x422e0100
Frame10 0x422B0100               0x42100060, 0x42310110
Frame11 0x422E0110               0x42100060, 0x42371030
Frame12 0x42310120               0x42100060, 0x42370130
Frame13 0x42340130               0x42130070, 0x42370130
Frame14 0x423d4160               0x42130070, 0x42404160
And
0x42100010               0x43fffff0, 0x42100060

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:

Code Select Expand


        /* 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;


[16]

i updated the main post.
the package is now available here and gdbstub is avaible via menu id 16

i found a severe bug that i have fixed now (one kind of STRH wrote a whole word...)
but i am sure, there are still some bugs

How can I have access to your SVN?

eeerh, thats in the first post

done -> http://www.magiclantern.fm/forum/index.php?topic=2940.0

[eventually]

I promised to have a look at how to add a GDB stub into magic lantern.
looked quite simple to do, so i implemented it.


as it is a quite big thing, please understand that i cannot publish a full guide to this tool.
also it is (very) far from perfect.
see it as a tool that helps you to breakpoint into a specific function, get the memory/stack/register contents and
*eventually* continuing the execuion.
latter wont work reliable on the camera, as it is some complex realtime system.
we cannot simply halt some tasks without side effects like ERR70 or even total lockup.

but i was able to test some basic breakpointing, changing registers and continuing in some test task.
in canon tasks it did sometimes lock up everything.

the way how i implemented it does not perfectly match how gdb frontends expect it.
that would mean we would not simply set a BP wherever we want (no interrupts!) and wait for some task(s) being stalled.
i intentionally decided not to do it like they expect as i had some special goals using that code.
i want it to be a swiss tool to e.g. hook code anywhere in ROM for testing purpose or capturing registers etc.

nevertheless it may help with inspecting "what are the parameters to this function?"
you can also add "watchpoints" that are breakpoints that trigger once and save the registers.
this feature is not yet available via GDB interface, but you must call the functions manually using
   gdb_add_bkpt(uint32_t address, GDB_BKPT_FLAG_WATCHPOINT | GDB_BKPT_FLAG_ARMED)
and then read the captured registers from gdb_breakpoints[pos].ctx
but you can very simple extend the gdb.c to allow setting such watchpoints from your favorite GDB frontend.


be warned - you will have to repower your camera very often

here it is:
magic lantern code: http://upload.g3gg0.de/pub_files/8e155ddcc88ee690cd07b6c2da365807/gdbstub.zip
ptpcam: use the one inside the contrib folder of the repository (as of 2012-10-16)
(Merged) updated tasks.h: http://upload.g3gg0.de/pub_files/4015304003c3c336e66f651e1418439e/tasks.h
(Merged) ptpcam patch: http://upload.g3gg0.de/pub_files/92879a741f5b8863da832ca8fe9327db/gdb.patch

how it works:
* it adds two new PTP messages PTP_CHDK_GDBStub_Download and PTP_CHDK_GDBStub_Upload (defined for 600D)
* "void gdb_setup()" is starting the processing task that handles GDB serial commands - call it from e.g. run_test
* ptpcam has 3 new commands "gdb s" to send gdb serial commands, "gdb r" to receive the response and "gdbproxy" to forward gdb commands between a network socket and the camera (for remote debugging using e.g. IDA)
* breakpoints are set using cache hacking - i place a undefined instruction that raises UNDEFINED interrupt
* in UNDEFINED interrupt, i stall the running process using continuous msleep(1) and *store* the process context
* when that process is resumed, i use another UNDEF instruction and the handler to *restore* the process context where it was stalled

important notes:
* it is not possible to continue a process as long the breakpoint is still active. deactivate the BP, add another one behind the current PC, continue and then set the first one again
* there is no "single step" functionality - the camera will do nothing
* some tools (like IDA) update newly set breakpoints when e.g. "single step"ing and they fetch the current registers - so consdier "single step" as some kind of "refresh" or "sync"
* do not (!) set breakpoints in interrupts. that wont work.
* if you just continue execution in e.g. IDA without setting any breakpoint, IDA will wait. and wait. and wait. ... until you kill the network connection by exiting ptpcam or killing IDA (this break could also be done with a menu in ML to break the wait in in gdb.c:1159)
* this might also happen if the "continue" command failed for some reason (i warned you that it wont work reliable )

how to debug:
* call "gdb_setup()"
* start "ptpcam --chdk"
* enter "gdbproxy"
* connect to localhost:23946 using your favorite debugger
* you will see all the registers 0x0000..
* set a breakpoint in the function you want to debug
* "sync" using single step to activate the breakpoint
* "sync" again to get current process registers - they will change if breakpoint is reached
* you must now disable the triggered breakpoint and set a new one where you want to stop again
* "continue" execution until BP is reached
* some frontends like IDA allow "step over" commands that automatically set a breakpoint after the current instruction - this is supported of course

example code that displays all breakpoints and registers on-screen:

Code Select Expand



    while(1)
    {
        uint32_t line = 0;
        uint32_t bp = 0;
       
        bmp_printf(FONT_MED, 0, line++ * 20, "exc %08X, l 0x%08X", gdb_exceptions_handled, loops++);
       
        for(bp = 0; bp < GDB_BKPT_COUNT; bp++)
        {
            if(gdb_breakpoints[bp].flags & GDB_BKPT_FLAG_ENABLED)
            {
                uint32_t reg = 0;
           
                bmp_printf(FONT_MED, 0, line++ * 20, "BP#%d 0x%08X flags 0x%1X hits %d", bp, gdb_breakpoints[bp].address, gdb_breakpoints[bp].flags, gdb_breakpoints[bp].hitcount);
                for(reg = 0; reg < 15; reg+=2)
                {
                    bmp_printf(FONT_MED, 0, line++ * 20, "R%02d %08X R%02d 0x%08X", reg, gdb_breakpoints[bp].ctx[reg], reg+1, gdb_breakpoints[bp].ctx[reg+1]);
                }
                bmp_printf(FONT_MED, 0, line++ * 20, "CPSR %08X", gdb_breakpoints[bp].ctx[16]);
            }
        }       
        msleep(100);
    }


feel free to improve that tool. maybe it will get good enough to get into mainline tree somewhen