tkaiser Posted January 13, 2016 Posted January 13, 2016 Hi folks, I started to think about that a while ago and want to share my thoughts with you. In my opinion RPi-Monitor is a great tool to get a clue what's going on on a SBC (especially when testing stuff but also in 24/7 use). It's also lightweight enough to run all the time in the background collecting data and to be used by a few clients also (rendering/display happens in the user's browser and not on the SBC). Currently users have to install RPi-Monitor manually and sometimes seem to be confused (for example they switch between legacy and vanilla/mainline kernel and temperature/consumption graphs disappear). If we would integrate RPi-Monitor into Armbian (integrate means 'installation by default, right adjustments by default, activation by user on demand') I see the following advantages: easier to support users when they experience strange problems. Simply tell them to 'systemctl/service ... rpimonitor' and get back to us with monitoring data choosing the right template (based on kernel version and maybe also other conditions like connected disk or not) Increasing the meaning of motd (for example using rrdtool to fetch temperature or average load peak values from the RRD databases RPi-Monitor maintains) Encouraging developers to write drivers for stuff that's currently missing in mainline kernel (eg. reading out the consumption stuff from the AXP209 PMU -- it should be relatively easy to port the old sysfs driver to mainline but nobody done it so far) Disadvantages: A lot of efforts even if most of the boards we support now are already covered by RPi-Monitor support (all Allwinner A10/A13/A20/H3 devices and the S500 boards -- Armada A38x, Allwinner A31s, ODROID and i.MX6 missing). What do you think?
zador.blood.stained Posted January 13, 2016 Posted January 13, 2016 If we would integrate RPi-Monitor into Armbian (integrate means 'installation by default, right adjustments by default, activation by user on demand') Possible problem #1: delivering fixes and new configuration files to existing Armbian installations, i.e. user updated kernel to a new version that supports new AXP parameters, but RPi-Monitor doesn't know about this. Possible solution: making Debian package and hosting it in Igor's Armbian repo, updating this package when new kernel stuff comes out or to fix any bugs. Encouraging developers to write drivers for stuff that's currently missing in mainline kernel (eg. reading out the consumption stuff from the AXP209 PMU -- it should be relatively easy to port the old sysfs driver to mainline but nobody done it so far) Possible problem #2: RPi-Monitor fork graph on GitHub looks like a christmas tree. Which version to use (original? your? ) and how to maintain it.
tkaiser Posted January 13, 2016 Author Posted January 13, 2016 I think it's necessary to fork the project and to integrate it through an own .deb that gets updated automagically. The dependency stuff (which board and which kernel/features) could be handled by the start script. Eg. using output of 'uname -r' and armhwinfo (/var/run/machine.id) and comparing some values [1] you could reliably choose the right templates prior to starting rpimonitord. Same applies to disk monitoring. If we would integrate rpimonitord we could use uevent/udev rules to maintain disks by id (GUID) while watching at device nodes. Eg. /dev/sdb appears on the USB bus, we translate /dev/sdb to eg. A57BF307-7D82-4783-BD1D-B346CA8C195B using 'gdisk -l /dev/sdb' and then monitor drive health/temperature of device /dev/sdb in database A57BF307-7D82-4783-BD1D-B346CA8C195B.rrd. When the disk appears next time as /dev/sda instead -- no problem since mapping happens dynamically. This would just require adding gdisk and smartmontools to the default packages... and a lot of work to maintain this later... Still thinking about whether that's worth the efforts. [1] Eg. /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/power_supply/battery/current_now greater than 0 but /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/power_supply/battery/voltage_now equal to 0 --> A10/A20 device (most likely Lamobo R1) fed with 5V through LiPo battery connector
tkaiser Posted January 13, 2016 Author Posted January 13, 2016 We could also address some other problems due to outdated packages (applies to smartmontools in Wheezy that needs a fix to be able to update the drivedb and the hddtemp package). I thought about writing a small bash script 'add-disk' for these monitoring purposes. This script would do the following: install gdisk/smartmontools if not already installed, patch it if necessary (Wheezy) and update the drivedb list available disks (relying on GUIDs but showing the device name so users could easily choose the right device) look whether that disk is in the hddtemp.db (most probably not since the hddtemp package is dead/unmaintained and its database is from 2007) list thermal values that 'smartctl -a' outputs and asks the user whether one of the results should be added to hddtemp's database opionally offer to add known S.M.A.R.T. attributes that are worth a look (attribute 199 to check cable/connection problems or the LCC value) to the monitoring If you want to add such 'extended' SMART stuff to RPi-Monitor it will cost you one or even many hours to figure out how this template stuff works and how to reliably let smartctl do the job. If we would prepare this, let smartd do the job and offer the opportunity to simply use the collected data from smartd in rpimonitor Armbian would provide real added value here.
zador.blood.stained Posted January 13, 2016 Posted January 13, 2016 If the first goal of integrating rpi-monitor is easier to support users when they experience strange problems. Simply tell them to 'systemctl/service ... rpimonitor' and get back to us with monitoring data then maybe it's better to start with basic stuff - load average, memory usage, rootfs space usage, CPU & PMU temperature (if available). Reading S.M.A.R.T. attibutes of external drives won't help in 95% of cases (if not in 99%) on this forum, for example. We could also address some other problems due to outdated packages (applies to smartmontools in Wheezy that needs a fix to be able to update the drivedb and the hddtemp package). If they don't have too much dependencies it may be possible to install and automatically update jessie versions of these packages. Edit: wheezy-backports has almost the same "smartmontools" version as jessie. "hddtemp" in both wheezy and jessie has exactly the same versions.
tkaiser Posted January 13, 2016 Author Posted January 13, 2016 wheezy-backports has almost the same "smartmontools" version as jessie. "hddtemp" in both wheezy and jessie has exactly the same versions. The version of smartmontools isn't the main problem but there's a wrong link in the update-smart-drivedb script that prevents smartctl/smartd from learning newer drives' SMART capabilities. Patching is easy but if using the backports version will fix this also then it's probably better to include this on Wheezy ... The database even for the old smartmontools version used by Wheezy is still maintained: http://sourceforge.net/p/smartmontools/code/4199/log/?path=/branches/RELEASE_5_41_DRIVEDB/smartmontools/drivedb.h I summarized the problem with both packages almost immediately when I started to try to use sunxi SBCs as small servers: http://forum.lemaker.org/forum.php?mod=viewthread&tid=7102(chapter "Drive health / temperature"). Since the ability to check drive health is a prerequisit in my eyes when running a server. And that's where the 'Added value' comes from that might attract more users to try out Armbian. Anyway: You're right, we should start with basic stuff but don't forget about the extended monitoring stuff that will only work if we integrate our own fork of rpimonitord into Armbian. I will think about a basic set of monitoring sources that would be useful on all boards supported by Armbian without requiring that much external dependencies or extended stuff. But not until my Clearfog arrives and I had a look myself which data sources are available with Armada A38x today.
tkaiser Posted January 15, 2016 Author Posted January 15, 2016 I just had a look at sunxi SoC thermal read-outs and came up with a new variant of sunxi_tp_temp (needs also mod_mmio.h): sunxi_axp209_temp.c: http://pastebin.com/GS9FpaaG(the idea is to include this binary as a fall-back mechanism when A10/A13/R8/A20 temp can not be read from kernel... or the read-out is known to be wrong -- I don't know whether that applies to Armbian but unpatched kernel 4.1 suffered from wrong temperatures) Unfortunately I'm too dumb to implement switch "-n" that should output the temperature in degree C * 1000 (so that the value is the same as when querying /sys/class/thermal/thermal_zone0/temp --> 39200 instead of 39.2). When we had a look into this last time we found out that we've to deal differently with different SoCs: http://forum.armbian.com/index.php/topic/155-testers-wanted-sunxi-adjustments-for-rpi-monitor/?p=967 #!/bin/bash CheckSunxiHardware() { SunxiGeneration="$(awk -F" " </proc/cpuinfo '/^Hardware/ {print $3$4}')" case ${SunxiGeneration} in *sun7i*) # A20 CpuPart="$(awk -F" " </proc/cpuinfo '/^CPU part/ {print $4}')" case ${CpuPart} in *0xc07*) echo "A20: /path/to/sunxi_axp209_temp 144700 100" ;; esac ;; *sun5i*|*A1X*) CpuRevision="$(awk -F" " </proc/cpuinfo '/^Revision/ {print $3}')" case ${CpuRevision} in *a13*|*A13*) # A13 echo "A13: /path/to/sunxi_axp209_temp 144700 100" ;; *) # A10 echo "A10: /path/to/sunxi_axp209_temp 257000 133" ;; esac ;; esac } # CheckSunxiHardware CheckSunxiHardware Now I'm stuck not knowing whether we should/could deal with the different SoCs inside the sunxi_axp209_temp.c code and whether this binary is still needed (at least true for users running A10/A13 boards with kernel 3.4). Also it would be interesting to compare the output of /sys/class/thermal/thermal_zone0/temp with sunxi_axp209_temp on A10/A13 boards when using mainline kernel there. But I've only A20 boards lying around...
tkaiser Posted January 17, 2016 Author Posted January 17, 2016 @Igor and others: I need some feedback please Currently I'm thinking about to split the armbianmonitor approach into the following parts: 1) RPi-Monitor installation at the usual location (below /etc/rpimonitor/ and /usr/share/rpimonitor/). Actually there's no need to fork RPi-Monitor as long as we manage to install it somehow automagically in case it's needed. I would prefer to not alter anything _inside_ RPi-Monitor except of relinking /etc/rpimonitor/data.conf. Users could then also update RPi-Monitor to make use of new features or extend their templates nearly unlimited while our armbianmonitor approach still works since we're just providing an environment for rpimonitord (a few templates with fixed names using the right data sources and a daemon collecting data otherwise unavailable). 2) Three scripts and one binary (maybe more later): /usr/sbin/armbian-monitoring /usr/sbin/setup-armbian-monitoring-environment /usr/sbin/armbian-update-disks /usr/bin/sunxi_axp209_temp 3) Dynamically created template stuff below /etc/armbianmonitor/ 4) A collection of data sources below /etc/armbianmonitor/datasources/ -- either through symlinks pointing to sysfs nodes or by filling in values into files in daemon mode: root@lime2:/etc/armbianmonitor/datasources# ls -la total 8 drwxr-xr-x 2 root root 4096 Jan 17 14:16 . drwxr-xr-x 4 root root 4096 Jan 17 14:20 .. lrwxrwxrwx 1 root root 30 Jan 17 14:16 ac_current -> /sys/power/axp_pmu/ac/amperage lrwxrwxrwx 1 root root 29 Jan 17 14:16 ac_voltage -> /sys/power/axp_pmu/ac/voltage lrwxrwxrwx 1 root root 35 Jan 17 14:16 battery_current -> /sys/power/axp_pmu/battery/amperage lrwxrwxrwx 1 root root 34 Jan 17 14:16 battery_voltage -> /sys/power/axp_pmu/battery/voltage lrwxrwxrwx 1 root root 36 Jan 17 14:16 pmictemp -> /sys/power/axp_pmu/pmu/internal_temp lrwxrwxrwx 1 root root 47 Jan 17 14:16 soctemp -> /sys/devices/virtual/thermal/thermal_zone0/temp lrwxrwxrwx 1 root root 32 Jan 17 14:16 usb_current -> /sys/power/axp_pmu/vbus/amperage lrwxrwxrwx 1 root root 31 Jan 17 14:16 usb_voltage -> /sys/power/axp_pmu/vbus/voltage The scripts do the following: armbian-monitoring is meant to be called by our users to activate monitoring (a new user reports here in the forum that he/she experiences sudden shut-offs, then we recommend using 'sudo armbian-monitoring' to enable monitoring followed by a reboot and to get back to us with reliable informations). It will also list connected disks and asks whether these should be monitored or not. setup-armbian-monitoring-environment should be executed at boot by armhwinfo, sets up the necessary environment for rpimonitord and then decides whether to start rpimonitord or not I believe armhwinfo is the right place to interact with setup-armbian-monitoring-environment since in case a new board will be supported adjustments need to be made always to both scripts. I also believe it's better to force users into a reboot when they experience problems to activate monitoring since some problems simply disappear by a reboot (true also for Linux sometimes ) Please read through the early stubs (a bunch of comments and few code now) of both armbian-monitoring and setup-armbian-monitoring-environment and provide some feedback: armbian-monitoring: http://pastebin.com/nuqnuQua (new version with nearly all necessary code to deal with disks) setup-armbian-monitoring-environment: http://pastebin.com/BJThzxwA (new version with AXP209 function defined) BTW: Would be great if armhwinfo would export the necessary variables and/or could be called sane by invoking '. /etc/init.d/armhwinfo' EDIT: Getting the variables works this way: . /etc/init.d/armhwinfo start >/dev/null 2>&1 EDIT: Updated the script skeletons again and will pause for a while
zador.blood.stained Posted January 20, 2016 Posted January 20, 2016 It would be really interesting to see what features are the most needed and most requested for Armbian users, sadly this forum doesn't have polls as far as I see, but since there are not so many active users interested in new features, simple post answers probably will work too. For example, possible data: System load info (load average, memory and swap usage) Filesystem status (free space on root, boot partition (if exists), external drives) Power monitoring data from axp20x SoC temperature HDD S.M.A.R.T. data - drive temperature and health Representation of data: Current (instantaneous) values Min/max observed values Full history (charts) Additional features: Event logging when parameters go beyond defined min/max values Console interface (single command to display all values) Web UI
zador.blood.stained Posted January 20, 2016 Posted January 20, 2016 @tkaiser I'll check your scripts and if they have a chance to work on my heavily modified system, I'll give it a try. Especially since looks like S.M.A.R.T. monitoring causes external HDD spin-up in USB/UAS enclosure, in fact it doesn't spin down at all with smartd set to monitor all available HDDs. Another thing - maybe host these scripts on GitHub (GitHub gists at least)? It's easier to update via git and easier to see diff/changelog.
tkaiser Posted January 20, 2016 Author Posted January 20, 2016 Zador, it's definitely too early to try the scripts out. I just collect pieces of code 'known to work' but the most important script's contents now is the structure and my assumptions the script code might express (eg. showing that a few variables used in Armbian might require more work if changed in the future -- eg. $ID containing the board's name) In the meantime I came to the conclusion that the armbianmonitor approach has to co-exist with rpimonitor (or any monitoring solution one might use). That means we only provide a set of data sources (through symlinks, template's contents and a daemon approach where it's necessary to not only collect data but to provide a more intelligent representation that can be used by any monitoring tool -- eg. the whole battery stuff) that any user might use or not. Eg. when someone installed RPi-Monitor on his own and extended the configuration in /etc/rpimonitor extensively (using environment sensors for example) we won't overwrite anything but provide template contents instead that can be easily adopted by the user by either including our templates in his data.conf or simply copy&paste from our templates to get the data sources armbianmonitor provides into his own customised templates) Regarding your questions/suggestions: I would take the actual set of data sources RPi-Monitor uses (just modify it slightly, eg. leave out the 'firmware' version since this doesn't apply to the boards Armbian supports). The board specific things are just thermal and/or consumption stuff so we will provide a huge amount of data even when board/kernel does not support these special read-outs (the _DealWithNewBoard_ case). Apart from this board specific stuff (great for supporting users if they experience stability issues due to hardware/power problems!) the most added value will be generated by dynamic template creation for disk/filesystem stuff and also 'monitoring' itself. Filesystems: Still not sure whether we should use a config file (one watchpath per line, eg. /, /data and so on) and create templates dynamically based on the config file's contents (risking that people create templates that won't work) or simply abandon /etc/armbianmonitoring/filesystems.conf and parse the output of 'df' instead (creating templates for / and the mountpoint of every other sd* disk device automagically) Disks: I also came to the conclusion that smartd won't work in our situation (due to preventing spin-down). It's necessary to specify the tool (hddtemp or smartctl), the smartctl mode (nothing for SATA connected disks but eg. '-d sat' or '-d usbprolific' and so on for USB disks) and the appropriate command line to get temperature values if hddtemp can not be used, eg. /sbin/hdparm -C DISK | egrep -q "standby|sleeping" || /usr/sbin/smartctl -d sat -a DISK | awk -F" " '/Temperature_Cel/ {printf $10}' I made many tests with different USB enclosures the last days, just to learn that hddtemp is crap (to be expected, the code is really old). I'll come up with a disk readme that will be hosted on Github together with the scripts if they're worth a try (at the moment they aren't -- just look into it to get an idea where I want to rely or have to interact with Armbian 'basics') Regarding representation of data. IMO the UI of choice is the web interface of RPi-Monitor (very lightweight using HTML5 and doing all the rendering work in the client's browser). RPi-Monitor already supports defining warning/error tresholds so UI elements change automagically their color if tresholds will be exceeded. Then I plan to consistently provide the ability to use all the data sources we collect through SNMP (net-snmp package and a simple config file that can be used with an include rule). This might be an interesting 'business' feature for Armbian. Instead of buying an insanely overpriced networked thermal sensor for a rack cabinet (from APC for example) one could use a cheap SBC in the rack providing the very same data through SNMP and also doing a couple of other things. If monitoring is enabled and rpimonitord collects data in its many RRD databases then also all sorts of queries are possible. Eg. modify the motd stuff to not only show actual temperature, load, memory useage, whatever while logging in but the peak values from the last 24/48/168 hours (simply using rrdfetch). Also calling 'logger -t armbianmonitor' with actual values when collecting data in daemon mode is easy. There exist countless possibilities if basics are fixed. At the moment I need just a little feedback from you guys doing the development of Armbian's build scripts to get a feeling whether the idea to also maintain one more included script (and a bunch of templates in case basics change!) scares you too much or not. As an example: Changing the board's names ($ID in armhwinfo) in the future would also require to adjust the contents of setup-armbian-monitoring-environment. Also when something happens as your axp209_sysconfig stuff: the immediate need to extend templates will arise In the meantime I discovered that there aren't that much dependencies between Armbian and armbianmonitor as I thought in the beginning. But there still are some and the efforts to maintain this stuff has to be considered. Therefore I still wait for some comments on this... and develop the scripts and template stuff in the meantime (useable for both rpimonitord and net-snmp). If it's ready for try-out I will either push the stuff through Igor into Armbian's repo or provide it in an own repo. At the moment the script code is just meant for you other Armbian coders to look through and provide feedback regarding dependencies. BTW: Another interesting RPi-Monitor feature is the 'addons' functionality. In case the user chooses armbianmonitor 'debug' functionality we could activate some of those addons (eg. displaying the 'top' 10 processes through RPi-Monitor's web UI or anything else that helps with debugging strange problems)
zador.blood.stained Posted January 21, 2016 Posted January 21, 2016 Main suggestion for the backend/data collection daemon configuration would be splitting single script into a modular/plugin based system. On startup main script loads all available plugins from a directory (or from multiple directories), each plugin tests for its data source (like SoC temperature, PMU data) and adds configuration entries to volatile config file. It improves readability, It simplifies testing, It simplifies per-board and per-plugin configuration (great for supporting users if they experience stability issues due to hardware/power problems!) axp202/209 has interrupts for all possible power related issues, it would be easy to implement power diagnostics as a standalone service (especially useful for boards like Lamobo-R1), but unfortunately AXP power driver was submitted in October 2014 and there is no visible progress since its submission. Filesystems: Still not sure whether we should use a config file (one watchpath per line, eg. /, /data and so on) and create templates dynamically based on the config file's contents (risking that people create templates that won't work) or simply abandon /etc/armbianmonitoring/filesystems.conf and parse the output of 'df' instead (creating templates for / and the mountpoint of every other sd* disk device automagically) If only it worked automagically With free disk space IMHO the best approach is - show warnings if any non-temporary mount has less than configured (i.e. 10% by default) free space. At the moment I need just a little feedback from you guys doing the development of Armbian's build scripts to get a feeling whether the idea to also maintain one more included script (and a bunch of templates in case basics change!) scares you too much or not. As an example: Changing the board's names ($ID in armhwinfo) in the future would also require to adjust the contents of setup-armbian-monitoring-environment. Also when something happens as your axp209_sysconfig stuff: the immediate need to extend templates will arise This is exactly where modular approach would show its advantages. New board (i.e. Clearfog) has new PMU interface? Just add new plugin, test it and add it to new release.
tkaiser Posted January 22, 2016 Author Posted January 22, 2016 After thinking about it your plugin style is the way to go. Will refactor the stuff the next day after finishing the battery stuff (still waiting for the ordered battery to arrive). We need the following per board (being 'unknown' a special board with yet unknown characteristics) basic RPi-Monitor template (CPU/PMIC specific) extended/debug RPi-Monitor template (CPU/PMIC specific an containing probably more information sources needed when turning on debug monitoring) a set of script code to deal with the board at startup a set of script code to deal with the board in an endless loop (eg. reading out SoC temperature when not available through sysfs or providing real consumption numbers when running on battery) This 'endless loop' will also be responsible for disk monitoring (hddtemp for SATA, hdparm/smartctl for USB in most cases) Will start with AXP209 on an Olimex Lime2 and put that stuff on Github (hopefully within the next 4 days). Regarding the AXP power driver: It seems the author (bonbons) even disappeared from IRC
tkaiser Posted January 28, 2016 Author Posted January 28, 2016 Just a small update: This is the result based on this template: http://pastebin.com/75qRgFm7 Charging state and display of different data sources done dynamically based on values: 1
Tido Posted January 28, 2016 Posted January 28, 2016 Looks nice. concering accu - to have a long life for a Li-Ion accu it should be used between 15 - 80% above and below is stress /mobile /laptop /tablet and so on. I don't know if there is a possibility to change the color of the Accu-Capacity already from 80% to green - but I thought it is worth to know it. The Lenovo Power Manager 6 offers me to adjust max charge and a threshold for start to charge again. Just as information - I don't expect this functions. What you have designed is already great.
zador.blood.stained Posted January 28, 2016 Posted January 28, 2016 The Lenovo Power Manager 6 offers me to adjust max charge and a threshold for start to charge again. Just as information - I don't expect this functions. Unfortunately, recharge voltage is not configurable and it's set to (target voltage - 0.1) V
tkaiser Posted January 28, 2016 Author Posted January 28, 2016 I don't know if there is a possibility to change the color of the Accu-Capacity already from 80% to green The problem is that RPi-Monitor currently only provides warning/error conditions based on higher values for the JustGageBar display type. That means if you define the valid data range as "0 - 100" then you could define a warning and an error treshold. But colors change from green or red only when exceeding these tresholds. And with battery percentage it should be the other way around. It should become orange when less than 25% and red when less than 10% for example. Unfortunately not possible at the moment. For this the javascript code that does the rendering would've to be adjusted and that is something I don't want to touch at the moment (still want to make armbianmonitor to be useable with any 'standalone RPi-Monitor installation' and not a patched/forked one we'll have to include)
zador.blood.stained Posted January 28, 2016 Posted January 28, 2016 Ok, I installed RPi-Monitor and looked at its configuration. Also I looked at your latest template. I think that differences between data sources should be implemented via different template files that will be included in data.conf So data.conf includes /etc/armbianmonitor/battery.conf, which is a symlink either to axp209-battery-legacy.conf or axp209-battery-mainline.conf, same with other board- and device-specific stuff. If data source is not available, it can be symlinked to an empty template. configuring this for jessie is a piece of cake # /etc/systemd/system/rpimonitor.service.d/10-armbianmonitor.conf [Service] ExecStartPre=/usr/bin/armbianmonitor-prepare-symlinks.sh This way main rpi-monitor process starts only after armbianmonitor-prepare-symlinks.sh exited
tkaiser Posted January 28, 2016 Author Posted January 28, 2016 I think that differences between data sources should be implemented via different template files that will be included in data.conf Unfortunately I hadn't the time to put all the stuff on Github. So again just as a reference: setup-armbian-monitoring-environment: This will be started at boot, creates the symlinks (TODO: filesystem/disk config, implement battery template selection and your plug-in approach instead of functions for each SoC/PMIC combination and add the loop stuff) and a basic /etc/armbianmonitor/armbian.conf template where /etc/armbianmonitor/cpu_pmic.conf is included which is a simple symlink to the correct template (/etc/armbianmonitor/templates/axp209_template_battery.conf in this case) If SoC/PMIC have the ability to use/charge batteries i would prefer maintaining two templates (since you don't want to see empty battery stuff when there's no battery possible/available). You could do this in a single template using RPi-Monitor's visibility feature. But then setting up the templates gets overly complicated therefore I would prefer maintaing a battery and a non-battery template and let setup-armbian-monitoring-environment decide which to link to cpu_pmic.conf armbian-monitoring: helper script to activate monitoring (also debug mode or not) and to deal with disks (TODO: finish) Please give me just a little bit more time. I want to finish this for A20/AXP209 and Armada 38x (my Clearfog should arrive today or tomorrow) and put it then on github. The basic idea is still: Relink data sources to files below /etc/armbianmonitor/datasources (and where no datasource is available create a file instead and let setup-armbian-monitoring-environment write values collected in daemon mode into (applies to disk temperatures for example or A20 temperature when not using mainline kernel) Use maximum 4 templates for each SoC/PMIC configuration (with and w/o battery, each with and w/o debug mode) At the moment I'm in this stage: root@lime2:/# ls -alR /etc/armbianmonitor/ /etc/armbianmonitor/: total 32 drwxr-xr-x 4 root root 4096 Jan 28 09:30 . drwxr-xr-x 79 root root 4096 Jan 1 1970 .. -rw-rw-r-- 1 root root 551 Jan 17 15:42 armbian.conf lrwxrwxrwx 1 root root 58 Jan 26 13:32 cpu_pmic.conf -> /etc/armbianmonitor/templates/axp209_template_battery.conf drwxr-xr-x 2 root root 4096 Jan 27 21:57 datasources -rw-r--r-- 1 root root 223 Jan 19 17:34 disks.conf drwxr-xr-x 2 root root 4096 Jan 28 09:30 templates -rw-r--r-- 1 root root 1009 Jan 17 15:42 uptime.conf -rw-r--r-- 1 root root 1724 Jan 17 15:42 version.conf /etc/armbianmonitor/datasources: total 8 drwxr-xr-x 2 root root 4096 Jan 27 21:57 . drwxr-xr-x 4 root root 4096 Jan 28 09:30 .. lrwxrwxrwx 1 root root 30 Jan 17 15:42 ac_current -> /sys/power/axp_pmu/ac/amperage lrwxrwxrwx 1 root root 29 Jan 17 15:42 ac_voltage -> /sys/power/axp_pmu/ac/voltage lrwxrwxrwx 1 root root 35 Jan 27 21:57 battery_charging -> /sys/power/axp_pmu/battery/charging lrwxrwxrwx 1 root root 35 Jan 22 21:41 battery_current -> /sys/power/axp_pmu/battery/amperage lrwxrwxrwx 1 root root 35 Jan 22 21:18 battery_percent -> /sys/power/axp_pmu/battery/capacity lrwxrwxrwx 1 root root 34 Jan 22 21:40 battery_voltage -> /sys/power/axp_pmu/battery/voltage lrwxrwxrwx 1 root root 35 Jan 26 13:24 charger_current -> /sys/power/axp_pmu/charger/amperage lrwxrwxrwx 1 root root 27 Jan 22 16:35 pmictemp -> /sys/power/axp_pmu/pmu/temp lrwxrwxrwx 1 root root 47 Jan 17 15:42 soctemp -> /sys/devices/virtual/thermal/thermal_zone0/temp lrwxrwxrwx 1 root root 32 Jan 17 15:42 usb_current -> /sys/power/axp_pmu/vbus/amperage lrwxrwxrwx 1 root root 31 Jan 17 15:42 usb_voltage -> /sys/power/axp_pmu/vbus/voltage /etc/armbianmonitor/templates: total 36 drwxr-xr-x 2 root root 4096 Jan 28 09:30 . drwxr-xr-x 4 root root 4096 Jan 28 09:30 .. -rw-r--r-- 1 root root 654 Jan 17 15:58 armbian.png -rw-r--r-- 1 root root 12302 Jan 28 09:30 axp209_template_battery.conf -rw-r--r-- 1 root root 7547 Jan 18 15:56 axp209_template.conf Let me try out to add the Clearfog and to compare with the old AXP209 sysfs interface, put this on github and then decide together in which direction to go? 1
Recommended Posts