code you HAVE RUN on your dslr

[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 ;-)

[ASalina]

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

I just tried this on the 40D. No success (with udumper as the AUTOEXEC.BIN file).
I will say, though, that a card formatted by the camera does have "EOS_DIGITAL" at 0x2B, and "EOS_DEVELOP" is the same number of characters, so the new label does fit neatly in place of the old one.

Does the 400D start up in "playback" mode? The 40D does not. I don't know if that has any relevance.

[DataGhost]

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]

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.

[ASalina]

I don't know if this will help, but I've managed to accidentally completely reboot the 40D with buggy programs. In particular, the led scanner I started with caused this to happen. I threw some wild data somewhere and it caused a complete reboot.

I can try to recreate it later if it'll help.

[owerlord]

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]

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.

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

[ASalina]

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.

I wasn't suggesting it as any kind of approach, of course. I was suggesting that it was possibly a clue to the reboot process.
Is there a memory location that controls power to the camera?
I don't know, but the camera seemed to cleanly reboot while in the "upgrade state."

Anyway, I'm trying to process 150M bytes of blinked out data with adc. Lots of SYNC errors. So I'm rather too busy to be defending myself here, right now.