znoxx

Will be fixed once before 2/2020 https://armbian.atlassian.net/projects/AR/issues/AR-86

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:
 
 

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.

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 :)
 

Looks like stability issue. Start with PSU and microSD replacing.

Actually I run snapsot from 17 nov and it is working. I even see difference with different thermal compound in different boards.

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.

Yes. Also a "community supported" configuration can be added to the build system to automate image building.

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.

Just for info - issue is also resolved in 5.32
 

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 ...

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.

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! 

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.

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.

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)

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?

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

 

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

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!