Regarding DM8148 Sata clock

hi Ajay,

Please check this thread: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/181083/671141.aspx

Best regards,

Pavel

Hi Pavel,

Thank you for quick reply. I have already gone through this topic. I understand how this is to be done but where to apply these changes? uboot or kernel. As I know u-boot setup all the PLL and in file board/ti/ti8148/evm.c pcie_pll_config() is commented. I then uncommented pcie pll configuration code from evm file and rebuild complete u-boot, but u-boot stopped booting now. is there a specific reason why PCIe PLL configuration is commented in u-boot?

and for sata clock selection, I think by just clearing that bit I should be able to select right clock for sata. and can I do this in u-boot itself where sata PLL is getting configured?

Thanks,

Ajay Bhargav

Hi Ajay,

I can not say why pcie_pll_config() is commented, I will contact our PSP team with this question.

I think you do not need to modify anything in the PCIE PLL, as the value you need PCIE_PLLCFG0[31] SEL_IN_FREQ is 0x0 (100 Mhz) by default.

When I try to modify the sata_pll_config() function, clearing bit SATA_PLLCFG0[31] SEL_IN_FREQ to 0x0 (100 Mhz), the u-boot stopped booting. So I change this bit in s_init(u32 in_ddr) function, board/ti/ti8148/evm.c file, modify it as:

void s_init(u32 in_ddr)

{

........

prcm_init(in_ddr);
__raw_writel(0x40000017, SATA_PLLCFG0);

delay(0xFFFF);

........

}

Thus the u-boot is booting fine, with SATA_PLLCFG0[31] SEL_IN_FREQ = 0x0 (100 Mhz).

Does this work for you?

Best regards,

Pavel

Hi Pavel,

Thanks for reply. This is what I have modified in u-boot:

in pcie function (pcie_pll_config()):

        /* wait for ADPLL lock */
-       while(__raw_readl(PCIE_PLLSTATUS) != 0x1);
+       while((__raw_readl(PCIE_PLLSTATUS) & 0x01) != 0x1);

pcie_pll_config(); moved ahead of sata_pll_config() as pcie pll has to be locked first before we can select 100Mhz for sata.

My uboot did not work either with directly writing the value. so I have added the change for clearing bit 31 this way... uboot is booting but there is no way to confirm if sata clock is at 100Mhz or not.

@@ -549,6 +569,10 @@ static void sata_pll_config()
        /* wait for ADPLL lock */
        while(((__raw_readl(SATA_PLLSTATUS) & 0x01) == 0x0));

+       regdata = __raw_readl(SATA_PLLCFG0);
+       regdata &= ~(1 << 31);
+       __raw_writel(regdata, SATA_PLLCFG0);
+       //while(((__raw_readl(SATA_PLLSTATUS) & 0x01) == 0x0));

Moreover prcm_init function is called from within s_init so you keep that clearing bit within the sata_pll_config or out of it wont make any difference.

Please let me know how can I confirm if SATA is working at 100Mhz or not. Is there any change required on the kernel side? like for the parent clock and ops for sata_ick?

Thanks & Regards,

Ajay Bhargav

Hi Ajay,

We have a section in the DM814x TRM - 2.3.11 Clock Output Pin

There you can find information how to rout the sata clock to device pin for observation (see CLKOUT_MUX register description also). Thus you can verify the frequency of the clock. 

Best regards,

Pavel

Am having the same problem.  I tried the modification you suggested and u-boot stopped booting.  The u-boot software gets hung in a loop reading the SATA_PLLSTATUS register at 0x48140734.  The software is reading a 0x4 and testing for 0x1 (APLL is locked).  0x4 is APLLDIGSTS4 that is marked "Not used" in the TRM.  APLLDIGSTS4 gets set and APLLDIGSTS0 never does, so the u-boot software just hangs there.

I have posted my code snippet how I changed the clock. Even Pavel has did the same way. After SATA pll is initialized just clear bit 31. I did not confirm yet if clock is actually working at 100Mhz or not. But My actual problem which is SATA link getting limited to 1.5Gbps is still there after doing all this.

Are you facing same problem?

Ajay,

I am using libata.force=1.5 in the linux command line passed from u-boot to force 1.5Gbps and seeing transfer rates in the 70 Mbytes/sec range on our hardware.  We need a reliable sata interface.  I would like to see it run at 3Gbps, but that does not appear to work at this time.  That may be because we are using internal 20 MHz clock instead of external 100 MHz differential clock, I don't know. 

