REF: https://bugzilla.tianocore.org/show_bug.cgi?id=704
For root directory, the FID (File Identifier Descriptor) pointer is
accessible through PRIVATE_UDF_FILE_DATA.Root, whereas non-root
directory and regular files, their FIDs are accessible through
PRIVATE_UDF_FILE_DATA.File.
In UdfSetPosition(), the FID was retrieved through
PRIVATE_UDF_FILE_DATA.File, hence when calling it with a root directory,
PRIVATE_UDF_FILE_DATA.File.FileIdentifierDescriptor would be NULL and
then dereferenced.
This patch fixes the NULL pointer dereference by calling _FILE() to
transparently return the correct UDF_FILE_INFO * which points to a valid
FID descriptor of a specific file.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Steven Shi <steven.shi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Reported-by: Steven Shi <steven.shi@intel.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
VS2010/VS2012 build failure with below info:
warning C4701:
potentially uninitialized local variable 'DataOffset' used
potentially uninitialized local variable 'FilePosition' used
potentially uninitialized local variable 'FinishedSeeking' used
potentially uninitialized local variable 'Data' used
warning C4703:
potentially uninitialized local pointer variable 'Data' used
In fact, DataOffset, FilePosition and FinishedSeeking are initialized
and then used if (ReadFileInfo->Flags == READ_FILE_SEEK_AND_READ).
DoFreeAed will be set to TRUE when Data is allocated and returned from
GetAedAdsData(), and Data will be freed if (DoFreeAed) when exiting.
Use same method at 5afa5b8159 to fix
the build failure.
There is related discussion at
https://lists.01.org/pipermail/edk2-devel/2017-September/014641.html
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
When building the driver for DEBUG/RELEASE, GCC48/GCC49 warn about
ReadFile() possibly using "BytesLeft" without initializing it first.
This is not the case. The reads of "BytesLeft" are only reachable if
(ReadFileInfo->Flags == READ_FILE_SEEK_AND_READ). But, in that case, we
also set "BytesLeft" to "ReadFileInfo->FileDataSize", near the top of the
function.
Assign "BytesLeft" zero at the top, and add a comment that conforms to the
pending Coding Style Spec feature request at
<https://bugzilla.tianocore.org/show_bug.cgi?id=607>.
This issue was reported by Ard's and Gerd's CI systems independently.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
The ECMA-167 standard (3rd Edition, June 1997) reserves values 4 through 7
in the ICB.Flags[2:0] bit-field for future standardization; see "14.6 ICB
Tag" / "14.6.8 Flags (RBP 18)".
https://www.ecma-international.org/publications/standards/Ecma-167.htm
The
switch (RecordingFlags)
statement in the ReadFile() function handles all the standard values,
using the constants of the UDF_FE_RECORDING_FLAGS enum type. However, the
reserved values are not caught with a "default" case label, which both
breaks the edk2 Coding Style Spec, and leaves the Status variable
un-initialized, before we return Status under the Done label.
Set Status to EFI_UNSUPPORTED if we encounter a reserved value.
This issue was reported by Ard's and Gerd's CI systems independently
(through build failures with GCC48/GCC49, DEBUG/RELEASE targets).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
This patch gets rid of a negative comparison of an UINT64 type (Offset)
as it'll never evaluate to true.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Reported-by: Star Zeng <star.zeng@intel.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
In the expression
(RemainderByMediaBlockSize != 0 ||
Media->BlockSize > UDF_LOGICAL_SECTOR_SIZE)
the second expression is only evaluated if the first expression is false.
If the first expression is false, i.e.,
RemainderByMediaBlockSize == 0
then UDF_LOGICAL_SECTOR_SIZE is a whole multiple of "Media->BlockSize",
which implies
UDF_LOGICAL_SECTOR_SIZE >= Media->BlockSize.
Therefore whenever
Media->BlockSize > UDF_LOGICAL_SECTOR_SIZE
is evaluated, it is false.
The expression
((expression) || FALSE)
is equivalent to
(expression).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In edk2, the division and shifting of 64-bit values are forbidden with
C-language operators, because the compiler may generate intrinsic calls
for them.
For example, clang-3.8 emits a call to "__umoddi3" for
UDF_LOGICAL_SECTOR_SIZE % Media->BlockSize
in PartitionInstallUdfChildHandles(), if PartitionDxe is built for IA32,
which then fails to link.
UDF_LOGICAL_SECTOR_SIZE has type UINT64, while
EFI_BLOCK_IO_MEDIA.BlockSize has type UINT32(). Replace the % operator
with a DivU64x32Remainder() call.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In edk2, initialization of local variables is forbidden, both for
stylistic reasons and because such initialization may generate calls to
compiler intrinsics.
For the following initialization in UdfRead():
CHAR16 FileName[UDF_FILENAME_LENGTH] = { 0 };
clang-3.8 generates a memset() call, when building UdfDxe for IA32, which
then fails to link.
Replace the initialization with ZeroMem().
Do the same to "FilePath" in UdfOpen().
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ard reports that clang-3.8 correctly flags the following issue in the
ReadFile() function:
If "RecordingFlags" is INLINE_DATA, then there are three paths through the
code where we mean to return success, but forget to set Status
accordingly:
(1) when "ReadFileInfo->Flags" is READ_FILE_GET_FILESIZE, or
(2) when "ReadFileInfo->Flags" is READ_FILE_ALLOCATE_AND_READ and
AllocatePool() succeeds, or
(3) when "ReadFileInfo->Flags" is READ_FILE_SEEK_AND_READ.
Set "Status" to EFI_SUCCESS when we are done processing the INLINE_DATA
request, i.e., when we reach the corresponding "break" statament under the
INLINE_DATA case label.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In the ReadFile() function, if "RecordingFlags" is INLINE_DATA, then we
cover the following values of "ReadFileInfo->Flags":
- READ_FILE_GET_FILESIZE
- READ_FILE_ALLOCATE_AND_READ
- READ_FILE_SEEK_AND_READ
We don't do anything (just proceed to the end of the function) if
"ReadFileInfo->Flags" is anything else.
In reality the above three values cover the domain of the
UDF_READ_FILE_FLAGS enum type fully, and "ReadFileInfo->Flags" is only
ever set internally to UdfDxe. Therefore any other flag value would be a
bug in UdfDxe.
ASSERT() specifically that "ReadFileInfo->Flags" has been set correctly,
so that the reader is not left wondering what happens if none of the enum
constants match.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Initialize the array DescriptorLBAs[] after declaration to fix
non-constant aggregate initializer warning in VS tool chains.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Initialize the array DescriptorLBAs[] after declaration to fix
non-constant aggregate initializer warning in VS tool chains.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
V3: Remove one unnecessay type cast in patch 1.
Codes:
if (FilePosition + ExtentLength > ReadFileInfo->FilePosition) {
Offset = ReadFileInfo->FilePosition - FilePosition;
if (Offset < 0) {
Offset = -(Offset)
}
...
}
Offset is UINT64 can not < 0, so the code logic may have some issue.
and Offset = -(Offset) may build failure in some circumstance.
Previously type cast Offset to INT64 to fix build break. Now remove
the type cast. Then can to check the code logic later.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This patch introduces UDF file system support in EDK2. All block devices
that support BlockIo and DiskIo protocols and contain a valid UDF file
system - as specified by OSTA Universal Disk Format (revisions 1.02
through 2.60) - will be installed EFI_SIMPLE_FILE_SYSTEM_PROTOCOL to
provide access to underlying file system.
File system operations on regular, directory and symlink files are
supported.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Scan for UDF file systems on all block devices, as specified by OSTA
Universal Disk Format Specification 2.60, and install a Vendor-Defined
Media Device Path for each file system found.
The Vendor-Defined Media Device Path for the UDF file system is then
checked by UdfDxe to decide whether or not start the driver.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
RamDiskDxe installs the RamDiskAcpiCheck() Ready To Boot callback
function. If EFI_ACPI_TABLE_PROTOCOL and/or EFI_ACPI_SDT_PROTOCOL are not
found, then informational messages are logged, and the RAM disks are not
published to the (nonexistent) NFIT table.
The logic is fine, but the info messages are not concatenated correctly
from multiple string literals -- the second parts are passed as (unused)
arguments to DEBUG(). Fix the typos.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This PCD is used to indicated the recovery file name.
The previous name - FvMain.Fv is hardcoded in CdExpressPei.
It does not make sense to force the name.
Now a platform may use any recovery file name.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Current PeiCdExpress driver will return capsule size to
be block aligned.
It will fail if we check the capsuleImageSize field.
The patch correct the returned capsule size.
Tested-by: Eric Dong <eric.dong@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
This commit will scan all the EFI raw section instances within the
module's FV to make sure the NVDIMM root device SSDT can be properly
located.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Zhang Chao B <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Adding an option in HII menu so user can choose memory type to use when
creating a RAM Disk in system.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah <tapandshah@hpe.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
The 'Size' numeric value used when creating a raw RAM disk does not
require a varstore to save its previous value in the create raw RAM disk
HII page.
The expecting behavior is that after a user created a raw RAM disk, the
next time when the create raw RAM disk page is entered, the 'Size' numeric
will be the default value (EFI_PAGE_SIZE).
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>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
Potentially uninitialized local variables 'TableKey' and 'TableHeader'
might be used in functions RamDiskPublishNfit() and RamDiskUnpublishNfit()
in file RamDiskProtocol.c.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
The RamDiskDxe driver originally uses a variable-length HII varstore to
retrieve the HII checkbox status of each registered RAM disk.
However, HII does not support the variable-length varstore feature.
Therefore, only the checkbox status for the first 8 RAM disks are tracked
for the following definition of HII varstore structure considering the
alignment:
typedef struct {
UINT64 Size;
UINT8 RamDiskList[0];
} RAM_DISK_CONFIGURATION;
This commit uses the private data of each registered RAM disks to track
the HII checkbox status instead to resolve the issue.
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>
The RamDiskDxe now will report RAM disks with reserved memory type to NFIT
in the ACPI table.
This commit will also make sure that an NVDIMM root device exists in the
\SB scope before reporting any RAM disk to NFIT.
To properly report the NVDIMM root device, one will need to append the
following content in the [Rule.Common.DXE_DRIVER] field in platform FDF
files:
RAW ACPI Optional |.acpi
RAW ASL Optional |.aml
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>
Reviewed-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
EndingAddress is calculated incorrectly. Original code calculates it as
(StartingAddress + Size). Correct value should be (StartingAddress +
Size - 1.
Note:
Besides the changes made by Samer, Hao also fixed a similar issue in
RamDiskImpl.c
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
Signed-off-by: Tapan Shah <tapandshah@hpe.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
There are scenario when the BindingStop service of PartitionDxe driver be
re-entered.
An example will be ejecting a DVD from a SATA DVDROM and then run
"reconnect -r" under shell. In this specific case, part of the calling
stack will be:
PartitionDriverBindingStop() (PartitionDxe) ->
Stop first child handle (PartitionDxe) ->
ScsiDiskFlushBlocksEx() (ScsiDiskDxe) ->
A media change is detected (ScsiDiskDxe) ->
Reinstall of BlockIO(2) protocols (ScsiDiskDxe) ->
Entering PartitionDriverBindingStop() again (PartitionDxe) ->
Potential risk of referencing already stopped child handle (PartitionDxe)
...
The current code has potential issue of referencing of already stopped
child handle. This commit adds re-entry handling logic to resolve such
issue.
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>
Found an issue that file system cannot be started on a DVD when doing the
following process:
Boot to shell with a DVD inside a SATA DVDROM. Eject the DVD and run
"reconnect -r". Put the DVD inside again and run "reconnect -r".
The cause is that after executing the second reconnect action, DiskIo
immediately returns EFI_NO_MEDIA in function DiskIo2ReadWriteDisk() when
checking the media information. However, at this time, the media
information does not get updated by the ScsiDisk driver. Therefore, DiskIo
driver should left the no media check to ScsiDisk driver.
Generally, the media changed and media write protect check should also be
left to lower-level device driver. Thus, these two checks in function
DiskIo2ReadWriteDisk() are also removed.
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>
Some ISO images cannot be recognized properly when they are on media whose
block size is not 2048 bytes.
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>
There is no asynchronous operations to the registered RAM disks link list
maintained within RamDiskDxe driver, therefore, the TPL raise and restore
operations when dealing with the link list are unnecessary.
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>
Previously, the code uninstalls the DEVICE_PATH_PROTOCOL with the device
path given by caller of the 'RamDiskUnregister' function. The given device
path might be different from the one used to install the
DEVICE_PATH_PROTOCOL.
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>
The 'DisconnectController' function calls after
'UninstallMultipleProtocolInterfaces' are unnecessary, since
'DisconnectController' is called inside function
'UninstallMultipleProtocolInterfaces'.
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>
The RamDiskDxe driver will:
1. Produce the EFI RAM Disk Protocol
2. Install RAM disk device path and block I/O related protocols on the
RAM disk device handle.
3. Install RAM disk configuration form to HII database
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
UEFI Spec 2.3.1.D Section 9.3.5.1 says Partitions are numbered
according to their entry in their respective partition table,
starting with 1.
Update the code for MBR partition to follow this rule.
Ref: https://github.com/tianocore/edk2/issues/50
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Add check to see if there is a media in the disk device. If not return
EFI_NO_MEDIA directly.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19446 6f19259b-4bc3-4df7-8a09-765794883524
The call in ProbeMediaStatus() to the ReadDisk() function of the
EFI_DISK_IO_PROTOCOL interface implemented in DiskIoDxe/DiskIo.c
crashed in DiskIo2ReadWriteDisk() because of the NULL value of
the destination buffer pointer.
Pass the address of a buffer in the stack instead of a NULL
pointer.
In addition to avoiding the crash, that way, the media probe does not
depend anymore on the way the EFI_DISK_IO_PROTOCOL implementation deals
with a NULL value of the destination buffer pointer as the UEFI
specification does not specify the expected behaviour.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ronald Cron <Ronald.Cron@arm.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17859 6f19259b-4bc3-4df7-8a09-765794883524
El Torito format can be used on different media (eg: USB).
A ISO image can be dumped onto a USB mass-storage.
These media might not have the same block size as the CDROM media (ie: 2KB).
The El Torito code and the specification assumes a LBA 2KB.
In addition, the specification says in "12.3.4.4 CD-ROM and DVD-ROM":
UEFI code does not assume a fixed block size.
I was able to dupliacte the issue by copying a debian ISO on a USB driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16600 6f19259b-4bc3-4df7-8a09-765794883524
DiskIoDxe: Fix ReadDiskEx and WriteDiskEx to not modify the user’s buffer when the BufferSize is 0.
DiskIoDxe: Fix ReadDiskEx and WriteDiskEx hang issue when the submitted blockio2 task is completed before submitting another blockio2 task.
DiskIoDxe: Fix FlushEx to free the flush task item in callback (memory leak issue).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16215 6f19259b-4bc3-4df7-8a09-765794883524
1. Module UNI and Package UNI files are not DOS format. Convert them to DOS format.
2. Remove unused SectionExtractionDxeModStrs.uni and SectionExtractionPeiModStrs.uni
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gao, Liming <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16044 6f19259b-4bc3-4df7-8a09-765794883524
2. Add MODULE_UNI_FILE file that contains the localized Abstract and Description of a module.
a. Addresses an information gap between INF files and the UEFI Distribution Packaging Specification XML schema
b. There will be an associated update to UPT in BaseTools to consume MODULE_UNI_FILE and associated UNI file during UDP creation that performs the INF -> XML conversion.
c. There will be an associated update to UPT in BaseTools to produce MODULE_UNI_FILE and associated UNI file during UDP installation that performs the XML -> INF conversion.
3. Add Module Extra UNI file that provides the localized Name of a module.
a. [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a module to specify extra files not listed in [Sources] or [Binaries] sections to be added to a UDP without having to list the files in the UPT package information data file.
b. There will be an associated update to UPT in BaseTools to package up files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP creation.
c. UNI file contains localized name of a module to go along with the localized Abstract and Description from the MODULE_UNI_FILE.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zeng, Star <star.zeng@intel.com>
Reviewed-by: Gao, Liming <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15963 6f19259b-4bc3-4df7-8a09-765794883524