Early mainline images for RK3288, RK3328 and RK3399

    This thread is for early mainline kernel, so no Kodi 18.7 here.

    Hi everyone

    Is this the correct thread for the actual nightly builds for rk3399 devices here: Index of /

    I'm actually thinking about buying an rk3399 based board and am wondering if it is possible to turn the SBC on via IR remote or on board button, or if it has to be powercycled once shut down.

    Thanks

    P.S. turns out npcomplete has similar question :) I guess it all depends if there is an embedded controller and if that's supported by mainline LE.

    Quote from lumpi

    Hi everyone

    Is this the correct thread for the actual nightly builds for rk3399 devices here: Index of /

    I'm actually thinking about buying an rk3399 based board and am wondering if it is possible to turn the SBC on via IR remote or on board button, or if it has to be powercycled once shut down.

    Thanks

    P.S. turns out npcomplete has similar question :) I guess it all depends if there is an embedded controller and if that's supported by mainline LE.

    I was reading else where and I think this needs to be configured in u-boot, i.e u-boot controls "power-on" and LibreElec (OS) controls the "power-on"

    I'm interested in power-on either from hdmi-cec or RC

    Just looking at the datasheet and found this:

    Code
    1.2.5  System Component 
  Cortex-M0 
  Two Cortex-M0 inside RK3399 to cooperate with Cortex-A72/Cortex-A53 
  Thumb instruction set  combines high code density with  32-bit performance 
  Integrated  sleep modes  for low power consumption 
  Fast code execution permits slower processor clock or increases sleep mode time 
  Deterministic, high-performance interrupt  handling for time-critical  applications 
  Serial Wire  Debug reduces the number of pins required  for debugging

    if this MCU has control over PMU and IR receiver all but the M0 can be shut down. That works before u-boot I suppose.

    Due to the lack of time of Kwiboo I added his latest work to LibreElec recently which also adds some functionality:

    • H264 Hi10 decoding and rendering (RK3399 and RK3328)
    • proper decoding of H264 field encoded content on all SoCs
    • USB3 support for RK3328
    • HDMI / DRM addtions to support 2160p@60Hz on all SoCs (RGB444 on RK3288/RK3399, YUV420 on RK3328)
    • WIP patches to support VP9 and HEVC decoding on RK3328 and RK3399 (keep in mind: WIP!)

    They are included in latest LE nightlies on Index of /

    There are no updates in regards of HDMI passthrough and this won't change any time soon.

    Also there are some shortcommings in some upstream devicetrees (no hdmi sound enabled for example for RK3288 miqi) which I will be addressing in a follow-up PR.

    Note: Due to the lack of upstreamed devicetrees not all devices that were supported in LE 9.2 can be supported in future. (its very unlikely that LE will add support for devices that do not have a devicetree in mainline kernel since it will add additional overhead with rebasing and adapting this with every kernel update). So: If you want to your device to be supported: You'll have to go the "extra mile" and submit it to mainline kernel (or at least suggest it there and hope somebody else is doing the work for you)

    Also: please don't use update functionality for LE 9.2 -> LE 9.8 and use an extra SD card for this tests.

    Thanks knaerzche for your effort. I see quite some improvement here.

    I still have Rockchip: add H96 Max+ support by easybe · Pull Request #4195 · LibreELEC/LibreELEC.tv · GitHub pending. I will give a shot at upstreaming the DT. However, it would be good if we could test it for a while with LE master first. Is that an option?

    I am also willing to work on support for other devices if there are people that would benefit from that.

    Cheers,

    Ezra.

    Hi knaerzche

    Do you know if the bug explain in the link below is a bug that can be correted ? Personnaly I think that Rockchip devices run very well but that bug is really disturbing for 4k movie.

    That bug exist with my Rock64 AND my Rockpro64

    4k Quality on Rock64

    I know that rockchip release of Librelec is only a beta, I'm just curious to know if that bug should be fixed in a future release.

    Thank you !

    Note that the report is about vendor kernel stuff while we are now using mainline kernel. The (huge amount) of work of last months/years was to port vendor code to mainline kernel / ffmpeg and it is possible that some shortcommings were ported as well - I'm confident they will be ironed out with ongoing work.

    The whole HEVC/HDR, VP9 and the 10 bit output are all WIP and is what makes this a beta release for Rockchip and should be seen as technical preview.

    XFS formatted hard drive works in the latest nightly built (nightly-20210311-3f55efc). Files can be copied using SMB as well as plays well.

    This build has two problems (not related to XFS):

    (1) Rock64 - not providing 1440p resolution for 32" monitor. (Actually all LE10-nightly)

    (2) LibreElec repository broken. Kodi repository works. (LE rep works in 2021-03-08)

    Quote from MakaaiD

    XFS formatted hard drive works in the latest nightly built (nightly-20210311-3f55efc). Files can be copied using SMB as well as plays well.

    Thanks for testing.

    Quote from MakaaiD

    (1) Rock64 - not providing 1440p resolution for 32" monitor. (Actually all LE10-nightly)

    Its a feature, not a bug.

    I'm tryiing to stay as less technical as possible: RK3328's HDMI phy supports only a very limited number of (TMDS/Pixel)-clock rates. In previous (vendor kernel) versions they were alll supported within a given min-/max-range which is not correct and resulted in non-working screens for many people (and no possibility to easily change it). In mainline kernel we support only exact rates (+/- 5% which is the VESA standard) and 1440p respectivly 241.5 MHz TMDS-/pixel clock is not natively supported by RK3328's hdmi phy (even if might have worked for your particular screen). This might change if the vendor provides settings for more rates in upstream kernel. In short: stability beats compatibility here (again).

    Hi Knaerzche,

    I have a 1440p screen for which the 4.4 rockchip kernel does a decent job with rk3399. With a couple of printk I got my hands on the would-be-mpll_cfg that (I thought) would allow to configure that mode.

    However, when adding a mode this way into mpll_cfg, it gets rejected by vop_crtc_mode_valid with MODE_CLOCK_LOW, as when requesting 241500kHz the clock only accepts to grant a 198000kHz rate - where with the rockchip kernel, dclk_vop0 can really be set to 241500 (with parent dclk_vop0_div, taking its source from vpll). Can you see any obvious reason why the VPLL would not be able to deliver this clock rate ?