Jump to content

Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party


Igor

Recommended Posts

35 minutes ago, targa said:

Worth trying this on a R40 board (Banana Berry) ?

/T


IIRC there is no DVFS implementation there yet but you are welcome to investigate if it can be added.

Link to comment
Share on other sites

Added report for Banana Pi with Dev image. Everything seems to work fine (did not test sata for now). The kworker CPU problem (use search for more information) is still there but removing the module still works (I never managed to stress the CPU enough to go above 55°C so I think removing the module won't cause any problem)

Link to comment
Share on other sites

4 hours ago, vlad59 said:

The kworker CPU problem for Banana Pi (use search for more information) is still there but removing the module still works 

did search, but didnt find the solution.  (unload a module?) and found :

rmmod sun4i_gpadc_iio
rmmod sun4i_gpadc 

 

please give me a hint, because my Banana Pi has also these kworker threads:
 

 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2591 root      20   0       0      0      0 I  16,5  0,0   0:14.22 kworker/0:1-eve
   17 root      20   0       0      0      0 I   9,9  0,0   0:29.96 kworker/1:0-eve
  116 root       0 -20       0      0      0 I   3,6  0,0   0:02.11 kworker/0:1H-kb
  115 root       0 -20       0      0      0 I   0,3  0,0   0:00.81 kworker/1:1H-kb

ARMBIAN 5.67 user-built Debian GNU/Linux 9 (stretch) 4.19.4-sunxi
Linux bpi-pihole 4.19.4-sunxi #4 SMP Wed Nov 28 13:01:58 +03 2018 armv7l GNU/Linux

 

Link to comment
Share on other sites

10 hours ago, vlad59 said:

In my case removing the module completely fixes the problem.


rmmod sun4i_gpadc

Do you still have the problem without this module ?

 

I didnt got a problem with this module - I only did wonder why there are 1-4 kworker threads working on a idle system
also after rmmod these 2 modules :

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
   17 root      20   0       0      0      0 I   9,9  0,0   0:11.68 kworker/1:0-eve
    5 root      20   0       0      0      0 I   0,0  0,0   0:00.00 kworker/0:0-cgr
    6 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 kworker/0:0H-kb
    7 root      20   0       0      0      0 I   0,0  0,0   0:00.05 kworker/u4:0-fl

 

Link to comment
Share on other sites

@guidol

Ok, for the dev kernel, I only tested it for a couple of minutes so I'm not perfectly sure about it. I'll test it later today when back from work.

With kernel 4.14, I have two other Banana Pi that are running without this module for months 24/7 without any problems and without any weird kworker CPU usage.

 

I noticed that your hostname is pihole, do you have Pihole running ? Or any other process ?

Link to comment
Share on other sites

On 11/28/2018 at 11:45 AM, targa said:

Worth trying this on a R40 board (Banana Berry) ?

The results are the same as for the "Big Brother" of the M2 Berry --> the Banana Pi M2 Ultra:
https://github.com/armbian/testings/blob/master/bananapim2ultra-dev.report:
 

Spoiler

BOOT=yes

VERSION=5.67

KERNEL=4.19.1-sunxi

NETWORK=yes

WIRELESS=yes

HDMI=no

USB=yes

DVFS=no

ARMBIANMONITOR=http://ix.io/1rF5

 

Link to comment
Share on other sites

On 11/28/2018 at 8:55 AM, Igor said:

 

Yes. just location is elsewhere if you look from kernel sources perspective.  IIRC its inside common sunxi-h3-h5 include file which is under arch/arm/boot/dts not arm64 ... which is a bit confusing.

Thank you!:beer:

Link to comment
Share on other sites

10 hours ago, guidol said:

Only as my 2nd Pihole (if the 1st is in reboot state) - no other processes

 

So as promised I did some more thorough test with latest Dev on a Banana pi. There's indeed a difference with what I have with 4.14.X.

 

After removing the module I still see a `kworker/1:0-eve` process with ~ 16% CPU for 1 second every 5~6 seconds. I checked again and this does not happen with 4.14.X

I'm also letting it run idly for a while to check cpufreq-info I think it will still spend a lot of time at 960MHz (again it does not with 4.14).

Link to comment
Share on other sites

1 hour ago, vlad59 said:

I'm also letting it run idly for a while to check cpufreq-info I think it will still spend a lot of time at 960MHz

with GOVERNOR=conservative (and not using ondemand) in /etc/default/cpufrequtils it stays idle at 528Mhz

Spoiler

# WARNING: this file will be replaced on board support package (linux-root-...) upgrade
ENABLE=true
MIN_SPEED=480000
MAX_SPEED=960000
GOVERNOR=conservative
# GOVERNOR=ondemand
 

 

Link to comment
Share on other sites

Nice to have those tested:

Sopine A64
Olimex Lime 2 eMMC

 

Those are still problematic and should be fixed before any update:

 

Orange Pi Zero Plus2 H5

Pinebook

Link to comment
Share on other sites

8 hours ago, Igor said:

Those are still problematic and should be fixed before any update:

 

Orange Pi Zero Plus2 H5

 

Hi, this should now be fixed with https://github.com/armbian/build/commit/e0f27fff66220e56b6419879957af28fa46ff84f.  I tested this on an unmodified Plus2 H5 (i.e., missing MOSFET in the regulator switching circuit).  Without this change the boot would fail as @guidol noted (heartbeat, then stops, and the board hangs); with this change it boots and runs just fine, and the maximum CPU clock rate is properly limited.

Link to comment
Share on other sites

2 hours ago, 5kft said:

 

 unmodified Plus2 H5 (i.e., missing MOSFET).  with this change it boots and runs just fine, and the maximum CPU clock rate is properly limited.

My Plus2 H5 does boot now, but without HDMI (no HDMI-console either). USB-ethernet-dongle works :)

