Lobosito

The pps_gpio module does not take parameters. Definitions of a PPS device must be in the DTB, or overlay: https://mjmwired.net/kernel/Documentation/devicetree/bindings/pps/pps-gpio.txt
 
 
That's because you're missing parts of the DTB overlay. Notably, you need to specify that:
It's an overlay Where it applies ("target" or "target-path") What you're doing there (overlay or fixup) And in this case, what you're adding ... You probably meant to do something like this instead. Note that I don't have your setup, nor your board, so can't test this. But probably a better start than where you are.
 
/dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; // Define a PPS device on GPIO Bank 1, pin 2 fragment@0 { target-path = "/"; __overlay__ { pps0: pps-gpio0 { compatible = "pps-gpio"; gpios = <&gpio1 2 0>; assert-falling-edge; }; }; }; };  

I've thrashed through this here with an Odroid-C2 running PRETTY_NAME="Armbian 23.02.1 Bullseye" 
 
I confirmed that with current, "stock" kernels, the suggestions to manually configure a pin for the pps-gpio module are no longer useful.
 
At least on the C2 and perhaps on other devices, the gpioinfo utility can reveal the proper line (and chip) for a given pin, without needing to refer to the DTS, such as at https://elixir.bootlin.com/linux/v6.1.11/source/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts#L304 
 
 
$ sudo gpioinfo | egrep 'gpiochip|Pin7' gpiochip0 - 15 lines: line 11: "J7 Header Pin7" unused input active-high gpiochip1 - 119 lines: line 113: "J2 Header Pin7" unused input active-high  
Decompiling the "live" device tree with dtc -I fs -O dts /sys/firmware/devicetree/base or similar will reveal the phandle for the GPIO bank
 
bank@4b0 { reg-names = "mux\0pull\0pull-enable\0gpio"; gpio-controller; gpio-line-names = "Eth MDIO\0Eth MDC\0Eth RGMII RX Clk\0Eth RX DV\0Eth RX D0\0Eth RX D1\0Eth RX D2\0Eth RX D3\0Eth RGMII TX Clk\0Eth TX En\0Eth TX D0\0Eth TX D1\0Eth TX D2\0Eth TX D3\0Eth PHY nRESET\0Eth PHY Intc\0HDMI HPD\0HDMI DDC SDA\0HDMI DDC SCL\0\0eMMC D0\0eMMC D1\0eMMC D2\0eMMC D3\0eMMC D4\0eMMC D5\0eMMC D6\0eMMC D7\0eMMC Clk\0eMMC Reset\0eMMC CMD\0\0\0\0\0\0\0\0SDCard D1\0SDCard D0\0SDCard CLK\0SDCard CMD\0SDCard D3\0SDCard D2\0SDCard Det\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0I2C A SDA\0I2C A SCK\0I2C B SDA\0I2C B SCK\0PWM D\0PWM B\0Revision Bit0\0Revision Bit1\0\0J2 Header Pin35\0\0\0\0J2 Header Pin36\0J2 Header Pin31\0\0\0\0TF VDD En\0J2 Header Pin32\0J2 Header Pin26\0\0\0J2 Header Pin29\0J2 Header Pin24\0J2 Header Pin23\0J2 Header Pin22\0J2 Header Pin21\0J2 Header Pin18\0J2 Header Pin33\0J2 Header Pin19\0J2 Header Pin16\0J2 Header Pin15\0J2 Header Pin12\0J2 Header Pin13\0J2 Header Pin8\0J2 Header Pin10\0\0\0\0\0\0J2 Header Pin11\0\0J2 Header Pin7\0\0\0\0\0"; reg = <0x00 0x4b0 0x00 0x28 0x00 0x4e8 0x00 0x14 0x00 0x520 0x00 0x14 0x00 0x430 0x00 0x40>; phandle = <0x23>; #gpio-cells = <0x02>; gpio-ranges = <0x20 0x00 0x00 0x77>; };  
Knowing the line that you wish to use, you can then construct an overlay. The pps-gpio bindings are described at https://www.kernel.org/doc/Documentation/devicetree/bindings/pps/pps-gpio.txt
 
In my case, I needed the pin to be active high, without any pull-up/down. When you create the file, use the .dts extension for compatibility with the Armbian compile/install script.
 
/dts-v1/; /plugin/; /* * bank@4b0 is at phandle = <0x23>; * GPIO 113 is "J2 Header Pin7" * GPIO_ACTIVE_HIGH is 0 */ / { compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb"; fragment@0 { target-path = "/"; __overlay__ { pps0: pps-gpio0 { compatible = "pps-gpio"; gpios = <0x23 113 0>; }; }; }; };  
Running sudo armbian-add-overlay pps-gpio.dts will compile the source, install it into /boot/overlay-user/ and add a line to /boot/armbianEnv.txt to load it through U-Boot. It won't add the line if it is already there, so re-running the utility should be "safe".
 
While looking at /boot/armbianEnv.txt it is worth noting that the boot script has two useful U-Boot variables, extraargs and extraboardargs. At least on the C2 these seem to be unused elsewhere. 
 
setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} consoleblank=0 coherent_pool=2M loglevel=${verbosity} ubootpart=${partuuid} libata.force=noncq usb-storage.quirks=${usbstoragequirks} ${usbhidquirks} ${extraargs} ${extraboardargs}"
 
These can be set in /boot/armbianEnv.txt to adjust the kernel cmdline, such as adding
 
extraargs=nohz=off  
if appropriate for your application.
 
Success should create /dev/pps0 and gpioinfo now showing
 
gpiochip1 - 119 lines: line 113: "J2 Header Pin7" "pps-gpio0" input active-high [used]  
With a source connected to the expected pin, the function can be checked with
 
$ sudo 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 1678986077.000000404, sequence: 44681 - clear 0.000000000, sequence: 0 source 0 - assert 1678986078.000000575, sequence: 44682 - clear 0.000000000, sequence: 0 source 0 - assert 1678986079.000000371, sequence: 44683 - clear 0.000000000, sequence: 0 ^C  
Configuration of gpsd and chronyd did not seem to have any notable differences from other platforms. That is a topic on its own, but not specific to Armbian.

a bit late but the problem was I forgot to add the line "[Seat:*]"

In order to have such functionality in open source, where anyone can integrate code from another, this will be a lot harder. For example - our user / you covers us only 0.5% of costs of this project https://docs.armbian.com/User-Guide_FAQ/ Manjaro on ARM is a lot smaller project and basically only builds mainline kernel for you. Official builds - they are patching stock kernel, where such functions might be glued together in some proprietary way, with blobs. Linux distributions usually don't go that way since that would mean support can be tied to one (and those very similar) hardware only.
 
What you are asking for is expensive to develop and I am not aware if there are any usable common ways. https://en.wikipedia.org/wiki/Mozilla_Foundation has 1000+ volunteers and around 100 full-time staff and yearly revenue of 500+ million dollars. If they can't provide this functionality OOB within their budget, few people certainly can't. This problem is also not Radxa specific. They integrate SoCs and sell it. We are focused into a build framework, so you can use this HW for something. For full potential, you need to look into different price range.