manuti

Based on a quick discussion with @Xaliustoday I think we should overthink Chromium (non) sandboxing. Currently we use --no-sandbox which removes several layers of protection: https://chromium.googlesource.com/chromium/src/+/lkcr/docs/linux_sandboxing.md
 
With enabled sandboxing we run in troubles on arm64 platforms since for whatever reasons there Seccomp-BPF doesn't work. Potential workaround: Disabling this similar to this commit for A64 legacy: https://github.com/ayufan-pine64/linux-pine64/commit/7a78cc22d6a4b79feedc821c9514da59dc3f19de
 
In the end chrome://sandbox should show the first 3 in green and the last 2 in red only:

 
Any objections against removing '--no-sandbox' from default settings affecting arm64 kernel configs for Pine64 and ODROID-C2 currently?

To elaborate on this only for now. My main concern is 'communicating clearly to end users what to expect'. On our download page only devices should be listed that receive 100% full support.
 
All other devices should be moved to completely separated 'Unsupported' page. The devices listed here fall into the following 3 categories:
 
'Phased out': support has been removed for documented reasons (applies to those A20 Orange Pis and the two S500 devices now). Latest OS images are still accessible but behind a nag screen where people have to accept that support requests are ignored and support threads even deleted without replying (at least they clicked 'I agree' once). 'Work in Progress': these are the boards we're currently working on but that are not ready, where every question 'why not worky?!' is just useless and a waste of time. Preliminary or even nightly OS images are accessible but behind a nag screen where people have to accept that support requests are ignored and support threads even deleted without replying (at least they clicked 'I agree' once, we should add the 'nightly' motd disclaimer to .wip boards too) 'Not supported': these are the boards people would think will be supported by Armbian (soon) but won't. This is the process of a short discussion in development forum which ends up in a file below https://github.com/armbian/documentation and a link to the initial thread. This page clearly documents the reasons why there's no support for the board (not worth the efforts since support nightmare due to crappy Micro USB, vendor not releasing complete schematic, only crappy BSP available and so on  
The last category is the most important one for me since it allows us to document decisions and maybe even to change vendor behaviour (providing schematics earlier, becoming more cooperative).
 
How do we do today? A hardware vendor sends out a bunch of dev samples and we start like brain damaged retards immediately to work on getting all these boards supported in Armbian even if it makes no sense at all. For example OPi Zero Plus H5. For Xunlong it makes no difference to feed the reel with H3 or H5 SoCs and to push out boards with a slight price difference all running a 32-bit Android they already have from Allwinner. For whatever reasons (desktop replacement the only possible on this design) people buy these boards. But running a 64-bit distro especially with X on this limited device is just stupid with only 512 MB DRAM. So at least three reasons against: Armbian support would be stupid, Micro USB and high expectations combined with unreliable powering create a support nightmare. No thanks.
 
Since while supporting such devices might be absolutely wrong but board bring up could be fun we could treat these devices simply as 'WiP forever'. They just remain on the unsupported page marked 'Work in Progress' so software can be improved, support requests happily ignored and once something changes we could rethink and move the board to supported section (BTW: Having download statistics from dl.armbian.com as well as torrent tracking would be great to help with decisions regarding user acceptance)
 
To me it's really important to list devices we'll most probably never support on a page just to document this clearly, list requirements (so vendors looking this up could improve eg. providing schematics earlier) and maybe even educate users (what to look for prior to an impulse buy). We'll soon get more H3 boards with H5 instead (since it's that easy to exchange the SoC) and I really don't see why we should automatically support them since software support for H3 and H5 is somewhat different and higher memory requirements of a 64-bit distro render use cases useless.
 
Also we face SBC customers who were tricked into believing they buy 'upgrades'. This applies to eg. 'Cubieboard 6' (Actions Semi S500 --> no way at least for now) or the so called 'BPi R2' many users believe would be just an enhanced R1 version eliminating the many design flaws of R1 and being somewhat compatible. But it's a whole different product using a new SoC from a manufacturer that started just recently to become somewhat open (MTK guys now even send patches upstream so maybe in 2018 we can talk about R2 again then running with mainline only). But R2 customers have not the slightest idea how crappy software situation for R1 was in the beginning and that unlike R1 they can't expect any improvements with R2 since there's no community around this time. This needs to be clearly documented so people might get actual results when doing a web search for 'bpi r2 armbian'.

