Skip to content

Cross-platform GUI wrapper for SDK upgrade_tool (macOS / Linux / Windows) — feedback welcome #129

Description

@hiifong

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:

  1. Official RKDevTool (GUI) — graphical workflow, but essentially Windows-only. It drives the SDK upgrade_tool under the hood.
  2. 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.
  3. Official open-source rkdeveloptoolcommand-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:

  1. Would a complementary third-party GUI around upgrade_tool be useful to others here, alongside CLI workflows such as rkdeveloptool?
  2. Any concerns about redistributing SDK upgrade_tool binaries in release installers vs. asking users to supply them from the SDK?
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions