Jump to content

Changing Default kernel, Testing needed


TonyMac32

Recommended Posts

Hello everyone,

 

    I've begun working to target the Armbian Legacy Tinker Board build to the Rockchip kernel.  There are a list of reasons why it needs done, including some relatively large differences between the current kernel's code base and the Rockchip kernel (making it hard to patch with bugfixes/etc) and inactivity on the part of the vendor of that kernel.  There are also reasons I am preferring to use the Rockchip kernel rather than the ASUS kernel.  First and formost is the need to also support the MiQi.  The miniarm branch of Rockchip and the ASUS kernel have board-specific fixes written in such a way as to not be friendly to other boards.  I've decided it would in fact be easier and more reliable to use the Rockchip kernel and apply the needed fixes in the most appropriate way for our project, as we have different needs than a board-specific vendor kernel.

 

This is a build-it-yourself situation.

 

This is a fork of the Armbian build system using the Rockchip kernel source from https://github.com/rockchip-linux/kernel

 

Things that work and are tested:

 

  • Wireless
  • Bluetooth (via the typical hci attach method)
  • 4k/2k/1080
  • Raspberry Pi touchscreen
  • Compiles with gcc 7.2.1
  • [resolved] Mali is somehow only building for Android, "Mali for linux" throws error during build. This has been clarified, I reached out to Rockchip, this kernel config is simply to allow using older drivers with Linux if so desired.  I don't see immediate reason to desire, so good.
  • [resolved] HDMI Blanking out on change from 4K to other resolutions.  Somehow switch to 4k is ok.  Rockchip adjustments to drivers fixed this for my use case, waiting to hear other feedback
  • VPU/Mali tested/a tutorial by @JMCC

Things not worked out:

  • RGA/VPU/etc are untested/unconfigured/incomplete. Not tested 100%, but working (RGA uncertain)
  • Other things I'm sure.

 

What is needed are people able to test the kernel and determine if it is able to be rolled out.  The kernel presently used is no longer maintained by the vendor, and split from Rockchip too long ago to be able to patch it appropriately.

 

Link to comment
Share on other sites

16 hours ago, TonyMac32 said:

and inactivity on the part of the vendor of that kernel.

it is a bit difficult to understand what you mean, without giving a name to the Kernels e.g. armbian-Kernel, Rockchip-Kernel, ASUS-Kernel?

Maybe you can edit your post in that regard ?

 

16 hours ago, TonyMac32 said:

*** HDMI currently blanks out on resolution change.

Well, how often do you change resolution/display while running it. I attach it to a display and if I move it to another display.. in another room I usually have to shutdown/boot anyway.

Link to comment
Share on other sites

23 minutes ago, Tido said:

it is a bit difficult to understand what you mean, without giving a name to the Kernels e.g. armbian-Kernel, Rockchip-Kernel, ASUS-Kernel?

 

16 hours ago, TonyMac32 said:

The kernel presently used is no longer maintained by the vendor, and split from Rockchip too long ago to be able to patch it appropriately.

https://github.com/armbian/build/blob/2c049615d55a1e7f88fe58e2061c299f5a4ac3b6/config/sources/rockchip.conf#L19

 

 

------

 

26 minutes ago, Tido said:

Well, how often do you change resolution/display while running it. I attach it to a display and if I move it to another display.. in another room I usually have to shutdown/boot anyway.

I mostly agree, but it is a regression from current capability.

Link to comment
Share on other sites

On 28.1.2018 at 7:25 PM, TonyMac32 said:

What is needed are people able to test the kernel and determine if it is able to be rolled out.

Basically, people with a tinker board and like to setup a build environment - as described in the Readme - shall run the compiler, burn it, run it and come back with their findings.

It should even work with Mali ?

Link to comment
Share on other sites

1 minute ago, Tido said:

should even work with Mali ?

It should.  It should also be theoretically possible to use the mpp platofrm for video decoding as well, something I haven't yet tested, along with device tree overlays (see most recent commit).  I haven't made an image because I don't want an explosion on my hands, but a show of hands who can test that wouldn't be able to build it?

Link to comment
Share on other sites

OK, in a last attempt, ***use at your own risk***, and only for evaluation purposes. 

 

debian packages for kernel/bootloader/etc

 

I also noticed the one up now is claiming to be "4.4.112", but there is a failed incremental patch after I merged the current build system to get mine up to date.

 