My proposal for removal:

https://www.armbian.com/orange-pi-mini/ (limited edition, no samples, never sold)
https://www.armbian.com/orange-pi/ (limited edition, no samples, never sold)
https://www.armbian.com/lemaker-guitar/ (no development for some time, design flaws, no mainline)
https://www.armbian.com/roseapple-pi/ (no development for some time, design flaws, no mainline, never sold)

Somewhat off-topic here but a great way to say thank you is to support Armbian in practical ways, eg. seeding Torrents: 
This is smallest OPi Zero seeding 24/7 our torrents since few weeks (33% of the 256MB used, consumption below 700mW running off a 128 GB Samsung EVO)
 
 

So many thanks for your images, now running OMV_3_0_71_Bananapipro_4.10.12 after a weekend of restoring and resetting my first armbian deploy ... many time ago.

Here is a short instruction how to enable S/PDIF digital audio output on NanoPI M1 board running Debian Jessie with legacy kernel.  This instruction can be applied to other H3 based boards but connect S/PDIF output hardware to GPIOA17 can be tricky (soldering miniature camera connector pins). Operations can be done over serial console or ssh.   Login as root Get a .fex file and open it in editor: bin2fex /boot/script.bin /tmp/script.fex nano /tmp/script.fex Search a csi0 (camera) section an disable it: [csi0] vip_used = 0 Search a S/PDIF section and enable it: [spdif0] spdif_used = 1 Get the name of the file pointed by the /boot/script.bin link and convert modified .fex to it: ls -la /boot/script.bin ----- /boot/script.bin -> bin/nanopim1.bin fex2bin /tmp/script.fex /boot/bin/nanopim1.bin Open /etc/modules to instruct Jessie to load S/PDIF modules at boot: nano /etc/modules Add module names near the end of file: sunxi_spdif  sunxi_spdma   sndspdif   sunxi_sndspdif Reboot system: sync reboot After reboot login as root again Get the list of ALSA devices available: aplay -l **** List of PLAYBACK Hardware Devices **** card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC sndcodec-0 []   Subdevices: 1/1   Subdevice #0: subdevice #0 card 1: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 []   Subdevices: 1/1   Subdevice #0: subdevice #0 card 2: sndspdif [sndspdif], device 0: SUNXI-SPDIF sndspdif-0 []   Subdevices: 0/1   Subdevice #0: subdevice #0  
To connect board S/PDIF output to my favorite DAC i use an optical S/PDIF module soldered out from dead DVD player:
 

 
There are 3 wires connected to board 40-pin connector: GND (pin 6), VDD_5V (pin 2) and SPDIF-OUT/GPIOA17 (pin 26)
 

 
Module pinout can be found in datasheet http://www.mouser.com/catalog/specsheets/totx177(f,t).pdf
 
Modules come in 2 types: 6-MBit (up to 24 bit / 96KHz) and 15-MBit (up to 24 bit / 192KHz). Most likely from DVD or SAT receiver You get the 6-MBit module. 15-MBit modules can be purchased at Digikey, etc.
 
When listening to music, I faced with spontaneous fadings. This is due to some problem of the CPU speed switching. To this do not happen, I banned the clock frequency of 240 MHz in the /etc/default/cpufrequtils:
MIN_SPEED=480000

Any of you have such a beautiful problem?
They like Orange Pi's, they are hot !
 
 
 
 

Yes, keeping them out when soldering is a must.
Jumper cables, LED's, buttons, sensors - no matter what I plug - they are "game" (in both meanings).
And I need to recheck breadboards in every test run.

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.

