Changes include:
* Added missing \r\n line endings inside string literals
* Fixed inconsistent indentation in multi-line string entries
* Removed duplicated #language en-US directive
* Aligned string formatting to match the UNI specification
Updated files:
ShellPkg/DynamicCommand/HttpDynamicCommand/Http.uni
ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
The issues were identified during testing of the parser
https://github.com/xpahos/edk2-idea.
Signed-off-by: Alexander Gryanko <xpahos@gmail.com>
Memory Range Capsule is described in the UEFI spec 2.9
s8.5.3 Update Capsule with the following GUID:
{0DE9F0EC-88B6-428F-977A-258F1D0E5E72}
Support to print the EFI_MEMORY_RANGE_CAPSULE address in the EFI
Configuration table was added in commit: 42b0443599
("ShellPkg: UefiShellDebug1CommandsLib: Uefi Config Tables in Dmem.c")
but EFI_MEMORY_RANGE_CAPSULE type and GUID is not present in edk2.
Thus dmem always print a 0 value for this configuration table.
Remove support of EFI_MEMORY_RANGE_CAPSULE in dmem.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
The SAL System Table is unsupported and its support was
removed in commit:
f4c874c45d ("ShellPkg/UefiShellDebug1CommandsLib")
Remove remaining of SAL System Table handling.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
1. Do not use tab characters
2. No trailing white space in one line
3. All files must end with CRLF
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Neither the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL nor the EFI_CPU_IO2_PROTOCOL
impose any restrictions when it comes to the range of valid I/O
addresses. Even so, the 'mm' command in -IO mode refuses to perform
accesses to addresses >= 0xffff.
It is not up to 'mm' to impose this restriction, so remove it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Change "dmpstore" to show name of known variable vendor GUID.
The name is got from ShellProtocol.GetGuidName().
Cc: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Huajing Li <huajing.li@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 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>
The patch adds the "-sfo" support to "dmpstore" command.
When -l or -d is specified, -sfo is not supported.
When the variable specified by name and GUID cannot be found,
an error message is displayed; Otherwise, the SFO is displayed.
E.g.: "dmpstore -guid GuidThatDoesntExist -sfo" produces output
as:
ShellCommand,"dmpstore"
VariableInfo,"","GuidThatDoesntExist","","",""
"dmpstore NameThatDoesntExist -guid GuidThatDoesntExist -sfo"
produces output as:
ShellCommand,"dmpstore"
dmpstore: No matching variables found. Guid GuidThatDoesntExist, Name
NameThatDoesntExist
The difference between the above 2 cases is that former one only
specifies the GUID, but the latter one specifies both name and GUID.
Since not specifying GUID means to use GlobalVariableGuid,
"dmpstore NameThatDoesntExist -sfo" produces the similar output as
latter one.
I personally prefer to always produce SFO output for both cases.
But the above behavior is the discussion result between HPE engineers.
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
