Author Topic: Canon 1000d / Rebel XS (Read 89894 times)

SysCall · « **Reply #50 on:** December 05, 2016, 08:12:06 PM »

@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://www.magiclantern.fm/forum/index.php?topic=2054.0

We have to clarify first, which one makes sense and worth the effort.

a1ex · « **Reply #51 on:** December 05, 2016, 08:20:21 PM »

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 (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.

Ant123 · « **Reply #52 on:** December 05, 2016, 08:20:34 PM »

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"

Levas · « **Reply #53 on:** December 05, 2016, 08:51:13 PM »

Great to see Alex arrive in this post

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 ?

Levas · « **Reply #54 on:** December 05, 2016, 08:56:26 PM »

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

Ant123 · « **Reply #55 on:** December 05, 2016, 09:06:58 PM »

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.

SysCall · « **Reply #56 on:** December 05, 2016, 09:22:08 PM »

@ a1ex and Ant123

Thank you very much.

I will look into it.

shmadul · « **Reply #57 on:** December 05, 2016, 09:34:40 PM »

@Levas, Changed the Title as you suggested

shmadul · « **Reply #58 on:** December 05, 2016, 09:58:52 PM »

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 .....

SysCall · « **Reply #59 on:** December 06, 2016, 06:55:50 PM »

@ 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?

Ant123 · « **Reply #60 on:** December 06, 2016, 07:24:04 PM »

on 450D this code works well.

SysCall · « **Reply #61 on:** December 06, 2016, 07:36:44 PM »

@ 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

Ant123 · « **Reply #62 on:** December 06, 2016, 07:49:44 PM »

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 works?

SysCall · « **Reply #63 on:** December 06, 2016, 07:51:13 PM »

Ok, fixed it myself.

In Trammell_Hudson_ML/src/disp_direct.c

Replace this

Code: [Select]

static uint8_t *disp_framebuf = (uint8_t *)0x04000000;

with this

Code: [Select]

static uint8_t *disp_framebuf = (uint8_t *)0x00400000;

Ant123 · « **Reply #64 on:** December 06, 2016, 07:58:34 PM »

Do you get picture like this using autoexec.bin, not *.FIR?

SysCall · « **Reply #65 on:** December 06, 2016, 08:08:38 PM »

@ 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

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.

Ant123 · « **Reply #66 on:** December 06, 2016, 08:21:33 PM »

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 from the begining to the end again.

If BOOTFLAG is set you will see "BOOT=-1" ( -1 == 0xFFFFFFFF)

SysCall · « **Reply #67 on:** December 06, 2016, 08:24:33 PM »

Video is online, same link as previous post.

Btw, why is your flag set?

You got it already running?

Quote

If BOOTFLAG is set you will see "BOOT=-1" ( -1 == 0xFFFFFFFF)

Guess my boot flag is set then, look at my link.

Ant123 · « **Reply #68 on:** December 06, 2016, 08:34:56 PM »

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. 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.

SysCall · « **Reply #69 on:** December 06, 2016, 08:46:53 PM »

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.

Code: [Select]

	// EnableBootDisk()  
	Funktion f = 0xFFD21248;
	 f();

After that, I made the SD card bootable by executing in terminal:

Code: [Select]

sudo ./make_bootable.sh

After executing .fir the first time, I don't need it anymore and the camera loads the AUTOEXEC.BIN automatically.

Ant123 · « **Reply #70 on:** December 06, 2016, 08:56:47 PM »

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 .

SysCall · « **Reply #71 on:** December 06, 2016, 08:59:36 PM »

Sorry for the confusion, for me the latest is the last release from coutts is:

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

Ant123 · « **Reply #72 on:** December 06, 2016, 09:02:28 PM »

But this is not ML. Are you porting ML or something else?

Levas · « **Reply #73 on:** December 06, 2016, 09:19:13 PM »

Quote

Now 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

SysCall · « **Reply #74 on:** December 06, 2016, 09:22:20 PM »

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.

News:

Author Topic: Canon 1000d / Rebel XS (Read 89894 times)