Myy

Members
  • Content count

    102
  • 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

243 profile views
  1. Tinker board thermals broken post 4.12.0

    I asked the question, I got informed that I should not hardcore these numbers, but didn't get anything on a fool proof method to get the CPU temperature. I'll reiterate another day, with less typos and a better grammar. https://irclog.whitequark.org/linux-rockchip/2017-09-16 The discussion then diverted on potential future Vulkan support.
  2. Tinker board thermals broken post 4.12.0

    Well, after a quick test, it seems that the number after tsadc seems to determine the probe to check, but does not affect the numbering. Meaning that if you put tsadc 1 on the reserve_thermal and tsadc 0 on the cpu : - You won't be able to read the CPU temperature through thermal_zone1, even though it's enabled - but you'll be able to the CPU temperature through thermal_zone0, even though it's disabled and named reserve_thermal.
  3. Tinker board thermals broken post 4.12.0

    I don't know if that's the order, or the number associated with the tsadc entry ( thermal-sensors = <&tsadc 0>; ). I'll try to ask #linux-rockchip , see if they have a clue about this reserved area.
  4. Tinker board thermals broken post 4.12.0

    On my MiQi board, thermal_zone0 is disabled, thermal_zone1 is enabled and so is the 2. Which gives : root@miqi:~# cat /sys/class/thermal/thermal_zone0/mode disabled root@miqi:~# cat /sys/class/thermal/thermal_zone1/mode enabled root@miqi:~# cat /sys/class/thermal/thermal_zone2/mode enabled root@miqi:~# cat /sys/class/thermal/thermal_zone0/temp cat: /sys/class/thermal/thermal_zone0/temp: Invalid argument root@miqi:~# cat /sys/class/thermal/thermal_zone1/temp 45000 root@miqi:~# cat /sys/class/thermal/thermal_zone2/temp 44090 Since the temperature sensor used in the login message from Armbian works, I never tried to play too much with the temperature sensors. I could try to find why the first sensor is disabled though.
  5. The VPU driver

    Alright, I think I got something working ! MPV using MPP seems to work and is able to read a 1080p WebM file and output a very fluid image ! However, I only tested this with 1m30s sample files so I'll have to test this more seriously. Still, having the VPU driver works on 4.13 kernels is nice ! Now, I'll need testers ! So here's a patched kernel build, including the VPU driver in it : https://github.com/Miouyouyou/RockMyy-Build/releases/tag/v4.13-VPU-Test This build include patches that makes logging VERY NOISY when playing files. If everything works nicely, I'll remove the noise. Here's the repository containing the patches applied : https://github.com/Miouyouyou/RockMyy/tree/VPU_Work_tests And here's the patch itself : https://github.com/Miouyouyou/RockMyy/blob/VPU_Work_tests/patches/kernel/v4.13/0012-Slight-butchering-to-test-the-VPU-driver.patch Here's the repository containing the working VPU code : https://github.com/Miouyouyou/rockchip-vcodec/tree/retry Testing the VPU Now, in order to test the VPU driver, you'll need something that work with it ! I tested it with MPP and MPV. So if you want to test it like I did, you'll have to recompile MPP and MPV, and also know how to download and use ARM Mali user-space binary drivers and make them work through the DRM interface. https://github.com/rockchip-linux/mpp https://github.com/LongChair/mpv https://github.com/rockchip-linux/libmali/ Have fun ! Whether everything works or you got a crash, don't hesitate to reply on this thread. If you something went wrong, please provide any crash message that might appear in dmesg !
  6. Kernel -rcX : Last version issues

    Stock OS ? You mean ASUS Debian image ? Yeah, I guess you can give it a try. I got ready-to-use kernel files here : https://github.com/Miouyouyou/RockMyy-Build That said, my configuration and ARMbian kernel configuration might differ in some places. Also, I'm only testing my kernels on MiQi devices so I can't guarantee that everything will work on Tinkerboard systems.
  7. Kernel -rcX : Last version issues

    The patch seems to have been backported in time for the 4.13.0 release and can now be omitted.
  8. Kernel -rcX : Last version issues

    So the issue is now resolved in linux-next, which is one of the official git repository that pull the changes that will happen in the next version following the current Release or Release Candidate. I imported the patch and here it is : https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.13/0012-net-phy-Deal-with-unbound-phy-driver-in-phy_attached.patch The official patch being : https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=fcd03e362b1cd17de487953aac34f2d4574895cf
  9. Let's make a topic dedicated to the latest issues with the latest Linux Release Candidate provided on the Linus Torvalds git repository. So, on the 4.13.0-rc6, I got a crash on boot on my MiQi devices due to some changes in the logging functions used by the STMMAC Ethernet driver. I reverted some of their changes by just commenting the new logging function. I'll try to get in touch with the person who wrote the commit that generated this issue, as he tends to roam in the #linux-rockchip IRC channel. Meanwhile, here's the patch : https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.13/0012-net-stmmac-Reverting-a-part-of-Use-the-right-logging.patch Here's the issue : https://github.com/Miouyouyou/RockMyy/issues/1 And here's the commit that generated that issue : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c?id=fbca164776e438b639af592c522b8b0506b54dcc
  10. The VPU driver

    Not until I can run Crysis on it. Also, the thing is, will my software (or the OS) be able to map more than 4GB without some additional TLB sorcery ? ( ̄〜 ̄ ) Anyway, I guess I'll just rework my patch to set them to "okay" again, then, until I find a RK3288 board without any VPU chip integrated.
  11. The VPU driver

    LPAE... If this "thing" is as well-done as it was on X86, that's clearly not a smart move. Managing tiny virtual special windows with a double dose of address translation just to map more than 4GB on systems where you should not need *that* much sounds pretty much useless. Anyway, the DTS files of Rockchip kernels actually set up the IOMMU to be "okay" directly from the DTSI file. It seems like that the VPU being absent is extremely exceptional on Rockchip 3288 systems. So, I actually did the same in my kernel now.
  12. Add Support for RK3399 (2xA72+4xA53)

    It should not be necessary. The Rockchip DRM package main purpose is to exploit DRI capabilities and the RGA 2D acceleration on Rockchip systems, but the RGA 2D acceleration was deemed inefficient for X11 purposes, and the DRI is not useful when testing DRM capabilities directly from a console.
  13. Add Support for RK3399 (2xA72+4xA53)

    The command to build most of the Rockchip repositories with a debian folder seems to be : dpkg-buildpackage -b -rfakeroot -us -uc That said, I would still highly recommend taking the .so library from their repository, put it in a folder, regenerate the appropriate links quickly and test GLES programs by invoking them like this : LD_LIBRARY_PATH=/path/to/the/library gles-program Installing the new OpenGL ES libraries in /usr/lib could generate serious issues. Testing DRM/KMS OpenGL ES programs, like glmark2, from a real console (CTRL+ALT+F1), or from weston (Wayland), will generally be easier than trying from X11.
  14. ASUS Tinker Board Bluetooth

    Looking at Rockchip's code, I'm starting to wonder if the uart_rts0 GPIO was enabled at all when using their rfkill_bt driver. Maybe it was the reason ? However, in their DTS they initialize it with GPIOD_OUT_LOW, and I put GPIOD_OUT_HIGH in my code (since it's the value that's actually checked by the rfkill_bt driver). I don't know if I should put it to LOW again. The uart_rts0 GPIO don't have any "BT" prefix in their DTS but seems essential to get any communication working with the BT driver anyway.
  15. ASUS Tinker Board Bluetooth

    So, in order to tackle this Tinkerboard issue, I'm trying to write a small Out-Of-Tree driver "bluetooth" driver that focus on enabling and disabling the right GPIO pins, using the RFKILL system as a control system. It does NOT do the UART/HCI communication part, as this should be delegated to BlueZ IMHO. Currently, the code needs to be double checked and then tested (in this order). The point of this driver is to be able to maintain it easily, and so has been heavily commented. Feel free to remove the comments if your own forks. The Makefile needs to be edited in order to use your own kernel tree path, and your own cross-compiler prefix. Once done, just type make to compile the module. This driver needs a different DTS section than the Rockchip one, in order to avoid conflicts, confusion and other issues with the Rockchip "rfkill-bt" driver. So, if anyone with a Tinkerboard has some time to spare, and have enough GPIO knowledge to be sure that the GPIO defined in the DTS and the code are the good one, etc...; Feel free to test my driver. If the driver seem to load correctly, check with the rfkill programs if you can unblock the "bt-gpio" device. Then, if you can, try this hacked HCI attach version or use the latest HCI attach tool provided by BlueZ to set up the device.