Posts by knaerzche

  • LibreELEC (Nexus) 11 Beta1

    Quote from petediscrete

    Did a fresh install of Nexus 11 on the RockPro64 (RK3399). Boots to LE splash screen, resizes the file system, announces a reboot and then hangs.

    I can manually reboot but it is grabbing a 1920x1200 HDMI setting instead of the usual 1920x1080 and continues with the boot with sound but a black screen. Tried a number of times with different HDMI cables. Same result.

    Looks like EDID is not being being recognised correctly on initial boot. No such issue with 10.04 stable.

    I just reverted to 10.04 and all is well. I’m just reporting my findings in case it’s useful to anyone.

    I'm having a rockpro64 myself and actually can't reproduce this with my board.
    Could you pls add drm.debug=0xe in extlinux.conf and run pastkodi after a reboot?

  • How to make buildin wifi work on NanoPi NEO4 ?

    Thanks for checking.

    It looks a lot like we are currently only supporting NanoPi M4 https://github.com/LibreELEC/Libr…elper#L306-L309, but not NanoPi NEO4.

    That's likely also the reason, why wifi isn't correctly working with M4-devicetree for you.

    It might have worked before, since we did use RK's vendor DDR initialisation and kernel side DT-differences are minimal. However, I'm fine to add support for your board if you open a pull request - it's supported both upstream kernel and upstream u-boot. Hint: it's rk3399-nanopi-neo4.dtb as kernel device tree and nanopi-neo4-rk3399_defconfig as u-boot config. Please build before and check if it works correctly..

  • RockPro64 SPDIF/TOSLINK

    That's actually pretty easy to achive:

    RockPro64 devicetree has all i2s engines enabled by default: You'll just have to disable the unused (i2s0, iirc - i2s1 is used for the analog codec and i2s2 for hdmi) and enable spdif (and spdif-dit). Reason behind is, that the dma controller does not support all channels which are connected to it at the same time and the upstream pl330 driver does not support virtual channels (yet).

    Also you should check if the second pin of the spdif header outputs the voltage (> 3V) which is needed drive the optical output (maybe there is another pinctrl required - check schematics for that) - or try first by connecting via coax by using spdif_tx and gnd only.

  • Rockchip RK3568 + RK3566

    Quote from PANiCnz

    do you think they'll get mainline support? or perhaps LE too?

    Despite theses SoCs were release just a few month ago - they are already supported in mainline kernel - check https://github.com/torvalds/linux…hip/rk356x.dtsi which parts are already there (also in mainline u-boot).

    Main reason they haven't been added to LE yet: The missing driver for the display controller which is entirely new and adding it will be kind of a huge effort. Adapting video codec drivers should be relatively easy as they are "just" an evolution to the previous ones.

  • HDMI-CEC work on PINE RockPRO64 until TV goes off and on cycle

    Quote from xleox

    Thanks for the promising news!! Unfortunately I can't test the img. My box is a RockPro64 (RK3399), not a Rock64 (RK3328).

    This fix has been merged last couple of days and it's included in RK nightlies available at https://test.libreelec.tv/.

    I guess (hope) it was the same issue for all of you. Note that CEC is not available immediately after TV is swithed back on, you'll have to wait some secs (depends on TV) ... for debugging: https://github.com/LibreELEC/Libr…mment-944993387

    maddoxik  munninen  TV_Guy  Adr3nal1n

  • HDMI-CEC work on PINE RockPRO64 until TV goes off and on cycle

    Quote from maddoxik

    Nevertheless, I checked the issue again and found that just restarting Kodi systemctl restart kodi.service solve the issue. Which points me to suspection that the issue is not in the hdmi-cec driver itself but somewhere in the Kodi, or maybe specificaly in libCEC library/addon.

    This is actually very helpful, thanks for reporting.

    Have you tried playing with any of those CEC-settings in System->Inputs->Peripherals->CEC Adapter - espacially those for "When TV is switched off" or "Action when switching to another source"? Sorry that I can do only guesswork here again: Since I can't reproduce this issue here, I can only guess what eventually needs to be changed.

    (Not sure it is required, but better restart kodi after changing any of these settings)

  • Rock Pi4 Plus

    Quote from radoskur

    I'm going to buy Rock Pi4 Plus (4GB RAM / 32GB eMMC). Are there any major problems with libreELEC on this device?

    I submitted the device tree for this new variant recently (having one myself) and it will be part of linux 5.15 - I backported it to 5.14 and it will be in LE after [Allwinner,Generic,Rockchip] linux: Update to 5.14 by heitbaum · Pull Request #5558 · LibreELEC/LibreELEC.tv · GitHub - however the device will have to be added - no problem I could report of.

    Quote from mo123

    LE has no support for HD Audio passthrough for Rockchip and no one is working on it. which is sad.

    This is not limited to Rockchip.

    From what I have understand: upstream kernel and/or alsa libs currently do not provide the interfaces at least for dw-hdmi to implement passthough which is used for Amlogic, Allwinner and Rockchip (and some more) - as soon there is a solution for any of those - there will be one for Rockchip (one of the massive advantages upstream development has)

    Quote from Mikhail

    There is one significant issue on the LibreELEC 10 (and nightlies LE11) on the RK3399 SBC, intermittent clicks in sound when hardware decoding is enabled.

    You've repeatedly said this now - could you please stop complaining and provide any proof, logs (pastekodi), example videos, whatever for us to reproduce this? Thanks!

    Quote from Mikhail

    it's a pity that only one person is working on the Rockchip SOC.

    While this might be true for LE - its certainly not true for Rockchip kernel devlopment overall: There are hunderts of developer working for/on Rockchip SoCs upstream kernel including "opensource companies" like collabora (LE team has good contacts to some of those devs), Rockchip employees (what is relativly unique for a fabless chinese ARM SoC vendor, at least for those used in LE), and LOTS of contributors (like me) - which we automatically benift from here - just check Rockchip maling lists (those can be used for reporting bugs also, btw.) Though, their priorities, what to do next, might not always match yours.

  • Rock Pi 4 and old Sony TV

    Quote from Mikhail

    why does the driver choose YCbCr color space by default?

    Its just the way the upstream driver works (YCbCr is the default as per HDMI specs) - we had a workarround for that in b1/b2 releases since colorspace conversion was broken (driver preferred RGB).

    Quote from Mikhail

    So far, I see only one solution - to make a custom EDID specifying YCbCr

    Only way I'm seeing also: Your TV should not announce YCbCr , if it is broken. Or even better: treat yourself and get a working TV - you will see this issue with everything which implements HDMI specs correctly.

    Quote from Mikhail

    In LibreElec 10, you really need to make it possible to manually select the pixel format for the Rockchip SoC, as, for example, in OSMC for Raspberry Pi 4

    You should start to understand, that this project's main goal is to use (only) upstream software - which increases compatibilty and future support in so many ways. This is currently a limitation of upstream(!) drm framework - we could do something like that our own, but nobody has a intention to do so (it would be a waste of time and will get dropped whenever there is a upstream solution)

  • need help for extending libreElec

    Quote from CvH

    I am not sure if this can't get automated, maybe knaerzche knows.

    After (hopefully short after) final LE10 is released and I (or someone else) has enough time to test everything Rockchip project will (finally) switch to mainline u-boot where we can use device tree overlays (they'll make it possible to inject stuff to device trees)

  • Cracking / Popping audio - HDMI - LibreELEC (official): 9.95.1 (RK3399.arm)

    Quote from tony013

    Could it be, that the kernel module for sdhci isn't enabled yet?

    Nope.

    Quote from tony013

    Could you tell a bit about your experience with rockpro64?

    That actually the RK3399 board I'm developing with - I never had any sound issues nor emmc issues (I'm using an emmc module for booting LE there, too)

    For the emmc issue on rock pi4: I won't waste yours and my time with further attempts to make it work until I actually have a board.

  • HDMI-CEC work on PINE RockPRO64 until TV goes off and on cycle

    Could you try this image: https://mega.nz/file/yTIWTD7Q#…w6ozjcyeM02jLNY

    Please take a spare SD card and flash it there. Note: Since I can't reproduce your issue, I just compared the vendor driver with the current upstream driver and tried to find a difference that could have an impact - so: no guarentee it will change anything or even make it worse than before.

    If it doesn't work either: remove the cec.debounce_ms=5000 in extlinux.conf and check if that changes anything.