Disclosure: I maintain awesome-rockchip, and three of my own open-source projects (rk-bench, RK Edge Doctor and onvif-scan) appear in it as ordinary entries, under the same rules as everything else.
Rockchip lists rot the same way every other list does
If you develop on RK3588, you have probably landed on a Rockchip "awesome list" that looked great in a search result and turned out to be a snapshot of the ecosystem from two years ago: dead links, archived repos presented as current, and pull requests from contributors sitting unanswered for months. The content wasn't bad on day one. Nothing about a static list keeps it true on day three hundred.
I ran into the sharp end of this myself. I submitted a small, correct addition to the best-known RK3588 list for one of my tools. The list has hundreds of stars and is genuinely useful — but contributions there appear to get merged in roughly annual batches, and my PR simply sat. That's not a criticism of the maintainer; it's what happens when a list has no maintenance system, only good intentions.
So I built the list I wished existed: awesome-rockchip — 108 entries at launch, in English and Chinese, covering the whole family rather than one chip: RK3588/3588S, RK3576, RK3566/3568 and RV1106/1126.
What "verified" actually meant
I started from 127 candidates gathered from official Rockchip sources, vendor organisations, upstream projects and existing lists — then checked every single one before it earned a place:
- Does the link resolve, and does it point at the project's own home rather than a mirror or re-upload?
- When was the last commit or release (checked via the GitHub API, not by eyeballing)?
- Is the repository archived? If so, it is either out, or in with "(archived)" printed next to its name.
- Is it actually about Rockchip, or a generic project that merely mentions the chip once?
Nineteen candidates didn't survive: exact duplicates (the vendor kernel was a candidate in three different sections), generic upstreams whose Rockchip story is better told by a more specific entry, and tools that turned out to be tiny, stale, or superseded. Every surviving entry got an original one-sentence description, written from what the project does — no text was lifted from any existing list. The full verification ledger (last activity, stars, archived flag, both descriptions) is how the list was built, entry by entry.
Three findings worth knowing even if you never open the list
1. The most popular Ubuntu images for RK3588 are a frozen baseline now. Joshua Riek's ubuntu-rockchip (4,000+ stars, the images half the community started with) is archived. It still works, but anyone building on it should know it is no longer maintained. The list keeps it — honestly labelled "(archived)" — because pretending it doesn't exist would be worse.
2. The mainline story is better than most people think, and there's one page that proves it. Between Mesa's Panthor driver, upstream U-Boot booting more boards every release, and Collabora's running RK3588 mainline-status tracker, "vendor kernel forever" is increasingly a choice rather than a necessity. That tracker is in the list under OS & Kernel, and it's the single page I now check first when someone asks "does mainline support X yet?"
3. The NPU ecosystem has quietly grown a long tail. Beyond Rockchip's official RKNN Toolkit2 and RKLLM stack, the curation surfaced Go and Rust bindings for the RKNN runtime, OpenAI-shaped API servers for RKLLM, Docker images that save you from assembling the conversion environment by hand, and vision-language models (Qwen3-VL, SmolVLM2) already running entirely on the RK3588 NPU. A year ago most of that didn't exist.
The rules that are supposed to keep it alive
A list is a promise about the future, so the maintenance terms are printed at the top of the README, where breaking them is visible:
- Every PR gets a first response within 48 hours — merged, commented, or changes requested. Not "merged within 48 hours"; responded to. That's the part contributors actually feel.
- Links are checked automatically every week (lychee in GitHub Actions), and failures open an issue on their own.
- A maintenance round runs every month: new entries in, dead links fixed or removed, newly archived projects marked.
- No paid placements, ever. Entries are in on merit, in a fixed one-line format, and my own projects get no special position or wording.
Will it work? The honest answer is that the system matters more than the launch. Weekly automation removes the "I forgot to check links" failure mode, and the 48-hour pledge is cheap to keep precisely because the list is small enough to actually maintain. Check back in six months and grade it — the commit history will tell you whether the pledge held.
How to use it / contribute
Start at the section that matches your problem: Boards & Vendors if you're choosing hardware, OS & Kernel for images and boot, RKNN/RKLLM & AI Toolchain plus Models & Deployment if the NPU is your job, Multimedia for MPP/RGA/ISP work, Development Tools for flashing and diagnostics, and Community & Docs for the forums and wikis that still answer questions.
If you maintain or know a Rockchip project that belongs here, the contributing guide is one page: one line per entry, link must be live, project must be Rockchip-relevant and active within the last 12 months (or a stable official baseline). You'll hear back within 48 hours.
Top comments (3)
The 'static list has good intentions but no maintenance system' line is the core insight — the same rot hits dependency allowlists, Electron integration tables and internal docs, and the fix is always a verifiable contract instead of a promise. Your verification protocol (resolve, last-commit via API, archived flag, subject match) is exactly what a CI checker should run weekly so the list stays true without heroic manual effort — the manual pass just seeds the rules. Also appreciate the explicit disclosure that your own three projects are in under the same rules; that's the trust mechanism that keeps a list like this from becoming a billboard.
Thanks for reading it that closely — you're right that the manual pass mainly seeds the rules. The weekly check is automated already (lychee in GitHub Actions), and on its first run it caught a repository that had vanished entirely just hours after I had verified it by hand — exactly the failure mode you describe. What CI still can't judge is the archived-but-essential case, and whether a project is actually about Rockchip or just mentions it once, so those two stay human — along with the 48-hour PR response, which is the part contributors actually feel. "A verifiable contract instead of a promise" is a better summary than the one I wrote; the pledge sits at the top of the README precisely so that breaking it is visible.
If you ever spot a dead or stale entry, an issue or a PR is very welcome — that is exactly how this list is supposed to get better.