Posts by Kwiboo

Quote from mo123

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/LibreELEC.tv · 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.

Quote from smp

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.

Quote from knaerzche

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/rkbin@c99ef00 · GitHub, I used the same technique on rk3328 ddr blobs to get a 786 and 933 MHz blob.

01 2C = 300

03 12 = 786

Last time I tested speaker-test (months ago) it did not support or made use of channel mappings api and expect channels to follow a specific configuration / order.

Kodi make use of the channel mapping api when correct alsa card/device is used, make sure you select the hdmi audio device that read and make use of ELD, it usually contain short TV/AVR manufacture name in kodi.

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.

Quote from mo123

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.

Quote from mo123

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

Quote from JerryPenguin

I hope that we will soon get a current version for testing with WiFi

Thanks for testing on a NanoPC-T4.

I am working on an update to linux v5.1.15 and will include initial H264 hw decoding support, aiming to have it ready later this week.

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.

Quote from Loader009

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.

Quote from doof

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.

Quote from npcomplete

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.

Quote from vpeter

Intel is also working on S9xxx SoC?

Core functionality for HDR Static Metadata should land in v5.3, and was made by Intel. dw-hdmi HDR metadata support for Allwinner, Amlogic and Rockchip has already been posted to mailing list: DRI devel - Patchwork

Quote from mike2002

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.

Quote from mike2002

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

Quote from Nerd

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.

Quote from kmartin347

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.

Quote from balbes150

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.