Try to read key strike even when the TimeOuts value is zero, this will avoid BDS not get user input when TimeOuts value set to zero.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>




git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16304 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: BDS: remove dead call to PlatformBdsEnterFrontPage()

This call has been dead since the conception of OvmfPkg (git commit
49ba9447 / SVN r8398), and only confuses readers -- let's remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16305 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: BDS: drop useless return statement

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16306 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: BDS: don't overwrite the BDS Front Page timeout

The PlatformBdsEnterFrontPage() function's first parameter,
"TimeoutDefault", determines the behavior of the setup utility:

- If (TimeoutDefault == 0), then the usual boot order is to be acted upon
  immediately.

- If (TimeoutDefault == 0xFFFF), then the setup utility is entered
  unconditionally.

- If (0 < TimeoutDefault && TimeoutDefault < 0xFFFF), then the
  PlatformBdsEnterFrontPage() function displays a progress bar, waiting
  for TimeoutDefault seconds. If the user presses a key, then the setup
  utility is entered, otherwise the normal boot option processing takes
  place.

The TimeoutDefault parameter is supposed to be set from

  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut

which has the following (matching) documentation in
"IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec":

  The number of seconds that the firmware will wait before initiating the
  original default boot selection.
  A value of 0 indicates that the default boot selection is to be
  initiated immediately on boot.
  The value of 0xFFFF then firmware will wait for user input before
  booting.

OVMF does this actually -- see the Timeout variable in
PlatformBdsPolicyBehavior() -- but right before calling
PlatformBdsEnterFrontPage(), OVMF hardwires TimeoutDefault to 0xFFFF.

This has been acceptable until now, because OVMF implements its own "wait
for keypress at the splash screen" logic in PlatformBdsPolicyBehavior(),
completely avoiding the progress bar mentioned above. OVMF only calls
PlatformBdsEnterFrontPage() when the user presses a key during its own
"splash screen wait", and *then* it indeed makes sense to enter the setup
utility unconditionally.

However, even that way, the

  Timeout = 0xffff;

assignment is superfluous, because 0xFFFF is already the default value of
PcdPlatformBootTimeOut in "IntelFrameworkModulePkg.dec", and OvmfPkg
doesn't override it in its DSC files.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16307 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: BDS: optimize second argument in PlatformBdsEnterFrontPage() call

The second parameter of said function is "ConnectAllHappened", and if set
to TRUE, the function sets "gConnectAllHappened" to TRUE.

This global variable in turn controls whether Intel BDS code *itself*
calls BdsLibConnectAllDriversToAllControllers() in various places -- if
the indicator is TRUE, then the "connect all" is assumed to have been
performed, and Intel BDS doesn't do it itself.

OVMF should pass TRUE as "ConnectAllHappened", because a few lines before
our call to PlatformBdsEnterFrontPage(), we already connect everything
with BdsLibConnectAll(), which includes the effects of
BdsLibConnectAllDriversToAllControllers():

