I apologize in advance, but it’s been two months of wasted nights and weekends trying to figure this out, and I’m frustrated to no end
I want to use an s805x / La Frite board as an NTP server, but cannot activate UART or GPIO for use with the GPS module.
I am using Armbian out of necessity. I do not have the skill needed to compile a Linux distro from scratch, and Armbian is the only available distro with an image that has been compiled for this SBC.
I have read through the relevant posts, but none of these go into much detail on what is actually needed to address the issue on Armbian. Any of the posts that I have seen boil down to “change to a different distro”, or “RTFM”.
I would appreciate any relevant advice or guidance that would allow me to get this to work
Now that I’ve had some sleep, I’m adding a bit more background to this.
I have tried to load Debian and Ubuntu both onto this board using the generic images linked from this site. This gives me a live USB of a desktop operating system that barely runs on the La Frite, and lacks an installer. have tried to DD the image file onto the EMMC directly, which is an exasperating failure after hours of waiting every single time.
I have two La Frites working for me as Pi-Holes with Unbound, both running Armbian. It was a PITA to get these to work, having to edit *.YAML files for Netplan, and *.CONF files for Unbound. (Pi-hole doesn’t have an option to change the IP and Armbian randomizes the MAC address, so static DHCP assignment’s don’t work.)
I have a third La Frite as the test bed for NTP. Ideally, I want each La Frite to be its own NTP server for DNSSEC … but that’s far downstream from getting UART and GPIO to work.
I have found out, the hard way, that the Libre fork of Armbian absolutley does not support the use of Device Tree Overlay, and have been focusing on editing the main device tree instead. - I am not able to re-compile the edits, because nothing I can find actually points to the true hardware resources on the board.
Attempting to deep-dive even further down this particular rabbit-hole, I found the YouTube videos: “Device Tree for Dummies” and “Tutorial: Device Tree (DTS), Linux Board Bring-up and Kernel Version Changing”, which suggest starting from the DTSI file for the processor which doesn’t seem to be included in the Libre fork of Armbian, and I’m not able to find it elsewhere.
If I’m looking in the wrong direction, please let me know, but please give me something than can help dig me out of the rabbit-hole instead of digging further.
I would still love some advice on how to do this properly, with fewer headaches and forehead shaped holes in the drywall, but but I’m finally receiving GPS data off of the module on UART_C.
Now to figure out how to activate GPIO for the PPS pin.
Edit: - In case this helps someone down the line that has no earthly clue on how to start working with Device Tree on Armbian, this is what I had to do: - The node names don’t point to anything, if you’re going to reference anything reference the phandle. = If you find a guide asking you to use “pinctrl-0 = <uartb_b>” (or similar), don’t. Use "pinctrl-0 = <0x7c> (or similar) instead.
Changes made to the DTB file are bracketed with two Asterisks.
This is an example of the actual “node”, that refers to the pins. - You can’t use the name (first bold), because it won’t work. You need to use the phandle. (second bold).
**uart_c** {
phandle = <**0x7c>**;
mux {
groups = "uart_tx_c\0uart_rx_c";
function = "uart_c";
bias-disable;
};
This is a very horrible explanation, with almost zero true technical knowledge behind it, but it’s working so far. - But, hopefully it’s a step forward for someone else who’s also having trouble with this on Armbian.
Hi there - Adding some more rambling to this monologue. Would still welcome advice, but have managed to get my hands on the DTSI files, and am still not done chasing all of the #includes back to the source. - Same with finding references to YAML files for pinctrl. - I’m trying to find something, somewhere, with a coherent set of labels that the GPIO pins will actually answer to.
Should that happen, I’ll post the results here.
Still haven’t figured out to do more than listen activate and listen on UART_C. - Also, might have accidentally activated UART_B at the same time… unsure how.
With current edits, I have both a ttyAML6 and a ttyAML7 - I know 7 is UART_C, but I haven’t bothered trying to check what 6 is actually linking to yet.
AML-S805X-AC works on the +arm64 images per the download instructions since it is UEFI boot capable. We don’t support Armbian since their processes are very different than ours.
You’re trying to use our infrastructure with Armbian which it’s not designed for and paying in time and pain. This is needless suffering. Just use our distros.
Thanks for responding back. - Working on Device Tree blind has been a hell. - I did manage to get a Raspbian image installed.(I used a live USB so I could have the board flash itself using DD). Had no luck when I tried Debian.
I haven’t had a chance to do much more than the initial prepwork, but being able to use Libre wiring tool to tell me the labels instead of hunting for them blindly is nice. - Will report back once I get a chance to do more, and get it working.
In the mean time, though, any insight as to why Device Tree has to be an exra layer of hell on Armbian? Any research I’ve been able to do on device tree makes out that the distro shouldn’t matter as long as the labels used are ones the board can respond to. - I’m sure that there are plenty of people with better Linux skills than mine that have tried comparing the DTB’s between Raspbian and Armbian. - I could understand if all of the associated commands to get there are different, or possibly even borked, but why don’t the labels seem to match up even?
Have you read the README for libretech-wiring-tool?
There’s already UART overlays for every board so I’m not sure why you’re re-inventing the wheel for serial unless your application has some special requirement.
For Armbian questions, ask on the Armbian forum. We do not have input or control their process.
Work issues have been clawing at my free time, and I haven’t had much chance to touch this project since I last replied.
Sorry for the late response.
It’s not so much that I have a specialized project but that I have a general one. I want to be able to run the standard combo of Pi-Hole + Unbound along with a GPS based NTP, DNS over TLS / DNSCrypt functionality, and a basic firewall.
I’m sitting at ~25% RAM use with Pi-Hole, Unbound, and IP-tables running on the two boards that I have on Armbian. - I’m sitting at ~30% RAM use on the test board with Raspbian, and don’t have any services running on it yet.
I don’t want to ‘reinvent the wheel’. I want to understand why the existing wheel is apparently defective. - The default answer from both the Armbian and the Libre forums is “Not our problem. Next window, please”, as each points at the other.
I don’t understand why this is the case, when device tree is supposed to be agnostic to the OS. What is the major malfunction between Libre and Armbian? Why don’t any of the overlays available on the LTDO github actually function with Armbian?
I’m willing to read up, but I need background information to information to work with.
I’m also willing to use something other than Armbian, but would prefer to keep the overhead as low as possible.
I will respond back once I get the chance to dig back in.
Thanks again.
This is not the case. We support our software. If you choose not to use our software, then you cannot expect support from us for someone else’s software.
Device tree is OS agnostic for the most part but Armbian uses non-standard boot infrastructure so our tooling cannot be used since our tooling is designed for standard boot infrastructure.
Frite or sweetp - either one comes with (using the LC Debain image, anyway) the ldto tool and a boatload of semi-documented (a list form 2022 IIRC, which is less than half the overlays ldto reports) overlays that just work, though sometimes you have to use the gpio/uart/etc. they were written for. See also your board’s directory here for the DT sources, which will at least let you know which pins/devices each overlay uses.
For running PPS on Frite (or sweetp) you’ll want the pps-gpio-7j1-12 overlay and uart-a for the PPS and serial connection, respectively. At least those are the exact names I used on sweetp, frite isn’t currently connected but I believe the overlays are the same. chrony (or ntpsec, though it doesn’t work as well with PPS IME), gpsd to parse the serial data and feed the daemon (1). I’ve said elsewhere that there are better SBCs for GPS/NTP, but with tweaking sweetp achieves a standard deviation around 200 nsec as reported by chrony’s tracking data. There is a fixed offset over NTP due to the always-honored (as far as I can tell) rx-usecs coalescence delay in the ethernet/driver, but at 20-some usecs (minimum, 100+ stock) it’s at least an order of magnitude better than the FC-NTP-MINI that seems popular at three times the price. FC does come in a cute little case…
Perhaps it’s a mistake for Libre to offer some of those images, especially with no visible warning that some are supported and some… aren’t. I know this has been mentioned somewhere in a posting, but trying to find that even if you know it’s here… It’s not the best situation.
(1) blacklist pps_ldisc to stop gpsd from registering a bogus PPS device which may race for naming with the real one
I’m hoping to avoid using UART_A, because I don’t want to disable the debug UART in the process, especially since SSH isn’t enabled by default on the Raspbian image. - It is nice to be able to use LDTO to turn UART-C on in a single command and verify that the it can receive a GPS signal using CAT.
Now, I’m trying to figure how to get the pps-gpio-7j1-12 overlay to compile. - It took much less time to get UART-C enabled, but I’m having the exact same problems with trying to get a PPS_PIN on Raspbian as I was on Armbian. - None of the labels seem to actually correlate to something the hardware recognizes, and I have no clue why that is the case.
EDIT - I have no way to tell for sure, but the error messages I’m getting seem to be pointing to the #includes… which of course are never included. - I’ve already went down the down the rabbit-hole of using the Armbian compiler to chase the # include files all the way down, and it didn’t do me any bit of good to do so. - I doubt the files are the same between Raspbian and Armbian. I really don’t want to have to figure out how to partially compile Raspbian to see if I might be able to find these files. - - Is there an actual repository to get the correct *.h files from?
Will this actually do any good?
EDIT: I think I found the includes in the LTDO tool github. Will see if that helps.
EDIT: Nope. Having the includes doesn’t do any good. Still impossible to compile the overlay.
uart-a is distinct from the debug (I think of it as the console) uart, which is known in these chips as uart-ao-a. That AO shows up in other places as well, and it indicates that these devices and GPIO pins are Always On. Many devices and pins can be literally turned off under program control to manage the power budget.
But there’s no reason not to use uart-b or uart-c if you prefer, as long as they don’t require pins that you need for something else. uart-b, for example, uses the same pins that I2C-a would need.
As for your DT issues, I can’t offer any help, as I’ve never used any of the {Rasp,Armb}ian distros. I still can’t find the post I (imagine?) I saw that made it clear which of the ones LC has images for are best supported, but this one makes it clear that at some level there’s Debian and then there’s all the rest, each with its own funny ways.
I’m back to having to deal with the includes. I don’t have “meson-gic.h” and it is not part of the includes for LTDO.
Is there a guide somewhere that can give me a coherent list of absolute references to use instead? Admittedly, I would be using these blindly… but they at least compile.
This is the current attempt. It at least compiles, and avoids the includes. No clue if it will work, won’t have the chance to test it for a bit.
I have moved the jumper. - I’ve tried doing this with pin 12 instead of pin 11, but I can’t find any absolute references that work with pin 12.
Just a sec, I have to administer a ritual dope-slap to myself…
So there’s no pps-yadda-yadda-gpio overlay in the Frite directory - I just got around to noticing this, sorry - so what did I use? And then I started looking for an almost forgotten old thread about getting a PPS signal into the Frite.
I have to give partial credit to this to Rod Stewart, as I had Every Picture Tells A Story playing while eating lunch and then pondering this issue. Last summer really does seem like a long time ago…
I managed to get a working pps pin (according to ppstest) with my cobbled overlay, but only on the initial “enable” it borked on the “merge”.
So, at least some measure of progress.
@mmaney - Thanks for the earlier explanation on AO pins. That, and the post, is what got me to try switching to pin 11.
I think it worked specifically because it’s an AO pin. It doesn’t seem to be possible to enable individual pins on this board, only specific pin groups.
@librecomputer - Is there a source available somewhere to get all of the include files necessary to use symbols instead of direct references in device tree? - I would use the pps-gpio-7j1-12.dts example, if it worked.
Thanks for bearing with me on what seems to be mostly a never-ending gripe list.
Now to figure out how to get it to retain the update without borking.
EDIT: It didn’t reboot properly, but it did start back up after a power cycle. Still getting a pps signal per ppstest.
It’s missing at least one of the includes, but off hand I don’t know which one. - I’ve tried every example of a DTS file given on the forum, referring to getting PPS pins to work on the La Frite or the Le Potato, as well as the “offical” pps-gpio-7j1-12.dts on the github.
If I somehow don’t get an error pointing to the includes, I get an error pointing to the labels/symbols being invalid… presumably because of not having the include.
I’ve also used SVN to pull the entire dt-bindings directory from the GIT, and added it to the /usr/includes directory.
At this point, I don’t know if my cobbled overlay using direct references is fully functional or not. I can get inputs from the PPS and UART-B, but can’t get gpsd to read from them.
