> -----Original Message-----
> From: Laszlo Ersek [mailto:[email protected]]
> Sent: 13 January 2015 10:23
> To: [email protected]
> Subject: [edk2] [PATCH v2 1/3] OvmfPkg: QemuBootOrderLib: expose QEMU's
> "-boot menu=on[, splash-time=N]"
>
> The QEMU command line option
>
> -boot menu=on
>
> is meant to have the guest firmware wait for a firmware-specific
> interval
> for the user to enter the boot menu. During the wait, the user can opt
> to
> enter the boot menu, or interrupt the wait and proceed to booting at
> once.
> If the wait interval elapses, the firmware should boot as it normally
> would.
>
> The QEMU command line option
>
> -boot menu=on,splash-time=N
>
> means the same, except the firmware should wait for cca. N milliseconds
> instead of a firmware-specific interval.
>
> We can approximate this behavior quite well for edk2's virtual
> platforms
> because the Intel BDS front page already supports a progress bar, with
> semantics similar to the above. Let's distill the fw_cfg bits
> underlying
> "-boot menu=on,splash-time=N" for the BDS policies, in the form of a
> timeout value they can pass to Intel's PlatformBdsEnterFrontPage().
>
> If the boot menu is not requested, we return
> "gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut",
> which
> is what the virtual platforms use right now.
>
> If the boot menu is requested without specifying the timeout, we return
> the same PCD, unless it would cause us to skip the boot menu at once.
> In
> the latter case, we return 3 seconds (as an approximation of the 2500
> ms
> SeaBIOS default.)
>
> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170507
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <[email protected]>
> ---
>
> Notes:
> v2:
> - distinguish the possible cases in more detail in the commit
> message
> and in code comments [Jordan]
> - refine logic for "-boot menu=on" (no splash-time=N) [Jordan]
> - rewrite GetFrontPageTimeoutFromQemu() to simplify nesting of
> "if"s
>
> OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf | 3 +++
> OvmfPkg/Include/Library/QemuBootOrderLib.h | 12
> ++++++++++++
> OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c | 50
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 65 insertions(+)
>
> diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> index 6289e6a..e7be0f3 100644
> --- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> +++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> @@ -57,3 +57,6 @@
> [FeaturePcd]
> gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation
> gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderMmioTranslation
> +
> +[Pcd]
> + gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut
> diff --git a/OvmfPkg/Include/Library/QemuBootOrderLib.h
> b/OvmfPkg/Include/Library/QemuBootOrderLib.h
> index 12cda6a..80d02c8 100644
> --- a/OvmfPkg/Include/Library/QemuBootOrderLib.h
> +++ b/OvmfPkg/Include/Library/QemuBootOrderLib.h
> @@ -54,4 +54,16 @@ SetBootOrderFromQemu (
> IN CONST LIST_ENTRY *BootOptionList
> );
>
> +
> +/**
> + Calculate the number of seconds we should be showing the FrontPage
> progress
> + bar for.
> +
> + @return The TimeoutDefault argument for
> PlatformBdsEnterFrontPage().
> +**/
> +UINT16
> +GetFrontPageTimeoutFromQemu (
> + VOID
> + );
> +
> #endif
> diff --git a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
> b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
> index bc2fb56..e63ad26 100644
> --- a/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
> +++ b/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c
> @@ -1571,3 +1571,53 @@ ErrorFreeFwCfg:
>
> return Status;
> }
> +
> +
> +/**
> + Calculate the number of seconds we should be showing the FrontPage
> progress
> + bar for.
> +
> + @return The TimeoutDefault argument for
> PlatformBdsEnterFrontPage().
> +**/
> +UINT16
> +GetFrontPageTimeoutFromQemu (
> + VOID
> + )
> +{
> + FIRMWARE_CONFIG_ITEM BootMenuWaitItem;
> + UINTN BootMenuWaitSize;
> +
> + QemuFwCfgSelectItem (QemuFwCfgItemBootMenu);
> + if (QemuFwCfgRead16 () == 0) {
> + //
> + // The user specified "-boot menu=off", or didn't specify "-boot
> + // menu=(on|off)" at all. Return the platform default.
> + //
> + return PcdGet16 (PcdPlatformBootTimeOut);
> + }
Should it not return 0?
You said this PcdPlatformBootTimeOut is set to 0 for qemu in an earlier
email.
As far as I can see there is no way to differ "-boot menu=off" or no "-boot
menu=off".
- "-boot menu=off" is clearly Timeout=0
- no "-boot menu=off" means default behaviour. And the current default
behaviour is Timeout=0 for qEmu.
Reading this code might be confusing if we do not know
PcdPlatformBootTimeOut is set to 0.
That's why I am suggesting to explicitly return 0.
Feel free to ignore my comment if I miss something. I do not want to block
this patch if my comment is not relevant.
> +
> + if (RETURN_ERROR (QemuFwCfgFindFile ("etc/boot-menu-wait",
> &BootMenuWaitItem,
> + &BootMenuWaitSize)) ||
> + BootMenuWaitSize != sizeof (UINT16)) {
> + //
> + // "-boot menu=on" was specified without "splash-time=N". In this
> case,
> + // return three seconds if the platform default would cause us to
> skip the
> + // front page, and return the platform default otherwise.
> + //
> + UINT16 Timeout;
> +
> + Timeout = PcdGet16 (PcdPlatformBootTimeOut);
> + if (Timeout == 0) {
> + Timeout = 3;
> + }
> + return Timeout;
> + }
> +
> + //
> + // "-boot menu=on,splash-time=N" was specified, where N is in units
> of
> + // milliseconds. The Intel BDS Front Page progress bar only supports
> whole
> + // seconds, round N up.
> + //
> + QemuFwCfgSelectItem (BootMenuWaitItem);
> + return (UINT16)((QemuFwCfgRead16 () + 999) / 1000);
> +}
> --
> 1.8.3.1
>
>
>
> -----------------------------------------------------------------------
> -------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in
> Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely
> compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
