zador.blood.stained

And in each SoC subforum (Allwinner A10/A20, Allwinner H2/H3, etc.) we could create a pinned locked thread named like "List of boards supported in this subforum" to improve navigation.

- build script: support for Xenial as a build host is 95% ready.
- build script: implemented automatic toolchain selection
step 1: if kernel or u-boot needs specific GCC version, add this requirement in LINUXFAMILY case block in configuration.sh variables KERNEL_NEEDS_GCC and UBOOT_NEEDS_GCC, supported relationships are "<", ">" and "==", GCC version needs to be specified as major.minor.
i.e. 
UBOOT_NEEDS_GCC="< 4.9" step 2: unpack toolchains (i.e. Linaro) in $SRC/toolchains/ For running Linaro 4.8 on x64 build host you need to enable x86 support:
dpkg --add-architecture i386 apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 libtinfo5:i386 zlib1g:i386 step 3: run compilation process and check results. Report discovered bugs here on forum on on GitHub.

@immutability
Try looking at output of
systemd-analyze blame to check if any userspace service takes a long time to start, also you may want to run
systemd-analyze plot > plot.svg and open plot.svg on another machine to see graphical representation of startup time of different services.
 
I would guess that your delay is related either to waiting for network connection or to slow SD card read/write speed.

Symptoms:
Board does not boot Armbian from inserted SD card, but may boot other distributions (based on old/legacy u-boot).
Following or similar output can be grabbed from the serial console:
U-Boot SPL 2017.01-armbian (Feb 02 2017 - 03:04:04) DRAM: 2048 MiB Trying to boot from MMC1MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The key message here is "MMC: no card present"
 
Most likely cause:
Malfunctioning microSD slot card detect switch.
It can be verified either visually (with a magnifying glass) or electronically (with a multimeter) - at least in the slots used on Orange Pi boards and on Pine64 the pin near the switch should be shorted to the ground (i.e. SD slot casing) when card is inserted.
 
Illustration (example) of a working switch:

 
Verification (with a multimeter):
Probe 1 - slot pin near the switch (may be different for different slot types, but at least true for Oranges and Pine64)
Probe 2 - microSD slot casing or other parts connected to GND (not shown on the photo)
No card - circuit is open
Card inserted - circuit is shorted
 
Photos - card is not inseted on the left and is fully inserted on the right:
Orange Pi
 
Pine64 (switch is more visible)
 
Can it be fixed?
Yes if the switch is not broken completely, by carefully adjusting (bending) the stationary contact (left on the pictures and photos, it usually is a part of the SD slot casing) i.e using a needle so it touches the moving contact (mostly hidden inside the slot on the photos) when card is inserted and not touching it when it is not inserted.

Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6

I think you meant "expect the user to read and not just mindlessly tick checkboxes that prevent them from posting their question"?

sudo modprobe tun If this fixes the error for you, you should add
tun to /etc/modules (on a new line)

First I would change and reword the current implementation - use something like "I understand that not providing requested information will reduce the chance to solve my issue" (current one with the possibility of getting banned doesn't correlate with the forum rules), explain why providing armbianmonitor -u info is needed (I checked a few new new threads and they don't have it), deal with old images that try to upload the info to sprunge.us (i.e. by linking an instructions for updating the script without updating the BSP), ideally deal with the possibility that ix.io may stop to provide its free service one day too, etc.
I'll just leave the public download statistics link here. I'm not an expert on hosting prices in EU, but you need to take into account both the storage space and monthly traffic.
Edit: clarification - this is daily stats that don't include torrent traffic.

Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again".
 
For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u".
 
Funny thing is that this thread was created after the addition of the new information collection form, so we may as well make providing armbianmonitor -u output mandatory with 2 exceptions in dedicated subforums - devices without network connection and devices that failed to boot completely.
 
Applying your knowledge and experience while at the same time learning something new is fun, and it can happen when you are talking with a person who at least tries to understand what he is doing and who respects your time by trying to provide requested (and even more than requested) information.
Reading 90% of threads in the "Allwinner H2/H3" section made by people who expect performance and software quality of at least a $200 PC like a J5005 based NUC7 from a $20 board like Orange Pi PC is definitely not fun for me. YMMV.
Unfortunately supporting low end (by price) boards attracts their target audience aka people for whom even the Raspberry Pi is too expensive.

Don't get me wrong, I'm not a fan of the current form implementation, but it's only the first iteration. Since "Technical support" section is mostly used as a bug tracker and we wouldn't be able to support a standalone bug tracker / task management system, adding data collection form to the forum is a step in the right direction.

Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again".
 
For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u".
 
Funny thing is that this thread was created after the addition of the new information collection form, so we may as well make providing armbianmonitor -u output mandatory with 2 exceptions in dedicated subforums - devices without network connection and devices that failed to boot completely.
 
Applying your knowledge and experience while at the same time learning something new is fun, and it can happen when you are talking with a person who at least tries to understand what he is doing and who respects your time by trying to provide requested (and even more than requested) information.
Reading 90% of threads in the "Allwinner H2/H3" section made by people who expect performance and software quality of at least a $200 PC like a J5005 based NUC7 from a $20 board like Orange Pi PC is definitely not fun for me. YMMV.
Unfortunately supporting low end (by price) boards attracts their target audience aka people for whom even the Raspberry Pi is too expensive.

Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again".
 
For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u".
 
Funny thing is that this thread was created after the addition of the new information collection form, so we may as well make providing armbianmonitor -u output mandatory with 2 exceptions in dedicated subforums - devices without network connection and devices that failed to boot completely.
 
