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.