hjc
-
Posts
92 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by hjc
-
-
11 hours ago, Dave Kimble said:
how about a M.2 slot instead supporting PCIe x4 so we can buy the biggest, fastest and cheapest per GB SSDs around.
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.
11 hours ago, Dave Kimble said:You could then eliminate the TF slot, micro-SD cards and eMMC modules, and the system could boot off the drive in the normal Linux manner.
Try any board with SPI NOR flash. BTW, "slots" or "pins" are really cheap components, they worth nothing comparing to chipsets.
-
8 hours ago, e97 said:
An OrangePI R1 like device with dual gigabit and a quad core a8 at ~$30 would make an excellent firewall/network appliance thats lower power.
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.
-
1 hour ago, NicoD said:
but pricy
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.
-
On 10/11/2018 at 4:09 AM, NicoD said:
The undervoltage problem was a bad cable. It's a lot more stable with the original cable.
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.
-
1 hour ago, Seasalt said:
Is it worth paying more and getting the NanoPi M4 2 GB model?
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.
-
-
On 10/3/2018 at 9:39 PM, NicoD said:
Please check your usb voltage if you can so I can confirm this is not only on my board.
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.
-
-
-
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?
-
-
17 hours ago, tkaiser said:
2 x Ethernet (also no idea yet)
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).
-
-
38 minutes ago, Faber said:
I already knew about that. I was actually wondering if Debian could boot on one of these boards and how stable it is on them. I noticed that there's a Rockchip bootloader in the Debian repository, and I was wondering if that was necessary for Debian to be able to boot on the NanoPi M4.
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.
-
46 minutes ago, tkaiser said:
I've seen @hjc is experimenting with several USB3 based Gigabit Ethernet chips connected to NanoPi M4 but switching to PCIe might improve latency here?
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.
-
-
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:
Spoilerkerne[ 274.232128] Modules linked in: xt_nat xt_tcpudp xt_mark xt_TPROXY nf_tp roxy_ipv6 nf_tproxy_ipv4 xt_REDIRECT veth fuse 8021q garp mrp bridge stp llc cdc _ether usbnet r8152 rockchip_rga videobuf2_dma_sg videobuf2_memops snd_soc_rockc hip_spdif snd_soc_rockchip_i2s snd_soc_rockchip_pcm v4l2_mem2mem videobuf2_v4l2 videobuf2_common videodev media nvmem_rockchip_efuse brcmfmac rockchip_io_domain ip6table_filter rockchipdrm cfg80211 ip6_tables rfkill rockchip_thermal brcmuti l dw_hdmi analogix_dp iptable_filter ipt_MASQUERADE drm_kms_helper rockchip_sara dc drm iptable_nat pcie_rockchip_host nf_nat_ipv4 drm_panel_orientation_quirks n f_nat adc_keys input_polldev nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_ mangle tcp_bbr sch_fq ip_tables x_tables ipv6 btrfs libcrc32c xor zstd_decompres s zstd_compress
l:[ 274.231695] Internal error: Oops: 96000004 [#1] SMP
[ 274.238767] xxhash zlib_deflate raid6_pq phy_rockchip_typec phy_rockchip_pci e rtc_rk808 realtek dwmac_rk stmmac_platform stmmac
[ 274.240188] CPU: 2 PID: 21 Comm: ksoftirqd/2 Not tainted 4.19.0-rc1-rk3399 #3 5
[ 274.240822] Hardware name: FriendlyElec NanoPi M4 (DT)
[ 274.241276] pstate: 40000005 (nZcv daif -PAN -UAO)
[ 274.241708] pc : dev_hard_start_xmit+0x48/0x128
[ 274.242110] lr : dev_hard_start_xmit+0x90/0x128
[ 274.242509] sp : ffff0000092236f0
[ 274.242803] x29: ffff0000092236f0 x28: 0000000000000001
[ 274.243272] x27: dead000000000100 x26: ffff0000092237bc
[ 274.243742] x25: ffff000008c76000 x24: ffff80007abc5090
[ 274.244212] x23: ffff000008c7d8d0 x22: ffff000008c7d0c0
[ 274.244681] x21: ffff800075186c00 x20: ffff80007abc5000
[ 274.245150] x19: dead000000000100 x18: ffff80004600a140
[ 274.245620] x17: 0000000000000000 x16: 0000000000000000
[ 274.246089] x15: 0000000000000000 x14: 000000000a18006c
[ 274.246558] x13: 000000000000001c x12: 0000000000000018
[ 274.247028] x11: ffff000009223398 x10: 0000000000000004
[ 274.247497] x9 : ffff00000094b8f8 x8 : 0000000000000000
[ 274.247966] x7 : 00000000a0000000 x6 : 000000018e36996c
[ 274.248436] x5 : 00ffffffffffffff x4 : 0029df11ad4bd57e
[ 274.248905] x3 : 0000000000000018 x2 : c574e174c02a4100
[ 274.249374] x1 : 0000000000000000 x0 : 0000000000000000
[ 274.249845] Process ksoftirqd/2 (pid: 21, stack limit = 0x00000000b03e934a)
[ 274.250455] Call trace:
[ 274.250676] dev_hard_start_xmit+0x48/0x128
[ 274.251046] __dev_queue_xmit+0x7b0/0x838
[ 274.251402] dev_queue_xmit+0x10/0x18
[ 274.251730] ip_finish_output2+0x248/0x388
[ 274.252094] ip_finish_output+0x114/0x1f8
[ 274.252449] ip_output+0xa8/0x118
[ 274.252744] ip_forward_finish+0x64/0xa0
[ 274.253092] ip_forward+0x38c/0x4c0
[ 274.253401] ip_rcv_finish+0x54/0x88
[ 274.253718] ip_rcv+0x54/0xc0
[ 274.253983] __netif_receive_skb_one_core+0x54/0x80
[ 274.254414] __netif_receive_skb+0x14/0x60
[ 274.254777] netif_receive_skb_internal+0x38/0xe0
[ 274.255194] napi_gro_complete+0x68/0xb8
[ 274.255541] dev_gro_receive+0x660/0x678
[ 274.255889] napi_gro_receive+0x30/0xc8
[ 274.256235] r8152_poll+0x4a8/0x1068 [r8152]
[ 274.256614] net_rx_action+0x10c/0x2d0
[ 274.256948] __do_softirq+0x10c/0x200
[ 274.257274] run_ksoftirqd+0x30/0x40
[ 274.257594] smpboot_thread_fn+0x1a0/0x1d0
[ 274.257957] kthread+0x128/0x130
[ 274.258245] ret_from_fork+0x10/0x1c
[ 274.258564] Code: 91024038 f90023b9 f0002399 f9002fbc (f940027b)
[ 274.259107] ---[ end trace b81d4210d61a59cb ]---
[ 274.259516] Kernel panic - not syncing: Fatal exception in interrupt
[ 274.260075] SMP: stopping secondary CPUs
[ 274.260546] Kernel Offset: disabled
[ 274.260856] CPU features: 0x0,21806008
[ 274.261188] Memory Limit: none
[ 274.261462] Rebooting in 10 seconds..@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)
-
19 hours ago, chwe said:
you should be able to access it from windows (someone motivated may confirm this).
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.
-
1 hour ago, tkaiser said:
Boot priority with Rockchip boards is AFAIK always eMMC first then SD card.
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...
-
1 hour ago, esbeeb said:
To me, those are the only boards I'd want to consider for a NAS. @hjc
suggests the NanoPC T4, but that's not yet a "Supported" board.
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.
-
16 hours ago, tkaiser said:
@hjc did you already look into lowering DVFS voltages? In the past we did this using a special Linpack version that is able to spot undervolted DVFS OPP before the board actually crashes.
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.
-
1 hour ago, tkaiser said:
Yes, I hope this one does well. No chance to test yet since missing the needed adapter (also available in FriendlyELEC's online shop and also a recommendation for those affected then):
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).
-
44 minutes ago, Nora Lee said:
Soft remind that our company signed NDA with Realtek, we must follow Realtek's rule to release files under Realtek's approval.
22 minutes ago, Lion Wang said:yes , we must signed NDA , if not , we can not begin this project ,You may think it's pointless to start the project because it's not "open source", but i know some few user need this .
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.
Selling Pi-based products very hard to hack
in Off-topic
Posted
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.