Allow arbitrary SVD values to be set through ConfApp #77
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
os-d
commented
Dec 10, 2022
Codecov Report
@@ Coverage Diff @@
## main #77 +/- ##
=======================================
Coverage 50.10% 50.10%
=======================================
Files 16 16
Lines 6219 6219
=======================================
Hits 3116 3116
Misses 3103 3103
Flags with carried forward coverage won't be shown. Click here to find out more. Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
kuqin12
approved these changes
Dec 10, 2022
apop5
approved these changes
Dec 10, 2022
kuqin12
approved these changes
Dec 14, 2022
os-d
force-pushed
the
osde/arbitrary_svd
branch
from
c77b649
to
5d068b8
Compare
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
github-actions bot
pushed a commit
to kuqin12/mu_feature_config
that referenced
this pull request
Dec 15, 2022
## Description Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs `"Device.ConfigData.*"`. However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug). This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces. For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [x] Impacts functionality? - [ ] Impacts security? - [ ] Breaking change? - [x] Includes tests? - [ ] Includes documentation? ## How This Was Tested Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD. ## Integration Instructions N/A
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Currently, mu_feature_config is in a transition to an XML based backend. The current YAML based ConfApp expects SVDs with the IDs
"Device.ConfigData.*". However, the XML has no such restriction. In the case of the XML, we want to allow arbitrary SVD provided variables to be set, as this option is only provided in the manufacturing mode state (used often for bringup and debug).This change leaves the YAML processing in place until more XML pieces are set to remove the remaining YAML pieces.
For each item, place an "x" in between
[and]if true. Example:[x].(you can also check items in the GitHub UI)
How This Was Tested
Tested with unit tests and in QemuQ35 by booting to the ConfApp in manufacturing mode, applying an SVD with arbitrary variables, rebooting to the EFI shell, using dmpstore to dump the variables to a file, applying that file in Config Editor and seeing that the current variable state matches what was provided in the SVD.
Integration Instructions
N/A