5kft

https://github.com/armbian/build/commit/76ac54aae381714cee7bf1b03d4bce097b1630de
root@orangepizeroplus2:~# uname -a Linux orangepizeroplus2 5.1.15-sunxi64 #5.90 SMP Thu Jul 4 21:07:22 CEST 2019 aarch64 GNU/Linux root@orangepizeroplus2:~# cat /sys/class/thermal/thermal_zone0/temp 58191  

Hi @Igor, @guidol - in case it is helpful, I took a quick look at this and the fix is pretty straightforward.  Essentially all that needs to be done is to remove the existing "patch/kernel/sunxi-dev/ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch" for 5.1, and to port over the 4.19 "patch/kernel/sunxi-next/ths-29-add-correct-h5-thermal-zone.patch" to 5.1 (i.e., bring into "patch/kernel/sunxi-dev/").  The problem is the currently the thermal-zone is defined in the wrong DT location, and the zone definition and tips  and cooling maps are incorrect/incomplete for the 5.1 version.
 
I did a quick test of fixing it this way and the result works:
root@nanopineo2:~# cat /proc/version Linux version 5.1.15-sunxi64 (root@elrond) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #5.90.190705 SMP Thu Jul 4 14:05:17 UTC 2019 root@nanopineo2:~# cat /sys/class/thermal/thermal_zone0/temp 40936 root@nanopineo2:~# I'd fix this and submit the change myself, but unfortunately I don't have time to be thorough about testing it right now (e.g., verify on some H3 boards and other H5 boards as well), and likely won't be able to until next week...I'm happy to do this then if you don't have time to look into this.

Hi @Igor, @guidol - in case it is helpful, I took a quick look at this and the fix is pretty straightforward.  Essentially all that needs to be done is to remove the existing "patch/kernel/sunxi-dev/ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch" for 5.1, and to port over the 4.19 "patch/kernel/sunxi-next/ths-29-add-correct-h5-thermal-zone.patch" to 5.1 (i.e., bring into "patch/kernel/sunxi-dev/").  The problem is the currently the thermal-zone is defined in the wrong DT location, and the zone definition and tips  and cooling maps are incorrect/incomplete for the 5.1 version.
 
I did a quick test of fixing it this way and the result works:
root@nanopineo2:~# cat /proc/version Linux version 5.1.15-sunxi64 (root@elrond) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #5.90.190705 SMP Thu Jul 4 14:05:17 UTC 2019 root@nanopineo2:~# cat /sys/class/thermal/thermal_zone0/temp 40936 root@nanopineo2:~# I'd fix this and submit the change myself, but unfortunately I don't have time to be thorough about testing it right now (e.g., verify on some H3 boards and other H5 boards as well), and likely won't be able to until next week...I'm happy to do this then if you don't have time to look into this.

The problem with AP6212 appears to be a regression caused by this commit:  https://github.com/armbian/build/commit/52d82c921d02366f5fe7fa5e6a754227ce9e6913.  I added a comment to the commit regarding this...
 

The problem with AP6212 appears to be a regression caused by this commit:  https://github.com/armbian/build/commit/52d82c921d02366f5fe7fa5e6a754227ce9e6913.  I added a comment to the commit regarding this...
 

Per request, here are updated instructions for overclocking the NEO2 v1.1 LTS board to 1.3GHz, for the latest builds of Armbian (kernel 4.19+, build 5.70+):
 
1.  Please note that this will not work on a NEO2 v1.0 board - the first version of the board doesn't include a regulator nor circuit that supports voltage switching.  Only follow these instructions if you are using a v1.1 board!
 
 
2.  Edit /boot/armbianEnv.txt, and add these lines:
overlay_prefix=sun50i-h5 overlays=cpu-clock-1.3GHz-1.3v If you have other overlays specified in your /boot/armbianEnv.txt, simply append these two new ones following them, for example:
overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost1 usbhost2 cpu-clock-1.3GHz-1.3v  
3.  Edit /etc/default/cpufrequtils, and set the MAX_SPEED definition to 1300000, e.g.:
# WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1300000 GOVERNOR=ondemand  
4.  Configure APT so that /etc/default/cpufrequtils will not be reverted to the system default when the package is upgraded (e.g., via "apt upgrade"):
dpkg-divert --add /etc/default/cpufrequtils  
5.  Reboot the board.
 
That should be it!  Following reboot, you can verify proper operation at the higher CPU clock speeds using "cpufreq-info" (for example).

Given the number of boards that can support higher CPU clocks (e.g., Nano Pi Neo 2, Plus2, Core2, OPi Zero Plus, OPi Zero Plus2 w/H/W MOSFET fix, etc.) it'd be great to be able to do this with overlays, rather than introduce a combinatorial explosion of board DTBs (i.e., per-board 1.1GHz max, 1.3GHz max, 1.4GHz max).
 
