NicoD

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?

Well, yes, I didn't mention that you need to configure the system with the script first. I'll PM you a link of the preliminary version, though it is almost finished

well we have what you would call a militia parliament.. It's not always that they understand stuff better.. But hey.. data is the new oil.. we might need a few exxon valdez'es or deep water horizons to figure out how this new oil is handled safely..
some other bad jokes..
we don't understand it fully yet but let's build up a cartel (that's some years ago for the real oil)... wherever the pipeline goes.. someone is upset once it's in the environment it needs years until it disappears.. seems that this 'dataset' also contains information of their kids (account-names etc.), maybe this helps them a bit to understand the issue better...
 

 
feeling like grandpa simpson

@NicoD Well, in order to compile ffmpeg with rkmpp support, you need to pass these three configure flags (or their cmake equivalent, if that's what you are using): 
--enable-libdrm --enable-version3 --enable-rkmpp  
Then, make sure your user has access to DRM. It should be enabled out-of-the-box for the default user in Armbian, if you build a current NanoPC-T4 image with the script (not in the one for download). Or you can just try to launch ffplay with sudo.
 
For last, when you launch it try changing the "h264" decoder to the "h264_rkmpp" decoder. Here is a link to a thread in the ffmpeg lists from someone who tried to do something similar: http://ffmpeg.org/pipermail/libav-user/2018-April/011081.html
 
Good luck with that 

AFAIK, ffmpeg can only display rkmpp decoded video through drmprime/gbm. Meaning that it cannot show it windowed in kdenlive.
 
I see more chances of using mpp accelerated decoding in a gstreamer-based video editor, such as pitivi

This thread summarizes the efforts done to get armbian support for the new RockPi 4b.
 

 
Boardspecs (from: https://wiki.radxa.com/Rockpi4/getting_started):
 
Rockchip RK3399 64bit dual channel LPDDR4@3200Mb/s, 1GB/2GB/4GB optioal storage:
eMMC module (optional) uSD card M.2 SSD (M.2 connector supports up to 2T M2 NVME SSD) display:
HDMI 2.0 up to 4k@60 MIPI DSI 2 lanes via FPC connector other features:
3.5mm jack with mic MIPI CSI 2 lanes via FPC connector, support up to 800 MP camera. 802.11 ac wifi Bluetooth 5.0 USB 3.0 OTG X1, hardware switch for host/device switch, upper one USB 3.0 HOST X1, dedicated USB 3.0 channel, lower one USB 2.0 HOST X2 GbE LAN with PoE support (hat required!) 40-pin expansion header USB PD, support USB Type C PD 2.0, 9V/2A, 12V/2A, 15V/2A, 20V/2A. (supports Qualcomm® Quick Charge as well) 85mm x 54mm  
Current support status (and some background):
first dev samples arrived and @martinayotte and @TonyMac32 started to integrate it into the rockchip64 boardfamily. Radxa offers a patched kernel and u-boot based on rockchips out of tree 4.4 kernel and 2017.09 u-boot. The our rockchip64 family is based on @ayufan s u-boot (which is a fork of rockchips) but a simple patch in of raxdas defconfig and the needed devicetree files don't work (it breaks on several parts during compilation related to USB and other stuff I'm still not 100% sure why.. ). So we went for a defconfig and DT file based on the one of the RockPro64 (cause even without patching, those images booted - a lot of stuff didn't work but at least it allowed us to start getting things working).
People related to Radxa forked the buildscript (https://github.com/brian541/build) and I assume that's why they can provide some 'preview' Armbian images on their site. Problem here is that they defined their kernel and their u-boot in a new linuxfamily (https://github.com/brian541/build/blob/master/config/sources/rk3399rockpi4b.conf) we simply can't have another RK3399 boardfamily (we have two, they share the kernels but not u-boot cause some boards have issues with upstream u-boot - we don't want to manage another u-boot fork nor another 4.4 kernel, it's ayufans or upstream).
That's why things may need a bit of time until they work properly on the RockPi.
 
Currently working (rockchip64-dev branch):
GbE
USB
Wifi (but laggy)
SD-Card (seems to be fine now)
HDMI (not committed yet)
 
Currently broken or with issues:
SD-Card has random hangs (probably speed issues)
 
everything else must be expected as broken at the moment. As far as I know nobody is currently working on 4.4 images and it might need some time to bring things up there. So RockPi 4b images must be considered as early wip at the moment and have to be built on your own cause we don't provide images yet.
 
side-note: first patches are also upstream to support the board in mainline kernel (not done by us https://patchwork.kernel.org/patch/10745929/)
 
@martinayotte & @TonyMac32 can you please correct in case I screwed something up in my summary?
 
@Igor or @zador.blood.stained if you think the thread fits better into the 'board bring up' subforum just move it.

That`s a joke. Learn to laugh
Don`t joke about C, that`s serious stuff. (again...)
Greetings

I am there Friday evening - Monday morning. 
 

See you there.  

I plan to attend FOSDEM 2019, anyone else too?

I'm afraid not.  A few have some sort of "marker" to show what they are (a resistor somewhere tied to an ADC, and efuse value, etc), but they are as non-standard as the SoC's themselves.
 
 
A lot of people feel this way, but it would require an agreement on a standard.  SPI flash or an eeprom drive cost some vendors will never sign up for, and create some problems when needing to upgrade the information stored on them (device tree bugs, bootloader fixes, etc)
 
And projects like this one wouldn't have much to do either, the "big guys" would take over and you'd have the same basic options as PC, with others like us and Arch being "alternatives".  That said, there is a versatility of application to SBC's that does not exist with PC.  Few strap a PC to a bench with bare I/O monitoring things, that died with the parallel port.  So I think there will always be room.
 
An FPGA that runs a RISC-V  powerful enough for linux isn't in my budget just yet, but it does look interesting.

That would be ideal, but some of these boards have... peculiarities that cause source code issues (Tinker has some gymnastics around reboot that require some ugly hacking of the sd/emmc driver that can break other RK3288 devices) or userspace issues (manually toggling IO's to reset BT adapters).  In general, though, you'll find that most of our images are the same for the same SoC, just with DTB/boot script differences for each particular layout, it's why on any board bringup you see us just manually swapping DTB's to see if it will work out of the box.

In Libreelec (KODI-18) on Khadas EDGE (RK3399) play all video works. Including HW for 4K and sound.
 
 
p.s. pls test  https://forum.armbian.com/topic/8898-ramblings-and-progress-with-the-rk3399/?do=findComment&comment=68690 
 

You read my mind! I'm brushing up the last stages for the RK3328/3399 multimedia support, and after that I was going to propose to add it to the build script.
 
So my plan is to release the media scripts for those two SoC's in a few days, and after having some feedback from the community integrate the main features into the main build.
 
Edit: I mean including all three RK SoC's: 3288, 3399 and 3328.

You've got an undervoltage before it goes into the board.
I wonder what your USB voltage is?

Heatsink and M.2 Expander Board are out. You can buy them here https://shop.allnetchina.cn/collections/rock-pi-4-accessories?page=2

I built Jock's forked X11 armsoc driver,   Installed and configured the Malie BLOB rpm and configured for X11.
 
Rebooted.
 
I ran glmark2-es2 :
=======================================================
root@nanopct4:~/Desktop# glmark2-es2 --fullscreen
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T860
    GL_VERSION:    OpenGL ES 3.2 v1.r14p0-01rel0-git(966ed26).f44c85cb3d2ceb87e8be88e7592755c3
=======================================================
[build] use-vbo=false: FPS: 11 FrameTime: 90.909 ms
[build] use-vbo=true: FPS: 13 FrameTime: 76.923 ms
=======================================================
                                  glmark2 Score: 12 
=======================================================
 
I checked the Xorg.0.log.. armsock_dri isn't installed.  Isn't that part of the armsoc driver build ?
 
[   732.501] (EE) AIGLX error: dlopen of /usr/lib/aarch64-linux-gnu/dri/armsoc_d
ri.so failed (/usr/lib/aarch64-linux-gnu/dri/armsoc_dri.so: cannot open shared o
bject file: No such file or directory)
 
 
Without armsoc_dri I'm stuck software rendering.
 
If you have armsoc_dri.so can you attach it to this thread ?
 
 
I'm pretty sure I'm getting close to getting hardware acceleration working on my nanopc-t4 

Of course. You need to fix this otherwise everything you do is just a waste of time. And it's under-VOLTAGE and not under-current so as long as you ignore Ohm's law you're getting nowhere. The problem is high resistance and most probably (and as usual) the cable between PSU and device is to blame.

I'm going to test with the current stable armbian image and update this thread when done.
 

Some news:
 
https://wiki.radxa.com/Rockpi4/downloads
 
There is a first Armbian image available.

Yep.. I am using uname -a to get the architecture type.   I get aarch64.
I will rebuild with arm64 and post it.
It should be posted within the hour

We all know there are several shortcomings which causes mess in the config files and prevent simple implementing of more complex scripting. In order to make build system future proof and to cleanup the exception mess, which is virtually everywhere, I decided to start working on a part of the build system. Now the concept works and it is not that far to be mad if idea is bad
 
packages/extras was moved into this, then board support package and (for now) Cubietruck and Tinkerboard hacks from config/sources/ All others have to be implement into packages and their scripts. It's one time job and it will be much easier in the future, with new boards or functions.
 
New board support packages are now broken into unlimited number of packages. Currently there are three main groups and already present logical packages. Most of present are tested and are fully operational. Mostly its copy/past with bug fixed here and there. Perhaps some bugs were made in this process, but in essence system works - for those two boards. Upgrade path is not determined yet - I only focused on packaging and installing. All those packages can be installed from freshly build ones or from the repository. Each package can have their own number and package is rebuild only if number upstream doesn't exists.
 
This RFC includes preliminary merge of @balbes150 TV boxes fork so it's ATM a bit messy. Cubietruck and Tinkerboard images were tested (Bluetooth briefly, audio need to check again), the rest is not prepared and it requires some manual work. I hope someone else, not just the usual suspects, will help doing this.
 
I will slowly move forward and keep it mergeable/synced with upstream.
 
This approach is more or less only a working proposal for changes. IMHO it's better than what we have now but not perfect.

(WIP) Readme with some more details https://github.com/armbian/build/tree/tvboxes/config/packages
 
You can try this by adding LIB_TAG="tvboxes"
 
Edit:
 
Skeleton is done, images can be build from this branch ... Most but not all of our current families and board specialities has been moved under this packaging system. I tested Cubietruck, RockPro, Tinkerboard. At least they works fine - checked for Bluetooth (TB/CB3) and video acceleration on Cubietruck.

TBD: adjust changes in armbian-config regarding desktop (nodm is gone, lightdm only with possible autologin) and kernel switching.

@JMCC Welcome to try adding perhaps Tinkerboard MM script as a new multimedia/something package. What shall be its name? If some 3rd party packages needs to be placed to the repository, put them here: https://github.com/armbian/upload
 
@gprovost mvebu family is not there yet, but if you got time it should be clear what to do? If not, I wrote lousy docs or scripting is more complicated as before  
 
@selfbg Added Olimex SOM204. Check when possible.

@zador.blood.stained Are packages relations alright? I hope they are future proof. Upgrade is planned from armbian-config and is actually optional. Older packages, except boot and kernel are no more.
 
@tkaiser cpufreq is not overwriting anymore, serial consoles are board property SERIALCON="ttyS0,ttyGS0", board config is reloaded right before packages building. Shell we move hardware-optimisations.sh to per board script? Changes should not affect OMV.
 
@Staars Z28Pro merged but untested
 
@lanefu @5kft @TonyMac32 .... check.

@balbes150 have a lot of work to move his scripting into the build engine. Helping him, testing, fixing, ... @all Check and join if you can.
 
beta.armbian.com can be switched to this new world order ASAP.

Expected merge due: 2/2019 ?

Happy 19!

Edit by lanefu 7/2019:

A project #1 has been created on github.   There are several tasks, which will be tracked as issues on the board.

I made a custom Plex Media Player build that leverages the decent performance we get with the fbdev/dri driver.
I tested Rockchip MPP gstreamer plugin.   The Rockchip Hardware VPU is very basic, it breaks with mkv playback, so I decided to use ffmpeg software decoding since it's extremely robust. Also 1080p playback through DRI isn't too shabby!.  If you want 4k video then you need to contact Rockchip.   They seem to be overwhelmed or not interested in bringing 4k support to Linux.   I built a .deb package that will install plexmediaplayer to /usr/local.  No worries about installing to somewhere and clobbering an official library or package.    Official Armbian dependencies will be installed to the proper location.  The plexmedia web-client will be installed to /usr/local/share/plexmediaplayer, the Qt5 binary will be installed to /usr/local/bin/plexmediaplayer
 
install with:
gdebi plex-media-player-install.deb
 
remove with:
apt-get remove plex-media-player-installer
 
To fix the installer package I basically reflashed my NanoPC-T4 with a clean Armbian image,  printed out the errors.
Updated the Debian control file with all the proper dependencies.  
 
Here's the binary install package.  
 
 
 
If you get a dependency error you can use the --ignore-depends dpkg argument and resolve after the install.
The files are installed in an easy location to clean up. 
plex-media-player-install.deb