hjc

Members
  • Content Count

    91
  • Joined

  • Last visited

About hjc

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    https://blog.hjc.im/

Profile Information

  • Location
    Shanghai

Recent Profile Visitors

874 profile views
  1. hjc

    eliminating hardware bloat

    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.
  2. 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.
  3. hjc

    New Odroid H2 with Intel

    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.
  4. hjc

    NanoPI M4

    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.
  5. hjc

    NanoPi NEO4

    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.
  6. hjc

    NanoPI M4

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

    NanoPI M4

    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.
  8. hjc

    NanoPI M4

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

    NanoPI M4

    This may explain why I could not use multiple RTL8153 on the board stably.
  10. 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?
  11. hjc

    Xilinx Zynq or ZynqMP

    It is probably because armbian already planned to support RK3399 boards at that time.
  12. 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).
  13. hjc

    NanoPC T4

    The M.2 connector on T4 does not support SATA, so you should get an NVMe SSD.
  14. 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.
  15. hjc

    NanoPi NEO4

    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.