NicoD

Hi all. As regular I was looking for news about a new Odroid.
Finally the news arrived. The N2 will have the Amlogic S922X with 4xA73(@1.8Ghz) + 2xA53(@1.9Ghz), a Mali-G52 GPU and 4GB DDR4 RAM. Looks very promising. It should quite a bit faster than the RK3399's.
It does have a giant heatsink, so this thing will get very hot I suppose.
https://forum.odroid.com/viewtopic.php?f=176&t=33781&p=245930&hilit=n2#p245930
 

Please let me know what you all think of this. I find it very interesting.
Greetings, NicoD

Maximum Geek
 
Edit:
The Rock64 Revision 3 is the latest version of the company’s mini PC with a Rockchip RK3328  processor.
https://liliputing.com/2019/02/pine64s-single-board-computers-are-getting-2019-upgrades-prices-still-start-at-25.html
 

Hi all.
Last weekend PINE64 was on FOSDEM with many new products.
The PineBook Pro with RK3399.
The new designed PINE H64 with the H6, now with wifi on-board and a small form-factor. That one's comming out next week.
The PinePhone. A prototype of the PinePhone with an A64 SoC and 2GB of RAM.
The PineCam. A multi-funtional network camera.
A new SNES case.
Exciting times to come with all that.
I've made a video about it all. You can see it here.
Greetings, NicoD
 

Yes I have. I like my XU4 for gaming and for rendering. It may be faster than the C2, but it`s not as versitile. I use the C2 as a laptop powered by a power bank and a 7" display. It does everything right.  It`s power efficient, doesn`t overheat, very fast when overclocked to 1.75Ghz and ram to 1104Mhz.
Software is great. Perfect Youtube playback, I used it a lot for video editing and rendering when traveling.
None of the other SBC`s do so well in all these things. While ths also the oldest design.
But the C2 isn`t perfect. It has troubles with a display resolution of 1080p or higher.

My use cases are different of that of most other people. For many high resolutions are more important. Then the C2 isn`t a good choice. It`ll stay my laptop until I find another that is faster, as small and light and doesn`t overheat.
Cheers.

You forget the "root" as first, then "1234" x2, then new password x2, then user name, then password for the user x2, then again user name, then 4x enter and then "y"

I think that's the right order, I don't know why it asks for a phone number and a room number.
Cheers

Me neither
Fortunately, it doesn't ask Social Security Number ...

First I would change and reword the current implementation - use something like "I understand that not providing requested information will reduce the chance to solve my issue" (current one with the possibility of getting banned doesn't correlate with the forum rules), explain why providing armbianmonitor -u info is needed (I checked a few new new threads and they don't have it), deal with old images that try to upload the info to sprunge.us (i.e. by linking an instructions for updating the script without updating the BSP), ideally deal with the possibility that ix.io may stop to provide its free service one day too, etc.
I'll just leave the public download statistics link here. I'm not an expert on hosting prices in EU, but you need to take into account both the storage space and monthly traffic.
Edit: clarification - this is daily stats that don't include torrent traffic.

Yes. In the early days, about linux 4.17 when the first initial support for Allwinner H6 from Armbian came, it was limited to 1,5GHz but I remember a patch for 4.18 which rised the max frequency to 1810MHz and it ran well. I did benchmark without cooling whatsoever and it survived. Over a longer period of time on heavy load I would think about some kind a cooling though,

I think that was never the intention that 'armbian people' only answer to questions.. fist cause there are for sure other smart(er) people here and their contributions are highly appreciated.
Personally I wouldn't participate in such an sub-forum. But I don't spend as much time in armbian when my 'dayjob' doesn't allow it. By paying for support people expect solutions, solutions aren't that easy. If *random hardware feature* doesn't work the pressure should be on the boardvendors side to fix it not on ours. For maintainers spending much more time to keep the project running (e.g. Igor) some sort of a salary might be mandatory and ways to make this possible isn't as easy but I don't think that such a payed supportforum is the way to go.
how about a less radical approach. Just ignore topics which don't provide the needed information? Those really interested in getting their issue heard/solved may get it that there's information missing.
 
challenge accepted. (we shouldn't lose our sense of humor even if it's a dark one )
 
