Myy

Okay, it seems that Rockchip already export the base groups and GPIO0 only has 24 pins root@tinkerboard:/sys/class/gpio# cat /sys/class/gpio/gpiochip0/label gpio0 root@tinkerboard:/sys/class/gpio# cat /sys/class/gpio/gpiochip0/ngpio 24 GPIO4 starts from 120, not 128 it seems : root@tinkerboard:/sys/class/gpio# cat /sys/class/gpio/gpiochip120/label gpio4 root@tinkerboard:/sys/class/gpio# cat /sys/class/gpio/gpiochip120/ngpio 32 root@tinkerboard:/sys/class/gpio# cat /sys/class/gpio/gpiochip120/base 120 So the actual values would be : UART_RTS : GPIO4 19 (GPIO4C3 : uart0bt_rtsn - RTS Pin) → GPIO139 RESET : GPIO4 29 (GPIO4D5 : sdio0_bkpwr - Reset == Remove the backup power ??) → GPIO149 WAKE : GPIO4 26 (GPIO4D1: sdio0_detectn - Wake up == Detect the chip ??) → GPIO146 WAKE_HOST_IRQ : GPIO4 31 (GPIO4D7 : Undocumented) → GPIO151 But the export functions give me nothing on my 4.17. I'll check tomorrow if I'm not missing an option with GPIO export. I'll also remove the DTS entry, see if it "frees" up the GPIO.

So, continuing the discussion of this thread here : BS stands for BullShit of course ! ＼（・ヮ・）／ ... Broadcom Systems ? (・ω・｀ ) Anyway, since the Rockchip DTS uses one naming, the kernel uses another one and the Rockchip Datasheet uses yet another one, I don't which one we're talking about. According to TRM : GPIO4C3 is RTS. The DTS says GPIO4 19 for RTS. I guess that the kernel starts from GPIO 0 and the TRM using one letter every 8 bits, so GPIO4C3 refers to GPIO4 2*8 + 2 -> GPIO4 19 ? Now the kernel wants the absolute reference when enabling it. Since there seems to be only 32 pins per GPIO group, GPIO4 19 would be GPIO 128 + 19 -> GPIO 147 ? So exporting the RTS pin would be something akin to : echo 147 > /sys/class/gpio/export This would lead to : UART_RTS : GPIO4 19 (GPIO4C3 : uart0bt_rtsn - RTS Pin) → GPIO147 RESET : GPIO4 29 (GPIO4D5 : sdio0_bkpwr - Reset == Remove the backup power ??) → GPIO157 WAKE : GPIO4 26 (GPIO4D1: sdio0_detectn - Wake up == Detect the chip ??) → GPIO154 WAKE_HOST_IRQ : GPIO4 31 (GPIO4D7 : Undocumented) → GPIO159 So basically, to expose the Bluetooth GPIO (besides the IRQ one) : echo 147 > /sys/class/gpio/export echo 157> /sys/class/gpio/export echo 154 > /sys/class/gpio/export ? I'll try that and see how it fares.

Aha ! I'll try this tonight ! Though I forgot the chip they used in the Tinky. It's a broadcom too ? I'll take a look.

Hmm, the usb driver seems to be whining about missing regulators so there might be a few things to check here. Or maybe it's a red herring. Wasn't the q8 kind of similar to "MiQi" devices ? If you temporarily swap the MiQi DTS with the q8 DTS, do you have USB devices enabled ? If yes, does the same bug happen ? Also, if you shorten the following sections from : &usb_host0_ehci { reg = <0x0 0xff500000 0x0 0x20000>; resets = <&cru SRST_USBHOST0_PHY>; reset-names = "phy-reset"; status = "okay"; }; &usb_host1 { pinctrl-names = "default"; pinctrl-0 = <&usbhub_rst>; resets = <&cru SRST_USBHOST1_PHY>; reset-names = "phy-reset"; status = "okay"; }; to &usb_host0_ehci { status = "okay"; }; &usb_host1 { status = "okay"; }; Does it work better ?

Could you provide your dmesg logs ? Also, what's the issue with the USB ports exactly ? They just don't work or is it more subtle ?

So Rockchip's 4.4 I2S driver works fine though ? I'll take a look at it then.

Greetings, I recently had a request about testing the I2S and SPDIF output of MiQi devices and after some fiddling on this board, it seems that the Rockchip I2S + Simple-Audio ALSA driver just output nothing on the I2S TX/RX pins, at least. So was anyone able to output sound directly through the I2S GPIO pins on any RK3288 device ? Tinkerboard devices seems to use that setup and it seems to be working, but I'd like to know if that's working through the soldered Jack or the GPIO.

Did you enable the Synopsys DesignWare Watchdog Driver ? Check in your .config file if DW_WATCHDOG=m or DW_WATCHDOG=y is present. It's the only watchdog driver compatible with snps,dw-wdt DTB entries. /* drivers/watchdog/dw_wdt.c */ static const struct of_device_id dw_wdt_of_match[] = { { .compatible = "snps,dw-wdt", }, { /* sentinel */ } };

Are you sure the driver is installed ? I'll see if I can put a tutorial on how to install Rockchip libmali Debian packages ( https://github.com/rockchip-linux/rk-rootfs-build/tree/master/packages/armhf/libmali ) and their Xserver ( https://github.com/rockchip-linux/rk-rootfs-build/tree/master/packages/armhf/xserver ). Anyway, if you don't care about X11, install the libmali package and launch glmark2-es2-drm. Else, try to install the Xserver first, then the libmali package. The reason being that the official XServer glamor extension does not play well with the Mali drivers, it seems. Could you give the output of glmark2-es2-drm --debug ?

Be sure to use the git version of glmark2, as Debian or Ubuntu's version of glmark2 might not have the Udev DRM node selection code. Also, be sure to execute this from a real terminal (CTRL+ALT+F1 if your keyboard is connected to the RK3288 device, or chvt 1 if you're connected through SSH). At last, try this as root in order to be sure that you don't have any issue due /dev/mali0 access rights.

Ah ! Good to know ! I'll still keep it in the "To be done or documented" list, though.

So, since I received my microSD correctly, I've been able to test the Tinkerboard with my kernels, using an Armbian image as a basis (along with some microSD cards), and I hit one of the bugs that were reported on my Github page. This bug triggers an endless stream or error messages which talk about the DRM driver trying to bind something through the MIPI output and failing. Which is perfectly normal since I didn't plug anything in MIPI (nor HDMI when the bug was triggered). Still, blocked the boot phase. With the original boot.scr, it seemed to trigger a quick reboot continuously, but I don't know if it's because of that bug since I got no output on the serial console when that happened with that configuration (just U-boot output, booting, and U-boot output again, ...). Switching to extlinux/extlinux.conf configuration displayed the error messages, with no reboot. Anyway, the only solution I found to sidestep the issue at the moment is to avoid adding a mipi_dsi node to the Tinkerboard DTS which... removes the MIPI DSI capabilities of the board, yeah... So, basically, I don't apply the patch that adds the mipi_dsi node to the rk3288-tinker.dts for the moment. However, if I get a touchscreen, I'll still try to see if I can enable such functionnality without triggering the same issue.

Is the CPU becoming burning hot during when it hangs ? Your issue sounds like @Tido's issue in the GPU Driver? thread. What kind of display do you use ? And also what is its resolution ?

Well, after upgrading to artful, I discovered that the official FFMPEG project pulled a patch provided by LongChair which enable MPP support in FFMPEG directly... So I now need to recompile FFMPEG... On Ubuntu... I'll try to recompile ffmpeg with just h264 support for now.

I've ported the new code provided by Ayaka but I still need to test it. Since I'm using a different MiQi, I have to recompile mpp (done) and mpv. The last one is posing several issues since it wants a pretty recent version of FFMPEG. I'll see whether I compile a new local version of ffmpeg of if I upgrade from Ubuntu Xenial to Ubuntu Artful to resolve this issue.

Yeah, I only care about the the Direct Rendering Manager system (・ω・｀；) Now, I understand everyone requests for a better documentation on how to install and use the Mali user-space binary drivers. This has been asked on my repository too, and I just started and untested draft in the Wiki of my repository, until I find a better way to format and distribute such documentation. Still, I repeat, this is untested for now.

Indeed, the DRM tests are VSync'ed by default. So you'll get ~1 FPS/Hz . I got 59 on a cold boot but when using a proper power supply, it stays at 60 for most of the tests, beside crystal bunny and that ugly terrain. Note that the special X server can be installed more easily if you have you use Zesty or Arftul repositories. However, I really doubt that any Armbian people could help you if that patched X Server becomes broken. If I have the time, I'll try, once again, to use plasma-desktop + KWin Wayland/DRM with the Mali drivers and see how it goes... It will probably fail miserably though, with no useful error messages.

@Tido Glad you make it through. As always, ugly terrain and crystal bunny are the most GPU intensive operations. I guess that you're screen works at 55Hz ? Anyway, scripting the Mali user-space binary drivers sound nice and all until you realize that, besides wayland (weston only I'd say), DRM (used by almost nobody currently) and fbdev (used only by mediacenter-like distros), they won't be very useful. The X11 ones require a specific X Server, or you'll get a terrific crash when X starts... Anyway, something like : mkdir -p ~/.local/lib cd ~/.local/lib wget https://github.com/rockchip-linux/libmali/raw/rockchip/lib/arm-linux-gnueabihf/libmali-midgard-t76x-r14p0-r1p0-wayland.so -O libmali.so for file_to_link in libGLESv1_CM.so{,.1} libGLESv2.so{,.2} libEGL.so{,.1} libgbm.so{,.1,.1.0.0} libOpenCL.so{,.1,.1.0.0}; do ln -s libmali.so $file_to_link; done echo "alias mali_exec LD_LIBRARY_PATH=\$LD_LIBRARY_PATH:`echo ~/.local/lib`" >> ~/.bashrc Might do the trick for now. This is actually untested though. This should add a "mali_exec" command that can be used like this : mali_exec glmark2-es2-drm Providing a Nvidia Optimus bumblebee-like execution mechanism.

if you type file /home/tido/myy-s/mali/libmali.so what does it return ?

If you read this when running glmark2 : GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 4.0, 128 bits) Then you're not using the Mali user-space binary drivers. You're using CPU-bound renderer provided by Mesa. Now, the user-space binary drivers are a pain in the ass tricky to install, since they require a special snowflake X server from Rockchip. What I'd suggest is to : Create a folder Download libmali-midgard-t76x-r14p0-r0p0-wayland.so from rockchip-linux/libmali repository Copy the file in the folder you created, then open a shell in this folder and type mv libmali-midgard-* libmali.so for file_to_link in libGLESv1_CM.so{,.1} libGLESv2.so{,.2} libEGL.so{,.1} libgbm.so{,.1,.1.0.0} libOpenCL.so{,.1,.1.0.0}; do ln -s libmali.so $file_to_link; done LD_LIBRARY_PATH=. glmark2-es2-drm Be sure that your user have read-write access to /dev/mali0. Else the test might also fail. This should recreate all the necessary library file names that are searched by the OpenGL ES 2.x binary and use the instructions stored in libmali.so. Aren't you glad that these drivers are so easy to install... Yeah I should create a wrapper script for that thing... seriously.

No, you'll have to : Reinstall the Mali drivers somehow, or get them in a folder and use the LD_LIBRARY_PATH trick. If X11 is currently using the display, you'll have to type : sudo chvt 1 # Equivalent of CTRL+ALT+F1 on a keyboard To reattach the TTY 1, which will provide a non-locked CRTC, since the X11 CRTC, generally attached to TTY 7, is locked by the X11 process for various valid reasons. The binary looks good though.

I remember that I compiled it with only doing something like : apt install libjpeg-dev libpng-dev libdrm-dev libgbm-dev libudev-dev libegl1-mesa-dev libgles2-mesa-dev The error message is incorrect. The project only needs libpng 1.2 OR 1.5 OR 1.6. Not all at once. Anyway, no need to compile the required libraries. You should be able to grab them through apt and standard Debian/Ubuntu repositories. Just try to be as generic as possible when searching for the development headers.

