Board report: Xiongmai XM550 + SmartSens SC5332, 8 MB NOR

The camera is a generic white PTZ dome bought in Russia, sold without a
meaningful model name. It came with the vendor (Xiongmai) firmware and has
since been flashed with OpenIPC nightly-20261109 (build 38d76d0,
majestic master+c17707d).

ipctool reads the SoC as Xiongmai XM550 and the board vendor as Xiongmai,
but no board code: /api/v1/boards/identify answered known=false with zero
matches, and nothing in the stock firmware images carries a marking that
matches a catalogue entry. The physical PCB marking has not been read yet
(the owner has offered to open the case); this report is sent first so the
stock dump is on file.

Hardware as read by ipctool (see the yaml part):
  chip            Xiongmai XM550
  board vendor    Xiongmai
  sensor          SmartSens SC5332 (i2c bus 0, addr 0x60)
  flash           8 MB NOR, 64K blocks
  ram             128 MB total, 64 MB media
  partitions      boot 0x40000, env 0x10000, kernel 0x200000,
                  rootfs 0x500000 (squashfs), rootfs_data 0xb0000 (jffs2)

Stock firmware (the vendor build this camera shipped with), from U-Boot env
and the flash layout:
  U-Boot 2014.04 (Apr 08 2021 - 10:22:49), CPU XM530, DRAM 128 MiB
  mtdparts xm_sfc:256K(boot),1536K(kernel),1280K(romfs),4544K(user),
                  256K(custom),320K(mtd)
  soc=xm530  sensor=sc5332  appProducerID=A37

What the board has on it, as found by probing the hardware:
  - PTZ on two axes, driven through kmotor.ko with gpio_pin=3,70,75,77 for X
    and 74,76,69,71 for Y, max_degree 345/135, max_steps 3925/1536
  - IR-cut filter on pads 1 and 2, driven by majestic
  - 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 by
    a GPIO the SoC drives
  - no SD card slot wired up that the driver can see; /dev/mmcblk* is absent
    and /sys/class/block holds only ram devices, yet sdio0_sd loads

Stability, in case it is useful to the nightly maintainers: this build
(nightly-20261109-38d76d0, kernel 3.10.103+, majestic master+c17707d) is not
stable on this board. In one night it rebooted seven times and produced about
thirteen kernel Oops events, of four distinct kinds:
  - majestic SIGILL at libc+0x40934 (UDF #255, __aeabi_idiv0: divide by zero)
  - majestic SIGSEGV at 0x652e70, an address outside every mapped region
  - kernel NULL deref at 0x000000a0 inside the arasan SD clock path
  - kernel paging request faults at addresses that differ each time
    (0x00000001, 0x1d4cc314, b108efc8, 00c39844), landing in unrelated
    processes (majestic, sh, dropbear, fake-hwclock, dmesg)
Unloading sdio0_sd stopped the reboots. Crash dumps are available on request.