StuxNet

Leave the PA13 as SPI_CS, and choose any other free GPIO for the IRQ, could be the original PA7.

PA13 : single pin cannot be IRQ and SPI_CS at the same time ...

On Zero SPI bus 0 is wired to the SPI flash pads (even if the flash itself it's not soldered), and SPI bus 1 is wired to the pin headers, so it should be
target = <&spi1>; instead

Please show your edited overlay.

Orange Pi schematics list this connector as "FPC24-05PH-BOT", so I would assume it is FPC 24 pin 0.5mm pitch bottom contacts.

@Igor I've edited both announcements a bit, see what you think of the changes. And please, please, please change "Before you think to report a problem with your board running Armbian' to something a little less... sharp? I know I would do that tongue in cheek (and do... hence why you sometimes see strikethroughs in my text)  , but that could be a little less unfriendly... "Before reporting problems with your board running Armbian" or ""Before reporting problems with your board running Armbian, check the following" ... something like that?

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.

Simply, no. Not that I'm aware of.

I've personally tested onboard UART and over USB-OTG for days on end. I've not experienced any problems (that weren't of my own doing ;D) Then again, I'm also using a small heatsink and mini 5v fan.
What are you doing with OPi/Arduino? The reason I ask is because I've experienced 'drop outs' in connection over SSH/UART, etc... (which exhibit similar behavior to what little description you provide) as result of power for various reasons on OPi. 
Updating/installing/compiling large packages High CPU usage Poor power cable Combination of the above + Heat Are you cooling OPi at all? Heat is a known issue with OPi Zero. Provide logs and/or more description. ie: armbianmonitor -u
 
 

Isn't convincing enough evidence for me to rule out:
Problem with UART, not necessarily "on Orange PI Zero." Problem with the Arduino's communication to the UART  

Yup yup. This I know. Wasn't asking for help just trying to help out dude I quoted. I'm very familiar with op_mode=2. It's probably the third time you've told me xD (I understand you're just trying to make the info known)
Also, I've tried manually modprobing it, custom configs, armbian-config with no luck. No pressure though. You've got more important things to worry about and I'm well aware armbian-config is in first versions and expect bugs.
 
TL;DR: I gotchu.

Yeah funny, dirt cheap electronics crap shows strange (expected) behaviour but people ask about 'kernel bugs'.

With an el cheapo CHG340 serial to USB or is it claimed to be a FTDI? I have three of them lying around. The CHG340 works just fine. Both FTDIs are fake, one works fine the other one made me crazy. So test your USB to serial before you run into 'unexpected issues on serial output'. Even if FTDI decided to no longer brick fake FTDIs with their driver.

Bingo.  Worked with USB ethernet!  Thanks!!!
 
Now waiting for my serial to usb cable to arrive from China to better understand why my orangepi won't boot when I compile the same .img, but with F2FS instead of ext4.  Most likely I'll be posting again in 3-4 weeks.

Let me guess, you have a plus model with emmc, and you're not booting armbian. You're booting the stock android on emmc.

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.

This guy is experiencing the same exact detailed issue as you.
Attempted to create kernel. Kernel doesn't boot. Kernel complains of Ethernet missing. End user wrote image with `dd` command.   
The only difference is that OP is using OPi Zero Plus, not OPi Zero.... big woop. Simply try with Etcher, report back. That might be hard though without a UART adapter... get MitchD to do it for ya xD

Sup MitchD? Keep up the good work.

Tinkering with API's is fun. Always wanted to allocate the scripts and tools made over time and allow quick access to the data they can provide. Never liked the idea of leaving a power hungry Desktop running to have access to it and am too paranoid to leave any SBC (FTP/WebServer) connected to the World Wild West for too long. As seen with the Mirai Botnet/DYN attacks. So my answer was to have something low power (SBC and armbian) that was at least 'secure enough' for me to let it interface with the world.

So this was made: https://github.com/BiTinerary/PersonalAPI


In a nutshell this is how it works:
Scripts on an OPi Zero that make API calls, scrape web data or w/e. I want to collect this data, check a sensor, trigger... from my phone. SMS/MMS an email to users inbox containing a keyword. Weather, Beer, Water plants, etc... The script uses a dictionary.txt file to constantly check the inbox for keywords. When one is found, it executes the key's respective value. ie: Key = Forecast. Value = Weather API call. Any returned value or echoed statement is passed as a string and sent as a reply, back to my phone.  
The only security concern is that anyone can fire off one of these scripts by sending a spoofed message, as a specific address, containing a predefined keyword. This might be a big security concern for some but personally, it's negligible. Not only do you need to know the address to spoof, keyword to send, parameter to pass, syntax to use, etc... but you would only succeed in entering a sandbox that I control.

Not to mention, SMS two factor authentication can be implemented later on and message content can be obfuscated to oblivion.
The sky is periwinkle but the grass is still green.

Anyways... Maybe someone can use the source code. Hopefully someone can use the source code. What are the thoughts of the community? Am I off my rocker? Suggestions on what you'd like to be add? Always looking for new ideas and projects.

cyclic redundancy check
 
I've never built my own kernel (I let Igor do that for me) but I know a bad 'hard drive' when I see one, from my computer repair days.

BAD CRC = cyclic redundancy check error

Make sure your SD card image writing software is 'approved' to work with armbian. ie: Etcher
This is (as far as I know) the only Armbian 'approved' method. Likely because Etcher verifies the image after writing, by default. Whereas dd and Win32Disk Imager (uses dd) don't require verification, of what it just wrote.

So..... bad SD card? Prove it is/isn't then come back asking for help.
 
Otherwise, I've received bad CRC errors due to power cables going bad at pain points. I think. Might of been that I was writing using Win32 at the time xD IDK for sure because I immediately tried fixing both birds with one stone as opposed to troubleshooting individually.
So double check that Power Supply if you haven't already. If you haven't already, see 0, 1 and 2 links in my signature. ;D

The kernel you supplied has no drivers, so I'm willing to bet there will be nothing in the TV out. 
 
The ethernet doesn't exist in the dtb, so it will not load it in the kernel. 
 
I have created a legacy image for you, which has basically everything working but the wifi. It has python and ssh like you wanted. The login is root,  password is root. 
 
For TV output, you'll want to change the fex file, as described here. Since there is no xserver, I'm not sure what you're going to be displaying on the TV. 
 
I hope this helps. 
 
https://drive.google.com/file/d/0B42tAZ6A-UbDV3dFTHhlQnVsdVE/view?usp=sharing

My default workstation. Soon it will be deserted on those small notebooks for summer time.
 
Usually there is, little but not much, random clutter around: papers, cables and boards. Core testing and debugging infrastructure is on the right side. Under the table I have two fix mounted and easy accessible USB powered hubs, which serves as powering and debug. Half ports have secured 1.5A per port. 14 ports in total, connected to server and shared around the network. Powering via extended USB3 hub proved to be enough in most cases, for rest and for special cases I use their original power supplies. which are somewhere below, differentiated with colours. Than there are 15 gigabit and 5 fast Ethernet ports and 2.4G AP. Since I am software developer first and tinkerer second, 40" of property is central point of interest. Sometimes it also get too small and also to avoid more cables, I have another fixed 19" in debug section. On the top of folder shelves I got an extremely low noise build server and another cabinet of electronics stuff. Lower left cabinet is place for small desktop computer and printer, while right side is filled with various parts, from cables, bigger boards, soldering equipment, hard drives, etc. Most of cables are hidden / embedded, to make this mess manageable. When I don't play with boards, I move cabinets in upper level and make use of whole table (minus keyboard and mouse).

I'm using puredata with alsa, and i have a latency of about 8ms. I haven't dug down and messed with drivers yet, but I hope to reduce that. I may add Jack in the future. 
 
I'm gonna guess you built it from linux 3.4 sources, right? In your boot partition, there is no script.bin. You'll need that instead of the dtb for the legacy images. I would also suggest getting a USB to serial device and plugging directly into the board via the headers to get boot output. It is extremely useful in cases like these. 
 
I will try with my orange pi zero tonight. 

Hi MitchD :
Your work is awesome. What I need to change to work in my orange pi zero?
I trying to make a rt kernel distro for my orange pi zero but  your solution is very cool.
Very Thanks!

try to log in via keyboard, not ssh. 

The file is /etc/shadow, there will be lines like:
 
user:asdfasdfasdf$$$$asdfasdfasdfsadfasdf::17178:0:98899:7:::
anotheruser:asdfasdfasdf$$$$asdfasdfasdfsadfasdf::17178:0:98899:7:::
systemd-timesync:*:17199:0:94499:7:::
systemd-bus-proxy:*:17199:0:94449:7:::
messagebus:*:17199:0:93459:7:::
ntp:*:17199:0:23499:7:::
(...)
You must remove the second field as:
user::17178:0:98899:7:::
 
Then boot, press enter on prompt for password and once login in, change password with passwd. 
 
Make a copy in case things go south. 
 

 

I think paid/unpaid and branching is a fools errand. Anyone who expects to have full support for any rando board isn't going to know the reason for the difference (much less make the Redhat/Fedora association) because they didn't even bother to research into the board or it's kernel before purchase to really get a feel for it's abilities, limitations and current status.

Stable/Experimental, in my mind, is more than sufficient. Keep it as a single branch. Do think things can get a little heated especially with Tech support but no different than any other forum and especially no different than real life tech support, believe me. I have some stories.

I kinda zoomed through the past few comments but I liked the idea of offering a slightly tiered system in terms of payment. For instance, if I could donate towards Armbian dev on a specific board, that would be dope. I would throw several pretty pennies at NanoPiNeoAir. To be honest though, it probably wouldn't affect my donating habits, which is as much and as often as I can afford. W/e though, I'm a strange fruit ;D

Maybe a trend could become visable though if hundreds of cheapos buy OPi Zeros and never donate to the dev of it. Something can be said for the demand and visibility to Armbian by supporting it but something can also be said for the willingness and ability to support.
 
For instance:
~ "Donate here to support X feature of Y board" *Thermometer to goal*
~ Info graphic: Armbian on 9999 OPiZero boards. $50 donated. Armbian on 300 NanoPi Neo boards. $600 donated.

 

That is network manager, issues are most likely related and need to be investigated when possible. No quick fix - only workarounds are possible at this stage.