I modified my code with the snippet Pavel posted and could not boot afterwards.  1st stage u-boot gets stuck in a loop waiting for a PLL lock indication in bit 0 of SATA_PLLSTATUS (0x4814_0734).  Instead, bit 2 gets set in the status register (APLLDIGSTS4 "not used") and the system just hangs there waiting on a lock that never occurs.  sata_pll_config() writes to SATA_PLLCFG0 four times.  It looks like the modified code snippet only clears bit 31 in the last write and writes a one the first three times, why is that?

Thanks - Gary

Ajay,

Correction.  On re-reading the posts, I find that I have not tried either code snippet (yours or Pavel).  I cannot use Pavel's modification as he is letting u-boot program the SATA_PLLCFG0 register with a one in bit 31 and waiting for the PLL to lock.  Then writing bit 31 to zero afterwards, without waiting for the PLL to lock on the new clock.  I don't think that will work correctly.

Did you ever get an answer on why pcie_pll_config() is commented out in u-boot?  I think you are right and we need to uncomment the code that initializes the PCIE PLL and move it in front of sata_pll_config().  That makes a lot of sense.  Although I notice your code does not wait on a PLL lock after changing the clock source, either.  Is that because the code hangs waiting for the PLL to lock?

Thanks - Gary

Gary,

Thanks for the update, Yes I commented code myself coz u-boot gets stuck in stage 1 if I uncomment the following line u-boot goes on well

while(((__raw_readl(SATA_PLLSTATUS) & 0x01) == 0x0));

You're right, actually SATA PLL never locks to new frequency. I don't know if this is coz of silicon bug? If errata has mentioned a bug then why TI PSP team did not implemented it in SDK release made last month? I haven't received any answer yet for why pcie_pll_config() kept out of init part.

As I mentioned in my earlier post i moved pcie function before sata and I did modification for the PLL lock wait as

/* wait for ADPLL lock */
        while((__raw_readl(PCIE_PLLSTATUS) & 0x01) != 0x1);

earlier it was blindly waiting for register to go 0x01. I believe pcie might be getting configured correctly coz I get u-boot prompt.

Keep me updated with any test you do on your side.

Edit:
-------

Another reason for commenting SATA pll lock statement was, I thought it might be possible that SATA is directly using clock out from PCIE PLL once locked.

Regards,

Ajay Bhargav

Hello,

I asked the question about the pcie_pll_config() to PSP, still waiting for the answer.

I have tried the clkout0 pin to observe the SATA SERDES clock, but this pin is showing the satass_125m_ck which is always 125MHz. The other clock that you have asked - the sata_ick is the interface and functional clock coming from the device PRCM, it is 200MHz. To sum up, I still can not find how to verify that SATA SERDES is switched to 100MHz diff ref clock. I am still investigating.

Meanwhile, there are two more bits which seems related to that 100MHz diff ref clock:

SATA_PLLCFG1[30] PLLREFSEL = 0x0 (100M)

SATA_PLLCFG1[3] EN_CLK100M = 0x1 (enable for 100M)

Please try with these bits also.

Here are some links that may be useful: http://processors.wiki.ti.com/index.php/TI_SATA_FAQ, http://processors.wiki.ti.com/index.php/EZSDK_Using_SATA_drive_for_Data

Best Regards,

Pavel

Hi Pavel,

Thank you for reply. I will check with these bits

SATA_PLLCFG1[30] PLLREFSEL = 0x0 (100M)

SATA_PLLCFG1[3] EN_CLK100M = 0x1 (enable for 100M)

I have already enabled PLLREFSEL, I need to see if bit 3 is enabled or not. Also as Gary and I already mentioned that SATA PLL never locks to new frequency. It could be possible that bit 3 is not set. I will get back to you with my findings.

Regards,

Ajay Bhargav

Hi Ajay,

This is the feedback from the PSP team concerning the pcie_pll_config() issue in u-boot:

PCIe PLL is set up in Linux when using root complex mode and hence not configured in U-Boot.

Regards,

Pavel

Hi Ajay,

The PCIe PLL is set up in linux-2.6.37-psp04.04.00.01/arch/arm/mach-omap2/devices.c, ti81xx_init_pcie function. I think this function overwrites all your PCIe PLL settings in the u-boot. Please examine and modify here.

Regards,

Pavel

Hi Ajay,

I receive more info from our PSP team:

PCIe PLL config in Linux should not be changed, just ensure it is set up before SATA.

