guidol

Hi @guidol, yes I found with 4.17 that the HDMI-related shutdown/restart issues no longer occur.  I.e., you should not have to patch out these entries in the DT - it works fine by default (which is nice!).

Fixed now. All is working.

Your OPi Zero seems to run alltime at 1200Mhz.
 
Please check via armbianmonitor -m 
normally it should switch down (idle) to 240Mhz:
 
root@opi-zero(192.168.6.99):~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 20:20:17: 1008MHz 0.06 0% 0% 0% 0% 0% 0% 70.4°C 2/8 20:20:23: 240MHz 0.05 1% 0% 0% 0% 0% 0% 69.1°C 1/8 20:20:28: 240MHz 0.05 1% 1% 0% 0% 0% 0% 70.3°C 2/8 Maybe it doesnt switch down at the armbian 5.38 with kernel 4.14
 
check  /etc/default/cpufrequtils  for the following content:
 
# WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=240000 MAX_SPEED=1200000 GOVERNOR=ondemand but when it doenst switch down to 240Mhz then try the following command and recheck via armbianmonitor -m  
echo 200000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate A slower cpu could run cooler.

And it seems that you didnt use the WiFi - so you can disable it with the follwoing command in the /etc/rc.local (before the exit 0) :
ifconfig wlan0 down rmmod xradio_wlan rmmod mac80211 rmmod cfg80211 actual I am running a armbian debian nightly version:
 
Welcome to ARMBIAN 5.54.180727 testing Debian GNU/Linux 9 (stretch) 4.17.10-sunxi System load: 0.08 0.02 0.01 Up time: 4 days CPU temp: 70°C I did similiar configurations also on my OPi Zero Plus (non Plus2 but H5) - which also did before sometimes freeze and overheat.

@5kft Hi, seems the genius in you found the right way ?
root@192.168.0.39's password: 
 _   _                   ____  _   _   _              ____  
