Posts by chewitt

    If you are using one of the nightly images from Index of / there is a tool called "emmctool" in the OS to help with installing LE to the internal emmc storage. In short, you need to boot from any image to an LE console and then run:

    emmctool w /path/to/LibreELEC-AMLGX.arm-XXXXX-khadas-vim.img.gz

    The tool will then unpack and overwrite the existing contents of emmc storage with the specified image. If you are already booted from the AMLGX "box" image the tool is in the OS, and all you need to do is download the "khadas-vim.img.gz" suffixed image to /storage and run the command.

    The tool is considered experimental but has worked well for me in regular wipe/format boot tests. If it does screw up (it was writen by me so this is always possible) the provblem will be something wrong with partitions and naming. In this scenario you still end up with a working u-boot installed on emmc and can continue to boot from the "box" SD card to simply repeat the process.

    If you are using older "KVIM" images (our legacy codebase) .. support for them among staff is now rather limited and I would recommend you continue to run them from an SD card.

    Kodi support for newer Allwinner (and Amlogic, and Rockchip) hardware is a choreographed ballet of very recent kernels, mesa, ffmpeg and Kodi (19) items. You can backport kernel, mesa, and ffmpeg to an older LE release fairly easily, but then the Kodi version will not support the kernel drivers and ffmpeg correctly. TL/DR; You need to stick with LE master images. There has been a lot of indecision among add-on authors due to a long/protracted noegotiation about how to handle the Py3 version bump. There is now firm clairity on that from Team Kodi, and while not all authors will like the decision made, the decision has been made so the way forwards is clear, and that should result in more add-ons being converted.

    /flash/extlinux/extlinux.conf is not an equivalent to config.txt (RPi config commands won't work) but if you follow the instructions for Intel GPUs here Custom EDID [LibreELEC.wiki] the same process for forcing a specific edid.bin file (so the kernel drm framework always thinks an HDMI device is connected and powered) should work - Allwinner boards are also using the same kernel drm framework.

    FWIW .. I was playing the file from an NAS (SMB) device in the network using the low-spec on-board WiFi of the Hub. I'm not aware of any issues with USB read/write performance on Amlogic SoC's but I also never/rarely use local media with any low-power ARM devices; not because they're inherently bad, but because I swap between 20+ devices on a regular basis so everything's in a central place in the network to make that easier.

    If you set defaults to -Os it will optimise the image for file size not "running in RAM size" which is the issue. LE sets -O2 which is sensible.

    And .. every couple of years some user discovers this wonderconfig they read about called zram, makes a lot of noise, and rushes off to do extensive performance testing that proves zram has negligible/zero benefit in our distro. Boards under 1GB don't have enough RAM to really benefit from loading more things into RAM and 1GB+ we already run everything in a ramdisk so forcing zram use only adds additional overhead.

    If I add "mem=512M" to kernel boot params on an S905 device Kodi faults with this error ^

    So unless there are improvements to RAM utilisation in the OS or specifically the video stack, Kodi cannot run on 512MB LaFrite devices. I've flagged it to a couple of the developers, but since we are refusing to support 512MB Allwinner devices as being "too small for sensible Kodi use" and the long-term message on RPi 512MB hardware is similar (we will drop support for RPi0/1 sometime soon) I wouldn't expect a surge of activity .. sorry.

    ^ as long as these are set in device options you shouldn't need to change anything else in the build-system *BUT* you will need to make a clean build (remove the entire build.LibreELEC* folder) to ensure the kernel is not build with lima and that all userspace symlinking and compile-linking against EGL and GBM libraries is handled correctly. Your description makes me think you've built with a mesa configuration and then done the switch to mali without doing a clean build after?

    NB: It's also worth bumping to mesa HEAD to pick-up all the improvements made since 20.0.x .. lima is still under very active development with small incremental improvements on a weekly basis. It would be a shame to go back to blobs.

    Here's my $0.02 theory: Over time the kernel has evolved better power management which means more hardware can go into deeper sleep states. This is great for power efficiency during suspend/sleep but means you might have to apply some configuration to ensure the NIC (or entire device) remains at a high enough sleep state to still receive the WOL packet. I have a huch that the move from older to newer kernel effects the change. I haven't been using x86 kit for aeons so have no idea how you'd prevent deeper suspend/sleep, but it's something to investigate.

    Users tend to focus on "my device can do 802.11b/g/n/ac" but in reality WiFi is a lot more nuanced than "n" and "ac" as each country can (and most do) set their own wireless regulations which dictate the radio properties a router can legally use in that country. Until recently forcing a specific country has been a very occasional thing which is why it's remained an SSH console hack. RPi4 appears to be changing the requirement; more users are using its built-in WiFi as it's more usable (RPi3/3+ aren't good for WiFi) and there are a lot more users (RPi4 is popular) and it's somewhat important to set the radio properties of the WiFi card to match the router if you want everything to work correctly. LE master branch (will be LE10) already has the config setting moved to the GUI. Next step will be to add something into the setup wizard. If we create a 9.2.3 release (not yet, but if/when Kodi do an 18.7 releasae we'll bump) I'll ask for the first part to be backported.

    I had issues booting GT-King Pro using the original Android factory firmwares as Beelink tweaked the u-boot environment to minimise the point in the boot sequence where u-boot waits for input (e.g. IIRC the power button on the Pro being pressed). This makes the boxes boot a little faster, but also makes them a pain in the rear as you need to press the button at exactly the right time (measured in ms) to invoke restore mode; then u-boot checks SD/USB media for images and finds LE and boots. The official response from their developers is "keep pressing the reset button during boot" and after a few attempts you'll get the timing right. More recent Beelink firmwares appear to be easier to interrupt and work with so I assume they increased the wait period a little. I forget which firmware I have installed now (as only booted it once or twice) but it was from ~October ish last year. It's a nice box once you get over the install hurdle :)

    The /storage/.smb/smb.conf location is not used anywhere in modern versions of LE .. use /storage/.config/samba.conf (rename the sample conf) and set the following values (notice they are uncommented):

    # The following are default values for the master selection process

    local master = no

    preferred master = no

    domain master = no

    os level = 100

    reboot to make the new config active; if /storage/.config/samba.conf exists it is used in preference to the embedded one.

    This will not prevent one of the LE devices from being elected master in the event you turn off the server master browser; the system works to always have one elected master. However, with that config and the high oslevel value (lowest is better in an election) the LE devices should conceed the election to the server quickly when it reappears, although quickly is not a word that should be used here.

    Check cables .. that's always a source of potential issues. You could also put the AMLGX image at Index of / on a spare SD card and see what things are like under tthe mainline kernel. Video playback in those images has some challenges, but we're interested in HDMI stability, so testing a completely different (but familiar looking) OS on the same hardware might rule in/out a hardware fault.

    My recommendation would be to test playback over SMB or NFS .. as this isolates the issue to WebDAV. If it works over SMB .. you can take the issue to the Kodi forums as it's their WebDAV code that's the issue. NB: I'm not sure anyone in current Team Kodi uses WebDAV so it's probably not a well-maintained feature, hence the suggestion.