Is your enhancement proposal related to a problem? Please describe.
Since January 2026 Zephyr upstream has removed the HWMv1 board extension feature. Bridle has used this feature since years and will not miss it, also not in HWMv2 generation.
Describe the solution you'd like
The old HWMv1 behavior was more random in terms of the order in which board extensions were integrated. Now, after removal in upstream, Bridle can be very confident that only its own board extensions play a role in the build process. However, to really guarantee this, the revert commit of tiacsys/zephyr@c02c6ad must be avoided so as not to potentially offer the same functionality to other Zephyr modules. It should work exclusively for Bridle.
The goal is therefore to provide this functionality within the Bridle boilerplate and drop the revert commit. Revert commits will always lead to increased maintenance effort in the future.
Describe alternatives you've considered
Non.
Additional context
Zephyr upstream documentation: Board extensions
Is your enhancement proposal related to a problem? Please describe.
Since January 2026 Zephyr upstream has removed the HWMv1 board extension feature. Bridle has used this feature since years and will not miss it, also not in HWMv2 generation.
Describe the solution you'd like
The old HWMv1 behavior was more random in terms of the order in which board extensions were integrated. Now, after removal in upstream, Bridle can be very confident that only its own board extensions play a role in the build process. However, to really guarantee this, the revert commit of tiacsys/zephyr@c02c6ad must be avoided so as not to potentially offer the same functionality to other Zephyr modules. It should work exclusively for Bridle.
The goal is therefore to provide this functionality within the Bridle boilerplate and drop the revert commit. Revert commits will always lead to increased maintenance effort in the future.
Describe alternatives you've considered
Non.
Additional context
Zephyr upstream documentation: Board extensions