Jump to content

5kft

Members
  • Posts

    264
  • Joined

  • Last visited

Reputation Activity

  1. Like
    5kft got a reaction from Werner in Orange Pi 3 (H6) ethernet not working on 5.9 and above   
    This problem sounds like this issue:  https://github.com/armbian/build/issues/2315
  2. Like
    5kft got a reaction from TRS-80 in Switching SUNXI-DEV to 5.10.y (h3-h5-h6/megous)   
    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.24.18.20 root@air:~# cat /proc/version Linux version 5.10.0-rc1-sunxi (root@355045fc2473) (arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #trunk SMP Tue Oct 27 14:13:23 UTC 2020 root@air:~# root@air:~# cpufreq-info -c 0 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.20 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.10 GHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 816 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:97.72%, 648 MHz:0.22%, 816 MHz:0.20%, 960 MHz:0.23%, 1.01 GHz:0.15%, 1.10 GHz:0.19%, 1.20 GHz:1.29% (679) root@air:~#  
    I tested this on a spare NanoPi NEO Air board I had; I haven't tried an arm64 build yet.  dmesg is clean; cpufreq works,  overclocking works, wireless works, etc.  Our 5.9 kernel patchset applied almost completely without error (there are a few other changes needed such as the builddeb patches and fbcon reversion patch we did).
     
    In any case I just wanted to let people know.  Given that 5.10 is confirmed to be the new LTS and 5.9 is the new primary -stable,  I'm wondering if 5.8's days are numbered (like what happened to 5.7).  I'm happy to put some work into bringing 5.10 into build if there is interest.
     
  3. Like
    5kft reacted to Ford_Prefect in Orange Pi R1 IPSec freezing Problem with large amounts of traffic / e.g. iperf3   
    Hi,
    Thanks for your work,
    I tested your kernel packages yesterday and everything works flawlessly now. I get about 40 to 50 MBps throughput with Ipsec now without stalling and "breaking" the Interface.
     
    I am happy, thanks alot!
     
    Cheers
     
    Ford Prefect
     
  4. Like
    5kft got a reaction from guidol in Orange Pi R1 IPSec freezing Problem with large amounts of traffic / e.g. iperf3   
    I'm not an expert in this area whatsoever, but this problem looks like an upstream kernel issue, and perhaps is related to this fallback deadlock fix?  https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=a2715fbdc6fc387e85211df917a4778761ec693d
     
    The posted fix patch is only applicable to kernel v5.10; just in case you want to give it a try, I've uploaded a ToT test build of v5.10-rc3 with this kernel patch applied:  https://drive.google.com/file/d/1Eg_cn3bEYsRFZ3vrP9Mc0fxJjPREczcW/view.  Again, I'm not sure if this will fix the problem, but there are a number of changes in cryptodev here compared to kernel v5.9, so it might be worth a try.
  5. Like
    5kft got a reaction from NicoD in H3 running a lot warmer with 5.8.5 vs 4.19   
    A lot has changed in the thermal drivers since 4.19, it's possible that the "better temperatures" you are seeing in the older kernel are actually incorrect.  E.g., see https://github.com/megous/linux/commits/orange-pi-5.3/drivers/thermal/sun8i_thermal.c (in particular https://github.com/megous/linux/commit/eac37f0ec6f33e8f3edb8dbdb9d11b4cb8e218e5#diff-e5ac7e093b36d92344ed52a2747602d5e46d366ca34b4abb46cc005f92ee679f).  There are numerous posts in the forums about this and there have been a number of changes in the upstream drivers in this area over the past couple of years...
     
    New (post-4.19) thermal driver history here:  https://lore.kernel.org/linux-arm-kernel/20191226202607.GA9524@Red/T/#mfffc26980cb13605429156c3833464fe3cbdb661 
     
  6. Like
    5kft got a reaction from guidol in [Info] Samba server problem Kernel 5.10.0-rc2 with ubuntu focal on NanoPi Neo2 (1GB Ram-version)   
    I actually tried both - Debian works fine (as you noted), but Focal crashes just like I was seeing yesterday:
     
     
     
  7. Like
    5kft got a reaction from Werner in Switching SUNXI-DEV to 5.10.y (h3-h5-h6/megous)   
    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 
  8. Like
    5kft got a reaction from Frank F. in No network with 5.9.0-sunxi on Banana Pi M2 Berry   
    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!
  9. Like
    5kft got a reaction from guidol in Switching SUNXI-DEV to 5.10.y (h3-h5-h6/megous)   
    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.24.18.20 root@air:~# cat /proc/version Linux version 5.10.0-rc1-sunxi (root@355045fc2473) (arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #trunk SMP Tue Oct 27 14:13:23 UTC 2020 root@air:~# root@air:~# cpufreq-info -c 0 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.20 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.10 GHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 816 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:97.72%, 648 MHz:0.22%, 816 MHz:0.20%, 960 MHz:0.23%, 1.01 GHz:0.15%, 1.10 GHz:0.19%, 1.20 GHz:1.29% (679) root@air:~#  
    I tested this on a spare NanoPi NEO Air board I had; I haven't tried an arm64 build yet.  dmesg is clean; cpufreq works,  overclocking works, wireless works, etc.  Our 5.9 kernel patchset applied almost completely without error (there are a few other changes needed such as the builddeb patches and fbcon reversion patch we did).
     
    In any case I just wanted to let people know.  Given that 5.10 is confirmed to be the new LTS and 5.9 is the new primary -stable,  I'm wondering if 5.8's days are numbered (like what happened to 5.7).  I'm happy to put some work into bringing 5.10 into build if there is interest.
     
  10. Like
    5kft reacted to guidol in [Experiment] armbian on NanoPi A64   
    @5kft @Hannes Worst @@lex
    somebody did hear us  the analog sound is back in dev kernel/dtb 5.9.1
    and now - I think - we have found the missing link:
    sound was playing but we didnt hear anything on analog-audio because - as I remember right -  the option
    AIF1 Slot 0 Digital DAC
    was missing. So it couldnt be enabled  
     
    Now the option is back and the DAC could now enabled again - so no more silence anymore  
     
    BUT be advised to set AIF DA0 not higher than 17, because then the sound will very fast be distorted/overdriven  
     
    So here is my kernel-information als alsamixer-setting for analog-audio (sun50i-a64-audio):
    _ _ ____ _ _ __ _ _ | \ | | _ \(_) / \ / /_ | || | | \| | |_) | | / _ \| '_ \| || |_ | |\ | __/| | / ___ \ (_) |__ _| |_| \_|_| |_| /_/ \_\___/ |_| Welcome to Debian GNU/Linux 10 (buster) with Linux 5.9.1-sunxi64 No end-user support: built from trunk package bsp-kernel[20.11.0-trunk] u-boot[20.11.0-trunk] dtb [20.11.0-trunk] firmware [20.11.0-trunk] config[20.11.0-trunk] branch[dev] root@npi-a64-116(192.168.6.116):~# uname -a Linux npi-a64-116 5.9.1-sunxi64 #trunk SMP Mon Oct 26 18:14:55 +03 2020 aarch64 GNU/Linux root@npi-a64-116(192.168.6.116):~# more /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" root@npi-a64-116(192.168.6.116):~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: sun50ia64audio [sun50i-a64-audio], device 0: 1c22c00.dai-sun8i-codec-aif1 sun8i-codec-aif1-0 [1c22c00.dai-sun8i-codec-aif1 sun8i-codec-aif1-0] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: sun50ia64hdmi [sun50i-a64-hdmi], device 0: 1c22800.i2s-i2s-hifi i2s-hifi-0 [1c22800.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 root@npi-a64-116(192.168.6.116):~# alsamixer Card: sun50i-a64-audio Value: Item: 83 Headphone [dB gain: -8.00] Mixer Headphone Source [Mixer] 15 AIF1 DA0 [dB gain: -24.00, -24.00] Stereo AIF1 DA0 Stereo [Stereo] Enable AIF1 Slot 0 Digital DAC 82 DAC [dB gain: 18.75, 18.75] Enable DAC Reversed  
  11. Like
    5kft got a reaction from Igor in No network with 5.9.0-sunxi on Banana Pi M2 Berry   
    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!
  12. Like
    5kft got a reaction from guidol in No network with 5.9.0-sunxi on Banana Pi M2 Berry   
    @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 RTL8812E is properly configured and works.  However this means that all of the relevant DTs need to be updated to correctly reflect their actual hardware configuration.
     
    I started making these changes in the patches in sunxi-dev, confirming the existence of the delay configuration pull-ups with the board schematics to determine the proper phy-mode to set, and removing my reversion patch.  However any boards that are missed will have Ethernet failures until the DTs are properly patched.  Should we just leave the reversion patch in instead (long-term)?
  13. Like
    5kft got a reaction from Werner in Orange Pi zero - freezing randomly   
    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...
  14. Like
    5kft got a reaction from Werner in Realtek NIC driver dumps on Nano Pi Neo   
    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.
     
  15. Like
    5kft got a reaction from guidol in Switching SUNXI-DEV to 5.8.y (h3-h5-h6/megous)   
    I went ahead and cleaned up the remaining problems for 5.8.  I don't have an H6 board so I can't test the changes there, but I believe they should work fine (I did a rework of my previous thermal changes for H6 and re-applied on the new 5.8 base).
  16. Like
    5kft got a reaction from guidol in Switching SUNXI-DEV to 5.9.y (h3-h5-h6/megous)   
    @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" bind mount is created via "/usr/lib/armbian/armbian-ramlog".)  Hope this helps!
  17. Like
    5kft reacted to guidol in Switching SUNXI-DEV to 5.9.y (h3-h5-h6/megous)   
    @5kft Yes - does work now correctly. I compiled the kernel/dtb 5.9.0.rc4 after your commit and installed all files. Then I activated the 1.0Ghz/1.1v dtbo and rebooted. All dtbo-files are now loaded correctly:
     
     
    And all CPU-frequencies are available up to the 1008Mhz (1.01Ghz)  
  18. Like
    5kft got a reaction from guidol in Switching SUNXI-DEV to 5.9.y (h3-h5-h6/megous)   
    This fixes operation for these overlays under v5.9 so that they work correctly (just like under v5.8) 
  19. Like
    5kft got a reaction from guidol in Switching SUNXI-DEV to 5.9.y (h3-h5-h6/megous)   
    @guidol - thank you, the logs you provided were exactly what I needed!  I have fixed the issue with the overclock overlays for -dev, and have push the changes to master (https://github.com/armbian/build/commit/9a096fc557367668e01736400d2c5cb4c8c28a75).  Please give these changes a try and let me know how it goes!
  20. Like
    5kft got a reaction from Werner in CPU Frequeny Scaling NanopiNEO   
    Actually from the schematic (http://wiki.friendlyarm.com/wiki/images/f/fd/Schematic_NanoPi-NEO-V1.4-1801-20180320.pdf), the NEO H3 has an MP2143DJ GPIO regulator, which supports switching betwen 1.1v/1.3v - the board DT is just missing the regulator entry.  This is why the default maximum CPU clock is too high; adding this regulator will correctly address this problem by default and will also allow the board to be overclocked (potentially to 1.3GHz) using the overclocking overlays.  I'll look at adding support for this in the DT.
  21. Like
    5kft got a reaction from Werner in Switching SUNXI-DEV to 5.9.y (h3-h5-h6/megous)   
    Yes, one part of this patch is included in the v5.9 mainline upstream, so that particular part is rejected as it is already present.  This patch is a general patch for all builds (it is present in patch/misc), so it's a little more work to address - e.g., it's a matter of splitting the patch and doing a kernel version check during the build.  I simply haven't gotten around to addressing this yet in the build process (there's no impact because of this).
  22. Like
    5kft reacted to martinayotte in Switching SUNXI-DEV to 5.9.y (h3-h5-h6/megous)   
    My Allwinner garden tour using 5.9.y is almost finished ! Only 2 board models left ...
  23. Like
    5kft got a reaction from Werner in Switching SUNXI-DEV to 5.9.y (h3-h5-h6/megous)   
    Agreed - I did this locally as well and it worked fine.
  24. Like
    5kft got a reaction from Werner in Switching SUNXI-DEV to 5.8.y (h3-h5-h6/megous)   
    I went ahead and cleaned up the remaining problems for 5.8.  I don't have an H6 board so I can't test the changes there, but I believe they should work fine (I did a rework of my previous thermal changes for H6 and re-applied on the new 5.8 base).
  25. Like
    5kft got a reaction from Werner in Switching SUNXI-DEV to 5.9.y (h3-h5-h6/megous)   
    I checked in a number of changes today into master that make it very straightforward to build sunxi w/kernel v5.9-rc2.  I have created a v5.9 development branch for sunxi in my repo that contains the current changes necessary for v5.9:  https://github.com/5kft/build/tree/v5.9-sunxi-development.  With the base mainline changes in master now only a few changes are needed to support v5.9.
     
    With these changes, both sunxi and sunxi64 work in an initial state with v5.9-rc2.  There are still some things that need some cleanup (e.g., there's a sound driver issue and a few other existing patches that need to be cleaned up/merged), but overall it seems to be at a very good initial working point now.  From cursory testing of this on some NEO variants with several different Realtek-based USB Wi-Fi adapters all seems to work quite well.
     
    I originally encountered some serious problems with the AP6212 Wi-Fi adapter (tested on a NEO Air and NEO Plus2) where Wi-Fi communication would randomly hang or stop.  I narrowed this down to the brcmfmac changes in this change in the kernel:  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47ec5303d73ea344e84f46660fff693c57641386.  I haven't debugged exactly what the issue is - I'm guessing it's something to do with the SDIO reset changes that were added, or perhaps there is an incompatibility with these changes and the current AP6212 firmware we're using.  However by reverting these specific changes to the brcmfmac driver back to the kernel v5.8.y version, the AP6212 Wi-Fi part works perfectly fine again, so I added a patch to revert the v5.9 changes to this driver.
     
    @Igor, @martinayotte - any thoughts as to when we might want to move sunxi-dev to v5.9?  It's going to be in -rcX state for another month or so, so I'm not sure it makes sense to move from v5.8.y right away, but then again there's an appeal to being on the latest.  Interested to hear your thoughts!
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines