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: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@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: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@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: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@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: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@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: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@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: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@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: svn://svn.code.sf.net/p/edk2/code/trunk/edk2/OvmfPkg@16311 6f19259b-4bc3-4df7-8a09-765794883524