search

nxp-archive / openil

OpenIL is an open source project based on Buildroot and designed for embedded industrial solution.
Other
135 stars 55 forks source link

Query about phc2sys #61

Closed diegotxegp closed 4 years ago

diegotxegp commented 4 years ago

Hi there,

After synchronising my network (slave-master-slave) with IEEE 802.1AS gPTP, acting my LS1021ATSN platform as master. My question is: What phc2sys instructions should I use on the slaves?

I tried to use this: sudo phc2sys -a -rr -m

But a message appears saying: "waiting for ptp4l". But ptp4l is already working.

Another command I tried was: sudo phc2sys -c /ptp/ptp0 -s CLOCK_REALTIME -O 0 -m With this command, the node tries to synchronise CLOCK_REALTIME to its PHC but it appears an offset high.

My question is: What instruction for phc2sys do you recommend me? And another question is: Must I run phc2sys also in the master?

Thank you very much for reading me.

Kind regards, Diego

diegotxegp commented 4 years ago

Hello Vladimir.

I came back to OpenIL 1.8 release, and I run these commands:

For LS1021ATSN: ptp4l -i swp2 -i swp3 -f /etc/ptp4l_cfg/gPTP.cfg -m --tx_timestamp_timeout 20 phc2sys no because, as I said to you, I do not mind the time was in 1970 or 2054. Just the same for the whole network. Then, I avoid that problem you said. Perfect.

For node: ptp4l -i swp2 -i swp3 -f /etc/ptp4l_cfg/gPTP.cfg -m --tx_timestamp_timeout 20 sudo phc2sys -a -rr --transportSpecific 0x1 --step_threshold 0.0002 --first_step_threshold 0.0002 -m

And it works perfectly from my point of view. Low offset both on ptp4l and phc2sys.

nodo2@nodo2-N-A:~$ sudo ptp4l -i enp3s0 -f /home/nodo2/linuxptp-2.0/configs/gP.cfg --tx_timestamp_timeout 20 -m ptp4l[575.901]: selected /dev/ptp0 as PTP clock ptp4l[575.944]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[575.945]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[579.263]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[579.265]: selected local clock aabbcc.fffe.00094a as best master ptp4l[579.266]: assuming the grand master role ptp4l[579.847]: port 1: new foreign master 00049f.fffe.ef0808-2 ptp4l[581.847]: selected best master clock 00049f.fffe.ef0808 ptp4l[581.847]: port 1: MASTER to UNCALIBRATED on RS_SLAVE ptp4l[582.107]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[582.858]: rms 22 max 37 freq +14246 +/- 23 delay 233 +/- 0 ptp4l[583.859]: rms 22 max 29 freq +14286 +/- 14 delay 233 +/- 0 ptp4l[584.861]: rms 19 max 26 freq +14306 +/- 5 delay 233 +/- 0 ptp4l[585.862]: rms 8 max 17 freq +14302 +/- 6 delay 233 +/- 0 ptp4l[586.863]: rms 3 max 5 freq +14299 +/- 4 delay 233 +/- 0 ptp4l[587.865]: rms 4 max 7 freq +14293 +/- 4 delay 233 +/- 0 ptp4l[588.866]: rms 3 max 7 freq +14292 +/- 4 delay 233 +/- 0 ptp4l[589.867]: rms 3 max 6 freq +14296 +/- 4 delay 234 +/- 0 ptp4l[590.869]: rms 4 max 7 freq +14294 +/- 5 delay 234 +/- 0 ptp4l[591.870]: rms 3 max 5 freq +14294 +/- 4 delay 234 +/- 0 ptp4l[592.871]: rms 4 max 9 freq +14294 +/- 6 delay 236 +/- 0 ptp4l[593.873]: rms 3 max 5 freq +14294 +/- 4 delay 236 +/- 0 ptp4l[594.874]: rms 4 max 7 freq +14295 +/- 5 delay 236 +/- 0 ptp4l[595.875]: rms 4 max 7 freq +14293 +/- 5 delay 236 +/- 0 ptp4l[596.876]: rms 4 max 8 freq +14293 +/- 5 delay 236 +/- 0 ptp4l[597.878]: rms 3 max 5 freq +14293 +/- 4 delay 236 +/- 0 ptp4l[598.879]: rms 4 max 8 freq +14296 +/- 5 delay 236 +/- 0 ptp4l[599.880]: rms 4 max 7 freq +14295 +/- 5 delay 236 +/- 0 ptp4l[600.882]: rms 4 max 8 freq +14293 +/- 5 delay 236 +/- 0 ptp4l[601.883]: rms 4 max 8 freq +14293 +/- 6 delay 236 +/- 0 ptp4l[602.885]: rms 4 max 7 freq +14293 +/- 5 delay 236 +/- 0 ptp4l[603.886]: rms 3 max 5 freq +14293 +/- 4 delay 236 +/- 0 ptp4l[604.887]: rms 4 max 8 freq +14293 +/- 5 delay 236 +/- 0 ptp4l[605.889]: rms 3 max 6 freq +14293 +/- 5 delay 236 +/- 0 ptp4l[606.890]: rms 3 max 5 freq +14294 +/- 4 delay 236 +/- 0 ptp4l[607.892]: rms 2 max 4 freq +14292 +/- 3 delay 235 +/- 0 ptp4l[608.893]: rms 4 max 7 freq +14292 +/- 6 delay 234 +/- 0 ptp4l[609.894]: rms 2 max 4 freq +14292 +/- 3 delay 233 +/- 0 ptp4l[610.895]: rms 4 max 8 freq +14294 +/- 5 delay 233 +/- 0 ptp4l[611.897]: rms 4 max 8 freq +14297 +/- 5 delay 233 +/- 0 ptp4l[612.898]: rms 4 max 8 freq +14291 +/- 5 delay 234 +/- 0 ptp4l[613.900]: rms 3 max 6 freq +14290 +/- 4 delay 235 +/- 0 ptp4l[614.901]: rms 3 max 6 freq +14292 +/- 5 delay 234 +/- 0 ptp4l[615.903]: rms 4 max 6 freq +14292 +/- 5 delay 234 +/- 0 ptp4l[616.905]: rms 3 max 6 freq +14292 +/- 5 delay 233 +/- 0 ptp4l[617.906]: rms 3 max 6 freq +14295 +/- 4 delay 233 +/- 0 ptp4l[618.908]: rms 4 max 7 freq +14293 +/- 5 delay 233 +/- 0

And phc2sys in the node, similar. I do not have the values of this.

Now, I was going to write you to explain these good results, and repeat the steps, and I get these results in phc2sys on the node. The previous one, the CLOCK_REALTIME changed automatically its value to take the master's PHC value (1970). This time no.

nodo2@nodo2-N-A:~$ sudo phc2sys -a -rr --transportSpecific 0x1 --step_threshold 0.0002 --first_step_threshold 0.0002 -m phc2sys[811.347]: reconfiguring after port state change phc2sys[811.348]: selecting CLOCK_REALTIME for synchronization phc2sys[811.348]: selecting enp3s0 as the master clock phc2sys[811.348]: CLOCK_REALTIME phc offset 1593085251906565919 s0 freq +9237 delay 5412 phc2sys[812.349]: failed to step clock: Invalid argument phc2sys[812.349]: CLOCK_REALTIME phc offset 1593085251906565885 s1 freq +9203 delay 5628 phc2sys[813.349]: CLOCK_REALTIME phc offset 1593085251906565884 s0 freq +9203 delay 5256 phc2sys[814.350]: CLOCK_REALTIME phc offset 1593085251906565896 s0 freq +9203 delay 5604 phc2sys[815.350]: failed to step clock: Invalid argument phc2sys[815.350]: CLOCK_REALTIME phc offset 1593085251906565914 s1 freq +9221 delay 5604 phc2sys[816.350]: clockcheck: clock jumped forward or running faster than expected! phc2sys[816.351]: CLOCK_REALTIME phc offset 1593085251906565902 s0 freq +9221 delay 5616 phc2sys[817.351]: failed to step clock: Invalid argument phc2sys[817.351]: CLOCK_REALTIME phc offset 1593085251906565894 s1 freq +9213 delay 5616 phc2sys[818.352]: clockcheck: clock jumped forward or running faster than expected! phc2sys[818.352]: CLOCK_REALTIME phc offset 1593085251906565879 s0 freq +9213 delay 5400

I will repeat this procedure some more time because I think it happened to me using IEEE 1588 as well. Like CLOCK_REALTIME does not take well the time, and if you try the same operation later, it works.

vladimiroltean commented 4 years ago

phc2sys[815.350]: failed to step clock: Invalid argument

As I said before:

There are bugs surrounding the clock stepping of CLOCK_REALTIME to a value close to 0 (Jan 1st 1970), and nobody is actively looking into fixing them, because nobody is in 1970 anymore.

