Time sensitive networking [TSN] on NX

it was the default stock non modified file


 cat /boot/extlinux/extlinux.conf 
TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      FDT /boot/tegra194-p3668-all-p3509-0000-user-custom.dtb
      APPEND ${cbootargs} quiet

# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
#      sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot

# LABEL backup
#    MENU LABEL backup kernel
#    LINUX /boot/Image.backup
#    INITRD /boot/initrd
#    APPEND ${cbootargs}

will that work ?

That’s perfect!

Hi @_av, Did it work?

It is what I am working on to understand, at the moment;
As all devices that I am working with are remote, it takes a while to recover after boot failure.
However, I shall update you soon.

Hi @gtj
on the fresh OS from sdcard image, after patching

It is staying blank with a flash _

[ as per the observatino of local person]
from remote dev: “Nothing is showing except the _ flashing on the top left”

mounted the sdcard to another device:

/media/boot$ ls
dtb                                                              tegra186-quill-p3310-1000-c03-00-base-hdr40.dtbo
extlinux                                                         tegra186-quill-p3310-1000-c03-00-dsi-hdmi-dp.dtb
grub                                                             tegra186-quill-p3489-0888-a00-00-base.dtb
Image                                                            tegra186-quill-p3489-1000-a00-00-ucm1.dtb
Image.sig                                                        tegra186-quill-p3489-1000-a00-00-ucm2.dtb
initrd                                                           tegra194-p2888-0001-p2822-0000-adafruit-sph0645lm4h.dtbo
initrd.img                                                       tegra194-p2888-0001-p2822-0000.dtb
initrd.img-4.9.140-tegra                                         tegra194-p2888-0001-p2822-0000-fe-pi-audio-z-v2.dtbo
pps.dtbo                                                         tegra194-p2888-0001-p2822-0000-hdr40.dtbo
pps.dts                                                          tegra194-p2888-0001-p2822-0000-maxn.dtb
tegra186-quill-p3310-1000-a00-00-base.dtb                        tegra194-p3668-all-p3509-0000-adafruit-sph0645lm4h.dtbo
tegra186-quill-p3310-1000-as-0888.dtb                            tegra194-p3668-all-p3509-0000.dtb
tegra186-quill-p3310-1000-c03-00-base-adafruit-sph0645lm4h.dtbo  tegra194-p3668-all-p3509-0000-fe-pi-audio-z-v2.dtbo
tegra186-quill-p3310-1000-c03-00-base.dtb                        tegra194-p3668-all-p3509-0000-hdr40.dtbo
tegra186-quill-p3310-1000-c03-00-base-fe-pi-audio-z-v2.dtbo      tegra194-p3668-all-p3509-0000-user-custom.dtb
xavier@agx:/media/boot$ cat extlinux/extlinux.conf 
TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      FDT /boot/tegra194-p3668-all-p3509-0000-user-custom.dtb
      APPEND ${cbootargs} quiet

# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
#      sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot

# LABEL backup
#    MENU LABEL backup kernel
#    LINUX /boot/Image.backup
#    INITRD /boot/initrd
#    APPEND ${cbootargs}

from AGX:

sudo chroot /media

inspection of the filesystem and logs doesn’t provide any hint.

cat pps.dts
/dts-v1/;
/plugin/;

/ {
    overlay-name = "Jetson PPS";
    compatible = "nvidia,p3509-0000+p3668-0001";

    fragment {
        target-path = "/";
        __overlay__ {
                        pps: pps_gpio {
                                compatible = "pps-gpio";
                                gpios = <&tegra_main_gpio 148 1>;
                                assert-falling-edge;
                                status = "okay";
                        };
        };
    };
};
 sudo /opt/nvidia/jetson-io/config-by-hardware.py -l
Configurations for the following hardware modules are available:
1. Adafruit SPH0645LM4H
2. FE-PI Audio Z V2
3. Jetson PPS
**
**
sudo /opt/nvidia/jetson-io/config-by-hardware.py -n "Jetson PPS"
Configuration saved to /boot/tegra194-p3668-all-p3509-0000-jetson-pps.dtb.
then Reboot.
Then
ls /dev/pp
ppp   pps0
$ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out).

It seems that the device needs to get attached the time-pulse wire to the pin 7
I anticipate it will not boot if I return the extlinux.conf FDT line

That’s very odd. Did you change the FDT entry to “/boot/tegra194-p3668-all-p3509-0000-jetson-pps.dtb” or did you leave it out altogether to get it to work?

it was changed by the jetson-io toolkit gracefully so that it appended an entire section in the bottom
I just commented with # the manually added FDT in order to boot at all ,as otherwise it wouldn’t boot

cat /boot/extlinux/extlinux.conf
TIMEOUT 30
DEFAULT Jetson PPS

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      #FDT /boot/tegra194-p3668-all-p3509-0000-user-custom.dtb
      APPEND ${cbootargs} quiet

# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
#      sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot

# LABEL backup
#    MENU LABEL backup kernel
#    LINUX /boot/Image.backup
#    INITRD /boot/initrd
#    APPEND ${cbootargs}

LABEL Jetson PPS
	MENU LABEL Jetson PPS
	LINUX /boot/Image
	FDT /boot/tegra194-p3668-all-p3509-0000-jetson-pps.dtb
	INITRD /boot/initrd
	APPEND ${cbootargs}

Well, that makes it easy. It’s still odd that it didn’t work the other way but oh well. :)

Next question is how to forward pps0 outputs to linuxptp;
@gtj, from hardware point of view, does it take to connect one wire from pps source? to the pin N7? two wires from the pps source? to the pin N7 and also some other pin?

from linuxptp maintainers

 In my experience, PPS-in via GPIO just has far too much jitter to be useful.

source Re: [Linuxptp-users] Grandmaster with gps pps | linuxptp

Could you comment on this statement??

You don’t need any physical connection. The PPS signal is read by the kernel and programs like ntpd to discipline the system clock. ptpd in master mode uses that and phy timestamping to broadcast the time over the network.

actually first question was how to wire GPS pulse pins to Jetson NX GPIO;
at this point no software context for this question ,but just for wiring;
does it require to connect 2 wires for pps pulse to jetson from GPS pps source? one wire? to the pin 7?
otherwise how the GPS pps source passes its signals to the NX?
the second question is how ptpd gets the pps; it doesn’t just broadcast a request for all possible available pps scenarios, but will require explicit input. previously I would set the date manually for hardware ptp

I think it really depends on the platform.

From my NX using the GPIO:

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPP0.           1 l    -    8  377    0.000    0.200   0.015
*time-d-b.nist.g .NIST.           1 u   10   64    3   11.471    2.109   0.124

From my x86 time server using the CD pin on a serial port:

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPP0.           1 l    2    8  377    0.000   -0.013   0.029
*time-d-b.nist.g .NIST.           1 u   47   64  377   11.822    2.984   0.341

The NX using GPIO has less jitter than the x86 using CD.

After seeing this, I may get another NX to replace the x86 timeserver. :)

you are not connecting any wires tto pin7 GPIO of NX? Are you? smth like the below?
How do I get pps inputs unless the PPS source is connected? WQhich wires to use? one wire? two wires? to which pins? 7? and the other wire?

got it! thanks.

Sorry, I read your question wrong. Yes, what I do is connect the PPS output of the GPS to pin 7, the TXD of the GPS to pin 10 and RXD pin on the GPS to pin 8. This allows ntpd to get the NMEA sentences from the gps to set the date and time, and the PPS to synchronize the seconds.

The following udev rules will create the correct /dev symlinks…

KERNEL=="ttyTHS0", SYMLINK+="gps0"
KERNEL=="pps0", MODE="0660", SYMLINK+="gpspps0"

These entries in ntp.conf will tell ntpd to use both the NMEA sentences and the PPS…

server 127.127.20.0 mode 80 minpoll 3 burst iburst prefer
fudge 127.127.20.0 stratum 1 flag1 1 flag2 0 flag3 1 flag4 0 time1 0.0 time2 0.095 refid GPP0

You may have to tune the time2 value a bit (see the ntp docs)