zador.blood.stained

... or not. Merged here and renamed this thread to include "Orange Pi One Plus" in the title.

There is no such configuration in the Armbian build script. If you added a configuration or made any other modifications to the build script or its configuration you have to fix issues by yourself - add missing device tree files, fix u-boot configuration, etc.

Renaming/disabling the xradio patch file is a better option IMO.

This is caused by 4.14.17 kernel update - at least the xradio compilation is broken.

Yes, but in a long run this may not be enough, there are too many sunxi SoCs and not that many involved developers to get mainlining efforts close to Amlogic or Rockchip levels, and any documentation issue only makes it worse, especially for essentials like DRAM code.

Yes, but in a long run this may not be enough, there are too many sunxi SoCs and not that many involved developers to get mainlining efforts close to Amlogic or Rockchip levels, and any documentation issue only makes it worse, especially for essentials like DRAM code.

For me frustration comes from this:
- legacy / backwards compatibility that prevents making advancements or fixes
- trying to make "one fits all use cases out of the box" images - too much stuff to maintain
- lack of communication/understanding of some issues, i.e regarding base firmware package contents (example of the results)
 
Wrong user expectations come from existing problems - web pages contents, extra (IMO excessive) branding, overall project positioning

Looks like u-boot MMC numbering changes broke backwards compatibility with our old boot script (that had "mmc 0" hardcoded everywhere, pre-23-08-2017), now the question is which images are affected.
@Igor
I would recommend removing new u-boot packages from the repository for all sunxi devices that have eMMC. Or simply for all sunxi devices since I'm not sure if other old (something like pre-5.30) images will be affected.

IMO, minimizing complexity and subsequently saving energy should be a recurrent activity. Its so simple to get lost in a pile of code, projects and tasks. Few of people, including myself, are too involved and sometimes is getting too much. I don’t want to get depressed or disabled by stress, so more tasks should be redistributed or cut. It's not just about board support count.

When a board can come to a support list:
 
