piknew

  • Content Count

    106
  • Joined

  • Last visited

About piknew

  • Rank
    Elite member

Recent Profile Visitors

3278 profile views
  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