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.

You have to redo the change described in that post for every upgrade. The upgrade affects also the file /boot/bin/cubietruck.bin so your changes get lost.

Yes, it is very likely the same or similar problem. On my NAND1 I found only a zImage identical to the vmlinuz file but not an uImage. When creating an uImage it is binary different than the zImage. (Expected behavior, as uImage can be a zImage with additional header.) I will do more tests (e.g. booting) when I find some spare time and the serial cable has arrived...

I ordered this one: Amazon PL2303HX USB to TTL Probably shipped from China, so further details from my side will be earliest next month...

Any recommendation for buying a serial cable to get that console boot log?

I did not change system settings, except minor modifications to script.bin (VGA mode and LEDs). NAND1 was mounted as /boot (and NAND2 as /). Probably it was bad luck or a weak power supply (I doubt that, as I also have the battery connected). But as I migrated to SD card anyway, I will stay there for the near future. Maybe I will find some time during the next days to compare the kernel files from NAND1 and SD card. But as this is my "production" system, I would like to avoid additional down time.

"Good" to hear other have the same problem... after the workaround went fine on my CubieBoard2 I bricked my production system CubieTruck the same way, you described. The workaround trick went fine on the CubieTruck. But after reboot the system does not start anymore: red power LED near power jack is lit network LEDs show some activity SATA disk stays off front LEDs stay off VGA has no signal no other reaction observable I had similar NAND boot problems in the past, so I assumed it is the same case again. The last time it was sufficient to leave the board unpowered for some hours (discharging battery a bit), but this time nothing helped. So I migrated my complete system back to SDCARD, and it is working like before. After thinking a night about the problem, it might be sufficient to manually update all kernel files on NAND1. I did not test that. Do you have a serial cable to watch the boot output? (I don't have one.)

When doing apt-upgrade to get the latest linux-jessie-root-cubieboard2, it fails with this error message: # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: linux-jessie-root-cubieboard2 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 3 not fully installed or removed. Need to get 0 B/1.810 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Y (Reading database ... 51863 files and directories currently installed.) Preparing to unpack .../linux-jessie-root-cubieboard2_5.00_armhf.deb ... Unpacking linux-jessie-root-cubieboard2 (5.00) over (4.81) ... dpkg: error processing archive /var/cache/apt/archives/linux-jessie-root-cubieboard2_5.00_armhf.deb (--unpack): unable to make backup link of `./boot/bin/cubieboard.bin' before installing new version: Operation not permitted dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for systemd (215-17+deb8u3) ... Errors were encountered while processing: /var/cache/apt/archives/linux-jessie-root-cubieboard2_5.00_armhf.deb E: Sub-process /usr/bin/dpkg returned an error code (1) When /boot is on NAND it is not possible to link files there, maybe that is the problem?

I can prove, that your intended setup is working on my CubieTruck and also on the CubieBoard2: I'm booting Armbian from NAND and a SDCARD, a HDD and USB drives can be mounted as expected.

It worked also with that option for several month now... You just get an error message in the logs and when you query the systemd status. I wrote down a note some month ago to investigate this further, but forgot about it, as everything seems to work correctly. After thinking about the source for this entry in /etc/fstab I have the strong feeling that it is a default setting from Armbian. At least in the version I installed first (which was most likely 4.5). I found the same value on my Cubieboard2 test system which is is a stock Armbian just as reference. Maybe it takes only effect when installing to NAND (which I do)?

Thanks, that fixed it. I have no idea how this option came there...