Messages

Hello!

I installed ML Alpha 1 for 7D several times and followed always exactly the instructions. But: nothing happens when I press the DELETE button. Display remains black. Everything else works. I have now re-installed ML 5x.

I use a Sandisk Ultra 8GB CF-Card.

Any ideas?

what is ML 5x !?

can you please upload a video where you show what steps you've done?

technically possible, we will discuss if the overhead in build process makes sense.

thanks a lot. it looks like some CPU load issue.
will try with panning.

you got it working? nice, good job!

i tried it with a samsung smart tv with 1920x1080.
recorded a video of a green laser pointer dot moving over a surface.
couldnt notice any drops there.

can you explain the scene more detailed and post some images?
i think that would help a lot.

thanks!

Ran 2 different Benchmarks.  First, clean ML boot with No Monitor Attached:
https://skydrive.live.com/redir?resid=E642B6CE19214075!132&authkey=!AOZD8t2Pd1dMjkA

2nd, clean ML boot with the Marshall Monitor Attached:
https://skydrive.live.com/redir?resid=E642B6CE19214075!133&authkey=!AItmv5ki8o_HASQ

Praying you can download these files!

"Something went wrong and we can't sign you in right now. Please try again later."

you can use: http://upload.g3gg0.de/

thanks for reporting.
can you a) run a card benchmark and b) send me your MAGIC.CFG?

@chroma:
np.
can you do this please? thanks.

When I record a video 24p1080 with ML fimware running with Marshall 5" Monitor connected via HDMI, the video file recorded to the CF card has a periodic "stutter" or "dropped frames" throughout.

The video file shows the "dropped frames" when .... played back through a computer.

thanks for reporting.
can you a) run a card benchmark and b) send me your MAGIC.CFG?

n/p, you are welcome

check your mail, i sent you a new version.

you followed the installation instructions as described in http://www.magiclantern.fm/forum/index.php?topic=3103.0 ?

settings etc are saved to card

That is good to hear, g3gg0!! If you don't mind me asking, what about the video bitrate controls? Do they work? (in particular increasing the bitrate, and all-i?) There's no mention of that at the wiki...

nothing at all

[in camera]

I formatted another SD card using MacBoot

from http://www.zenoshrdlu.com/macboot/macboot.html:
    "Note that MacBoot does NOT format cards, nor does it put any files there"

please format that card in camera, and make it bootable via MacBoot.

Since you mention shutdown, is it safe to assume it cleanly boots from the card now?

it was doing that before, we use FIR for that alpha as
a) alphas are not for productional use, just for testing features
b) it is safer not to modify flash before we are not sure that it is safe
c) hey this device is worth 2k$, i wont recommend you to patch the flags yet

this shutdown problem isnt linked to startup method. it also happens in FIR mode.

just to keep you informed:
intervalometer, bracketing (HDR, apterture) and bulb ramping seems to work fine.
i am just having shutdown issues which means, powering off the camera will turn the screen black, but it will still consume power.
this happens only after one of these functions was used.

removing battery and re-insert will of course work
as this looks like a generic problem of shutting down (how tasks should behave) we are investigating this atm.

some special case are VxWorks cameras.
when scanning the binary for instruction cache flushing functions, i found a lot.
here is some code to disable that for 40D v1.1.1.

when we dont patch this, its likely that our flash patches get deleted.
(to be verified)

#if defined(CONFIG_40D)
  /* this is a evil hack to disable instruction cache clearing */
  cache_fake(0xFF810220, 0xE1A00000, TYPE_ICACHE);
  cache_fake(0xFFD654E0, 0xE1A00000, TYPE_ICACHE);
  cache_fake(0xFFD654EC, 0xE1A00000, TYPE_ICACHE);
  cache_fake(0xFFD65560, 0xE1A00000, TYPE_ICACHE);
  cache_fake(0xFFFFDEF40, 0xE1A00000, TYPE_ICACHE);
  cache_fake(0xFFFFDF04, 0xE1A00000, TYPE_ICACHE);
#endif

thanks

here some example code with hints when using watchpoints.

Code Select Expand


/* when our hook gets executed, it captures the call stack into this string */
char stack_trace[1024];
/* here we see the maximum malloc size */
int max_size = 0;

