Messages

great news!!! beta 3 released (first page updated)

So, Andrew it looks like you've checked off your short term goals (from page 1) and now you've got the software running beside the Canon software.

Whats your priority list for implementing the rest of the ML features - so we get some kind of idea in what order things will be coming?

Great work BTW.

Walt

if I can find a way to trigger bulb exposures, we can make bulb ramping work (for timelapse videos). Also, if I can find a status indicator memory address for focus confirmation (value is 0 when no focus confirmation, 1 when there is), then I can make trap focus work.

hdr and intervalometer worked in last build but don't seem to work now, I need to figure that out (some of the back-end has changed since my last release, need to get things back to a working state again).

I'm hard pressed for time so I will try to work on this when I get free time, classes have me pretty busy though. Also i always appreciated donations from users, thank you everyone who has donated!!

I managed to blur the image of the LCD. I now have to know the coordinates valid in order to draw a rectangle.

I used this STUB, and wrote somewhere in vram0.

NSTUB(0x1E450, bmp_vram_info)

In the coming days, I'll want to have a bmp_printf(...) function to write text on the display.

Once you get it, I want to improve the boot process.

you should start porting ML to the 40d, clone the latest repo and look for CONFIG_5DC, maybe add #define CONFIG_5DC CONFIG_40D and copy the same diretory structure / entry.S of the 5dc. All of the changes for the 5dc in menu.c should be valid for the 40d too.

Yes, I will do that ..

A simple test to see if you found the vram is to try and paint on the screen, write something like 64kb of 1s to the buffer and you should see a colored square on the screen.

great to see your progress!!

Thanks Coutts, appreciate yr hard works !!

I've tried the beta 2 and it works
the shutter disabled, black LCD in beta 1 are now gone.
Enabling and disabling the ML work the same way (updating the firmware procedure . . . )

My machine is under the DS126091 batch and
s/n # 20312xxxx

- HDR Bracketing      works
- Intervalometer       not
-  Bulb/Focus Ramp   didn't try yet
-  Bulb Timer             didn't try yet
-  Mirror Lockup        didn't try yet
-  Flash Tweaks        didn't try (don't have a Canon/compatible flash unit)

-  Trap Focus             not
-  Image review
    settings                works
-   Config file             works
-   Crop Factor
    Display                 not (need LiveView ??)

-   Debug Menu        not tried (or should I try ?)

the "Set" (middle of the dial) can "Confirm / Change" the values
pressing down the cursor can also have the same result

Dial and cursor can move around on the Menu bar and the sub-selections

BUT
form time to time the original Canon Menu "flash" out

I am ready for the next beta


P.S. just "bought you a cup of coffee" to express my thanks

Thank you very much! All donations greatly appreciated

Andrew, now that there are 2 FIR files is this line still valid in the installation instructions.

"Download the zip file from the link below, unzip all of the files to your CF card."

It loads both FIR files together?

Walt

Sorry it's a little confusing, but the installer fir should only be run once to enable the camera bootflag, once this is enabled it will stay enabled until you run that FIR again to disable it. The new second FIR file will **only** make your card bootable, it won't touch the camera bootflag. so, this just makes it easier to set up a card for ML.

Hi Coutts,

Have just updated my 5dc with ML beta 2 and ran through few ML menus - probably beta 2 is ok for me (sn 382130****).

Thank you for all your hard work,
Stas.

this is great news!!! that means it works for newer serial number cameras finally 

Beta 2 posted, hoping it works for all of you guys that haven't had any luck with beta 1. Let me know how it works

