willmore

Now it's also included in Armbian sources so following builds will have this fix already. 

No, most likely some dtc or environment commands changes that were made recently. Now that we have a test case I will try to bisect the sources.

Getting back to development related news - basic Rock64 support was added to the mainline tree starting with 4.14-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts?h=v4.14-rc1&id=955bebde057e71b6f29b97b78c027efdd596e62d

Thank you.
 
I have figure it out from an topic about pine64.  I modified and recompiled the boot.cmd. Now everything is Okay.
 
 

Bingo ! You got a good idea !
Without the mSATA inserted, there is no more issue for using the USB receptable for any devices.
This means the JMS stay quiet on the D+/D- line and no more conflicts.
 

the following patch fixes cpufreq for the Orange Pi Zero, Mainline 4.11.12.
@mbee, to give it a try save it as e.g. "orangepi-zero-add-cpufreqscaling.patch" and place it in build/userpatches.
Don't forget to freeze the kernel version in armbian-config to avoid loosing this functionality when running apdate/upgrade.
This patch also fixes some temperature issues since the CPU is not fed 1.3V all the time. My OPiZ is right now idling happily at 30 deg (21 deg ambient temp). Armbianmonitor now reports the current cpu-freq.
@igor, please consider to include this patch. 
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts index 69b4a35..506c462 100644 --- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts @@ -50,10 +50,11 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> #include <dt-bindings/pinctrl/sun4i-a10.h> +#include <dt-bindings/thermal/thermal.h> / { model = "Xunlong Orange Pi Zero"; - compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus"; + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h3"; aliases { serial0 = &uart0; @@ -94,6 +95,77 @@ reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; post-power-on-delay-ms = <200>; }; + + vdd_cpux: gpio-regulator { + compatible = "regulator-gpio"; + regulator-name = "vdd-cpux"; + regulator-type = "voltage"; + regulator-boot-on; + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1300000>; + regulator-ramp-delay = <50>; /* 4ms */ + gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; + gpios-states = <0x1>; + states = <1100000 0x0 + 1300000 0x1>; + }; +}; + +&cpu0 { + operating-points = < + 1008000 1300000 + 816000 1100000 + 624000 1100000 + 480000 1100000 + 312000 1100000 + 240000 1100000 + 120000 1100000 + >; + #cooling-cells = <2>; + cooling-min-level = <0>; + cooling-max-level = <6>; + cpu0-supply = <&vdd_cpux>; +}; + +&cpu_thermal { + trips { + cpu_warm: cpu_warm { + temperature = <65000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu_hot: cpu_hot { + temperature = <75000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu_very_hot: cpu_very_hot { + temperature = <90000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu_crit: cpu_crit { + temperature = <105000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + + cooling-maps { + cpu_warm_limit_cpu { + trip = <&cpu_warm>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT 1>; + }; + cpu_hot_limit_cpu { + trip = <&cpu_hot>; + cooling-device = <&cpu0 2 3>; + }; + cpu_very_hot_limit_cpu { + trip = <&cpu_very_hot>; + cooling-device = <&cpu0 5 THERMAL_NO_LIMIT>; + }; + }; }; &ehci0 {  

To (try to) display a boot logo
 
The logo patch contains 2 parts: extra commands in the boot sequence and a configuration patch to compile in BMP support code: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/sunxi-boot-splash.patch
Obviously "unknown command "bmp"" error means that one part of the patch doesn't work.
 
boot.scr is boot.cmd packaged with a special header that contains the image type, checksum and similar things.
U-boot sets some variables during the boot sequence, some of them come from platform specific include files, others come from generic distro_bootmd support. You can check the u-boot environment with "env print", it will contain most of the boot sequence commands and variables, you'll just have to trace how commands are calling other commands while setting some variables in the process.

Basic characteristic from the kernel in development is that things are missing and regressions are possible. Linux kernel and Armbian are community projects, a common work. If all would only wait that things are fixed, they never are or very late: https://docs.armbian.com/Process_Contribute/

