Ok, started...

from rockmyy-build.

PASSED! No vblank timeout for dmesg_4.16-rc1-RockMyy-16Bits-Edition.log

from rockmyy-build.

I'll try to research what is error -517 and what could cause this issue. I'll see what I can find.

Note that, given my current schedule, this will take roughly a week to pinpoint the issue.

There are other issues with the Rockchip DRM and my current set of patches so I'll see if porting previous ones or removing some patches could fix such issues too.

from rockmyy-build.

Ok, thanks :)
I'll keep an eye out for your work!

from rockmyy-build.

Hmm, the issue seems to come from the dw-mipi-dsi.c driver. The issue seems to occur during the binding phase and it seems to call pm_runtime_enable, since the driver forget to call pm_runtime_disable when failing generating additional error logs when calling pm_runtime_enable after the first time.

The binding function of the dw-mipi-dsi driver is called dw_mipi_dsi_bind. The function is very noisy and the only way it could bail out, after calling pm_runtime_enable, without sending any error log is during the following check :

        if (!dsi->panel) {
                ret = -EPROBE_DEFER;
                goto err_mipi_dsi_host;
        }

Which coincide with the error number 517 :

#define EPROBE_DEFER      517     /* Driver requests probe retry */

Errors are always negated in order to do simple checks (if return_value < 0 then it's an error).

So, the main point will be to understand why the MIPI driver consider that there's no panel.

Did you try to plug the screen after starting the Tinkerboard ? Does it make a difference ?

Also, did you try to connect to the Tinkerboard with a serial link, start the tinkerboard THEN plug the screen ? Does it make a difference too ?

from rockmyy-build.

Well, since I've been able to test my kernel on a real Tinkerboard myself AND hit this bug on the way, I found a way to resolve the issue and pushed a new build script + a new build that should work this time.

Now the thing is, in order to sidestep this issue, I had to disable the MIPI-DSI node in the rk3288-tinker.dts, so if you have a touchscreen connected in MIPI, they won't work anymore. I'll try to investigate this issue a bit more once I get a touchscreen to play with the Tinkerboard.

That said, I know that this bugreport is quite old so I don't know if you still own a Tinkerboard and still wish to give these kernel builds a test.
Anyway, if you can comment on this issue, this will be nice.
Else, I'll close this bug in a few days. In such event, you can re-open it if the issue is not solved on your side, of course.

from rockmyy-build.

I hit this error -517:

dmesg | grep rockchip

[ 0.488560] rockchip-drm display-subsystem: bound ff930000.vop (ops 0xc0d8748c)
[ 0.489022] rockchip-drm display-subsystem: bound ff940000.vop (ops 0xc0d8748c)
[ 0.489167] rockchip-drm display-subsystem: failed to bind ff980000.hdmi (ops 0xc0d88d98): -517
[ 0.489557] rockchip-drm display-subsystem: master bind failed: -517
[ 0.507395] rockchip-spi ff130000.spi: chipselect 0 already in use
[ 1.039613] dwmmc_rockchip ff0c0000.dwmmc: IDMAC supports 32-bit address mode.
[ 1.039632] dwmmc_rockchip ff0c0000.dwmmc: Using internal DMA controller.
[ 1.039639] dwmmc_rockchip ff0c0000.dwmmc: Version ID is 270a
[ 1.039665] dwmmc_rockchip ff0c0000.dwmmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo
[ 1.039743] dwmmc_rockchip ff0c0000.dwmmc: GPIO lookup for consumer cd
[ 1.039747] dwmmc_rockchip ff0c0000.dwmmc: using device tree for GPIO lookup
[ 1.039759] dwmmc_rockchip ff0c0000.dwmmc: using lookup tables for GPIO lookup
[ 1.039763] dwmmc_rockchip ff0c0000.dwmmc: lookup for GPIO cd failed
[ 1.039767] dwmmc_rockchip ff0c0000.dwmmc: GPIO lookup for consumer wp
[ 1.039770] dwmmc_rockchip ff0c0000.dwmmc: using device tree for GPIO lookup
[ 1.039780] dwmmc_rockchip ff0c0000.dwmmc: using lookup tables for GPIO lookup
[ 1.039783] dwmmc_rockchip ff0c0000.dwmmc: lookup for GPIO wp failed
[ 1.063291] dwmmc_rockchip ff0d0000.dwmmc: 'num-slots' was deprecated.
[ 1.063412] dwmmc_rockchip ff0d0000.dwmmc: IDMAC supports 32-bit address mode.
[ 1.063429] dwmmc_rockchip ff0d0000.dwmmc: Using internal DMA controller.
[ 1.063435] dwmmc_rockchip ff0d0000.dwmmc: Version ID is 270a
[ 1.063464] dwmmc_rockchip ff0d0000.dwmmc: DW MMC controller at irq 31,32 bit host data width,256 deep fifo
[ 1.063472] dwmmc_rockchip ff0d0000.dwmmc: 'clock-freq-min-max' property was deprecated.
[ 1.063492] dwmmc_rockchip ff0d0000.dwmmc: GPIO lookup for consumer wp
[ 1.063495] dwmmc_rockchip ff0d0000.dwmmc: using device tree for GPIO lookup
[ 1.063507] dwmmc_rockchip ff0d0000.dwmmc: using lookup tables for GPIO lookup
[ 1.063511] dwmmc_rockchip ff0d0000.dwmmc: lookup for GPIO wp failed
[ 1.063543] dwmmc_rockchip ff0d0000.dwmmc: allocated mmc-pwrseq
[ 1.101011] rockchip-drm display-subsystem: bound ff930000.vop (ops 0xc0d8748c)
[ 1.101213] rockchip-drm display-subsystem: bound ff940000.vop (ops 0xc0d8748c)
[ 1.101330] dwhdmi-rockchip ff980000.hdmi: Detected HDMI TX controller v2.00a with HDCP (DWC MHL PHY)
[ 1.101657] rockchip-drm display-subsystem: bound ff980000.hdmi (ops 0xc0d88d98)
[ 1.319467] dwmmc_rockchip ff0c0000.dwmmc: Successfully tuned phase to 130
[ 1.431569] rockchip-drm display-subsystem: fb0: frame buffer device
[ 1.431824] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0
[ 5.279795] rockchip-rga ff920000.rga: HW Version: 0x00.00
[ 5.279968] rockchip-rga ff920000.rga: Registered rockchip-rga as /dev/video0

from rockmyy-build.

Ah, indeed, when I was building RockMyy-Build, I don't think I had a Tinkerboard at that time, so I didn't pay attention to this issue.

For the moment, if you got a x86 machine (or if you want to recompile a kernel on a Tinkerboard), I might recommend using the latest RockMyy script and give it a go.
I'll push a recent build that work with Tinkerboard systems this week.

from rockmyy-build.

Oh sure, I've the x86 machine ready with Ubuntu/qemu-arm-static in a docker container or shouldn't be any problem for even recompile the kernel under Tinkerboard itself. In case of this how to disable cross compile for GetPatchAndCompileKernel.sh?

My goal is try setup a proper environment to compile/run Kodi 18 gbm with rkmpp hw accelerated support for h.264/hevc video playback in the Tinkerboard. At this moment I am running Android version of Kodi 18 with it which is very stable, however, Android doesn't like my remote control (generating repeat keys, no such problem under Linux) so I would like to get a working version of Kodi with Linux.

I really appreciate the setup Mali user-space driver tutorial that you put in RockMyy wiki, it really given me a lot of hints on how to get things together, I wish I could discover it earlier!

from rockmyy-build.

To disable the cross-compilation, edit the GetPatchAndCompileKernel.sh
and just comment the CROSS_COMPILE variable, or set it to nothing (CROSS_COMPILE=).

Concerning the Video playback with RKMPP, you'll need the VPU driver that goes with it and, on my side, it's still WIP. I'm currently trying to get it working. To do that, I need to :

• Get the list of registers values sent to the VPU, by RKMPP
• Get the corresponding frames related decoded, when sending these values (Current frame + Reference frames)
• Analyse them. Some registers values are modified by the driver, some are not.
• Reproduce the behaviour on my driver.

The first two steps are being dealt with, so I'm focusing on the third and last one.

Also, there's a V4L2 implementation, coded by Tomasz Figa ( @tom3q ) from the Chromium team, that is known to work on 4.4 kernels. @baruchsiach is trying to port this implementation on recent kernels.
The base kernel driver of that implementation is here : https://github.com/rockchip-linux/kernel/tree/release-4.4/drivers/media/platform/rockchip-vpu
The libraries can be retrieved, following this ebuild : https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/libv4lplugins/libv4lplugins-9999.ebuild
The idea, with this implementation, is that you don't need any special plugin. As long as the media player knows how to use V4L2 for Video decoding, it should work.
I haven't tested it though and the port needs some special part of the V4L2 API that are not "mainlined".

Anyway, it might still take a few months before getting a working VPU driver on mainline kernels.

Meanwhile, GBM + GLES work fine.

I also started to test Vulkan but... the API isn't easy and there's only ONE driver for Mali T760 FBDEV driver that is known to possibly work... At least querying for devices and queues work, but since the it does not have GBM, the whole "get a framebuffer with DRM and use it with the API" thing needs to be reimplemented...

from rockmyy-build.

I've released a 4.18-rc5 build. Have a try : https://github.com/Miouyouyou/RockMyy-Build/archive/v4.18-rc5.tar.gz

from rockmyy-build.

I see, rockchip vpu driver is still missing in the mainline. I noticed that kodi 18 support V4L2, I will give it a try before rkmpp ready.

I've started RockMyy script 4.18-rc5 build for a few hours already, would it be possible to pass over "-j N" to speed up the compilation?

# MAKE_CONFIG=menuconfig bash GetPatchAndCompileKernel.sh
scripts/kconfig/mconf-cfg.sh: line 7: pkg-config: command not found
scripts/kconfig/mconf-cfg.sh: line 13: pkg-config: command not found

I would expect the above are just warning messages? because the compilation process just keep going..

It failed:
CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192ee/rf.o CC fs/xfs/xfs_trans_inode.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192de/led.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.o CC [M] drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.o CC [M] drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192cu/phy.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rtl8188ee.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192ce/rf.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192se/dm.o CC fs/eventfd.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.o CC fs/aio.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192ee/table.o CC fs/locks.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.o CC fs/xfs/xfs_trans_refcount.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192se/led.o CC fs/xfs/xfs_trans_rmap.o CC fs/xfs/xfs_sysctl.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192se/phy.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.o LD [M] drivers/net/wireless/realtek/rtlwifi/btcoexist/btcoexist.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/fw.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192de/rf.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8192ee/rtl8192ee.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/dm.o CC fs/binfmt_script.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/fw.o AR fs/xfs/built-in.a CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192ce/table.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192de/table.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hal_btc.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hal_bt_coexist.o CC fs/binfmt_elf.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192cu/table.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192se/table.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8192se/trx.o CC fs/binfmt_elf_fdpic.o CC fs/mbcache.o CC fs/posix_acl.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/led.o CC fs/coredump.o CC fs/drop_caches.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8192de/rtl8192de.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8192ce/rtl8192ce.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723com/main.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.o CC fs/fhandle.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/phy.o CC fs/iomap.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723com/dm_common.o CC fs/dcookies.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/pwrseq.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rtl8192cu.o CC [M] drivers/net/wireless/realtek/rtlwifi/base.o CC [M] drivers/net/wireless/realtek/rtlwifi/cam.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8192se/rtl8192se.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/rf.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/table.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/led.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723com/fw_common.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723com/phy_common.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/pwrseq.o CC [M] drivers/net/wireless/realtek/rtlwifi/core.o CC [M] drivers/net/wireless/realtek/rtlwifi/debug.o AR fs/built-in.a CC [M] drivers/net/wireless/realtek/rtlwifi/efuse.o CC [M] drivers/net/wireless/realtek/rtlwifi/ps.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/led.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/rf.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/table.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/rtl8723ae.o CC [M] drivers/net/wireless/realtek/rtlwifi/rc.o CC [M] drivers/net/wireless/realtek/rtlwifi/regd.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/pwrseq.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8723com/rtl8723-common.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/rf.o CC [M] drivers/net/wireless/realtek/rtlwifi/stats.o CC [M] drivers/net/wireless/realtek/rtlwifi/pci.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.o CC [M] drivers/net/wireless/realtek/rtlwifi/usb.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.o CC [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8723be/rtl8723be.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtlwifi.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl_usb.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl_pci.o LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/rtl8821ae.o AR drivers/net/wireless/built-in.a AR drivers/net/built-in.a AR drivers/built-in.a compilation failed

ReRun

./GetPatchAndCompileKernel.sh
scripts/kconfig/conf  --oldconfig Kconfig
    configuration written to .config
scripts/kconfig/conf  --syncconfig Kconfig
  CALL    scripts/checksyscalls.sh
<stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp]
  CHK     include/generated/compile.h
  GZIP    kernel/config_data.gz
  CC      net/rfkill/core.o
make[2]: *** No rule to make target 'net/netfilter/xt_DSCP.o', needed by 'net/netfilter/built-in.a'.  Stop.
scripts/Makefile.build:558: recipe for target 'net/netfilter' failed
make[1]: *** [net/netfilter] Error 2
make[1]: *** Waiting for unfinished jobs....
  AR      net/rfkill/built-in.a
Makefile:1029: recipe for target 'net' failed
make: *** [net] Error 2
make: *** Waiting for unfinished jobs....
Compilation failed

from rockmyy-build.

pkg-config issues come from the fact that pkg-config is not installed. In most distributions, the package containing this software is named pkg-config. On Debian, you could try apt-get install pkg-config.
Also, install ncurses-dev, if you want to use menuconfig.

Try to install pkg-config and see if resolves the issue.

I don't know why the current configuration requires xt_DSCP...

Worst case try to move or delete the linux folder, and rerun the script like this :
bash GetPatchAndCompileKernel.sh

And then, if it compiles fine, try to do :

cp linux/.config CurrentConfig
MAKECONFIG=menuconfig bash GetPatchAndCompileKernel.sh
# Configure the kernel as you want

And if it fails, paste the output of :

diff -u CurrentConfig linux/.config

from rockmyy-build.

Installed both pkg-config and ncurses-dev, deleted linux... restart the whole process:
bash GetPatchAndCompileKernel.sh

let's wait...
For the record. a fresh installed debian need the following packages:
apt install gcc make automake bison flex wget git libssl-dev bc pkg-config ncurses-dev

from rockmyy-build.

Very weird...

In file included from arch/arm/boot/dts/rk3288-rock2-square.dts:42:0:
./scripts/dtc/include-prefixes/dt-bindings/input/input.h:13:31: fatal error: linux-event-codes.h: No such file or directory
 #include "linux-event-codes.h"
                               ^
compilation terminated.

$ ls -l linux/scripts/dtc/include-prefixes/dt-bindings/input
total 10
-rwxr-xr-x 1 root root  358 Jul 20 10:03 gpio-keys.h
-rwxr-xr-x 1 root root  538 Jul 20 10:03 input.h
lrwxrwxrwx 1 root root   36 Jul 20 10:03 linux-event-codes.h -> ../../uapi/linux/input-event-codes.h
-rwxr-xr-x 1 root root 1061 Jul 20 10:03 ti-drv260x.h

$ more linux/scripts/dtc/include-prefixes/dt-bindings/input/input-event-codes.h
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
/*
 * Input event codes
 *
 *    *** IMPORTANT ***
 * This file is not only included from C-code but also from devicetree source
 * files. As such this file MUST only contain comments and defines.
 *
 * Copyright (c) 1999-2002 Vojtech Pavlik
 * Copyright (c) 2015 Hans de Goede <[email protected]>
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 as published by
 * the Free Software Foundation.
 */

I believe something wrong with docker while the source folder is mount from host, everything alright after moved the source back inside the container...

from rockmyy-build.

Is the filesystem used able to handle symlinks ? When you move the data back, are the symlinks still symlinks ?

from rockmyy-build.

Host is Windows NTFS, should able to handle symlinks. In fact I was not able to move the data back because ./scripts/dtc/include-prefixes/dt-bindings/input unable to move with some strange characters left behind, I was not able to delete this folder within docker but only able to remove it from host side.

Anyway, compilation success this time, I will install it to tinkerboard tomorrow and report back.

from rockmyy-build.

Alright then 😺

from rockmyy-build.

I don't know what to say, in summary:

# dmesg | grep rockchip
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.518511] rockchip-vop ff930000.vop: Linked as a consumer to ff930300.iommu
[    0.518922] rockchip-vop ff940000.vop: Linked as a consumer to ff940300.iommu
[    0.521409] rockchip-drm display-subsystem: Linked as a consumer to ff930000.vop
[    0.521449] rockchip-drm display-subsystem: Linked as a consumer to ff940000.vop
[    0.522237] rockchip-drm display-subsystem: Linked as a consumer to ff980000.hdmi
[    0.523436] rockchip-drm display-subsystem: bound ff930000.vop (ops 0xc0d8984c)
[    0.523901] rockchip-drm display-subsystem: bound ff940000.vop (ops 0xc0d8984c)
[    0.524014] rockchip-drm display-subsystem: failed to bind ff980000.hdmi (ops 0xc0d8b280): -517
[    0.524270] rockchip-drm display-subsystem: master bind failed: -517
[    0.543183] rockchip-spi ff130000.spi: chipselect 0 already in use
[    0.780514] dwmmc_rockchip ff0c0000.dwmmc: IDMAC supports 32-bit address mode.
[    0.780534] dwmmc_rockchip ff0c0000.dwmmc: Using internal DMA controller.
[    0.780541] dwmmc_rockchip ff0c0000.dwmmc: Version ID is 270a
[    0.780569] dwmmc_rockchip ff0c0000.dwmmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo
[    0.780660] dwmmc_rockchip ff0c0000.dwmmc: GPIO lookup for consumer cd
[    0.780664] dwmmc_rockchip ff0c0000.dwmmc: using device tree for GPIO lookup
[    0.780684] dwmmc_rockchip ff0c0000.dwmmc: using lookup tables for GPIO lookup
[    0.780687] dwmmc_rockchip ff0c0000.dwmmc: No GPIO consumer cd found
[    0.780692] dwmmc_rockchip ff0c0000.dwmmc: GPIO lookup for consumer wp
[    0.780695] dwmmc_rockchip ff0c0000.dwmmc: using device tree for GPIO lookup
[    0.780712] dwmmc_rockchip ff0c0000.dwmmc: using lookup tables for GPIO lookup
[    0.780715] dwmmc_rockchip ff0c0000.dwmmc: No GPIO consumer wp found
[    0.806322] dwmmc_rockchip ff0d0000.dwmmc: IDMAC supports 32-bit address mode.
[    0.806337] dwmmc_rockchip ff0d0000.dwmmc: Using internal DMA controller.
[    0.806345] dwmmc_rockchip ff0d0000.dwmmc: Version ID is 270a
[    0.806371] dwmmc_rockchip ff0d0000.dwmmc: DW MMC controller at irq 31,32 bit host data width,256 deep fifo
[    0.806397] dwmmc_rockchip ff0d0000.dwmmc: GPIO lookup for consumer wp
[    0.806400] dwmmc_rockchip ff0d0000.dwmmc: using device tree for GPIO lookup
[    0.806419] dwmmc_rockchip ff0d0000.dwmmc: using lookup tables for GPIO lookup
[    0.806422] dwmmc_rockchip ff0d0000.dwmmc: No GPIO consumer wp found
[    0.806441] dwmmc_rockchip ff0d0000.dwmmc: allocated mmc-pwrseq
[    0.846881] rockchip-drm display-subsystem: bound ff930000.vop (ops 0xc0d8984c)
[    0.847109] rockchip-drm display-subsystem: bound ff940000.vop (ops 0xc0d8984c)
[    0.847214] dwhdmi-rockchip ff980000.hdmi: Detected HDMI TX controller v2.00a with HDCP (DWC MHL PHY)
[    0.847729] rockchip-drm display-subsystem: bound ff980000.hdmi (ops 0xc0d8b280)
[    1.025048] [<c07385ac>] (drm_atomic_helper_wait_for_vblanks) from [<c0763a8c>] (rockchip_atomic_helper_commit_tail_rpm+0xb4/0x164)
[    1.025053] [<c0763a8c>] (rockchip_atomic_helper_commit_tail_rpm) from [<c0739c50>] (commit_tail+0x40/0x6c)
[    1.025138] [<c073e378>] (__drm_fb_helper_initial_config_and_unlock) from [<c0767cb4>] (rockchip_drm_fbdev_init+0x88/0xd0)
[    1.025143] [<c0767cb4>] (rockchip_drm_fbdev_init) from [<c0763550>] (rockchip_drm_bind+0x158/0x1c8)
[    1.025150] [<c0763550>] (rockchip_drm_bind) from [<c0777854>] (try_to_bring_up_master+0x68/0x158)
[    1.025161] [<c0777b60>] (component_master_add_with_match) from [<c07637b4>] (rockchip_drm_platform_probe+0x19c/0x1f0)
[    1.025167] [<c07637b4>] (rockchip_drm_platform_probe) from [<c077e56c>] (platform_drv_probe+0x48/0x94)
[    1.094464] dwmmc_rockchip ff0c0000.dwmmc: Successfully tuned phase to 129
[    1.144085] rockchip-drm display-subsystem: fb0:  frame buffer device
[    1.144335] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0
[    2.225552]   #1: rockchip,tinker-codec

