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

Any developers interested in working on CHDK firmware for DSLRs ?

  • 202 Replies
  • 149612 Views
*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #110 on: 25 / April / 2008, 11:56:45 »
Advertisements
Quote from: owerlord on 25 / April / 2008, 11:08:13
fread(&c, sizeof(char), 1, in);        /* stored in file. */
                sum += c;

it should be:

n= fread(&c, sizeof(char), 1, in);        /* stored in file. */
if (n) sum += c;

otherwise the last byte is doubled.
now it end's with -1 :-)

Checksum now works here on 40D-1.0.5 and 40D-1.0.8 FW also.
-1 from each file. :-)
Logged
*

Offline owerlord

  • ***
  • 115
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #111 on: 25 / April / 2008, 12:20:24 »
So we're on the go !

task for now: find the addresses of all the functions and things :-)
Logged
*

Offline mx3

  • ****
  • 372
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #112 on: 25 / April / 2008, 19:00:49 »
some tools

decrypt_fw1 - for 20D / 350D
decrypt_fw2 - for 5D / 30D / 400D

dissect_fw2 - for 30D / 400D
dissect_fw2_d5 - for 5D
Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #113 on: 26 / April / 2008, 13:45:03 »
Because owerlord's work on the EOS 400D is spread across several posts, I thought I'd condense it into a single post to make it easier to follow.

Firmware file structure for the 400D (all detective work was done by owerlord.
Secretary work done by Artemia Salina):

File structure is [loader]+[firmware pack].
4B: model ID (36 02 00 80 for 400D)
12B: 0?
16B: firmware number (string)
4B: checksum - see below
4B: file offset of the loader
4B: file offset where is the firmware pack (for 400d: 127C90)
4B: 0?
all rest until the firmware pack is the loader code (starting point for the code.
probably 0x800000)

Checksum algorithm is:
Sum of all bytes in the encrypted .fir file, excluding the checksum above,
are summed with the checksum. -1 (0xFFFFFFFF) means the file is good.

The firmware pack (starting at file offset 0x127C90) is structured as follows:
4B are the checksum (same method) of the data pack.
4B number of parts in the pack ("files" in the pack)
4B offset of the "file" table. (=24)
4B header size (offset of the first "file")
4B size of the "file" table (number of "files" * 40)
4B summary size of the "files" (size of the pack minus offset of the first)
Next is a table of segments of the pack, with records in form:
4B: don't know yet - mostly #4 propably a flag
4B: offset of the segment (in reference to the begining of the pack)
4B: lenght of the segment
28B: name of the segment (string).
Logged
*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #114 on: 26 / April / 2008, 14:06:23 »
I'm working on a 40D (not 400D) myself.
The 40D's firmware file structure seems to be somewhat different than the 400D's.
The version 1.0.5 firmware for the 40D does not seem to have multiple firmware "files" within it, so the file offset to the firmware pack (found at absolute file location 0x29) contains a pointer to the entry point of some code (0x120).

ROM:FF810120                 MOV     R0, #2
ROM:FF810124                 B          loc_FF810174
This branch jumps over a text string to more code.

The checksum algorithm is the same as the 400D's method, and the stored checksum is in the same location (0x20).
Logged
*

Offline owerlord

  • ***
  • 115
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #115 on: 26 / April / 2008, 18:40:19 »
that's my packer:

It searches for files "loader", "firm" (firmware) and so. And pack it all.
You'll find everything in the code. It can be easily modifed.

Code: [Select]
#include <stdio.h>
#include <unistd.h>

#define CK(X) -1-(X)

typedef unsigned long t_dword;
typedef unsigned char t_byte;

typedef struct
{ t_dword modelID;
  t_byte unknown[12];
  char version[16];
  t_dword cksum;
  t_dword firstOffset;
  t_dword secondOffset;
  t_dword unknown_0;
} s_main_head;

typedef struct
{ t_dword cksum;
  t_dword rec_num;
  t_dword tableOffset;
  t_dword packOffset;
  t_dword tableLenght;
  t_dword packLenght;
} s_pack_head;

typedef struct
{ t_dword flags;
  t_dword Offset;
  t_dword lenght;
  char name[28];
} s_file_rec;

void f_clear(void *p, t_dword s)
{ t_byte *cp;  cp=p;
  while (s--) *(cp++)=0;
}
t_dword f_cksum(void *p, t_dword s)
{ t_byte *cp; t_dword sum=0; cp=p;
  while (s--) sum += *(cp++);
  return sum;
}

