Search the Community

there have been VLAN CVE, rather encounter a security issue down the road - eliminate the problem with separate NICs. simple is always best Mainline kernel has support. You may lose some HW features but patching is not too hard, fortunately I only need firewall and QoS so that shouldnt be an issue. yup it was the the last board I ever helped kickstart. Now I wait to see if a board survives to mass production - like the Pi. I did back Parallella and was pleasantly surprised but that speaks to the caliber of the people working on the project. The founder is now a DARPA AI/compute project lead. I am pretty excited about the Ryzen V1000 boards coming out. if you look at the "companies" releasing the boards, you'll see its the same people under a different "brand" name. If you have lots of money to burn and want to encourage more bad boards, sure buy them all. I'll wait and see what survives. The smaller companies have to make a profit to survive unless they have tons of investment or are part of a much larger company. I mean look at Asus Tinkerboard, it still has issues and it used a few year old SoC and was made by a Tier 1 x86 motherboard manufacturer. Yes, have given up on any type of router boards - looking at the block diagrams and datasheets will reveal numerous issues.. Old x86 server I have around, it E3 Xeon uses ~25W since its server hardware. You can get older Xeons on ebay for very cheap.. But thats still 5x more vs a typically router ~5W. I forgot I also got a Linksys AC1200 refurb for $USD 40 which has an A385 . Was testing LEDE and ZFS on it. Will be putting debian on it now and will likely meet my needs. Yes, that's why industrial boards are expensive in addition to better spec-ed components. But I'm not looking for an industrial board - just one that has proper hardware at least, the software I can be fix. However, the NXP board I mentioned has an EXCELLENT BSP and hardware and support and its $50.. perhaps its subsidized as NXP to sell more chips since NXP is usually pretty expensive SoC-wise. I'd like to see any other manufacturer come out with something of comparable quality. Thank you for sharing. Most people don't know the difficult to bring a physical product, much less consumer electronics to market. Fortunately, one of my advisors helps manage supply chain for a certain fruit company. Their advice and experience was invaluable. After being burdened by one investor, I have learned to CAREFULLY read the legal and informal obligations of any contract/partnership and look for potential pitfalls, lest I be shackled again. One SoC vendor wanted free reign over our IP as they could be "independently" developing similar products and they had already released a similar product with a competitor. I declined. It sucked having to search for a new SoC vendor but it worked and we sold a good product. A year later we started talking again for a new project and they are more flexible having seen our success. Its unfortunate you couldn't manufacture in China, because then you could also do the regulatory testing/certifications in the area (HK, Taiwain or Shenzhen). The same testing/certification facilities used by Tier 1 motherboards manufacturers will provide testing services including the one you mentioned for USD $5K - $15K depending on what all you need. RF products will cost more. Glad to hear that you had an exit. Congrats Yes, out of all the community boards the EspressoBIN seems OK. The Marvell chips are fairly robust and the capabilities/performance aligns with the datasheet specs. However, after discussing the boards with GlobalScale I got an errie feeling similar to working with other SoC manufactures so I backed out and wanted to wait until launch. It was delayed over half a year and the end result is what you have now. They did release some Google Compute related boards so perhaps they are more focused on that but I got the sense they didn't really care about the community version board. I mean everyone wants Raspberry Pi level success and they seem to think the form factor is what does it, when its the fact they to long term support and committed part of their team to continue improving the BSP. "More wood behind fewer arrows". Rock64 says the same thing but shows different results. Releasing multiple boards with different SoCs with a small team will spread any small company too thin. Current SBC methodology is fire and forget and see what sticks. That generally works with software products but definitely not with hardware. Hence the bucket of EoL ARM devices that I and many others have sitting in the corner collecting dust. Hence why I refuse to support anymore campaigns without showing substantial thought into the product. Things do seem to be getting better as a couple mfgs are joining mainline kernel development and submitting patches and supporting projects like armbian. Just wish it didnt take companies 5 years to realize this.. The first "SBC" MK802 with Allwinner A10 was what changed the game back in 2012 and kicked off this SBC revolution and helped create a space which eventually gave us the Pi though the story with the Pi is it was built to get kids back into computers. Anyway I'm confident things will get better one way or another!

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.