@Tido What version of glmark2 do you have ? The old versions seemed to have a broken DRM detection system based on some whitelist, that I kind of fixed in the later versions. I highly suggest using the GIT version of glmark2 and uninstalling glmark2 Debian packages for the moment. sudo apt remove glmark2 git clone --depth 1 https://github.com/glmark2/glmark2 cd glmark2 ./waf configure --with-flavors=drm-glesv2 ./waf sudo ./waf install glmark2-es2-drm Also, be sure to execute that version from a TTY (Ctrl+ALT+F1 or chvt 1)

Now that I have access to my MiQi, here's the /boot/extlinux/extlinux.conf I'm using to boot my kernels : root@miqi:~# cat /boot/extlinux/extlinux.conf label kernel-4.4 kernel /boot/zImage fdt /boot/rk3288-miqi.dtb append earlyprintk console=ttyS2,115200n8 rw root=/dev/mmcblk1p1 rootfstype=ext4 init=/sbin/init Note that I'm not using a /boot partition. Anyway, here's ls -l /boot root@miqi:~# ls -l /boot total 92172 -rw-r--r-- 1 root root 78 May 3 2017 armbianEnv.txt -rw-r--r-- 1 root root 1557 May 3 2017 armbian_first_run.txt -rw-r--r-- 1 root root 129427 May 3 2017 config-4.11.0+ -rw-r--r-- 1 root root 155497 Sep 12 00:36 config-4.13.0-RockMyy-XIII -rw-r--r-- 1 root root 155497 Sep 10 19:44 config-4.13.0-RockMyy-XIII.old -rw-r--r-- 1 root root 156664 Sep 16 07:53 config-4.14.0-rc4-RockMyy-XIV-A-Myy-Reborn -rw-r--r-- 1 root root 156664 Sep 16 07:36 config-4.14.0-rc4-RockMyy-XIV-Myy-Returns -rw-r--r-- 1 root root 156664 Nov 2 09:05 config-4.14.0-rc7-RockMyy-XIV-A-Myy-Reborn -rw-r--r-- 1 root root 125351 Aug 12 17:31 config-4.4.81-rockchip drwxr-xr-x 2 root root 4096 Jun 20 15:42 dtb-4.11.0-rockchip drwxr-xr-x 2 root root 4096 Aug 7 16:50 dtb-4.13.0-rockchip drwxr-xr-x 2 root root 4096 Aug 18 16:49 dtb-4.4.81-rockchip drwxr-xr-x 2 root root 4096 Sep 12 00:26 extlinux -rw-r--r-- 1 root root 4438628 Oct 30 16:10 initrd.img-4.11.4-rockchip -rw-r--r-- 1 root root 4421353 Aug 18 16:55 initrd.img-4.4.81-rockchip drwx------ 2 root root 4096 Jul 16 22:17 lost+found -rw-r--r-- 1 root root 40525 Nov 2 09:05 rk3288-evb-act8846.dtb -rw-r--r-- 1 root root 40922 Nov 2 09:05 rk3288-evb-rk808.dtb -rw-r--r-- 1 root root 37039 Nov 2 09:05 rk3288-fennec.dtb -rw-r--r-- 1 root root 40777 Nov 2 09:05 rk3288-firefly-beta.dtb -rw-r--r-- 1 root root 40769 Nov 2 09:05 rk3288-firefly.dtb -rw-r--r-- 1 root root 41955 Nov 2 09:05 rk3288-firefly-reload.dtb -rw-r--r-- 1 root root 39656 Nov 2 09:05 rk3288-miqi.dtb -rw-r--r-- 1 root root 41029 Jul 18 16:59 rk3288-miqi.dtb.bak -rw-r--r-- 1 root root 39604 Nov 2 09:05 rk3288-popmetal.dtb -rw-r--r-- 1 root root 37310 Nov 2 09:05 rk3288-r89.dtb -rw-r--r-- 1 root root 40289 Nov 2 09:05 rk3288-rock2-square.dtb -rw-r--r-- 1 root root 41026 Nov 2 09:05 rk3288-tinker.dtb -rw-r--r-- 1 root root 39316 Nov 2 09:05 rk3288-veyron-brain.dtb -rw-r--r-- 1 root root 47442 Nov 2 09:05 rk3288-veyron-jaq.dtb -rw-r--r-- 1 root root 47495 Nov 2 09:05 rk3288-veyron-jerry.dtb -rw-r--r-- 1 root root 39921 Nov 2 09:05 rk3288-veyron-mickey.dtb -rw-r--r-- 1 root root 48314 Nov 2 09:05 rk3288-veyron-minnie.dtb -rw-r--r-- 1 root root 45862 Nov 2 09:05 rk3288-veyron-pinky.dtb -rw-r--r-- 1 root root 47270 Nov 2 09:05 rk3288-veyron-speedy.dtb -rw-r--r-- 1 root root 3702224 Sep 12 00:36 System.map-4.13.0-RockMyy-XIII -rw-r--r-- 1 root root 3702224 Sep 10 19:44 System.map-4.13.0-RockMyy-XIII.old -rw-r--r-- 1 root root 3781860 Sep 16 07:53 System.map-4.14.0-rc4-RockMyy-XIV-A-Myy-Reborn -rw-r--r-- 1 root root 3781964 Sep 16 07:36 System.map-4.14.0-rc4-RockMyy-XIV-Myy-Returns -rw-r--r-- 1 root root 3782323 Nov 2 09:05 System.map-4.14.0-rc7-RockMyy-XIV-A-Myy-Reborn lrwxrwxrwx 1 root root 23 Oct 30 16:10 uInitrd -> uInitrd-4.11.4-rockchip -rw-r--r-- 1 root root 4438692 Oct 30 16:10 uInitrd-4.11.4-rockchip -rw-r--r-- 1 root root 4421417 Aug 18 16:55 uInitrd-4.4.81-rockchip -rw-r--r-- 1 root root 19873868 Sep 10 19:44 vmlinuz-4.13.0-RockMyy-XIII -rw-r--r-- 1 root root 19897976 Sep 16 07:09 vmlinuz-4.14.0-rc4-RockMyy-XIV-Myy-Returns -rwxr-xr-x 1 root root 8039272 Aug 21 05:05 vmlinuz-4.4.81-rockchip -rwxr-xr-x 1 root root 8167960 Nov 2 09:05 zImage And the motd SSH output : __ __ _ ___ _ | \/ (_)/ _ \(_) | |\/| | | | | | | | | | | | |_| | | |_| |_|_|\__\_\_| Welcome to ARMBIAN 5.30 stable Ubuntu 16.04.2 LTS 4.14.0-rc7-RockMyy-XIV-A-Myy-Reborn System load: 0.52 0.19 0.07 Up time: 0 min Memory usage: 7 % of 2009MB IP: 10.100.0.55 CPU temp: 61°C Usage of /: 27% of 15G [ 0 security updates available, 97 updates total: apt upgrade ] Last check: 2017-11-02 09:08 [ General system configuration: armbian-config ] Last login: Mon Oct 30 16:21:04 2017 from 10.100.0.1 To run a command as administrator (user "root"), use "sudo <command>". See "man sudo_root" for details. Anyway, I still have some issues with the HDMI screen that I have to unplug / plug back sometimes. I'll try to see if adding back some the old DRM patches fix the issue. Here's my modules list btw : root@miqi:~# lsmod Module Size Used by bnep 20480 2 mali_kbase 512000 1 dw_hdmi_i2s_audio 16384 0 dw_hdmi_cec 16384 0 rk_crypto 24576 0 Why is the bnep loaded ? Well, that's a good question ! I have no single idea, since there's no Bluetooth chip integrated into the MiQi, as far as I remember. When launching glmark2, you should get that kind of output : root@miqi:~# glmark2-es2-drm ======================================================= glmark2 2017.07 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-T760 GL_VERSION: OpenGL ES 3.2 v1.r14p0-01rel0-git(966ed26).810f535757d8c9adaaa72f5da29c688e ======================================================= [build] use-vbo=false: FPS: 59 FrameTime: 16.949 ms [build] use-vbo=true:^C FPS: 60 FrameTime: 16.667 ms ======================================================= glmark2 Score: 59 ======================================================= The ^C is due to me hitting CTRL+C. The first batch should be at 59 fps generally, after a cold start.

And that's how @TonyMac32 became a SnowMan. Anyway, I guess I'll have to find a Tinkerboard during December, since that clearly needs special testing.