Thanks for the response! So to access a SATA HDD, to send any command to SATA HDD or to probe SATA devices, we need this complete stack in place?
And is there any existing command (any shell command that scans/discover SATA devices) in EDK2 to check whether HDD is scanned in the system? Thanks and Regards, Shaveta -----Original Message----- From: Tian, Feng [mailto:[email protected]] Sent: Thursday, May 05, 2016 11:18 AM To: Shaveta Leekha <[email protected]>; Kinney, Michael D <[email protected]>; Laszlo Ersek <[email protected]>; [email protected] <[email protected]> Cc: Tian, Feng <[email protected]> Subject: RE: [edk2] Two PCI IO protocols getting produced by same GUID, how to open correct one? AtaAtapiPassThru produces ATA_PASS_THRU and EXT_SCSI_PASS_THRU two protocol instances. AtaBus consumes ATA_PASS_THRU protocol to convert upper layer BlockIo request to ATA cmd and sent the cmd to specified ATA device. ScsiBus + ScsiDisk consume EXT_SCSI_PASS_THRU protocol to convert upper layer BlockIo request to ATAPI cmd and sent the cmd to specified ATAPI device. Why we can do this is because ATAPI cmd is derived from SCSI cmd. Thanks Feng -----Original Message----- From: edk2-devel [mailto:[email protected]] On Behalf Of Shaveta Leekha Sent: Thursday, May 5, 2016 1:34 PM To: Kinney, Michael D <[email protected]>; Laszlo Ersek <[email protected]>; [email protected] <[email protected]> Subject: Re: [edk2] Two PCI IO protocols getting produced by same GUID, how to open correct one? Thanks Mike for the response! Hi All, Few doubts in SATA stack. I have seen at some places that in UEFI/EDK2, The complete ATA stack should be like: IdeControllerDxe + AtaAtapiPassThru + AtaBus + ScsiBus + ScsiDisk + PartitionDriver + Fat What is the role of "ScsiBus + ScsiDisk" in this stack? Complete AHCI specific code is there in "AtaAtapiPassThru"? is tha correct? Then why ScSi bus layer is required? Thanks and Regards, Shaveta -----Original Message----- From: Kinney, Michael D [mailto:[email protected]] Sent: Wednesday, May 04, 2016 10:58 PM To: Shaveta Leekha <[email protected]>; Laszlo Ersek <[email protected]>; Kinney, Michael D <[email protected]> Cc: [email protected] <[email protected]> Subject: RE: [edk2] Two PCI IO protocols getting produced by same GUID, how to open correct one? Shaveta, All UEFI drivers (not just ones for PCI controllers) are responsible for evaluating the ControllerHandle in their EFI Driver Binding Supported() and Start() APIs to make sure the ControllerHandle is the type the driver knows how to manage. If there is more than one driver that can correctly manage the same ControllerHandle, then there are precedence rules for the order that each driver's Supported() and Stop() APIs are called. This is described in the UEFP Spec and the UEFI Driver Writer's Guide. See UEFI DWG Section 3.14.1 for precedence rules. See UEFI DWG Section 18.3 for details on what a PCI Driver is recommended to do in their Supported() and Start() functions. https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer's-Guide Mike > -----Original Message----- > From: Shaveta Leekha [mailto:[email protected]] > Sent: Wednesday, May 4, 2016 12:23 AM > To: Kinney, Michael D <[email protected]>; Laszlo Ersek > <[email protected]> > Cc: [email protected] <[email protected]> > Subject: RE: [edk2] Two PCI IO protocols getting produced by same > GUID, how to open correct one? > > Thanks for the reply > My replies are in-lined. > > Thanks and Regards, > Shaveta > > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of > Kinney, Michael D > Sent: Tuesday, May 03, 2016 9:29 PM > To: Shaveta Leekha <[email protected]>; Laszlo Ersek > <[email protected]>; Kinney, Michael D <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: [edk2] Two PCI IO protocols getting produced by same > GUID, how to open correct one? > > Shaveta, > > As long as all PCI I/O Protocol instances in the platform conform to > UEFI spec, it can work. > > [Shaveta] Correct. > > Your original question was about how to tell that a handle has the PCI > I/O Protocol produced By PCI Bus Driver or your emulation of PCI. If > the PCI I/O Protocols are conformant, then It should not matter. Just > write a PCI Device Driver that manages a PCI controller based on PCI > Class code or Vendor ID/Device ID matching and it should work. > > [Shaveta] Yes, eventually correct the PCI I/O Protocol produced my PCI > emulation layer code is getting opened. > As and when a valid protocol gets opened, I am checking the CLASS code > and Sub-CLASS code before proceeding. > And that's working. > > But what if, some other device's driver in my system, intended to open > "PCI I/O Protocol produced By PCI Bus Driver" > Doesn't test CLASS CODE or any SUB-CLASS/VENDOR etc., then it may land > up using API's provided with protocol Of my PCI emulation layer code? > is that understanding correct ?? > > So in such scenarios, where more than one protocol instances (with > different APIs > associated) are installed with same GUID in the system, Then all the > drivers should check VENDOR ID/CLASS etc immediately after opening the > protocol? > > > > Mike > > > > -----Original Message----- > > From: edk2-devel [mailto:[email protected]] On Behalf > > Of Shaveta Leekha > > Sent: Tuesday, May 3, 2016 3:27 AM > > To: Laszlo Ersek <[email protected]> > > Cc: [email protected] <[email protected]> > > Subject: Re: [edk2] Two PCI IO protocols getting produced by same > > GUID, how to open correct one? > > > > > > > > -----Original Message----- > > From: Laszlo Ersek [mailto:[email protected]] > > Sent: Tuesday, May 03, 2016 1:15 PM > > To: Shaveta Leekha <[email protected]> > > Cc: [email protected] <[email protected]> > > Subject: Re: [edk2] Two PCI IO protocols getting produced by same > > GUID, how to open correct one? > > > > On 05/03/16 08:54, Shaveta Leekha wrote: > > > Hi, > > > > > > I have a scenario where two separate drivers are installing/producing > > > "PCI IO" > > protocol with same GUID (gEfiPciIoProtocolGuid). > > > > > > Where: > > > > > > (1) One of the PCI Io protocol instance is produced by > > "MdeModulePkg/Bus/Pci/PciBus" driver for real PCI devices to use( > > like E1000/NIC card to use) > > > > > > (2) Other PCI Io protocol instance is produced by "Pci Emulation" > > > layer created > > for USB and SATA kind of controllers. This protocol (APIs) is > > intended to be used by USB and SATA controller drivers. > > > > > > Now when I use "OpenProtocol" in my "Platform specific Sata controller > > > driver" > using: > > > > > > Status = gBS->OpenProtocol ( > > > Controller, > > > &gEfiPciIoProtocolGuid, > > > (VOID **) &PciIo, > > > This->DriverBindingHandle, > > > Controller, > > > EFI_OPEN_PROTOCOL_GET_PROTOCOL > > > ); > > > > > > How can I make sure that PCI Io protocol that is produced by > > > "PciEmulation" layer > > driver is getting opened? > > > > > > As "gEfiPciIoProtocolGuid" is same for both protocol instances. > > > > > > How to handle such scenarios? > > > > The UEFI spec forbids installing more than one protocol interface > > with the same GUID on the same handle. See > > EFI_BOOT_SERVICES.InstallProtocolInterface(): > > > > [... The same GUID cannot be installed more than once onto the same > > handle. If installation of a duplicate GUID on a handle is attempted, > > an EFI_INVALID_PARAMETER will result. [...] > > > > EFI_INVALID_PARAMETER Protocol is already installed on the handle > > specified by Handle. > > > > If you have two separate UEFI drivers that install PciIo interfaces > > on handles, then their EFI_DRIVER_BINDING_PROTOCOL.Supported() > > methods may report success only on distinct sets of handles. There must be > > no overlap. > > > > But, in any case, I think it's very unusual to have two drivers that > > produce PciIo interfaces. According to the "Driver Writer's Guide > > for UEFI 2.3.1" (03/08/2012, Version 1.01), section "18.2 PCI Bus Drivers": > > > > TIP: PCI Bus Driver customizations are *strongly discouraged* > > because the PCI Bus Driver is designed to be conformant with > > the /PCI Specification/. Instead, focus platform specific > > customizations on the Root Bridge Driver that produced > > EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL and its PCI Device Drivers. > > > > > > [Shaveta] > > Yes, it is un-usual and we had discussed over it also. > > > > So the scenario is: > > ================ > > On LS2080 platform, we have real PCI controllers that have E1000 > > card on them(used for networking purposes) And USB and SATA controllers are > > on-board. > > So to provide SATA and USB, a PCIe emulation layer, a PCI IO > > protocol is installed in PciEmulation code. > > PciEmulation code is very thin layer that simply produce > > PciRootBridgeIo protocol and hence PCI IO protocol, Hence bypass the > > need of "real Pci Bus" code. > > > > Reference is taken from ArmJune platform code in EDK2. In it, it install : > > (1) PCI IO protocol using "gEfiPciIoProtocolGuid" in > > ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c > > (2) It also install " gEfiPciRootBridgeIoProtocolGuid" protocol, > > using which "PciBusDxe" will produce PciIo protocol > > > > The same we are doing for our platform. > > For real PCI controller, we have " installed Root Bridge PCI IO > > protocol with gEfiPciRootBridgeIoProtocolGuid" > > And for emulation layer, the code direcly install PCI IO protocol > > with gEfiPciIoProtocolGuid" > > > > Regards, > > Shaveta > > > > Laszlo > > > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