Please diff the complete before/after kernel upgrade dmesg log for details (I've cut off the time stamps column): dmesg_logs.zip

Before/after chrome GPU outputs: chrome_gpu_outputs.zip

System still boot up in GUI desktop but seems everything is in software rendering mode.

I did not touch the stock user space mali yet:
~# dpkg -l libmali-rk-midgard-r9p0-r0p0
ii libmali-rk-midgard-r9p0-r0p0:ar 1.5-4 armhf The mali library for Rockchip RK3288(not included RK3288W).

Should I replace it with libmali-rk-midgard-t76x-r14p0-r0p0_1.6-1_armhf.deb and see what happen?

from rockmyy-build.

Okay, so in order :

The Vblank timeout issue seems to be a common random issue that can occur on multiple systems : anholt/linux#66

What is the resolution of your screen ? Does it happen with other screens at 1080p resolution ? Does it also happen if you reboot ?

When you boot into the GUI, can you switch back to a console and see the login prompt ? (CTRL+ALT+F1)
If you can, try to install the https://github.com/rockchip-linux/rk-rootfs-build/blob/master/packages/armhf/libmali/libmali-rk-midgard-t76x-r14p0-r0p0-wayland_1.6-1_armhf.deb , then acquire the latest glmark2 from their Git, compile it and run the DRM version and see if you get something on the screen.

git clone --depth 1 https://github.com/glmark2/glmark2
cd glmark2
./waf configure --with-flavors=drm-glesv2
./waf
sudo ./waf install

The wayland drivers should have the necessary calls to deal with X11 too. Also note that if that's a fresh install, you might need the special snowflake xserver from Rockchip to get any acceleration done. ( https://github.com/rockchip-linux/rk-rootfs-build/tree/master/packages/armhf/xserver )
You can check if you have OpenGL ES 2 acceleration using es2_info, which is provided by mesa-utils-extra.
Use es2_info | grep -i vendor to check if you OpenGL ES 2 is done through Mesa or through Mali drivers.

Does the issue also occurs with the tarball of the latest RockMyy-Build (→ release). I just want to rule out potential compiler versions issues.

Also, if you can, have a try with other microUSB cables, just in case. Some random issues can happen when underpowering the board, due to an insufficient charger/cable combination. The worst being shutdown.

from rockmyy-build.

What is the resolution of your screen ? Does it happen with other screens at 1080p resolution ? Does it also happen if you reboot ?

My TB connected via HDMI to a Toshiba 1080p TV, I am not aware of this Vblank timeout issue until now. I mainly using it with Android due to I cannot find any Kodi with HW accelerated support in the Linux world. I also found the SoC run much cooler while operate under Android.

If not look into the dmesg logs by no mean it can tell anything goes wrong after boot up because lightdm show up as usual without any complaint. I can see the screen resolution being set to 1920x22XX in the text mode for a few seconds before the GUI desktop, it switched back to 1080p automatically after that. If GUI being disabled upon boot, it will stay at 1920x22XX which is very difficult to view in the TV screen. I am about to ask how can text console default to 1080p upon boot up for using RockMyy kernel. No such problem with TinkerOS kernel.

When you boot into the GUI, can you switch back to a console and see the login prompt ?

Sure, I mainly manage it via ssh instead of sitting in front of the TV :) My remote is for Kodi operation.

