Support board config

[hzyitc]

Description

I note that the u-boot args are defined in /config/sources. So if we need some device-special values, we need to use if or case to check BOARD, which make /config/sources so ugly.

This PR allow to overwrite sources config in /config/board/$BOARD/sources.conf.

This PR use imx6 to demo.

This may not be the best way. And I have another solution. Which do you accept?

Another solution

Adjust folder struct like this:

${processor-family}/
├── ${processor}/
│   ├── ${board}/
│   │   ├── kernel.conf
│   │   ├── u-boot.conf
│   │   ├── boot.cmd
│   │   ├── boot-env.ini
│   │   └── patches/
│   ├── kernel.conf
│   ├── u-boot.conf
│   └── patches/
├── kernel.conf
├── u-boot.conf
├── boot.cmd
├── boot-env.ini
└── patches/

Read processor-family level config first, then processor level, then board.

So we got all config with priority.

How Has This Been Tested?

• [X] Build
• [X] Check the correctness of boot.scr in output image

Checklist:

• [ ] My code follows the style guidelines of this project
• [X] I have performed a self-review of my own code
• [X] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] My changes generate no new warnings
• [ ] Any dependent changes have been merged and published in downstream modules

[lanefu]

@hzyitc we have some big refactoring changes in the armbian-next branch that may address this.

Including @rpardini @igorpecovnik for feedback

[igorpecovnik]

We need to see if this has value in armbian-netxt.. Plan is to merge by the end of this month. If we manage.

[igorpecovnik]

@rpardini what to do with this? Merge as is ?

[rpardini]

Yeah this is trying to address the old problem of "board defines family indirectly, family includes common file directly" and the overwriting of board-defined variables, leading to if/case/etc for $BOARD in the family or common code.

Solution in this PR involves having 2-phase source'ing for boards, one the existing one, then another after family code is run. This might allow for cleaner (board-independent) family code, but causes further fragmentation of board-related info into many files. Essentially moves from family to more board files.

I'd rather have everything defined in a single board file, using callbacks. This could be done right away in master branch by defining a function called for example post_family_config__fix_uboot_stuff_for_cubox() right there in the board file. That function will be run after family code has run and can overwrite what's defined by family or common include.

See the documentation for extensions (https://docs.armbian.com/Developer-Guide_Extensions/) and the hooks (https://docs.armbian.com/Developer-Guide_Extensions-Hooks/) -- although in this case we don't need a separate file for the code, instead can be right there in the board file.

(The "another solution" directory-based scheme is something we've thought about for a long while too. See for example LibreELEC or buildroot-based build systems. I think it is more worth investing time in; I've not gone this way in armbian-next since I'm trying to keep configuration compatible with master.)

[rpardini]

@hzyitc let me know if I can be of assistance...

[hzyitc]

@rpardini Sorry for forgot this.

Yes, hook function is better than this PR. We can use different function to divide the configs of u-boot, kernel.

But as my option, hook function is a new feature. The current configs need to be changed to adapt it. So why not try to support tree config. For compatiblity, we can support both tree and legacy config. If have tree config then use it. Otherside, use legacy.

If we need to support tree config in master, we can use source to include all files.