Jump to content

Myy

Members
  • Posts

    365
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Myy reacted to EkSeL in rk3288 alternative boards (cheap tv boxes).   
    First, I have to thank @jeanrhum for posting the UT3S deal. Thanks!
     
    I have managed to boot my UT3S via SD card with the MyyQi kernel and the rootfs from the Miqi Armbian image without making any changes to the internal eMMC.
     
    My UT3S came with U-Boot 2014.10-RK3288-02 (Nov 10 2014 - 03:41:49) and I have not done any firmware updates.
     
    Here are the steps that I took:
     
    Follow this guide to creating a bootable Arch Linux ARM SD card. Make sure your UT3S will boot with it.
     
    The toolchain used in the above guide is too old to compile a mainline kernel.
    I used the gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf toolchain which can be downloaded from here:  https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linux-gnueabihf/
     
    Download the MyyQi build script.
     
    At the top of GetPatchAndCompileKernel.sh I replaced the CROSS_COMPILE line with the following:
    export TOOLCHAIN_PATH=/path/to/toolchain export CROSS_COMPILE=${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- export LD_LIBRARY_PATH=${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/lib:${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/libexec/gcc/arm-linux-gnueabihf/5.4.1 export PATH=${TOOLCHAIN_PATH}/gcc-linaro-5.4.1-2017.05-x86_64_arm-linux-gnueabihf/bin:$PATH  
    Run GetPatchAndCompileKernel.sh
    The output should go to /tmp/MyyQi
     
    Do the following to write a bootable SD card:
    cd archlinux-firefly ./firefly-rk3288-kernel/mkkrnlimg /tmp/MyyQi/boot/zImage kernel.img ./firefly-rk3288-kernel/resource_tool /tmp/MyyQi/boot/rk3288-miqi.dtb ./bin/rockchip-mkbootimg/mkbootimg --kernel kernel.img --ramdisk initrd.img -o linux-boot.img # Remove links to firefly kernel rm create-linux-sdcard-usb/boot-linux.img rm create-linux-sdcard-usb/kernel-linux.img cp linux-boot.img create-linux-sdcard-usb/boot-linux.img cp kernel.img create-linux-sdcard-usb/kernel-linux.img cp resource.img create-linux-sdcard-usb/resource-linux.img cd create-linux-sdcard-usb sudo ./create-linux-sdcard-usb  
    You should now have a bootable SD card with MyyQi kernel but no rootfs.
     
    Download the Miqi Armbian image and follow this guide for how to extract the rootfs from an Armbian image.
    Important: Make sure your rootfs image has the label "linuxroot".
     
    Copy firmware and modules from MyyQi kernal to rootfs image:
    cp /tmp/MyyQi/lib/* /path/to/rootfs/image/lib
    Write the rootfs image you have created to USB.
     
    If you would prefer to have the rootfs on the SD card you are using for booting:
    Copy the "create-linux-sdcard" script from the Linuxium RK3288 tools to archlinux-firefly/create-linux-sdcard-usb.
     
    Write SD card with rootfs:
    cd archlinux-firefly/create-linux-sdcard-usb ln -s /path/to/rootfs.img linux-rfs.img sudo ./create-linux-sdcard Put SD card (and optionally USB drive) in UT3S and power on.
     
  2. Like
    Myy got a reaction from chwe in How do I use the camera on tinkerboard?   
    You can try my configuration file if you want, as a basis, since I've already enabled it. Turns out :
     
    1) It's currently a staging driver. Meaning that it *could* work with *some* Raspberry Pi camera. As I understand, there's two completely different versions of the Raspberry Pi Camera and only one is mainlined in the staging folder.
    2) It has a lot of weird dependencies, like requiring Mailbox hardware support, Broadcom SoC support, Raspberry PI Firmware loading support, ...
     
    The configuration key is named VIDEO_BCM2835 .
     
    Its basic requirements are : CONFIG_STAGING, CONFIG_BCM_VIDEOCORE, CONFIG_MEDIA_SUPPORT, CONFIG_VIDEO_V4L2, CONFIG_ARCH_BCM2835
    CONFIG_BCM_VIDEOCORE requires CONFIG_RASPBERRYPI_FIRMWARE, which in turn requires CONFIG_BCM2835_MBOX, hence the requirement for Mailbox hardware support.
     
     
  3. Like
    Myy reacted to tkaiser in [Example] Support proposal for ROCK64   
    Understood, it must be an inner circle. People like @TonyMac32or @Myywho found their way to here by joining open discussions (AFAIK) should be kept out.
     
    I remember differently. Xunlong offered board giveaways, we (the inner circle) discussed whether we want to organize a draw or try to attract more contributors. Some improvements were made but it's obvious that we don't get more contributors in return of hardware worth a few bucks. I still think it's a motivational problem and an 'inner circle' will prevent getting more people joining development efforts.
     
    In the past IMO we also suffered from discussions here in the forum 'moderated' in an 'inner circle' style by at least one former moderator. IMO this is something we should avoid at all costs if we want more people joining the party.
     
    Not for development but to estimate whether it's worth supporting a device. If price is too high we run in the same situation as with 'dev samples only' boards like Roseapple Pi. IMO that's pretty important and was covered by the sentence 'Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks)' in post #1.
     
    Important if we want to discuss use cases. I'm biased (since I don't care at all about this Multimedia stuff) but I'm also aware that my use cases aren't those of the majority of people later using the device. That was 'RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth)' in post #1.
  4. Like
    Myy reacted to Xalius in RK3328 Kernel   
    Do not forget to actually lift the BT reset GPIO, on the Pine64 that is done via 'rfkill unblock all' or 'rfkill unblock xxx' otherwise the uart of the BT part will not answer and you just get a 'sync timeout'  from the firmware loader...
  5. Like
    Myy reacted to Xalius in RK3328 Kernel   
    Pine64 uses the same RTL8723BS module and we got BT working more or less reliably now. There are some versions of the BT firmware loader floating around (Iwfinger, hadess, ...) but NextThingCo seems to have the latest version for the RTL8723DS, which also works with CS and BS though...
     
    Check out:
     
    https://github.com/ayufan-pine64/linux-build/blob/master/Makefile#L49 - build the rtk_hciattach firmware loader, loads FW over UART and attaches it to the BT stack
     
    https://github.com/ayufan-pine64/linux-build/tree/master/package/root/lib/firmware/rtlbt - needed firmware files
     
    https://github.com/ayufan-pine64/linux-build/blob/master/package/root/etc/systemd/system/rtk-hciattach.service - systemd service
     
     
  6. Like
    Myy got a reaction from Tido in RK3328 Kernel   
    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 ?
  7. Like
    Myy got a reaction from lafalken in RK3328 Kernel   
    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
  8. Like
    Myy got a reaction from tkaiser in RK3328 Kernel   
    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
  9. Like
    Myy reacted to TonyMac32 in RK3328 Kernel   
    Thanks tkaiser, I obviously didn't look around hard enough.  :-/
     
    *update*
     
    wifi firmware added, kernel config updated, and device tree patched.  Anyone using 4.12 should be able to happily use wifi.
     
    4.11 may not be worth the effort due to it not having any driver support for the rtl8723bs.  You would have to patch in the driver/etc.
  10. Like
    Myy got a reaction from traumfaenger in RK3328 Kernel   
    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.
  11. Like
    Myy got a reaction from TonyMac32 in RK3328 Kernel   
    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.
  12. Like
    Myy reacted to tkaiser in RK3328 Kernel   
    --> https://github.com/Miouyouyou/MyyQi
×
×
  • Create New...