manuti reacted to Christos in FriendlyELEC NanoPi K2 (S905)
IMHO FA might go for the S912 now..
They already got M3 (with Samsung CPU) in the past as a 8xCore (and from my experience on it its really fast) but it lacked support, now with Amlogic the foundations are already there to deliver the first decent and trully mainline supported hacker-friendly 8xCore 64-bit A53 SBC.
manuti reacted to tkaiser in Armbian running on Pine64 (and other A64/H5 devices)
A small update regarding "NAS performance" on A64 devices. Since I'm currently busy evaluating Armbian's build system as base for universal OpenMediaVault OS images I made a quick test after tweaking NAS relevant settings once more:
This is a "SAMSUNG MZ7TE128HMGR-00004" (EVO 840 OEM) connected to the lower USB port on Pine64+ running with legacy kernel:
And this is the same SSD connected to the upper USB port which is A64's USB OTG port connected to a different controller that is said to perform worse:
Well, performance numbers do not differ that much but unless an OMV image with mainline kernel is available (where we can set some magic bits to connect Pine64's upper USB port to a real USB host port using an own EHCI/OHCI controller pair) it's recommended to connect any disk to the lower USB port since this is the real host port.
Regarding other A64 boards and their USB ports: all behind an internal hub and having to share bandwidth. Do not even try the 'NAS use case' there
manuti reacted to TonyMac32 in RK3328 Kernel
Getting back to the Tinker Board itself..
I swapped in the device tree from the miniarm branch at rockchip-linux, it compiles and boots properly, however I have had no luck getting the Bluetooth or wifi devices enumerated, I need to spend some more time with it. More troubling, and the reason I have so little progress, is the adjustments made to the HDMI portions of the DT have rendered video output almost impossible to maintain (anytime the system puts the monitor output to sleep it refuses to wake up, sometimes a hotplug of the monitor will rectify it). The mainline builds fail if I try to patch anything at the device driver level, I'll dig into that later.
manuti reacted to Klez in Two cosmetic improvements for Armbian
Hi Igor and everyone else.
Id'like to suggest the following:
It´s not necesary to use both noatime and nodiratime, because noatime already implies nodiratime, so you can use only the option "noatime" instead of both.
When creating the ext4 filesystem with mkfs.ext4 you can type a label for it with the parameter " -L " so when the users mount their cards on a computer, the desktop will show some name instead "NO NAME".
# mkfs.ext4 -O ^has_journal -L Armbian /dev/mmcblk0p1
# mkfs.ext4 -O ^has_journal -L Cubox-i /dev/mmcblk0p1
manuti reacted to malvcr in Orange Pi Zero NAS Expansion Board with SATA & mSATA
Hi ... I acquired more OPIZ and some NAS (just before they offered the H3 and H5 ... well, next purchase maybe for these machines).
When receiving them, I realized the need for the special SATA cable, so I made a small Frankenstein with some old cables I had around (just for primary testing purposes while I have real supported cables).
I have an Orange Pi power supply, but attached to a 2E device that I can't turn off right now, so I decided to risk myself a little and to power only the OPIZ (no power to the NAS device). And both work with a Canakit 2.5A microUSB power adaptor. The OPIZ powering the NAS worked, at least turning it the tiny green leds.
Next test: To put USB memories on all the USB ports (3 of them) ... and they work well, as 480 Mbps devices. OK, this means, the power from OPIZ to NAS it is enough, at least for that. And then, the big test ...
... a WD Blue 500GB 2.5 inch hard drive connected to the NAS. And ... it works!! Even together with another USB memory on the same machine. Without using the NAS dedicated power connector.
NOTICE: Before updating the armbian, the hard disk was working as an 1.1 USB device ... painfully slow ... so, update the operating system before testing this.
OK ... how fast is this? (after the update)
root@orangepizero:~# hdparm -Tt /dev/sda1 /dev/sda1: Timing cached reads: 686 MB in 2.00 seconds = 342.52 MB/sec Timing buffered disk reads: 74 MB in 3.03 seconds = 24.41 MB/sec root@orangepizero:~# hdparm -Tt /dev/sdb1 /dev/sdb1: Timing cached reads: 684 MB in 2.00 seconds = 342.08 MB/sec Timing buffered disk reads: 94 MB in 3.05 seconds = 30.80 MB/sec root@orangepizero:~# In this case, sda1 is a Lexar 32GB memory stick and sda2 is the WD Blue.
Then, the raw speed on the hard disk it is good enough for many purposes.
NOTICE: When attaching a USB memory stick on the USB port next to the SATA connector, the SATA disk it is expelled in some way (remains mounted but with i/o errors). This must be the multiplexed ports that was previously indicated in this post. Then, I imagine (still doesn't have one of them to test), that the msata will disable the "other" USB port on the NAS card (or the USB will disable the msata devices). So, be careful when using these ports if there are sata devices connected to the NAS card.
A final "initial" test ... to copy with scp from a Mac Mini through ethernet a big file.
The average speed it is 10 MB/s this is 80 Mbps (when reducing the ssh and operating system overhead, it is not so bad) . However, it is clear that the network it is a real bottleneck when observing the raw sata speed.
In this case, and with a regular OPIZ - H2+,512MB device, the speed it is good enough for not so demanding backups, some media files and other usages that have a good behavior on 100 Mbps. OR ... when the OPIZ perform the tasks on the hard disks, as with databases when the 100 mbps it is not in the accessing equation.
When I have a msata at hand I will include more numbers.
manuti reacted to tkaiser in [preview] Generate OMV images for SBC with Armbian
Anyone ever dealt with OpenMediaVault (OMV) on SBC? Great piece of software but pretty slow, right? One of the many reasons why that happened are outdated crappy kernels and bad settings. I looked at an OMV image for A20 based boards like Banana Pi Pro recently, ended up here http://simplenas.com/download/bananas-simple-system and simply thought: Are you kidding me? Your stable release is based on horribly outdated Debian Wheezy, a kernel 3.4.something and a 2.x OMV release?! What a mess...
Igor had an OMV install routine since a long time in his Debian-micro-home-server post-processing script but since an Armbian user evaluated using Armbian's build system to generate OMV images we thought... why not integrating it in Armbian?
We started yesterday to prepare all kernels for the Ethernet equipped boards to meet the OMV requirements (just Quota/ACL/NFS stuff) and then played around with an installation routine that can be used from our image customization script to generate OMV images without the need to tamper with them manually later (one of Armbian's design goals). A first preview is now available. All that's needed to create a fresh OMV image from scratch is checking out Armbian build system as outlined in the docs and then use the new customize-image.sh.template as userpatches/customize-image.sh, uncomment the InstallOpenMediaVault line and then create an Debian Jessie Armbian image that will be a full OMV 3 release afterwards.
This will take some time but then you have an OS image that can be booted on your device of choice, needs 2-3 minutes for housekeeping (finishing the installation -- network connection required!), reboots and will then be accessible through http://openmediavault.local (if your router's DHCP server is not broken then http://openmediavault will also work). No need to use any smelly OMV images you find in dark corners of the Internet. Just create one yourself if needed or ping your hardware vendor of choice to look into the possibilities he gets when relying on a solid foundation for creating OS images.
Quick performance test with the beefiest device we currently support (Solid-Run's Clearfog Pro):
86/98 MB/s (write/read) over a wired connection isn't that bad but with other/slower devices we've seen that there's some room for improvement. I will join openmediavault forum soon to discuss stuff there. Especially that Armbian's cpufreq scaling settings get overwritten (/etc/defaults/cpufrequtils) is a bad thing since the settings OMV uses are ok for x86 boxes but not for those small SBC.
All quick tests looked good. I tried hard to destroy configurations on OrangePi Plus 2E, Banana Pi Pro, Clearfog Pro and Pine64+... but to no avail. Even nasty things like creating btrfs stripes on the command line (USB3+SATA with kernel 4.10) and then importing into OMV worked flawlessly, Armbian's nand-sata-install mechanism executed while OMV running to transfer the installation to a SATA disk worked and even downgrading the above btrfs stripe to 4.4.59 and moving the USB3 connected disk out of its enclosure and behind an ASM1062 PCIe SATA controller worked flawlessly (though performance sucks for whatever reasons). I'm pretty impressed by OMV
No need to fiddle around with the command line, everything can be configured through a browser... nice. This is how the interface looks like:
manuti reacted to tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA
Sure can you put NEO 2 onto that board, it's just a different front panel that's needed since for whatever reasons the Ethernet jack on NEO 2 has been moved by a few mm:
The enclosure is even large enough to add a 2nd 2.5" disk so maybe they come up with a different front panel, 2 better USB-to-SATA bridges, 2nd PCB to mount 2nd disk and sell this as 'NAS Box Plus' or something like that. The power design already relying on external 12V could be an indication.
Anyway if you want to use a NEO 2 with that box it's time for some 3D printing. And I still hope FriendlyELEC replaces the JMicron bridge with an UASP capable variant since users can add Gigabit Ethernet easily to the normal NEO too by spending another $7 for a simple RTL8153 dongle (performance numbers and information here: https://forum.armbian.com/index.php?/topic/1440-h3-devices-as-nas/)
manuti reacted to tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA
In the meantime FriendlyELEC provides something similar that is also much worse unfortunately:
It's an Expansion Board for their NEOs with DC-DC converter and an enclosure. Looks nice but a few details are awful:
According to their wiki page the USB-to-SATA bridge used is a JMicron JM20329 (designed for USB2, therefore lacking UAS capabilities. Insane when you think about that Allwinner SoCs with mainline kernel can make use of UAS even on USB2 ports. A JMicron JMS567 or JMS578 would've been a way better choice) This enclosure would've be the perfect choice to make use of NEO's design. Due to the SoC placement the enclosure could dissipate the heat to the outside by putting a simple thermal pad between SoC and enclosure. Putting a heatsink on NEO and both into an enclosure looks like a joke. On their product page (here or look at the picture above) you see that they talk about H3. Nasty since the H3 based NEO has only Fast Ethernet so it's a pretty bad choice for a NAS. The only NEO suitable for this use case fitting in that enclosure would be H5 based NEO 2. But on the other hand: if you're already bottlenecked by ultra slow network the crappy USB-to-SATA bridge doesn't matter any more. FriendlyELEC provides an OMV OS image ('OpenMediaVault' claims to 'make NAS easy', everytime I tried it performance was horribly low since the necessary parameter tuning hasn't been done -- I hope FriendlyELEC looked into this). This OS image is based on kernel 3.4.39! Are you kidding me? Why not mainline kernel for this? There's not a single reason to use a smelly Android kernel with this use case (no display and no audio) and especially not that outdated/unpatched 3.4.39 when there's a community patched 3.4.113 also available. I'm sure this thing will sell even if it will perform badly. And of course it's better than any Raspberry Pi based NAS but it's really sad that FriendlyELEC starts to target a clueless audience. If there would be a better USB-to-SATA bridge inside this thing combined with NEO 2 running mainline kernel and a custom OMV build that sets parameters correctly would make a great low-end NAS. Unfortunately we're talking about something different here
Screenshot showing kernel version used on their OMV build:
manuti reacted to tkaiser in Support of Raspberry Pi
As part of this I discovered that (64-bit kernel and userland for RPi 3 that should now also be useable on RPi 2 since newer models also use 64-bit BCM2387). And just for fun I will play around with this and maybe even publish a recipe how to build Armbian for RPi 3.
But I really really hope Armbian will never officially support Raspberries since this would be the project's dead (doing development for a platform where a mythical Foundation controls hardware's behaviour through something they euphemistically call 'firmware' we can't alter and dealing with an even larger userbase not caring about anything that's important -- if you buy a Raspberry you do it for a reason. The hardware is totally lame so there's other factors that attract people: and that's free support AKA large community besides the fairy tales a Foundation tells. Please leave this stuff where it belongs to: over at https://www.raspberrypi.org/community/)
manuti reacted to Igor in Winw for Orange Pi (PC+)
I actually tested on Opi PC+ with 4.10.x but it was crashing all the time. I didn't investigate why, while on XU4 it was working. Linux i386 applications were working good while apps under Wine also, but they had some strange refresh. Usable, but still need some work.
I started to talk with Eltech folks to see if something can be done to ensure better support on Allwinner boards.
manuti got a reaction from Naguissa in Winw for Orange Pi (PC+)
You need to buy an Eltechs license I think this type: Eltechs ExaGear Desktop for ARMv7 devices and after installing ExaGear intall inside WINE and inside of Wine the Windows software.
I do some test https://raspberryparatorpes.net/instalacion/probando-exagear-emulador-x86-sobre-arm/
but for me is only usable under ODROID-U3 quad core 2GB RAM and eMMC memory.
manuti reacted to zador.blood.stained in Orange Pi Zero Plus 2 available
WTF? There are both H3 and H5 based Zero Plus 2 on sale by Xunlong:
manuti reacted to tkaiser in Orange Pi Zero Plus 2 available
Ahem, yes. I agree. I've to admit that I've not decided whether the same name for both boards is just worse or the H5 variant now being called 'Zero Plus Ultra 2' could even be worse. At least the whole naming scheme is already f*cked up to the max
manuti reacted to martinayotte in How to Get Python Shutdown GPIO/Button Script to Start at Boot on Orange Pi Zero
When adding any thing in /etc/rc.local, you need to make sure it done as a subprocess, not block /etc/rc.local from exiting.
So, you should call your script similar to :
nohup /usr/bin/python /root/hw_shutdown.py &
manuti reacted to jernej in RK3328 Kernel
No need to depend on board maker support, because official Rockchip version should work pretty well and basically all drivers are mainlined anyway.
Yes, it is possible, but I'm not sure how easy or interesting it is. If it is based on reference design, then yes, it is matter of hours for some who knows DT stuff. Another issue is how hard to find or extract is manufacturer dtb file. I doubt that they provide schematic. It is also the question if it is worth the effort.
I guess it should be similar enough to some existing board which has support already manilined. The biggest difference between the boards I saw is which power management chip is used.
manuti reacted to tkaiser in RK3328 Kernel
Nope, not interested in RK3288
Your small chip is one of the reasons (since it's an Terminus USB2 hub, so 'shared bandwidth' which is kinda boring):
Regarding GbE I doubt further tests are needed (since the GbE MAC is inside the SoC and combined everywhere with an external RTL8211E PHY). If you destroy settings or at least don't care about those then you end up with something like this while everyone else reports 930-940 Mbits/sec (most probably that's iperf in 'duplex mode' vs. unidirectional -- that's always the mess with numbers flying around on the internet, without the exact test setup also mentioned they're always just 'numbers without meaning' ).
Edit: As usual with Gigabit Ethernet... settings matter: http://freaktab.com/forum/tv-player-support/rk3288-devices/21530-poor-wired-network-rate-with-rk3288-board?p=395824#post395824
manuti reacted to tkaiser in H3 board buyer's guide
H2+/H3/H5 boards overview (2017/03 update)
Since it has been a while since this topic has been updated and a lot of new boards have been released in the meantime it's time for a new overview.
I'll add also H2+ and H5 based boards since in the meantime we learned that those SoCs are pin-to-pin compatible and recently vendors started to simply exchange H3 with H5 on some PCB (and vice versa in at least one occurence). From a software point of view H5 is quite different (using 64-bit Cortex-A53 CPU cores and ARMv8 instruction set, some early boot stages are also totally different compared to Cortex-A7/ARMv7 used in H3 and H2+) and it should also be noted that Armbian currently only provides OS images based on mainline kernel for H5 boards (so please forget about HW accelerated video decoding or 3D for now or maybe ever since none of the developers is in the mood to deal with Allwinner's BSP/legacy kernel for H5 (regarding 'BSP' just look above in post #2).
While software support for H5 is currently somewhat different hardware features are pretty much the same as with H3 (still 3 to 4 real USB2 host ports and one USB2 OTG port: a simple register setting can switch the Micro USB port's PHY between the so called 'musb' controller used for OTG and a real EHCI/OHCI controller pair: with mainline kernel it will soon be possible to switch OTG to a real 4th USB2 host port with full feature set that still has not to share bandwidth with any of the other USB ports).
CPU performance with H5 compared to H3 is slightly higher at the same clockspeed but some workloads that benefit from either 64-bit or ARMv8 instruction set are significantly faster (eg. software making use of NEON instructions might perform almost twice as fast and the best example is the stupid 'sysbench' CPU pseudo benchmark which shows over 10 times better scores on the same hardware when compiled with ARMv8 settings).
In the following list I will also introduce some subjective 'categories' to deal better with the huge amount of boards we can use in the meantime:
NAS category: these are the H3/H5 boards with Gigabit Ethernet IoT category: these are the small and cheap boards best suited for low consumption 'General purpose' category: all the other H3 devices, these are also those you should look for if you want a cheap device to run with X11, OpenELEC, RetrOrangePi or Lakka since they all feature HDMI and full legacy kernel support As already said the differentiation is subjective and partially misleading since new boards like NanoPi NEO 2 featuring Gigabit Ethernet are also that inexpensive, small and energy efficient that they could serve both as NAS and IoT nodes (actually you can somewhat control behaviour since GbE vs. Fast Ethernet makes a pretty huge difference in consumption so it's up to you). Boards that might fit in multiple categories are listed more than once to make comparisons more simple if you're only interested in a specific device category:
NAS category (only due to Gigabit Ethernet available):
Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi PC Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB fast eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi IoT category (cheap, small, energy efficient, most of them headless):
NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Some important notes:
The following boards are listed in more than 1 category due to advanced feature mix: NanoPi NEO 2, NanoPi NEO Plus 2 and OrangePi Zero Plus 2 H3/H5 CE/FCC certifications: Please check individually and don't trust in logos silkscreened on the PCB, even if it looks like 'CE' it might mean 'China Export' instead IO bandwidth: H2+/H3/H5 SoC features 3+1 USB2 ports but on a few boards an internal USB hub is used so while these expose more USB receptacles some ports have to share bandwidth. Also on these boards a buggy/slow GL830 USB-to-SATA bridge is used. Search for 'hub' above to identify them. eMMC: shows most of the times higher random IO performance compared to 'the average SD card', but some vendors use pretty slow eMMC on their boards (Xunlong being the exception with OPi PC Plus, Plus, Plus 2, Plus 2E and Zero Plus 2). Please do not overestimate eMMC -- there's no need to choose crappy/slow SD cards and if you follow the usual recommendations difference in performance varies not that much (for example eMMC on most boards shows pretty low sequential write speeds that will be easily outperformed by any good SD card and differences in random IO don't have to be that huge, simply watch out for SD cards showing A1 or even A2 logo) USB ports: Some of the IoT devices have two of the SoC's USB host ports available on a pin header to be used with soldering or combined with various Docks, HATs or 'Expansion boards' (search for '1+1+2' above). On OPi One/Lite the unexposed USB host ports are available at pretty tiny solder pads so only usable with a lot of soldering experience Wi-Fi/BT: all boards providing both Wi-Fi and BT rely on Ampak's AP6212 so performance is identical, the Wi-Fi only boards either rely on RTL8189ETV/8189FTV (slightly better Wi-Fi performance than AP6212) or Allwinner's XR819 (so expect low Wi-Fi performance with OPi Zero or NEO Plus 2 since implementation is low-end and currently driver sucks) Yeah, each vendor's naming scheme totally sucks. Partially there are rules involved (the 'Plus' then means eMMC with Xunlong or GBit Ethernet with FriendlyELEC... mostly) but please don't trust in and check always individually!
And now another few words on a different technical detail affecting both performance and thermal behaviour of the various boards: Voltage regulation / DVFS. TL;DR: the SoC can be fed with a variable voltage (VDD_CPUX), the lower the voltage the lower the temperature (less problems with heat/overheating), the higher the voltage the higher the maximum CPU clockspeed. So the best idea is to adjust this dynamically (low voltage/clockspeed when idle and only increasing both when needed). There are 3 variants to implement this: not at all, primitive or advanced (using a voltage regulator that's able to adjust VDD_CPUX in 20mV steps)
Only 3 devices implement no voltage regulation at all: Banana Pi M2+/EDU (frying the SoC constantly at 1.3V therefore prone to overheating), Beelink X2 (no idea) and NEO 2 (only 1.1V therefore limited to 1008MHz cpufreq max since above instabilities might occur). Some boards use SY8106A I2C accessible voltage regulator where we can use fine grained voltage settings (Armbian fine-tuned these for every board so far to achieve max performance). This applies only to the following Xunlong boards: OPi PC, PC Plus, PC 2, PC 3, Plus, Plus 2 and Plus 2E. All other boards implement a simple two voltage scheme and are able to switch between 1.1V (up to 912MHz possible with H2+/H3 or 1008MHz with H5) or 1.3V (1.2GHz max with H2+/H3 and 1.25GHz with H5) And finally to add some stupid rankings: the cheapest board is from Xunlong (Orange Pi Zero: $7), the fastest is from Xunlong (Orange Pi PC 2 for $20) and the one with best feature set and onboard peripherals is also from Xunlong (Orange Pi Plus 2E: $35). And that's only due to OrangePi PC 3 Prime still not being released at the time of this writing (since otherwise regarding both performance and features this specific Xunlong board... )
Hope that helps
Edit: OPi 3 is now known as OPi Prime and (almost) nothing has changed compared to the leaked pictures back from last August.