RPi5 kernel development image

    If you found some pre-compiled module somewhere on the internet then you are stuck with trying to use a specific kernel version as the 'version magic' must match for the kernel to load the module.

    Unless the driver code is shockingly bad: If you're going to compile the out-of-tree module (as you have stated) it can be built against whatever kernel version is latest/used in our buildsystem and you don't need to care about the version.

    NB: User attempts to shortcut compiling in our buildsystem "because compiling an image takes ages" with some module compiled outside our buildsystem "because it'll be quicker" usually result in the user expending considerably more time/effort/frustration on the shortcut than just compiling the image in our buildsystem would have taken.

    chewitt Thanks.

    Quote from chewitt

    NB: User attempts to shortcut compiling in our buildsystem "because compiling an image takes ages" with some module compiled outside our buildsystem "because it'll be quicker" usually result in the user expending considerably more time/effort/frustration on the shortcut than just compiling the image in our buildsystem would have taken.

    Despite being a professional software developer, proficient in bash, too, and docker/podman and everything, I have avoided compiling (esp. cross-compiling) drivers myself my entire life - probably due to several traumatic experiences in the early 90s. In this field, I'm nothing more than a noob who, after 4 hours of nonsense, finally sought help from ChatGPT - with the result that the whole thing took either a day longer or a days shorter (I'll never know which). ChatGPT made me ask this question. I'm truly sorry that this question was apparently dump. At that time, I had downloaded about 80G of data, and compiled in total for about 8h at least. Much of the code was compiled multiple times. In any case, the traumatic experience repeated itself. But we made it - it works now. However, I have no idea why. I only know that I overcame about 30 insurmountable hurdles, like blacklisting an ancient vendor via `/etc/udev` . Shortly afterwards, a new LibreELEC version came out and the fun started all over again. It didn't take as long, but it was way enough to crush again any positive mood that day. Now I ended up in having a big mess of files and folders that I really want to delete. It's all chaos. Unfortunately, this mess represents 2d of work (noob work, perhaps 45min for someone with your knowledge).

    What's all this about?

    It's about a USB dongle that ships together with the official Xbox One controllers: https://github.com/dlundqvist/xone

    I couldn't find an existing driver, so I have created the addon driver ZIP file myself.

    Now that I have everything together, is it possible to get the add-on officially built into LibreELEC? What would I/sbd need to do for that? All of this has overwhelmed me and taken away all my motivation to go back there again. But I would. I think it's a good timinig in general, because of the new steamlink addon(s) for Kodi.

    I have

    • package.mk
    • bin/install
    • meta/addon.xml.in
    • meta/changelog.txt
    • meta/README.md
    • system.d/service.xone.service
    • udev.d/99-xone.rules
    • a firmware driver that needed to cabextracted: FW_ACC_00U.bin

    If you are proficient in Docker then it should be trivial for you to use the Docker files in tools/Docker that result in a pre-configured and working build environment for creating an LE image. Once you have a working LE image, add a package for the xone driver and build it into the image and push the changes to GitHub/Gitlab etc. so others can see the package.mk recipe.

    It is not impossible to build a driver add-on, but the general challenge is that kernel modules must have the same 'version magic' as the running kernel, and in LE the add-on repo version is loosely aligned to Kodi API version and not kernel version. This means for each add-on repo version users will have a range of different kernel versions in use. The kernel's media-tree used to support 'media build' which provides a method for compiling and running 'DVB' kernel modules from an older codebase to run on a newer kernel version. LE has previously used this to package a bunch of DVB drivers for e.g. TBS cards as an add-on. We have since stopped doing this because it's a pain in the rear to maintain, but the prior art still exists in the buildsystem and you could use the same approach to create an add-on for the Xone driver.

    Quote from chewitt

    If you are proficient in Docker then it should be trivial for you to use the Docker files in tools/Docker that result in a pre-configured and working build environment for creating an LE image.

    What is needed is a shell script which creates complete build environment without even knowing or understanding docker. No messing with building docker container and other stuff. Just start a script which creates docker environment with a shell. And then development works just like on a host directly. Lately I use such approach for different projects and works great. Last one is small GO dev environment :)

    Code
    docker run --rm --log-driver none -v `pwd`:/build -w /build -it libreelec make image

    ^ from documentation, no script required. User claims Docker proficiency so you have to draw the line somewhere /shrug