The clock skew on the MT7986 seems to be rather horrible. I’m trying to add a RTC (DS-3231) by way of the SPI interface, but it’s not being detected in any i2c bus scans. Tried a few other DS chips (1307/3231M/etc) I had sitting around that works in other systems just to confirm the chips are good, but nothing is showing up on this board.
For the PPS, it seems to not want to accept setting any GPIO pins for input so that I could at least use them with an external reference source.
Anyone else have luck on setting up i2c interfaces yet? I’m using OpenWRT’s 5.15.93 kernel for testing with at the moment.
I tested the i2c on the board using a small oled display before sending out bpi-r3 dts.
Spi was imho only tested in loopback-mode (miso-mosi bridged), have not got my spi-display working,but this can also be a display-driver issue or misconfiguration.
@ShawnO did you get the pps pin working on bpi-r3?
I’m trying to set up a gps disciplined ntp server and I don’t know how to expose the pps pin on this board.
On my RPi in the u-boot extraconfig.txt file, I have dtoverlay=pps-gpio,gpiopin=18. That may help. However, to get it fully working, you’ll need to build your own kernel and configure periodic timer ticks (I think) which allows you to pick PPS kernel consumer support
Thanks, is it one of these? I’m running kernel 6.3
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
# end of Timers subsystem
I have not had a chance to play with it. Even while doing a sync to two other local ntp servers (both using PPS+GPS), the RBI-R3 seems to be unable to keep time.
I’m normally seeing 50~200ms of offset, whereas other boards/systems are normally < 2ms stable. I can restart ntpd, watch it do an initial step sync so it’s +0.000 with one of the PPS sources, and then watch as it’s offset slowly increases to 200+.
Thanks for this post! I configured gps/pps on the BPI-R3 and the offsets are just awful… as you just described, it oscillates between 50-200ms.
I thought I was doing something wrong so I replicated the setup on a raspberry 3 and it worked fine there fine there so it seems the probelm is BPI-R3.
Could this be a kernel issue or something that we can do something about it?
So, running ntpd --help, the last 3 lines should show something similar to (you need PPS & GPSD):
This version was compiled with the following clock drivers:
LOCAL GENERIC NMEA PPS SHM
GPSD
if not, then you need to rebuild ntpsec.
If so, it could be the user running ntpd does not have permissions to open /dev/ppsX - check logs.
Read the man page on what stats are produced, create the stats directory with suitable permissions. You should be able to see in clockstats what PPS signals it sees. This is my config without keys and restrict lines and the server line is a reference to gpsd:
logfile /var/log/ntpstats/ntp.log
logconfig =all
statsdir /var/log/ntpstats/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
filegen protostats file protostats type day enable
filegen rawstats file rawstats type day enable
filegen sysstats file sysstats type day enable
filegen usestats file usestats type day enable
refclock pps unit 0 minpoll 3 maxpoll 3 flag3 1 prefer
server 127.127.28.0 minpoll 4 maxpoll 4
In the ntpsec logs, when started, you should see similar lines to:
I can build my own kernel, and I’ve been doing it all along. I guess my problem is that I’m not sure what to enable.
I think the problem is between pps and ntpsec then, beause I definetely can see the pps0 from the OS, so I dont think I missing support.
What version of ntpsec are you using? maybe the different outputs are expected. I’m using prepackaged version 1.2.0+dfsg1-4 on both the RPI and BPI and the RPI has an offset of 0.0002 with the PPS. Same ntpsec config file.
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
# PPS clients support
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
CONFIG_PPS_CLIENT_GPIO=y
# PPS generators support
root@bpi-r3:~# zcat /proc/config.gz | grep HZ
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ=y
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
I really despise double negatives that the Americans seem to like so much. It just confuses the hell out of life.
By default, the kernel does NOT support NTP, therefore NO_HZ_COMMONmust be unset before NTP_PPS can be selected.
To do so, navigate to General setup->Timers subsystem and select Periodic timer ticks (constant rate, no dynticks).
Choosing either of the other 2 (Idle dynticks system (tickless idle) - NO_HZ_IDLE or Full dynticks system (tickless) - NO_HZ_FULL), sets NO_HZ_COMMON to Y which means it will NOT work.
Indeed, you will not even see the following if it is set:
From the Kconfig:
PPS kernel consumer support (NTP_PPS)
CONFIG_NTP_PPS:
This option adds support for direct in-kernel time
synchronization using an external PPS signal.
It doesn't work on tickless systems at the moment.
Symbol: NTP_PPS [=y]
Type : bool
Defined at drivers/pps/Kconfig:32
Prompt: PPS kernel consumer support
Depends on: PPS [=y] && !NO_HZ_COMMON [=n]
Location:
-> Device Drivers
-> PPS support (PPS [=y])