So to start dealing with your problem in a somewhat logical way:
We're talking about JMS561 and not ASM1153E here, right? Since calling smartctl -d sat manually for this Cloudshell 2 gimmick provides 1) the data but 2) doesn't trigger USB resets it seems the way OMV does SMART queries could be responsible (then this is clearly the wrong forum since OMV people could tell without doing research first) Hardkernel guys unfortunately don't give a sh*t about upstream support for their products (no reports of problematic UAS bridge chips to linux USB kernel maintainers, same with those shitty Seagate enclosures and evaluating whether Exynos 5422 USB3 host controller needs quirks). This means: no support in smartmontools for JMS561. What you could do:
Add JMS561 to /var/lib/smartmontools/drivedb/drivedb.h as outlined in http://forum.openmediavault.org/index.php/Thread/17855-Building-OMV-automatically-for-a-bunch-of-different-ARM-dev-boards/?postID=145278#post145278 (possible result: OMV trying 'smartctl' first without any of the '-d' modes avoiding the USB resets here) Try to figure out how OMV does SMART queries (mv smartctl binary to smartctl.orig, replace smartctl with a script that logs calling parameters) Check smartctl manual page for possible -d values and try them out one after another (since my guess is that OMV will exactly do that when dealing with devices that lack support as it's obviously the case with JMS561 here, so maybe the USB resets happen since OMV tries 'smartctl -d jmicron' or whatever) BTW: I can't provide more help here since I dropped the idea of using ODROID-XU4 as NAS already (especially when combined with the Cloudshell gimmicks). For me a NAS has to be reliable and the list of potential problems with ODROID-XU4 has became too long in the meantime (and to be honest: Hardkernel's role here has been a bit too underwhelming)
 

On 1st generation Raspberry Pis (A and B -- the later models fixed that) under-voltage can directly cause data corruption. And then you can always get counterfeit SD cards. If you keep those two issues in mind (and fix under-voltage which is possible even with Raspberries and their shitty Micro USB DC-IN connector by using appropriate cables and test for counterfeit/fake SD cards) you can run Raspberries and every other SBC from SD cards just fine. Please read through whole thread over there: http://tech.scargill.net/a-question-of-lifespan/#comment-33659

armbian-config - wireless network connect,
- AP (hotspot) in bridged or NAT mode,
- freeze and unfreeze kernel and BSP upgrades,
- edit boot environment, network, FEX, welcome screen items,
- switching between available kernels and nightly builds,
- enabling read only root filesystem (Ubuntu only),
- set display resolution (H3 boards with legacy kernel),
softy - TV headend (IPTV server)
- Syncthing (personal cloud)
- SoftEther VPN server (VPN server)
- Transmission (torrent server)
- ISPConfig (WEB & MAIL server)
- Openmediavault NAS (NAS server)
- PI hole (ad blocker)
- MiniDLNA (media sharing)
 
Welcome to submit / push your modifications if you think they are interesting for general public.

EDIT: Hardkernel explains various issues with Cloudshell 1 and 2. And another one: USB reset issues with Cloudshell 1 explained.
 
I thought about opening a new thread but since this is just a list of known issues most probably OMV users will run into I'll add it to this thread. As follows the list of problems with ODROID XU4 when used as NAS especially when combined with Hardkernel's Cloudshell 2 gimmick:
 
1) Everything is USB here. Gigabit Ethernet on XU3 is provided by an internal ASIX AX88179 USB chip while Hardkernel replaced this with the somewhat better RTL8153 on ODROID XU4. This is not necessarily bad especially since Gigabit Ethernet bandwidth can be fully satured but amount of interrupts to be processed as well as latency are higher than necessasry. Also it seems that general USB problems on other ports (cable somewhat loose) affect network stability (see this report here for both available kernels)
 
