Jump to content

Switching SUNXI-DEV to 5.4.y

martinayotte

By martinayotte
in Advanced users - Development

 Share

Recommended Posts

dolphs

dolphs

Posted
Posted

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.

 

megi

megi

Posted
Posted
  On 11/27/2019 at 2:47 AM, dolphs said:

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.

 

Expand  

Linux 5.4 now uses a different cpufreq driver for H6. I guess it needs to be enabled in Armbian's Linux defconfig.

dolphs

dolphs

Posted
Posted
  On 11/27/2019 at 10:58 AM, 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.

Expand  

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=ondemand

 

But 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:u

 

Files 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

 

 

dolphs

dolphs

Posted
Posted
  On 11/27/2019 at 10:58 AM, 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.

Expand  

@megi - Hi megi - Would it be possible to bump ( tag ) orange-pi-5.4 to 5.4.1 please instead of 5-4.0RC8? thanks for your time

Igor

Igor

Posted
Posted

Nightly packages update is also coming to beta.armbian.com in few hours from now.

martinayotte

martinayotte

Posted
  • Author
Posted

BTW, issue faced earlier with ramdom MAC on 8189fs has been narrowed : I'm using "old school" /etc/network/interface, but it is the NetworkManager that was assigning a random MAC, although it wasn't supposed to touch "wlan0" at all, so the fix is to disable it using "systemctl disable NetworkManager". My OPiPC+s, OPiLite and OPiPlus2E are back to their normal state ...

 

Igor

Igor

Posted
Posted
  On 12/2/2019 at 4:09 PM, martinayotte said:

but it is the NetworkManager that was assigning a random MAC

Expand  

 

IIRC it shouldn't / we fix this for Network Manager usage which still our default way. Either we break something in the last RFC or we have upstream changes defaulting to randomizing wireless MAC. 

martinayotte

martinayotte

Posted
  • Author
Posted
  On 12/2/2019 at 4:36 PM, Igor said:

it shouldn't

Expand  

But it does ... According to the link you provide, they mentioned this file /etc/NetworkManager/conf.d/00-macrandomize.conf, but it doesn't exist !

Maybe we need to create it and place "wifi.scan-rand-mac-address=no" instead of "yes" ?

 

dolphs

dolphs

Posted
Posted
  On 11/27/2019 at 12:25 PM, dolphs said:

UPDATE1:  1,5GHz currently max? [ driver: cpufreq-dt ]

Expand  

 

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 driver

 

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

dolphs

dolphs

Posted
Posted

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 stuff

TiA!

Werner

Werner

Posted
Posted

This just adds the source code needed to compile the modules. If you remove/disable them from your kernel config they won't be built. Though I do not think this is even necessary as they should be built as modules already and if you do not load them they would not eat up any ressources whatsoever besides a tiny bit of space on your sd card.

If they get forcefully loaded on boot for unknown reason blacklist the appropriate modules.

dolphs

dolphs

Posted
Posted
  On 12/5/2019 at 6: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 driver

 

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

Expand  

 

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? )

Igor

Igor

Posted
Posted
  On 12/15/2019 at 1:18 PM, dolphs said:

is not closed yet

Expand  


I got 1.8 Ghz on my Opi3. Perhaps there is a problem with other boards, haven't test them ...

dolphs

dolphs

Posted
Posted
  On 12/15/2019 at 5:35 PM, Igor said:

I got 1.8 Ghz on my Opi3. Perhaps there is a problem with other boards, haven't test them ...

Expand  

 

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

 

Igor

Igor

Posted
Posted
  On 12/15/2019 at 7:03 PM, dolphs said:

which I reported also 5 December:

Expand  


Thank you for report. Development needs time and this problem is far far from critical.

 

  On 12/15/2019 at 7:03 PM, dolphs said:

has 5.4.3 incorporated in orangepi-5.4 branch

Expand  


We use the same branch. Just lots of patches which could also break something ... some work has to be applied.

dolphs

dolphs

Posted
Posted
  On 12/15/2019 at 7:12 PM, Igor said:

Thank you for report. Development needs time and this problem is far far from critical.

Expand  

 

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!

megi

megi

Posted
Posted
  On 12/15/2019 at 7:03 PM, dolphs said:

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

 

Expand  

I don't think waiting will help. I almost never update non-rc branches after release, I only merge from linux-stable.

Anyway, I can only see you're missing 1.8GHz, because Armbian changes my CPU OPP table to something else, because my OPP table has 1.8GHz operating point.

https://megous.com/git/linux/commit/?h=ths-5.4&id=8bad58044be498d409400dbf9757f2ae25c6ad9d

 

dolphs

dolphs

Posted
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

 

Cheater

Cheater

Posted
Posted

I tried version 5.4(.20) - Ubuntu/Bionic (downloaded from https://www.armbian.com/nanopi-duo-2/ )

Since this topic is about creating 5.4 version for a processor series that I use, I think my posting here is correct. 

I have the Allwinner H3 (SUN8I 1680) processor on a NanoPi Duo2 board.

 

The startup of Bionic hangs at a certain point, always the same point. Here the complete log (in a spoiler block so not everyone has to see this/scroll over it)

 

  Reveal hidden contents

 

I tried reflashing a couple of times to the SD card.

I tried a different image flasher tool (tried win32diskimager and etcher)

I tried 2 SD cards, both with same result.

 

Now the interesting bit: the Buster (Debian) variant of 5.4.20 DOES work corrrectly and boots up perfectly.

 

Is this interesting feedback for you?

Is there a solution for my Bionic/Ubuntu version? 

Can I give you more information you possibly need?

Werner

Werner

Posted
Posted
  On 2/20/2020 at 8:16 PM, Cheater said:

 the Buster (Debian) variant of 5.4.20 DOES work

 

 

Expand  

Therefore your post has nothing to do with the kernel building :lol:

I'll suggest someone to split this topic up.

This may not even be related to Armbian since Armbians job is to put together a working kernel for various sbcs and build a operating system with minimal customization (Buster and Bionic to say) on top. The kernel boots fine as seen above so this might be OS related and therefore an issue that Ubuntu have to fix themselves.

Cheater

Cheater

Posted
Posted

After MANY trials of restarting, Debian has finally started correctly.  I have not changed anything, but I THINK it was something with a too hot (temperature) processor.

My support question can be ignored, because there is no problem anymore.

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept