EtlARM

Just installed the missing Armbian updates -> no change to missing symlink. Now timestamp of Device-Tree-Binary is 2021-01-05 23:17:53 (as expected with Armbian 20.11.6)

Hi, thanks for the input Your link is for the Cubieboard 2, I have the CubieTruck (also numbered 3) Looking at: https://linux-sunxi.org/Cubietech_Cubietruck my Device-Tree should be: sun7i-a20-cubietruck.dtb On my board, this file has a timestamp: 2020-10-20 22:15:29 (like all other .dtb files) This also looks ok to me: > cat /proc/device-tree/model Cubietech Cubietruck I have no experience with Device-Tree. Has someone an idea how to evaluate that further?

I just installed latest CubieTruck image (Armbian_20.08.2_Cubietruck_buster_current_5.8.6) and /sys/class/power_supply/axp20x-ac is missing. With older image (Armbian_20.05.4_Cubietruck_buster_current_5.4.45) it was present. Any ideas? ls /sys/class/power_supply/ lrwxrwxrwx 1 root root 0 Okt 21 00:00 axp20x-battery -> ../../devices/platform/soc/1c2ac00.i2c/i2c-0/0-0034/axp20x-battery-power-supply/power_supply/axp20x-battery lrwxrwxrwx 1 root root 0 Okt 21 00:00 axp20x-usb -> ../../devices/platform/soc/1c2ac00.i2c/i2c-0/0-0034/axp20x-usb-power-supply/power_supply/axp20x-usb

Yes, I had seen these posts some time ago. They contain some really useful links. But as I forgot to bookmark it, is is very good you dig it out again. When I find some spare time, I will try to modify the AXP209 registers directly.

Yes, I read the forum during the last years, also read the datasheet of the charging controller and also the github repository to control it.

Does anybody have a solution how to charge battery with more conservative voltage range? I'm using battery backup for my CubieTruck boards to survive power outages for several years. And as one of the batteries recently blew up (and also killed the backup HDD next to it) I try to find a way to charge the battery in a range that preserves health of it. When searching for a long-term-save voltage range of LiPo batteries you get something like: use only half of capacity, much below 4V, never deep charge, ... Default setting for the AXP209 charge controller is to charge to 4,2V, and emergency shutdown is at 2,9V. These ranges are much too broad and may damage the battery over the years. Deep discharge protection is quite easy, just use a script to regularly check current voltage and issue a shutdown when too low (no clue, why this is not already handled by the OS): if [ $(cat /sys/class/power_supply/axp20x-battery/status) = Discharging ]; then if [ $(cat /sys/class/power_supply/axp20x-battery/voltage_now) -lt 3200000 ]; then # prevent undervoltage shutdown -h fi fi But target voltage for the charge controller is not that easy to change, as AXP209 only supports 4,1V / 4,15V / 4,2V / 4,36V: echo 4100000 > /sys/class/power_supply/axp20x-battery/voltage_max_design I tried to reduce the charge current with rising voltage to stop charging at some point: echo 300000 > /sys/class/power_supply/axp20x-battery/constant_charge_current_max But the minimum supported value is 300mA, which is still charging and increasing the voltage. Also the charge current can not be increased again after setting a lower value. Does anybody have an idea how to stop charging at some voltage and to resume if it has dropped again below a second threshold?

As I asked the same question some time ago, this thread may help . . .

All motd messages are created by scripts located here: /etc/update-motd.d/ To get another name displayed, I always change /etc/update-motd.d/10-header #TERM=linux toilet -f standard -F metal $BOARD_NAME TERM=linux toilet -f standard -F metal $(hostname -s) ... or whatever you like as name.

Could anybody give a hint where to find the script that is executed during kernel upgrade? Than we could start some high level debugging.

With every upgrade I struggle with a "changed to default" login welcome message and have to do my modifications again. Therefore I would like to explain my changes and hope you can integrate them in the default version...: Your welcome message prints the $BOARD_NAME as ASCII art. Probably you have dozens of boards and can distinguish them in this way. So after login-in you directly see which board it is. I have only one type of "boards" (Cubietruck) and distinguish them by their hostname. So I have to replace "$BOARD_NAME" with "$(hostname -s)" in /etc/update-motd.d/10-header to identify my boards. What do you think about a change in that direction?

Just did the 5.23 -> 5-25 upgrade on a Cubieboard2 (with NAND). Everything went fine! In case someone tries to replicate the problem I mentioned, here a list with things that were different to your test setup: Debian Jessie Server instead of Xenical SATA disk connected and mounted as /backup SD card connected and mounted as /var/ftp/sdcard old system was installed and last updated in summer 2016, so maybe another version and different update level of all packages

Is this problem back again? https://forum.armbian.com/index.php/topic/690-upgrade-error-with-armbian-500-on-cubieboard2-running-from-nand/ I also experienced problems with the 5.24 (or was it 5.23?) upgrade made during Christmas. It also bricked the system on NAND, but I don't remember what went wrong. I reinstalled from scratch because no supporting tools where available far away from home. With the right tools to hand it should be possible to recreate the boot files on NAND with the help of the linked thread. As I have to do the 5.25 upgrade in the next days, I would appreciate when this problem gets sorted out sooner than later...

You have to load the correct kernel module to enable watchdog support in general: nano /etc/modules # and append this somewhere (reboot afterwards) sunxi-wdt And you have to install the watchdog package: apt-get install watchdog It is possible to configure some more stuff here: nano /etc/watchdog.conf But I have the feeling that it works just out of the box. I would appreciate if you could post your experience with that settings.

Hi, I'm using the CubieTruck with legacy kernel and also searching for watchdog support. As far as I can figure out, the kernel seems to be compiled without watchdog support: /dev/watchdog is not present and /var/log/syslog does not contain anything with sunxi_wdt

End of last year I received several faked Samsung EVO 32G, therefore I bought a Samsung Pro 32G: Tested on CubieTruck, Armbian 5.11, ext4, card is used for 7 month, system is doing some minor background work.