Okay, composited:
root@orangepipc2 Doing aes-128-cbc for 3s on 16 size blocks: 19231577 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 12853395 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 5372534 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1669698 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 224642 aes-128-cbc's in 3.00s Doing aes-192-cbc for 3s on 16 size blocks: 17959061 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 64 size blocks: 11051987 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 256 size blocks: 4292528 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 1024 size blocks: 1276599 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 8192 size blocks: 168931 aes-192-cbc's in 3.00s Doing aes-256-cbc for 3s on 16 size blocks: 17198520 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 9922363 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 3673052 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1063205 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 139337 aes-256-cbc's in 3.00s The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 102568.41k 274205.76k 458456.23k 569923.58k 613422.42k aes-192-cbc 95781.66k 235775.72k 366295.72k 435745.79k 461294.25k aes-256-cbc 91725.44k 211677.08k 313433.77k 362907.31k 380482.90k root@odroid64 Doing aes-128-cbc for 3s on 16 size blocks: 9702869 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 2781948 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 727164 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 183877 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 23058 aes-128-cbc's in 3.00s Doing aes-192-cbc for 3s on 16 size blocks: 8720919 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 64 size blocks: 2461310 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 256 size blocks: 639833 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 1024 size blocks: 161576 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 8192 size blocks: 20256 aes-192-cbc's in 3.00s Doing aes-256-cbc for 3s on 16 size blocks: 7892666 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 2170451 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 561814 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 141717 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 17766 aes-256-cbc's in 3.00s type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 51748.63k 59348.22k 62051.33k 62763.35k 62963.71k aes-192-cbc 46511.57k 52507.95k 54599.08k 55151.27k 55312.38k aes-256-cbc 42094.22k 46302.95k 47941.46k 48372.74k 48513.02k  