- if there are not a lot of problems and most of the stuff already work. At least: network, (HDMI), thermal protection, to run as a server.
- if there is at least one stable kernel,
- if we got minimum of two boards/persons to cover, except special cases, where one board is stripped version of the one we already support
- [new] if we have chosen a responsible person(s), not necessarily a developer, for editing board status and to join perhaps with personal motives and spread responsibility. Technical part of editing is under rework and will be done in some simple manner within a Wordpress only (no more WP + github .conf + github. Putting to other words – if we, as a community, wanted to have longer support for certain boards or their less aggressive moving to »deprecated« section, we need people to take a part in this maintainer/tester role - to take responsibility. BTW: last week I throw out some obvious deprecated candidates, while I still have some left: Odroid C1, Bananapi+, Beelink X2, Lime1. From a kernel perspective: sun4i, sun7i, odroid1
- what else?
 
From this perspective, H3 NEXT images should now get a support status. Should they? Shell we merge forums into one? Its yet another decision to make? Should I just do it or shell we spent "long hours on meetings"? BTW. There was an idea by @Tido that we should start to use some VOIP solution (https://wiki.mumble.info) to regularly, better and faster clear out opened questions. If this helps save energy, I fully support the initiative.
 
Then, there is a question how a board becomes a WIP and why it is not just CSC? How is this path from nothing to WIP, something like »Board bring up« / »Support proposal«? It seems like a good idea, but the very first proposed board, Rock64, proved to be a hard nut or it is simply too early to do anything with? There are many uncertainties and it’s a hit and miss game per se. Or rather push here and there – only our initiative is anyway not enough – and move the board among supported, when we have enough "ifs" on the table?
 
In essence is all about a kernel, not boards. I would rather start talking from there, always. And what @zador.blood.stained already exposed - there is usually a personal motive to work on some board or type of problems and we have to consider that, when doing some plans or talking and organising the work around the project, but certain things, those which might not require a lot of time and energy, could be agreed upon. 
 
Reasonable minimal OS images, exactly. Perhaps we have to look on this more from the user side. But we face a big variety, from »I am new to Linux« down to kernel hackers. Well, first ones take a lot of time and ask stupid questions, while others don’t ask much, but when they do, sometimes is not possible to answer – because of quantity, complexity or we simply don’t know the answers.
 
Cleaning is a very good idea but its some work.
Yes, this is a good description, but how users see this? Each Linux distribution is nothing but a mix of just some packages. Some only mix and add a stamp, others do big changes. Nevertheless, how big changes are, we have to tell people, where we can help and for what we ask people that is better to use a Google or ask elsewhere. This makes me think to do some changes to a forum (at once) and remove »Common issues« since they are nothing but a generic Debian/Ubuntu problems (which should not be our problem) and merge them with »Peer to peer«.  There we add a sticky where and how to search. Also move all nontechnical stuff from »General chit chat« as well. I hardly catch up on topics and can't moderate forum content. If this is too much for current moderator team, it should expand. 
 
New WEB is under construction and the person who is doing the actual work - from UX and design perspective - is doing this on biased limited input. Old WEB, the way it looks now, is a patch over patch over patch. Affiliate Amazon links are added value content, but since it’s tied to a kernel only, it might not show up completely correctly. This problem is being considered in the new database design. 

Current WEB is not a representation of what I or what we wanted to show. That’s the reason something is going on in this field. A basic logical concept of WEB is already standing, without any content. It's possible to add direct comments and check actual navigations - currently, only me and Tido were added comments and if anyone wants to participate in the process, send me a PM and we will ger credentials. Currently, we have a basic frame, UX is getting better and database/web management is designing from scratch.
 
It's a stereotype which won't just go away. We can only send those who come up with such questions to the place where all those common things, like power supply, SD cards, ...  essentially to the "Getting started"/"welcome to forum" and simply stating that Armbian is a generic Linux distribution and we don’t cover such special cases. KODI might work, but most likely won't and you better look after a special multimedia distributions like Openelec, Librelec, … In any case, users must be aware how to find such information from a very first page. Such questions are considered in a UX redesign over and over again.

Just in time for FOSDEM some more infos on the new Pine64 H6 and RK3399 boards are available now...
 
https://forum.pine64.org/showthread.php?tid=5614

Usually from Linux this can controlled via sysfs like this (needs to be executed as root):
echo 0 > /sys/block/mmcblk0boot0/force_ro  

My opinion (regarding project aims):
- View Armbian as a base, reasonably minimal OS images. Unfortunately this doesn't work well for targeting inexperienced users, or rather when such users are attracted to the project.
- Explaining "minimal" and "reasonable" to people who don't listen is hard. People expect Kodi to work out of the box on any hardware, expect a perfect desktop performance even on OPi Zero 256MB and expect Mali drivers to magically fix all performance issues.
- Trying to add things to the base image is bad for the project if it can't be fully supported, if it can prevent making project-wide advancements. IMO a lot of things added to the image are not really required but they increase the maintenance efforts. For example for me it would be easier to make a build repository fork and clean it up than try to resolve all possible conflicts with the recently added Realtek wireless drivers (in addition to important device-specific patches) when I decide to upgrade devices that I use to mainline kernel v4.15.
- We still fail to explain what Armbian is. I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config. A lot of support requests are related to upstream packages, a lot of problems are related to kernel/userspace compatibility and people want optional stuff to work perfectly (if it's available in the menu it should work, why not?) while we still have base platform issues. 
- Current web pages and the direction they are changing doesn't help explaining what Armbian is and what level of support can be expected for different images and kernels, unless adding random affiliate links to Amazon should somehow help with this in the long run.
 
The problem here is that "interesting" is subjective. @tkaiser is mostly interested in NAS type boards with high performance and recent enough kernel for using btrfs. Adding ECC RAM to such board multiplies the "interestingness" of a board by 10.
Some people are interested in a generic home NAS device and don't care if its max sequential speed is 40MB/s instead of 400MB/s 100MB/s as long as it is much cheaper.
A lot of people are interested in desktop/multimedia use cases, and here ARM devices in general have a lot of problems unless you are running Android on a well supported device.
Some people bought the cheapest device they could find and expect it to do everything - NAS, desktop, multimedia player, IoT/GPIO stuff, etc.

My opinion (regarding project aims):
- View Armbian as a base, reasonably minimal OS images. Unfortunately this doesn't work well for targeting inexperienced users, or rather when such users are attracted to the project.
- Explaining "minimal" and "reasonable" to people who don't listen is hard. People expect Kodi to work out of the box on any hardware, expect a perfect desktop performance even on OPi Zero 256MB and expect Mali drivers to magically fix all performance issues.
- Trying to add things to the base image is bad for the project if it can't be fully supported, if it can prevent making project-wide advancements. IMO a lot of things added to the image are not really required but they increase the maintenance efforts. For example for me it would be easier to make a build repository fork and clean it up than try to resolve all possible conflicts with the recently added Realtek wireless drivers (in addition to important device-specific patches) when I decide to upgrade devices that I use to mainline kernel v4.15.
- We still fail to explain what Armbian is. I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config. A lot of support requests are related to upstream packages, a lot of problems are related to kernel/userspace compatibility and people want optional stuff to work perfectly (if it's available in the menu it should work, why not?) while we still have base platform issues. 
- Current web pages and the direction they are changing doesn't help explaining what Armbian is and what level of support can be expected for different images and kernels, unless adding random affiliate links to Amazon should somehow help with this in the long run.
 
The problem here is that "interesting" is subjective. @tkaiser is mostly interested in NAS type boards with high performance and recent enough kernel for using btrfs. Adding ECC RAM to such board multiplies the "interestingness" of a board by 10.
Some people are interested in a generic home NAS device and don't care if its max sequential speed is 40MB/s instead of 400MB/s 100MB/s as long as it is much cheaper.
A lot of people are interested in desktop/multimedia use cases, and here ARM devices in general have a lot of problems unless you are running Android on a well supported device.
Some people bought the cheapest device they could find and expect it to do everything - NAS, desktop, multimedia player, IoT/GPIO stuff, etc.

My opinion (regarding project aims):
- View Armbian as a base, reasonably minimal OS images. Unfortunately this doesn't work well for targeting inexperienced users, or rather when such users are attracted to the project.
- Explaining "minimal" and "reasonable" to people who don't listen is hard. People expect Kodi to work out of the box on any hardware, expect a perfect desktop performance even on OPi Zero 256MB and expect Mali drivers to magically fix all performance issues.
- Trying to add things to the base image is bad for the project if it can't be fully supported, if it can prevent making project-wide advancements. IMO a lot of things added to the image are not really required but they increase the maintenance efforts. For example for me it would be easier to make a build repository fork and clean it up than try to resolve all possible conflicts with the recently added Realtek wireless drivers (in addition to important device-specific patches) when I decide to upgrade devices that I use to mainline kernel v4.15.
- We still fail to explain what Armbian is. I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config. A lot of support requests are related to upstream packages, a lot of problems are related to kernel/userspace compatibility and people want optional stuff to work perfectly (if it's available in the menu it should work, why not?) while we still have base platform issues. 
- Current web pages and the direction they are changing doesn't help explaining what Armbian is and what level of support can be expected for different images and kernels, unless adding random affiliate links to Amazon should somehow help with this in the long run.
 
The problem here is that "interesting" is subjective. @tkaiser is mostly interested in NAS type boards with high performance and recent enough kernel for using btrfs. Adding ECC RAM to such board multiplies the "interestingness" of a board by 10.
Some people are interested in a generic home NAS device and don't care if its max sequential speed is 40MB/s instead of 400MB/s 100MB/s as long as it is much cheaper.
A lot of people are interested in desktop/multimedia use cases, and here ARM devices in general have a lot of problems unless you are running Android on a well supported device.
Some people bought the cheapest device they could find and expect it to do everything - NAS, desktop, multimedia player, IoT/GPIO stuff, etc.

Added: e52300d

The easiest way would be blacklisting 8189fs.

Or, as I suggested before, read /proc/device-tree/compatible (null-separated array) which contains both the board name and SoC name, so even if the library doesn't support a new board it can at least support SoC specific pin map.

23% 'one star rating' at least for me is a very clear 'never ever buy such crap' indicator. 2nd 1 star review names the problem already:
 
As very often with cheap PSUs you can not trust in what's printed on them. 5V/4A would mean 20W if you multiply both numbers. But crappy PSUs either provide 5V (no load) or 4A but not both at the same time (voltage drop under load). And the same phenomenon can be observed with cables between PSU and board if wires are too tiny. Incoming voltage at the board dropping due to cable/contact resistance too high. And this happens only with some load generated (Ohm's law).
 
Can a moderator now please move this whole thread to the subforum where it belongs too? Thanks!

There's a new JMS578 beta firmware available ready for test (don't forget to backup your currently running firmware -- see above). This should fix the issue of cutting power hard to connected disks, for details (and firmware link) see here please: https://forum.odroid.com/viewtopic.php?f=97&t=29069

I'm not sure if I completely understand the issue, but recently I came across this LE PR: https://github.com/LibreELEC/LibreELEC.tv/pull/2382
 
Long story short, kernel from 4.9 onwards has latency issues on USB, which could cause visible artifacts when using DVB dongles. It is not clear what is correct solution, but in this thread some possible workarounds are proposed: https://www.spinics.net/lists/linux-usb/msg163892.html
 
I think that most promising workaround can be found in LE PR mentioned at the beginning.
 
Let me know if this is what you're after.

Keep in mind that if you upgrade the kernel you will loose these changes. You can use something like
apt-mark hold linux-image-next-sunxi apt-mark hold linux-dtb-next-sunxi to prevent kernel upgrade or just redo this procedure after each Armbian kernel update

You need to clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Then checkout tag v4.6.3 (or v4.6.7, doesn't matter)
To minimize download time you can do it like this:
mkdir kernel cd kernel git init . git remote add origin "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git" git fetch --depth 1 origin tags/v4.6.7 git checkout -f FETCH_HEAD  Then edit arch/arm/boot/dts/sun7i-a20-bananapi.dts to include changes from my previous post
After that, if you are doing this on the board, run in the top directory of kernel source tree
cp /boot/config-`uname -r` .config make ARCH=arm dtbs after the process is finished, you should get compiled DT file arch/arm/boot/dts/sun7i-a20-bananapi.dtb

You can ask dtc to scan the tree and produce textual representation of the state.
dtc -I fs /sys/firmware/devicetree/base/ If the output from above command includes the change you intended then it must be something else that prevents it from working.

Looks like it can be easily solved by cutting a cable with 2 female Molex connectors from an old ATX power supply and then using a pretty common Molex male to SATA power cables or adapters.
You may also find a cable with both female Molex and SATA power on it, but AFAIK modern ATX power supplies usually have separate cables for Molex and SATA power, especially since "full" SATA power has additional 3.3V line not present on 4pin Molex connectors.
 
You can call it "wrong" but I did a quick search and I couldn't find a Molex female connector (of this type) for soldering on PCB. Of course you could use any other connector there or solder a piece of cable to the PCB with a Molex female connector on the other end, but I'm not sure if those are better options than the current one.

Maybe you have a card reader issue?
Did you write the image with Etcher? Unless Etcher writes the image without reporting any issues I'm not sure anyone will be able to help you further - you should try a different card reader and different SD cards first and write images only with Etcher.