manuti

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, it looks the same but in nice blue color!

Ok, I'm going to just keep adding boards if it continues to work. I was more worried about it throttling down the performance of the boards before they shut off but it sounds like that's not what it would do.
 
You seem knowledgeable about the board so what do you feel like is a good stable operating temperature for these units?  I am running active cooling and no overclock (1.4GHz) on all of my fires and I am seeing something between 66-70 degrees C on average when I periodically check on temps. This can of course vary depending on the ambient temerature in the room as well. If I tried out a mild overclock what temperature range would you start to get concerned at? It sounds like you are running yours at 1.6GHz - what kind of cooling are you running?  I'm currently using small fans running on 3.3v. My setup is close to my desk and I have found running them at 5v is on the annoying side so I'd like to keep them at 3.3v.

The NanoPi K1 Plus:
 
[  ] armbian good support - not yet
[x] 2+GB ram - yes
[x] fast cpu - yes and 64bits
[x] Gigabit Ethernet - yes
[x] eMMC support could be nice for fast OS - yes
[x] it will run headless - yes 
[  ]- docker support - yes when armbiam come
[  ]- USB 3 support could be nice, otherwise USB 2 is ok - USB2.0
 
 

last numbers:
openssl speed -elapsed -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 21097762 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 13885050 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 5712407 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1744124 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 232965 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 116966 aes-256-cbc's in 3.00s OpenSSL 1.1.0g 2 Nov 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 112521.40k 296214.40k 487458.73k 595327.66k 636149.76k cpufreq-info -c 1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 1: 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: 2.54 ms. hardware limits: 480 MHz - 1.37 GHz available frequency steps: 480 MHz, 648 MHz, 720 MHz, 768 MHz, 912 MHz, 1.08 GHz, 1.20 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.37 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1.37 GHz. cpufreq stats: 480 MHz:4.74%, 648 MHz:1.64%, 720 MHz:0.35%, 768 MHz:0.59%, 912 MHz:0.48%, 1.08 GHz:0.44%, 1.20 GHz:0.38%, 1.37 GHz:91.36% (3239) at least, 4.17 pretty stable...
 
I think there is room for improvement, board does not get Temp over 54 ºC so lets the experts handle this... 
 

The dtb file name contains all the necessary information. For which platform, how much RAM, type of network, etc. some have an indication of a particular TV box model.

@Igor great!
 
I'll create my commit locally in that branch, then generate a plain image for the Odroid HC1, then test it directly in the board, when everything is ok will PR to development branch. Sounds good?

I just looked through those numbers on https://libre.computer/2018/03/21/raspberry-pi-3-model-b-review-and-comparison/ again just to realize that there's also something seriously wrong. The OpenSSL tests are also a great benchmark to check for real CPU clockspeeds since not affected by memory bandwidth at all (the AES scores with ARMv8 Crypto Extensions available scale linearly with clockspeed when comparing different A53).
 
When comparing Le Potato (S905X claiming to run at 1.5 GHz) with Renegade (RK3328 at 1.3 GHz) then it's pretty obvious that the S905X was running with 1320 MHz maximum. Which is a bit too low even if we already take into account that S905X can't reach the 1.5 GHz anyway due to bl30.bin situation.
 
There's something seriously wrong with CPU clockspeeds on Amlogic platforms. And maybe there's also a relationship with broken/weird scheduling though I really don't understand how this can happen (there should be no difference on a quad-core CPU whether the kernel decides to run on cpu 0-3 or the user 'forces' exactly the same using 'taskset -c 0-3' -- but reality draws a different picture)

You can find that ssv6051 module in 5.41.1 images(I don't know about 5.41 ) . And mali 7 one I downloaded yesterday , it has ssv 6051 module too.

The only real difference is that nightly images are (usually) not tested. They are just built from upstream, normally every day ... in reality building can be on hold for a week or more until things, which break the compilation, gets fixed or are removed. And most of the images don't get daily images rebuild, but only packages. This means any existing image, stable or nightly, can be upgraded to the latest nightly. (armbian-config -> switch to nightly)
 
171217 = 17. December, 2017

http://wiki.friendlyarm.com/wiki/index.php/NanoPi_K1_Plus
 
RPi 3 form factor like their K2, maximum DRAM (2GB), Gigabit Ethernet, Wi-Fi with onboard aerial provided by RTL8189ETV, still using their own/new eMMC socket. According to schematics and their Github repo a SY8106A voltage regulator is used which is great news since then it's possible to clock the H5 well above 1.3 GHz.

Test image Debian + KODI-18.
 
https://yadi.sk/d/goZiDfto3UV8UU
 
To run KODI-18 , you need to perform additional configuration of the system.
1. you need to remove the package “pulseaudio”
2. Switch to the test repository (disable all other repositories and enable "test" in the sourceslist file). Then install a new version of libc6-2.27 from the test repository).
After these steps, you can use KODI-18 as usual.

I have completely rewritten my first post with detailed instructions on how to install Ayufan's Armbian Ubuntu without needing a separate PC.