2) The other USB3 port of the Samsung Exynos 5422 SoC is connected to an Genesys Logic GL3521 USB hub on the PCB showing up in lsusb output as 05e3:0616 (XHCI/USB3) and 05e3:0610 (EHCI/USB2). This is not necessarily bad as long as you simply ignore one of the two USB3 receptacles and connect 1 disk only. Performance when accessing two disks in parallel sucks (as it's always the case when hubs are involved). These are two Samsung SSDs in two UAS (USB Attached SCSI) capable enclosures running as RAID-1:
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M |__ Port 1: Dev 5, If 0, Class=Mass Storage, Driver=uas, 5000M |__ Port 2: Dev 6, If 0, Class=Mass Storage, Driver=uas, 5000M random random kB reclen write rewrite read reread read write 102400 4 14197 15286 15750 16128 14502 14419 102400 16 38999 39800 48671 51743 45884 39061 102400 512 50223 51847 111445 160264 157900 60487 102400 1024 50706 48524 141865 162106 160770 50088 102400 16384 48546 50328 218430 221731 221526 47258 Performance is worse than a single SSD being accessed (as expected -- you always try to avoid USB hubs between disks and host) and also problems are reported by users, for example search for 'USB HDD connected as USB2 device' here: https://forum.odroid.com/viewtopic.php?f=146&t=26016&start=50#p187838 (for whatever reasons only the EHCI part of the internal GL3521 hub is coming up cutting the SuperSpeed data lines to the ASM1153E and so the user in question ends up with an USB2.0 data connection (Hi-Speed and not SuperSpeed). As usual UAS will be blamed for this problem but is totally unrelated.
 
3) Adding to this already somewhat fragile situation the USB3 receptacles are known to cause trouble. Please see here and here and problem 1) I reported here yesterday:  My problem could be solved by exchanging the USB cable/plug: the one I used later and with another disk enclosure before fits more tightly. Warning: If you ever connect something to any of the USB3 ports of an ODROID XU4 ensure that the USB plug and receptacle fits 100 percent (some force should be needed to insert the plug) otherwise you'll run for sure into troubles. Symptoms may vary, in my case the disk did not even mount but it's also possible that this works and you run later into troubles when accessing the storage. In case you use an UAS capable disk enclosure be aware that dmesg will show messages mentioning 'uas_eh_abort_handler' since this driver is dealing with the mess. Again this is totally unrelated to UAS, it's just this driver reporting hardware troubles now.
 
4) Underpowering issues: see problem 2) reported here yesterday: https://forum.odroid.com/viewtopic.php?f=146&t=26016&start=150#p190909 (or here).
 
After I ensured that USB cable and receptacle fit tightly I ran a benchmark and after some time problems occured ('uas_eh_abort_handler' showing up in dmesg output). UAS is still not the cause for this problem but UAS might be related since with UAS communication between host and disk gets way more efficient and as such power requirements increase too. So with this XU4 powered 2.5" SSD UAS triggers the underpowering issue while the same SSD might run fine without UAS (Mass Storage / Bulk Only) or on an USB2 bus (less efficient protocol --> lower power requirements).
 
I use these JMS567 based 2.5" disk enclosures since years with a variety of SSDs and 2.5" HDDs on powered by USB3 ports of various Macs and never encountered problems (except of an EVO750 with rather high peak consumption when being powered on). To confirm I used the same EVO840 in the same JMS567 enclosure powered by my MacBook Pro only (sytem_profiler reporting 'Current Available (mA): 900') and ran a quick but demanding benchmark there too:
 
I don't know whether that's just the combination of my XU4 with this enclosure (a different ASM1153 based worked fine powered by XU4 only) or a more general problem. The reason why I list this is since it looks like 'yet another UAS problem' but it's only partially related due to higher efficiency triggering potential underpowering problems earlier. This very well known problem has been described by one of Linux' USB gurus here already and gets happily ignored since then: https://github.com/hardkernel/linux/commit/c18781b1ef56a800572e8342488504e4e818013a#commitcomment-21996557
 
5) potential USB3 host controller issues as outlined by Hans de Goede in the aforementioned link maybe needing a two line patch to add another quirk. Status: no one cares about.
 
Can it get worse? By adding a Cloudshell 2 you might avoid problem 4) above but might still suffer from 2) and 3) and add a bunch of new problems:
 
6) On the first batch of Cloudshell 2 units Hardkernel simply forgot to flash a serial number. Problem reported here, fix there, workaround added in latest OMV image so please ensure that you're using OMV 3.0.76 image or above if you use a Cloudshell 2.
 
