Posts by LuRu

Thank you!

I added the command git pull origin libreelec-10.0 and it worked like a charm.

I apologize for the beginner's question.

For several days now I have been trying in vain to compile LibreELEC for Allwinner H6.

I use commands:

git checkout libreelec-10.0
PROJECT=Allwinner ARCH=arm DEVICE=H6 make image

Compilation always ends with an error:

2021-10-17 10:09:45 (1.19 MB/s) - '/home/technician/LibreELEC.tv/sources/kodi/kodi-19.2-Matrix.tar.gz' saved [52359726]


WARNING      Incorrect checksum calculated on downloaded file: got e8f5e50767ddd1b8f0399016dcf5ba762315c16c0568cb06e659c493376f99d5 wanted 9830e68a2b6d6381e1dc03c1be119d9742fcdfff9824da1e4fe8c5c778f8f6ed
--2021-10-17 10:09:46--  http://sources.libreelec.tv/mirror/kodi/kodi-19.2-Matrix.tar.gz
Resolving sources.libreelec.tv (sources.libreelec.tv)... 138.68.75.163
Connecting to sources.libreelec.tv (sources.libreelec.tv)|138.68.75.163|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://sources.libreelec.tv/mirror/kodi/kodi-19.2-Matrix.tar.gz [following]
--2021-10-17 10:09:46--  https://sources.libreelec.tv/mirror/kodi/kodi-19.2-Matrix.tar.gz
Connecting to sources.libreelec.tv (sources.libreelec.tv)|138.68.75.163|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-10-17 10:09:46 ERROR 404: Not Found.




Cannot get kodi sources : https://github.com/xbmc/xbmc/archive/19.2-Matrix.tar.gz
Try later!
*********** FAILED COMMAND ***********
. "${get_handler}"
**************************************
*********** FAILED COMMAND ***********
${SCRIPTS}/get "${PKG_NAME}"
**************************************
*********** FAILED COMMAND ***********
${SCRIPTS}/unpack "${p}" "${PARENT_PKG}"
**************************************
*********** FAILED COMMAND ***********
${SCRIPTS}/unpack "${PKG_NAME}" "${PARENT_PKG}"
**************************************
FAILURE: scripts/build JsonSchemaBuilder:host has failed!


The following log for this failure is available:
/home/technician/LibreELEC.tv/build.LibreELEC-H6.arm-10.0-devel/.threads/logs/70.log


>>> JsonSchemaBuilder:host seq 70 >>>
[129/279] [FAIL] build   JsonSchemaBuilder:host


The following log for this failure is available:
/home/technician/LibreELEC.tv/build.LibreELEC-H6.arm-10.0-devel/.threads/logs/70.log


Parallel build failure - see log for details. Time of failure: Sun Oct 17 10:09:46 CEST 2021
Makefile:12: recipe for target 'image' failed
make: *** [image] Error 1

Am I doing something wrong?

After a few days of daily use, I can confirm the previous conclusions.

There are no system freezes. Only occasionally Kodi crashes (LibreELEC lives during the crash - it responds to a ping) and this happens always and only during IPTV playback. First the image stops and after a few seconds Kodi restarts.

The significant factor is definitely the CPU regulator voltage range and not the wifi power supply.

I made two new versions:

V2 is without changing the CPU regulator voltage range and

V3, on the other hand, contains only a change in the CPU regulator voltage range.

First I tried V2. It ran for about half an hour and there was a system freeze.

Then I used the V3 version. So far, it runs smoothly for about 2 hours. This looks promising, but we'll see in two or three days.

Here is the contents of the V3 patch:

--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -296,9 +296,8 @@

reg_dcdca: dcdca {
regulator-always-on;
-                regulator-min-microvolt = <800000>;
-                regulator-max-microvolt = <1160000>;
-                regulator-ramp-delay = <2500>;
+                regulator-min-microvolt = <810000>;
+                regulator-max-microvolt = <1080000>;
regulator-name = "vdd-cpu";
};

I don't have an answer to that (yet).

In fact, I customized your adjustments (made for LE11) for LE10.

