Add centralized board configuration#32
Add centralized board configuration#32EugeniyKozhanov wants to merge 1 commit intoflipperdevices:devfrom
Conversation
EugeniyKozhanov
commented
Mar 15, 2026
EugeniyKozhanov
commented
- created individual configuration files for 6 supported boards (config/boards)
- created configs/combo.conf - centralized build settings
- created configs/board-config.sh - configuration management utility
- created build-combo.sh - unified build script with commands
- created individual configuration files for 6 supported boards (config/boards) - created configs/combo.conf - centralized build settings - created configs/board-config.sh - configuration management utility - created build-combo.sh - unified build script with commands
|
Hi Eugeniy, thanks for your PR! Would you mind elaborating a bit on the rationale for this addition? From what I see, the config part of this change should really live in U-boot and upstream DTS, and we’d better update things there if anything is not quite suitable for common use cases. The information on Maskrom activation per board sounds like it belongs in documentation (either a README in this repo, or dev portal, or even upstream U-boot for what it’s worth). |
|
Please also note that the build stages are deliberately split up to enable selective rebuilds only for those components which changed in respective Git trees. It’s what our Buildbot uses. So merging everything into a single script is not what we want. I don’t particularly mind a helper script which calls all the sub-stages in sequence, altogether it won’t be much different from just pasting a sequence of commands from the README into a terminal. |
|
The main goal is to try separating board-specific settings into individual configs. I don’t have any of the boards you listed, and as an experiment I wanted to try building your OS for my PineNote (rk3566). However, it wasn’t straightforward, because it seemed that information about sources, settings, and options is spread across different scripts. In short, I’d love to have a simple way to add a new board: explicitly define it, override a few parameters (and maybe an overlay), and be confident that this won’t break already tested builds. |
|
Some parameters there might currently be unnecessary. You could also treat these configs simply as an example for possible future changes. I tried to make something similar to the combo approach used for launch configurations in AOSP. If the project continues to support a range of devices, there will likely need to be a place to configure things like enabling/disabling Wi-Fi, Bluetooth, DisplayPort, as well as screen type, resolution, and similar device-specific parameters. The combo script can actually run each stage separately - it’s essentially a copy-paste of the root scripts :) |
|
Frankly, extending the build system beyond RK3576 is probably out of scope for us, as it’s opening a Pandora’s box into trying to support everything at once without any chance of being good at it. Pragmatically, for your use case, you can just manually build a U-boot binary for your board (using upstream U-boot if available) and put it into the prebuilt/u-boot/[boardname] directory (e.g. through a one-off modification of the build-uboot.sh script - you don’t have to update it often unless you know otherwise). The rest of the build scripts are board and SoC agnostic and should just pick it up transparently |
2 participants
