close-circle
Close
0%
0%

Raspberry Pi Camera v2.1 Reversed

Reversed schematic and PCB of Raspberry Pi Camera v2.1

Similar projects worth following
close
So you assume with all the openness of the Raspberry Pi Foundation that there most popular peripherals would be Open Hardware, but you would be wrong. Turns out the PI Camera does not have publicly available schematic or PCB designs. The project is here to fix that. I am currently working on another project that the PI Camera boards form factor doesn't work out in but I figured it would be the easiest camera to get up and running so I bought a few and started working on software. Then I found out I had to figure out the support hardware from what was on the PCB.

If you are just curious to look at the schematic and PCB real quick try the interactive viewers on my website: http://dryerzinia.io/index.php?p=projects/ReversePiCam21

As it stands I have drawn up a full schematic for the board. I still need to measure the values of the capacitors and inductors but the basic functionality is apparent. There are 3 regulators, 2 LDOs that supply 2.8v and 1.8v and a buck that supplies 1.2v. There is a dual NMOS package that does I2C level conversion from the PIs 3.3v to the 1.8v for the sensor. There is also a 24MHz crystal to drive the clock of the sensor. There is an EVIL I2C cryoto chip used to lock down the Raspberry PI Camera driver so it wont work with cloned boards. Also there are common mode chokes on the differential data pairs.

PI2_I2C_Test_1.txt

I2C Decode from Logic Analyzer listening in on Pi Cam v2.1 I2C bus during raspistill

plain - 45.78 kB - 01/28/2017 at 03:43

download-circle
Download

  • PI Camera Driver Makes Deal With The Devil

    DrYerzinia02/12/2017 at 01:16 0 comments

    So I have confirmed the nefarious purpose of the ATSHA204A. When you switch sensors between camera boards they continue to function. But when you remove the ATSHA204A the board stops working. Which means it is meant to make sure the Pi Camera Drivers will not work with cloned boards unless they have a ATSHA204A with the correct secrets programmed in! As if it wasn't bad enough we had to deal with a close sourced blob for the video core!

    I have a PiCamera I thought the sensor was broken on, but it turns out the ATSHA204A was borked, the sensor works on another board and now there is no way for me to use that sensor because I don't have a matching crypto chip for the driver!!!

    I have also confirmed my schematic and PCB layout are good, transferred over all the components to my OSH Park boards and the sensors function.


  • I2C Logic Analyzer Trace

    DrYerzinia01/28/2017 at 04:02 0 comments

    I just uploaded a file PI2_I2C_Test_1.txt which contains the I2C decode from running a logic analyzer on the PI Cameras I2C bus while running Raspi Still. Based on the messages it looks like the I2C device is a ATSHA204A. Why on earth do they need a crypto IC on the raspberry PI camera I wonder. Does the sensor require some special keys to communicate with it? I'm a bit short on time lately so if someone wants to dig into it and figure out whats going on that would be awesome, if not I'll get around to it eventually.

    You can see this bytes being read from the device which match the sequence on page 24 of the datasheet of the ATSHA204A.

    0.516076750000000,5,d (0x64),'4' (0x04),Read,NAK

    0.516295000000000,6,d (0x64),'17' (0x11),Read,ACK

    0.516385000000000,6,d (0x64),3 (0x33),Read,ACK

    0.516475000000000,6,d (0x64),C (0x43),Read,NAK

    I also found a forum post mentioning this device with address 0x64. The camera sensor is at I2C address 0x10 it would appear. Oddly enough running a eeprom dump on the camera sensor did produce information, not sure if its anything valid but it was consistent.

    Getting some boards from OSH park tommorow so hopefully I'll be able to let you know if I successfuly transfer a camera sensor to them or not. Looks like I may have to use the same U4 from the old board if that crypto IC is used in any meaningfull way.

    Update:

    Turns out I'm a liar and I did have time to figure out what the I2C data was. It gets the devices serial number. Then it gets a Nonce and HMAC digest from it. Not sure what it does with it though:

    Command
            Length: 0x07
            Opcode: 0x02 Read 4 bytes from device
            Param 1: Zone Config 4 Bytes
            Param 2: Address 0x0000 Serial Number [0:3]
            Checksum: 0x2D1E
    
    Response
            Length: 0x07
            Data: SN[0:3] 01230B59
            Checksum: 0x413F
    
    Command
            Length: 0x07
            Opcode: 0x02 Read 4 bytes from device
            Param 1: Zone Config 4 Bytes
            Param 2: Address 0x0002 Serial Number [4:7]
            Checksum: 0xAD18
    
    Response
            Length: 0x07
            Data: SN[4:7] 8C196D83
            Checksum: 0xC465
    
    Command
            Length: 0x07
            Opcode: 0x02 Read 4 bytes from device
            Param 1: Zone Config 4 Bytes
            Param 2: Address 0x0003 SN[8] Res I2CEN Res
            Checksum: 0x112D
    
    Response
            Length: 0x07
            Data: SN[8] 0xEE Res 0x13 I2CON 0x01 Res 0x00
    
    Command
            Length: 0x1B
            Command: 0x16 Generate a 32-byte random number and an internally stored nonce
            Param 1: Mode combine the new random number with NumIn, store in TempKey. Automatically update EEPROM seed only if necessary prior to random number generation
            Param 2: ZEROS
            Input Value: 5805F3C898C3133154498E082F2E703516F2DBD1
            Checksum: 0x2C82
    
    Response
            Length: 0x23
            Nonce Response: B66B48272C80EA2D2E778162FD300728E2E7E8F04CB0C645BFD0206CC0E7E772
            Checksum: 0x4574
    
    Command
            Length: 0x07
            Opcode: 0x11 Calculate response from key and other internal data using HMAC/SHA-256
            Param 1: Mode include the 48 bits SN[2:3] and SN[4:7] in the message
            Param 2: SlotID 0
            Checksum: 0x8D14
    
    Resonse
            Length: 0x23
            HMAC Digest: 283AE84222422456DEB86CA33D2DFB3A9443E59F2828ABFA71037E34AAA27B2D
            Checksum: 0x445B
    
    

  • Board Overview

    DrYerzinia01/17/2017 at 06:43 0 comments

    Just a quick video about the board showing off the interactive viewers on my website. If you know what the I2C chip is or if the dual indcutors are more than they seem let me know in the comments.

