sfx2000

Yes and no - It's not H3 actually - one can have L1 even on H3 or any chipset - it's more the ARM TEE and requirements there - and with Android, this means full-on GMS compliance, which means that the OEM/ODM has to have written agreements with Google, and do all the compliance/conformance testing around those requirements.
 
Widevine L3 limits output to sub-HD, and sounds like Netflix from Google Play likely won't work (there are ways around this with a patched apk there) - this is not unexpected with AOSP, even with Play Store hacked in...
 
L1 is full on compliance with Widevine, all keys are good, and everything runs inside the ARM Trust Environment - most NA/EU mobile phones have that, but cheap TV boxes, and AOSP handsets likely don't.
 
Many AOSP TV boxes will have test keys installed, but TEE and the APK's know this - grrr... DRM, and I understand why content distributors want this, but still...
 
Anyways - Widevine is an android thing - and android support does mean that the box is still useful if mainline support is lacking...
 
 
16GB - most likely eMMC, IMHO...  if one is going to put 16GB on the board, might as well be eMMC.
 
One could have 'naked' NAND and run it as a MTD device I suppose, but mmcblk is less work, and more flexibility with supply chain,  besides, eMMC prices are probably better, and eMMC has knockon benefits later on with OS level support...
 
Anyways - good res pics of the board, along with RAM, WiFi, eMMC, that's a good start - high resolution of just the board - top and bottom, goes a long way - there's only so many ways to do a H3 board, and now that the chip in question is pretty old, most of the options have been refined to a narrow set of choices...
 
Good example of board pix - http://linux-sunxi.org/HYH-TBH3
 
 

Sounds good...  When/If pics happen - top/bottom of the board, thermal solution, take a close look at WiFi (should be a system on module, if you can note the vendor/model there), and mass storage... also look for UART pads, as this is key - if you can get into uBoot, that's a good thing...
 
I suspect that whatever they're doing, it's going to be super cost optimized... at the sub-$30USD price, including an IR Remote, HDMI cable, AC adapter, and of course the shipping box -- Sunveil must have done lot of work to reduce any additional BOM costs to keep some profit on the product.
 
In past experience with AllWinnner Android boxes, ADB is there, and fairly open, at least on Android 4.x - this one runs Android 7* (Nougat) so all bets are off - just note that there might be some security items with the BSP that you can take advantage of to get root for spelunking of the OS in general... First shot would be -- If Google's PlayStore is enabled within the stock Android on that box, one might consider getting "Termux" (it's free) and dig around a bit - it's sandboxed, but one can still get some decent info about the environment it runs in...
 
* bit surprised with Nougat support, but hey, it's current enough...
 
Anyways - to check the kernel/etc - go into Kodi, and there, you should be able to confirm the android and kernel versions...
 
Best case - might be a good alternative for the OrangePI Plus 2E...
 
 

Just to add another potential reason why reboot seems to not work: since the board gets stuck on u-boot prompt due to some noise on serial RX line or via USB devices. The latter was one of the reasons why we disabled USB in u-boot for H3 boards (still can't remember whether this change made it already in the available 5.14 releases) and we just recently discovered that on NanoPi NEO obviously noisy power sources lead to u-boot waiting endlessly for input on the prompt since it misinterpreted some signals before and stopped autoboot behaviour.
 
In other words: reboot works perfectly but then the board waits sitting at the u-boot prompt for instructions (had this several times with NanoPi NEO the last days but only when connected to a specific PSU source).
 
BTW: Since you mentioned contact resistance and also consumption measurements in another thread. Contact and cable resistance might influence your consumption readouts (too much) and on the other hand I did a lot of research/tests the last weeks how to lower idle consumption especially of various H3 based boards. Good starting points might be
http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/ http://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/ http://forum.armbian.com/index.php/topic/1728-rfc-default-settings-for-nanopi-neoair/

Completely agree...
 
Etcher does a great job - and the verification ensures that one has a good write to the card...
 
When in doubt - one can use the SDCard Formatter Util (Win/Mac) to "refresh" the card prior to writing...
 
https://www.sdcard.org/downloads/formatter_4/
 
If it fails, then check either the card, or the reader...

Just to share a thought or two...
 
Armbian is actually in a special place - and thru community consensus and working with the OEM/Chipset community can do a lot of good work...
 
Not that much different than what the OpenWRT and FreeElectrons/Bootlin folks have done...
 
I've read thru the threads - and that really stuck out was @tkasier and the GPIO mess that is... and yes, it's a mess.
 
(along with uboot and dts, and then solve kernel and related stuff) - anyways, been there, done that.
 
Armbian has great experience at bringing up boards, doing some tweaks to improve performance/compat as needed...
 
So it's reach out to the community - the chipset guys, the board folks, work with the community - and there, it's the regular gatherings, and build the brand and set up BOF meetings to get some consensus across the community.
 
I'm a former member of IETF - and one of the big deals is letting loose of ownership, but keeping a gentle hand on development, and that gains a lot of respect within the larger than armbian team...
 
Hard to explain, but if the team has already solved hard problems, then those solutions are generally agreed upon, so the collective can move forward.
 
Getting back to Igor's statement...
 
Don't tell - rather be open and ask...
 
Find the community gatherings, work the threads with OEM's and Chipset contacts...
 
 

well, here's some PR stuff how people think a lab should look like..

better?  But, we don't use plastic molecule models in our lab.. Acetone for cleaning will likely f*ck them up (a bunch of plastics get dissolved by acetone, and acetone is common to clean stuff in the lab).. 
 
We don't dissolve potassium permanganate that often to get those nice purple solutions (we do it.. but then to oxidize TLC plates).. Or Copper sulfate for the blue one, or basic phenolphthalein for pink and methyl orange for the orange one..  That's not how chemistry looks like..  Your products are mostly brown, or yellow, or ocher, or tones of those colors before purification.. sticky brown residue describes the product often best..  Such nice looking crystals 

is something you only grow if you do x-ray for structure determination and you didn't run out of budget (x-ray is done by other experts, and they're expensive and the whole process is time consuming).. 
The fume hood I showed isn't a perfect one, and I would change several things, but it's a realistic one. I saw a bunch of worse fume hoods during my career.. 
There are even people proudly show their mess on reddit.. 
Have fun to explain your insurance company that this is an appropriate work place if you burn something down.. If you didn't have time to clean your mess partly during a 14h prep session, you did IMO something wrong.. But well, chemists tend to be messy..  
 
 

