• Content Count

  • Joined

  • Last visited

About hjc

  • Rank
    Advanced Member

Contact Methods

  • Website URL

Profile Information

  • Location

Recent Profile Visitors

639 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. hjc

    NanoPI M4

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

    Xilinx Zynq or ZynqMP

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

    NanoPC T4

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

    NanoPi NEO4

    Now FriendlyARM has a wiki page for NEO4.
  14. 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)
  15. 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.