PlatformBdsPolicyBehavior()                   [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
  BdsLibConnectAll()                          [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConnect.c]
    BdsLibConnectAllDriversToAllControllers()
  PlatformBdsEnterFrontPage()                 [IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16308 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: BDS: drop superfluous "connect first boot option" logic

This is again obviated by our earlier BdsLibConnectAll() call.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16309 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: BDS: drop custom boot timeout, revert to IntelFrameworkModulePkg's

PlatformBdsEnterFrontPage() already implements a keypress wait (for
entering the setup utility at boot) with a nice progress bar, only OVMF
has not been using it.

Removing our custom code and utilizing PlatformBdsEnterFrontPage()'s
builtin wait has the following benefits:

- It simplifies OVMF's BDS code.

- Because now we call PlatformBdsEnterFrontPage() unconditionally, it
  actually has a chance to look at the EFI_OS_INDICATIONS_BOOT_TO_FW_UI
  bit of the "OsIndications" variable, improving compliance with the UEFI
  specification. References:
  - https://bugzilla.redhat.com/show_bug.cgi?id=1153927
  - http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10487

- The progress bar looks nice. (And it keeps the earlier behavior intact,
  when the user presses a key on the TianoCore splash screen.)

  In any case, we set the timeout to 0 (which doesn't show the progress
  bar and proceeds to the boot options immediately) in order to keep the
  boot time down.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16310 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: set video resolution of text setup to 640x480

On a physical screen such a low graphics resolution would lead to huge
glyphs (the text resolution is 80x25, centered, with 8x19 pixel glyphs).
But in a virtual machine it just saves screen real estate on the client,
by removing the black bands.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16311 6f19259b-4bc3-4df7-8a09-765794883524
Add safe string function to base lib.

Contributed-under: TianoCore Contribution Agreement 1.0

signed off by: Yao, Jiewen <jiewen.yao@intel.com>
reviewed by: Ni, Ruiyu <ruiyu.ni@intel.com>
reviewed by: Long, Qin <qin.long@intel.com>
reviewed by: Kinney, Michael D <michael.d.kinney@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16312 6f19259b-4bc3-4df7-8a09-765794883524
AppPkg: Add the Lua interpreter and library.
StdLib: Add support and include files for Lua.

The sources for the Lua standalone interpreter, as well as its library, have been added to AppPkg/Applications/Lua.  The Lua library, LuaLib, can be used to embed Lua into new applications.

The Lua header files, needed for both building and embedding, are located in StdLib/Include/Lua.  The original versions of these header files, in the source directory, have been converted into stubs that reference the include files in StdLib.  This allows us to keep the Lua sources as close to the distributed version as possible.

Documentation is contained in the Lua/doc directory.  Further information is available at www.lua.org.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed Off by:  Bruce Maynard <Bruce.Maynard@Emulex.Com>
Reviewed by:    Daryl McDaniel <daryl.mcdaniel@intel.com>


git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16313 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg XenBusDxe: Convert Ia32/hypercall.asm to NASM

The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/hypercall.asm to Ia32/hypercall.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16314 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg XenBusDxe: Convert Ia32/InterlockedCompareExchange16.asm to NASM

The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/InterlockedCompareExchange16.asm to Ia32/InterlockedCompareExchange16.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16315 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg XenBusDxe: Convert Ia32/TestAndClearBit.asm to NASM

The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/TestAndClearBit.asm to Ia32/TestAndClearBit.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16316 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg XenBusDxe: Convert X64/hypercall.asm to NASM

The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/hypercall.asm to X64/hypercall.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16317 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg XenBusDxe: Convert X64/InterlockedCompareExchange16.asm to NASM

The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/InterlockedCompareExchange16.asm to X64/InterlockedCompareExchange16.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16318 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg XenBusDxe: Convert X64/TestAndClearBit.asm to NASM

The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/TestAndClearBit.asm to X64/TestAndClearBit.nasm

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16319 6f19259b-4bc3-4df7-8a09-765794883524
   Fix execution status & DEBUG message level mismatch. EFI_D_ERROR is used only when failure/case can’t be resolved by code.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Dong Guo <guo.dong@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16320 6f19259b-4bc3-4df7-8a09-765794883524
MdeModulePkg/AtaAtapiPassThru: don't write read-only AHCI MMIO register

Per AHCI 1.1 spec, AE bit of GHC register is read-only if CAP.SAM is 1

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16321 6f19259b-4bc3-4df7-8a09-765794883524
Fix a bug in DebugAgent that hang happens when the ACK for GO is lost.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16322 6f19259b-4bc3-4df7-8a09-765794883524
ShellPkg: Fixed variable set but never used

This warning/error raised by ARM toolchain prevents to build
the EFI Shell for ARM 32-bit with this toolchain.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>



git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16323 6f19259b-4bc3-4df7-8a09-765794883524