cx3576: CX3576-Z / Rockchip RK3576

cx3576 is a hardware board, named for the product, and the in-tree porting reference. Its images are published and its flashing path is implemented, and nothing in these repositories starts its images — no suite boots a FIT image.

One hardware observation is on file, of 2026-09-20: on a CX3576-Z unit the loader verified the project’s key over the kernel, device tree and ramdisk, the authenticated init selected and verified the deployment, and the health gate confirmed it (mica-build:boards/cx3576/evidence.json, which names the console capture by digest). The capture is a loader-initiated warm reset, so it is neither the cold-boot nor the warm-boot row, and every row of the qualification matrix below stays not tested.

Status is owned by the status table.

At a glance

SoC	Rockchip RK3576
Architecture	arm64
Boot chain	BootROM → vendor DDR/SPL/TF-A → pinned Mica OS U-Boot → required signed FIT configuration → kernel and authenticated native init → SYSTEM → signed verity root/support → systemd
Firmware form	rockchip-loader — U-Boot sits at sector 64 of the image itself
Partitions	FIRMWARE / SYSTEM / DATA
Storage	eMMC /dev/mmcblk0; the concrete part is still a bench measurement
Kernel and U-Boot	a vendor 6.1 kernel and mainline U-Boot, pinned with their patches in mica-build:boards/cx3576/bsp.env
Tier	bring-up
Boot assurance	I1

There are vendor blobs in the boot chain: DDR init and TF-A from Rockchip rkbin. Software FIT enforcement does not prove that those first mutable stages are authenticated by hardware.

Hardware and feature state

BOARD_FEATURES="wifi bluetooth display status-led can usb-gadget containers". “Declared” means the board declares the feature and ships the packages and initialisation for it; every physical row is untested.

Feature	State	Note
Containers (Podman)	ships	—
Wi-Fi	declared, untested on hardware	the board has a dual radio SKU — AP6275S (bcmdhd, SDIO) or AIC8800D80 — not distinguished at build time. Only the AIC8800D80 firmware ships; the AP6275S SKU is outside this page’s claims
Bluetooth	declared, untested on hardware	the same module as Wi-Fi
Factory access point	ships in cx3576.full, untested on hardware	on out of the box, with the station off; name and key from the device code and the product secret, printed on the label and valid until the claim (mica-core:docs/factory-ap-key.md)
Device code	ships	source emmc-cid, the eMMC chip identifier; survives reflashing
BLE provisioning	ships in cx3576.full, untested on hardware	a phone sets the WiFi network and claims an unclaimed device (first run section 5)
Ethernet	declared, untested on hardware	Motorcomm YT8531 PHY, its init sequence carried as a kernel patch; MAC addresses derive from the eMMC CID and the port’s place in the bus topology rather than from the machine id
HDMI display	declared, untested on hardware	output and rotation defaults sit in the board definition’s prose; nothing in the image pipeline reads a display setting yet
Boot logo	implemented	the Mica OS icon above its wordmark, rendered at build time
CAN	declared, untested on hardware	can0 is a micad network entry of kind can; the board’s defaults are classic CAN at 250 kbit/s, restart after 100 ms, FD off (configuration)
USB OTG / USB gadget	declared, untested on hardware	the gadget getty udev rule ships with the board package
Status LED	declared, untested on hardware	—
RTC	presence unconfirmed	the device tree declares an AT8563/hym8563 at 0x51 on i2c7, board.env records no RTC fact, and neither driver nor backup cell has run on a unit. Time management does not depend on it: always-on NTP, the DATA/state clock floor and the timezone setting are the same on a board with no RTC
Physical recovery action	none	BOARD_RECOVERY_ACTIONS="". The recovery button is not a presence assertion — it puts the board into rockusb loader mode, and no software recovery flow reads it

The hardware-init concerns (BOARD_HWINIT_CONFS="otg bt mac gadget modules") carry one unit and one script each; the board package enables five units.

status: board-dependent — evidence: mica-build:boards/cx3576/board.env, mica-build:boards/cx3576/evidence.json

Partition layout

Partition	Range	Note
FIRMWARE	sectors 64–36863 (below 18 MiB)	holds U-Boot (sector 64; the magic RKNS sits at byte offset 32768) and two 64 KiB CRC-protected boot records at 16 MiB and 17 MiB
SYSTEM	from 18 MiB, 1024 MiB	ext4 + verity, immutable component files and two signed deployments
DATA	from 1042 MiB, 256 MiB at the factory	grown to the medium on first boot

The complete factory image is 1299 MiB = 1,362,100,224 bytes including the GPT tail. The GPT covers the loader and both records, so DATA growth cannot discard them.

Console

Serial ttyFIQ0 at 1500000 baud, with earlycon=uart8250,mmio32,0x2ad40000; net.ifnames=0.

Obtaining an image

The products are cx3576.basic (the default) and cx3576.full (with containers), each released as cx3576.<variant>.<YYYYMMDD-HHMM> with the image mica-cx3576.<variant>-<YYYYMMDD-HHMM>.img.gz. Verification is in download.

Flashing

The image carries its own boot loader: U-Boot sits at sector 64 inside the protected range, so writing the image writes the loader too — there is no separate idblock step, and this board produces no vendor update.img.

Flashing is an operator procedure over USB with rkdeveloptool; the build tree carries no flashing tooling. The image must be the decompressed .img, exactly 1,362,100,224 bytes.

Device in Loader/RockUSB mode (U-Boot runs and its gadget enumerates):

