Tido

I have a running obsession with sensors/motors/SBCs and have been creating a collection of C libraries as I learn/conquer each new device. I recently added a few that might interest some of the forum residents here. They include a C library to talk to the RPI Sense Hat, ST Micro VL53L0X time of flight distance sensor, and CCS811 air quality sensor. You can find them all here:
 
https://github.com/bitbank2
 
If anyone has a sensor/add-on that they would like to program in C from their Orange Pi and there isn't any code available, let me know and maybe I can add it to my collection.
 
 

I have to disagree with a lot of points on that FAQ since I'm monitoring some other forums and see complaints towards Armbian from a perspective of an inexperienced user.
For people that want to use CSI cameras, C or Python GPIO libraries that have questionable (at best) hardware detection by parsing /proc/cpuinfo or want to run Kodi or Android Armbian won't be an answer. For poor souls that bought an OPi 2G-IOT or its lighter variant Armbian won't be an answer either. For boards that (currently) have rather poor mainline support (OPi Win/Win+) Armbian may have more problems than vendor's images.
Please keep in mind that an average person may not care about security or performance optimizations but may want specific software features that won't work on our images out of the box.

I would prefer to split it into multiple services: a logging service, an optimizing service, a hardware monitoring service, etc.
And instead of reinventing the wheel with zram we could use a systemd-swap service, i.e. this implementation from Arch Linux: https://github.com/Nefelim4ag/systemd-swap
 
This way it would be easy to disable individual components of Armbian that may not be needed or that may interfere with other services (i.e. your "activate_zram" function checks only for zram-config package and it would interfere with systemd-swap installed by users without an easy way to disable it (since any changes to armhwinfo will be lost on upgrade))

The picture is a bit dark, but a nice idea with the R1 in the background to compare the size of the PCB. It is quite large.
 
What about the LEDs on the Ethernetports, I haven't attached any device on my R1 lately, but they didn't work in the past.
Do these LEDs work on ClearFog?

it's hot here

This is now different:
root@tinkerboard:/home/tido/myy-s/mali# LD_LIBRARY_PATH=. glmark2-es2-drm Error: eglGetDisplay() failed with error: 0x3000 Error: eglGetDisplay() failed with error: 0x3000 Error: main: Could not initialize canvas Error: Failed to restore original CRTC: -13 I try after  chvt 1, et voila:
root@tinkerboard:/home/tido/myy-s/mali# LD_LIBRARY_PATH=. glmark2-es2-drm ======================================================= glmark2 2017.07 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-T760 GL_VERSION: OpenGL ES 3.2 v1.r14p0-01rel0-git(966ed26).810f535757d8c9adaaa72f5da29c688e ======================================================= [build] use-vbo=false: FPS: 55 FrameTime: 18.182 ms [build] use-vbo=true: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=nearest: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=linear: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=mipmap: FPS: 55 FrameTime: 18.182 ms [shading] shading=gouraud: FPS: 55 FrameTime: 18.182 ms [shading] shading=blinn-phong-inf: FPS: 55 FrameTime: 18.182 ms [shading] shading=phong: FPS: 55 FrameTime: 18.182 ms [shading] shading=cel: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=high-poly: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=normals: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=height: FPS: 55 FrameTime: 18.182 ms [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 55 FrameTime: 18.182 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 50 FrameTime: 20.000 ms [pulsar] light=false:quads=5:texture=false: FPS: 55 FrameTime: 18.182 ms [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 27 FrameTime: 37.037 ms [desktop] effect=shadow:windows=4: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 55 FrameTime: 18.182 ms [ideas] speed=duration: FPS: 55 FrameTime: 18.182 ms [jellyfish] <default>: FPS: 55 FrameTime: 18.182 ms [terrain] <default>: FPS: 13 FrameTime: 76.923 ms [shadow] <default>: FPS: 55 FrameTime: 18.182 ms [refract] <default>: FPS: 27 FrameTime: 37.037 ms [conditionals] fragment-steps=0:vertex-steps=0: FPS: 55 FrameTime: 18.182 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 55 FrameTime: 18.182 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 55 FrameTime: 18.182 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms ======================================================= glmark2 Score: 51 =======================================================  
Wow, in  htop  CPU is close to Zero !
Temperature: around 50° C  steady.
It does need more RAM than before, but not more than 352
 

I have to agree with@chwe on this, I am in the automotive industry, not only would I be fired for such documentation of a design, there could be federal charges brought against myself and my company ending with me in jail if incorrect documentation could be linked to a failure or unexpected behaviour. Not to mention losing all OEM business, etc.

It is not such an impossible task to document properly. But attacking anyone who points out factual errors in your paperwork causes animosity and people will refuse to support these products. Trust me, I am no stranger to poor documentation. But at least for the ASUS Tinker Board the problem is missing documentation, not incorrect documentation. Were it incorrect I would have immediately recommended Armbian drop all support for the board, no matter how popular it may be.

Now, as an engineer I am accustomed to dealing with suppliers. In this situation, that is your role. You are a supplier of single board computers to a marketplace. That gives the user (customer) a certain amount of agency over you, the customer can require correct documentation, the customer can provide negative feedback and refuse to use your product. As a supplier it is your duty to provide a product the customer wants. In the single board computer world that is more than a board, it is also the means to use it. Your product cannot simply be defined as a board, your product is a board and a manual. And that manual needs to make it possible to use the board. The manual includes complete and correct schematics, diagrams of all exposed connections, a basic board support package (device tree or equivalent, vendor-specific drivers, uboot if not mainline, etc)

As you have pointed out, most SBC suppliers in this market have flaws. But I have seen none that are outright confrontational and generally unprofessional. Do you think I don't have customers and coworkers just as disagreeable as Thomas is capable of being? Of course I do, many far worse actually. Do I respond the way you do? No, or else I would not have a job. Do I always agree with the magnitude and force of Thomas's quick anger? No. But I certainly understand it. I actually refused to reply several times during this thread because I felt my feedback would be less than professional. However, my reserved tone has apparently caused some confusion which I felt it necessary to clear up.

I want to see a good competition between board makers, and the obvious benefits that come with it. So to that end I want to see you succeed. However, for that to happen you need to also compete in documentation. You have said you will, but be aware I will not engage in any development, privately or for Armbian, until there is some proof of that effort. A big step would be addressing the concerns you have heard here so many times that I'm even tired of reading about them.

[/rant]

Sent from my Pixel using Tapatalk

This is now different:
root@tinkerboard:/home/tido/myy-s/mali# LD_LIBRARY_PATH=. glmark2-es2-drm Error: eglGetDisplay() failed with error: 0x3000 Error: eglGetDisplay() failed with error: 0x3000 Error: main: Could not initialize canvas Error: Failed to restore original CRTC: -13 I try after  chvt 1, et voila:
root@tinkerboard:/home/tido/myy-s/mali# LD_LIBRARY_PATH=. glmark2-es2-drm ======================================================= glmark2 2017.07 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-T760 GL_VERSION: OpenGL ES 3.2 v1.r14p0-01rel0-git(966ed26).810f535757d8c9adaaa72f5da29c688e ======================================================= [build] use-vbo=false: FPS: 55 FrameTime: 18.182 ms [build] use-vbo=true: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=nearest: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=linear: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=mipmap: FPS: 55 FrameTime: 18.182 ms [shading] shading=gouraud: FPS: 55 FrameTime: 18.182 ms [shading] shading=blinn-phong-inf: FPS: 55 FrameTime: 18.182 ms [shading] shading=phong: FPS: 55 FrameTime: 18.182 ms [shading] shading=cel: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=high-poly: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=normals: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=height: FPS: 55 FrameTime: 18.182 ms [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 55 FrameTime: 18.182 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 50 FrameTime: 20.000 ms [pulsar] light=false:quads=5:texture=false: FPS: 55 FrameTime: 18.182 ms [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 27 FrameTime: 37.037 ms [desktop] effect=shadow:windows=4: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 55 FrameTime: 18.182 ms [ideas] speed=duration: FPS: 55 FrameTime: 18.182 ms [jellyfish] <default>: FPS: 55 FrameTime: 18.182 ms [terrain] <default>: FPS: 13 FrameTime: 76.923 ms [shadow] <default>: FPS: 55 FrameTime: 18.182 ms [refract] <default>: FPS: 27 FrameTime: 37.037 ms [conditionals] fragment-steps=0:vertex-steps=0: FPS: 55 FrameTime: 18.182 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 55 FrameTime: 18.182 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 55 FrameTime: 18.182 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms ======================================================= glmark2 Score: 51 =======================================================  
Wow, in  htop  CPU is close to Zero !
Temperature: around 50° C  steady.
It does need more RAM than before, but not more than 352
 

@guidol thank you so much for sharing your thoughts, experience and pointing a direction. @Lion Wang that is the kind of feedback you MUST read, understand, SHARE with your team and act to solve the pains.
 
+1 for eMMC, a 8GB class-10 sdcard costs ~6.5USD nowdays. How much it is 8GB eMMC?

