dolphs
-
Posts
275 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by dolphs
-
-
First attempt (5.5-rc2), thanks to @megi who added rc2 to the 5.5-branch
This build resulted in compile errors at once, which was to be expected.
Just reporting here in case DEV will be switched to 5.5 this month.
The log attached holds "duplicate_label" as "well duplicate_node_names"-errors.
-
check
1/ kernel settings, eg:
net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 87380 16777216 net.ipv4.tcp_fastopen = 3 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_timestamps = 02/ openvpn settings, eg;
sndbuf 393216 rcvbuf 393216 push "sndbuf 393216" push "rcvbuf 393216" comp-lzo no #No need for streaming fast-io #Optimize I/O writes tls-version-min 1.2 remote-cert-tls client cipher AES-128-CBC ncp-disable auth SHA256 auth-nocacheboth ends have h5 (neo2 lts) currently and get upload/download of >100Mbit over VPN tunnel
BTW kernel 5.3.9 shows on this board lower values so you should easily get 100Mbit
openssl speed -evp aes-128-cbc -elapsed :~# openssl speed -evp aes-128-cbc -elapsed You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 12715522 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 10201155 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 5342908 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1919464 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 274635 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 138772 aes-128-cbc's in 3.00s OpenSSL 1.1.1a 20 Nov 2018 built on: Thu Nov 22 18:40:54 2018 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-d3BJKw/openssl-1.1.1a=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 67816.12k 217624.64k 455928.15k 655177.05k 749936.64k 757880.15k -
15 minutes ago, Igor said:
Thank you for report. Development needs time and this problem is far far from critical.
agreed, was just following the Jira stories and noticed AR-86 is not fully solved, just wanted to report back and that is it.
So I do not want to put any rush on this, but at least we know now it is not fully solved yet.
As said once I see either branch or kernel being updated will spin up another test drive. cheers for your efforts as you know it is appreciated!
-
1 hour ago, Igor said:
I got 1.8 Ghz on my Opi3. Perhaps there is a problem with other boards, haven't test them ...
in which I can contribute to test, as I owe the "orangepioneplus" ( pihole and ovpn server ) as well a spare, so excellent for testing purposes
Yet as we unfortunately can see it is not showing 1,8 which I reported also 5 December:
root@orangepioneplus's password: ___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ _ | | | | |_) | | | | | | '_ \ / _ \_| |_ | |_| | __/| | | |_| | | | | __/_ _| \___/|_| |_| \___/|_| |_|\___| |_| Welcome to Armbian buster with Linux 5.4.2-sunxi64 System load: 0.27 0.24 0.10 Up time: 2 min Memory usage: 7 % of 989MB IP: 192.168.10.121 CPU temp: 45°C Usage of /: 4% of 15G root@orangepioneplus:~# cpufreq-info |grep cpufreq cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147)Will give it another shot once @megi has 5.4.3 incorporated in orangepi-5.4 branch,
both default and with the " Allwinner nvmem based SUN50I CPUFreq " driver
-
On 12/5/2019 at 7:57 AM, dolphs said:
Actually it is interesting finding these under " CPU Frequency scaling " kernel config options
<> Generic DT based cpufreq driver
<*> Allwinner nvmem based SUN50I CPUFreq driverThis last option should " add the nvmem based CPUFreq driver for Allwinner dule capable h6 SoC. ", thus also for the orangepioneplus imho
Wonder if this is a driver issue in current kernel and if this has been fixed meanwhile in 5.4.2 ?
The first driver gives result as indicated 27 Nov already, the " sun50i-cpufreq-nvmem " fails on this board so far....
noticed current dev build ( default kernel ) takes still 5.4.2, would like to try 5.4.3 to see if the this generic driver takes clock speedback to 1,8GHz ( currently 1.5 ) on the orangepioneplus.
Not sure if the newer driver ( Alwinner CPUFreq ) is working now, but in 5.4.3 kernel updates has been made to the Generic driver as far I read the ChangeLogs.
imho AR-86 is not closed yet, it works with a workaround unless it has been confirmed the Generic driver is the one to use ( though it should be the SUN50I CPUFreq driver imho? )
-
While 5.4.y is not in ( sunxi64_common.inc ) current yet, at this time of writing I like to explore " KERNELBRANCH="branch:orange-pi-5.5" ".
Except for just updating to this branch, I noticed it is just too early as megous github branch is not prepared yet for 5.5-RC1.
I am curious to see if any of these have been applied already and what new fun stuff needs to be considered in the kernel .config
-
-
Still exploring kernel 5.4,
little bit out of scope as I am tuning the orangepioneplus board to my needs ( .config )
and no need for WiFi or Bluetooth
Thus how to disable following wifi drivers that are added to the kernel ( as well wireguard ),
[ o.k. ] Adding [ WireGuard tag:0.0.20190702 ] [ o.k. ] Checking git sources [ wireguard 0.0.20190702 ] [ .... ] Up to date [ o.k. ] Patching WireGuard [ Applying workaround for headers compilation ] [ o.k. ] Adding [ Wireless drivers for Realtek 8811, 8812, 8814 and 8821 chipsets branch:v5.2.20 ] [ o.k. ] Checking git sources [ rtl8812au v5.2.20 ] [ .... ] Up to date [ o.k. ] Adding [ Wireless drivers for Realtek 8188EU 8188EUS and 8188ETV chipsets branch:v5.3.9 ] [ o.k. ] Checking git sources [ rtl8188eu v5.3.9 ] [ .... ] Up to date [ o.k. ] Adding [ Wireless drivers for Realtek 88x2bu chipsets branch:master ] [ o.k. ] Checking git sources [ rtl88x2bu master ]
Did read it somewhere but I forgot, one to guide me please? At least it is not here unless I am overlooking stuffTiA!
-
On 11/27/2019 at 1:25 PM, dolphs said:
UPDATE1: 1,5GHz currently max? [ driver: cpufreq-dt ]
Actually it is interesting finding these under " CPU Frequency scaling " kernel config options
<M> Generic DT based cpufreq driver
<M> Allwinner nvmem based SUN50I CPUFreq driverThis last option should " add the nvmem based CPUFreq driver for Allwinner dule capable h6 SoC. ", thus also for the orangepioneplus imho
Wonder if this is a driver issue in current kernel and if this has been fixed meanwhile in 5.4.2 ?
The first driver gives result as indicated 27 Nov already, the " sun50i-cpufreq-nvmem " fails on this board so far....
-
-
-
we're talking about the OPi Zero LTS here? Could you try kernel 5.4.x instead of 5.3.x please ?
[ ./compile.sh BOARD=orangepizero BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no ]
-
WIP - similar here and has been issued to Jira AR-86
If you open .config ( update KERNEL ), this part needs to be updated:
*
* CPU frequency scaling drivers
*
Generic DT based cpufreq driver (CPUFREQ_DT) [M/n/y/?] m
Allwinner nvmem based SUN50I CPUFreq driver (ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM) [N/m/y/?] (NEW) y
SCPI based CPUfreq driver (ARM_SCPI_CPUFREQ) [M/n/y/?] m
SCMI based CPUfreq driver (ARM_SCMI_CPUFREQ) [N/m/y/?] n
CPU frequency scaling driver for Freescale QorIQ SoCs (QORIQ_CPUFREQ) [N/m/y/?] nSadly that brings partly joy as 1,5GHz is currently max speed
-
-
-
1 hour ago, Werner said:
May I ask why it has to be an OPi Zero? OPi One has HDMI, better voltage regulation, full H3 instead of H2+, no broken-by-design wifi chip and is even cheaper than the OPi Zero in the 512MB version.
- [x] HDMI -> no need ( ssh and http enough )
Those caught my interest:
- [v] better voltage regulation -> that was my hunch but trying to verify how H2+ is nowadays ( kernel 5.3/ 5.4 )
- [v] full H3 instead of H2+
- [v] no broken by-design WiFi chip -> OPi One does not have WiFi imho
Zero LTS hopefully has no longer that "heat" problem , LTS states: " low running temperature and low power consumption. ", but I dunno.
Though I was not aware of crappy WiFi (xr819?), is mandatory though as I dont have cables in the meter cupboard, unless I'd use a HomePlug
Except for that have older H5 ( first Neo2 series ), but without WiFi and H2+ was the missing piece I did not have stocked ;-),
thus consider this more like a little "funny" project and might swap the board sooner or later, only stuff on there would be armbian ( buster ) with domoticz
thanks!
-
-
On 9/24/2017 at 11:17 PM, prisma said:
I would recommend no one to buy a Zero currently.
How are we doing at this moment, referring to the newer OPi Zero LTS
It states " low running temperature and low power consumption. ", but ... ... ?
Anyway my goal is to run domoticz, which will be connected to my smart meter in the meter cupboard
-
14 hours ago, megi said:
Linux 5.4 now uses a different cpufreq driver for H6. I guess it needs to be enabled in Armbian's Linux defconfig.
ta! , uhm right, I just quickly kicked off another build with " KERNEL_CONFIGURE=yes " and except many new features not configured yet I found these disabled:
"PSCI CPU idle Driver (ARM_PSCI_CPUIDLE) [N/y/?] (NEW)" ,
"Allwinner nvmem based SUN50I CPUFreq driver (ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM) [N/m/y/?] (NEW) ",
Optional and out of this scope, but nice have "exFAT fs support (EXFAT_FS) [N/m/y/?] (NEW) ",
Set the last two to enabled [Y] and will compile it, once back home I can flash and see what happened ...
Thus basically when new default ".config' is ready for commit, let's not forget to include these please ( and many others I missed out at quick glance ) .
thanks
UPDATE1: 1,5GHz currently max? [ driver: cpufreq-dt ]
<snip snip> analyzing CPU 3: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 244 us. hardware limits: 480 MHz - 1.49 GHz available frequency steps: 480 MHz, 720 MHz, 816 MHz, 888 MHz, 1.08 GHz, 1.32 GHz, 1.49 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.49 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:67.14%, 720 MHz:1.34%, 816 MHz:0.01%, 888 MHz:0.05%, 1.08 GHz:0.15%, 1.32 GHz:0.08%, 1.49 GHz:31.23% (84)
UPDATE2:
Checked /etc/default/cpufrequtils which shows ( as expected MAX_SPEED=1810000 ):
ENABLE=true MIN_SPEED=480000 MAX_SPEED=1810000 GOVERNOR=ondemandBut is it required to enable a flag to " /boot/armbianEnv.txt "in order to get 1.81Ghz back?
I do recall, with NEO2 v1.1 board, in past something similar happened and it was needed to add the option " overlays " which is in this version currently missing:
root@orangepioneplus:~# cat /boot/armbianEnv.txt verbosity=1 console=both overlay_prefix=sun50i-h6 rootdev=UUID=d1e21321-c4f1-407b-9903-d825f76d9e25 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:uFiles listed in overlays rgd H6 ( for NEO2 the option is "sun50i-h5-cpu-clock-1.3GHz-1.3v.dtbo" ):
root@orangepioneplus:/boot/dtb/allwinner/overlay# ls -la *h6* -rw-r--r-- 1 root root 4161 Nov 27 16:06 sun50i-h6-fixup.scr -rw-r--r-- 1 root root 374 Nov 27 16:06 sun50i-h6-i2c0.dtbo -rw-r--r-- 1 root root 374 Nov 27 16:06 sun50i-h6-i2c1.dtbo -rw-r--r-- 1 root root 374 Nov 27 16:06 sun50i-h6-i2c2.dtbo -rw-r--r-- 1 root root 268 Nov 27 16:06 sun50i-h6-ruart.dtbo -rw-r--r-- 1 root root 1177 Nov 27 16:06 sun50i-h6-spi-add-cs1.dtbo -rw-r--r-- 1 root root 804 Nov 27 16:06 sun50i-h6-spi-jedec-nor.dtbo -rw-r--r-- 1 root root 645 Nov 27 16:06 sun50i-h6-spi-spidev1.dtbo -rw-r--r-- 1 root root 780 Nov 27 16:06 sun50i-h6-spi-spidev.dtbo -rw-r--r-- 1 root root 502 Nov 27 16:06 sun50i-h6-uart1.dtbo -rw-r--r-- 1 root root 790 Nov 27 16:06 sun50i-h6-uart2.dtbo -rw-r--r-- 1 root root 790 Nov 27 16:06 sun50i-h6-uart3.dtbo -rw-r--r-- 1 root root 773 Nov 27 16:06 sun50i-h6-w1-gpio.dtbo -
understood martinayotte, loiter for a while taking your rest!
Meanwhile booted the dev image built - just sharing some info for the ones that are interested.
One thing that immediately caught my attention it appears CPUFreq is still WIP ?
Most likely this a .config kernel thingie, which simply needs to be enabled or more work to do ?
root@orangepioneplus's password: ___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ _ | | | | |_) | | | | | | '_ \ / _ \_| |_ | |_| | __/| | | |_| | | | | __/_ _| \___/|_| |_| \___/|_| |_|\___| |_| Welcome to Armbian Buster with Linux 5.4.0-rc8-sunxi64 System load: 1.44 0.56 0.22 Up time: 4 min Memory usage: 12 % of 989MB IP: 192.168.10.121 CPU temp: 45°C Usage of /: 11% of 7.1G Last login: Wed Nov 27 02:34:54 2019 from 192.168.10.98 root@orangepioneplus:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 2: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 3: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. -
cheers both - final attempt for today, which actually appers to be third time " lucky " :
git clone --depth 1 https://github.com/armbian/build armbian cd armbinan ./compile.sh BOARD=orangepioneplus BRANCH=dev <snip snip>... ... # same parameters as shown in previous post
[ o.k. ] Checking git sources [ u-boot v2019.10 ] # nice! :-)
[ o.k. ] Checking git sources [ linux-mainline orange-pi-5.4 ] # good stuff! now megi to merge things for 5.4 final, so no more KERNELRELEASE=5.4.0-rc8-sunxi64 :-)
<snip snip>
Well hats off to youse guys, seems following DEV image has been built :
Armbian_19.11.3_Orangepioneplus_buster_dev_5.4.0-rc8_minimal.imgGrepping on logs shows tons of warnings so will exclude these, ERRORS however
compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-a64-spi-spidev.dts:20.11-25.6: Warning (spi_bus_reg): /fragment@1/__overlay__/spidev: SPI bus unit address format error, expected "0"
compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-a64-spi-spidev.dts:34.11-39.6: Warning (spi_bus_reg): /fragment@2/__overlay__/spidev: SPI bus unit address format error, expected "0"
compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-h5-spi-spidev.dts:20.11-25.6: Warning (spi_bus_reg): /fragment@1/__overlay__/spidev: SPI bus unit address format error, expected "0"
compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-h5-spi-spidev.dts:34.11-39.6: Warning (spi_bus_reg): /fragment@2/__overlay__/spidev: SPI bus unit address format error, expected "0"
compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-h6-spi-spidev.dts:20.11-25.6: Warning (spi_bus_reg): /fragment@1/__overlay__/spidev: SPI bus unit address format error, expected "0"
compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-h6-spi-spidev.dts:34.11-39.6: Warning (spi_bus_reg): /fragment@2/__overlay__/spidev: SPI bus unit address format error, expected "0"
output.log:Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] 0080-rtl8723bs-disable-error-message-about-failure-to-all.patch info
patching.log:Processing file /home/dolphs/armbian/patch/kernel/sunxi-dev/0080-rtl8723bs-disable-error-message-about-failure-to-all.patch
So it is really getting there chaps, well done!
Now where is 5.5-rc1 next ;-)
nite nite
-
Hi, ok just lit up my dev environment and tried to build from scratch ( removing armbian directory and check out again )
Current orangepione plus status building with:
./compile.sh BOARD=orangepioneplus BRANCH=dev RELEASE=buster BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no BUILD_MINIMAL=yes<snip snip>
oot-nodtb.bin 0x4a000000 $start $end
scripts/Makefile.lib:308: recipe for target 'arch/arm/dts/sun50i-h6-beelink-gs1.dtb' failed
scripts/Makefile.lib:308: recipe for target 'arch/arm/dts/sun50i-h6-orangepi-lite2.dtb' failed
scripts/Makefile.lib:308: recipe for target 'arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb' failed
scripts/Makefile.lib:308: recipe for target 'arch/arm/dts/sun50i-h6-pine-h64.dtb' failed
dts/Makefile:38: recipe for target 'arch-dtbs' failed
Makefile:1061: recipe for target 'dts/dt.dtb' failed
[ error ] ERROR in function compile_uboot [ compilation.sh:204 ]
[ error ] U-boot compilation failed
[ o.k. ] Process terminated:~/armbian/output/debug$ grep ERROR output.log Displaying message: ERROR in function compile_uboot compilation.sh:204 err :~/armbian/output/debug$ grep failed output.log Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] add-h6-syscon+emac.patch failed wrn Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] add-orangepi3.patch failed wrn Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] fix-u-boot-H6-reset.patch failed wrn Displaying message: U-boot compilation failed err:~/armbian/output/debug$ grep ERROR compilation.log arch/arm/dts/sun50i-h6-beelink-gs1.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name arch/arm/dts/sun50i-h6-beelink-gs1.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name ERROR: Input tree has errors, aborting (use -f to force output) arch/arm/dts/sun50i-h6-orangepi-lite2.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name arch/arm/dts/sun50i-h6-orangepi-lite2.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name ERROR: Input tree has errors, aborting (use -f to force output) arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name ERROR: Input tree has errors, aborting (use -f to force output) arch/arm/dts/sun50i-h6-pine-h64.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name arch/arm/dts/sun50i-h6-pine-h64.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name ERROR: Input tree has errors, aborting (use -f to force output)
-
5 hours ago, martinayotte said:
I've just did the commit, hoping not much broken ...
@megi did you plan to merge the Linus Offical Non-RC soon ?
thanks - built with orangepi-5.4 (rc8) but still get the dts duplicate_node_names errors as back then, suppose 5.4 will not be ready for building till megi merged to official?
[ ./compile.sh BOARD=orangepioneplus BRANCH=current RELEASE=buster BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no BUILD_MINIMAL=yes ]
#updated " sunxi64_common.inc " to " KERNELBRANCH="branch:orange-pi-5.4" "
output.log
<snip snip>
Displaying message: Compiling dev kernel 5.4.0-rc8 info
Displaying message: Compiler version aarch64-linux-gnu-gcc 8.3.0 info
Displaying message: Using kernel config file config/kernel/linux-sunxi64-dev.config info
Displaying message: ERROR in function compile_kernel compilation.sh:382 err
Displaying message: Kernel was not built @host err
grep ERROR compilation.log
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:735.21-747.5: ERROR (duplicate_node_names): /soc/i2c@5002000: Duplicate node name
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:749.21-761.5: ERROR (duplicate_node_names): /soc/i2c@5002400: Duplicate node name
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:763.21-775.5: ERROR (duplicate_node_names): /soc/i2c@5002800: Duplicate node name
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:1205.18-1213.5: ERROR (duplicate_node_names): /soc/ir@7040000: Duplicate node namethanks for efforts, will stay tuned!
-
On 11/23/2019 at 1:37 PM, dolphs said:
good news - However guess that will be coming Monday once 5.4.0 will be born ( assuming 5.4-rc9 won't be released instead )?
and there it is ...
so " dev " will be 5.5 ( once available ) and
" current " will be based on 5.4.x soon ( once ayufan rgd RK3399 and rgd H6 megi got their code tagged ),
Interesting two months coming up.
Switching SUNXI-DEV to 5.4.y
in Advanced users - Development
Posted
So this means basically more efforts to be done before the orangepioneplus board will have 1,8GHz using the " cpufreq-dt " driver.
cheers for clarifying