root@tinkerboard:~# lsmod
Module                  Size  Used by
uas                    20480  0
zram                   28672  4
lz4_decompress         16384  1 zram
lz4_compress           16384  1 zram
8723bs               1253376  0

On resolution change from 4k this kernel still gets DRM crash resulting in oops, going to do some debugging, if anyone else has seen this let me know.

Spoiler

[ 1386.115332] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 3840*2160, close all win
[ 1386.167778] [drm:hdmi_config_hdr_infoframe] *ERROR* Not support DRM Infoframe
[ 1427.353264] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 1427.362268] pgd = ec744000
[ 1427.365259] [00000000] *pgd=00000000
[ 1427.369216] Internal error: Oops: 5 [#1] SMP ARM
[ 1427.374318] Modules linked in: zram lz4_decompress lz4_compress 8723bs
[ 1427.381568] CPU: 3 PID: 759 Comm: Xorg Not tainted 4.4.112-rockchip #34
[ 1427.388878] Hardware name: Rockchip (Device Tree)
[ 1427.394077] task: ec5bf000 task.stack: ecf86000
[ 1427.399094] PC is at vop_crtc_bandwidth+0x268/0x34c
[ 1427.404487] LR is at vop_crtc_bandwidth+0x1ac/0x34c
[ 1427.409880] pc : [<c06a14d8>]    lr : [<c06a141c>]    psr: 60000013
               sp : ecf87cd0  ip : ffffff18  fp : ecf87d2c
[ 1427.422570] r10: 0000000b  r9 : dcf10900  r8 : 00000002
[ 1427.428344] r7 : dcf10440  r6 : ffffff7c  r5 : ffffff7c  r4 : ffffff18
[ 1427.435558] r3 : 00000000  r2 : 00000004  r1 : ffffff7c  r0 : 00000000
[ 1427.442774] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[ 1427.450662] Control: 10c5387d  Table: 2c74406a  DAC: 00000051

 

 

 

 

Link to comment
Share on other sites

Just thought I'd chime in here and say mine has been running fine headless on next/mainline :D -  log http://ix.io/F6V

 

But why anyone would want to use (channeling my inner tkaiser here) crusty 4.4 is beyond me, well.. unless the feature is missing from mainline.  

 

I'm more than happy to try 4.4 though if it would help!

Link to comment
Share on other sites

5 hours ago, TonyMac32 said:

Well, that's exactly the reason.  ;-). The video codec/etc are not yet implemented in mainline.

I've just installed your debs on stretch, ran into a minor hiccup, but otherwise it seems to run fine - log http://ix.io/F88

 

Spoiler

Selecting previously unselected package linux-u-boot-tinkerboard-default.
dpkg: regarding .../linux-u-boot-tinkerboard_5.40_armhf.deb containing linux-u-boot-tinkerboard-default:
 linux-u-boot-tinkerboard-next conflicts with armbian-u-boot
  linux-u-boot-tinkerboard-default provides armbian-u-boot and is to be installed.

dpkg: error processing archive ./linux-u-boot-tinkerboard_5.40_armhf.deb (--install):
 conflicting packages - not installing linux-u-boot-tinkerboard-default
Setting up linux-dtb-rockchip (5.40) ...
Setting up linux-headers-rockchip (5.40) ...
Compiling headers - please wait ...
Setting up linux-image-rockchip (5.40) ...
update-initramfs: Generating /boot/initrd.img-4.4.112-rockchip
update-initramfs: Converting to u-boot format
Errors were encountered while processing:
 ./linux-u-boot-tinkerboard_5.40_armhf.deb

 

fix: remove linux-u-boot-tinkerboard-next & install linux-u-boot-tinkerboard
 

HTH

 

Link to comment
Share on other sites

9 minutes ago, bedalus said:

Download the legacy version and then dpkg the debs?

That would be ideal. 

 

Yes, working features is primary, I've had mine running for 5 days on my desk with the wifi/touchscreen, just looking through files/using IRC/etc.

 

Thanks!

Link to comment
Share on other sites

I've hit a snag. With the default download (Armbian_5.38_Tinkerboard_Ubuntu_xenial_default_4.4.112_desktop) I get nothing on the screen. I also tried a different image for good measure (Armbian_5.37_Tinkerboard_Debian_jessie_default_4.4.104).

 

I think maybe the issue is that it's a 4K TV. I didn't have any issues with my old HD TV, but we got rid of it! Any config changes I can apply after flashing the image so I get an output?

Link to comment
Share on other sites

I'd like to test too but can someone please tell me which option I'm supposed to pick:

-> I select full OS build for flashing (as I don't know how to use the other option)

-> don't change the kernel option

-> select tinkerboard

?? Then I can chose between 

- Default (vendor provided / legacy) which I assume is not the correct option

- Mainline (@kernel.org)

- development version (which I assume to be the correct option)

 

Can someone please confirm that the correct options so that I can test the new kernel?

Link to comment
Share on other sites

Tests with original
Armbian_5.38_Tinkerboard_Ubuntu_xenial_default_4.4.112_desktop.img

root@tinkerboard:~# uname -a
Linux tinkerboard 4.4.112-rockchip #7 SMP Thu Jan 25 01:04:58 CET 2018 armv7l armv7l armv7l GNU/Linux

root@tinkerboard:~# lsmod
Module                  Size  Used by
zram                   28672  4
lz4_decompress         16384  1 zram
lz4_compress           16384  1 zram
8723bs               1232896  0

WiFi = it works
I guess RPi-Monitor is removed from armbian-config

HDMI-to-DVI  1280x1024 (SXGA) = it works
Unplug HDMI and plug in again (same Display) = startx was necessary, but it works

Touch screen 1024x600 = it works full screen :beer:  (touch I did not test)

In the on-screen-display the display writes: 1080p

Spoiler

 


root@tinkerboard:~# xrandr --verbose
Can't open display

[  3796.173] (II) modeset(0): EDID vendor "DWE", prod id 8448
[  3796.173] (II) modeset(0): Using hsync ranges from config file
[  3796.173] (II) modeset(0): Using vrefresh ranges from config file
[  3796.173] (II) modeset(0): Printing DDC gathered Modelines:
[  3796.173] (II) modeset(0): Modeline "1024x600"x0.0   50.25  1024 1068 1156 1344  600 603 609 625 +hsync -vsync (37.4 kHz eP)
[  3796.173] (II) modeset(0): Modeline "720x576"x0.0   27.00  720 732 796 864  576 581 586 625 -hsync -vsync (31.2 kHz e)
[  3796.173] (II) modeset(0): Modeline "1920x1080i"x0.0   74.25  1920 2008 2052 2200  1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e)
[  3796.173] (II) modeset(0): Modeline "1920x1080i"x0.0   74.25  1920 2448 2492 2640  1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e)
[  3796.173] (II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1720 1760 1980  720 725 730 750 +hsync +vsync (37.5 kHz e)
[  3796.173] (II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (56.2 kHz e)
[  3796.173] (II) modeset(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[  3796.173] (II) modeset(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz e)
[  3796.173] (II) modeset(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
[  3796.173] (II) modeset(0): Modeline "640x480"x0.0   31.50  640 664 704 832  480 489 492 520 -hsync -vsync (37.9 kHz e)
[  3796.174] (II) modeset(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[  3796.174] (II) modeset(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[  3796.174] (II) modeset(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[  3796.174] (II) modeset(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[  3796.174] (II) modeset(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
[  3796.174] (II) modeset(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[  3796.174] (II) modeset(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz e)
[  3796.174] (II) modeset(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
[  3796.174] (II) modeset(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz e)
[  3796.174] (II) modeset(0): Modeline "1440x480i"x0.0   27.00  1440 1478 1602 1716  480 488 494 525 interlace -hsync -vsync (15.7 kHz e)
[  3796.174] (II) modeset(0): Modeline "1440x240"x0.0   27.00  1440 1478 1602 1716  240 244 247 262 -hsync -vsync (15.7 kHz e)
[  3796.174] (II) modeset(0): Modeline "720x480"x0.0   27.00  720 736 798 858  480 489 495 525 -hsync -vsync (31.5 kHz e)
[  3796.174] (II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1390 1430 1650  720 725 730 750 +hsync +vsync (45.0 kHz e)
[  3796.174] (II) modeset(0): Modeline "1440x576i"x0.0   27.00  1440 1464 1590 1728  576 580 586 625 interlace -hsync -vsync (15.6 kHz e)
[  3796.174] (II) modeset(0): Modeline "1440x288"x0.0   27.00  1440 1464 1590 1728  288 290 293 312 -hsync -vsync (15.6 kHz e)
[  3796.174] (II) modeset(0): Modeline "1920x1080"x0.0   74.25  1920 2558 2602 2750  1080 1084 1089 1125 +hsync +vsync (27.0 kHz e)

 

 


Test with Tony's .deb
After installation dpkg -i but before reboot: to http://ix.io/FbO

root@tinkerboard:~# uname -a
Linux tinkerboard 4.4.112-rockchip #34 SMP Tue Jan 30 22:34:04 EST 2018 armv7l armv7l armv7l GNU/Linux

root@tinkerboard:~# lsmod
Module                  Size  Used by
zram                   28672  4
lz4_decompress         16384  1 zram
lz4_compress           16384  1 zram
8723bs               1253376  0

no armbian-config...  WiFi so I nmtui = it still works

 

xrandr still doesn't work for both displays.
HDMI-to-DVI  1280x1024 (SXGA) = it works but it came with 800*600

touch screen 1024x600 = it works full screen

 

Thank you for the *.debs was pretty easy.

 

Question, does tinker board use zram like @tkaiser and @zador.blood.stained had the discussion here: https://forum.armbian.com/topic/5565-zram-vs-swap/?do=findComment&comment=42739  ?

 

 

 

Edited by Tido
added zram question
Link to comment
Share on other sites

18 hours ago, bedalus said:

I think maybe the issue is that it's a 4K TV. I didn't have any issues with my old HD TV, but we got rid of it! Any config changes I can apply after flashing the image so I get an output?

 

Sorry I missed this, that shouldn't be the issue, I've started it on both HD and 4K without issue.  The display issue I've had involves changing from 4k to another resolution and the DRM system crashing.

 

Did you install all of the debs, and remove the old kernel packages?

 

4 hours ago, Tido said:

Question, does tinker board use zram

It was rolled out at the same time as the others, and shows up in your "lsmod" output as a loaded module.  That's about all I know.

 

4 hours ago, Tido said:

Touch screen 1024x600 = it works full screen :beer:  (touch I did not test)

who's display is that?  I only have the RPi one at 800x480.

 

15 hours ago, stefan.steffens said:

I'd like to test too but can someone please tell me which option I'm supposed to pick:

Stefan, I just wanted to make sure you had cloned my fork of the Armbian build system, and then check to make sure I answered your question well enough.

Link to comment
Share on other sites

5 hours ago, TonyMac32 said:

who's display is that?  I only have the RPi one at 800x480.

7 inch 1024*600 Display Capacitive Touch Screen

 One day it shall become the control display to my music-player in the living room.

I expected to use it with RPi in the worst case, because it shall work with it 'out of the box' after some configurations.. however it didn't fill the whole display, but touch just works.

 

The controller board can also be used for other displays, but cautions or customization is recommended:

Spoiler

PCB800099 – RTD2660/RTD2662 based LCD Controller Review

 

“PCB800099”, also known as VS-TY2662-V1 is an LCD controller PCB which has entered the market relatively recently. As per usual I have no idea who designed either the board or who wrote its software, but I do know it is based on the Realtek RTD2662 controller, although some may be labelled RTD2660 (which in theory means no HDMI), but if your HDMI input works, it’s an RTD2662. This is just sloppy chip labelling. The RTD266x family represents Realtek’s “TV” lineup, and using this, you notice it.

http://tech.mattmillman.com/lcd/pcb800099/ you can hack EDID if it doesn‘t fit.

 

VS-TY2662L-V1 is a LCD control board, it supports between 7 and 22 inch LCD panel with single /dual LVDS interface.

Powering DC 5V or 12V TWO-IN-ONE adapter (12V recommended)

Inverter Board CONNECTOR / Back-light ON/OFF control / Pin 3

 

Getting too hot and fails

They often will fail after several hours of use and I figured out why: people are connecting their LCD backlights to the 3.3V logic supply and this is pulling far more current through the 3.3V domain than its built for. The inductor coil on the switching power supply reaches over 140°C (290ºF) after about 45 minutes when using my 7“ 1280×800 (WXGA), IPS (HSD070PWW1) no touch and then this causes downstream components to be damaged.

 

I found that seems to work (although haven’t tested it as much) is to replace the inductor coil (82uH) with one which can handle over 2A. I replaced it with AIUR-06-820K off digikey and this doesn’t get anywhere near as hot.

 

Link to comment
Share on other sites

7 hours ago, TonyMac32 said:

 

Sorry I missed this, that shouldn't be the issue, I've started it on both HD and 4K without issue.  The display issue I've had involves changing from 4k to another resolution and the DRM system crashing.

 

Did you install all of the debs, and remove the old kernel packages?

 

It was rolled out at the same time as the others, and shows up in your "lsmod" output as a loaded module.  That's about all I know.

 

who's display is that?  I only have the RPi one at 800x480.

 

Stefan, I just wanted to make sure you had cloned my fork of the Armbian build system, and then check to make sure I answered your question well enough.

Hi Tony, I downloaded from

git clone https://github.com/Tonymac32/build.git

cd build

./compile.sh

successfully generated 'Welcome to ARMBIAN 5.40 user-built Ubuntu 16.04.3 LTS 4.4.112-rockchip' which I hope is the correct one but after successful boot ran into the first problem of not being able to mount a CIFS (NFS mounts if you remember always crashed the system under load) and I'm getting the error message 'mount error: cifs filesystem not supported by the system' even though I loaded the CIFS-Utils. Is CIFS not included in the kernel?

Link to comment
Share on other sites

+1 for the decision to switch to the Rockchip kernel. It is under very active development (several commits a week), and incorporating all that work into Armbian would be a great asset.

 

However, they are also developing different kind of stuff related to video HW acceleration (GLES libraries, X server, gstreamer, mplayer, kodi, etc.), but they only support Debian Stretch in their releases. I suggest to switch to Stretch for the default image, so we can also take advantage of that too.

Link to comment
Share on other sites

1 hour ago, JMCC said:

I suggest to switch to Stretch for the default image, so we can also take advantage of that too.

 

Stretch has demonstrated it's own set of issues, but it is available if you wish to build it yourself.  My last test was certainly more promising than in the past, a few months ago it would lock up for approximately 20 seconds while loading apps like web browsers or LibreOffice.  Now it is still glitchy but does not hang.

 

4 hours ago, stefan.steffens said:

I found it under File systems > Network File Systems and selected the respective options

 

Strange that is was unselected, I'll update that, or you can put in a pull request. updated in build system

Link to comment
Share on other sites

19 hours ago, TonyMac32 said:

 

Stretch has demonstrated it's own set of issues, but it is available if you wish to build it yourself.  My last test was certainly more promising than in the past, a few months ago it would lock up for approximately 20 seconds while loading apps like web browsers or LibreOffice.  Now it is still glitchy but does not hang.

 

 

Strange that is was unselected, I'll update that, or you can put in a pull request.

 

Some great news to share while testing continues: with the old kernel I easily could freeze the tinkerboard so that I couldn't connect anymore when putting high load on NFS mounted shares (100 Mbps and 1 Gbps).
With this new kernel the NFS mount ist stable!! I've got two compiles running in parallel via SSH sessions via 100 Mbps for > 1h with CPU load > 3 @ 1800 Mhz with 70 C.
That's impressive so I'm no longer worrying about CiFS

Unfortunately using 1 Gbps it crashed again so still some work to be done :-(

 

Link to comment
Share on other sites

16 hours ago, stefan.steffens said:

Unfortunately using 1 Gbps it crashed again so still some work to be done :-(

 

I will need to experiment with something that ayufan rolled out for the Rock64 to tune the timings on GbE, that could cause the network to fail (Rock64 has/had some GbE instability as well)

 

In the meantime, updated the available packages with current state of my fork, Rockchip repo updated to 4.4.112, I've patched to 4.4.115, however a couple chunks did not patch in properly and a couple claimed to already be in place, so not 100%

Link to comment
Share on other sites

5 hours ago, TonyMac32 said:

 

I will need to experiment with something that ayufan rolled out for the Rock64 to tune the timings on GbE, that could cause the network to fail (Rock64 has/had some GbE instability as well)

 

In the meantime, updated the available packages with current state of my fork, Rockchip repo updated to 4.4.112, I've patched to 4.4.115, however a couple chunks did not patch in properly and a couple claimed to already be in place, so not 100%

 

That would be great. The current kernel doesn't support SMB2 and later. I'll put in a pull request to get this changed as SMB1 is outdated

Edited by stefan.steffens
Link to comment
Share on other sites

13 hours ago, TonyMac32 said:

to tune the timings on GbE

some weeks ago I read about a guy who took the code (script) from TK and tweaked it even further to check different settings for Ethernet automagically hmmm.. I can't remember the name.

Does someone else know it ?

Link to comment
Share on other sites

Shell we also unify DTB across kernels? rk3288-tinker.dtb is now in mainline and we are adding rk3288-miniarm.dtb there ... backward compatibility can be solved within bootscript.

 

What do you think?

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