i.MX6Q SATA PLL failure

[zorg1331]

Hi, all!

We have our custom board with i.MQX6 Quad on it. This board significantly based on SABRE Lite D one.

When Linux kernel boots, we see following messages:

[    2.368995] Wait for CR ACK error!

[    2.393698] Wait for CR ACK error!

[    2.418597] Wait for CR ACK error!

[    2.443331] Wait for CR ACK error!

[    2.470046] Wait for CR ACK error!

[    2.494640] Wait for CR ACK error!

[    2.521353] Wait for CR ACK error!

[    2.546059] Wait for CR ACK error!

[    2.572772] Wait for CR ACK error!

[    2.597462] Wait for CR ACK error!

[    2.624175] Wait for CR ACK error!

[    2.648866] Wait for CR ACK error!

[    2.675538] Wait for CR ACK error!

[    2.700164] Wait for CR ACK error!

[    2.703592] Wating for RX_PLL lock time out

And further...

[    3.722579] ahci ahci: AHCI 0000.0000 1 slots 1 ports ? Gbps 0x1 impl platform mode

[    3.730249] ahci ahci: flags:

[    3.734678] scsi0 : ahci_platform

[    3.738240] ata1: SATA max UDMA/133 mmio [mem 0x02200000-0x02203fff] port 0x100 irq 71

And finally..

[    4.811475] ata1: failed to resume link (SControl 0)

[    4.816466] ata1: SATA link down (SStatus 0 SControl 0)

So, SATA did not work.

What might be the cause of this?

We have tried exactly the same kernel binary image with HummingBoard (the only one development kit that we have) and SATA works fine there.

So we think, that it is hardware issue, but we did not know where to look for the reason of it.

Our assumption was that something wrong with ENET PLL (PLL6). It constructs it own clock (500 MHz) from external 24 MHz, then divides it to 100 MHz for SATA and 125 MHz for PCIe. So, if 24 MHz is broken, then SATA and PCIe and Ethernet would not work. However, we have double checked this and found nothing wrong.

We have tried to bring up PCIe and catched some problems with it:

- We can observe 100 MHz clock on CLK1_N/CLK2_P pins.

- Rarely we even got link with PCIe card.

- Almost all time Linux kernel hangs while trying to access PCIe.

Ethernet works fine, but it takes it clock from AR8031 phy.

[zorg1331 · Accepted solution]

Thanks God! We've found the issue!

Pins G12 and G13 (SATA_VPH and SATA_VP) were swapped! The rest things were OK.

[igorpadykov]

Hi zorg1331

reason may be board noise and signal loss in board material.

In order to get good edges in the electrical signal,

a board needs to have the proper characteristic impedance at a minimum

of four times the data frequency, ideally eight times.

In general one can try change IOMUX GPR13, it defines various SATA Phy

transmitter/receiver settings:

set transmitter level settings to max

set receiver sensitivity settings to min

Also board can have high noise or not good SATA signals

layout (check sect.3.9 SATA recommendations IMX6DQ6SDLHDG ).

One can use SATA analyzer and check SATA signal integrity..

For minimizing noise from DDR one can try SATA example from

internal iRAM and check if this helps.

i.MX 6Series Platform SDK : Bare-metal SDK

iRAM (OCRAM) i.MX6 SDK Application

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[zorg1331]

Hi, Igor!

Thanks for the answer! Unfortunately it does not help. :smileysad:

We've check all those things you suggested and it gives nothing to us. :smileysad:

We've double-check impedance and PCB layout. In attachements you can find parts of our schematic and PCB, that contain SATA.

We cannot check SATA signals -- we have no instruments with enough quality.

We've tried SATA example from SDK and received following:

**************************************************************************

    Platform SDK (1.1) for MX6DQ TO1.2 Smart Device (SD) rev. C        

    Build: Oct 10 2014, 12:29:07                                        

    Copyright (c) 2012-2013 Freescale Semiconductor, Inc. All rights reserved.

**************************************************************************

========== Clock frequencies ===========

CPU: 792000 kHz                      

DDR: 528000 kHz                      

IPG: 66000 kHz                        

Debug UART: 80000000 Hz              

========================================

+SATADBGMSG: SATA PHY Clock <= ANATOP ENET PLL

+SATAERR : Timeout to Spin-Up Device

SATA test failed

So, why do you think, that we must check SATA signals layout? As I menshioned in first letter, Linux kernel cannot even initialize CPU's SATA. May be we observe consequences of some faults in frequencies initialisation? I.e. we some how should check external oscillator quality or maybe some key capacitors...

[igorpadykov]

Hi Pavel

I think so because I am working for a long time with these

processors and have much experience with them.

You should connect SATA device to i.MX6 and only then to test.

You can check SATA device with i.MX6 reference board if it works.

