Jump to content

Changing Default kernel, Testing needed


TonyMac32

Recommended Posts

1 hour ago, Igor said:

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?

The miniarm.dtb in mainline is a simple name change to keep things simple script wise, if you would like to remove that patch and make changes for the scripts I don't have any objections.  Anything for/from the Asus images (like overlays) will expect miniarm.dtb on the 4.4, and the educated user will expect tinker.dtb for mainline.

Link to comment
Share on other sites

@Kwiboo Sorry to bug you, but have you seen the Rockchip linux oops when switching video modes?  It's  a null pointer dereference:

 

[65622.009223] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 3                                                                                                                                                                                                                                             840*2160, close all win
[65622.061744] [drm:hdmi_config_hdr_infoframe] *ERROR* Not support DRM Infoframe
[65669.817468] Unable to handle kernel NULL pointer dereference at virtual addre                                                                                                                                                                                                                                             ss 00000000
[65669.826474] pgd = ecb30000
[65669.829499] [00000000] *pgd=00000000
[65669.833472] Internal error: Oops: 5 [#1] SMP ARM
[65669.838570] Modules linked in: 8723bs ip_tables uas
[65669.843965] CPU: 0 PID: 947 Comm: Xorg Not tainted 4.4.115-rockchip #40
[65669.851271] Hardware name: Rockchip (Device Tree)
[65669.856465] task: eca3e200 task.stack: ecb26000
[65669.861474] PC is at vop_crtc_bandwidth+0x268/0x34c
[65669.866861] LR is at vop_crtc_bandwidth+0x1ac/0x34c

I can't find any reference to it in the Rockchip repo, botfap claimed to have seen it but hasn't been in touch in a while.

Link to comment
Share on other sites

7 hours ago, TonyMac32 said:

Anything for/from the Asus images (like overlays) will expect miniarm.dtb on the 4.4, and the educated user will expect tinker.dtb for mainline.


OK, then leaving miniarm on 4.4 and tinker/upstream default for mainline. I'll adjust patches for mainline later today.

Link to comment
Share on other sites

As I said before, I tested thoroughly 3D and video acceleration, and both work. Only that /dev/mali0 has permissions "600" by default, so you need to do a "chmod 666 /dev/mali0" in order to use 3D accel as a regular user. Permissions of /dev/vpu-service and /dev/hevc-service (video accel) are OK.

 

I tested in both Ubuntu and Debian images. I managed to compile the Glamor-enabled X server for ubuntu, as well as some other driver for armsoc chip, which also has 3D acceleration. Performance is very good in 3D, not so good in video. Full video HW acceleration, though, requires a special gstreamer plugin, which I wasn't able to compile for Ubuntu, but I could test it in Debian. If someone has interest, I could upload the debs and post a little howto.

Link to comment
Share on other sites

For GbE, I have been playing with the delays, but no, so far no setting appears to be more stable than any other, so I'm not certain it is delay-related, and performance degrades quickly as you deviate from the pre-set delays.

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

2 minutes ago, TonyMac32 said:

For GbE, I have been playing with the delays, but no, so far no setting appears to be more stable than any other,


Good enough to remove "Known issues: Ethernet driver needs some fixing" at download page?

Link to comment
Share on other sites

Just now, TonyMac32 said:

For GbE, I have been playing with the delays, but no, so far no setting appears to be more stable than any other, so I'm not certain it is delay-related, and performance degrades quickly as you deviate from the pre-set delays.

Sent from my Pixel using Tapatalk
 

ok, given that it's only happening with the NFS client it may not be the ethernet driver at all. I now noticed multiple times that the network lights on the Tinkerboard continued to blink and RPi-Monitor did still refresh while my SSH sessions had frozen and I couldn't open any new connections.

Weird behaviour and the only thing I know for sure is that heavy NFS load via GbE reproduces the freeze :-(

Link to comment
Share on other sites

@Igor, I believe so, I have not experienced this issue in normal use, and only see strange behavior while repeatedly cramming new settings into the DT via Ayufan's tkaiser-inspired script, which could be a multitude of other things.

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

On 2/8/2018 at 5:01 PM, TonyMac32 said:

@Igor, I believe so, I have not experienced this issue in normal use, and only see strange behavior while repeatedly cramming new settings into the DT via Ayufan's tkaiser-inspired script, which could be a multitude of other things.

Sent from my Pixel using Tapatalk
 

 

Have you tried disabling rx/tx offloading? iirc there was some issue on RK3328 with that as well...

Link to comment
Share on other sites

@Igor feedback so far has been quite positive, let's wait until next week, I am in Mexico on business and so I don't have access to my pc/tinker.  I would like to take another shot at sound and Bluetooth before we release new images.  @zador.blood.stained's Bluetooth scripts/service for the 8723bs should work, but don't, so I am a little in the dark on what the rockchip wireless subsystem might be doing.  

Link to comment
Share on other sites

I think it would be good to include in the released image the files I am attaching. It's some udev rules to set the proper permissions on the video acceleration nodes. There is also another rule that triggers a script every time HDMI is plugged/unplugged, to allow hotplug. Right now, if you unplug the HDMI or the monitor goes to sleep mode, you are not able to bring the display back without a reboot.

 

fixes.7z

Link to comment
Share on other sites

@JMCC thank you, the hotplug was on my to-do list (can't remember if image building included it yet if not, will check when back in the US with my equipment/boards).  The mainline already has the script, the old kernel didn't need it somehow.

 

I will work these into the release, hopefully I get started on that tonight.

Link to comment
Share on other sites

I'll try to post something about X video acceleration in these days, and maybe it can also make it into the image. It would be cool if users had 3D, accelerated video and Chrome webgl working out of the box when they downloaded the new images

 

Link to comment
Share on other sites

On 04/02/2018 at 2:31 AM, 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?

 

I couldn't install the debs since there was no video. When the new images are released I'll have another try and get back to you

Link to comment
Share on other sites

@Igor I'm going to roll back the Tinker S board ID patch until I can get more information (GPIO errors all over the place) and we should be good for a new image.  The bluetooth service still doesn't work, I even checked the ASUS one, so I'm not surewhat's going on there, I'll try their rtk_hciattach quickly tonight to see if it is somehow better. (the one I've included works on the command line with no issues, but won't load properly with systemd)

 

 

Link to comment
Share on other sites

On 2/22/2018 at 4:55 AM, JMCC said:

You probably have already checked Rockchip's own BT service, but just in case

 

Yes, I'm not sure why it doesn't take on Armbian, however Igor made a workaround that does the trick. 

 

I would like to know if anyone else has gotten the display system crash I had been getting, today I mysteriously cannot reproduce it.

Link to comment
Share on other sites

Packages updated at the link shared above.  Rockchip appears to have corrected whatever was triggering the hdmi crash, I was able to turn it on and off by installing older and newer kernel to their latest git update.

 

@Igor That was the only major bug I am aware of if you want to roll out a new Rockchip-default image.

Link to comment
Share on other sites

14 minutes ago, TonyMac32 said:

That was the only major bug I am aware of if you want to roll out a new Rockchip-default image.


Splendid. Right after my breakfast :) 

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