link on external repo corresponding to this:

Regards,

Pavel

Thank you so much Pavel. I will check this patch and get back to you. I hope this should solve my problems and You will surely get the credit for it.

Regards,

Ajay Bhargav

Pavel,

That means the SATA interface is not going to be working correctly and reliably until the linux kernel has been loaded from some other medium and is booting.  Which implies we cannot expect to boot the linux kernel from a SATA HDD because the sata clocks are initialized in the linux kernel, not the boot loader.

Do we have a patch that configures the sata clock to run from an external 100 MHz differential in u-boot so the sata interface is up and running early enough to boot the linux kernel from hard disk?  That is why we are trying to configure the sata clock in the boot loader, we need the sata interface to be working reliably as soon as possible.

- Gary

Hi Pavel,

I have tried the patch after resolving uart5 issue. But it seems patch did not work as expected. I am still getting SATA link limited at 1.5Gbps. any suggestions?

ata1: softreset failed (1st FIS failed)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1: link online but 1 devices misclassified, retrying
ata1: softreset failed (1st FIS failed)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1: link online but 1 devices misclassified, retrying
ata1: softreset failed (1st FIS failed)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1: link online but 1 devices misclassified, retrying
ata1: limiting SATA link speed to 1.5 Gbps
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1: link online but 1 devices misclassified, device detection might fail

@Gary,

Did you try the patch on kernel? did it work for you?

Regards,
Ajay Bhargav

Hi Ajay,

I need some clarifications first. Did you tried the patch on linux-2.6.37-psp04.04.00.01 or on linux-2.6.37-psp04.01.00.06.patch2?

I didn't try the patch, as I do not possess external SATA 2 HDD (3Gbps).

Regards,

Pavel

Hi Pavel,

I tried on latest PSP 04.04.00.01. I will try on older PSP too. but I do not find much difference if I see from the patch. only one variable is changed. rest of the patch applies directly. Is it feasible for you to try out with SATA2 HDD? and do you recommend checking on older PSP too? coz i feel newer PSP is better.

Thanks & Regards,
Ajay Bhargav

Hi Ajay,

According to the latest feedback from PSP team, this SATA patch should be applied on top of older PSP 04.01.00.07 release:

http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/TI814XPSP_04.01.00.07

This is how I see the development tree:

tag/04.01.00.06 -> tag/04.01.00.06.patch1 -> tag/04.01.00.07 -> head/04.01.00.07

http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/TI814XPSP_04.01.00.07

tag/04.01.00.06 -> tag/04.01.00.06.patch1 -> tag/04.01.00.06.patch2 -> head/04.01.00.06

http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/TI814XPSP_04.01.00.06

tag/04.01.00.06 -> tag/04.01.00.06.patch1 -> tag/04.01.00.07 -> tag/04.04.00.01 -> head/04.04.00.01

http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/TI81XXPSP_04.04.00.01

Old EZSDK release - tag/04.01.00.06.patch2

New EZSDK release - tag/04.04.00.01

If you prefer new EZSDK (04.04.00.01), we should remove all patches between tag/04.01.00.07 and tag/04.04.00.01, verify that SATA works with 3Gbps, then add all previously removed patches one by one, till SATA stops working, and finally remove the last added patch.

This is my idea, I am still waiting additional information from the PSP team.

BR

Pavel

Hi Pavel,

Thanks for the info. I do have linux-2.6.37-psp04.01.00.06.patch2 kernel with me so can you tell me exactly which patch to apply so that I can verify SATA @3Gbps. I think after patch2 it directly comes to psp04.01.00.07 am I right?

This is the patch I have with me:

http://pastebin.com/9bCa2ZQZ

Regards,

Ajay Bhargav

Hi Ajay,

I just receive new info from PSP team. They are developing new SATA patch, which will run on top of 04.04.00.01. This patch is scheduled for next Tuesday (17-July).

BR

Pavel 

Hi Pavel,

I think its worth to wait for that patch.

Regards,

Ajay Bhargav

hi Ajay,

This is the update:

1. http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=19190e50826af1ce640284bfd2dcdfa9b355002b

2. http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=26a44c7509a049ddf84cd9769a427648783c2e23

3. http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=4fc50a3fcbbf80f4e5b67cb5d1223bb05cef782c

You have to pick up the 3 patches from above and apply them against the PSP 04.04.00.01 release : http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/TI81XXPSP_04.04.00.01

Regards,

Pavel