Jump to content

hexdump

Members
  • Posts

    457
  • Joined

  • Last visited

Reputation Activity

  1. Like
    hexdump got a reaction from stonetv in Armbian on B860AV2.1-M with S905L3-B   
    looks like the s905l3 is another of those amlogic socs where they did reduce the hw even further to bring down the price - for the s905l2 this one helped for me: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av8/dtb/meson-gxl-s905l2-x7-5g.dts but your trace looks different ... good luck for finding out what they changed this time
     
    p.s.: it looks like the above change is needed there too, but looks like they even crippled the vpu and/or hdmi hw as well ...
  2. Like
    hexdump got a reaction from jock in Cards on the table: Which boxes have working WiFi?   
    the ssv6x5x chips are not supported in mainline or with anything else than the meanwhile quite dated rockchip legacy tree and as the existing sources and docs for them are so bad (and i guess the hardware design as well) they most probably never will be supported in mainline.
     
    mxq boxes can have everything in them: they exist with allwinner, amlogic and rockchip socs in them combined with a large variety of wifi chips. tv boxes can be fun to play with but never expect anything to be too well - you might win the lottery and get a really good one with supported wifi,good case, power supply and heat sink etc. and you can end up on the other end where the 4gb/32gb emmc box you bought in reality is just a1gb/8gb nand box with unsupported wifi there the first components fall off the board after a few weeks. i think the second option get more and more likely nowadays
     
    enjoy those toys if you run across them, but better do not trust in or rely on them ...
     
    best wishes - hexdump
  3. Like
    hexdump reacted to lanefu in Armbian the Virtual Machine   
    quick update.. armbian now produces a qcow2 image for the virtual-qemu build...

    I installed virgl but still working on a script to launch...  
  4. Like
    hexdump got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    @Dragao - dying emmc is something which happens from time to time with tv boxes - i had it on an amlogic box and i think @jock and @fabiobassa can sing a song about this topic too ... i think tv boxes are sometimes assembled from very low quality components to push prices down ...
  5. Like
    hexdump got a reaction from Jeremiah Cornelius in Release Announcement: TWO New, Community Unofficial Armbian MAINLINE Desktop Images for Khadas VIM3 Pro   
    @Jeremiah Cornelius - for your lightdm issue, maybe give the slick greeter for lightdm a try - it fixed my problems with non working lightdm on 32bit arm - might be worth a try
     
    best wishes and good luck - hexdump
  6. Like
    hexdump got a reaction from tommy in CSC Armbian for RK3318/RK3328 TV box boards   
    @elbuit - if nothing else works, this should usually work to get the device tree from a running android: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
     
    best wishes and good luck - hexdump
  7. Like
    hexdump got a reaction from ArkhanLK in CSC Armbian for RK322x TV box boards   
    @jock - just in case: the slick greeter is also working well on armhf
  8. Like
    hexdump got a reaction from jock in CSC Armbian for RK322x TV box boards   
    @jock - just in case: the slick greeter is also working well on armhf
  9. Like
    hexdump got a reaction from lanefu in Armbian the Virtual Machine   
    @lanefu - as you mentioned the m1 mac: there is a very nice brew package around, which gives you a qemu there which even sends opengl via virgl and angle to the m1 gpu - not the fastest in the world, but better and more cpu saving than software rendering - https://github.com/knazarov/homebrew-qemu-virgl
  10. Like
    hexdump got a reaction from SteeMan in A really dumb question Amlogic Vs RockChip vs Allwinner   
    @jock - i think amlogic (the company) still is not very good regarding open source, but at least linux mainline is quite useable on their chips
     
    the emmc clk pin trick works for amlogic too (if one finds it ) and wiping the emmc results in a boot from sd card ... the main problem is that the legacy u-boot reads its dtb from a later partition on the emmc and fails if it cannot find it - this is a problem if one for instance fdisk's and mkfs the emmc: the u-boot itself can still be intact, but it is bricked as it can no longer find its dtb (this is why the balbes150 amlogic images always kept 700mb and later more of the emmc in place when installing onto emmc to avoid overwriting this sensitive information) ... putting a mainline u-boot on amlogic boxes is possible but due to the complex boot structure and the required fitting blobs way more complicated than on rockchip and allwinner ... in summary: if amlogic then best is a properly supported sbc (odroid etc.) - unsupported stuff like tv boxes can result in quite a bit of extra work and unwanted surprises with those socs
  11. Like
    hexdump reacted to tripole in Chainloaded uboot images for amlogic   
    @hexdump
     
    Thank you for your work on these chain loaders. It has enabled me to do something I have wanted for a long time.
     
    I have your g12a-u-boot.bin (renamed to u-boot.ext) running on my Ugoos AM6 plus, in a multi-os boot setup, with all OSes installed on the SD (utilizing the vendor boot for the all boot stages except the last, which is in u-boot.ext). Currently, I can boot into Armbian Meson64 (Hirsute flavor, built in QEMU based on the rootfs file tree), Manjaro ARM (for VIM3/Ugoos, copied from distro image), and a Armbian Buster mini as rescue (also from QEMU/rootfs).
     
    By writing the entries in extlinux.conf according to the correct menu syntax (inferred from e.g. pxe_utils.c in u-boot source, see below) one can select which kernel+initrd+dtb to load, and which root file system to mount. (One has to be quick at the second prompt to make the OS selection. This prompt appears at the sysboot stage, after u-boot autoload has timed out. Perhaps the sysboot timeout can be extended a bit? Edit: The TIMEOUT keyword does not seem to take effect.)
     
    On all the OSes I have kept their original /boot dir and then added a new mount point /boot_FAT32 where the first FAT32 partition is located (with extlinux.conf, kernels+initrds+dtbs, and u-boot.ext), and updated the local /etc/fstab accordingly. Then it is simple to propagate the changes made to /boot under a running OS also to the boot partition. The SD layout/geometry is essentially: From the first available sector (2048, no gap needed) and 300M onwards; the kernel+initrd+dtbs and extlinux.conf stuff on a FAT32 partition. The follows, after perhaps a common swap partition, a number of ext4 partitions with the different OSes.
     
    Here is what the extlinux.conf can look like
     
     
    P.S. I know it is hard to compile these loaders correctly: From u-boot-amlogic (custodian) have have managed to compile, starting with different defconfigs, chain loaders that boot but with; no (HDMI) screen, green screen (several flavors), and indeed, purple-pinkish screen, but not one single working properly. Doh.
  12. Like
    hexdump reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    ­DISCLAIMER (PLEASE READ): everything you can find in this thread (binaries, texts, code snippets, etc...) are provided AS-IS and are not part of official Armbian project. For this reason not people from Armbian project nor myself are responsible for misuse or loss of functionality of hardware.

    Please don't ask about support or assistance in other non-community forums nor in the official Armbian github repository, instead post your questions in this thread, in the TV Boxes forum section (hardware related) or in the Peer-to-peer support section (general linux/software related).

    Thank you!
     
    This thread is to give stable and mature long-term range support to rk3318/rk3328 found in many tv boxes in Armbian project as Community Supported Configuration (CSC).
    The current work is mainlined into Armbian project, but your mileage may vary; most recent developments live on my personal fork on github -> here <-
     
    Important notes: is just a personal opinion, but apparently widely supported, that rk3318 chip is not an official rockchip part. They probably are scrap rk3328 parts which have not passed conformance tests but are sold anyway to tv boxes manufacturers. They don’t reach the same operating frequency of the rk3328, have much higher leakage currents (and thus higher temperatures) and often the boards they are installed on are low quality with low quality components, in fact a very very common issue is the eMMC failure due to bad parts and bad soldering. So said, I personally suggest not to buy any rk3318 tv box, but instead find a properly supported SBC (Single Board Computer) if you need a reliable product. In the unfortunate case you already have such product, this thread may help you have some fun with them.
     
    What works:
        • Works on RK3318 and RK3328 TV boxes with DDR3 memories
        • Mainline u-boot
        • Mainline ATF provided as Trusted Execution Environment
        • All 4 cores are working
        • Ethernet
        • Serial UART (configured at stock 1.5Mbps)
        • Thermals and frequency scaling
        • OTG USB 2.0 port (also as boot device!)
        • EHCI/OHCI USB 2.0 ports and XHCI USB 3.0 ports
        • MMC subsystem (including , SD and sdio devices)
        • Hardware video acceleration (fully supported via RKMPP on legacy kernel, support via hantro and rkvdec kernel driver on mainline)
        • Various WIFI over SDIO are supported
        • Full acceleration on legacy kernel and mainline kernel
        • U-boot boot order priority: first the sdcard, then the USB OTG port and eventually the internal ; you can install u-boot (and the whole system) in the internal and u-boot will always check for images on external sdcard/USB first.
     
    Unbrick:
    Technically, rockchip devices cannot be bricked. If the internal flash does not contain a bootable system, they will always boot from the sdcard. If, for a reason, the bootable system on the internal flash is corrupted or is unable to boot correctly, you can always force the maskrom mode shorting the clock pin on the PCB. The procedure is explained here for rk322x, but for rk3318/28 is the same.

    In most of the rk3318/28 boards, shorting the clock pin is difficult or impossible because eMMC are BGA chips with no exposed pins. Pay double attention when burning something on the internal flash memory and always test first the image booting from the sdcard to be sure it works before burning anything in internal flash.
     
    This is a list of posts where forum users have been able to spot the eMMC clock pin to trigger the maskrom mode:
    H96 Max+ (board signature: RK3318_V1.4) by @Gausus X88 PRO 10 (board signature: X88_PRO_B) by @mathgaming Ninkbox N1 Max RK3318 by @enigmasphinx  
     
    Partecipation and debugging:
    If you want to partecipate or need help debugging issues, do not hesitate to share your experience with the installation procedure of the boxes.
    In case of issues and missed support, provide as many as possible of these things is very useful to try and bring support for an unsupported board:
     
    some photos of both sides of the board. Details of the eMMC, DDR and Wifi chips are very useful! upload the device tree binary (dtb) of your device. We can understand a lot of things of the hardware from that small piece of data; and alternative is a link to the original firmware (you can do a full backup with the Multitool); dmesg and other logs (use armbianmonitor -u that automatically collects and uploads the logs online) attach a serial converter to the device and provide the output of the serial port;  
    Multimedia:
    Mainline kernel: 3D acceleration is provided by Lima driver and is already enabled. Hardware video decoding: https://forum.armbian.com/topic/19258-testing-hardware-video-decoding-rockchip-allwinner/ Legacy kernel: If you need multimedia features, like OpenGL/OpenGL ES acceleration, hardware accelerated Kodi, ffmpeg and mpv you can take a look to this post  
    Installation (via SD card):
    Building:
    You can build your own image follow the common steps to build armbian for other tv boxes devices: when you are in the moment to choose the target board, switch to /TVB/ boards and select "rk3318-box" from the list.
       
    Prebuilt images:
    Archived images - built by Armbian servers and GPG-signed: https://imola.armbian.com/dl/rk3318-box/archive/ Nightly stables - built from trunk by Armbian servers and GPG-signed: https://github.com/armbian/community Stables provided by me (unsigned): https://users.armbian.com/jock/rk3318/  
    Multitool:
    Multitool - A small but powerful image for RK3318/RK3328 TV Box maintenance. Download it from here  
    Quick installation instructions on eMMC:
    Build or download your preferred Armbian image and a copy of the Multitool; Burn the Multitool on an SD card; once done, place the Armbian image in images folder of the SD card NTFS partition; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; OPTIONAL: you can do a backup of the existing firmware with "Backup flash" menu option; Choose "Burn image to flash" from the menu, then select the destination device (usually mmcblk2) and the image to burn; Wait for the process to complete, then choose "Shutdown" from main menu; Unplug the power cord and the SD card, then replug the power cord; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt. On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run rk3318-config to configure the board specific options Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed!  
    Despite the procedure above is simple and reliable, I always recommend to first test that your device boots Armbian images from SD Card.
    Due to the really large hardware variety, there is the rare chance that the images proposed here may not boot. If a bad image is burned in , the box may not boot anymore forcing you to follow the unbrick section at the top of this post.
     
    Quick installation instructions to boot from SD Card:
    If you are already running Armbian from eMMC, skip to the next step. Instead if you are running the original firmware you need to first erase the internal flash; to do so download the Multitool, burn it on an SD Card, plug the SD Card and power the TV Box. Use "Backup flash" if you want to do a backup of the existing firmware, then choose "Erase flash" menu option. Build or download your preferred Armbian image; Uncompress and burn the Armbian image on the SD Card; Plug the SD Card in the TV Box and power it on; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run rk3318-config to configure the board specific options Run armbian-config to configure timezone, locales and other personal options, or also to transfer the SD Card installation to internal ; Congratulations, Armbian is running from SD Card!  
    Tutorial - How to install Armbian on your TV Box (by @awawa) :
    https://www.hyperhdr.eu/2022/01/tv-box-mania-i-part-x88-pro-10.html
    A note about boot device order:
    With Armbian also comes mainline U-boot. If you install Armbian, the bootloader will look for valid bootable images in this order:
    External SD Card External USB Stick in OTG Port Internal  
    The Multitool does not boot / How to burn image directly on eMMC:
     
    Some boards have the sdcard attached to an auxiliary (called also sdmmc_ext or external) controller which is not the common one.
    Forum findings declare that those boards are not able to boot from sdcard with stock firmware and they neither do in maskrom mode: the stock firmware always boots even if you put the multitool on sdcard.
     
    In such case, burning images directly on eMMC is the only way to have a working Armbian installation.
    You can follow these instructions by @fabiobassa to burn images directly on eMMC:
     
    https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=130453
     
    Notes and special hardware:
    Script to change DDR memory frequency here Wireless chip AP2734, SP2734, HY2734C and similars: they are clones of AmPAK AP6334 which is combo wifi + bluetooth of broadcom BCM4334/B0 chips. You may need a special nvram file, instructions by @paradigman are here  
    Critics, suggestions and contributions are welcome!
     
    Credits:
    @fabiobassa for his ideas, inspiration, great generosity in giving the boards for development and testing. The project of bringing rk3318 into armbian would not have begun without his support! @hexdump for his precious support in early testing, ideas and suggestions
    @MX10.AC2Nfor his patience in testing mxq-rk3328-d4 board support
    All the rockhip64 maintainers at Armbian project who have done and do most of the work to support the platform
     
     
  13. Like
    hexdump reacted to XFer012 in OrangePi Zero2 - Allwinner H616   
    Ok, so let's see the steps I followed.
     
    1. Installed Armbian Unstable for OrangePi Zero2:
    https://imola.armbian.com/dl/orangepizero2/nightly/Armbian_21.05.0-trunk.77_Orangepizero2_hirsute_edge_5.11.11.img.xz
     
    2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
    ethtool -s eth0 speed 100 duplex full autoneg off
     
    3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
    https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/download/5.11.0-rc1-stb-616%2B/5.11.0-rc1-stb-616+.tar.gz
     
    4. Extracted the various parts and fixed the symlinks:
    Image -> Image-5.11.0-rc1-stb-616+
    uInitrd -> uInitrd-5.11.0-rc1-stb-616+
    dtb -> dtb-5.11.0-rc1-stb-616+
     
    5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
     
    6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
    [ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk  
  14. Like
    hexdump got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    @XFer012 - in case you run into any problems while trying get it working based on my notes, just open an issue on that git repo and i may try to help you to resolve them
     
    good luck - hexdump
  15. Like
    hexdump got a reaction from gounthar in OrangePi Zero2 - Allwinner H616   
    @XFer012 - you can also build a kernel directly on the box - takes a bit of time, but works well - i'm building all my arm kernels on arm devices
  16. Like
    hexdump got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    @XFer012 - i think the best approach might be to build your own kernel and then you can change the original dts and dtsi files directly (with labels etc.) instead of dealing only with the compiled versions ... maybe my notes from playing around with the h616 on tv boxes might be helpful for you: https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel
     
    i also built a kernel with working usb and early hdmi (based on the code of @jernej): https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/tag/5.11.0-rc1-stb-616%2B - i did not test it on a orange pi zero 2 myself (as i only tried it on a h616 tv box), but at least i tried to keep the opi zero 2 dtb up to date, so it might just work
     
    all that is not a perfect solution, but maybe its helpful for you on your way
     
    good luck and best wishes - hexdump
  17. Like
    hexdump got a reaction from Dan MacDonald in Jetson Nano   
    just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3
     
    so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)
     
    i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce
     
    all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs
  18. Like
    hexdump got a reaction from gounthar in Jetson Nano   
    just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3
     
    so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)
     
    i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce
     
    all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs
  19. Like
    hexdump got a reaction from gounthar in 8Gb RAM in a TV Box   
    @gounthar - i think you do not need esxi as kvm and maybe xen (and some other free hypervisors) are working quite well on aarch64 already ...
  20. Like
    hexdump got a reaction from lanefu in Chainloaded uboot images for amlogic   
    @lanefu - for those amlogic tv boxes chainloading u-boot means the old legacy u-boot on the box is loading a mainline u-boot.bin (which has nice features like extlinux.conf support and allocates less memory for itself) which is then loading the kernel
     
    @SteeMan - this looks a bit like this box has a non standard mmc setup which might be not so easy to track down (one would need to extract the android dtb from the box - see: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy and then the mmc entries should be compared to the android dtbs of other boxes where emmc works - here is for instance my h96max-x3 android dtb: https://github.com/hexdump0815/linux-mainline-and-mali-amlogic-kernel/blob/master/misc.aml/dtb/meson-sm1-h96max-x3.dts.android - this is a big puzzle and a lot of trial and error might be required without the guarantee to get it working)
     
    the patch is to remove some code which will not work in our scenario (getting linux working on it) - it looks like the mainline u-boot code for the s905x3 i used as a base was only done for android which has a different partition (+table) setup than what we plan to use
     
    the uEnv.txt file is read before extlinux.conf, so things can be set there which partially cannot be defined in the extlinux.conf (which is quite limited) - in armbian that file usually is called armbianEnv.txt i think, so you should maybe adjust the filename to be in sync with armbian if you want to get it closer to a standard armbian setup
     
    just an idea: you might also try the newer u-boot 2021.01 or soon the upcoming 2021.04, but i think nothing really changed in there for amlogic
     
    @lcapriotti - it would be very helpful if you could find out how you got it to work on your box - this might getting this resolved easier for @SteeMan maybe
     
    good luck and best wishes - hexdump
  21. Like
    hexdump got a reaction from manuti in Jetson Nano   
    did anyone already test to boot this image on the 2gb model of the jetson nano? i just tried it and it does not boot - the nano already has the new u-boot in the spi ... looks like i have to connect a serial console when i find some time
  22. Like
    hexdump got a reaction from Piezo in CONFIG_RT_GROUP_SCHED=y harmuflull for real time applications   
    @Piezo - did you already try "sysctl -w kernel.sched_rt_runtime_us=-1" - it works well for me for jackd ...
     
    best wishes and good luck - hexdump
  23. Like
    hexdump got a reaction from Seth in CSC Armbian for RK322x TV box boards   
    @Seth - it might be good to get the dtb from the box - in case no other way works, this approach so far worked for nearly every android tv box for me: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
     
    good luck - hexdump
  24. Like
    hexdump got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    @Seth - it might be good to get the dtb from the box - in case no other way works, this approach so far worked for nearly every android tv box for me: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
     
    good luck - hexdump
  25. Like
    hexdump reacted to jernej in OrangePi Zero2 - Allwinner H616   
    If someone has too much time, here is extremely basic and hackish H616 display driver (HDMI up to 1080p only): https://github.com/jernejsk/linux-1/tree/h616-hdmi (take branch as-is, USB works too)
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines