Jump to content

Myy

Members
  • Posts

    365
  • Joined

  • Last visited

Posts posted by Myy

  1. 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.

  2. So, continuing the discussion of this thread here :

     

    2 hours ago, TonyMac32 said:

    It's a Realtek 8723BS, but operates the same way. (any guess what BS stands for? ;-) ). I actually think we should wipe out the DTS entry that's there for it and start over, since that one appears to be tied somehow to the Rockchip special rfkill system.  I was able to get it to start the handshake by toggling the gpio pins associated, so this might be a template for getting to to work properly.  Ok, enough off-topic.  :-D

     

    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.

  3. On 5/7/2018 at 3:02 AM, TonyMac32 said:

    @Myy I wonder if this might be able to be adapted for Tinker mainline bluetooth?

     

    So much time so little to do!...  Strike that, reverse it.

     

    220px-Gene_Wilder_as_Willy_Wonka.jpeg

     

    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.

  4. 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 ?

     

  5. 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.

  6. 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 */ }
    };

     

  7. 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 ?

  8. 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.

  9. 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.

  10. 3 hours ago, Tido said:

    @Myy, I am just reading about the new features of 4.14 release and come across this: Direct Rendering Manager (DRM)

    When you wrote about it, I always thought, why does he care about Digital Rights Management :D

     

    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.

  11. 10 hours ago, Tido said:

    I checked, 56Hz it says when the tinker board is connected on Windows I ran that Display at 60Hz.
    Does this explain the FPS maxium, I saw you reached 59 ?

    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.

  12. @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.

  13. 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.

  14. 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.

  15. 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.

  16. @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)

     

  17. 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.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines