Myy

Alright, I'll take a look at how Tablets kernels implement it then, if any use DTS files

Well, while the RTL8723bs driver itself will tell you the reference of the Bluetooth chip, BTCoexist, I don't think that it knows how to use directly. I'm wondering if it doesn't delegate the whole management to that other driver. Anyway, I thought that would worth a try, since it's related to rtlwifi drivers and seem to coincide with the dmesg output for the RTL8723bs WLAN driver. Given that everything else has been loaded, I'm wondering what else could be missing.

So I'm trying to add Bluetooth support for Tinkerboard devices and after searching for any "Bluetooth" related option in the kernel, I stumbled into CONFIG_RTLBTCOEXIST . So in addition to CONFIG_BT_HCI_UART , this option might be needed to use the BT Coexist functionalities of the Realtek 8723 BS devices. However, it turns out that CONFIG_RTLBTCOEXIST cannot be enabled directly. If you search for the symbol in menuconfig , you won't see any configuration section referenced. So, in order to enable it, you need to enable its dependencies, which are : CONFIG_NETDEVICES (Network device support) CONFIG_WLAN (Wireless LAN) CONFIG_WLAN_VENDOR_REALTEK (Realtek devices) CONFIG_RTL_CARDS (Realtek rtlwifi family of devices) And also one of these drivers : CONFIG_RTL8723AE (Realtek RTL8723AE PCIe Wireless Network Adapter) CONFIG_RTL8723BE (Realtek RTL8723BE PCIe Wireless Network Adapter) CONFIG_RTL8192EE (Realtek RTL8192EE Wireless Network Adapter) CONFIG_RTL8821AE (Realtek RTL8821AE/RTL8812AE Wireless Network Adapter) Which depend on : CONFIG_PCI (PCI support) So, I've generated a configuration that integrate these requirements. If any Tinkerboarder could give it a shot and see if they, at least, get a hci0 interface, this would be great ! The configuration file is : https://github.com/Miouyouyou/MyyQi/blob/master/boot/config-4.12.0-rc4-The-Twelve-MyyQi%2B If you don't get anything, could you paste the dmesg content ?

What do lsmod and uname -a return ?

This error is generally due to /dev/mali0 being inaccessible. If the user-space binary driver cannot access /dev/mali0 it will print a generic error message, telling you that the kernel driver doesn't fit. This can be due to the Mali driver not being loaded, or the current user not being able to access /dev/mali0 due to the current permissions set on the device node. If you have some OpenCL code that you trust, you might want to compile and test it as root. Meanwhile, I try to give a shot at a simple OpenCL example, and the ARM compute library, and both worked. Though, the examples of the Compute Library aren't very noisy and I don't understand how to use them currently. Anyway, here's the results. I pasted the simple OpenCL example code in the file test.c . I used the OpenCL headers provided by the ARM Compute Library since I guess they are suited for their hardware (At least, I hope so) : gamer@tachibana /tmp $ gcc -o /tmp/test /tmp/test.c -lOpenCL -I /tmp/ComputeLibrary/include gamer@tachibana /tmp $ ./test Platform - 1 1.1 CL_PLATFORM_NAME: ARM Platform 1.2 CL_PLATFORM_VENDOR: ARM 1.3 CL_PLATFORM_VERSION: OpenCL 1.2 v1.r12p0-04rel0.c7cf4c8b39970391360f91824733eb1a 1.4 CL_PLATFORM_PROFILE: FULL_PROFILE 1.5 CL_PLATFORM_EXTENSIONS: cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_fp64 cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_gl_sharing cl_khr_icd cl_khr_egl_event cl_khr_egl_image cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory Device - 1: CL_DEVICE_NAME: Mali-T760 CL_DEVICE_VENDOR: ARM CL_DRIVER_VERSION: 1.2 CL_DEVICE_VERSION: OpenCL 1.2 v1.r12p0-04rel0.c7cf4c8b39970391360f91824733eb1a CL_DEVICE_MAX_COMPUTE_UNITS: 4 gamer@tachibana /tmp $ uname -a Linux tachibana 4.12.0-rc4-The-Twelve-MyyQi+ #1 SMP PREEMPT Mon Jun 5 14:12:21 UTC 2017 armv7l Rockchip (Device Tree) GNU/Linux The ARM Compute Library examples gave me that : gamer@tachibana /tmp/ComputeLibrary/build/arm_compute $ cp -r ../../src/core/CL/cl_kernels ./ gamer@tachibana /tmp/ComputeLibrary/build/arm_compute $ LD_LIBRARY_PATH=. ./cl_convolution ./cl_convolution Usage: ./build/cl_convolution [input_image.ppm] No input_image provided, creating a dummy 640x480 image Test passed gamer@tachibana /tmp/ComputeLibrary/build/arm_compute $ ls cl_convolution libarm_compute_core.so src cl_events libarm_compute_core-static.a test_helpers cl_kernels libarm_compute.so examples libarm_compute-static.a gamer@tachibana /tmp/ComputeLibrary/build/arm_compute $ LD_LIBRARY_PATH=. ./cl_events ./cl_events Usage: ./build/cl_events [input_image.ppm] No input_image provided, creating a dummy 640x480 image Test passed Test passed... Well I guess it's okay then

Well, I went with the r17p0 drivers with my kernels and the user-space binary drivers work fine, whether it's the rockchip libmali drivers, or the one provided by ARM for Firefly systems (mostly used for fbdev). The Mali user-space and kernel-space drivers are not directly correlated. They're both needed (although I wonder if it's possible to access the GPU acceleration directly through the kernel interface). However, the user-space binary drivers will work as long as the kernel-space driver version is equal or superior. I guess there's a dumb check like this, in the user space binary drivers. uint_fast8_t is_kernel_version_valid() { return user_version <= kernel_version; } Also, recent versions of the Mali kernel drivers tend to support more 'recent' kernels (4.9 maximum, IIRC), while older versions might have to be patched and adapted to 4.7, 4.8 and 4.9 changes. That said : If you encounter issues with Rockchip r13p0 user-space binary drivers and kernel r16p0 drivers, I could provide some help. If you want to try integrating the r13p0 kernel drivers, you could get them here : https://developer.arm.com/products/software/mali-drivers/midgard-kernel And try playing with my script here : https://github.com/Miouyouyou/MyyQi/blob/master/GetPatchAndCompileKernel.sh Or you could also try to adapt phusson OOT Mali modules drivers here : https://github.com/phhusson/rockchip_forwardports

Yay ! ＼（・ヮ・）／ Well, that's one more integrated element supported. So, besides the VCodec driver, what Tinkerboards' drivers are still completely missing ? Bluetooth I guess ?

Ah, too bad. Yeah, I've seen that a part of the wireless detection is linked to the RFKill subsystem (Why though...). Is the SDIO part enabled though ? The driver itself seems to rely on SDIO detection ID. I wonder if there's a way to probe any hardware using the SDIO subsystem, a bit like lspci or lsusb , in order to get the hardware ID of hardware available through this protocol. https://github.com/TinkerBoard/debian_kernel/blob/linux4.4-rk3288/drivers/net/wireless/rockchip_wlan/rtl8723bs/os_dep/linux/sdio_intf.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/rtl8723bs/os_dep/sdio_intf.c Anyway, I'll try to compile the Tinkerboard version of the driver on the newest kernel, see if it can be done and see if it adds anything.

Hey everyone ! Due to some demands, I started to try integrating the Tinkerboard Wifi module, which is nicely implemented in their own kernel. Really, first time I see actual Wifi configuration tools directly integrated into the kernel source tree. Work of art ! I don't know if the most important part is the DTS part that seems to hint that the Wireless system is detected through the RFKill subsystem. Or if that part is kind of a red herring and the most important parts are the ones common to many different RK3288 DTS integrating Wifi, which is a combination of a sdio_pwrseq definition, some pinctrl definitions and an SDIO section definition. Example on an official RK3288 DTS, rk3288-veyron.dts : sdio_pwrseq: sdio-pwrseq { compatible = "mmc-pwrseq-simple"; clocks = <&rk808 RK808_CLKOUT1>; clock-names = "ext_clock"; pinctrl-names = "default"; pinctrl-0 = <&bt_enable_l>, <&wifi_enable_h>; /* * On the module itself this is one of these (depending * on the actual card populated): * - SDIO_RESET_L_WL_REG_ON * - PDN (power down when low) */ reset-gpios = <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>; } &sdio0 { status = "okay"; bus-width = <4>; cap-sd-highspeed; cap-sdio-irq; keep-power-in-suspend; mmc-pwrseq = <&sdio_pwrseq>; non-removable; num-slots = <1>; pinctrl-names = "default"; pinctrl-0 = <&sdio0_clk &sdio0_cmd &sdio0_bus4>; sd-uhs-sdr12; sd-uhs-sdr25; sd-uhs-sdr50; sd-uhs-sdr104; vmmc-supply = <&vcc33_sys>; vqmmc-supply = <&vcc18_wl>; }; Similar sections can be found in the Tinkerboard's kernel rk3288-miniarm.dts file. These sections are not present in the official rk3288-tinker.dts, so I created a patch to add it like this : https://github.com/Miouyouyou/MyyQi/blob/master/patches/kernel/v4.12/0014-Second-tinkerboard-Wifi-driver-addition-tentative.patch However, I don't own the hardware so if anyone can give it a try, while enabling the staging rtl8723bs driver (´・ω・`　) Also, here's a mainlined Sunxi SoC DTS declaring the driver in a totally different way.

IIRC, X11Vnc uses its own X11 configuration file. You might find some useful tips in there : http://www.karlrunge.com/x11vnc/faq.html#faq-display-manager

I remember that they had a repository named "rootfs", which had Debian packages for the proprietary drivers and their video codecs libraries. I see that they renamed it rk-rootfs-build. Their packages worked when I tested them, however they were only generated for one specific version of Debian (Debian 9 I think, if I'm not mistaken), and so they tend to depend on specific outdated components versions sometimes. Also, since the drivers provided by the ARM Mali team seem to have better support for some technologies, at some points, I made my little aliases scripts to juggle with the different drivers. That said, on my Gentoo system, I tried to use their drivers to run different KMS/DRM and Wayland GL benchmarks and they work fine. Using mutter and qtwayland was a mess, but I blame these projects for providing terrible error messages and poorly written documentation.

Concerning the OpenGL ES side, using the proprietary drivers and my patched kernel, I've been able to run all the Mali GLES FBdev SDK samples, whether they use Compute Shaders or Occlusion culling, using FBdev and KMS drivers. I'm also able to run the different variants of glmark2, but that's OpenGL ES 2.x samples so... I haven't any OpenGL ES 3.x benchmarks for Linux systems, anyway Now, as pointed in this whole thread : Powering the whole board with something better than the micro USB would be very wise if you want to run GPU intensive applications on it, or else you might suffer from bad lags and worse. Also, be sure that your application is OpenGL ES and Embedded friendly (Manage your bandwith, draw front to back, draw transparent elements last, prefer small and optimized shaders to big generic shaders, ...), if you want to get the maximum performances from the board. See the ARM® Mali™ Application Developer Best Practices for more informations on how to optimize things for Mali GPU. That said, I've run all the Mali samples while powering the board with a Micro USB cable between my PC front USB ports and the board. *ducks*. That said, if you create a new GLES project, in 2017, on Linux systems, try to focus on the DRM/KMS side, or the Wayland side if you want to target windowing systems. The FBdev interface, while being greatly supported by the ARM team right now, is also deprecated by the Linux kernel team since a few years and is likely to be abandoned. I mean, the main maintainer of the FBdev interface has quit a few months ago, and nobody replaced him. Edit : My main way to run the OpenGL ES samples using the proprietary drivers is to create a shell alias commands, that run the targeted software with the appropriate GLES drivers, in a "Nvidia optimus bumblebee drivers" fashion, like this: In the .bashrc In the shell $ mali_drm ./drm_kms_gles_program # Run this program using the proprietary GLES KMS drivers $ mali_fbdev ./fbdev_gles_program # Run this program using the proprietary GLES FBdev drivers That's clunky, though.

@TonyMac32 Yeah, I just compiled a 4.12-rc1 today and added/removed a few patches to make it work. Still, most of patches applied nicely, which is a nice thing... I guess ? Anyway, here's the new patchset for Mali r17p0 drivers : https://github.com/Miouyouyou/MyyQi/tree/master/patches/Mali/r17p0-01rel0 The UMP drivers failed to compile because the headers for copy_from_user and copy_to_user were unified to linux/uaccess.h instead of asm/uaccess.h. ( Is there a way to inline code nicely with Invision ? (´・ω・`　) ) https://github.com/Miouyouyou/MyyQi/blob/master/patches/Mali/r17p0-01rel0/0005-Using-the-new-header-on-4.12-kernels-for-copy_-_user.patch That said, I might drop UMP support soon as, with dmabuf, PRIME and others kernel and GPU memory sharing features provided by the new DMA and DRM infrastructure; the Unified Memory Protocol is not really useful anymore. The new 4.12 patchset I'm using is available here : https://github.com/Miouyouyou/MyyQi/tree/master/patches/kernel/v4.12 Now, I haven't followed this thread for a week, so I don't know if there's new patches for the rk3288-tinker.dts file. I just avoided the creation of the rk3288-miniarm.dts file, as I don't know if it's still useful now that there's a mainlined Tinkerboard DTS file, and I cannot test and compare the two as I do not possess such hardware. However, I'll take a look at this thread now and see if there's any useful patch that I could add for the -rc2 release. Yes ! This is a known bug and I'm starting to wonder if it's related to overheating, as I do not have such problems when running the fan at full speed, however this typically happen if I don't put it on and run a few compilations on Gentoo. That said, there were some 4.4 Rockchip patches that seemed to solve this issue. I'll try to find back the references and see how this could be implemented on the 4.12 side.

There's some informations here about advanced configuration of ALSA and Pulseaudio : https://wiki.archlinux.org/index.php/PulseAudio#ALSA

In the mainline kernel, I see references about the RT5640 for Tegra SoC and some Intel SoC, but nothing about Rockchip. It might be necessary to write some code to adapt these drivers for Rockchip systems, in such kernels.

What's the lsmod output on the working image ? Also, ALSA provides some additional informations in /proc/asound that you might find useful for determining the currently used driver. http://alsa.opensrc.org/Proc_asound_documentation

Greetings everyone. @TonyMac32 I tried to add a few lines to the DTS file integrated in the ARMbian tree, in order to enable preliminary support for Mali drivers and VCodec services to the Tinkerboard DTS file. If anyone could test this : https://github.com/Miouyouyou/MyyQi/blob/master/patches/kernel/v4.11/0101-First-Mali-integration-test-for-ASUS-Tinkerboards.patch A precompiled kernel and DTB file are available here. However the kernel come with minimal drivers support so I don't know if it will run directly on Tinkerboards. 0101-First-Mali-integration-test-for-ASUS-Tinkerboards.patch

Could you paste the content of the failing compilation lines ? Also, you might want to create a quick git repo containing your DTS files. While I could try compiling a DTB file for Tinkerboards during the next update, I'll not be able to test such DTB as I do not own any Tinkerboard

Well, my main use of rockchip tools was to put a working UBoot, by typing ' upgrade_tool db rk3288_boot.bin ' when my MiQi was out of service, in order to be able to use UBoot commands afterwards (through a UART console). That said, I do not know if these commands can do the same on Tinkberboards.

If the Tinkerboard acts like the MiQi, nothing on UART might mean that the system is in "Rockchip download" mode and can accept a new firmware. If you can connect it to a PC and check its 'lsusb' ID, you could do a web search of this ID and check if that's a common "Rockchip download" ID (like 2207:320a).

Greetings everyone ! Concerning the eMMC, note that one of the patches applied to kernel 4.10.0 just mute the eMMC driver, in order to avoid it spamming the logs with mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0) Discussion about the original patch (not the adaptation) can be found here : http://lists.infradead.org/pipermail/linux-rockchip/2017-January/013621.html Still, if anyone with DTS knowledge could analyse the DTS files and see if the eMMC drivers are not misconfigured, that would be nice. Also, you could see if trimming affect performances by running fstrim before.