Also note that if that's a fresh install, you might need the special snowflake xserver from Rockchip to get any acceleration done. ( https://github.com/rockchip-linux/rk-rootfs-build/tree/master/packages/armhf/xserver )

As mentioned, this is not a fresh install, I am just using RockMyy kernel with TinkerOS so I believe this Rockchip xserver already there. I will install libmali-rk-midgard-t76x-r14p0-r0p0-wayland_1.6-1_armhf.deb and compile glmark2 and get back.

Does the issue also occurs with the tarball of the latest RockMyy-Build (→ release). I just want to rule out potential compiler versions issues.

Will download and test before switching libmali.

Also, if you can, have a try with other microUSB cables, just in case. Some random issues can happen when underpowering the board, due to an insufficient charger/cable combination. The worst being shutdown.

Thanks for the reminder, I power it via GPIO with a 2.5A adapter.

from rockmyy-build.

I guess that the HDMI detection is broken again in "fbdev" emulation mode. I remember that the default Rockchip 4.4 kernels, and the Tinkerboard ones, added a lot of modifications to HDMI related code to avoid this issue with the framebuffer.

Now the reason I'd like to check if DRM OpenGL ES work fine, is that it avoids the framebuffer code and only uses DRM/KMS directly. If everything goes fine in this mode, that would mean that the issue is mainly located into the Framebuffer emulation code.