It was not properly fixed. Now is.

Hehe... just wait for USB-C connectors on SBC's... that's going to be a mess with all the interesting options
 
(perhaps the reason why the folks over on Cupertino decided with their recent HW releases to keep their proprietary connection)

Depends. IMO the vast majority of problems with suddenly dying flash media (SD cards or USB pendrives) is related to fraud flash: flash memory products that fake their capacity so all of a sudden they stop working once the total amount of data written to exceeds the drive's real capacity (see here for a tool to check for this).
 
If you manage to buy genuine flash products (not the brands matter but where you buy -- with eBay, Aliexpress & Co. chances to get fake flash are most probably well above 50%) then there are still huge differences. Pine's cheap FORESEE eMMC modules with low capacity are way slower than the Samsung or SanDisk (Pine and other SBC vendors use for their higher capacity modules). But no idea about reliability since AFAIK all you can do here is to trust and believe since without extensive testing it's impossible to predict longevity of SD cards, eMMC and USB flash storage.
 
My personal take on this is
trying to minimize writes to flash storage ('Write Amplifcation' matters here, keeping stuff like logs in RAM and only write them once per hour and so on) When using low-end flash storage preferring media that supports TRIM (that's SD cards and most probably also eMMC supporting ERASE CMD38 -- you can then TRIM them manually from time to time and maybe we get filesystem drivers in Linux that will support TRIM on (e)MMC too in the future) Weighing eMMC with A1 rated SD cards If huge amounts of important data need to be written to the media then always using SSDs that can be queried with SMART. The better ones provide a SMART attribute that indicates how much the storage is already worn out Some more info:
https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card https://forum.armbian.com/topic/6444-varlog-file-fills-up-to-100-using-pihole/?do=findComment&comment=50833 https://forum.openmediavault.org/index.php/Thread/24128-Asking-for-a-opinion/?postID=182858#post182858

Apologies up front - after digging thru the forums, you have a fair investment in your methods and means...  fair enough, and much appreciated.
 
Just ask that you keep an open mind on this item - I've got other things to worry about...
 
current tasks are rk3288 clocks and temps, and an ask to look at rk_cypto performance overall...
 
Keep it simple there... many use cases to consider - one can always find a benchmark to prove a case...
 
I've been there, and this isn't the first ARM platform I've worked with - I've done BSP's for imx6, mvedbu, broadcom, and QCA... not my first rodeo here.
 
Just trying to help.

Apologies up front - after digging thru the forums, you have a fair investment in your methods and means...  fair enough, and much appreciated.
 
Just ask that you keep an open mind on this item - I've got other things to worry about...
 
current tasks are rk3288 clocks and temps, and an ask to look at rk_cypto performance overall...
 
Keep it simple there... many use cases to consider - one can always find a benchmark to prove a case...
 
I've been there, and this isn't the first ARM platform I've worked with - I've done BSP's for imx6, mvedbu, broadcom, and QCA... not my first rodeo here.
 
Just trying to help.

Yes, it is a reflex that a hobbyist has, "to collect all the things".  Especially when one looks like it should be shinier than the others.  BSP's, true performance, driver catastrophes, kernel defilement doesn't show up in the advertisements for these devices.  It is not helped that the "flagship" SBC in most people's minds out there is the Pi 3, a micro-usb powered usb-hub throttled VPU-constrained machine with very poor resources.  Compared to that, anything with high clock numbers or extra "RAM Chips" looks like an amazing deal, people tend to take the community support over there for granted.
 
I do like the Wiki idea, however in a less ambitious sense:  We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board.  For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.
 
 

https://lists.debian.org/debian-kernel/2017/04/msg00333.html