Werner

It should run as your regular user. Can you launch the browser from console (as your regular user), and post here the output?

Armbianmonitor: http://ix.io/260w Armbianmonitor for 5.4.6: http://ix.io/260C
 
 
From switching between 4.19.x and 5.4.x kernels I noticed that the lower cpu frequencies got missing.
It should start at 120MHz like this:
root@horangepione:~# uname -a Linux honeypot2 4.19.84-sunxi #19.11.3 SMP Mon Nov 18 18:39:42 CET 2019 armv7l GNU/Linux root@horangepione:~# cpufreq-info -o minimum CPU frequency - maximum CPU frequency - governor CPU 0 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand CPU 1 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand CPU 2 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand CPU 3 120000 kHz ( 11 %) - 1008000 kHz (100 %) - ondemand Though on 5.4.x the minimum frequency is 480MHz.
 
 
Since the default cpufrequtils file was not there I created one:
cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=120000 MAX_SPEED=1200000 GOVERNOR=ondemand It seems to have an effect because when changing the minimum frequency it clocks up as it should.
 
Frequencies beyond 1.01GHz missing as well but that is a different story...I guess.
 
Cheers
Werner

I think this is the reason for the cap. This is the same in all kernels from 4.19.84 up to 5.5.0-rc2
 
 
Edit: Interesting. On 4.19.35 it is still capped, though more information in dmesg
[ 5.745212] cpu cpu0: Linked as a consumer to regulator.5 [ 5.745277] cpu cpu0: Dropping the link to regulator.5 [ 5.745464] cpu cpu0: Linked as a consumer to regulator.5 [ 5.746315] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746328] cpu cpu0: _opp_add: OPP not supported by regulators (1056000000) [ 5.746436] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746443] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 5.746569] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746579] cpu cpu0: _opp_add: OPP not supported by regulators (1152000000) [ 5.746669] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746676] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 5.746783] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.746790] cpu cpu0: _opp_add: OPP not supported by regulators (1224000000) [ 5.746926] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.746935] cpu cpu0: _opp_add: OPP not supported by regulators (1248000000) [ 5.747030] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.747038] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 5.747155] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 5.747163] cpu cpu0: _opp_add: OPP not supported by regulators (1344000000) [ 5.747290] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 5.747299] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000)  

Wherever you are around the world I wish you all a happy new year!
May 2020 bring all the best for you, your family and your friends. Don't party too hard

Wherever you are around the world I wish you all a happy new year!
May 2020 bring all the best for you, your family and your friends. Don't party too hard

Looking decent.
___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ | | | | |_) | | | | | | '_ \ / _ \ | |_| | __/| | | |_| | | | | __/ \___/|_| |_| \___/|_| |_|\___| Welcome to Armbian Buster with Linux 5.5.0-rc2-sunxi [...] root@honeypot:~# lsmod Module Size Used by wireguard 57344 0  
 
Edit: OPi0+ looking good too.
___ ____ _ _____ ____ _ / _ \| _ \(_) |__ /___ _ __ ___ | _ \| |_ _ ___ | | | | |_) | | / // _ \ '__/ _ \ | |_) | | | | / __| | |_| | __/| | / /| __/ | | (_) | | __/| | |_| \__ \ \___/|_| |_| /____\___|_| \___/ |_| |_|\__,_|___/ Welcome to Armbian buster with Linux 5.5.0-rc2-sunxi64 Though CPU is capped to 1.01GHz while the H5 should work at 1.2GHz.
Found this:
[ 6.037059] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 6.037083] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 6.037167] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 6.037174] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 6.037301] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 6.037309] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 6.037392] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 6.037400] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000) Maybe something missing in the dts?

I did compile with 
./compile.sh EXPERT=yes WIREGUARD=no AUFS=no BUILD_KSRC=no and it did also work for for my non-64Bit-sunxi SBCs OPi Zero, OPi One and my BPi M2 Berry

At this time I have no need for WireGuard.

I've committed the sunxi-dev switch to 5.5.y !
The only patches that I didn't took time to fix, so I've disabled them, are :

 
0128-drm-bridge-extract-some-Analogix-I2C-DP-common-code.patch-disabled 0130-drm-bridge-Add-Analogix-anx6345-support.patch-disabled v3-1-2-si2168-Set-TS-clock-mode-and-frequency.patch-disabled v3-2-2-dvbsky-Add-support-for-MyGica-T230C-v2.patch-disabled But I will try again later ...

Thank you very much, pointing to the "sndbuf/rcvbuf" values was the key. After changing those the throughput showed "normal" values again.
 
Bye