| \ | | __ _ _ __   ___ |  _ \(_) | \ | | ___  ___   |___ \ 
|  \| |/ _` | '_ \ / _ \| |_) | | |  \| |/ _ \/ _ \    __) |
| |\  | (_| | | | | (_) |  __/| | | |\  |  __/ (_) |  / __/ 
|_| \_|\__,_|_| |_|\___/|_|   |_| |_| \_|\___|\___/  |_____|
                                                            
Welcome to ARMBIAN 5.54.180730 nightly Debian GNU/Linux 9 (stretch) 4.17.11-sunxi64   
System load:   0.00 0.04 0.02      Up time:       4 min        
Memory usage:  11 % of 481MB      IP:            192.168.x.xx
CPU temp:      33°C               
Usage of /:    7% of 15G        
[ General system configuration (beta): armbian-config ]
Last login: Sun Jul 29 16:57:57 2018 from 192.168.x.xx
root@nanopineo2:~# ls -al /sys/class/leds/
total 0
drwxr-xr-x  2 root root 0 Jul 29 16:59 .
drwxr-xr-x 53 root root 0 Jan  1  1970 ..
lrwxrwxrwx  1 root root 0 Jan  1  1970 nanopi:blue:status -> ../../devices/platform/leds/leds/nanopi:blue:status
lrwxrwxrwx  1 root root 0 Jan  1  1970 nanopi:green:pwr -> ../../devices/platform/leds/leds/nanopi:green:pwr
 

Hi @reverend_t, it's not quite done yet; but it's almost there   At this point I am still cleaning a few things up and am starting to submit PRs for this (e.g., PR #1064 and PR #1065 to start).  I'll keep you posted!

Excellent!!!  @guidol, thank you so very much for your time and effort in testing this, I truly appreciate it!!! 

@5kft it did work! -  
U-Boot 2018.05-armbian (Jul 29 2018 - 01:32:58 +0000) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Failed (-5) In: serial Out: serial Err: serial NanoPi NEO2 v1.0 detected Net: No ethernet found. 230454 bytes read in 25 ms (8.8 MiB/s) starting USB... No controllers found Autoboot in 1 seconds, press <Space> to stop Welcome to ARMBIAN 5.54.180730 nightly Debian GNU/Linux 9 (stretch) 4.17.11-sunxi64 root@nanopineo2:~# ls -l /sys/class/leds total 0 lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:blue:status -> ../../devices/platform/leds/leds/nanopi:blue:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:pwr -> ../../devices/platform/leds/leds/nanopi:green:pwr  

The official git armbian\build adds the tvboxes test branch. Everyone is invited to participate in the development , testing and maintenance of different models of TV boxes.
 
https://github.com/armbian/build/tree/tvboxes
 

Thanks for your replies.
I tried the image corresponding to Nanopi Neo / Core after the changes that you made but i got the same results.
I will try the image that you mentioned now @guidol .
Thanks a lot for your help.

@5kft: like @Pat my 2 Neo2 v1.0 are identified at u-boot as Neo2 v1.1
So I also see the wrong led-color-names
 
I did test it with my 2 Neo2 v1.0 and also get them out of the case to see they are real v1.0 (non-popup-sdslot, the v1.0 Ethernet-port, unsoldered audio):
 
IP22 Neo2: ========================================================================== U-Boot 2018.05-armbian (Jul 21 2018 - 07:20:45 -0700) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Failed (-5) In: serial Out: serial Err: serial NanoPi NEO2 v1.1 detected Net: No ethernet found. 230454 bytes read in 24 ms (9.2 MiB/s) starting USB... root@nanopineo2:~# ls -al /sys/class/leds/ total 0 drwxr-xr-x 2 root root 0 Jul 21 14:26 . drwxr-xr-x 53 root root 0 Jan 1 1970 .. lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr IP23 Neo2: ========================================================================== U-Boot 2018.05-armbian (Jul 21 2018 - 07:20:45 -0700) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** Failed (-5) In: serial Out: serial Err: serial NanoPi NEO2 v1.1 detected Net: No ethernet found. 230454 bytes read in 25 ms (8.8 MiB/s) starting USB... root@nanopineo2:~# ls -al /sys/class/leds/ total 0 drwxr-xr-x 2 root root 0 Jul 21 14:28 . drwxr-xr-x 53 root root 0 Jan 1 1970 .. lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr  

Hi @guidol, @Pat - thanks again for the testing!  I dug into this and as-is in the current u-boot the driver code for the second GPIO bank doesn't appear to be working, so I can't properly read the "board ID" GPIO line.  Unfortunately as I am completely unfamiliar with this implementation in u-boot I need to debug this and figure out what is going on.  The good news is that I found another exposed GPIO line in that same bank that I can use to debug and test, so I won't bother you with trying this until I have the new implementation   (It may be a few days for me to find enough time to work on this, however...but I will keep you posted!)

NanoPi Fire3 with Samsung/Nexell S5P6818 which is an octa-core A53 clocked by default with 1.4 GHz (results irrelevant):
 
Why are results irrelevant? For two reasons:
Throttling occured. The board with vendor's standard heatsink starts to overheat badly when running demanding loads. Active cooling is needed and that's why monitoring when running benchmarks is that important! This is an octa-core Cortex-A53 SoC showing with this benchmark a score of well above 7000 when no throttling happens. Once again: such multithreaded results are BS wrt most real world workloads. An RK3399 board like an ODROID-N1 scoring 'just' 6500 will be the faster performing board with almost all usual workloads since equipped with 2 fast A72 cores while the Fire3 only has 8 slow A53 cores. Most workloads do not scale linearly with count of CPU cores. This has to be taken into account.

maybe @Pat is this time faster, because my 2 Neo2 v1.0 are installed inside the silver NAS case....
I have to open the case and install MicroSD and serial converter...and every time I unscrew the case it wouldn't get better

Not the final version.

 
Update(8/24/2018): It's time to deal with NEO4, this picture is not the final version. NEO4 will have PCIe x2 and eMMC connector too, and a MIPI-CSI. But the dual-layer USB connector  will share USB 3.0 & USB 2.0, Type-C take another USB 3.0.

Here the output from (one of) my v1.0:
 
root@nanopi-neo22(192.168.6.22):~# sudo su - root@nanopi-neo22(192.168.6.22):~# cd /sys/class/gpio root@nanopi-neo22(192.168.6.22):/sys/class/gpio# echo 355 >export root@nanopi-neo22(192.168.6.22):/sys/class/gpio# cd gpio355 root@nanopi-neo22(192.168.6.22):/sys/class/gpio/gpio355# echo in >direction root@nanopi-neo22(192.168.6.22):/sys/class/gpio/gpio355# cat value 1 Kernel: Linux nanopi-neo22 4.17.7-sunxi64 #129 SMP Tue Jul 17 20:35:09 UTC 2018 aarch64 GNU/Linux  

Me neither. Maybe @guidol can help?

https://invisioncommunity.com/forums/topic/439176-haze-42x-by-ips-themes/?do=findComment&amp;comment=2751318

I had the same issue today, with a system working well with xenial but no sound on stretch.
 
The problem was with the wrongly identified active / passive controls, i had to manually adjust the line out volume and enable the line out to get any sound out from the 3.5 jack.
You can use this code to enable the line out on your board:
# enable line out on jack connector (IMPORTANT) /usr/bin/amixer -c 0 cset numid=4 on # Set line out volume to maximum (0-31) /usr/bin/amixer -c 0 cset numid=3 31 # Setting the DAC volume (master PCM channel) (0-63) /usr/bin/amixer -c 0 cset numid=1 63 # Enable DAC to be routed to output (analog pcm) (on/off) /usr/bin/amixer -c 0 cset numid=10 on  
You must also disable the mic1 loopback, otherwise everything coming from your microphone will be forwarded to the line out and you most certainly dont want to do that:
# Microphone settings #mic1 (internal) volume 0-7 /usr/bin/amixer -c 0 cset numid=7 7 #mic1 CAPTURE switch (on/off) - this will let you use the microphone /usr/bin/amixer -c 0 cset numid=18 on #mic1 (input) boost (0-7, 1 recommended) /usr/bin/amixer -c 0 cset numid=8 1 #mic1 (internal) playback loop switch (direct route to output) (on/off) LEAVE IT OFF to avoid feedback loop between internal microphone and speakers !!! /usr/bin/amixer -c 0 cset numid=13 off #mic2 volume 0-7 /usr/bin/amixer -c 0 cset numid=5 7 #mic2 CAPTURE switch (on/off) - this will let you use the microphone /usr/bin/amixer -c 0 cset numid=19 on #mic2 boost (0-7, 1 recommended) /usr/bin/amixer -c 0 cset numid=6 1 #mic2 playback loop switch (direct route to output) (on/off) /usr/bin/amixer -c 0 cset numid=14 off # obviously you can disable the capture in either or both of the microphones if you want to have a single source (mic1/mic2/linein) Simply save it somewhere, make it executable, and insert at /etc/rc.local before the exit 0; line.
I hope someone will find this info valuable.
 

With 10,000 the kernel takes a look 100 hundred times each second, when set to 200,000 it's just 5 times any more. And this is all off-topic here as already said (but same applies to the other thread that talks about OPi Zero)
 
As a first step I tried to consolidate timer frequency settings accross all kernels since what we have today is just chaos.

Yes - here's an example:  https://i.imgur.com/ynC6IiP.jpg.  Very simple, and perfect for fitting on a tiny perfboard 

@guidol has a good looking case mentioned in the NanoPi K1+ thread:
 
 
 
 

@guidol, today arrived my Transcend RDF5 (unfortunately not available in white here). Veryfing the image is lovely 50MB/sec. I think my old USB2.0 is way slower, I have to check that.

I did an initial boot without changes to see if the image it works...
Warning: a reboot is needed to finish resizing the filesystem. Please reboot the system as soon as possible root@bananapim2plus:~# h3disp -m 1280x1024 -d Now trying to patch script.bin with your settings. Successfully finished. Please reboot for changes to take effect reboot ...  brilliant, it booted to the desktop with 1280x1024 @60Hz. Resizing completed.
 
I did all that. Unfortunately, the Display stays now black, I can only access it via SSH.
armbianmonitor -u   http://ix.io/1h7i
 
h3disp -m 1280x1024 -d ... reboot... et voila desktop is up and running. Well done Sir
 

OK, I did the following:
cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=240000 MAX_SPEED=1008000 GOVERNOR=conservative sudo rm /lib/systemd/system/ondemand.service sudo systemctl daemon-reload sudo reboot cpufreq-info -o minimum CPU frequency - maximum CPU frequency - governor CPU 0 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative CPU 1 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative CPU 2 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative CPU 3 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative

Cool!  Thanks for this
 
Just tweaked to change my cpu minimum to 240MHz
sudo cpufreq-set --min 240MHz changed my governor to conservative and now in my armbianmonitor -m shows it dropping down to the lower cpu speed and temps are dropping well at idle speeds
 

Thank you! I tried to follow the directions, it was just not the right directions. I created a Ubuntu 18.04 VirtualBox like you said, changed LIB_TAG to sunxi-4.18 and built and ran mainline 4.17 and touch screen, wifi, GPIO are working. I will test more.  So far all is good.
 
I really appreciate everyone's help.