Posts by axel

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Sadly, this happened both with the out of the box /storage/.kodi from building LE, and then again with one i plucked from another working arm64 LE box (a Rock 4 SE) that i copied over to the microSD card to bring over all the config.

    In the first case, the timeout was set to 30 min by default and that's when it happened. Testing with the second config, it happened after 5 min which is when the timeout for the screensaver is set.

    chewitt how can i rebase my build on the same commit as you built your latest test builds, to make sure i'm using the same code as you, with only the annoying aic8800 driver package as a difference?

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Is anyone else running into an issue where the screensaver kicks while playing a video, and it's not possible to get out of it? (I've not found any way out than to reboot using Kore or over SSH) This is on my custom build built from Github main branch two weeks ago (2026-04-15), but the only thing different is adding the (annoying) aic8800 wireless driver, so you'd expect this to have no bearing on video / screensaver.

    It's happening while set to "dim". I'm going to test with another screensaver, like the weather page, to see if it makes a difference.

  • [RK356X] AIC8800 WiFi driver build issues using docker (podman)

    Quote from 25characterslong

    You mentioned this is "rootless".

    This just means that podman runs the containers used to build LE not as root but as my regular user.

    Quote from 25characterslong

    I would also check the router and see what the DHCP lease time is, and whether that matches the time before the connection is dropped. There may be something in the router log about failed lease requests.

    The zero 3 gets the same rules as everyone else, so it shouldn't drop wifi anymore than any other device, which is not at all :)

    Right, so i have a working build, built on top 12.0.0-7184-ge59019e505 (about 3 weeks ago). But the driver looks flaky as hell. As I'm testing this out a bit more i see that something like 3 out of 4 times, after booting, there is simply no networking interface that the LibreELEC add-on's "Connections" menu can see.

    This means without a USB keyboard plugged in, the Radxa Zero 3W is entirely useless.

    Going to bust out the USB to UART serial console cable and see if i can get anything useful.

    Out of curiosity Yasai-san are you also having issues?

  • [RK356X] AIC8800 WiFi driver build issues using docker (podman)

    I was able to build a release image ready to write to a micro SD card (using make image instead of ./scripts/image image), write it and then start from it. And on first run, it prompted me to connect to wireless networks and did so successfully, so that's very nice.

    However, when coming back to the device a few hours later, it had forgotten the wifi password as it was asking for it again. The device was no longer reachable on the network either. Is this a known issue? is there a place to track this bug?

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Yasai-san I've managed to build an image of LE13 for RK356X for my Radxa Zero 3 thanks to your work. Many thanks!

    I rebased on master, and tried to bump the aic8800 driver from the radxa-pkg/aic8800 repo from 4.0~ to 5.0~, but it failed to build. ie:

    Code
    PKG_VERSION="5.0+git20260123.5f7be68d-4"
PKG_SHA256="58c4c1ee085fac7971e9972dba99c5e3207e1ea0991c3f957bd9200f6ec8fbe7"

    Two questions:

    • Did you pick 4.0+git20250410.b99ca8b6-5 specifically, or was it just the latest when worked on this?
    • How did you figure out the right targets in projects/Rockchip/packages/aic8800/package.mk?
      • When trying to build 5.0+git20260123.5f7be68d-4 i had to comment out the pre_make_target for linux 6.12 as that build patch is missing and it then failed anyway with another error.

  • [RK356X] AIC8800 WiFi driver build issues using docker (podman)

    Hello,

    I'm trying to build LE13 with the aic8800 wifi driver, following the great work by Yasai-san (cf. https://github.com/ShigeakiAsai/L…er-and-firmware ) however, the build is failing.

    I've build the Trixie image and am now trying to build with the following command:

    podman run --rm --log-driver none --userns=keep-id:uid=1000,gid=1000 -v `pwd`:/build:z -w /build -it -e PROJECT=Rockchip -e DEVICE=RK356X -e ARCH=arm libreelec scripts/image image

    This is on a Fedora 43 host. --userns is needed to as this is rootless podman, and the :z in -v `pwd`:/build:z ensures SELinux labels are relabelled accordingly to allow processes in the container to access and use the files.

    The build fails at step 95/315: build Mako:host:

    Looking further in the logs doesn't give anything immediately useful.

    build.LibreELEC-RK356X.arm-13.0-devel/build/glibc-2.43/.armv8.2a-libreelec-linux-gnueabihf/config.log shows:

    Am i missing something obvious?

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Quote from chewitt

    axel I've spoken to Radxa about the AIC8800 wireless chip a couple of months ago as it's also fitted to one the boards I've been using to test. Radxa have no plans to upstream the driver as this would require a large effort, i.e. complete rewrite as the current quality of driver code would never be accepted into the kernel, and after years of working to rid our codebase of the maintenance burden of downstream (mostly Realtek) drivers we have no desire to add technical dept in the form of another vendor driver that has no plan to be upstreamed. I've shared our surprise/annoyance and position, and have strongly suggested they stick to using Broadcom, Qualcomm, Realtek (now upstream) chips in future iterations of current boards and future board designs so distros can avoid the need for crap drivers. I'm not sure LibreELEC's opinion will carry much commercial weight with them, but from our side, there's no action to be taken.

    Thanks for the detailed answer, it's appreciated. I understand and support your position, from a LE project perspective.

    From a "how do i get this device to do what i want" perspective, it sounds like i need to learn to build LE and add the driver in my image, to get it to get usable wifi? or add an external wifi adaptor, which is a lot simpler, a bit sad considering it has onboard wifi, and not as fun (probably type-2 fun though, lets' be honest). Or run Armbian / Radxa Debian and make it boot into Kodi.

  • Kindly add NFSv4 support!

    I just tried Milhouse's latest LibreELEC build, and there is no OS level NFSv4 support.

    But there is Kodi-lever support, which I think is what the logs refer to.

    Thanks CvH, great to see NFS kernel support work happening. That would really be a superior option to mounting via Kodi!

  • Kindly add NFSv4 support!

    Hi. I'd just like to clear this up and check I've got it right:

    • there is currently no NFSv4 support in LibreELEC because of limitations with busybox (tested and confirmed in the current latest stable: LibreELEC (official): 8.2.5 (Generic.x86_64))
    • there is NFSv4 support in community builds such as Escalade's (along with a wide selection of extras)
    • there is NFSv4 support in test builds by Milhouse, such as this Kodi 18 Leia build #0111 (cf. change log)

    So my choices are to go with a community build or a test build, to get NFSv4 support.

    I also understand that Milhouse's test builds are designed to test features that will be included in LibreELEC official, so does this mean NFSv4 is planned to come to LibreELEC official? This is in contradiction to what Irusak was saying:

    Quote from lrusak

    possibly in the future. However busybox mount does not support nfsv4 so it would require switching to util-linux and adding nfs-utils which isn't really desired at the moment.

    Clarifications welcome :) Thanks!

  • USB-SD creator is not able to run as root

    Quote from dahmage


    I just had this issue after upgrading from fedora 24 to 25. the only difference i know of is that now i am using a Wayland session instead of X? this trick worked, but i wonder if it is a wayland related issue.

    Yes, this completely has to do with Wayland, which is now the default graphical server in Fedora 25.
    Wayland, by design, does not let another user (root in our case) access what our user is doing in their session on the graphical server. So when root tries to open its window in another user's (ie: our user's) graphical session, Wayland (rightly) denies it.

    The fix suggested,

    Code
    xhost +


    allows any and all users to access the current users' graphical session.

    If you find this a bit much, you can allow only root to access your current session, with the following:

    Code
    xhost si:localuser:root


    Once you've finished using the app you want as root, you can remove root from the list of allowed users with:

    Code
    xhost -si:localuser:root

    Hope this helps. At the end of the day, a better solution (using the suggestions in this bug: Bug 1274451 – sudo with graphical apps doesn't work on wayland) should probably be used, as this is really just a workaround (and end-users shouldn't have to be doing this).