tkaiser

Yep, this looks nice and sufficient. I still don't get how the board is powered (is this USB-C compliant powering with circuitry that can cope with both 5V and 12V -- same with PoE and 12V) but doesn't matter that much yet. I assume we'll get info when available. BTW: For other readers IMO important your comment about PCIe Mezzanine board and PCIe attached SATA (not 'native' ): https://www.cnx-software.com/2018/06/24/odroid-n1-canceled-due-to-ram-supply-issues-odroid-n2-coming-later-this-year/#comment-554498

Compared to microUSB, I still think it will... Again: http://forum.khadas.com/t/power-supply-suggestions/1221 If board makers use now an USB-C receptacle without being USB-C compliant then this is what happens: Good and standards compliant USB-C chargers won't work or will show stability issues under load. These standards compliant USB-C chargers will refuse to provide to 'dumb devices' more than 'Default USB power' (which is 500mA at 5V with USB2 and 900mA at 5V with USB3: so those chargers will provide up to 4.5W or maybe only just 2.5W). How to overcome this limitation? Use also a dumb PSU with an USB-C connector like Khadas does (2A at 5V -- already a bit on the low side). Is this better than a barrel plug? No. While the above 'dumb USB-C' misuse at 5V won't cause any harm it gets interesting once board makers start to repeat the game with 12V: again putting only an USB-C receptable on the board while not being fully USB-C compliant (would require USB PD and support for at least profile 3), selling also a 12V USB-C PSU to be combined with the board. Won't cause harm on the board but might fry other devices with USB-C receptacle that expect 5V only. USB-C is a rather complex specification and wrt powering requires that both current and voltage will be negotiated between both ends of the cable (even roles should be negotiated!). Making one side dumb is asking for troubles

Thanks a bunch for this explanation, Kever. I think it pretty much explains a lot of the annoyances developers ran into. Also thank you for your other explanation and suggestions. Though I'm a bit disappointed about lack of other developer responses. Anyway, to get back on (our) topic. We have the following 'BSP' branches for RK3399 boards right now: RK's own: https://github.com/rockchip-linux/kernel/tree/release-4.4 Firefly's repo for their RK boards: https://gitlab.com/TeeFirefly/linux-kernel/ (If I understood @hjc correctly also based on an older RK 4.4 kernel?) Hardkernel's for their canceled ODROID N1: https://github.com/hardkernel/linux/tree/odroidn1-4.4.y (AFAIK a fork of RK's 4.4 but rebased on 4.4 kernel.org version) ayufan's: https://github.com/ayufan-rock64/linux-kernel/tree/release-4.4 (forked and rebased from RK's 4.4 recently) FriendlyELEC's for NanoPC T4/NaniPi M4: https://github.com/friendlyarm/kernel-rockchip/tree/nanopi4-linux-v4.4.y (older fork from RK's 4.4 with some device specific additions for now) What else? With mainline we have: true mainline Heiko's branch: https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git Heinrich Schuchardt's Firefly RK3399 repo: https://github.com/xypron/kernel-firefly-rk3399 Ayufan said he would be happy to open up his repo for other contributors: http://irc.pine64.uk/?date=2018-06-21 08:03:47 (change the channel to #Rock64 via the menu). TL Lim also added he is for unifying development efforts (stopping developers from wasting their time reinventing the wheel over and over again). Is this addressing your concerns @JMCC? So how to proceed? To me it seems possible to use one single BSP kernel for all three RK 'open source SoCs' but I'm not into any details at all.

BTW: For anyone thinking USB-C would make life easier and powering more reliable... please think about that USB-C compliance is a different thing than what we already get on SBCs and will see in the future. As an example the 'famous' Vim2 using an USB-C receptacle to be powered while not being USB-C compliant: http://forum.khadas.com/t/power-supply-suggestions/1221

And... already canceled: https://www.cnx-software.com/2018/06/24/odroid-n1-canceled-due-to-ram-supply-issues-odroid-n2-coming-later-this-year/ So looking back playing around with early N1 development samples served the purpose to generate some RK3399 specific numbers that are valid for all other RK3399 designs as well

Same with your ROC-RK3399-PC (Renegade Elite): https://libre.computer/products/boards/roc-rk3399-pc/ How do you plan to solve heat dissipation there? And do I get it right that the USB-C in the upper left corner is meant as a generic 12V input?

No need for a full aluminium enclosure (to rip-off clueless users as today with FLIRC case and others). Just a thin thermal pad combined with an aluminium bottom plate combined with an enclosure top made out of plastic, wood or whatever is all that's needed: https://forum.armbian.com/topic/6794-pi-factor-cases/?do=findComment&comment=51529

Well... by looking at the (closed) pull request it becomes even more obvious that the RK people owning this github repo don't have an idea how to deal with the world outside. They don't care about the state of this kernel tree breaking stuff most probably since their internal work style is totally different from ours. I would continue to discuss this stuff here since i sent Kever Yang only a link to this thread right now...

I don't think this group of Rockchip engineers working in these github repos is aware what's happening outside (various open source communities using their kernel sources for a bunch of RK devices). Yesterday I dropped a quick note to Kever Yang (AFAIK he's in charge of some of RK's open source activitities) but got no answer yet. Edit: got an answer almost immediately, just found it in another inbox now. Let's wait and see

Just for the record: this package (a simple script in reality) installs and works pretty well in Debian too so it should be purged anywhere as part of an upgrade mechanism.

Not only you tested it but thousands of OpenMediaVault users (the majority on the Raspberry Pi) since I did exactly the same in our OMV images for ARM boards. But this is not the recommended way any more, lz4 for whatever reasons performs not greater than lzo but it would be great if you can join testing efforts.

If there are 4 USB3 receptacles (either provided by an internal USB3 hub or with an own PCIe attached USB host controller) then USB consumers alone might take 18W (each USB3 port has to provide 900mA at 5V). With 2 x USB2 and 2 x USB3 it's only slightly better: 14W max by USB consumers. And the board needs some juice for its own so we're talking about 25-30W input requirements. Unfortunately USB-C ports still have to provide only 900mA, the two more powerful USB-C 5V modes with 1.5A and 3A are optional (and insufficient too since only providing 7.5W or 15W). So without an USB-C charger capable of USB PD (power delivery specs) and supporting at least profile 3 (36W when switching to 12 V at 3A) USB-C isn't an advantage over a barrel plug. And it would also require NanoPi M4 being compliant to USB PD and able to cope with changing input voltages. In other words: curious how powering will look like here... Will we see a 'dumb' 12V PSU with USB-C jack that is not USB PD compliant ready to fry normal USB-C devices?

SoC on the appropriate PCB side (to be combined with a metal enclosure/baseplate efficiently dissipating the heat out of the enclosure)! This looks really nice. I would suspect we get 2 x USB3-A, 2 x USB2, Gigabit Ethernet but no PCIe and all the camera/display connectors? Not the same size. The Rock960 is 96boards compliant (the SBC standard without connectivity ) Please merge all the M4 stuff into a new 'NanoPI M4' thread.

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).

My 2 cents on this at the bottom of the list: https://github.com/armbian/build/pull/1015 Can't really test/review at the moment since running out of spare time. My only other 'Armbian contribution' this week will be a little bit NanoPC T4 testing (relying on @hjc's work).

You should keep in mind that your SSD wants (and gets on Intel) PCIe Gen3 ('LnkCap: Port #0, Speed 8GT/s, Width x4') and that RK's 4.4 kernel allows for PCIe power management (defaulting to 'powersave'). I would assume retesting with adjusted /sys/module/pcie_aspm/parameters/policy sysfs node won't change results with larger blocksizes and that's most probably since your SSD wants Gen3 link speed to perform great (seen this several times in reviews that even if the theoretical max bandwidth of a Gen2 x4 link would be more than sufficient the same SSD performs faster on a Gen3 x2 link which would allow for the same transfer rates)

In the meantime I ordered an USB-C drive enclosure based on VIA VL716. A quick check with lsusb shows 'Bus 008 Device 002: ID 2109:0715 VIA Labs, Inc.' (that's the same product ID as VIA's VL715 which is basically the same chip as the VL716 but the latter contains the USB-C stuff). My first test was disappointing since performance looked like USB2 and a quick 'lsusb -t' confirmed. The enclosure only established a Hi-Speed but no SuperSpeed connection. After replugging the cable it worked one time but then I got connection issues (that looked like UAS software troubles as usual in the logs). Now after a reboot it looks like this: random random kB reclen write rewrite read reread read write 102400 4 15833 21863 24630 24740 15728 17119 102400 16 41332 57594 63793 63974 53032 57263 102400 512 236008 246826 232867 238458 231778 231332 102400 1024 282755 296478 280089 282768 279200 295004 102400 16384 377360 377555 388708 396527 395120 383106 Well, numbers look ok but I've to admit that USB storage kinda sucks. 'Armbianmonitor -u' output: http://ix.io/1dbY

You need to adjust DT on your NanoPC since the device claims to be only capable of PCIe Gen1. Please see also https://patchwork.kernel.org/patch/9345861/ @FrankM: Would be interesting to test on your RockPro64 with link speed set to 1 and see whether now a x4 link will be established: https://github.com/ayufan-rock64/linux-kernel/blob/65dce4f6760180105cda50d6f8d603e25eaf26fc/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts#L260

Yes, tkaiser has tested this already. On another RK3399 device: https://forum.armbian.com/topic/6496-odroid-n1-not-a-review-yet/?do=findComment&comment=49400 And here you find a general storage performance overview also covering RK3399 devices: https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=51350 ODROID-N1 in my tests was also running RK's 4.4 kernel, they use the same ASM1061 controller Pine folks sell as Add-On card, the only other performance relevant parameters are CPU clockspeeds (these are simple tunables in the device tree to let the CPU cores clock slightly higher) DRAM initialization/parameters (we should get a slight speed improve on RockPro64 in the future once LPDDR4 memory uses optimized settings) Settings (e.g. PCIe power management active or not -- see the ODROID N1 thread above) So everything is already known. :-)

I've seen x4 so far only with mainline (4.16 back then): https://gist.github.com/kgoger/4a6a363d2999e512cd057148404a29dc (this is on Theobroma's Q7-RK3399 -- maybe different trace routing is also important?)

Like all of those list it's not worth to visit them since they're full of mistakes. That's only for people who are impressed by vast amounts of data and don't give a sh*t about information (data != information). 3 examples after looking for ONE MINUTE into this BS collection: Banana Pi M2 Berry is listed with 4 USB ports while this board in reality just uses one USB host port to provide 4 USB receptacles (shared bandwidth due to internal USB hub). Banana Pi M2 Ultra is also listed with 4 USB ports which is BS since this board has 2 USB receptacles (+ 1 x Micro USB OTG port) and at least exposes all of the USB host ports CubieBoard6/7 is listed as one entry which is OK from a hardware point of view (since the pin compatible S500/S700 SoCs are the only change between both board variants). But under 'OSes' for both boards 'Linux, Android' is listed which is simply BS since Cubieboard 7 with it's Actions Semi S700 SoC is simply an Android toy only. No Linux image has been made available, there's only one smelly 3.10 kernel that receives no updates since a long time any more and the vendor is known for providing horrible software support these days anyway. After spotting that much errors within a minute I stopped and closed the browser tab. It's just a waste of time to look through a huge collection of data providing zero (correct) information. Also the most important factor if you also want to USE a SBC and not just buy one is missing: quality of software support. Everybody should know that 'software support' makes the difference between a SBC and a paperweight or door stop. This collection of (partially wrong) data does not differentiate at all so it's completely useless.

With Xenial it was this way: https://github.com/armbian/build/issues/499 -- so I would assume with Bionic they do it now differently and we have to mask another service?

And do on the running system this prior to compressing: dd if=/dev/zero of=/lala bs=1M || rm /lala Usually reduces the size of the compressed image by magnitudes since zeroes compress better than random garbage (it's a block device that gets compressed so this does not happen at the filesystem layer --> everything that has been deleted is still there on the block device) As a side note: there are two search functions here, the search bar using the crappy/useless internal forum search and 'Google site search'. This topic has been discussed in detail many many times.

Nope, every Northbridge cooler with a mounting hole distance of 60 mm will work. Latest ayufan release from few hours ago activated USB so let's do a quick USB3 storage benchmark with an EVO840 in a JMS567 enclosure. Testing with our usual iozone benchmark: random random kB reclen write rewrite read reread read write 102400 4 19833 26941 35089 35464 24545 26763 102400 16 66374 85914 107740 108213 79784 86035 102400 512 308034 318723 298717 301950 293118 316910 102400 1024 335762 349205 335279 338808 330313 346358 102400 16384 379379 382513 378721 383947 383529 384295 1024000 16384 397369 402562 384391 384846 Up to 400 MB/s as expected. Current ayufan images are yet not optimized for performance. They're missing increase in CPU clockspeeds (1.4/1.8 GHz instead of 1.5/2.0 GHz) and also do not use latest DRAM initialization (RockPro64 is the first RK3399 device using LPDDR4 so with appropriate DRAM initialization everything memory dependent -- e.g. I/O DMA -- will be faster afterwards) I also did a quick iperf3 test in the meantime: +940 MBits/sec in both directions after ayufan adjusted TX/RX delay values:

Well, every other week the same question is asked here so the mechanism to display a random version number contained in /etc/armbian-release that is part of one specific package that doesn't get updated each time Armbian version number is increased is obviously misleading.