[Feature]: support flash to eMMC

[jw0785]

Prerequisites

• I have searched the existing issues and this feature has not been requested before

Feature Area

Flash/Write functionality

Problem Statement

on windows those sbc's imager are all very rough and need various process of elimination to find the combination that do flash.

it would be helpful if armbian imager can provide a universal interface for that.

Proposed Solution

support flash to eMMC

Alternatives Considered

No response

How important is this feature to you?

Would significantly improve my workflow

Use Case

No response

Mockups / Examples

No response

Additional Context

No response

[SuperKali]

Hi, could you share a bit more detail about what you’re trying to achieve?
If I remember correctly, some vendors use boards where the eMMC isn’t soldered on, but instead is a detachable module that can be connected via USB using dedicated dongles.

That said, writing directly to the eMMC through the board’s “regular” USB port sounds quite difficult. To do exactly what you’re describing, it would likely require re-implementing (or heavily modifying) rkdevtool from scratch to support that workflow.

[SuperKali]

On top of that, not all boards support rkdevtool—it only works on devices that provide Maskrom mode. And if we’re talking about non-Rockchip boards, it would get even more complicated.

[jw0785]

Yeah, I mean specifically for rockchip boards that support maskrom mode.
Armbian could ship a tested, working combination of loader binary + tool version per board. Right now users go through painful process of elimination which rkdevtool version + which loader binary actually works for the specific board, something like radax zero 3w.
Even just documenting the validated combos per board would be a huge improvement. For non rockchip boards, agreed that's a separate and harder problem.

also alternatively(which i think arguably better a solution) rkdeveloptool might be crosscompiled targeting windows. that thing is far more reliable vs the gui rkdevtool. If armbian imager can pipe to that as the backend it will solve the problem for a lot of board at once.

[igorpecovnik]

Armbian could ship a tested, working combination of loader binary + tool version per board.

That would cost us a significant amount of time and money to implement and maintain long-term. Unfortunately, with our current resources, we’re already stretched thin just maintaining existing SW stack / infrastructure.

Armbian is largely volunteer-driven, and public funding https://github.com/sponsors/armbian cover less then 0.5% of project costs - we are not in a position to fund expensive projects as such and we can't expand our team - unless people join as volonteers.

I absolutely agree this would be valuable. The most practical way forward would be dedicated funding or contributors specifically interested in working on Rockchip maskrom tooling and integration. If someone is willing to contribute development effort - or seriously sponsor it - we’d be happy to do our best to allocate developers resources ...

[jw0785]

or maybe armbian can reach out to the vendors, i think they at least should do some testing for a project they care enough to sponsor. and it will be for their best interest too.

on armbian end simply using rkdeveloptool as backend will solve most of those problems without extensive testing(for those rockchip sbc) granted, i have no clue if it can be done on windows though

[SuperKali]

or maybe armbian can reach out to the vendors, i think they at least should do some testing for a project they care enough to sponsor. and it will be for their best interest too.

on armbian end simply using rkdeveloptool as backend will solve most of those problems without extensive testing(for those rockchip sbc) granted, i have no clue if it can be done on windows though

There’s another key point: right now there’s no Rust library that can handle this, so we need to build a custom one to properly communicate with the SBC.
That takes time for implementation, debugging, and testing across multiple setups.

Also, simply compiling a binary and dropping it into the imager isn’t a good long-term solution. It may work short-term, but it’s not maintainable over time and it can quickly turn into technical debt (updates, compatibility, packaging, security, CI, etc.).

In practice, Armbian is sustained by the open-source community, with a small core team investing a lot of effort. That’s why we should aim for a clean, properly integrated and packaged solution, rather than shortcuts that become hard to maintain.

If anyone is interested in contributing, help would be greatly appreciated, for example:

• building the Rust library (stable API, error handling, compatibility)
• testing across different boards/revisions and collecting logs
• proper Armbian integration/packaging (deb packages, build pipeline, updates)
• documentation and usage examples

Even small contributions (testing, feedback, focused patches) can make a big difference and help move things forward faster.