tkaiser

Which doesn't change much wrt the name of Linux kernel modules that provide SMB3 client functionality  
 
Speaking about Linux naming conventions: 'mount_smb' is the deprecated variant of 'mount_cifs' that should be used today. And this most probably originated from the history of SMB/CIFS support in Linux. Two decades ago SMB could've been best described as a pile of rotten protocols that are pretty much useless since Microsoft's implementations differed in almost any detail. Compared to that CIFS was an advancement (read through Linux manual pages -- many of this historical stuff still there). SMB2 and SMB3 have nothing in common with the SMB we know from 2 decades ago. Robust protocols with lots of cool features and specifications worth the name.
 
Anyway: CONFIG_CIFS is not set on just 5 kernel variants (by accident) so @sunxishan please send a PR with them enabled as module.

Latest sbc-bench version 0.6 implements a new 'thermal testing' mode:
root@nanopct4:/home/tk# sbc-bench.sh -h Usage: sbc-bench.sh [-c] [-h] [-m] [-t $degree] [-T $degree] ############################################################################ Use sbc-bench.sh for the following tasks: sbc-bench.sh invoked without arguments runs a standard benchmark sbc-bench.sh -c also executes cpuminer test (NEON/SSE) sbc-bench.sh -h displays this help text sbc-bench.sh -m [$seconds] provides CLI monitoring (5 sec default interval) sbc-bench.sh -t [$degree] runs thermal test waiting to cool down to this value sbc-bench.sh -T [$degree] runs thermal test heating up to this value ############################################################################ root@nanopct4:/home/tk# This mode makes only use of cpuminer and is only useful to measure thermal effects (looking at temperatures, cpufreq statistics and relative performance differences) but provides no general benchmarking functionality other than displaying thermal efficiency of
physical aspects of heat dissipation (heatsink, heatsink + fan, nothing, airflow, enclosure or not, whatever) efficiency of throttling settings (bad settings --> bad performance once throttling occurs) Both -t and -T need an integer value as second argument: e.g. '-t 50' or '-T 70'. In the former case sbc-bench ensures that SoC temperature falls below 50°C prior to starting the test, the latter case will result in the tool heating up to 70°C first and then starting the test.
 
Both modes should be used combined to generate a reproducable environement. E.g.
sbc-bench.sh -T 70 ; sbc-bench.sh -t 50 This will result in a first test heating up the SoC to 70°C, then testing, then let the second run wait to cool down to 50°C before 2nd test starts. This way it's ensured that several tests run under almost identical conditions.
 
If you want to skip pre-heating or waiting for chill down simply use -T with a very low value, e.g. 'sbc-bench -T 20'.
 
As an example comparison of NanoPC-T4 with stock heatsink. 1st test with FriendlyELEC's blue thermal pad between RK3399 and heatsink, 2nd time with the thermal pad replaced by a copper shim with thermal paste (test duration is ~302 seconds).
 

 
 
With thermal pad:
1992 MHz: 100.79 sec 1800 MHz: 0.02 sec 1608 MHz: 0 sec 1416 MHz: 169.13 sec 1200 MHz: 32.26 sec vs. copper shim:
1992 MHz: 136.00 sec 1800 MHz: 0 sec 1608 MHz: 0.02 sec 1416 MHz: 159.06 sec 1200 MHz: 7.19 sec Copper shim + thermal paste performs better but not that much in this mode (somewhat simulating the board being enclosed and idling at around 50°C).
 
And it's also obvious that there's something seriously wrong with our throttling settings since 1800 and 1608 MHz cpufreq OPP are skipped. When those would be used performance in throttling state would be a little bit better. That's what the '-T' switch is about: operating the board under conditions where thermal trip points and such stuff can be tested efficiently.
 

20x20x1mm. Ordered them 18 months ago on Aliexpress for 2 bucks (5 pieces) but the link is dead. Anyway: I don't think such a copper shim is a good solution for end users. Heatsink able to be directly attached to SoC is better.
 
Will try again with my next RK3399 board with thermal glue between heatsink and copper shim and normal thermal paste between shim and SoC. Currently I fear a bit the shim could move when vibrations occur.

