Posts by chewitt

    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

    It's not possible to set codec-specific configurations. It sounds like bad encoding, so best option would be to re-rip the content from original media. NUCs are quite speedy for ripping - even the low-spec ones.

    LE 9.2.3 will have GUI options for setting wireless regulatory domain which appears to be more important on RPi WiFi hardware than other devices for setting the correct radio properties and getting good (or better) performance. Until the release you can force the same with this:

    Code
    echo "options cfg80211 ieee80211_regdom=US” > /storage/.config/modprobe.d/cfg80211.conf

    replace "US" with other country codes if required.

    Linux 5.7 doesn't really fix anything - it's just another incremental step in the journey. I've been working with it for a month now and need to rework audio support as the upstream maintainers rejected yet-another idea that I had to simplify adding new devices - so I need to revert back to a previous approach (aka doing it the hard way). Once that's done I'll push some device support upstream and then think about making a general 5.7 update to LE master. There are still some known glitches for audio support on GX hardware and while there has been some effort with ffmpeg V4L2m2m we still have issues with draining which impacts end of stream and seeking. No public code for HEVC yet either. Apart from that, things are stable.

    illusi0n: In that case emmc is wiped or broken or both. LE does not ship and test images for box devices with signed firmware and u-boot (only for board devices we have FIP sources for) so whatever image you're using is probably for G12B or SM1 hardware not G12A, and the RAM timings in the signed firmware are not correct for your board so it faults between BL2 and BL3x and restarts. You're now at the same stage where you need to self-build an image using the FIP sources for the U200 device and hope they work. I'd also go hunting on freaktab for some kind of Android image for the box that you can load or maybe dump the first 2-4MB from as this will get you enough of the factory boot firmware to get u-boot installed. From that point an LE "box" image should boot.

    Commits · chewitt/LibreELEC.tv · GitHub <= branch is use for development and experimentation and is rebased freqently. I will publicly refuse support on anything built from it :)

    illusi0n the BL1 firmware (hardcoded into the SoC) on GXL and newer boxes checks for BL2 firmware at specific sectors of emmc, and if nothing is found, it then checks the SD card. In your case it finds BL2 on the emmc so uses it, but then I guess it reaches bad sectors as the UART output shows BL2 load but only the start of the BL3x stages that follow. It's not impossible to recover from this scenario, but it's a non-trivial fix and may depend on finding the correct fip sources for signing the boot firmware for your device.

    In short [sic] you'll need to open the box and short-circuit specific pins on the emmc chip to disable it, which results in BL1 failing to see it and then checking the SD card. In the absence of a special SDIO board Amlogic uses in development (which you cannot purchase) this is the only way to force this behaviour. You will also need a bootable SD card that contains signed boot firmware and u-boot. If you can compile new boot firmware, you should be able to boot from SD card to a point where you can either overwrite the broken firmware on emmc with good firmware or (what I would do) zero the initial sectors of emmc to erase the incomplete firmware - it will then always fail to find BL2 and always check the SD card.

    Creating signed boot firmware is not that hard, but, part of the signed firmware recipe uses files that determine the RAM timing data (which RAM chips are supported). I have a collection of sources from various places, but there's no guarantee the files I have will support the chips in your box. If you are lucky, your box is from early in the S905X2 production and follows the U200 reference design specs.

    I would start with building an AMLG12 image from the amlogic-master branch in my GH repo - as this is already using newer versions of u-boot and amlogic-boot-fip packages that have things for U200 support. Create an AMLG12 image to prove the build-system workls, and then you can add a scripts/uboot_helper entry that uses the recently upstreamed u200 defconfig for u-boot and the u200 linux device-tree (dtb) file. If you're lucky, the fip sources for the U200 have the right memory timings for your device and the output will be a bootable SD card image.

    Right now I don't have time to spoon feed these changes so you'll need to take some initiative. Having a UART cable handy shows you might be technically inclined .. I hope.

    If the TV has a 24Hz mode (most will support 23.976, 24, 25, 29.97, 30, 50, 59.94, 60) adjust refresh will switch to the exact mode unless a mode that is "double" the refresh exists, e.g. PAL 25Hz will play at 50Hz, NTSC 29.97Hz will play at 59.94Hz if the modes exist. If the TV does not have 24Hz modes, it will default to 60Hz using pulldown. If the mode is doubled the frame is simply rendered twice.

    Zameero "arm" is 64-bit kernel and 32-bit userspace for compatibilty with add-ons that need software widevine (DRM) support, and aarch64 is 64-bit kernel and 64-bit userspace which means no widevine support (as only 32-bit libs are sourceable). Also, mainline Linux will report the actual RAM installed, not what u-boot reports, and while you could hardware-hack fake values I doubt most box vendors are that clever. I also doubt it's imposssible to replace u-boot as I haven't seen truly locked bootloaders yet, only ones with more complex/customised boot environments. You cannot "replace emmc with nand" on boxes, but you can replace the bootloader - if - you have the fip sources for the box; the fip sources are semi-standardised around Amlogic reference devices but cheap box vendors frequently deviate from the reference design with slower/lower spec memory and then you need the files specific to that box to compile a replacement bootloader. This is one reason why we have subzero interest in fiddling with u-boot for box devices where 99.999% of the time we don't have (and won't ever get) the fip sources.

    miwenka Userspace manual tweaking of kernel drivers is not needed (and thus that stuff doesn't exist) in mainline. If you connect to a not-YUV-capable screen, e.g. RGB-only monitor, the DRM driver outputs RGB. So what's the actual problem you have?

    phlp11 no idea what the issue is, but I will push a bump to Linux 5.7-rc kernels later in the week and this may improve things .. or not. LE master branch is some way behind my own branches now, it needs to catch up a little.

    The storage partition exists, but it's ext4 formatted which means Windows cannot "see" the partition (because Windows doesn't support ext4). You can see the partition on any Linux OS.

    Boot LE, enable SSH, login using WinSCP and copy the advancedsettings.xml file, or use PuTTY and copy/paste (might be easier and avoids the temptation of Windows users to create incompatible line-ending files in Notepad.exe).