piknew

  • Content Count

    106
  • Joined

  • Last visited

Everything posted by piknew

  1. Question: can this kind of issue to be handled? Unfortunatelly I am not able to get clear information how it is possible to report such an issue (it is not really a bug, it is somehow enhancement for particular use case, in this situation chroot'ed env): https://github.com/armbian/build/issues/2533 I went also through https://www.armbian.com/bugs/ and it seems that there is no place to report enhancement (which I understand shall be evaluated properly).
  2. It is upstream (Debian's), you may add buster-backports (read what are pros and cons: https://wiki.debian.org/Backports). As you can see there are two versions: [root@PKOTHER ~]# apt show openssh-server -a Package: openssh-server Version: 1:8.4p1-2~bpo10+1 Priority: optional Section: net Source: openssh Maintainer: Debian OpenSSH Maintainers <debian-ssh@lists.debian.org> Installed-Size: 1,299 kB Provides: ssh-server Depends: adduser (>= 3.9), dpkg (>= 1.9.0), libpam-modules (>= 0.72-9), libpam-runtime (>= 0.76-14), lsb-base (>= 4.1+Debian3), openssh-client (= 1:
  3. It works! Thank you. Attached are: decompiled source (command: dtc -I dtb -O dts sun8i-h3-orangepi-plus.dtb >sun8i-h3-orangepi-plus.dts ) with modified line 540 to be phy-mode = "rgmii-id"; (as given in patch): sun8i-h3-orangepi-plus.dts compiled dtb (command: dtc -O dtb -o sun8i-h3-orangepi-plus.dtb sun8i-h3-orangepi-plus.dts ), to be placed in /boot/dtb-5.10.4-sunxi (then I have executed command: update-initramfs -u just in case): sun8i-h3-orangepi-plus.dtb
  4. Is it possible to just recompile fixed dts into dtb and replace it in /boot/dtb (then recheck, maybe with update-initramfs)? If yes - is there a tool at Armbian to do it? Edit: I will try with this: https://stackoverflow.com/questions/21670967/how-to-compile-dts-linux-device-tree-source-files-to-dtb
  5. Thank you for confirmation. It seems that this board is affected. Thanks, however, I will use "chroot" method when fixed kernel / packages will be available. For now I have just restored system from my backup image with previous kernel. I am able to help with any other diagnostics. First step I would suggest to check if code for driver has been changed: 8189es - which I guess is used only by OPI+2. "OPI+2e" version which I also own is using 8189fs - and there is no problem there.
  6. Done, U-Boot is updated: U-Boot SPL 2020.10-armbian (Dec 12 2020 - 00:52:34 +0100) DRAM: 2048 MiB Trying to boot from MMC2 U-Boot 2020.10-armbian (Dec 12 2020 - 00:52:34 +0100) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus / Plus 2 DRAM: 2 GiB MMC: mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 1:1... In: serial@1c28000 Out: serial@1c28000 Err: serial@1c28000 Net: phy interface7 eth0: ethernet@1c30000 starting USB... Bus usb@1c1b000: USB EHCI 1.00 Bus usb@1c1d000: USB EHCI 1.00 sca
  7. For files to compare - emmc (network is not working) == upgraded version, sd (no issues) == version before upgrade: dmesg_sd.txt boot_sd.txt boot_emmc.txt dmesg_emmc.txt
  8. This is full log from Serial connection: U-Boot SPL 2018.05-armbian (Sep 19 2018 - 13:00:01 +0200) DRAM: 2048 MiB Trying to boot from MMC2 U-Boot 2018.05-armbian (Sep 19 2018 - 13:00:01 +0200) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus / Plus 2 DRAM: 2 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... MMC: no card present ** Bad device mmc 0 ** Failed (-5) In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 MMC: no card present ** Bad device mmc 0 ** MMC: no card present ** Ba
  9. Orange Pi + 2 - still issue with network. I do not know if this is important, but other board has upgraded 6 packages (which 1 is Debian's), for example Opi Zero: [root@PKCHECKER /var/log]# cat dpkg.log | grep upgrade 2021-01-04 20:24:19 upgrade libp11-kit0:armhf 0.23.15-2 0.23.15-2+deb10u1 2021-01-04 20:24:22 upgrade armbian-config:all 20.11.4 20.11.6 2021-01-04 20:24:24 upgrade linux-buster-root-current-orangepizero:armhf 20.11.3 20.11.6 2021-01-04 20:24:30 upgrade linux-dtb-current-sunxi:armhf 20.11.3 20.11.6 2021-01-04 20:24:45 upgrade linux-image-current-sunxi:armhf
  10. I have reflashed SD card for OPI Zero with previous kernel (5.9.14-sunxi) - it works. So, next step will be apt update && apt upgrade to see if problem occurs again. This is currently working version: http://ix.io/2KRL Edit: it works. So, problem with Opi Zero was related to some "unknown unknown" :). Also now I am flashing other SD card with previous kernel (5.9.14-sunxi) for OPI+2 and I will check the same as above. BTW. When I am referring "previous kernel" - I mean my own images of configured system (which is kept with every upgrade since legacy 3.
  11. Remark: on my Orange Pi PC and Orange Pi Plus 2e - everything is OK. Problem occurred on Orange Pi Plus 2 and Orange Pi Zero After upgrading to: [root@PKTEST ~]# uname -a Linux PKTEST 5.10.4-sunxi #20.11.6 SMP Sun Jan 3 21:28:45 CET 2021 armv7l GNU/Linux My "headless" Orange Pi Plus 2 "disappeared from network. I switch it off and connected via serial. I was able to login. Device runs successfully, it is assigning IP to network interface (static assignment) but... there is no connectivity at all (both egress and ingress). [root@PKTEST ~]# ifconfig e
  12. Please post dmesg output after changes are committed to emmc (with "w"). I had exactly the same issue - dmesg was reporting a lot of serious write errors. I already assumed that emmc is not usable anymore, however, after couple of weeks... I tried again and everything was OK. I am not sure if this was really hardware issue or software. So, please check dmesg output...
  13. piknew

    piknew

  14. I need to revert statement as above. My OPi+2E has "frozen". So, entry MIN_SPEED=408000 is not valid for my SBCs. Until it is corrected I have added following to /etc/cron.d/cpufrequtils-fix */5 * * * * root /bin/grep 'MIN_SPEED=408000' /etc/default/cpufrequtils 1>/dev/null 2>&1 && /bin/sed --in-place s/MIN_SPEED=408000/MIN_SPEED=480000/ /etc/default/cpufrequtils 1>/dev/null 2>&1 && /bin/systemctl restart cpufrequtils 1>/dev/null 2>&1 Edit. My mistake. It was that I have put my SBC on quite warm router. And during scheduled job
  15. It seems that with kernel 4.19.13-sunxi the typo is no longer causing issues (at least on OPi+2, which I've selected to perform test): ___ ____ _ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) _ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | |_| |_ | |_| | | | (_| | | | | (_| | __/ | __/| |_ _| \___/|_| \__,_|_| |_|\__, |\___| |_| |_| |_| |___/ Welcome to ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.13-sunxi System load: 2.25 1.43 0.62 Up time: 10 days Memory usage: 4 % of 2014MB IP: 192.16
  16. I will change it on one of my platforms to verify. It will be Orange Pi+ 2 - just a moment ago I have changed it back to original package version (with "408") and rebooted: ___ ____ _ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) _ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | |_| |_ | |_| | | | (_| | | | | (_| | __/ | __/| |_ _| \___/|_| \__,_|_| |_|\__, |\___| |_| |_| |_| |___/ Welcome to ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.13-sunxi System load: 1.43 0.34 0.11 Up time: 0 min Memory usage: 3
  17. @Igor, with latest upgrade the "typo" (408 vs 480) is still in cpufrequtils. Is there a chance (I mean: time to do it) to have it corrected in the source? THe related thread:
  18. Still OK (I can confirm this for all of my "orange" SBCs): [root@PKBACKUP ~]# date Mon Oct 29 20:21:27 CET 2018 [root@PKBACKUP ~]# uptime 20:21:32 up 8 days, 2:32, 1 user, load average: 0.10, 0.03, 0.01 [root@PKBACKUP ~]# ll /etc/default/cpufrequtils -r--r--r-- 1 root root 175 Oct 18 18:01 /etc/default/cpufrequtils [root@PKBACKUP ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=1296000 GOVERNOR=ondemand #GOVERNOR=performance [root@PKBACKUP ~]#
  19. After correcting cpufrequtils file - no issues so far: [root@PKBACKUP ~]# date Fri Oct 26 11:03:47 CEST 2018 [root@PKBACKUP ~]# uptime 11:03:53 up 4 days, 16:14, 1 user, load average: 0.00, 0.00, 0.00 [root@PKBACKUP ~]# ll /etc/default/cpufrequtils -r--r--r-- 1 root root 175 Oct 18 18:01 /etc/default/cpufrequtils [root@PKBACKUP ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=1296000 GOVERNOR=ondemand #GOVERNOR=performance [root@PKBACKUP ~]# Anybody else (who's SBC
  20. I referred to your post in: I guess the other thread is better to analyze this finding.
  21. For now I have modified cpufrequtils as following for my three boards (orangepipc, orangepiplus 2 GB, orangepiplus2e): [root@PKBACKUP ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=480000 MAX_SPEED=1296000 GOVERNOR=ondemand #GOVERNOR=performance For orangepizero as following: [root@PKOTHER ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=240000 MAX_SPEED=1200000 GOVERNOR=ondemand #GOVER
  22. Could you please take a look here: Considering that when running on performance mode - system seems to be stable but once switched to "ondemand" - unstable. May the "mismatch" be the root cause here?
  23. Could you please point out how to achieve this? All my H3 (also H2+) devices suffer from the issue as described. Even with newest kernel. So, after reading I decided to test stability with "constant cpu frequency". EDIT: I've done it by: [root@PKTEST ~]# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1296000 #GOVERNOR=ondemand GOVERNOR=performance [root@PKTEST ~]# Question: would it be possible not to overwrite cpufrequtils file once su
  24. SUCCESS Story: I have used armbian-config to check Hardware (if my I2C bus is enabled). I have noticed very strange behavior of function: grep was outputted in "usage" mode. I revieved all the scripts and it appeared that line which is searching for "overlays=" is throwing this error. My /boot/armbianEnv.txt didn't have any overlay, especially for I2C, enabled. So, I have added as following (+ overlay prefix): [root@PKTEST ~]# cat /boot/armbianEnv.txt rootdev=UUID=f8301761-6756-4f97-aa80-12c05ea037cf extraargs=pty.legacy_count=2 overlays=i2c0 i2c1 i2c2 user_overlays=ds1
  25. Definitely not (PKTEST is Orange Pi PC) - I also checked on OPI+2 with the same results (FAILED on "dev"). But I will try to downgrade to "next" on OPiPC (PKTEST). I will give an update in matter of minutes. Update: "next" is the same. But then I have downgraded to "Default" and: [root@PKTEST ~]# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- --