Web UI for BeagleBoard Imaging Utility

Google Summer of Code
1

@ayush1325 I’m creating this topic for you to foster discussion. We really need to get some ideas pushed up to the site to make it easier for the GSoC folks to find them!!!

Idea is:
Allow flashing BeagleBoard.org boards directly from web based UI, without requiring any local install. BeagleBoard Imaging Utility <https://github.com/beagleboard/bb-imager-rs/>_ is written using iced, which does allow targeting web. Depending on the performance, using Tauri/Dioxus or something similar for UI parts is acceptable. However, the flashing code should be shared with the existing imager.

4 Likes
2

Hello everyone!

I’m Mannan, and I’m interested in participating in GSoC 2026, particularly in the project “Web BeagleBoard Imager.”

To better understand the project, I built a small demo where I:

  • Extracted the Rust core from the existing BeagleBoard Imager application.
  • Created a Rust backend service that reuses the flashing and downloading core logic.
  • Implemented image downloading through the backend service.
  • Built a simple HTML + JS frontend as a user interface (UI).

Currently, the webpage supports downloading images. I am now working on integrating the flashing functionality using the same shared Rust core logic. My goal is to ensure the website can serve as a unified interface for both downloading and flashing images, improving usability and accessibility.

Before reviewing the prototype, please refer to this guide: -

BeagleBoard Idea 2026.docx

Prototype Links:

Website Demo: BB Imager
GitHub Repo: synan-mannan/BeagleBoard_Idea_2026_Prototype

Looking ahead, I plan to:

  • Expand the website with image selection and configuration settings

  • Integrate full flashing support via the Rust backend service

  • Maintain a shared core logic between the web interface and the application

I would greatly appreciate any feedback, suggestions, or guidance on improving the architecture or aligning better with the project goals.
Thanks, and looking forward to your insights!
@jkridner @ayush1325

3

We explicitly don’t want a separate backend service. The reason is that if the user can download and install a service, it’s better to direct them to install the native application.

A web version should be standalone. Maybe asking them to install an extension would be fine. But I would prefer to make even that non-mandatory.

4

Thanks for the clarification - that totaly makes sense that not to use a backend service running.

Based on your feedback, I’m exploring a fully standalone browser-native approach using WebAssembly and WebUSB, instead of a separate backend service.

The idea is to refactor the Rust flashing core into a platform-independent library, compile it to WebAssembly, and run it directly in the browser. WebUSB (via JavaScript) would handle device communication, so no local daemon or installation would be required.

Before proceeding further, I’ll verify whether the BeagleBoard devices support USB-based flashing and identify any OS-level dependencies that need to be abstracted.

I also wanted to clarify one point — does the current flashing mechanism rely on raw disk writing or direct SD card writes at the block device level? If so, that may not be feasible from a browser environment, since WebAssembly and WebUSB do not allow direct raw disk access. I’d like to confirm this to better understand the technical constraints before refining the architecture further.

5

Hi @ayush1325 ,

I’ve been reworking with a prototype related to BB Imager and deployed a small WebAssembly-based demo that runs in the browser:

https://synan-mannan.github.io/BB_Imager_WASM/

It’s a work in progress exploring how the imager workflow could work in a browser environment and as mentioned before it is based on Web Assembly. I’d really appreciate any feedback or suggestions.

Thanks!

6

Hello, please provide source code if you want feedback.
Also, BeagleBoard was not selected for Google Summer of Code this year. So please keep that in mind.

7

Appreciate your response. I’m mainly interested in the project itself and contributing to it as an open-source contribution, not specifically for mentoring or Google Summer of Code.

Here is the GitHub repo for source code - synan-mannan/BB_Imager_WASM

Thanks!

8

I would suggest to first look at compiling the current iced based UI itself to wasm. It should be possible. If the performance ends up being terrible, only then should we try to have seperate UI code for wasm.

9

Hi @ayush1325,

Thanks for taking time to check back on this, noted your suggestion!

I’ve shared the source code earlier, but to give more context — this prototype is an experimental attempt to explore how the BB Imager workflow could be adapted to run in a browser using WebAssembly.

Currently, I’m focusing on:

  • Understanding how disk imaging workflows translate to a browser sandbox

  • Handling file operations within browser constraints (no direct block device access)

  • Exploring performance and UX trade-offs compared to native implementations

Up next. will try to:

  • Translate the current Iced UI to wasm.
  • Integrate UI to my current prototype.

I’d really appreciate your thoughts on:

  • Whether this direction makes sense from a BeagleBoard ecosystem perspective

  • Any architectural changes you’d recommend

  • Areas where this could align better with existing tooling or workflows

Also, if there are specific parts of the codebase you’d like me to refine or explore further, I’d be happy to work on that.

Looking forward to your feedback!

10

It would be better to start with just BeagleConnect Freedom flashing. We know it can work over webserial.
Normal disk imaging workflows will not work in wasm context, we can use DFU or something else, but that should come later.

11

Thanks for suggestion @ayush1325 that makes sense! I’ll pivot to focusing on BeagleConnect Freedom flashing via WebSerial first and build a minimal working flow around that.

Once that’s stable, I can explore DFU or other approaches later.

Appreciate the guidance!