@balbes150 LE images with Kodi-19 for S9xxx

  • If you are a LE developer, email me at Slake in PM, I will explain in detail how to do this.

    I can barely compile a Makefile, so I don't think I qualify.

    But there's something else I'd like to ask you:

    As I already written, only your Armbian/Libreelec images work on the R-TV S10. Is it possible to apply your "magic" to a foreign .img and cook a bootable image?

  • These are completely different systems, with different principles of working with media content, they do not need to be compared.

    Sure I didn't want to compare both systems, I just wanted to say, that it was not a faulty file(as it works on other builds of LE and armbian without issues). Accidently I overwrote this specific version. On newer builds the problem dissappeared and file plays as it should. Maybe I was the error, it was a strange moon phase or elsewhat...everything fine with local files now for me.


    Thank you for all your good and hard work!

  • So that kinda had me wondering what direction was better to look into "stateful or the newer stateless" and didn't want to go in a direction that was opposite to where everyone here is working towards.

    Hardware IP is either stateless or stateful .. it's not a choice. Amlogic is stateful.

  • i realize this probably is not the thread to yap about this stuff...


    but briefly i was of the same opinion till some others pointed out to me that because the Mali IP is actually common to all SoC's licensing it that because other SoC's using those IP's are going the stateless way is why i asked... i realize there is a lot of things that need to be changed to implement it but just wasn't sure..


    once again thanx for the input.

  • Mali = GPU, used for rendering GLES content on screen (e.g. Kodi). It has nothing to do with hardware video decoding.

  • sorry for the brain-fart... I seen Hardware IP in you post while looking at some GPU binary code i dumped and forgot to jump out of that mindset...


    now that you said that i get what your talking about with the codec stuff and amlogic...

  • I get this error on the aarch64 amglx from 30.04:

    May 01 13:22:37 LibreELEC systemd[1]: Finished Update UTMP about System Runlevel Changes.

    May 01 13:22:38 LibreELEC kodi.sh[3468]: /usr/lib/kodi/kodi.bin: symbol lookup error: /usr/lib/kodi/kodi.bin: undefined symbol: glGetIntegerv

    May 01 13:22:38 LibreELEC systemd[1]: kodi.service: Main process exited, code=exited, status=127/n/a

    May 01 13:22:38 LibreELEC systemd[1]: kodi.service: Failed with result 'exit-code'.

    May 01 13:22:41 LibreELEC systemd[1]: kodi.service: Scheduled restart job, restart counter is at 5.


    Perhaps compiled with a different mesa than the one provided?

  • On an S912 is it possible to get analog audio?


    Also I tried LibreELEC-ARM-ALL.arm-9.80-devel-20200406105758.... image on my S10 but when I do:

    Quote

    LibreELEC:~ # uname -m

    aarch64

    So what's the difference between arm and aarch64 images?


    One more question: The S10 has some weird bootloader that fakes the amount of RAM, apparently it's impossible to replace it because there's some security mechanism or encryption in the image or the EMMC.

    If I remove the EMMC and replaced it with a NAND, can I then upload (via burning tool) an image with a "normal" bootloader?

    Or is the fake bootloader somehow locked in by in the CPU EFUSEs?

    Edited once, last by Zameero ().

  • I am so sorry. I have found question, about rgb but not found answer.

    Is it possible to force rgb? For previous release solution was :

    echo 1 > /sys/class/amhdmitx/amhdmitx0/output_rgb

  • 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.

  • Hello. I have S96Max with a broken emmc (not formatted and not defined). I wanted to use LibreELEC to start the system with an SD Card. Recorded an image. Specified the DTB file. The launch fails. Is there anything else you need to do? When you start the UART displays the following information:

  • "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

    If the add-on compatibility is not needed, is there any actual advantage/hindrance in using arm or aarch64 images? I recall reading balbes150 mentioning temperature, but maybe I'm having a Mandela effect... Does one perform better than the other?


    Regarding memory this board is very strange: I'd think that boards with fake RAM would have less RAM (as in actual memory IC), and I've actually seen one of these: just 4 x 256MB installed became 2GB advertised.

    But this one has the real deal (2x1GB + 2x512MB=3GB), however at boot only 2GB are recognized and then they are faked to 3GB.


    Code
    DR4 chl: Rank0+1 @ 1008MHz - PASS
    Rank0: 1024MB(auto)-2T-18
    Rank1: 1024MB(auto)-2T-18
    [...]
    U-Boot 2015.01-ga4d8f5c-dirty (Dec 07 2017 - 19:23:54)
    DRAM:  3 GiB


    You cannot "replace emmc with nand" on boxes

    This board has provision for EMMC (BGA) or NAND (TSOP) memory, and I've seen similar (cheaper) boxes where they use NAND TSOP.


    you can replace the bootloader - if - you have the fip sources for the box

    The problem is that the EMMC has a region that is write protected, so the bootloader CAN'T be overwritten. That's why I was looking to replace the chip with a NAND.

    Have you got any info on how to disable the write protection on the EMMC? Maybe there's some u-boot command that can do that?

  • 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.

  • Put Dropbox - u-boot.ext - Simplify your life in the root folder of the USB key and reboot, and colours should be fixed. It's a bit of a hack (chain-loading mainline u-boot) but it works.

    I am very sorry for misunderstanding. I copied this file to root USB key ( STORAGE and LIBREELEC) , but OS stop loading. After that I try to copy this file to OS:

    LibreELEC:~/backup # cp u-boot.ext /

    cp: can't create '/u-boot.ext': Read-only file system


    Should I do it after creating USB by LibreElec.USB.SD.Creator.bin, before installing OS?

  • chewitt , thank you for your attention.

    I thought the problem was in the LibreELEC loading stages.

    When downloading without an SD Card

    Code
    G12A:BL:0253b8:61aa2d;FEAT:E0F83180:2000;POC:F;RCY:0;EMMC:0;READ:800;READ:800;READ:800;SD?:20000;USB:8;LOOP:1;EMMC:0;READ:800;READ:800;READ:800;SD?:20000;USB:8;LOOP:2;EMMC:0;READ:800;READ:800;READ:800;SD?:20000;USB:8;LOOP:3;EMMC:0;READ:800;READ:800;READ:800;SD?:20000;USB:8;LOOP:4;EMMC:0;READ:800;READ:800;READ:800;SD?:20000;USB:8;LOOP:5;EMMC:0;READ:800;READ:800;READ:800;SD?:20000;USB:8;LOOP:6;EMMC:0;READ:800;READ:800;READ:800;SD?:20000;USB:8;LOOP:7;EMMC:0;READ:800;READ:800;READ:800;SD?:20000;USB:8;

    When loading from the original recovery image there is information about LPDDR4 parameters

    Maybe it makes sense to extract the U-Boot from the original image?

    Please specify the link to the repository, because I can't find it with the name "amlogic-master" in your repository.