chwe

Added yet another link - directly to "Getting started". @pfeerick I hope words are not too harsh ?

https://sites.google.com/site/zberrysbc/
 
Is it worth it?  Assuredly not, but you can't help but smile if you have any sense of nostalgia.  It also doesn't help that the entire thing can be implemented in an FPGA, although that may actually turn out to be more expensive...

Absolutely agree on that and was more talking about what happens in the future. In this specific case I see myself at fault since announcing to duplicate/recreate the thread and then not doing so timely. But fortunately we identified the issues quickly and those were fixed either internally or externally (thanks @Igorand Alasdair!).
 
But these issues should remind us that Armbian forum is not only used for internal discussion but also to have some impact on the outside (at least that's one of my uses, I still refuse to run my own thing/blog and try to collect knowledge here as part of a community to try to help letting the community grow).

Finding an answer by your self and share this is always a good oppurtunity. 

Since this thread is started, a lot of improvements are made to clean up the forum. Also a lot of cool ideas to avoid same questions again and again. I have one for the Getting Started guide. Here's the part of burnig the SD-Card:
Why don't we add one sentence about why we use Etcher to burn Armbian on a SD-Card? Something like: Compared to other burnig software like win32 etc. etcher validates the image after burning so that you don't run into SD-Card corruption. 
On the SD-Card part there is clearly writte what TK found out with all his tests, but the reason why someone should use etcher isn't that clear. It's obvious that not every one will read it, but most of the blogs I saw in the past, copy-past their sentences from docs to save time, and hopefully they'll 'spreading of the gospel' 
 
Thinking about 'The Ten Commandments' of armbian:
1. Use a reliable powersource
2. Burn your image with etcher
3. Tbd
Nobody calls into question the ten commandments, whereas a lot of people does this on armbians recommendations...  Ok, sounds like a religious armbian sect (time to go to bed  ). 
 
Edit: Just had to search to find my own thread about my IoT stuff that I'm doing.  I miss somehow a subforum where users can describe their projects. For sure they can write a tutorial, but it can inhibit the less experienced users to call it a tutorial (I would never call my thread a tutorial cause it started more or less as a link sharing of some stuff I found with google, as soon as I have more time & being sure that everything works fine, I'll rewrite it to make something that I would call a tutorial).

Just as information. It seems all external links to individual posts are broken which I consider worst case scenario since I'm writing here tutorials for a reason (to both spread some knowledge and also to get more attention for Armbian).
 
Eg. linking to read this first will be redirected to top of thread instead https://forum.armbian.com/index.php?/topic/3953-generate-omv-images-for-sbc-with-armbian/&do=findComment&comment=32340
 
The first one is the example link as I was using it all the time from external, the second one is the new link:
https://forum.armbian.com/index.php?/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/#comment-32340 https://forum.armbian.com/index.php?/topic/3953-generate-omv-images-for-sbc-with-armbian/#comment=32340 Update: it seems the title change is responsible for this. @Igorcan you please try to fix this (were other thread titles changes as well?) and can other mods please keep in mind to not change titles when moving tutorial/knowledge threads or 'hot stuff'? I've set maybe a few hundred external links to specific posts here and really don't want to see them getting useless.  

Of course, not ...
 

but you're still their Nr.1  (sry for the off-topic)
 
IMO it 'sounds' like a nice product from the product page, so a lot of server ideas will come up by various users. I'm not really interested in server applications on a SBC and my knowledge on this field is more than limited (I'm more the IoT intrested guy, than the server guy). But my main question is, compared to boards that are still on market, is there really a benefit compared to other boards on hardware side? Imagine every thing will work properly on software side. Will the comunity have a (real) benefit compared to other boards? Since it seems a lot of work to get this board to work (SoC without that much community support in the past etc.), I think weighting the benefits compared to the workload should be kept in mind.

ok I'll answer my own question since i figured it out.  Start terminal emulator, type su and enter the superuser password.  then type passwd <user> and enter the user password. voila

