Posts by eTrax

Short update: The two hacks by lrusak solved problem with the missing video picture.

Also some other formats (i.e. MPEG2/DVDvob) now show a picture.

Playback gets unstable (offset between audio and video), seeking could be activated (at lower factors 2x-4x), but when returning to normal playback, kodi seems to get stuck.

Also when trying to change audio tracks (foreign languages), kodi seems to get stuck.

CPU load is also still higher compared to old OE7, although using DRMPRIME (HW): OE: both cores <= 10%, LE9.8: both cores 35-50%.

I will collect and prepare additional data during the week.

Quote from chewitt

Your current script passes imx6.arm as $1 (the $PROJECT.$ARCH of the current image) to the script which evaluates true (exit 0) so the upgrade continues.

I was trying this on a recent nightly build of LE, which should pass "iMX6.arm" to the script and then exit with 1...

But busybox threw a monkey wrench into our works. Its init-script checks architecture of both, current image and update image ('fake'-check of /etc/os-release, not the real running architecture). Only if they differ, it will look for a canupdate script. (and btw, canupdate could then also 'echo' debug information to the console, at least on my cubox it did)

So indeed canupdate.sh could be used to control update of arm/aarch64 systems of the same (or even different) $project.

But as long as both have the same architecture, it could not be used to evaluate not to update older kernel versions.

So I guess, a Rockchip Tinkerboard LE 9.0 will be upgraded by an RK3288 LE 9.8 image although using a kernel version 4.4? (Rockchip.arm == Rockchip.arm -> no call of canupdate.sh, just call update.sh)

Also a RK3288 LE 9.8 system accepts an RK3399 LE 9.8 update.tar (stupid user mistake) and gets stuck due to the new aarch64 kernel? (Rockchip.arm != Rockchip.aarch64 -> call to canupdate, which will return 0 and update continues...)

Maybe it's a good idea to check that, before releasing official images of Kodi19/LE10, JM2C

Hi there,

I tried the LibreELEC nightly builds for iMX6 for some days in parallel to an older OpenELEC 7.0 setup on a Cubox-i2eXw.

As this platform is a little bit outdated I was pleased to see that there might be a future release of LibreELEC with gpu support/hw acceleration.

As far as I understood, the kms/gbm/dri/mesa configuration is only in a basic state: h264 decoding with hw acceleration should work, all other formats might have some issues or will not play...

And that's exactly what I have experienced. MPEG1/MPEG2 and AVI-containers with DivX/Xvid-encoded video data will not show a picture, only sound is present for some files. I guess, to get this working, some work has to be done (as for the other platforms already was done in the last weeks), and based on the labels I have seen in the kodi and ffmpeg project, this seems to be addressed to some time later (Kodi 20).

But I still have a problem with some of h264 encoded files. Some will play with sound and picture, some will play sound, but there is only flickering (switching between black picture and the kodi gui) instead of video picture. The file which does not play, is the first one, h264 packaged in a matroska container. (Occupied - Die Besatzung - S01E01 - April.mkv)

The second one plays well, again h264, but packaged as MP4. (ARTE Concert - Pop & Rock-Rage Against the Machine - Live at Finsbury Park-1127769147.mp4)

I could also paste another example of a working h264/matroska file if needed.

For the first look I would expect something like a problem during init of the buffers (udmabuf/dma_heap) at kodi startup. And selection of a good suiting resolution and refresh rate looks a little bit weird, too. Source has 25fps, best suiting target resolution is using 60fps?

Maybe somebody could give me a hint, where to start investigations and how to fix this issue after having a look to the logs:

kodi.log

dmesg

modetest

Just to finish my investigations:

Either I didn't get the config right or it seems not to to be working on newer installations too. I started with a recent nightly build and prepared an update tar with canupdate.sh set to

#!/bin/sh
if [ "$1" = "imx6.arm" ]; then
  exit 0
else
  exit 1
fi

