pfeerick

We already tried that and it didn't work well - people demanded fixes for unsupported build hosts even though they had to read the warning each time, so at least understanding what "no support" means wasn't trivial for them.
 
If you tried to build, for example, the default sun8i branch some time ago it would be a different story.

Hello, for completely disable x819 just remove U56 on bottom of board.

Save your words.  Just give them this link
 
Orange PI FAQ

Let's sum up major concerns/problems and unify/create a plan of actions.
 
We already decided to wait with mainline H3-H5-A64 ... which means old stable/legacy kernels/a10-20-xu4 (what else?) mainline should be rebuilt and what remains goes under nightly? Images can be made one board at the time, they can be made in exactly 4 days or not. Perhaps I should emphasize "approximately" more? Or remove this date since it only creates an extra pressure? Or is it ok?
 
This should be fun. For me, most of the time is even sometimes days are wasted and frustration or stress builds up to insane levels.

We know which kernels are not done and there is nothing we can do in a week(s)/month, so let's focus now only on userspace and kernels which are labeled stable ...  and what shall be removed from /download and dl. ?

Since we don't go out with mainline H3-H5-A64 major testing is not that critical, but things are rolling in that direction. With a delay.
 
I am aware we are not organized perfectly. It's also WIP

@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.

What Igor said. From what I've seen mentioned, it sounds like in this case "newer != better" :-( I have two V1.1 Orange Pi Zeros that I purchased 2-3 months ago via their aliexpress page, and (after testing that both worked!) I have had one running 24x7 since I got it, open air without a case, plugged into ethernet running node-red and some other bits. I turned everything down power-wise and down-clocked it using the h3consumption script, and haven't had any issues with it, and it runs nice and cool. It does have a heatsink on it, but it certainly doesn't *need* it, but it helps keep it cool and let it throttle up for longer when needed. 

That's exactly what I did...  I maintained some servers for fraternities when I was in college, I learned a few relevant tidbits.  The RAID box I have has eSATA as well as USB 3 and presents itself as a single drive rather than as a port replicator.  But yes, I'm sure that's not the best USB 3 to SATA bridge in there, it's on its fifth year, any trouble and I may simply go to a pair of mirrored redundant disks without all the overhead.
 
 
My current setup is designed around the idea of highly disposable clients with permissions, so centralized staorage was key.  However, it is, to the fully functional clients, as you suppose:  they have full copies to reduce traffic on the network itself, synchronized for changes.
 
For the Rock64 I've seen their little hat with the fast ethernet and sound, I'd be more interested in a fast Ethernet to cover an HDHomerun in a dedicated fashion.
 
For Plex, and I can say this as I run it, I hate their transcoding scheme.  I think they should have that portion of their work wholly documented so interested parties can improve hardware support.  As it stands the Plex transcoder is 100% software on all platforms but select PC's (which need this advantage the least)  This is important for the next point:  The XU4 is capable of transcoding in software, at least with my really stupid cooling system (what throttling?), I am not sure the Rock64 will have that ability.  If the transcoder were truly open for development, it would be possible to have transcoders for these lightweight ARM devices.  This is, of course, unimportant if all of your devices support direct streaming of everything you want to watch, or you're not going to stream outside the home.  I've been watching Emby develop, I may need to try it out if I can get ffmpeg working properly on Rock64 and Tinker Board, having a more or less shared vcodec system. (Tinker is more primitive).  When I say "I" it's actually more likely @Myy, who is working to get it working on mainline while I cheer enthusiastically.
 
This board has a barrel jack, so that's a positive.  It is tiny though, so I can't be certain it has a very high current rating, often the miniature ones top out at 1 to 1.5 amps.  I have not done my normal power testing on the Rock64, but I doubt it will disappoint.
 
Type C will not be a solution for a few years yet, because of the saturation of microUSB and the availability of $1 for three adapters to USB Type C.  Sadly the reality will be properly designed boards being powered via a meter long AWG 24 cable at 5.0 Volts through a microUSB to Type C adapter. 
 
I have a wired home network, not for speed but rather for reliability, I have many neighbors, all with wireless, and several who think that Channels 2, 7, etc are valid for use.

8 Minutes before thermal throttling is still pretty impressive and I wouldn't think it unreasonable to need active cooling if you're going to peg all 4 cores for a long time on such a tiny board with a tiny heatsink.
I'm always open for more testing though

legacy
 
For everything inside a case I can't give you an answer, my OPi laying somewhere around. But as bozen mentioned, this boards aren't running stable inside a case and I think he tested it more than once. At the moment I wouldn't recommend this board for high load use cases. Seems that rev. 1.4 is somehow a design failure. I have one running since ~20d stable (without case, last reboot was due to updates not crash, legacy) with node-red on it over ETH without problems. You can try with a heat sink and set max_freq with h3consumption to 912MHz (this should aviod feeding the CPU with 1.3V) but I'm not sure if this is enough to avoid overheating. 