ARMBIAN 5.67 user-built Debian GNU/Linux 9 (stretch) 4.19.4-sunxi64

Linux opi-zero-plus2-h5 4.19.4-sunxi64 #4 SMP Sat Dec 1 19:28:55 +03 2018 aarch64 GNU/Linux

Also did try to create a report ;)

 

Link to comment
Share on other sites

49 minutes ago, guidol said:

My Plus2 H5 does boot now, but without HDMI (no HDMI-console either). 

 

Interesting...both of mine boot and work fine with HDMI - bootloader logo, kernel boot, and HDMI console all work okay (tested using a wireless keyboard, which works as well):

 

20181201_104117.thumb.jpg.ee2ca826ce6f70b618f4ab6601d534bf.jpg

 

Did you try a different monitor and/or HDMI cable?  What does "dmesg | grep -i hdmi" show for you?

Link to comment
Share on other sites

1 hour ago, 5kft said:

Did you try a different monitor and/or HDMI cable?  What does "dmesg | grep -i hdmi" show for you?

root@opi-zero-plus2-h5(192.168.6.26):~# dmesg | grep -i hdmi
[    1.718759] sun8i-dw-hdmi 1ee0000.hdmi: 1ee0000.hdmi supply hvcc not found, using dummy regulator
[    1.718811] sun8i-dw-hdmi 1ee0000.hdmi: Linked as a consumer to regulator.0
[    1.719571] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_phy)
[    1.719927] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI I2C bus driver
[    1.720143] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xffff000008b09a78)

its a 4:3 19" 1280x1024 HDMI-monitor but doesnt see a signal :(

Link to comment
Share on other sites

1 hour ago, guidol said:

root@opi-zero-plus2-h5(192.168.6.26):~# dmesg | grep -i hdmi
[    1.718759] sun8i-dw-hdmi 1ee0000.hdmi: 1ee0000.hdmi supply hvcc not found, using dummy regulator
[    1.718811] sun8i-dw-hdmi 1ee0000.hdmi: Linked as a consumer to regulator.0
[    1.719571] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_phy)
[    1.719927] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI I2C bus driver
[    1.720143] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xffff000008b09a78)

its a 4:3 19" 1280x1024 HDMI-monitor but doesnt see a signal :(

 

This all looks good (mine is identical)...  I tried a different monitor as well and that also works for me (1080p 24" LG).  Does the 4.14 kernel work for you in the same exact H/W configuration?

Link to comment
Share on other sites

12 hours ago, guidol said:

its a 4:3 19" 1280x1024 HDMI-monitor but doesnt see a signal


Mine is the same except it's VGA only and I use a converter. No issues whatsoever. I also tried HDMI capture card and it's fine. http://ix.io/1v3H

Let's try others common features such as: I2C, SPI,  audio, HDMI audio, ... Those are mostly common and can be switched via overlays. 

 

Still nice to have those tested even I suspect they are just fine.

Sopine A64
Olimex Lime 2 eMMC

Link to comment
Share on other sites

3 hours ago, Igor said:


Mine is the same except it's VGA only and I use a converter. No issues whatsoever. I also tried HDMI capture card and it's fine. http://ix.io/1v3H
Let's try others common features such as: I2C, SPI,  audio, HDMI audio, ... Those are mostly common and can be switched via overlays. 


Sopine A64
Olimex Lime 2 eMMC

@Igor  @5kft 
the problem was my HDMI-cable which did work since years - or it is the black plastic case of my Zero Plus2 where the HDMI Connector is 1mm to short fore conencting the Zero Pllus2?
Now I used another HDMI cable and do get a Console-Picture - also with a HDMI to VGA converter (the monitor has both inputs).

I did test HDMI-audio. Configured /etc/asound.conf and the alsamixer, but espeak and aplay wound play a sound.
aplay did work after giving the device as a option ( -D plughw:1,0 )
espeak is working only via .wav and using aplay with the device option - BUT mpg123 doenst has this problem and played straight away :)
 

