JMCC

Members
  • Content Count

    592
  • Joined

  • Last visited


Reputation Activity

  1. Like
    JMCC got a reaction from Da Xue in Librecomputer Renegade RK3328   
    So the Media Script is finally released:
     
  2. Like
    JMCC reacted to TonyMac32 in Improve 'Support over Forum' situation   
    I see some structural challenges here.  One is a perceived hierarchy perhaps keeping some people from mentioning issues (to be honest we already have that problem, I've had small issues in images for months before someone pointed it out).  If we take this route, then the forum has to be as open as possible to general user complaints.  Restricting access results in a shrinking of community in general, it's a difficult position because in order to grow the community you have to allow "know-nothings" to ask questions and hopefully become "know-somethings".  We also need to find a good way to appeal to a more diverse user base, application wise. 
     
    People like @Larry Bank and @sgjava have done some great work, but our willingness (and ability) to support ends with server-type environments (nothing wrong with this, but it is a *very* limited niche of people who can contribute to that specific task thing)
     
    @JMCC is doing great work with media, if we can roll at least some of what he's doing into the build script it would be fantastic (I was thinking we should package his scripts as part of a board or family specific armbian-config menu)
     
    So we have the groundwork for IoT and Multimedia applications, which will make our little Linux project more interesting for the general public, especially if we can make these things somewhat standard, we get more users.  from those users, some programmers/maintainers/mods/etc will show up.  The issue is the age old one of humanity:  Talent and interest are hard to find together. If the vendors are not willing to help, despite the value, then we need to move an insane number of people through the forums to snag ones that are able and willing to contribute.
     
    I think we do need to approach the "slimming down" of our boards a bit more carefully.  This is something along the lines of @tkaiser's comments about this being a project for us, with our help to everyone else being a happy side-effect.  If we are not overwhelmed, we make better things, the community benefits.  If a high-level user wants their board supported badly enough, they will work to support it (Me with Tinker Board)  We need to add a "maintainers" list or something similar, this is for one simple reason:  boards with no maintainer need to be put on probation.  A stronger definition of individual roles (not in a leadership sense, just in a contribution sense) will help as well I think. 
    If a board has no maintainers and no vendor support, it should be "CSC'd", with a list on the website with "looking for maintainers"  I would propose we not make images for those boards available on the download page, allow people to build them if they want.  That alone filters who would be asking questions.
     
    So, for boards:
     
    Each board entry should include 2 additional fields:
    Maintained-by  (Member or members) Vendor-supported (Does the Vendor give Armbian anything more than just a couple boards?  I include technical support here) So Tinker Board and Le Potato would look like:
    supported-by: tonymac32 vendor-supported: yes  (or we could make tiers, everything from boards on demand, technical support, direct code contribution, money)  
    For Member-contrubtors:
     
    boards hosting documentation etc So Igor (sorry if I massively under-represent:
     
    Build Script Author (obviously multiple people can have each tag) Web Admin Build Hosting Family-Allwinner Family-Freescale Documenter etc I can expand on this later in a specific thread since it covers a wide topic matter.
  3. Like
    JMCC reacted to TonyMac32 in RK3288 Media Script (TinkerBoard)   
    Pssssst:
     

     
    So, this has @Myy's work with the patchset that got dropped on the mailing list for vdec, I've gotten everything building properly (minus a wireless driver and we don't have 1.7 and 1.8 GHz opps)
     
    I ran the media script ans installed everything.
     
    I'm watching a 1080p mp4 at fullscreen, here is my armbianmonitor -m:
     
    Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 05:41:25: 1608MHz 1.00 20% 3% 16% 0% 0% 0% 51.7°C 0/11 05:41:30: 1608MHz 0.92 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:35: 1608MHz 0.92 21% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:40: 1608MHz 0.93 19% 3% 15% 0% 0% 0% 51.2°C 0/11 05:41:45: 1608MHz 0.93 20% 3% 17% 0% 0% 0% 50.4°C 0/11 05:41:50: 1608MHz 0.94 21% 5% 16% 0% 0% 0% 51.7°C 0/11 http://ix.io/1zbd
     
    As for functionality, gstreamer does not seem to want to work, so I would guess the vdec isn't operational yet, or something isn't quite right.  In any case, there is hope, perhaps.  ;-)
  4. Like
    JMCC reacted to Myy in RK3288 Media Script (TinkerBoard)   
    Be sure that ROCKCHIP_MPP is enabled in the kernel configuration. It's not automatically set up.
    The driver is available in "Device Drivers -> Staging drivers -> Rockcihp MPP".

    Generally you get some warning, like for the Realtek staging driver, telling you that the code isn't that great, etc...
  5. Like
    JMCC reacted to Lev Lybin in [Development] RK3399 media script   
    Hello.
     
    Linux rockpro64 4.4.167-rockchip64 #12 SMP Wed Jan 23 00:26:14 CET 2019 aarch64 aarch64 aarch64 GNU/Linux
    media script installed. System was switched to nigthly.
     
    ls -l /dev/mali*
    ls: cannot access '/dev/mali*': No such file or directory
  6. Like
    JMCC got a reaction from Dante4 in [Development] RK3399 media script   
    Good to see that you like experimenting. As I said, if you use as a base anything other than Armbian Bionic Default image, results can be unpredictable. I invite you to use the build script to make a proper image, or wait until it is publicly released, if you want to take advantage of all the possibilities of the script.
  7. Like
    JMCC got a reaction from Tommy21 in RK3328 Media Script (Rock64, Renegade)   
    Yes, actually "Desktop acceleration" means here "Desktop GPU integration". Ironically, when using the X server, that very often means that the Desktop will be slower and laggier when "accelerated". It even happens on my desktop Intel Core i7 computer . It's a fault of the terribly outdated X protocol; just imagine all Windows 10 graphic stack was running on top of the Windows 3.1 graphic system: that's something similar to what we are doing today in Linux.
     
    That is precisely the reason why Wayland appeared. Now it is getting more mature, and is without any doubt the future for Linux desktop in general. And even more in embedded systems, which don't support the full OpenGL API, but only a reduced version (OpenGL for Embedded Systems), designed basically to run Android and similar OSes. On the other hand, Wayland is much more similar to the Android graphics API, which is what those SoC's are designed for.
     
    So, in short: X server sucks, even more when it comes down to acceleration, and even more when you want to perform that acceleration with a device that only supports OpenGL-ES (i.e. a Mali GPU). Right now, I'm working on Amlogic X acceleration, and I'm getting more and more convinced that we need to move to Wayland if we want to get serious about accelerated desktop.
  8. Like
    JMCC reacted to chwe in RockPi 4b 'board bring up'   
    As promised we prepare a little patch for our RockPi... Since it's a while since we created our branch it makes sense to sync our branch with upstream. with:
    git fetch upstream && git merge upstream/master && git push (followed by your username & password to keep the branch updated)
     
     
     
    It's not allays that much.. but it's worth to do it before you start with development. according to radxas device tree the RockPI has two configurable LEDs.
    https://github.com/radxa/kernel/blob/c26d93d001494bbeec86d62e9954b932f254776c/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L271-L284
    gpio-leds { compatible = "gpio-leds"; user-led1 { gpios=<&gpio3 28 GPIO_ACTIVE_HIGH>; linux,default-trigger="heartbeat"; default-state = "on"; }; user-led2 { gpios=<&gpio3 29 GPIO_ACTIVE_HIGH>; linux,default-trigger="heartbeat"; default-state = "on"; }; If we don't know what we can do with those we can look into documentation:
    https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt
    and from there:
    https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/common.txt
     
    you see we've quite some options to set our LEDs. At the moment there's different usage in Armbian but I prefer to have one LED always on, ant the other one in heartbeat (some indication in case the board crashes). We could also set one LED to disk-activity but as an example this should do the job. A bit a more useful name for the nodes could also help who knows which led is which if they're named led1 and led2...
    so first make sure we're on the right branch and have create patch properly set nano default-config.conf: (cause we build dev image set EXPERT="yes")
    CREATE_PATCHES="yes" # wait that you make changes to uboot a$ BUILD_ALL="no" # cycle through available boards and ma$ # set KERNEL_ONLY to "yes" or "no" to b$ BSPFREEZE="" # freeze armbian packages (u-boot, kern$ INSTALL_HEADERS="" # install kernel headers package LIB_TAG="rockpi_tutorial" # change to "branchname" to use$ CARD_DEVICE="/dev/mmcblk0" # device name /dev/sdx $ EXPERT="yes"  
    if we now compile for our board we will be prompted to make changes once for ATF (we don't, our little change has nothing to do with ATF) u-boot (we could.. but heartbeat doesn't make sense here.. we want it once the board is booted fully up) and kernel.
    ATF:
    [ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip ] [ warn ] Press <Enter> after you are done [ waiting ] [ warn ] No changes found, skipping patch creation u-boot:
    [ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ] [ warn ] Press <Enter> after you are done [ waiting ] okay.. it might make sense to fix the RockPi DT in u-boot as well... That's how the DT looks at the moment (armbian/build/cache/sources/u-boot-rockchip64/rockchip-master/arch/arm/dts/rk3399-rockpi4b.dts):
    as you can see.. wrong gpios and a naming which is IMO also not satisfying... Let's change it to:
    as you can see, we didn't use heartbeat yet (and the gpios are also wrong).. and now for the kernel:
    [ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ] [ warn ] Press <Enter> after you are done [ waiting ] /home/chwe/armbian/build/cache/sources/linux-rockchip64/4.20.0-1083-ayufan/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts
    keep in mind.. we've to change it in the LED node and the pinctrl node..
     
    in build/output/patch we get two patches:
    u-boot-rockchip64-dev.patch:
    and for the kernel: (kernel-rockchip64-dev.patch)
    now let's boot the image.. The green led is bright as hell.. and the red one shows heartbeat..  annoying.. let's change them vice versa and hope that everything was right..
    as long as we keep the patches in output without renaming them, they get applied in the next run we build an image.. and the can "edit" them. so it's just change gpios in the DT..
    hmm seems that now both LEDs are always on.. so something is wrong here.. either the DT from the BSP kernel isn't correct.. or it doesn't work..
    means, we've no idea how to trigger the green LED. But we know how to trigger the RED LED. Now let's write a patch which only triggers the RED LED and erase the other LED node cause we've no clue how to trigger it.
    U-boot:
    diff --git a/arch/arm/dts/rk3399-rockpi4b.dts b/arch/arm/dts/rk3399-rockpi4b.dts index 5d73ce5..5574e9b 100644 --- a/arch/arm/dts/rk3399-rockpi4b.dts +++ b/arch/arm/dts/rk3399-rockpi4b.dts @@ -65,14 +65,9 @@ status = "okay"; compatible = "gpio-leds"; - power-led { - label = "power"; - gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>; - }; - - standby-led { - label = "standby"; - gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>; + system-status { + label = "status"; + gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>; }; }; Kernel:
    diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts index 7f10da2a8..1d4721dcc 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts @@ -140,20 +140,15 @@ }; leds { + status = "okay"; compatible = "gpio-leds"; pinctrl-names = "default"; - pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>; - - work-led { - label = "work"; - default-state = "on"; - gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>; - }; + pinctrl-0 = <&status_led_gpio>; - diy-led { - label = "diy"; - default-state = "off"; - gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>; + system-status { + label = "status"; + gpios = <&gpio3 29 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "heartbeat"; }; }; @@ -643,12 +638,8 @@ }; leds { - work_led_gpio: work_led-gpio { - rockchip,pins = <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>; - }; - - diy_led_gpio: diy_led-gpio { - rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; + status_led_gpio: status_led_gpio { + rockchip,pins = <3 28 RK_FUNC_GPIO &pcfg_pull_none>; }; }; Now since we know that our patch works, let's give it a meaningful name and move it in the correct folder. the patchname makes it easy for you.. and rename it to a meaningful name. (build/patch/kernel/rockchip64-dev & build/patch/u-boot/u-boot-rockchip64-dev). For the beginnings fix-rockpi4b-led.patch sounds ok-ish. We've to check if those new patches apply correctly after moving to the right folder:
    uboot:
    [ o.k. ] * [l][c] add-board-renegade.patch [ o.k. ] * [l][c] add-board-rockpi4b.patch [ o.k. ] * [l][c] add-missing-SDMMC0_PWR_H-rockpro64.patch [ o.k. ] * [l][c] add-u-boot-delay-rockpro64.patch [ o.k. ] * [l][c] board-renegade-updates.patch [ o.k. ] * [l][c] enable-DT-overlays-support.patch [ o.k. ] * [l][c] fix-rockpi4b-led.patch and kernel:
    [ o.k. ] * [l][c] RK3328-enable-1512mhz-opp.patch [ o.k. ] * [l][c] RK3399-enable_1.5_2.0_ghz_cpufreq_opp.patch [ o.k. ] * [l][c] add-board-rockpi4b.patch [ o.k. ] * [l][c] add-fusb30x-driver.patch [ o.k. ] * [l][c] board-rockpi4-dts-wip-fixup.patch [ o.k. ] * [l][c] firefly-rk3399-enable-wifi.patch [ o.k. ] * [l][c] fix-rockpi4b-led.patch [ o.k. ] * [l][c] fix-rockpro64-emmc.patch [ o.k. ] * [l][c] fix-spi1-flash-speed.patch [ o.k. ] * [l][c] general-add-overlay-compilation-support.patch [ o.k. ] * [l][c] general-increasing_DMA_block_memory_allocation_to_2048.patch [ o.k. ] * [l][c] general-packaging-4.17-dev.patch [ o.k. ] * [l][c] general-rockchip-overlays.patch [ o.k. ] * [l][c] nanopi4-dts.patch [ o.k. ] * [l][c] orangepi-rk3399-dts.patch [ o.k. ] * [l][c] renegade-add-HDMI-nodes.patch [ o.k. ] * [l][c] renegade-enable-usb3.patch [ o.k. ] * [l][c] rk3328-sd-drive-level-8ma.patch [ o.k. ] * [l][c] rk3399-sd-drive-level-8ma.patch [ o.k. ] * [l][c] timekeeping32-tweaks-for-4.20.y.patch [ o.k. ] * [l][c] unlock-temperature.patch seems that everything is okay. So it's time to bring them back to armbian. Let's check our repo with git status:
    chwe@chwe-HP:~/armbian/build$ git status On branch rockpi_tutorial Your branch is up to date with 'origin/rockpi_tutorial'. Untracked files: (use "git add <file>..." to include in what will be committed) patch/kernel/rockchip64-dev/fix-rockpi4b-led.patch patch/u-boot/u-boot-rockchip64-dev/fix-rockpi4b-led.patch nothing added to commit but untracked files present (use "git add" to track) there are our two new patches.. lets add and commit (with a meaningful commit message) them with: git add -A && git commit followed by git push
    chwe@chwe-HP:~/armbian/build$ git push Username for 'https://github.com': chwe17 Password for 'https://chwe17@github.com': Counting objects: 9, done. Delta compression using up to 8 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 1.50 KiB | 1.50 MiB/s, done. Total 9 (delta 5), reused 0 (delta 0) remote: Resolving deltas: 100% (5/5), completed with 4 local objects. To https://github.com/chwe17/build.git a156fddf..bb63ed6d rockpi_tutorial -> rockpi_tutorial https://github.com/chwe17/build/tree/rockpi_tutorial
    our features branch is now one commit ahead of armbian master and we can create a PR against armbians master:
    https://github.com/armbian/build/pull/1236
     
    You see, just adding something simple like triggering an LED to heartbeat can give you some headache.. and takes more time that we expected cause the second LED didn't behave as we thought. But finally, we got it.
     
    Edit: this post was written 'on the fly'.. If something isn't clear, just let me know.. and I'll try to explain it better.
    Edit2: cause 'we know' that @TonyMac32 does a lot with RK boards we request him as reviewer.
  9. Like
    JMCC got a reaction from xorro in Librecomputer Renegade RK3328   
    So the Media Script is finally released:
     
  10. Like
    JMCC got a reaction from TonyMac32 in Le Potato / C2 / K2 4.19 LTS testing thread   
    Aha, I got it. We were missing the firmware.
     
    Here is the output of mpv. Notice the line confirming the use of hardware decoding:
     
    Here is a ffmpeg output:
     
    Though, performance is far from being good yet. Let's see if I can find some time to package everything I have so far into a script, for others to test too.
     
    I'm attaching the firmware here. @Igor I'm going to add it to the armbian/firmware repo.
    meson-firmware.tgz
  11. Like
    JMCC got a reaction from beautynow in Le Potato / C2 / K2 4.19 LTS testing thread   
    Hello. I'm still testing, I want to post a howto/script when I have some more results.
  12. Like
    JMCC got a reaction from manuti in X2go an armbian   
    Depends on your board. If it's armhf, you can use Raspbian Stretch repos, otherwise you may need to build. I recommend to build from source in any case, I did it once and didn't take long.
     
    https://wiki.x2go.org/doku.php/wiki:repositories:raspbian
  13. Like
    JMCC got a reaction from balbes150 in Le Potato / C2 / K2 4.19 LTS testing thread   
    Hello. I'm still testing, I want to post a howto/script when I have some more results.
  14. Like
    JMCC got a reaction from zogu in Armbian for TV box rk3328   
    These are the areas that need more testing:
    Using MPV and Gstreamer video players, and reporting performance. We need to choose which of the two will be the default player in the Armbian multimedia implementation. Performance of Chromium streaming, playing unencrypted videos (e.g. Youtube) at different resolutions, and also DRM encrypted videos (Netflix, Amazon Prime Video, etc.). General desktop experience, when using regular desktop apps (text editors, pdf readers, libreoffice, etc). Thx. 
  15. Like
    JMCC reacted to Igor in Le Potato / C2 / K2 4.19 LTS testing thread   
    https://github.com/armbian/documentation/commit/63c02d26ceca64d032696247e7c4657f4656a1ce
    https://github.com/armbian/build/commit/730c1f6f4d6a5f45418c39e789f63b8da4fb1411 (not yet included in latest images, but included via apt update)

    1m from router.

    RTL8188CUS
    RTL8188EUS
    MT7610 at 5G
    MT7601U
     
  16. Like
    JMCC reacted to TonyMac32 in Pi-Factor power solution   
    Some feedback from @chwe and some improvements on the protection circuitry:
     

     
    And for the record, electrical cleaner can/will dissolve your electrical connectors...   Also, lead-free solder is an angry and terrible thing.  ;-)
     
    I'm charging my Pixel off of one of the power ports while I play music over bluetooth on the Tinker...  
  17. Like
    JMCC reacted to Igor in Le Potato / C2 / K2 4.19 LTS testing thread   
    I will rebuild those images ASAP.
  18. Like
    JMCC got a reaction from TonyMac32 in Le Potato / C2 / K2 4.19 LTS testing thread   
    I fixed some u-boot bug, happening in boards with 1GB of RAM, that could not load u-boot. Here is the console log with the failure:
    Reference to the commit: https://github.com/armbian/build/commit/01571c0a4c6c3e7cdb1fec8c99465d8fc00c8c90
  19. Like
    JMCC got a reaction from Shades_aus in RK3328 Media Script (Rock64, Renegade)   
    And, for last,  the first version of:
    The UN-official, UN-supported, UN-expected
    RK3328 MEDIA TESTING SCRIPT
     
    This is the first release of the RK3328 media testing script. The script provides a functionality similar to its RK3288/3399 equivalents, except for the OpenCL related stuff, which is not supported by the SoC. So it includes:
    Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 2.0 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi. A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with: Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.), and a simple Pulseaudio GTK equalizer using LADSPA.  
    Here is a more thorough documentation:
     
     
     
    >>> DOWNLOAD LINK <<<
     
    Prerequisites:
    You need a fresh Armbian Bionic desktop image with default kernel installed. 
     
    Instructions:
    Download the file above Untar it: tar xvf media-rk3328_*.txz cd media-script ./media-rk3328.sh  
    Notes:
    This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
    Enjoy!
  20. Like
    JMCC got a reaction from balbes150 in Armbian for TV box rk3328   
    Okay, so just to avoid hijacking this thread, we can continue the discussion about this in a new one. I'll tag you when I start it. I'm very interested in this topic too.
  21. Like
    JMCC got a reaction from NicoD in Librecomputer Renegade RK3328   
    So the Media Script is finally released:
     
  22. Like
    JMCC got a reaction from balbes150 in RK3328 Media Script (Rock64, Renegade)   
    Yes, I noticed that if you launch it just like "kodi", it won't start here, unlike the RK3399 where it worked.
     
    The cause seems to be that "standard" mali midgard T86x binaries have the necessary GBM symbols that Kodi uses, while in the case of utgard 450 you need to use the specific binaries for GBM.
     
    Solution: launch it in one of these two ways:
    LD_LIBRARY_PATH=/opt/libmali-gbm kodi or:
    kodi-gbm-wrapper  
  23. Like
    JMCC reacted to balbes150 in RK3328 Media Script (Rock64, Renegade)   
    Congratulations, great job.
     
    Quick check on MVR9
    the browser now shows videos in full screen all up to 4K, the only limitation is the channel in the Internet.
    MPV-also shows everything in full screen
    KODI -  not yet started up, complains that it is impossible to create the GUI (this is not critical, KODI is LE, everything works)
    I haven't checked the rest yet.
     
     
  24. Like
    JMCC reacted to Multi in [Development] RK3399 media script   
    Installed on rockpro64 and bash ran flawlessly, everything's seems to have installed and all desktop links created for applications, unfortunately seems that script was unable to override something, all apps run as if nothing had been done no streaming, mpv works same as before and Kodi does close x but breaks system when trying to run kodi, I'll try to upload log scripts 2morrow, hope whatever is missing shows up there.
  25. Like
    JMCC got a reaction from nachoparker in RK3328 Media Script (Rock64, Renegade)   
    And, for last,  the first version of:
    The UN-official, UN-supported, UN-expected
    RK3328 MEDIA TESTING SCRIPT
     
    This is the first release of the RK3328 media testing script. The script provides a functionality similar to its RK3288/3399 equivalents, except for the OpenCL related stuff, which is not supported by the SoC. So it includes:
    Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 2.0 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi. A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with: Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.), and a simple Pulseaudio GTK equalizer using LADSPA.  
    Here is a more thorough documentation:
     
     
     
    >>> DOWNLOAD LINK <<<
     
    Prerequisites:
    You need a fresh Armbian Bionic desktop image with default kernel installed. 
     
    Instructions:
    Download the file above Untar it: tar xvf media-rk3328_*.txz cd media-script ./media-rk3328.sh  
    Notes:
    This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
    Enjoy!