DIGIC5

Ok. First look at this message link

So DIGIC5 is definitely production of Texas Instruments.

I checked their site. And now I'm not so sure, that DIGIC5 is in fact OMAP processor.
Check this link: http://www.ti.com/lsds/ti/dsp/platform/device.page
There is a selection tool at the bottom of the page. There are several SoCs, that fulfill "Encode + 1080i/p + 1080p" requirement. All of them use either C64X or C674x DSP.

From what I know about DSP, the software implementation of codecs for DSP are highly optimized. The optimization process is kinda hard, can take really long time(even half of year) and it is very costly in terms of money. So there is 0% possibility, that they created completely new DSP with optimized Video Encode library.

That's why DIGIC5 should contain C64X or C674x DSP.

I met several times the messages about DSP at this forum. And I've got an idea, that community already know how to retrieve the software code of DSP. Am I correct at this one?

Canon's DIGIC has a long history. It integrates several functions, many of those exist even in the first DIGIC. They must have kept most of their design, maybe, for efficiency, they licenced additional stuff from TI (like a better DSP/code, power saving technology).

I met several times the messages about DSP at this forum. And I've got an idea, that community already know how to retrieve the software code of DSP. Am I correct at this one?

I don't know about DIGIC 5, but for example, DIGIC II cameras definitely have the DSP code probably unencrypted in the ROM. I've seen code in the firmware that allocates RAM, copies some of this code into RAM and then sets some DIGIC registers to the RAM address.

From what I know about DSP, the software implementation of codecs for DSP are highly optimized. The optimization process is kinda hard, can take really long time(even half of year) and it is very costly in terms of money. So there is 0% possibility, that they created completely new DSP with optimized Video Encode library.

Canon has been incrementally developing Digic since the early 2000s, and according to everything I've seen the image processing part of this is an indigenous development. While they have probably licensed subsystems from others (just as they do with the ARM core) I'm quite certain this isn't something off the shelf from another vendor like TI.

I don't know about DIGIC 5, but for example, DIGIC II cameras definitely have the DSP code probably unencrypted in the ROM. I've seen code in the firmware that allocates RAM, copies some of this code into RAM and then sets some DIGIC registers to the RAM address.

Agreed. On a540 (digic II), for example sub_FFC79AFC seems to load some binary code for some non-ARM architecture.  On d10 (digic IV), sub_FF8EF64C looks quite similar.

An interview with some digic engineers http://www.canon.com/technology/interview/digic4/digic4_p1.html

Some interesting quotes:

So far we've only been talking about hardware circuits. Is software not important for image processing?

Ikeda
    What the DIGIC software handles is command control, with the main focus being on "directing traffic." The software has nothing to do with the actual image processing. If you used software for image processing, it would take too long.

Am I right in saying that Canon has always had a policy of developing its image processors in-house, right from when the first digital cameras started being developed? Given that, today, most other camera makers customize processors provided by specialist LSI chip suppliers, what is Canon's stance regarding in-house development now?

Kawaguchi
    As a developer, the advantages of designing every single part of the LSI chip ourselves are invaluable. If we want to change something, we can change it; there are no restrictions. What's more, by listening to requests from the design teams and feedback from the users regarding each product, we can reflect all of this knowledge in the latest technology that we develop for the next version.

Ah. So no one actually saw DSP code. Well, that changes the situation a bit.

DSP processors have one important characteristic. The manufacturers often write the library right into ROM without possibility to overwrite it. So assumption that there is DSP code somewhere in firmware updater might be false.

Next, according to datasheet document of CX64(link, page 18), that DSP have capability to map external DDR2 memory to isolated address space. This means two things:
1) DSP's ROM data is completely isolated from ARM's address space
2) DSP and ARM can communicate through DDR2 memory.

Also DSP and ARM can communicate through IRQ interrupts. So I'm not sure what type of synchronization they use(IRQ or specific address in DDR2 memory). And since CHDK can retrieve raw sensor data the algorithm might be this like:
1) ARM retrieve raw data
2) ARM prepares buffer for encoded jpeg
3) ARM passes addresses for raw data and jpeg buffer to DSP
4) ARM signals somehow to DSP(either IRQ or "magic memory address")
5) ARM receives signal of the completed operation through IRQ.

There is only question, that is still unclear to me. What happens when camera enters "Movie mode"? There are two possibilities, that I see:
1) ARM continue to be in charge of receiving RAW data and passing it to DSP
2) DSP enters the mode, when it can receive RAW data without the help of ARM, and it only pass encoded data back to ARM.

