Myy

Members
  • Content Count

    191
  • Joined

  • Last visited

About Myy

  • Rank
    Elite member

Contact Methods

  • Website URL
    https://github.com/Miouyouyou/RockMyy

Profile Information

  • Gender
    Not Telling
  • Interests
    https://pledgie.com/campaigns/33598

Recent Profile Visitors

1024 profile views
  1. Yeah, the dreaded purple line appeared on my screen too. I jumped the gun. It only disappear on the second reboot, whether the patch is applied or not. If you can try with the HDMI frequencies defined in the DTS file and see it it doesn't break everything, I'd like to get some feedback, indeed. Be careful though, you might have to SSH or Serial back on your machine to replace the current DTS file, if the frequencies generate blackout issues with the screen.
  2. I've adapted a set of patches from Urja Rannikko, which move the HDMI frequencies definition into the DTS file, with some preconfigured rates if none are defined in the DTS. The original patches set is here : https://www.spinics.net/lists/arm-kernel/msg673156.html The big patch I used as a basis is here : https://github.com/urjaman/arch-c201/blob/master/linux-c201/0020-RK3288-HDMI-clock-hacks-combined.patch I included these patches by splitting them again : https://github.com/Miouyouyou/RockMyy/commit/57ff073fffb5678e75959e566704376f6f52ac17 These patches were suggested to me here : https://github.com/Miouyouyou/RockMyy/issues/3 Anyway, after some quick tests, these patches remove the dreaded bar of purple pixels at the left of my HDMI screen, when plugged to Tinkerboard systems and MiQi systems. Note that these bars only appear on my screen when using "good" (enough) USB power supply. Still, with these patches, they are gone. However... I only tested these patches on my 60Hz 1080p screen, which is pretty much the de-facto standard screen. I'd like to see people test these patches on other HDMI configurations which are known to have some issues with Tinkerboard, MiQi and others RK3288 systems. So, yeah, if you'd like to test some kernel patches and are not afraid to see your screen go black after a reboot, have a try. Note : This is completely unrelated with the CEC issue.
  3. Myy

    RK3288 Media Testing Script

    @naseeb From the logs, it is clear that your user-space drivers are more recent that the kernel drivers. The Mali Midgard proprietary drivers are split into two parts : - The kernel driver, under GPL license, which must be added to the kernel or modified to be compiled as an OOT module. - The user-space binary driver, which is a proprietary set of libraries that provide the OpenGL/OpenCL functions. These might be replaced by https://gitlab.freedesktop.org/panfrost in some distant future. Now, getting a new kernel (4.4 -> 4.14) does not ensure you that you'll get newer drivers. You'll get newer drivers, only if the archive containing newer drivers were included in the kernel. Still, IIRC, the linux kernel 4.14 and 4.18-dev provided by Armbian should include more recent Mali Midgard kernel drivers that should allow you to use the provided libraries. However, if you switch from a 4.4 to a 4.14, you'll lose the VPU support at the moment. Concerning the NV12 support, I would suggest you try this, to test the support for this format : https://github.com/robclark/kmscube I guess that Mali drivers supports this format since Mali-400 GPU supported it : https://community.arm.com/graphics/f/discussions/6178/mali-400-dumb-questions
  4. Just let a few ones intact, just in case (´・ω・` )
  5. Logging through the serial console is configured through systemd and boot parameters... But, yeah, one of the default behaviour is to output the kernel messages through the serial console ONLY IF no screen is available. So I guess that HDMI CEC support is broken ? Does the freeze happen with other screens too ? The default UART for debugging purposes on RK3288 is the UART2 (/dev/ttyS1). It might be changed though. The RK3288 Datasheet name UART2 "uart2dbg". UART3 is for plugging GPS systems (which is not used very often, I concur). Just for information : 1. When the HDMI cable is plugged, do you have any SSH access ? If you wait for 5 minutes, is it still frozen ? 2. If you start without an HDMI cable, get a serial console and *then* plug the HDMI screen, what happens ? Do you have any crash or freeze message ? I remember some bug a long time ago, about 4.14 kernels... That would make the system unbootable if you plugged the HDMI cable before booting : https://github.com/Miouyouyou/RockMyy-Build/issues/1 I don't remember how I was able to get a log for this though...
  6. Myy

    RK3288 Media Testing Script

    Also, be sure to use a recent version of glmark2. Compile the GIT version if you can. sudo apt install libjpeg-dev libpng-dev pkg-config libudev-dev libdrm-dev libegl1-mesa-dev libgles2-mesa-dev libgbm-dev git clone --depth 1 https://github.com/glmark2/glmark2 cd glmark2 ./waf configure --with-flavors=drm-glesv2 ./waf Then you should have a binary ready (find -name "glmark2-es2-drm") You could install it too, but it might clashes with your current installation. ./waf install
  7. Myy

    RK3288 Media Testing Script

    @naseeb Hmm, it's weird that the driver doesn't try to access /dev/mali0 at all. It doesn't even try to find DRM devices too. Could you try the DRM version of glmark2 in a terminal (CTRL+ALT+F1 or chvt 1 from an SSH session) and see if it works better ? Also try the --debug flag.
  8. Myy

    The VPU driver

    So, I'm still trying to get this "thing" working on mainline kernels and my last issue is that the setup is done, I launch a decode pass, the IRQ handler is triggered but the output buffer remains untouched. However, the thing I don't have any error messages. I see that some VPU registers changed after the (failed) decode pass, but most of the changed registers are completely undocumented. And by "undocumented", I mean, even RKMPP and the Chromium V4L2 do not document these registers. Meanwhile, I saw that the old drivers use the IOMMU DMA API, so I tried to enable the IOMMU_DMA API on Rockchip systems but that led to the Video Output MMU breaking, along with the DRM drivers firing BUG_ON after BUG_ON. I was still able to boot the system by unplugging the screen, but the VPU driver issue remained identical. Loads, runs, trigger the IRQ, no output. I've even setup an IOMMU Fault handler, just in case, but it's never called. I'm currently trying to look at how to setup a DMA fault handler, maybe that's the issue here. Meanwhile, I tried to disable an old patch I kept around in my kernels and... that led to the VPU MMU clocks not starting anymore... Yay... As a last resort, I'm asking for various hints on the Rockchip Linux and IOMMU Linux Mailing lists. Still... I don't expect much. So I'm close but still not there. Maybe it's a simple bug in the code that I'm not seeing.
  9. The principal major feature not implemented in mainline kernels is the VPU driver. I'll try to give H264 decoding on mainline kernels a shot today. Still, there's a few bugs here and there in the mainline kernels that impact various RK3288 boards, notably USB hotplug, HDMI audio and MMC detection on some systems. There's also some minor warnings regarding framebuffer initialization with some screens that a bug reporter named samsonluk is trying to pinpoint.
  10. If you can get a serial console working, this might help us troubleshooting your current issue.
  11. Could you connect a serial console to your Tinkerboard S and provide the output of the serial console ?
  12. Myy

    RK3288 Media Testing Script

    The Mali driver can use devfreq, and has various ways to be told how to vary the frequency of the GPU. Now, I've been informed recently that a patch is necessary on mainline kernels to avoid some Mali Devfreq related warnings and panics. A modified version of the patch is available here : https://github.com/Miouyouyou/RockMyy/blob/master/patches/Midgard/r19p0-01rel0/0010-GPU-Mali-Midgard-remove-rcu_read_lock-references.patch The original is here : https://github.com/mihailescu2m/linux/commit/bbe73c3c1143e5991bdcaee3afaecf5c31af0647 That said, if you want to push the Mali GPU to higher limits, you can do something like this : cd /sys/class/misc/mali0/device/devfreq/devfreq0/ echo `cat max_freq` > min_freq echo 10 > polling_interval This will force the GPU to be at its highest clock rate constantly (supposedly, I have no way to actually verify that). Now, let's be clear, if you launch a GPU intensive task with these settings, while not having a beefy stable power supply, the board might just shut down or not provide any performance gain. Now that's mostly the case for USB power supplied board. Still, these settings provide good performances gain on some benchmarks, very little on others. Frequency alone won't help you overcome bad optimizations. Also sometimes performances issues become CPU bound as the GPU gets faster.
  13. Myy

    Wifi is not working

    And if you do sudo ifconfig wlan0 up ? Is NetworkManager able to bring up the interface through nmtui ?
  14. What if you do : mv /var/lib/apt/lists/apt.armbian.com_dists_xenial_InRelease{,.bak} apt update ? If that fails miserably, just do : mv /var/lib/apt/lists/apt.armbian.com_dists_xenial_InRelease{.bak,}