You can, of course, switch to a console through SSH 😺

Just type, in your SSH console :

chvt 1 # 1 being the VT number. 1 -> CTRL+ALT+F1. 2 -> CTRL+ALT+F2

Then try to launch glmark2-es2-drm once it's installed.

If you feel adventurous enough, you could then try things like : https://github.com/dvdhrm/kmscon
This is a Virtual Terminal that uses the DRM/KMS backend for display, instead of the framebuffer code.

from rockmyy-build.

Screen resolution is 1920x2205/24 before switch to GUI, 1080p/60 being correctly setup in GUI, below logs should explain why:

[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] rockchip_mmc_get_phase: invalid clk rate
[    0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[    0.000008] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns

Confirmed, by install over tarball of the latest RockMyy-Build reproduce the same vblank timeout issue and this is not a random event, I have reboot and power on/off 4 to 5 times and it happened 100%.

BTW, I forgot from where did I download 4.15.0-rc9-Kernel-Maker-XV tarball? It should be from the branch before you updated 2 days ago in RockMyy-Build but I can only found v4.13-VPU-Test now. If you take a look on dmesg_4.15.0-rc9-Kernel-Maker-XV.log, this is the one without vblank timeout issue and I want to test it again. I lost that tarball...

from rockmyy-build.

Google found 4.15.0-rc9-Kernel-Maker-XV - GitHub but is now 404-Page not found

Cache here

from rockmyy-build.

Every time I push to RockMyy-Build, I delete the previous modules folders, else the size of the repository would go up dramatically. It's already very heavy, so I won't add more.

Anyway I've tagged the 4.15-rc9 released. You can now download it through the "releases" link. Note that you can also browse the history of a repository by clicking on "Commits" and then clicking on the "<>" link at the right of a commit. This link allows you to browse the repository at that commit point. In the browsing interface, Github provides a "Clone or Download" button, which allows you to download the whole repository. You can use that technique, to download the previous version of a repository.

Could you also give RockMyy 4.15, 4.16 and 4.17 a try ? I'm trying to pinpoint when this issue appeared. I think this is related to the IRQ issue that slowed down the Video Output to a crawl, and the associated patch.

Just change the kernel versions in the main script by 4.15, 4.16 or 4.17.

from rockmyy-build.

Noted and thanks for the hints on Git. I will give everyone a try and report back...

from rockmyy-build.

Could you also give RockMyy 4.15, 4.16 and 4.17 a try ? I'm trying to pinpoint when this issue appeared. I think this is related to the IRQ issue that slowed down the Video Output to a crawl, and the associated patch.

Just change the kernel versions in the main script by 4.15, 4.16 or 4.17.

I suppose no need to delete linux/ folder, right? Here we go:

root@91d81f86bc53:/usr/src# diff GetPatchAndCompileKernel.sh GetPatchAndCompileKernel_4.18-rc5.sh
10,11c10,11
< export KERNEL_SERIES=v4.16
< export KERNEL_BRANCH=v4.16
---
> export KERNEL_SERIES=v4.18
> export KERNEL_BRANCH=v4.18-rc5
root@91d81f86bc53:/usr/src# bash GetPatchAndCompileKernel.sh
scripts/kconfig/conf  --oldconfig Kconfig
#
# configuration written to .config
#
scripts/kconfig/conf  --syncconfig Kconfig
  CALL    scripts/checksyscalls.sh
<stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp]
  CHK     include/generated/compile.h

