From d3497f6eb80c885c7b8bbb2350803e72afc16653 Mon Sep 17 00:00:00 2001 From: kuqin12 <42554914+kuqin12@users.noreply.github.com> Date: Thu, 6 Jul 2023 16:34:38 -0700 Subject: [PATCH] Fixing document to reflect the current state (#213) # Preface Please ensure you have read the [contribution docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior to submitting the pull request. In particular, [pull request guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices). ## Description There has been a few movements since the last documentation update: 1. The policy producers are centralized to a common module. 2. Added a new tool to read the applied configuration through the host OS. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [ ] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [ ] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [x] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested This is just documentation updates. ## Integration Instructions N/A --- SetupDataPkg/Docs/Overview/Overview.md | 3 +++ .../PlatformIntegration/PlatformIntegrationSteps.md | 12 +++++++++--- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/SetupDataPkg/Docs/Overview/Overview.md b/SetupDataPkg/Docs/Overview/Overview.md index f11e7219..0f52ca71 100644 --- a/SetupDataPkg/Docs/Overview/Overview.md +++ b/SetupDataPkg/Docs/Overview/Overview.md @@ -117,6 +117,9 @@ file, binary, or SVD. [Profiles doc](../Profiles/Overview.md). - The variable list binary, saved in .vl format, can be applied to a running system via dmpstore in the EFI shell, or via [WriteConfVarListToUefiVars.py](../../Tools/WriteConfVarListToUefiVars.py). +- Vice versa, variables applied to target system can be fetch through ConfApp's dump configuration option in UEFI, saved +to a file system in the EFI shell via dmpstore, or by [ReadUefiVarsToConfVarList.py](../../Tools/ReadUefiVarsToConfVarList.py) +in the OS. - The SVD can be applied to a running system via USB/serial via mu_feature_config's Conf App. - Changes to the XML itself will result in a change to the default configuration options of a platform. diff --git a/SetupDataPkg/Docs/PlatformIntegration/PlatformIntegrationSteps.md b/SetupDataPkg/Docs/PlatformIntegration/PlatformIntegrationSteps.md index 060449e3..4ff11c9e 100644 --- a/SetupDataPkg/Docs/PlatformIntegration/PlatformIntegrationSteps.md +++ b/SetupDataPkg/Docs/PlatformIntegration/PlatformIntegrationSteps.md @@ -66,9 +66,8 @@ configure the hardware accordingly. ## Platform Data Flow -The default silicon policy should be initialized by silicon modules during early PEI after Policy Service is available. -An example is provided in -[mu_tiano_platforms](https://github.com/microsoft/mu_tiano_platforms/blob/HEAD/Platforms/QemuQ35Pkg/PolicyDataGfx/PolicyDataGfx.c). +The default silicon policy can be initialized by silicon modules during early PEI after Policy Service is available, and +then updated by a phase-2 module to apply the changes from configuration data to silicon policy. The OemConfigPolicyCreator should take the autogenerated data provided by PlatformConfigDataLib (via the `gKnobData` extern structure) and publish the config policy. This module can perform any filtering required by the OEM/platform, @@ -82,6 +81,13 @@ Following these two operations, the n number of Config Policy to Silicon Policy policy and override the relevant silicon policies. An example is provided in [mu_tiano_platforms](https://github.com/microsoft/mu_tiano_platforms/blob/HEAD/Platforms/QemuQ35Pkg/ConfigKnobs/ConfigKnobs.c). +Note that, for demonstration simplicity and data overhead reduction, the provided example above directly intialized the +silicon policy and update the value using data from configuration autogen headers. In real world, this same model could +also be considered as long as this model would not cause dependency intervention. More often though, existing silicon modules +from major silicon vendors might already have their data pipelines, such as setup variables, structured PCDs. In those cases, +platforms can consider updating the data that resides in the existing pipelines instead of introducing major silicon module +overhaul. + During the rest of boot process, the silicon drivers will consume the updated silicon policies to configure hardware components or adjust firmware configuration. An example is provided in [mu_tiano_platforms](https://github.com/microsoft/mu_tiano_platforms/blob/HEAD/Platforms/QemuQ35Pkg/QemuVideoDxe/Driver.c).