Posts by Kwiboo

    It might still take a long time until all features work in mainline so this might be a stopover for some developers and work better than the 4.4 kernel for now?

    I am hoping to reach a new base state for mainline in a week or two, rkvdec high 10/422 h264, vp9 and initial hevc is more or less working (mainly tested on rk3399, probably needs some tuning on rk3328 and rk3288), will post a h264 high-10/422 v3 series on mailing list later this weekend.

    There has also been some progress on HDMI side to be able to support proper 10-bit output, color space conversion needs more work before I start posting hdmi patches on mailing list and generate patches for use in LE-master.

    Commits · Kwiboo/ · GitHub have the latest diff I am testing, this branch should see some updates this weekend and next week, currently missing some bits for 10-bit framebuffers, hevc, hantro interlace due to testing h264 uapi changes.

    Regarding PT audio, the Allwinner patches should probably work on RK mainline, I have not tested yet as I want to finalize v4l2 and 10-bit hdmi work before jumping on audio.

    Maybe devs know something regarding this issue. Kwiboo ?

    This is the main "blocking" issue from my point of view, it seems to happen when mode is changed from one 4:2:0 12-bit mode to another 4:2:0 12-bit mode (and yuv plane is involved). I think LibreELEC-Generic.x86_64-9.80-devel-20200201013402-e776789.img.gz contain a limit to use 8-bit output and if I remember correctly using 4:2:0 50/60hz 8-bit works, it will activate HDR mode on my LG OLED but I am sure colors will not be optimal.

    I have not been able to produce a simple reproducible test case (not using kodi) for this 4:2:0 50/60hz distorted image issue.

    Main problem for me at this point: They dropped the driver for dmc-controller in mainline - which means all features for dram-frequency-switching (at kernel time) is no available now and device will always run in the (propably very low) freq, at which it was initialised at boot time

    Please try the ddr blobs I just patched to hopefully init ddr at 786MHz speed at rk322x: add ddr v1.10 and miniloader v2.56 · Kwiboo/[email protected] · GitHub, I used the same technique on rk3328 ddr blobs to get a 786 and 933 MHz blob.

    01 2C = 300

    03 12 = 786

    Thanks everyone who have done testing! Mainline support has now been merged into LibreELEC master branch!

    Test images at Index of /test/ has been updated and they should support MPEG-2, H264 and VP8 hw decoding, and on RK3328 initial 4K and 10-bit HDMI output support is included.

    There is plenty of areas to improve going forward and main focus next will be to upstream kernel patches.

    Hum, ASoC: hdmi-codec: reorder channel allocation list - Patchwork is the upstream submitted patch that have some more details in commit message. It is intended to fix wrong speaker channel allocation mainly for 7.1 audio, where 6.1 ca gets selected without that patch.

    daten please share a kodi debug log, it should include some details on how channels is mapped.

    Also try to see if setting speaker count in kodi settings to 4.0, 4.1 or 5.1, 7.1 makes any difference.

    Kwiboo, we really need new images for testing, please :)

    I know, summer vacation got in the way :) , I am now back working on an updated rockchip mainline image and other related things for the next few days.

    Gigabit ethernet is broken for all RK3328 devices at the moment., Kwiboo said he will look into it.

    I am hoping that something like arm64: dts: rockchip: improve rk3328-roc-cc rgmii performance. - Patchwork also can help other RK3328 devices, I had some trouble with gigabit on MVR9 last time around. Hoping to get it storted out this round :)

    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.

    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.