What LC said, though the instructions for using the repo are kind of “just build the world”. From a quick look, the only way to build just one overlay, or even just for one target chip, would take editing of the Makefile.
One plus - a pps-gpio-7j1-12 was added about a month ago, so building from the repo is probably the only way to get it before the next image updates, whenever they happen. I also found a very interesting note in that module - says rising edge trigger is less stable than level in the 850X, which might account for less than impressive PPS tracking I saw on Frite.
I completely forgot to mention that the dtc errors you’re getting are due to the dts NOT having been run through the C preprocessor, which is what handles the includes as well as turning many symbolic names into magic numbers that dtc understands. Been there, have the head-shaped dent in the wall…
Since there have been mentions of multiple starting images, I’m not sure I know which one you’re actually using now. Which is it?
Okay, on further review it seems that you’re using Armbian, and so what LC refers to as a “third party” image. I had some time to spare, and skimming Arbian’s User Guide to Overlays I saw something very familiar from the BeagleBB’s boot setup. Armbian loads the /boot/armbianEnv.txt at the u-boot stage, and applies overlays specified there before loading and booting the Linux kernel. This is quite different than the approach ldto manages, which applies a monolithic DT (if present) - there are no overlays as such at this point, they’ve been merged by ldto. OTOH, ldto enable can activate an overlay at runtime on Armbian because that’s done through the kernel’s builtin facilities (at least I assume it is, and that LC didn’t create a redundant version). But ldto merge CAN NOT arrange for an overlay to be activated at boot time because it doesn’t work with Armbian’s Own Way of doing that.
And that, and likely other things, are why LC says
We don’t support Armbian since their processes are very different than ours.
Note that Armbian overlay files have to be named meson-yadda-yadda.dtbo, and they are found in the /boot/dtb/amlogic/overlay directory. There don’t seem to be as wide a range of overlays for Frite as LC has available in their Debian image.
So the Armbian Way of applying overlays is completely different than the LC Way, even though the individual overlay source and binary files might be identical (aside from that prefix for Armbian). Either one looks weird if you’re familiar with the other, and if I sound like I understand the Armbian Way really well, it’s because it is at bottom the same as the BeagleBB Way that I really do understand pretty well from years of using it.
At the root of the issue is that Armbian’s way is proprietary. We do not support proprietary boot mechanisms as the maintenance burden is passed on to adopters of said proprietary mechanism. ldto’s merge is not proprietary. It sets the entire device tree in the upstream search path.
