Board marking, read off the PCB by the camera's owner: IPC-RB-BLK550AI-M535-ABQ

The silkscreen on the sensor board carries two lines plus a version:
  IPC-RB-BLK550AI-M535-ABQ
  0408205751    V1.02

A note on the last three characters, because it matters and the photos are
not sharp enough to settle it on their own: machine reading of the photograph
returns "...-ABG", but the owner, who has the board in hand, reads "-ABQ".
I am reporting it as ABQ, per the owner. The suffix is plausible in this
family — the catalogue already holds IPC-RB-BLK530AI-0235P-ABQ, the XM530
sibling of this board.

Why this looks like a distinct board and not a duplicate of that sibling:
  - SoC is XM550, not XM530 (ipctool reads chip model XM550)
  - sensor is SmartSens SC5332, i2c bus 0 addr 0x60
  - flash is 8 MB NOR with 64K blocks, partitions
    boot 0x40000 / env 0x10000 / kernel 0x200000 / rootfs 0x500000 /
    rootfs_data 0xb0000
  - the marking's middle group is M535 where the sibling has 0235P

The camera it sits in is a white PTZ dome sold in Russia with no model name on
the box. Hardware found by probing it:
  - PTZ on two axes through kmotor.ko, gpio_pin=3,70,75,77 (X) and 74,76,69,71
    (Y), max_degree 345/135, max_steps 3925/1536
  - IR-cut filter on pads 1 and 2
  - white light array on pad 39 (register 0x1002009c, bit 0x800)
  - speaker amplifier on pad 73
  - the IR illuminator is switched by the board's own light sensor, not a SoC GPIO
  - connectors silkscreened J24/IR_PWM, CN1/IRCUT 1, J20/MOTO, MIC, SPK,
    and an SD slot that no card is fitted to

The flash image attached is the vendor firmware this camera shipped with, read
off the chip before OpenIPC was installed: 8 MB, exactly as read, no header
added. U-Boot 2014.04 (Apr 08 2021), mtdparts
xm_sfc:256K(boot),1536K(kernel),1280K(romfs),4544K(user),256K(custom),320K(mtd),
soc=xm530, sensor=sc5332, appProducerID=A37. SHA256
105b6cc2476c80f0f2f5acbacea6743fde91de4a277a3d3ef9a1abc2e54d9fec.
A copy is welcome in the board's page so a working image exists for it.

One thing worth passing to whoever maintains the nightly: on this board
nightly-20261109-38d76d0 (kernel 3.10.103+, majestic master+c17707d) was not
stable. Seven reboots in one night and about thirteen kernel Oops events of
four different kinds — majestic SIGILL from a divide by zero in libc, majestic
SIGSEGV at an address outside every mapped region, a NULL deref inside the
arasan SD clock path, and paging faults at addresses that differ each time,
landing in unrelated processes (majestic, sh, dropbear, fake-hwclock, dmesg).
Unloading sdio0_sd stopped the reboots; the board has an SD slot but no card,
and /dev/mmcblk* never appears. Crash dumps are available if wanted.