Any that you want to use the new DTB with. Hard to give exact instructions without seeing your existing extconfig.conf.
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!
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.