code you HAVE RUN on your dslr

owerlord

:\ I totaly got stuck. Mayby anybody can help. There are three things I traced and end up in a dead end:

1. When the data is copied from rom to ram.

the 0xC0A100xx are initialized with data-in-rom-adr, data-in-ram-adr, lenght-of-data - when it is copied ??

2. What code is runned when the battery compartment is closed?

I searched the booloader and firmware and haven't see anything.

3. What is done before firmware-loader is started?

Do we know anything ?

mx3

owerlord
:\ I totaly got stuck. Mayby anybody can help. There are three things I traced and end up in a dead end:

1. When the data is copied from rom to ram.

the 0xC0A100xx are initialized with data-in-rom-adr, data-in-ram-adr, lenght-of-data - when it is copied ??

2. What code is runned when the battery compartment is closed?

I searched the booloader and firmware and haven't see anything.

3. What is done before firmware-loader is started?

Do we know anything ?

0xC0XXXXXX - it is devices IO address space.
be carefull with it
what are you going to do with it?

I had impression that jeff666 and dataghost have given you details about how powershots are started
theirs comments were unhelpful?

you can try to analize powershot's firmware and boot procedure of CHDK and find similarities

owerlord

mx3
0xC0XXXXXX - it is devices IO address space.
be carefull with it
what are you going to do with it?

The firmware at romStart puts an adres of data saved in ROM, place do copy it in RAM and its lenght to the 0xC0A100xx. I'm not planing to do anything with it - I just want to know where it is used. Propably the data is copied when the battery are closed or something - but I cannot find it.

mx3
I had impression that jeff666 and dataghost have given you details about how powershots are started
theirs comments were unhelpful?
you can try to analize powershot's firmware and boot procedure of CHDK and find similarities

I think DSLR are totaly diffrent here. For instance - they're loading CF cards even when they have the power swich to Off. In DSLR one thing is what happens at battery closing, and other is at switch on.

owerlord

I dumped the 0x0-... section. And:
When the loader is started:
0x0 interupts are set to the values from 0xFFFF0000 - so bootloader propably loads the program.
0x1900++ section is totaly empty. It is cleared before run.

owerlord

jump to 0xFFFF0000: Loading ... Loading ... Loading ... Loading ...

Seklth

~~try start autoexec.bin with this jump =)~~
no, it is incorrect)) it is repeat start bootloader and loading autoexec.bin..

DataGhost

I did some backtracking and reading through the bootloader code... I think I figured out how to load AUTOEXEC.BIN. Only thing is, I don't know where it's loaded yet and I don't know if it needs a special header (but I think not). Anyway, it seems that, besides 'BOOTDISK', the CF card needs to be named EOS_DEVELOP. Judging by the offsets of the two tests, it can boot from FAT12/16 AND FAT32. So.. my guess is
FAT12/16:
Volume label (0x2B) EOS_DEVELOP
0x40 BOOTDISK

FAT32:
Volume label (0x47) EOS_DEVELOP
0x5C BOOTDISK

it doesn't seem to need anything besides that and AUTOEXEC.BIN. Could you please see if that has any effect? In the meantime, I'll continue looking for the loading address. You may also have to set some 0xC0...... addresses but I'll get to that if it doesn't work.
Ok... I *THINK* the code will then be executed from 0x800000, but I also see 0x10800000, though with a condition. I guess we can safely assume the first one.

owerlord

I hope there is somebody else with 400D, becose I'm now aiming at full camera restart without pulling the battery out. The bootloader is quite simple, and the adress is 0x80000. The procedure loading .bin and .fir are the same - in bin it just don't do the encryption. And the procedure enabling the bootdisk run is in the firmware (eventproc_EnableBootDisk 😉

DataGhost

owerlord
I hope there is somebody else with 400D, becose I'm now aiming at full camera restart without pulling the battery out. The bootloader is quite simple, and the adress is 0x80000. The procedure loading .bin and .fir are the same - in bin it just don't do the encryption. And the procedure enabling the bootdisk run is in the firmware (eventproc_EnableBootDisk 😉

So did you try booting this way and/or calling the 'enable' function and then seeing if it will execute AUTOEXEC.BIN? It does seem to require that one address in the MMIO region is 0 and another is 1, so maybe it needs an external input for it to work... but I don't really know what it does.

owerlord

I have a impression that I didn't post my findings long:

The bootloader have a program attached (FFFF2414-end). It is copied to 0x100000 and runned with an code. The code means an action, for example:
5) run the .fir
6) run the autostart.bat

the FFFF0000 code know that to do, from the 0xF8000000 (before-firmware) section. apx. first 12 bytes are a "command" for the bootloader what to do. Other used part is the 0xF8002000 - it's a part to save Camera Adjustment data and Sweep times and so.

