Hi Ard,
I am working on support for AHCI controller for my ARMv8 platform and I decide to use PciEmulation approach. I was able to run XHCI via PciEmulation without problems, but unfortunately with AHCI it isn't working.
Controller is compatible with AHCI specification. It isn't dma-coherent and I think that problem lies here. Initialization timeouts in below part of code:
// // Enable FIS Receive DMA engine for the first D2H FIS. // Offset = EFI_AHCI_PORT_START + Port * EFI_AHCI_PORT_REG_WIDTH + EFI_AHCI_PORT_CMD; AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE); Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT ); if (EFI_ERROR (Status)) { continue; }
Where do you think may be problem? Do you have any tips what should I try to do?
Thanks, Jan
On 4 May 2016 at 18:42, Jan Dąbroś jsd@semihalf.com wrote:
Hi Ard,
I am working on support for AHCI controller for my ARMv8 platform and I decide to use PciEmulation approach. I was able to run XHCI via PciEmulation without problems, but unfortunately with AHCI it isn't working.
Controller is compatible with AHCI specification. It isn't dma-coherent and I think that problem lies here. Initialization timeouts in below part of code:
// // Enable FIS Receive DMA engine for the first D2H FIS. // Offset = EFI_AHCI_PORT_START + Port * EFI_AHCI_PORT_REG_WIDTH +EFI_AHCI_PORT_CMD; AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE); Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT ); if (EFI_ERROR (Status)) { continue; }
Where do you think may be problem? Do you have any tips what should I try to do?
Are you using DmaLib? If you are, it is simply a matter of using ArmDmaLib, which uses uncached memory and/or explicit cache maintenance to perform non-coherent DMA. Basically, you need to implement the Allocate, free, map and unmap functions in the PCI I/O protocol using DmaLib methods, so you can use either coherent or non-coherent DMA depending on which version of the library you bind your driver to.
On 4 May 2016 at 18:52, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 4 May 2016 at 18:42, Jan Dąbroś jsd@semihalf.com wrote:
Hi Ard,
I am working on support for AHCI controller for my ARMv8 platform and I decide to use PciEmulation approach. I was able to run XHCI via PciEmulation without problems, but unfortunately with AHCI it isn't working.
Controller is compatible with AHCI specification. It isn't dma-coherent and I think that problem lies here. Initialization timeouts in below part of code:
// // Enable FIS Receive DMA engine for the first D2H FIS. // Offset = EFI_AHCI_PORT_START + Port * EFI_AHCI_PORT_REG_WIDTH +EFI_AHCI_PORT_CMD; AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE); Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT ); if (EFI_ERROR (Status)) { continue; }
Where do you think may be problem? Do you have any tips what should I try to do?
Are you using DmaLib? If you are, it is simply a matter of using ArmDmaLib, which uses uncached memory and/or explicit cache maintenance to perform non-coherent DMA. Basically, you need to implement the Allocate, free, map and unmap functions in the PCI I/O protocol using DmaLib methods, so you can use either coherent or non-coherent DMA depending on which version of the library you bind your driver to.
Also, make sure you set any I/O align fields in the protocol structures according to the CWG (max cacheline size) of your SoC. This will result in fewer cases where ArmDmaLib needs to use bounce buffering for streaming DMA.
Thanks for quick response.
I am using ArmDmaLib as DmaLib (also for XHCI), so it looks like problem other than cache coherency.
Regards, Jan W dniu środa, 4 maja 2016 Ard Biesheuvel ard.biesheuvel@linaro.org napisał(a):
On 4 May 2016 at 18:52, Ard Biesheuvel <ard.biesheuvel@linaro.org javascript:;> wrote:
On 4 May 2016 at 18:42, Jan Dąbroś <jsd@semihalf.com javascript:;>
wrote:
Hi Ard,
I am working on support for AHCI controller for my ARMv8 platform and I decide to use PciEmulation approach. I was able to run XHCI via PciEmulation without problems, but unfortunately with AHCI it isn't working.
Controller is compatible with AHCI specification. It isn't dma-coherent and I think that problem lies here. Initialization timeouts in below part of code:
// // Enable FIS Receive DMA engine for the first D2H FIS. // Offset = EFI_AHCI_PORT_START + Port * EFI_AHCI_PORT_REG_WIDTH +EFI_AHCI_PORT_CMD; AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE); Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT ); if (EFI_ERROR (Status)) { continue; }
Where do you think may be problem? Do you have any tips what should I try to do?
Are you using DmaLib? If you are, it is simply a matter of using ArmDmaLib, which uses uncached memory and/or explicit cache maintenance to perform non-coherent DMA. Basically, you need to implement the Allocate, free, map and unmap functions in the PCI I/O protocol using DmaLib methods, so you can use either coherent or non-coherent DMA depending on which version of the library you bind your driver to.
Also, make sure you set any I/O align fields in the protocol structures according to the CWG (max cacheline size) of your SoC. This will result in fewer cases where ArmDmaLib needs to use bounce buffering for streaming DMA.
Hi,
Just in order to provide full background - XHCI works properly using same PciEmulation and ArmDmaLib methods. Moreover it all behaves same way after disabling cache.
Best regards, Marcin
2016-05-04 19:21 GMT+02:00 Jan Dąbroś jsd@semihalf.com:
Thanks for quick response.
I am using ArmDmaLib as DmaLib (also for XHCI), so it looks like problem other than cache coherency.
Regards, Jan W dniu środa, 4 maja 2016 Ard Biesheuvel ard.biesheuvel@linaro.org napisał(a):
On 4 May 2016 at 18:52, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 4 May 2016 at 18:42, Jan Dąbroś jsd@semihalf.com wrote:
Hi Ard,
I am working on support for AHCI controller for my ARMv8 platform and I decide to use PciEmulation approach. I was able to run XHCI via PciEmulation without problems, but unfortunately with AHCI it isn't working.
Controller is compatible with AHCI specification. It isn't dma-coherent and I think that problem lies here. Initialization timeouts in below part of code:
// // Enable FIS Receive DMA engine for the first D2H FIS. // Offset = EFI_AHCI_PORT_START + Port * EFI_AHCI_PORT_REG_WIDTH +EFI_AHCI_PORT_CMD; AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE); Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT ); if (EFI_ERROR (Status)) { continue; }
Where do you think may be problem? Do you have any tips what should I try to do?
Are you using DmaLib? If you are, it is simply a matter of using ArmDmaLib, which uses uncached memory and/or explicit cache maintenance to perform non-coherent DMA. Basically, you need to implement the Allocate, free, map and unmap functions in the PCI I/O protocol using DmaLib methods, so you can use either coherent or non-coherent DMA depending on which version of the library you bind your driver to.
Also, make sure you set any I/O align fields in the protocol structures according to the CWG (max cacheline size) of your SoC. This will result in fewer cases where ArmDmaLib needs to use bounce buffering for streaming DMA.
On 4 May 2016 at 19:21, Jan Dąbroś jsd@semihalf.com wrote:
Thanks for quick response.
I am using ArmDmaLib as DmaLib (also for XHCI), so it looks like problem other than cache coherency.
Indeed. Also, it seems the operation where the hang occurs does not involve a DMA transaction, does it? Can you confirm that the AHCI MMIO space is mapped correctly?
W dniu środa, 4 maja 2016 Ard Biesheuvel ard.biesheuvel@linaro.org napisał(a):
On 4 May 2016 at 18:52, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 4 May 2016 at 18:42, Jan Dąbroś jsd@semihalf.com wrote:
Hi Ard,
I am working on support for AHCI controller for my ARMv8 platform and I decide to use PciEmulation approach. I was able to run XHCI via PciEmulation without problems, but unfortunately with AHCI it isn't working.
Controller is compatible with AHCI specification. It isn't dma-coherent and I think that problem lies here. Initialization timeouts in below part of code:
// // Enable FIS Receive DMA engine for the first D2H FIS. // Offset = EFI_AHCI_PORT_START + Port * EFI_AHCI_PORT_REG_WIDTH +EFI_AHCI_PORT_CMD; AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE); Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT ); if (EFI_ERROR (Status)) { continue; }
Where do you think may be problem? Do you have any tips what should I try to do?
Are you using DmaLib? If you are, it is simply a matter of using ArmDmaLib, which uses uncached memory and/or explicit cache maintenance to perform non-coherent DMA. Basically, you need to implement the Allocate, free, map and unmap functions in the PCI I/O protocol using DmaLib methods, so you can use either coherent or non-coherent DMA depending on which version of the library you bind your driver to.
Also, make sure you set any I/O align fields in the protocol structures according to the CWG (max cacheline size) of your SoC. This will result in fewer cases where ArmDmaLib needs to use bounce buffering for streaming DMA.
Hi Ard,
2016-05-04 21:28 GMT+02:00 Ard Biesheuvel ard.biesheuvel@linaro.org:
On 4 May 2016 at 19:21, Jan Dąbroś jsd@semihalf.com wrote:
Thanks for quick response.
I am using ArmDmaLib as DmaLib (also for XHCI), so it looks like problem other than cache coherency.
Indeed. Also, it seems the operation where the hang occurs does not involve a DMA transaction, does it?
Yes, it doesn't involve DMA transaction, above flag should be set automaticaly (in less than 500ms) after writing '1' to PxCMD.FRE. But after commenting out waiting for this flag (e.g. Linux driver doesn't check this), initialization continues until the point where transfer from device should be performed (and there is no response from SATA disk). Maybe it is improper address mapping (DmaMap function) - is there simple way to check this?
Can you confirm that the AHCI MMIO space is mapped correctly?
Yes, MMIO space is mapped correctly. For example link on port is seen up if device is connected.
Best regards, Marcin
Hi,
I too am facing same error while running AHCI mode for SATA controller on my platform. I am not using DMA for any SATA controller's register read/write, instead using mmio read and write which is working fine.
What can be the probable issue. When in the code:
Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT );
Value "400010" is written on command register at offset 0x18h of Port 0 (MMIO address 3200118 for SATA 1 controller in my platform)
Though no hang occur bur FR bit is not getting set in "AhciWaitMmioSet"
"FIS Receive Running (FR): When set, the FIS Receive DMA engine for the port is running"
Thanks and Regards, Shaveta
-----Original Message----- From: Linaro-uefi [mailto:linaro-uefi-bounces@lists.linaro.org] On Behalf Of Ard Biesheuvel Sent: Thursday, May 05, 2016 12:59 AM To: Jan Dąbroś jsd@semihalf.com Cc: Haim Boot hayim@marvell.com; Neta Zur Hershkovits neta@marvell.com; Linaro UEFI Mailman List linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] PciEmulation - problem with AHCI
On 4 May 2016 at 19:21, Jan Dąbroś jsd@semihalf.com wrote:
Thanks for quick response.
I am using ArmDmaLib as DmaLib (also for XHCI), so it looks like problem other than cache coherency.
Indeed. Also, it seems the operation where the hang occurs does not involve a DMA transaction, does it? Can you confirm that the AHCI MMIO space is mapped correctly?
W dniu środa, 4 maja 2016 Ard Biesheuvel ard.biesheuvel@linaro.org napisał(a):
On 4 May 2016 at 18:52, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 4 May 2016 at 18:42, Jan Dąbroś jsd@semihalf.com wrote:
Hi Ard,
I am working on support for AHCI controller for my ARMv8 platform and I decide to use PciEmulation approach. I was able to run XHCI via PciEmulation without problems, but unfortunately with AHCI it isn't working.
Controller is compatible with AHCI specification. It isn't dma-coherent and I think that problem lies here. Initialization timeouts in below part of code:
// // Enable FIS Receive DMA engine for the first D2H FIS. // Offset = EFI_AHCI_PORT_START + Port *EFI_AHCI_PORT_REG_WIDTH + EFI_AHCI_PORT_CMD; AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE); Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT ); if (EFI_ERROR (Status)) { continue; }
Where do you think may be problem? Do you have any tips what should I try to do?
Are you using DmaLib? If you are, it is simply a matter of using ArmDmaLib, which uses uncached memory and/or explicit cache maintenance to perform non-coherent DMA. Basically, you need to implement the Allocate, free, map and unmap functions in the PCI I/O protocol using DmaLib methods, so you can use either coherent or non-coherent DMA depending on which version of the library you bind your driver to.
Also, make sure you set any I/O align fields in the protocol structures according to the CWG (max cacheline size) of your SoC. This will result in fewer cases where ArmDmaLib needs to use bounce buffering for streaming DMA.
_______________________________________________ Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
Hi Shaveta,
I also use mmio not DMA for writing to SATA controller's registers.
Despite timeout (I comment out above code), it looks like problem with exchange of Frame Information Structures, memory isn't updated by hardware properly.
Regards, Jan
2016-05-06 11:15 GMT+02:00 Shaveta Leekha shaveta.leekha@nxp.com:
Hi,
I too am facing same error while running AHCI mode for SATA controller on my platform. I am not using DMA for any SATA controller's register read/write, instead using mmio read and write which is working fine.
What can be the probable issue. When in the code:
Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT );
Value "400010" is written on command register at offset 0x18h of Port 0 (MMIO address 3200118 for SATA 1 controller in my platform)
Though no hang occur bur FR bit is not getting set in "AhciWaitMmioSet"
"FIS Receive Running (FR): When set, the FIS Receive DMA engine for the port is running"
Thanks and Regards, Shaveta
-----Original Message----- From: Linaro-uefi [mailto:linaro-uefi-bounces@lists.linaro.org] On Behalf Of Ard Biesheuvel Sent: Thursday, May 05, 2016 12:59 AM To: Jan Dąbroś jsd@semihalf.com Cc: Haim Boot hayim@marvell.com; Neta Zur Hershkovits neta@marvell.com; Linaro UEFI Mailman List linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] PciEmulation - problem with AHCI
On 4 May 2016 at 19:21, Jan Dąbroś jsd@semihalf.com wrote:
Thanks for quick response.
I am using ArmDmaLib as DmaLib (also for XHCI), so it looks like problem other than cache coherency.
Indeed. Also, it seems the operation where the hang occurs does not involve a DMA transaction, does it? Can you confirm that the AHCI MMIO space is mapped correctly?
W dniu środa, 4 maja 2016 Ard Biesheuvel ard.biesheuvel@linaro.org napisał(a):
On 4 May 2016 at 18:52, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 4 May 2016 at 18:42, Jan Dąbroś jsd@semihalf.com wrote:
Hi Ard,
I am working on support for AHCI controller for my ARMv8 platform and I decide to use PciEmulation approach. I was able to run XHCI via PciEmulation without problems, but unfortunately with AHCI it isn't working.
Controller is compatible with AHCI specification. It isn't dma-coherent and I think that problem lies here. Initialization timeouts in below part of code:
// // Enable FIS Receive DMA engine for the first D2H FIS. // Offset = EFI_AHCI_PORT_START + Port *EFI_AHCI_PORT_REG_WIDTH + EFI_AHCI_PORT_CMD; AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE); Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT ); if (EFI_ERROR (Status)) { continue; }
Where do you think may be problem? Do you have any tips what should I try to do?
Are you using DmaLib? If you are, it is simply a matter of using ArmDmaLib, which uses uncached memory and/or explicit cache maintenance to perform non-coherent DMA. Basically, you need to implement the Allocate, free, map and unmap functions in the PCI I/O protocol using DmaLib methods, so you can use either coherent or non-coherent DMA depending on which version of the library you bind your driver to.
Also, make sure you set any I/O align fields in the protocol structures according to the CWG (max cacheline size) of your SoC. This will result in fewer cases where ArmDmaLib needs to use bounce buffering for streaming DMA.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
On 6 May 2016 at 12:08, Jan Dąbroś jsd@semihalf.com wrote:
Hi Shaveta,
I also use mmio not DMA for writing to SATA controller's registers.
Despite timeout (I comment out above code), it looks like problem with exchange of Frame Information Structures, memory isn't updated by hardware properly.
When you say 'memory isn't updated by hardware properly', that suggests there is some kind of bus mastering going on. Which memory are you talking about here? Is this memory that has been allocated by ArmDmaLib's AllocateBuffer()?
2016-05-06 11:15 GMT+02:00 Shaveta Leekha shaveta.leekha@nxp.com:
Hi,
I too am facing same error while running AHCI mode for SATA controller on my platform. I am not using DMA for any SATA controller's register read/write, instead using mmio read and write which is working fine.
What can be the probable issue. When in the code:
Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT );
Value "400010" is written on command register at offset 0x18h of Port 0 (MMIO address 3200118 for SATA 1 controller in my platform)
Though no hang occur bur FR bit is not getting set in "AhciWaitMmioSet"
"FIS Receive Running (FR): When set, the FIS Receive DMA engine for the port is running"
Thanks and Regards, Shaveta
-----Original Message----- From: Linaro-uefi [mailto:linaro-uefi-bounces@lists.linaro.org] On Behalf Of Ard Biesheuvel Sent: Thursday, May 05, 2016 12:59 AM To: Jan Dąbroś jsd@semihalf.com Cc: Haim Boot hayim@marvell.com; Neta Zur Hershkovits neta@marvell.com; Linaro UEFI Mailman List linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] PciEmulation - problem with AHCI
On 4 May 2016 at 19:21, Jan Dąbroś jsd@semihalf.com wrote:
Thanks for quick response.
I am using ArmDmaLib as DmaLib (also for XHCI), so it looks like problem other than cache coherency.
Indeed. Also, it seems the operation where the hang occurs does not involve a DMA transaction, does it? Can you confirm that the AHCI MMIO space is mapped correctly?
W dniu środa, 4 maja 2016 Ard Biesheuvel ard.biesheuvel@linaro.org napisał(a):
On 4 May 2016 at 18:52, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 4 May 2016 at 18:42, Jan Dąbroś jsd@semihalf.com wrote:
Hi Ard,
I am working on support for AHCI controller for my ARMv8 platform and I decide to use PciEmulation approach. I was able to run XHCI via PciEmulation without problems, but unfortunately with AHCI it isn't working.
Controller is compatible with AHCI specification. It isn't dma-coherent and I think that problem lies here. Initialization timeouts in below part of code:
// // Enable FIS Receive DMA engine for the first D2H FIS. // Offset = EFI_AHCI_PORT_START + Port *EFI_AHCI_PORT_REG_WIDTH + EFI_AHCI_PORT_CMD; AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE); Status = AhciWaitMmioSet ( PciIo, Offset, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR, EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT ); if (EFI_ERROR (Status)) { continue; }
Where do you think may be problem? Do you have any tips what should I try to do?
Are you using DmaLib? If you are, it is simply a matter of using ArmDmaLib, which uses uncached memory and/or explicit cache maintenance to perform non-coherent DMA. Basically, you need to implement the Allocate, free, map and unmap functions in the PCI I/O protocol using DmaLib methods, so you can use either coherent or non-coherent DMA depending on which version of the library you bind your driver to.
Also, make sure you set any I/O align fields in the protocol structures according to the CWG (max cacheline size) of your SoC. This will result in fewer cases where ArmDmaLib needs to use bounce buffering for streaming DMA.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
When you say 'memory isn't updated by hardware properly', that suggests there is some kind of bus mastering going on. Which memory are you talking about here? Is this memory that has been allocated by ArmDmaLib's AllocateBuffer()?
Yes, I mean memory buffers allocated with ArmDmaLib's AllocateBuffer(). Those buffers' addresses are entered into SATA controller register's. Buffers should be updated (after performing necessary init) with data from hardware, but in my case, it doesn't happen.
-----Original Message----- From: Jan Dąbroś [mailto:jsd@semihalf.com] Sent: Friday, May 06, 2016 3:54 PM To: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Shaveta Leekha shaveta.leekha@nxp.com; Linaro UEFI Mailman List linaro-uefi@lists.linaro.org; Haim Boot hayim@marvell.com; Neta Zur Hershkovits neta@marvell.com Subject: Re: [Linaro-uefi] PciEmulation - problem with AHCI
When you say 'memory isn't updated by hardware properly', that suggests there is some kind of bus mastering going on. Which memory are you talking about here? Is this memory that has been allocated by ArmDmaLib's AllocateBuffer()?
Yes, I mean memory buffers allocated with ArmDmaLib's AllocateBuffer(). Those buffers' addresses are entered into SATA controller register's. Buffers should be updated (after performing necessary init) with data from hardware, but in my case, it doesn't happen.
[Shaveta] Does it all happen before device probing?
I mean, what if there is no SATA device attached? Then this code would not work, right?
Regards, Shaveta
Yes, I mean memory buffers allocated with ArmDmaLib's AllocateBuffer(). Those buffers' addresses are entered into SATA controller register's. Buffers should be updated (after performing necessary init) with data from hardware, but in my case, it doesn't happen.
[Shaveta] Does it all happen before device probing?
I mean, what if there is no SATA device attached? Then this code would not work, right?
It happens after probing. If no SATA device is attached, we break execution and go to next port's init sequence. Link is detected properly.
-----Original Message----- From: Jan Dąbroś [mailto:jsd@semihalf.com] Sent: Friday, May 06, 2016 4:01 PM To: Shaveta Leekha shaveta.leekha@nxp.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org; Linaro UEFI Mailman List linaro-uefi@lists.linaro.org; Haim Boot hayim@marvell.com; Neta Zur Hershkovits neta@marvell.com Subject: Re: [Linaro-uefi] PciEmulation - problem with AHCI
Yes, I mean memory buffers allocated with ArmDmaLib's AllocateBuffer(). Those buffers' addresses are entered into SATA controller register's. Buffers should be updated (after performing necessary init) with data from hardware, but in my case, it doesn't happen.
[Shaveta] Does it all happen before device probing?
I mean, what if there is no SATA device attached? Then this code would not work, right?
It happens after probing. If no SATA device is attached, we break execution and go to next port's init sequence. Link is detected properly.
[Shaveta] But in my case, there is no device attached.
So for this code to run successfully, there should be a device at SATA interface. Is that correct ??
Because "When PxCMD.FRE is set, it cause PxCMD.FR to be set to ‘1’. Only then HBA receives FISes from the device and copies them into system memory."
In my case, FR is not getting set.
Regards, Shaveta
Let me clear our discussion a little bit.
Checking PxCMD.FR is performed even if there is no device at port.
Because "When PxCMD.FRE is set, it cause PxCMD.FR to be set to ‘1’. Only then HBA receives FISes from the device and copies them into system memory."
In my case, FR is not getting set.
Exactly the same is in my case, setting PxCMD.FRE doesn't cause PxCMD.FR to be set to ‘1’. Since reference driver in Linux doesn't check PxCMD.FR, I assume that it isn't necessary for receiving FISes (I mean that it is enough to set PxCMD.FRE. BTW: "Only then HBA receives FISes from the device and copies them into system memory." is this sentence taken from AHCI Spec?). This assumption lets me comment-out above code, but further in init sequence I have another problem that, data from device isn't copied into system memory.
Do you think that even though PxCMD.FRE is set, receiving FISes is blocked? Do you know what may cause PxCMD.FR to stay unset?
Thanks, Jan
I am finally able to run SATA on my platform. It turned out that bad working was caused by two independent factors.
1. PxCMD.FR staying unset, what was discussed here It isn't necessary to wait for above bit being set, only necessity is to set PxCMD.FRE, which enable FIS transfers. I didn't find in AHCI Spec anything about polling for PxCMD.FR, but need to dig into deeper.
2. Conditional setting AE bit Below code checks in CAP register if it is necessary to set AE.
Capability = AhciReadReg (PciIo, EFI_AHCI_CAPABILITY_OFFSET);
if ((Capability & EFI_AHCI_CAP_SAM) == 0) { AhciOrReg (PciIo, EFI_AHCI_GHC_OFFSET, EFI_AHCI_GHC_ENABLE); }
In my case EFI_AHCI_CAP_SAM was set and writing to EFI_AHCI_GHC_ENABLE wasn't performed. This caused defective work of whole controller. AHCI Spec says that setting AE bit should be performed *before* any other writes to AHCI registers, so I think it will be better to perform it before reading CAP registers (and remove 'if' statements). Reference drivers in Linux and Uboot always set AE bit, without any additional conditions.
Patch with above fixes will be submitted for edk2 RFC next week.
Thanks and Regards, Jan
2016-05-06 12:55 GMT+02:00 Jan Dąbroś jsd@semihalf.com:
Let me clear our discussion a little bit.
Checking PxCMD.FR is performed even if there is no device at port.
Because "When PxCMD.FRE is set, it cause PxCMD.FR to be set to ‘1’. Only then HBA receives FISes from the device and copies them into system memory."
In my case, FR is not getting set.
Exactly the same is in my case, setting PxCMD.FRE doesn't cause PxCMD.FR to be set to ‘1’. Since reference driver in Linux doesn't check PxCMD.FR, I assume that it isn't necessary for receiving FISes (I mean that it is enough to set PxCMD.FRE. BTW: "Only then HBA receives FISes from the device and copies them into system memory." is this sentence taken from AHCI Spec?). This assumption lets me comment-out above code, but further in init sequence I have another problem that, data from device isn't copied into system memory.
Do you think that even though PxCMD.FRE is set, receiving FISes is blocked? Do you know what may cause PxCMD.FR to stay unset?
Thanks, Jan
Thanks Great Jan!
I am still struggling to make it work.
In my case also "PxCMD.FR stay unset" so I have removed that test code (as suggested for the time being). Similarly In my case EFI_AHCI_CAP_SAM was set and writing to EFI_AHCI_GHC_ENABLE wasn't not getting performed. So I have "ENABLED AE" also. So the code so far is installing "gEfiAtaPassThruProtocolGuid" Protocol.
But somehow, in " AtaBusDriverBindingSupported" , this protocol is not getting opened. Status = gBS->OpenProtocol ( Controller, &gEfiAtaPassThruProtocolGuid, (VOID **) &AtaPassThru, This->DriverBindingHandle, Controller, EFI_OPEN_PROTOCOL_BY_DRIVER );
Above code throws an error.
Any idea about that?
Thanks and Regards, Shaveta
-----Original Message----- From: Jan Dąbroś [mailto:jsd@semihalf.com] Sent: Friday, May 06, 2016 8:10 PM To: Shaveta Leekha shaveta.leekha@nxp.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org; Linaro UEFI Mailman List linaro-uefi@lists.linaro.org; Haim Boot hayim@marvell.com; Neta Zur Hershkovits neta@marvell.com Subject: Re: [Linaro-uefi] PciEmulation - problem with AHCI
I am finally able to run SATA on my platform. It turned out that bad working was caused by two independent factors.
1. PxCMD.FR staying unset, what was discussed here It isn't necessary to wait for above bit being set, only necessity is to set PxCMD.FRE, which enable FIS transfers. I didn't find in AHCI Spec anything about polling for PxCMD.FR, but need to dig into deeper.
2. Conditional setting AE bit Below code checks in CAP register if it is necessary to set AE.
Capability = AhciReadReg (PciIo, EFI_AHCI_CAPABILITY_OFFSET);
if ((Capability & EFI_AHCI_CAP_SAM) == 0) { AhciOrReg (PciIo, EFI_AHCI_GHC_OFFSET, EFI_AHCI_GHC_ENABLE); }
In my case EFI_AHCI_CAP_SAM was set and writing to EFI_AHCI_GHC_ENABLE wasn't performed. This caused defective work of whole controller. AHCI Spec says that setting AE bit should be performed *before* any other writes to AHCI registers, so I think it will be better to perform it before reading CAP registers (and remove 'if' statements). Reference drivers in Linux and Uboot always set AE bit, without any additional conditions.
Patch with above fixes will be submitted for edk2 RFC next week.
Thanks and Regards, Jan
2016-05-06 12:55 GMT+02:00 Jan Dąbroś jsd@semihalf.com:
Let me clear our discussion a little bit.
Checking PxCMD.FR is performed even if there is no device at port.
Because "When PxCMD.FRE is set, it cause PxCMD.FR to be set to ‘1’. Only then HBA receives FISes from the device and copies them into system memory."
In my case, FR is not getting set.
Exactly the same is in my case, setting PxCMD.FRE doesn't cause PxCMD.FR to be set to ‘1’. Since reference driver in Linux doesn't check PxCMD.FR, I assume that it isn't necessary for receiving FISes (I mean that it is enough to set PxCMD.FRE. BTW: "Only then HBA receives FISes from the device and copies them into system memory." is this sentence taken from AHCI Spec?). This assumption lets me comment-out above code, but further in init sequence I have another problem that, data from device isn't copied into system memory.
Do you think that even though PxCMD.FRE is set, receiving FISes is blocked? Do you know what may cause PxCMD.FR to stay unset?
Thanks, Jan
Hi Shaveta,
inline
2016-05-09 12:05 GMT+02:00 Shaveta Leekha shaveta.leekha@nxp.com:
Thanks Great Jan!
I am still struggling to make it work.
In my case also "PxCMD.FR stay unset" so I have removed that test code (as suggested for the time being).
Do you notice that besides initialization, this polling is performed also in AhciEnableFisReceive () ?
Similarly In my case EFI_AHCI_CAP_SAM was set and writing to EFI_AHCI_GHC_ENABLE wasn't not getting performed. So I have "ENABLED AE" also.
Just in case - do you notice, that it is also performed in AhciReset function?
So the code so far is installing "gEfiAtaPassThruProtocolGuid" Protocol.
But somehow, in " AtaBusDriverBindingSupported" , this protocol is not getting opened. Status = gBS->OpenProtocol ( Controller, &gEfiAtaPassThruProtocolGuid, (VOID **) &AtaPassThru, This->DriverBindingHandle, Controller, EFI_OPEN_PROTOCOL_BY_DRIVER );
Above code throws an error.
Any idea about that?
I didn't have such error, but can you provide returned Error Code? It may help.
Regards, Jan
The error I am getting is:
gEfiAtaPassThruProtocolGuid couldnt opened: Unsupported
from "AtaBusDriverBindingSupported" code.
Whereas I have added some debug prints in "AtaAtapiPassThruStart" function as:
DEBUG ((EFI_D_INFO, "==AtaAtapiPassThru Start== Install gEfiAtaPassThruProtocolGuid\n")); Status = gBS->InstallMultipleProtocolInterfaces ( &Controller, &gEfiAtaPassThruProtocolGuid, &(Instance->AtaPassThru), &gEfiExtScsiPassThruProtocolGuid, &(Instance->ExtScsiPassThru), NULL ); ASSERT_EFI_ERROR (Status);
DEBUG ((EFI_D_INFO, "==AtaAtapiPassThru Start== gEfiAtaPassThruProtocolGuid Installed \n")); DEBUG ((EFI_D_INFO, "==AtaAtapiPassThru Start== Returning Status :%r\n", Status));
UEFI runtime logs are:
==AtaAtapiPassThru Start== Install gEfiAtaPassThruProtocolGuid InstallProtocolInterface: 1D3DE7F0-0807-424F-AA69-11A54E19A46F 836EBFD8C0 InstallProtocolInterface: 143B7632-B81B-4CB7-ABD3-B625A5B9BFFE 836EBFD910 ==AtaAtapiPassThru Start== gEfiAtaPassThruProtocolGuid Installed ==AtaAtapiPassThru Start== Returning Status :Success
they show that the protocol has been installed properly. Then why it couldn't get opened?
NOTE: no SATA device is attached currently.
Regards, Shaveta
-----Original Message----- From: Jan Dąbroś [mailto:jsd@semihalf.com] Sent: Monday, May 09, 2016 4:30 PM To: Shaveta Leekha shaveta.leekha@nxp.com Cc: Ard Biesheuvel ard.biesheuvel@linaro.org; Linaro UEFI Mailman List linaro-uefi@lists.linaro.org; Haim Boot hayim@marvell.com; Neta Zur Hershkovits neta@marvell.com Subject: Re: [Linaro-uefi] PciEmulation - problem with AHCI
Hi Shaveta,
inline
2016-05-09 12:05 GMT+02:00 Shaveta Leekha shaveta.leekha@nxp.com:
Thanks Great Jan!
I am still struggling to make it work.
In my case also "PxCMD.FR stay unset" so I have removed that test code (as suggested for the time being).
Do you notice that besides initialization, this polling is performed also in AhciEnableFisReceive () ?
Similarly In my case EFI_AHCI_CAP_SAM was set and writing to EFI_AHCI_GHC_ENABLE wasn't not getting performed. So I have "ENABLED AE" also.
Just in case - do you notice, that it is also performed in AhciReset function?
So the code so far is installing "gEfiAtaPassThruProtocolGuid" Protocol.
But somehow, in " AtaBusDriverBindingSupported" , this protocol is not getting opened. Status = gBS->OpenProtocol ( Controller, &gEfiAtaPassThruProtocolGuid, (VOID **) &AtaPassThru, This->DriverBindingHandle, Controller, EFI_OPEN_PROTOCOL_BY_DRIVER );
Above code throws an error.
Any idea about that?
I didn't have such error, but can you provide returned Error Code? It may help.
Regards, Jan
-
Ard Biesheuvel -
Jan Dąbroś -
Marcin Wojtas -
Shaveta Leekha