Posts by gonciarz

    Hi chewitt
    Thank you for sharing that detailed explanation; it's really helpful in understanding the broader context. I wasn't fully aware of how Armbian operates, especially in terms of its approach to vendor kernels and patches. I can see how their focus on industrial use cases and hobbyist needs can lead to some compromises that wouldn't suit everyone. Like you, I also much prefer working with changes directly in the mainstream kernel—it feels more robust and future-proof.

    I do appreciate LE for its clean and lightweight approach, similar to Gentoo in its philosophy of building from scratch. While it's excellent for running Kodi as a dedicated appliance, I've often thought about ways to integrate it more seamlessly into a general-purpose system, perhaps via AppArmor or similar. The idea of not wasting resources on dual setups is appealing.

    Regarding the RK3588S2, I misunderstood the relationship between it and the RK3588 at first, thinking it was a bit different SoC and GPU. Thanks for pointing me to the GitLab link. I have seen it before. It's great this SoC becomes so well supported.

    I'm not in a rush to replace my Odroid C2—it’s still serving me well for now—but I’m exploring options for when I do need an upgrade. Actually my NanoPC T6 LTS (RK3588-based with AV1 support) has just arrived, so I’d love to contribute to testing where possible. Let me know how I can help!
    But thanks for pointing RPi5. That may be a great fit for my family.

    Thanks again for your insights, and my apologies if I misunderstood or came across as dismissive earlier.

    Hi, I'm considering buying a budget SBC (~90-120 USD including all accessories to launch it) for my family:

    Tech spec: https://radxa.com/products/rock5/5c/

    There are two variants:
    - Radxa ROCK 5C (SoC: Rockchip RK3588S2, GPU: ARM Mali G610MP4)
    - Radxa ROCK 5C Lite (SoC: Rockchip RK3582, no GPU)

    Multimedia:
    H.265 / VP9 / AVS2 decoding up to 8K@60fps, H.264 decoding up to 8K@30fps, H.265 / H.264 encoding up to 8K@30fps

    Kernel:
    RK3588S2 is merged to mainline kernel 6.3.

    I'm not sure about Mali support. Google mentions:

    Quote


    As of March 2017, proprietary drivers for Midgard devices (including Mali G610MP4) have been packaged in Debian’s non-free section. However, starting from Debian 11 (Bullseye), the proprietary driver packages have been removed due to the inclusion of a free driver in Mesa.

    Do you have a support for this device on your road map?
    It has platinum support in Armbian.

    What do you think?

    It seems that an old dd works as a charm, so there is no special need for anything else.
    Initially I experience some errors writing an image and my SD card couldn't properly boot.
    Then I used the same card with the same USB reader on another hardware and it works. Magic ;)

    But, anyway here is a short description I believe should be published in the download/installation section for linux:

    Code
    1. Find a correct disk in my case it was /dev/mmcblk0, but will use /dev/sdX
    2. Check mounting points: mount | grep '/dev/sdX'
    3. dd if=/dev/zero of=/dev/sdX bs=1M count=8
    4. sync
    5. download the image (e.g. LibreELEC-AMLGX.arm-11.0-nightly-20230204-7beffea-odroid-c2.img.gz)
    6. gunzip -c image.img.gz | dd of=/dev/sdX conv=fsync bs=4M
    7. sync

    You may optionally verify saved bytes using a similar approach (just decompress an image first) :

    Code
    dd if=/dev/sdX bs=512 count=$((`stat -c%s image.img`/512)) | md5sum
    dd if=image.img bs=512 count=$((`stat -c%s image.img>`/512)) | md5sum
    Quote

    Thanks Robert, i've tested on Plasma Wayland and it works fine

    Thanks for a quick feedback.

    Quote

    Unfortunately shared Qt builds are simple. Static is something else

    I'm aware about it. Static linking is doable but requires some time to make it done. I'm not sure I will invest in that now at least not using ArchLinux as this is a rolling distro that rather avoids static linking.

    Quote

    To release official LE binaries we need to build Qt6 "static" to avoid depending on sizeable Qt packages. Since the codebase was bumped to Qt6 I've not stumbled upon a working Qt6 static build recipe for Linux.

    I updated the dependencies to QT6 and adopted the code.

    @herrmeier / chewitt Feel free to check the newest package.

    Quote

    Nice, but I have no plan to install Arch Linux to test a single package. If you created it, you need to test it

    No worries, I've just CC-ed you because you are one of the active members here. I've already tested a build process on bootstrapped system in chroot, but I believe I need to add there some runtime dependencies as you use other packages in your code, spawning system processes.

    Quote

    To release official LE binaries we need to build Qt6 "static" to avoid depending on sizeable Qt packages.

    I wouldn't release binaries, because this tool requires a root access. Distributions and package maintainers can support. You may just a mentioned in the documentation, that ArchLinux's package exist. It doesn't need to be official. It's ambivalent for me.

    Quote

    Since the codebase was bumped to Qt6 I've not stumbled upon a working Qt6 static build recipe for Linux.

    I will have a look if I may quickly update QT dependencies.

    I'll also test an old-fission dd. I believe that would be the easiest approach for Linux users.

    If we don't need to do anything specific for u-boot, then dd an ISO image is rather straight forward.

    I'll test it within few days on my Odroid C2.