[pszab]

Finally
http://opensource.rock-chips.com/

[asavah]

Finally what?
The kernel, mali libs and even video decoding stuff have been on their official github for a good while.
Kodi can be built and it will run, but no hw video decoding because video decoding api is ... well ... let's call it peculiar.
No support in Kodi and AFAIK the devs refuse (and rightfully so) to accept another non-standard halfassed decoder api into Kodi.
While it's possible to find working forks, patches and hacks IMO this not enough.
Unless rockchip provides proper vaapi or vdpau support my guess is that we won't be seeing proper Kodi on rockchip boards on linux.

ARM world is a zoo where vendors do as they please, ARM cores design is the same but all the peripheral stuff is pure madness.

[pszab]

Seems to have better documentation and source than amlogic.

"You’ll find links to source code for u-boot, Coreboot, ARM Trusted Firmware, and Linux on the website, as well as software development guides and tools, including a Linux porting guides, BSP module user guides, graphics and multimedia user guides (GPU/VPU/ISP), and tools like Rockusb abd Rkdeveloptool.

They also have a dedicated email address opensource [at] rock-chips.com for people who want to provide feedback about the website."

I hope something has began

[wrxtasy]

From a LibreELEC perspective...

Current LibreELEC work is aimed more generally at RK3328 support (not specifically Rock64 or the Tinkerboard) with the intention of having something sorted for Kodi Leia in ~6 months time. Development so far has been done with Krypton, but a rebase against Leia is now starting.
So far progress has been rapid thanks to diligent work from LongChair/Kwiboo and great support from a small group of RK staff who feed them weekly updates against an evolving issue list.

Current state is still closer to “technical proof of concept” than “alpha” and definitely not “beta” which implies a completed codebase with minor finishing required.
We expect the next phase to go slower; complex code needs to be written and multiple efforts from AML, RK, FFmpeg, Kodi, etc. need to be aligned as we push onwards towards mainline kernels and V4L2 support (SoC vendors need to get their arses [into gear] about V4L2 drivers).

Fun times are ahead.

RK3328 (ROCK64) vs AMLogic S905(x) (click):

If you want a device to use as a *4K* media player, Amlogic S905 is a currently better choice than RK3328.

In optimal use, both will display video on a hardware overlay with no involvement from Mali. The differentiation is that, today, S905 will use AFBC (ARM Frame Buffer Compression) natively in the H265 codec and display controller allowing 4K HDR @ 60fps. The RK33xx media codecs (mpp library), today, do not appear to support AFBC. The display controller supports it, but there is no support in Linux to make use of it (patches are showing up). The result is that 4K UHD performance will be directly proportional to the speed of RAM used on the RK3328 board.

For Android use, the additional Mali core in S905 will mean it is more responsive and performant. Mali-450 is not a unified shader processor. The additional core (MP2 vs MP3) is a pixel processing (PP) core. This means that for every 3 pixels the S905 outputs, RK3328 outputs 2 pixels (33% performance difference). For Linux, this performance difference will only show up on applications that use Mali (which Kodi does).

Neither chip has a general advantage over the other. The choice depends on how you intend to use it and can be summed up as:
If you want to run a NAS, RK3328 is better. If you want to run graphical applications, S905 is better. If you run console applications that are not memory bound (2GB vs 4GB) or IO bound (USB2 vs 3), the performance should be consistent.

The above is my personal opinion. Others are certainly free to offer differing opinions.

[polo_joe]

There are some libreelec test builds for rock64 and tinkerboard.

https://github.com/Kwiboo/LibreELEC.tv/releases

[wrxtasy]

it's been a slow and Rocky Road getting Linux Rockchip support - so time for a little update...

I've been testing this afternoon with a RK3399 and the very latest LibreELEC Kodi Leia v18.0 pre-release.

Details about Surprises and current Kodi Leia usage limitations found over in the LibreELEC forums (click)

I'm pleasantly surprised.

[noggin]

it's been a slow and Rocky Road getting Linux Rockchip support - so time for a little update...

I've been testing this afternoon with a RK3399 and the very latest LibreELEC Kodi Leia v18.0 pre-release.

Details about Surprises and current Kodi Leia usage limitations found over in the LibreELEC forums (click)

I'm pleasantly surprised.

I've been looking at a Rock64 and a RockPro64 with LibreElec - but mainly concentrated on Rock64.

I've just installed the latest LibreElec 9.0.0 release on my Rock64 (RK3328)

The good news is that since I last checked, interlaced h.264 content is performing much better.   I hadn't held up hope for native 50Hz content being correctly deinterlaced - but a TV Headend recording of a UK entertainment show shot at 50i plays OK.  Early 'separate field' h.264 Blu-ray, as well as recent MBAFF Blu-ray content both play.  The separate field stuff used to be a blocky mess.  Native interlaced stuff seemed to constantly jump between correct and reversed field dominance. (i.e. field phase seemed to slip between TFF and BFF)

Downside is that DTS HD MA bitstreaming seems to be broken. You can either decode to multichannel PCM or bitstream the core. When I play DTS HD MA to my Denon AVR I just get crackle. (I don't know if this is because the DTS HD MA isn't being flagged properly. I noticed my HD Fury Vertex seems to think both DD and DTS are "PCM 2.0" not "Bitstream", so it could be there is a flagging issue?)

I'd previously thought that Avg/Max HDR Metadata was passed during earlier releases, but can confirm it isn't currently (I get 0/0 reported on my my HD Fury Vertex)

BBC UHD HLG content is output with an HLG EOTF signalled (the only Kodi platform I know of that does this properly currently)

**EDIT - unlike the AMLogic HDR metadata issue, the Rockchip situation appears to be worse.  The AMLogic sends the display mastering primaries and min/max mastering luminance levels, but doesn't send the content MaxCLL and MaxFALL levels.  The Rockchip currently sends no mastering primaries, min/max mastering luminance level metadata - as well as not sending MaxCLL and MaxFALL)**

kwiboo has also confirmed that the audio output is only flagged as PCM - relying on AVRs to recognise that there is a valid bitstream rather than it being flagged (which I think is basically luck based on how your AVR copes with out-of-spec audio)