Official LE Test Images for Amlogic (Kodi-19)

  • Odroid N2 dont working ethernet and hdmi cec. dont recognize Realtek RTL8811AU usb wifi adapter. thanks


    edit: Its possible run by petitboot?

    Edited 2 times, last by loznic89 ().

  • With the last linux kernel bump AML is broken, due holidays and spare time issues nobody has yet updated the AML project yet.

    So no new images are created and old images are removed after x days :)

  • can anyone bring any news about the amlogic constructions!

    I tried a construction I get errors, impossible to build a test.

    It is useless knowledge if not shared the world.

  • I found some possible solution for better kernel support not only for Amlogic in Libreelec , if it is possible and have some advantages over current support for kernel maybe some integration from KernelCi project in Libreelec have sense.

  • I am assuming your all talking about the normal 9.2 version...


    The master for at least the AMLGX builds ok if you strip out all the bad kernel patches in the Amlogic Project folder.. It appears that a lot of the patches still in the project are for earlier kernels and when building against the 5.8.7 they are already in the source so the patches cause the build failures and by removing them the project will build.


    I have not tested against the AMLG12 projects tho at this time... i just tested the GX as i checked the completed images on some S912/S905 devices which other then the typical matrix issues works.


    I have begun a 9.2 build by moving the Amlogic project back into the 9.2 project and am in the middle of regressing kodi down to the current 18.8 version just to see if it will work...


    I am busy with some other builds so it may take a while depending on what i come across while trying this.


    Anyways i posted this just for the ones that want to play as the more that try the quicker things may happen as i am sure most of the dev's here probaby have their hands full with the limited time they have.

  • Hi. I have one technical question about this problematic state of support for hardware decoding on Amlogic and other SoC platforms. If I understand correctly for proper hw decoding is needed mainly codec as library from some vendor/programist/company which have extension for hardware capabilities for platform which is bundled for running. On Amlogic for example s805x with mali-450 mesa have 3d extensions for that gpu but on desktop also have for gpu like vaapi vdpau fo radeon and intel and nvidia for hw decoding. On Soc cpu/gpu if i think about this state instruction for handling hw acceleration for codec formats should have mesa but i remember on linuxtv git v4l tree have something to do with that code, situation is even more complicated because meson build system have some layers beetwen things to get everything done if i understand this. So codec is ffmpeg or something on other layer like for example libde265 for hevc, maybe in opensource world not exist codec with implementation for every SoC and ffmpeg code base sometime have this futures. Modularity is for to get things done wery well but it this time consuming effort... Sorry for my mistakes in writing , im not native speeker

  • I have begun a 9.2 build by moving the Amlogic project back into the 9.2 project and am in the middle of regressing kodi down to the current 18.8 version just to see if it will work...

    You can share this construction!

    Knowledge and little to do.

    Thank you.

    It is useless knowledge if not shared the world.

  • The AMLG12 is for on master failing at the mali-bitfrost package so i need to isolate the changes as its been awhile since i last built the LE projects when it was working... so some time needs to be spent seeing why it no longer builds for me...


    The Amlgx project i stuck into the 9.2 build i am picking away at correcting a few issues matching that project into the 9.2 build but its coming along bit by bit...


    Stpf99... The answer to your questions is probably more then what should be talked about in this thread as it involves a number of pieces of code in a variety of spots that either needs to actually be created or old code adjusted.


    In short tho it stems from the proprietary vendors bsp packages being done away with as LE migrates to using mainstream packages looking ahead to the future.


    Trying to maintain builds for the growing group of devices is just way to many headaches every time something breaks as each vendor kinda hacked together whatever they needed at the time for that device with no real thought of looking much beyond the initial sales when they introduced the device...


    Amlogic for example, has for years had their own hobbled together player support in the form of libamcodec which Kodi used which has now been removed and replaced with opengles(mesa) which means a number of areas need to be fixed up... The V4L and Ffmpeg projects are probably the most notable ones as they strive to solve the encode/decode issues.


    LE shows the wear and tear while this is going on as while working towards Matrix and the obstacles it brings (like most new versions) they have decided to take a hands on approach with the various mainstream packages and developing the required supporting code...


    CE and most of the other forks are more committed to making use of the vendors proprietary bsp's which has allowed better working Aml images for most of those devices...


    Most of the devices they support are running on are pre-5 kernels usually at 4.9 or 3.14 which because Android on those devices is locked down on kernels in the same general revisions it has allowed for some of the proprietary blobs or firmware to be used in these Jeos Linux Distros to make use of the hardware as it was meant to.


    There is no real easy way with the mainstream road as its a lot of work but there has been a lot of ground gained but more is needed and its just one of those things that has to many unknowns to predict if and when it will all end, so the quest carry's on.


    As for the LE vs CE approach its not a matter of one being right or wrong its simply a choice for the enduser to be aware of the differences and if running on older kernels isn't a concern then CE or any of its spin-offs like AE is probably the better choice for now... As well its probably a good idea to be aware of the differences and issues if looking to buy a new device as there is a lot of marketing out there that can make it confusing when looking at the new devices.


    I will stop there as its kinda outside the intent of this thread but hope that helps point you in the right direction.

  • I have finally managed to fix the issues with getting the AMLG12 to complete the build...


    i need to dig out a device to test things and see if it actually runs tho... and then i will push the build and patched up to my github...

  • CvH ... i would if i knew enough about git to safely go about doing so... I barely know my way around git for my own use, let alone someone letting me pollute their sources... It took me 3 commits just to finally settle on how to produce a patch that someone else can use and eventually i will figure out how to delete the early commits on trying to create a patch properly... lol...


    Anyways for now till i learn more about git for anyone looking to build against LE Master branch and running into issues with the mali-bifrost package not building because of the missing mmap_sem structure...


    There is a patch in my LE Master branch under the /packages/linux-drivers/mali-bifrost directory... i created a patch directoy and stuck it in there and it should solve those build issues when pulling the BX301A01B-SW-99002-r16p0-01rel0 package from LE or any other unaltered source.


    Hope that helps for now... its only taken me 3 days now to figure out how to use that part of git... lol...


    sorry i quess i should have pointed to my github for anyone looking...


    hxxps://github.com/buzzmarshall/LibreELEC.tv

    *replace the xx with tt to make the link work.

  • ARM Mali GPU - openSUSE Wiki

    For ARM related support in Open Source exist :

    "Lima" for mali-400 and mali-450 soc gpu's aka Utgard gpu's

    and

    "Panfrost" for both Bifrost and Midgard Mali GPU: Mali-Gxx GPU and Mali-T6xx / Mali-T7xx / Mali-T8xx GPU

    LibreELEC is focused on that drivers not on ARM Corp. versions like mali- utgard,midgard,bifrost

    and Ciolabora now writing panfrost code with ARM developers for upstream Linux


  • Which GIT and branch are you trying to use ?

    GitHub - LibreELEC/LibreELEC.tv: Just enough OS for KODI origin/master # Per wiki instructions


    PROJECT=Amlogic DEVICE=AMLG12 ARCH=aarch64 make image # My best guess


    -----


    patching file arch/arm64/kernel/cpuinfo.c

    Hunk #1 succeeded at 148 (offset 1 line).

    APPLY PATCH (project) projects/Amlogic/patches/linux/amlogic-0004-HACK-arm64-dts-meson-gx-add-ATF-BL32-reserved-memory.patch

    patching file arch/arm64/boot/dts/amlogic/meson-gx.dtsi

    APPLY PATCH (project) projects/Amlogic/patches/linux/amlogic-0005-HACK-media-cec-silence-CEC-timeout-message.patch

    can't find file to patch at input line 25

    Perhaps you used the wrong -p or --strip option?

    The text leading up to this was:

    --------------------------

    |From d7ba0960e3bc51f8368ef9d3b98ce33be91e3570 Mon Sep 17 00:00:00 2001

    |From: Christian Hewitt <[email protected]>

    |Date: Tue, 7 Jan 2020 07:12:47 +0000

    |Subject: [PATCH 005/156] HACK: media: cec: silence CEC timeout message

    |

    |If testing with an AVR that does not pass-through CEC state the system

    |log fills with timeout messages. Silence this to stop the log rotation

    |and ensure other issues are visible.

    |

    |[ 42.718009] cec-meson_ao_cec: message ff 84 50 00 01 timed out

    |[ 45.021994] cec-meson_ao_cec: message ff 87 00 15 82 timed out

    |[ 47.325965] cec-meson_ao_cec: message 10 timed out

    |[ 49.630023] cec-meson_ao_cec: message 10 timed out

    |[ 51.933960] cec-meson_ao_cec: message 10 timed out

    |

    |Signed-off-by: Christian Hewitt <christi[email protected]>

    |---

    | drivers/media/cec/cec-adap.c | 6 +++---

    | 1 file changed, 3 insertions(+), 3 deletions(-)

    |

    |diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c

    |index 6a04d19a96b2..fcb29dba8de1 100644

    |--- a/drivers/media/cec/cec-adap.c

    |+++ b/drivers/media/cec/cec-adap.c

    --------------------------

    File to patch:

    Skip this patch? [y]

    Skipping patch.

    1 out of 1 hunk ignored

    *********** FAILED COMMAND ***********

    patch -d $(echo "${PKG_BUILD}" | cut -f1 -d\ ) -p1 1>&${VERBOSE_OUT}

    **************************************

    *********** FAILED COMMAND ***********

    ${SCRIPTS}/unpack "${PKG_NAME}" "${PARENT_PKG}"

    **************************************

    FAILURE: scripts/build linux:host has failed!


    The following log for this failure is available:

    /mnt/fast/LibreELEC.tv/build.LibreELEC-AMLG12.aarch64-9.80-devel/.threads/logs/42.log


    >>> linux:host seq 42 >>>

    [041/257] [FAIL] build linux:host


    The following log for this failure is available:

    /mnt/fast/LibreELEC.tv/build.LibreELEC-AMLG12.aarch64-9.80-devel/.threads/logs/42.log


    Parallel build failure - see log for details. Time of failure: Tue Sep 22 06:53:21 PDT 2020

    make: *** [Makefile:12: image] Error 1

  • Please tell me,

    How can I turn off at compilation such a parameter, which is designated as "Adjust display refresh rate" in the kodi?

    The fact is that I tried to disable this parameter in the "appliance.xml" file. But in any case, the display frequency adjusted to match video (the screen goes blank for 2 seconds). For some reason, the LibreELEC team builds images "on start/stop" for amlogic, and for x86_64 this parameter is disabled by default. Where can it be disabled in the git (in which file, in which piece of code)?


    Thank you

    Odroid C2