sgjava

I sent you an email, so as not to pollute this thread. I believe it's possible to do MMIO GPIO based on some projects I've seen. I just need to do the mappings.

@diozeroWhen I say generic I mean there's not a particular class tied to a board (even if you use an interface to abstract away the implementation). I'd be OK with some common C or ASM code, but only the memory mapping would be board specific and require no custom code. If you look at my library there's no board specific code in it, thus it's cross platform (like your sysfs provider). I'll dig into your code some more, but this is basically what I was trying to stay away from. It may not be possible to do what I'm describing i.e. use MMIO to do GPIO.

Yes, it was worth mentioning since it's the first tie I saw this. It is self correcting after apt upgrade.

Answering my own question here. apt upgrade resolves this issue.

@diozeroif you look at my library java-periphery you will see some Armbian related info there (including device tree stuff). I ended up just wrapping c-periphery since it supports deprecated sysfs and currently supported gpiod. I abandoned libgpiod because it was more difficult to compile and c-periphery can be compiled inline using hawtjni. It would be interesting if you got MM GPIO working on Armbian in a generic way, but I didn't see an easy way to do it. I'm OK with gpiod since it has decent performance and is cross platform out of the box.

Err:14 https://uk.mirrors.fossho.st/armbian/apt focal/main armhf Packages File has unexpected size (516030 != 453208). Mirror sync in progress? [IP: 82.145.63.161 443] Hashes of expected file: - Filesize:453208 [weak] - SHA512:2106846c18399ffc28b2da849488e65c512fdc5024e395233874da288a0f8bcd380c31e0a6d8b86689adcb695b8d1ddf53714310976c520a51433887c8596c64 - SHA256:f98960dc39dcf26f9825ea957244139e72bc71bf64f5a7c4a5f714ec9c53b252 - SHA1:a8eff6f5dcf5e2dcc6c1eefffc99951543612c2a [weak] - MD5Sum:81ae2c24b7cc23144890c2db0cb64df5 [weak] Release file created at: Mon, 1

@Tido I made an edit to top of post. https://github.com/sgjava/java-periphery

Actually I tried based on it's for the Duo, but I would imagine I'd do this for any of my boards with this behavior.

Would there be a way to add a configuration option to armbian-config to disable built-in button being used for shutdown? Currently I have to remove the r_gpio_keys section in the DTB and compile. Seems like something armbian-config could do?

Ha, no, I don't work for Oracle. In fact, I use Zulu Open JDK https://www.azul.com/products/zulu-enterprise/jdk-comparison-matrix since it's easier to download and doesn't require an account like Oracle JDKs. I actually develop Java Periphery on a x86-64 platform and test on ARM 32/64. Zulu is a great OpenJDK implementation. I've used XenServer a lot, but OpenStack is very interesting. The main issue with RedHat is not to fall into the "Enterprise" trap which is their paid for software and services. RedHat is famous for wrapping Open Source in their GUIs and selling that to Enterprise customer

So basically the topic drifted from Zabbix (omni monitoring tool) to Cockpit (admin tool) and you mentioning Node.js which is based on an event loop. My point was the thread vs. event loop argument was solved decades ago, but people keep reinventing event loops as more scalable. They probably didn't read the seminal research already out there. There are interesting structures like ring buffers that can scale massively and replace queues. https://lmax-exchange.github.io/disruptor. Any ways, I'm not falling into the JS/TS/Node.js trap. I'll stick with Java/Python/C/C++ as most of my work doesn'

It's funny you mention Node.js as the question of event loop vs. threads was answered back in the 70s. This paper explains it and even it is 17 years old. https://people.eecs.berkeley.edu/~brewer/papers/threads-hotos-2003.pdf Any ways, newer isn't always better.

I'm really not looking at Zabbix as a development platform. It's a tool and that's what I use it for, so the underlying stack is not that interesting to me. Also, Zabbix can be served up with nginx or use PostgreSQL if that matters. Cockpit is more of an admin tool with limited monitoring (compared to Zabbix) from what I can tell and it's only for Linux. Zabbix has cross platform agents and can monitor diverse things like DBs, web endpoints, switches (or my refrigerator). Plus I'll let Zabbix fix issues for me automatically without any intervention. They are fundamentally different tools.

Actually Zabbix is monitoring software that collects telemetry and allows actions such as emailing, texting, restarting services or servers based on conditions and escalations. I've totally automated network admin type roles with it and things at home like monitoring the power state of my beer refrigerator in the garage. It's super flexible and easy to add stuff to the agent for client specific needs. It can also scale to millions of devices or just a handful at home. Also, the agent is now golang, not C. Cockpit looks more like Webmin on steroids. It's also Linux only from what I can tell.

I've used Zabbix professionally and at home to monitor servers, IoT, and IP devices. I've built scripts for the server and client to automate the install process including moving the MySQL database, so you can locate it to a NFS mount instead of serving the database from the slower SD card. The deb packages do not work for ARM, so you have to build it from source using my scripts. Install Zabbix