Besides that, I'm fine with stupid questions. Even in the field I'm good in (chemistry) I sometimes have stupid questions.. Happens.. but the way you react when you realize that you asked a stupid question makes the difference.. If you start to complain about support and and come up with "but the users are most important" I'll answer you with a polite form of "Go fu... *have sex with yourself*"... If you look at a forum from an SBC armbian doesn't support you'll see that moderators there have some sort of a scheme for questions they don't want to answer - always ends with: believe us we sold 20 millions boards we know what we're doing..
We've to accept that there are people on forums which don't spend as much time on SBCs to get trivial issues solved on the other side, they've to accept that if they're not willing to invest time to fix things on their own/help us figuring out what's wrong, I'm not willing to waste my time with their issues.
 
 
The first iteration of the new mandatory parts for opening a topic in technical support was a failure:
 
the new version with:
is at least not as harsh anymore.. but as @zador.blood.stained and @martinayotte showed  (https://forum.armbian.com/topic/9400-does-not-see-emmc-after-component-change/) here, there's still room for improvement. Maybe it needs some days/weeks/months until we have a solution which is "more or less" satisfying but I still think setting some pressure to people to provide armbianmonitor in their starter isn't a bad thing. Cause it is annoying to ask always for it and hope that he gets it after you asked for it 10 times..  (and it's also annoying to find different polite forms of the part from the "personal non rational rant" )
 
For me this thread should be merged with "Improve 'Support over Forum' situation" - IMO it belongs to it. If nobody disagrees on that let's move it there.

Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again".
 
For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u".
 
Funny thing is that this thread was created after the addition of the new information collection form, so we may as well make providing armbianmonitor -u output mandatory with 2 exceptions in dedicated subforums - devices without network connection and devices that failed to boot completely.
 
Applying your knowledge and experience while at the same time learning something new is fun, and it can happen when you are talking with a person who at least tries to understand what he is doing and who respects your time by trying to provide requested (and even more than requested) information.
Reading 90% of threads in the "Allwinner H2/H3" section made by people who expect performance and software quality of at least a $200 PC like a J5005 based NUC7 from a $20 board like Orange Pi PC is definitely not fun for me. YMMV.
Unfortunately supporting low end (by price) boards attracts their target audience aka people for whom even the Raspberry Pi is too expensive.

Technical support section is mainly a feedback to improve Armbian as operating system. We can only deal with Armbian images and our tweaks. That's plenty of work and we have to do something about that.

"If you deal with everything you fix nothing"
 
Common issues sections is already on the edge/outside since mainly contains generic Debian/Ubuntu problems, which we don't have intention nor resources to deal with. Armbian specific problems are already enough. I am seriously thinking to move it to less restricted "community" area, where only general restriction apply.
 
More topics in technical support could also mean developers are doing a lousy job in making Armbian. But since overall user base is growing and since we people are lazy by default (I also belong to that tribe), this section also grow. No forum around is happy on opening more topic for the same issue. Over and over again. Technical support questions are specific. They need to contain certain things or they are useless.
 

That was also intendenten. When you are putting a pressure and wasting precious time, you are making a damage and if you are aware of this, a progress was made. For all of us. It's like traffic regulations.
 

Yes, that's all about. All this is just yet another SPAM filter. One out of many that we already use.

After removing the noise from the input-data, I now got quite reasonable RPM values for the Noctua NF A14:
 
RPM per duty_cycle [ns] duty_cycle RPM 180 158 200 476 250 637 300 938 400 1111 500 1200 2000 1251  
Below 180ns the fan stops, above 500ns it doesn't really increase anymore.
 
fan.svg

So the Media Script is finally released:
 

wow.. nice bacteria rick and morty fun  
 

THE MEDIA SCRIPT IS DEPRECATED, IN FAVOR OF THE LEGACY MULTIMEDIA INTEGRATION. PLEASE REFER TO THIS TOPIC:
 
So finally we have the first version of:
The UN-official, UN-supported, etc...
RK3399 MEDIA TESTING SCRIPT
 
This is the first release of the RK3399 media testing script. The script provides a functionality similar to its RK3288 equivalent:
Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 3.2 / OpenCL 1.2 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi. Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple). A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with:  Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.), and a simple Pulseaudio GTK equalizer using LADSPA.  
Here is a more thorough documentation:
 
>>> DOWNLOAD LINK <<<
 
Prerequisites:
You need a fresh Armbian Bionic desktop image with legacy kernel installed.  
Instructions:
Download the file above Untar it: tar xvf media-rk3399_*.txz cd media-script ./media-rk3399.sh  
Notes:
This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
Enjoy!

RK3399 media script released, with full VPU acceleration support:
 

so today we're talking a little bit about the buildscript (likely that those posts will be splitted out into it's own thread to build up a miniseries of tutorials)... I just talk about basics of it. To be honest, I don't know every part of it fully but for detailed questions there are people here which can answer specific parts. For the simplicity we assume that the SoC on the board is a supported one (rk3399 is). A basic overview with tree -L 2 to get a overview:
 
cache: to avoid downloading the sources again and again every time you build an image and saving you time to build images, armbians build-script caches sources (e.g. rootfs, kernel sources, u-boot sources, atf, compilers - out of tree sources can't always be compiled with the newest compiler versions so we also have some older ones) config: basic configuration files for your board, the kernel and sources we use. config --> board: an armbian specific boardconfig file, for the RockPi 4b it looks like the follwowing: # RK3399 hexa core 2G/4GB SoC GBe eMMC USB3 WiFi BOARD_NAME="RockPi-4B" BOARDFAMILY="rockchip64" BOOTCONFIG="rockpi4b-rk3399_defconfig" # MODULES="" MODULES_NEXT="" # KERNEL_TARGET="default,dev" CLI_TARGET="stretch,bionic:default" DESKTOP_TARGET="stretch,bionic:default" CLI_BETA_TARGET="" DESKTOP_BETA_TARGET="" BOARDFAMILY tells you which sources it uses (later more on that).
BOOTCONFIG telly you which xxx_defconfig file in u-boot will be used (maybe something for an u-boot plumber tutorial follow up) Modules is only needed if you've to install special modules to enhance functionality (something for a more detailed tutorial).
KERNEL_TARGET (will be explained in sources), CLI_TARGET (which flavors of Armbian you can build (here we provide only ubuntu bionic and debian stretch for some older kernels we've to provide xenial as well cause they're not able to work properly with stretch or bionic).
DESKTOP_TARGET - same as CLI but with a DESKTOP (e.g. we don't provide DESKTOP images for boards without HDMI etc.). CLI_BETA_TARGET not of interest yet.
 
config --> kernel (the .config file you normally get with make ARCH=arm xxx_defconfig if you compile kernels on your own - our configs differ often from defconfigs provided by kernels often to enhance functionality) config --> sources as you can see, the RockPi4b is part of the rockchip64 family therefore (https://github.com/armbian/build/blob/master/config/sources/rockchip64.conf):   for a beginner, most of this configs here can be ignored cause it needs some knowledge to deal with but a few interesting parts will be explained. It basically describes you which sources we use for ArmTrustedFirmware (part of  all(most?) ARM64 boards during boot. U-boot (before the kernel fires up) and which kernel sources will be used for default (often a BSP Kernel), next (mostly a vanilla kernel) and dev (mostly a kernel close to mainline - for rockchip64 for example this is a kernel based on 4.20). some tweaks needed to build an image (e.g. different SoCs expect the u-boot binary on a clear defined place inside the SD-Card for example here: dd if=$1/uboot.img of=$2 seek=16384 conv=notrunc status=none >/dev/null 2>&1 ) tweaks which are needed to boot up the board (e.g. rockchip needs a few binaries and it depends on which rockchip SoC, (sometimes also ramspecific) you use to boot up a board - rockchip64 is for rk3328 and rk3399 and they use different binaries) some family_tweaks here to enable debug console etc. (boardspecific tweaks are also here with some if statements to keep those changes separated from the others). To do changes here or to create such a file from plain (for a new boardfamily) you might need some more experience but it's worth to have a look at it (especially to check which sources we use). The rest of config is currently not that important.
config-default.conf (shows up after you build an image for the first time): this file will be important but since this post here gets anyways too long I try to explain it in the next days (it deserves to have it's own day)
lib: the build-script is not only one big bash-script it's splittened into different ones. In the beginnings you (hopefully) don't need to change something in them but cause the script isn't everywhere 100% clean (we've to be pragmatic here + different people have different opinions how stuff should be solved) it's worth to try to understand how random part of the script work (needs knowledge in bash and definitively not learned within a few hours - you need some background this grows over time)
output: that's where your kernel config (if you decide for Show a kernel configuration menu before compilation - would also need it's own post), debs (debian packages built during compilation, e.g. needed for sending kernelupgrades via apt upgrade), debug (also something for a further tutorial - you'll have a lot of fun with this folder during development ) images (the finally compiled images if nothing fails) patch (will be explained in the follow up, but that's most of the work devs do here.. - e.g. if we fix something inside a kernel or u-boot etc. a patch is automatically generated this is then moved to the appropriate patch folder and part of the buildscript)
packages:  blobs we've to deliver (e.g. to boot up a board), bsp (board support package - I also call non vanilla kernels bsp kernels, it has similarities but it's not the same - some boards need special configurations, e.g the bananapi r2 which has 5x GbE has here some configuration files to bring up all it's interfaces), tools (never worked with, ask someone else ) extras-buildpkgs for packages we deliver to get the enhanced functionality ( also not needed to understand fully in the beginnings - wouldn't call myself an expert on this part.. )
patch: if you generate a patch for kernel or u-boot and you want that others can use it as well place it here in the right folder, create a pull request to armbian and we'll get it. The structure is 'relatively' simple splitted into kernel, u-boot and atf (you won't patch atf soon.. ) for the kernel then splitted into boardfamily-branch (default,  next & dev - for the rockpi this means rockchip64-default and rockchip64-dev is of interest). For u-boot it's mostly u-boot-boardfamily (sometimes we have two branches for u-boot, e.g. the time we switch from a out of tree u-boot to upstream or we need different u-boot sources. not that often here u-boot-rockchip64-dev is of interest for the RockPi)
userpatch: the same than patches but for stuff you don't submit back to our tree (e.g. you can place your patch there if for whatever reasons it's not accepted by armbian - e.g. if it breaks other boards)
now you got an brief overview how much you'll have to learn until you understand it fully and in the next days I might partly explain how to use it.. If you can't wait reading more.. there you go:
https://forum.armbian.com/topic/6-how-to-build-my-own-image-or-kernel/?page=6&amp;tab=comments#comment-65998
https://forum.armbian.com/topic/7296-bananapi-r2-csc-mt7623-as-new-boardfamily/
 
have fun.

Привет, Балбес.
Do you have got a dtb file for the NanoPi M4 and/or RockPi4B? They've got working Armbian images. But would be cool to be able to use the same image on both boards. 
I wished all images were like this. Then we would not need new images for different boards with simular SoC's.
Can this then also be done with the LibreElec image?
I tried downloading your LibreElec image for the Edge. Got this message 'Произошла ошибка'. I don't have an Edge, but still wanted to let you know.
https://docviewer.yandex.ru/view/0/?*=hmrjCyQfuYVKHUtYSUu1p%2BR66fx7InVybCI6InlhLWRpc2stcHVibGljOi8vdmxhK21JbW9qR0hMNHhKVjc3MzZGSFJFWlIzaVZqS0taK3dUOXJLcVAyYXZNeHdxMnlBYmg4Y0JkNlFqV2RNVHEvSjZicG1SeU9Kb25UM1ZvWG5EYWc9PTovTElCUkVFTEVDLzIwMTgxMjI0L0xpYnJlRUxFQy1SSzMzOTkuYWFyY2g2NC05LjEtZGV2ZWwtMjAxODEyMjQxNDMxNTAtNzljMTBhYi1raGFkYXMtZWRnZS5pbWcuZ3oiLCJ0aXRsZSI6IkxpYnJlRUxFQy1SSzMzOTkuYWFyY2g2NC05LjEtZGV2ZWwtMjAxODEyMjQxNDMxNTAtNzljMTBhYi1raGFkYXMtZWRnZS5pbWcuZ3oiLCJ1aWQiOiIwIiwieXUiOiI2MjI2MjIxNjIxNTQxNTI0MjQwIiwibm9pZnJhbWUiOmZhbHNlLCJ0cyI6MTU0NjEyMDQxMDA0M30%3D
 
Спасибо, привет.

yes and there are good reasons for it.
Linus salary is also partly paid by Microsoft... https://www.linuxfoundation.org/membership/members/
 
it's never too late..   for sure you'll find something else to contribute.

RockPi is ok with vp9 4k60fps, thanks for telling me about it (about RockPi)

I did not had this message (but LongChair's mpv seems to not working with 10bits? on rk3399) so what i did:
cd /home/dante4 && mkdir video && cd video && git clone -b master https://github.com/rockchip-linux/libmali && git clone https://github.com/rockchip-linux/mpp && git clone -b master https://github.com/rockchip-linux/gstreamer-rockchip && git clone https://github.com/rockchip-linux/gstreamer-rockchip-extra && git clone https://github.com/mpv-player/mpv-build cd libmali && cmake CMakeLists.txt && make -j4 && make install && ldconfig LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/include cd ../mpp && cmake -DRKPLATFORM=ON -DHAVE_DRM=ON && make -j6 && make install apt-get update && apt-get upgrade -y && apt-get install -y libqt5opengl5 libqt5qml5 libqt5quick5 libqt5widgets5 libqt5gui5 libqt5core5a qml-module-qtquick2 libqt5multimedia5 libqt5multimedia5-plugins libqt5multimediaquick-p5 qtmultimedia5-examples qtmultimedia5-doc-html pkg-config gcc make git unzip wget xz-utils cmake devscripts equivs build-essential docutils-common mercurial cmake-curses-gui build-essential yasm mercurial cmake cmake-curses-gui build-essential gcc-arm-linux-gnueabi g++-arm-linux-gnueabi texinfo nasm automake pkg-config apt-get install libass-dev apt-get install libfdk-aac-dev fdkaac aac-enc libfdk-aac1 apt-get install autoconf automake build-essential cmake git-core libass-dev libfreetype6-dev libsdl2-dev libtool libva-dev libvdpau-dev libvorbis-dev libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev pkg-config texinfo wget zlib1g-dev yasm libx264-dev libx265-dev libnuma-dev libvpx-dev libfdk-aac-dev libmp3lame-dev libopus-dev mc locate libghc-bzlib-dev and then i configured FFmpeg with this options
PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" +http://forum.loverpi.com/discussion/comment/1426/#Comment_1426
 
with doing this first
where $home/ffmpeg_build is place where folder FFmpeg laying

And SBC vendors - they just look for the best solution to fit their needs and business plan for a certain board...
 
The cost and efforts need to verify/validate ISA conformance are extremely high, as they should be - you look at companies like Intel and AMD, qualification of a chip can take years - and same with ARM folks like Apple and Qualcomm, where they take the ARM ISA and do their own designs - the chips you see on the market now were actually done 3-4 years ago in a cadence of development.
 
And that's millions of euro's/dollars...
 
You look at SoC vendors like Allwinner, Rockchip, Amlogic - they're using IP blocks that have been pre-certified by ARM (and others) with the fabs - so each block has tapeouts for a certain geometry node and process.. Grab the ARM core of choice, the Mali GPU block, wrap it around DesignWare blocks for peripherals for UART's, GPIO, Ethernet, etc... It's like lego's or ikea furniture...
 
And to the CN side - this is all dependencies on foreign IP... whether is ARM, Intel, Imagination Tech (GPU's with PowerVR), MIPS, Oracle (ex-SUN), etc...
 
With RISC-V - that's all out the door - which makes this interesting - going back to CN, there's enough government money at the local and national level to make things happen, and enough research in the academic space, along with the industrial resources to get things done...
 
Remember the CN initiative - "Made in China 2025"
 
I'm just an observer on the industry here - not being political...but it is interesting what the mainland is doing, and worth watching...

that's ok, but what I have found is that UnixBench a good equalizer across different SoC's on these cheap little boards - even though UnixBench is still variable based on the compiler...
 
It runs long enough (a full run can be 28 minutes) to show if thermals are a challenge (for TinkerBoard, absolutely with stock config compared to NanoPI NEO, where the Tinker has a much better architecture (A12) vs. NEO with A7, but the Neo can shed heat faster, and outperform the Tinker in the longer run - heck, even Pi3B+ runs UnixBench faster than Tinker...

Good questions, I've added them. Thanks.

How can SoC vendors help here with support for chips, interfaces, GPU/VPU, network, etc...
The Armbian team has done a lot of development, how receptive has upstream been to accepting changes/pull requests?
What's the best approach for SoC/Board Vendors to get Armbian ported to their board/chipset?
Documentation is key for supporting a chip or board - where are the opportunities for the vendors to improve?