7) Using a Cloudshell involves connecting an USB cable between one of XU4's USB3 ports and the Cloudshell PCB. So you can run into issue 3) -- USB3 receptacle crappiness -- above at any time (now or later, just adding some vibrations might break your whole storage setup if USB plug fits not absolutely perfect -- some force should be needed to insert the plug). Here a user reports 'UAS issues': https://forum.odroid.com/viewtopic.php?f=146&t=26016&start=150#p191018 that are obviously none but will just be reported differently after disabling UAS https://forum.odroid.com/viewtopic.php?f=146&t=26016&start=150#p191082 (of course you can't fix USB connection or cable issues with different drivers and also of course we can't blame users for reporting random erratic behaviour as 'UAS issue' since they don't know better, shouldn't be experts and are even victims of an insanely stupid 'UAS is broken' campaign still running over at ODROID forums).
 
8) Cloudshell 2 uses a JMicron JMS561 USB RAID chip which is said to rely on JMS567 for the USB-to-SATA bridge functionality. JMS567 needs specific quirks to work flawlessly with UAS, (see here for an example how this is diagnosed/developed and how to proceed with a new device), JMS561 has a different USB product ID so the quirk will not be applied (but is maybe needed). Status: no one cares about.
 
9) The JMS561 on Cloudshell 2 can work in various modes: two stupid RAID variants, Span (adding capacity of two disks) and JBOD ('just a bunch of disks' so 2 disks can be accessed individually -- no idea how that's achieved in this mode, maybe someone can post 'lsusb -t' output with 2 disks inside the Cloudshell 2 and JBOD mode in this mode two disks appear as one USB device node but as different devices since JMS561 acts as a SATA port multiplier here). Depending on what you choose you might get different or no SMART data from connected drives. JMS561 is also missing from smartmontool's drivedb.h (so you get just an 'Unknown USB bridge [0x152d:0x0561 (0x8037)] if you're not forcing smartctl to make use of SCSI / ATA Translation. Status: no one cares about.
 
10) The Cloudshell 2 LCD is currently used to display some fancy data instead of useful information (highest peak temperature since last reboot, CRC errors occured, LCC increasing too fast, firmware updates available for attached disks or SSDs, any signs of connection errors according to dmesg and so on). The software support is provided by a Hardkernel employee (using his private Ubuntu PPA). First version showed efficiency problems (also increasing idle temperatures/consumption) but this should be fixed in the meantime so please ensure to either run 'apt upgrade' on the command line or use OMV's 'Update Management' menu item.
 
11) Cloudshell 2 in most modes (RAID-0, RAID-1 and Span) currently doesn't provide vital SMART health data for drives. They're only available when using PM/JBOD mode (PM means port multiplier -- since JMS561 product brief doesn't mention switching method I would assume that JMS561 only implements the slow CBS mode and not FIS based switching). Details regarding SMART (let's hope Hardkernel gets in touch with JMicron and can provide a fix for this but this would require flashing a new firmware to JMS561 anyway): http://forum.openmediavault.org/index.php/Thread/17855-Building-OMV-automatically-for-a-bunch-of-different-ARM-dev-boards/?postID=144752#post144752
 
12) Even in PM/JBOD mode SMART is broken and needs a Cloudshell 2 firmware upgrade (the Cloudshell 2 gimmick fails to do 'SCSI / ATA Translation' correctly which leads to USB resets)
 
