TonyMac32

For GbE, I have been playing with the delays, but no, so far no setting appears to be more stable than any other, so I'm not certain it is delay-related, and performance degrades quickly as you deviate from the pre-set delays.

Sent from my Pixel using Tapatalk

If no one has any real complaints, I plan to merge the new kernel/config tomorrow.  I've created a pull request in the meantime for discussion.

As I said before, I tested thoroughly 3D and video acceleration, and both work. Only that /dev/mali0 has permissions "600" by default, so you need to do a "chmod 666 /dev/mali0" in order to use 3D accel as a regular user. Permissions of /dev/vpu-service and /dev/hevc-service (video accel) are OK.
 
I tested in both Ubuntu and Debian images. I managed to compile the Glamor-enabled X server for ubuntu, as well as some other driver for armsoc chip, which also has 3D acceleration. Performance is very good in 3D, not so good in video. Full video HW acceleration, though, requires a special gstreamer plugin, which I wasn't able to compile for Ubuntu, but I could test it in Debian. If someone has interest, I could upload the debs and post a little howto.

Quick post just to say that I tested 3D and video accel, and it works. I'll post more on it later, when Igor's issue is solved.

Gaze longingly at it's many ports and connectors.

While they still don't cooperate with open source community as good as Rockchip, they at least are more cooperative. I asked for HDMI/DE2/DE3 documents and received all of them. Someone else asked about AC200 doc and also receive it. Or better said, they were uploaded to linux-sunxi.org. I would say that is a very good improvement.

I've just installed your debs on stretch, ran into a minor hiccup, but otherwise it seems to run fine - log http://ix.io/F88
 
HTH
 

Free Electrons (now Bootlin ;/) have launched a Kickstarter to get the work on the Allwinner VPU (Video Processing Unit) off the ground again...
 
 
https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel

At $60 that's a definite want.  At $110 you need to show me why I need all those connectors.  

Has the rx/tx delay been tuned on the Tinkerboard? Since we did that for Pine64/Rock64 most of the GbE issues have gone away. Ayufan made an automated script that uses configfs/dt-overlays to iterate through all the values without rebooting each time, based on tkaiser's scripts... 
 
https://github.com/ayufan-rock64/linux-build/tree/master/recipes/gmac-delays-test
 
This resulted in a small patch that did wonders for GbE performance:
 
https://patchwork.kernel.org/patch/10178969/
 
Worked both for BSP and mainline...
 
 

Just in time for FOSDEM some more infos on the new Pine64 H6 and RK3399 boards are available now...
 
https://forum.pine64.org/showthread.php?tid=5614

Hello everyone,
 
    I've begun working to target the Armbian Legacy Tinker Board build to the Rockchip kernel.  There are a list of reasons why it needs done, including some relatively large differences between the current kernel's code base and the Rockchip kernel (making it hard to patch with bugfixes/etc) and inactivity on the part of the vendor of that kernel.  There are also reasons I am preferring to use the Rockchip kernel rather than the ASUS kernel.  First and formost is the need to also support the MiQi.  The miniarm branch of Rockchip and the ASUS kernel have board-specific fixes written in such a way as to not be friendly to other boards.  I've decided it would in fact be easier and more reliable to use the Rockchip kernel and apply the needed fixes in the most appropriate way for our project, as we have different needs than a board-specific vendor kernel.
 
This is a build-it-yourself situation.
 
This is a fork of the Armbian build system using the Rockchip kernel source from https://github.com/rockchip-linux/kernel
 
Things that work and are tested:
 
Wireless Bluetooth (via the typical hci attach method) 4k/2k/1080 Raspberry Pi touchscreen Compiles with gcc 7.2.1 [resolved] Mali is somehow only building for Android, "Mali for linux" throws error during build. This has been clarified, I reached out to Rockchip, this kernel config is simply to allow using older drivers with Linux if so desired.  I don't see immediate reason to desire, so good. [resolved] HDMI Blanking out on change from 4K to other resolutions.  Somehow switch to 4k is ok.  Rockchip adjustments to drivers fixed this for my use case, waiting to hear other feedback VPU/Mali tested/a tutorial by @JMCC Things not worked out:
RGA/VPU/etc are untested/unconfigured/incomplete. Not tested 100%, but working (RGA uncertain) Other things I'm sure.  
What is needed are people able to test the kernel and determine if it is able to be rolled out.  The kernel presently used is no longer maintained by the vendor, and split from Rockchip too long ago to be able to patch it appropriately.
 

