5kft

Members
  • Content Count

    249
  • Joined

  • Last visited

About 5kft

  • Rank
    Elite member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. If you're feeling adventurous and like living life on the edge, I have provided a buildable 5.10 tree here for sunxi: git clone -b v5.10-dev-test https://github.com/5kft/build Build as normal using "./compile.sh" using "BRANCH=dev" from this git branch and it'll build 5.10.0-rc1 targets. Both sunxi and sunxi64 builds are enabled. Note that I only tested on a few H3 and H5 boards (both Nano Pi and Orange Pi), but it seems to work pretty well. But no guarantees, support, etc. - this is just a side project atm
  2. Understood. A lot has changed since 4.19...it could be any number of things. I checked the passive polling rate and 5.x actually polls more often than 4.x, so that's interesting... A couple of questions: In terms of your older 4.19 kernel, what was the maximum clock rate of the CPU? If you don't overclock to 1.3GHz with 5.x, does it work okay (i.e., doesn't overheat)?
  3. It is if we want to switch -current to 5.9 (i.e., deprecate 5.8)
  4. With just a few local test hacks, I was able to bring up kernel 5.10-rc1 on sunxi this morning (based on the new megous branch): root@air's password: _ _ ____ _ _ _ | \ | | _ \(_) / \ (_)_ __ | \| | |_) | | / _ \ | | '__| | |\ | __/| | / ___ \| | | |_| \_|_| |_| /_/ \_\_|_| Welcome to Armbian 20.08.14 Buster with Linux 5.10.0-rc1-sunxi System load: 2% Up time: 11 min Memory usage: 14% of 491M IP: 172.24.18.151 CPU temp: 34°C Usage of /: 24% of 7.2G Last login: Tue Oct 27 07:20:02 2020 from 172.2
  5. Thanks @linuxjosef, these videos are very helpful! From what I can see, it is working just fine in the default configuration, and overheating in this instance when overclocking to the maximum speed possible. Clearly you have insufficient cooling present on this board, especially when overclocking (e.g., too small a heatsink, no fan). I've had the same problem on my Orange Pi Zero Plus2 H5s, because the heatsink is so small - unfortunately the board isn't designed well for supporting a large heatsink. However, on my Nano Pis for example I can overclock to the maximum 1.3GHz without an issue
  6. Yes, I agree - especially if this patch from @Icenowy makes it into the mainline: https://groups.google.com/g/linux-sunxi/c/QzBM7nciPLo. We should wait for the dust to settle then can remove our revert patch and adapt the other DTs appropriately. Thanks!
  7. @Igor I'd like to get your thoughts regarding this...: The Realtek kernel change that caused this issue is indeed correct and good (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=bbc4d71d63549bcd003a430de18a72a742d8c91e), as it fixes the earlier invalid implementation in the kernel. The failure problems with the RTL8812E occur with this change because "phy-mode" in the DT now matters and must be correct, whereas previously it did not. By changing the "phy-mode" to "rgmii-id" correctly for sunxi boards that have the TXDLY and RXDLY pull-ups on the PHY, the RTL88
  8. If the kernel is trapping/crashing for some reason then this would likely be shown on the console, which could help provide a clue as to what might be going on...
  9. For what it's worth, I'm not seeing any issues on a 256MB OrangePi R1 running 5.8.14-current (I only have a 512MB Pi Zero). It works without issue - e.g., root@orangepi-r1:~# uname -a Linux orangepi-r1 5.8.14-sunxi #trunk SMP Sun Oct 11 14:48:02 UTC 2020 armv7l GNU/Linux root@orangepi-r1:~# cpufreq-info -c 1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by soft
  10. Yes, do a pull and try again - I just removed the offending patch as it was merged upstream in -rc6 (See https://github.com/armbian/build/commit/9637d3d0f94203a8ea18495d61090dbe202aeeaf)
  11. Just fixed this in master; they rolled this patch into upstream with -rc6. Thanks for noting this!
  12. Exactly - this is because these additional Wi-Fi drivers are conditionally added outside of each local target patchset. If the drivers aren't included (e.g., via "EXTRAWIFI=no", then the patches will fail because there are no files to patch. As @Werner notes, this is really just a cosmetic issue.
  13. I'm not sure if this will help at all, but figured I'd mention it just in case: These traps look somewhat similar to some that I fixed for the RTL8812AU driver (see https://github.com/aircrack-ng/rtl8812au/pull/704). I don't have an RTL8188EU, but the changes are simple enough to try if you have some spare time - see https://github.com/aircrack-ng/rtl8812au/pull/704/commits/94340760e7d6144a2099eccbebb21dc53fe9fdeb. Obviously you'll have to find the related lines in the 8188 sources to make the changes, but this should be pretty easy to try.
  14. @guidol - no, while this may seem weird it's perfectly normal - this is a "bind mount", and this is how bind mounts appear in "mount". You can create one of these yourself, for example: root@nanopi:~# mkdir foo bar root@nanopi:~# mount --bind foo bar root@nanopi:~# mount | grep bar /dev/mmcblk1p2 on /root/bar type f2fs (rw,relatime,lazytime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix,compress_algorithm=lz4,compress_log_size=2) root@nanopi:~# (The "log.hdd"
  15. It'd be worthwhile to search the forums regarding this subject, e.g., https://forum.armbian.com/topic/6398-orange-pi-zero-cpu-and-load-issues-with-538/?do=findComment&comment=58057. If you want to change this in the system, you'll have to update the appropriate DT and add the desired clock entries.