Posts by axel

  • LE13 RK356X build issues using docker (podman)

    Thanks chewitt , as i've said elsewhere i understand and agree with the policy of not supporting issues with that drivers that can't be included in LE.

    I'll check the MAC address, could be that. I've see this happen on my rock4 se too, where LE "forgets" the wifi, so thought it might be linked to a more general bug. Let's see what's going of first.

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

  • LE13 RK356X 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).