Gah - watched the video - and a lot of problems across the board (pardon the pun). Different kernels, built with different versions of GCC, userland (for example, Raspbian userland is all ARMv6 with exception of the kernel for the A7/A53 boards).... (I wouldn't have included the any of the Pi's in the set of boards being evaluated because of the userland - <soapbox> nothing against Pi's in general, one must appreciate that 35M+ boards means they're doing something right, and they've spawned an entire HW/SW ecosystem around their platform, that's ok - and that ecosystem has in turn made affordable ARM boards available for hobbyists, makers, and developers - before Pi, if one wanted to do development around ARM, boards were expensive, and SW support was very limited to the vendor BSP - these days, it's a lot more open - not perfect, but much better than it was</soapbox>) Rock64 vs Odroid XU4 - Quad A53 vs A7/A15 big.LITTLE - the big.LITTLE is a challenge for the scheduler, and depending on the BSP from the OEM, it's easy to get wrong, where threads can land on the lesser preferred core, this is an issue even on Android, where much work has been done outside of the mainline kernels (ARM and Qualcomm, I know they've done a lot of research there, but much of that has not been pushed back to mainline). In my experience, with supported boards (for me this is Tinker and NanoPi NEO), Armbian is generally faster than the vendor's images - and that's doing Byte-Unixbench, which is discounted because it is compiler sensitive - that being said, it's still a useful tool when comparing apples to apples (e.g. tweaking settings on the same OS/Platform, but comparing Platform A to Platform B, one has to take the results with a grain of salt) I haven't found a lot of evidence of cheating by any of the SBC vendors - it's really hard to do with FOSS, compared to Android, where cheating has occurred with certain OEM's and specific benchmark APK's - Android has enough hooks to enable this kind of cheating in any event. sbc-bench, in my humble opinion, is a good benchmark for supported boards - as long as the boards being compared are all on the same version of Armbian - and this is made clear in the script comments (please review the script on github, and @tkaiser has been pushing updates, so if one has cloned the repo, it's worthwhile to do a git pull to get the latest revision. To answer your question about the different versions of Cortex... Small Cores - A7, A53 are the low power cores focused on efficiency Big Cores - A15, A12(A17), A72 - big cores... Think of it like Atom (Small Core) vs Core i3/i5/i7 (Big Core) - even at the same clock, the big core is going to get more work done, but perhaps at the cost of heat, so thermal solution needs to be considered.

The BPi R1, R2 and W2. All above $50. But you've got to pay what it costs, manufacturers aren't going to change prices. No idea about the software support for them. EspressoBin is a good choice. https://www.amazon.com/ESPRESSObin-SBUD102-Single-Computer-Network/dp/B06Y3V2FBK You can also buy a Rock64 and add USB3 network adapters. Enough choice, you only have to make it work...

@tkaiser Hi Thomas. I'm planning to make a video about the use/uselessness/problems of benchmarking SBC's. Today I got a message from a subscriber about the Odroid H2, where he claimed the XU4 was a very slow SBC. His claim was backed up by "benchmarks" from ExplainingComputers. Here are those results. Video ExplainingComputers : &nbsp;Six SBC Benchmark: ODROID XU4, ROCKPro64 & More! Here the ROCK64 seems to outperform the XU4. We all know that's not right. I would use SBC-bench if ok for you and Blender to show the difference in results using different platforms, kernels and settings on the same SBC. I think with the M4. Lubuntu xenial armhf vs Lubuntu bionic armhf vs Lubuntu bionic arm64 and Armbian stretch vs bionic. Those differences are big. And the Raspberry 3B+ with ram overclock and without to show importance of ram+cpu. I would make different subjects. Of which : Problems with Benchmarks and sollutions SBC-Bench (how does it work, what does it do) Differences between different cortexes A7, A53, A72, ... (I'll need to do a lot of homework for that, if you could elaborate on it, please do) Importance of RAM speed with CPU speed, and other parameters Cheating manufacturers (Amlogic with C2, Raspberry Pi with 3B+, any others I should mention?) Conclusion... So with this I ask your permission to use SBC-bench, and quote you out the readme.md and eplanations and insights in the results.md file. And if you would like me to mention something, please tell me. Or if you want you could record an audio/video file with your words to add in the video(just a thought) Did you start a draft for the "Interpreting results" part yet? I'll be busy for at least another week gathering information. When done I'll share my results, and I''ll say what I'm going to use from your texts in the video. Sorry for the long post. Greetings.

as far as I can see, the same wifi chip as for the firefly is populated on this board.. so by using the same drivers, and ensure it's properly defined in DT chances are high(er) that it should work 'as expected'. Using the same kernel as @hjc used for the firefly.. GbE is also the same, then it should be just adjustments in case DT definition changed slightly.. And if it performs badly: https://github.com/ayufan-rock64/linux-build/blob/master/recipes/gmac-delays-test/range-test well you've to be in case you want to give it a try.. I'll only help you.. build and test is then up to you... I prefer to mess with DT rather than fixing then broken things after the image is created.. From the sources, this is mostly a reference board with a few additional stuff populated (http://vamrs.com/sapphire-excavator).. There's not much an reason why things should not work. doesn't need years, DT is good enough described in the documentation to learn it..

Under 20$ the Raspberry Pi Zero W for 10$. It's very slow with only 1 core at 1Ghz. You can watch youtube with kiosk browser. And surf, very slowly. The Banana Pi M2 Zero for 20$. A lot faster. 4x1.2Ghz. You need a good heatsink for it or it overheats constantly. Not very good video playback. For 25$ the Rock64. Faster, better, but no wifi on-board. A raspberry pi 3b+ is 35$ and again a bit better. For your use case an Odroid C2 is perfect. Good Youtube playback, fast, doesn't overheat, ... That's about 50$ Those or the ones I have, and I can recommend. But for 20$ you will not get much. You need to know that many sbc's don't have hardware acceleration for video playback in browsers. So expect choppy and low resolution video with most. The Odroid C2 does this best in Linux. Also if a board only has 512MB ram then you want be able to open many tabs. FriendlyArm also has got some interesting cheap boards. I review sbc's on their desktop capabilities. Of all those I've got a video, except the C2. https://www.youtube.com/channel/UCpv7NFr0-9AB5xoklh3Snhg

I would suggest a Rock3399 board. With a big enough heatsink it can be fanless. Also if you underclock it a bit... There's the Orange Pi RK3399 with sata on-board, USB-3.0 type C, 2GB ram, ... But the Orange Pi has got less software support than many other RK3399's. http://www.orangepi.org/Orange Pi RK3399/ Otherwise I would suggest the NanoPi M4. This does not have SATA, but there's a 4xSATA hat comming for it. And it has USB3. It's got an amazing heatsink. When running it at 1.8Ghz/1.4Ghz then it always stays under 70°C when constantly maxed out without a fan. There's a 2GB and 4GB model. Gigabit ethernet. Great wifi 2.4Ghz/5Ghz + blue tooth. It's the most power efficient of the RK3399 boards. If you want it cheaper and don't need a lot processing power you could go for Rock64. Again no SATA, but USB3, gigabit ethernet, 1/2/4GB models, ... With a big enough heatsink it can run fanless. Biggest disadvantage is it's a slow CPU. One that has got everything you want is the Banana Pi W2. 2 SATA interfaces, USB3, 2GB DDR4, PCIe, 2Xgigabit ethernet, ... It's a very different SBC than others, I don't know about the software support of this one. I think I'll be able to make a review video about this next month. http://www.banana-pi.org/w2.html Here my video about the NanoPi M4 Here my video about the Rock64 If you also would like it to be able to play games well. Then the Odroid XU4-Q could also be a possiblity. When underclocked enough it doesn't need a fan. There are many others. It depends on how much you want to pay, how much processing power you want, ... The Rock64 is good enough to run a simple server. But if you want to be future proof, then I would rather go for a NanoPi M4 or so. Greetings.

We can/could merge Nanopi M4/T4/Neo4 under one image, which share boot loader and kernel family rk3399. We wanted to add Rock64 and Rock64PRO to one common rockchip64 family. To maintain one kernel source ... but its sadly way too much work and this is postponed to the future. Since we have two legacy kernels for RK3399 and since boot loaders are different, we can't provide one image.

I agree - your build is working. But on the box v88piano constantly crashes, the operating system on micro SD collapses. As a result, the system load stops with the message "kernel panic". It was checked on your (and not only your) builds of LibreElec and linux with different device trees - z28, Rock64, etc. Could you add support for the box v88piano to your builds?

IMHO taking into account the need for GPIO, to date (in the near future this situation may change) for you to optimally use models based on RK3328 (Renegat Rock64 etc). This is optimal in terms of cost and the result obtained for your tasks. And advice, do not chase the cheapness, it is better to spend 100 and use the purchased piece of iron in full compliance with the tasks for many years than to spend 50 and then not get the desired result (at best, somehow use the purchased iron, at worst-throw in the trash). https://forum.armbian.com/forum/21-rockchip-3288-3328/ https://forum.armbian.com/forum/16-amlogic-s905x/

Well, the FreeIPA release just updated on Friday (2018/10/05) it looks like to solve the issue... now I just have to wait for it to make its way into debian/ubuntu/armbian's repos (or get Fedora working on Rock64 but so far that's been a fail - I expect the repos will update before I get Fedora booting on the Rock64)

Thanks for the insights. I hope we can make it work on armbian at some point. I know ayufan (https://github.com/ayufan-rock64/linux-build/releases/tag/0.7.9) bundles it on his builds but not sure how.

A few things do not work yet on 5.60 version (4.18 kernel) 1) reboot does not work -- only function as shutdown. 2) I have not figured how to change the resolution to 1920x1080p60 yet (HDMI) -- it is now only at 1024x768 3) WiFi does not work and the addon USB card TP-Link TL-WN727N is not working out of the box as in 3.14 kernel. I followed the following -- by editing armbianEnv.txt to add "disp.screen0_output_mode=1920x1080p60 " (this method works for my Rock64 board) but it does not seem to work. https://docs.armbian.com/User-Guide_Fine-Tuning/