13) It seems no quality control happens. This is both somewhat surprising and inexcusable. We're talking here about a combination of SBC and an add-on sold and produced by the same vendor that is advertised as a complete NAS solution. The cable connecting both pieces and being part of the add-on product is one of the most crucial parts since this NAS kit doesn't rely on reliable storage implementations ('reliable' includes design of connectors, protocol implementation and monitoring possibilities) but USB instead. Real storage protocols implement some sort of error detection mechanism (CRC -- cyclyc redundancy check) and provide occuring mismatches as counter (with SATA it's SMART attribute 199). But this CRC counter only reports data corruption between SATA host controller and drives, in Cloudshell's case that's the JMS561 on Cloudshell PCB connected directly to the drives without cables in between. Data corruption due to defective USB cable or USB plugs not fitting perfectly into the receptacle are not handled at this low layer. They're reported at a higher layer and if you see them your filesystem is most probably already corrupted (check dmesg output for either 'I/O error' or 'uas_eh_abort_handler' since the messages vary depending on whether UAS or the older Mass Storage protocol is used)
 
BTW: These are SATA connectors and a 'Mini SAS to SATA breakout cable'. Guess why there are metal latches on each end of the cable:

Just for the record: a more appropriate comparison would be Orange Pi PC Plus vs. Plus 2E since both share most details, eg. RTL8189FTV Wi-Fi and same type of eMMC (Xunlong uses even on the PC Plus pretty fast Samsung 2-bit MLC eMMC while SinoVoip for example on all recent Bananas uses way slower 3-bit TLC eMMC). For $13 more you get 16 GB vs. 8 GB eMMC and twice as much DRAM on Plus 2E.
 
(on my wishlist is a H5 OPi Zero with 2MB SPI NOR flash presoldered, 2 x 4Gb DRAM chips (to get 1 GB using full 32 bit memory bandwidth), SY8113 voltage regulation switching between 1.1V and 1.35V (not 1.3V) with RTL8211E as GbE PHY. For $15  )

Well, maybe it's time to slow down (again) and do some research first? 
 
What do we 'know'? Chromium stability might be related to settings (I'm not sure whether this commit missing trailing double quote works or not -- tried to fix it yesterday but my whole commit has been reverted for good reasons). Firefox/arm64 stability might be related to... what? We don't know, we never explored (maybe it's extensive memory usage, maybe not). Installing armhf FF on arm64 blows up installation size by ~140MB. Also not that great. 
 
Based on the way we currently build images we could easily differentiate between armhf and arm64 at image creation time (not ideal from a maintainance point of view but at least we would get experiences/feedback on both browser variants). Luke shared some ideas how to improve FF performance here. And Zador outlined what needs to be done to solve storage performance dependency problems (cache/profile in RAM) in a more general way here.
 
I still wonder whether there's some sort of a 'real world' benchmark suite for webbrowsers on Linux (the usual benchmarks are crap since testing irrelevant stuff for our situation). Something like a script that can be used to instruct FF and Chromium to visit 10 defined web sites so we can measure performance, IO load and memory requirements (to get more ideas about armhf vs. arm64 on 64-bit platforms!). On macOS I would already be done but no idea how to do this with Linux

Thank you. Now this works surprisingly well with Chromium (with 'export XDG_CACHE_HOME="/var/log/.cache"' and /var/log/.cache created with 777 mode manually before):
root@pinebook:~# cat /etc/chromium-browser/default # Default settings for chromium-browser. This file is sourced by /bin/sh from # /usr/bin/chromium-browser # Options to pass to chromium-browser CHROMIUM_FLAGS="--disable-smooth-scrolling \ --disable-low-res-tiling \ --enable-low-end-device-mode \ --num-raster-threads=4 \ --disk-cache-size=314572800 \ --profiler-timing=0 \ --disable-composited-antialiasing \ --disable-seccomp-filter-sandbox" root@pinebook:~# cat /etc/default/log2ram # configuration values for the log2ram service # # enable the log2ram service? ENABLED=true # # size of the tmpfs mount SIZE=350M # # use rsync instead of cp -r # requires rsync installed, may provide better performance # due to copying only new and changed files USE_RSYNC=true  

Setting this improves everything a lot with FF, Midori and Chromium. But it's not a 'real' solution since this way most probably all available RAM will be eaten up over time unless the browsers have a configurable cache size. Also everything is lost after a reboot (so setting XDG_CACHE_HOME="/var/log/.cache" might be an idea since log2ram then does the job). 
 
I will stop now testing with the following results:
root@pinebook:/dev/shm/.cache# du -sh * 4.0K blueman-applet-1000 27M chromium 12K event-sound-cache.tdb.aab709d4dc8efb47e12e29ac5910e6a8.aarch64-unknown-linux-gnu 100K fontconfig 276K gstreamer-1.0 616K mate 3.6M midori 5.7M mozilla 0 obexd 0 tilda 4.0K webkit root@pinebook:/dev/shm/.cache# cat /etc/chromium-browser/default # Default settings for chromium-browser. This file is sourced by /bin/sh from # /usr/bin/chromium-browser # Options to pass to chromium-browser CHROMIUM_FLAGS="--disable-smooth-scrolling \ --disable-low-res-tiling \ --enable-low-end-device-mode \ --num-raster-threads=4 \ --disable-seccomp-filter-sandbox" With '--disable-seccomp-filter-sandbox' every time Chromium will be started a security/stability warning will appear with our current kernel config which might be better than fooling users by disabling sandboxing without notice? Then on Pinebook installation of this Extension is recommended: https://chrome.google.com/webstore/detail/no-mousewheel-zoom/ckhlfagjncfmdieecfekjbpnnaekhlhd
 
For anyone doing further testing I strongly recommend to always run htop and 'iostat 5' in 2 separate terminals in the background to watch for multithreading behaviour and Pinebook being bottlenecked by slow IO (or not when caches live in memory and not on slow storage). Testing with https://www.theguardian.com/international seems like a good idea (@Xaliusidea -- see today's http://irc.pine64.uk log)
 
BTW: using LZO compression my chromium cache folder shrinks only to ~75% so most probably it's useless to further explore ways to use compressed tmpfs. I did just a quick static test and already gave up on the idea.

Hello, folks. First of all, I really appreciate your efforts maintaining practical and powerful Armbian image for this board.
You, guys are the reason why I have returned my Banana Pi m2u back to the seller.
 
Today I got my Tinker in the mail.
 
I've installed Armbian 5.27 (stable) with kernel version 4.4.66, it is pretty smooth, and I'm not looking back for the BPi m2u.
 
Thank you very much!
 
I have attached a picture, of what I have found out, but you will surely know this already.
 
Tinker is running via SSH, hosting Pi Hole and some other network-based services. No GUI, no video acceleration required in my setup.
 
When connected to a Gigabit Network, I can write and read up to ~30MB/s to a Tinker-attached USB drive. (Compiled ntfs-3g latest stable 2017.3.22)
 
My question is, whether, and to what extent does the speed drop, when I do a copy to two drives connected to Tinker simultaneously.
 
I mean, USB/Ethernet bus is not shared, what is big pro. But its SoC has internally 3 USB hosts (info provided by dmesg, one of them is also OTG) and a USB Hub is connected to one of them providing us with 4 ports. The bandwidth of the USB drives would need to split between them because of the HUB. Can you agree on that?
 
In this scenario, I would copy a file to two network shares (Samba) simultaneously, the speed would drop to half. Resulting in 15MB/s for each drive. Have anyone tested this?
 
Also interesting is USB to USB transfer rate, since Ethernet is not involved in that process.
I mean, the USB 2.0 bus has 480Mbps of bandwidth, but ~30MB/s is about 250Mbps, so this is the real speed (overhead subtracted).
In addition, would be there any bandwidth free for the second drive in USB to USB scenario leading to the transfer rate to be the nearly same? Like if 130Mbps of 480 would be available to the second drive?
 
Again, thank you very much!
 
Edit: I have experienced following trouble: When copying at full speed (CPU usage is about 49%; Computer to Tinkers USB drive on Gbit LAN) it seems that the system has not enough internal bandwidth, or an ability to set an interrupt to be able to handle PiHole DNS.
Because of that behavior, pi hole does not get enough "CPU time" or whatever and does not resolve and forward a DNS address. I understand, it is busy by copying, of course, but it is be able to do multitasking, right? Since only 1/4 of total available Gbit speed is used by copying the data. It still should be able to do other network stuff.

Correct, the Tinkerboard as well as the MiQi show here another serious design flaw (Micro USB for DC-IN is the other): Not exposing one of the two available SoC's USB host ports and connecting all USB receptacles to the remaining host port via an internal USB hub. So if you want to connect anything bandwidth intensive forget about both highest performance (hub) and to use more than 1 USB port (shared bandwidth). For such use cases Tinkerboard is simply an overpriced fail
 
For any further tests you should switch to 'performance' (/etc/defaults/cpufreq) now since otherwise you get numbers without meaning anyway with kernel 4.4 (since so far no one knows which cpufreq tweaks Rockchip engineers implemented here)

After talking about "the crazy idea" of use of this boards like light desktops in other thread with @JoeyBeelinkX2 :
I start reading about ways to improve the performance.
In this way I find an alternative scheduler specially conceived by responsiveness of desktop use, is called MuQSS http://ck-hack.blogspot.com.es/2016/10/muqss-multiple-queue-skiplist-scheduler.html
I also find a kernel ready to use on x86 architectures (includes de MuQSS scheduler instead of CFS and BFQ instead of CFQ, while also adding more tweaks for responsiveness like proper QoS over TCP to avoid TCP congestion): https://liquorix.net/#install
And my final questions:
Can this kernel improve the Desktop performance or responsiveness? Can be included on the Desktop images?  

Hey guys,
 
Awesome news, our Kickstarter campaign is finally live. Be amount the first backers and enjoy our early bird deals :

Our kickstarter page :  Helios4
 
For some specs : Helios4_Specifications.pdf
 


Basic Kit - 1GB (USD$125)
(Save 16% off the $149 Retail - Limited to 50 units)

Full Kit - 1GB (USD$139)
(Save 18% off the $169 Retail - Limited to 130 units)

Full Kit - 2GB (USD$165)
(Save 11% off the $185 Retail - Limited to 70 units)
 
Our kickstarter page :  Helios4
 
Cheers ;-)
 

All this stuff run under old kernels and proprietary drivers and blobs. I'm agree with you about the slow response running Chrome (Chromiun) under armbian and the performance you can obtain using the same or equivalent Chrome under Android.
But is a matter of freedom, real freedom, vs a limited but good user experience.
 
This video is recorded using kazam https://launchpad.net/kazam on an Orange Pi One (only 512MB RAM) at the same time I use the system to show his capacities. Is not an intel Skull Canyon NUC http://amzn.to/2qR3YjY but can be useful in some scenarios.
 
 

All this stuff run under old kernels and proprietary drivers and blobs. I'm agree with you about the slow response running Chrome (Chromiun) under armbian and the performance you can obtain using the same or equivalent Chrome under Android.
But is a matter of freedom, real freedom, vs a limited but good user experience.
 
This video is recorded using kazam https://launchpad.net/kazam on an Orange Pi One (only 512MB RAM) at the same time I use the system to show his capacities. Is not an intel Skull Canyon NUC http://amzn.to/2qR3YjY but can be useful in some scenarios.
 
 

All this stuff run under old kernels and proprietary drivers and blobs. I'm agree with you about the slow response running Chrome (Chromiun) under armbian and the performance you can obtain using the same or equivalent Chrome under Android.
But is a matter of freedom, real freedom, vs a limited but good user experience.
 
This video is recorded using kazam https://launchpad.net/kazam on an Orange Pi One (only 512MB RAM) at the same time I use the system to show his capacities. Is not an intel Skull Canyon NUC http://amzn.to/2qR3YjY but can be useful in some scenarios.
 
 

I use a BeelinkX2 as a light/cheap desktop replacement, mainly because is the best way to manage my others headless ARM boards by SSH sessions. Sometimes I perform flac to mp3 conversions in this machine without worrying about heat, as long time ago say @tkaiser : H3 is not an animal or a human being that gets hurt by temperatures exceeding 40°C. It's a chip rated for up to 125°C  → 
Related to CPU throtling in the past I use some CPU desktop pluging monitor on Ubuntu but I d'ont know if working in this case: https://apps.ubuntu.com/cat/applications/quantal/indicator-cpufreq/
Also in the past I use on ODROID boards cpufrequtils like showed in this post: http://odroid.us/mediawiki/index.php?title=Use_cpufrequtils_to_Adjust_Processor_Settings