Apu2 uefi #1
Open
Apu2 uefi #1
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
mek-x
approved these changes
Jul 19, 2017
Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
…aths for ConIn/ConOut/ErrOut Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
Cc: Maurice Ma <[email protected]> Cc: Prince Agyeman <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Piotr Król <[email protected]>
Signed-off-by: Piotr Król <[email protected]>
pietrushnic
pushed a commit
that referenced
this pull request
Nov 18, 2017
The new algorithm converts the problem calculating optimal
MTRR settings (using least MTRR registers) to the problem finding
the shortest path in a graph.
The memory required in extreme but rare case can be up to 256KB,
so using local stack buffer is impossible considering current
DxeIpl only allocates 128KB stack.
The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and
MtrrSetMemoryAttribute() to use the 4-page stack buffer for
calculation. The two APIs return BUFFER_TOO_SMALL when the buffer
is too small for calculation.
The patch adds a new API MtrrSetMemoryAttribute*s*InMtrrSettings() to
set multiple-range attributes in one function call.
Since every call to MtrrSetMemoryAttributeInMtrrSettings (without-s)
or MtrrSetMemoryAttribute() requires to calculate the MTRRs for the
whole physical memory, combining multiple calls in one API can
significantly reduce the calculation time.
In theory, if N times of call to without-s API costs N seconds,
the new API only costs 1 second.
The new API uses the buffer supplied from caller to calculate
MTRRs and returns BUFFER_TOO_SMALL when the buffer is too small for
calculation.
Test performed:
1. Random test
a. Generate random memory settings, use the new algorithm to
calculate the MTRRs.
b. Read back the MTRRs and check the memory settings match
the desired memory settings.
c. Repeat the above #1 and #2 100000 times.
2. OVMF 32PEI + 64DXE boot to shell.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <[email protected]>
Cc: Michael D Kinney <[email protected]>
Cc: Eric Dong <[email protected]>
Reviewed-by: Jiewen Yao <[email protected]>
BartekLew
pushed a commit
that referenced
this pull request
Feb 12, 2018
PerformancePkg contains following components: 1. TscTimerLib 2. Dp_App 3. Header files. #1 has already been deprecated. #2 can be removed because DpApp was added to ShellPkg. #3 Header files are not used by DpApp and MdeModulePkg/PerformanceLib instances. In summary, this package is no longer useful. All related platforms have been updated to remove the references. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <[email protected]> Cc: Jaben Carsey <[email protected]> Cc: Daryl McDaniel <[email protected]> Reviewed-by: Jaben Carsey <[email protected]>
pietrushnic
pushed a commit
that referenced
this pull request
Feb 14, 2018
v2: * Refine the commit log. There are two place to close the ISCSI ExitBootServiceEvent: #1.IScsiOnExitBootService(), which is the callback function of ExitBootServiceEvent. #2.IScsiCleanDriverData(), which will be invoked by ISCSI driver binding stop(). So, the ExitBootServiceEvent will be closed and freed when exit boot server is triggered. But it may be closed and freed again in ISCSI driver binding stop(), which will result in the issue recorded at https://bugzilla.tianocore.org/show_bug.cgi?id=742. This patch is to resolve the issue. Cc: Ye Ting <[email protected]> Cc: Fu Siyuan <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <[email protected]> Reviewed-by: Fu Siyuan <[email protected]>
pietrushnic
pushed a commit
that referenced
this pull request
Feb 14, 2018
v2: * Refine the commit log. There are two place to close the ISCSI ExitBootServiceEvent: #1.IScsiOnExitBootService(), which is the callback function of ExitBootServiceEvent. #2.IScsiCleanDriverData(), which will be invoked by ISCSI driver binding stop(). So, the ExitBootServiceEvent will be closed and freed when exit boot server is triggered. But it may be closed and freed again in ISCSI driver binding stop(), which will result in the issue recorded at https://bugzilla.tianocore.org/show_bug.cgi?id=742. This patch is to resolve the issue. Cc: Ye Ting <[email protected]> Cc: Fu Siyuan <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <[email protected]> Reviewed-by: Fu Siyuan <[email protected]>
pietrushnic
pushed a commit
that referenced
this pull request
Apr 4, 2018
v2: * Refine the commit log. There are two place to close the ISCSI ExitBootServiceEvent: #1.IScsiOnExitBootService(), which is the callback function of ExitBootServiceEvent. #2.IScsiCleanDriverData(), which will be invoked by ISCSI driver binding stop(). So, the ExitBootServiceEvent will be closed and freed when exit boot server is triggered. But it may be closed and freed again in ISCSI driver binding stop(), which will result in the issue recorded at https://bugzilla.tianocore.org/show_bug.cgi?id=742. This patch is to resolve the issue. Cc: Ye Ting <[email protected]> Cc: Fu Siyuan <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <[email protected]> Reviewed-by: Fu Siyuan <[email protected]> (cherry picked from commit d321598)
pietrushnic
pushed a commit
that referenced
this pull request
Apr 4, 2018
v2: * Refine the commit log. There are two place to close the ISCSI ExitBootServiceEvent: #1.IScsiOnExitBootService(), which is the callback function of ExitBootServiceEvent. #2.IScsiCleanDriverData(), which will be invoked by ISCSI driver binding stop(). So, the ExitBootServiceEvent will be closed and freed when exit boot server is triggered. But it may be closed and freed again in ISCSI driver binding stop(), which will result in the issue recorded at https://bugzilla.tianocore.org/show_bug.cgi?id=742. This patch is to resolve the issue. Cc: Ye Ting <[email protected]> Cc: Fu Siyuan <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <[email protected]> Reviewed-by: Fu Siyuan <[email protected]> (cherry picked from commit a37c60b)
pietrushnic
pushed a commit
that referenced
this pull request
Apr 13, 2020
MpInitLib sets X2ApicEnable in two places. 1. CollectProcessorCount() This function is called when MpInitLibInitialize() hasn't been called before. It sets X2ApicEnable and later in the same function it configures all CPUs to operate in X2 APIC mode. 2. MpInitLibInitialize() The X2ApicEnable setting happens when this function is called in second time. But after that setting, no code consumes that flag. With the above analysis and with the purpose of simplifying the code, the X2ApicEnable in #1 is changed to local variable and the #2 can be changed to remove the setting of X2ApicEnable. Signed-off-by: Ray Ni <[email protected]> Reviewed-by: Eric Dong <[email protected]> Reviewed-by: Laszlo Ersek <[email protected]>
Sakoram
pushed a commit
that referenced
this pull request
Oct 5, 2020
The unit test app supports running in 3 mode:
1. MtrrLibUnitTest generate-random-numbers
<path to MtrrLib/UnitTest/RandomNumber.c> <random-number count>
It generates random numbers and writes to RandomNumber.c.
2. MtrrLibUnitTest [<iterations>]
It tests MtrrLib APIs using configurations generated from static
numbers generated by mode #1.
This is the default execution mode running in CI environment.
3. MtrrLibUnitTest <iterations> random
It tests MtrrLib APIs using configurations generated from random
numbers.
This is what developers can use to test MtrrLib for regressions.
Signed-off-by: Ray Ni <[email protected]>
Cc: Michael D Kinney <[email protected]>
Cc: Eric Dong <[email protected]>
Cc: Laszlo Ersek <[email protected]>
Cc: Ming Shao <[email protected]>
Cc: Sean Brogan <[email protected]>
Cc: Bret Barkelew <[email protected]>
Cc: Jiewen Yao <[email protected]>
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.
This only for review purposes I do not plan to merge those changes in this repo.