BCM15700 Camera

From LogiWiki
Jump to navigation Jump to search

The A1398, A1465, A1466, A1502 from 2013 to 2015 (Haswell/Broadwell) as well as A1708 machines use a FaceTime HD camera connected through a MIPI bus to a BCM15700 controller, itself connected through PCIe to the PCH. Older machines use a USB camera, newer ones have the camera handled by T1/T2/M1, they are not covered here.

The BCM15700 uses an external 4Gb framebuffer RAM through a DDR3 bus.

The BCM15700 also includes various voltage regulators (LDO and buck converters) to drive its internal logic, the MIPI bus and the RAM.

Power rails

The BCM15700 only takes PP3V3_S3RS0_CAMERA as its power supply. The other power rails for the camera circuit are created by the BCM15700 itself.

RAM voltages are the usual DDR3L power rails:

  • PP1V35_CAM: the VDDQ voltage for the RAM at 1.35V, 1.337kohms to ground on an 820-3476
  • PP0V675_CAM_VREF/PP0V675_CAM_VREFDQ: feeds VREFDQ at 0.675V, 4.5Mohms to ground on an 820-3476
  • PP0V675_CAM_VREFCA: feeds VREFCA, voltage divider at 0.675V from PP1V35_CAM

Crash during macOS boot

If the BCM15700 is unstable/defective, it can crash, causing the driver to crash when booting macOS and in turn causing a reboot of the machine. Linux would not crash in this situation.

macOS Sierra and Mojave may show something like this when booting in verbose mode:

AppleCamIn::init
AppleCamIn::probe
AppleCamIn::start

Unfortunately these debug messages seem to have disappeared with Big Sur, and it crashes after:

IOG Flags 0x3
Generation from SMC report as 2

The 25MHz clock generated by the clock generator (SYSCLK_CLK25M_CAMERA from U1900 on an 820-3437) can cause it to crash if the clock generator itself is defective or if there is an issue on its power rail, such as a burnt resistor (R2042 on an 820-3437). Interestingly, Linux is less likely to have issues than macOS if the clock is not perfect.

The BCM15700 can be disabled by disconnecting the CAMERA_PWR_EN line (removing R2030 on an 820-3437, R2033 on an 820-4924). This should avoid the crash mentioned above, but of course camera will not work.

See https://boards.rossmanngroup.com/threads/820-3476-820-3437-stuck-on-progress-bar-with-applecamin.54959/#post-64298

Troubleshooting using Linux

In a terminal:

lspci

can tell you if the BCM15700 is at least detected on the PCIe bus. You should see something like:

Multimedia controller: Broadcom Inc. and subsidiaries 720p FaceTime HD Camera

If it is not detected then you probably have an issue with its power supply or with the PCIe bus between the chip and the PCH (check the capacitors) or the chip itself is defective. If it is detected, you could have an issue with the camera itself rather than the BCM15700 controller.

Linux does not have a native official driver for the BCM15700, however there is a reverse engineered driver that works perfectly fine but it must be installed manually.

This driver is very verbose and show information about the controller and RAM initialization in the kernel log when it is loaded.

The driver is available here: https://github.com/patjak/bcwc_pcie

Installation on Ubuntu 20.04

In a terminal:

sudo apt install git curl build-essential
git clone https://github.com/patjak/facetimehd-firmware
cd facetimehd-firmware
make
sudo mkdir /lib/firmware/facetimehd
sudo cp firmware.bin /lib/firmware/facetimehd

git clone https://github.com/patjak/bcwc_pcie
cd bcwc_pcie
make
sudo make install
sudo depmod
sudo rmmod bdc_pci

Then open a second terminal, type:

sudo journalctl -f

Go back to the first terminal and type:

sudo modprobe facetimehd

You should see the log in the second terminal.

Debug logs

Successful initialization

Here is a picture of part of the logs of what a successful initialization looks like:
 

Errors

Here is an example of an error, this one is related to RAM but it was in fact caused by the BCM15700 controller itself (which includes the framebuffer RAM controller):