rockusb: add rkdeveloptool-compatible aliases for subcommands

[obbardc]

Add some short aliases matching rkdeveloptool conventions for compatibility: ld, db, rl, wl, rci, rid, rfi, rcb, ef, rd.

Fixes: #17

[sjoerdsimons]

How compatible are these? Can you reasonably do s/rkdeveloptool/rockusb with these? I never aimed for command line compatibility so don't have a good feeling for that

[Copilot]

Pull request overview

Adds rkdeveloptool-compatible short aliases to the rockusb example CLI subcommands to improve compatibility and muscle-memory for users coming from rkdeveloptool (Fixes #17).

Changes:

• Added short subcommand aliases: ld, db, rl, wl, rci, rid, rfi, rcb, ef, rd.
• Kept existing long-form subcommand names intact while enabling alternate invocation forms.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[obbardc]

How compatible are these? Can you reasonably do s/rkdeveloptool/rockusb with these? I never aimed for command line compatibility so don't have a good feeling for that

Pretty good for the ones I tested, BUT I didn't test all of them for compatibility.

The main reason for this change was that labgrid uses rkdeveloptool and hard-codes these short codes and I wanted to use rockusb as a drop-in replacement for rkdeveloptool. See the thread at labgrid-project/labgrid#1542 (comment)

I don't use labgrid anymore, so I am happy to drop this really if you don't see any point.

I guess it COULD make sense to either:

1. remove the commit message suggesting this change makes rockusb a drop-in replacement for rkdeveloptool and just adds some short-options
2. check proper compatibility with rkdeveloptool AND possibly add a unit-test checking so.
3. drop this completely so to not confuse anyone.

I think option 1 or 3 is probably best to not limit rockusb in future, but pen to suggestions either way

cc @sjoerdsimons @QSchulz @Emantor

[Emantor]

My 2 cents as a labgrid maintainer: my preference would be to add another driver for rockchiprs that better maps how it is supposed to be used instead of trying to shoe it into the existing driver.

[obbardc]

My 2 cents as a labgrid maintainer: my preference would be to add another driver for rockchiprs that better maps how it is supposed to be used instead of trying to shoe it into the existing driver.

I agree. Guess it'd make sense to drop this.

[sjoerdsimons]

@obbardc I'll leave you to decide whether to close it then or if you'd like to do short, but not necessarily compatible aliases to minimize typing ;). Basically you pick 1 or 3..

[QSchulz]

The very nice thing about rockusb from rockchiprs is the ability to flash bmap'ed files. Being able to use it with the exact same arguments as rkdeveloptool would make it easier to migrate to it. At the same time, last time I checked rockusb was significantly slower than rkdeveloptool so that also is a brake on adoption.

At the same time, we (Kwiboo mainly) are planning to USB-load into DRAM U-Boot/Barebox binaries without a need for an external tool, see labgrid-project/labgrid#1721. With that, the usefulness of rockusb/rkdeveloptool in labgrid is reduced to flashing with the rockusb protocol over USB, which we wouldn't even be forced to do anymore for upstream-supported devices where e.g. DFU or fastboot could be available (or even custom TFTP/wget + flashing from U-Boot directly).
We're currently stuck at "U-Boot generates two binaries but the bootstrapping in labgrid only expects one" which requires us to either require the user to run the Rockchip-proprietary binary tool boot_merger on those two binaries to generate a single one, or reverse-engineer it and add support in mkimage for a new format that matches that output by boot_merger. Another option could be to come with yet another format but then the usefulness of it is pretty close to zero if people cannot use rkdeveloptool/rockusb which is documented everywhere as the tool to use for Rockchip.

[sjoerdsimons]

the file boot_merger spits out is rather trivial though (for unsigned ones)? We already have the rockfile crate to read those (otherwise rockusb wouldn't be able to push it to maskrom) Which means writing it should be easy enough. So i'm not entirely sure what the problem is here.

[QSchulz]

I'm also pretty convinced it's trivial, but somebody needs to put in the work and nobody's volunteered so far. I'm interested but I lack bandwidth for the next few weeks/months.

[obbardc]

I updated the commit message to be more clear that these are provided on a best-effort case and in no longer suggesting this commit makes rockusb a drop-in replacement for rkdeveloptool.

[sjoerdsimons]

I'm also pretty convinced it's trivial, but somebody needs to put in the work and nobody's volunteered so far. I'm interested but I lack bandwidth for the next few weeks/months.

Ah yes; Getting time is always a lot less trivial. If it's valuable for you, please do open an issue against this project to add write support for rockfile.. That's something i can probably make a bit of time for.. For adding it to binman less so sadly.