So, you would need to manually move the PTP clock of your master (that is the LS1021A-TSN, according to your logs) to a different time, at each boot:

phc_ctl /dev/ptp1 set 1592817646.744752137

And only then start ptp4l.

diegotxegp commented 4 years ago

Yes. It is true. I set it and it worked fine. My question is how do I keep this time permanent at /dev/ptp1?

vladimiroltean commented 4 years ago

You could add the command as ExecStartPre in the ptp4l service. Like this:

vim /usr/lib/systemd/system/ptp4l.service
[Unit]
Description=Precision Time Protocol daemon
After=syslog.target network.target
Before=time-sync.target
Wants=time-sync.target
Wants=phc2sys.service

[Service]
ExecStartPre=/usr/sbin/phc_ctl /dev/ptp1 set 1592817646.744752137
ExecStart=/usr/sbin/ptp4l -f /etc/linuxptp.cfg
Restart=always

[Install]
WantedBy=multi-user.target
diegotxegp commented 4 years ago

I did that and reset, but /dev/ptp1 kept in 1970. Maybe it is, as you could see some messages behind, that ptp4l.service is inactive when LS1021ATSN platforms boots.

vladimiroltean commented 4 years ago

Have you tried enabling the ptp4l service with systemctl?

diegotxegp commented 4 years ago

Yes, once I enable ptp4l service "systemctl enable --now ptp4l", /dev/ptp1 comes to 2020. On the other thread, I undestood to you that if I wriite the command "ptp4l ...", activating ptp4l service would not be necessary. It works as well.

Apart from that, I have a new doubt for you. Since last week, the lights of the occupied ports ETH2 and ETH3 is blinking when LS1021ATSN boots, not just when I use ptp4l. I have not touched anything on its configuration.

vladimiroltean commented 4 years ago

You can check with tcpdump what traffic is being transmitted. If it has an EtherType of 0x88f7, it's PTP.

vladimiroltean commented 4 years ago

On the other thread, I undestood to you that if I wriite the command "ptp4l ...", activating ptp4l service would not be necessary

And of course that is true. But if you run ptp4l manually, you should also run phc_ctl manually. I thought your question is how to do it automatically...

diegotxegp commented 4 years ago

Ah. Another thing in case someone wants to compile OpenIL. Yesterday, I tried to compile it again, to discard that it is some corrupt data in SD, and an error raised. After "make" command, it was compiling as usual but after some hours, an error raised with the following message:

diegotxegp commented 4 years ago

--2020-06-29 17:22:26-- http://sources.buildroot.net/uboot-master.tar.gz Resolviendo sources.buildroot.net (sources.buildroot.net)... 104.26.1.37, 172.67.72.56, 104.26.0.37, ... Conectando con sources.buildroot.net (sources.buildroot.net)[104.26.1.37]:80... conectado. Petición HTTP enviada, esperando respuesta... 404 Not Found 2020-06-29 17:22:26 ERROR 404: Not Found.

package/pkg-generic.mk:167: fallo en las instrucciones para el objetivo '/home/diegotxe/openil/output/build/uboot-master/.stamp_downloaded' make[1]: [/home/diegotxe/openil/output/build/uboot-master/.stamp_downloaded] Error 1 Makefile:84: fallo en las instrucciones para el objetivo '_all' make: [_all] Error 2

diegotxegp commented 4 years ago

On the other thread, I undestood to you that if I wriite the command "ptp4l ...", activating ptp4l service would not be necessary

And of course that is true. But if you run ptp4l manually, you should also run phc_ctl manually. I thought your question is how to do it automatically...

Ah, ah. Yes, you thought right. I thought that although I run it manually, it could be saved as well, like when I saved my IP for br0. Understood.

diegotxegp commented 4 years ago

You can check with tcpdump what traffic is being transmitted. If it has an EtherType of 0x88f7, it's PTP.

I tried it and there are some PTP packets, according to what you said, but not so many how for that traffic and blinking.

