Posts by chewitt

  • Libreelec problems

    As a rule we don't ban users unless they are abusive towards staff or they are spam bots, we simply refuse support and perhaps control threads to ensure others don't step in, to ensure forum rules are followed. Users (even the worst initial offenders) should always have the option to change their ways and redeem themselves with a clean/free-of-crapware system.

  • Official LE11 Test Images for Amlogic (Kodi-20)

    The Beelink devs have no more/less of a clue what the issue could be as anyone else. I've looked at their boot sources (with git history) and there's no smoking gun; the sources have the same Amlogic BSP baseline that Khadas and Hardkernel use with fairly minimal hacking to account for the normal things that are different between board vendors. I've also had them ship samples to people with the skills to hopefully figure the issue out, but those folks are full-time developers and we're asking them to investigate our weird problem for $free, so we'll have to be patient until they have some time to spare. I see "Beelink doesn't care" as a wrong statement. If they didn't care they wouldn't courier $240 products to people, or provide schematics and sources to developers who haven't signed an NDA, to help customers run an OS they don't ship and don't support.

  • Official LE11 Test Images for Amlogic (Kodi-20)

    Quote from darkstar

    Dear chewitt I tried your LibreELEC-AMLGX.arm-9.80.7-beelink-s922x.img.gz image on my gt-king-pro but no luck, it did not boot. I tried to change dtb setting to pro and again didn't boot.

    It's an image for emmc install (overwriting factory u-boot) not an image for SD/USB boot.

    Normally I'd suggest using the "box" image to boot, then erase the emmc or use "emmctool" to write the image to emmc storage. However there's an issue when booting from vendor u-boot and the mainline kernel under high I/O load (e.g. when writing the image) where the kernel deadlocks and this can leave you with broken u-boot. It's not impossible to recover from, but needs Amlogic burning tool or UART cables (the UART port is on the rear of the pro box) and a lot of faffing about to kill vendor u-boot to force boot from SD card. I've not tested it, but a possible workaround is booting from CE (which doesn't have the lockup issue) and using 'dd' to write the image to emmc.

    In general, anything with vendor u-boot should use the box image. I've mostly built the -beelink image to help the Armbian/Manjaro folks boot/run on the box using mainline u-boot to avoid the deadlock problem. LE still has the same issue, but since we are ultra-lightweight seem to mostly-avoid the problem. I had a sample shipped to one of the kernel maintainers to see if they can figure the issue out, it's beyond me, but it's a busy time of year so nothing was looked at yet. The same issue exists on all the Beelink S922X boxes.

  • Xiaomi MI TV sources

    It wouldn't be too hard to build the OS for the Amlogic sources, although CE is probably a better starting point since they already use the same Linux 4.9 kernel sources; the challenge is the lack of git history in what's been shared so good luck in finding which of 350,000 files has been fiddled with by the TV vendor. Mediatek is a total unknown. However the issue won't be kernel, it will be the boot environment. I'd be surprised if the bootloader was not encrypted. This normally rules out most tinkering. Also, we're happy to break Raspberry Pis and such, but I'm not sure anyone on staff wants the responsibility for bricking a users TV so it's not hardware we'd investigate.

  • KI Pro (S905D) Need to debug log run UART

    Current situation is improved from 2019 when previous post was written, but still a long way from a solution and those commits don't directly help.

    The demod chip is from Availink and we have now direct contact with them and they are (or were, no updates since the summer) working on a public release of their previously closed-source drivers and we/me persuaded them to publish under GPLv2 to things can eventually go upstream. They also have a pile of tuner drivers to work with their demod, although some of the drivers have dubiouos code provenance so might never be upstreamable too the kernel. The current missing pieces are: a) the large amount of work to deconstruct the Amlogic/Android style monolithic driver so that all the component driver bits are standalone/configurable via kernel defconfig (and thus correctly supporting upstream APIs), and b) somene needs to write a GBM/V4L2 compliant demux driver as the one from the Amlogic BSP is written around the BSP memory drivers, and c) someone will need to write a deinterlace IP driver, although that's easier and recent work on Allwinner to do similar provides some prior-art and clues on how to do it.

    Using the WP1 as the headend is by far the best idea, as the above ^ isn't going to happen anytime soon.

  • Meson 8* Lives!

    Nothing official and I appear to have deleted the local branch I did my initial experiments with. The upstream kernel repo is here: Branches · xdarklight/linux · GitHub but there are few device-tree files and converting ye olde 3.10 kernel ones is not the simple eyeball aand copy/paste job of newer hardware. There is also no mainline u-boot support for Meson8 so it's a little fiddly to come up with the changes to make the image. Progress is also rather slow and sporadic .. Martin has been rather busy with day-job work recently.

  • Kodi 18.0 Update for Slice.

    Quote from g7ruh

    there are at least 2 users still out here :):). Keep up the hard work on Slice, please.

    There are 79 of you in total (declining slowly with time). Currently there are no plans to release further Slice-specific images, e.g. LE10. I'm not entirely sure what the status of things is upstream and how realistic it is to configure Slice support using the RPi images. I think we hand everything back to the community to figure out.