There is no any evidence that "Linux kernel cannot even initialize CPU's SATA",

"Timeout to Spin-Up Device" means that there is no signal from PCIe device.

You may wish to check hardware using SATA requirements given in

IMX6DQ6SDLHDG

Also we support here Freescale reference boards and boards based on Freescale designs.

SABRE Lite and boards based on SABRE Lite are supported on boundary devices site.

Best regards

igor

[zorg1331]

Hi, Igor!

Thanks for the quick answer. )

> You should connect PCIe device to i.MX6 and only then to test.

> You can check PCIe device with i.MX6 reference board if it works.

> "Timeout to Spin-Up Device" means that there is no signal from PCIe device.

PCIe? We are talking about SATA.. If you mean "SATA" then yes, of course, we've tested them before on reference boards and they work fine.

Concerning PCIe.. Yes, there is a problem with PCIe too. Sometimes we can observe link with PCIe devices, but it happens rarely and board hangs then. :smileysad:

> There is no any evidence that "Linux kernel cannot even initialize CPU's SATA",

Not exactly.. It is covered in the following citation from my first post:

> [    2.703592] Wating for RX_PLL lock time out

At that moment Linux kernel tries to initialise SATA PHY:

sata_phy_cr_addr(SATA_PHY_CR_CLOCK_RESET, mmio);
sata_phy_cr_write(SATA_PHY_CR_RESET_EN, mmio);
usleep_range(100, 200);
/* waiting for the rx_pll is stable */
for (i = 0; i <= 5; i++) {
  sata_phy_cr_addr(SATA_PHY_CR_LANE0_OUT_STAT, mmio);
  sata_phy_cr_read(&ret, mmio);
  if (ret & SATA_PHY_CR_LANE0_RX_STABLE) {
    pr_info("sata phy RX_PLL is stable!\n");
    break;
  } else if (i == 5)
    pr_info("Wating for RX_PLL lock time out\n");
  usleep_range(1000, 2000);
}

This is taken from linux-2.6-imx.git - Freescale i.MX Linux Tree (imx_3.10.17_1.0.1_ga branch of Freescale repo).

May be I'm somehow misunderstand that and this is not a real problem? However, something does not work as expected to.

> Also we support here Freescale reference boards and boards based on Freescale designs.

> SABRE Lite and boards based on SABRE Lite are supported on boundary devices site.

Yes, of course you are right, but I suppose that my question leeds to some theoretical point, may be with clock domains... )

Please accept my apologies, I cannot express myself clearly because of my terrible English.

[igorpadykov]

Hi Pavel

Errors like:

/* waiting for the rx_pll is stable */..
    pr_info("Wating for RX_PLL lock time out\n");

may be caused by fact that SATA phy can not recover clock from weak input signal

(clock embedded in signal), so SATA RX PLL fail to lock.

~igor

[zorg1331]

Hi, Igor!

Thanks for the answer. We still cannot bring SATA up and find were we fail.

I've tried to read SATA PHY lane0 registers before and after PHY reset under the Linux kernel in the code listed above. Example here: http://pastebin.com/3bG37w6Q.

However, I've received only ""Wait for CR ACK error!\n". Does it mean that SATA PHY module completely broken? Is there some sanity checks for external supplies and clocks?

Also, I should mention that we're using automotive variant of MX6Q CPU (MCIMX6Q6AVT10AC) v1.2.

[igorpadykov]

Hi Pavel

I do not think that SATA PHY module can be broken.

In general you can replace processor for checking.

For bring-up it is recommended to use

i.MX 6Series Platform SDK

~igor

[zorg1331]

One more set of experiments, that bring new questions without answers.

* We have our custom board and HummingBoard.

* We use identical code base. Linux kernel based on Freescale 3.10.17 1.0.1 ga. Even binary images of kernel and dts are the same.

On our board we see 100 MHz clock on CLK1_N/CLK1_P outputs. Also, on HummingBoard we observe exactly the same 100 MHz on the same pins. This fact means that:

- Our 24 MHz XTAL source is enough to multiply it to 500 MHz in ENET_PLL and then divide it to 100 MHz.

- SATA_REF is present and has enough quality.

- Software correctly configures hardware.

If we commented out SATA_REF enabling in ahci_imx.c on HummingBoard we get exactly the same results as on our board. I mean, that no registers of SATA module are readable, all zeroed.

If we commented out only enabling MPLL_CLK in GPR13 register on HummingBoard we again get the same.

So, we can conclude, that on our custom board there is an issue that prevents SATA_REF to go to SATA module, and this issue is hardware issue. Is this possible?

Now we are waiting for another type of IMX6 CPU to check if we use broken chip revision.

[igorpadykov]

regarding hardware reasons, one can check

requirements given in IMX6DQ6SDLHDG