Much better than Kali since Armbian low level support is unprecedentedly better. Build-in 3rd party wireless drivers (Realtek 881xAU, 8188EUS) provides full hacking possibilities, monitor mode and frame injection while the rest are scripts and apps which you install according to your need.
 
Perhaps you should stick to Debian based Armbian since Kali is derived from Debian.
 

This would be the most stupid thing to do. Just use system as is. A lot of knowledge is behind this default setup.

Let me help to translate
 

Old kernel naming doesn't receive updates anymore. You have to do this manual procedure / switch to new naming ... then update goes the usual way. It could be done automatically, but even without it was already insane lots of work most people don't even notice or support. Manual updating is a small price you need to pay.

That is great.  You have a lot of opportunities to learn ... and help. When I started with this project, most of activities were either a blur from the past or something totally new. Persistence is the key.
 
There are lots of tasks, where no Linux know-how is needed, but has to be done. Since most people don't even notice, nobody likes to do them ... I have to do it.
 

its not a trivial problem (i usually get serial consoles working easily) - i tried close to all speeds etc. ... its either that the connectors are not for the serial console (but they really look like: 4 connectors, one is mass, another seems to be vcc and the other two in the middle go directly to the soc chip), there are maybe some electrical components missing to make it work properly or u-boot output is somehow scrambled (never seen something like this so far) ... these are at least my guesses ...
 
best wishes - hexdump

Hi all.
I've made a new video about how to build your own Armbian image with the Armbian build script.
I also show how to set up virtualbox with a Ubuntu 18.04 image.
Here's the video.
Greetings, NicoD

"dialog" tool is missing ...

Not to soon, I need some rest ...

Well, AFAIK hardware encoding is not yet supported with the FOSS Cedrus library, which is the only one you can use in mainline kernels. If you want HW encoding on Allwinner, you would need the old and controversial closed-source CedarX binaries for that. They only work with older 3.4/3.10 kernels. So the reason why your SoC is getting so hot is probably because it is using mere CPU power for software encoding.
 
If you want to do h.264 hardware encoding, your best options are rockchips (rk3288, rk3399 and rk3328, ordered by preference), or Odroid XU4/HC1. All of them can do HW encoding with Armbian, if you use my media packages.
 
Notice that rockchips will use gstreamer, while XU4 will use ffmpeg.

If you follow the link I posted above, you will see at the status matrix that, indeed, encoding is not yet implemented.
 
It has the most standard and easy to implement and use interface, v4l2-m2m
 
XU4, MC1 and HC1 are sold now for less than $50, which I consider cheap considering its power, features and stability. Take into consideration that one of these can do the work of four to six H3 boards, for example. And if you want to build a farm, you can stack several HC1 or MC1, and put a fan on them, which will make them run steadily at maximum frequency.
 
If you still want something cheaper with HW encoding, then you can go for a 1Gb Rock64, but these boards are having lots of stability problems lately.

I answered to your post before reading the link you provided, so yes, it's written, my bad.
I will try to follow that page, so that I can switch to H3 when the encoding part will be available.
 
Regarding the XU4, I know it's plenty powerful, and love to see its eight core working at full speed when compiling... But I have yet to test its encoding abilities, because if it can encode only one 1080p at a time, the ratio power/price won't really interesting.

Anyway, thanks a lot for your crystal clear answer, the definite links, and your patience answering my vague questions.
 

I've just did the commit, hoping not much broken ...
@megi did you plan to merge the Linus Offical Non-RC soon ?

Right ! Due to change of structures in configs and branches, I've to redo testing again before doing my commits. Maybe by the end-of-weekend ...

Most of these images are headless images, to say without desktop environment. One exception is the "desktop" labeled image for the OPi3 which I provide as special request by a user.

If you did not compile it by yourself yet and/or do not want to you can grab a quite recent 5.3.x image for the OPi Zero and some other models through the link in my signature down below.

In the past I did hope that the "minimal-image" would save memory, but I looks to me to have only less included packages.
The "minimal-image" do use also around 60-90MB after bootup, but I dont know if I do need every loaded package.
 
I did wonder about the 60-90MB from armbian when I did see a x86 PC after debian netinstall OR my old trusty Marvell Kirkwood devices
Linux excito-b3 4.19.59-1 #1 Wed Jul 17 14:58:51 EDT 2019 armv5tel GNU/Linux
which do start up with 25-35MB of Memory-usage.

So I did also having a strip-down-script, but I dont know which packages do eat up the additional Ram, because the Excito-B3-image also do use already systemd.
 
With a footprint of 25-35MB even a 256MB device like the OPi R1 is very useable