Never mind, now I've learned a bit about working with the diff utility.

I will do some experiments and we will see which change is significant.

So I was finally successful.

Now I have a fully functional build LE10 for OPi3, including the necessary DT patch. And my experience so far is very positive.

The board is completely stable, no system freezes. It seems to confirm that the official file sun50i-h6-orangepi-3.dts is not correct. In any case, it does not correspond to a publicly known wiring diagram.

Quote from jernej

I have a feeling that this is not so common issue, otherwise there would be more complaints, either here or IRC #linux-sunxi.

Yes, that also amazes me a lot.

Here is the my patch for LE10: 0021-arm64-dts-allwinner-h6-OPi3-stability-LE10.patch

I can't compile it.

I created a 0021-arm64-dts-allwinner-h6-OPi3-stability.patch file to which I copied http://ix.io/3yMQ.

I placed this file in the location you specified.

Compilation failed:

APPLY PATCH (device)      projects/Allwinner/devices/H6/patches/linux/0021-arm64-dts-allwinner-h6-OPi3-stability.patch
patching file arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
Hunk #1 succeeded at 73 with fuzz 2 (offset 10 lines).
Hunk #2 succeeded at 155 (offset 39 lines).
Hunk #3 FAILED at 152.
Hunk #4 succeeded at 250 (offset 36 lines).
Hunk #5 succeeded at 265 (offset 36 lines).
1 out of 5 hunks FAILED -- saving rejects to file arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts.rej
*********** 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!

Contents of the sun50i-h6-orangepi-3.dts.rej file:

--- arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -152,13 +132,17 @@ &ohci3 {
&pio {
vcc-pc-supply = <&reg_bldo2>;
vcc-pd-supply = <&reg_cldo1>;
-    vcc-pg-supply = <&reg_vcc_wifi_io>;
+    vcc-pg-supply = <&reg_bldo3>;
};


&r_ir {
status = "okay";
};


+&r_pio {
+    vcc-pm-supply = <&reg_bldo3>;
+};
+
&r_rsb {
status = "okay";

Of course it's not certain yet (freezing is accidental), but it looks good!

It has only one flaw. This is LE11 and updating or installing LE add-ons fails.

How can I compile LE10 with the necessary changes?

Note: I am able to perform a normal compilation (eg with git checkout 10.0.0).

Quote from jernej

LuRu I think I found important difference. While it's true that wireless power supply is a mess, really important bit is CPU voltage range. I copied over One Plus values and my OPi3 seems to be much more stable. Please test this update:

Index of /test/opi3-stability/

That sounds promising!

As soon as I get home today, I'll try it right away. If it's okay, I'll get back to you in a few days. If it's not okay, I'll see it today or tomorrow at the latest.

BTW: I've done some attempts in the meantime (especially on the weekend), but I haven't been successful.

I have made considerable progress !

It was like this: At first I made one desperate attempt. I took a new SD card and wrote the LE image for the Orange Pi One Plus on it.

I inserted the card into the Orange Pi 3 and turned on the power. LE and Kodi started normally. I made some settings and installed (among other things) the PVR IPTV Simple Client add-on and my IPTV add-on. I used it for a few days, waiting for a total freeze to occur again. It didn't happen!

So it looks like the freeze problem is probably related to either USB3 or WiFi / BT. To rule out at least one of these, I decided to run at least USB3 (the absence of USB3 bothered me much more than the absence of WiFi and BT). So I found the source file sun50i-h6-orangepi-one-plus.dts and tried to compile it into sun50i-h6-orangepi-one-plus.dtb. But I couldn't. I was still getting the error message "FATAL ERROR: Unable to parse input tree".

So I did it differently. I took the sun50i-h6-orangepi-one-plus.dtb file located in the /flash folder and converted it to the sun50i-h6-orangepi-one-plus.dts file. There I enabled USB3 and did the conversion back to sun50i-h6-orangepi-one-plus.dtb.

I replaced the original file in the /flash folder and turned on the device. It worked - USB3 started working.

I used the device with the modified DT file again for a few days - it never froze!

Then I took the next step. I returned to the original SD card I had earlier in Orange Pi 3. There I replaced the original sun50i-h6-orangepi-3.dtb file with the modified sun50i-h6-orangepi-one-plus.dtb file. After switching on the device, the expected is confirmed: no total freezing.

Result: It seems that the total freezing of the Orange Pi 3 is related to either WiFi or BT. However, it is not enough if I use the original file sun50i-h6-orangepi-3.dtb and disable WiFi and BT in the settings of the LibreELEC add-on.

How do I proceed to find the real cause of the freeze?

Note: I'm still talking about "total freezing". So I say a state where the board did not respond to anything (except turning off the power or pressing the power button). This never happened while testing the device with a modified DT file. However, sometimes (always during IPTV playback) there was a temporary freeze (the image stopped and after a while Kodi restarted spontaneously). This is probably related to the mentioned ffmpeg. Interestingly, this crash never occurred on an Orange Pi 3 board with the original sun50i-h6-orangepi-3.dtb file.

I made an aluminum case for one of my media centers. It has a built-in LCD display and several buttons connected to the GPIO. I was looking for how other users are solving the problem of controlling Kodi via GPIO. I found some options, but I didn't like anything. That's why I decided to create my own add-on for this purpose. I named it GPIO keyboard.

My add-on works on the principle of keyboard emulation. Pressing the button calls up a normal keyboard shortcut. For this to work, I had to create one more add-on. This is actually a python-evdev library, modified into a Kodi add-on form. This (binary) add-on is named the same as the original library, thus python-evdev (id = "script.module.evdev"). The python-evdev library is very powerful, and I think its use in Kodi add-ons could be much greater.

The GPIO keyboard add-on allows you to configure up to 16 buttons. Each button can have two functions (short or long press).

I made both add-ons in two versions. One is for Orange Pi boards (Allwinner), the other for Raspberry Pi 4.

There is no dedicated support area for Raspberry Pi created here, so I publish it together in the Allwinner space.

The GPIO keyboard add-on depends not only on the python-evdev add-on, but also on the Orange Pi Tools (or Raspberry Pi Tools) add-on.

Allwinner_addon_service.gpio-keyboard-001.zip

RPi4_addon_service.gpio-keyboard-001.zip

Source_addon_module.evdev-001.zip

Compiled_addon_module.evdev-001.zip

Quote from mglae

This is fixed in the fresh mc 4.8.27. Expect a system-tools REV 125 update soon.

Great news. Thank you.

I have released new versions of add-ons. See the initial post of this topic for more information.

Quote from Joeker

This solved the problem.

I'm glad it helped. I had the same problem some time ago.

Quote from mglae

Try mc -u.

Thank you for the advice. It really helps.

What is the reason I have to disable subshell now, while before it was not necessary?

I recommend your attention this post.

Midnight Commander (part of virtual.system-tools) has not been working for several weeks. It starts, but then it freezes.

The last functional version was 9.80.11.121 (at least according to my tests).

Note: I run LibreELEC on the Allwinner platform, but I think it's the same on RPi4.

Quote from jernej

no need, just remove quiet from extlinux.conf. If you want terminal on serial, also add systemd.debug-shell=ttyS0

I had the quiet parameter removed before. Now I have also added systemd.debug-shell=ttyS0, so the serial console is fully functional.

So now I can use a serial console to communicate with the LE in a similar way as via an SSH connection.

Once it freezeed, I found that the system was not responding to the serial console either. Like when it's off.

Quote from Da Flex

From what we know until now, it won't hurt to do the test.

That's right, a memory test can't hurt. So I prepared an SD card with the Debian operating system. I found only one software for memory testing, a memtester.

I did some tests, but all the results were OK. Debian worked well, there was no freezing.

Then I did the same and with the same result with the Ubuntu operating system.

So there is no indication that my board is defective.

Nevertheless, I decided to buy another piece of the same board to see if the board was defective or not.

I am aware that in one case I will have two good boards, which, however, cannot be used with LibreELEC ...