summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg/Bus
Commit message (Collapse)AuthorAgeFilesLines
...
* MdeModulePkg/NvmExpressDxe: Fix wrong queue size for async IO queuesSean Brogan2019-11-202-3/+5
| | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2118 When a packet is queued/completed for the asynchronous IO queue, the logic to roll over to the front of the queue doesn't account for actual size of the IO Submission/Completion queue. This causes a device to hang due to doorbell being outside of visible queue. An example would be if an NVMe drive only supported a queue size of 128 while the driver supports 256. Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Sean Brogan <sean.brogan@microsoft.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Acked-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/Pci: Add DeviceSecurity support.Jiewen Yao2019-11-115-4/+94
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303 Whenever a PCI device is discovered, PCI bus calls the EDKII_DEVICE_SECURITY_PROTOCOL to authenticate it. If the function returns success, the PCI bus allocates the resource and installs the PCI_IO for the device. If the function returns fail, the PCI bus skips the device. It is similar to EFI_SECURITY_ARCH_PROTOCOL, which is used to verify an EFI image. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Yun Lou <yun.lou@intel.com> Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/UhciPei: Initialize the variable RequestMapShenglei Zhang2019-11-041-0/+2
| | | | | | | | | | | | RequestMap is used but not Initialized. RequestMap is called by UhciMapUserRequest, in which RequestMap(Map) is called by IoMmuMap, and is finally called by IoMmu->Map. We can not assume RequestMap is given an initial value at any step. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/EhciPei: Initialize the variable MapShenglei Zhang2019-11-041-0/+2
| | | | | | | | | | | Map is used but not Initialized. Map is called by IoMmuMap, in which Mapping(Map) is called by IoMmu->Map. We can not assume Map is given an initial value at any step. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdBlockIoPei: Add check for DeviceIndexShenglei Zhang2019-11-041-2/+2
| | | | | | | | | | DeviceIndex is used as index in Slot[]. The max size of Slot[] is SD_PEIM_MAX_SLOTS. So DeviceIndex should be checked before used. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/NvmExpressPei: Fix Opal S3 unlock issueMaggie Chu2019-10-301-20/+23
| | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2312 This patch is for fixing unexpected system hang during S3 unlock process. FatPei driver maintained and updated internal BlockIo devices list when there is new BlockIo PPI has installed, and it relied on BlockIo PPI service to get data from devices. Because BlockIo Ppi leverage NvmExpressPei Ppi to transit Nvm command to device, we should make sure NvmePassThruPpi installed before BlockIo PPI. Signed-off-by: Maggie Chu <maggie.chu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
* MdeModulePkg/XhciPei: Fix Aligned Page AllocationAshish Singhal2019-10-213-21/+160
| | | | | | | | | | Add support for allocating aligned pages at an alignment higher than 4K. The new function allocated memory taking into account the padding required and then frees up unused pages before mapping it. Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/XhciDxe: Fix Aligned Page AllocationAshish Singhal2019-10-211-1/+1
| | | | | | | | | | While allocating pages aligned at an alignment higher than 4K, allocate memory taking into consideration the padding required for that alignment. The calls to free pages takes care of this already. Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/Ufs: Fix UFS flag read from Query Resp UPIUAgrawal, Sachin2019-10-152-2/+8
| | | | | | | | | | | | | | | As per UFS spec, flag value is stored in the 'last byte' of value field. Existing code is attempting to read first byte. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2208 Test: Verified the Fix by sending command to set fPowerOnWPEn flag and then reading it to verify the set value. Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Sachin Agrawal <sachin.agrawal@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg: fix UninstallMultipleProtocolInterfaces() callsLaszlo Ersek2019-10-097-9/+9
| | | | | | | | | | | | | | | | | | Unlike the InstallMultipleProtocolInterfaces() boot service, which takes an (EFI_HANDLE*) as first parameter, the UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as first parameter. These are actual bugs. They must have remained hidden until now because they are on error paths. Fix the UninstallMultipleProtocolInterfaces() calls. Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/ScsiDiskDxe: Support Storage Security Command ProtocolZurcher, Christopher J2019-09-293-16/+774
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546 This patch implements the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL in the ScsiDiskDxe driver. Support is currently limited to the RPMB Well-known LUN for UFS devices. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Christopher J Zurcher <christopher.j.zurcher@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/ScsiBusDxe: Clean up Peripheral Type checkZurcher, Christopher J2019-09-291-2/+3
| | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546 Replacing "magic numbers" in the Peripheral Type check with defines for the reserved range from IndustryStandard/Scsi.h Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Christopher J Zurcher <christopher.j.zurcher@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/UfsPassThruDxe: Check for RPMB W-LUN (SecurityLun)Zurcher, Christopher J2019-09-291-1/+16
| | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546 Currently UfsPassThru only checks for 8 common LUNs. This adds a check for the RPMB Well-known LUN and sets the corresponding bit-mask. Further handling of the WLUN is already present in the driver. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Christopher J Zurcher <christopher.j.zurcher@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Fix SdMmcMmcLegacy bus timing handlingAlbecki, Mateusz2019-09-291-1/+7
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218 There is a bug in current driver code that makes it impossible for it to work with devices that only work in legacy speed mode since the function EmmcSwitchToHighSpeed will return with EFI_INVALID_PARAMETER for such bus mode. Since the logic in that function will work well for SdMmcMmcLegacy this patch just allows to call this function with SdMmcMmcLegacy bus mode. Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Marcin Wojtas <mw@semihalf.com>
* MdeModulePkg/SdMmcPciHcDxe: Fix bus timing switch sequenceAlbecki, Mateusz2019-09-291-44/+26
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218 SD specification recommends switching card bus timing before switching bus timing in controller. Emmc driver used to do this switch other way around. This commit adds controller timing switch in EmmcSwitchBusTiming function to enforce this order and removes all controller timing programming from EmmcSwitchToXXX functions. Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Marcin Wojtas <mw@semihalf.com>
* MdeModulePkg/SdMmcPciHcDxe: Remove clock stop from HS200 switchAlbecki, Mateusz2019-09-291-29/+0
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218 Stopping the SD clock before switching host controller bus timing is only necessary if preset value enable is set in host controller. Code that performs switch to HS200 doesn't check this condition right now and we also don't do the SD clock stop before any other bus timing switch in host controller. Since the driver is generally not ready to support host controller with preset value enable set we removed this code. Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Hao A Wu <hao.a.wu@intel.com> Tested-by: Marcin Wojtas <mw@semihalf.com>
* MdeModulePkg/UfsPassThruDxe: Implement EDKII_UFS_HC_PLATFORM_PROTOCOLAlbecki, Mateusz2019-08-134-3/+112
| | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1343 This commit adds EDKII_UFS_HC_PLATFORM_PROTOCOL implementation in UfsPassThruDxe driver in version 1. Driver assumes that at most one instance of the protocol exists in the system. Presence of the protocol is not mandatory. Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/UfsPassThruDxe: Refactor private data to use UfsHcInfoAlbecki, Mateusz2019-08-133-23/+58
| | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1343 Private data has been refactored to use EDKII_UFS_HC_INFO structure to store host controller capabilities and version information. Getting host controller data has been moved into single place and is done before host controller enable. Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/UfsPassThruDxe: Refactor UfsExecUicCommand functionAlbecki, Mateusz2019-08-132-23/+27
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1343 UfsExecUicCommand function has been refactored to allow the caller to check the command results which is important for commands such as UIC read. Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/UsbBusDxe: Return error when the device is not presentMarcin Wojtas2019-08-051-0/+1
| | | | | | | | | | | Until now, during the USB device enumeration when its PortState USB_PORT_STAT_CONNECTION bit was not set, the stack was not informed that the device is not present. Fix that by returning appropriate error code. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* PciBusDxe: duplicate node insertion for every PPB device in the systemJaveed, Ashraf2019-07-011-18/+1
| | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1796 Bug fixed in PciBusDxe\PciLib.c. Removed the redundant second call to PciSearchDevice sub-routine when the PCD for the Hot-Plug support is disabled. Signed-off-by: Ashraf Javeed <Ashraf.javeed@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocolAlbecki, Mateusz2019-07-016-231/+814
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1882 Implement support for GetOperatingParamters notify phase in SdMmcHcDxe driver. GetOperatingParameters notify phase is signaled before we start card detection and initialization. Code has been updated for both eMMC and SD card controllers to take into consideration those new parameters. Initialization process has been divided into 2 steps. In the first step we bring the link up to the point where we can get card identification data(Extended CSD in eMMC case and SWITCH command response in SD card case). This data is later used along with controller capabilities and operating parameters passed in GetOperatingParameters phase to choose preferred bus settings in GetTargetBusSettings function. Those settings are later on to start bus training to high speeds. If user passes incompatible setting with selected bus timing driver will assume it's standard behavior with respect to that setting. For instance if HS400 has been selected as a target bus timing due to card and controller support bus width setting of 4 and 1 bit won't be respected and 8 bit setting will be chosen instead. Tests on Marvell boards were also performed by Marcin Wojtas <mw@semihalf.com>: https://edk2.groups.io/g/devel/message/42999 Board 1 (out of tree): SD - OK, MMC - OK Board 2: (Armada80x0McBin): SD - OK, MMC - OK Board 3: (Armada70x0Db): SD - problems, MMC - OK Please note that the problem on Armada70x0Db SD devices are introduced by adding new types of SD bus modes, a subsequent patch within edk2-platforms repository will be proposed to address it. (More details can be referred from the above link.) Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Regression-tested-by: Sumit Garg <sumit.garg@linaro.org>
* MdeModulePkg/UfsPassThruDxe: Fix unaligned data transfer handlingAlbecki, Mateusz2019-07-012-54/+150
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1341 Since UFS specification requires the data buffer specified in PRDT to be DWORD aligned in size we had a code in UfsInitUtpPrdt that aligned the data buffer by rounding down the buffer size to DWORD boundary. This meant that for SCSI commands that wanted to perform unaligned data transfer(such as SENSE command) we specified to small buffer for the data to fit and transfer was aborted. This change introduces code that allocates auxiliary DWORD aligned data buffer for unaligned transfer. Device transfers data to aligned buffer and when data transfer is over driver copies data from aligned buffer to data buffer passed by user. Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/UfsPassThruDxe: Refactor UFS device presence detectionAlbecki, Mateusz2019-06-271-32/+18
| | | | | | | | | In current implementation we are checking for device presence every time we execute UIC command. To make UfsExecUicCommands more generic checking device presence has been moved to UfsDeviceDetection. Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/NvmExpressPei: Produce NVM Express PassThru PPIMaggie Chu2019-06-248-117/+420
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1879 This commit will add codes to produce the NVM Express PassThru PPI. Signed-off-by: Maggie Chu <maggie.chu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/PciBusDxe: catch unimplemented extended config space readsLaszlo Ersek2019-06-111-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may find that the extended config space is not (fully) implemented. In LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as 0xFFFF_FFFF at a given config space offset, after which the loop gets stuck spinning on offset 0xFFC (the read at offset 0xFFC returns 0xFFFF_FFFF most likely as well). Another scenario (not related to virtualization) for triggering the above is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the topology -- intervenes between a PCI Express Root Port and a PCI Express Endpoint. The Conventional PCI bus limits the accessible config space of the PCI Express Endpoint, even though the endpoint advertizes the PCI Express capability. Here's a diagram, courtesy of Alex Williamson: [PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP] ->| |<- Conventional PCI bus Catch reads of 0xFFFF_FFFF in LocatePciExpressCapabilityRegBlock(), and break out of the scan with a warning message. The function will return EFI_NOT_FOUND. Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/AhciPei: Fix device cannot be found in non-S3 pathHao A Wu2019-05-311-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1862 Current implementation of function AhciModeInitialization() has an incorrect assumption that the value in the CAP (offset 00h) register will always be greater than the highest bit set for the value in the PI (offset 0Ch) register. This will lead to an issue that hard disk devices may not be found in the non-S3 boot path for some AHCI controller capabilities. More specifically, variable 'PortInitializeBitMap' will have the value from 'Private->PortBitMap', which will be 0xFFFFFFFF in non-S3 boot path. When the CAP register is of value 0x1 and PI register with value 0x4 (meaning port 2 is available), the current logic will only enumerate port 0. And the device attached behind port 2 will not be enumerated. To address this issue, variable 'PortInitializeBitMap' will now take the bitwise and result between 'Private->PortBitMap' and the value read from the PI register. Please note that there will be no function impact for S3 path, since in this case, the bits being set in 'Private->PortBitMap' will be a subset of the bits being set in the PI register. Their bitwise and operation will still be the value of 'Private->PortBitMap'. Cc: Maggie Chu <maggie.chu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg: Remove BootInRecoveryMode PPIxuwei62019-05-096-6/+6
| | | | | | | | | | | | | | | | | | DEPEX from PEI storage stack. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1777 BootInRecoveryMode Ppi dependency should be removed from PEI storage stack drivers. Besides recovery, more features are using the storage stack. Platform can apply Ppi dependency in Recovery FV which contains full storage driver stack. Platform storage stack modules, such as host controller init PEI module, should also remove this dependency. Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
* MdeModulePkg/NvmExpressHci.c: Change commentsZhichao Gao2019-04-281-4/+1
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460 Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific or not. So change the comments of NvmeShutdownAllControllers. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael Turner <Michael.Turner@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/AhciPei: Add PEI BlockIO supportHao Wu2019-04-246-0/+960
| | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1483 This commit will add the PEI BlockIO (2) PPIs support for AHCI mode ATA devices. More specifically, the driver will consume the ATA AHCI host controller PPI for ATA controllers working under AHCI code within the system. And then produces the below additional PPIs for each controller: EFI PEI Recovery Block IO PPI EFI PEI Recovery Block IO2 PPI Cc: Eric Dong <eric.dong@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/AhciPei: Limit max transfer blocknum for 48-bit addressHao Wu2019-04-241-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1483 Due to the limited resource on the VTd DMA buffer size in the PEI phase, the driver will limit the maximum transfer block number for 48-bit addressing. According to PCDs: gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSize|0x00400000 gIntelSiliconPkgTokenSpaceGuid.PcdVTdPeiDmaBufferSizeS3|0x00200000 The default buffer size allocated for IOMMU mapping is: * 4M bytes for non-S3 cases; * 2M bytes for S3 For ATA devices in 48-bit address mode, the maximum block number is currently set to 0xFFFF. For a device with block size equal to 512 bytes, the maximum buffer allowed for mapping within AhciPei driver will be close to 32M bytes. Thus, this commit will limit the 48-bit mode maximum block number to 0x800, which means 1M-byte maximum buffer for mapping when the block size of a device is 512 bytes. By doing so, potential failure on calls to the IOMMU 'Map' service can be avoided. Cc: Eric Dong <eric.dong@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/PciBusDxe: dispatch option ROMs for foreign architecturesArd Biesheuvel2019-04-141-7/+0
| | | | | | | | | | | Delete the explicit machine type check for option ROM images, and instead, rely on the LoadImage() boot service to decide whether an option ROM can be dispatched or not. This permits platforms to ship with emulators to execute option ROMs that are not native to the processor architecture. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-09405-2894/+405
| | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA SupportAshish Singhal2019-03-114-73/+161
| | | | | | | | | | | | | | Driver was supporting only 32b DMA support for V3 controllers. Add support for 64b DMA as well for completeness. For V4.0 64b support, driver was looking at incorrect capability register bit. Fix for that is present as well. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1583 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Tested-by: Eugene Cohen <eugene@hp.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/UfsBlockIoPei: Correct use of 'DeviceIndex' in BlkIO PPIHao Wu2019-02-251-25/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1474 Within UfsBlockIoPei, the current implementation of the Block IO(2) services: UfsBlockIoPeimGetMediaInfo UfsBlockIoPeimReadBlocks UfsBlockIoPeimGetMediaInfo2 UfsBlockIoPeimReadBlocks2 does not handle the input parameter 'DeviceIndex' properly. According to both of the PI spec and the function description comments: > DeviceIndex Specifies the block device to which the function wants > to talk. ... This index is a number from one to > NumberBlockDevices. But current codes incorrectly treat the valid range of 'DeviceIndex' as 0 to (NumberBlockDevices - 1). This commit is to address this issue. Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/AhciPei: Add AHCI mode ATA device support in PEIHao Wu2019-02-2213-0/+5183
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409 This commit will add the AHCI mode ATA device support in the PEI phase. More specifically, the newly add AhciPei driver will consume the ATA AHCI host controller PPI for ATA controllers working under AHCI code within the system. And then produces the below PPIs for each controller: EDKII PEI ATA PassThru PPI Storage Security Command PPI Also, the driver will consume the S3StorageDeviceInitList LockBox in S3 phase. The purpose is to perform an on-demand (partial) ATA device enumeration/initialization on each controller to benefit the S3 resume performance. The implementation of this driver is currently based on the below specifications: Serial ATA Revision 2.6 Serial ATA Advanced Host Controller Interface (AHCI) 1.3.1 AT Attachment with Packet Interface - 6 (ATA/ATAPI-6) Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBoxHao Wu2019-02-225-1/+236
| | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409 For the NvmExpressPei driver, this commit will update the driver to consume the S3StorageDeviceInitList LockBox in S3 phase. The purpose is to perform an on-demand (partial) NVM Express device enumeration/initialization to benefit the S3 resume performance. Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPIHao Wu2019-02-228-89/+1075
| | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409 For the NvmExpressPei driver, this commit will add codes to produce the Storage Security Command PPI if the underlying NVM Express controller supports the Security Send and Security Receive commands. Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/NvmExpressPei: Avoid updating the module-level variableHao Wu2019-02-223-84/+92
| | | | | | | | | | | | | | | This commit is out of the scope for BZ-1409. The commit will remove the call of RegisterForShadow() at the entry point of the driver. By doing so, the driver is now possible to be executed without being re-loaded into permanent memory. Thus, this commit will update the NvmExpressPei driver to avoid updating the content of a global variable. Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widthsEdgar Handal2019-02-201-4/+21
| | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1537 Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register accesses from being split up into 8-bit accesses. The SDHCI specification states that the registers shall be accessible in byte, word, and double word accesses. (SD Host Controller Simplified Specification 4.20 Section 1.2) Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jeff Brasen <jbrasen@nvidia.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequenceAlbecki, Mateusz2019-02-201-16/+17
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140 In eMMC HS400 switch sequence flow eMMC driver attempted to execute SEND_STATUS just after switching bus timing to high speed and before downgrading clock frequency to 52MHz. Since link was at that time in incorrect state SEND_STATUS was failing which made driver think switch to HS400 failed. This change makes driver always change clock frequency after switching bus timing and before executing SEND_STATUS. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Albecki Mateusz <mateusz.albecki@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored sometimesRay Ni2019-02-141-28/+23
| | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1505 When a device under PPB contains option ROM but doesn't require 32bit MMIO, ProgrameUpstreamBridgeForRom() cannot correctly restore the PPB MEM32 RANGE BAR. It causes the 32bit MMIO conflict which may cause system hangs in boot. The root cause is when ProgrameUpstreamBridgeForRom() calls ProgramPpbApperture() to restore the PPB MEM32 RANGE BAR, the ProgramPpbApperture() skips to program the BAR when the resource length is 0. This patch fixes this issue by not calling ProgramPpbApperture(). Instead, it directly programs the PPB MEM32 RANGE BAR. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com>
* MdeModulePkg/PciBus: Correct typosRay Ni2019-02-1420-156/+154
| | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/PciBus: Change PCI_IO_DEVICE.RomSize to UINT32 typeRay Ni2019-02-145-13/+13
| | | | | | | | | Per PCI Spec, the option ROM BAR is 32bit so the maximum option ROM size can be hold by UINT32 type. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/NvmExpressDxe: Report StatusCode for device init failureSean Brogan2019-02-133-3/+13
| | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1408 According to the information of the above BZ-1408 and other platform owners, NVM Express devices are becoming more likely to be a critical part during the boot process. This commit will add the calls to 'REPORT_STATUS_CODE' when there is a failure happens during the NVM Express controller/device initialization process. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <brbarkel@microsoft.com> Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Update comment for spec compliance statusHao Wu2019-02-014-8/+14
| | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1441 This commit will update the file-level comments within the SdMmcPciHcDxe to reflect the latest specification compliance status of the driver. Cc: Ray Ni <ray.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/NonDiscoverablePciDevice: Remove the redundant checkDandan Bi2019-01-081-5/+3
| | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1422 if (Attributes) { if ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0) { return EFI_UNSUPPORTED; } } In above code block, "If ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0)" is TRUE, the Attributes must be not 0. So we can remove the redundant check "if (Attributes)". Cc: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT build failureHao Wu2019-01-051-4/+4
| | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1425 This commit will resolve the VS2015 IA32 NOOPT build failure within SdMmcPciHcDxe. More specifically, this commit will use BaseLib API RShiftU64() to perform right-shift operations for UINT64 type operators. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Bi Dandan <dandan.bi@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Add SDMMC HC v4 and above Support.Ashish Singhal2019-01-036-83/+366
| | | | | | | | | | | | | | | | | | | | | | Add SDMA, ADMA2 and 26b data length support. If V4 64 bit address mode is supported in capabilities register, program controller to enable V4 host mode and use appropriate SDMA registers supporting 64 bit addresses. If V4 64 bit address mode is supported in capabilities register, program controller to enable V4 host mode and use appropriate ADMA descriptors supporting 64 bit addresses. If host controller version is above V4.0, enable ADMA2 with 26b data length support for better performance. HC 2 register is configured to use 26 bit data lengths and ADMA2 descriptors are configured appropriately. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1359 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/PciBus: Fix system hang when no PCI Option ROM existsRuiyu Ni2018-12-171-4/+6
| | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1394 When there is no PCI option ROM exists, today's logic still creates virtual BAR for option ROM using Length = 0, Alignment = (-1). It causes the final MEM32 alignment requirement is as big as 0xFFFFFFFF_FFFFFFFF. The patch fixes this issue by only creating virtual BAR for option ROM when there is PCI option ROM. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Chiu Chasel <chasel.chiu@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-01 00:05:34 +0000