Pocket Cinema Camera 6K Pro

01Method and evidence grading

Blackmagic Design do not publish schematics or service documentation for this camera. Everything here was established either by direct measurement and observation of a single physical board, or by reading manufacturers' published datasheets for parts identified on it.

Because a repair reference is only as good as its provenance, every claim carries a grade. This is not decoration — it tells you which statements you can build on and which you should re-verify before acting.

02The SoC

The main processor is an AMD (Xilinx) Zynq UltraScale+ MPSoC XCZU5CG in the FBVB900 package, marked FBVB900AAZ on the die. It is mounted as a lidless flip-chip — bare silicon, no integrated heat spreader — under Blackmagic's own heatsink and fan assembly with thermal compound. M

Why the CG variant matters

The CG suffix denotes dual Cortex-A53 application cores plus dual Cortex-R5F real-time cores, and critically no GPU and no Video Codec Unit. Neither hardware block exists on this die.

The consequence is architectural: the entire image pipeline and the BRAW codec must be implemented in the programmable logic fabric. There is nowhere else for them to run. Anyone diagnosing a video fault on this camera is, ultimately, diagnosing the PL. I

Package mechanicals

From AMD UG1075, Figure 5-10, which covers XCZU5CG explicitly. Conforms to JEDEC MS-034 (depopulated). M

Die size is 16.54 × 9.77 mm, with a keepout of 19.54 × 13.77 mm. Balls are Sn/Ag/Cu. Rows run A–AK omitting I, O, Q, S, X and Z.

Ball allocation

All 900 balls parsed from AMD's published package file and classified. M

Two independent transceiver blocks exist and are frequently conflated. The PS-GTR block (4 channels, bank 505) carries USB 3.0 and DisplayPort. The PL GTH block (16 channels, banks 223–226) is fabric-side. They have separate supplies, separate reference clocks and separate calibration resistors. A fault in one tells you nothing about the other. M

03Memory subsystem

DDR4

Four Samsung K4A4G165WE devices sit immediately to the right of the SoC. Each is a 4 Gb DDR4 E-die organised 256M × 16 — 32 Mbit × 16 I/O × 8 banks in 2 bank groups — in a 96-ball FBGA. M

Four ×16 devices form a 64-bit bus totalling 2 GB in a single rank. The device count is set by bus width, not capacity: the controller wants 64 bits and each part supplies 16.

The package brings out 72 DQ — 64 data plus 8 ECC — but four ×16 devices populate only 64. This design has no ECC. I

eMMC

A Samsung KLM8G1GETF-B041, 8 GB eMMC 5.1 in a 153-ball FBGA, sits near the SoC. It holds the boot payload and firmware; recorded footage never touches it. M

Note the ball array occupies only 6.50 × 6.50 mm in the centre of an 11.5 × 13 mm body, leaving 2.5 mm of bare substrate left and right and 3.25 mm top and bottom.

Write speed in this family scales with die count — 50, 50, 100, 200 MB/s for the 8, 16, 32 and 64 GB parts — while read stays pinned at 330 MB/s because the interface saturates, not the NAND. All four share the same footprint; only the 64 GB part breaks 0.80 mm height. A design using this family can therefore accept up to 32 GB with no mechanical change. M

04Component inventory

Parts identified on BMDPCB720C by package marking and confirmed against manufacturers' datasheets. M

Three programmable devices besides the SoC carry their own firmware and are therefore independent update targets: the CYPD3125 (Cortex-M0), the GL3227 (8051), and the Si5338B (on-chip NVM).

05Power rails

Nominal values from AMD DS925 for this device. Rail names are common across the family; do not assume positions transfer. M

AMD's own design guidance permits all five 0.85 V core rails to be sourced from a single regulator, and by default they are. On this board three 470 µF polymer capacitors sit on the reverse side beneath the SoC — bulk decoupling consistent with one high-current core supply rather than five independent ones. I

GTH calibration uses two precision resistors that are worth checking on any transceiver fault: MGTRREF_R at ball K8 and MGTAVTTRCAL_R at ball K7.

06Display path

A Toshiba TC358860XBG embedded DisplayPort to MIPI DSI bridge sits between the eMMC and the SoC. That fixes the display chain: M

Zynq PS DisplayPort  →  eDP over PS-GTR  →  TC358860XBG  →  MIPI DSI  →  LCD panel

