Rockchip RK3576 EVB1 v10

Rockchip’s own RK3576 reference board. boot2deb ships it for one reason: its device tree is already in mainline, so a build of rk3576-evb1-v10/forky exercises the whole RK3576 chain — the kernel builds its DTB from its own tree, u-boot builds against the DDR loader and BL31 — with no board device tree of ours in the picture.

That makes it the SoC-path validator. When an RK3576 build breaks, building this recipe answers whether the fault is in the SoC layer (kernel definition, kconfig fragments, patch series, rkbin blobs) or in a particular board’s .dts. Compare it with the H96 MAX M9, which carries a device tree of its own.

boot2deb build rk3576-evb1-v10/forky

The board defaults to the loader u-boot series — the minimal rockusb image, the dev-board bring-up posture — rather than the display u-boot a consumer board ships. The display and util variants are both in its supported_uboot_series, so a build can select either:

boot2deb build rk3576-evb1-v10/forky --uboot-series rk3576-util

See RK3576 u-boot images for what each series carries and The maskrom loader for streaming one into RAM.

Status

The image builds; nobody has booted it on the hardware. It is expected in the support matrix — every axis it resolves is shared with the H96 MAX M9, which is validated, and it differs only in using an upstream DTB instead of a board one. If you have this board, a boot report is the one thing that would move it.

rk3576-generic

devices/rk3576-generic.toml is not a board. It is a tool host: it exists so the SoC-generic u-boot images — rk3576-generic/loader and rk3576-generic/util — have somewhere to live, since their payload builds from the rk3576-generic control DTB and is byte-identical on any RK3576 board. Those recipes are u-boot-only deliverables (deliverable = "uboot"): they name no suite, no kernel, and no image.

Reach for them when you are bringing up an RK3576 board boot2deb has no device file for yet — they will flash and drive it before anything board-specific exists.