topic Re: Problems Running IEEE-1588 Precision Timing Protocol (PTP) on i.MX-6Q in Linux in i.MX Processors

Problems Running IEEE-1588 Precision Timing Protocol (PTP) on i.MX-6Q in Linux

davidprice — Wed, 21 May 2014 20:13:20 GMT

I am trying to get IEEE-1588 Precision Timing Protocol (PTP) to run on a new board design using the i.MX-6. Our board is based on the i.MX-6 Rex design which is based on the SabreSD reference design.

The board runs the 3.0.35 Linux kernel fine from the Rex project when booted with the 2009.04 u-boot from the Rex project. The problem is that the 3.0.35 kernel lacks the support for the Linux PTP application. There seems to be some early sandbox support of IEEE-1588 in 3.0.35, but it is incompatible with the current PTP application. The first official PTP kernel support appeared in the 3.8 version kernel. I have been trying to get more recent kernels to boot, but have run into a lot of difficulty. Later kernels also started using the device tree method of booting, and it is my understanding that later version of u-boot are needed to have flattened device tree (FTD) support. When I try to boot 3.8 and later kernels with the 2009.04 u-boot, they hang silently. So I thought that maybe I needed a newer version of u-boot with FTD support. I have seen hints of that requirement on the forums.

When I try to compile and run the 2013.04 and 2014.04 versions of u-boot, they boot, but have problem accessing the SPI device on ECSPI3 with chip select 2. These u-boot versions are booting from that same SPI device as set by the boot fuses; but when u-boot tries to "sf probe" the SPI for the environment variables, it fails with all ones or all zeros depending on the clock polarity setting in the ECSPI. The chip select seems to be having an effect because if I do not select cs3, I always get zeros no matter what polarity or phase is selected. I have checked the clock gating and pin configuration and they seem correct. I have even used the "md" command to check the register settings. If the ECSPI clocks are gated, the sf probe hangs u-boot, and I'm not hanging.

Is it possible to boot a version 3.8 or later kernel with u-boot 2009.04? Specifically the Freescale 3.10.17 Linux kernel seems to be the best candidate for i.MX-6 support. I tried booting this and tried passing the ftd to bootm as the third argument, but it hangs silently with no messages. Perhaps I'm not setting up the FTD correctly. It is hard to debug since there are no messages.

If u-boot 2009.04 cannot boot a later Linux kernel, is there a later version of u-boot that works correctly with SPI on SabreSD derivative designs? We boot u-boot from SPI, and store the environment variables in the same SPI device on ECSPI3. There is another thread on this forum that seems to imply that chip selects aren't handled correctly on ECSPI in new versions of u-boot.

Ultimately, we want to run the PTP Linux stack on our board with a precise pulse-per-second timing reference that comes out of the ENET_1588_EVENT0_OUT pin. We already have a IEEE-1588 master clock running on our network, and have run the PTP stack in Linux on a PC with software timestamping, but we want to use the hardware timestamping and hardware timer/event provided by the i.MX-6. All the work above is to achieve this goal. We are ready to test it, but getting the correct Linux version to run has been a major headache.

Re: Problems Running IEEE-1588 Precision Timing Protocol (PTP) on i.MX-6Q in Linux

davidprice — Wed, 21 May 2014 22:46:49 GMT

Here's a followup. I have made some progress. This thread https://community.freescale.com/thread/314421 mentioned a problem with the SPI chip select in newer versions of u-boot. I switched the IO config of the chip select pin/pad to a GPIO4_26, and set the include/configs/mx6qdarde.h (DARDE is our board) to use that GPIO.

#define CONFIG_SF_DEFAULT_CS (2 | IMX_GPIO_NR(4, 26) << 8)

I'm using the Freescale uboot-imx-imx_v2013.04_3.10.17_1.0.0_beta version of u-boot.

It now boots and successfully probes the SPI device. It is the SST25VF016B.

U-Boot 2013.04 (May 21 2014 - 14:16:03)

CPU: Freescale i.MX6Q rev1.2 at 792 MHz

CPU: Temperature 40 C, calibration data: 0x57c4f069

Reset cause: POR

Board: MX6Q/DARDE

I2C: ready

DRAM: 1 GiB

MMC: Warning: you configured more USDHC controllers(3) than supported by the board

FSL_SDHC: 0, FSL_SDHC: 1

SF: Detected SST25VF016B with page size 4 KiB, total 2 MiB

No panel detected: default to Hannstar-XGA

Display: Hannstar-XGA (1024x768)

In: serial

Out: serial

Err: serial

Net: FEC

Normal Boot

Hit any key to stop autoboot: 0

U-Boot >

I have a problem with accessing the ethernet now.

U-Boot > ping 192.168.10.137

Using FEC device

ARP Retry count exceeded; starting again

Abort

ping failed; host 192.168.10.137 is not alive

U-Boot >

I am able to boot the 3.10.17 Linux kernel with the fdt file now. The boot process eventually hangs, and it might be related to the ethernet problem. I have no ethernet problems with 2009.04 u-boot.

Re: Problems Running IEEE-1588 Precision Timing Protocol (PTP) on i.MX-6Q in Linux

davidprice — Thu, 22 May 2014 03:40:18 GMT

I have made a bit more progress. The ethernet problem was a phy problem. The Rex project and our board use the Micrel KSZ9021 Ethernet Phy, which is different than the phy on the SabreSD. I merged in the initialization code from the SabreLite board file, and now the ethernet works. u-boot 2013.04 can now fully boot the 3.0.35 kernel, and the 3.10.17 kernel starts to boot, but it eventually hangs.

U-Boot > bootm 0x10800000 - 0x12000000

## Booting kernel from Legacy Image at 10800000 ...

Image Name: Linux-3.10.17

Image Type: ARM Linux Kernel Image (uncompressed)

Data Size: 4412856 Bytes = 4.2 MiB

Load Address: 10008000

Entry Point: 10008000

Verifying Checksum ... OK

## Flattened Device Tree blob at 12000000

Booting using the fdt blob at 0x12000000

Loading Kernel Image ... OK

Read SW1AB error!

Loading Device Tree to 4f55b000, end 4f56984a ... OK

Starting kernel ...

Booting Linux on physical CPU 0x0

Linux version 3.10.17 (dprice@ubuntu) (gcc version 4.6.2 20110630 (prerelease) (Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) ) #1 SMP Tue May 6 19:17:39 PDT 2014

CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d

CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

Machine: Freescale i.MX6 Quad/DualLite (Device Tree), model: Freescale i.MX6 Quad SABRE Smart Device Board

cma: CMA: reserved 256 MiB at 3e000000

Memory policy: ECC disabled, Data cache writealloc

....

mxc_sdc_fb fb.32: register mxc display driver lcd

mxc_sdc_fb fb.32: ipu0-di0 already in use

mxc_sdc_fb: probe of fb.32 failed with error -16

mxc_sdc_fb fb.33: register mxc display driver ldb

imx-sdma 20ec000.sdma: no iram assigned, using external mem

imx-s

That last line is where it hangs in the middle of printing. Since we aren't really using a display currently, perhaps the display driver is hanging.

Re: Problems Running IEEE-1588 Precision Timing Protocol (PTP) on i.MX-6Q in Linux

davidprice — Tue, 27 May 2014 22:41:39 GMT

The above kernel hang was traced to the root filesystem being mounted as "ro" read-only. The 3.0.35 kernel did not have this problem. Adding "rw" to the 3.10.17 kernel bootargs allowed the kernel to boot. I found that one can also put the kernel bootargs in the device tree file using the "chosen" keyword binding. For example:

/ {

model = "Freescale i.MX6 Foo Board";

compatible = "fsl,imx6q-foo", "fsl,imx6q";

chosen {

bootargs = "ttymxc0,115200 ip=dhcp root=/dev/mmcblk0p1 rw rootwait loglevel=7";

};

Perhaps since the 3.10.17 kernel uses device trees, the default root filesystem permission is read-only.

Re: Problems Running IEEE-1588 Precision Timing Protocol (PTP) on i.MX-6Q in Linux

mbp — Thu, 18 Dec 2014 17:23:36 GMT

David,

Appreciate your postings as we are moving forward on a 1588 implementation based on the SABRE platform. (I assume you have seen the 1588 postings on the 1588 work and expected bsp update to support 1588 in the imxcommunity - and based some of your work on these?).

Have you been successful in completing your integration?

If you have a consolidated set of notes as the required steps - posting them here would benefit a great many!

Thanks David,

Mike