Hi , can anyone tell me which module will be good for wifi chip sv6051p? I have s905w board (x96 mini ). I tried wifi_dummy and modprobe dhd but nothing worked .

For those interested I made some improvements in the GLES display backend of uae4arm:
 
https://github.com/Chips-fr/uae4arm-rpi
 
I tested it on Armbian on my orange Pi Pc+ (H3), was able to get 50fps for some games.
 
The only remaining issue is that vsync is not activated and tearing occurs.
Does anyone know how to solve this ?
 
Feel free to try on others boards...
 

All right, the wi-fi now works:
You need to create the file /etc/modprobe.d/ssv6051.conf
and enter the path to the driver configuration file
(type in file)
options ssv6051 stacfgpath = / lib / firmware / ssv6051 / ssv6051-wifi.cfg
You must also configure the wpa_supplicant for network access.
 
A great idea from Forum Alex @ ELEC
 
The other error messages to boot remain to be solved but it is a secondary problem!
 
Now I will install my home automation server (probably Fhem)
 
Thanks to all for collaboration!

This topic is a response to the growing number of kernels, growing number of boards with... "unique properties", and for the increased complexity of some platofrms (aarch64 and the atf, etc).  I think the coherency of the chosen organizational method is starting to fall apart.
 
So just a thought experiment on my part:
 
Currently, we have a sources directory, and the sources file has not just sources, but also executable script functions in it.  We also do our patches per SoC, mostly, but the organization is by the thing being compiled rather than by the target, making finding/adjusting a bit cumbersome in some cases. 
 
I would propose a directory tree looking something like this:
 
├── RK3288 │   ├── kernel │   │   ├── default │   │   ├── dev │   │   └── next │   ├── miqi │   ├── tinkerboard │   │   ├── kernel │   │   │   ├── default │   │   │   ├── dev │   │   │   └── next │   │   └── uboot │   │   ├── default │   │   ├── dev │   │   └── next │   └── uboot │   ├── default │   ├── dev │   └── next └── S905 In this case the organization is by SoC, then by board.  All patches safe for the entire board population get put in the SoC-level kernel and uboot patch folders, anything unsafe (hardkernel-specific patches, Tinker board specific patches) go into the board-level folders.  To reinforce that we want those folder to be "last resort", we could call them "C2_bugs, Tinker_bugs" etc.
 
For our 64-bit targets, the trusted firmware would likewise have it's directory.  I think it might also make for a lower barrier to entry on committing fixes, I still worry about patching things when I don't have all the boards to test on, this way, as a novice or as someone doing something that I can't test on other hardware, I can drop the patch into the board(s) I have, then they can be evaluated by the other devs on the remainder of the hardware.
 
My particular set of boards benefit this way:
 
Tinker board specific patches are many, integrating them safely is one of the biggest reasons we lag the vendor kernel, changes to the architecture files, changes to rk3288.dtsi instead of just to rk3288-minarm.dts, changes to various drivers for specific hardware issues, etc etc etc etc. Differences in gxbb vs gxl Meson64 devices.  Most of these coexist peacefully, but then you have vendor issues with u-boot of the C2, K2, etc (everyone has their own bootloader blobs)  
I'd say we organize bootloader scripts similarly, rather than having executable scripts in the sources file we could place an include in the appropriate board folder covering the specifics. For example, if a board ships with a SPI boot flash, we don't need to burn u-boot, only provide the proper configuration of partitions/etc. That might be the only board in the series (an unusually awesome H3 board, for example).
 
Ideally, at that point, adding a new board would require a new board definition file, and then the proper patches folder. 
 

Have you downloaded the modules for WiFi ? Maybe your whole problem is solved with one command " modprobe ssv6051"

OMV is based on Debian. That's the simple reason it won't install on Ubuntu (dependency hell, different package versions). And if someone wants to run OMV I strongly recommend to check first whether there are available images at the download page or otherwise choose an Armbian Stretch next variant and then use armbian-config to install OMV.
 
Even if someone interested in NAS does not want to rely on OMV/Debian looking into the various performance tweaks we did is worth the efforts: https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/?do=findComment&comment=44097
 
 
And for any NAS usage next kernel is strongly recommended since better hardware support (especially UAS support for USB storage).