I'm well aware of this and as already said IF SINOVOIP WOULD START TO PROVIDE CORRECT HARDWARE DESCRIPTIONS BPi M2 Zero would've been long added as .csc (community supported board variant) so it's at least ensured that hardware settings match so other projects relying on Armbian's build system or using same legacy kernel can easily add support for BPi M2 Zero to their projects (those others are for example H3Droid, RetrOrangePi, Lakka and @jernej's community OpenELEC distro).
 
It would have already happened if the company in question would start to provide correct and not all the time missing or even wrong information.
 
That was talking about most basic support, just describing the hardware so it's useable with legacy kernel (the 3.4 that is unsupported since more than half a year since EOL in April 2017) in a good way. Impossible with SinoVoip since they do not provide the needed information (voltage regulation, if this thing can't switch to 1.1V it will permanently overheat). As soon as this is fixed it's throwing in 2 files into the build system and perfectly working OS images can fall out of it, then @lvmc would already be happy since he doesn't need community, friendlyness and the other stuff but just working OS images for his commercial use cases. Fair enough but not related to 'Armbian support', he and we are missing vendor support.
 
'Full Armbian' support would mean we actively try to support this device. Armbian wants to move away from legacy kernel so all you have with mainline kernel is then a H2+ device lacking 3 USB ports with a problematic Wi-Fi implementation (AP6212A though referenced as AP6212 by the vendor -- do you start to understand why dealing with them sucks?), only one USB OTG port, no working camera and tinkerers encouraged to solder a MagJack wrongly then then flooding our forum about Ethernet problems.
 
Adding to this: false/misleading advertising. Buyers believe M2 Zero would be compatible to RPi cameras (not true at all) and to RPi software (not true at all). And these people will later end up here in the forum (since they'll realize pretty fast that SinoVoip doesn't support SinoVoip hardware) and complain about incompatibilities. That's the other reason official Armbian support is highly questionable.
 
And may I remind you that all the work done on Armbian is done by volunteers even if the liar who called me already an asshole constantly spreads I would be paid by Xunlong. Seriously: why dealing with this stuff?

@lvmc,
You probably know there is no CSI/VFE subsystem in kernel 4.xx , to have full control over DVP interface for OV5640 you should rely on legacy kernel or develop your own subsystem which is... well... overkill.
As a start, you could look into ./config/boards and change from a current H2 board config file and modify/add  information, since all H2 seems to be very similar with little changes. You just need to find  the correct gpio/port  pins for the ./config/fex (if legacy).
Nora Lee from Foxconn has always provided information when asked,  seems to be part of the business, need more information... just ask me. (you get the picture! ) 
 
Hope this helps.
 
 
 

Easy: Correct this mistake here: https://bananapi.gitbooks.io/bpi-m2-/content/en/bpi-m2-zero-hardware/bpi-m2-zero-hardware-spec.html (what to expect from a vendor who is not even able to specify the physical dimensions of his own products? It's now year 3 that we deal with this insane amount of stupidity/ignorance, these guys simply don't give a shit about 'information' they provide being correct or of any meaning).
 
As you can see in this thread as usual either schematics or their hardware description (provided fex file) are wrong, this simply sucks and prevents any development efforts. As you can also see above @Icenowy (member of linux-sunxi community) is the only person on this planet currently able to provide some real information (eg. voltage regulation different on her board compared to later board variants -- but you never know what they screw up with a new board revision).
 
As soon as SinoVoip starts to support their own hardware (and do not just spread BS) things might greatly improve though I've not the slightest idea why Armbian would want to support this board (just with BPi M2 Berry the M2 Zero only tries to attract clueless RPi users and I'm sure we really don't want these people here in the forum constantly asking why raspivid, omxplayer and adjusting display resolutions in /boot/config.txt doesn't work. Supporting boards that are designed as scam isn't that smart)

I downloaded the git repo of Myy and copied some files into armbian eg. zImage. I believe because of the sym-link it looks like it is 4.13 but the date of the changed
 
Nightlys are already 4.14 rc6

Found the real culprit. It was the patch that... enable the VPU services... Some issues with IOMMU definitions made it bork the entire IOMMU group, which included the video output IOMMU. So when the DRM driver tried to use the Video Output, no video output was usable anymore and it bailed out.
 
I'll perform some GLES tests tomorrow and if everything is working, I'll try the rc5 and release a rc5 !
 
 

which brands? models? Would be interesting so that others can try to reproduce your findings.

And one of that products you can only sell online since everyone trying it out in real life wants to throw it out of the window or back at the manufacturer asking for a refund
 
https://www.cnx-software.com/2017/02/15/gpd-pocket-cherry-trail-7-portable-computer-runs-ubuntu-16-04-or-windows-10-crowdfunding/

We could switch to torrent based image distribution (and leave images with throttled download speed as a fallback) if hosting providers don't have any objections against torrent traffic. If we have multiple servers we could just simply use them to seed the torrents.
Packages will be mostly downloaded when we release stable images, so they shouldn't generate much traffic compared to images.

I preffer Lakka.tv:
 http://www.lakka.tv/get/linux/ 
with decent Orange Pi support http://www.lakka.tv/get/linux/opi/ 
https://raspberryparatorpes.net/sistemas-operativos/lakka-tv-mas-emulacion-y-retrogaming-para-torpes/

OK, got it compiled into 4.13.3:  http://sprunge.us/aBaA
 
Both HEVC-service and VPU-service available in /dev/
 
[Edit]  I forgot they were using Stretch, tried to install the Rockchip Mali driver and nuked my xserver.  Tried to install their xserver but Xenial does not support a couple libraries they now need.  Building a Stretch image to give it a try.  I'll have to try this on 4.14 next as I'd rather not stuff (this level of) experimental code into Next.

If you plan to use built in WIFI in "Client" mode only, there shouldn't be a problem. I haven't tested much, but problems were in "AP" mode, client was kind of stable. So better test first, before changing the whole module (witch is generally good idea for this crappy board, but may be too much for your needs), how it interacts in client mode. About setup @reverend_t post explain briefly what you need. But if you prefer quick and not so complicated solution, with GUI, check out OpenWrt for this board (if there is still any download link alive).

You're absolutely right. The few hundred people a day downloading these broken and totally untested images (check statistics yourself: https://dl.armbian.com/_download-stats/) are all fooled since these images can't work (broken, untested, 'armbian style'). And only you are brave enough to publicly inform those lazy Armbians about this severe problem. Last image has been released back in June so those lazy Armbians already fooled thousands of poor users with providing broken and untested images. It's almost a miracle that you're the first to tell the truth! Keep on rocking!

If this is so, then why have many podcasts this in use ?
 
In my opinon Patreon would be a good additional option to:
   PayPal: Make This Recurring (Monthly) - option
 
Patreon, beside being an american company like PayPal, I see no bad thing about it, you keep 90%.
"It is popular among YouTube videographers, webcomic artists, writers, podcasters, musicians, and other categories of creators who post regularly online."
 
What are my responsibilities as a Patreon creator?
As I was reading this, does @Igor hold a Trademark for "armbian" - otherwise such donations could also be used to register it.
 

from your replies:
     I gather the first boot Ext4 resize delay (still an issue) others have mentioned (likely for a larger, 64Gig SD-card),
apparently are not much on an an issue when resizing a BtrFS file system.
    While at some point most users will in some way connect to the internet, the whole point of providing most of the ARMbian OS as an SD_card image might be able to come up running without the need for an additional downloads of:
wget https://mirrors.kernel.org/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb 
yes, "it's easy" if your ARMbian target on line..  but it may not be during first boot? 
    New ARMbian users (those who have not yet created a customized first boot script) would likely prefer to be asked (with defaults) how the ARMbian SD_card image should be handled.. this includes the possible size of a Linux swap partition near the end,  as well as the nature RootFS partition / FS resize operation.  That is: I think, blind first boot SD_card state change should be avoided.   On target boards that provide additional NV store beyond the SD_card, this first boot user interaction would likely be a good opportunity to prompt for an image install in addition to any options for a possible SD_card resizing operation.     
   Since one is already insisting that users set the root passWord..  it would be nice if new ARMbian users can easily understand that ARMbian SD_card image is being modified... and yes it's great that more advanced users can customize most all of this, then lets keep in mind that it's newcomers who will help grow the ARMbian community yet further.  

Tkaiser and Zador -
   Thanks for giving ARMbian's adjustment towards supporting the BtrFS some additional thought.
from my perspective resizing of SD_card partitions / File system images should not be automatic on first_boot,
but instead queried if should be done during first_login just after ARMbian's mandatory PassWd adjustment.
   I make this point, as a long delay during first boot, makes it hard for newbies to know what is going on, not to mention 
increasing any challenges associated with debugging the initial boot process.
 
   I'm not sure what how important it is for Linux to have a swapFile (in my case: NanoPi Neo2 has 512meg of RAM)..  
sure using ZRAM might help,.. then as Tkaiser points out swapping to/from the SD_card (the only mass storage on a Neo2)..
is not a very attractive solution..   since the SD_card resizing logic and this SD-card swap space allocation are both issues that are somewhat unique to systems that run with just the SD-card...   it might make sense to also ask (with defaults) how one would like to configure the SD-card/ ZRAM swap space options...
    Then these additional swap space parameters would be factored into the SD-card's partition adjustment / file system adjustment logic...
 
    Yes: taking an initial (post resize?) BtrFS snapshot sound like it would be a good thing!
 
   -Peter
     

Please note that I gave the author credit and also already referenced the link in post #1. Please also have a look what I've written there (the most important part to not trust in every stuff you find somewhere on the Internet!)
 
People interested in this part of the story should better read through http://www.cnx-software.com/2017/07/15/office-factory-business-model-and-ambitious-plans-of-shenzhen-xunlong-software-orange-pi-maker/ since there you can find also Statements from Steven and Igor 'correcting' the french 'report'.