/proc/sys/crypto doesn't exist, so anything checking the status of /proc/sys/crypto/fips_enabled fails terribly. (Specifically trying to bring up a FreeIPA server which includes tomcat-based Dogtag CA, it checks for FIPS during setup, dies). I see there is an rk_crypto kernel module available, so I don't know why /proc/sys/crypto itself is missing. I tried 'modprobe rk_crypto' and it loaded (appears in output of 'lsmod'), but /proc/sys/crypto still doesn't exist.

I assume you need at least an mpc251x driver (as module). Seems not to be here for rock64. Go through this one to see how you can change that.

Hi there, I'm trying to made a dts file to handle a pican2 hat on ROCK64 armbian, but now I'm stuck. I'm a noob in writing dts files, I've tried to take as exemple dts from RPI and Thinker. edit: I've rebuild the kernel, and build the mcp251x.ko module, it load like a charm. But I assume I've to write a correct .dts file to link it to my devices tree. here is my loaded modules list: Module Size Used by can_bcm 24576 0 can_raw 20480 0 can 53248 2 can_bcm,can_raw mali 262144 0 rt2800usb 28672 0 rt2800lib 81920 1 rt2800usb rt2x00usb 20480 1 rt2800usb rt2x00lib 49152 3 rt2x00usb,rt2800lib,rt2800usb zram 32768 5 lz4_compress 16384 1 zram mcp251x 20480 0 dw_hdmi_i2s_audio 16384 0 can_dev 20480 1 mcp251x binfmt_misc 20480 1 ip_tables 24576 0 x_tables 32768 1 ip_tables autofs4 40960 2 uas 20480 0 usb_storage 61440 1 uas Cannot find device "can0" eth0 lo wlx00c141390c5a And as you can see, there is no can0 devices in /sys/class/net. here is my dts file: /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328", "pine64,rock64"; fragment@0 { target-path = "/spi@ff190000"; //target = <&spi0>; __overlay__ { status="okay"; spidev@0{ status = "disabled"; }; spidev@1{ status = "disabled"; }; }; }; /* the interrupt pin of the can-controller */ fragment@1 { target-path = "/pinctrl/gpio3@ff240000"; //target = <&gpio3>; __overlay__ { can0_pins: can0_pins { rockchip,pins = <0 7 0 &pcfg_pull_none>; //phandle = <1>; }; }; }; /* the clock/oscillator of the can-controller */ fragment@2 { target-path = "/"; __overlay__ { /* external oscillator of mcp2515 on SPI0.0 */ can0_osc: can0_osc { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <16000000>; }; }; }; /* the spi config of the can-controller itself binding everything together */ fragment@3 { target-path = "/spi@ff190000"; //target = <&spi0>; __overlay__ { /* needed to avoid dtc warning */ #address-cells = <1>; #size-cells = <0>; can0: can0@0 { //phandle = <1>; reg = <0>; compatible = "microchip,mcp2515"; pinctrl-names = "default"; pinctrl-0 = <&can0_pins>; //pinctrl-0 = "/pinctrl/gpio3@ff240000/can0_pins/"; spi-max-frequency = <10000000>; interrupt-parent = <&gpio3>; //interrupt-parent = "/pinctrl/gpio3@ff240000"; interrupts = <7 0x2>; // 7 2 //clocks = "/can0_osc"; clocks = <&can0_osc>; }; }; }; }; here is what I can read from dmesg: pi@rock64:/boot/overlay-user$ dmesg | fgrep -i spi [ 0.199580] bus: 'spi': registered [ 0.199591] device class 'spi_master': registering [ 0.215439] device: 'ff190000.spi': device_add [ 0.215471] bus: 'platform': add device ff190000.spi [ 0.215560] PM: Adding info for platform:ff190000.spi [ 2.069101] bus: 'spi': add driver cros-ec-spi [ 2.069297] device class 'spi_transport': registering [ 2.069329] device class 'spi_host': registering [ 2.070797] bus: 'spi': add driver m25p80 [ 2.070861] device class 'spidev': registering [ 2.070890] bus: 'spi': add driver spidev [ 2.070956] bus: 'platform': add driver rockchip-spi [ 2.071145] bus: 'platform': driver_probe_device: matched device ff190000.spi with driver rockchip-spi [ 2.071162] bus: 'platform': really_probe: probing driver rockchip-spi with device ff190000.spi [ 2.071495] rockchip-spi ff190000.spi: no init pinctrl state [ 2.071552] rockchip-spi ff190000.spi: no sleep pinctrl state [ 2.071566] rockchip-spi ff190000.spi: no idle pinctrl state [ 2.071795] rockchip-spi ff190000.spi: no high_speed pinctrl state [ 2.071820] device: 'spi32766': device_add [ 2.072075] PM: Adding info for No Bus:spi32766 [ 2.072326] device: 'spi32766.0': device_add [ 2.072362] bus: 'spi': add device spi32766.0 [ 2.072582] PM: Adding info for spi:spi32766.0 [ 2.072661] rockchip-spi ff190000.spi: chipselect 0 already in use [ 2.072675] spi_master spi32766: spi_device register error /spi@ff190000/flash@0 [ 2.072692] spi_master spi32766: Failed to create SPI device for /spi@ff190000/flash@0 [ 2.072709] driver: 'rockchip-spi': driver_bound: bound to device 'ff190000.spi' [ 2.072758] bus: 'platform': really_probe: bound device ff190000.spi to driver rockchip-spi [ 8.643523] bus: 'spi': add driver mcp251x [ 8.643560] bus: 'spi': driver_probe_device: matched device spi32766.0 with driver mcp251x [ 8.643570] bus: 'spi': really_probe: probing driver mcp251x with device spi32766.0 [ 8.643678] mcp251x spi32766.0: no pinctrl handle [ 8.646051] mcp251x spi32766.0: Looking up vdd-supply from device tree [ 8.646071] mcp251x spi32766.0: Looking up vdd-supply property in node /spi@ff190000/can0@0 failed [ 8.648100] mcp251x spi32766.0: Looking up xceiver-supply from device tree [ 8.648120] mcp251x spi32766.0: Looking up xceiver-supply property in node /spi@ff190000/can0@0 failed [ 8.661924] mcp251x: probe of spi32766.0 rejects match -19 pi@rock64:/boot/overlay-user$ help me plz.

