Jump to content

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


Recommended Posts

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

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

/T

Expand  


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

Posted

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)

Posted
  On 11/28/2018 at 1:00 PM, vlad59 said:

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

Expand  

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

 

Posted

In my case removing the module completely fixes the problem.

rmmod sun4i_gpadc  

Do you still have the problem without this module ?

Posted
  On 11/28/2018 at 8:33 PM, vlad59 said:

In my case removing the module completely fixes the problem.

rmmod sun4i_gpadc

Do you still have the problem without this module ?

Expand  

 

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

 

Posted

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

Posted
  On 11/29/2018 at 8:30 AM, vlad59 said:

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

Expand  

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

Posted
  On 11/28/2018 at 7: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.

Expand  

Thank you!:beer:

Posted
  On 11/29/2018 at 9:38 AM, guidol said:

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

Expand  

 

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

Posted
  On 11/29/2018 at 8:03 PM, 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

Expand  

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

  Reveal hidden contents

 

Posted

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

Posted
  On 12/1/2018 at 6:51 AM, Igor said:

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

 

Orange Pi Zero Plus2 H5

Expand  

 

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.

Posted
  On 12/1/2018 at 3:10 PM, 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.

Expand  

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

 

Posted
  On 12/1/2018 at 5:58 PM, guidol said:

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

Expand  

 

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?

Posted
  On 12/1/2018 at 6:47 PM, 5kft said:

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

Expand  
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 :(

Posted
  On 12/1/2018 at 8:41 PM, 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 :(

Expand  

 

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?

Posted
  On 12/1/2018 at 8:41 PM, guidol said:

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

Expand  


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

Posted
  On 12/2/2018 at 9:27 AM, 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

Expand  

@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 :)
 

  Reveal hidden contents

 

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

Posted
  On 12/2/2018 at 9:27 AM, 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. 

Expand  

 

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!

 

Posted
  On 12/2/2018 at 12:40 PM, guidol said:

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

Expand  


You already helped a LOT! :thumbup:

 

  On 12/2/2018 at 2:48 PM, 5kft said:

Very nice how well it all is working!

Expand  


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

Posted
  On 11/23/2018 at 8: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.

Expand  

 

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

Posted

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

Expand  

 

pine64.dts

pine64noplus.dts

pine64so.dts

Posted (edited)

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
Posted

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 )

Posted
  On 12/19/2018 at 7:52 PM, dolphs said:

when v5.67 will be final

Expand  


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.

Posted

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

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

Important Information

Terms of Use - Privacy Policy - Guidelines