some more numbers on pin 1&2 that are working (setup: orangepi zero rev. 1.4, micro USB powered, samsung evo32gb, headless ssh over LAN, with NRF24l01 radio module):
opi in idle modus: 5.16V
running cpu-miner: 5.12V
 
Edit:
Just tried to create a underpower situation on my opi zero (not easy when you throw away most of the bad usb chargers& cables). 
I got finally it with an old sony mobile phone charger and a thin noname 1m cable. Without any load on it delivers exactly 5.00V on its output (measured with a Keweisi USB powermeter). Connecting it to the opi zero voltage drops to arround ~4.8V on the USB output and ~4.5V on pin 1&2, which result in no proper startup of the opi. 
Things that indecate that opi 0 doesn't startup properly: 
-The LED (D7) does not shine (green one)
-The Opi 0 gets unexpectable hot (disconnected it after 1min to avoid burnig something on my board)
I don't wanna watch all your videos to see if D7 LED shines when you power the board but it's up to you to do that.

For those of you who are interested in using a OPI zero as a small IoT-Server. I have some hints to get it working. It's more or less a lmgtfy How To plus some arduino code to test if it works.
Hardware:
OrangePi 0 with Armbian 5.25 connected over lan to my router DHT11 Module on a Wemos D1 mini (a small cheap wlan MCU for ~3$ which can be programmed via the Arduino IDE) Installation:
First of all we install node-red on the OPI. Instead of rewrite how to do that again I just give you the link who to do that: Node-Red on armbian
Second we install Mosquitto as a mqtt broker. If I have it right in mind I followed this instructable (I'm not shure, it's more than 2 weeks ago and I didn't save the link then): Mosquitto
To represent the data of our DHT sensor-node graphically we install the node red dashboard module in: /usr/lib/node_modules/
with npm i node-red-dashboard
If everything goes right you should have access to node-red via browser on port 1880:
192.168.1.xx:1880
and to the UI of dashboard:
192.168.1.xx:1880/ui/
Setting up everything:
Now we're setting up the Wemos D1 mini. DHT11 wiring (DHT-->Wemos):
VCC -->3.3V 
Signal --> D4
GND -->GND
Some of the Wemos pins are capable for 5V (A0 definitly not!) but the DHT readings gets noisier when the device is powered through 5V (don't ask me why, I'm not en electronic engineer...)
For the testprogramm we need two libraries which can be installed via the arduino IDE lib manager (+ ESP8266WiFi.h which comes when adding the generic ESP8266 board via Boardmanager):
PubSubClient.h (PubSubClient by Nick O'Leary) DHT.h (DHT sensor library by Adafruit) And here comes the simplyfied code publishing to the mqtt broker:
The code is more or less a combination of the examples which comes with the PubSubClient & DHT libraries + throw away all the stuff that we don't need (I had also a version of code where the Wemos D1 mini subscribe to the mqtt broker and gets a timestamp injected from node-red which was then added to the published sensor data).
Humidity data is stored in the "hum" topic, temperature in "temp". Keep in mind that if you plan use more than one senor-node, you should name the topics properly (see: MQTT topics best practices for more information about proper topic nameing)
We can now generate our test-flow on the node-red webpage (See printscreen). Subscribe to the mqtt topics and publish it on the chart and gauge (more information about Dashboard can be found on: Node-Red & Dashboard). 
Powering the Wemos and deploy the created flow shoud show us the graphs on 192.168.1.xx:1880/ui/ (see picture)
To call me an IoT expert is like someone calling tkaiser a fan of micro USB powered SBCs. According to the MIT licence this HowTo  is provided "as is", without warranty etc.

I doesn't expect that it differs so much from a opi zero.. so usage of the forum search engine would help.
Search for mqtt
 

For those of you who are interested in using a OPI zero as a small IoT-Server. I have some hints to get it working. It's more or less a lmgtfy How To plus some arduino code to test if it works.
Hardware:
OrangePi 0 with Armbian 5.25 connected over lan to my router DHT11 Module on a Wemos D1 mini (a small cheap wlan MCU for ~3$ which can be programmed via the Arduino IDE) Installation:
First of all we install node-red on the OPI. Instead of rewrite how to do that again I just give you the link who to do that: Node-Red on armbian
Second we install Mosquitto as a mqtt broker. If I have it right in mind I followed this instructable (I'm not shure, it's more than 2 weeks ago and I didn't save the link then): Mosquitto
To represent the data of our DHT sensor-node graphically we install the node red dashboard module in: /usr/lib/node_modules/
with npm i node-red-dashboard
If everything goes right you should have access to node-red via browser on port 1880:
192.168.1.xx:1880
and to the UI of dashboard:
192.168.1.xx:1880/ui/
Setting up everything:
Now we're setting up the Wemos D1 mini. DHT11 wiring (DHT-->Wemos):
VCC -->3.3V 
Signal --> D4
GND -->GND
Some of the Wemos pins are capable for 5V (A0 definitly not!) but the DHT readings gets noisier when the device is powered through 5V (don't ask me why, I'm not en electronic engineer...)
For the testprogramm we need two libraries which can be installed via the arduino IDE lib manager (+ ESP8266WiFi.h which comes when adding the generic ESP8266 board via Boardmanager):
PubSubClient.h (PubSubClient by Nick O'Leary) DHT.h (DHT sensor library by Adafruit) And here comes the simplyfied code publishing to the mqtt broker:
The code is more or less a combination of the examples which comes with the PubSubClient & DHT libraries + throw away all the stuff that we don't need (I had also a version of code where the Wemos D1 mini subscribe to the mqtt broker and gets a timestamp injected from node-red which was then added to the published sensor data).
Humidity data is stored in the "hum" topic, temperature in "temp". Keep in mind that if you plan use more than one senor-node, you should name the topics properly (see: MQTT topics best practices for more information about proper topic nameing)
We can now generate our test-flow on the node-red webpage (See printscreen). Subscribe to the mqtt topics and publish it on the chart and gauge (more information about Dashboard can be found on: Node-Red & Dashboard). 
Powering the Wemos and deploy the created flow shoud show us the graphs on 192.168.1.xx:1880/ui/ (see picture)
To call me an IoT expert is like someone calling tkaiser a fan of micro USB powered SBCs. According to the MIT licence this HowTo  is provided "as is", without warranty etc.

Added the -ings for you..
 
The dashboard things came from a add-on. At the moment I'm a little bit annoyed from the mysensor stuff. So much of their sensor nodes are fix configured which makes it hard to me to understand, how their library work. My purposes for the hole IoT thing isn't that my opi recognizes when go to the toilet or other senseless homeautomatization stuff (senseless to me, if someone else needs this feel free to make a toilet node ). I want to use it in lab-automatization (mostly chemistry labs). So most of their predefined nodes are useless to me. Nevertheless, I'll start with things, where an error doesn't burn my labratory.
IMO knowlege should be shared to give something back to the armbian community who makes it possible to me, even thinking about doing lab-automatization on an sbc. 
 

I also started to get the cheap nrf24l01 boards to work. when I followed this tutorial, I always get the error that something with the gpio was wrong.
mysgw: Starting gateway... mysgw: Protocol version - 2.2.0-beta mysgw: MCO:BGN:INIT GW,CP=RNNG----,VER=2.2.0-beta mysgw: TSF:LRT:OK mysgw: TSM:INIT mysgw: TSF:WUR:MS=0 mysgw: Could not open /sys/class/gpio/gpio24/direction
Using this configuration settings showed that the nrf24l01 should work on orange pi zero side:
root@orangepizero:/home/opi/MySensors# ./configure --spi-spidev-device=/dev/spidev1.0 --my-transport=nrf24 --my-rf24-ce-pin=2 --my-rf24-cs-pin=13 --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 followed by make should give you something like this:
The evening would show if I also get it to run on the sensor node side (don't have time at the moment).

For those of you who are interested in using a OPI zero as a small IoT-Server. I have some hints to get it working. It's more or less a lmgtfy How To plus some arduino code to test if it works.
Hardware:
OrangePi 0 with Armbian 5.25 connected over lan to my router DHT11 Module on a Wemos D1 mini (a small cheap wlan MCU for ~3$ which can be programmed via the Arduino IDE) Installation:
First of all we install node-red on the OPI. Instead of rewrite how to do that again I just give you the link who to do that: Node-Red on armbian
Second we install Mosquitto as a mqtt broker. If I have it right in mind I followed this instructable (I'm not shure, it's more than 2 weeks ago and I didn't save the link then): Mosquitto
To represent the data of our DHT sensor-node graphically we install the node red dashboard module in: /usr/lib/node_modules/
with npm i node-red-dashboard
If everything goes right you should have access to node-red via browser on port 1880:
192.168.1.xx:1880
and to the UI of dashboard:
192.168.1.xx:1880/ui/
Setting up everything:
Now we're setting up the Wemos D1 mini. DHT11 wiring (DHT-->Wemos):
VCC -->3.3V 
Signal --> D4
GND -->GND
Some of the Wemos pins are capable for 5V (A0 definitly not!) but the DHT readings gets noisier when the device is powered through 5V (don't ask me why, I'm not en electronic engineer...)
For the testprogramm we need two libraries which can be installed via the arduino IDE lib manager (+ ESP8266WiFi.h which comes when adding the generic ESP8266 board via Boardmanager):
PubSubClient.h (PubSubClient by Nick O'Leary) DHT.h (DHT sensor library by Adafruit) And here comes the simplyfied code publishing to the mqtt broker:
The code is more or less a combination of the examples which comes with the PubSubClient & DHT libraries + throw away all the stuff that we don't need (I had also a version of code where the Wemos D1 mini subscribe to the mqtt broker and gets a timestamp injected from node-red which was then added to the published sensor data).
Humidity data is stored in the "hum" topic, temperature in "temp". Keep in mind that if you plan use more than one senor-node, you should name the topics properly (see: MQTT topics best practices for more information about proper topic nameing)
We can now generate our test-flow on the node-red webpage (See printscreen). Subscribe to the mqtt topics and publish it on the chart and gauge (more information about Dashboard can be found on: Node-Red & Dashboard). 
Powering the Wemos and deploy the created flow shoud show us the graphs on 192.168.1.xx:1880/ui/ (see picture)
To call me an IoT expert is like someone calling tkaiser a fan of micro USB powered SBCs. According to the MIT licence this HowTo  is provided "as is", without warranty etc.

It is frustrating, it's also universal human nature.  I sold car parts while going to college, people always wanted to buy the generic parts instead of the original equipment and then got mad when they lasted 2 months instead of 5 years.  
 
Even now working with Automotive companies, sometimes I have to explain the laws of physics and why my products can't defy them.
 
So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero?  I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions.
 
Example:. "Why can't my nanopi neo transcode 6 video streams simultaneously while cooking me breakfast?"
 
From moderator:. "post moved to "collection of insane and redundant questions.  See FAQ in OP of thread."

keep in mind, you dont spend this money to the armbian devs. you spend it to xunlong. So, being rude to the guys who gives you all the support for free isn't the best idea to solve your problems right?
Especially if you're under pressure and need support from people that give it for free, be polite. It doesn't help you if they are pissed,  cause they can just stop answer to your tread and you're alone with your problems.
 
I can confirm for you that with a rev. 1.4 opi zero (powered over micro usb @2A PSU, with samsung evo 32gb sd-card) and debian on it works fine (see pictures, for sure good enough to work with ssh).  Getting four (if I have it right in mind) damaged boards at once seems you're a really unlucky guy or you're brick them somehow (btw I would never power them with alligator clips, that's a harakiri way to power sensitive things).
 
With Igor, martinayotte and tkaiser you had at least three guys answering to your questions who are good in problem solving.  Doing their proposals should help you immediately to determine if it is a software or a hardware problem.
 
 

Also slow as hell. SanDisk gets interesting when choosing Extreme Pro or Plus. Best buy at the moment are Samsung EVO with 32 or 64 GB on boards like Oranges where sequential transfer speeds are limited by the host's SDIO implementation. Since they're both cheap and show excellent random IO performance while being fast enough when it's about sequential transfer speeds: http://forum.armbian.com/index.php/topic/954-sd-card-performance/

What about this?
 
New board appeared and it either is available already or it will be sold in the future Board passes the requirements checklist (documentation, no serious hardware design flaws, good software situation - like planning or ongoing mainlining, board samples can be obtained in sufficient quantity) Internal (team) voting and discussion to see who is personally interested in supporting this hardware, bringing it into the build system, testing, documenting and maintaining it in the future Making a decision: accepting, declining or postponing. New boards can be added to the "WIP" section  
For the phasing out process:
Supported board has significant hardware design flaws or software issues that can't be solved due to missing hardware samples or can't be solved by us at all Internal (team) voting and discussion to see who is personally interested in supporting the board in case of software issues End Of Support notice published with details for the reason and possibility in reverting this decision in case HW samples can be obtained Board is moved to the "EOS" section

As you can imagine, my time & know how (in this area) is somehow limited, but if it helps you and other developers to do the hard stuff that I'm for sure not able to do, we can give it a try. 
 
I see the point, maybe something to consider as soon as more important issues are solved. I'm still impressed by the FriendlyArm wiki, but for sure the have much more man power to do that.  

Conclusions:
 
- nightly kernel and BSP building yes, nightly images once per week
- focus more to provide simpler way for new developers to get in
- nightly images should be carefully picked to provide best "price performance" ratio
 
and another proposed actions:
 
- moving another three boards (Lamobo R1 / Cubieboard 1 / Lime A10) into deprecated sessions. All those boards get one last update with last known working configuration and frozen kernel packages
 
 
This a current project overview, which we try to follow. Is this time span perfectly o.k. ? Not sure. We will need to adjust it in the future, but it’s something to go with and stick to it, when and if we agree:
 
UPCOMING MILESTONES
Milestone Responsible Person Due On Feature developement --- Due in 81 Days Feature freeze --- Due in 90 Days Beta testing and bug fixing --- Due in 130 Days Writing release documentation --- Due in 142 Days Launch --- Due in 149 Days Withing project management we manage to establish fully operating testing system – a person get’s an email, when and what to test – his report is clicking few check boxes + adding a note when necessarily. Technology was tested twice and it works, methodology needs broad discussion. Project manager is the one, who has overview and drive (volunteer) developers to fix this and that. In reality this means I was driving myself and Michael was assisting in this and solving problems which are out of my league. Since we were also testers, most of bugs were saved already on the way ...
 
 
Project management is yet another full time position, which waits to be filled developed and filled in. We deliberately use this hidden, because I was not sure if it’s the right way to go, because not everybody needs to  be involved in everything and because not finished products are better to hide. Check email.
 
Until there is no somebody who will take a full lead on this, I am moving it forward with (my) highest possible speed. Well, in fact it's already we. Tido is helping in this beta trial process.
 
 
We can add text to forum description, which board are officially supported – I know people will still fail to see.
 
 
Yes. This is at least much simpler to support and is to consider.
 

Yeah. At least we are highly motivated to end / limit at best as possible.
 
 
We would certainly need more moderators, which would take care of such questions appropriately. Technical knowledge about those boards is not a requirements. If @chwe wants to take care of general moderator duties, he is one click away
 

This is fine, but very hard to maintain.
 
The rest elsewhere. This one is already off topic.

---