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 > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
