AM5728: i818 - SATA PHY Reset Required Following SATA PLL Unlock

Hello Maeda-san,
What OS is being used in this case?

Hi, Daisuke,

If the OS is linux, could you attach the failing boot logs? Thanks!

Rex

Hi -DK--san and Rex-san,

Thank you for your reply.

The OS is Windows, which is probably WEC7 (Windows Embedded Compact 7).

The customer sees that the application fails to load during Windows startup. Because that Windows is loaded from SATA drive, they believe that there is a problem with SATA. So the customer does not require support for Windows.

I have some questions for the i818 issue.

1) Is there any source code for Linux or RTOS for the workaround?

2) Does the DPLLCTRL_SATA_PLL_STATUS[1] PLL_LOCK bit show 0x0 (PLL is not locked) when the PHY receiver looses lock by the i818 issue?

3) Is there any way to see that the i818 issue has occurred by checking the terminal such as a clock output?

The customer does not implement the JTAG traces on their boards for mass production.

4) Is the description for the workaround on the errata correct?

It seems to power down the SATA_PHY_RX and the SATA_PHY_TX and power up only the SATA_PHY_TX since the CONTROL_PHY_POWER_SATA[21:14] SATA_PWRCTL_CLK_CMD is set from 0x0 to 0x2.

Best regards,

Daisuke

Hi -DK--san and Rex-san,

Our customer does NOT require support for Windows.

For the i818 issue, please give me an answer as soon as possible. Thank you in advance for your prompt reply.

Best regards,

Daisuke

Hi, Daisuke,

We had a Jira filed against the i818, but closed due to not being able to reproduce it. When working on it, an upstream commit was mentioned and thought it may be related. Looking at the discription of the commit, I don't think it is for i818. Since it is not reproducible in TI's lab, there hasn't be any workaround implemented or verified it. Below is the commit which has been merged since version 2015.01.

commit 87791adc22ecb513e5f34cf51e167d3638da75da
Author: Dmitry Lifshitz <lifshitz@compulab.co.il>
Date:   Mon Dec 15 16:02:58 2014 +0200

    arm: omap: reset sata on boot
   
    On OMAP platforms (like OMAP5) Linux kernel fails to detect a SATA
    device if it is used by U-Boot.
   
    It happens because U-Boot does not reset SATA controller before boot.
   
    Reset the controller on OS boot so that Linux will have a clean state
    to work with.

Rex

Hi Rex-san,

Thank you for your reply.

I understand that i818 is theoretically possible but not reproduced in TI's lab.

Our customer will investigate whether it is necessary to reset SATA controller on booting Windows.

Best regards,

Daisuke

Hi -DK--san,

Thank you for your reply.

Our customer will check to power up the SATA_PHY_RX and the SATA_PHY_TX by setting the CONTROL_PHY_POWER_SATA[21:14] SATA_PWRCTL_CLK_CMD from 0x0 to 0x2 for the workaround.

Best regards,

Daisuke

Hi Rex-san,

Why is it required to reset SATA controller before booting OS?

Is it because the configuration to handle SATA is different between U-boot and Linux?

If U-boot and Linux are the same configuration, the reset will not be needed.

Best regards,

Daisuke

Hi -DK--san,

Our customer fails to reinitialize SATA controller for the workaround. The procedure to reset the SATA controller seems incorrect.

The SATA controller supports three levels of software reset:

- Software reset (least intrusive)
- Port reset
- HBA reset (most intrusive)

Which software reset in the three levels should be used for the reinitialization?

Where should each of the software resets be done in "24.8.5.1 Global Initialization" on TRM?

Best regards,

Daisuke

Hi -DK--san and Rex-san,

Please give me any source code such as Linux or RTOS for SATA initialization.

Best regards,

Daisuke

Hi, Daisuke,

I still have question on the setup. I can't visual the relationship betwwen the AM5728 and the windows OS. Is the Windows OS running on AM5728 or they are 2 separate entities? What OS is AM5728 running? The commit for resetting SATA in u-boot was done by another company who contributed to u-boot upstream. From the description in the commit, it says "Reset the controller on OS boot so that Linux will have a clean state to work with".

Rex

Hi Rex-san,

Thank you for your reply.

The Windows OS (WEC7) is running on AM5728.

Our customer is testing which of the three levels of software reset to use.

Best regards,

Daisuke

Hi, Daisuke,

Happy New Year. Can you or the customer do a "git diff" on the commit ID and find out what changes are for that commit? From kernel code in Linux Processor SDK, it should be easy to find out which register it is setting. I think it is the global host control register, but please look at the code to confirm.

Rex

Hi Rex-san,

Happy New Year. Thank you for your reply.

I am not familiar with Linux, so do not know the proper means to find out changes for the commit, but found out them on the web.

https://patchwork.ozlabs.org/patch/421207/

https://lists.denx.de/pipermail/u-boot/2014-December/198771.html

I will try to find out all of code for reset.

Best regards,

Daisuke

Hi Rex-san,

Thank you for your reply.

Best regards,

Daisuke