On 02/16/16 09:06, Shaveta Leekha wrote: > Hi Laszlo, > > Please find my replies and few more doubts in-lined.
I cannot visually distinguish your comments from mine. Can you please resend your email with a mailer that supports sane quoting, or else mark each one of the paragraphs you are adding with [Shaveta]? Thanks Laszlo > > -----Original Message----- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Monday, February 15, 2016 4:42 PM > To: Shaveta Leekha <shaveta.lee...@nxp.com>; Bhupesh Sharma > <bhupesh.sha...@nxp.com>; Leif Lindholm <leif.lindh...@linaro.org> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> > Subject: Re: [edk2] SATA 3.0 AHCI host controller codebase > > On 02/15/16 06:52, Shaveta Leekha wrote: >> >> >> -----Original Message----- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Monday, February 08, 2016 1:20 PM >> To: Bhupesh Sharma <bhupesh.sha...@nxp.com>; Leif Lindholm >> <leif.lindh...@linaro.org>; Shaveta Leekha <shaveta.lee...@nxp.com> >> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> >> Subject: Re: [edk2] SATA 3.0 AHCI host controller codebase >> >> On 02/06/16 09:38, Bhupesh Sharma wrote: >>>> From: Laszlo Ersek >>>> Sent: Friday, February 05, 2016 2:27 AM >>>> >>>> On 02/03/16 22:39, Leif Lindholm wrote: >>>>> Hi Shaveta, >>>>> >>>>> On Tue, Feb 02, 2016 at 07:05:03AM +0000, Shaveta Leekha wrote: >>>>>> Is there some SATA 3.0 AHCI driver implementation in UEFI / EDK code? >>>>>> The one I need to write for our platform is not PCI based. >>>>>> >>>>>> I have seen few implementations in EDK2: >>>>>> DuetPkg/SataControllerDxe/SataController.c >>>>>> OvmfPkg/SataControllerDxe/SataController.c >>>>>> But in all of them SATA connectivity is via PCI Express switch. >>>>>> >>>>>> Kindly point me to some non-PCI based "SATA 3.0 AHCI driver code" >>>>>> for UEFI, if there is any such code. >>>>> >>>>> I have seen several such platforms implementing a "dummy" PCI >>>>> Express driver, simply translating PCI accesses to memory mapped >>>>> ones, and still making use of the MdeModulePkg/Bus/Ata/ libraries. >>>>> >>>>> You can see examples of PCI emulation in >>>>> Omap35xxPkg/PciEmulation/PciEmulation.c >>>>> and >>>>> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c >>>>> >>>>> As a side note, we really should have a common mmio-PCI emulation >>>>> library in core EDK2. >>>> >>>> Actually the driver stack rests upon the platform-specific PCI host >>>> bridge/root bridge driver (a DXE_DRIVER, i.e., one that doesn't bind >>>> other handles according to the UEFI Driver Model, but produces the >>>> Root Bridge IO protocols, and the Host Bridge Resource Allocation >>>> protocol(s), out of "thin air", in its entry point function). >>>> >>>> The PCI Bus driver (producing PciIo protocol instances) is platform- >>>> independent, and needs the previously mentioned driver. From PciIo >>>> upwards, it's all generic. (Well, I'll mention that there is no >>>> platform- independent SataControllerDxe in edk2. I don't recall the >>>> reason -- apologies --, but a reason *was* given for it.) >>>> >>>> Ray recently implemented a generic PCI host bridge / root bridge >>>> driver, in "MdeModulePkg/Bus/Pci/PciHostBridgeDxe". That driver delegates: >>>> >>>> - some of the platform specifics to the (also new) PciHostBridgeLib >>>> class, >>>> - PCI config space access to the PciSegmentLib class (there are, or can >>>> be made, library instances that provide 0xCF8/0xCFC, or MMCONFIG/ECAM >>>> based config space access), >>>> - IO port access to the CPU driver that provides the >>>> EFI_CPU_IO2_PROTOCOL. >>>> >>>> I believe that for a "single root bridge" system, this structure is >>>> generic enough. >>>> >>>> (Of course, nothing prevents a system from implementing PciIo >>>> independently, which "ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe" >>>> seems to do.) >>> >>> Thanks Laszlo and Leif. >>> >>> So, AFAIU there are two approaches available on implementing the SATA >>> (AHCI based) host controller on ARM based SoCs: >>> >>> 1. Either, we can use the PCIe emulation layers to emulation a SATA >>> controller sitting as a PciIO device on top of the PCIe emulation >>> layer. So, eventually we will be using the ATA Bus layer inside >>> MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf >>> to get the AHCI-ATA bus services. >>> >>> 2. Or, we can implement the AHCI based SATA controller as a block >>> device (exposing the BLOCK IO protocol) and implemented on the lines >>> of a SD/MMC card like driver. The BLOCK IO protocol can then be used by a >>> FatPkg like layer to provide a support for FAT32 filesystem over the SATA >>> driver. >>> >>> Both the above approaches have their own merits and demerits. While >>> approach 1 might introduce extra memory allocation/housekeeping overheads >>> for PCIe emulation layer, approach 2 might not be compatible to all UEFI >>> shell applications that want to use a underlying SATA HDD support. >>> >>> So, this brings forward the question, as to which UEFI shell applications >>> (e.g. GRUB2) can work with approach 2 and which cannot. >>> Are there any other obvious disadvantages to approach 2? >>> >>> Please share your thoughts. >> >> I don't know many UEFI applications, but the few I know, should be happy >> with the BlockIo + above protocols. At least I can't name any obvious >> disadvantages. >> >> Thanks >> Laszlo >> >>> >>> Regards, >>> Bhupesh >>> >> >> Hi Laszlo, Leif, >> >> Thanks for your feedbacks. >> >> As per above discussion, we are following 1st approach for implementing SATA >> driver for our platform. >> That is: >> >> => We will create a PCIe emulation layer to emulate that SATA controller >> sitting as a PciIO device. >> For it we can take the reference from >> "Omap35xxPkg/PciEmulation/PciEmulation.c", as the generic PCI driver >> "MdeModulePkg/Bus/Pci/PciHostBridgeDxe" >> Seems to be for some real PCI Root bridge, not for emulated one, is >> this understanding correct? > > "MdeModulePkg/Bus/Pci/PciHostBridgeDxe" is indeed meant as a "real" PCI host > bridge / root bridge driver, but it delegates some aspects to the platform, > via the PciHostBridgeLib class. (As I wrote above.) > > I think it might be worthwhile to investigate if this driver could cover your > needs. The question is if you can push down *all* the emulation you need into > libraries and drivers that PciHostBridgeDxe uses to do its work. For example, > you can implement > - a PciSegmentLib instance to provide PCI config space access, > - a PciHostBridgeLib instance to list the root bridges with their > apertures, and > - a CPU IO driver to produce the EFI_CPU_IO2_PROTOCOL, where the > Io.Read() and Io.Write() members would be likely emulated with > accesses to a special MMIO range (or just refused as EFI_UNSUPPORTED). > > Sure, I will investigate this driver further as per our need. But I have one > doubt here, > In case I use " Omap35xxPkg/PciEmulation/PciEmulation.c" kind of emulation > code, which is not for real PCI root bridge and > doesnot produce "RootBridgeResourceAllocation protocol", it only produces > RootBridgePciIo protocol, will it still work? > > >> >> => Also we may use "MdeModulePkg/Bus/Ata/AtaBusDxe/" code for ATA bus >> implementation. >> Does this code follow AHCI 1.3 spec/any such standard OR AHCI 1.3 >> specification need to be taken care at SATADxe driver level, >> By keeping ATA bus code generic? > > I recommend looking at git commit b82802b83f06 ("OvmfPkg: enable SATA > controller") to see how the protocols stack up. > > The only AHCI register that OvmfPkg/SataControllerDxe accesses itself is the > CAP ("HBA Capabilities"), to get the number of ports, and to see if port > multiplication is supported. These infos are used for implementing > EFI_IDE_CONTROLLER_INIT_PROTOCOL. > > The real AHCI stuff is implemented by > "MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf". > > The driver you mention, "MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf", > comes on top of that. > > So, I guess the answer to your question is, "yes, AtaBusDxe is generic, and > no, SataControllerDxe *also* doesn't need (much) AHCI knowledge -- that's in > the middle, in the AtaAtapiPassThru driver". > > True. From " OvmfPkg: enable SATA controller" commit, it clear the stack as > you have mentioned. > > But I have seen one more SATA driver: > commit f63424474e8b022c0b7675d282c9b4c255a95ff4 > Author: Olivier Martin <olivier.mar...@arm.com> > Date: Mon May 11 17:50:27 2015 +0000 > > EmbeddedPkg: Added SATA Silicon Image driver > > Note: This is the same SATA controller present on Juno R1. > > > In this " EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c", it directly > install " AtaPassThruProtocol". > In this case, does it skip " AtaAtapiPassThru driver" layer in between? Is > this working? > Also code in " AtaAtapiPassThru driver" layer also use PciIo protocol. > Which of the path is tested? > >> >> => SATA Dxe driver will consume PciIo protocol > > Yes. > >> and will produce "AtaPassThruProtocol" for ATA bus code to use. > > Not exactly -- at least looking at the current in-tree example -- see the > OVMF commit I referenced above. The SATA driver would produce > EFI_IDE_CONTROLLER_INIT_PROTOCOL, AtaAtapiPassThru would produce > EFI_ATA_PASS_THRU_PROTOCOL on top, separately, for AtaBusDxe to consume. > >> => All the chipset specific SATA controller initialization part will be >> there in SATADxe driver. > > I think so, yes. In OVMF's case, this is minimal. > > OK > >> Is this flow and understanding correct for a platform SATA controller driver? > > I think the only significant omission was the AtaAtapiPassThru driver in the > middle. > > Thanks, > Shaveta > > Thanks > Laszlo > >> >> Thanks and Regards, >> Shaveta >> > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
