Great, master/nightly builds will at some point (soon) change to use mainline linux. Recommendation for daily use devices is to stay on 9.2 alpha image until master/nightly is more feature complete.
Can you try with latest 9.2 alpha 001?
libreelec-rk3399.arm-9.1.001.tar?mirrorlist for update tar or libreelec-rk3399.arm-9.1.001-rock-pi-4.img.gz?mirrorlist for rock pi 4 image
Nothing rockchip specific have really changed since 9.0 alpha 015, using nightly image is not recommended because it is using an older version of kodi (18.2rc1 vs 18.2/18.3).
If there is a consistent problem with crashes with nightly that are not seen in 9.0/9.2 images there is probably an issue with the newer version of gcc or glibc and rk 4.4 kernel.
Device: Libre Computer/ Firefly ROC-RK3399-PC
dtb I tried: rk3399-roc-pc.dtb + rk3399-firefly.dtb
I do not have this device so I can not help with testing, also I have not checked the device trees is anything important may be missing/wrong.
Tried the rockpro64 image. Didn't boot. No red light on board.
I am preparing a new build (and a pull-request for merging rockchip mainline support to LibreELEC master), will test on my different devices tomorrow.
I fixed the incorrect voltage used for pmu_io_domains (1.8 correct vs 3.0 wrong) now I do get 1080p display. I'll post my dts soon.
Nice, do you plan on submiting this device tree upstream?
KOPRajs I have also noticed small audio issues on rk3399 using 4.4 kernel, on mainline I did not notice such issues, but I did not test enough on rk3399.
Can you try with one of the mainline images at Index of /test/ and see there is an improvement or not. Mainline images should support multi-channel lpcm same as on 4.4 kernel.
The nigtly builds do not always finish in time on our jenkins build server and that result in some images not being built on a daily basis.
I would recommend LE 9.0.2 / 8.90.015 for rockbox (and other Rockchip devices) as it has newer Kodi version. Everything rockchip specific is more or less same in nightly vs 9.0.2.
Early mainline images for RK3288, RK3328 and RK3399 have early mainline linux (v5.1) test images and is where most development happens.
Just a little precision, my resolution is set to 720p. As soon I set it to 1080p suttering and jittering appear.
Good point, any scaling will be done in GPU and the GPU in rk3328 is on the lower end. Changing scale mode in OSD -> Video settings may reduce stuttering and jittering.
With the Direct-To-Plane renderer the video output processor (VOP) will do scaling and is not limited by the weaker GPU.
This is the one of the reasons I want confirmation if this issue exists using mainline images.
Actually the Rock64 is clock at 1.2 Ghz, if we can clock it at 1.5 Ghz (like armbian do with the Rock64) maybe that can help to eliminate the stuttering.
I do not think the CPU is the limiting factor, it is the GPU. I do not remember at what freq the GPU run on RK 4.4 images, it may be limited to 500 mhz. Previous testings showed that the GPU can be run at 600mhz without issues. Mainline images will run GPU at 500mhz.
No you cannot disable gpu rendering (it is the only way to render sw decoded videos). Render sw decoded video using direct to plane is still work in progress.
Possible due to a bug in Kodi, please test 8.90.015 and mainline image and see if problem is also present, they both have newer Kodi versions with important fixes.
Nightly images is using the older 18.2rc1 version with some known bugs.
LE master is still on that version because it is the latest taged version on kodi master branch.
As I mentioned before xvid/divx/mpeg-4 is all sw decoded and will use GPU rendering instead of direct to plane rendering, please try the mainline linked to in Early mainline images for RK3288, RK3328 and RK3399
Those images will use sw decoding and direct to plane rendering, let us know if there is any difference
Yeah was afraid of that. I installed libreelec on the internal emmc and the board is in a aluminium case for cooling. It is always a bit of a struggle to get the sd-card in and find the right jumper position.
You should not need to change the emmc jumper to boot from sd-card, at least I do not have too, it will probably use ddr+u-boot from emmc, if u-boot is new enough it should still try to boot from sd-card before trying to boot from emmc.
tested the rockpro64 image, got a 'mode not supported' error on my 1080p60 monitor using HDMI. I can't tell if its the image or the old monitor causing the issue.
Mainline 5.1 linux do not have support for all video resolutions and refresh rate at the moment, connecting the device to a TV usually work, the old vendor 4.4 kernel have much better support for different resolutions and refresh rates and is why your monitor works using the latest non-mainline images. This should improve in the future.
Checked the image for Khadas EDGE. As part of no DTB.
I totaly forgott to remove that image Before uploading, mainline do not have a DTS for Khadas Edge and I have not created one yet, I will run tests and create a Khadas Edge dts suitable for mainline before next update.
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 hw decoding (everything else is sw decoded)
- 8ch Linear PCM HDMI audio
- IR (keymap is not pre configured)
- Only up to 1080p resolution and not all refresh rates
- 10-bit videos will show as green picture
- SW decoding of VP8 on RK3399 produce garbage
- 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)
- No deinterlacer
- 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).
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)