NEW: 0x8F000000 looks like this:
4B unknown: 0 when loader starts (wierd !)
4B Boot flag
4B ram execute flag
4B UpDate flag

0 = set to yes. -1 = set to no.

The bootloader-attached program have an menu to change them. Wierd thing is:
1. there is no code in bootloader-attached program to change the unknown
2. 0xFFFF0000 interupt program don't read the update flag, but it reads the unknown.
3. running .fir (option 5) changes update flag to "no" (but the interrupt didn't read it !)

owerlord

runned the romStart with the 0xFFFF0000 init code. As earlyer: couple of seconds and menu reapare with 2 buttons working.

NEW: I copied the data section and runned the romStart. nearly the same effect, only it restarted at normal screen not menu (but the buttons don't work)

owerlord

New thing:

I found out that the message "[MAIN] Init Start" isn't writen. That means that Startup task isn't runned whole ! We know that "InitializeIntercom" is writen - but what then ? Where the Startup breaks ?

ryanpg

Hi owerlord, as a CHDK fan and 400D owner, I've been watching your work with excitement. If you have a minute, could you summarize where you are at; what you've accomplished so far and what obstacles you are working against currently? I'm thinking other interested owners and perhaps potential developers might benefit from a quick point by point rundown (the forum gets cluttered and confusing IMHO). If you're feeling too busy please disregard my request - it's all just so much fun to watch you work! 😛

Also, just want to say "thanks" for your effort and express my genuine amazement at how bright you and all the CHDK "hackers" are. I would probably given up by now - but cheers to you for putting obsessiveness to good use. I'm confident this port will happen!

😁

owerlord

Summerize:

The orginal .fir file is a program with "attachments". It loads the attachments in to the rom and eprom.
It is coded, and the decrytpion is known (I found it on the forum). We can easyly write code, encrypt it and run it on the camera. Problem is: what to run ? 😀
We found the addresses of many functions in the firmware - nearly know how it's working. Problem is: we really don't know, becose:When the firmware entry point is run - it don't restart properly.
Without knowing why, we're just guessing. The camera is restarting fully when you pull out the battery - so we know somewhere is a code that restart's it. (the orginal .fir file after loading the firmware says "Pull out the battery" - so we won't find the code there :\)
I wrote a blinking driver so I can open it as a file and redirect stdout on it. I posted here the full log. If I'll menage to restart the camera fully I'll be able to log any acticity, and say what part of code do what. I'll be easyer then.
I'm now rewriting the Startup code in C so I can log what is working and what's not.

jeff666

owerlord
Problem is: we really don't know, becose:When the firmware entry point is run - it don't restart properly.

I discovered the same on my A720.

Reason: when our code is run, we have a (mostely) running OS which causes

1. garbage in memory which isn't initialized during startup
or
2. Multi-tasking-related CPU-settings are still active and code (other tasks) is run although it isn't valid anymore.

I find the first reason not very likely and think the second causes the trouble.

Since the restart function looks pretty much the same on every digic2- and digic3-cam, you might have success by taking exactly the same code I posted on the first page of this thread, modify the target address (void* dst_void, => "MOV PC, %0") to the official firmware start, run this code on your cam and see if it restarts then.

Cheers.

owerlord

jeff666
1. garbage in memory which isn't initialized during startup
or
2. Multi-tasking-related CPU-settings are still active and code (other tasks) is run although it isn't valid anymore.

I tired all initialize code I could think of. The bootloader clears all pending proceses, and clears memory - I checked it by dumping the ram - all is cleared. I even copied the data section from the firmware - all with the same effect - restart, after waiting the screen get up and the menu apears - and nothing works.

As I wrote earler : the Startup Task code hangs in some part - and it don't reach the main initialization code.

ASalina: You tried to jump to FF810000 ? mayby the 40D don't have this problem. I'll make your work easyer.

jeff666

[unknown]
I threw some wild data somewhere and it caused a complete reboot.

This is not what we need. We need a "controlled reboot" which
1. resets the hardware
2. lets us decide what code to execute afterwards.

Your "approach" probably didn't meet the second requirement.

owerlord
I tired all initialize code I could think of.

You don't address my suggestion. Did you run the code I posted (and that works in every CHDK-supported cam)?

Cheers.

owerlord

"You don't address my suggestion. Did you run the code I posted (and that works in every CHDK-supported cam)?"

Maybe you didn't notice our tests, but:

!!! THE CODE IS VERY DENGEROUS !!!

owerlord

Don't bother to defend yourself. Your observations are usefull - they suggest it's possible in the 40D. I didn't got a full restart even once on the 400D 😀

apropos, your analysing of data - if it fail - I can propose my method. more tests?, but It worked here, hope it'll work on 40D.

_MAG_

ASalina try isolate photodiode from external light. Or use non-internal sound card...
You use photodiode from mouse? They sense only IR light (need to filter i sink).

« Previous Page Next Page »