Support upgrade device firmware / download image

[Tnze]

I have an implementation of the rkusb protocol. And maybe we can combine the two project to support the upgrading process?

[suyulin]

Thanks, this looks like a good fit. afptool-rs can handle RKFW/RKAF parsing while rkusb provides the device transport and storage operations.

I would prefer keeping the projects separate and integrating rkusb as an optional dependency, with an initial workflow like:

1. parse/unpack the RKFW/RKAF image;
2. detect the device and download the loader when required;
3. match RKAF entries to GPT partitions;
4. validate partition sizes before writing;
5. write partitions with explicit confirmation and dry-run support.

Are you proposing to submit the integration PR? Also, should the first version target full update.img upgrades or individual partition flashing, and which chip/storage combination can you test?

It would also help to add a LICENSE file to rkusb; its Cargo.toml declares MIT, but GitHub currently does not detect a repository license.

[Tnze]

I'd prefer first refactoring this tool, separating the parsing and unpacking/packing logic.

Then we publish the parsing part as a library to the crate.io and put the executable binary form as sub-crate or some other structure like that.

After doing that, I can add this crate as a dependency of rkusb. And I will only support upgrades with update.img as whole.

On the other hand, we can also add an optional feature for this afptool supporting both upgrading entire RKAF image or unpacked images as you like, with rkusb dependency.

[suyulin]

That sounds like a clean separation. I agree that the image parsing/packing logic should first be extracted into a reusable library crate, while keeping the CLI as a separate workspace member.

The dependency structure could be:

• afptool-format: RKFW/RKAF parsing, validation, packing, and unpacking APIs;
• afptool-cli: the current command-line interface;
• rkusb depends on afptool-format for whole update.img upgrades;
• afptool-cli may optionally depend on rkusb for device upgrade/flashing commands.

This avoids a dependency cycle as long as the format library remains independent of rkusb.

I can start by restructuring this repository and defining the initial public API. Do you have a preferred crate name or any parsing API requirements from the rkusb side?

[Tnze]

I will propose PRs for this since you agree this change. The development will take about half years in my plan.

I can test on RK3588S and RK3576S platforms.

[suyulin]

Sounds good, thank you for taking the lead on this. RK3588S and RK3576S should provide useful test coverage.

Feel free to submit the refactoring in incremental PRs so that we can review and agree on the crate boundaries and public API before moving on to the device-upgrade integration. There is no need to bundle everything into a single PR.