zador.blood.stained

Basically I tested it only on OPi2 and there it works nicely. If HDMI screen is connected, then HDMI is used, otherwise TV out is enabled. The only possible drawback I see is that TV out detection is not implemented and it unconditionaly enables it if HDMI is not connected. This is the same behaviour as in video driver for older chips.
 
Small note, I updated the driver and simplefb node in DT for TV out must have a different name "de0-lcd1-tve0". Reason for that is that TV out has different clocks, which get disabled at shutdown - DE2, TCON1 and TVE0.
 
Now, I will try to make it work on A64.

@zador,
 
I just added support for TV out, PAL and NTSC standard. Do you think that it is interesting enough to include in Armbian? Maybe for OPi0?
 
https://github.com/jernejsk/u-boot/tree/h3_hdmi_tv_v1
 
You have to include "CONFIG_VIDEO_COMPOSITE=y" in defconfig. PAL is selected by default and can be overriden by environment variable.

Your serial port name should be present in /etc/securetty in order to allow root login, but ttyS0 should already be there. Based on other errors in the log that should not normally happen I can assume that either this image is broken in general or you have some issues on your end like a bad SD card.

This depends on your definition of "stability". These boards (most of them) will run perfectly stable on your desk (especially when using mainline kernel), but please keep in mind that these are the cheap development boards and not the industrial-grade PLCs. These are not designed to work in wide temperature range (especially below 0 Â°C), have minimal or close to zero power supply voltage filtering capability, minimal ESD, overvoltage, overcurrent, wrong polarity, strong EMI, dust, dew, moisture, etc. protection, and reliability may be affected by unclean shutdowns, so if you design any kind of hardware project, you have to know what these boards are capable of and treat them accordingly.

This depends on your definition of "stability". These boards (most of them) will run perfectly stable on your desk (especially when using mainline kernel), but please keep in mind that these are the cheap development boards and not the industrial-grade PLCs. These are not designed to work in wide temperature range (especially below 0 Â°C), have minimal or close to zero power supply voltage filtering capability, minimal ESD, overvoltage, overcurrent, wrong polarity, strong EMI, dust, dew, moisture, etc. protection, and reliability may be affected by unclean shutdowns, so if you design any kind of hardware project, you have to know what these boards are capable of and treat them accordingly.

I checked the first 10 pages of this subforum and found 11 threads describing different OPi Zero wireless related issues and questions, not counting this one and locked development related one. I think it's a good indication of what you should expect from this wireless module.
The thread that you posted in was related to the ongoing development and improvements of the driver, and after a dozen messages it turned into off-topic discussions, so it was closed for a good reason.
 
Also please keep in mind that Armbian is a non-commercial project too, not affiliated with Xunlong. We didn't make the board manufacturer use this wireless module, we didn't advertise any wireless related specifications or abilities like perfectly working AP mode, and constant unending spam of same questions and reports can make any developer regret that he decided to support this device.
 
Opi Zero it's still a good device for its price, just imagine that it doesn't have onboard wireless module. Want similar device with wireless? I think NanoPi Air may be a good alternative.

I don't understand you !!!
Who has "positive attitude" or "negative attitude" here, outside of YOU ...
The hardware design choice of Xunlong about eMMC on OPi0 is NOT an Armbian design choice !!! Armbian has NO relationship with Xunlong except to get some sample board to help community !
 
 
(I'm usually a quiet gentle guy, but here, please @igor, I'm getting out, if he fight, please BAN if forever)
What the FUCK ! As Volunteer, I'm should simply say to you :  GET OUT OF OUR FORUM !!! YOU'RE A SICK GUY !!!
 
EDIT : as I said eailer, STOP complain and become YOURSELF a CONTRIBUTOR !

I checked the first 10 pages of this subforum and found 11 threads describing different OPi Zero wireless related issues and questions, not counting this one and locked development related one. I think it's a good indication of what you should expect from this wireless module.
The thread that you posted in was related to the ongoing development and improvements of the driver, and after a dozen messages it turned into off-topic discussions, so it was closed for a good reason.
 
Also please keep in mind that Armbian is a non-commercial project too, not affiliated with Xunlong. We didn't make the board manufacturer use this wireless module, we didn't advertise any wireless related specifications or abilities like perfectly working AP mode, and constant unending spam of same questions and reports can make any developer regret that he decided to support this device.
 
Opi Zero it's still a good device for its price, just imagine that it doesn't have onboard wireless module. Want similar device with wireless? I think NanoPi Air may be a good alternative.

Well, it's not that hard to simply raise the default voltage to the maximum and have DFS instead of DVFS (and possible overheating problems), or implement a CPU voltage driver that would look more like a hack, but people are not that interested in spending their time on implementing hacky solutions, especially after the release of the first H5 based board.