Hmm... to summarize the 'OpenSSL 1.0.2g  1 Mar 2016' results for the 3 boards/SoC tested above with some more numbers added (on all A53 cores with crypto extensions enabled performance is directly proportional to CPU clockspeeds -- nice):
ODROID N1 / RK3399 A72 @ 2.0GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 377879.56k 864100.25k 1267985.24k 1412154.03k 1489756.16k aes-192-cbc 325844.85k 793977.30k 1063641.34k 1242280.28k 1312189.10k aes-256-cbc 270982.47k 721167.51k 992207.02k 1079193.94k 1122691.75k ODROID N1 / RK3399 A53 @ 1.5GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 103350.94k 326209.49k 683714.13k 979303.08k 1118808.75k aes-192-cbc 98758.18k 291794.65k 565252.01k 759266.99k 843298.13k aes-256-cbc 96390.77k 273654.98k 495746.99k 638750.04k 696857.94k MacchiatoBin / ARMADA 8040 @ 1.3GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 360791.31k 684250.01k 885927.34k 943325.18k 977362.94k aes-192-cbc 133711.13k 382607.98k 685033.56k 786573.31k 854780.59k aes-256-cbc 314631.74k 553833.58k 683859.97k 719003.99k 738915.67k Orange Pi One Plus / H6 @ 1800 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 226657.97k 606014.83k 1013054.98k 1259576.66k 1355773.27k aes-192-cbc 211655.34k 517779.82k 809443.75k 963041.96k 1019251.37k aes-256-cbc 202708.41k 470698.97k 692581.21k 802039.13k 840761.34k NanoPi Fire3 / Nexell S5P6818 @ 1400 MHz (4.14.40 64-bit kernel): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 96454.85k 303549.92k 637307.56k 909027.59k 1041484.46k aes-192-cbc 91930.59k 274220.78k 527673.43k 705704.40k 785708.37k aes-256-cbc 89652.23k 254797.65k 460436.75k 594723.84k 648388.61k ROCK64 / Rockchip RK3328 @ 1296 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 163161.40k 436259.80k 729289.90k 906723.33k 975929.34k aes-192-cbc 152362.85k 375675.22k 582690.99k 693259.95k 733563.56k aes-256-cbc 145928.50k 337163.26k 498586.20k 577371.48k 605145.77k PineBook / Allwinner A64 @ 1152 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 144995.37k 387488.51k 648090.20k 805775.36k 867464.53k aes-192-cbc 135053.95k 332235.56k 516605.95k 609853.78k 650671.45k aes-256-cbc 129690.99k 300415.98k 443108.44k 513158.49k 537903.10k Espressobin / Marvell Armada 3720 @ 1000 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 68509.24k 216097.11k 453277.35k 649243.99k 741862.06k aes-192-cbc 65462.17k 194529.30k 375030.70k 503817.22k 559303.34k aes-256-cbc 63905.67k 181436.03k 328664.06k 423431.51k 462012.42k OPi PC2 / Allwinner H5 @ 816 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 102568.41k 274205.76k 458456.23k 569923.58k 613422.42k aes-192-cbc 95781.66k 235775.72k 366295.72k 435745.79k 461294.25k aes-256-cbc 91725.44k 211677.08k 313433.77k 362907.31k 380482.90k Banana Pi R2 / MediaTek MT7623 @ 1040 MHz and MTK Crypto Engine active type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 519.15k 1784.13k 6315.78k 25199.27k 124499.22k aes-192-cbc 512.39k 1794.01k 6375.59k 25382.23k 118693.89k aes-256-cbc 508.30k 1795.05k 6339.93k 25042.60k 112943.10k MiQi / RK3288 @ 2000 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 87295.72k 94739.03k 98363.39k 99325.95k 99562.84k ODROID-HC1 / Samsung Exynos 5244 @ (A15 core @ 2000 MHz): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 78690.05k 89287.85k 94056.79k 95104.34k 95638.87k aes-192-cbc 69102.10k 77545.47k 81156.61k 81964.71k 82351.45k aes-256-cbc 61715.85k 68172.80k 71120.73k 71710.72k 72040.45k ODROID-C2 / Amlogic S905 @ 1752 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 51748.63k 59348.22k 62051.33k 62763.35k 62963.71k aes-192-cbc 46511.57k 52507.95k 54599.08k 55151.27k 55312.38k aes-256-cbc 42094.22k 46302.95k 47941.46k 48372.74k 48513.02k NanoPi M3 / Nexell S5P6818 @ 1400 MHz (3.4.39 32-bit kernel): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 44264.22k 54627.49k 58849.88k 59756.35k 60257.62k aes-192-cbc 39559.11k 47999.32k 51095.30k 51736.15k 52158.46k aes-256-cbc 35803.41k 42665.24k 44926.47k 45733.21k 45883.39k Clearfog Pro / Marvell Armada 38x @ 1600 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 47352.87k 54746.43k 57855.57k 58686.12k 58938.71k aes-192-cbc 41516.52k 47126.91k 49317.55k 49932.63k 50151.42k aes-256-cbc 36960.26k 41269.63k 43042.65k 43512.15k 43649.71k Raspberry Pi 3 / BCM2837 @ 1200 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 31186.04k 47189.70k 52744.87k 54331.73k 54799.02k aes-192-cbc 30170.93k 40512.11k 44541.35k 45672.11k 45992.62k aes-256-cbc 27073.50k 35401.37k 38504.70k 39369.39k 39616.51k Banana Pi M3 / Allwinner A83T @ 1800 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 36122.38k 43447.94k 45895.34k 46459.56k 46713.51k aes-192-cbc 32000.05k 37428.74k 39234.30k 39661.91k 39718.95k aes-256-cbc 28803.39k 33167.72k 34550.53k 34877.10k 35042.65k Banana Pi R2 / MediaTek MT7623 @ 1040 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 22082.67k 25522.92k 26626.22k 26912.77k 26995.37k aes-192-cbc 19340.79k 21932.39k 22739.54k 22932.82k 23008.60k aes-256-cbc 17379.62k 19425.11k 20058.03k 20223.66k 20267.01k Edit: Added results for Pinebook and ODROID-HC1 ensuring both were running at max cpufreq
 
Edit 2: Added cpufreq settings for each tested device. Please note throttling dependencies and multi-threaded results below
 
Edit 3: Added Banana Pi M3 single thread performance above. Performance with 8 threads sucks since A83T throttles down to 1.2GHz within 10 minutes and overall AES253 score is below 190000k.
 
Edit 4: Added EspressoBin numbers from here. Another nice example for the efficiency of ARMv8 crypto extensions.
 
Edit 5: Added NanoPi M3 numbers from there.
 