Here are results for 800 and 1000:
http://ix.io/1l2a
http://ix.io/1l2n
 
The inferred CPU frequencies are now reasonably consistent with configured u-boot values.  We also have the old OpenSSL
performance back.  So, the bug is in the Linux frequency scaling code.
 
Maybe this helps with reboot issue.

For 4.4 kernel, there's no other issues. Everything else works fine (at least as a headless server. Haven't tried to connect a monitor yet). I may try the Bionic desktop image this weekend.
As for mainline, WiFi and USB 3.0 does not work. lsusb only shows the otg 2.0 root hub.
 
PCIe and MIPI are not tested yet.
 
Yes, AFAIK Rockchip's binary blobs can detect the DDR type and initialize them accordingly. I can see different DRAM initialize log output on T4 and M4, although they use the same rk3399_ddr_800MHz_v1.14.bin file and exactly the same u-boot config.

There's something wrong (DRAM related) when running Rockchip 4.4 kernel, which causes the latency to be twice as much as other RK3399 boards. This causes very poor 7-zip performance, and it takes a long time to run the tinymembench. (~20 minutes both on big and little cores)
However the DRAM is performing normally on mainline kernel (4.19-rc1), and the benchmark numbers are identical to other boards.
 
Mainline kernel benchmark details: http://ix.io/1lzx. I didn't modify the opp table and thermal trip point, and it's limited to 70℃ and 1.8/1.4GHz, so thermal throttling occurs very frequently. Though it's still very powerful running under 1.6/1.4GHz and keeps cool.
 
Edit: Re-run with opp/trip point modified: http://ix.io/1lzP

Hi,
 
I saw you tested your Up board based on atom z8300, so I tested my x5 based on z8350: http://ix.io/1lwg
However, I have only manjaro installed on it and cpufreq is not reported, nor the soc temperature, so maybe this numbers are not relevant for you.
 

M4 (4.4 armbian nightly kernel) w/ the official huge heatsink attached: http://ix.io/1lvP
Ambient temperature is ~29℃
I'll write a full review this weekend.

This is something hopefully suitable to become a 'Board Bring up' thread.
 
The NanoPC T4 was the smallest RK3399 board around featuring full set of interfaces (Rock960 was smaller but there you can't use GbE without a proprietary expander) but in the meantime he got two smaller siblings: NanoPi M4 and the cute NEO4.
 
Pros:
Another RK3399 board so software support is already pretty mature Rich set of interfaces (2 x USB2 without shared bandwidth, 2 x USB3, triple display output and so on) No powering hassles due to 12V (2A) PSU requirement 16GB superfast eMMC 5.1  Usable and performant Wi-Fi (dual band and dual antenna so MIMO can be used, for numbers see here) All 4 PCIe lanes exposed (M.2 M key connector on the bottom, suitable for NVMe SSDs, or to attach a 4 port SATA controller or a PCIe riser card)  
Cons:
A bit pricey (but if you compare with RockPro64 for example and order all Add-Ons you end up with a similar price) High idle consumption (4W PSU included in idle), maybe this is just bad settings we can improve over time heatsink too small for continous loads  
I started relying on @hjc's work since he's currently using different kernels than we use on RockPro64 or ODROID-N1 (though all the 4.4 kernels are more or less just RK's 4.4 LTS branch with some modifications, with mainline I didn't had a look what's different in Heiko's tree and 'true' mainline).
 
Tinymembench numbers with RK 4.4 vs. mainline kernel (the latter both showing lower latency and higher bandwidth).
 
Internal 16 GB eMMC performance:
eMMC / ext4 / iozone random random kB reclen write rewrite read reread read write 102400 4 23400 28554 26356 26143 27061 29546 102400 16 48364 48810 85421 85847 84017 47607 102400 512 48789 49075 273380 275699 258495 47858 102400 1024 48939 49053 290198 291462 270699 48099 102400 16384 48673 49050 295690 295705 294706 48966 1024000 16384 49243 49238 298010 298443 299018 49255 That's what's to be expected with 16 GB and exactly same numbers as I generated on ODROID-N1 with 16 GB size. When checking SD card performance it maxed out at 23.5 MB/s which is an indication that no higher speed modes are enabled (and according to schematics not possible since not able to switch to 1.8V here -- I didn't try to adjust DT like with ODROID-N1 where SDR104 mode is possible which led to some nice speed improvements when using a fast card -- see here and there)
 
Quick USB3 performance test via the USB-3A port:
Rockchip 4.4.132 random random kB reclen write rewrite read reread read write 102400 4 24818 29815 33896 34016 24308 28656 102400 16 79104 90640 107607 108892 80643 89896 102400 512 286583 288045 285021 293431 285016 298604 102400 1024 315033 322207 320545 330923 320888 327650 102400 16384 358314 353818 371869 384292 383404 354743 1024000 16384 378748 381709 383865 384704 384113 381574 mmind 4.17.0-rc6-firefly random random kB reclen write rewrite read reread read write 102400 4 37532 42871 22224 21533 21483 39841 102400 16 86016 104508 87895 87253 84424 102194 102400 512 274257 294262 287394 296589 287757 304003 102400 1024 294051 312527 317703 323938 323353 325371 102400 16384 296354 340272 336480 352221 339591 340985 1024000 16384 367949 189404 328094 330342 328136 139675 This was with an ASM1153 enclosure which shows slightly lower numbers than my usual JMS567 (all currently busy with other stuff). Performance with RK 4.4 kernel as expected, with mainline lower for whatever reasons. I also tried to test with my VIA VL716 enclosure directly attached to the USB-C port but ran into similar issues as with RockPro64 but since my enclosure and the cable also show problems when using at a MacBook Pro I suspect I should blame the hardware here and not USB-C PHY problems with RK3399.
 
This is NanoPC T4 with vendor's heatsink, lying flat on a surface that allows for some airflow below, running cpuburn-a53 on all 6 cores after half an hour:
13:57:31: 1008/1416MHz 8.44 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:40: 1008/1416MHz 8.52 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:48: 1008/1416MHz 8.51 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:57: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 90.6°C 0/5 13:58:05: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 91.1°C 0/5 So with heavy workloads you most probably need a fan to prevent throttling. 
 
Development related questions: IMO we should try to rely on single sources for all the various RK3399 boards that are now available or will be soon. And I would prefer ayufan's since he's somewhat in contact with RK guys and there's a lot of great information/feeback provided by TL Lim. What do others think?
 
Also an issue is IRQ affinity since on boards where PCIe is in use those interrupts should clearly end up on one of the big cores while on other boards USB3 and network IRQs are better candidates. I already talked about this with @Xalius ages ago and most probably the best idea is to switch from static IRQ affinity set at boot by armbian-hardware-optimization to a daemon that analyzes IRQ situation every minute and adopts then dynamically the best strategy.
 
Wrt information for endusers. All RK3399 boards basically behave the same since the relevant stuff is inside the SoC. There's only different DRAM (matters with regard to consumption and performance), different interfaces exposed and different power circuitry (and obviously different settings like e.g. cpufreq behaviour but I think we should consolidate those for all RK3399 boards). So you already find a lot of information in my ODROID-N1 'review', my SBC storage performance overview and most probably also a lot around RockPro64. No idea where to inform about RK3399 GPU/VPU stuff since not interested in these areas at all (hope others add references or direct information).

@tkaiser I've managed to boot 4.18 kernel on Firefly RK3399 (those problems on 4.17 seems gone), and ran sbc-bench after editing the dts in the same way (set trip point to 85℃, OC to 2.2/1.8GHz), results are here: http://ix.io/1lmN.

Just to have some sort of comparison to x86 based SBC I benchmarked my UP Board (lying in the drawer for years) right now:
 
As can be seen the Intel Atom x5-Z8300 CPU will be outperformed by an RK3399 or even an el cheapo NanoPi Fire3 pretty easily: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
 
Onboard eMMC performance (16GB on my model) also not that impressive (random IO ok, but sequential write performance below SD card level at just ~20 MB/s):
Internal 32 GB eMMC random random kB reclen write rewrite read reread read write 102400 4 2959 3431 16319 16706 11944 3400 102400 16 6710 6162 23026 23813 21143 6775 102400 512 15525 20512 100141 97841 98877 20622 102400 1024 20925 21024 102145 105088 100305 17150 102400 16384 20425 20749 106923 107996 108337 20844 1024000 16384 18512 19994 106359 106060 103988 20007 I backed this board in the beginning to check it with NAS usage in mind but never managed to attach fast storage since UP Board (just like LeMaker's Guitar back then) uses the crappy Micro-B USB3 receptacle (designed for OTG/device and not host mode -- you need an UEFI update and a special cable to be able to attach USB3 SuperSpeed peripherals to this board).
 
BTW: kernel situation as crappy as with a lot of ARM boards (or maybe the board now fully works also with mainline kernel -- I don't know). At least the official kernel enabling majority of board features is a 4.9.45 that received zero fixes for over a year now: https://github.com/emutex/ubilinux-kernel

LOL! Yeah, asking the SoC vendor constantly cheating on users... haha, no, my simple approach is to stay away from everything where's Amlogic printed on!  

Just a little bit list, more detail would be done on wiki soon.
1. NEO4 board size is 45 x 56mm, but M4 is 85 x 56mm
2. NEO4 has 1GB DDR3 RAM with single chanel, But M4 has two version 2GB DDR3 RAM/4G LPDDR3 RAM with Dual Chanel.
3. NEO4  will use AP6212 wireless module with single antenna , but M4 use AP6356S dual-band module, and use 2x2 MIMO and 2 real antennas. 
4. NEO4 has one MIPI-CSI, M4 has two MIPI-CSI
5. NEO4 has USB3.0  x1 & USB 2.0  x1, but M4 has USB 3.0 x4 behind a VL817 internal hub.
6. NEO4 use 1.27mm pitch SMD connector for GPIO-40 pinout,  M4 is same with RPi3 40pin GPIO.
 
Both have:
1. PCIe x2 pin-out
2. eMMC module connector
3. GigE port.
4. TypeC is for power supply and OTG.
5. HDMI-A & MicroSD slot.
6. Big CNC heat sink, with two side 1/4 screw hole

Please see
 
It seems writing something to /etc/resolvconf/resolv.conf.d/head at image creation time creates this issue and removing the file should solve it. @Igor wanted to look into but no idea what happened.
 
IMO neither using Google's DNS nor Cloudflare's is a brilliant idea and we should really change this so user's local config always wins. Details: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/
 

That is not a problem. How about this way:
 
RK3288 -> rockchip with whatever source, ayugan if there will be not much hassle
RK3399 (RockPRO) and RK3328 (Rock64) ->  rockchip64 (ayufan source)
RK3399 (FriednlyARM) remains RK3399 (fa source) ... we postponed this merge for the future

Are you kidding?
 
https://www.google.com/search?rls=en&q=Micro-USB_1_01.pdf
 
This is the relevant specification for WHAT YOUR USERS HAVE AT HOME. The connector is rated for 1.8A max, 99.99% of cables are made for 500mA max.
 
That is the REALITY OUT THERE if you throw an electronics device on the market equipped with this crappy Micro USB connector. It encourages users to use common Micro USB gear which simply WILL FAIL with the Tinkerboard since not made for higher currents than a few hundred mA.
 
USB PD (power delivery) specs in the meantime defined NEW specifications so with both NEW receptacles and NEW cables 3A are possible with Micro USB. The USB PD specs (see here for an overview) while now defining NEW Micro USB connections (needing NEW receptacles, jacks and cables!) do of course not define any PD profile that uses 3A at 5V. Why? Since VOLTAGE DROP. Ohm's law still exists. The lower the voltage, the higher the drop.
 
The USB PD specs define Micro USB carrying 3A with NEW Micro USB connectors and NEW cables only at 12V (Profile 3) or 20V (Profile 4). And the reason is once again called VOLTAGE DROP.
 
If you put a Micro USB receptacle on your product to power your board you do two things at the same time:
Encourage users to use the Micro USB gear that's already lying around (crappy phone chargers, average cables not suitable for more than 500mA). You introduce underpowering hassles Encourage users to make the wrong calculation since they think they won't need a new and special PSU if they already have a charger or an USB PSU lying around. You try to create the impression your product would be cheaper than it is (since always needing a SPECIAL Micro USB PSU which is additional costs) By using Micro USB board makers trick their customers into believing they could re-use existing PSUs so the board appears to be a less expensive buy compared to honestly stating that while the board uses a pretty common connector it's incompatible to 99.99% of all Micro USB gear that consumers already have.
 
And the whole sh*t show started over at the RPi. If they would've started with a sane barrel plug this whole mess wouldn't exist. Since then those other board makers who copied the crappy Micro USB connector would now copy this barrel plug instead to advertise their '1:1 replacement for the RPi'.
 
Since having the same moronic discussion with the RPi fanclub some while ago: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=208192&start=50#p1292499 (just a quick check how many different Micro USB connectors at which amperage rating a company like RS sells. If you read through the whole thread please keep in mind that RPi forum moderators act as censors. They partially edited my posts and banned my account as a result of frequent mentions of competitor's products. But that's normal over there)

This just works (on RockPro64 -- I did the testing already of course):
 

One of the Banana Pi employees took @zador.blood.stained's work, added a Windows GUI and extended SoC support from H3 only to A64, A83T and even H5: http://forum.banana-pi.org/t/the-3rd-party-emmc-flash-tool-for-bpi/4080

Tried a fix with https://github.com/armbian/build/commit/f10acc0080825faf711eb6e6b7425910d75d840c
 
Would be great if you could try next nightly version and report back.

Well, FFmpeg's RKMPP support includes only decoding so far, so not many chances that Plex/Emby will support accelerated encoding for RK3399 anytime soon. Gstreamer should be pretty well supported, in theory just as RK3288, but I haven't tested it. Now I'm returning to SBC's after some weeks, so I'll make sure to test video encoding when I do the RK3399 media script, God willing.

I hope you added the heatsink?
 
My take on 'enclosure' is all those boards landing in a drawer. Since most recent boards generate more and more heat I'm thinking about adding 2 large and silent fans + dust filters in a similar way as shown here: https://forum.openmediavault.org/index.php/Thread/18962

Ok, so it's confirmed:
 
Powering also possible through pins 2 and 4 so since the SoC is at the right side and heat dissipation is no problem @mindee could evaluate a 'SATA HAT' using the 2 PCIe lanes, a Marvell 88SE9235 SATA controller (x2 PCIe to host, 4 x SATA 3.0 to disks) and power circuitry with 12V input able to feed board and 4 x 3.5" disks.
 
If I understood correctly RK3399's VPU capabilities make it interesting as transcoding NAS (once video support is ready in Linux, though no idea how far things are. @JMCC do you know about the state of video transcoding with RK3399?)

I thought they were two different names for the same upcoming board, with various intermediary designs. But you're right, the NEO4 is even smaller than the M4! So yes that makes sense, it's a single channel RAM. Then I think I'm more interested in the M4. However if they made a complete aluminum enclosure like they recently did with the NEO/NEO2 with the buttons and OLED, it could be very tempting to get one as well for about everything you can do with a machine lying in your computer bag!

Mikey from Sinovoip showed me some photos on kernel logs that is said to be booting A40i with mainline U-Boot.
 
(Of course this makes no difference as mainline U-Boot doesn't try to recognize the print on the chip ;-) )

OK - I have requested the boot log:

Guido Imran Lehwalder:
Lion Wang If you got an example of the board with A40i would it be possible to get a bootlog of armbian with kernel 4.18.y from this A40i device?
This would much help for working on armbian for the A40i version of the board ;)
And maybe if you logged in in armbian also a the info from:
armbianmonior -u

Lion Wang:
Guido Imran Lehwalder Ok ,i will let my R&D ( Research and development ) do this work ,thank you.
i see armbian have a beta image for Ultra and berry .
 
I also doubled the request in their forum.