I'm just experimenting with it, I don't know what options are used to build the nightlies so we need to make sure that fbturbo is installed and is working fine. Also I'm not sure how much improvement can it provide (if any) on ARM64 and with framebuffer display driver.

Ok, for all the "Buy cheap, Buy twice" fellows doing the necessary research only after they bought hardware here's a great (and the official) place to discuss the funny mismatch between expectations and reality: http://www.orangepi.org/orangepibbsen/forum.php?mod=forumdisplay&fid=67

First off, this happens on x86. Google "rowhammer" if you think that this kind of situation isn't a problem even for "expensive" computers.
 
 
Xunlong never advertised the Orange Pi Zero as an AP! Please, show me where they said "use the Orange Pi Zero as a WiFi router"
 
Even the cheapest WiFi routers that I know of cost $15 (AR9331/MT7620).
 
This is additional functionality that we've been lucky to get from the WiFi radio, and now people are getting all pissed that it doesn't work as well as a Raspberry Pi.
 
In my country, the Orange Pi Zero costs as much as a hamburger meal from McDonalds. Just try and use your hamburger as an AP...
 
Fack, people. Lower your expectations.

I don't think OTG port is enabled as host in the u-boot by default, so it will work if USB flash is connected to any USB port other than OTG.
 
Well, CDC is not a storage so it shouldn't count. This "only one USB storage" reguirement exists because there is no way to determine how many USB storage devices are connected (it can be implemented in theory, but it's not present by default), so the u-boot will try the USB storage device 0 (order of enumeration may be consistent) and will fail if it doesn't work (you can force u-boot to try several USB devices, but, again, it will require some patching) and since storing environment in SPI is not implemented yet you can't change the default number 0 to anything else without recompiling the u-boot.
 
BTW, the latest boot script will work without any changes and the FS resizing procedure was updated too.

For the 7805 dropout voltage lower than 3V is not recommended and lower than 2V may not work reliably, so the input voltage should be at least 8V.

Well, 7805 is a linear regulator, so it will generate a lot of heat at this voltage difference and current.
Tips? Use a switching (buck) converter.

For the 78xx electrolytic cap should be on input and ceramic cap should be on output (as close to the regulator as possible). For all types of regulators looking at the datasheet is recommended before trying to apply a common sense - some require a ceramic cap on the output while others require electrolytic one for the stability.
In any case 78xx or any kind of linear regulator should not be used here - it will consume more power than the board itself at this voltage difference.

Desktop image releases will be only based on Ubuntu LTS - easier to support a LTS release when you have to provide additional packages for the HW acceleration stuff.
Server releases will be both Debian and Ubuntu, once Debian Stretch is released (probably in several months) Ubuntu Xenial will be more outdated compared to it in terms of package and default compiler versions, it's just currently the latest Ubuntu LTS release is newer than the latest Debian stable release.

If you tested the prebuilt nightly then idle consumption numbers still can change since this one didn't go below 792MHz due to a wrong number in the DT.

I've sent a patch to enable the SY8106A driver in SPL.

Created a small tool that checks the stability of a range of frequencies using HPL. 
 
Simple clone the git and install libmpich-dev and you're good to go.
 
https://github.com/ehoutsma/StabilityTester
 
If you want to increase the load you can alter the HPL.dat and set the Ns to 10960, which is the maximum size you can run on a 1G device before swapping kicks in.
 
Edit: Don't be scared of high temperatures! High temperatures are good!

If I understand you correctly, you didn't try it yet? Because the driver should select native screen resolution, in this case 1080p. If it is not, then it is bug.
 
 
 
H5 doesn't have any HW 2D acceleration, only 3D through mali.
 
 
For this you need DRM driver. Maybe something can be done with H3 experimental one, but let's focus on basics first.

Ok, it boots now.
 
 

Not yet, out of (more or less) supported boards Zero may be a better choice if you don't need onboard wireless (which is total crap) and a display output
While it's possible to build an image for the PC2, it's still in an early WIP state and mostly server oriented
 
Edit: Or if you want something like Orange Pi PC with onboard storage, look at Orange Pi PC Plus

No. Only boards with eMMC, Orange Pi Zero with SPI flash (which is optional but can be soldered if it's missing) and Orange Pi PC2 (which always comes with SPI flash soldered) can boot without SD card and without using FEL mode.
Depending on your project considerations you may have following options:
Using the cheapest possible SD cards only to store the u-boot Buying SPI flash on a breakout board and some wires to connect it like this (no soldering required, but you may want to find a way to attach it to the main board for a finished product) Choosing another H3 board if it's not too late

Well, as I said, you need some kind of permanent storage (one of listed there in theory, out of those one of supported by the HW (which leaves only external SPI flash and SD card). Additional u-boot environment tweaks can be done at compilation time with some patches if you need it.