REF:https://bugzilla.tianocore.org/show_bug.cgi?id=620
Adds the support for SD/eMMC device path to show as a boot option.
The CID register content (returned from DiskInfo->Inquiry) seems do not
provide very useful/readable 'OEM/Application ID' and 'Product name'
field.
For SD devices, the OID is a 2-character ASCII string and the Product name
is a 5-character ASCII string.
For eMMC devices, the OID is an 8-bit binary number and the Product name
is a 6-character ASCII string.
These strings are relatively short and do not provide a very readable
description. Hence, this commit uses general 'SD (eMMC) Device' for the
boot option description.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
This patch is to update UEFI Boot manager to support DNS device path
for HTTP(S) network boot.
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
KeyOption points to a buffer holding the content of Key####.
So its size is smaller than EFI_BOOT_MANAGER_KEY_OPTION.
Old code to assign value to KeyOption->OptionNumber modifies
the memory outside of the KeyOption buffer.
The patch fixes this bug.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
When a load option points to a physical UsbIo controller, whose
device path contains UsbClass or UsbWwid node, old logic
unconditionally treats it as a short-form device path and expands
it. But the expanding gets the exactly same device path, and the
device path is passed to BmGetNextLoadOptionDevicePath() which
then passes this device path to BmExpandUsbDevicePath() again.
This causes a infinite recursion.
The patch avoids the USB short-form expanding when the device path
points to a physical UsbIo controller.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Old implementation only finds first matched full device path for a
given short-form device path.
The patch adds internal function BmGetNextLoadOptionBuffer() to finds
all matched full device path for a given short-form device path.
There are 6 kinds of device paths. Some of them match to multiple
load options, some of them don't.
1. Media device path:
Returns multiple load options: The media device path may point
to a physical BlockIo which contains multiple logic partitions,
each logic partitions contains \EFI\BOOT\BOOT${ARCH}.EFI.
2. Short-form hard-drive device path:
Returns one load option because the partition signature is unique.
3. Short-form file-path device path:
Returns multiple load options: There are multiple SimpleFileSystem
instances and each contains the same file.
4. Short-form URI device path:
Returns multiple load options: There are multiple LoadFile
instances and each can boot.
5. Short-form USB device path:
Returns multiple load options: There are multiple UsbIo instances
and each contains the boot-able file.
6. FV device path, device path pointing to SimpleFileSystem, device
path pointing to LoadFile
Returns one load option.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.
An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);
Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.
The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;
2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;
3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);
4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}
For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
For pointer subtraction, the result is of type "ptrdiff_t". According to
the C11 standard (Committee Draft - April 12, 2011):
"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is
undefined."
In our codes, there are cases that the pointer subtraction is not
performed by pointers to elements of the same array object. This might
lead to potential issues, since the behavior is undefined according to C11
standard.
Also, since the size of type "ptrdiff_t" is implementation-defined. Some
static code checkers may warn that the pointer subtraction might underflow
first and then being cast to a bigger size. For example:
UINT8 *Ptr1, *Ptr2;
UINTN PtrDiff;
...
PtrDiff = (UINTN) (Ptr1 - Ptr2);
The commit will refine the pointer subtraction expressions by casting each
pointer to UINTN first and then perform the subtraction:
PtrDiff = (UINTN) Ptr1 - (UINTN) Ptr2;
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
BmExpandMediaDevicePath contains a bug that it uses the
uninitialized Handle.
Since the function is called when the Handle supports BlockIo
or SimpleFileSystem, when there is no SimpleFileSystem installed
on the Handle, BlockIo is *guaranteed* to be installed on the Handle.
The fix initializes the Handle by locating the BlockIo protocol
from the device path.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Sunny Wang <sunnywang@hpe.com>
The type of return value for function EfiBootManagerFindLoadOption() is
INTN. When checking its return value, it is unnecessary to type cast -1 to
type UINTN.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Sunny Wang <sunnywang@hpe.com>
When firmware boots to UiApp, the memory type information settings
are saved to NV storage and the settings in HOB are changed as well.
Because UiApp is an APPLICATION type of boot option, system doesn't
reset when settings change.
But when user selects OS to boot in UiApp, because the settings in HOB
was updated when booting to UiApp, the BDS doesn't think the settings
change, expected reset doesn't happen.
The patch fixes this issue to not update the settings in HOB.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Sunny Wang <sunnywang@hpe.com>
The API dispatches the deferred images that are returned from all
DeferredImageLoad instances.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
Reviewed-by: Sunny Wang <sunnywang@hpe.com>
BootManagerMenu boot option is handled by EfiBootManagerGetBootManagerMenu.
Don't need to handle it again when parse LoadFile protocol.
In V2, use "BootManagerMenu" instead of "BootMenuApp".
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Sunny Wang <sunnywang@hpe.com>
Rename local function name BootMenuApp to BootManagerMenu to align to
other public function name.
In V2, use "BootManagerMenu" instead of "BootMenuApp".
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Sunny Wang <sunnywang@hpe.com>
Instead of comparing a GUID with gZeroGuid via the CompareGuid API, the
commit uses the IsZeroGuid API to check if the given GUID is a zero GUID.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@Intel.com>
Update boot description to support LoadFile protocol based on FV file.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
New LoadFileOnFv2 driver will install LoadFile protocol based on FV file.
Update UefiBootManagerLib to find BootMenuApp with LoadFile protocol.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>