Messages

will check the 60D firmware these days. i made that patch for 600D, but didnt test 30 minute limit yet

i am using IDA pro.

Code Select Expand



#if 1
    uint32_t objPtr = autodetect_movierecorder_ptr();
    uint32_t offsetMax = autodetect_movierecorder_maxsize_pos();
    uint32_t offsetMaxFailed = 0;
   
   
    if(!offsetMax)
    {
        offsetMaxFailed = 1;
#ifdef CONFIG_60D
        offsetMax = 76;
#endif   
    }
   
    if(objPtr && offsetMax)
    {
        uint32_t *movRec = *((uint32_t**)objPtr);
        uint32_t offsetCur = offsetMax - 0x06;
       
        /* set maximum to 0x3FFFFFFFF bytes (16GiB) and time to 180 minutes */
        movRec[offsetMax+2] = 180*60 - 1;
        movRec[offsetMax+1] = 0x00000003;
        movRec[offsetMax] = 0xFFFFFFFF;
       
        while(1)
        {
            msleep(100);
            bmp_printf(FONT_SMALL, 10,40, "Object: 0x%08X  Ptr: 0x%08X  Off: %04X  f: %d", movRec, objPtr, offsetMax, offsetMaxFailed);
            bmp_printf(FONT_SMALL, 10,50, "max: %08X%08X cur:%08X%08X", movRec[offsetMax+1], movRec[offsetMax], movRec[offsetCur+1], movRec[offsetCur]);
        }
    }
    else
    {
        uint32_t loops = 0;
        while(loops++ < 100)
        {
            msleep(50);
            bmp_printf(FONT_SMALL, 10,10, "Object/MaxPos not found");
            bmp_printf(FONT_SMALL, 10,20, "Object: --  Ptr: 0x%08X  Off: %04X", objPtr, offsetMax);
        }
    }
#endif



I tried doubling the limit, just changing 7 to F and limit still remains. I looked in the firmware and don't see any other spot for it.

DryosDebugMsg(BYTE((unk_R4->off_0x4)->off_0xC), 22, 'MVR_APPENDCHECK_30MINOVER', HALFWORD(unk_SP->off_0x8))

MVR_APPENDCHECK_30MINOVER is the check for clip mode, not for normal recording.

you tried to double what limit on which camera and which limit do you still hit?

note:
to be honest, calling ML monolithic is wrong. i meant non-modular of course.
linux is modular and monolithic. 

a) plugin architecture will cover big size autoexec.bin issue.(But it's good at increasing a capability)
bc) uncompress need more time? and autoexec.bin reading is not so slow now. and ROM selecter need a timeout like a linux grub or lilo. So more time will need boot sequence. I guess

a) true, but still ML is monolithic for some good reason. but what i dont like is the merging of all camera models in *one* autoexec.bin. it works, but is some thing that can be improved
b) depending on compression algorithm data can be decompressed faster than load from SD card in ROM without DMA
c) timeouts? no gui, no user interaction, nothing to have to wait for.

there are users who already are irritated by the small delay on some models and i wondered how minimal and modular we can make magic lantern.

and true, yours is available *now*, mine is theory yet

this is going in direction of the current idea i have - Magic Boot Loader.

had this idea to wor around some hacks and problems we have with current method.

a) ROM doesnt have to read megabytes of autoexec.bin, but only a small loader and can decide between multiple real ML binaries (startup speedup)
b) those ML binaries can be compressed to speed up loading process even more (startup speedup)
c) we can add selectors for alternative firmware images depending on hw/config
d) we can add rom dumper features etc to this slim bootloader and use it as development base for new models

on 600D its the size in seconds. 0x0707 which is 1799 seconds

@thba74:
thanks.
for the 550D it seems the maximum file size is 0xFF000000 (4080MiB).

also, the size_t type is 32 bits, so we cannot simply tell MovieRecorder to record longer and concentrate on splitting files. (or use exFAT as done with 600D)

i guess 550D user will have to stick to movie-restart. sorry.

6. fix the video file with g3ogg3 tools on post

*cough* g3gg0

about how to make exFAT cards bootable - this one will help: http://chdk.wikia.com/wiki/EOScard

you ever put a child seat into your car?
read whats printed on that stickers?

it says like
"warning: if you do it wrong, your child may get severe injuries, and may even die"
well. this encouraged me to double-check what i've done.

thats the point about the sentence you found.

not only the register map differs, but also the meaning of the registers are totally different.
e.g. setting GPIOs or configuring timers is done in a different way as on TMS320

600D, fpga is gone but mystery chip appears:

which chip do you mean?

if this doesnt work on 60D, try this one (also working on all cameras) and tell about "f:1" or "f:0" being displayed

http://upload.g3gg0.de/pub_files/b1c16b181c80a6e8cbe823c70977a1a6/autoexec.bin

One way to check for sure is to look at those bins and see if the contents is there and if its encoder settings or memory settings.

Why is TMS320DM36x from TI mentioned in data sheets? IF the ASIC is on the digic chip can it be set to a different profile?

which binaries do you mean?
in which datasheets is the TMS320 mentioned?

br,
g3gg0

ok, update again.

http://upload.g3gg0.de/pub_files/a5e5655bdfa7454e8d970d2505aa0d47/autoexec.bin

can all camera users try what is being detected when pressing "dont click me"?
the exact values are not that important, i care more about if the 4GiB limit is disabled or if there is some error message.

thanks.

alex, can you do one try again with mirror lockup enabled?

nothing.
if you enable the flag at this location:
LDR     R11, =unk_3564
LDR     R0, [R11,#0x30]

the camera will write two files on shooting:
http://upload.g3gg0.de/pub_files/24765bcf500210a789475f646b002805/BLKITG01.BIN
http://upload.g3gg0.de/pub_files/60415441719ef3b7bd40e50d40c2c925/WS01.BIN

not sure what they contain. its something from 0x40........ area, maybe some defects data or such.

to be honest...
i am quite sure those FPGAs seen on some older models dont have to do anything with MPEG encoding.
to me it looks as if the FPGA is for managing access to the external memory bus, maybe SDRAM controller, maybe HDMI interface etc.

but for H.264 encoding, the XA3S250E has far to few processing power.
the IP core you mentioned needs ~8k slices for NTSC/PAL videos. this FPGA has less than 2.5k.
for 720p we would need a virtex-4 instead of a spartan-3E and ~9k slices.

i am sure the digic has some built-in asic for mpeg encoding.

are we talking about VIDEO or PHOTO?
OP talks about photos...

the conclusion:
you are using "unified" version which includes binaries for all compatible camera bodies.
when starting the camera, this binary is loaded (1.7MiB) and this takes little longer (0.5 - 1 sec maybe)

one solution would be: use a version special compiled for 5DII only.
then it will take less time to boot.
-> compile from source, or someone uploads the binary

neither first nor latter.
i tend to someone who thinks that exposure time of 1/2000th means 2000 fps. *sigh*

yeah, looks doable.
i would take the 2nd opamp (currently it inputs are GNDed) for configuring the decision point with a voltage divider using potentiometer.
optionally drive that as schmitt-trigger. (signal + feedback to minus i think)

i would feed that to a MAX232 which creates the right voltages.

the feedback capacitor should be somewhere around 1pF, optionally filter the output of the 1st opamp.
thats required to cancel that ringing.

i never made anything with opamps before

to be honest.
we are still in experimental phase and determining which method is the best and if it will work at all.
at the moment i really dont care about perfectness.
it will work for every user good enough.

next step is to test it for other models and then to enable 4GiB file splitting.

not yet, but will be, i think.

you have to run that function *before* recording!