t_dword f_filecpy(s_file_rec *rec, FILE* out, FILE* in)
{ t_byte buf[256];
  t_dword red,sum=0,len=0;
  while (! feof(in))
  { red = fread(buf, sizeof(t_byte), 256, in);
    fwrite(buf, sizeof(t_byte), red, out);
    sum += f_cksum(buf, red);
    len += red;
//    printf("red:%d ", red);
  } 
  rec->lenght=len;
  return sum;
}

int f_add(t_dword* cksum, s_file_rec *rec, FILE* out, t_dword flags, char* infile, char* name)
{ FILE* in;
  printf("Adding %s->%s\n",infile, name);
  if ((in = fopen(infile, "rb")) == NULL)
  { printf("Can't open file name %s\n", infile);
        return 0;
  }
  *cksum += f_filecpy(rec, out, in);
  fclose(in);
  strcpy(rec->name, name);
  return rec->lenght;
}

main(int argc, char *argv[])
{
        FILE* out;
        FILE* pack;
        s_main_head mhead;
        s_pack_head phead;
        s_file_rec rec[20];
        s_file_rec frec;
        t_dword len, cksum=0, i=0,j;
        f_clear(&mhead,sizeof(s_main_head));
        f_clear(&phead,sizeof(s_pack_head));
        f_clear(rec,sizeof(s_file_rec)*20);
       
       
        if (argc < 2)
                printf("eospack outfile [firm version]");
        if (argc > 2)
                strcpy(mhead.version, argv[2]);
        else
                strcpy(mhead.version, "eos test firm1");
               
        if ((out = fopen(argv[1], "wb")) == NULL) {
                printf("Cant't open file name %s\n", argv[1]);
                exit(-1);
        }
       
        if ((pack = fopen("tmp.pack", "wb+")) == NULL) {
                printf("Cant't open file name tmp.pack\n");
                exit(-1);
        }

        printf("File to write: %s\n", argv[1]);
        printf("Writing pack\n");
       
        cksum = 0;
        if (f_add(&cksum, &(rec[i]), pack, 8, "firm", "MAIN_FIRMWARE")) i++;
        if (f_add(&cksum, &(rec[i]), pack, 8, "ver", "FirmwareVersion")) i++;
        fseek(pack, 0, SEEK_SET);
       
        phead.tableOffset = sizeof(s_pack_head);
        phead.rec_num = i;
        phead.tableLenght = i*sizeof(s_file_rec);
        phead.packOffset = phead.tableLenght+phead.tableOffset;
        for (j=0; j<i; j++)
        {
          rec[j].Offset = phead.packLenght + phead.packOffset;
          phead.packLenght += rec[j].lenght;
          cksum += f_cksum(&(rec[j]), sizeof(s_file_rec));
        }
        phead.cksum = CK(cksum + f_cksum(&phead,sizeof(s_pack_head)));
       
        printf("Writing main\n");
       
        cksum=0;
        len=0;

        mhead.modelID= 0x80000236;
        mhead.cksum= 0x00000000;
        mhead.firstOffset = sizeof(s_main_head);
       
        fwrite(&mhead, sizeof(s_main_head), 1, out);
       
        len =f_add(&cksum, &frec, out, 0, "loader", "LOADER");
        mhead.secondOffset = mhead.firstOffset + len;
       
        fwrite (&phead, sizeof(s_pack_head), 1, out);
        fwrite (rec, sizeof(s_file_rec), phead.rec_num, out);
        cksum += f_filecpy(&frec, out, pack);       
       
        mhead.cksum = CK(cksum +
          f_cksum(&mhead, sizeof(s_main_head)) +
          f_cksum(&phead, sizeof(s_pack_head)) +
          f_cksum(rec, sizeof(s_file_rec)*phead.rec_num));
       
        fseek(out, 0, SEEK_SET);
        fwrite(&mhead, sizeof(s_main_head), 1, out);
       
        fclose(pack);       
        fclose(out);

        exit(0);
}
Quote from: ASalina on 26 / April / 2008, 14:06:23
The version 1.0.5 firmware for the 40D does not seem to have multiple firmware "files" within it, so the file offset to the firmware pack (found at absolute file location 0x29) contains a pointer to the entry point of some code (0x120).

So in the place of 400d data pack there is only a firmware code? Interesting.