I have made some test override overlays to add the regulator and extend the CPU operating table (e.g., adding additional CPU core clock frequencies).  This works fine - one can just add the desired overlays in armbianEnv.txt and the new clock speeds appear and work:
... overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost2 usbhost3 gpio-regulator-1.3v cpu-clock-1.3GHz param_spidev_spi_bus=1 ... However the problem is that one can't reliably run these boards at the higher clock rates without adjusting the thermal-zone cooling-map for the higher speeds.  Unfortunately device tree overlays don't appear to support thermal zones (at least I can't get them to compile with these present ).
 
I'm interested if anyone might have any ideas to to manage this.  Just brainstorming here, but perhaps we could make the default cooling-map for the H5 a bit more conservative, and then it could cover the introduction of the higher possible clock rates?  Or perhaps we could remove some slower entries from the H5 default clock operating table to allow for the addition of the optional higher clock rates (to better correspond to the default H5 cooling-map)?
 
Again, the nice thing about the overlay route is that we wouldn't have to change the 1.1GHz Armbian H5 default, so operation will be reliable.  But if users want to try speeding up their boards (whatever brand, VDD regulator, etc.), then they can just add an overlay or two and voila the higher speeds will be enabled.
 

Hi @Frank F., interesting...I'm not sure why the Plus2 is still WIP, as IMHO it essentially is at the same level of functionality as the other FriendlyElec H5 boards (e.g., NEO2).  I actually use both boards for several different purposes and they work really well.
 
I use both GPIOs and SPI on the NEO2 and they work great (multiple LED control as well as interfacing to an nRF24l01-based wireless radio).  I have tried a subset of the I/Os on the NEO Plus2 some time back (e.g., testing interfacing with SPI flash), but haven't used the I/Os on that board since.  I don't know why it all wouldn't work the same on the Plus2 given that the base platforms are essentially the same.
 
Wi-Fi works nicely on the Plus2 (I use the FE metal case with the included antenna).  I haven't tried BT.  The USB ports work fine on both.  The eMMC on the Plus2 is fairly fast as well (I use btrfs to save space as it is only 8GB in size).  They both overclock nicely to 1.3GHz.
 
Here's a quick dump of some stuff from the Plus2:
root@nano:~# cat /proc/version Linux version 4.19.20-sunxi64 (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.75 SMP Fri Feb 8 10:29:25 CET 2019 root@nano:~# uptime 14:20:35 up 49 days, 22:46, 2 users, load average: 0.04, 0.03, 0.00 root@nano:~# dpkg --list | grep plus2 ii linux-stretch-root-next-nanopineoplus2 5.73 arm64 Armbian tweaks for stretch on nanopineoplus2 (next branch) ii linux-u-boot-nanopineoplus2-next 5.75 arm64 Uboot loader 2018.11 root@nano:~# hdparm -tT /dev/mmcblk2 /dev/mmcblk2: Timing cached reads: 1078 MB in 2.00 seconds = 538.66 MB/sec Timing buffered disk reads: 132 MB in 3.04 seconds = 43.41 MB/sec root@nano:~# root@nano:~# sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 4 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 7.0618s total number of events: 10000 total time taken by event execution: 28.2335 per-request statistics: min: 2.79ms avg: 2.82ms max: 8.84ms approx. 95 percentile: 2.79ms Threads fairness: events (avg/stddev): 2500.0000/0.71 execution time (avg/stddev): 7.0584/0.00 root@nano:~#  
As to which one to get, a lot depends on your desired use...  The NEO2 is really nice because of its tiny size; however there is no included eMMC, nor Wi-Fi, and it includes just one USB port.  The Plus2 is a bit larger, but the two USB ports and gigE port are nice (I use one of the boards as a local router), as is the built-in Wi-Fi and eMMC (so no additional uSD card is needed).  The metal case for the Plus2 is really great as well (https://www.friendlyarm.com/index.php?route=product/product&path=93&product_id=203).
 
I hope that this feedback helps a bit!
 
 

little "dumb" idea:
if the part outside the linuxfilesystem is damaged, the non-armbian-image will work because of the vfat partition which is "covering" the error.
years ago I had a old hdd which has bad sectors in the first 1GB.
after adding a 1GB partition ad the start of the hdd and using the rest as the second partition the os could be installed and used from the second partition.
Maybe @rmoriz could use the other partition style for armbian when tranfering armbian manually to emmc.

Hi @dispo, nice catch!  I just enabled the CPU activity LED trigger in the kernel (https://github.com/armbian/build/commit/fd3b83136b9baa62326feea28d14d44736b6f448).  With this change you can set the LED trigger to "activity" and the LED will flash based upon instant CPU load (across all cores).

Images are building and uploading at this moment. A few more tests and repository will also be updated, so you will be able to upgrade your current build to 4.19.y

You already helped a LOT! 
 

Indeed! Let's fix this Pinebook's troubles and we might slowly switch 4.19.y to nightly NEXT building ...

Hi @Igor, I just tested both I2C and SPI on the Plus2 H5 and both appear to work.  Both tests were to devices connected to the pin header.  The SPI test was using a 4MB SPI flash part, and the I2C test was just to detect an SH1106 OLED display connected to TWI0-SDA/SCK (display is configured at I2C address 0x3c):
root@orangepizeroplus2:~/tmp# dd if=/dev/random of=test.dat bs=1024 count=4096 iflag=fullblock 4096+0 records in 4096+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 8.29973 s, 505 kB/s root@orangepizeroplus2:~/tmp# root@orangepizeroplus2:~/tmp# flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000 -w test.dat flashrom v0.9.9-r1954 on Linux 4.19.4-sunxi64 (aarch64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on linux_spi. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED. root@orangepizeroplus2:~/tmp# flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000 -r test2.dat flashrom v0.9.9-r1954 on Linux 4.19.4-sunxi64 (aarch64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on linux_spi. Reading flash... done. root@orangepizeroplus2:~/tmp# md5sum test*.dat 979776e45a0b9fd7caf154f4f1bbbbf4 test2.dat 979776e45a0b9fd7caf154f4f1bbbbf4 test.dat root@orangepizeroplus2:~/tmp# root@orangepizeroplus2:~/tmp# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@orangepizeroplus2:~/tmp# root@orangepizeroplus2:~/tmp# cat /boot/armbianEnv.txt verbosity=1 console=both overlay_prefix=sun50i-h5 overlays=usbhost2 usbhost3 spi-spidev i2c0 param_spidev_spi_bus=1 rootdev=UUID=2b29fd0a-3553-4999-be20-f3175d84e624 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u root@orangepizeroplus2:~/tmp# Very nice how well it all is working!
 

Hi, this should now be fixed with https://github.com/armbian/build/commit/e0f27fff66220e56b6419879957af28fa46ff84f.  I tested this on an unmodified Plus2 H5 (i.e., missing MOSFET in the regulator switching circuit).  Without this change the boot would fail as @guidol noted (heartbeat, then stops, and the board hangs); with this change it boots and runs just fine, and the maximum CPU clock rate is properly limited.

Hi, this should now be fixed with https://github.com/armbian/build/commit/e0f27fff66220e56b6419879957af28fa46ff84f.  I tested this on an unmodified Plus2 H5 (i.e., missing MOSFET in the regulator switching circuit).  Without this change the boot would fail as @guidol noted (heartbeat, then stops, and the board hangs); with this change it boots and runs just fine, and the maximum CPU clock rate is properly limited.

I did also compile for the OPi R1 - I could also successfully test the USB via the OPi NAS AddOn.
A report has been created (dont know if @5kft did this also)
I do have some lacking at the SSH-connection via eth0  like on a "bad" WiFi-Connection because of:
 
[ 1439.605021] ==> rtl8188e_iol_efuse_patch [ 1501.258078] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1523.785870] dwmac-sun8i 1c30000.ethernet eth0: Link is Down [ 1524.810021] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1528.905843] dwmac-sun8i 1c30000.ethernet eth0: Link is Down [ 1529.930016] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1538.121820] dwmac-sun8i 1c30000.ethernet eth0: Link is Down [ 1539.146029] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1628.389288] ==> rtl8188e_iol_efuse_patch [ 1691.429555] ==> rtl8188e_iol_efuse_patch [ 1754.554618] ==> rtl8188e_iol_efuse_patch the second ethernet-port enxc0742bffxxxx didnt seem to have this lacking

