Nightly images for A64, H3, H5, H6 and R40 boards

    • Official Post

    Is there a chance for official NanoPi K1 Plus support?

    Only boards which are or will be officially supported by Linux kernel can be supported. Somebody must submit DT upstream and once it's confirmed, we can talk again.


    Note: We don't accept additional out-of-tree wifi drivers anymore. It's also stated in first post of this topic. In short, unless someone manages to include rtl8189ES driver in Linux, it won't be supported.

  • CEC-adapter (firmware 4.0.7) not workong on OrangePi Plus.

    Libreelec Version: LibreELEC-H3.arm-10.0-nightly-20210705-3010e06-orangepi-plus.img

    TV: Panasonic Viera PR50ST50


    CEC firmware 4.0.4 on Llibreelec 9.20 working fine with this hardware

  • Allwinner H6 has crazy stuttering in default.


    Two options help - setting dirty region to 0 and using EGL instead of Direct to Plane.


    Default = crazy stuttering

    Direct to Plane + 0 = almost no but still there

    EGL + 0 = I don't perceive any stutter in pan view


    Problem with EGL, though, is that it fails to trigger HDR mode on the TV. =/

  • Am I the only one having network problem with my Tanix H6 when returning from standby? The player is answering to pings but Kodi shows the wrong time and has no access to file shares or PRV backend.
    This happens mostly when the system was longer than 20-24h in standby and happens with these nightly builds as well as with the current audio passtrough testbuild.

    • Official Post

    Am I the only one having network problem with my Tanix H6 when returning from standby?

    I never observed any issue with ethernet after resume, but I'm not sure if I ever tested network access after being in suspend that long.

    Anyway, I added some code which completely turns off Ethernet PHY at suspend and completely re-init it at resume. Please test this update:

    Index of /test/ac200-suspend/

    source: GitHub - jernejsk/LibreELEC.tv at ac200-suspend

    EDIT: scratch that, I found some issues...


    BTW, which wifi chip is on your board? There are many variants of this board and 3 different wifi chips are known. I'm working on mainline driver support for all 3, so I would like to find people with all variants for testing.


    Allwinner H6 has crazy stuttering in default.

    I can't really agree with that. There might be stuttering with *some* videos, but not all. At least if they are HW decoded. Tweaking GPU settings sound like your video is SW decoded. Can you tell more about videos you watch? Like which codec, framerate, etc. Enabling debug log, watching some video and then posting log here (preferably via pastebin or similar service) will clear some questions I have.

  • ElwoodSC I prepared better test update, just follow links in previous post to test it.

    Thank you very much for that - I will test and report my findings! :)

    To elaborate a little more on the issue: To me it seems more like a Kodi issue than a OS issue, the player answers to PINGs as soon as it resumes from suspend but Kodi shows a not NTPed time on screen and is not able to access my PVR backend or my SMB-shares with movies.

    I found kodi-waitonnetwork: enabled by default with 10 sec timeout / use NTP for Online Status by mglae · Pull Request #4802 · LibreELEC/LibreELEC.tv · GitHub which comes quite close to my problems - but the fix is already included but does not work completely with my Tanix H6. Just to test it I disabled the WaitOnNetwork yesterday jut so see whether is does make a difference.

    • Official Post

    Wait on network is used only at boot if I'm not mistaken. It's meant to wait on network to become available, so all addons, which depend on network availability, can work. If anything, you can try with longer delay, I wouldn't disable it in your case, since you're using PVR backends and SMB.


    Anyway, please try test image anyway. If nothing else, it should lower power consumption, since it disables Ethernet PHY in suspend.

  • Anyway, please try test image anyway. If nothing else, it should lower power consumption, since it disables Ethernet PHY in suspend.

    I installed your testbuild (maaaany thanks for your support btw.) yesterday and tested it - unfortunately it does not change the odd behaviour of not using the correct time after suspend. Here is a journalctl -o short-precise from just now, as you can see from the timestamps the system is hanging behind 83 minutes and it takes (in that case) 3 minutes to correct the time. On other occasions it took much longer - mostly I lost patience and just rebooted the system. On reboot I always have a correct time.


    • Official Post

    ElwoodSC If I understand correctly, clock difference is the same as the amount of time spent in suspend state? If that's true, then RTC is accidentally stopped when transitioning to suspend state.


    Note that Tanix TX6 doesn't have dedicated RTC oscillator on board. It uses internal RC oscillator, which has terrible precision. Drift can be 0.5 second or more per minute.

  • Hmm, no, it is not that obvious - I switched the player to standby yesterday at 23:06 and started it this morning at around 10:56. When started it was thinking it was 83 minutes earlier until after running for three minutes it synced NTP to the correct time (at 09:36:50 in the log).
    I guess if NTP sync would be in the resume from suspend stack than the problem would be gone. From my point of view I can't the a logic to when the ntp-client tries to sync time.

    When it is just running it seems to ntp every 17 minutes - that would explain the wait time after a resume from suspend.


    Code
    Jul 26 21:10:47.744371 mediawz connmand[506]: ntp: adjust (slew): +0.015361 sec
    Jul 26 21:27:51.744636 mediawz connmand[506]: ntp: adjust (slew): +0.008531 sec
    Jul 26 21:44:55.740670 mediawz connmand[506]: ntp: adjust (slew): +0.004358 sec
    Jul 26 22:01:59.716942 mediawz connmand[506]: ntp: adjust (slew): +0.001634 sec
    Jul 26 22:19:03.744245 mediawz connmand[506]: ntp: adjust (slew): +0.000759 sec
    Jul 26 22:36:07.676150 mediawz connmand[506]: ntp: adjust (slew): +0.000785 sec
    Jul 26 22:53:11.738523 mediawz connmand[506]: ntp: adjust (slew): -0.000112 sec
    • Official Post

    That's about 1.43 seconds per minute drift, which is about right for imprecise RC oscillator. Only thing we can do about it, is to run NTP sync right after resume, as you suggested. But to be honest, I'm not knowledgeable enough about systemd services to fix that right away. I'll check few sources...

  • Hi, I'm trying to troubleshoot HDMI-CEC not working on my Orange Pi Plus 2e (H3) with my TV's remote. I can see from previous replies that CEC is problematic; was wondering if the issue I'm seeing is something different from the commonly appearing one(s).


    Outputs of cec-ctl -S and cec-client:

    External Content pastebin.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    As far as I can tell from cec-client, CEC transmission fails with errno=64 aka ENONET. (I cherry picked this line from the log, but may be been wrong about it's importantness)

    Code
    CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64


    And the physical address in cec-ctl is f.f.f.f, which I would imagine may be an indication of an initialization error?


    I'm on the 20210801 nightly, linux 5.10.47. If there's any further way I can contribute by testing/troubleshooting, please let me know.

  • Hi jernej it's me with the sd card boot issue again. I gave up trying to fix my issue since even a usb ttl couldn't help me. But now I searched for the problem and found an issue where the sd card didn't get enough voltage from bootRom it got 2.8V but it should be 3.2V. Could that be my issue here? The uboot github doesn't even have an "issues" section lol.

  • I have a box with allwinner H3 chip. The box doesn't have sd card slot, it only has 02 usb port and also reset button.

    I did try some H3 libreelec firmware on usb drive, but the box refused to boot to libreelec (it didn't appear or response anything on the tv, and the led light of box didn't come up as normal - it's blue when boot to android).

    Please kindly advise, how can I let my box boot with ny usb drive, or are there any steps in advance before plug in to the box?


    Thank you.

    • Official Post

    gkatev CEC is probably something that will never work in all cases. That being said, H3 uses SW implementation which should work with majority of TVs. I forgot details, but IIRC address f.f.f.f means CEC is not supported. Make sure it's enabled on your TV (common issue). Another possible reason would be AVR (if you have it). Try connecting directly first. At the end, you can also try different HDMI cable. Some cables may not have CEC line connected.


    okabekudo It could be voltage issue. That can be easily checked with voltmeter. Note that your box is not supported by Linux nor U-Boot and I don't have it, so you're pretty much on your own to figure this out. Strange issues are not uncommon for TV boxes due to cost optimizations. That's the main reason why Allwinner port of LE supports mostly SBCs and only 3 TV boxes which we have and test images on them.


    U-Boot development process is similar to Linux, which excludes any fancy stuff like issues on github. In fact, U-Boot github page is unofficial and just clone of official gitlab portal. Issues should be reported on mailing list with CCing respective maintainers.


    Uphantom88 USB drive is not supported boot media. Only SD card, eMMC, NAND and SPI NOR. LE supports only SD card and eMMC. You can open box up and check which storage is used. If it doesn't have SD card nor eMMC, you can forget doing anything with it. Even with eMMC only, it would be pretty tedious to boot LE over FEL (USB protocol used for "rescue"). As I said before, there is a reason why only few TV boxes are supported.

  • ...

    BTW, which wifi chip is on your board? There are many variants of this board and 3 different wifi chips are known. I'm working on mainline driver support for all 3, so I would like to find people with all variants for testing.

    ...

    Is there a way through SSH to determine what WiFi chip I have or do I have to crack open the box?


    Thanks