/* this is our hook. we want it to get called whenever 'alloc_dma_memory' is called */
void alloc_dma_hook(breakpoint_t *bkpt)
{
    /* here we check R0 if it is larger than the current maximum. ctx[2] would be R2. thats possible up to R15 */
    if(bkpt->ctx[0] > max_size)
    {
        /* when yes, capture the call stack. this *must* be done in the hook. that cannot be done later as stack gets overwritten when we return */
        max_size = bkpt->ctx[0];
        strcpy(stack_trace, gdb_get_callstack(bkpt));
    }
    /* we could now even patch the registers if we want. but don't patch R15 please. else this simple watchpoint feature wouldn't trigger everytime, but only every second time */
}

void run_test()
{
    uint32_t loops = 0;

    /* install ARM exception hook for breakpoint (we use an invalid instruction) */
    if(!gdb_setup())
    {
        return;
    }

    /* so now add a watchpoint at alloc_dma_memory() */
    gdb_add_watchpoint(&alloc_dma_memory, 0, &alloc_dma_hook);

    /*
        note:
        a watchpoint sets TWO breakpoints. one at the instruction you say and one behind.
        when the first breakpoint is reached, its deactivated and the second gets activated.
        then the hook is executed (if != NULL). after that execution is continued and we
        instantly reach the next breakpoint as the second breakpoint is placed there automatically.
        then the second breakpoint gets disabled and the first one enabled again.
        (short, the second is just to re-enable the first breakpoint)

        reason: we can *not* execute an instruction where a breakpoint is set
        and if we remove the breakpoint, well.. then the breakpoint is removed :)
        its comparable to an air lock
    */
   
    while(1)
    {
        uint32_t line = 0;
        uint32_t bp = 0;

        /* counting numbers are always fun */
        bmp_printf(FONT_MED, 0, line++ * 20, "exc %08X, l 0x%08X", gdb_exceptions_handled, loops++);
       
        for(bp = 0; bp < GDB_BKPT_COUNT; bp++)
        {
            /* just print the watchpoint, not the second breakpoint needed for re-enabling (we call it 'linked' watchpoint) */
            if((gdb_breakpoints[bp].flags & GDB_BKPT_FLAG_WATCHPOINT) && !(gdb_breakpoints[bp].flags & GDB_BKPT_FLAG_WATCHPOINT_LINK))
            {
                uint32_t reg = 0;
           
                bmp_printf(FONT_MED, 0, line++ * 20, "BP#%d 0x%08X flags 0x%2X 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]);
                bmp_printf(FONT_MED, 0, line++ * 20, stack_trace);
            }
        }
       
        msleep(100);
    }
}


you can add a watchpoint to GUI_CONTROL function and look at the call trace if that helps

@Papa schulz:
the rant of 'stir fry a lot' was not against you, but the posts before that ask about .fir loading


at the moment we are checking which license/OS we choose for which developer.
another 500 EUR and both, alex and me will get the HEXARM decompiler for our native OS
we are still discussing the exact configuration.

OK, I'm so stoked at this development. I upgraded my firmware and loaded the ML 7D alpha. It comes up but the screen is gibberish, I can go from menu item to item but it is totally illegible. Anyone else here experiencing this?

did you extract all files ans folders in the zip into your cards root folder?

ah okay but one change request.
the gdb.c features two main use cases

a) gdbstub for debugging via gdb protcol over PTP and
b) useful functions like gdb_add_watchpoint() to inject a hook function at any flash address, that
gets called everytime when ARM processor executes specified instruction

feature a) is good to be selectable, but needs OS functions like task_create and PTP integration
feature b) is also good to be selectable and is target-independent (no OS calls, no stubs needed) and very helpful

so can we make it selectable in 2 different ways?

CONFIG_GDB (generic debugging routines)
  will add gdb.c only and make watchpoint funcs accessible

CONFIG_GDBSTUB (GNU debugger compatible stub via PTP)
  will enable task_create in gdb_setup and the functions starting from gdb_send_append (undo changeset be31d5eb6daf, gdb.c)
  will automatically enable CONFIG_GDB

CONFIG_GDB_PTP is replaced by CONFIG_GDBSTUB then.

what do you think?

Congratulations Mr. g3gg0 more than 5000 downloads and going strong!  If you asked for $2 donation for each download you should have the new develpment tools in your hands.

thanks.
then we would have less than 500 downloads
but we would be able to buy IDA pro, thats correct

Ahh. You mean, as CLEARLY stated in opening post ?

exactly identified by filename in troubleshooting section

[7D000203.FIR]

the MD5 is of the ORIGINAL CANON 7D000203.FIR, not of magic lanterns 7D000203_ML.FIR