This has a useful diagnostic consequence. If the LCD shows an image at all, the PS-GTR transceivers and their supplies are working — the picture physically cannot reach the panel otherwise. On a camera with no usable video but a working menu, that eliminates the PS-GTR domain and points at the PL GTH block instead. I

The bridge also contains a built-in colour bar generator, which is useful for isolating faults to either side of it.

07Debug and boot

Ball positions for the pins that matter when bringing up or debugging this SoC. M

JTAG is itself a selectable boot mode via the PS_MODE straps, and those straps are sampled and latched at power-on reset. Any switch that changes camera behaviour only when held during power-up, and stays latched until the next power cycle, is behaving like a boot-mode strap. I

JTAG is also the practical route to running your own code on this hardware. The firmware payload is encrypted and signed, so a custom update image is not achievable — but a JTAG cable bypasses that path entirely.

08Firmware container format

Blackmagic Camera Setup ships one payload per product, named by USB PID — data-be60.bin for this camera. The format was decoded by parsing every payload shipped with the application and verifying that byte accounting closes exactly on each. M

A package is a chain of nested containers, not a single payload. Each section's header follows immediately after the previous section's body. Only the outermost container is preceded by a 32-byte digest, which is why its magic sits at offset 0x20 while every nested one starts at offset 0.

All fields are big-endian. Header length is 0x30 bytes from the magic. The high byte of +0x20 identifies the target device class; the low byte behaves as a running section index in most packages but not all, and should not be relied upon. I

09Update targets

A Blackmagic camera update is not one write. It is a sequence of independent programming operations against separate devices, each with its own readback verify. On older products these sections ship unencrypted, so the architecture is directly readable. M

Three target classes are firmly identified across the range: 0x04 is the BlamOS application image, 0x10 the Zynq bootloader, and 0x13 a Silicon Labs microcontroller.

Plaintext FPGA bitstreams

Thirteen sections across the older packages are raw, unencrypted Xilinx bitstreams — ffffffff pad, 000000bb 11220044 bus-width detect, then the aa995566 sync word. M

One package alone carries seven. Three of them are identical in length with differing content, and two of those three are byte-identical to each other. Identical length means the same target device; differing content at the same length means different fabric configurations for one FPGA. These cameras hold multiple full bitstreams and switch between them.

Modern cameras — including this one — ship as a single fully encrypted section. The structure still exists; it is decrypted and split by the camera rather than exposed in the package. The split is generational, not per-model.

10BlamOS

Blackmagic cameras do not run Linux. They run BlamOS, an in-house operating system, built with LLVM libc++ and LLVM libunwind. Versions 3.2.2, 3.3.3, 4.1 and 5.1.3 appear across the product range, alongside sibling components bmd_zynq_bootloader and bmd_spi_eeprom_drivers. M

It is not a thin RTOS layer. Kernel strings recovered from plaintext images describe a multi-core, MMU-based operating system with process isolation:

Its filesystem is /boot, /boot/environ, /sys/apps, /sys/settings, /devinfo/productId. Configuration is Apple property-list XML. Kernel panics print with a %s: BUG: prefix. Applications are separate ELF processes loaded from /sys/apps, with their own address spaces, able to bind interrupt handlers directly.

Task decomposition

Recovered from symbols: SchedulerTask, SettingsTask, DiskTask, DualRecTask, ColorCorrectionTask, EVFControlTask, RadioControlTask, RemoteControlTask, ViscaControlTask, IPCReadTask and IPCWriteTask.

That last pair is the architecturally significant one. The application processor does not drive the video pipeline directly — it communicates across an inter-processor boundary. On a faulty camera this predicts a specific split: the subsystems native to the application side keep working while every operation that needs the far side to answer hangs. I

Error codes worth recognising

BlamOS namespaces errors as Subsystem:kebab-case-failure. Those recovered so far:

Disk:write-failed              getTemperature:failed
Disk:read-failed               getRawTemperature:failed
Disk:readback-verify-failed    temp:failed
Disk:is-read-only              setSensorChannelData:failed

Disk:readback-verify-failed is the OS-level name for a target that was written and did not read back correctly — the failure mode behind a firmware update that reaches the end and then reports failure.

11Product IDs

Recovered from product-name strings inside plaintext firmware sections. All are vendor 1EDB. M

Fully encrypted with no recoverable model name: BE11, BE16, BE44, BE60, BE68, BE80, BE81, BE87, BE8A, BEA4.