Hi,
I'm sharing a small open-source project and would appreciate the community's perspective.
Background
Rockchip-related flashing tools fall into a few categories:
- Official RKDevTool (GUI) — graphical workflow, but essentially Windows-only. It drives the SDK
upgrade_tool under the hood.
- SDK
upgrade_tool (CLI) — the command-line tool shipped with the Rockchip SDK (macOS / Linux / Windows). Same command set as the Windows GUI, but no official cross-platform GUI is provided for it.
- Official open-source rkdeveloptool — command-line only (no GUI), for Linux and macOS.
I often work on macOS and Linux. Flashing firmware purely from the command line was inconvenient for my day-to-day workflow. I wanted a desktop GUI similar to the official Windows RKDevTool.
I chose to wrap SDK upgrade_tool (not rkdeveloptool itself) because it matches the Windows tool's commands and workflow. That led me to build an unofficial, fully open-source cross-platform GUI wrapper.
What I built
RKDevTool is an unofficial, community desktop app that wraps the SDK upgrade_tool CLI (subprocess invocation, live logs, device polling):
It automates common upgrade_tool operations, for example:
- Download / flash partition images (DI, WL, UL, DB)
- Firmware upgrade with
update.img (UF)
- Advanced actions (chip info, erase, reboot, storage switch, serial log export, etc.)
- Real-time log output with in-place progress updates
- Multi-device selection when several boards are connected
On Linux, .deb installs can ship a udev rule for Rockchip USB devices (VID 2207) so flashing does not require sudo, similar in spirit to 99-rk-rockusb.rules in this repository.
Disclaimer
This is a third-party community project. upgrade_tool binaries come from the Rockchip SDK and are subject to the SDK's license terms. Release installers may bundle platform upgrade_tool binaries for convenience; I am open to switching to a "bring your own binary from the SDK" model if that is preferred.
Questions for the community
I want to make sure this approach is reasonable and respectful:
- Would a complementary third-party GUI around
upgrade_tool be useful to others here, alongside CLI workflows such as rkdeveloptool?
- Any concerns about redistributing SDK
upgrade_tool binaries in release installers vs. asking users to supply them from the SDK?
- Is there anything I should change in naming or documentation to avoid implying official endorsement?
I am not claiming official status. Feedback on any of the above is very welcome.
Thanks for maintaining rkdeveloptool and for any guidance.
Hi,
I'm sharing a small open-source project and would appreciate the community's perspective.
Background
Rockchip-related flashing tools fall into a few categories:
upgrade_toolunder the hood.upgrade_tool(CLI) — the command-line tool shipped with the Rockchip SDK (macOS / Linux / Windows). Same command set as the Windows GUI, but no official cross-platform GUI is provided for it.I often work on macOS and Linux. Flashing firmware purely from the command line was inconvenient for my day-to-day workflow. I wanted a desktop GUI similar to the official Windows RKDevTool.
I chose to wrap SDK
upgrade_tool(notrkdeveloptoolitself) because it matches the Windows tool's commands and workflow. That led me to build an unofficial, fully open-source cross-platform GUI wrapper.What I built
RKDevTool is an unofficial, community desktop app that wraps the SDK
upgrade_toolCLI (subprocess invocation, live logs, device polling):.dmg), Linux (.deb/ AppImage), Windows (.exe)It automates common
upgrade_tooloperations, for example:update.img(UF)On Linux,
.debinstalls can ship a udev rule for Rockchip USB devices (VID2207) so flashing does not requiresudo, similar in spirit to99-rk-rockusb.rulesin this repository.Disclaimer
This is a third-party community project.
upgrade_toolbinaries come from the Rockchip SDK and are subject to the SDK's license terms. Release installers may bundle platformupgrade_toolbinaries for convenience; I am open to switching to a "bring your own binary from the SDK" model if that is preferred.Questions for the community
I want to make sure this approach is reasonable and respectful:
upgrade_toolbe useful to others here, alongside CLI workflows such asrkdeveloptool?upgrade_toolbinaries in release installers vs. asking users to supply them from the SDK?I am not claiming official status. Feedback on any of the above is very welcome.
Thanks for maintaining
rkdeveloptooland for any guidance.