@balbes150 LE images with Kodi-19 for S9xxx

    • Official Post

    Work on the vdec stalled due to an upstream compliance review of the kernel APIs involved and since rework would be required it was better to wait until it completed before continuing. There are also issues in the firmwares - it's the reason why HEVC is (still) missing. The API reviews are now done and updates for MPEG2 and H264 codec have already been submitted upstream, but those codecs are the easy ones and VP9/HEVC are a lot more complicated. Some work on retooling ffmpeg and Kodi around the compliance changes has already started.

    NB: Team Kodi will bring forward the v19 release to get the hugely disruptive Python3 change into public view and the ETA on first alpha is within the next month as Python2 will be EOL on 1st Jan. The GBM/V4L2 work we are championing on ARM platforms will not align with the reschedule so v19 will be an alpha/beta release for ARM devices and v20 becomes the target, on similar dates to the original v19 schedule.

    Quote from Rataplan626

    Just updated to the latest (as of yet) Odroid C2 build. But I still have the same issues I've reported before, but as noone responded at all I'll do again:

    Image is installed on SD, not eMMC. It boots fine, but when I reboot Kodi, it halts. The OS shuts down nicely though, it seems to do a shutdown -h rather than a shutdown -r.

    DVD menu's aren't working. I have all my DVD's ripped to ISO. Doesn't matter if I play them from NAS or the local SD card. DVD trailer starts playing, but the menu is blank (black) with only the cursor showing. When I enter a few times something usually starts playing, and when I then go back to the dvd menu, it works fine. Initially it doesn't though.

    Are this bugs to be reported at this time, and if so what logs would you like? The usual kodi debug logs?

    DVD playback has been flacky in Kodi for years at this stage, it has not got attention for years because the people who maintain Kodi do not have any interest in supporting it properly. Its effectively a dead technology.


    Shoog

    Quote from chewitt

    NB: Team Kodi will bring forward the v19 release to get the hugely disruptive Python3 change into public view and the ETA on first alpha is within the next month as Python2 will be EOL on 1st Jan. The GBM/V4L2 work we are championing on ARM platforms will not align with the reschedule so v19 will be an alpha/beta release for ARM devices and v20 becomes the target, on similar dates to the original v19 schedule.

    hopefully the migration of the add ons will go quick. Right now still a lot of add ons incompatible, most notably inputstream.adaptive

    but good the transition is going on now

    Quote from chewitt

    crazycat is/was planning to bump things once 5.4 is released, not before. I'm also waiting on LE master branch to stabilise after the Py3 changes before spending time on 5.4 things (not much spare time at the moment).

    Do the plans remain the same? chewitt

    I mean we can expect something functional in the upcoming balbes150 builds (like updated crazycat drivers).

    As said here by you, here is Linux 5.4.

    LKML: Linus Torvalds: Linux 5.4

    These are the simple problems I have had with Libreelec reported here for a long time. (No solution)

    1- Kernel panic when booting or restarting.

    2- LibreELEC module drivers error.

    3- Kernel panic on TBS5520SE (never worked)

    Good morning,

    I have an Ariva 4K combo box (SAT + DTT) with which I have tested both COREELEC and ALEXELEC with a DBT image (attached file), and I get it to boot without problems.

    The tests I want to do with LIBREELEC is for SAT and DTT tuners. They are AVL6762 and AVL6211 (AV2026) controllers. In COREELEC and ALEXELEC I can't scan anything with TVHEADEND.

    If with the image I use for CORE and ALEX I can boot from the SD. Why with LIBREELEC from the SD card does not start ?. I have changed uEnv.ini to indicate my image. Should the image be dts or dbt ?. If it has to be dts, could someone change it for me?

    Can somebody help me.

    Thank you very much.

    ..also etcher works good for me on linux to write all variants of images(armbian, *eelec..)..

    cigarron : There was a change in structure of dtbs, so the old ones(from kernel 3.x) doesn't work on newer builds..so you have to determine which of the dtbs that came with the build works best with your hardware by changing the uEnv.ini..

    Its the way the bootloader is being implemented now...

    Even tho intially both CE and AE were simple forks of LE things have somewhat changed with LE and how its implementing the initial bootloader has changed leaving CE different and being AE is to a large extent just another fork of CE those two are not implementing the intial bootloader setup in the same manner as LE...

    I already assumed that it was not a problem of how to record the SD card.

    Which leads me to think that it is a problem with the structure of the DBT file that I am trying to use.

    The question then is: is the DBT file that I have uploaded adaptable to LIBREELEC ?. If so, can anyone adapt it for LE?

    All this without forgetting that the purpose is for the SAT / DTT to work with the adapter that I indicated

    Thank you.


    (p.d. Where can I find this meson-gxbb-ki- plus .dtb for example?)

    Edited once, last by cigarron (November 27, 2019 at 4:24 PM).

    As far as the dtb file goes... its a standard so editing them and adapting them if you understand those files is not all that hard but i think you might be missing something else...

    As far as booting goes its the manner in which the different forks of LE go about writing to the original firmware (bootloader) to allow it to check and boot from alternative media then the internal flash...

    Initially for a while most Distro's used the same scripts to edit the manufacturers bootloader to allow the alternate loading mechanism but that is no longer the case which is what i think Balbes was attempting to point out to you, and that to make it work with his LE's and Armbian builds you need to restore to factory state and then us his newer method to create HIS bootloader edits thus allowing LE and Armbian to load properly...

    You will still need the right dtb but to get his builds to work it needs to make the device boot in a manner compatible with his builds which is what i think your having issues with...

    Someone correct me if i am wrong tho...


    Hope that clears some of the muddy water...

    If you mean original firmware, the box has not been modified, continue with the factory Android. I do not try to boot from the internal flash, but from an external SD with the "stick" method. I don't know if I explain myself. I do not have CORE / ALEX in the internal flash, I have always started in dual, always respecting the original ANDROID.

    I guess LE also starts in dual mode, doesn't it?

    Ya thats cool...

    Still tho, even when loading CE or AE on a sd or stick to enable that those original installs on the box altered the existing factory bootloader ONCE to allow the device on reboot to now check for a bootable OS someplace other then just the internal flash... from the factory normally a box just boots up into Android but does have the ability to load outside sources which is how the Android recovery works...

    To enable a off box bootable source tho there is a script in most builds that will alter the internal bootloaders setup to check elsewhere... essentially your telling the manufacturers u-boot to check other places then just internal memory and then saving those new settings into u-boots storage area so it can be used from that point forward anytime the device reboots. So even tho your still running CE or AE on external media they at one point in their original 1st boot made those alterations to u-boot on the device...

    Once that intially happens normally you never need worry bout that anymore and just need to worry bout things like the proper dtb file for the device with its matching build...

    With that in mind what i am getting at is that the method CE/AE and LE go about making the alteration to u-boots startup environment is no longer the SAME...

    For along time seeing as historically CE/AE and others started life as Forks of LE that once any One of them were initially setup to run internally or externally the could all take advantage of U-boots altered environment...

    As CE/AE now insist they aren't really LE forks anymore their way is Not supported by Balbes (LE) builds anymore as his scripts work slightly differently... tho i quess if one wanted to spend enough time analyzing the differences a common method could be done...

    Personally even tho i have followed along for years and built all of the Distro's going back to and predating even OpenELEC which kinda started all of these types of frame works. I have a tool i created years ago that i use to create boot loaders for all of my projects on pretty much any Arm based device as i develop on ST and TI as well as the typical Amlogic or Rockchip SoC's that use Arm cores... I do RE work so i do a lot of messing around with proprietary Devices and SoC's but essentially they function in similar manners at the core...

    Thank you very much for the reply.

    You can explain to me then how is the process that you say Balbes:

    "you will no longer be able to run LE and Armbian normally until the full recovery of the standard firmware via the USB Burn Tool and the new activation of the universal multi-boot, which is used in all new systems."

    What is "the USB Burn Tool"? Do I have to flash the Android? If so, it is too much for me to lose everything I have mounted in the box with Android. Is there another recovery method for boot boot?

    Sorry for my ignorance.

    Best regards.

    Edited once, last by cigarron (November 28, 2019 at 9:25 AM).

    • Official Post

    Amlogic "USB Burn Tool" allows you to connect the device via USB ports to a Windows laptop and flash an image (in a proprietary Amlogic format, not the same format we've ever used) directly to the internal NAND/eMMC storage. It's for flashing factory images onto a device. Most images will be Android, but it restores the factory u-boot, which negates any changes that other boot scripts have done to the boot environment.

    Quote from chewitt

    Amlogic "USB Burn Tool" allows you to connect the device via USB ports to a Windows laptop and flash an image (in a proprietary Amlogic format, not the same format we've ever used) directly to the internal NAND/eMMC storage. It's for flashing factory images onto a device. Most images will be Android, but it restores the factory u-boot, which negates any changes that other boot scripts have done to the boot environment.

    So what you mean is you have to connect the box to a pc with usb burn tool but it's not necessary to flash anything in order to fix uboot?