i have some RPi4 running with a gps device and the connected PPS Signal to one of the gpio pins.
Now im thinking about “copying” this to ipfire (im using a APU2C3/4 Board which has also GPIO Pins)
I saw on startup of ipfire
Blockquote
Mar 13 16:40:49 ipfire kernel: pps_core: LinuxPPS API ver. 1 registered
Mar 13 16:40:49 ipfire kernel: pps pps0: new PPS source ptp0
Mar 13 16:40:49 ipfire kernel: pps pps1: new PPS source ptp1
Mar 13 16:40:49 ipfire kernel: pps pps2: new PPS source ptp2
So 2 questions…
How i can enable in ipfire using a GPIO Pin as a PPS source…
It seems nobody has an idea… so i investigated a little… and i found out that i have to enable some kernel features… but i dont know how to do that…
I would need
enableing gpio for APU boards
enabling gpio as a pps client…
Im not sure how and where do do that persistant…
The Linux kernel interfaces with hardware through a modular structure involving loadable drivers and pseudo file systems. Here’s a concise rundown:
Kernel incorporates loadable modules for different hardware.
Hardware gets registered and initialized with the kernel by loading the driver module.
An interface for programs to communicate with hardware is created under /dev by the driver.
Some devices reveal structured information to userspace via sysfs virtual filesystem interfaces under /sys.
Userspace programs interact with hardware using standard POSIX OS interfaces on /dev and /sys nodes, e.g. open(), read(), write(), etc. This should be handled by the GPS software or service you are using on the RPi board.
Kernel handles low-level hardware communication details, providing a hardware-agnostic environment for userspace programs.
According to GPT4, for APU systems enabling GPIO involves these steps (with root privileges):
Module loading: modprobe gpio-apu2.
GPIO exposure: echo 0 > /sys/class/gpio/export. ← this is ON
GPIO configuration: echo out > /sys/class/gpio/gpio0/direction.
the command echo out > /sys/class/gpio/gpio0/direction sets GPIO pin number 0 as an output pin. After running this command, you would be able to write values to this pin (turn it on or off), but not read values from it. If you wanted to set the pin as an input, you would use “in” instead.
Output GPIO value setting: echo 1 > /sys/class/gpio/gpio0/value.
GPIO unexporting: echo 0 > /sys/class/gpio/unexport. ← this is OFF
Replace ‘0’ with the correct GPIO number.
To make it permanent, the code can be placed in rc.local.
same procedure, you just need to know the module name to load and how to activate it. Also, it has to be compiled for the kernel to be able to load it.
The problem is not so simple. Looking in the kernel file in the IPFire source code then it looks like the modules are not installed so can not be loaded.
# CONFIG_PPS_CLIENT_GPIO is not set
# CONFIG_PCENGINES_APU2 is not set
As the IPFire kernel is cryptographically signed when it is built then you can not just install a driver and expect to be able to load it. The signature of the kernel would no longer match when additional drivers are installed.
When the IPFire package is built it is signed and the key is then thrown away.
The only option you have is to make the modifications to the required source files and then make a complete IPFire build and use the created iso to install on your system and then restore your backup to give you the settings.
This means that you would need to do a fresh build each time there is a Core Update.
The only other option is to raise a bug as a feature request to have the required kernel modules installed but not loaded (m option). Then you can load the modules as required.
If you raise the bug make sure that you are clear on which specific kernel modules are required to be changed from “not set” to “=m” in the following file:
You have to change the kernel file that I gave the link to so that the required modules are actually set but with “=m” so that they are available but not loaded by default.
Then you will need to run the ./make.sh clean followed by ./make.sh build as in the following wiki page.
The IPFire build process will include the build of the kernel and that will pull in the modules source file that tells the kernel which modules it should include and which are installed and loaded and which are just installed but available to load.
As long as the required modules are available in the kernel then the above applies because you just have to say which ones to include in the build in the file I gave the link to.
For Info that link is for the x86_64 kernel modules. If anyone was looking for modules on the aarch64 arm kernel then the file for that architecture would have to be modified (in the same directory as the x86_64 file)
before compiling