Spoiler

DOESNT WORK

espeak "Hello" 2>/dev/null
espeak -w /tmp/espeak.wav -s150 "Hello how are you today?"; aplay /tmp/espeak.wav 2>/dev/null
  

DID WORK
espeak -w /tmp/espeak.wav -s150 "Hello how are you today?"; aplay -D plughw:1,0 /tmp/espeak.wav 2>/dev/null

 

mpg123 ./Law_and_Order_x14.mp3
Playing MPEG stream 1 of 1: Law_and_Order_x14.mp3 ...
Title:   Law and Order Speed 1.4
[0:36] Decoding of Law_and_Order_x14.mp3 finished.

 

ASOUND.CONF

pcm.!default {
    type hw
    card 1
    device 0
}

ctl.!default {
    type hw
    card 1
}

 

aplay -l


**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: Codec [H3 Audio Codec], Gerät 0: CDC PCM Codec-0 []
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: allwinnerhdmi [allwinner,hdmi], Gerät 0: 1c22800.i2s-i2s-hifi i2s-hifi-0 []
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

 

I have no I2C and SPI test-devices nor a SoPine A64/Lime 2 eMMC :(

Link to comment
Share on other sites

5 hours ago, Igor said:

Let's try others common features such as: I2C, SPI,  audio, HDMI audio, ... Those are mostly common and can be switched via overlays. 

 

Hi @Igor, I just tested both I2C and SPI on the Plus2 H5 and both appear to work.  Both tests were to devices connected to the pin header.  The SPI test was using a 4MB SPI flash part, and the I2C test was just to detect an SH1106 OLED display connected to TWI0-SDA/SCK (display is configured at I2C address 0x3c):

root@orangepizeroplus2:~/tmp# dd if=/dev/random of=test.dat bs=1024 count=4096 iflag=fullblock
4096+0 records in
4096+0 records out
4194304 bytes (4.2 MB, 4.0 MiB) copied, 8.29973 s, 505 kB/s
root@orangepizeroplus2:~/tmp#
root@orangepizeroplus2:~/tmp# flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000 -w test.dat
flashrom v0.9.9-r1954 on Linux 4.19.4-sunxi64 (aarch64)
flashrom is free software, get the source code at https://flashrom.org

Calibrating delay loop... OK.
Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
root@orangepizeroplus2:~/tmp# flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000 -r test2.dat
flashrom v0.9.9-r1954 on Linux 4.19.4-sunxi64 (aarch64)
flashrom is free software, get the source code at https://flashrom.org

Calibrating delay loop... OK.
Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on linux_spi.
Reading flash... done.
root@orangepizeroplus2:~/tmp# md5sum test*.dat
979776e45a0b9fd7caf154f4f1bbbbf4  test2.dat
979776e45a0b9fd7caf154f4f1bbbbf4  test.dat
root@orangepizeroplus2:~/tmp#
root@orangepizeroplus2:~/tmp# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@orangepizeroplus2:~/tmp#
root@orangepizeroplus2:~/tmp# cat /boot/armbianEnv.txt
verbosity=1
console=both
overlay_prefix=sun50i-h5
overlays=usbhost2 usbhost3 spi-spidev i2c0
param_spidev_spi_bus=1
rootdev=UUID=2b29fd0a-3553-4999-be20-f3175d84e624
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
root@orangepizeroplus2:~/tmp#

Very nice how well it all is working!

 

Link to comment
Share on other sites

2 hours ago, guidol said:

I have no I2C and SPI test-devices nor a SoPine A64/Lime 2 eMMC


You already helped a LOT! :thumbup:

 

Just now, 5kft said:

Very nice how well it all is working!


Indeed! Let's fix this Pinebook's troubles and we might slowly switch 4.19.y to nightly NEXT building ...

Link to comment
Share on other sites

On 11/23/2018 at 9:12 PM, vlad59 said:

@belfastraven

 

It's great you also got it working. I bought 3 pine64 + 3 SDIO Wifi / BT addons and I got a faulty one, fortunately I tested all 3 three and I got another one for free ;).

 

About bluetooth I also saw Anarsoul kernel, In case you didn't saw you may have to tweak the firmware blobs :

 * https://forum.manjaro.org/t/bluetooth-not-working-with-rtl8723bs-bt/51906/10

 * https://github.com/lwfinger/rtl8723bs_bt/issues/28#issuecomment-432806835

 

If nobody beats me to it, I'll probably try to fix bluetooth next week.

 

Si I've tried to make Bluetooth work, but I've failed :(

 

I saw Igor added Arnarsoul's patch : https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/0145-arm64-allwinner-a64-enable-Bluetooth-On-Pine64.patch

 

So I simply update the kernel and rebooted and I thought the uart would magically appear in the boot log but no :

 

root@pine64:~# dmesg | grep -i "serial\|uart\|bt\|blue\|tty"
[    0.000000] Kernel command line: root=UUID=790ebccd-7548-41d1-8134-b625a5df2f4f rootwait rootfstype=ext4 console=ttyS0,115200 console=tty1 panic=10 consoleblank=0 loglevel=1 ubootpart=84ade46c-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=memory swapaccount=1
[    0.000288] console [tty1] enabled
[    0.181520] Serial: AMBA PL011 UART driver
[    1.836148] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    1.861452] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.861468] usb usb1: SerialNumber: 1c1a000.usb
[    1.925443] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.925460] usb usb2: SerialNumber: 1c1a400.usb
[    1.948103] Btrfs loaded, crc32c=crc32c-arm64-ce
[    1.994198] console [ttyS0] disabled
[    2.014733] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 23, base_baud = 1500000) is a U6_16550A
[    2.014790] console [ttyS0] enabled
[    2.035888] 1c28400.serial: ttyS1 at MMIO 0x1c28400 (irq = 24, base_baud = 1500000) is a U6_16550A
[    2.057410] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.057427] usb usb3: SerialNumber: 1c1b000.usb
[    2.121469] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.121486] usb usb4: SerialNumber: 1c1b400.usb
[    2.123135] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.123152] usb usb5: SerialNumber: musb-hdrc.1.auto
[    5.491663] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40
[    5.491666] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40

