chwe

Cause you find this table on the friendly Arm wiki...
 

I think it's going to be many years before you can find an SBC with both excellent IO bandwidth and a high performance GPU.
 
You currently get to choose between the two.
 
I guess the reason for this is there are only really three markets for the SoC's:
Android tablets and phones. Needs decent GPU. Nothing more than SD/eMMC is required. TV box. Needs decent GPU, still doesn't need high IO bandwidth. Wifi runs over SDIO, still doesn't need a full 1GBe network connection. NAS/home server boxes. Goesn't needs a GPU at all. Needs decent SATA and NIC. High end soho expect 200MB/s with dual gbe. Mavell have this market pretty much covered. CPU doesn't need to be that great either, if they put in hardware acceleration for network/ssl/etc I'm also not aware of any mPCIe video cards, so you'd need to go down the route of an external PCI-E enclosure. Getting ARM drivers for an AMD or nVidia card would be interesting too. I was under the assumption that if you want proper drivers for these, they come as binary blobs.

Would it be safe to assume that without attaching any USB peripherals (aside from WiFi) it should be able to run from the firewire port provided I use a DC-DC converter?
I would plan on hooking it directly into the 5v in header on the top and avoid the USB jack altogether.
 
The board's main function is to provide WiFi to the ethernet connection and run devkitPro's devkitARM toolchain.
In the end it'll stick onto the side of my iBook kind of like what the pi zero w does except through the ethernet jack instead of USB.
 


 

I did not say there was, I was addressing your assertions that they were useless to software developers, in case anyone had a similar opinion or hadn't considered it before.  Now, let's all bring the combative nonsense and slander down a notch, shall we?  
 
   

Back at base now, I confirm that Igor's fix in rc.local works here also.
 
armbianmonitor -u output without rc.local fix is at http://sprunge.us/TLVa
 
 

Apart from some migration issues, the hash from a fixed serial will be constant (Edit: well, it's not a hash in the true sense of the word since it uses part of the SID directly and crc32 of another part of the SID). Whether MAC address will be generated using that hash or not is the question, and, as I said, if the MAC is random, then it's due to the Device Tree configuration, and it is a board specific problem since each board uses its own Device Tree.
Just for the reference: http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=800f412b383ddf9ac90972e50a684c534d40fea4;hb=HEAD#l656
 
Random ones are not generated from a hash, obviously.
 
For some reason I've spent wasted some time and found the exact reason why the MAC is random in some cases. I guess blaming systemd and NetworkManager without trying to understand and debug the problem is easier.
 
Are you talking about stability in images that are marked "development" and "provided with no support"? For testing/development purposes random MAC is not an issue, completely broken Ethernet is not an issue, even missing CPU frequency scaling and thermal protection is not an issue. As long as it builds without issues and boots to a command prompt on a serial console it's working as intended, everything else is a nice bonus.

Oh believe me - I absolutely don't want the headaches and yes - the strength comes from the community most certainly. There's a lot of talented and dedicated people here!

I'd like to see support for the R2 too - I expect OpenWRT will want support the device given its nature but support requires the will,  feasibility and hardware knowledge available to draw upon.

As a side note - I used an mPCIe to PCIe extender/adapter and got an NVIDIA GTX 1070 working with the board using the binary ARM drivers (a setup I use for a laptop) -  I felt all warm and fuzzy inside.

A feat any ARM board with mPCIe/PCIe could achieve of course but I just thought that was both cool and insane - a great combination

On the R1 the SATA connector had no power for the Harddisk. SinoVoip sold a product with software that would not turn on the main feature of the board.
Thanks to a hw engineer who tinkered and reverse-engineered it could be powered in the end. Still months after that the sw of SinoVoip was not fixed and people in the forum were asking for help.
What was your question again
 
I wrote that begin of 2016, first contact with Nora - can you see improvement?

Maybe work on 'charles' list posted in the BPi forum:
It's clearly not your job to provide this data (team bpi never showed the willingness to work wit 'charles'), but as you noticed, lot of people's here aren't that excited to work on a sinovoip device (again). Maybe you can give them a reason to change their behaviours.
I followed quite a while the boot up thread in de BPi forum, is there now a possibility which doesn't involve more steps than build up a ikea furniture? (never thought that boot up a sbc can be so hard...)

Hey Armbian aficionados - it's me of 'I can confirm that sound support isn't compiled into the kernel' fame. Please don't rush me all at once, I didn't ask for this fame and glory and I've already turned to hard drugs and fast women.

Since I've got this board and I'm not entirely incompetent (open to debate) - please let me know if there's anything I can do from my end to provide you with information for your assessment.

I'm guessing from the smattering of posts I've read that I won't be encountering many fans of the manufacturers - I agree that their software practices and documentation is poor - there's basically no info on the battery connector, efficiency of the step-up, max draw etc - the barrel jack was a different size from their technical drawings (that's £1 on an adapter I'll never get back - it sits on my desk... mocking me) - I'm sceptical in regards to the simultaneous power draw of the 2-pin and 4-pin SATA power headers using the specified 2A supply  (I got a 3A for testing but I'm not ready to risk two drives just yet - definitely need to be careful in regards to lithium battery draw) and there's an unpopulated position for a cap next to the 4 pin supply on my board that's present on their pictures for the v1.1 revision of the board - I'm a little suspicious as to why it was left out in this production batch - perhaps it was determined to be superfluous but I've popped a question to support - they've been really helpful so far (just remember to throw your sentences back and forth between English and Mandarin on a translator to ensure that meaning remains intact - you get much more detailed responses when you remove the ambiguity of translation)

