Handling the continue cases for BDS retry #367
Merged
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
apop5
approved these changes
Apr 20, 2023
makubacki
reviewed
Apr 20, 2023
makubacki
reviewed
Apr 20, 2023
|
I made some adjustments to the PR description to help clarify the issue. Please correct if you'd like to change anything. |
makubacki
approved these changes
Apr 20, 2023
cfernald
approved these changes
Apr 20, 2023
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com> Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
ProjectMuBot
referenced
this pull request
in microsoft/mu_tiano_platforms
Apr 26, 2023
Introduces 4 new commits in [MU_BASECORE](https://github.com/microsoft/mu_basecore.git). <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/microsoft/mu_basecore/commit/a5bf121fa89e0e65c0edfafac6eee88777214eda">a5bf12</a> Additional CodeQL Fixes (<a href="https://github.com/microsoft/mu_basecore/pull/358">#358</a>)</li> <li><a href="https://github.com/microsoft/mu_basecore/commit/85cfafd87dbe6724e4d8c5419a249a71c51d754e">85cfaf</a> Handling the continue cases for BDS retry (<a href="https://github.com/microsoft/mu_basecore/pull/367">#367</a>)</li> <li><a href="https://github.com/microsoft/mu_basecore/commit/d812d01ab5783c2119e1a47424b327e66b7dd442">d812d0</a> Removing BASECORE overrides for unit test include file (<a href="https://github.com/microsoft/mu_basecore/pull/370">#370</a>)</li> <li><a href="https://github.com/microsoft/mu_basecore/commit/6bc15eef159bb4605e8a9419bb1fa60a1ae451a5">6bc15e</a> Repo File Sync: Update to Mu DevOps 2.4.0 (<a href="https://github.com/microsoft/mu_basecore/pull/366">#366</a>)</li> </ul> </details> Signed-off-by: Project Mu Bot <mubot@microsoft.com>
makubacki
referenced
this pull request
in microsoft/mu_tiano_platforms
Apr 26, 2023
Bumps MU_BASECORE from `2022080001.2.1` to `2022080001.2.2` Introduces 4 new commits in [MU_BASECORE](https://github.com/microsoft/mu_basecore.git). <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/microsoft/mu_basecore/commit/a5bf121fa89e0e65c0edfafac6eee88777214eda">a5bf12</a> Additional CodeQL Fixes (<a href="https://github.com/microsoft/mu_basecore/pull/358">#358</a>)</li> <li><a href="https://github.com/microsoft/mu_basecore/commit/85cfafd87dbe6724e4d8c5419a249a71c51d754e">85cfaf</a> Handling the continue cases for BDS retry (<a href="https://github.com/microsoft/mu_basecore/pull/367">#367</a>)</li> <li><a href="https://github.com/microsoft/mu_basecore/commit/d812d01ab5783c2119e1a47424b327e66b7dd442">d812d0</a> Removing BASECORE overrides for unit test include file (<a href="https://github.com/microsoft/mu_basecore/pull/370">#370</a>)</li> <li><a href="https://github.com/microsoft/mu_basecore/commit/6bc15eef159bb4605e8a9419bb1fa60a1ae451a5">6bc15e</a> Repo File Sync: Update to Mu DevOps 2.4.0 (<a href="https://github.com/microsoft/mu_basecore/pull/366">#366</a>)</li> </ul> </details> Signed-off-by: Project Mu Bot <mubot@microsoft.com>
TaylorBeebe
pushed a commit
to TaylorBeebe/mu_basecore
that referenced
this pull request
Apr 27, 2023
## Description The original change (microsoft#347) will not handle the use case when the last entry in the BootOptions being inactive, and the loop will break in one of the "continue" cases. This change will ensure that continue statements redirect control to logic for handling infinite retry attempt support. Fixes microsoft#368. - [x] 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, ... - [ ] 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 tested on FVP based virtual platform. ## Integration Instructions N/A --------- Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Apr 28, 2023
## Description The original change (#347) will not handle the use case when the last entry in the BootOptions being inactive, and the loop will break in one of the "continue" cases. This change will ensure that continue statements redirect control to logic for handling infinite retry attempt support. Fixes #368. - [x] 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, ... - [ ] 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 tested on FVP based virtual platform. ## Integration Instructions N/A --------- Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
May 3, 2023
## Description The original change (#347) will not handle the use case when the last entry in the BootOptions being inactive, and the loop will break in one of the "continue" cases. This change will ensure that continue statements redirect control to logic for handling infinite retry attempt support. Fixes #368. - [x] 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, ... - [ ] 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 tested on FVP based virtual platform. ## Integration Instructions N/A --------- Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
May 4, 2023
## Description The original change (#347) will not handle the use case when the last entry in the BootOptions being inactive, and the loop will break in one of the "continue" cases. This change will ensure that continue statements redirect control to logic for handling infinite retry attempt support. Fixes #368. - [x] 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, ... - [ ] 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 tested on FVP based virtual platform. ## Integration Instructions N/A --------- Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
May 4, 2023
## Description The original change (#347) will not handle the use case when the last entry in the BootOptions being inactive, and the loop will break in one of the "continue" cases. This change will ensure that continue statements redirect control to logic for handling infinite retry attempt support. Fixes #368. - [x] 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, ... - [ ] 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 tested on FVP based virtual platform. ## Integration Instructions N/A --------- Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com> Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
May 5, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
May 5, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
May 9, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
May 9, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Oct 17, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Oct 17, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Oct 18, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Oct 18, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Oct 19, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Oct 20, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Oct 23, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Dec 16, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Dec 18, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
kenlautner
pushed a commit
that referenced
this pull request
Dec 18, 2023
This is a draft of infinite boot retries based on a newly created PCD.
When true, the system will never stop retrying the boot options.
PCD default is FALSE to match existing functionality.
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?
- **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, ...
- [ ] 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, ...
n/a
Handling the continue cases for BDS retry (#367)
The original change (#347)
will not handle the use case when the last entry in the BootOptions
being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to
logic for handling infinite retry attempt support.
Fixes #368.
- [x] 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, ...
- [ ] 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, ...
This is tested on FVP based virtual platform.
N/A
---------
Signed-off-by: kuqin12 <42554914+kuqin12@users.noreply.github.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
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
The original change (#347) will not handle the use case when the last entry in the BootOptions being inactive, and the loop will break in one of the "continue" cases.
This change will ensure that continue statements redirect control to logic for handling infinite retry attempt support.
Fixes #368.
flow, or firmware?
validation improvement, ...
in build or boot behavior?
a function in a new library class in a pre-existing module, ...
outside direct code modifications (and comments)?
on an a separate Web page, ...
How This Was Tested
This is tested on FVP based virtual platform.
Integration Instructions
N/A