[root@LS1021ATSN ~] # tcpdump -i swp2 ether proto 0x88f7 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on swp2, link-type EN10MB (Ethernet), capture size 262144 bytes 17:07:40.638319 00:04:9f:ef:08:08 (oui Freescale) > 01:80:c2:00:00:0e (oui Unknown), ethertype Unknown (0x88f7), length 68: 0x0000: 1202 0036 0000 0000 0000 0000 0000 0000 ...6............ 0x0010: 0000 0000 0004 9fff feef 0808 0001 11ef ................ 0x0020: 0500 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 0000 0000 0000 ...... 17:07:41.638506 00:04:9f:ef:08:08 (oui Freescale) > 01:80:c2:00:00:0e (oui Unknown), ethertype Unknown (0x88f7), length 68: 0x0000: 1202 0036 0000 0000 0000 0000 0000 0000 ...6............ 0x0010: 0000 0000 0004 9fff feef 0808 0001 11f0 ................ 0x0020: 0500 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 0000 0000 0000 ...... 17:07:42.638693 00:04:9f:ef:08:08 (oui Freescale) > 01:80:c2:00:00:0e (oui Unknown), ethertype Unknown (0x88f7), length 68: 0x0000: 1202 0036 0000 0000 0000 0000 0000 0000 ...6............ 0x0010: 0000 0000 0004 9fff feef 0808 0001 11f1 ................ 0x0020: 0500 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 0000 0000 0000 ...... 17:07:43.638865 00:04:9f:ef:08:08 (oui Freescale) > 01:80:c2:00:00:0e (oui Unknown), ethertype Unknown (0x88f7), length 68: 0x0000: 1202 0036 0000 0000 0000 0000 0000 0000 ...6............ 0x0010: 0000 0000 0004 9fff feef 0808 0001 11f2 ................ 0x0020: 0500 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 0000 0000 0000 ...... ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel

Supposedly, ptp4l should not work if I do not order it.

Forget this comment because I had ptp4l.service enable. Once, it is disable, there are not ptp4l packets.

diegotxegp commented 4 years ago

I noticed that blinking is due to ssh.

Before I was connected via SSH and using tcpdump I could see a great number of ssh packets. To see it without using SSH, I connected via USB0 K22, and the blinking disappeared. So, is it correct or there is some problem that ssh provokes such blinking and traffic?

diegotxegp commented 4 years ago

In fact, if I connect to LS1021ATSN via SSH with the USB0 K22 cable connected, it does not blink.

vladimiroltean commented 4 years ago

Commit 'master' does not exist in this repository.

This looks strange, I can reproduce it. Let me see if I can come up with a proper solution. At the moment, the only fix would be to go back at the source code and make this change:

diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
index 4cf43128719f..fa567962d5f6 100644
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -78,7 +78,7 @@ config BR2_TARGET_UBOOT_CUSTOM_REPO_URL

 config BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION
        string "Custom repository version"
-       default "master"
+       default "OpenIL-v1.8-u-boot-202005"
        help
          Revision to use in the typical format used by
          Git/Mercurial/Subversion E.G. a sha id, a tag, branch, ..

then make nxp_ls1021atsn_defconfig again. Sorry, here's an explanation of why it isn't working: http://lists.buildroot.org/pipermail/buildroot/2018-June/223083.html

vladimiroltean commented 4 years ago

In fact, if I connect to LS1021ATSN via SSH with the USB0 K22 cable connected, it does not blink.

Ah! I know what you're talking about. I have no idea what's going on there. There is some hardware issue of the K22 microcontroller wiring with the rest of the board. So just keep the K22 plugged in, even if that means "plugged in loopback into the board's own USB0 type-A port".

diegotxegp commented 4 years ago

Commit 'master' does not exist in this repository.

This looks strange, I can reproduce it. Let me see if I can come up with a proper solution. At the moment, the only fix would be to go back at the source code and make this change:

diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
index 4cf43128719f..fa567962d5f6 100644
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -78,7 +78,7 @@ config BR2_TARGET_UBOOT_CUSTOM_REPO_URL

 config BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION
        string "Custom repository version"
-       default "master"
+       default "OpenIL-v1.8-u-boot-202005"
        help
          Revision to use in the typical format used by
          Git/Mercurial/Subversion E.G. a sha id, a tag, branch, ..

then make nxp_ls1021atsn_defconfig again. Sorry, here's an explanation of why it isn't working: http://lists.buildroot.org/pipermail/buildroot/2018-June/223083.html

I wanted to compile it again because maybe blinking was due to something I did wrong, and using a new clear compilation. But if blinking was a problem of K22 USB, I do not need it.

vladimiroltean commented 4 years ago

Yes, nothing to do with software. It's just that the K22 seems to be toggling some board reset line when it's unpowered (I think), since the power of the K22 microcontroller comes from the microUSB VBUS pin.

diegotxegp commented 4 years ago

Thank you very much for your help, Vladimir. I appreciate your help. I hope that this thread is useful for more people. If I have another query, I will ask you. Thank you.