Information Regarding Linux on Rockchip SoC's

1st Official Post

    I am curious with regards to some of the status and issues of running linux on the RK3399 platform.

    Its been along time since i last played with developing on Rockchip (back in the rk3066 and rk3188 days) and i can see the linux platform is sitting around 4.4 and i am curious as to whether those builds are out of tree builds or are they in sync with the main line 4.4 kernel tree.

    As well i am interesting to know if the Mali T860 processor used in the RK3399 is in a simular position as the unsupported stage the S912's Mali T820 is stuck at?

    I have a H96 Max on its way from a factory and am planning on migrating my own operating system over to a Rockchip platform (its basically a similar idea as LibreELEC just i started it before LibreELEC existed when all that was around was OpenELEC} I am not interested in even having Android on the box so that part i don't really care about.

    Basically i am just trying to see where the Rockchip platform sits reqarding a linux system and from downloading all of the Rockchip SDK's and some other githubs curious as to where things sit as they seem to be providing more open support then Amlogic ever has and probably ever will.

    Anyways any thoughts or information on the status would be greatly appreciated.

    RK3399 Linux support is vastly superior to S912 that don't have any GPU drivers and rely on slow Android libhybris drivers.

    Here is some more info about Armbian Linux on RK3399

    With the media script you can play 4K video in Linux, desktop is also very fast with 3D apps that are also working.

    [Development] RK3399 media script - Rockchip 3399 - Armbian forum

    Rockchip 3399 - Armbian forum

    Status Matrix

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

    If you look at RK3399 that are popular with LE and will get more support in future, you can look at the devices for which images are build for and used by developers.

    Index of /test/

    I would recommend you only get a RK3399 device that is supported by Armbian or LE otherwise you are going to have a very difficult time to get wifi, bt and everything else to work yourself from a 'ship and forget' device.

    Khadas Edge, RockPro64, Radxa NanoPi are good choices as they also have their own forums where users discuss Linux related topics.

    RK3399 in mainline linux is rather good as it is also used in some Chromebooks (OP1 processor = RK3399).

    When it comes to the 4.4 kernel rockchip have a pretty recent Linaro Stable Kernel (Android) merged, unfortunately when I asked if there was a chance to see a new version pushed to github it ended with "not a chance", I am speculating that the internal rockchip linux tree contains code for unreleased products blocking pushing a new version public.

    For LE we use a special 4.4 version that I have tuned for video/audio/cec/media, see the different rockchip-4.4 branches at Branches · Kwiboo/linux-rockchip · GitHub, they correspond to the patches seen at rockchip-4.4, the base version used in LE corresponds to the release-4.4 branch in my kernel tree.

    Moving forward I am mainly focused on mainline linux development (rk3288 and rk3328 already works rather okay), my next step is to confirm rk3399 devices works before I push initial mainline support to LE.

    As mo123 mentions gpu driver exists for T860, you can find it at GitHub - rockchip-linux/libmali: The Mali GPU library used in Rockchip Platform, for LE we only use the gbm version.

    When it comes to tv boxes I would also highly recommend any of the SBC type of devices, box devices will not see much support when we move to mainline unless vendor or other community members upstream device tree to mainline u-boot/linux.

    • Official Post

    In the mid-term the difference between T860 (RK3399) and T820 (S912) should become moot because both will be using panfrost. The current advantage of RK3399 is that the T860 blob is available publicly and it's the more stable option, and we can elect when to make the change vs. S912 which can only use panfrost. Fortunately panfrost is making rapid progress :)

    cool... thanx... i have kinda watched the armbian thing for quite awhile so i am somewhat familiar what they were up to.

    ya the RK3399 is where i want to start and look, As far as anyone else software that i am not really to worried about as i have been building embedded linux systems for a long time. I am interested because i want the 4gig of ram which will let me do more on the box. I was aware of the lack of CEC support but just wasn't sure about the Mali Cores. The T820/830 i am already well familiar with and aware of the issues with it out in the public

    I realize now after being away from the scene for awhile that things really haven't changed all that much with the S912's and Amlogic providing any real support as they seem to be relying on the community and a private company to get things in order. Its nice to see that a couple of good hearted coders at least got things going some what by using the Hybris library as a layer to handle allowing the Android blobs to run giving at least a somewhat workable solution but now after a week of reading and playing catch-up i realize that most things are still stuck at a community participation level. especially the mainstream kernel stuff. I can't belive they have not made any real headway on that. Privately theres a set of patches that have been developed to unifiy the S8xx and S9xx to their own 4.9 outta tree level and from there another set of patches to bring things up to 4.19 mainstream. Just the patches have never been publicly released.

    Anyways i digress...

    thanx for the heads up and information

    Quote from chewitt

    In the mid-term the difference between T860 (RK3399) and T820 (S912) should become moot because both will be using panfrost. The current advantage of RK3399 is that the T860 blob is available publicly and it's the more stable option, and we can elect when to make the change vs. S912 which can only use panfrost. Fortunately panfrost is making rapid progress :)

    Ya i have been paying more attention to Panfrost since you mentioned that before and your right it doe's look promising, i've cloned the repos and been looking at things and can see its promising

    Ive got most of the Mali docs and tools and kinda thought they looked pretty close but just wasn't sure of the issues of public support , but i was nicely surprised to see Rockchip openly supporting linux. I started on Rockchip way back so i am somewhat familiar with them but i moved to Amlogic which was a good thing for me for along time but now have come to the conclusion its time to change to something again and Rockchip looks extremely interesting to me.

    Thanx man... you answered quite a bit for me in that... i had already downloaded most of that and seen the different branches on some of it and was kinda wondering about them so your post helps a lot on what i seen and cloned. I just need to build something to get familiar with their build methods.

    as well i seen the trusted platform repo and was beginning to wonder about locked stuff.

    once again thanx guy

    I’ve been researching in the past couple of days about rockchip’s based SBC’s. as those seemed to become the go to SOC for 2019+.

    thanks, guys, for all the information provided here in this thread it’s really helpful.

    As they answered most of my question in regards of Linux support on rockchip.

    I only have one more question. Which I can’t seem to find an answer for:

    As we know the video decoding is not done by mali but the VPU.
    AMlogic’s S905D/X VPU internally converts 10-bit to 8-bit for processing as we know.

    Does the rk3328/rk3399 internally work the same when processing 10-bit content or do they both stick to 10-bit?

    Actually that is a good question and someone with more experience on the platform can provide a exact answer...

    So far from the as i start to go thru the SoC's docs i see they keep saying up to 10-bit but so far in what little i have gotten into i have not come across the specifics of how it works. The Rk3399 looks interesting especially the idea of coupling i higher performance A72 cores and the A53 cores on the SoC.

    Hopefully someone in the know will provide a better answer and i definitely agree i can see a bright future with this board.

    Quote from djnice

    And the RK pass-thru all of the HDR metadata especially the MaxFALL, MaxCLL too?

    RK3328 and RK3399 share same DW-HDMI TX core and can both send Dynamic Range and Mastering InfoFrame with EOTF/MaxFALL/MaxCLL metadata.

    RK3328 have HDR2SDR / SDR2HDR support, this is not supported by RK3399 where the T860 GPU could potentially be used for tone mapping for up to 4k@30hz.

    RK3399 does however have more advanced colorspace conversions support with custom coefficients, where RK3328 have predefined color conversions methods.

    For LE we only set EOTF metadata because we currently do not have a simple way to extract MaxFALL/MaxCLL using rkmpp-library, will be something that gets improved once mainline v4l2 decoder is ready.

    I have a H96 Max coming from the factory and should be here soon but the deeper i get into looking at the 3399 i am curious to if you guys have a better recommended different form factor board based more as a development board where more of the gpio's are exposed?

    Something along the lines of a beaglebone or raspberry layout. been looking around seen a few different ones. things like the Rock64 and some other Pine made boards.

    Its kinda a shame for me to wreck the H96 Max jury rigging it with interfaces where as a different form of the board. I need to get Jtag up and running on the cores to see whats going on in some areas...

    Any suggestions would be appreciated.

    I'm running LE on H96 MAX. For now forget about WiFi and BT support until the mainline kernel switch but apart from that it runs pretty well. You need to use the correct device tree. I've extracted the one from stock Android and customized it to get the HDMI audio in ALSA, HDMI-CEC and the IR receiver working. You can download it in the H96 MAX thread:

    H96 MAX RK3399

    The only thing I'm missing is deinterlace support. I'm not sure if it is related to the DTB or if it is a global RK3399 problem.

    k... whats the issue tho with the WiFi and BT support and the mainline kernel switch... you kind of lost me there... you meaning that when the box switches to mainline kernel then things will be fixed? I kinda figured you would be fishing the hardware information from the intended OS in Android in this case so i am all good with that.

    how bout the boot/reset vector on the box? by that i mean are they protecting that in anyway or can you adapt something like u-boot to just pick up the reset vector on the boot core and then pull the whole system up on Linux in this case and just do away with Android totally?

    Quote from chewitt

    It means right now we are focussed on core video/audio support more than figuring out some of the packaging mess required for WiFi/BT firmware and nvram files. It's something we need to align for Allwinner, Amlogic and Rockchip.

    RockPro64 is a popular RK3399 board among a variety of RK developers.

    k... i was looking at that and wondering... I need something to setup a working jtag and some other interfaces on and a open form factor like that is probably easier to retrofit then destroying the H96.

    the reasons i ask about the linux and driver stuff is my intention is to try and do the same thing we did with the S812 in creating all the missing stuff to get it up and into Amlogics own 4.9 open linux. I was going to start on the S912's but since looking around here and reading have come to the conclusion of going back to Rockchip as they seem more open with support then Amlogic ever will be. Its a lot of work and a fair bit of reverse engineering to gain the knowledge of how things work but the RK3399 seems like a neat SoC and my interests in it actually go outside just another tv box and i would need to tackle some issues for that to happen anyways so i think its were i will dig in and start. thanx tho as i always find your posts interesting and informative

    • Official Post

    I don't see Rockchip as particularly better than Amlogic when it comes to upstream/mainline development. Both vendors are mainly still focussed on legacy codebases (4.4 for RK and 4.9 for AML) and despite RK having a GitHub presence both vendors work mostly in private repos. And since the focus of all new code is (or should be) the upstream kernel both vendors have similarly sized/active teams of independent kernel maintainers (the kernel prefers non-employees). Both vendor mainline efforts are missing stuff and the only real-world difference is in what the missing bits are. Right now (from a mainline readiness LE oriented viewpoint) Amlogic is actually the more usable one due to RK missing the VPU.

    Most of the missing Amlogic components (10bit output, framebuffer compression methods and audio) either have funded work packages lined up or a known/probable contributor who's expressed interest in working on it. The one item that has no "owner" yet is the hardware deinterlace capability. Support for ge2d exists in the legacy kernel but like many things in the BSP kernel, the existing code is poorly structured and over-complex (a house that has been extended and remodelled over time) and it won't transplant directly to V4L2. So it's necessary to reimplement and not simply forward-port the existing code. Could that be something of interest?