Early mainline images for RK3288, RK3328 and RK3399

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

  • Kwiboo Any idea if cec wakeup/poweron works for rk3399? I can see that my LG TV power downs the RK339 TV box I have, but it does not powers it back on.

  • 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.

  • The rockpro64 .dtb is missing the entry for ir-recv. I think I can figure out the fix (it's a GPIO IR receiver so a copy from the 4.x dtb should be about right)

  • 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 [email protected] 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.

  • 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 !

    Libreelec : Raspberry 4, Orange pi lite2, Orange pi PC(and +), Pine H64, Rock64, RockPro64, soon Orange Pi 3 and PC2

    Divers : NVidia Shield Pro, NVidia Shield Tube, N2 and C4

  • 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)

  • 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.

    (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).

  • Thanks, Knaerzche,


    Greatly explained. In short, the vendor needs to provide rate settings for the new kernel.

  • 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 ?