I tested a firmware without the attached file pack - and it didn't work, but my tests could be wrong (other thing might have been wrong in the file). If somebody have run a firmware without an attachement - post ! :-)
Logged
*

Offline mx3

  • ****
  • 372
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #116 on: 28 / April / 2008, 14:24:59 »
Quote from: ASalina on 26 / April / 2008, 14:06:23

ROM:FF810120                 MOV     R0, #2
ROM:FF810124                 B          loc_FF810174


RAM:00800120                 MOV     R0, #2
RAM:00800124                 B       loc_800174
RAM:00800124 ; ---------------------------------------------------------------------------

RAM:00800174 loc_800174
.........
RAM:008001E0                 LDR     PC, =loc_8001FC
RAM:008001E0 ; ---------------------------------------------------------------------------
RAM:008001E4 off_8001E4      DCD loc_8001FC
RAM:008001FC ; ---------------------------------------------------------------------------
RAM:008001FC loc_8001FC
RAM:008001FC                 MOV     R12, SP

Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
*

Offline ryanpg

  • *
  • 12
Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #117 on: 28 / April / 2008, 21:28:45 »
I have both the S3 IS and a 400D. I'm new to DSLRs and fairly new to CHDK. I'm fairly excited about the possibility of CHDK on my 400D. Is lifting the mirror and closing the aperture to display information from the CMOS a possibility? The first set of features listed below seem quite possible based on my understanding of the limitations of the DSLR hardware. The second set is predicated on the idea that the mirror can be selectively raised and the CMOS read from.

-Scripting
-Custom Auto-ISO or ISO "warning"
-Better exposure bracketing
-Intervalometer
-Disable all/any noise reduction
-400D underexposure/metering correction
-Save dark frame separately

-Live view
-Live histogram
-Live grid
-Zebra
-Motion detection

Is my understanding of these potential features correct? What other possibilities might come with a DSLR CHDK port? Oh, and thanks to all those involved.
« Last Edit: 28 / April / 2008, 21:52:09 by ryanpg »
Logged
*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #118 on: 29 / April / 2008, 12:36:47 »
Quote from: mx3 on 28 / April / 2008, 14:24:59
Quote from: ASalina on 26 / April / 2008, 14:06:23

ROM:FF810120                 MOV     R0, #2
ROM:FF810124                 B          loc_FF810174


RAM:00800120                 MOV     R0, #2
RAM:00800124                 B       loc_800174
RAM:00800124 ; ---------------------------------------------------------------------------

RAM:00800174 loc_800174
.........
RAM:008001E0                 LDR     PC, =loc_8001FC
RAM:008001E0 ; ---------------------------------------------------------------------------
RAM:008001E4 off_8001E4      DCD loc_8001FC
RAM:008001FC ; ---------------------------------------------------------------------------
RAM:008001FC loc_8001FC
RAM:008001FC                 MOV     R12, SP



Yes, I read your earlier posts and was surprised at the similarity between the two code sections (I'm still not clear if your code was from the 350D or the 400D...)

Unfortunately it seems that the 40D will need its firmware patched and flashed into ROM in order to run CHDK, like you were talking about earlier. Although I trust your code and don't think it would damage the camera itself, if the camera were to die for any reason with modified firmware installed it would be impossible to re-install the original firmware before sending the camera to Canon for repair. If the modified FW was discovered the warranty would be void. (Actually legally just changing the FW would void the warranty). That's too much of a risk for me to try it. Maybe after the warranty runs out. :-)

PS: Out of general curiosity, I guess

LDR PC, =Location

is the ARM's equivalent of a JMP instruction? i.e. it doesn't touch the link register like "B Location" does?
Logged
*

ASalina

Re: Any developers interested in working on CHDK firmware for DSLRs ?
« Reply #119 on: 29 / April / 2008, 14:02:41 »
Quote from: ryanpg on 28 / April / 2008, 21:28:45
What other possibilities might come with a DSLR CHDK port?

One other interesting possibility is focus and aperture control in the software intervolometer. When making time lapse movies it would be nice to be able to control the aperture or focus while filming, especially if you're using a motorized articulated camera mount to pan and dolly the camera. It's too bad that lens length can't be changed this way as well (although that could be done with another stepper motor attached to the zoom ring).
Logged
Pages: 1 ... 7 8 9 10 11 [12] 13 14 15 16 17 ... 21   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal