* Wireguard: bump tag to most recent since it breaks building on 5.4.y
* Move rockchip current to 5.4.y
* Move sunxi current to 5.4.y
* Move meson64 to 5.4.y
* Move odroidxu4 to 5.4.y and enable "current" targets
* Enable missing target
this update of the previous patch (#1663) additionally fixes the following overlays:
sun5i-a13: i2c1..2, nand, pwm, spi2, uart0..3
sun4i-a10: can, i2c1..2, pwm, spdif-out, spi0..2
corrections re #1663:
sun7i-a20: fixed typo in pwm overlay in #1663
arch64-makefile now back in line with original patch
some armbian dts overlays currently do not work since pinctrl names have not been
adapted to renaming in 5.0 and 5.2.
this patch modifies the following overlays:
sun50i-h5: cir, spdif-out
sun8i-h3: cir, spdif-out
sun7i-a20: i2c1..4, mmc2, pwm, spdif-out, spi0..2, spi-add-cs1, uart4..7
sun5i-a13: uart0
sun4i-a10: spdif-out
* Sunvell R69: cpu voltage regulator (re-)added - dram clock reduced.
CPU regulator (re-)added to u-boot and kernel dts - the box will not boot without it.
Dram clock reduced in defconfig to increase stability.
[AR-85]
AR-1 - Adding support category for distributions
AR-4 - Remove Allwinner legacy
AR-5 - Drop Udoo family and move Udoo board into newly created imx6 family
AR-9 - Rename sunxi-next to sunxi-legacy
AR-10 - Rename sunxi-dev to sunxi-current
AR-11 - Adding Radxa Rockpi S support
AR-13 - Rename rockchip64-default to rockchip64-legacy
AR-14 - Add rockchip64-current as mainline source
AR-15 - Drop Rockchip 4.19.y NEXT, current become 5.3.y
AR-16 - Rename RK3399 default to legacy
AR-17 - Rename Odroid XU4 next and default to legacy 4.14.y, add DEV 5.4.y
AR-18 - Add Odroid N2 current mainline
AR-19 - Move Odroid C1 to meson family
AR-20 - Rename mvebu64-default to mvebu64-legacy
AR-21 - Rename mvebu-default to mvebu-legacy
AR-22 - Rename mvebu-next to mvebu-current
AR-23 - Drop meson64 default and next, current becomes former DEV 5.3.y
AR-24 - Drop cubox family and move Cubox/Hummingboard boards under imx6
AR-26 - Adjust motd
AR-27 - Enabling distribution release status
AR-28 - Added new GCC compilers
AR-29 - Implementing Ubuntu Eoan
AR-30 - Add desktop packages per board or family
AR-31 - Remove (Ubuntu/Debian) distribution name from image filename
AR-32 - Move arch configs from configuration.sh to separate arm64 and armhf config files
AR-33 - Revision numbers for beta builds changed to day_in_the_year
AR-34 - Patches support linked patches
AR-35 - Break meson64 family into gxbb and gxl
AR-36 - Add Nanopineo2 Black
AR-38 - Upgrade option from old branches to new one via armbian-config
AR-41 - Show full timezone info
AR-43 - Merge Odroid N2 to meson64
AR-44 - Enable FORCE_BOOTSCRIPT_UPDATE for all builds
* Fix wifi
patch "board-h2plus-nanopi-duo-add-device.patch": increase post-power-on-delay-ms from 50ms to 200ms in wifi_pwrseq node in nanopi-duo dts [dev-branch].
Change in line with other XRADIO device trees (orange pi zero, sunvell).
See also Pull Request #1605.
* Fix xradio patch (dev-branch)
fix KConfig to 5.x - WLAN_VENDOR-flag set to "y" in line with other drivers - otherwise module not loaded.
* correct device name
change nodes "model" and "compatible" to correct device name (from "NanoPi Duo AIR" to "NanoPi Duo") [dev-branch]
Not functionally necessary, but more correct.
* Initial commit for serial consoles rfc
* Board configuration cleanup + small tweaks
* Add serial gadget rename to dev kernel as well
* Cleanup, fixing permissions
* Cleanup board configs
* Initial commit for FA ZeroPi.
* Tested for building.
* Adjust few bugs.
* Move to WIP since its not tested on hardware yet.
Signed-off-by: Igor Pecovnik <igor.pecovnik@gmail.com>
In current kernels (both next and dev) this patch breaks cpufreq and all that depends on it (no dvfs means board overheating). Removing it makes cpufreq and dvfs work again.
I've tested my OPi3 for best voltage numbers (for resolving stability problem after first patch), using StabilityTester and increasing slowly mV by 10 after every crash. Finaly, this values gives no error by running StabilityTester 100 times.
new values are based on stabilityTester results
when using 930mV for 1.6GHz and 980mV for 1.8GHz, xhpl failed randomly.
So 930/980mV are the critical operation voltage.Then increase 10mV and
run 100 times test, result shows that xhpl (not always) failed 1~2 times.
It seems +10mV is still not enough to ensure dc-dc output voltage always
above operation voltage, that means the design of dc-dc converter is not
good enough that results in large ripple.
The testing script is "github.com/mzhboy/StabilityTester"
The following configuration have been tested.
1.08-1.32-1.48-1.64-1.8 GHz
900-910-920-930-990 *ok, 930 failed 2/100
900-900-910-940-990 *ok, 990 failed 1/100
890-900-910-940-990 *ok, 990 failed 1/100
880-880-910-940-1000 *ok, 940 failed 2/100
880-880-910-950-1000 *ok, 1000 failed 1/100
880-880-910-950-1010 *ok