Placed the script at different positions (root of update.tar, inside folder /3rdparty/bootloader and also in the squashfs beside the update.sh). Result each time: Update of the running system.

Do I still use a misconfiguration of canupdate.sh or was its functionality removed from recent the project?

Quote from chewitt

I appreciate the desire/intent to support a nice upgrade experience, but IMHO the simplest and best option is to force a clean install and not attempt to handle upgrades and migration from legacy images.

I fully agree. I was not looking for a way to provide an upgrade routine for the old installations. I was just wondering how to prevent a "DAU" from trying to upgrade such an old installation and getting a messed up installation.

So at the moment, the canupdate.sh script fails for the imx6 platform:

for installations < v8.0: They will not expect a canupdate script, update will proceed until mount of squashfs fails due to the newer zstd format and leaves the actual installation messed up

for installations >= v8.0 (< v9.8/nightly): the script should be executed and should stop the update as $ARCH is "imx6" and not "iMX6". This also fails, as the mount of the squashfs (in which the canupdate script resides) fails due to the newer zstd format.

for installations >= v9.8/nightly there is no need for this script at the moment, as there is only one $ARCH for the project.

So in the end, it should be mentioned in the (future) WIKI, that for the recent images a clean install is forced.

Maybe somebody could give me a hint on how to check canupdate.sh is working or explain the sequence, how (or in which sequence) the update should work...

I am playing around with the update.tar file on my Cubox system to check and prevent upgrade of unsupported installations. (i.e. kernel too old, bootloader not using extlinux.conf...)

I added some echo messages for debugging to my canupdate.sh script just before the script decides if update/upgrade is supported or not.

After placing the update file in the .update folder, rebooting, a new .tar archive is found, extracted and kernel, system file and dtbs are updated, system reboots, finished.

My canupdate.sh script is placed in SYSTEM:/usr/share/bootloader, just beside the update.sh script, the two files for u-boot and all of those device tree files.

Do I have to add a call to canupdate.sh to the update.sh script to get this working?

I am also not sure if the sequence of update/upgrade is correct: I am facing a problem on my productive installation (v7.0.1), where kernel and system files get already replaced before mounting the new system fails. (so no access to the canupdate script and no warning message for upgrade not supported) - the system is stuck in the end.

If using the latest v8.2.5 image and trying to apply the update, also no debug information appears indicating my canupdate.sh was executed, the mounting of the new system fails, but here the system is still working after reboot.

So at this point, it seems for me, there is no way to prevent update/upgrade on unsupported older installations...

I merged all suggestions in the @by-gnome proposed project files in a new branch.

I also prepared a solution for the NXP/imx6 update.sh script.

How to proceed? Would you like to review the other files in advance, should I close this PR and start a new one based on the other branch or... ?

Maybe we could discuss some of the remarks still in this topic and merge them to a solution:

- What is the preferred position to do the changes? Inside the NXP project (as by-gnome is using) or outside in the global scripts?

- dtb files should be placed in / folder beside the kernel file

- As both are using FDTDIR in extlinux.conf, maybe they both will require an additional patch of extlinux.conf during update, moving from a dl-/q-based image to the independent one?

- direct adressing of files is preferred instead of using wildcards (*cubox*.dtb)

As I shot forward maybe too quickly, I have no problems in recalling my PR for a better approach, just let me know.

Took some time to setup a build machine, but here we are. I prepared a small change and added it as a PR for review.

Hi there,

Cubox i2eXw is also working this way. Thanks.

At the moment I was still using an legacy OpenELEC 7 image (which was providing HW accelerated video playback) and was trying to get a running Armbian system with MESA HW acceleration on this small box. Two weeks ago I found these newer LibreELEC images and tried one. The image contained only one .dtb file, which didn't boot. The Armbian system used a v15-dtb, so I tried this one from the Kernel image-TAR - and now system is up and running.

To have only one image you should put all the .dtbs in one sub-directory and let the FDTDIR-tag point to this folder.

btw: Is there already a topic to discuss IMX.6 specific experiences, bugs etc. ?