when I found the 5dc vram, I did it a bit oddly. I used img.py (http://magiclantern.wikia.com/wiki/VRAM/550D#How_to_find_segments[/url]). You should look into this. You already know the dimensions of the buffer (same as 5dc): 720x240 with a pitch of 360 I believe. so, dump an area of memory and run it all through img.py to see if you can see the menu or whatever screen you dumped the ram at.

One way to find vram:

All vram buffers are like structures, with off_0x00 pointing to a string in the ROM that says "Vram Instance". There's a few of these so you'll have to check for all of them. But, you can dump say the first 0x10000 bytes of ram and look for these pointers. Tip for dumping: you might need to do what I have to do with the 5dc (which I learned from 0xAF with the 400d) and dump using a buffer.

For whatever reason, I can't seem to dump very much without using a buffer. simple code:

Code Select Expand


//~ dump memory 64kb at a time using a buffer.
void dump_with_buffer(int addr, int len, char* filename)
{
    FIO_RemoveFile(filename);
    FILE* f = FIO_CreateFile(filename);
    if (f!=-1)
    {
        int address = addr;
        while (address<addr+len)
        {
            char buf[0x10000];
            memcpy(buf, (void*)address, 0x10000);
            FIO_WriteFile(f, buf, 0x10000);
            address += 0x10000;
        }
        FIO_CloseFile(f);
    }
}

audio.c needs finished headphone looping never worked.

i'm glad the 500d will get some polishing!

I've been pressed for time latey, sorry for no progress. I appreciate the donations, thank you all!

I'm hoping to figure out g3gg0's cache hack boot method in hopes that it will fix this issue of only some cameras working and others don't.

great job!

would it be possible to change the print button (which i never never need) to mirror-lockup-butten?
This would be another real great feature!

PS: Where can I donate für the 5DC ML? I'm shure you will handle it!

thanks! I could add that in the next release probably (maybe just make a new setting in the menu to enable it). If you want to donate (greatly appreciated!) I have paypal: [email protected]

4.1.1 !?!?!?!? whaaaat

that's odd, maybe some error by canon? weird.. maybe we can obtain a firmware dump from him if he is still in contact online

As for 40D then.
That will result in HUGE videoclips at less than 15 fps, right?
Like that third party application that dumped the frames from LV and saving them as avi.

I think live view updates at 30fps so it will probably be that. We need to speak to Alex about this, I only know it is possible. He knows how to implement it

For those having trouble with ML, just delete the autoexec.bin then disable the bootstrapping by re-flashing the firmware provided by coutts.

captcha workaround: after writing your message focus on the message field and press ctrl + a to have a copy of what you just wrote in the clipboard so if you sent the wrong captcha you can simply paste it back

the capchas go away after 3 posts i believe, sorry!

As for removing ML, all you really need to do is format the card to delete the autoexc.bin file and make the card non-bootable. the in-camera bootflag can stay enabled and it won't interfere with anything.

Video mode with the 1000D?
Isn't it a Digic III model?
Digic III shouldn't be capable of encoding videos, right?

no, but we should be able to dump the live view buffer

the new version of magic lantern recorded in 1080p at 24 fps in the canon 500D?

la nueva versión de magic lantern graba en 1080p a 24 fps en la canon 500D ?

if I remember correctly, the 500d 1080p video cannot be increased beyond 22fps. I haven't worked on the 500d port since last year though, maybe things have changed

Any developers have this camera? With the 5dc and 40d being worked on, it should be easy to port the 1000d to ML as well now. The 1000d has live view, so it should be possible to capture video with it. 1000d shares the same low quality screen as the 5dc so I bet all of the vram stuff is the same.

Initial porting is already done by me. Look at this project here to get started, it boots the main firmware and sets the bootflag. Look at the 5dc entry.S / init.c to get an idea of where to start for the 1000d and ML.

https://bitbucket.org/coutts/1000d_dev

The entry.S of the 5dc can be seen here. As you can see it's very similar to the 1000d one I already wrote above:
https://bitbucket.org/hudson/magic-lantern/src/bbaee3c6d8d0/platform/5DC.111/entry.S

Only thing that will need fixed up is the call to where it sets up one of the main heaps. We need to shrink the heap and make room for ML to be copied there, and then link to this spot. It is not safe to link to 0x800000 from what everybody says (though I don't yet understand entirely why).

I have not worked on it in a while (no longer have access to a 1000d), but it is all set for someone to take over. Maybe someone has a 1000d to send to me?

[flush_caches__start_firmware]

I was tracing back the 5dc bootloader when I thought I should start making some notes of how it boots things.

The code that actually starts the firmware can be found at FFFF36EC

The flush_caches__start_firmware function is at  FFFFE358

So, working backwards.. jump_to_firmware is called in 3 different spots. Arg0 is the name of the file that the bootloader has loaded/ is going to jump into, so it could either be the FIR filename or it will be AUTOEXEC.BIN. Arg1 is the actual address it is going to jump to. This address is determined by load_file_to_execute (FFFF4388), which is the function that I believe copies the file into RAM at 0x800000.

The 3 spots that jump_to_firmware are called give somewhat of a clue as to what it is booting:
- one passes arg0 as AUTOEXEC.BIN
- one passes arg0 as an inputted filename (probably used for debug purposes by canon)
- one passes arg0 as the return of sub_FFFF46B8. Initial look at this indicates maybe this is an auto-calculated FIR filename, used with the flasher during a normal firmware update procedure.



So, it appears it goes like this:
- load_file_to_execute is called with arg0 as the filename to load into memory. arg1 to this function is some variable (stack variable) to hold a return value. This return value is the link address of the file being loaded into memory. It has 2 options: it will either be 0x800000 or 0x10800000. Not sure yet what this caching bit of 0x10000000 means.
- jump_to_firmware is called with arg0 as the filename being executed and arg1 as the load address of that file.

Coutts I understand but how do I boot VxWorks?! ...
My apologies if the question is basic!

I've been to see the entry.S 5DC but still seems to me very complicated.
How do you know the sequence of function calls to boot.
I studied multitasking, but on the VxWorks I only know the name: (

How do I use AUTOEXEC.BIN to start the VxWorks?! ...

Can I use the functions DEBUGMSG and dump before starting VxWorks?

Those functions you listed earlier sound like they are bootloader functions but they are being called from RAM, so I wouldn't call those (not sure if the functions are copied there or not). I've been looking for file i/o in the bootloader for a while but haven't found it, if you have found these functions in the BL, then that is huge progress! It will help new ports a lot.

Now for booting VxWorks, what I mean is you must copy/paste the boot code starting at 0xFF810000 far enough to where you can spawn your own task. We need to hook ourselves into VxWorks. Once we have started our one task, we can hand execution back to canon and boot the camera like normal.

So, I used some bootcode from chuchin but it is literally copy/pasted line for line from the ROM (at FF810000). As a test, see if you can make your entry.S jump execution to FF810000 and see if the camera boots like normal.

Then begin tracing the boot process to know how much code needs to be re-written. You only need to write until the part where it calls CreateTask on the startup task. We can hook our task in here.

My next steps are:

1) find the addresses of the functions Open, Write and Close;

2) create BL & ROM dumps.

you must boot the firmware first. you cannot call file i/o until it has been initialized by VxWorks. now that you can run autoexec.bin, you can boot the firmware

I used the information provided by Coutts to flash both LEDs.

See the examples:


1_1000D LED Finder

2_1000D LED-Dumper

These are the addresses of blue and red LEDs:

LED_RED     0xC02200E0
LED_BLUE    0xC02200E8

great job! Let's get the 40d port on its way
Next step: copy/paste boot code into entry.S like the 5dc one. copy enough of the boot code until you can hook a task.

For initial hacking you may want to refer to 5dplus:
https://bitbucket.org/coutts/5dplus

glad to see the 500d is still alive

i sort of saved the 500d port from certain extinction

Helló!
I already have 5D classic, and I dont't have money to change it 5D MK2.
The ML firmware will came to be a clever to 5D Mk2 tricks!
Many thanks to develop to you, and respect!
I want to donate you, if you done an 1.0 5D Classic stable version firmware!
(ISO 6400, smaller jpg picture in the CR2 file (thumb), ... )
How to donate? >> Paypal?
Have a nice day! :-)
TakiTibi

paypal: [email protected]
Any donations greatly appreciated thanks!

Here is where the different memory regions are setup. This is one of the early functions called when the bootloader starts:




It kind of makes sense! Some regions overlap, but the permissions for all are the same so overlapping doesn't mean much.
Region 0 is the total addressable space of the 32-bit ARM (0x0-0xFFFFFFFF).
Region 1 could represent 1gb of RAM area, in the bootloader it references the RAM area as 0x0-0x40000000.
Region 2, not sure about. I know the flag area is at 0xF8000000 so maybe related to that.
Region 3 looks to possibly be the DIGIC Register area, since anything in the 0xC range maps to digic registers (from what we know).
Region 4 is 8mb starting at 0xFF800, sounds a lot like the 8mb firmware ROM
Region 5 is 128mb starting at 0x0, I think this is the cacheable RAM area. From strings in the bootloader I think the camera has 256mb of RAM total, and if you look at my notes above it sets only regions 4 and 5 as cacheable, so I think the other half of RAM is uncacheable. There are allocate memory functions for cacheable and uncacheable memory, so maybe this is all related.

Just probing around, don't mind me