hjc

Learn something from game consoles' DRM systems, like Xbox One/PS4. Basically you need secure boot to ensure bootloader/kernel integrity, and something like TPM to store the encryption key and only unseal the key to trusted bl/kernel. Seems to be impossible with AllWinner and RPi SoC.

I guess what you said (M.2 without PCIe x4) is M.2 SATA. From the perspective of storage protocol they have no differences from normal SATA and mSATA SSDs, and normal SATA SSDs are even cheaper and probably with better heat dissipation. You'd find a lot of Armbian-supported boards with SATA ports (either native SATA or USB3 attached SATA). There are also boards with mSATA slot available. Try any board with SPI NOR flash. BTW, "slots" or "pins" are really cheap components, they worth nothing comparing to chipsets.

Actually you can always use VLAN to implement such firewall or router, combined with a switch which supports 802.1q aka VLAN tagging. The drawback is that you can only have 1Gbps in a single direction. BTW, internal GbE on devices like ROCK64 don't do well in these scenarios, because when running Ethernet in full duplex, its CPU reaches 100% (single core), and the full duplex throughput is only around ~400Mbps. An RTL8153 attached to the USB3, however, does this job quite well. The CPU consumption stays very low even when stress testing full duplex. However Ethernet over USB sometimes has stability issues. I think these issues are the ones that could not be avoided when evaluating cheap devices. It's a trade off.

Plus you would need (NVMe SSD or SATA disks) and SO-DIMM DDR4, since it does not have on-board eMMC and DRAM. These costs a lot, even for the cheapest setup.

I replaced the cable with a 0.25m USB Type-A to Type-C cable (a really cheap one), and it turns out that the voltage is much more stable. At full load+2*RTL8153, it's still up at ~4.97V, and multiple RTL8153 works like a charm now. However it seems that multiple RTL8153 behind a hub has some limitations. On the switch I can see traffic coming out on both USB attached ports, but they're only ~1.3Gbps total. When doing all port test (internal GbE+2 RTL8153, peer is 6*82583v configured with LACP), CPU0 is 100% and CPU2 is near 100%. I guess the A53 cores are not capable of handling such load. Anyway, currently the best choice seems to be attaching one additional RTL8153 for networking. It handles 2Gbps traffic in both directions simultaneously.

If you don't mind the size and pricing, sure. BTW, M4 sometimes performs much better than NEO4, since it has got dual channel memory.

So it's not a defect of the board, right? That's good news. I'd get some shorter cable w/ lower resistance and try to test 2*RTL8153 again.

I can confirm that my M4 also has the voltage drop issue. 1 RTL8153 connected, system idle: 4.9V Running iperf3 and generate 2Gbps traffic: 4.7V Running iperf3 with 6x cpuburn: 4.5V On NanoPC T4 the voltage is always 5.0V no matter what workload I run.

Unfortunately I'm on vacation and don't have physical access to my M4 right now. Will check that once I return home.

This may explain why I could not use multiple RTL8153 on the board stably.

It seems that @ayufan's rebase work is done recently (in the github repo it's now 187 commits ahead of official rockchip kernel). Maybe it's suitable now to test and evaluate the kernel and decide to merge rk3399 and rockchip64 family or not?

It is probably because armbian already planned to support RK3399 boards at that time.

I remember that once in a YouTube interview video it is said that one of these Ethernet ports are for out of band management. Don't know if that's accurate, though. It is mentioned that the LTE (mPCIe) port is also for the management system, so remote access of the serial console is possible. Out of band management are barely seen in the area of SBC, at least for Armbian supported ones. IMO if OOB management is usable, Armbian's software testing might even take place in the cloud. One developer maintains a lot of physical boards at his/her home, others connect in using VPN or other methods, and do all the image deployment & testing remotely or even automatically, just like how we do that on modern x86 systems (BMC, IPMI stuff, or some SoC embedded solutions like Intel Management Engine).

The M.2 connector on T4 does not support SATA, so you should get an NVMe SSD.

Stock Debian can install and boot on Firefly RK3399, however these new RK3399 boards' dts files are not mainlined yet, so it requires kernel/bootloader package modifications, and adding a board entry to flash-install db, or flash-install will fail. BTW: Stock Debian does not contain any of the armbian optimizations, so nothing will be as smooth as armbian runs.

Actually USB was never a good choice for networking especially when using behind a hub. I tested various setups and the only one that could actually work stably is with (only) one RTL8153 connected. If I connect 2 or more, as soon as I start stress testing (full duplex iperf on all connected NIC), the whole internal hub goes down in a few seconds (dmesg shows the internal hub is disconnected, lsusb -t only shows the root hub) and I have to do a USB reset or reboot the device to get that back again. I'm powering the board with official 5V/4A PSU so the board itself should be fine, but there still seems to be a current limit on the internal USB hub. One RTL8153 combined with the internal GbE, however, works smoothly. I even tried to configure LACP with my CRS326 switch. bonding1=ether1+ether2 (NanoPi M4) bonding2=ether5+ether6+ether7 (NanoPC T4) tested with iperf3 -P 2. With layer3+4 hash, two connections can easily use up to 2Gbps bandwidth between two devices. PCIe cards would definitely be better, though I don't know how many people seriously want to use RK3399 devices as a router.

Now FriendlyARM has a wiki page for NEO4.

Used M4 with RTL8153 in routing for several days. I'm having some trouble with 4.19-rc1, when the board is doing NAT between RTL8153 and the internal Ethernet port at about ~600Mbps, the system crashes with an invalid memory page request. After digging I found that this is a kernel software issue, and ayufan's 4.18-rc8 kernel does not have the problem at all. Crash logs: @Igor IMO it might be better move to the same dev kernel as Rockchip64 (I've published the commit here, in case you're willing to merge the changes)

It works great on Windows Server 2016 (so probably Windows 10, too). Now I'm playing with my NanoPi on the desktop workstation in my office. It's easy to use, run devmgmt.msc, find the serial device, then go with putty.

Rockchip boot sequence is typically BOOTROM -> u-boot SPL -> u-boot, AFAIK bootrom tries eMMC first, but u-boot SPL tries loading u-boot from SD card first (reference), so if there's a valid SPL on eMMC, you might still have a chance to boot from SD...

Actually the 4.4 kernel is quite stable, however Armbian development on this board is still in early stages, so it's marked as WIP. It means many optimizations may have not been applied yet (e.g. interrupts), and many configurations may be changed later (e.g. board family change requires a manual upgrade). If you are an experienced Linux user, this may not be a problem. There are a few other boards with fast native SATA or capable of PCIe SATA supported by Armbian, e.g. Helios4, EspressoBin, Clearfog Pro.

I personally never tried to rely on USB for stability, thus never put any important files on a USB drive. I do attach some USB HDDs on SBC and share them using Samba, but they are only used to store music & video files. Now my (not so) "simple" NAS is a NanoPC T4 combined with 1TB NVMe SSD. Have Samba and Owncloud server syncing ~30k files on several PCs, never seen an error.

Not yet, recently I'm trying to use M4 (with mainline kernel) as a network router & gateway (connect 2-3 RTL8153, set up VLAN, routing, NAT, and site to site VPN), and still trying to resolve some USB related issues. Currently with mainline kernel the USB hub must be manually reset (USBDEVFS_RESET) after reboot, or it wouldn't be usable.

I spotted two versions of the charger being sold by local resellers: 5V/2A and 5V/4A. They claim that 5V/2A is sufficient unless you need to connect any peripheral devices (like USB).

You're not alone, many board makers have to sign NDA with chip vendors. For example, when Dragonboard 820c was under development, they signed NDA with Qualcomm, and they must get approval before releasing Qualcomm kernel/bootloader sources. However before they got the approval to release kernel/bootloader source code, they didn't even release the board, nor any GPL-licensed binaries. You should follow the rules, too.