You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the refactoring of qemu boards that was done under #1642 showed for those boards to be used as reference, since they represent most of existing board flavors today, maintening them just makes no sense anymore.
The solution forward, as started already, is to have common goals mk files under targets dir, and for boards to just pick those targets into the board configurations, and where extensive documentation could then be inside of those target sub-Makefiles.
The qemu-coreboot* boards can easily be used as a base to do that forward.
Until then, when changes related to specific board configs, please compare your board to those reference boards to understand what makes what.
Ideally in the future, those sub-makefiles could also test things out prior of building a non-working board.
For example today, enabling tethering for a board without having the kernel config file adding those modules will fail at build time.
The Makefile could parse the Kconfig file, and tell which Kconfig options are missing, refusing to build the board. or even call internal helpers added to add those Kconfig options to the pointed config file for the developer to simply verify prior of commiting and pushing changes upstream.
The text was updated successfully, but these errors were encountered:
As the refactoring of qemu boards that was done under #1642 showed for those boards to be used as reference, since they represent most of existing board flavors today, maintening them just makes no sense anymore.
The solution forward, as started already, is to have common goals mk files under targets dir, and for boards to just pick those targets into the board configurations, and where extensive documentation could then be inside of those target sub-Makefiles.
The qemu-coreboot* boards can easily be used as a base to do that forward.
Until then, when changes related to specific board configs, please compare your board to those reference boards to understand what makes what.
Ideally in the future, those sub-makefiles could also test things out prior of building a non-working board.
For example today, enabling tethering for a board without having the kernel config file adding those modules will fail at build time.
The Makefile could parse the Kconfig file, and tell which Kconfig options are missing, refusing to build the board. or even call internal helpers added to add those Kconfig options to the pointed config file for the developer to simply verify prior of commiting and pushing changes upstream.
The text was updated successfully, but these errors were encountered: