• Content Count

  • Joined

  • Last visited

About Myy

  • Rank
    Embedded member

Contact Methods

  • Website URL

Profile Information

  • Gender
    Not Telling
  • Interests

Recent Profile Visitors

2697 profile views
  1. Sooo, I tried to fix the issue, using a 5.8-rc3 kernel... While the frequencies are back, there's some heavy glitches with Panfrost drivers and I don't know if that's due to kernel changes (entirely plausible) or if that's due to the patch. I'll try test a 5.8-rc3 kernel without this patch, just to check who's the culprit. Meanwhile, here's a patch that brings 500Mhz frequencies back for Mali GPU on RK3288 boards : From 73258d32daf3a661281bb5c77c5e2e06c7ff714e Mon Sep 17 00:00:00 2001 From: "Miouyouyou (Myy)" <> Date: Fri, 3 Jul 2020 02:02:18 +0200 Subject: [PATCH] arm: dtsi: rk3288: add GPU 500 Mhz OPP again Undoing the very bizarre mainline kernel patch, 75481833c6dbab4c29d15452f6b4337c16f5407b which main purpose is to sync some 3.14 kernels hacks to mainline kernels, for reasons that only matter for a few Chromebooks, and shove it down the throat of every RK3288 user. If you need to avoid the GPU going to 500 Mhz on Chromebooks, remove the OPP entry inside the DTS that actually matters to RK3288 Chromebooks. Meanwhile, the 600 Mhz operating point can prove to be unstable on some RK3288 boards, while 500 Mhz works fine. Signed-off-by: Miouyouyou (Myy) <> --- arch/arm/boot/dts/rk3288.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi index a66412547..ef7457f79 100644 --- a/arch/arm/boot/dts/rk3288.dtsi +++ b/arch/arm/boot/dts/rk3288.dtsi @@ -1312,6 +1312,10 @@ opp-400000000 { opp-hz = /bits/ 64 <400000000>; opp-microvolt = <1100000>; }; + opp-500000000 { + opp-hz = /bits/ 64 <500000000>; + opp-microvolt = <1200000>; + }; opp-600000000 { opp-hz = /bits/ 64 <600000000>; opp-microvolt = <1250000>; -- 2.27.0
  2. Somebody had some issues with a few screens on X11, when testing the latest DRM patches to improve HDMI handling of various screens, and were able to force X11 to use manually input EDID values. If you could retrieve the EDID values used by the TinkerOS and feed them to X11, you might be able to get this resolution working... Though, that's a weird bug. I might have to reintroduce a way to get the list of EDID values obtained and evaluated by the DRM driver, for each plugged screen, in the dmesg logs.
  3. I was wondering the last day I touched the GPU frequencies. I never touched that. CPU frequencies, yes. GPU frequencies, no. All my patches are available on RockMyy . The removal of the 500 MHZ GPU frequencies were done on the mainline kernel here : That's a pretty heavy-handed patch, I agree (Some Chromebooks are broken so let's remove the functionality for everyone). I don't know if it's possible to patch frequencies within a sub-DTS file. Something like (untested) : @gpu_opp_table { opp-500000000 { opp-hz = /bits/ 64 <500000000>; opp-microvolt = <1200000>; }; }; I'll give it a try when possible.
  4. Could you provide your dmesg after trying to setup the right resolution ? I guess that others resolutions fail too, or are not available ?
  5. According to chrony, the system clock was wrong when it started up, and it was 97380 seconds late, which is roughly 27H, which fits with the "1 day 3 hours ago" diagnostic. Now, I don't know how the clock is updated and it seems that systemd is displaying the "running" time based on the day time, instead of a monotonic clock. There might be a way to force it to display the "running" time using a monotonic clock, though.
  6. Interesting approach. I'd just like to mention that factorizing is required, if the patches apply to the same file AND the same blocks (functions, DTS, ...). If you create THAT big patch that add 50 entries to a single DTS file, and the mainline DTS file gets updated with the addition of, like, 3 entries out of the 50, then you won't be able to apply your big patch AND you'll need to rework it. Since you won't be able to apply it again, you can either pray that 3-way merging works, or you'll have to do a copy-paste of every missing entry from the patch, back to the DTS file AND regenerate a patch from there. Now, if you got 5 patches affecting "that same function" or "that same DTS block", then yes, merging is required. Anyway, this tool should greatly help in reducing the number of patches. Just don't do a blind factorization, it will back-fire very quickly.
  7. If anyone could test the following pull request, with a Tinkerboard and a screen supporting resolutions like 1366x768, this should settle the HDMI issues with RK3288 boards for now : Note : I prepared a Debian Bullseye image with the patches reworked here : Since it uses the reworked patches, and not the patches as provided in the pull request, if that doesn't work, give the pull request patches a try ! The reworked patches are available here : (4005 to 4012)
  8. Just in case, I have a very small example that uses DRM and OpenGL ES : You'll have to compile it like this : gcc -o drmgl Linux_DRM_OpenGLES.c `pkg-config --cflags --libs libdrm` -lgbm -lEGL -lGLESv2 This will only throw a glClearColor on the screen, with a blueish tone. You might want to try it, if you want to check for DRM/KMS capabilities on your hardware. Note that if you have multiple /dev/dri/cardX nodes, you'll have to edit the source code accordingly : If your system crashes with KMS/DRM, could you try to get some logs from a serial console ?
  9. If anyone has troubles with HDMI when using 5.x kernels, and has enough skills to recompile an armbian, give this a try : And then either answer here, or in the bug report :
  10. If you know how to recompile armbian kernels ( sudo ./ docker EXPERT="yes" ), could you test this : And see if that works with your TV ?
  11. This might be due to the lack of some YUV configurations support in the Rockchip DRM drivers used in mainline kernels. I'll try some new HDMI patches next week, against mainline kernels, see if that resolve these kind of situations.
  12. Hmm, the WARNING can either happen during these four situations : - - - - In the first case, that means that the VOP unit got disabled, for whatever reasons. The others mean some DRM/KMS bugs, which might be due to Rockchip DRM drivers. The best way to be sure would be to recompile a kernel and place logs before the specified points ( dev_err(crtc->dev, KERN_ERROR "Blabla is %d\n", value_to_test) )
  13. Yeah, the logs message clearly indicate that something is going very wrong. My guess is that there's a driver messing up with the system memory, so you get very random behaviour or crashes. So, indeed, try without the Bluetooth dongle for a week or so, see if there's any issue. If there isn't, you'll have to find updated Bluetooth drivers for this chip, or just find another Bluetooth dongle with decent drivers.
  14. Try Werner steps first. Installing libgles2 installed OpenGL ES 2.x drivers. So, to test it, you could try glmark2-es2 (which is installed with glmark2). I'm still surprised that apt install mesa returns nothing.