Hi @shaun27, I just implemented support for this for the Fire3 and have pushed the changes into Armbian (see https://github.com/armbian/build/commit/1301f9f8c254d8408b9136948c786dffa5007acd).  The power button/PWRKEY now works for both powering up the board as well as powering it down 
 

Hi @Igor, just a quick note - I had to make a small fix for Orange Pi Zero Plus (https://github.com/armbian/build/commit/b0f92ee58c6cbefbbcd52dcb93e1128c7528cb54); with this change this board seems to work fine now as well with the new 4.19.y kernel.

Hi @Igor, I've tried a top-of-tree H5 build so far on:
Neo2 v1.1 512MB Neo2 v1.1 1GB Orange Pi Zero Plus2 H5 Nano Pi Neo Plus2 ...and all works well.  Very nice!!    (These are all dumb regulator boards BTW)
 
Tests include USB (Wi-Fi and Ethernet dongles), H/W SPI interface (via spidev), multiple GPIOs (via libgpiod).  I've switched to 4.19.y for all of these now.
 
(I still have a few more boards that I'll dig up and try it on...)
 

https://github.com/MockbaTheBorg/RunCPM
there is a nice little CP/M emulator which do compile fine under armbian.
(There is also a version for the Arduino DUE with SD-Hat or a ESP32/Teensy)
 
With that you can run many CP/M-Software like Wordstar, dBase II and so on
 
Special on this emulation is that it do use directorys as drives
The directory A (or A/0/) would be Drive A>
 
Maybe you also want do something retro this weekend?
 
Here is how I did compile/install it on my OPi One:
 
compile RunCPM: =============== install ncurses-dev and lua: ============================ apt install libncurses5-dev liblua5.3-dev git make cd /home/guido/ git clone https://github.com/MockbaTheBorg/RunCPM RunCPM_git cd RunCPM_git/RunCPM make posix clean make posix build mkdir /home/guido/RunCPM mkdir /home/guido/RunCPM/A mkdir /home/guido/RunCPM/A/0 cp RunCPM /home/guido/RunCPM cp /home/guido/RunCPM_git/CCP/* /home/guido/RunCPM cp /home/guido/RunCPM_git/DISK/A.ZIP /home/guido/RunCPM/A/0 cd /home/guido/RunCPM/A/0 unzip A.ZIP cd /home/guido/RunCPM To start the Emulation: ======================= ./RunCPM To exit the emulation: ====================== a> exit  

bumping is normally the best way to get a warning... 
 
that's why h5 is marked testing.. nobody knows..
 
nothing to care about... that's normal.. 
 
 
probably related to this one:
no idea, I don't follow H5 development close enough....
 

and a lot of reading might give you a clue what's and how stable things are working on h5 for *random usecase*.. H5 and H6 are in development phase. 
 
@Igor I think our download-page here is 'part of the problem'. 

 
I suggest that we mark those images as wip not supported. The only kernel we provide is in experimental or at least testing phase.. The exceptions from supported are higher than WIP.. 

FYI - the NEO4 is now available - see https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=241
 
I just placed my order 
 
 

FYI - the NEO4 is now available - see https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=241
 
I just placed my order 
 
 

@5kft -- Thanks for this, worked like a charm! For anyone looking for more -- all I had to do was grab the device tree tools and run the following on the existing dtb in the boot directory:
 
dtc -O dts s5p6818-nanopi-fire3.dtb > fire3-devicetreetxt.dts #[Modify frequencies on dts file, too lazy to build a sed command] dtc -O dtb fire3-devicetreetxt.dts > s5p6818-nanopi-fire3.dtb I think on the FriendlyArm provided distro this would be the 05.dtb file as @wtarreau mentioned. No recompilation of the kernel required, just a reboot.
 
It seems that for any overclock a small voltage bump is required. I am still looking into if this will push my 10 port USB hub (60w anker) past its rated capacity when all 10 Fire3's are loaded to 100%.
 
@wtarreau -- If you have a chance I'd love to take a look at your thermal throttling point configuration. Standard disclaimer of course noted :-)
 
Thank you both!
 

Hi @cmoski, in case it is helpful to you:  If you are using the "nanopifire3" board configuration ("next" target), you can build the kernel, specifying the "CREATE_PATCHES=yes" option, and then modify the generated DT in "cache/sources/linux-4.14.y/arch/arm64/boot/dts/nexell/s5p6818-nanopi-fire3.dts".  Look for "dvfs-tables" in this DT file and edit/add the higher frequency:
dvfs:dynamic-freq@bb000 { supply_name = "vdd_arm_spu"; supply_optional = "vdd_arm_axp"; vdd_arm_spu-supply = <&VCC1P1_ARM_SPU>; vdd_arm_axp-supply = <&VCC1P1_ARM_PMIC>; status = "okay"; dvfs-tables = < 1400000 1200000 1300000 1140000 1200000 1100000 1100000 1040000 1000000 1040000 900000 1000000 800000 1000000 700000 980000 600000 980000 500000 940000 400000 940000>; }; In this table the first column is the frequency, and the second is the voltage provided by the SPU1705 regulator for that frequency.  Note that the maximum voltage that this regulator can output is 1.265v (please see ".../drivers/regulator/spu1705.c" for details).
 
My Fire3 could run fine at 1.5GHz using 1.265v, but 1.6GHz was too unstable (random crashes).  The original FriendlyELEC kernel tree sets the maximum to 1.4GHz at 1.2v, so this is what I brought over to Armbian.
 
I hope this helps...!