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.

Well damn, your post made me realize I hadn’t tried doing a byte receive to probe the i2c bus, and it did show up where I expected (0x68).

root@bpi-r3-02:/sys/bus/i2c/devices/i2c-0/0-0068/driver# ls -la
total 0
drwxr-xr-x    2 root     root             0 Feb 19 20:46 .
drwxr-xr-x    4 root     root             0 Feb 19 20:32 ..
lrwxrwxrwx    1 root     root             0 Feb 19 20:46 0-0068 -> ../../../../devices/platform/soc/11008000.i2c/i2c-0/0-0068
--w-------    1 root     root          4096 Feb 19 20:46 bind
lrwxrwxrwx    1 root     root             0 Feb 19 20:46 module -> ../../../../module/rtc_ds1307
--w-------    1 root     root          4096 Feb 19 20:46 uevent
--w-------    1 root     root          4096 Feb 19 20:46 unbind
root@bpi-r3-02:/sys/bus/i2c/devices/i2c-0/0-0068/driver# ls -la /dev/rtc0 
crw-------    1 root     root      253,   0 Feb 19 20:45 /dev/rtc0
root@bpi-r3-02:/sys/bus/i2c/devices/i2c-0/0-0068/driver# hwclock -l
Sun Feb 19 11:53:47 2023  0.000000 seconds

After I manually added it, then it showed up.

Now on to getting a GPIO to be used as a PPS source.

@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_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
# end of Timers subsystem

It’s CONFIG_HZ_PERIODIC which means CONFIG_NO_HZ_IDLE is not selected.

Then Device Drivers->PPS Support and you should see PPS kernel consumer support. If not, then check those timing selections again.

Unless they’ve changed it from 5.15.

And you may have to rebuild ntp, or preferably ntpsec if using openwrt. I found the supplied ntp binary to be a steaming pile of doo doo.

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?

What package are you using? Chrony? ntpd? ntpsec?

Are you sure you are using PPS?

If using kernel PPS, you should receive similar lines to:

Feb 07 12:00:00 feeder kernel: pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[email protected]>
Apr 10 10:46:13 feeder kernel: pps pps0: new PPS source [email protected]
Apr 10 10:46:13 feeder kernel: pps pps0: Registered IRQ 67 as PPS source
Apr 10 10:47:22 feeder kernel: pps pps0: bound kernel consumer: edge=0x1

I’m using ntpsec, kernel 6.3,

[    0.046671] pps_core: LinuxPPS API ver. 1 registered
[    0.046677] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[email protected]>
[   18.021670] pps pps0: new PPS source pps.-1
[   18.025969] pps pps0: Registered IRQ 80 as PPS source

This are the pps modules I built

# CONFIG_PPS_DEBUG is not set
# PPS clients support

# ppstest /dev/pps0  
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1681773171.637288700, sequence: 2304 - clear  0.000000000, sequence: 0
source 0 - assert 1681773172.636726092, sequence: 2305 - clear  0.000000000, sequence: 0
source 0 - assert 1681773173.636163561, sequence: 2306 - clear  0.000000000, sequence: 0
source 0 - assert 1681773174.635601338, sequence: 2307 - clear  0.000000000, sequence: 0
source 0 - assert 1681773175.635037961, sequence: 2308 - clear  0.000000000, sequence: 0
source 0 - assert 1681773176.634476045, sequence: 2309 - clear  0.000000000, sequence: 0

As you are missing:

kernel: pps pps0: bound kernel consumer: edge=0x1

it means ntpsec is not using pps.

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

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 minpoll 4 maxpoll 4

In the ntpsec logs, when started, you should see similar lines to:

2023-04-10T10:46:48 ntpd[1160]: PROTO: c01d 0d kern kernel time sync enabled
2023-04-10T10:46:48 ntpd[1160]: PROTO: c012 02 freq_set kernel -15.644409 PPM
2023-04-10T10:46:48 ntpd[1160]: PROTO: c016 06 restart
2023-04-10T10:47:06 ntpd[1160]: PROTO: c41c 0c clock_step -0.171691 s
2023-04-10T10:47:05 ntpd[1160]: PROTO: c415 05 clock_sync
2023-04-10T10:47:10 ntpd[1160]: PROTO: c418 08 no_sys_peer
2023-04-10T10:47:26 ntpd[1160]: PROTO: 011d 0d kern PPS enabled status: 2001 -> 0007

I’ve tried a few different kernels, and I keep seeing the same behavior. Even added a RTC (ds1307 based) and it still wants to keep going off.

I’m honestly getting more curious about this, but just don’t have time at the moment to dig into it deeper.

And you do not seem to have configured PPS kernel consumer support, since there is no CONFIG_NTP_PPS=y line.

You have to build your own kernel since kernel PPS support is not enabled due to NO_HZ_COMMON being selected.

Or perhaps CONFIG_NO_HZ being set to “Y”. What can I say, this side of things is a nightmare…

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_DEBUG is not set
# PPS clients support
# PPS generators support
root@bpi-r3:~# zcat /proc/config.gz | grep HZ
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set

I also tried enabling CONFIG_NTP_PPS but it doesnt seem to work, I found this description, is the BPI-R3 a tickless system?

PPS kernel consumer support

configname: CONFIG_NTP_PPS

Linux Kernel Configuration

└─> Device Drivers

└─> PPS support

└─> PPS kernel consumer support

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.

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_COMMON must 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)
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]
-> Device Drivers
-> PPS support (PPS [=y])