zador.blood.stained

This is a SoC/CPU network interface that connects to the Topaz switch: http://wiki.espressobin.net/tiki-index.php?page=Block+diagram
So it has to be brought up first in order to work with interfaces that are behind the the switch.

Running "systemctl --user enable ..." using su won't work according to my tests, so psd activation needs to be reworked into a separate login script.

Apart from DT changes, driver shouldn't need much adjustements for 4.14, if any. 4.15 (current linux-next) is a different story though.

Hm. According to schematics Opi Zero+2 H5 doesn't wire USB port 1 anywhere, and Opi PC2 and Prime have USB1 enabled by default.
And since I also don't see anything that would resemble an amrbianmonitor -u support link and a serial console log from u-boot I don't think I have anything I can look into.
 
It is possible to check that overlays are applied correctly in /proc/device-tree and probably somewhere in /sys too.

This is not related to OPi PC2 and H5 in any way. And I wold try to get working a combination the existing in-kernel driver and non-Realkek hostapd first.

@Tido
If you think that a user didn't do his homework like using Etcher and trying a good power supply, IMO it's better to ignore posts/threads and move obvious hardware issues (for tested stable images) to the dedicated subforum, not delete them. If you delete something they may post the same thing again and again (happened already, even if you simply moved their thread to another subforum), and not giving an answer may give a person some time to think and search for a solution, and only if people complain that they think their problems are ignored they can be pointed to the power supply and SD card FAQ.
 
Again, it was discussed already - the only things that should be hidden or deleted are spam and duplicate posts. Anything else should be left as is, though sometimes you (as a moderator) can i.e. fix typos in the thread title to make the thread searchable in the future.
 
IMO the main problem with this is that without a serial console you can't be 100% certain that it's the power supply stress test that caused the board to not boot. This doesn't mean that we don't need to implement the stress test, it just means that it may not be as effective solution for diagnosing boot problems as we want.

I don't remember anyone linking the mainline DT for this board, so here we go:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=f4ff257cd1607ef79f6647a633d6cc495529cbff
 
It's interesting to see a CPU operating points table there (so DVFS should work already), looks like Ethernet (with DSA), USB and basic peripheral interfaces (I2C, CIR, I2S, PWM, GPIO, ...) should be supported too, but don't see anything that would represent SATA or PCIe yet.

Yes
 
But we (and Icenowy in her branch) reverted that removal.
"Unstable bindings" doesn't mean that something isn't working or is unstable, it just means that DT maintainers are not happy with the way DT represents the hardware.
Today the 7th iteration of the attempt to resolve this was posted: https://groups.google.com/forum/#!topic/linux-sunxi/jxF_AIJP0VA

There is no KMS driver for this hardware yet, it may be added to the mainline kernel in 3-6 months from now.

This (and similar relocation related issue on XU4/HC1 which killed UAS) should be hopefully fixed. Other kernel configs may have to be changed too in the future.

It checks /etc/armbian-release, but since you added it to the package list in lib.config it is installed too early, before the board support package (which contains the /etc/armbian-release file)
Installing it manually using apt-get in customize-image.sh should work fine.

Installing glshim for all applications doesn't really work - it doesn't provide full OpenGL implementation so i.e. web browsers and other heavy applications will crash with it, and it's no a good thing.
It can (and should) be used with individual applications by adding the private directory to LD_LIBRARY_PATH (at the beginning), or by preloading a special library.

I can tell that I tested Mali wayland/gbm driver version and it works well.

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.

Got it : https://github.com/armbian/build/blob/master/packages/bsp/common/etc/init.d/firstrun#L174-L179
But this code isn't ran during a simple upgrade ...
 

No DVFS on the next branch, so CPU there is running at 480MHz by default.

Or we should check if we can use systemctl isolate?
 
Yes, but we need to make sure that the directory /var/log is created on the target

After comparing SoPine and Pinebook schematics I can say that they are not the same. On the Pinebook vqmmc (port C power) is wired to a separate AXP output, on the SoPine vmmc (eMMC power supply) and vqmmc are tied together (and to the main 3.3v output), so it will be impossible to switch to speed modes that require 1.8V vqmmc, and any attempt of switching vqmmc to 1.8v will affect DCDC1 output voltage.

Yeah, I'll fix that. Usually I'm lazy when it comes to DT...
 
I tested it already. Just one line fix was required to make it work, which is already included on my github:
https://github.com/jernejsk/linux-1/commit/5de498da7efd4593976c4e41ca7367ac23352616#diff-0dd6c05e592804ae87e06c218a333a37R318

Patch the driver to use data from the FEX file (if you want to use the fex)
 
You need to supply the driver with platform data (check the header file in the repository you linked). You can either use fex, module arguments or hardcode the values as constants or defines.
 
No idea, you can compare the drivers to check the differences.
 
You still will need to add the platform data hacks/code if you want to use this driver on sunxi 3.4.x kernel, in addition to possible backporting issues.

So we (or rather Maxime/Free-electrons) got r6p2 Mali400 armhf blobs with a good license. No arm64, no mali450 (?), so I wouldn't call this "closed"

Because I won't call it "acceleration" but "hardware support" (AFAIK Kodi doesn't run on software OpenGL ES (Mesa) at all) or "offloading", and if I really wanted good software support I would look i.e. in the direction of i.MX6 with Vivante GPUs that have Etnaviv open-source drivers.

No, at least this seems to be fixed. In any case overlays functionality affects stable branches too, so it's not "development, not supported", so thanks for the bug report.

IMO instead of deleting it's better to post a correction or clarification, or in the worst case edit your own message striking out the incorrect information like this.

https://github.com/armbian/build/issues/593