> From: Laszlo Ersek [mailto:[email protected]] > Sent: Monday, February 08, 2016 1:20 PM > > 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. Leif - Do you see any concerns to enable a 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 - so that it can be reused across ARM SOCs having SATA host controller support (this would mainly be a candidate for OpenPlatform.git then). I can only think of things like: - Lack of plug-n-play support that we can probably get with a PCIe emulation like layer - Some UEFI applications not working with the implementation proposed above. Regards, Bhupesh _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