rkdeveloptool wl 0 mica-cx3576-<stamp>.img          # write the whole disk
rkdeveloptool rl 0 36864 boot.bin                     # read the loader and record region back...
cmp boot.bin <(head -c $((36864*512)) mica-cx3576-<stamp>.img)
rkdeveloptool rl 36864 2623488 rest.bin               # ...then everything after it
cmp rest.bin <(tail -c +$((36864*512+1)) mica-cx3576-<stamp>.img)
rkdeveloptool rd                                      # reset, only after both comparisons passed

Device in Maskrom mode (the loader region is absent or broken): push the committed vendor loader first, then the Loader sequence above.

sha256sum -c boards/cx3576/loader/MiniLoaderAll.bin.sha256   # in the mica-build tree
rkdeveloptool db boards/cx3576/loader/MiniLoaderAll.bin

• The loader region (the first 36,864 sectors) is read back first and on its own, because a partial or corrupt write there is the one failure that bricks the board past the recovery key. Do not run rd after a mismatch: the device stays in Loader mode and can be flashed again.
• Do not cut power, unplug or reset the board between db and rd.
• Prerequisites: rkdeveloptool on PATH and USB access to the device (the tree ships no udev rules). On macOS build it natively as docs/hardware/cx3576/rkdeveloptool/README.md describes.

Unverified: every step against real hardware, the key or pad sequence that enters Maskrom, and any SD-card boot fallback. Detail is in flashing section 5.

status: board-dependent — evidence: mica-build:boards/cx3576/loader/MiniLoaderAll.bin.sha256, docs/hardware/cx3576/rkdeveloptool/README.md, docs/start/flashing.md

First boot

DATA growth, two factory deployments and the health gate work as on the UEFI boards; the difference is that the boot records live in redundant U-Boot environments inside the firmware range (tries = 3) instead of in loader entries on an ESP.

U-Boot starts the watchdog before it touches eMMC, validates the current GPT geometry, selects a record, writes, flushes and reads back the decremented attempt, and only then loads its FIT; failing to persist refuses the launch. Both records exhausted or invalid enters local rockusb recovery.

Updates

full, root and kernel archives, as on every board. A/B is two file-based deployments on SYSTEM rather than a partition pair, so there is no “other slot” to flash. See updates and rollback.

Nothing in these repositories starts this board’s images, so the chain from write through first boot, update, confirmation and rollback has no end-to-end run on record.

Recovery

The ladder is the one every board follows; the bottom two steps differ:

• Available: read-only diagnosis, manual rollback, configuration reset, application-data reset, whole-disk reflash.
• Unavailable: credential recovery and full-factory reset — BOARD_RECOVERY_ACTIONS="", so no presence assertion can be produced.
• The floor is rockusb: the recovery button at power-on, the automatic entry when boot fails, or Maskrom when the loader region itself is gone, followed by a whole-disk reflash from Maskrom. It costs every partition and the device identity.
• There is no secure erase; no erase primitive on this eMMC has been verified.

See recovery.

Known limitations

• Physical boot, eMMC power cuts, watchdog handoff and reset cause, the full USB flash, RTC and peripheral qualification all need a named local bench device.
• DDR init and TF-A are vendor blobs; software FIT enforcement proves neither hardware authentication of the first mutable stages nor a closed debug path.
• The accepted radio package targets AIC8800D80; the AP6275S SKU is not qualified.
• The exact eMMC part and board revision still need physical evidence.
• Standalone sha256 digests of the rkbin blobs are not on file.
• Development boot, content and metadata keys are separate test inputs: no OTP/fuse change and no production key ceremony is claimed.
• U-Boot keeps an interactive console (BOOTDELAY=1, with fdt, md/mw and go), so someone at the serial port can alter the in-memory control DTB or run an unsigned binary.

Qualification results

Binding (named-revision rule): board revision CX3576-Z; eMMC at /dev/mmcblk0, part not yet named; radio module AIC8800D80; BSP as pinned in mica-build:boards/cx3576/bsp.env. The AP6275S radio variant is not covered.

Owners: the Mica OS project owns BSP sync, CVE response and the qualification; the board is the in-tree porting reference and has no integrator of record.

No matrix run on a unit is on file, so every hardware row is not tested. Off-hardware gates speak for their own surface and never count as a hardware pass: boot record parsing and firmware IO, DATA growth, and the FIT signature and key-rotation refusals.

Row	Result	Date	Evidence / reason
Cold boot	not tested	—	needs bench hardware
Warm boot	not tested	—	needs bench hardware
A/B switch and update	not tested	—	needs bench hardware; record parsing and firmware IO have an off-hardware suite, not a physical result
Power-cut during update	not tested	—	needs the power-cut rig
Storage growth/health	not tested	—	needs bench hardware; the growth logic has a host-side test, same caveat
Network/radio	not tested	—	needs bench hardware with the AIC8800D80 SKU
USB/fieldbus (CAN, OTG/gadget)	not tested	—	needs bench hardware
RTC	not tested	—	RTC presence itself unconfirmed
Thermal/throttling	not tested	—	needs bench hardware under sustained load
Watchdog/reset cause	not tested	—	needs bench hardware
Offline service	not tested	—	needs bench hardware
Recovery	not tested	—	needs bench hardware; every listed path is described, none rig-proven
Installation and first boot	not tested	—	needs bench hardware; the rockusb flash is documented and has not been run on a unit

status: board-dependent — evidence: mica-build:boards/cx3576/evidence.json, mica-build:boards/cx3576/board.env, mica-build:tests/suites/lifecycle-uboot-fit