I can see ttys1, is that the bluetooth UART ?

 

I see there's also a patch to enhance rtl8723 driver to become DT-aware : https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/0142-Bluetooth-hci_h5-Add-support-for-binding-RTL8723BS-w.patch.disabled

But it's currently disabled, I checked git history but did not find a good reason for that.

 

I'll start by enabling this patch and rebuild a kernel but that's starting to become black magic to me ;)

 

I'll be happy to hear advices from other with more knowledge than me ;)

Link to comment
Share on other sites

I got the following on the email - it's best to be attached here. I don't have any of this boards to implement and test.
 

Quote

Someone on the Pine forum had difficulties getting an i2s device running on a Pine64+ board using Armbian.
Eventually he turned to me and I was able to verify that the problem was the device tree configuration (dts).
The i2s pins had been configured correctly, but when we originally did the changes in the dts , we discovered that there was an overlap with the gpio pins for UART2.
Obviously these dts changes did not make it correctly into ayufan's version of the kernel used by Armbian.
Just disable UART2 in the 3 dts files and you will be fine.

As reference I have attached the dts files as we use them in our kernel version 3.10.105 (based on Longsleep's work).

 

pine64.dts

pine64noplus.dts

pine64so.dts

Link to comment
Share on other sites

Hello,  

I try out this new kernel with banana pi m1 and as first post says: " Mesa (OS Mali drivers are enabled by default) / WebGL works on Debian based Chromium, fails on Ubuntu)". I understood this as hardware graphical acceleration shoud work. So, now on chrome youtube video should be nice and smoth?  

Now Chromium works like slide show 😉

My armbian monitor log : http://ix.io/1vJ0

Edited by torbert
Link to comment
Share on other sites

hello all - trying to find out when v5.67 will be final having all these juicy bits from DEV incorporated,

in my case both NanoPi NEO2 ( older version ) and current LTS do work fine so far on this release.

then again I use the boards just for ovpn so nothing to fancy ( in terms of GPU, etc )

Link to comment
Share on other sites

35 minutes ago, dolphs said:

when v5.67 will be final


Good question. If you wait for me - I need to take a deep and long rest before I can get ready to sustain extreme stress related to major upgrades. And I would need several hands which are also not happy to be stressed out. For nothing + more stress in exchange. If someone else wants to take a lead on this I will be more than happy. Even with great help from community it is still several hundreds of hours to go. From the point we thing it's ready. Usually in a bulk. And after. Things will break no matter how good we were at testing. Quick untested upgrade = more stress after.

Link to comment
Share on other sites

Hello,

 

I've built the DEV image/kernel for an Orange Pi Prime.  On HDMI I see U-boot and the Armbian logo come up but I get "No signal" on the display after "Starting Kernel ..." I purchased a USB to TLL converter and observe the same symptom over the serial connection.

 

I've written Armbian_5.67_Orangepiprime_Debian_stretch_dev_4.19.12.img using Etcher to a 32gb Samsung Evo Plus microsd.  The board itself shows a steady green light.

I'm new to the ARM world; so if I could get past this hurdle I'd be happy to maintain the Orange Pi Prime image.

 

Thank you for all your work

Link to comment
Share on other sites

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

Important Information

Terms of Use - Privacy Policy - Guidelines