zador.blood.stained

Please show your edited overlay.

Will be fixed eventually. Some files are being moved from one package to another, and currently there are some missing relationships between those packages.

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

Yes. Also a "community supported" configuration can be added to the build system to automate image building.

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

No support currently. Unofficial/community support in the future may be possible, but it depends on the vendor providing complete and correct documentation (I'm sure @tkaiser will write something since this is the first thread here discussing this board).
 
The only similarity is the form factor.
 
And if your project is multimedia oriented (i.e. using HDMI display or CSI camera) I would strongly recommend staying with the Raspberries.

Also it's worth noting that the Ohm's law doesn't really apply to the internal impedance of a power supply since it will be non-linear.
 
Also measuring the output voltage can be tricky. With a low quality (or overloaded, or with dried output capacitors) power supply the voltage will be pulsating, and a cheap multimeter won't be able to display a good (RMS) value.
 

Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
Basics:
It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

Illustration 1: AWG print on cable
Example:
If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
*this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
 
Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

Figure 2: Voltage drop of a copper cable at various thiknesses
If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
 
Case Study:
Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

Illustration 2: Setup vor measurement
FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
Table 1: Specification of the tested chargers

Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
Table 2: Tested micro USB cables

Results:
After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

Figure 3: Voltage drop at delivered current of all chargers
Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

Figure 4: Voltage without load, with load and on output and @powerbank
.
Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
Conclusion:
What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

Illustration 3: Recommended powersource
 
 

What kernel are we talking about (since this is posted in the "mainline" section)?
 
For the legacy - pull requests with fixes are welcome, at this point it's unlikely that the legacy kernel will receive any significant changes/patches.
For the mainline - you have to find RT patches that match the available mainline kernel version (currently it's 4.11.5).

AFAIK it's not related to systemd. Some loglevel overrides come from Debian/ubuntu default, i.e. on Xenial it's caused by /etc/sysctl.d/10-console-messages.conf (added by the "procps" package), and lack of kernel messages on any console can be caused by multiple console= defines on the kernel command line, since without explicit forwarding (i.e. by journald) kernel will print its boot log only on one console.

This means that "NoNewPrivileges" option is not correctly applied to the TOR service. What file did you add it to? Did you reload the systemd configuration?
 
Edit:
You need to add something like
[Service] NoNewPrivileges=no to a new file - /etc/systemd/system/tor@.service.d/10-no-new-privileges.conf
this should apply this setting to all TOR instances. "sudo systemctl daemon-reload" is required to reload the configuration after changing.
 
Upstream Debian Jessie relies on kernel 3.16, Ubuntu Xenial - on kernel 4.4. "NoNewPrivileges" option tries to use kernel features that are not present in kernel 3.4, so it has to be disabled first.

I would've preferred iTestAgain

How exactly did you connect the serial adapter to the cubietruck? GND-GND TX-RX RX-TX?

And I'm assuming you saw this in the docs page you linked:
 

https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1702407

Highly doubt it because of totally different situations - different target audience, different software state to begin with (linux support for generic x86/x64 vs ARM), people buying hardware first (due to its low price) and trying to fit it to their use cases later
 
We are already splitting kernel branches (default/next/dev) and image types (stable/nightly), and this doesn't work in general since people don't get the difference between them.

Minimum kernel version and all new kernel features required by systemd and udev. In your case NM fails to start because namespaces and/or cgroups are not available. It is (in this case) a security enhancement which can be disabled/bypassed for different services (including NM) but I'm sure that we will rather not provide legacy Stretch images at all than try to bypass and lower the system security measures.
 
https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix
Due to some critical features currently missing in mainline we don't provide supported images with mainline kernel for H3 based boards. While mainline is possible to use, it is provided with no support only for experts and experienced users.

Legacy 3.4 is too old to use in Stretch images, so upgrading to Stretch will not be supported and there won't be Stretch based Armbian images with the legacy kernel.

Requirements
Fresh enough nighly or manually built image Latest kernel and dtb packages (26.03.2017 or newer)  
Limitations
As stated in other PWM related threads, hardware PWM output is supported only on pin PA5 which is also UART0 ("debug" serial console) RX pin, so enabling PWM will disable this console.
 
Activation
Add "pwm" to "overlays" line in /boot/armbianEnv.txt
Example:
overlays=pwm Reboot is required to apply the changes
Armbian overlays documentation: https://docs.armbian.com/User-Guide_Allwinner_overlays/
 
PWM sysfs interface
Official documentation: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/ABI/testing/sysfs-class-pwm?h=v4.10
Please note that this ABI is considered "testing" so it may change in the future.
 
Sysfs interface example
# activate the PWM. On H3 only 1 PWM is supported, so exporting PWM 0 echo 0 > /sys/class/pwm/pwmchip0/export # set period to 10ms echo 10000000 > /sys/class/pwm/pwmchip0/pwm0/period # set normal polarity. needs to be reset explicitly. Bug? echo "inversed" > /sys/class/pwm/pwmchip0/pwm0/polarity echo "normal" > /sys/class/pwm/pwmchip0/pwm0/polarity # enable the PWM echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable # set duty cycle to 1ms echo 1000000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle Result:
# set duty cycle to 2ms echo 2000000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle Result:
 
# set duty cycle to 1us, period to 2us echo 1000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle echo 2000 > /sys/class/pwm/pwmchip0/pwm0/period Result:
 
Please note that some settings needs to be changed in a correct sequence, i.e. you can't set duty cycle higher than period
root@orangepiplus2e:~# echo 1000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle root@orangepiplus2e:~# echo 500 > /sys/class/pwm/pwmchip0/pwm0/period -bash: echo: write error: Invalid argument root@orangepiplus2e:~#  

https://linux-sunxi.org/Xunlong_Orange_Pi_Plus#SATA

Make the Raspberry Pi great again! 

Make the Raspberry Pi great again! 

I would prefer to collect all known issues first, and @tkaiser most likely would prefer if you started a "board bring up" thread.
 
Then we should look at the mixer values or maybe extract asound.state from a fresh ayufan build.

Awesome Helios4 is successfully funded !!!
 
We still accept orders till the end of the campaign : July 19, 2017
 
https://shop.kobol.io/
 
Thanks for the support.

I remember reading about issues with UART DMA on the Tinkerboard, so maybe Rockchip DMA in general is partially broken?
According to Rockchip SPI DT bindings DMA properties are optional so you can try removing them, but whether it will work without DMA depends on the driver.