Seems not, have to remove linux/ :(

from rockmyy-build.

Patch missed:

--2018-07-22 01:39:06--  https://raw.githubusercontent.com/Miouyouyou/RockMyy/master/patches/kernel/v4.16/0007-drivers-drm-rockchip-Enable-IRQ-on-unbi
nd.patch
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.76.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.76.133|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2018-07-22 01:39:07 ERROR 404: Not Found.

Could not download 0007-drivers-drm-rockchip-Enable-IRQ-on-unbind.patch

from rockmyy-build.

Seems not just missing... hopefully can be fixed by getting GetPatchAndCompileKernel.sh at The 4.16.0 !

Keep going now... Thanks for the Git tutorial...

from rockmyy-build.

Test Summary:
dmesg_4.15.0-rc9-Kernel-Maker-XV.log - No vblank timeout
dmesg_4.16-RockMyy-16Bits-Edition.log - with vblank timeout
dmesg_4.18.0-rc5-RockMyy-181818.log - with vblank timeout

On which kernel I should work on other mentioned stuff?

from rockmyy-build.

Ok, Could you try one last time with this script : https://raw.githubusercontent.com/Miouyouyou/RockMyy/96213ddf19c13d054e863e999be8e89630504900/GetPatchAndCompileKernel.sh

So I can be sure that the issue occurred at the 4.16-rc1 release.

from rockmyy-build.

Script failed:

--2018-07-22 10:49:08--  https://raw.githubusercontent.com/Miouyouyou/RockMyy/master/patches/kernel/v4.16/0005-ASUS-Tinkerboard-Stupid-reboot.patch
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.76.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.76.133|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2018-07-22 10:49:08 ERROR 404: Not Found.

Could not download 0005-ASUS-Tinkerboard-Stupid-reboot.patch

from rockmyy-build.

Replace that patch reference by 0005-drivers-mmc-dw-mci-rockchip-Handle-ASUS-Tinkerboard.patch. The old got moved to 0005-dw_mmc-The-stupid-ASUS-Reboot.patch

from rockmyy-build.

Or you can add that patch to the patches/kernel/v4.16 folder :
https://raw.githubusercontent.com/Miouyouyou/RockMyy/96213ddf19c13d054e863e999be8e89630504900/patches/kernel/v4.16/0005-ASUS-Tinkerboard-Stupid-reboot.patch

cd patches/kernel/v4.16
wget https://raw.githubusercontent.com/Miouyouyou/RockMyy/96213ddf19c13d054e863e999be8e89630504900/patches/kernel/v4.16/0005-ASUS-Tinkerboard-Stupid-reboot.patch
cd -

from rockmyy-build.

Ok, passed

from rockmyy-build.

The compilation passed or the vblank issue did not occur ? 😺

from rockmyy-build.

Sorry, I mean script passed. Compilation just completed, wait...

from rockmyy-build.

So that's between the 4.16-rc1 and the release that something went wrong with the framebuffer...

I'll check the logs of the mainline kernel, to see if that's something that was added over there.

from rockmyy-build.

Ok, just for the DRM subsystem alone, we're around 130 patches between the 4.16-rc1 and the 4.16

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/gpu/drm?h=v4.16
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/gpu/drm?h=v4.16-rc1

The fbdev driver in the other hand received too few modifications it seems :

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/video?h=v4.16-rc1
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/video?h=v4.16

On my side, there were no major changes between each 4.16-rcX versions. Only the ASUS Tinkerboard reboot patch got modified.

So, have a try with the rc4, at least, this should cut the chase in half.
Here's the RockMyy repo at that moment, with the scripts and patches : https://github.com/Miouyouyou/RockMyy/archive/0dfd08eeb9ca1ece37b083e22c494afd5f4a379c.zip

If I can test it on a TV this week, I'll give it a try. On my ASUS Screen, the problem doesn't occur, so I need to pinpoint two rcX versions where the problem occured and did not occur.
logs.txt

Then, it will be time for educated guesses and test patches, based on the modifications added between those two versions, to understand what's going on exactly and how to solve it.

from rockmyy-build.

Meanwhile, I'll open a new bug report.

from rockmyy-build.

Here, let's continue the conversation there : Miouyouyou/RockMyy#9

from rockmyy-build.