Update TCG drivers for TPM 1.2 devices to use Tpm12DeviceLib instead
of TpmCommLib. This is required to support TPM 1.2 hardware devices
that are not on LPC bus.
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19723 6f19259b-4bc3-4df7-8a09-765794883524
Update TCG drivers for TPM 1.2 devices to use Tpm12DeviceLib instead
of TpmCommLib. This is required to support TPM 1.2 hardware devices
that are not on LPC bus.
The current versions of the TCG PEIM and DXE driver contain
MMIO reads/writes to a TPM attached to an LPC bus. In order
to support TPMs that are connected to other bus types, the
TGC PEIM and DXE drivers must be updated to not perform any
direct register accesses to any TPMs.
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19722 6f19259b-4bc3-4df7-8a09-765794883524
Update TCG drivers for TPM 1.2 devices to use Tpm12DeviceLib instead
of TpmCommLib. This is required to support TPM 1.2 hardware devices
that are not on LPC bus.
The current versions of the TCG PEIM and DXE driver contain
MMIO reads/writes to a TPM attached to an LPC bus. In order
to support TPMs that are connected to other bus types, the
TGC PEIM and DXE drivers must be updated to not perform any
direct register accesses to any TPMs.
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19721 6f19259b-4bc3-4df7-8a09-765794883524
Rename the Ui libraries,so need to update the QuarkPlatformPkg.dsc file.
Cc: Kelly Steele <kelly.steele@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Kelly Steele <kelly.steele@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19720 6f19259b-4bc3-4df7-8a09-765794883524
The changes due to the previous patches should be reflected in a higher
minor version number.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Suggested-by: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19719 6f19259b-4bc3-4df7-8a09-765794883524
The DumpHex() function produces very friendly output (known from DMPSTORE,
for example); let's use it with "BCFG -v" as well.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19718 6f19259b-4bc3-4df7-8a09-765794883524
The UEFI Shell specification classifies shell commands into various shell
levels / profiles.
Currently the DumpHex() internal function is only used by commands that
belong to the Debug1 profile exclusively (i.e., they are not required to
be present in other than Debug1 profiles):
- SMBIOSVIEW
- PCI
- DMPSTORE
- DMEM
- DBLK
In the next patch, we'd like to call DumpHex() from BCFG as well. However,
BCFG is not only required to be present in the Debug1 profile; the
Install1 profile contains BCFG as well. For this reason, move DumpHex()
from UefiShellDebug1CommandsLib to the more generic UefiShellCommandLib,
which "Provides interface to shell internal functions for shell commands".
The matching header file is "ShellPkg/Include/Library/ShellCommandLib.h".
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19717 6f19259b-4bc3-4df7-8a09-765794883524
This is likely a copy & paste error from the preceding ShellPrintHiiEx()
function call. ShellPrintEx() takes no Language parameter, so remove the
NULL argument, which is currently misinterpreted as a format string.
This bug prevents the hexdump of optional data even when -v is passed to
BCFG, and optional data exist.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19716 6f19259b-4bc3-4df7-8a09-765794883524
In this cleaned up form of BcfgDisplayDump(), it is easier to see that the
OptionalDataOffset <= BufferSize
expression, used to report whether optional data are *absent*, is
incorrect. For any well-formed EFI_LOAD_OPTION, this inequality always
holds.
Optional data are present exactly if
OptionalDataOffset < BufferSize
therefore the absence condition is the negation of the above,
OptionalDataOffset >= BufferSize
This patch fixes the bug where BCFG always reports "Optional- N", even if
optional data exist.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19715 6f19259b-4bc3-4df7-8a09-765794883524
Copying and releasing each EFI_LOAD_OPTION.FilePathList under the name
DevPath is wasteful -- we only need FilePathList for a single conversion
to text. Do it directly from the EFI_LOAD_OPTION object.
This patch is not supposed to change observable behavior.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19713 6f19259b-4bc3-4df7-8a09-765794883524
The Buffer variable points at the beginning of an EFI_LOAD_OPTION
structure. We might as well address the "FilePathListLength" member by
name, rather than with *(UINT16*)(Buffer+4).
This patch is not supposed to change behavior.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19711 6f19259b-4bc3-4df7-8a09-765794883524
"3.1.1 Boot Manager Programming" in the UEFI 2.5 spec mandates that
Boot#### and similar options contain EFI_LOAD_OPTION structures. The
EFI_LOAD_OPTION structure encodes the fixed initial part of the payload,
and we can (and should) use it to enforce a minimum size for variable
contents.
This patch is meant as a safety improvement.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19710 6f19259b-4bc3-4df7-8a09-765794883524
Don't exit the command immediately when a variable access fails; continue
processing after printing the error message. Let the final return status
reflect any encountered errors.
This patch is intended as a functional improvement.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19709 6f19259b-4bc3-4df7-8a09-765794883524
It will help with error handling if we move these initializations near the
top of the loop body.
This patch is not supposed to change behavior.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19708 6f19259b-4bc3-4df7-8a09-765794883524
STR_GEN_PROBLEM_VAL, STR_GEN_TOO_MANY, and STR_BCFG_LOCATION_RANGE are not
used in the C source code. Remove them to decrease clutter.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19707 6f19259b-4bc3-4df7-8a09-765794883524
This patch incurs no functional changes, it just modifies some whitespace,
so we can separate these non-functional changes from the functional
changes in the next patches.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19706 6f19259b-4bc3-4df7-8a09-765794883524
Check if the FV name is in the FV dictionary before using it which fixes
a crash during build report generation when FVs are specified by path in
the FDF.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen <eugene@hp.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19705 6f19259b-4bc3-4df7-8a09-765794883524
The Serial IO protocol instances provided by SerialDxe and consumed by
TerminalDxe come with a Mode.ReceiveFifoDepth=1 default setting, as
required by UEFI 2.5.
Although TerminalDxe calls EFI_SERIAL_IO_PROTOCOL.SetAttributes() in the
TerminalDriverBindingStart() and TerminalConInTimerHandler() functions, it
only does so to change the Mode.Timeout member. Other members of Mode,
including Mode.ReceiveFifoDepth, are preserved.
On some platforms this causes the UART that underlies TerminalDxe not to
have enough room for bursts of scan codes, which translates to broken
parsing of escape sequences, e.g. cursor movement keys.
According to the UEFI spec, passing ReceiveFifoDepth=0 to
EFI_SERIAL_IO_PROTOCOL.SetAttributes() "will use the device's default FIFO
depth". While TerminalDxe could try to configure a receive FIFO depth that
matches the longest escape sequence it wishes to parse, in practice the
device-specific default FIFO depth -- which may well differ from the
spec-mandated SerialIo->Mode.ReceiveFifoDepth=1 default -- seems to work.
Hence let's just set that.
This issue was exposed by SVN r18971 / git commit 921e987b2b
("ArmPlatformPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg").
In that conversion, MdeModulePkg's SerialDxe started to initialize
Mode.ReceiveFifoDepth to 1 (in conformance with the spec), unlike the
prior, non-conformant initialization to 0 in EmbeddedPkg's SerialDxe.
Since TerminalDxe would never change ReceiveFifoDepth from the new default
value 1, and the ArmPlatformPkg/Drivers/PL011Uart library instance,
underlying SerialDxe through SerialPortLib, would obey it too, they would
collectively effect a receive queue depth of 1, rather than the default 16
or 32. This broke cursor keys on the ARM FVP and Juno platforms.
It is the client of EFI_SERIAL_IO_PROTOCOL that is responsible for
modifying the attributes, if the defaults are not appropriate, hence this
patch modifies TerminalDxe.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Ryan Harkin <ryan.harkin@linaro.org>
Reference: http://thread.gmane.org/gmane.comp.bios.edk2.devel/4779/focus=6553
Reference: http://thread.gmane.org/gmane.comp.bios.edk2.devel/6594
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19701 6f19259b-4bc3-4df7-8a09-765794883524
In "11.8 Serial I/O Protocol", UEFI 2.5 requires:
The default attributes for all UART-style serial device interfaces are:
(a) 115,200 baud,
(b) a 1 byte receive FIFO,
(c) a 1,000,000 microsecond timeout per character,
(d) no parity,
(e) 8 data bits,
(f) and 1 stop bit.
It also says, about the EFI_SERIAL_IO_MODE.ControlMask member:
(g) A mask of the Control bits that the device supports. The device must
always support the Input Buffer Empty control bit.
SerialDxe complies with requirement (b) via hard-coded constants. It
complies with requirements (a), (d), (e) and (f) through PCD defaults (see
MdePkg/MdePkg.dec):
(a) 115,200 baud:
gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200|UINT64|0x00000020
(d) no parity:
# 1 - No Parity.<BR>
gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity|1|UINT8|0x00000022
(e) 8 data bits:
gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits|8|UINT8|0x00000021
(f) 1 stop bit:
# 1 - One Stop Bit.<BR>
gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits|1|UINT8|0x00000023
SerialDxe does not comply with requirements (c) and (g). In this patch, we
fix (c), and leave (g) for later.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
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>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19700 6f19259b-4bc3-4df7-8a09-765794883524
- Remove test usage declared obsolescent by POSIX
- Pass argv array through as literal rather than forming into a string, then
string-splitting and glob-expanding same.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Charles Duffy <chaduffy@cisco.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19697 6f19259b-4bc3-4df7-8a09-765794883524
- Avoid obsolescent forms of test builtin (`-a` and `-o`; see APPLICATION USAGE
section of http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html).
- Quote all expansions to prevent string-splitting and globbing.
- Avoid unspecified "exit -1" (only single-byte integers are valid); instead,
use identical exit status to shell command-not-found.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Charles Duffy <chaduffy@cisco.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19695 6f19259b-4bc3-4df7-8a09-765794883524
- Use `python2` executable if it exists, to avoid breakage on systems (such as
Arch Linux) where `python` is Python 3.
- Quote all references to `$0`, for safety when located in a directory
containing spaces in its name.
- Use the `exec` shell command to avoid leaving the shell wrapper in the
process table when invoking the actual build tool.
- Use `"$@"` rather than `$*` to pass arguments through directly rather than
concatenating to a string, and then string-splitting and glob-expanding its
contents.
- Use `$BASH_SOURCE` in preference to `$0` (which is only guaranteed to be
process name, *not* source path).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Charles Duffy <chaduffy@cisco.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19694 6f19259b-4bc3-4df7-8a09-765794883524
This patch is used to update the CryptoPkg and NetworkPkg
maintainer list.
Cc: Long Qin <qin.long@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Tian Hot <hot.tian@intel.com>
Cc: Li Ruth <ruth.li@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Qin Long <qin.long@intel.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19692 6f19259b-4bc3-4df7-8a09-765794883524
This module only handles MOR lock v1.
Now MOR lock V2 solution is published and added in variable driver. So this module can be deprecated.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Zhang, Chao B" <chao.b.zhang@intel.com>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19691 6f19259b-4bc3-4df7-8a09-765794883524
Per secure MOR implementation document, it is not proper to add MOR lock in non-SMM version, because DXE version can not provide protection.
This patch add standalone TcgMorLockDxe implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Zhang, Chao B" <chao.b.zhang@intel.com>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19689 6f19259b-4bc3-4df7-8a09-765794883524
Microsoft published secure MOR implementation at https://msdn.microsoft.com/en-us/library/windows/hardware/mt270973(v=vs.85).aspx
with revision 2 update. See URL for tech detail.
Previous revision 1 is handled in SecurityPkg\Tcg\ MemoryOverwriteRequestControlLock.
But the VarCheck API can not satisfy revision 2 requirement.
So we decide include MOR lock control into variable driver directly.
This patch add standalone TcgMorLockSmm implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Zhang, Chao B" <chao.b.zhang@intel.com>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19688 6f19259b-4bc3-4df7-8a09-765794883524
By the BUILDRULEORDER feature to process files listed in INF [Sources]
sections in priority order, if a filename is listed with multiple
extensions, the tools will use only the file that matches the first
extension in the space separated list.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19686 6f19259b-4bc3-4df7-8a09-765794883524
SVN r19611 (git commit 7cac240163), "MdeModulePkg/Ide: return correct
status when DRQ is not ready for ATAPI", changed the behavior of
AtaPacketReadWrite(), when DRQReady2() reported an error. The previous
logic had been to:
(a) terminate the transfer loop,
(b) check the status register with CheckStatusRegister(), and determine
AtaPacketReadWrite()'s return code directly from that.
Action (a) had been correct, but action (b) had masked genuine errors.
For example, when DRQReady2() reported EFI_TIMEOUT -- because the BSY bit
had not been cleared within the allotted time --, CheckStatusRegister()
would report EFI_SUCCESS, simply *because* BSY was still set, and the rest
of the status bits could not be evaluated.
SVN r19611 (git commit 7cac240163) intended to fix action (b) by directly
propagating the error code of DRQReady2() from AtaPacketReadWrite(),
eliminating the CheckStatusRegister() call. This was the right thing for
most of the errors reported by DRQReady2() -- timeout, command abort,
other device error --, but there was one exception: the "read" sub-case of
EFI_NOT_READY, which stands for "'read' complete, with less data available
than the requested amount".
Regarding the "write" sub-case of EFI_NOT_READY: the
AtaPacketCommandExecute() function programs the full transfer length into
the IDE device before it calls AtaPacketReadWrite(), and
AtaPacketReadWrite() only uses CylinderLsb and CylinderMsb for "chunking"
(as requested by the device). Therefore the device cannot justifiedly
clear DRQ earlier than seeing the entire data, when writing.
However, when reading from the device, a "short read" is a successful
operation. (The actual read length will be decoded by the higher level
protocols.) And "short reads" had been handled correctly by the logic
before git 7cac240163. Namely, when DRQReady2() returns EFI_NOT_READY, the
BSY bit is already clear, and we can call CheckStatusRegister() to
investigate all the other bits it cares about.
Therefore restore the logic from before git 7cac240163, but only for the
"read" sub-case of EFI_NOT_READY.
This problem was encountered with OVMF running on QEMU's i440fx IDE
emulation. Many thanks to John Snow for analyzing QEMU's behavior, and
pointing out that it adhered to the relevant specs.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: John Snow <jsnow@redhat.com>
Reference: https://github.com/tianocore/edk2/issues/43
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19685 6f19259b-4bc3-4df7-8a09-765794883524
The DRQReady() and DRQReady2() functions only differ in that they poll
different status registers for BSY, ERR, and DRQ: the former looks at the
Status Register (clearing interrupt status), while the latter looks at the
Alternate Status Register (not clearing interrupt status).
They both correctly return a unique status code, EFI_NOT_READY, for the
BSY==0 && ERR==0 && DRQ==0
case; that is, when the device reports "command complete".
However, the functions' leading comments don't explain this case, so it's
easy to miss in callers. Update the comments.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: John Snow <jsnow@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19684 6f19259b-4bc3-4df7-8a09-765794883524
This enhancement is to use the FilePath field in the loaded image
protocol to find the name of an image as a fallback for when the
loaded image device path protocol is not installed on the image handle.
This is necessary because the SMM core does not install the loaded
image device path protocol, so DP was displaying "Unknown Driver Name"
for every SMM driver.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Shumin Qiu <shumin.qiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19683 6f19259b-4bc3-4df7-8a09-765794883524
This enhancement is to use the FilePath field in the loaded image
protocol to find the name of an image as a fallback for when the
loaded image device path protocol is not installed on the image handle.
This is necessary because the SMM core does not install the loaded
image device path protocol, so DP was displaying "Unknown Driver Name"
for every SMM driver.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Daryl McDaniel <edk2-lists@mc2research.org>
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: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19682 6f19259b-4bc3-4df7-8a09-765794883524