@TakeoTakahashi2020 @iabdalkader I'm trying to further simplify the board configuration for this port. What do you think about this change?

I'm not sure if this will work, some modules may need different config options based on the project's configuration, @ TakeoTakahashi2020 would know more about this than I do.

Ideally, I would like to see just one config file for the whole FSP SDK, per board, auto-generated by e2studio but that's not going to happen because FSP code #includes single config files.

I'm not sure if this will work, some modules may need different config options based on the project's configuration,

At the moment all these files are exactly the same, so at least we can start with this simplification for now.

Ideally, I would like to see just one config file for the whole FSP SDK, per board

We could possibly do that by:

1. having a common config file for all boards for each component (as done by this PR)
2. at the end of each common config file, #include a board-specific config file that can override any options that it needs to

Ultimately, I would like users to be able to define their own custom boards without using e2studio at all. Not sure how feasible that is, but IMO it's a good goal, and requires each board config to be as simple as possible.

having a common config file for all boards for each component (as done by this PR)

I think that's a better option than assuming that those config options are common defaults. Maybe a Python/bash script can take ra_cfg dir and output a consolidated config file, which is then included in empty components config files.

Ultimately, I would like users to be able to define their own custom boards without using e2studio at all.

@dpgeorge san, Thank you for your proposal. It might be not easy but I also think so especially when the device is already supported by MicroPython.
I have confirmed that building of this PR was successful for all EK & CLICKER and peripheral tests were passed as same as the previous result. If this PR would be merged first, then I can try to update #11680 next.

I think that's a better option than assuming that those config options are common defaults

Most of the options here are just setting PARAM_CHECKING_ENABLE variables. And the other main one is enabling code flash programming. These settings should be defined by the port rather than each board. Just like we try to unify ports, we should try to unify boards as much as possible, or else it gets too complicated.

If in the future a board needs to customise these settings then we can add hooks to #include a single board-config file. But for now I think it's good to try and simplify things where possible.

I have confirmed that building of this PR was successful for all EK & CLICKER and peripheral tests were passed as same as the previous result.

Thank you @TakeoTakahashi2020 -san for testing.

Most of the options here are just setting PARAM_CHECKING_ENABLE variables

It's fine I have no strong opinions about this, however I think this PR should wait and the other PRs should be merged first, mainly because we have no control over how long it will take the other contributors to rebase their work, it could be days or weeks, and their PRs have been blocking our work, on the other hand rebasing this on their PRs should be trivial (the other PR adds one or two new boards).

however I think this PR should wait and the other PRs should be merged first, mainly because we have no control over how long it will take the other contributors to rebase their work,

I understand. Although it is possible for me to update those PRs myself.