-----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?
=> 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?
=> SATA Dxe driver will consume PciIo protocol and will produce
"AtaPassThruProtocol" for ATA bus code to use.
=> All the chipset specific SATA controller initialization part will be there
in SATADxe driver.
Is this flow and understanding correct for a platform SATA controller driver?
Thanks and Regards,
Shaveta
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
