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?
Video mode with the 1000D?
Isn't it a Digic III model?
Digic III shouldn't be capable of encoding videos, right?
Quote from: ilguercio on August 14, 2012, 07:29:13 PM
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 ;)
Quote from: coutts on August 14, 2012, 08:35:10 PM
no, but we should be able to dump the live view buffer ;)
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.
Coutts,
I started thinking about making the 40D port when I saw your port of 1000D
Quote from: ilguercio on August 14, 2012, 08:46:02 PM
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 ;)
Quote from: coutts on August 15, 2012, 02:45:27 PM
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 ;)
Coutts, could you please teach me how to use your SW?
How do I install and use it?
I have a Canon XS (AKA 1000D).
I am also ready to help with any testing as I too own a 1000D! Have been waiting for ages for some hack for my 1000D :D Hope I can help in some way
There's no develper for the 1000d yet as coutts doesn't have one anymore.
Seems like Coutts was very close to getting this ported over. Its not just going to die now is it? Anyone willing to take over?
Quote from: r00t4rd3d on November 24, 2012, 01:04:46 AM
Seems like Coutts was very close to getting this ported over. Its not just going to die now is it? Anyone willing to take over?
To continue this work we have to own a camera.
If you have one of these cameras and have technical expertise, can make a contribution continuing the work begun by Coutts.
I own a 1000D and i'm a developer, mainly on C# but I'll give it a try... what work has already been done?
The features I would like to see on 1000D are the focus trap, time laps("Intervalometer ")
Quote from: andrecbrito on January 03, 2013, 10:18:15 AM
I own a 1000D and i'm a developer, mainly on C# but I'll give it a try... what work has already been done?
The features I would like to see on 1000D are the focus trap, time laps("Intervalometer ")
those seem very possible! To get started, look here:
http://magiclantern.wikia.com/wiki/Developing_info
The magic lantern repo can be found here:
www.bitbucket.org/hudson/magic-lantern
Follow the 5dc and 40d ports, as they are the only VxWorks cameras supported. I did some testing with the 1000d here, you can use it for the bootcode found in entry.s. The code here will boot the firmware and start a user task so it's a great starting point.
www.bitbucket.org/coutts/1000d_dev/src
jxlpto and myself are probably the best to talk to for porting VxWorks, so feel free to pm us with any questions.
good luck :D
I'm really hoping to get some help with my canon 1000d. I bought a 1000d used and it came in Factory Service Mode.
When I connect it to a usb port it comes up as "DCP CONNECT" and the drivers won't recognize it because its not in PTP mode.
The bottom item under the first menu list is "Factory Menu"
Anyone know how to get the 1000d out of Factory Service Mode? Can Magic Lantern software be of any help here?
Lewis
Quote from: andrecbrito on January 03, 2013, 10:18:15 AM
I own a 1000D and i'm a developer, mainly on C# but I'll give it a try... what work has already been done?
The features I would like to see on 1000D are the focus trap, time laps("Intervalometer ")
How is the development unfolding? If someone can walk me through testing it, I am happy to try on my 1000D. I am mostly using it for HDR bracketing. Is this functional at all for this model yet?
Can I download the 'repository' zip file and install it on my 1000d?
I just want intervalometer feature.
Hello,
I heard of Magic Lantern and I decided to install it on my camera, but I have a Canon EOS 1000D, so I found this thread.
I am willing to help with the development of this port. I'm an expert python programmer but I'm a beginner with C. I have already written working programs in C (mostly Arduino sketches) but I still consider myself a beginner.
That being said, I'm going to read how the boot process works on vxWorks and Magic Lantern.
I would mostly use it to record time lapse without using a computer, I'm not looking for too many features.
Is there anyone that is willing to chat with me on IRC about this? My timezone is GMT+1.
Hi, I own a D1000, what is the current status of magic lantern for this Camera ?
If the port is not done yet, is there some help I could provide ?
[ I am a professional embedded C developer, with+20 years experience]
What's blocking ?
Nothing's blocking it. Taking a look at the successor - the 1100D - I would say: grab yourself some updated and more capable cam. "Embedded C developer" sounds cool. Help is always welcome.
1000D is indeed a bit old and doesn't work with DRYOS (introduced about 2007) but VxWorks. Call it a lonely place even in not-so-crowded devland. If you insist working on it you may want to take a look over there: http://www.magiclantern.fm/forum/index.php?topic=991.msg157850#msg157850 where user gph reanimated 5Dc (VxWorks, too) development. Coutts seems to be out of town for some months. You may try to contact him anyway sending a PM.
Any news on this. I'm not developer but I own a 1000d, so if I can be of any help testing something just tell me. I'm mostly interested in the bracketing stuff
So ive been trying to compile the build from this forum here
https://www.magiclantern.fm/forum/index.php?topic=17991.0
and have had no luck, i keep getting bunch of errors, if its possible
for someone who already has the tools to compile it and could compile
and re-upload it for me that would be amazing. I just cant seem to do
it my self.......
Thanks,
Mason Dulemba
Unfortunately there is not much to compile, the files which were made by Coutts are only capable of letting the blue led on the camera burn.
So these files are only a very small beginning for porting the 1000d and no where near a working magic lantern build.
I'm not sure what the next step would be, probably a firmware dump with the use of the blue led?
After that, all sorts of addresses need to be found in the rom dump for use in the magic lantern software.
Thank You for the reply, I'm a bit confused because there were some that said they were able to get it running
IE:"
User:SysCall
Re: 1000d - help needed with compiling
« Reply #14 on: November 16, 2016, 10:14:24 PM »
Thanks guys, I can cofirm I'm also able to compile and start it on my Canon 1000D.
"
Source: 2nd To Last Comment
https://www.magiclantern.fm/forum/index.php?topic=17991.0 (https://www.magiclantern.fm/forum/index.php?topic=17991.0)
No contradiction.
You read something you want to read. He simply wrote "get it running" and "it" is not ML with the functions you get with cams running ML nightly build.
I already explained shmadul it is not a final built or even close to it.
Since he is new (like me), it is a little bit confusing to get into the development.
It is hard to start from scratch and figured out everything, especially since the forum is big and the information are spread all over the forum (use search engine, I know, but still confusing).
@shmadul
If you have troubles to compile, you should have posted in the other thread instead of opening a new one, then I would noticed it earlier.
Unfortunately, I do not look that much often in the forum, since I have a full time job and I spend the rest of time mostly shooting :D
If you still interested or anybody else, here is the compiled version:
Status: Awesome blue LED blinking
https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss (https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss)
Instruction:
1. Format your SD card in the camera
2. Extract the rar and copy and paste in the root of the SD card
3. Go to Menu -> Firmware update -> start it
4. Profit -> blue LED should blink and turn off after while
@Levas
Thank you for another bit of useful information ;-), I was searching for the next step.
In general I was looking for a development process to port magic lantern to different cameras, but didn't know where to start.
Maybe we can manage to organize a Canon 1000D team or something.
Cheers
@syscall That would be great, as i desperately need this for a class project..... Im a quick learner, i know a bit of everything when it comes to programming languages, C++, Java, JS, html, python, ive done some exploitation work for other platforms such as OS X and iOS, but from what im picking up as i go this seems a bit easier...
Just have a few Questions for You or anyone really....
1. How do i go about changing what is executed (iE: Currently the blinking lights script runs) but what file(s) control that,
Dont want to mess with any of the exploit work, because that seems to be working fine..
2. What all needs to be done scripting wise to tell it to hijack the canon Ui and boot ML ?
Thats it for now :)
Thanks,
Mason Dulemba
So i've Read this post
"A. Bootloader starts up and checks card and boot settings
B. It will find the Boot Flag set so it will check for a bootable card
C. Once found it will load canon firmware and then ML's autoexec.bin"
and have a guess as to how this works
1. The 1000D.fir file contains the exploit and sets the Boot Flag which then looks for the autoexec.bin file Correct ?
2. The autoexec.bin file contains the script to make the blue light blink
3. And normaly there is a ML folder for all the ML menus and stuff, does this need to be custom made specifically for the Eos XS ? Or are all ML folders the same for all builds?
Thanks,
Mason Dulemba
Im currently trying to port the 450D version to the 1000D....
And have gotten a solid blue light and a black screen (My Cameras Ok though :) )
@Syscal and @shmadul
Great, so we got three people who are willing to put some effort in the 1000d.
Alex is willing to help us if we can get some stuff done
http://www.magiclantern.fm/forum/index.php?topic=14732.msg172723#msg172723 (http://www.magiclantern.fm/forum/index.php?topic=14732.msg172723#msg172723)
I've send him a message a few weeks ago that I got the blue led blinking, now he asks for making the blue and the red led to blink
Probably to prove some sort of understanding of the written code.
But I got stuck letting the blue and red blink, here's where you guys probably could help.
As far as I understand, the program that runs on 1000d exists from these files.
main.c
main.h
Entry.s
Entry_subs.s
All these files can be viewed in a normal text editor and edited and compiled for testing.
Most stuff is done in the main.c
The entry.s contains arm code, see this link:
http://magiclantern.wikia.com/wiki/ASM_introduction (http://magiclantern.wikia.com/wiki/ASM_introduction)
The entry_subs.s contains addresses where commands are called in the 1000 firmware I think.
So does one of you know how to change the above files to get both the red and blue led blinking ?
@levas Like this ?
while (1)
{
LEDBLUE = LEDON;
LEDRED = LEDON;
msleep(500);
LEDBLUE = LEDOFF;
LEDRED = LEDOFF;
msleep(500);
}
Also, Could http://www.magiclantern.fm/forum/index.php?topic=14732.0 help us, Who wants to set up a github project for our team ??
Just a Note, Use Firmware Version 1.0.7 because anything Lower doesnt seem to work with anything that has been developed so far
Sounds good guys.
Can you guys also post when something is working, how you do it, especially if it was mentioned in the previous post as issue or problem?
E.g. shmadul, you mentioned you couldn't get it compiling and suddenly it works, but you did not mentioned the solution.
So, how you resolved the problem?
The answer would not only help other if they running into the same problem, but also document the status of the current work.
I'm currently trying to clean some code and make a readme.txt, it needs some time.
I will post it once it is done.
cheers
I tried your piece of code, put it in the main.c
Compiled and only the blue led blinks ???
Are you sure nothing needs to be changed in the entry.s file ?
I do get a lot of warnings during compiling, don't know if it means anything?
in terminal I do the command 'make' and this shows up:
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gcc -c -o entry.o entry.S
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gcc -c -o entry_subs.o entry_subs.S
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gcc -nostdlib -march=armv5te -fno-builtin -Wall -pedantic -std=gnu99 -c -o main.o main.c
main.c: In function 'dumpmemo':
main.c:19:3: warning: implicit declaration of function 'FIO_CloseFile' [-Wimplicit-function-declaration]
FIO_CloseFile(f);
^
main.c:22:2: warning: implicit declaration of function 'FIO_OpenFile' [-Wimplicit-function-declaration]
f = FIO_OpenFile("B:/ROMDUMP.BIN", 0, 0644);
^
main.c: In function 'MyTask2':
main.c:34:2: warning: implicit declaration of function 'msleep' [-Wimplicit-function-declaration]
msleep(5000);
^
main.c:37:5: warning: implicit declaration of function 'prop_request_change' [-Wimplicit-function-declaration]
prop_request_change(0x80040007, &x, 4);
^
main.c: In function 'CreateMyTask':
main.c:94:2: warning: ISO C forbids passing argument 4 of 'CreateTask' between function pointer and 'void *' [-Wpedantic]
CreateTask("MyTask2", 0x1A, 0x2000, MyTask2, 0);
^
In file included from main.c:1:0:
main.h:2:12: note: expected 'void *' but argument is of type 'void (*)()'
extern int CreateTask (const char *name, int prio, int stack_size /*?*/, void *entry, long parm /*?*/);
^
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gcc -nostdlib -march=armv5te -fno-builtin -Wall -pedantic -std=gnu99 -Wl,-T,link.script -oAUTOEXEC.arm.elf entry.o entry_subs.o main.o link.script
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-objcopy -O binary AUTOEXEC.arm.elf AUTOEXEC.BIN
-----------------------------
Baseline: 0
-----------------------------
Let start fresh.
A: Set up a workspace
-----------------------------
1. Setup Magic Lantern for development, I used this instruction
http://www.magiclantern.fm/forum/index.php?topic=16012.0 (http://www.magiclantern.fm/forum/index.php?topic=16012.0)
My setup:
Thinkpad T420 with hackintosh, El Capitan 10.11.4
Make sure that you can compile one of the current working projects 5D3, 6D or etc.
2. Download Canon 1000d project and put it in the platform folder of magic lantern.
https://bitbucket.org/coutts/1000d_dev/src (https://bitbucket.org/coutts/1000d_dev/src)
3. We have to fix the makefile and update it to a newer version of the compiler.
Go to:
magic-lantern/platform/coutts-1000d_dev-a7835d17602f/
Open the makefile with a text editor and replace the following code
CC=arm-none-eabi-gcc
AS=arm-none-eabi-as
OBJCOPY=arm-none-eabi-objcopy
with
CC=~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gcc
AS=~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-as
OBJCOPY=~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-objcopy
Don't forget to save it!
Source:
https://www.magiclantern.fm/forum/index.php?topic=17991.0 (https://www.magiclantern.fm/forum/index.php?topic=17991.0)
4. Now try to compile it, when everything works, you should end up with a new "AUTOEXEC.BIN"
Open a terminal and type:
make clean
make
"make clean" - removed compiled files
"make" - compiles the project
5. Generate a firmware for the Canon 1000d.
We have to compile a .fir file to be able to boot our own code.
Note: AUTOEXEC.BIN has to be generated first, since it is the input for the .fir
In terminal type:
perl assemble_fw
A file called 1000d.fir should be now generated.
6. Put it on a SD card
Take an empty SD card and format it in the camera.
Copy the following files to SD card:
1000d.fir
AUTOEXEC.BIN
7. Try it in the camera.
Go to Menu and then to Firmware update section.
Select firmware to get to firmware update screen and press ok.
B: LED blinking example
------------------------------
I have take a look in the "engelmarkus_examples/2_1000D LED-Dumper" folder and used it as base for this example.
Download the example from here (led_blinking.zip):
https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss (https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss)
What is it:
It lets both LEDs (blue and red) blinking in sync.
It is intended to have something to play with.
You guys can modified the time of blinking in the main.c and now the code should behave like it should.
What is it not:
A full working version of Magic Lantern.
Instruction:
The example comes with everything pre-compiled.
You can extract the files and follow step 6 from the instruction of section A.
Or you can compile it by yourself.
What was done:
- I took some functions defined in the "2_1000D LED-Dumper" and put them in the
basic_functions.h
basic_functions.c
- Some cleanups and documentation of the code.
- The firmware generation was base on e6kr5106, I updated the firmware generation to e6kr5107 (just used the script and files from latest release).
- All basic_functions functions are binded in the main.c now.
- Adapted it for the compilation.
Note:
This version does not contains the sub routines, which was defined in the latest release by Coutts in the entry.S or entry_subs.S files.
I guess he tried to adapt the boot routine from the 450? to the 1000d, but I could not get the LED blinking working on the latest version.
If you guys find some errors in the code let me know, I will update the example.
Hope this help some people to get into development for the Canon 1000D.
Have fun, I'm out photographing.
Don't like typing each time in the terminal the three commands?
make clean
make
perl assemble_fw
Me too, lets change that and create a bash script.
Create a new file, add the following "code" and save it as run.sh (compilation.sh or something else as you like).
Works on Mac and should also work in Linux.
#!/bin/bash
echo "Compiling starting ..."
echo "Removed previous compiled files ..."
make clean
echo "Compile the project ..."
make
echo "Generate the new firmware ..."
perl assemble_fw
echo "Compilation finished."
Put it in your project folder.
Now, in terminal only execute the script with:
./run.sh
@syscall I fixed the compiling errors by upgrading back to 1.0.7 firmware on my 1000D
@syscall about the script you made, Very similiar idea to one i had, heres a script that builds it, assembles it moves it over to the sd card, renames the sd card to EOS_DIGITAL, and then makes the card bootable, just by typing updateml in terminal :) Just Edit it to suit your needs and replace the directories where appropriate :) FOR OSX ONLY !!
Download makebootable.sh here https://mega.nz/#!MlZh1JzJ!M3hLfDDJ_zjI85QdNKyTUmdMnJri_EZJJmmrMmxe-KA
//PLACE THIS IN ~/.bash_profile
alias updateml="
sudo /usr/sbin/diskutil rename EOS_DEVELOP EOS_DIGITAL
echo Changing SD CARD NAME TO EOS_DIGITAL
cd /Users/masonpc/Desktop/ML/1000D_dev
FIXING FILES
sudo chmod 777 /Users/masonpc/Desktop/ML/1000D_dev/assemble_fw /Users/masonpc/Desktop/ML/1000D_dev/make_bootable.sh /Users/masonpc/Desktop/ML/1000D_dev/makefile
sudo /Users/masonpc/Desktop/ML/1000D_dev/makefile
sudo /Users/masonpc/Desktop/ML/1000D_dev/assemble_fw
echo copying files to sdcard
sudo cp /Users/masonpc/Desktop/ML/1000D_dev/AUTOEXEC.BIN /Volumes/EOS_DIGITAL/
sudo cp /Users/masonpc/Desktop/ML/1000D_dev/1000d.fir /Volumes/EOS_DIGITAL/
sudo /Users/masonpc/Desktop/ML/1000D_dev/make_bootable.sh
echo Updated ML On SD Card"
//PLACE THIS IN ~/.bash_profile
@Syscall Im On Mountain Lion right now on my black 2007 macbook So Far So Good, May Upgrade to Maverick or Yosemite later on ;D
@Levas, No thats normal , its just saying its done now u need to run the assemble_fw File
Great work you guys :D
Will try it this stuff out today, start clean, make the autoexec.bin, and after that the FIR file.
Ok, now that I compiled the autoexec.bin and the 1000d.fir myself.
I only get a blue burning led on the 1000d, no more blinking...
I do get a lot of error messages during autoexec.bin compiling:
Command make:
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gcc -c -o entry.o entry.S
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gcc -c -o entry_subs.o entry_subs.S
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gcc -nostdlib -march=armv5te -fno-builtin -Wall -pedantic -std=gnu99 -c -o main.o main.c
main.c: In function 'dumpmemo':
main.c:19:3: warning: implicit declaration of function 'FIO_CloseFile' [-Wimplicit-function-declaration]
FIO_CloseFile(f);
^
main.c:22:2: warning: implicit declaration of function 'FIO_OpenFile' [-Wimplicit-function-declaration]
f = FIO_OpenFile("B:/ROMDUMP.BIN", 0, 0644);
^
main.c: In function 'MyTask2':
main.c:34:2: warning: implicit declaration of function 'msleep' [-Wimplicit-function-declaration]
msleep(5000);
^
main.c:37:5: warning: implicit declaration of function 'prop_request_change' [-Wimplicit-function-declaration]
prop_request_change(0x80040007, &x, 4);
^
main.c: In function 'CreateMyTask':
main.c:94:2: warning: ISO C forbids passing argument 4 of 'CreateTask' between function pointer and 'void *' [-Wpedantic]
CreateTask("MyTask2", 0x1A, 0x2000, MyTask2, 0);
^
In file included from main.c:1:0:
main.h:2:12: note: expected 'void *' but argument is of type 'void (*)()'
extern int CreateTask (const char *name, int prio, int stack_size /*?*/, void *entry, long parm /*?*/);
^
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gcc -nostdlib -march=armv5te -fno-builtin -Wall -pedantic -std=gnu99 -Wl,-T,link.script -oAUTOEXEC.arm.elf entry.o entry_subs.o main.o link.script
~/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-objcopy -O binary AUTOEXEC.arm.elf AUTOEXEC.BIN
@Levas
Those are not "errors" they are warnings and as long as you end up with an AUTOEXEC.BIN, that means your compilation was successful.
QuoteI only get a blue burning led on the 1000d, no more blinking...
Exactly, some clarification here.
In my explanation / little tut (Section A) above I explained the work flow to get an AUTOEXEC.BIN and a firmware file 1000.fir.
If you do so, it will re-compile the current code in coutts folder.
The latest code in coutts folder and the pre-compiled AUTOEXEC.BIN and 1000.fir which comes with it are not the same!
He changed the code after he generated the AUTOEXEC.BIN and 1000.fir files.
That means, if you compile the source code new, you will always end up with a black screen on your camera and a glowing blue LED.
I don't know why yet, but it does not matter what I change in the main.c, I always end up with a blue LED glowing.
That is why I included an example in my Tut (section B), which contains a working version of blinking of both LEDs (with a camera black screen).
So if you download my example (B: LED blinking example) and re-compile it and put it on your camera, you should end up with two LEDs blinking in sync.
The files led_blinking.zip, comes with all source code and pre-compiled files, use this as project folder and compile inside this folder.
When you change e. g. duration or order of the blinking in the main.c and re-compile it you should be able to see the result on the camera.
And take a look into the source files, since I try to explain what each code line does.
Thanks Syscall, and sorry for the bad reading on my part :P , the working files were already there in you earlier post.
So now we've got a 1000d with flashing LED's. Perfect decoration for under the tree this christmass season ;D
So I've downloaded your zip file and compiled it myself, there where some files missing to do that, which I took from Coutts files.
I want to start with a clean directory of files, I've downloaded your zipfile and added these files, are they all necessary ?
assemble.wf
crc16.c
crc16.h
e6kr5107.fir_0_header.bin
e6kr5107.fir_1_flasher.bin
entry.S
link.script
entry_subs.S
header.bi
main.h
Something went wrong here, all files are in the zip
Hahaha
I though my memories are bad, since I compiled out of that folder XD.
Everything should be in that folder.
@Alex
Look, both leds are blinking, even made them alternate blinking, just like you asked for ;D
http://drive.google.com/open?id=0B1BxGc3dfMDaRUZweUJ5NWZUTTQ (http://drive.google.com/open?id=0B1BxGc3dfMDaRUZweUJ5NWZUTTQ)
What's next ?
@shmadul and @Syscall,
Meanwhile I checked the topic of the 450d progress.
http://www.magiclantern.fm/forum/index.php?topic=8119.msg174078#msg174078 (http://www.magiclantern.fm/forum/index.php?topic=8119.msg174078#msg174078)
Seems to be a vxworks branch for this type of camera's
https://bitbucket.org/hudson/magic-lantern/src/18ac6b0f992918c7ba6dd282c3e74ca42574561c/?at=vxworks (https://bitbucket.org/hudson/magic-lantern/src/18ac6b0f992918c7ba6dd282c3e74ca42574561c/?at=vxworks)
In the platform folder, you can find the 450d folder and it's source files.
@levas, Nice Work :D, Ive Heard the 450D is almost the same as the 1000D so maybe we could either see if we can apply the code to our port or see if we could get one of the guys working on the 450D port to help us get ML running, We already have the FW exploited and booting custom code, we just need to port the ML GUI and stuff
Direct Link to VXWorks Repo
https://bitbucket.org/hudson/magic-lantern/get/vxworks.zip
-----------------------------
Documentation
-----------------------------
Before we can port magic lantern to this camera, we have to understand what magic lantern is doing in the first place.
I will try to explain what my understanding of how magic lantern works so far is.
If some information are wrong or missing, please let me know.
A. Boot-up process
---------------------
Cases:
1. Turn camera on (normal):
The camera will boot up the firmware, normal camera operation.
2. Update the camera (normal):
With the original canon.fir on the SD card.
In the camera menu -> firmware update execution.
The new firmware will written into the internal flash.
This is the typical process for any firmware updates, not only on cameras.
After the firmware update finished, the camera reboots and the camera operates as usual.
3. Update with custom generated .fir file
With the custom .fir and AUTOEXEC.BIN on the SD card.
In the camera menu -> firmware update execution.
The custom firmware .fir on the SD card sets a boot-flag, which allows us to load the AUTOEXEC.BIN from the SD card.
The camera restart, now the camera is in normal operation + custom magic lantern code running in parallel.
Since the boot-flag is set, the camera will load the AUTOEXEC.BIN automatically each time the camera is started,
when turn on and off with camera switchI guess.
Comments on case 3:
This seems the normal operating process of magic lantern on most of the implementation so far.
Coutts explained here a little bit deeper:
https://www.magiclantern.fm/forum/index.php?topic=1452.0 (https://www.magiclantern.fm/forum/index.php?topic=1452.0)
And here in the wiki:
http://magiclantern.wikia.com/wiki/Packing_FIR_Files (http://magiclantern.wikia.com/wiki/Packing_FIR_Files)
B. Current development
---------------------------
Now that is interesting, because in my example "led_blinking.zip" I don't remember setting any bootflags.
So why does it work anyway?
The code for the modification of the boot process is usually defined in:
entry.S
Well looking into the entry.S shows:
.text
.org 0
.globl _start, start
start:
_start:
sysInit:
B main
.align 2
fin:
And the there is no entry_subs.S file so far in "led_blinking.zip" release.
So the question would be, does it also work without the AUTOEXEC.BIN on the SD card?
After a quick test with only the 1000d.fir on the SD card.
The answer is, yes it does. But why?
Well, thinking about it, what is the 1000d.fir?
It is base on the AUTOEXEC.BIN, which is again base on our code in the main.c.
Compilation order: brain -> main.c -> AUTOEXEC.BIN -> 1000d.fir
Simple speaking, the 1000d.fir is like an .exe in windows with our code.
Each time we execute the 1000d.fir through the firmware update menu, our code will be executed.
That means:
1. The .fir file and AUTOEXEC.BIN, both can have the same code.
2. The .fir file can be executed standalone without the AUTOEXEC.BIN.
3. Each time we turn the camera off and on, we have to start the firmware update process again to load our code.
4. The AUTOEXEC.BIN can only be executed if the bootflag is set.
And setting the bootflag can be done with the .fir file, since we know how to sign it and the camera can read and executed it.
Now, I just need some confirmation to back up my theory.
After thinking a while, I remember somebody gave a talk about magic lantern.
A quick google search and here we go:
Presentation:
https://events.ccc.de/congress/2013/Fahrplan/system/attachments/2246/original/Magic_Lantern_30C3.pdf (https://events.ccc.de/congress/2013/Fahrplan/system/attachments/2246/original/Magic_Lantern_30C3.pdf)
Video:
https://media.ccc.de/v/30C3_-_5554_-_en_-_saal_6_-_201312281400_-_magic_lantern_-_michael_zoller (https://media.ccc.de/v/30C3_-_5554_-_en_-_saal_6_-_201312281400_-_magic_lantern_-_michael_zoller)
From slide 23 of the presentation:
8.2 How is ML being executed?
Method 1: Firmware update
- We forge a firmware update file (.fir) with Magic Lantern as payload
- Contains no flash data
- Flash loaders in .fir are replaced with our code
- Checksums and hashes need recalculation
- User runs firmware update from original firmware menu
- Firmware restarts into boot loader
- Bootloader loads .fir into RAM and executes it
- Magic Lantern takes over control of the system and boots original firmware
Method 2: Autoboot
- Using .fir we set a flag in flash called "BOOTDISK"
- Bootloader checks for "AUTOEXEC.BIN" on CF/SD
- If found, it gets loaded and executed without checks
- Magic Lantern takes over control of the system and boots original firmware
----------------------------
Now, looking at Coutts latest release, we do have functions to set and de-assert the bootflag.
The functions to enable and disable of the boot-flag is defined in:
entry_subs.S
NSTUB(EnableBootDisk, 0xFFD21248)
NSTUB(DisableBootDisk, 0xFFD21260)
C. Development outlook
----------------------------
Highest priority:
- Currently the screen is black during the code execution (led_blinking.zip).
- We have to find out, how to load the original firmware to get into the normal operation mode where we can see the camera menu.
- After that we can try to get the magic lantern menu showing up on the screen and porting all functions to get magic lantern works correctly.
Low priority: Highest priority:
Figured out how to set the bootflag correctly to auto load the AUTOEXEC.BIN.
If it was that simple, why Coutts comment the code section out with the functions call in his latest release?
Translating his comments of the latest release, he had troubles to get it working correctly.
@shmadul, @levas
Thanks guys, but I have read a lot so far and the canon 1000d is often mentioned to be similar to this and that camera.
Sometime it is similar to 400 plus and sometimes you should use the 5Dc for the port and then maybe the 450D.
Some example, by Coutts himself:
https://chdk.setepontos.com/index.php?topic=6238.msg86614;topicseen#msg86614 (https://chdk.setepontos.com/index.php?topic=6238.msg86614;topicseen#msg86614)
https://www.magiclantern.fm/forum/index.php?topic=2054.0 (https://www.magiclantern.fm/forum/index.php?topic=2054.0)
We have to clarify first, which one makes sense and worth the effort.
A little more stuff:
There are two parts of the firmware: the bootloader and the main firmware.
The bootloader can:
- perform some low-level configuration (e.g. the MPU*) registers, which can give hints about the memory map)
- load FIR files
- load AUTOEXEC.BIN (if the boot flag is enabled)
- show a small diagnostic menu (aka FROMUTILITY)
- jump to main firmware
*) MPU = memory protection unit (see the ARM docs). Not to be confused with what Canon calls MPU (http://www.magiclantern.fm/forum/index.php?topic=17596.0) (a microcontroller).
In DIGIC 5 and earlier, the bootloader starts at 0xFFFF0000 (aka HIVECS or high exception vectors in ARM docs).
The two parts are pretty much independent: once in bootloader context, your program can call other bootloader routines, and once in main firmware, you can call main firmware routines. If you mix them, it won't work. Exception: some very simple routines that don't use any state (such as strlen).
ML runs alongside main firmware. In order to do that, it has to modify the startup routine, reserve some memory (so Canon firmware won't overwrite it) and launch one user task. Once you did that, our code is running as a regular task on Canon's operating system (be it DryOS or VxWorks). From here, it can launch other tasks, call file I/O routines or whatever.
For trying out things, you can compile the "recovery" branch from ML, from platform/portable.000. This will give you a portable autoexec.bin that runs on all cameras (and also in QEMU), and has display access (from the bootloader context). Of course, this autoexec can be signed as FIR and loaded without requiring a boot flag.
The boot flag can be enabled from both bootloader context (as done in the old 5D) or from main firmware. EnableBootDisk only works from main firmware, but usually there is an equivalent bootloader routine, found in the FROMUTIL menu.
Quote from: SysCall on December 05, 2016, 07:48:52 PM
C. Development outlook
----------------------------
Highes priority:
- Currently the screen is black during the code execution (led_blinking.zip).
- We have to find out, how to load the original firmware to get into the normal operation mode where we can see the camera menu.
- After that we can try to get the magic lantern menu showing up on the screen and porting all functions to get magic lantern works correctly.
Low priority:
Figured out how to set the bootflag correctly to auto load the AUTOEXEC.BIN.
If it was that simple, why Coutts comment the code section out with the functions call in his latest release?
Translating his comments of the latest release, he had troubles to get it working correctly.
If you want to convert 450D port, the first thing you should do is set bootflag and check it with help of AUTOEXEC.BIN from "display test" topic. It's because all VxWorks ports use AUTOEXEC.BIN startup method.
Then you should find addresses of functions for 1000D in your firmware dump and change them in "\platform\450D.110\stubs.S". It can take many days or weeks.
After this you should edit cache related stuff in "\platform\450D.110\init.c", and edit another files in "\platform\450D.110\" and in "\src"
Great to see Alex arrive in this post :D
Indeed the 1000d and 450d have a lot in common, but I'm not sure if that helps a lot with porting ML.
Since we know that even different firmwares need different ports, like in the 5d3.
It seems that most of the work is in finding the right addresses in the firmware.
But for that we need to have a firmware dump.
Which, as far as I know, isn't available for the 1000d ?
So is the first thing to do now, get a firmware dump ?
And how, can we write a program to make the 1000d do a firmware dump on the SD card.
Or can we just use the FIR file from the 1000d 1.0.7 update from the Canon site ?
And Alex, are there advantages to make it run in QEMU, or can we just try our stuff out on our real alive and kicking 1000d's, how big is the risk of bricking them ?
Just wondering, is there a moderator who can change the title of this topic?
Since it's no longer about compiling, but more about, porting ML to 1000d ?
Or at least, small steps in trying to port ML to the 1000d :P
Quote from: Levas on December 05, 2016, 08:51:13 PM
Which, as far as I know, isn't available for the 1000d ?
So is the first thing to do now, get a firmware dump ?
And how, can we write a program to make the 1000d do a firmware dump on the SD card.
Look it on CHDK forum. There is 1000D dump in their collection.
@ a1ex and Ant123
Thank you very much.
I will look into it.
@Levas, Changed the Title as you suggested :)
Where does the autoexec.bin get its code from ? I think it already boots to autoexec.bin but cant tell because the autoexec.bin is encrypted .....
@ a1ex
Quote
The boot flag can be enabled from both bootloader context (as done in the old 5D) or from main firmware. EnableBootDisk only works from main firmware, but usually there is an equivalent bootloader routine, found in the FROMUTIL menu.
Is there any differences, if the boot flag was set with boot loader or from the main firmware routines?
on 450D this code (https://bitbucket.org/hudson/magic-lantern/src/18ac6b0f992918c7ba6dd282c3e74ca42574561c/installer/450D.110/bootdisk.c?at=vxworks&fileviewer=file-view-default#bootdisk.c-156) works well.
@ Ant123
I'm sorry Ant123, I don't understand.
Btw, it looks like I got autoboot working too, at least when I change the AUTOEXEC.BIN I see that it is automatically executed.
Also after switching the camera off and on I see my code running, I also get into main Canon menu. So I guess the firmware just boot normally and the code runs in parallel.
I want to confirm hat as you said by using the display test.
Quote
the first thing you should do is set bootflag and check it with help of AUTOEXEC.BIN from "display test" topic.
And also
Quote
For trying out things, you can compile the "recovery" branch from ML, from platform/portable.000. This will give you a portable autoexec.bin that runs on all cameras (and also in QEMU), and has display access (from the bootloader context). Of course, this autoexec can be signed as FIR and loaded without requiring a boot flag
Unfortunately I get noises as image.
a1ex mentioned, he changed a value for the canon 1000d
Quote
(I'm placing the image buffer at 0x4000000 = 64MB, so this may explain the issue)
http://www.magiclantern.fm/forum/index.php?topic=14732.msg172723#msg172723
(http://www.magiclantern.fm/forum/index.php?topic=14732.msg172723#msg172723)
Quote from: SysCall on December 06, 2016, 07:36:44 PM
Btw, it looks like I got autoboot working too, at least when I change the AUTOEXEC.BIN I see that it is automatically executed.
Also after switching the camera off and on I see my code running, I also get into main Canon menu. So I guess the firmware just boot normally and the code runs in parallel.
I want to confirm hat as you said by using the display test.
I.e. you are sure that BOOTFLAG was successfully set and AUTOEXEC.BIN from there (http://www.magiclantern.fm/forum/index.php?topic=14732.0) works?
Ok, fixed it myself.
In Trammell_Hudson_ML/src/disp_direct.c
Replace this
static uint8_t *disp_framebuf = (uint8_t *)0x04000000;
with this
static uint8_t *disp_framebuf = (uint8_t *)0x00400000;
Do you get picture like this (https://drive.google.com/drive/folders/0B1BxGc3dfMDaYjV5eTlyNWdjcVU) using autoexec.bin, not *.FIR?
@ Ant123
Well looking at the image, I don't know what it is all about to be honest, especially what the BOOT value means, guess BOOT=-1 is wrong?
https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss (https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss)
But I can confirm, I can change the AUTOEXEC.BIN only and it will executed after each restart:
- removed battery and put it back
- switch the camera off and on
Maybe I should make a video.
Quote from: SysCall on December 06, 2016, 08:08:38 PM
Well looking at the image, I don't know what it is all about to be honest, especially what the BOOT value means, guess BOOT=-1 is wrong?
Read that topic (http://www.magiclantern.fm/forum/index.php?topic=14732.0) from the begining to the end again.
If BOOTFLAG is set you will see "BOOT=-1" ( -1 == 0xFFFFFFFF)
Video is online, same link as previous post.
Btw, why is your flag set?
You got it already running?QuoteIf BOOTFLAG is set you will see "BOOT=-1" ( -1 == 0xFFFFFFFF)
Guess my boot flag is set then, look at my link.
Quote from: SysCall on December 06, 2016, 08:24:33 PM
Video is online, same link as previous post.
Now I see. But why you are playing with LEDs and don't modifying VxWorks branch (https://bitbucket.org/hudson/magic-lantern/branch/vxworks). What is your final objective?
Quote
Btw, why is your flag set?
You got it already running?
My picture of 450D display test was made before BOOTFLAG was set.
Quote
Now I see. But why you are playing with LEDs and don't modifying VxWorks branch
Start simple :)
What I did was, in Coutts latest release, I just comment out the following code section.
// EnableBootDisk()
Funktion f = 0xFFD21248;
f();
After that, I made the SD card bootable by executing in terminal:
sudo ./make_bootable.sh
After executing .fir the first time, I don't need it anymore and the camera loads the AUTOEXEC.BIN automatically.
Quote from: SysCall on December 06, 2016, 08:46:53 PM
Start simple :)
What I did was, in Coutts latest release
I don't know what is "Coutts latest release" for.
I was working only with VxWorks ML ports (40D and 5DC ) to get ML on 450D with minimum functionality .
Sorry for the confusion, for me the latest is the last release from coutts is:
https://bitbucket.org/coutts/1000d_dev/src (https://bitbucket.org/coutts/1000d_dev/src)
But this is not ML. Are you porting ML or something else?
QuoteNow I see. But why you are playing with LEDs and don't modifying VxWorks branch
We're gonna use our 1000D as christmass decoration this year, hanging in a tree with blinking leds ;D
I know it is not ML, I was using it as base to get into ML development.
I totally new to this.
Since I couldn't find a description about the workflow on how to port ML to a camera, I tried to understand everything first.
If you look at the date of this thread, you would realize that we just started.
It helps that we just have a basic project like the one from coutts to play with.
Also it is the only project of the canon 1000D that I know or could find.
How can I start porting something if I don't understand the basics?
Yesterday we didn't have a boot flag that was set.
Quote from: Levas on December 06, 2016, 09:19:13 PM
We're gonna use our 1000D as christmass decoration this year, hanging in a tree with blinking leds ;D
So you need to rename this topic again - and you will celebrate till 2018. ;D
I am hoping to port ML, but at this point any custom firmware like chdk or ML works :)
OHhhh so the autoexec.bin file is if you already have ML installed,
The .fir file gotten from the assemble_fw file patches the script into the .fir file !!!
Good work by the way, Syscall.
You now a lot more about the technical side then I do.
So you set the bootflag, can you share the FIR file you did it with?
This way we could just run autoexec.bin at startup, no more firmware updates.
I'm just new to the magic lantern source files and finding my way to find addresses in firmware.
So I hope I can help when you're a little further in finding your way in magic lantern.
@shmadul
You're right.
Normally to run ML you don't need the fir file.
Once you enabled the bootflag, ML runs with autoexec bin file and the ML files in the ML directory on your SD card
any ideas ? I found this on the web :)
" I finally figured out why my code did not work with autoboot before, one tweak should fix things:
in link.script, change:
Quote
first 0x800120 :
to:
Quote
first 0x7F0000 :
Also, add this function to main.c:
Quote
void COPY() {
int i;
long *from = (long*) 0x800000;
long *to = (long*) 0x7F0000;
for (i = 0; i < 0x100000; i++) {
to = from;
}
}
and in entry.S modify it to look like this(I have bolded the one addition):
Quote
.text
.org 0
.globl _start, start
start:
_start:
BL COPY
BL my_LedBlueOn
B loc_FF810054
The problem was that before, the link script said to link the code to 0x800120, but the makefile linked it to 0x7F0000. This doesn't work because the code is actually loaded to 0x800000 by the bootloader. We first need to copy our code from 0x800000 to 0x7F0000 (a safe spot in memory, 0x800000 will be overwritten by the canon firmware during the boot process). Then our code will be executed from there.
"
Quote from: SysCall on December 08, 2016, 07:36:12 PM
I'm not able to set the boot flag each time I disable it. Sometime it works, sometime it does not.
Try to use modified 5DC installer. Maybe it will be more stable...
@Ant123 Where's that located ??
I'm out of the game.
I just successfully bricked my camera.
I managed to enable and disable the boot flag a few times in row without any issues and then ...
Now the boot flag says BOOT=-348549156
Camera can still read the autoexec.bin after removing the battery and put it back.
Black screen when no SD card or none bootable SD card is inserted.
Picture:
https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss (https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss)
@Syscall
"Funktion" is German for Function (2 years of German finally paying off LOL)
unless i'm mistaken Canon is a Japanese company.... Not sure why German is being used here, Could be part of the issue ??
@syscall :'(
Have you checked ur battery, Sounds Stupid, but its been my battery many many times just try plugging your battery in for 20-30 mins and then try and boot up your camera
(Try without SD)
Quote from: shmadul on December 08, 2016, 10:18:39 PM
@Ant123 Where's that located ??
On your computer.
But first you need to modify and complie this code (https://bitbucket.org/hudson/magic-lantern/src/18ac6b0f992918c7ba6dd282c3e74ca42574561c/installer/5DC.111/bootdisk.c?at=vxworks)
Quote from: SysCall on December 08, 2016, 10:25:47 PM
I'm out of the game.
I just successfully bricked my camera.
I managed to enable and disable the boot flag a few times in row without any issues and then ...
http://www.magiclantern.fm/forum/index.php?board=45.0 (http://www.magiclantern.fm/forum/index.php?board=45.0)
Wow, you bricked your 1000d camera ?
I just wanted to post that I want to check out setting the bootflag this weekend, but now I'm scared :o
Anything here:
http://www.magiclantern.fm/forum/index.php?board=45.0 (http://www.magiclantern.fm/forum/index.php?board=45.0)
@shmadul
Quote"Funktion" is German for Function (2 years of German finally paying off LOL)
It has nothing to do with the naming.
Coutts was german himself that is why he named it "Funktion", you can name it whatever you want even Ffuisdb() would work.
@Syscall
Did Some Digging Try these
Re: How do disable Bootdisk flag on a 5D Mk III
« Reply #36 on: September 24, 2013, 04:12:57 PM »
Hi all.
First of all, Thank you all developer.
I'm thinking about this problem. And yesterday, I built magiclantern compiling system.
I modified latest source code, and made special autoexec.bin.
This modification is calling "Disalbebootdisk" at auto save toggle.
I was dumping address at before and after modification, call"Disablebootdisk"
I checked these dumping result. Offset+4 address from 0xF8000000 is changing from 0xFFFFFFFF
to 0x00000000. This is clearing boot flag. But, I found some different point at other address. woo... :'(
May be, some developer is thinking that this result is occerd a bad influence on camera function.
After disable boot flag, I updated canon firm V1.2.1.
At present, I can't find a problem.
System boot time become so fast. and Eye-fi card is enable.
void
config_autosave_toggle(void* priv)
{
#if 0
config_flag_file_setting_save(CONFIG_AUTOSAVE_FLAG_FILE, !!config_autosave);
msleep(50);
config_autosave = !config_flag_file_setting_load(CONFIG_AUTOSAVE_FLAG_FILE);
#endif
bmp_printf(FONT_LARGE, 50, 50, "disable flag start");
call( "DisableBootDisk" );
bmp_printf(FONT_LARGE, 50, 50, "disable flag end");
}
Good Luck also Source :https://www.magiclantern.fm/forum/index.php?topic=6035.25
Interesting, if I set the dial to macro mode and push the shutter button the flash opens XD
:o :D
@Syscall
Just wondering, is the 1000d your main camera, your one and only camera?
@Levas
It was my backup, time lapse and magic lantern dev camera.
My main camera is the Canon 80D, maybe I should hang the 1000d on my tripod now to stabilize it :P
Ah, good it was not your main camera 8)
But you need to unbrick it, otherwise I don't dare to try more stuff on the 1000d
My main camera is a 6d, but I'd rather have my 1000d as a backup cam instead of a brick to stabilize my tripod :P
I just removed my instruction on how to set the boot flag to prevent others from bricking their cameras.
Wait so Did anything above help ?
also what bricked it ? was it the fact that you set the bootdisk to a - value or the fact that you enabled it at all ?
@syscall so you are still able to boot into magic lantern recovery ??
Please Report wether you get this fixed and how because unlike you, The 1000D is my main Camera and i cant risk it bricking :P
Whats next after we have bootdisk enabled ?
Quote from: SysCall on December 08, 2016, 10:25:47 PM
https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss
(http://a1ex.magiclantern.fm/bleeding-edge/qemu/1000D-qemu-brick.png)
CF is not a startup disk.
Now jump to RAMEXEC!!
Should be easy to fix:
asm("LDR PC, =0xF8010000");
autoexec.bin (http://a1ex.magiclantern.fm/debug/vx-jump/autoexec.bin)
See also http://magiclantern.wikia.com/wiki/Bootflags
@syscall any Luck ?
@a1ex, Whats next after we have bootdisk enabled ?
@ a1ex
Thank you very much for your help.
Here is my observation so far if someone is interested.
----------------------------------------------------------------------------------------------
What happened:
After enabling and disabling the boot flag several times the camera stops booting.
Why would I enable and disable multi times?
I want to make sure that it works stable, before posting it.
Camera still load autoexec.bin if the SD card was prepared for autoboot.
Observation:
Camera stays black after turning on, regardless of normal SD card or if it was made bootable.
Camera still functioning, if looking through the view finder, settings like aperture or exposure time can still be changed.
Taking picture is not possible only focus when pressing the shutter button.
Test 1:
-------
Putting display test (Magic Lantern Rescue) autoexec.bin on a bootable SD card shows:
Boot flags:
FIR=1610949440
BOOT=-348549156
RAM=-304267216
UPD=-1
Test 2:
-------
Putting (RAMEXEC fix) autoexec.bin from a1ex on the bootable SD card:
Camera boots up into canon menu, camera operates normal, taking pictures also possible now.
Magic Lantern Rescue still shows the same values.
Then did "clear setting" in canons menu, no changes.
Test 3:
-------
Same configuration as Test 2 plus canon original firmware update (e6kr5107.fir):
After updating the firmware, the FIR was reseted to zero. Rest still the same.
Boot flags:
FIR=0
BOOT=-348549156
RAM=-304267216
UPD=-1
Test 4:
-------
Same configuration as Test 2, now with the .fir that I compiled myself and was using to disable the boot flag.
After booting up and executed the .fir in menu update, camera boots up normal.
Looking again in the Magic Lantern Rescue shows:
Boot flags:
FIR=0
BOOT=0
RAM=-304267216
UPD=-1
The only thing that is not reseted is the RAM, which is still RAM=-304267216 instead of RAM=-1.
But now the camera still need a bootable SD card and the RAMEXEC fix autoexec.bin (or valid autoexec.bin) to boot into orignal firmware. When booting without SD card, the camera shows black screen, but still focus if press shutter button.
The interesting part is, even the Magic Lantern Rescue menu shows BOOT=0, the camera still auto execute the autoexec.bin.
Also, usually if the camera has the latest update it says "latest firmware installed" or something similar and
refuse a firmware update, but I'm still able to update the original firmware update as many time as I want.
@shmadul
1. Making dumps of RAM and ROM of the camera
2. Map all the magic lantern functions to the addresses located in the RAM
Magic Lantern use most of the standard functions of the original firmware which is loaded into the RAM after the boot up.
What you have to do is to "hook" (I think that is the term for it) those functions in the stubs.S file.
BTW, Ant123 gave you already the answer.
Quote
If you want to convert 450D port, the first thing you should do is set bootflag and check it with help of AUTOEXEC.BIN from "display test" topic. It's because all VxWorks ports use AUTOEXEC.BIN startup method.
Then you should find addresses of functions for 1000D in your firmware dump and change them in "\platform\450D.110\stubs.S". It can take many days or weeks.
After this you should edit cache related stuff in "\platform\450D.110\init.c", and edit another files in "\platform\450D.110\" and in "\src"
Quote
The interesting part is, even the Magic Lantern Rescue menu shows BOOT=0, the camera still auto execute the autoexec.bin.
That's because both autoexec.bin and ramexec are handled from the same routine, which happens to check the card bootflags first. You were quite lucky with this one; by disabling the boot flag, you risked removing the ability to run user code on the camera (other than ramexec, which simply jumps to 0x800000 without initializing that memory area; it assumes something was already loaded there somehow).
I wouldn't advise messing with boot flags just to see what happens, as you may get a configuration that no longer boots at all. In particular, on DIGIC 5, such configuration is very easy to get by changing the value at 0xF8000024 (even by mistake). Recovery from this would only be possible with hardware changes (lookup Ant123's posts on CHDK forum for an example).
Do you still have the FIR file that bricked the camera? It would be helpful to understand what happened.
Quote from: SysCall on December 09, 2016, 09:44:25 PM
I want to make sure that it works stable, before posting it.
You should not reinvent the wheel. Use modified common installer for VxWorks cameras (https://bitbucket.org/hudson/magic-lantern/src/18ac6b0f992918c7ba6dd282c3e74ca42574561c/installer/450D.110/bootdisk.c?at=vxworks).
You can also easily modify it to repair you camera.
@Ant123
QuoteYou should not reinvent the wheel.
No, that was not my intention, but maybe I should test it by myself before post it for others. At least I felt the needed to do some kind of verification. I always went with the mindset that I could damage my camera for this project. At least if I damage it myself, I can blame myself for it. Now, what if I just post the .fir and someone else brick their camera. Of course, even if state "use at your own risk", people would not be happy with it.
Especially if it is the only camera that they own:
QuoteThe 1000D is my main Camera and I can't risk it bricking
Of course you can argue, this is the development section and not the release section.
QuoteUse modified common installer for VxWorks cameras. You can also easily modify it to repair you camera.
After reading this I'm not sure if it is that easy.
QuotePosted by: a1ex
« on: Yesterday at 10:40:25 PM »
You were quite lucky with this one;
...
I wouldn't advise messing with boot flags just to see what happens, as you may get a configuration that no longer boots at all. In particular, on DIGIC 5, such configuration is very easy to get by changing the value at 0xF8000024 (even by mistake). Recovery from this would only be possible with hardware changes (lookup Ant123's posts on CHDK forum for an example).
I do appreciate you and a1ex to take the time to give us advices and answer the questions.
You guys surely have better stuff to do then answering noob questions.
Warning: Still under investigation, don't try anything described below if you don't want to damage your camera.
a1ex mentioned:
Quote
The boot flag can be enabled from both bootloader context (as done in the old 5D) or from main firmware.
EnableBootDisk only works from main firmware, but usually there is an equivalent bootloader routine, found in the FROMUTIL menu.
I tried with EnableBootDisk in the firmware.
In entry_stubs.S are the following function references defined.
NSTUB(EnableBootDisk, 0xFFD21248)
NSTUB(DisableBootDisk, 0xFFD21260)
Only, calling them in the main.c does not enable or disable the boot flag.
Coutts (original author) defined a pointer in the main.h
typedef void (*Funktion)();and call it the main.c with the address of the EnableBootDisk.
// EnableBootDisk()
Funktion f = 0xFFD21248;
f();
By doing this the boot flag gets enabled.
Calling this:
// DisableBootDisk()
/* Funktion f = 0xFFD21260;
f();
will disable it again.
At least that is what I observed.
@Ant123
QuoteUse modified common installer for VxWorks cameras.
Just for my understanding.
The installer enables the boot flag from the bootloader context?
You also needed the address of the write and read functions.
* 0xFFFF89F0 | start of write_bootflag in 5dc BL.
* 0xFFFF8A94 | end of write_bootflag in 5dc BL.
* 0xFFFF8AE0 | start of read_bootflag in 5dc BL.
* 0xFFFF8B20 | end of read_bootflag in 5dc BL.To find those addresses I have to do this:
Quote* I located these functions by hand using the 400d bootloader as a reference. I had
* to write code to search the bootloader region (0xFFFF0000-0xFFFFFFFF) for signatures
* of the read_bootflag and write_bootflag functions. It was a very long/tedious process
* checking each address one at a time - blinking everything through the LEDs. These
* routines are safe to run to the best of my knowledge, I have not had any issues yet.
Digging a little bit in this thread:
https://www.magiclantern.fm/forum/index.php?topic=1452.0
Coutts said:
Quote
If 40d is similar to the 5dc, then you won't be able to run any practical code from a FIR (including calling the EnableBootDisk function or booting the firmware/camera) so you will need
to write some code that scans the bootloader area (0xFFFF0000-0xFFFFFFFF) for function signatures to identify the read/write bootflag functions. This will allow you to set the camera's bootflag,
to boot an autoexec.bin file with a prepared card, and development takes off from there (you will be able to boot the firmware and do anything from autoexec). I created this bootdisk code from the 350d method, using the 400d bootloader to find the signatures I needed.
You can use this to write code to search for specific signatures of the read_bootflag and write_bootflag functions.
Some signatures would be instructions like:
MOVEQ R7, #0xF8000000
which is assembled and looks like this in memory:
0x03A0733E
I'll just tell you the signatures to find.
First, for write_bootflag. Here is a small snippet from that function, the first 5 instructions:
ROM:FFFF89F0 STMFD SP!, {R4-R8,LR}
ROM:FFFF89F4 MOV R5, R1
ROM:FFFF89F8 MOV R4, #0
ROM:FFFF89FC CMP R0, #0
ROM:FFFF8A00 MOVNE R7, #0xF8000000
If you were scanning memory, these 5 instructions would look like this(starting at 0xFFFF89F0 on the left and ending on 0xFFFF8A00 on the right):
0xE92D41F0 0xE1A05001 0xE3A04000 0xE3500000 0x13A0733E
So, look for the signature for the MOVNE R7, #0xF8000000 instruction, then once you find it, search backwards for the STMFD (push) instruction signature, and you will have located write_bootflag in the 40d bootloader. Chances are the functions will probably be identical, but take caution to verify at least 3 times that you have located the correct function and it seems the same / similar to the 5dc one (remember we are working blind here).
Now, read_bootflag. First 5 instructions look like:
ROM:FFFF8AE0 STR LR, [SP,#var_4]!
ROM:FFFF8AE4 CMP R0, #0
ROM:FFFF8AE8 MOVNE R3, #0xF8000000
ROM:FFFF8AEC ADDNE R3, R3, #0x2000
ROM:FFFF8AF0 MOVNE R2, #0x40
And in memory would look like this (same thing as before, starting at 0xFFFF8AE0 on left and ending at 0xFFFF8AF0 on the right):
0xE52DE004 0xE3500000 0x3E33A013 0x12833A02 0x13A02040
Note: there isn't a STMFD (push) instruction in read_bootflag. The 400d bootloader is like this too, so chances are the 40d is as well.
Now there are a few things that I don't understand.
1.
Search for specific signatures of the read_bootflag and write_bootflag functions
According to the two sources I have to blink through the address range (0xFFFF0000-0xFFFFFFFF) and find the "signature".
Where I can find the asm signature?
Example:
Do I have to blink one address and then make a ROM dump?
Afterwards I would load the ROM.BIN in IDA and jump to the part where I did the blinking and check if I can see the signature?
Otherwise I don't know how he gets the assembly instructions:
QuoteROM:FFFF89F0 STMFD SP!, {R4-R8,LR}
ROM:FFFF89F4 MOV R5, R1
ROM:FFFF89F8 MOV R4, #0
ROM:FFFF89FC CMP R0, #0
ROM:FFFF8A00 MOVNE R7, #0xF8000000
2.
I don't know why Coutts skip the installer way and try "to invent the wheel new" by the EnableBootDisk / DisableBootDisk in his last release?
Maybe because he doesn't want to blink the whole address range again for the canon 1000d?
Quote from: SysCall on December 10, 2016, 12:05:25 PM
The installer enables the boot flag from the bootloader context?
You also needed the address of the write and read functions.
I think 5DC installer is documented well enough.
Quote
Do I have to blink one address and then make a ROM dump?
Maybe because he doesn't want to blink the whole address range again for the canon 1000d?
I suspect that bootloader should be the same for different firmware versions.
http://www.magiclantern.fm/forum/index.php?topic=18337.msg176013#msg176013 (http://www.magiclantern.fm/forum/index.php?topic=18337.msg176013#msg176013)
But you can create your own dump using dumpmemo() (https://bitbucket.org/coutts/1000d_dev/src/a7835d17602fe2de51fda54d372f48ede290858e/main.c?at=default&fileviewer=file-view-default#main.c-9) function
Any Progress ?
I wrote a small sequence, which will help us to find the signature.
We know that the functions are in the boot loader area, from FFFF0000 to FFFFFFFF.
The program will create a log file on the SD card with the address and content within the boot loader area.
// Function to read the content of the bootloader and write it to logfile
void booloader_mem_dump_0()
{
// Create a logfile
MyGlobalStdSet();
// We use this pointer to read the content of an address
unsigned int *p_addr = NULL;
// The address range of the boot loader is from 0xFFFF0000 to 0xFFFFFFFF
// START_ADR: 0xFFFF0000
// END_ADR: 0xFFFFFFFC (last address not relevant, therefore 0xFFFFFFFC instead of 0xFFFFFFFF)
//
// Each address holds a 32 bit value => 4 bytes, therefore we have to increment the address by 4.
// 0xFFFF0000
// 0xFFFF0004
// 0xFFFF0008
// 0xFFFF000C
// ...
//
printf("\nAddr: Data");
printf("\n---------------");
for(unsigned int i=START_ADR; ((i <= END_ADR) && (i!=0)); i=i+4)
{
// Before assignment, "reset" the pointer to null
p_addr = NULL;
// Now point to the content of the address (in this case "i" is the address)
p_addr = *(int*)i;
// Write the data to the log file
printf("\n%x : %x", i, p_addr);
}
printf("\n\n END \n\n");
// Set pointer to null, since we not needed anymore.
p_addr = NULL;
// Signal finish
SleepTask(5000);
LEDRED = LEDON;
LEDBLUE = LEDON;
SleepTask(5000);
LEDRED = LEDOFF;
LEDBLUE = LEDOFF;
}
// ------------------------------------------------
@shmadul and Levas
We will continue once we found the boot flag functions, therefore we have to make sure that the boot flag functions are correct.
Note: The program will not do anything to the boot flag!
Link: https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss (https://1drv.ms/f/s!AsC1K_kH7N9pbYhpDPUbSuC8Iss)
1. Download the zip "bootloader_mem_dump.zip" and extract it
2. Build the project by "./run" in terminal (inside the folder)
3. Set the "Auto power of" to 8 or 15 minutes on your camera, we don't want to cancel the write process in between
4. Copy the .fir file on the SD card and execute it (don't touch any buttons afterwards)
5. After the sequence finish (both led, red and blue, turn on and off), copy the "address_log.txt" to your computer
6. Search now for signatures
Log file should look like this (example):
Addr: Data
------------------------
ffff0000 : e59ff018
ffff0004 : e59ff018
....
Now, go through the file and search for the signature (see below, compare Data with the values below).
Once you found them copy the whole section (including address and data) and post it here, then we compare if we all have the same addresses.
// ---------------------------------------------
Signatures
Attention: The order is very important!
The write function should be easy to find. Compare the data values in the log file with the following values.
write_bootflag signature (order of the data):
Quote
Data
--------------
E92D41F0
E1A05001
E3A04000
E3500000
13A0733E
The read function will differ from the one that is posted here.
Hint, search first all sequences that has E52DE004 and E3500000. Then search if the sequence has the rest values (3E33A013, 12833A02, 13A02040). The read functions has 2 values (unique) which differs from the sequence listed below.
Lets see if you guys can find the sequence.
read_bootflag signature (order of the data):
Quote
Data
--------------
E52DE004
E3500000
3E33A013
12833A02
13A02040
PS: Can you guys provide me your log files so I can check if there is any differences between them? Just PM me with the link.
@Syscall keep up the good work ;D
Will check it out tomorrow and send the log file
Luckiliy your 1000d is no longer a brick :D
Run the program on my 1000d which has version 1.0.7 canon firmware.
Searched the log file:
write_bootflag signature:
ffff5fe0 : e92d41f0
ffff5fe4 : e1a05001
ffff5fe8 : e3a04000
ffff5fec : e3500000
ffff5ff0 : 13a0733e
read_bootflag signature:
Couldn't find something exactly similar, but I did found this
ffff60d0 : e52de004
ffff60d4 : e3500000
ffff60d8 : 13a0333e
ffff60dc : 12833a02
ffff60e0 : 13a020aa
My logfile:
https://drive.google.com/drive/folders/0B1BxGc3dfMDaRUZweUJ5NWZUTTQ?usp=sharing (https://drive.google.com/drive/folders/0B1BxGc3dfMDaRUZweUJ5NWZUTTQ?usp=sharing)
You are strange people...
Printig bootloader memory values to log file instead making full ROM dump. Why?
I'm just following orders :D
@Levas
Perfect, confirmed.
I got the same result :D .
Now we can working on the bootflag installer.
Only one thing left is, I have to find out the write_card_bootflag address for canon 1000d.
From 450D port:
https://bitbucket.org/hudson/magic-lantern/src/18ac6b0f992918c7ba6dd282c3e74ca42574561c/installer/450D.110/bootdisk.c?at=vxworks&fileviewer=file-view-default#bootdisk.c-156 (https://bitbucket.org/hudson/magic-lantern/src/18ac6b0f992918c7ba6dd282c3e74ca42574561c/installer/450D.110/bootdisk.c?at=vxworks&fileviewer=file-view-default#bootdisk.c-156)
Quote
//~ Not sure if this is correct or not
write_card_bootflag = (ft_write_card_bootflag)0xFFFF4140;
I have read that someone just skip it and make the SD card bootable manually.
Quote from: SysCall on December 15, 2016, 07:51:11 PM
I have read that someone just skip it and make the SD card bootable manually.
On 450D write_card_bootflag() function works well.
I forgot to delete the comment.
@Ant123
Quote from: Ant123 on December 15, 2016, 03:42:18 PM
You are strange people...
Printig bootloader memory values to log file instead making full ROM dump. Why?
Thats because I did not have the correct setup yet. Even if have a dump I could not do anything with it.
Correct me if I'm wrong, but most people are using IDA Pro or GPL Tools/ARM console and QEMU for debugging.
I have difficulties to set it up on Mac OS, I'm considering to switch to linux and setup everything there.
QuoteOn 450D write_card_bootflag() function works well.
Is it a global function that you just can call?
In the installer it is defined as typedef:
typedef void (*ft_write_card_bootflag)(int arg0);How do you determine the address (0xFFFF4140) anyway?
write_card_bootflag = (ft_write_card_bootflag)0xFFFF4140;
Quote from: SysCall on December 15, 2016, 09:34:01 PM
Correct me if I'm wrong, but most people are using IDA Pro or GPL Tools/ARM console.
There is no another way to make ML port.
QuoteIs it a global function that you just can call?
Yes.
QuoteHow do you determine the address (0xFFFF4140) anyway?
Just looked on the bootloader code.
ROM:FFFF29A4 04 E0 2D E5 STR LR, [SP,#-4]!
ROM:FFFF29A8 80 D0 4D E2 SUB SP, SP, #0x80
ROM:FFFF29AC 11 0F 8F E2 ADR R0, aYouChoseTheWri ; "You chose the writing of a Volume Label"...
ROM:FFFF29B0 76 27 00 EB BL sub_FFFFC790
ROM:FFFF29B4 0D 10 A0 E1 MOV R1, SP
ROM:FFFF29B8 1B 0F 8F E2 ADR R0, aMayIWriteYN ; "May I write(Y/N)? :"
ROM:FFFF29BC 80 20 A0 E3 MOV R2, #0x80
ROM:FFFF29C0 41 00 00 EB BL sub_FFFF2ACC
ROM:FFFF29C4 00 00 DD E5 LDRB R0, [SP]
ROM:FFFF29C8 79 00 50 E3 CMP R0, #0x79 ; 'y'
ROM:FFFF29CC 00 00 DD 15 LDRNEB R0, [SP]
ROM:FFFF29D0 59 00 50 13 CMPNE R0, #0x59 ; 'Y'
ROM:FFFF29D4 05 00 00 1A BNE loc_FFFF29F0
ROM:FFFF29D8 00 00 A0 E3 MOV R0, #0
ROM:FFFF29DC D7 05 00 EB BL sub_FFFF4140
ROM:FFFF29E0 16 3F 8F E2 ADR R3, aWriteError_ ; "WRITE error.\n"
ROM:FFFF29E4 19 2F 8F E2 ADR R2, aWriteDone_ ; "WRITE done.\n"
ROM:FFFF29E8 00 10 A0 E3 MOV R1, #0
ROM:FFFF29EC 32 00 00 EB BL sub_FFFF2ABC
@Ant123
Cool, thank you very much.
//---------------------------------------
Note to myself:
Link: https://www.magiclantern.fm/forum/index.php?topic=12627.25
Quotestep 0: setup the toolchain (you can also do it like this)
step 1: dump the firmware (see a couple posts back)
step 2: analyze/decompile the firmware dump to find function stubs
step 3: run it in QEMU
step 4: if you get this far, get in touch with a1ex to create a bootflag fir, so you can run on actual camera
see also: some of the porting work done by recently for 70D (look at the commit history and diffs):
https://bitbucket.org/hudson/magic-lantern/branch/70d-support
https://bitbucket.org/hudson/magic-lantern/pull-request/620/add-support-for-eos-70d-111-both-revisions/diff#
Ok, I just found out how to disassemble the ROM.BIN.
As Ant123 mentioned earlier, in the "bootloader_mem_dump/main.c" just replace in "void MyTask2()"
booloader_mem_dump_0();
with
dumpmemo();
Now, compile and executed it on the camera.
After the dump finished, two files should be on the SD card.
RAMDUMP.BIN
ROMDUMP.BIN
Afterwards, follow the instruction from this link:
https://www.magiclantern.fm/forum/index.php?topic=12177.0
If you followed this thread (for Mac OS), update the "disassemble.pl" to this.
# adjust these for your needs (note final slash):
$path = "~/gcc-arm-none-eabi-4_8-2013q4/bin/";
# note on "strings": default is a minimum length of 4 chars.
# So if u are hunting for e.g. "FI2" add -n3
# However, it gives a lot of false positive.
$strdump = "strings -t x";
$objdump = "${path}arm-none-eabi-objdump";
$objcopy = "${path}arm-none-eabi-objcopy";
Now, looking at the main.c code, the ROM dump starts at FF800000, so modify the call like this.
perl disassemble.pl 0xFF800000 ROMDUMP.BIN
Once finished, open the "ROMDUMP.BIN.dis" in a text file.
---------------------
The write_bootflag and read_bootflag for the canon 1000d look like this in assembly.
write_bootflag:
Address reg value ASM code / instruction
--------- ----------- -------------------------
ffff5fe0: e92d41f0 push {r4, r5, r6, r7, r8, lr}
ffff5fe4: e1a05001 mov r5, r1
ffff5fe8: e3a04000 mov r4, #0
ffff5fec: e3500000 cmp r0, #0
ffff5ff0: 13a0733e movne r7, #-134217728 ; 0xf8000000
read_bootflag:
Address reg value ASM code / instruction
--------- ----------- -------------------------
ffff60d0: e52de004 push {lr} ; (str lr, [sp, #-4]!)
ffff60d4: e3500000 cmp r0, #0
ffff60d8: 13a0333e movne r3, #-134217728 ; 0xf8000000
ffff60dc: 12833a02 addne r3, r3, #8192 ; 0x2000
ffff60e0: 13a020aa movne r2, #170 ; 0xaa
Next step would be to find the addresses of the functions for the 1000D and add them to the stubs.S.
This will take time ...
ML on the 1000 would be awesome, thank you!
I use my 1000D as "every day camera", becuase it's lighter and smaller than my 50D and 5D2, and it still rocks!
Can't help you with this port, 'cause I suck with programming, but just wanted to thank you ;)
Any Progress
Not really, I was too busy photographing, I hope my Canon 1000D does not brake anytime soon (over 53000 shutter counts), to much time-lapse :D
I can't tell about any progress soon, because I want to use the summer and the good weather as much as possible.
Anyway, I started with the stubs.S and found so far a few function entry points (see below).
Note: Keep in mind the entry points (function addresses) are not verified yet nor tested.
Lines with "//SC" are the ones modified or updated with the addresses for the 1000D, again no guarantee that they are correct!
File: stubs.S
/** \file
* Entry points into the firmware image.
*
* These are the functio//NS that we can call from our tasks
* in the Canon 1.0.9 firmware for the 450d.
*
* \todo Sort this file? Generate it from the IDA map?
*/
/*
* Copyright (C) 2010 Magic Lantern Team
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public Lice//NSe
* as published by the Free Software Foundation; either version 2
* of the Lice//NSe, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public Lice//NSe for more details.
*
* You should have received a copy of the GNU General Public Lice//NSe
* along with this program; if not, write to the
* Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor,
* Boston, MA 02110-1301, USA.
*/
#include <stub.h>
.text
//NSTUB( ROMBASEADDR, firmware_entry )
//NSTUB(0xFFCFEBD4, AcquireRecursiveLock)
NSTUB(0xFF855870, AllocateFileCacheBuffer) //SC
NSTUB(0xffd1cc88, AllocateMemory) //SC
NSTUB(0xffd1cc88, _AllocateMemory) //SC
NSTUB(0xff960420, CreateDialogBox) //SC
NSTUB(0xFFD05A54, CreateTask) //SC
NSTUB(0xFFD0C544, CreateRecursiveLock) //SC
NSTUB(0xffd0c190, CreateMessageQueue) //SC
//NSTUB(0xFFD03C60, CreateMessageQueue) //SC from coutts
//NSTUB(0xff2ff7c4, DeleteDialogBox)
//NSTUB(0xFFD07654, DryosDebugMsg)
NSTUB(0xFFD0E1C4, dumpf)
//NSTUB(0xFFCCD90C, FIO_FindClose) // AJ__switch_0x1A50_n_calls_fstOpenDir FIO_FindClose
NSTUB(0xFFCDD570, FIO_CloseFile)
//NSTUB(0xFFCCD6DC, _FIO_CreateDirectory)
NSTUB(0xFFCDD558, _FIO_CreateFile) //SC
//NSTUB(0xFFCCCCD0, _FIO_FindFirstEx)
//NSTUB(0xFFCCCE34, FIO_FindNextEx)
NSTUB(0xffcd6f1c, _FIO_GetFileSize) // SC
NSTUB(0xFFCDD54C, _FIO_OpenFile) //SC
NSTUB(0xFFCDD57C, FIO_ReadFile) //SC
NSTUB(0xFFCDD564, _FIO_RemoveFile) // SC
NSTUB(0xFFCDD588, FIO_WriteFile) //SC
NSTUB(0xFFCDD594, FIO_SeekFile) //SC
//NSTUB(0xFFD16DB4, FreeMemory)
//NSTUB(0xFFD16DB4, _FreeMemory)
//NSTUB(0xff022004, GUI_ChangeMode)
//NSTUB(0xFF861F8C, GUI_Control)
NSTUB(0xffd44ef8, GUI_GetFirmVersion) //SC
//NSTUB(0xFF91E3BC, GetCFnData)
//NSTUB(0xff8dd40c, GuiEdLedBlink)
NSTUB(0xFF8DD40C, ___GuiEdLedBlink) //SC
//NSTUB(0xFF8DA670, GuiEdLedOff)
NSTUB(0xFF8DD3F4, ___GuiEdLedOff) //SC
//NSTUB(0xFF8DA640, GuiEdLedOn)
NSTUB(0xFF8DD3E0, ___GuiEdLedOn) //SC
NSTUB(0xFFD3F214, ioGlobalStdSet) //SC
//NSTUB(0xFFCF3C34, LoadCalendarFromRTC)
NSTUB(0xFF8458D4, MpuMonRead) //SC
NSTUB(0xFF845CFC, MpuMonWrite) //SC
//NSTUB(0xFFC6DD48, MuteOff_0)
//NSTUB(0xFFC6DDC4, MuteOn_0)
NSTUB(0xFFD04464, PostMessageQueue) //SC
NSTUB(0xFFD03FDC, ReceiveMessageQueue)
//NSTUB(0xFF97D5C4, RedrawDisplay)
//NSTUB(0xFFCFECFC, ReleaseRecursiveLock) // AJ_KernelDry_KerRLock.c_p2
//NSTUB(0xff15fd74, RemoteRelease)
NSTUB(0xFF855A54, RemoveAllFileCache) //SC
//NSTUB(0xff06f2fc, SetBitmapVramAddress)
//NSTUB(0xFF91E43C, SetCFnData)
//NSTUB(0xFF883E88, SetGUIRequestMode)
NSTUB(0xDD847338, TurnOnDisplay) //SC
NSTUB(0xFF8473BC, TurnOffDisplay) //SC
NSTUB(0xFFD046C0, TryPostMessageQueue) //SC
//NSTUB(0xff072f7c, _audio_ic_read)
//NSTUB(0xff0730c8, _audio_ic_write)
//NSTUB( 0x4154, additional_version) // or 4154 not sure
//NSTUB(0xFFD12088, alloc_dma_memory)
//NSTUB(0xFFD12088, _alloc_dma_memory)
//NSTUB( 0x30A90, bmp_vram_info ) // need checking
//NSTUB(0xffd7d718, bzero32) // memset at 0xffd7d718
//NSTUB(0xFFCF9788, call)
//NSTUB(0xC0220000, camera_engine)
////NSTUB(0xffd1989c, cfReadBlk)
NSTUB(0xFFCD9A34, cfReadBlk) //SC
//NSTUB( 0x314F8, cf_device) // not sure
//NSTUB(0xFFD2073C, cli_save)
//NSTUB(0xff01559c, create_init_task)
//NSTUB(0xFFCFEE00, create_named_semaphore)
//NSTUB(0xff010fb0, cstart)
//NSTUB(0xff2fe9f4, ctrlman_dispatch_event)
//NSTUB(0xFF95EF4C, dialog_redraw)
//NSTUB(0xFF8F0758, dialog_set_property_str)
//NSTUB( 0x2b18, dm_names)
//NSTUB(0xffd4cb6c, dm_set_store_level)
NSTUB(0xFFD3CC4C, free) //SC // not good points to FreeMemory
NSTUB(0xFFD3CC4C, _free) //SC // not good points to FreeMemory
//NSTUB(0xFFD120B4, free_dma_memory)
//NSTUB(0xFFD120B4, _free_dma_memory)
//NSTUB(0xff3d7798, fsuDecodePartitionTable) // AJ_fsuGetPart_related
//NSTUB(0xFFCFF390, give_semaphore)
//NSTUB(0xFF8646A4, gui_change_lcd_state_post)
//NSTUB(0xFF863B18, gui_change_mode)
NSTUB(0xFF864A4C, GUI_CHANGE_MODE) //SC
//NSTUB(0xFF8645E4, gui_change_shoot_type_post)
//NSTUB(0xFF861538, gui_init_end)
//NSTUB(0xFF8B3268, gui_init_event)
//NSTUB(0xFF863EE4, gui_local_post)
//NSTUB( 0x17530, gui_main_struct)
//NSTUB(0xFF861A28, gui_main_task)
//NSTUB(0xFF862734, gui_massive_event_loop)
//NSTUB(0xFF864380, gui_other_post)
//NSTUB(0xFF864514, gui_post_10000062)
//NSTUB(0xFF95BC58, gui_task_create)
//NSTUB(0xFF95BDA8, gui_task_destroy)
//NSTUB( 0x4AF8, gui_task_list)
//NSTUB(0xFFCFD6F4, gui_timer_something)
//NSTUB( 0x3624, gui_timer_struct)
//NSTUB(0xdeadbeef, init_task)
NSTUB(0xFFD3CC64, _malloc) //SC
//NSTUB(0xFFCFE720, msg_queue_post)
//NSTUB(0xFFCFE03C, msg_queue_receive)
NSTUB(0xFFD05708, msleep) // SC
////NSTUB(0xff1e0e04, mvrFixQScale)
////NSTUB(0xff1e0870, mvrSetDeblockingFilter)
////NSTUB(0xff1e08e0, mvrSetDefQScale)
////NSTUB(0xff1e0e24, mvrSetPrintMovieLog)
////NSTUB( 0xa39c, mvr_config)
////NSTUB(0xff078e6c, oneshot_timer)
//NSTUB(0xFFC35324, _prop_cleanup)
//NSTUB(0xFFC35144, prop_deliver)
//NSTUB(0xFFC35458, prop_get_value)
//NSTUB(0xFFC35200, prop_register_slave)
//NSTUB(0xFFC353AC, _prop_request_change)
//NSTUB(0xFFCF98C4, register_func)
////NSTUB(0xFFB97BF4, sdReadBlk) // might be good (dumps=1 score=8.2)
NSTUB(0xFFCDEBD8, sdReadBlk)
////NSTUB( 0x208D8, sd_device)
//NSTUB(0xFFD0ADA4, sei_restore)
////NSTUB( 0x1f54, sounddev)
////NSTUB(0xff063d64, sounddev_task)
////NSTUB(0xFF0640EC, sounddev_active_in)
//NSTUB(0xFFCFF1F4, take_semaphore)
//NSTUB(0xFFCFFAB4, task_create)
////NSTUB( 0x1934, task_dispatch_hook )
////NSTUB(0xff084ca4, task_trampoline)
////NSTUB(0xff2cb1e0, vram_get_number)
//NSTUB(0x00030528, vram_info)
//NSTUB(0xFFD08758, vsnprintf)
//NSTUB(0xFF8C1EA0, LiveViewApp_handler)
//NSTUB(0xFF8A6A04, PlayMain_handler)
////NSTUB(0xFF42B700, PlayMovieGuideApp_handler)
//NSTUB(0xFF8D560C, OlcAFFrameApp_handler)
//NSTUB(0xdeadbeef, ErrCardForLVApp_handler)
////NSTUB(0xFF3674A4, LiveViewWbApp_handler)
//NSTUB(0xFF8D64DC, ErrForCamera_handler) // ERR70 ERR80 etc (DlgErrForCamera.c AJ_DIALOG.HANDLER_DlgErrForCamera.c)
////NSTUB(0xff1f6b20, _engio_write)
////NSTUB(0xff1f664c, shamem_read) // AJ_0x8FB0_engio_struct_n_R0_manipulation_to_get_ptr
////NSTUB(0xff1f675c, _EngDrvOut) // AJ_EngDrvOut_1xVar_to_ShadowStruct
//NSTUB(0xFF8BBA54, ShootOlcApp_handler) // AJ_DIALOG.HANDLER_DlgShootOlcInfo.c
////NSTUB(0x29A9C, LCD_Palette) // in InitializeBitmapDisplayDevice right after 0xc0f14800
//NSTUB(0xFFD16E84, GetMemoryInformation)
//NSTUB(0xFFD06204, msg_queue_create)
////NSTUB(0xff0372b4, PD_RemoteRelease)
////NSTUB( 0xff16004c, PtpDps_remote_release_SW1_SW2_worker ) // called from: ptpRemoteRelease Occupy
// for task information
////NSTUB(0x2B24, task_max)
////NSTUB(0xFF087940, is_taskid_valid) // AJ_task_trampoline_related_p10
////NSTUB(0xff08779c, get_obj_attr) // AJ_checks_if_Process_id_created_by_Dryos
////NSTUB(0xff014c10, get_current_task)
//NSTUB(0xFFD17E18, AllocateMemoryResource) // m_pfAllocMemoryCBR
//NSTUB(0xFFD17E6C, AllocateContinuousMemoryResource) // m_pfContAllocMemoryCBR
//NSTUB(0xFFD17EC0, FreeMemoryResource) // m_pfFreeMemoryCBR
//NSTUB(0xFFD03548, GetFirstChunkFromSuite) // AJ_PackMemory_PackMem_p3
//NSTUB(0xFFD031B4, GetMemoryAddressOfMemoryChunk)
////NSTUB(0xff07365c, PowerAudioOutput)
////NSTUB(0xff061c44, StartASIFDMADAC)
////NSTUB(0xFF061A88, StartASIFDMAADC)
////NSTUB(0xff061d20, StopASIFDMADAC)
////NSTUB(0xFF0621C4, SetNextASIFADCBuffer) // called by SetNextUINT8ASIFADCBuffer and SetNextINT16ASIFADCBuffer
////NSTUB(0xFF06227C, SetNextASIFDACBuffer)
////NSTUB(0xff0736f4, SetSamplingRate )
////NSTUB(0xFF073944, SetAudioVolumeOut)
////NSTUB(0xFF06EDD0, AsyncEnableImagePhysicalScreenParameter)
////NSTUB(0xff06e8b0, EnableImagePhysicalScreenParameter)
//NSTUB(0xFF8A8C78, StartPlayProtectGuideApp)
NSTUB(0xFF8ABE0C, StartPlayProtectGuideApp) //SC
//NSTUB(0xFF8A9144, StopPlayProtectGuideApp)
NSTUB(0xFF8ABF1C, StopPlayProtectGuideApp) //SC
//NSTUB(0xFFCFFCC0, DeleteTask)
//NSTUB(0xFFD0068C, QueryTaskByName)
//NSTUB(0x30A98, LCD_Palette)
//NSTUB(0x30AD8, RGB_Palette)
//NSTUB(0x309C8, PB_Palette)
//NSTUB(0xFFC64BE8, SetRGBPaletteToDisplayDevice)
NSTUB(0xFFC6E838, SetRGBPaletteToDisplayDevice)
//NSTUB(0xFF8F08C4, ChangeColorPalette)
NSTUB(0xFF8F35A8, ChangeColorPalette)
//NSTUB(0xFFC63A88, SetParameterToBitmapDisplayDevice)
NSTUB(0xFFC6D6D4, SetParameterToBitmapDisplayDevice)
//NSTUB(0xFFC6D1EC, EnableBitmapVBufferForPlayBackAndWaiting)
NSTUB(0xFFC76AB0, EnableBitmapVBufferForPlayBackAndWaiting)
//NSTUB(0xFFC6B6B0, BmpDDev_give_semaphore)
//NSTUB(0xFFC6B660, BmpDDev_take_semaphore)
//NSTUB(0xFF81594C, bindGUISwitchCBR)
//NSTUB(0xFFCFDC18, register_interrupt)
//NSTUB(0xFFC3B624, SIO3_ISR)
NSTUB(0xFFC45108, MREQ_ISR)
//NSTUB(0xFFC3B55C, MREQ_ISR)
NSTUB(0xFFC45114, SIO3_ISR)
NSTUB(0xFFD04288, TryReceiveMessageQueue) // SC from coutts
//NSTUB(0xFFD0A7A0, TryPostEvent)
//NSTUB(0xFFD0A800, TryPostEvent_end)
//NSTUB(0xFFD1180C, TryPostStageEvent)
//NSTUB(0xFFD1197C, TryPostStageEvent_end) // PendStageEvent
//NSTUB(0xFFD28528, get_current_task) // 0x22E00
//NSTUB(0xFFD282EC, get_task_info)
//NSTUB(0xFFD29C10, get_active_task_list)
//NSTUB(0xFFD0A0D4, create_task_cmd_shell)
//NSTUB(0xFFB4AB18, ptp_register_handler)
//NSTUB(0xFFB42198, ptp_register_handlers_0x9800)
//NSTUB(0xFFD07654, DM_TryPostEvent)
NSTUB(0xFF841908, FA_Release) //SC
/** EDMAC routines **/
//NSTUB(0xFFCADCA0, SetEDmac)
//NSTUB(0xFFCADD00, StartEDmac)
//NSTUB(0xFFCADDC0, PopEDmac)
////NSTUB([idk], AbortEDmac)
//NSTUB(0xFFCADCC0, ConnectWriteEDmac)
//NSTUB(0xFFCADCDC, ConnectReadEDmac)
/** keep the old name until all are refcatored **/
////NSTUB(0xFFCADDA0, EDMAC_RegisterCompleteCBR)
/** register/unregister CBR names **/
//NSTUB(0xFFCADDA0, RegisterEDmacCompleteCBR)
//NSTUB(0xFFCADDD8, RegisterEDmacAbortCBR)
NSTUB(0xFFCB6D60, RegisterEDmacAbortCBR)
//NSTUB(0xFFCADE58, RegisterEDmacPopCBR)
//NSTUB(0xFFCADDC0, UnregisterEDmacCompleteCBR)
//NSTUB(0xFFCADE20, UnregisterEDmacAbortCBR)
NSTUB(0xFFCB6D80, UnregisterEDmacAbortCBR)
//NSTUB(0xFFCADE78, UnregisterEDmacPopCBR)
// DEF(0xffd18c2c, GetSizeOfMaxRegion) // SC
The 1000D GUI can now be emulated in QEMU (http://www.magiclantern.fm/forum/index.php?topic=2864.msg190254#msg190254) (same for the 450D ML (https://www.magiclantern.fm/forum/index.php?topic=8119.msg190270#msg190270)):
(https://builds.magiclantern.fm/jenkins/job/QEMU-tests/183/artifact/qemu/tests/1000D-menu.png)
What does this mean?
Porting ML on these VxWorks models just got easier by one (or maybe two) order(s) of magnitude - I hope it will be as easy as following the tutorial (https://www.magiclantern.fm/forum/index.php?topic=19417.0) and/or the walkthrough (http://www.magiclantern.fm/forum/index.php?topic=15895.msg185103#msg185103). The development tools run on all major operating systems (including Windows (http://www.magiclantern.fm/forum/index.php?topic=20214.0) and Mac (http://www.magiclantern.fm/forum/index.php?topic=2864.msg190015#msg190015)).
Good luck!
@a1ex
That is great, thanks a lot.
I have the Canon EOS Rebel XS DSLR. (also called the 1000d)
The Magic Lantern 1080p video recording program isn't listed on your site for my camera.
Could someone please upload the program for that specific camera?
I see a lot of people talked about making the file for this camera on this thread.
Did anyone ever do it?? I don't see a link anywhere on here to download the file for that camera.
If any of you have the download, can you please email me at
[email protected]?
Thanks!
PS: Would one of the mods mind sticking this thread to the "sticky posts" so that it is at the top of the message boards?
Thanks!
Unmaintained cams will not get a sticky thread. This is reserved for cams supported with nightly builds or (at least) labeled "Port in Progress". There is no ML for 1000D.
There is little to none for the 1000d.
Syscal did some important first steps, but nothing near a working port.
There is nothing yet, no Magic Lantern menu not a single Magic Lantern function etc.
Best way to make use of Magic Lantern is to buy another Canon DSLR which is compatible with Magic Lantern.
Click the 'Downloads' button at the top of this page and go to the 'Nightly builds' here you can see which camera's are supported.
Many of them are released many years ago, second hand they're really affordable.
Some are better supported then others (depending on the user base and if active developers support them) I believe the Classic Canon EOS-M is one of the better supported cheap cams.
1000D is such a great backup camera. It's sad to see the development was discontinued halfway..
Sad to see such a nice cam go down in history without anything to it's name. :(
It's 2018, but ML on this camera would still be awesome.
@Syscal Any updates on development?
http://wiki.magiclantern.fm/faq#any_progress_on_xyz
Development has not been discontinued - everything from the QEMU branch (https://bitbucket.org/hudson/magic-lantern/branch/qemu) is tested (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-tests/) on the 1000D firmware, too! (along with ~20 other models (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-tests/lastSuccessfulBuild/artifact/qemu-eos/tests/menu.png) able to run the GUI, and ~10 models (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-tests/lastBuild/console) not there yet)
I'm simply unable to take care of all these cameras alone (at least not in a timely fashion). It's now up to the community to follow (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst) our (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst) porting (http://www.magiclantern.fm/forum/index.php?topic=19417.0) guides (https://www.magiclantern.fm/forum/index.php?topic=15895.msg185084#msg185084) and do something about it ;)
Any news on the progress?
It looks like nobody is working on it at the moment. I did in the past but took a break.
a1ex still looking on the emulations side I guess.
I'm starting to looking into it again, from time to time.
Don't expect anything in the near future, but you can always join and help changing that :)
I had a look into this a couple of weeks ago, because I could have possibility to get a 1000D at a nearly bargain price which would be fun to play with it and learn how to reverse code.
So I found a dump of 1.0.5 to run into Qemu and started to analyze it.
However, while trying to find some stubs, I have noticed different patterns into disassembled code of 1000D compared to more recent cameras (50D)
Even simple stubs which can be found searchng for strings and then go up a couples of lines, they get hard to track for the function's entry point.
Having a dump of a 40D or 450D syde by side to 1000D could help understanding what to look for stubs and get development at the same point of the other two.
Had some fun yesterday hunting for stubs and I noticed that I can find the same code at different address which differ by an offset...
This is using disassembply.pl with argument "0xFF000000":
NSTUB(0xFF4D6F1C, _FIO_GetFileSize)
NSTUB(0xFF4D5D1C, _FIO_OpenFile)
NSTUB(0xFF4D6C40, FIO_ReadFile)
NSTUB(0xFF4D6B7C, _FIO_RemoveFile)
NSTUB(0xFF4D6DB0, FIO_WriteFile) //CF_Test.bin
This is what I get if I use "0xFF800000" as argument to disassemble.pl. To a quick look it sems to match IDA Disassembly when hunting for loc_xxxxx (the are named sub_xxxx instead).
NSTUB(0xFF960420, CreateDialogBox)
NSTUB(0xFFD0D5F4, DryosDebugMsg)
NSTUB(0xFFCD6E68, FIO_FindClose)
NSTUB(0xFFCD6E68, FIO_CloseFile)
NSTUB(0xFFCD7090, _FIO_CreateDirectory)
NSTUB(0xFFCD6AB8, _FIO_CreateFile)
NSTUB(0xFFCD67E8, FIO_FindNextEx)
NSTUB(0xFFCD6F1C, _FIO_GetFileSize
NSTUB(0xFFCD5D1C, _FIO_OpenFile)
NSTUB(0xFFCD6C40, FIO_ReadFile)
NSTUB(0xFFCD6B7C, _FIO_RemoveFile)
NSTUB(0xFFCD6DB0, FIO_WriteFile) //tracing "CF_Test.bin"
NSTUB(0xFF865060, GUI_Control)
NSTUB(0xFF896184, GUI_GetFirmVersion)
NSTUB(0xFF8DD5DC, GuiEdLedBlink)
NSTUB(0xFF8DD5AC, GuiEdLedOff)
NSTUB(0xFF8DD57C, GuiEdLedOn)
NSTUB(0xFFD05708, msleep)
NSTUB(0xFFD05A54, task_create)
NSTUB(0xFF887050, SetGUIRequestMode) //not sure - take more argument but has same code pattern
Is code in ROM duplicated also into other smaller range instead of 0xF8000000? Do I need to prefer the second range?
What I do is using 40D's dump and stubs address to find what appears to be the same address into 1000D's disassembly, hunting for function starting with same arguments number and similar refs number, near strings or particular instructions.
Is this method of code pattern matching valid? How can I use qemu to help me in this stage?
Yes, there are multiple copies of the same ROM; g3gg0 explains how it works here (https://www.magiclantern.fm/forum/index.php?topic=6785.msg58899#msg58899). QEMU also prints the memory map, so you can see where these copies are. See the Initial firmware analysis (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst?fileviewer=file-view-default#rst-header-initial-firmware-analysis) section in the RE guide.
You need to pick the address used by Canon code. Example for msleep:
./run_canon_fw.sh 1000D,firmware="boot=0" -d calls |& grep 05708
call 0xFFD05708(64, 0, 1, c022011c) at [tHotPlug:ff813224:ffd2f5d8]
...
How to read this:
- Canon code called the function 0xFFD05708 (so that's the one you should pick for stubs) from their HotPlug task, at PC=ff813224 and LR=ffd2f5d8 (go to these addresses in the disassembly to find out the caller code)
- first argument is 0x64 = 100 ms
- the call trace prints the first 4 arguments (R0-R3), but doesn't attempt to find out how many are actually used
- we already know the signature of msleep (from dryos.h: it takes only one argument, so the others should be ignored)
There are many QEMU examples in the EOS M2 thread (https://www.magiclantern.fm/forum/index.php?topic=15895.msg185084#msg185084); however, call trace support for VxWorks is not the best (it crashes quicky because it doesn't know how VxWorks performs task switching). I have a draft patch to get the current task ID, but for some reason, that doesn't seem to fix the warnings (maybe task IDs are reused? didn't look too much into it).
Done more patterns matching and got more stubs:
NSTUB(0xFFD0C558, CreateRecursiveLock) // **"CreateRecursiveLock"
NSTUB(0xFFD04B74, AcquireRecursiveLock)
NSTUB(0xFFD04C9C, ReleaseRecursiveLock) // AJ_KernelDry_KerRLock.c_p2
NSTUB(0xFFD05330, give_semaphore)
NSTUB(0xFF867778, gui_change_lcd_state_post)
NSTUB(0xFF866BEC, gui_change_mode)
NSTUB(0xFF8676B8, gui_change_shoot_type_post)
NSTUB(0xFF8645FC, gui_init_end)
NSTUB(0xFF8B6344, gui_init_event) // to be checked
NSTUB(0xff866fb8, gui_local_post)
NSTUB(0xff864aec, gui_main_task) // jump in the middle of procedure
NSTUB(0xff865808, gui_massive_event_loop) // similar to 40d
NSTUB(0xff867454, gui_other_post) // similar to 40d
NSTUB(0xff8675e8, gui_post_10000062) // to be checked
NSTUB(0xff95eb24, gui_task_create)
NSTUB(0xff95ec74, gui_task_destroy)
NSTUB(0xffd03694, gui_timer_something)
NSTUB(0xffd1cc88, AllocateMemory)
NSTUB(0xffd1cc88, _AllocateMemory)
NSTUB(0xffd1ccc8, FreeMemory)
NSTUB(0xffd1ccc8, _FreeMemory)
NSTUB(0xff97fd54, RedrawDisplay) // to be checked
NSTUB(0xffd18028, alloc_dma_memory) // takes one less parameter
NSTUB(0xffd18028, _alloc_dma_memory) // takes one less parameter
NSTUB(0xffd1ccc8, free) // not good points to FreeMemory
NSTUB(0xffd1ccc8, _free) // not good points to FreeMemory
NSTUB(0xffd56d2c, free_dma_memory)
NSTUB(0xffd56d2c, _free_dma_memory)
NSTUB(0xffd1cd98, GetMemoryInformation) // to be checked
NSTUB(0xFFD20B28, AllocateMemoryResource) // m_pfAllocMemoryCBR
NSTUB(0xFFD20B7C, AllocateContinuousMemoryResource) // m_pfContAllocMemoryCBR
NSTUB(0xFFD20BD0, FreeMemoryResource) // m_pfFreeMemoryCBR
NSTUB(0xFFD0931C, GetFirstChunkFromSuite) // AJ_PackMemory_PackMem_p3
NSTUB(0xFFD09154, GetMemoryAddressOfMemoryChunk)
NSTUB(0xFFD0C1A4, msg_queue_create) // **"CreateMessageQueue"
NSTUB(0xFFD046C0, msg_queue_post)
NSTUB(0xFFD03FDC, msg_queue_receive)
NSTUB(0xFFD0E6F8, vsnprintf) // to be checked
NSTUB(0xff8d9430, ErrForCamera_handler) // jump in the middle of procedure // ERR70 ERR80 etc (DlgErrForCamera.c AJ_DIALOG.HANDLER_DlgErrForCamera.c)
NSTUB(0xff8c4f34, LiveViewApp_handler) // used procedure entry point instead jumping in the middle like 40d (to be checked)
NSTUB(0xff8a9bb8, PlayMain_handler) // jump in the middle of procedure
NSTUB(0xffc74fac, BmpDDev_give_semaphore)
NSTUB(0xffc74f5c, BmpDDev_take_semaphore)
NSTUB(0xFFD04DA0, create_named_semaphore)
NSTUB(0xFFD05194, take_semaphore)
NSTUB(0xFFD31D8C, get_current_task)
NSTUB(0xFFD05C60, DeleteTask)
//NSTUB(0xFFD0062C, QueryTaskByName) // taken 40d pattern but jump in the middle of procedure
NSTUB(0xffd10074, create_task_cmd_shell)
NSTUB(0xffc3ecf4, _prop_cleanup) // similar, to be cheched
NSTUB(0xffc3ebd0, prop_register_slave)
I noticed that some stubs jump in the middle of a procedure and starts with a push to the stack. Is this correct?
Also some stubs form 40d like "malloc" and "free" have a comment stating "not good, points to FreeMemory/AllocateMemory" What need to be done?
Adding those stubs and this is what I currently get if I try to compile:
[ LD ] magiclantern
menu.o: In function `beta_should_warn':
menu.c:(.text+0xa3c): undefined reference to `LoadCalendarFromRTC'
menu.o: In function `handle_ml_menu_keys':
menu.c:(.text+0x7064): undefined reference to `LoadCalendarFromRTC'
gui.o: In function `ml_hijack_gui_main_task':
gui.c:(.text+0x264): undefined reference to `QueryTaskByName'
bmp.o: In function `set_ml_palette_if_dirty':
bmp.c:(.text+0x9d0): undefined reference to `PB_Palette'
config.o: In function `config_save_file':
config.c:(.text+0x7dc): undefined reference to `LoadCalendarFromRTC'
tweaks.o: In function `tweak_task':
tweaks.c:(.text+0xc): undefined reference to `LoadCalendarFromRTC'
lens.o: In function `clock_update':
lens.c:(.text+0x4f0): undefined reference to `LoadCalendarFromRTC'
bootflags.o: In function `bootflag_write_bootblock':
bootflags.c:(.text+0x238): undefined reference to `cf_device'
dialog_test.o: In function `get_current_dialog_handler':
dialog_test.c:(.text+0x14): undefined reference to `gui_task_list'
shoot.o: In function `display_idle':
shoot.c:(.text+0x368): undefined reference to `ShootOlcApp_handler'
zebra-5dc.o: In function `tic':
zebra-5dc.c:(.text+0xe08): undefined reference to `LoadCalendarFromRTC'
make: *** [magiclantern] Error 1
Solved most missing reference but "LoadCalendarFromRTC" is hard to track and I'm not sure about "QueryTaskByName"
// From 40D's stubs.s
//NSTUB(0x4AF8, gui_task_list)
//NSTUB(0x17530, gui_main_struct)
//NSTUB(0x314F8, cf_device)
//NSTUB(0x309C8, PB_Palette)
//NSTUB(0x2B24, task_max)
How can I find those RAM address?
Looking 40D "cstart" and "bzero32" are not used in stubs.s nor is warning during 1000D compilation. Does it need to be found at this stage or can get a working build to be run into qemu?
I need some time to read again M2 thread and look for something to try into emulation.
LoadCalendarFromRTC: try FFCFDA6C
cstart/bzero32 probably not needed (VxWorks model use a different method).
Need to do some digging to find the others.
When I try to run QEMU, I get only a gray image.
./run_canon_fw.sh 1000D,firmware=boot=1
DebugMsg=0xFFD0D5F4 (from GDB script)
Lockdown read 0
Lockdown read 0
Lockdown read 1
Lockdown read 1
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 0FFFFFFF: eos.ram
10001000 - 1FFFFFFF: eos.ram_uncached
10000000 - 10000FFF: eos.ram_uncached0
F8000000 - F87FFFFF: eos.rom1
F8800000 - F8FFFFFF: eos.rom1_mirror
F9000000 - F97FFFFF: eos.rom1_mirror
F9800000 - F9FFFFFF: eos.rom1_mirror
FA000000 - FA7FFFFF: eos.rom1_mirror
FA800000 - FAFFFFFF: eos.rom1_mirror
FB000000 - FB7FFFFF: eos.rom1_mirror
FB800000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FC7FFFFF: eos.rom1_mirror
FC800000 - FCFFFFFF: eos.rom1_mirror
FD000000 - FD7FFFFF: eos.rom1_mirror
FD800000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FE7FFFFF: eos.rom1_mirror
FE800000 - FEFFFFFF: eos.rom1_mirror
FF000000 - FF7FFFFF: eos.rom1_mirror
FF800000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.iomem
[EOS] loading './1000D/ROM1.BIN' (expected size 0x00800000, got 0x00400000) to 0xF8000000-0xF83FFFFF
[MPU] warning: non-empty spell #14 (PROP_CARD2_STATUS) has duplicate(s): #51
[MPU] warning: non-empty spell #34 (PROP_TFT_STATUS) has duplicate(s): #33 #43 #44
[MPU] warning: non-empty spell #42 (PROP_TFT_STATUS) has duplicate(s): #24 #29 #32 #74
[MPU] Available keys:
- Arrow keys : Navigation
- PgUp, PgDn : Sub dial (rear scrollwheel)
- [ and ] : Main dial (top scrollwheel)
- SPACE : SET (press only)
- DELETE : guess (press only)
- M : MENU (press only)
- P : PLAY (press only)
- I : INFO/DISP (press only)
- J : JUMP (press only)
- D : Direct Print
- W : Pic.Style (press only)
- Z/X : Zoom in/out
- Shift : Half-shutter
- 0/9 : Mode dial (press only)
- B : Open battery door
- C : Open card door
- F10 : Power down switch
- F1 : show this help
Setting BOOTDISK flag to FFFFFFFF
It looks like this is the problem:
[EOS] loading './1000D/ROM1.BIN' (expected size 0x00800000, got 0x00400000) to 0xF8000000-0xF83FFFFF
I did split the ROM.BIN dump in two equals ROM0.BIN and ROM1.BIN as mentioned in the EOS M2 thread.
8388608 ROMDUMP.BIN
4194304 ROM0.BIN
4194304 ROM1.BIN
Does anyone knows how to fix this?
Try loading it as ROM1, without splitting.
When following instructions from elsewhere, consider the context. The dumper that saves a file named (NULL) includes both ROMs in the same file (so it has to be split). The 1000D dumper runs:
int handle = FIO_CreateFile("B:/ROMDUMP.BIN");
FIO_WriteFile(handle, (void*)0xFF800000, 8*1024*1024);
FIO_CloseFile(handle);
Compare the above with the memory map (from QEMU log) and expected size.
Thanks a lot.
This does the trick:
QuoteTry loading it as ROM1, without splitting.
Btw, if anyone found an old ROM dump of the 1000D Firmware 1.0.5 on the internet and want to test in QEMU, renamed it to ROM1.BIN as mentioned above.
It was created the same way a1ex explained.
Both firmwares 1.0.5 and 1.0.7 are running in QEMU.
PB_Palette - the one maybe I need?
bmp_vram_real() - in bmp.c same as above
bmp_vram_info - should not be necessary as isn't asked during compilation if I remember correctly
sd_device - probably minor priority
How to find ram address for those?
I made a quick test defining CONFIG_40D (to solve some minor problems following difference in code for the others cameras running vxworks) and got a compilation without errors but no signs of ML getting loaded in qemu as it doesn't replace firmware version number and it doesn't draw ML Menu.
So I expect to find those pieces to be able to print text and draw ML menu.
Also tried to match gui_task_list from 40D using ./run_canon_fw.sh 40D,firmware="boot=0" -d ram and managed to found which subroutine return the value found into stubs.S, done the same with 1000D and also found what to appears the same code in rom's dump but as the function's address is called more than one times and return different values each time, i checked for the same value for 1000D and it shows up in console but not use if is correct to use it...
Hello im new go this stuff but i was hoping to achieve the build for 1000d or firmwares i beef messing around with it and. Manged to get. 1.0.6 firmware onto the camera. And i usded a 6d. Build. One that i could only get to do. Was magic lantern. Rescue i took images of it. But i have no clue what it does ir anything. Could anyone give me a hand on where. I obtain the factory firmware or a build that works got the eos xs 1000d