Edit 6: Added Clearfog Pro numbers (Cortex-A9 -- unfortunately OpenSSL currently doesn't make use of CESA crypto engine otherwise numbers would be 3 to 4 times higher)
 
Edit 7: Added Banana Pi R2 numbers from here (Cortex-A7, cpufreq scaling broken since ever so SoC only running with 1040 MHz, numbers might slightly improve once MTK manages to fix cpufreq scaling)
 
Edit 8: Added numbers for ARMADA8040 (A72) from CNX comment thread.
 
Edit 9: Added RK3288 (Cortex A17) numbers from here.
 
Edit 10: Added RPI 3 (BCM2837) numbers. Please be aware that these are not Raspbian numbers but made with 64-bit kernel and Debian arm64 userland. When using Raspbian you get lower numbers!
 
Edit 11: Added Allwinner H6 numers from here.
 
Edit 12: Added RK3399 numbers from here.
 
Edit 13: Added new S5P6818 numbers since now with mainline 64-bit kernel ARMv8 crypto extensions are available

It's most likely "benchmarking gone wrong".
-evp here applies only to the next algo on the command line (aes-128-cbc), 2 next ones are not affected by this option. So I would advise to rerun the test 3 times, 1 algo at a time, and edit/post a combined table.
openssl speed -elapsed -evp aes-128-cbc openssl speed -elapsed -evp aes-192-cbc openssl speed -elapsed -evp aes-256-cbc  

@tkaiser, while all of that is correct, there is another use case that you didn't consider.  What about using this for a NAS/router?  One interface towards the internal network and the other to the outside.  Not all of the traffic has to terminate on the Rock64.
 
 

You can't really compare A20 and H3 in the host mode. A20 will use rather limited host emulation (MUSB) mode by the OTG controller. H3, H5 and A64 OTG port can be multiplexed to a "real" EHCI/OHCI host which doesn't have any limitations (as long as the OTG port can provide enough power to your DVB-T tuner).
 
Sorry, I didn't try to be harsh or rude, I just already said on the previous page that I'm planning to upgrade when 4.13 is released and I didn't think that OTG may be of interest to anyone since H5 (compared to A64) has enough USB host controllers for most use cases.

What a wasted opportunity. Even an H5 sitting behind a 3 port switch chip would have been fantastic (as long as the switch was booted in the sane deny all connections mode) as the switch could have taken easy care of switching packets on the same VLAN and brought in the SOC to handle inter VLAN stuff (Netgate's horrifically overpriced sg-1000 is essentially this).
 
(At some point I'm really hoping someone combines an RK3328 with an ax88179 and a decent switch chip so that we can have a genuine dual nic gigabit routing device)

Obviously, I've missed the clearly visible 8198FTV, I was searching for the AP6212A

guess you're right, but its still a good learning experience
Lesson learned; you can almost always do stuff with a single liner
 
Thank you for this, i was not aware of the ftd* command

I wonder how many times the wheel can be reinvented... 
root@orangepiplus2e:~# fdtget /boot/dtb/sun8i-h3-orangepi-one.dtb /cpus/cpu@0 operating-points 1008000 1300000 816000 1100000 624000 1100000 480000 1100000 312000 1100000 240000 1100000 120000 1100000 root@orangepiplus2e:~# fdtput /boot/dtb/sun8i-h3-orangepi-one.dtb /cpus/cpu@0 operating-points 1008000 1300000 816000 1300000 624000 1100000 480000 1100000 312000 1100000 240000 1100000 120000 1100000 root@orangepiplus2e:~# fdtget /boot/dtb/sun8i-h3-orangepi-one.dtb /cpus/cpu@0 operating-points 1008000 1300000 816000 1300000 624000 1100000 480000 1100000 312000 1100000 240000 1100000 120000 1100000 root@orangepiplus2e:~#  

Note to self, don't be stupid.
 
On the plus side, both of my Orange Pi One boards now have working SPI0.  Want to guess why?
 
Let's use my previous post to show how to do it right as that worked perfectly.  One might just make a note to remember to perform all of those actions *on the same board*.
 
I'm going to go enjoy my working SPI and my stupidity.
 
Thanks for all of the help, @zador.blood.stainedand @martinayotte.  Also, sorry for the grief.

This depends on your boot script version and kernel/DT packages build date. I would recommend using both as new as possible (may require using a new image or manually upgrading the boot script). Serial console can be useful to spot any issues, but SPIdev overlays should work out of the box if they are loaded properly.

Since Dallas Semiconductor strongly suggest to use 4K7 Pull-Up for OneWire bus, I wouldn't rely on weak internal Pull-Ups which one some SoC are greater than 30K, especially if there are multiple sensor on the same bus or if those have long wires.

Here it's about board bring up. Which voltage is the SoC being fed with if no software started to control anything? Zero can switch between 1.1V and 1.3V but there's a default state when powering up and control is later turned over to software which then decides based on clockspeed which voltage to chose (remaining at 1.1V with lower clockspeeds and switching to 1.3V when exceeding 816MHz -- mainline -- or 912MHz -- legacy)
 
Edit: to elaborate on that a bit (and to stand corrected if necessary and also to add stuff to @zador.blood.stained's TODO list  ):
 
So the board's VDD_CPUX voltage is 1.3V when the board boots regardless of clockspeed set anywhere (what's happening when a 'reboot' has been issued before?). This should prevent any undervoltage issues at boot. Next step is booting u-boot, here a static cpufreq will be set (either u-boot default, IIRC 1008 MHz with sun8i, or in our case it's 480 MHz -- we chose this value since we prefer minimum consumption over boot duration) Next step is booting the kernel, with H2+/H3 legacy kernel here the userspace governor is set so the board remains at 480 MHz clockspeed while with mainline kernel schedutil governor takes over and results are not really predictable, at least now CPU cores might clock up to the highest limit allowed with sun8i dev kernel -- what's the value? 1296 MHz? -- and since DVFS is now active voltage starts to jump between 1.1V and 1.3V based on cpufreq) As soon as cpufreq-utils daemon is started it looks really weird since now we switch with legacy kernel from userspace to interactive governor while with mainline from schedutil to ondemand (everything ok, interactive is the better choice with legacy and we switched just recently to ondemand due to some strange reports regarding schedutil). From now on maximum cpufreq can be set by the user (h3consumption tool or /etc/defaults/cpufrequtils -- defaults for large H3 boards 1296MHz, for smaller H3 boards 1200 MHz and for NanoPi NEO/Air 912 MHz) DVFS settings switch voltage above 816MHz with mainline (since that's defined in official DT for Orange Pi One which we use for the Zero) and above 912MHz with legacy since after some extensive internal testing we don't give a sh*t about Allwinner's recommended defaults and let a few thousand Armbian H2+/H3 board users do some reliability testing in the field  
For me personally questions 1 and 3 are interesting. What happens at reboot and what's maximum cpufreq with sun8i dev kernel before cpufrequtils daemon is loaded?
 
And then I would propose to switch to userspace governor in sun8i dev kernel config too for obvious reasons (we discussed this back then when developing IoT settings for the smaller H3 boards and my tests revealed that boot times for the large boards aren't affected that much since their boot clockspeed in N° 2 above is 1008MHz and not 480MHz). Also I would prefer to switch voltages with mainline kernel on the primitive H3/H2+ board also above 912MHz and not 816MHz any more to get more test feedback for mainline DVFS implementation. But no need to hurry, opinions first!
 

I pushed the patch so next nightly and packages in beta repository should have the fix.
@willmore you'll have to extract the u-boot binary from the appropriate package (default for the legacy kernel or dev for the mainline kernel) and reflash the u-boot binary to the SD card. If this fixes the issue for you maybe MoeIcenowy should be pinged about this (since she is the maintainer for the OPi Zero u-boot defconfig)
 
u-boot packages: u-boots-opizero.zip
 
Edit: According to the schematic CPU on Zero should be powered with 1.3V by default, so it shouldn't be an undervoltage?
Edit 2: At least my board is powered with 1.3V by default

FDTI/CH341/PL2303 have been added for next mainline nightly build
 

@HAK @willmore: Thank you both, looks good and like the job can be done without having to differentiate between legacy and mainline kernel (sunxi-mmc, usb and '1c30000.eth' seem useable as regex)

http://sprunge.us/cZOb is the first half. If you point me to a specific image you want me to run, I'll DL and burn it and get the data. I've never used any of their images, so I'm unfamiliar with their site.