Posts by chewitt

    The Android box market moved onto newer/shinier things so S912 is long-forgotten as the top device in Amlogic's line-up, but there is still commercial interest in S912 from industrial users. LibreComputer is about to release a new board (tartiflette) and because GXM is only a minor evolution from GXL it's a solid/stable platform, which is key for that audience. I've been passed some S912 devices recently and even without an Android dtb or schematics it's been fairly trivial to get all the core hardware working.

    However, the tricky bit is always the boot firmware. You either need to self-compile a recent mainline u-boot and experiment with fip sources. The only public ones are for VIM2 and Tartiflette so that shouldn't be a lengthy exercise. Or you extract something from an Android image. Until you solve that piece of the puzzle building higher-level distro's (meta-meson, LE, Armbian, etc.) isn't going to be fruitful.

    The only way to force a connection to 5GHz only networks is to set the router so it has a dedicated SSID for 5GHz and then only authentticate the LE device to that SSID. Otherwise the WiFi card is doing what it's supposed to do .. find the best connection and use it. The problem with all WiFi networks is that connectivity and performance are variables that are largely outside your control.

    If you're using the .img.gz files that I linked, it's the first and only Amlogic device I've encountered which is not looking for boot firmware in the normal and known locations, and there isn't much I can do to help. The last dice-roll is writing them to a USB stick instead of an SD card.

    Please provide a full debug log.

    How to post a log (wiki)

    1. Enable debugging in Settings>System Settings>Logging
    2. Restart Kodi
    3. Replicate the problem
    4. Generate a log URL (do not post/upload logs to the forum)

    use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

    Those logs show no sign of u-boot at all, so I think the SD card image is not written correctly. Even if the boot firmware has the wrong SM1 fip sources or bad RAM timings you'll still see BL2 loading and some form of output on the console.

    The C4/VIM3L images have a single dtb in them for the respective device. The "box" image has all the dtb's including the SEI610 dtb. You can copy the SEI610 dtb from that image to an SD card created from the C4 or VIM3L images and then edit extlinux.conf to change the dtb name.

    I've had more success using the VIM2 dts with random boxes than the Q200/Q201 ones. That's also true of boot firmware - the 'vim2' suffix image on our test server is for emmc installs and has mainline u-boot in the imaage, but to test that you'll need to erase emmc first else the box will always find BL2 in emmc and use it.

    scarface911 this endless loop is BL1 (hard-coded into the SoC) searching for BL2 firmware. It is actually a better (more simple to work from) position than having the wrong or broken firmware installed, as we can experiment with booting from an SD card.

    Write the images below to an SD card and pastebin the UART output so we can see what happens, both C4/VIM3L are SM1 devices:

    LibreELEC-AMLG12.arm-9.80.0-khadas-vim3l.img.gz

    LibreELEC-AMLG12.arm-9.80.0-odroid-c4.img.gz

    If any of them boot (u-boot) but fail to run the kernel, download the AMLG12 "box" image from the same location and steal the SEI610 device-tree from it (change the dtb name in extlinux.conf) as I've had one person report that it works (mostly) with an A95X-F3 device.

    If Android starts failing to boot and reflashing is also failing there are probably defects in the emmc storage, but if you're able to boot a 3.14 image from USB the factory u-boot is still intact. Before attempting anything else I would use the USB booting OS to make a backup of the first 8MB of the emmc so that you have a copy of that u-boot, because although it's fairly simple to build bootable images for GXM devices, if the box has extra-cheap emmc chips (not unheard of) the fip sources might have been tweaked with custom timings (to deal with out-of-spec chips) and then it's unlikely you'll be able to find or recreate a bootable image. If the emmc deteriorates further it's then possible to erase emmc (short pins to boot from an SD card with factory u-boot installed). Worst case you might end up in a scenario where you need to boot from u-boot on a SD card but run an OS on a USB stick.

    NB: Once you start fiddling with boot firmware and u-boot it becomes important to have a USB > UART cable to see the boot/console output. If we can see that output we can literally see where things break and what happens when we experiment. If we can't see that output, we're reduced to guessing where the issue lies.

    I have no plans or interest in resurrecting work on AppleTV boxes. I still have the OE branches in my GitHub repo so if you wanted to attempt the backport you could. Use an older Ubuntu image to build with, 16.04 should align with what I/we were using at the time.

    I'd guess that the stream starts, but over time the buffer drains and then once it's depleted we have to re-request chunks of media to fill the cache again and the seeking behaviour to refind the start point to recover the stream generates a load of traffic. TL/DR; WiFi sucks. If you run an Ethernet cable the problem will probably go away. If that's not possible sometimes the better alternative to a USB device is an Ethernet > Wireless bridge. I'm personally a fan of old(er) Apple A1rport Express devices used as bridge devices as they're small and generally give good reception.