RFC: Project BootELEC – A Unified Hardware Enablement Base for LibreELEC and Its Forks
Summary
This proposal suggests creating a new project to separate hardware enablement and device boot efforts from LibreELEC (and all of its forks) into one shared dependency. The goal is to reduce duplicate efforts in supporting hardware, enable faster and better hardware support, and give userland-focused developers freedom from low-level hardware concerns. By decoupling these layers, the hope is to enable collaboration across several communities and still allow each developer and hobbyist to concentrate on what they love and do best.
Background: Duplication of Effort in Hardware Enablement
LibreELEC and its many derivatives (CoreELEC, Lakka, ROCKNIX, probably a hundred others) have all forked to pursue different goals or support specific hardware. While this forking is a natural part of open-source development, it has led to parallel work on the same problems:
[] Bring up bootloaders and firmware for target devices
[] Integrate kernel patches and device drivers
[] Maintain device trees and configurations
Multiple teams (often solo developers) are solving identical hardware challenges independently. This results in:
[] Slower updates across forks
[] Inconsistent feature support (e.g., HDR, Wi-Fi chips, display orientation)
[] Volunteer burnout and abandoned projects due to maintenance overhead
Forks happened for good reasons. But now we can work smarter—together. By unifying the hardware layer, we reduce redundant work and improve the experience for developers and users alike.
Proposal: Introducing Project BootELEC - not just a distribution, but an open source collaborative effort to enable custom firmware
BootELEC is a unified hardware enablement and boot environment that underpins LibreELEC and its forks. It includes:
[] Bootloaders & Firmware: U-Boot, EFI, etc.
[] Kernel & Drivers: Mainline or BSP kernels with labeled support status
[] Device Trees & Board Support: All initialization code in one place
[] Low-Level Services: Ensure a fully initialized, standardized hardware state before userland boots
Meanwhile, the userland (LibreELEC, Lakka, etc.) would continue to focus on:
[] Launcher applications (Kodi, ES-DE, Steam, etc.)
[] User-level software, services, and add-ons
- UI/UX customization
BootELEC is distribution-agnostic—a shared, modular foundation that every project can depend on without losing identity or independence.
Benefits of BootELEC
[]🛠 Unified Hardware Support: Enable a board once in BootELEC and reuse it everywhere. This saves developer time and immediately benefits all forks.
[]⚡ Faster Device Support: New devices get day-one support in every distro that builds BootELEC.
[]🎨 Freedom for Userland Devs: Focus on UX and features, not drivers or SoC quirks.
[]🤝 Community Collaboration: Shared ownership across distros, building a stronger ecosystem together.
[]🧩 Modularity: Debug faster, update independently, version cleanly.
[]🔄 Easier Backports: Features and fixes become easy to share across distros.
[]📜 Leverage GPL Source: Vendors release BSPs under GPL—BootELEC becomes the one place to integrate and clean them.
[]👨💻 Hobbyists & Pros Alike: Everyone benefits. Solo devs get help, companies reduce cost, and the community gains.
Implementation Overview
[] BootELEC can be built standalone or included as a package.mk dependency
[] Userlands only need to build BootELEC once, then overlay their GUI
[] Device-specific boot requirements (Pi, EFI, Rockchip, etc.) handled within BootELEC
[] Clear init handoff to userland (e.g., via switch_root)
[] Separate versioning for BootELEC and userland
[] Easy to include via submodule or existing buildsystem tooling
[] Optional CLI-only BootELEC image for debugging and bring-up work
[] Shared menu/action directory for device- or distro-specific options
Potential Challenges
[] Governance: Could use GitHub, Discord, or Reddit to coordinate and vote
[] Scope: Clearly define what’s “boot/hardware” vs “userland”
[] Kernel Variants: Support both mainline and BSP when necessary
[] Adoption: Emphasize BootELEC is a tool, not a takeover
- Transparency: Ensure BootELEC is invisible to users unless troubleshooting
Call for Feedback & Participation
Your insight is critical. We invite:
[]LibreELEC & fork maintainers: Can this cleanly integrate into your current workflow?
[]Hardware devs: Would one upstream make your life easier?
[]Manufacturers: Would you contribute your board support to BootELEC?
[]Users & Hobbyists: Would this help you support more devices?
Let’s begin with a proof of concept—split out the hardware layer, test it, and get a second distro running on it. Then iterate and expand.
Conclusion
Project BootELEC is about empowering the open source community, reducing burnout, and multiplying impact. It doesn’t replace LibreELEC or its family—it amplifies all of them by creating a shared foundation for them other forkers to contribute hardware support to.
LibreELEC was born from collaboration. Let’s extend that spirit and remove the single biggest roadblock to forks and innovation: duplicated hardware support.
I’m excited to hear responses. I hope you are too.
Thanks for reading—please share your feedback and ideas. Let’s make BootELEC real.