Posts by chewitt

    On GXBB (S905) devices BL1 checks for BL2 in sector 1 of emmc first, then sector 512 of SD and USB media. You can install mainline u-boot to the emmc device but then you cannot partition the emmc storage with MBR/GUID schemes as these store data in sector 1 breaking BL2. You can still partition emmc and run an OS from emmc but the device MUST boot from u-boot on SD card. The Amlogic u-boot works around this stupid stupid design by using a custom partition scheme; MBR with all data structures offset to avoid sector 1. This "works" but the scheme is proprietary and not supported by any normal partitioning or formatting tools. This limitation was removed in Amlogic GXL and newer SoCs which additionally check for BL2 in sector 512 on emmc allowing MBR/GUI structures to reside in sector 1 as normal with BL2 starting from sector 512.

    ^ TL/DR; the Hub/WP2 images in that folder are experimental and created for me to test mainline u-boot. Right now the Hub image doesn't boot (locks up) and I did not test the WP2 image (need to find the box first). The box(es) boot from emmc first allways, so you need to erase vendor u-boot from the emmc first to test these images. Then (and only then) the box will look for BL2 on the SD card and boot mainline u-boot from the SD card. To be clear. Anything you find in that folder is experimental and I provide no support. If you brick your box it's your problem not my problem to figure out how to recover things.

    If you have Khadas images using with vendor u-boot installed you can use the "box" image on SD card to boot LE, but this probably gives funky colours needing u-boot chainload to solve. Booting CE may also mess with the u-boot environment and cause issues for the box image. The "vim3" image is for writing to emmc only (once boooted from SD card). Chat to me in the #amlogic channel in Slack, it will be easier than forum posts.

    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.

    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.

    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.

    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.

    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.

    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.