The main utility to read and write GPIO pins on Raspian is /usr/local/bin/gpio.  It was written by Gordon Henderson (http://wiringpi.com) and also comes with an api library suitable for C/C++ development.  A couple of years ago I found an excellent version ported for the Orange Pi (https://github.com/zhaolei/WiringOP.git).  The one thing that they both do is set the SUID bit on the GPIO utility, thus allowing any user to run it.

Just for the record: This (using the OMV RPi image and removing the OMV parts) will not result in an Armbian installation (I'm aware that you've written about 'Armbian a like', just want to further clarify). It's just a Debian Jessie armhf rootfs generated by Armbian's build system that has been slightly adjusted and manually combined with RPi Foundation's kernel packages and the proprietary, closed sourced RPi stuff (ThreadX on the /boot partition and some proprietary userspace binaries to interact with VideoCore/ThreadX, most importantly to report/detect under-voltage).
 
Armbian is about:
bootloader and kernel optimizations (first not possible since closed source ThreadX, latter not reasonable/needed on Raspberries) optimized settings to improve performance, consumption and thermal behaviour (not possible on RPi since done entirely on the VideoCore by ThreadX) to improve security situation building an entire OS image from scratch so no one has fiddled around so far (if you use our build system and let it debootstrap a fresh Armbian image you know no one logged in so far and planted backdoors or stuff like that) So the OMV image is just a modified piece of data that was falling out of Armbian's build system (the rootfs) manually adjusted to be combined with the proprietary and closed source stuff that still makes up the whole 'RPi experience' (for the majority of RPi users I personally know the Pi is just a KODI and retrogaming box and without the proprietary video decoding and 3D acceleration stuff on the VideoCore they would have to throw it away)
 
So all you get by using this OMV image is the illusion wrt 3) above (clean rootfs) but thinking this would enhance security or prevent you from being backdoored is just... an illusion. The main CPU of every RPi is still the outdated VideoCore from 2009 (this chip contains not only GPU, VPU and multiple QPU cores but also an ordinary dual core CPU inside running the closed source RTOS called ThreadX). The ARM cores running any secondary OS are just guests. Since Raspberries are popular for stuff like Tor end nodes or VPN gateways who knows whether GCHQ already ordered the Foundation to ship their ThreadX with an universal backdoor to allow agency access?)
 
Anyway: maybe the OMV image's only real advantage is that it's Jessie based but still gets RPi Foundation's kernel updates (we do this via apt pinning since for whatever reasons someone at the Pi Foundation decided last year to cut off all their Jessie users from future kernel updates, weakening the security of all these installations). But if you're not running OMV (where OMV releases are bound to the underlying Debian release -- OMV 3 needs Jessie and OMV 4 simply wasn't ready last year) then why not using Stretch anyway? Raspbian isn't bad, it's just somewhat bloated.
 
As usual the 2 most important things you can do to improve general RPi performance/responsiveness is
Checking whether your powering is sufficient, you need to call perl -e "printf \"%19b\n\", $(vcgencmd get_throttled | -f2 -d=)" and have a look at the left whether there is a '1' (explanation). If you see there a 1 you're running 'frequency capped' at 600 MHz when performance would be needed. You must call vcgencmd since the usual ways to query CPU clockspeed are all fake (don't tell it over at the RPi forum -- for this you will get censored and banned  ) Throwing away your old and slow SD card and start with a new, genuine and A1 rated SD card of at least 16 GB in size (I would go with an A1 Extreme and not an A1 Ultra for the simple reason that most probably RPi folks with their next 'incremental Pi update' next year will finally implement SDR104 to speed up SD card access. This and better Wi-Fi is almost all they've left to once again sell their fanboys an 'improvement') Please note that both 'performance tweaks' are hardware and not software fixes.

https://asciinema.org/a/Goj9aUPvgpGk6YCx97Lqj3XwV
 
 

@balbes150 et al... maybe this is useful?
https://github.com/trustfarm/orangepi-zero-tfarm/tree/master/OrangePi-Kernel/linux-3.4/drivers/net/wireless/ssv6xxx
 
 

Perhaps someone will be interested-a new version of Volumio 0.7_20180325  for S9xxx. It has audio output via a standard HDMI output. To use this feature, you must use one of two dtb files. For VIM1 (S 905 X) - "kvim_android.dtb" for the VIM2 (S912) - "kvim2_android.dtb". For those who use other dtb files, please write the names of the dtb files that you use. They need to make a number of changes to make them earned HDMI output.
 
https://yadi.sk/d/xbesnjYG3PETk5
 
details
 
https://volumio.org/forum/volumio-for-box-amlogic-s905-s905x-s912-s802-s812-t8028.html

Which 'outsourcing'? Allwinner sells hardware. Cheap hardware for special markets. Android tablets back then, $something in between, now smart speakers, dashcams, retro gaming stuff, again tablets and TV boxes. Nintendo's NES Classic sold 2.3 million units in no time. Using a boring A33 SoC with technology from 5 years ago running a smelly 3.4.39 kernel from 5 years ago. Their customers (that's not us) do not care so why should Allwinner care so far?
 
They enable device manufacturers to throw out cheap hardware with somewhat working software with ok-ish margins (their main market) or sometimes enable their customers like Nintendo to sell insanely overpriced/overhyped products where again no-one cares about kernel, software or anything else we would be interested in.
 
For Allwinner there's still no 'Linux market'. Though things might change in the future. But unless there's an incentive to mainline their own hardware and submit code upstream (good luck given the BSP code quality) I doubt anything will change soon or at all. But of course I highly appreciate that they now contribute and react in a very responsive way. As @jernej pointed out in the meantime many requests will be answered positively (and I always chuckle seeing wink, the Allwinner guy, directly contributing to linux-sunxi wiki now -- I never thought this would happen)