Rockchip RK3576 EVB1 v10
Rockchip’s own RK3576 reference board. boot2deb ships it for one reason: its device
tree is already in mainline. A build of rk3576-evb1-v10/forky therefore exercises the
whole RK3576 chain, with no board device tree of ours in the picture. The kernel
builds its DTB from its own tree, and u-boot builds against the DDR loader and BL31.
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 rather than the display u-boot a
consumer board ships. That is the minimal rockusb image, the dev-board bring-up
posture. 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, and 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. 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, and it exists so the
SoC-generic u-boot images have somewhere to live. Those are rk3576-generic/loader
and rk3576-generic/util, whose 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.