@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
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
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.
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.