Search the Community

@tkaiserMan these numbers are absolutely awesome! Thanks for this first test to get an idea of this little piece of gold. I'm really looking forward to it to replace my current banana Pi (gigabit LAN and SATA) as my Seafile Cloud Server. Your thoughts about RAM sound sane. I guess 2GB will be enough for seafile and perhaps NAS altogether. What do you think about the capability to install armhf (instead of aarch64) software? Currently the Seafile server and some other stuff is mostly rpi2/3 compatible, which means it is armhf. I don't see any downside so far compared to aarch64. Ram usage is also lower with 32bit. I guess armhf stuff will be working on ROCK64 as well? In terms of USB3: As usb3 is specified to have a quite high capability of power supply... how would that be taken account by the ROCK64 board design? Any idea what the board might lift? I thought about bying a simple USB3toSATA bridge with UASP support and power a Crucial MX300 256GB without an external power supply (just leaving it away). Such an SSD should not consume too much, so I hope that the Rock64 USB3 port could handle it directly. Does anybody have something to say about the points I mentioned? On Topic: Somehow I totally feel you developers. You want to restrict development to worthy boards, which would also increase the quality of development for those few boards, because work is more focused. On the other hand I see boards like my old banana Pi and I really think that it would've never become what it is and as usable as it is without all your effort (which certainly started without much discussion before). From a user perspective it is a very hard topic that you discuss here. Obviously everybody in the community wants as much as possible. Unfortunately new builds/initial support matures after quite some time and then comes the breakthrough (which - sometimes - cannot be anticipated). Somehow it would also be a shame if nobody would even try to establish some initial support, thus nobody would know what the board is capable of :/. I really don't want to be in your situation to decide how this can be handled in the future. I'm just very thankful and happy that ARMBian was founded some years ago and that it became such a name in the ARM business About the ROCK64: One thing is clear: In my optinion the ROCK64 should be supported, as it combines so many good things. The interest is there, quite a few developers are working on it already, apparently. The more interesting is that two totally independent interest groups (ARMBian=Server/Cli aim and then the LibreELEC=Multimedia) show real interest and have put some effort already into it. This can push it very far and both camps can benefit one another. Really really great to see this!

I typically hate trying to figure out tutorials via forum after they've been around a while, things change, comments add info or other methods, then the OP isn't maintained. Also, diagrams and images are realistically impossible in this format. My thought would be to have the OP of a tutorial consolidate all of the useful information from ensuing discussion, make a document for the website, and stuff the thread into a locked archive bin linked to for reference in the finished tutorial. Or, alternatively, have the tutorial on the webpage, and link from it to the forum thread, and don't pin it. The info is on the webpage, discussion is as-needed on forum thread. There's a ton of useful info here, I was introduced to this project due to a search that led me to @Da Alchemist's post about getting I2S working on the H3 devices. That's also what I was thinking for pre-release/specific version support threads, lock/archive them once they're out of date (how out of date is obviously a discussion point). They disappear from cluttering the forum and keeping it on point, but we haven't deleted/removed anything, all can be retrieved for trace-ability purposes. (too many years in automotive, you keep all documentation and emails forever) Community would definitely be the place for TV Boxes, I've hesitated to build an image for the UT3S because I know the resulting torrent of requests that would follow... I've been trying to get the currently interested parties to try it out themselves. If RK3328 devices are the next "thing" with the Rock64 simply being first (and IF the team decides to support it), yes, a Rockchip subforum would be ideal. I like the "How To Use This Forum" bit, of course there are ~ 400k users and only ~190k views of that . At the very least it can be pointed at, giving the user every opportunity to do it the right way, making any moderation less surprising.

