dh command gets driver name and wrongly prints it as 'Child [handle]'.
It should print it as 'Driver Name [handle]'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah <tapandshah@hpe.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Current code will allocate pool to hold the null char for name buffer
when PrevName==NULL, but the NameSize is still 0.
For this case, GetNextVariableName will return EFI_INVALID_PARAMETER
to follow UEFI 2.7 spec.
UEFI 2.7 spec:
The VariableNameSize must not be smaller the size of the variable
name string passed to GetNextVariableName() on input in the
VariableName buffer.
EFI_INVALID_PARAMETER
Null-terminator is not found in the first VariableNameSize bytes of
the input VariableName buffer.
This patch is to make NameSize to be consistent with name buffer.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Found few instances where IPv4 and DHCPv4 spelled incorrectly
as IP4 and DHCP4 respectively.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah <tapandshah@hpe.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
STR_GEN_ERR_NOT_FOUND is added and currently is only
used by alias command. This string template can be used
by other commands as well.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
Couple of instances had IP4 mentioned, instead of IPv4.
Changing all to IPv4 to maintain consistency.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
The original code expects the Unicode stream from pipe doesn't
contains the Unicode BOM.
But that's not true.
Commit [9ed21946c7] changes
CreateFileInterfaceMem() to add the BOM for Unicode stream.
When parse pipe support was firstly added, a private implementation
ParseReturnStdInLine() was created to specially handle
the Unicode stream without BOM. Since now the Unicode steam contains
BOM, the private implementation can be removed and
ShellFileHandleReturnLine() can be used directly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Tapan Shah <tapandshah@hpe.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=566
In function InternalShellPrintWorker(), if the string in variable
'mPostReplaceFormat2' starts with character L'%', the following
expression:
*(ResumeLocation-1) == L'^' at line 2831
will read an undefined value before the starting of string
'mPostReplaceFormat2'.
This commit adds additional logic to avoid reading undefined content.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The patch dumps memory map information for all memory types.
But to follow the SFO format of "memmap" defined in Shell 2.2 spec,
the patch doesn't dump the memory map information for OEM/OS
memory types. But it does include the OEM/OS memory in the total
size in SFO format.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The patch changes Buffer to Descriptors, changes
(UINT8 *Walker) to (EFI_MEMORY_DESCRIPTOR *Walker).
The change makes lots of type conversion unnecessary.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
This patch adds support for showing the file name associated with a
LoadedImageProtocol file path. This is a behavior that was present in
the old shell but has been lost in the new shell.
For example, using 'dh -v' in the old shell:
Handle D3 (3A552218)
Image (3A54C918) File:MicrocodeUpdate
ParentHandle..: 3A666398
vs. the new shell:
D3: 3A552218
LoadedImage
Revision......: 0x00001000
ParentHandle..: 3A666398
Here's what the output of 'dh -v' looks like after this patch:
D3: 3A552218
LoadedImage
Name..........: MicrocodeUpdate
Revision......: 0x00001000
ParentHandle..: 3A666398
This seems like useful information for the shell to display.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
This patch changes the order of operations to make sure we can open the
LoadedImageProtocol before getting the format string. This should not
affect functionality, and makes the next patch easier to review.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
This patch adds support for displaying a text representation of the file
path associated with a LoadedImageProtocol. This is a behavior that was
present in the old shell but has been lost in the new shell.
For example, using 'dh -v' in the old shell:
FilePath......: FvFile(F3331DE6-4A55-44E4-B767-7453F7A1A021)
FilePath......: \EFI\BOOT\BOOTX64.EFI
vs. the new shell:
FilePath......: 3A539018
FilePath......: 3A728718
This seems like useful information for the shell to display.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
ASCII characters {|}~ should be printed by DumpHex. The problem is that
if you have a string like
{xizzy}~{foo|bar}~{quux}
in the dumped data, it will not appear as such in the *-delimited ASCII
column to the right, but as
.xizzy...foo.bar...quux.
which is less than ideal.
Most of the commit message was inspired by/shamelessly stolen from
Laszlo's example:
https://lists.01.org/pipermail/edk2-devel/2017-April/010266.html
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The SMBIOS Type 0 BIOS segment field is currently displayed in decimal.
Since this field is likely to have a value like 0xE800 or 0xF000, using
hexadecimal seems like a better choice.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
It is to align to the original behavior before "-ec" option was
added.
The patch also refines the code to make it more readable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jim Dailey <Jim.Dailey@dell.com>
Shell 2.2 spec defines =0x/=0X, =H/=h, =S, =L and =P for
hex number, hex array, ascii string, unicode string and
device path data.
The patch adds such support.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
The format specifier for the LoadOptions field of the LoadedImage protocol
is "%s". However, the data in LoadOptions is often generic binary data. A
format specifier of "%x" is more appropriate for this field.
Using "dh -v" with format specifier "%s" on BIOS images based on EDK II
source before commit 891d844 can cause a crash.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The patch doesn't impact the functionality.
The rename also fixes the inconsistency between function
header comments and function parameters.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@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: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@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: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Current UefiDpLib implementation depends on TimerLib,
as different platforms may implement and use their
own TimerLib, it makes the dp command needs to be built
by platform. The TimerLib dependency can be removed by
using performance property configuration table to make
UefiDpLib to be generic.
Cc: Andrew Fish <afish@apple.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Cinnamon Shia <cinnamon.shia@hpe.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Type 0: Update "EDD Enhanced Disk Driver)..." to
"EDD (Enhanced Disk Driver)..." for
STR_SMBIOSVIEW_PRINTINFO_EDD_ENHANCED_DRIVER
Type 3: Use L" Laptop" instead of L" LapTop" in
SystemEnclosureTypeTable to match SMBIOS spec.
Type 10: The BIT7 of Device Type is representing the
status of device whether it is enabled or disabled.
But current code is not considering the BIT7 and will
print "Undefined Value" for enabled device. Type 41
has same definition of Device Type, the code is
correct and will be applied to Type 10 by this patch.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Current PrintBitsInfo() will always print an additional trailing
" | " for the bit flags, for example,
Base Board Feature Flags: Hosting board | Replaceable |
Th patch is to eliminate trailing " | " in PrintBitsInfo(), then
the output will be like below
Base Board Feature Flags: Hosting board | Replaceable
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Before the "cd fs0:dir" fix, CD only prints destination directory
when the destination contains ":".
However, the "cd fs0:dir" fix changed CD to always print destination
directory.
This patch changes CD to never print destination directory.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Cc: Chris J Phillips <chrisp@hpe.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
The implementation was already there but through a private flag
"-_e". The patch removes "-_e" support and add "-ec" support.
Removing old "-_e" support makes the pci command more clean.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=354
The patch removes the local PCI definitions and uses the definitions
defined in MdePkg/Include/IndustryStandard folder.
There is no functionality impact.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jarben.carsey@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=340
The decoding of TPM Device (Type 43) has been added at
e9f0be021b.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
if we set a static IP using command
'ifconfig -s eth0 static 192.168.0.121 255.255.255.0 0.0.0.0'
The system says 'Failed to set address.' but using
'ifconfig -l', the static IP can be assigned successfully.
so we need to check the gateway validity before setting manual
address to keep the ifconfig -s command more consistent.
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Cc: Santhapur Naveen <naveens@amiindia.co.in>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=345
When I am adding SMBIOS spec 3.1.0 support, I found the decoding
of SMBIOS spec 3.0.0 for some definitions is missing.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Tapan Shah
Star Zeng
Ruiyu Ni
hegdenag
Jeff Westfahl
Hao Wu
Dandan Bi
Chen A Chen
Zhang Lubo