View all 3 project logs

Enjoy this project?

Share

Discussions

Pjort wrote 05/21/2017 at 18:12 point

I had my drone fall out of the sky, and my Raspberry pi cammera v2.1 was attached to it. The drone is completely toast, but I may be able to revive the cammera. But in the crash some components fell of. I am missing the following, and I am not sure what they are exactly, L2, it should be a dual inductor right? But does anyone have a guess on what I should get at digikey? And also C2, but that should just be any small value 0402 capacitor. Then X1, but I can see you already found a part for that: 1473-1150-1-ND correct?

  Are you sure? yes | no

Titus wrote 03/13/2017 at 15:36 point

Hello,

Any update for the crypto chip ?

Do we have any other way to remove that crypto chip and bypass it ?

  Are you sure? yes | no

samy kamkar wrote 01/20/2017 at 07:11 point

Pi "hats" are meant to have an I2C EEPROM that identifies the hat, including information about GPIO mapping. Although the camera pins are not tied to the same I2C bus (ID_SC/ID_SC, pins 27+28), it may be used similarly. Some more information is at https://github.com/raspberrypi/hats/blob/master/eeprom-format.md

  Are you sure? yes | no

Mike wrote 01/18/2017 at 14:32 point

Thomas was correct in that the filters are common mode chokes used on the mipi diff pairs for noise rejection.  This is standard practice in smartphones.  The I2C memory is usually used to store camera tuning information.  This is unique to each camera module and is programmmed at the factory.

  Are you sure? yes | no

Thomas wrote 01/17/2017 at 08:23 point

Just guessing: filters to improve noise immunity by flattening out spikes on one line while coupling it to the other? This would improve common mode rejection at a differential input, and it's standard practice for CAN networks.

  Are you sure? yes | no

Jarrett wrote 01/17/2017 at 06:47 point

Inductors could probably be baluns, yeah? So, like, rotate the schematic symbol 90 degrees, and you've got your voltage-agnostic transmission line.

Measuring continuity would resolve that very quickly.

  Are you sure? yes | no

DrYerzinia wrote 01/17/2017 at 06:52 point

Just went and buzzed them.  They are not baulns, continuity along the line.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates