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.
Again sorry for the late reply. - I had a flurry of activity on this, then got sick the next morning, and have been out of commission since.
@librecomputer, thanks for the extra context. The overall issue as far as Armbian support makes more sense now.
@mmaney - Is this something that I need to pull from the repository separately as an applet? Is this a separate pre-compile tool? Is this a different compiler entirely? - I’m only aware of DTC.
@librecomputer, would you mind clarifying this one for me? I’ve already followed these directions to get LTDO downloaded and compiled already. - Is this just meant to say that I could download the latest version and it would include a pre-compiled pps-gpio-7j1-12.dtb?
I’m focused on the Privacy/Security side of things right now, but if I can get past the initial hurdles, I want to get into some more of the fun and interesting side projects that could be had. - I’m going to need to know how to compile my own overlay eventually, even if that’s not necessarily going to be today.
Just clone the repository via git, add your overlay in the appropriate directory. Then run make at the root of the repo. It will compile all of the overlays. Then you can use the sudo ./ldto command to merge the overlay.
I am only familiar with MAKE in as a tool for compiling executables in Linux. Nothing to do with device tree, as far as I know.
There is a strong implication here, that LDTO will only compile on a fresh install, based on the focused referral to this section of the manual. - Which makes absolutely no sense.
Blockquote
cd libretech-wiring-tool
git pull origin master
make
type or paste code here
This “RTFM” answer is not helpful. There is nowhere in the wiring tool manual that refers to compiling device tree. - So, great, DTC the only compiler that I’m aware of for device tree isn’t the correct thing to use. What is?
I’m not against reading a manual, but it would be helpful if the manual actually has a section on the topic I need information on!
If you have a new overlay, just place it in the board folder. make at the root of the repo will compile overlays placed in the appropriate board folder. Use the local repo ldto via sudo ./ldto instead of the system ldto.
Hundreds of people already make use of the wiring tool and contribute overlays to the wiring tool, you’re the only one making a fuss about this topic because you lack basic system knowledge. If you don’t understand what automake does, then please ask a chat bot instead of saying our stuff does not work or our documentation is lacking.
For the record, I have been using sources outside of this forum as much as possible- including chat bots as you suggest- which did help me through the “guess and check” process of finding absolute references for some of the pins that would compile with DTC.
I’ve also been very clear that I’m operating with limited knowledge. - That’s the whole point of a project like this. I’m nowhere near an expert, and may never be. I’ll settle for competent, if I can get there.
Tribal knowledge is not the same thing as knowledge that is actually available to the end user. The manual for LDTO is clear enough with instructions triggering individual pins and applying pre-existing overlays. - There is no guidance on how to compile new overlays.
If there’s background knowledge that I’m missing, I would appreciate being pointed in the correct direction. If the necessary information isn’t in the manual, what purpose is served in an RTFM answer?
This entire process is like a bad martial arts movie training montage. Why must all of the secrets be hidden, and discovered only through much frustration?
All of that said, I do appreciate the answer. The explicit explanation helps avoid misunderstanding. Thank you for being clear.
I’m going to spend some time with this over the weekend and see if I can compile a proper overlay using the existing pin-outs. (I don’t want to have to move the unit from the one place it gets a GPS signal, but will if needed).
I apologize for being a grouch (if not other, various expletives that might apply).
Avoid knowledge outside this forum for things specific to our boards. There’s too much incorrect information online from chaps who don’t understand anything. If you look on YouTube, most of the SBC videos are hot garbage promoting hot garbage by people who pretend to know something.
For example, all of the overlays for Le Potato are in this directory
Just create your overlay in that directory and run make at the root.
Let me add that when you run make, you can build just one overlay by specifying it on the comand line. Now, this is from memory, the AMLs aren’t hooked up right now, but it goes something like this:
make librecomputer/$BOARD/dt/$OVERLAY.dtbo
And that will build the overlay from the source file of the same name (but *.dts, of course) and leave it in that directory without the wasted effort of building every overlay known to the wiring tool for every SBC. It leaves copying the .dtbo into the wiring tool’s overlay tree to you, of course.
