Hi Kwiboo,
I was running into an issue while I was updating from the latest tinkerboard nightly to your version.
The error message during boot is LibreELEC-RK3288.arm-9.1-devel-20190512171730-bdfaff1-tinkerboard.img.gz does not work with tinkerboard hardware.
I think you may need to do a clean install. Please keep in mind that this is very early test images, so I would recommend you to test on a separate sd-card.
May I ask you to point me the correct build and/or dtb file for RK3399 H96 Max 2g RAM version?
Sorry, I have only included dtb-files that have been submitted to mainline, with the exeption of some rk3328 dtb-files.
Is there a good dts-file that can be ported to mainline and eventually be submitted upstream somewhere?
Ethernet/WiFi/BT were not OK so I couldn't test more.
Thanks for reporting, I will test ethernet on my MVR9 box, never did more then a quick boot test on MVR9 before posting 
After some time of private testing mainline linux v5.1 on my rockchip devices here are some images for wider testing.
Please note that this is very early mainline images and are not meant as a replacement for you daily driver.
At this stage information if an image do not boot or stack traces is very good feedback.
RK3288 (Tinker Board S) and RK3328 (Rock64, roc-cc, rockbox) have got most of my attention,
so I expect there is more issues with RK3399 or any of the other boards/boxes not listed.
For RK3399 owners there are some more device tree files in .tar-file at 3rdparty/bootloader/.
Copy correct .dtb-file to sd-card and change DTB line in extlinux/extlinux.conf,
please report if dtb-file works for any device not having a dedicated .img.gz-file
What should work?
- MPEG-2, H264 and VP8 hw decoding (everything else is sw decoded)
- 8ch Linear PCM HDMI audio
- SPDIF
- CEC
- IR (keymap is not pre configured)
- Ethernet
- SD/eMMC
Known issues:
- Only up to 1080p resolution and not all refresh rates (RK3328 now support all refresh rates and resolution up to 2160p)
- 10-bit videos will show as green picture
- Hotplug of USB3 on RK3328 only work one time, a reboot is required to discover a new/replug usb device
- No AC3/DTS/HD audio
- No WiFi/BT (wifi should work on tinkerboard and box-trn9)
- No deinterlacer
Code:
- Now merged into LibreELEC master
Images:
- Index of /test/
Please report any issues related to HDMI, Audio, CEC, IR, Ethernet not already listed in known issues.
Issues related to other IO ports on your board will be ignored for now (too early to care about non-media player related issues).
UPDATE:
Mainline support has now been merged into LibreELEC master branch for linux v5.4, test images has been updated to latest code merged into master branch!
Thanks!
For me, all image files work / boot properly. My only problem is playback of HEVC video freezes and then catchup every 15 to 20 seconds for images after 2018/10/02, up to the latest 8.90.015.
Do you have a shorter sample of a video that cause such freeze/catchup? Would be interesting to test on my board.
Hopefully getting h264/hevc hw decoding on mainline wont take too much time (weeks).
I tested your linux 5.1 image on my ROCK64 with the fastest speed microSD card I can get. HW acceleration is still not working (green screen but audio is fine). Once I turned off HW acceleration, video playback just like everything in slow motion.
This is expected, the linux v5.x images only have MPEG-2 hw decoding (for now), everything else is sw decoded and there is an issue with 10-bit video (will show as green).
Does the image work / boot / do not crash compared to latest nightly or the recently released 8.90.015 image?
Could you also provide linux 5 test build for trn9 box?
I do not have a device tree for the trn9 box on mainline kernel currently, only roc-cc, rock64 and rockbox, I will try to add the missing ones before I create a new mainline testing thread and post all linux v5.1 images (later today).
I think the issue is with the different memory modules used, my Rock64 boards is from one of the batches when the board was rather new and when 1866mhz memory modules was used even if the board spec was 1600mhz.
The old images did not have dfi/dmc ddr devfreq enabled in device tree and possible explains why you have a more stable board with the old image and problems with newer images.
The linux v5.0 image I linked to possible had the 933mhz ddr init code and that would explain why it does not work on your board, I have uploaded a linux v5.1 image with the 786mhz ddr init code: libreelec-rk3328.arm-9.1-devel-20190512071134-2f3393e-rock64.img.gz
One of my Rock64 boards:
Do the crashes mainly happen during hw decoding? I am wondering if it is related to dynamic changing of memory clock speed and voltage.
What board revision do you have? (Has Rock64 rev3 started shipping?)
Please try an early mainline image at Index of /test/ and see if it is more stable, it only have mpeg2 hw decoding and other limitations.
(Plan to push updated linux v5.1 images for wider public testing sometime later this weekend)
mpeg-4/xvid/divx is software decoded, try go to Video settings when playing a video and change deinterlacer to half or off.
Just to clarify this, did LE ever pull in any of the commits submitted by CE team members ?
Lots of PRs submitted by CE team members have been reviewed and merged, unfortunately nothing have really been submitted since the fork.
adamg88: Pull Requests · LibreELEC/LibreELEC.tv · GitHub
rayelec: Pull Requests · LibreELEC/LibreELEC.tv · GitHub
afl1: Pull Requests · LibreELEC/LibreELEC.tv · GitHub
arthur-liberman: Pull Requests · LibreELEC/LibreELEC.tv · GitHub
The LG Chess is one of those 4K@60 clips that rk3328 will have problems with and will usually play at 58-59 fps and ends out of sync.
On ROC-RK3328-CC the slower memory bandwidth (compared to Rock64) may play back LG Chess with even less fps then that, a 4K@50 sample showed similar a/v sync issue when I tested.
Please share a sample of the video that stops after 8 seconds.
Kwiboo I just tested the LE version you suggested on ROC-RK3328-CC.
First of all this board runs extremely hot. I have the heatsink for the SoC mounted, and it still idles around 60C.
It does play H264 very well now, HEVC 10-bit is still dead in the water, but the short HEVC 8-bit clip I tried played well. The GUI looks like it's not hardware accelerated, a lot of jaggies, not smooth, etc. I couldn't really test audio passthrough, the list of available passthrough formats was empty (it's connected to a PC monitor which only supports PCM, so perhaps that is working as intended).
So yeah, there's progress since the last time I tried it.
I agree the RK3328 is running very hot as the default setting is to run CPU and GPU with performance governor (CPU at 1.3GHz and GPU at 500 MHz). ROC-RK3328-CC device tree has trip points at 80/95/100C. My device starts at 61C idle without any heatsink.
Please share any 10-bit HEVC clip that is having issues starting, all my 10-bit HEVC starts on my ROC-RK3328-CC-V1.0-A 2GB device using official RPi power supply, only the most demanding 4k 50/60 fps 10-bit HEVC should cause framerate issues.
I suggest you test with a 4k 10-bit capable TV instead of a monitor, also do not enable debug gui overlay as that will affect video playback, use default settings.
50/60fps 10-bit 4K HEVC will have more problems on ROC-RK3328-CC compared to Rock64 thanks to the DDR4 memory used on ROC-RK3328-CC vs LPDDR3 memory used on Rock64.
GUI should be hw accelerated but the Mali 450 MP2 gpu will not be as fast as an S905 Mali 450 MP3 gpu running at higher frequency.
PT-audio is not fully supported in current builds, only up to 192khz 24-bit 8 channel LPCM is supported. And as you have noticed EDID/ELD is used to determine audio capabilities.
Do you know if Ezequiel's work will be published and added to a review of libreelec for rockchip? Or is it necessary to patch what it says manually?
I tested the initial MPEG-2 decoder using libreelec and v1 patchset is included in my mainline test build. I will update to v2 patchset and 5.0 final for next mainline test images.
Out of curiosity are you talking about the normal Libreelec github sources or is this something from your own github sources? i have built bables rockpro64 build and am interested in looking at others as well...
The Alpha 014 image is build from the libreelec-9.0 branch at official LE repo.
My mainline testing is built from GitHub - Kwiboo/LibreELEC.tv: Just enough OS for KODI (final LE 9.0.0 + rockchip-5.x patches) using following commans:
PROJECT=Rockchip DEVICE=RK3288 ARCH=arm UBOOT_SYSTEM=tinkerboard LINUX=rockchip-5.x make image
PROJECT=Rockchip DEVICE=RK3328 ARCH=arm UBOOT_SYSTEM=rock64 LINUX=rockchip-5.x make imageThe two test images at Index of /test/ is built from the rockchip-5.x commit at my LE repo.
Kernel patches is based on Commits · Kwiboo/linux-rockchip · GitHub and rockchip-5.x-rebase (locally I have rebased those branches on latest 5.0-rc8 and will rebase and push an update with final 5.0 any day now.
I do all my building insed docker containers to minimize influense from build host, see README at LibreELEC.tv/tools/docker at master · LibreELEC/LibreELEC.tv · GitHub for a short example on how I build my images.
For Rock64 any eMMC should be faster then any SD-card as there only is support for high-speed transfer speed (20-23MiB/s).
There is no 1.8v signal voltage support that is required for faster UHS sd-card speeds.
since using ondemand govenor on my mvr9 box I had no more crashes.
Great, I will change the default govenor for rk3328 to ondemand (same as rk3399/rk3288) in next small update to 4.4.
I have been using ondemand as default in my mainline kernel testing so far without issues.
I have a SBC based on another Rockchip, and the last time I tested it, it was pretty useless as a media player in all regards.
H264 video stuttered, HEVC video would lock up after 10 seconds of playback, no HDR support, etc.
Please try the latest LibreELEC 9.0.1 / Rockchip Alpha 014 build (on a rockchip sbc with a "supported"/tested devicetree), it should work very good.
Do not stare blind at the alpha name, it is mostly there because there is features missing (HD-audio and full HDR infoframe metadata).
So LE has stopped supporting Amlogic and Rockchip users?
Rockchip is very much working and "supported" even if it is still flagged as alpha, the 9.0.0 / Alpha 013 and 9.0.1 / Alpha 014 images should work very well.
My focus for Rockchip at the moment is on mainline linux, hd-audio and adding more codecs to the rk v4l2 request api driver and ffmpeg hwaccel.
I still don't understand why you fixate on the Kernel version, how old it is, or what GPU drivers it has. As long as it works well and fast, and it does work well, and it's also very fast, I personally don't care what version of kernel it is running on.
LE pushes towards Mainline kernel support, I can understand why, LE has to cover multiple different platforms, so it makes sense for you.
Even with the 4.9 aml kernel the drm/kms stack is unfortunately not used for video rendering. Compared to mainline (or RK 4.4) this mean that the new video rendering path in kodi (the direct-to-plane drmprime renderer) cannot be used. When amlcodec (and mmal) rendering is removed from kodi the kernel subsystems used for the display stack gets important.
The drm prime decoder + direct-to-plane renderer was first designed and tested for RK 4.4 kernel but thanks to using "modern" kernel subsystems it is working with any drm/kms platform that can render video on a dedicated video layer / plane and has been proven to work very good on mainline aml, rk, rpi, imx and other platforms.
I have now been reading through LE forums including this one (wishing that I'd done that before
) discovering all the issues with developing a stable image for this device and its SOC (RK3328), and I feel that I somewhat understand (it may go over my head
From a developer perspective the Rockchip Alpha 013 image is as good as it is going to get with Rockchip 4.4 linux, it should be rather stable and supports hw decoding of most formats. Focus going forward is to make Rockchip run on mainline linux.
I already have Tinker Board and Rock64 working okay on mainline but it only supports mpeg-2 hw decoding and up to 1080p resolution so far, mainline testimages can be found at Index of /test/, upstreaming of linux patches is ongoing.
