Any developers interested in working on CHDK firmware for DSLRs ? - page 9 - DSLR Hack development - CHDK Forum
« previous next »
Pages: 1 ... 4 5 6 7 8 [9] 10 11 12 13 14 ... 21   Go Down

Any developers interested in working on CHDK firmware for DSLRs ?

  • 202 Replies
  • 126260 Views
*

Offline icz

  • *
  • 12
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #80 on: 29 / February / 2008, 10:31:49 »
Advertisements
this thread is really interesting, i have a 350d so i'd like to see any chance to make it more powerfull!!
Logged
*

Offline kwf

  • **
  • 72
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #81 on: 14 / March / 2008, 12:23:56 »
Nobody working on this anymore?
Logged
*

Offline nns

  • *
  • 4
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #82 on: 18 / March / 2008, 12:58:38 »
I'm still working on the 20D firmware it in my off time.  I've been through most of the code with IDA, and found most entry points, and have a good working knowledge of how the code functions now.  I'm still at a loss to identify the checksum in the firmware that is used when it is loaded.  Once I get a little more down time, I'm going to try a few more things.  Sadly, the checksum doesn't seem to be a neatly stored in a header as in the 40D and other cameras.

I've also run into some motorola S-records that are at the end of the firmware file that I'm curious about.  There seems to be two discrete segments, on labelled k175_eeprom, and the other labelled patch_12.S19m.  I do know that they're covered by the file checksum too...
Logged
*

Offline kwf

  • **
  • 72
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #83 on: 18 / March / 2008, 13:25:07 »
Hmmm interesting ... haven't looked so far yet. So there is probably a motorola uC next to the digic II, maybe for lens communication, flash communication, shutter control, or auto focus. Interesting for later research, but maybe not necessary for the beginning :)

Maybe i have a look into 350D code to find something similar, but maybe not the 20D flash file seems to be the double (!) size of the 350D flash. I need to find some time to understand the basic firmware upgrade procedure and how CHDK usually loads, no idea so far.
Logged
*

Offline nns

  • *
  • 4
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #84 on: 19 / March / 2008, 12:19:50 »
The recent 20D firmware files are large because they contain 3 segments of code.  The first is the firmware upgrader, and the second two are very similar versions of the firmware, but not identical.  I did a quick check, and the 20Da (for astrophotography) uses a firmware file that is bytewise identical to the 20D, so my guess is that the two firmware images in the file are for the two models -- the upgrader utility likely decides on which firmware to flash into the camera.  This is just a guess right now, as I haven't put a lot of time into looking at the differences. 

I've also noticed that the direct-print and wireless file transfer support seem to be the bulk of the code space (which is a waste for me, as I don't use either)....
Logged
*

Offline kwf

  • **
  • 72
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #85 on: 19 / March / 2008, 12:57:27 »
Thats interesting, i wonder why they have thrown 20D and 20Da firmware in one file. Maybe the cameras are not so different (apart from the IR response) after all? Use a software hack to enable liveview? :P

The uninteresting direct print code is also available for the 350D ... finding the differences in huge code sections is somehow boring, still waiting for a automated "binary diff disassembler" which just tells me which functions are different and which aren't :)
Logged
*

Offline kwf

  • **
  • 72
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #86 on: 24 / March / 2008, 18:28:50 »
As i understand the current theory is that the code starting at 0xff810000 is the main firmware, reads the FIR-File and transfers the first part of the firmware to 0x800000 (firmware loader). Then the control should be transfered to the firmware loader at 0x800000 and this firmware takes care of the flashing.
This seems to be supported by the various experiments done by some here.

Now i had a little look into the code. But i could not understand how this happens. I couldn't find a checksum calculation in the second part (would be nice to calculate the checksum before transferring control to the loaded code, or?), only in the first part. I didn't even manage to find the point where the FIR file is actually opened and read. The file operation in the 350D seems to be handled by an DrvManager and a DcfManager (both seem to be written in C++), this makes the code a bit more complicated to read. Rather than calling a function directly it's address seems to be written into some variable and then this is accessed from somewhere else, preferably around some more corners. Only thing i could find is some checking for the FIR file in the main firmware, but not the actual loading, checksum calculation, or a jump to the loader part.

I looked for some hours now, anyone had more success?

« Last Edit: 24 / March / 2008, 18:37:35 by kwf »
Logged
*

Offline holeepassion

  • *
  • 39
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #87 on: 29 / March / 2008, 02:35:45 »
Since 450D is using SD, is it easier to getting a firmware up for it ?

It would be awesome ....
Logged
*

Offline nns

  • *
  • 4
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #88 on: 31 / March / 2008, 15:52:00 »
holeepassion:  No, SD cards will not make it any easier.  I believe the 450D is also DryOS, so it's not going to be the same as 300D, 350D, 20D or 30D...

kwf:  I found the same routines.  The checksum calculation function is pretty blatant in the bootloader portion of the code.  In the application portion, there is a well defined calling structure to detect an FIR file's presence on the CF card, but I could not find a simple checksum calculation routine. 

I spent a while trying to figure out exactly how the memory mapped between the code, and the actual memory in the processor (I know it's loaded at 0x1900, but I'm not sure what location in the firmware file gets mapped to 0x1900 -- there are some reference to 'start of data' but I haven't been able to map, say, a menu item text string to where it is actually used in the code), so it's hard to identify what functions are called when (as you mentioned) a C++ member is executed ( -- it may not even be C++, they may have just used function pointer tables all over the place).

There are a lot of places in the data section that have subroutine pointers, but it's hard to tell where they are used.  All this isn't really important to getting some hacked code running, as we can use the same "hook" method used by chdk.  It is, however, making it a pain to find how the checksum is calculated. 

I thought at one point that the same function that decrypted the FIR file might also calculate a checksum, so I tried to identify that function without much luck.  I also tried a pattern search on a few variants of the XOR decoding table used in decrypt20D.exe, but didn't come up with anything.

I really wish I knew where all those logging/debugging messages were being printed too (probably a serial port internal to the camera, or maybe they are actived through the USB port somehow for use at Canon).

Things I *do* know about the checksum: 
- it is byte-oriented (I can decrement 1 byte, and increment the next byte, and the file passes)
- the same checksum covers the bootloader portion and the firmware portion of the file (I can decrement 1 byte in the firmware portion, and increment a byte in the bootloader portion and it passes)
- the 'S-records' at the end are covered by the checksum also (so it looks like a very large portion of the file, if not the whole thing, is covered).

I haven't figured out if the accumulated sum is stored as 8, 16, 32, etc bits....I did try a quick brute-force method of summing every single byte of the file (minus four) and comparing it to the 32-bit value of the four un-summed bytes (I tried leaving out every possible 32-bit value (eg, 8MB/4 times)), and compared the calculated checksum against the un-summed word in both big and little endian order, but didn't find a match......so either the checksum isn't summed into a 32-bit number, or the whol file is not covered. 

I'm starting to really get annoyed at this checksum....
Logged
*

Offline spmp

  • *
  • 1
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #89 on: 09 / April / 2008, 20:33:34 »
THanks to all who have done the magic to date. It looks like something will happen someday!'
 I am a 20D user who would LOVE to have auto ISO and the ability to do AEB of more than +-2stops and more than 3 shots, just to chime in here.
  More importantly the ability to setup custom funstions of scripts, and make use of all those modes that I never use, (anything past green square 8~)

This is just to chime in and say Good on ya! If there is something to be tested thats not going to break my precious then I would gladly do some beta testing.

As others have pointed out, once the floodgates open on the number of features, USEFUL features, that could be added to these cameras, that have been left out as part of the hangover from the philosophy of film cameras and the gross misunderstanding as to the desires of DSLR users, we (you) could maybee bring DSLR's forward a few generations and actually mature them as DIGITAL cameras, not just fancy film cameras with some kind of sensor thing in them.

I love merging images together to make new and exciting things, infinite depth of field (HDF), HDR, timelapse the list goes on...

  All power to you, and if I can help please say how. Ignorant non-coder, but can follow previouse syntax etc... so not totally useless.
Logged
Pages: 1 ... 4 5 6 7 8 [9] 10 11 12 13 14 ... 21   Go Up
« previous next »
 

Related Topics