But all that said - it's a really great bit of kit  very well made, general IO is nippy, the mPCIe is great for development (got a lovely little mPCIe FPGA board coming for my SDR project) SATA is working (tested a an old 2 inch spindle drive - need better kit to probe bottlenecks) sound is working perfectly (when compiled in), GPIO, WAN/LAN, USB3, OTG all seem to be functioning fine (wrote 30gb of data to a flash stick on the device from a CIFS mount - calculated hashes match) - so far it's not crashed on me once - SoC gets a bit hot under load - fine with a heat sink - don't think the thermal sensor is supported yet or perhaps that's not selected for compilation either (there's a lot of MediaTek stuff in this kernel that's not enabled but a lot of it is for other MTK chips - some of it is ambiguous in description so I'm not 100% sure yet)

Waiting on support for the internal WIFI/BT - hardware video decoding isn't working or not enabled (480p mp4 ran smooth as silk at 1:1 - the moment you scale, performance bombs) - obviously no GLES on the Mali450MP4 (userspace blobs for 3.x kernels - 4.x kernel for the board - that old chestnut) - not eeeeentirely sure if the X11 driver currently used is optimal (gallium on llvmpipe reported under Xorg - will dig into that a bit more now).

I'm sure the experts here are rubbing their temples at this stage - please don't geek attack me - I'll probably cry. It'll be really pathetic and my face will be a mess - nobody wants to see that.

Anyway - if I can run any tests and what-not then please let me know - I'm fine compiling/tweaking my own distro for my needs but I'd be a lot happier with a pro distro like Armbian - if you ever deem this board a viable target that is.

I finally tried it with another USB cable and everything worked without problems.

I should have followed the recommendations before posting a topic

Thanks anyway!

[update 12/2017 at bottom]
Possibly late, but I would like to put everything we know in one place for anyone who might think of buying this board.
 

 
Overview:
 
   This is a form factor and (mostly) I/O clone of the Raspberry Pi 3 with a much more powerful quad-core Cortex-A17 Rockchip rk3288.  It supports HDMI 2.0, has 2 GB RAM, Gigabit Ethernet, Wifi and BT on board, etc:  https://www.asus.com/us/Single-Board-Computer/Tinker-Board/
 
   As numerous other sites have covered all the typical performance metrics and extolled the power and so forth of this board, I'm going to go ahead and give you the less exciting information and the tradeoffs/problems.
 
Mainline:
 
Getting the mainline kernel to boot on this machine was pretty straightforward, mainline support for the hardware, including WiFi, makes for less patching and allows a lot of functionality from the mainline kernel without excessive patching.  That said, so far Bluetooth and squashing a reboot bug have not been successful (I'm under the impression the rk3288 was never truly intended to boot solely from external sdmmc devices)
 
Important Hardware Considerations:
 
          Power Solution:  This board is equipped with a micro-USB connector as it's power input.  Micro-USB is only rated for 1.8 Amps, no matter how big the numbers on your power supply are.  It is entirely possible, even likely, that you will hang this board by plugging in peripherals to the USB 2 slots.  Micro-USB is a terrible method of providing power to a single board computer, and is the most serious problem with this device.  This device should be powered via the GPIO header using a filtered supply if you wish to have any semblance of stability.
 
          Heat:  The rk3288 is not a low-power chip, and the heat sink supplied (pictured above), is not adequate for any CPU-intensive activity, quickly throttling performance when it gets too hot. 
 
          USB throughput:  I have not empirically tested this, mostly because it is unnecessary.  For some reason the 4 USB 2.0 ports on the board are all routed through a single USB Hub as on the Raspberry Pi.  Not incredibly useful, other than not having to buy an external hub to make the one exposed USB port into 4.  (unless of course those devices use power, then you need a powered hub anyway)  In case you are wondering, there are 2 USB2 ports available on the SoC, however the dev team for this board decided to dedicate one to an "HD Audio codec" instead of using the dedicated I2S/PCM output to do that job.
 
          Undocumented pins:  The 4 pin header  next to the micro-USB power serve no documented purpose.  One pair is definitely the power button as references in the device tree for the board,  I've determined (and have seen others likewise verify) that the pins closest to the edge are the power button input. The other is not documented at all, and I've not wanted to tempt fate by shorting it out.
 
Software/Support Considerations:
 
          The Documentation for this board is terrible.  Incomplete, non-existent, etc.  The Official ASUS image is a series of workarounds and, until release 1.6, was not properly available to the community.  Even then, development does not appear to be occurring publicly (if it is that means development has stopped).  Rockchip representatives (seemingly not the ones working on the Tinker Board) have at least come forward to provide some helpful hints concerning issues, but ASUS has been entirely silent. 
 
My opinion after use/development:
 
          This is a very powerful board.  Unfortunately I had to build an adapter to power it over GPIO so it would run properly with any moderately demanding USB peripherals, I added a larger heat sink to stabilize the thermal situation, and am currently trying to find a way to get the board to reset properly without using what the Tinker Board source code itself labels a "HACK".  I can not recommend this board to a new buyer.  It's a shame, really, this board had every opportunity to be a really good solution. 
 
If the prospective buyer wants nothing more than a 4K media player, there are other options that will serve that niche better, including a small mountain of inexpensive TV boxes.  This board is not ideal for a NAS due to the USB Hub (unless you want to test the limits of the SD card interface).  CPU intensive operations will throttle the device to under 1 GHz with the factory cooler, so without modification you are limited there. Powering peripherals through the board is simply not possible out of the box due to the Micro-USB power solution.  Powering through GPIO is the only sane option. Raspberry Pi compatibility is not absolute.  The GPIO libraries (WiringPi, etc) are not exact, some of the pins serve multiple purposes on the header, etc. This board may be adequate as a small kiosk linux desktop, it is fast enough to provide a snappy interface, and will fit in many of the available cases for the RPi.  I would still recommend GPIO power and probably improved cooling in case a lot of video/etc are needed.  
[update]  I've been running the Tinker Board as a daily driver for over a week, powering it via micro USB with my normal peripherals (mouse/keybd, wireless active, touchscreen attached)  My findings are what would be expected:
 
Power supplied to micro USB port:  5.25 volts 800 - 950 mA "normal" use Playing a Youtube Video (software render) this hits 1.7 Amps Voltage present at Tinker Board USB Host port:  4.7 Volts under "normal" use Playing a Youtube Video this drops to 4.2 Volts, meaning a > 1 Volt drop.  
Now, you might be saying "I run my Tinker on micro USB all the time and don't have any issues"  You're right, and you're wrong all at once.
 
The processor/RAM use much lower voltages provided by the RK808 PMIC, so the system doesn't fold up and crash when the input voltage gets too low.  HOWEVER, here is a snippet from my dmesg:
 
What you're seeing here is my little wireless mouse receiver giving up the ghost because of voltage starvation.  More or less, when I get these voltage dips, anything that needs 5 volts (like USB peripherals, say that external HDD, webcam, card reader, mouse) shut down and/or could be damaged/corrupted.  I have not had a single system failure, however were I to be reading/writing external media (or running this off of a flash drive for some reason) I'd have experienced some real problems.

Hell no,  It's not that I wanna like my own messages. I wanna like your post that the link post issue is solved now.  
Solved: You have to click twice the heart to like it... 

You cant click your own post which is a feature not a bug. Is this the case?

Wrote on mobile

Fixed. 

According to their faq it's scalled to 4k from 1080P.
Whenever the GPU is able to hardware decode 4K, doesn't mean that the software is able to do it... 
 
IMO, don't think about 4K as long as your tinker runs not smoothly & stable with provided tinker OS.
From TinkerOS 1.9:
Seems that they still work on a stable 4K player.
 
From the armbian dowloadpage:
And a must read too. The tinker is a cool board from specs, but has some hardware fails. It's claimed to be a RPi with much more power, but on software side it's still WIP. 
Just have a look on the open issues in the Rockchip subforum here (mine is lying around until I find motivation to play more with it. Sorry @TonyMac32 weather was too good and I was sailing during weekend ).

Do you ever thought about alternatives (Maybe C.H.I.P or Omega 2 are better for battery powered IoT devices. This is a little bit out of my knowledge, not sure if these two are good proposals)? From my experience, the opi 0 is a little bit bitchy as soon as it runs into a undervoltage situation. I realized that the SoC (OPi 0, rev. 1.4) gets really hot (finger test) as soon as there's not enough power to start up the board. I'll investigate this as soon as I have more time and my second OPi 0 arrives (I would be annoyed, if I grill the only one which I have at the moment). 

Temperature measured with a DS18b20 on the SoC is 56-57°C (internal temp 69-70°C, during stress --cpu 4). Idle @480MHz 45°C (internal temp 52°C). There'll be some more 'insights' here:
 

Starting to work on lets call it the "dogafu" experiment (don't give a fuck about recommendations). This would combine my threads about powering & bad SD-Cards. Cause I want do something useful and not just crash armbian on a system, from which I know that it would happen, I decided to do not only stupid tasks on my OPi zero.  I could just hammering the SD-Card with a webcam and motion until it crashes and write on this thread 'opi 0 with terrible setup crashes after x days'.  But, nobody would read this thread cause it's not interesting for anyone. We know that this would happen and for those users who don't know, there's nothing of interest in this thread. 
Since thermal throttling on the opi zero seems to be a real issue and there's a lack of information, that the temperature readouts from the SoC are correct, I decided to connect a DS18b20 to the OPi0 and let it measure the temperature of the SoC. Everything was installed on ARMBIAN 5.31 stable Ubuntu 16.04.2 LTS 3.4.113-sun8i. 
 
Hooking up the DS18b20:
First we edit the configuration file and uncomment the w1 modules with sudo nano /etc/modules-load.d/modules.conf
and cause onewire does not work properly @240 MHz we had also to change MIN_SPEED to 480000 with:
sudo nano /etc/default/cpufrequtils
after a shutdown we can connect the DS18b20 on GPIO10 (Data, physical pin 26), VCC to one of the 3.3V (physical pin 1 or 17) and ground (physical pin 6,9,14,20 or 25) don't forget to have a 4.8kOhm resistor betwenn VCC and Data! If you want to have your data pin not on GPIO10 you have to modify the script.bin with bin2fex /boot/script.bin /tmp/orange.fex followed by nano /tmp/orange.fex and change the GPIO in the [w1_para] section (example for using of GPIO6 for DS18b20):

sudo fex2bin /tmp/orange.fex /boot/script.bin and a reboot is needed to activate this settings. Im everything works correctly sudo armbianmonitor -m should show that the cpu frequency would not go below 480MHz (otherwise DS18b20 would not run smoothly). Go to cd /sys/bus/w1/devices/ we can see our sensor with ls.
 
It should start with something like 28-XXXXXXXXXXX. cat 28-0517010cbeff/w1_slave should show our actual temperature.
So the actual temperature in my room is 23.562°C (IMO forget about everything behind the °C, proper precise temperature measurement isn't trivial and needs calibration which is not possible without professional equipment). 
 
Send data to an other device:
Cause this setup with bad powering & a corrupt SD card will brick and I do not want to lose the collected data, I decided to send all the data to a second, proper running, OPi 0 via mqtt. This will be done by some bash scripts and crontab (it would be possible to do this only with crontab, but cause I may use this scripts on other devices for other purposes it's easier to have them isolated). For this, I installed a mqqt client with sudo apt-get install mosquitto-clients. After installation, we test if the client can publish on an other device with: mosquitto_pub -h 192.168.x.xx -t test -m "everything works ;-)" (-h ip oft the mqtt broker, -t topic to publish -m msg.payload). On my second OPi 0 with node-red and mosquitto we should see that the message arrived (installation of node-red and mosquitto).
(with #, we subscribe to every topic on the mosquitto broker)

Bash script & crontab:
IMO the easiest way to send data periodically is to generate a small bash script which includes all the tasks and then setup a crontab to start this bash script. The scritp was saved in /home/opi/scripts/ with nano scriptname the script was generated (It might be possible to do this tasks without a bash script but since I'll reuse parts of it i decided it's the lazy way to do it.):
 
Cause cpu infos are only available as root, crontab must run under root privileges. Add a new crontab with sudo crontab -e (1 for edit with nano). This crontab will start our script every minute:
 
Cause this script runs now with root privileges, this might be a security risk so make sure that no one has access to your OPi! Now it's time to set up everything in node-red to get our results visible. I added dashboard to node-red to have some nice UI templates (usage of node-red & how to set up can easily learned by google . 
FYI: This is an ongoing project. At the moment, everything runs on a reliable SD-Card and the DS18b20 is not properly mounted on the SoC (waiting for thermal paste). As soon as I have everything setted up, I'll put it on the bad SD-Card with a cheap phone charger to see how stable it runs.

Hi, All!
 
I have modified w1-therm kernel module. Now device directory contains two more files w1_read and w1_convert_all.

 
You can read sensor memory without triggering temperature conversion using the first one and you can trigger the temperature conversion on all sensors (implemented using "skip ROM") with the second one.
 
I needed this modification to speed up sensor reading. Now I start temperature measurement on all sensors (it takes 750ms on 18B20) and then read the results. Earlier reading sensor (using w1_slave) required 750+ms for each sensor. Here is the result for my 10sensors 1wire network (using the usual w1_slave required 8.5sec, with new features of the modified w1_term reading required 1.2sec).

 
I have tested it on the Orange PI PC Plus board with 10 DS18B20 sensors in the network.
 
Is anybody interested? What should I do to share my work? 
 
P.S. The patch is here https://github.com/sov1178/linux/commit/3775c3506830cd3c5b60e79f57ed15f2ac86a4f8

It took a bit more time then two weeks :) But I have made ds2482-800 board this week and tested modified modules with the multiple w1 masters configuration. Everything is ok.
 
Also I added a new feature - now it is possible to trigger the temperature conversion of the sensors on the individual w1 master. And finally I made a pull request...

Starting to work on lets call it the "dogafu" experiment (don't give a fuck about recommendations). This would combine my threads about powering & bad SD-Cards. Cause I want do something useful and not just crash armbian on a system, from which I know that it would happen, I decided to do not only stupid tasks on my OPi zero.  I could just hammering the SD-Card with a webcam and motion until it crashes and write on this thread 'opi 0 with terrible setup crashes after x days'.  But, nobody would read this thread cause it's not interesting for anyone. We know that this would happen and for those users who don't know, there's nothing of interest in this thread. 
Since thermal throttling on the opi zero seems to be a real issue and there's a lack of information, that the temperature readouts from the SoC are correct, I decided to connect a DS18b20 to the OPi0 and let it measure the temperature of the SoC. Everything was installed on ARMBIAN 5.31 stable Ubuntu 16.04.2 LTS 3.4.113-sun8i. 
 
Hooking up the DS18b20:
First we edit the configuration file and uncomment the w1 modules with sudo nano /etc/modules-load.d/modules.conf
and cause onewire does not work properly @240 MHz we had also to change MIN_SPEED to 480000 with:
sudo nano /etc/default/cpufrequtils
after a shutdown we can connect the DS18b20 on GPIO10 (Data, physical pin 26), VCC to one of the 3.3V (physical pin 1 or 17) and ground (physical pin 6,9,14,20 or 25) don't forget to have a 4.8kOhm resistor betwenn VCC and Data! If you want to have your data pin not on GPIO10 you have to modify the script.bin with bin2fex /boot/script.bin /tmp/orange.fex followed by nano /tmp/orange.fex and change the GPIO in the [w1_para] section (example for using of GPIO6 for DS18b20):

sudo fex2bin /tmp/orange.fex /boot/script.bin and a reboot is needed to activate this settings. Im everything works correctly sudo armbianmonitor -m should show that the cpu frequency would not go below 480MHz (otherwise DS18b20 would not run smoothly). Go to cd /sys/bus/w1/devices/ we can see our sensor with ls.
 
It should start with something like 28-XXXXXXXXXXX. cat 28-0517010cbeff/w1_slave should show our actual temperature.
So the actual temperature in my room is 23.562°C (IMO forget about everything behind the °C, proper precise temperature measurement isn't trivial and needs calibration which is not possible without professional equipment). 
 
Send data to an other device:
Cause this setup with bad powering & a corrupt SD card will brick and I do not want to lose the collected data, I decided to send all the data to a second, proper running, OPi 0 via mqtt. This will be done by some bash scripts and crontab (it would be possible to do this only with crontab, but cause I may use this scripts on other devices for other purposes it's easier to have them isolated). For this, I installed a mqqt client with sudo apt-get install mosquitto-clients. After installation, we test if the client can publish on an other device with: mosquitto_pub -h 192.168.x.xx -t test -m "everything works ;-)" (-h ip oft the mqtt broker, -t topic to publish -m msg.payload). On my second OPi 0 with node-red and mosquitto we should see that the message arrived (installation of node-red and mosquitto).
(with #, we subscribe to every topic on the mosquitto broker)

Bash script & crontab:
IMO the easiest way to send data periodically is to generate a small bash script which includes all the tasks and then setup a crontab to start this bash script. The scritp was saved in /home/opi/scripts/ with nano scriptname the script was generated (It might be possible to do this tasks without a bash script but since I'll reuse parts of it i decided it's the lazy way to do it.):
 
Cause cpu infos are only available as root, crontab must run under root privileges. Add a new crontab with sudo crontab -e (1 for edit with nano). This crontab will start our script every minute:
 
Cause this script runs now with root privileges, this might be a security risk so make sure that no one has access to your OPi! Now it's time to set up everything in node-red to get our results visible. I added dashboard to node-red to have some nice UI templates (usage of node-red & how to set up can easily learned by google . 
FYI: This is an ongoing project. At the moment, everything runs on a reliable SD-Card and the DS18b20 is not properly mounted on the SoC (waiting for thermal paste). As soon as I have everything setted up, I'll put it on the bad SD-Card with a cheap phone charger to see how stable it runs.

Alright, the biggest issue with the ASUS Tinkerboard being "resolved", I'm starting to take care of the VPU driver, in order to use it with mainline kernels.
 
The hardware video encoding/decoding facilities are the real meat of the RK3288, and recent Rockchip boards.
The VPU driver aims to use these facilities in order to provide the smooth video playback experience that every Netflix/Hulu addict expects when buying such boards.
 
Which mean, once this part dealt with, you might be able to enjoy your Multimedia oriented distributions/softwares on your Rockchip boards (MiQi, Tinkerboard and maybe Pine64 too !)
 
So the driver is already available in Rockchip 4.4 kernels, and started to be ported in an Out-Of-Tree fashion by phhusson on Github, and then got the attention of wzyy2, one of the Rockchip guy, which updated it and took care of multiple bugs that were present in this version.
 
I'm now reassembling the code, include files and all in my rockchip-vcodec repository, patching the code to use it with the latest 4.13 kernels.
 
Now, the problems are : I don't get the big picture from the user side. So it's kinda hard to test this quickly.
 
Rockchip seems to rely on their library, MPP, and patched gstreamer packages if I understand correctly. Last time I tried the "test-suite" of the MPP library, things were "clunky". Since it's mostly maintained by one person, ayaka, I'm pretty sure that it's the kind of test-suite that only the owner clearly understands. I know that problem, as I did the same thing with some of my libraries.
 
 
So, basically, the main goals are :
! Compile the VPU driver without issues. I took care of that for now. The driver compiles, loads AND unloads correctly, without issues. ? Understand clearly what packages, patches and software are needed to use the VPU services provided by the VPU driver. ? Enjoy 1080p movies without a hitch on RK3288 boards (and others Rockchip boards if possible) !  
I'll add these goals on the Github pages so that everyone gets how things are going, from the GH page.
 
If you have any issue with the driver and/or it's use, file it on my repository and I'll see what I can do.

I understand why you would love it cause your ferrari powered VW golf gets hammered quite often:
 
 
keep fighting, if you solved all this issues there's nothing else which works properly on a RPi.  Maybe they come up with something like 'is the tinker able to play 8k hardware encoded video?'  If I have time on weekend, I may play a little bit my asus tinker and try to solve some of these issues (if the weather gets better I go sailing ).

Test setup:
After the micro-USB thread where I showed that USB cable and charger matters, it’s time to speak about SD-Cards. For this I buyed a cheap SD-Card from aliexpress claimed to be a 8GB class 10 SDHC.
Since I have no other 8GB cards I’ll compare this card with a Samsung EVO+ 32GB card which I usually use with my SBCs. After arrival, I did (as recommended by the armbian getting started guide) a first H2testw to check if the card is in a good shape (test results in german).
Seems that this card still starts with bad sectors on it (384 sectors, 192 KB). Since formate a SD-Card on windows is shitty, I downloaded the tuxera SD-Card formater from sdcard.org. Formate the card and do the H2testw again showed that we no have 12MByte more space. but the number of corupted sectors also increased (896 sectors, 448KB).
 
Burning Armbian:
So we could expect that this card wouldn’t be a good choice for a SBC but doesn’t matter, let’s reformate the card and burn armbian 5.24 (debian with legacy kernel) to it. After burning the image with Etcher, it reminds me kindly that this may be not a good idea.

Let’s forget about warnings, connect the board via lan to the router and via serial debug to PuTTY. The first boot needs about 50 seconds. Set up the new password and new user for daily use and reboot the system (~30 seconds + 15 seconds for log in).
Since everything runs smoothly, I decided to follow @tkaisers SD-Card benchmark test to see how this card performs (10M instead of 100M, forgott to remove the 16384k files )
'iozone -e -I -a -s 10M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2'
The results aren’t that stable and we should consider that there’s a different kernel used compared to tkaisers thread but we see clearly that this card is slow. The reason why I choosed a outdated armbian is simple. I wanna see much the impact of the sd-card is during apt-update/ apt-upgrade from 5.24 to 5.31. Apt-get update needs 43 seconds followed by apt-get upgrade which needs 14 minutes. After a second reboot (~34 seconds) the SD-Card was removed formatted and a third H2testw was done. Surprisingly h2testw found less corrupted sectors than before (608 sectors, 304KB)
After all these tests with the cheap SD-Card, I formatted my Samsung EVO+ SDHC 32GB card and tested it with H2testw. As expected there were no bad sectors since my last test of this card. Also read and write speed are ~3MB/s faster as with the cheap SD-Card.
Burning the same image of Armbian to this SD-Card showed no error and the first boot needs about 44 seconds. After setup of the daily user followed by a reboot (30 seconds, 2 seconds after login), ‘iozone -e -I -a -s 10M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2’ showed that the card is faster than the cheap SD-Card but not as fast as in tkaisers setup on the banana pi.
After finishing the SD-Card performance tests apt-get update was done in 40 seconds and apt-get upgrade to Armbian 5.31 was done in 11 minutes!
 
Conclusion:
Both, etcher and H2testw, did a good job. They indicated that the cheap SD-Card isn't recommended to install a OS on it. Iozone then showed also that the cheap SD-Card is a way slower than the Samsung EVO+, this was also proved by apt-upgrade, which took 3 minutes longer than on a Samsung EVO+ (~27% slower). Even if there were no instabilities during this short test, I would never use this SD-Card on an SBC cause it's only a matter of time until this setup runs into instabilities.
 
Outlook:
So, what's next? I'll combine the shitty charger with the shitty micro USB cable, mixed it with this SD-Card and serve it as the worst case armbian set up to you. This 'toxic cocktail' will then run 24/7 with some data generating stuff on it, sending some 'still alive' notes to a proper powered SBC, until it crashes (thinking about connecting a USB-Camera& motion to generate data).