Applying your knowledge and experience while at the same time learning something new is fun, and it can happen when you are talking with a person who at least tries to understand what he is doing and who respects your time by trying to provide requested (and even more than requested) information.
Reading 90% of threads in the "Allwinner H2/H3" section made by people who expect performance and software quality of at least a $200 PC like a J5005 based NUC7 from a $20 board like Orange Pi PC is definitely not fun for me. YMMV.
Unfortunately supporting low end (by price) boards attracts their target audience aka people for whom even the Raspberry Pi is too expensive.

Plus adding this plugin
https://invisioncommunity.com/files/file/9042-auto-lock-topics/
to entire Technical support question with locking everything that older than 90days? 

This would make sense in a combination with various restriction for creating a new topics (adding armbianmonitor -u).

Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6

Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6

And also Terms of Use / Community guidelines should be linked somewhere in plain sight. Right now it can be accessed when registering, and even there it is not clearly shown as a link. IMO it should be on the top menu row as it is more important than i.e. Privacy policy that exists mostly for legal reasons.
 
Edit: It's also on the bottom bar, but it will be hidden after you click "Accept", looks like by a specific cookie.
 
Edit 2: Now that I'm looking at those (Registration Terms specifically) - they should be a numbered list instead of a bullet list, and we should probably add a new rule "Try to stay on topic defined by the starting post or developer posts in the thread. Off-topic posts that derail the discussion may be hidden, moved or deleted."

And also Terms of Use / Community guidelines should be linked somewhere in plain sight. Right now it can be accessed when registering, and even there it is not clearly shown as a link. IMO it should be on the top menu row as it is more important than i.e. Privacy policy that exists mostly for legal reasons.
 
Edit: It's also on the bottom bar, but it will be hidden after you click "Accept", looks like by a specific cookie.
 
Edit 2: Now that I'm looking at those (Registration Terms specifically) - they should be a numbered list instead of a bullet list, and we should probably add a new rule "Try to stay on topic defined by the starting post or developer posts in the thread. Off-topic posts that derail the discussion may be hidden, moved or deleted."

At least the vanilla mainline u-boot "fdt apply" requires OF_LIBFDT_OVERLAY (which there is set on the per board basis, but it's easier to "select" or "imply" it from ARCH_ROCKCHIP like here: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/enable-DT-overlays-support.patch

Yes, but is it still manufactured? Is it still sold worldwide? And what will you do if you are an "interested developer" and your board dies? Buy another one (if it would be even possible) or move it to "community supported"?
I'm not saying that we should drop support for this particular board right now (I'm sure that @tkaiser would have a different opinion) but any device will fade out in time, regardless of the history.
 

Things to add IMO, some general forum rules to let moderators make decisions based on written rules instead of personal opinions (yes, I think we already discussed this more than a year ago):
 - primary forum language is English, messages in other languages without translation outside of "General chit chat" section may be hidden or deleted
- don't bump topics too often and don't create duplicate messages and topics to bring attention to your issue
- be respectful to each other, follow the nettiquette
- don't abuse private messaging for tech support
- don't abuse forum for self-promotion and don't spam
- breaking the rules will result in a warning, getting multiple warnings will result in a ban
 
 

Then the project should be scaled back to the point where it is sustainable?
 
If a problem requires too much time to solve then it should be ignored until someone more knowledgeable or more resourceful solves it?
 
Then maybe "we" should not try to satisfy everyone? This includes answering to topics if you don't know the answer or can't solve the problem right now, includes providing nightly images and images for community supported devices (let people build images by themselves and share them without using the project infrastructure (i.e. via MEGA or Google Drive) since disk space and traffic costs money that doesn't come from nothing). Also includes working on and especially providing any images already for H6 which is (IMO) > 6 months away from getting enough green squares in the sunxi status matrix for making images suitable for everyday use. Includes providing "better" wireless drivers if integrating and testing them takes too much time.
 
I think this would help too, I don't want to wash my eyes with a soap after reading some threads.

Then the project should be scaled back to the point where it is sustainable?
 
If a problem requires too much time to solve then it should be ignored until someone more knowledgeable or more resourceful solves it?
 
Then maybe "we" should not try to satisfy everyone? This includes answering to topics if you don't know the answer or can't solve the problem right now, includes providing nightly images and images for community supported devices (let people build images by themselves and share them without using the project infrastructure (i.e. via MEGA or Google Drive) since disk space and traffic costs money that doesn't come from nothing). Also includes working on and especially providing any images already for H6 which is (IMO) > 6 months away from getting enough green squares in the sunxi status matrix for making images suitable for everyday use. Includes providing "better" wireless drivers if integrating and testing them takes too much time.
 
I think this would help too, I don't want to wash my eyes with a soap after reading some threads.

Did you add "emmc_fix=on" to /boot/armbianEnv.txt on the eMMC (you needed to mount it after flashing) or did you try to insert a SD card in the microSD slot on the board? Without this eMMC won't be detected by the kernel.

You can copy it to the same USB stick (as a file) and dd it to the eMMC. Please note that you need to add/set "emmc_fix=on" in /boot/armbianEnv.txt both on your USB stick and on eMMC after you flash the image on it, or you can just insert any SD card into the SD slot.
 
There is no USB OTG port here so UMS (mass storage gadget) or fastboot is not an option here. The only "better" solution could be tftp based to download the image to RAM or USB storage and flash it to eMMC, but it requires setting up a tftp server, or writing the image from USB to eMMC from u-boot.

OFF,OFF,ON,ON,ON as per Solid-Run wiki for SD/eMMC.