What do you think about this?

Ah. So no one actually saw DSP code.

Nobody said that
BLOBs, which we believe are DSP code, can be found in earlier cameras' firmware dumps. You can find strings like "jp56_firmware build#0100", "diagnosis() rev0.03", etc. along with build dates and names of the authors in them. I read it somewhere around here, that in newer firmwares, these BLOBs are encrypted or scrambled.

DSP processors have one important characteristic. The manufacturers often write the library right into ROM without possibility to overwrite it.

We don't know whether the above mentioned "DSP firmware" chunks are the whole DSP code or only some part of it.

So assumption that there is DSP code somewhere in firmware updater might be false.

The updater is another story (it contains what Canon wants it to contain). It happened at least once, that a certain model received RAW support through firmware upgrade (SX1, IIRC). The compression of RAW (CRW, CR2) is done by the DSP.

Also DSP and ARM can communicate through IRQ interrupts. So I'm not sure what type of synchronization they use(IRQ or specific address in DDR2 memory).

I think, the various parts of the DIGIC hardware (DMA controller, DSP, etc.) usually generate interrupts when they are done with the job (if you look at the information the Magic Lantern people collected, you'll see, that the generation of a certain interrupt can be optional).

1) ARM retrieve raw data
2) ARM prepares buffer for encoded jpeg
3) ARM passes addresses for raw data and jpeg buffer to DSP
4) ARM signals somehow to DSP(either IRQ or "magic memory address")
5) ARM receives signal of the completed operation through IRQ.

Yes, something like that. DMA is used everywhere for data exchange between the DSP and ARM.

There is only question, that is still unclear to me. What happens when camera enters "Movie mode"? There are two possibilities, that I see:
1) ARM continue to be in charge of receiving RAW data and passing it to DSP
2) DSP enters the mode, when it can receive RAW data without the help of ARM, and it only pass encoded data back to ARM.

2) the raw data is preprocessed by the DSP, and is placed into RAM in a YUV format. The uncompressed video frames then serve as source for the video compressor. In movie mode, a frame can have multiple targets: one for compression and another for display.

Recommended place: http://magiclantern.wikia.com/wiki/Register_Map (their wiki is a mess, they don't use categories).

BLOBs, which we believe are DSP code, can be found in earlier cameras' firmware dumps. You can find strings like "jp56_firmware build#0100", "diagnosis() rev0.03", etc. along with build dates and names of the authors in them. I read it somewhere around here, that in newer firmwares, these BLOBs are encrypted or scrambled.

On D10, I get the impression the blobs are quite similar to on a540, just without the strings. Of course, since I can't decode them it's hard to say if they are encrypted.

However, that the quote from Eiichiro Ikeda, and the relatively small size of these blobs makes me think most of the guts of it is built into the hardware. BTW, if you google the names on those blobs in the old firmwares, you'll find some camera/dsp/image processing related patents owned by Canon. Same for the people in the interview I linked, named here http://www.canon.com/technology/interview/digic4/index.html

Hi,

DIGIC4 updates for DSLR -do- contain TX19A (Toshiba) code
http://magiclantern.wikia.com/wiki/Update_records
http://magiclantern.wikia.com/wiki/Tx19a

Does it help ?

Indy

See also
http://magiclantern.wikia.com/wiki/Datasheets

5D Mark II has TMS320DM36x

Indy

Quote from: srsa_4c on 21 / May / 2012, 14:29:53

BLOBs, which we believe are DSP code, can be found in earlier cameras' firmware dumps. You can find strings like "jp56_firmware build#0100", "diagnosis() rev0.03", etc. along with build dates and names of the authors in them. I read it somewhere around here, that in newer firmwares, these BLOBs are encrypted or scrambled.

On D10, I get the impression the blobs are quite similar to on a540, just without the strings. Of course, since I can't decode them it's hard to say if they are encrypted.

I can confirm this now. On D10, the parts with peoples names have been replaced with spaces, but many byte sequences are identical to a540. But I think this is just something for jpeg, not the whole Digic DSP.

@arm.indiana TX19A looks like it's talking to peripherals, not image processing. Digic image processing is undoubtedly on the same die as the ARM (except maybe some very old cameras like S1is)  http://techon.nikkeibp.co.jp/english/NEWS_EN/20090217/165748/ shows way more chip than just a vanilla ARM946E-S

More or less related:
http://chdk.setepontos.com/index.php?topic=3038.0