Hi. I added a second wireless interface to my Rock64 and created a wifi hotspot using armbian-config. Now .local domains are not resolved anymore. I tried changing in files /etc/resolvconf/resolv.conf.d/base and /etc/resolvconf/resolv.conf.d/head IP from 8.8.8.8 to 127.0.0.1 but nothing changed. avahi-resolve-host-name is ok: christian@rock64:~$ avahi-resolve-host-name orangepi2mini.local orangepi2mini.local 192.168.0.12 but christian@rock64:~$ ping orangepi2mini.local ping: orangepi2mini.local: Name or service not known Could anyone point me on what could have gone wrong? Many thanks. Christian

Sure, I won't miss it. The problem is that enabling option CONFIG_USB_HIDDEV is not enough, something is still missing. I wanted to create a specific post in a general section because maybe someone else knows how to do it, but no problem. I'll try to compare the configuration kernel file of the other Ubuntu distribution, which I think is more similar to the Odroid XU4 Armbian configuration file than the Rock64 configuration file. Thanks

Hi all. I'm trying to figure out how to use gstreamer to encode h264 video on Rock64 (Rockchip RK3328). I'm using Armbian Bionic 5.60 (stable Ubuntu 18.04.1 LTS 4.4.156-rockchip64). I compiled mpp and gstreamer-rockchip from https://github.com/rockchip-linux and installed both, but I'm still missing mpph264enc, how do I get that? gst-inspect-1.0 mpph264enc says: No such element or plugin 'mpph264enc' Many thanks for reading, any help would be greatly appreciated. Regards. Christian

Yes, it works. So I can use the kernel configuration of the Rock64 board, I think this one linux-rockchip-next.config But it not simple, too many differences ... :-(

Hi All. I have some confusion on Touchscreen interface. My ques is very basic on LCD interface types ... apologies for that. I like to use a 3.5" Touchscreen. For CPU either Allwinner H6 and RK3328 is in my choice. I have attached the Touchscren Datasheet. Here we will build a custom PCB for the Touchscreen. But I found RK3328 don't have any LCD Interface. So is there any possible way to use this Touchscreen with RK3328 based SBC like Rock64? On the other hand Allwinner H6 have RGB LCD port. But in Touchscreen Datasheet it said LCD Driver IC is ILI9488. As H6 have direct RGB Port so do we need to use this ILI9488 Driver? There are many Touchscreen Shield connects with GPIO Header ... how they are communicating without a dedicated LCD Interface? Thanks in advance. Regards. HT035K1HV50C-U-V0.pdf

Can you help me? How can I do it? On the Rock64 I have the ayufan Stretch image 0.6.44, kernel 4.4.132. I have to search in that kernel configuration. And I can try the Rock64 Armbian image to check if apcuspd works with it. Thanks

Bionic and Stretch share kernel. Try to compare working (rock64) with nonworking configuration ... perhaps some other config option is needed or there is a bug in Odroid USB stack. You can also switch between different kernels for XU4 if that helps ... Wrote on mobile

The version of the image 20180930 with support for full-screen video through MPV with HW. To use MPV with HW, you must run these commands. sudo add-apt-repository ppa:ayufan/rock64-ppa sudo apt-get update sudo apt-get install ffmpeg mpv libmali-rk-utgard-450-r7p0-gbm Rename the file in the home directory of the user ".config/mpv/mpv.conf.rkmpp" to ".config/mpv/mpv.conf" Reboot the system. Please note that full-screen video with HW works only through MPV.