FYI as additional information: due to WIFI problems I changed a outside monitor box from OpiZero-256 (old version) to OpiZero2Plus with H3 processor. After turning down all unnecessary interfaces in the fex file, the H3 CPU idles now at a temperature 1-5 deg C higher than ambient, with minimal power consumption. In the weather-proof closed box (140x80x50 mm) there is a 18B20 sensor close to the OpiZero board, on the H3 I have a small 14x14 mm heat sink.
The initial setup with the 'old' OpiZero-256 survived even full sunshine and a box temperature of ~75 C. The old WIFI worked fine until the system went to sleep and usually never woke up. 

Small steps - with Zador's help I got the armbian build system working with Docker and managed to force in my changes. The new kernel now runs better than my previous attempt which couldn't load any modules for some reason, which prevented wifi from working amongst other things.
 
I also found that the uboot version of mmc.c has the same test for csd.rev which seems like a reasonable explanation for the boot failure from eMMC, so I've removed the test and rebuilt uboot. I installed the resulting .deb onto the armbian running from sd card, rebooted and have now started a fresh run of nand-sata-install. The only problem is that I have no idea where nand-sata-install gets the copy of uboot to write to the eMMC, so I hope it picks up my modified version and not a copy of the original from somwhere!
 
Ah, looks like the installer gets uboot from /usr/lib/linux-u-boot-pinebook-a64_5.32_arm64/ and that's been updated today, so presumably contains my new build:
 
/usr/lib/linux-u-boot-pinebook-a64_5.32_arm64$ ls -l
total 960
-rw-rw-r-- 1 root root 983040 Sep  4 11:46 u-boot-with-dtb.bin
 
Fingers crossed!

The fix for the 64G eMMC module looks promising - the module is now recognized when I boot armbian from sd card using the modified kernel. It's currently formatting the eMMC as the first stage of nand-sata-install...
 
The fix is trivial. In drivers/mmc/core/mmc.c, remove or comment out the conditional block at line 317
card->ext_csd.rev = ext_csd[EXT_CSD_REV];     /**     if (card->ext_csd.rev > 7) {         pr_err("%s: unrecognised EXT_CSD revision %d\n",             mmc_hostname(card->host), card->ext_csd.rev);         err = -EINVAL;         goto out;     }     */ This test has been removed from later releases of the driver and a comment added to indicate that the cards should be backwards compatible so the test is unnecessary.

Thanks a lot for your answers and especially for the suggestion to change the boot.cmd.
 
As proposed, I changed two lines concerning the fdtname in the the boot.cmd:
    "load ${devtype} 0 ${fdt_addr_r} ${prefix}dtb/${fdtfile}"
 
but leave these line concerning the overlay-setting unchanged
     "if load ${devtype} 0 ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-${overlay_file}.dtbo; then"
     "if load ${devtype} 0 ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-fixup.scr; then"
 
and recompile boot.cmd.
 
This works for me, also with the allwinner overlay dtbo-file.

Right ! This is true for all 64bits SoC, I've narrowed that on PineA64 too...
There is not so much "unsigned int" to "unsigned long" conversion required, if I remember : 2 in the gpio_lib.h and 2 in gpio_lib.c.
 

Via USB, no other way. Any size.
 

Repository beta.armbian.com has been populated with the latest full package base. It's a test build of recent build script rework and some more testing and checking would be helpful.
 
What is new?
- kernel sources with our patches and config (please try some onboard kernel compilation testings) Install example:
apt-get install linux-source-4.12.4-sunxi  - stretch packages

Did you use either internal PullUp or external PullUp to 3.3V ?
If not, the wire is acting as an antenna with random states.
 

Fixed. 

Replace friend with customer and you've lived my life. Good to know you figured it out. Take care.

There is no real PMIC on OPiZero, this means the power supply still plugged on the SoC, even after shutdown command.
 

I get what you are saying but I will wait for the post author to respond since the lcd module he has shown in the first video is same as what I have except that it has a ili9341 chipset; the pins are exactly same and then someone has asked about ili9341 and he gave some specific wiring changes so I have mentioned the board and the pins it has so that there is no confusion;

It should be fixed now. I hope.

UPDATE:
 
Found the workaround: suni4-codec & sun4-sndspdif were not be loaded anymore (why? I do not know). The test with modprobe was positive
 
Adding both modules into /etc/modules file and rebooting the system get all function again.
 
Best regards from Bavaria,
 
Martin

It looks to be a bug in the ARICS firmware. I reported it to TL LIm, but good luck & have fun waiting for Allwinner to fix (or even acknowledge) anything.
Obviously comparing the behavior to other releases would be good to see if it depends on u-boot DT (or maybe it's a "feature", not a bug).

Obviously not, it's just that nobody uses a power button since you need a soldering iron for. Simple workaround: don't use the power button, most probably not so simple fix: dive into BSP power management code
 
If the problem also occurs with other 'distros' then it might be worth to compare DT and kernel config. But zero priority of course since you're the only Armbian user around having a power button soldered (or connected to EXP header)