Dynamic Dahsharo-supported platforms database

[DaniilKl]

The problem you're addressing (if any)

Huge board_config function. Storing platform data inside DTS code.

Describe the solution you'd like

If we require internet access to download Dasharo binaries - why not to use it to fetch information about supported platforms and their configuration? It could be a database or even a simple .json file.

Where is the value to a user, and who might that user be?

Pros:

• More scalable;
• Easier to maintain;
• No need to make a DTS release (or a full DTS release) just to add support to some platform.

Describe alternatives you've considered

No response

Additional context

No response

[DaniilKl]

@m-iwanicki, pointed out that migrating hardware configuration from dasharo/dts-scripts repository, where its version adheres to a specific commit, and "live its own life" in the database. It means it can be deleted, modified, corrupted, etc.. Еhe first thingы that comes to mind: strict policies, versioning and a separate version for development.

[mkopec]

I think some of these variables :

          NEED_SMBIOS_MIGRATION="false"
          NEED_SMMSTORE_MIGRATION="true"
          NEED_BOOTSPLASH_MIGRATION="false"

as well as info on which specific regions to update and which to preserve, are tied to specific firmware versions and could be separated out.

I would see it like this: every platform has a manifest of updates containing a list of releases. Every release entry contains metadata like which regions changed, if the layout changed, what to preserve, what to update. Updater script takes the manifest and determines which regions to update (e.g. when updating from 1.0.0 to 1.2.0 skipping over 1.1.0, we have to take the logical OR of the regions that changed in 1.1.0 and in 1.2.0). Obviously if the IFD or FMAP layout changed in any of them ,we need to flash everything.

Eventually, we will also need to embed this data into capsule updates, to allow firmware to update itself correctly.