Time for a small '2017 follow-up' on this issue this time only focussing on 'disk performance' (HDD/SSD, not onboard storage like eMMC or SD cards). Since we all know that we don't need to differentiate here between individual boards but can look at board families (the SoC is the important thing) I only check the following 'families': cheap Allwinner stuff running with A64 or H5 (that's the Pine64 numbers below, H3 boards score a bit lower) Allwinner A20, R40 or V40 (that's the Banana Pi Pro numbers below, maybe random IO numbers look better with the R40/V40 boards but since those are only available from manufacturers also known as brain damaged retards that's not an option today) i.MX6 (Wandboard Quad, not supported by Armbian but a few other boards using the same SoC) Exynos 5422 (ODROID XU3 or XU4) RK3328 (ROCK64) Armada 38x (Clearfog Pro, same numbers will apply to Turris Omnia, Clearfog Base or Helios4 soon) Why are all other boards missing? Since uninteresting if it's about storage. SATA or USB3 are a must, the only exception below are the UAS capable USB2 Allwinner devices since they show a few more MB/s sequential throughput and way better random IO numbers compared to USB2 solutions that only support the old/anachronistic USB Mass Storage mode. All tests done with Samsung EVO SSDs (my EVO840 used for all tests except of the ODROID-XU4 results which were made with a much faster EVO850 instead and Pine64 numbers with a slower EVO750 so random IO numbers should be multiplied with 1.3 or even 1.4): Random IO in IOPS Sequential IO in MB/sec 4K read/write 1M read/write Pine64 (USB2/UAS) 2260/1948 42 / 41 Banana Pi Pro (SATA) 3943/3478 122 / 37 Wandboard Quad (SATA) 4141/5073 100 / 100 ODROID-XU4 (USB3/UAS) 4637/5126 262 / 282 ROCK64 (USB3/UAS) 4619/5972 311 / 297 Clearfog Pro (SATA) 10148/19184 507 / 448 Testing methodology is somewhat wrong but I refuse to waste much of my time to do proper benchmarking since it's only about getting the idea what to expect. So as a summary: USB2 SBC that lack UAS capabilities are simply too slow to be even listed here UAS capable cheap Allwinner USB2 boards show ok-ish performance for low-end setups (think of NanoPi NEO2 as NAS for example) SBC featuring 'real SATA' have to be differentiated. Armada 38x shows top performance like x86/x64 boards, i.MX6 is somewhat ok, A20/R40/V40 simply suck (you better don't buy this crap any more) USB3 SBC like ODROID-XU4/HC1 or ROCK64 show way better performance. You only have to take care of the USB downsides (XU4 with an internal USB hub and receptacles problems is in a bad position here) and ensure that you're using good USB-to-SATA bridges to connect SSD or HDD If we also take price/performance ratio into account then ROCK64 or other RK3328 boards that will follow are really hard to beat. The 1GB ROCK64 variant will most probably stay below the $25 margin and you should keep in mind that more DRAM is pretty useless if you think about (NAS) performance. Only on devices where IO throughput is way lower than network throughput having more DRAM as needed might improve NAS write performance if settings are appropriate (since then amounts of data that fit into RAM will be written at network speed and flushed later to disk)

XU4 easily outperformed by my new arrival ROCK64. Testing with an Samsung EVO840 (the same as above) with ext4, UAS enabled, a 4.4.70 kernel (ayufan build) and an external JMS567 disk enclosure: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 19727 23938 25879 24231 18475 23886 102400 16 67302 80160 87210 87008 68301 79484 102400 512 278860 292958 292461 301834 292974 291585 102400 1024 297825 310695 313499 324097 316276 313253 102400 16384 325951 330928 340258 351640 352109 323207 That's sequential write performance of +325 MB/s and read even better at ~345 MB/s. So now let's wait and see how pricing will look like (I guess we get the 1GB variant for less than $25). Debug log here (I simply used arm64 OMV rootfs from ODROID-C2): http://sprunge.us/HURC

I forgot: root@rock64:/mnt/sda# uname -a Linux rock64 4.4.66 #1 SMP Sun Jun 11 16:46:11 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux root@rock64:/mnt/sda# lsusb -t /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M This is an outdated ayufan build from 2 weeks ago. UAS already working but maybe needing quirks (see ODROID-XU4) Edit: Better SSD, better numbers: https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34185

This is ROCK64 specific. New board with correctly working USB3 arrived 10 minutes ago. Switched to performance governor and doing the usual 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' with the slowest SSD I have lying around (Intel 540): random random kB reclen write rewrite read reread read write 102400 4 10794 14075 18413 14337 12084 13125 102400 16 38316 48250 58929 50123 33636 44383 102400 512 85148 113573 217972 226149 209220 229556 102400 1024 239054 254531 226798 261436 240226 213082 102400 16384 271696 291983 316979 323006 282067 292218 In other words: this is the new single drive NAS board. Forget about overpriced fails or slow A20 boards or their R40/V40 successors currently only available from brain damaged retards.

I still have a problem with this. Because these devices are from China, and the manufacturer can change the board at any time. Maybe rev. 1 of the board was great, but they found a way to lower the cost (say, replace the WiFi module with a cheaper version, or replace EMMC with worse version) and rev. 2 is a pile of garbage. Just look at the OpenWrt/LEDE wiki if you want to get an idea of all the stupid things companies will do to lower cost and raise profit. Reduce memory size, reduce flash size, change chipsets entirely. I know this isn't very likely on these SBCs, because companies will just release a new version, but we have seen board revisions before (e.g. early Orange Pi Zero shipped without any SPI flash). Saying "Certified/Recommended for X" is a trap, because as soon as the company revises the board and breaks something, people will come here and complain, so you don't want to go there. I would go so far as to say if a manufacturer releases a new revision of the board which breaks the build, then we stop supporting the board. I would rather it go something like "Compatible with Orange Pi Zero Rev 1" or something which doesn't sound like a guarantee. Certified/Recommended to me says "it will work" instead of what Armbian should say, which is "it should work" As we've said previously, the Orange Pi Zero should not even have stable/nightly builds, given the hardware issues. This is an example of a board I would say is only available to build from git for those who are very willing to try. Edit: but this is getting pretty far from Rock64 topic... perhaps we can debate in another thread?

From general public view I would suggest to freeze Developement of all Boards with BSP 3.XX.XX Kernel. New Boards should be only supported, when there is Mainline Support and Documentation Support by Vendors. There should be no Support of Boards with known Issues until they are solved by the Vendors. In this special Case, Rock64, this means that Developement should not start until DRAM/Gbe Issues are solved. No Support for TV-Boxes, as there is no Support by Vendors. But I think voting is the Best Solution. Regards

It could be done simply via (double) voting. Once (first) from developers perspective and once (second) from general public and where is the match (third) ... Questions which goes up - How often / when shall we repeat this? Will boards without any interest be ever back to the list? How many we will accept into next round / some initial state? Wanting to support (being elected in this voting) does not provide warranty that we will actually come to the full level. We might still ditch the board while trying to support it. Right now we can come up with 5-10 boards which can be put on vote (and you can choose up to 3): - Rock64 - Olimex A64 - Esspressobin - Nanopi K2 - Bananapi M3 - Orangepi Win - Orange 2G IOT - Helios4 - - We have strengthen moderator team and we can ask them to conduct regular board popularity contests? Somebody has to update those lists, the rest is more or less automatic. I think 10 boards / round is o.k. and it's o.k. to put exotics, let's try again and failed boards too. You already know that there will be no vote for those, at least from developers perspective

That was the original purpose of this thread here. Gets still ignored. Already wasted way too much hours regarding a phase out process to reduce the number of supported boards and especially 'update drama' but since the real problem (why do Armbian moronically supports new boards even if there's not a single reason -- see OPi Zero Plus 2 H5 or the Banana crap) doesn't get addressed it's just another round of wasted time. Again: the purpose of this thread here was NOT go too much into ROCK64 technical details or already start development but weigh pros/cons and come to a conclusion AS COMMUNITY. A valid conclusion can also be: no support (at least not now since we need X, Y and Z from the vendor before we consider starting with this hardware).

Ok, I'm now only answering to the question 'board support decision'. We support already too much boards, a lot has changed in 2016 and in 2017 again and we just ignore this until Armbian project will collapse. Who decides whether a new board will be supported? Is it you? Is it 'us'? If the latter who are 'we'? Is it a random hardware vendor just shipping some dev samples and trusting in 'Armbian morons' doing his job for free? We're acting like the latter today. We work on boards for which ZERO Armbian use cases exist (Orange Pi Zero Plus 2 H5 or however this unbelievable f*cking stupid name is written exactly, at least it's absolutely STUPID to bring Armbian to this board since the only possible use case is 'Desktop Linux' since this board unfortunately has HDMI but just 512MB DRAM which is simply not enough for a 64-bit Linux running a Desktop environment, for H5 we've only mainline kernel since H5 BSP is such an INSANE crap so not even video acceleration will work here. It's STUPID to bring Armbian to this device but we do it). We work on boards that are not even supported by the hardware vendor. For example this BPi M2 Ultra thing, those SinoVoip folks only provide incorrect information (see DRAM timings, they write 733MHz, use 648 MHz but the SoC's memory controller supported 576MHz maximum --> reference, reference, reference look at the 'Technische Daten' PDF there, those irresponsible morons advertise this board with CPU @ 1.5GHz, DRAM at 733 MHz, Mali GPU at 500 MHz while in reality all numbers are way lower. Do we want later 'bug reports' that tell us 'Great Banana Pi M2 Ultra is able to run at 1500 MHz, Armbian is broken since allows only 1200 MHz'?!), those morons as usual do not even care about schematics being correct ('In schematic you can see two uart2 ports.'), they never release schematics timely, they're known to send out defective developer samples and they're either too stupid or too ignorant to get that this is a real problem. And what do we do? We ignore that and play morons happily working on bringing support to their boards so they are ensured their behaviour is totally OK and nothing needs to be changed. We behave like the greater morons than them since they succeed with their irresponsible behaviour since some community idiots are doing their job for free even if they actively hinder us all the time (incorrect information/schematics, defective board samples, no changelog for hardware changes). That's the whole purpose of a 'board bring up' DISCUSSION (that was the Rock64 example). Weighing pros/cons, benefits for users and developers, documenting what's missing (eg. incorrect information/schematics -- maybe even the most stupid board maker will get the idea he has to improve in this area if all his boards are rejected for the same simple reason: him behaving like an irresponsible asshole) Board bring up is fun, board support is boring but more important depending on how we look at the Armbian project (playground vs. providing a distro able to run serious stuff). We have to reduce the number of supported boards but instead we add more and more. Unless such discussions start all babbling is useless anyway (eg. whether to differentiate .playground boards from .wip boards that will at least get support eventually since we came to the conclusion that it's worth the efforts in the beginning).

Ok: how to define a process to decide whether we want to support a new device or not? Current situation: a hardware vendor sends out dev samples worth 50 bucks and we waste our time worth tens of thousands of bucks on these devices without even starting a discussion whether it's worth the efforts or not. Or someone with commit rights simply adds a board since... no idea. That sucks. Can we agree on a process like https://forum.armbian.com/index.php?/topic/4451-example-support-proposal-for-rock64/ and if not what are your ideas? Current situation: We support way too much boards to deal with, we scare away potential contributors (IMO due to lack of clear communication and the feeling for 'externals' there's an 'inner circle' or something like that) and we always just talk and talk and talk but nothing happens. This also sucks. Using Armbian and having to fear an 'apt upgrade' really sucks. There was a lot of babbling about what has to happen prior to releasing major releases ('team testers' and stuff) but... today we're on 5.30 for whatever reasons (maybe I just missed discussion, call for testers and announcement?) If we're not able to test through all those boards we claim to support why do we provide upgrades that break the most important things? This is not the first time and if we don't start to think about why we update all the time without most basic testing more of these situations will follow. If we don't have the resources to test through every f*cking u-boot update every two months everywhere why do we roll out these updates? We have devices where u-boot is from 2013 or maybe even older and that's just fine. Using 'latest and greatest' without even testing is quite the opposite of the distros we put on top of this (horribly outdated AKA stable Debian variants). This is how I would sum up Armbian engagement today: https://github.com/armbian/build/issues/512#issuecomment-269476270 (sorry for this rant but I consider current situation extremely discouraging)

The current state of the LibreELEC RK3328 build is rather unstable with occasional lockup or crash, there is also no working ethernet or wifi yet, making it very unusable and hard to test new builds. I see great potential in RK3328 as Rockchip have been very supportive this far and are working on fixes for issues we have reported. I have personally only tested on the Z28 2/16 box but you should be able to build an image using the build command on https://github.com/Kwiboo/LibreELEC.tv/tree/rockchip/projects/Rockchip/devices/RK3328 and flash the resulting image to a sd-card. But in order to boot from the sd-card you will have to erase the current bootloader from emmc, and that is where it gets a little bit tricky unless you are familiar with rockchip maskrom/rockusb mode and have uart connected. I am looking forward to switching to a ROCK64 board for continued RK3328 development

On the Z28 box the GPU will run at 600Mhz, the CPU at 1296Mhz and DDR at 786Mhz and we are using performance cpu/gpu governor but we still do not have silky smooth 1080p. I haven't received my ROCK64 dev board yet, but I hope the increased DDR speed will improve GPU performance a little bit. There is currently no issue tracker for Kodi related parts, the current code is pretty stable and upstreaming efforts have started at https://github.com/Kwiboo/plex-home-theater/commits/rockchip-leia We use drm/kms rendering and have zero-copy for video, only the gles gui uses the GPU. There are still improvements to be made and the current use of set plane legacy drm api requires a kernel hack to prevent double vsync. Thanks, we already have Rock64 boards incoming , very exited to test it out once it arrives

I forgot to ask, @Kwiboo do you need Rock64 boards, maybe Tl can send out more samples?

That looks very promising code-wise. I will get rock64 soon and definetly test your project. Do you have any issue tracker for Kodi related issues? Do you have zero copy rendering or do you render through GPU?

Thanks for the info! One more github to keep track of :-) We'll see how ayufan's first Android experiments turn out, but even on AW A64 / Pine64 Android 6/7 ran pretty well @1080p after some tweaking, a lot better than the SDK based stock images at least, 4K for video playing is more or less possible, but acccelerated 3D with Mali400 not so much... as far as I could see all of those RK3328 Android boxes run on an older 3.10.x kernel too instead of 4.4.x... At the moment there is a very early Debian image for Rock64 based on https://github.com/rock64-linux and ayufan already set up his CI magic to build consistent images at https://github.com/ayufan-rock64 , https://github.com/ayufan-rock64/linux-build/releases , https://jenkins.ayufan.eu/job/linux-build-rock-64/ . One issue we ran into is that there seems to be a problem with DRAM settings for Rock64 atm, the image is not running stable at least on the 4GB board, probably because the DRAM settings are from either the 1GB or 2GB board and RK has not yet released the u-boot spl and dram init code for RK3328, there are only two miniloaders with either 333Mhz or 768Mhz DRAM settings...

ROCK64 product page online with links to various resources/documentation: https://www.pine64.org/?page_id=7175

Nope, I only know I'm on the list since I received an email from him (which I responded to somewhat off-topic collecting a lot of weird proposals for a potential next Pine design). While I think Pine folks have no objections sending out few more dev samples IMO we should try to focus on what 'we' want: board bring up adventures or focus again on what Armbian has been in the past: a reliable distro with secure and optimized defaults (so me receiving an early pre-production sample is already somewhat wrong since I'm too stupid to read schematics or fix USB3 issues on my prototype with solder iron...) Not really but by looking at Pine64 price-list you get the idea (maybe already add a few bucks more since DRAM prices increased a lot and I don't think Pine Inc does any good selling a loss-leader). They'll decide within next 2 weeks and then I'll believe information will be leaked anyway even if official ROCK64 announcement will be delayed a bit. But from an end user perspective shipping costs are also important so let's wait and see with what they come up. Wrt availability: Currently Pine Inc gets some bad press regarding 11" Pinebook shipments due to display shortage (BTW: I would fully understand if that's no real display shortage since I can't imagine how they make any money with the $89 variant since they defined prices long ago and both DRAM and eMMC increased BOM costs a lot in the meantime) but I don't think that will be an issue with ROCK64. TBC. I'll only do some initial testing and maybe attend improving settings but I neither have the time nor skills/patience to add a new $LINUXFAMILY so someone else is needed as maintainer if we want to add this board to Armbian. Benchmarks are always a problem. Simple example: https://forum.armbian.com/index.php?/topic/1285-nanopi-m3-cheap-8-core-35/&do=findComment&comment=14623 (you need to understand relationship between cpufreq behaviour and numbers, then need to tweak settings so benchmark scores look better but in reality that's not important at all!). Network benchmarks on slow ARM devices are currently more or less benchmarks for cpufreq scaling and compiler settings (a lot is CPU bound even with appropriate settings) and the same is true for storage --> choose wrong cpufreq settings and storage performance sucks: https://tinkerboarding.co.uk/forum/thread-310.html If we want to behave like IT protozoons just collecting numbers without meaning it's easy (passive benchmarking, that's what Phoronix is about) but if we want to do benchmarking to improve things it gets complicated since then benchmarking is not a process of collecting numbers but improving them with focus on real world workloads and NOT synthetic benchmarks. In other words: Not that easy to come up with some sort of standard tests since on those low performing ARM devices with settings optimized for totally different use cases the most important thing is to identify and understand all the various bottlenecks to get the idea where to improve stuff.

For SBC to provide USB3 either the SoC has to be USB3 capable or the SoC needs a high speed bus (like PCIe) to attach an USB3 controller to it (which would be wrong if the SoC has just a single PCIe lane since then you don't use USB3 but SATA instead). That's why Armbian currently only supports the following boards with USB3: LeMaker Guitar and Roseapple Pi (Actions Semi S500 is USB3 capable but performance and software support are a sh*t show and Ethernet there is Fast Ethernet only --> forget about NAS use cases) Clearfog Base / Clearfog Pro (always wrong to use USB3 here since they feature native SATA -- performance numbers/comparison) ODROID XU4 (too expensive, technically questionable since everything is USB there, an internal USB hub is always between host controller and disks and host controller as well as recommended peripherals have their own issues paired with a user base trapped in a micro community rejecting reality) Hummingboard (you could add USB3 via a mPCIe card here but this would be wrong since this board has native SATA but limited Gigabit Ethernet so NAS performance is even lower than what cheap USB2/GbE H3/H5 boards provide) What's coming soon with USB3: EspressoBin (using USB3 here is just wrong since the board features native SATA -- even up to 3 ports by adding a cheap ASM1062 mPCIe card). Status: ready soon Helios4 (4 x SATA so why thinking about the 2 x USB3? ): Status: ready soon (the board is on Kickstarter the next 4 weeks) Rock64 (not even announced using Quad core Cortex-A53 RK3328 with native Gigabit Ethernet and USB3). Status: unknown but if price and SDK looks good there's no doubt Armbian will support it Rockchip RK3399 based devices (like this): Status: not even really announced, IMO uninteresting since way too expensive Boards based on Allwinner H6 (Quad core Cortex-A53, new 28nm process, 1 x USB3, PCIe 2.x x1 so you could avoid USB3 and use SATA through an ASM1061 instead). Status: nothing announced yet but if price and SDK looks good there's no doubt Armbian will support it (speaking of 2018) In other words: for NAS use cases forget about USB3 now and in the foreseeable future, choose EspressoBin if you want both affordable and fast or choose the combination H3/H5+GbE+USB2. Only potential exception from the USB3 rule: Rock64 soon and maybe later Allwinner H6 based boards. (Allwinner A20/R40 boards not mentioned by intention since too slow and especially R40 at the moment close to unusable since the only board available is from SinoVoip so no vendor support and most probably documentation/schematic f*cked up as usual)

BTW: I don't want to discourage anyone working on this board and further improving support. It's just me giving up on this hardware since ASUS performs so lousy (wrt deal with 3rd parties wanting to do exactly that: improving software support for their hardware). So as a last hint: since I believe the only really interesting use cases for this board are 'Desktop replacements' you should focus on this when experimenting with different cpufreq governors. Most desktop tasks benefit a lot from cpufreq being ramped up as quick as possible. Also have a look at: https://forum.armbian.com/index.php?/topic/4246-can-improve-the-desktop-performance/ (though I believe it's also important to improve IO behaviour of browsers) This is Rock64 with an I2S companion board sitting on it: https://drive.google.com/file/d/0B0KJDZUkcqOqUnBYNU9JN0EwV2c/view (details will be available soon so I won't share more information now since there isn't much more I know anyway )