znoxx

Members
  • Content Count

    95
  • Joined

  • Last visited

Reputation Activity

  1. Like
    znoxx reacted to Igor in Orange Pi One Plus - Constantly hangs   
    Will be fixed once before 2/2020 https://armbian.atlassian.net/projects/AR/issues/AR-86
  2. Like
    znoxx reacted to bschwehn in Armbian for OrangePi PC2, AllWinner H5   
    FWIW, these messages seem to go away when building the dev branch without patch /patch/kernel/sunxi-dev/ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch
     
    Not sure if this patch is compatible with the changes already done in the megous branch (like this patch)
     
    Still, throttling is done only down to 1104 MHz (not an issue for me personally, for me this throttle is enough for mine to not go above 81C @100% CPU usage for 10 minutes).
     
    Edit: Looks like I have it working now. I have basically added the patch ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch directly to linux-mainline/orange-pi-5.0/arch/arm/boot/dts/sunxi-h3-h5.dtsi (instead of
    /arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi)

     
     
     
    Not sure why that should make a difference, but throttling now seems to take the trips I have configured (though it seems to use a different cooling map:
     
    ramp up:
     
     
    after insulating the board to get the temperature up:
     
     
    removing insulation lets temp drop again, and freq rise:
     
     
  3. Like
    znoxx got a reaction from MX_Master in missing recordmcount - looks like solved   
    Playing with freshly installed/updated armbian, tried to compile "patched" realtek drivers for those weird realtek 81xx things.
    Bumped error: ./scripts/recordsmcount not found
     
    Go to /usr/src/linux-headers-whatever-version-4.x/scripts
    then, sudo make  recordmcount
     
    After this even DKMS version installed/build without any issues.
    Not sure I will survive next kernel update without manual intervention with this "make", but anyway, it worked for me.
  4. Like
    znoxx reacted to svts in Armbian for OrangePi PC2, AllWinner H5   
    So the problem was solved!
    sed -i -e '1imw.l 0x01C20020 0x80101810\' /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr The reason of crashes was DRAM PLL value which seems too high for the boards I have.
    Default DRAM_PLL value set by u-boot 2017.05+ is 624MHz. It seems not all board support this value.
    I changed it to 600MHz by setting 0x01c20020 register to 0x1810 value (instead of 0x1910 set by u-boot) and there's no any crash anymore.
     
    The script adds "mw.l 0x01C20020 0x80101810" line to boot.cmd and then compiles boot.scr.
    After that u-boot will change DRAM_PLL value to a bit lower one to avoid crashes.
     
    Thanks everybody who helped me to find a solution.
    Special thanks to @znoxx for testing and logging :)
     
  5. Like
    znoxx got a reaction from Jelev in Armbian for OrangePi PC2, AllWinner H5   
    Looks like stability issue. Start with PSU and microSD replacing.
  6. Like
    znoxx got a reaction from mousavy_mh in Armbian for OrangePi PC2, AllWinner H5   
    Actually I run snapsot from 17 nov and it is working. I even see difference with different thermal compound in different boards.
  7. Like
    znoxx got a reaction from mousavy_mh in Realtek hostapd troubles   
    I had same issue on almost same hardware. And I have already seen it on previous H5 build. Gave up and used Ralink2800 as a hostapd device. But really appreciate if there will be a tip/solution since rtlXXXC devices support concurrent mode - I can use one adapter for both AP and client.
  8. Like
    znoxx reacted to zador.blood.stained in Running Armbian on unsupported A20 device   
    Yes. Also a "community supported" configuration can be added to the build system to automate image building.
  9. Like
    znoxx reacted to zador.blood.stained in TOR fails to run on stable OrangePi Zero build   
    This means that "NoNewPrivileges" option is not correctly applied to the TOR service. What file did you add it to? Did you reload the systemd configuration?
     
    Edit:
    You need to add something like
    [Service] NoNewPrivileges=no to a new file - /etc/systemd/system/tor@.service.d/10-no-new-privileges.conf
    this should apply this setting to all TOR instances. "sudo systemctl daemon-reload" is required to reload the configuration after changing.
     
    Upstream Debian Jessie relies on kernel 3.16, Ubuntu Xenial - on kernel 4.4. "NoNewPrivileges" option tries to use kernel features that are not present in kernel 3.4, so it has to be disabled first.
  10. Like
    znoxx got a reaction from Igor in Cubieboard 2 (A20) LXC issue after 5.31/4.11.5 upgrade   
    Just for info - issue is also resolved in 5.32
     
  11. Like
    znoxx reacted to Igor in Cubieboard 2 (A20) LXC issue after 5.31/4.11.5 upgrade   
    I guess roll back to previous version (4.9.7) should do the job.
     
    apt install linux-image-next-sunxi=5.25 linux-dtb-next-sunxi=5.25 Than go to armbian-config and freeze kernel upgrades until this is not solved ...
  12. Like
    znoxx reacted to zador.blood.stained in Running Armbian on unsupported A20 device   
    Android->Linux switching may requre writing a Linux image with PhoenixSuit/LiveSuite first
     
    Yes.
     
    The only differences are u-boot compile-time configuration and script.bin, so it doesn't matter much
     
    script.bin editing should be enough, but the only way to say for sure would be checking the kernel code or actually trying to fiddle with script.bin
    https://linux-sunxi.org/Fex_Guide
    and in general just bin2fex, edit, fex2bin it back.
     
    Please note that you may want to remove Armbian repository from /etc/apt/sources.list.d or pin some packages to prevent upgrades from overwriting your changes. And in general upgrading kernel on NAND is not recommended as it is prone to breaking the system.
  13. Like
    znoxx reacted to renaudrenaud in Orange TORBox on Opi Zero   
    Thanks, I will have a look when back at home.
     
    I read in your documentation that realtek dongle are supported, but not for the OPz. Because the poor onboard wifi adapter in the case of Opz, it could be cool to have a realtek wifi dongle support, don't you think so ?
     
    Oh I see you also propose images! Nice job! 
  14. Like
    znoxx reacted to edupv in Armbian for OrangePi PC2, AllWinner H5   
    Are you using the default schedutil governor ?
     
    I am using my PC2 started from 170215 build, the behavior of schedutil governor was strange. It ramp up to 1296MHz when idle, but it went down to 480MHz under light load (e.g. apt-get update).  Sometimes, after some loading, it became more normal - More 480MHz and less 1296MHz.
     
    Then, I changed the governor to ondemand. ondemand is "lazy" by default, and needs tuning to make it responsive :
    echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold echo 50880 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate I am happy with the ondemand governor and have not tried schedutil again.
  15. Like
    znoxx reacted to zador.blood.stained in Armbian for OrangePi PC2, AllWinner H5   
    I added experimental shutdown support for the PC2, numbers from power meter for the next nightly (12.02) are welcome.
    Also please note that the only way to restart after power down is and will be the power cycle. This board doesn't have the PMIC, so it's either full shutdown or different kinds of suspend with "power button" support.
  16. Like
    znoxx reacted to tkaiser in Armbian for OrangePi PC2, AllWinner H5   
    A good place for such a shutdown hook is the stop case in /etc/init.d/armhwinfo. Cpufreq can also be adjusted directly through sysfs and in case you build all relevant hardware drivers as modules you could also try to unload them and then measure again (but then to get USB/Ethernet on boot the module's names might need to be added to /etc/modules or a DT modification might be necessary -- I'm pretty clueless here, same with CPU hotplug support in mainline kernel)
  17. Like
    znoxx reacted to willmore in Armbian for OrangePi PC2, AllWinner H5   
    I printed a case for my PC2 today and reran the thermal soak using cpuminer.  Old score (stock board, mainline kernel, no enhanced airflow) was around 3.2KH/s.  Now, in the case it's running 2.6KH/s and is around 5 degrees cooler.
     
    So, it looks like the DVFS/thermal budget cooling code works pretty well.  Shall I tape up the box so there's no airflow?
  18. Like
    znoxx reacted to Bart in Armbian for OrangePi PC2, AllWinner H5   
    Ok i do some performance check with copper plate ~30/30 mm and some small radiator ...

     
     

     

     
     
    Now i need to think how to put there 40x40x30 mm radiator
     
    After half hour with old cpu fan for lga 775

     

  19. Like
    znoxx reacted to Igor in Orange Pi Zero wireless AP   
    Latest hostapd, normal and patched for Realtek are built from sources and available within Armbian package base (apt.armbian.com) by default since early days of the project:
    apt-get install hostapd or
    apt-get install hostapd-realtek
  20. Like
    znoxx got a reaction from tkaiser in Armbian for OrangePi PC2, AllWinner H5   
    Hi Everyone!
     
    First of all - thanks for this Armbian developer version - works flawlessly.
     
    Here is my stability test result (temperature was about 71 - I'm using passing heatsink).
    Done testing stability: Frequency: 792000 Voltage: 1000000 Success: 1 Result: 0.0048034 Frequency: 816000 Voltage: 1000000 Success: 1 Result: 0.0048034 Frequency: 864000 Voltage: 1040000 Success: 1 Result: 0.0048034 Frequency: 912000 Voltage: 1050000 Success: 1 Result: 0.0048034 Frequency: 936000 Voltage: 1060000 Success: 1 Result: 0.0048034 Frequency: 960000 Voltage: 1080000 Success: 1 Result: 0.0048034 Frequency: 1008000 Voltage: 1100000 Success: 1 Result: 0.0048034 Frequency: 1056000 Voltage: 1150000 Success: 1 Result: 0.0048034 Frequency: 1080000 Voltage: 1160000 Success: 1 Result: 0.0048034 Frequency: 1104000 Voltage: 1170000 Success: 1 Result: 0.0048034 Frequency: 1152000 Voltage: 1200000 Success: 1 Result: 0.0048034 Frequency: 1200000 Voltage: 1240000 Success: 1 Result: 0.0048034 Also, may be you will find interesting some benchmarking results.
     
    I started with "OrangePiLibra" kernel, this 3.x one from SDK. Results were pretty disappointing... RPI3 was not even close.
     
    http://znoxx.me/2017/01/22/epic-battle-rpi-3-vs-opi-pc-vs-opi-pc2/
     
    Site is in Russian, but there is a "Translate" button in Menu. Feel free to use
     
    And finally I repeated tests for Armbian, and they are much better:
     
    http://znoxx.me/2017/01/27/epic-battle-2-armbian-orangepi-pc2-vs-raspbian-rpi3/
     
    RPI3 almost defeated, especially in 7Z benchmarks. Actually other results are close, and, since my SD card in OPi  PC2 is extremely slow (and good one was used in RPi3) - this may be an explanation. Also Raspbian is build with some optimisations, as far as I remember.
     
     
    By the way, here is my heatsink:  http://znoxx.me/content/images/2017/01/opi_pc2_heatsing.jpg
     
    Regarding the cpuminer - here it is in "benchmark" mode:
    [2017-01-27 19:07:21] thread 2: 4579 hashes, 0.93 khash/s [2017-01-27 19:07:21] thread 0: 925 hashes, 0.94 khash/s [2017-01-27 19:07:21] thread 1: 918 hashes, 0.93 khash/s [2017-01-27 19:07:27] thread 3: 4632 hashes, 0.87 khash/s [2017-01-27 19:07:27] Total: 3.66 khash/s It was 3.77 in the very beginning, may be throttling ?
     
    Flags, used to build: 
    ~/cpuminer-2.4.5$ ./configure CFLAGS="-O3 -mtune=cortex-a53 -mcpu=cortex-a53+crypto" Not sure it is correct, but, well, they were accepted by compiler.
     
    Regarding "Reboot issue", mentioned somwhere earlier - I made 3 or 4 reboots - everything is fine. Also, as I said, my mSD is old one 4 class from the box of old electronic guts. And it works without any issues except, well.. speed .
     
    One GREAT thing - my 1Gb router is pretty old and some devices were not able to communicate with it. OPi PC2 with 3.x kernel from China also failed. But this 4.9.0 works like charm! Only one thing - for some reasons DNS server, which should be "pushed" by DHCP is not used and I still see 8.8.8.8 in /etc/resolv.conf (and it does not work for me because of provider I guess). So i had only LAN connectivity, but after resolv.conf manual update everything was fine. Not a big deal, but worth mentioning I think.
     
    So thanks again!