Usually from Linux this can controlled via sysfs like this (needs to be executed as root):
echo 0 > /sys/block/mmcblk0boot0/force_ro  

My opinion (regarding project aims):
- View Armbian as a base, reasonably minimal OS images. Unfortunately this doesn't work well for targeting inexperienced users, or rather when such users are attracted to the project.
- Explaining "minimal" and "reasonable" to people who don't listen is hard. People expect Kodi to work out of the box on any hardware, expect a perfect desktop performance even on OPi Zero 256MB and expect Mali drivers to magically fix all performance issues.
- Trying to add things to the base image is bad for the project if it can't be fully supported, if it can prevent making project-wide advancements. IMO a lot of things added to the image are not really required but they increase the maintenance efforts. For example for me it would be easier to make a build repository fork and clean it up than try to resolve all possible conflicts with the recently added Realtek wireless drivers (in addition to important device-specific patches) when I decide to upgrade devices that I use to mainline kernel v4.15.
- We still fail to explain what Armbian is. I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config. A lot of support requests are related to upstream packages, a lot of problems are related to kernel/userspace compatibility and people want optional stuff to work perfectly (if it's available in the menu it should work, why not?) while we still have base platform issues. 
- Current web pages and the direction they are changing doesn't help explaining what Armbian is and what level of support can be expected for different images and kernels, unless adding random affiliate links to Amazon should somehow help with this in the long run.
 
The problem here is that "interesting" is subjective. @tkaiser is mostly interested in NAS type boards with high performance and recent enough kernel for using btrfs. Adding ECC RAM to such board multiplies the "interestingness" of a board by 10.
Some people are interested in a generic home NAS device and don't care if its max sequential speed is 40MB/s instead of 400MB/s 100MB/s as long as it is much cheaper.
A lot of people are interested in desktop/multimedia use cases, and here ARM devices in general have a lot of problems unless you are running Android on a well supported device.
Some people bought the cheapest device they could find and expect it to do everything - NAS, desktop, multimedia player, IoT/GPIO stuff, etc.

In the future please read the forum you are posting in, we have an excellent search feature.

Until the build system makes new packages, you can take the https://github.com/armbian/build/blob/master/packages/blobs/meson/u-boot-nanopik2.bin
 
and stuff it into your current SD card.
Make sure your SD card is your SD card or you could wreck your host machine.  <--- don't say I didn't warn you, some assembly required (seriously, don't overwrite your computer's boot sector)
# sudo dd if=fip/u-boot-nanopik2.bin of=/dev/<your SD Card> conv=fsync,notrunc bs=1 count=444 # sudo dd if=fip/u-boot-nanopik2.bin of=/dev/<your SD Card> conv=fsync,notrunc bs=512 skip=1 seek=1 # sync  

The board the K2 is based from, and so the board support package I started with, #defined ram size explicitly as 1 GB.  For the other Amlogic board I have that ram size is detected at boot, so I didn't check on the K2.

Fixed RAM size

I don't know to be honest.  If so, and ARMv8 is a benefit assuming the bonus cores and higher clock speeds don't offset it.  Remember the a53 is not a particularly powerful core, it's a power-saving core.  I would say, as of today for ARMv8 boards I'm familiar with, that Le Potato is more stable/mature, tradeoffs include no USB3, and no Gigabit Ethernet.
 
At risk of angering the benchmark gods, https://magazine.odroid.com/benchmark-results/
 
This is probably full of various holes, however the difference are large enough to demonstrate my point.  I couldn't give you a good answer for which is more powerful for a given workload given just how different they are.  (The C2 uses a quad-core a53 Amlogic SoC) 
 
 

I have a few things I'd like to "babble" about along those lines, however I think it would be best termed "philosophy of application".  In this case there are a few things that may help, such as board config templates (what kernel options/etc are common as possible across all Armbian kernels/etc). 
 
 
I would say "freezing" would be preferable to "dropping".  This project provides more than enough information to recompile kernels and add modules/make small changes/etc, there's no need for any of the devs to pull out a board with a cm of dust on it and risk starting an electrical fire when they plug it in and the capacitors have dried out [dramatization for effect] simply because one guy wants 'x' feature on 'y' board that hasn't been built in 'z' years.
 
Reading over @botfap's post I agree, other than the RPi bits, like with the Tinker Board we'd constantly get the "But the Vendor OS can *insert something a *team* of professionals implemented that you weren't able to do in the 3-4 hours you put into this on an average night when nothing interferes*. Raspbian does everything you should and shouldn't do with one, a similar reality is why I haven't pushed a "community support" package for the Khadas VIM.  All Meson GX/GXL (Amlogic S905(X)) boards are very nearly identical and can be supported very easily as a family, but Khadas already has a pile of fully capable OS images, I have no desire to "compete" with them by pushing a 66% or so capable Armbian branded image.  RPi is the same sort of situation.
 
We have a lack of metrics for what constitutes "ready" or "supported".  Now, some requirements are difficult to make "hard requirements"  But this goes back to the "matrix of what works" I proposed some time ago, if the hard requirements are met, and the board's aggregate support/capability is over let's say 75%, then it could be considered (arbitrary numbers).  I won't pretend to be an impressive developer, but I am in automotive engineering, and my life revolves around gate reviews and processes.
 
 
Keep it secret, keep it safe. 
 
There are, in my mind, two questions that must be asked before supporting anything:
 
What does Armbian bring to the SBC and its users that the Vendor does/can not? This needs to be in "dumb user" terms.  A board for watching cat videos is not an Armbian device. What does the SBC, it's vendor, and its users bring to Armbian that would be a benefit to the community? Will these users contribute?  Will they donate?  Will they spread the good word? Will the vendor contribute resources and will those resources outweigh the support effort for the device? In the case of the Pi, it is a cat video watching, Scratch programming, "ZOMG I AM 1337" type of board.  I think in terms of a beginner Linux doodling machine it's fine.  But it does not have any hardware capabilities that would benefit from Armbian in real terms.  I'm sure the OMV images perform much better than if they weren't Armbian, but how much better is that when the hardware is so bad?  I'm glad OMV and tkaiser were able to squeeze some water from the performance stone that is RPi, but to go that one extra step and have a general-purpose official Armbian-branded image would be stupid I think, the answer to the "Important Questions" would be as follows:
 We can make the Citroen 2CV go 5 km/hr faster, but it is still outrun in a 1978 Diesel Rabbit towing a trailer. The users would bring us exposure (probably bad when we're not as "friendly" (OS or devs) as Raspbian) and they would undoubtedly require more resources in support than we would gain in donations/contributions to continue the work on other boards.  Botfap's situation is quite different, if funding were assured and the customer defined then support is quite different than with an "anybody can download it and complain" model of an open project like this.

Ok !
should be :
 

I have successfully gotten Armbian to boot from a USB flash drive on the Rock64 board.  Followed ayufan's instructions on how to update SPI Flash with his boot code and then wrote the Armbian Rock64 image to a USB flash drive.  All worked as expected. 
 
Thanks to everyone at Armbian for all the great work!

Congratulations!
 
That said, the laws of physics still hold, and you missed providing the relevant information concerning your supply of choice:  The voltage of the supply.  Also, see:
 
That post contains empirical data and observations while running the Tinker Board.   If you wish to continue this discussion, we can do it in the review thread as it is off-topic for this thread.  I would actually recommend that @chwe or another moderator make that move of these last two (or more as deemed prudent) posts to that thread if possible, since we're far off topic of RK3328 vs RK3288 and the power discussion may be enlightening to others. 
 
From that post:
 
Remember that Armbian gives users the flexibility to run off of USB (after booting SD of course), and that use case would be a complete failure without spending some time seeing warnings like those above.  I also am referencing "as packaged" when I discuss the "factory" heat sink, since obviously with fans/etc it will perform better.  I can operate at a continuous 1.5 GHz with 30 second or so "sprints" at 1.6 when it cools slightly at full load, simply by attaching a superior low-cost heat sink, something I would highly recommend to anyone who did not want to suffer immediate and severe throttling (45 to 55% throttling is severe).  Add a fan and it may never throttle under normal use.

http://pcbway.com

I leave for vacation. All the answers after the holidays.